> Kontinuierliche Prozessverbesserung > Order to Cash Prozess für Abrechnung und Rechnungsstellung > Microsoft Dynamics 365 > Daten Template

Ihr Daten-Template für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Microsoft Dynamics 365

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung (18) Aktivitäten im Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung (12) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Dieses Template zeigt Ihnen, welche Daten Sie für die Analyse Ihres Order-to-Cash-Prozesses im Bereich Abrechnung und Rechnungsstellung erfassen sollten. Es enthält empfohlene Attribute für Ihr Event Log, wichtige Aktivitäten, die Sie verfolgen sollten, und praktische Hinweise zum Extrahieren der Daten. So können Sie Ihre Daten schnell für aussagekräftiges Process Mining aufbereiten.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten zur Erfassung
Anleitung zum Extrahieren von Daten aus Microsoft Dynamics 365

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie den Order-to-Cash-Prozess im Bereich Abrechnung und Rechnungsstellung umfassend analysieren können.

3 Erforderlich 6 Empfohlen 9 Optional

	Name	Beschreibung
	Rechnungsnummer InvoiceNumber	Die eindeutige Kennung jeder Kundenrechnung. Sie dient als zentrale Case-ID für den Abrechnungsprozess.
Beschreibung Die Rechnungsnummer ist der zentrale Schlüssel, der alle Aktivitäten zu einem einzelnen Abrechnungsdokument zusammenfasst. Sie ermöglicht eine vollständige Analyse des Rechnungslebenszyklus, von der Erstellung und Genehmigung bis zum Zahlungseingang und endgültigen Abschluss. Wird sie als Case-ID verwendet, gehört jeder Eintrag im Event Log zu einer bestimmten Rechnung. So lassen sich Varianten detailliert analysieren, Durchlaufzeiten berechnen und die Leistung jeder Abrechnungstransaktion überwachen. Warum das wichtig ist Dieses Attribut ist unverzichtbar, um den gesamten Lebenszyklus einer Rechnung nachzuverfolgen und Effizienz, Engpässe sowie Abweichungen für jedes einzelne Abrechnungsdokument zu analysieren. Woher beziehen Dieses Attribut findet sich üblicherweise im Modul Vertrieb und Marketing, in Tabellen wie CustInvoiceJour (Feld InvoiceId) oder über Datenentitäten wie SalesInvoiceHeaderV2. Beispiele CIV-001254INV-2023-9876US-004321
	Aktivitätsname ActivityName	Der Name der geschäftlichen Aktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt im Lebenszyklus einer Rechnung stattgefunden hat.
Beschreibung Dieses Attribut bezeichnet einen bestimmten Schritt oder Meilenstein im Abrechnungsprozess, etwa „Rechnung erstellt“, „Rechnung genehmigt“ oder „Kundenzahlung eingegangen“. Die Abfolge dieser Aktivitäten bildet den Prozessablauf. Ihre Analyse ist eine Grundlage für Process Mining: Sie ermöglicht es, Prozessmodelle zu ermitteln, Varianten zu erkennen und die Leistung zwischen einzelnen Schritten zu messen. Warum das wichtig ist Dieses Attribut legt die Prozessschritte fest. Damit lassen sich Prozessmodelle visualisieren, Prozessvarianten analysieren und Engpässe oder Abweichungen von der Standardvorgehensweise erkennen. Woher beziehen Dieses Attribut wird üblicherweise aus mehreren Quellen abgeleitet, etwa aus Feldern für Statusänderungen (z. B. DocumentState), ausgefüllten Datumsfeldern oder Workflow-Verlaufsprotokollen in Microsoft Dynamics 365. Beispiele Rechnung erstelltRechnung genehmigtKundenzahlung eingegangenGutschrift ausgestellt
	Ereigniszeitpunkt EventTime	Der genaue Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Ereigniszeit, auch Timestamp genannt, erfasst für jede Aktivität im Prozess das genaue Datum und die genaue Uhrzeit. Diese Daten sind für alle zeitbezogenen Process-Mining-Analysen entscheidend. Sie dienen dazu, Durchlaufzeiten zwischen Aktivitäten und die Gesamtdauer eines Case zu berechnen sowie die Prozessleistung im Zeitverlauf zu untersuchen. Genaue und verlässliche Timestamps bilden die Grundlage für KPIs wie Days Sales Outstanding und die Dauer der Rechnungserstellung. Warum das wichtig ist Dieses grundlegende Attribut ermöglicht alle leistungs- und zeitbezogenen Analysen. Damit lassen sich Durchlaufzeiten, Dauern und Durchsatz berechnen, um die Prozesseffizienz zu messen. Woher beziehen Die Timestamps stammen aus verschiedenen Datums- und Zeitfeldern in unterschiedlichen Dynamics-365-Tabellen, zum Beispiel aus CreatedDateTime in der Tabelle CustInvoiceJour für die Rechnungserstellung oder aus bestimmten Zeitstempeln der Workflow-Historie. Beispiele 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Abteilung Department	Die Fachabteilung, der der Benutzer oder die Aktivität zugeordnet ist.
Beschreibung Dieses Attribut ordnet eine Aktivität oder einen Benutzer einer bestimmten Abteilung zu, zum Beispiel „Debitorenbuchhaltung“ oder „Vertrieb“. Damit lässt sich die Prozessleistung auf einer höheren Ebene als der einzelner Benutzer betrachten. Die Analyse nach Abteilungen zeigt abteilungsübergreifende Übergaben, ermöglicht Effizienzvergleiche zwischen Teams und macht Engpässe auf Abteilungsebene sichtbar. Diese Auswertung wird vom Dashboard „Arbeitsauslastung der Abrechnungsabteilung“ benötigt. Warum das wichtig ist Das Attribut ermöglicht die Analyse der Leistung auf Organisationsebene. So können Sie die Effizienz verschiedener Teams vergleichen und untersuchen, wie sich Übergaben zwischen Abteilungen auf den Prozess auswirken. Woher beziehen Dieses Feld ist in der Regel nicht direkt in der Rechnungstransaktion enthalten. Es wird ermittelt, indem die UserResponsible-ID mit dem Mitarbeiter- oder Benutzerverzeichnis verknüpft wird, das die Abteilungsinformationen enthält. Beispiele DebitorenbuchhaltungFinanzenAbrechnungsbetrieb
	Kundenname CustomerName	Der Name des Kunden, an den die Rechnung gestellt wurde.
Beschreibung Der Kundenname bezeichnet das abgerechnete Unternehmen oder die abgerechnete Person in lesbarer Form. Bei der Process-Mining-Analyse können Sie den Abrechnungsprozess nach Kunden aufschlüsseln. So wird sichtbar, welche Kunden regelmäßig pünktlich zahlen und bei welchen es häufig zu Verspätungen kommt. Außerdem lassen sich besondere Prozessabweichungen oder Verzögerungen bei bestimmten Kundengruppen erkennen. Das Attribut ist wichtig für Dashboards zum Zahlungsverhalten und zur Analyse des Days Sales Outstanding. Warum das wichtig ist Damit können Sie Prozesse nach Kunden aufschlüsseln und kundenspezifisches Verhalten, Zahlungsmuster oder Prozessprobleme erkennen. Woher beziehen Diese Information wird abgerufen, indem die Rechnungsdaten anhand der Kundennummer mit den Kundendaten verknüpft werden, üblicherweise aus der Tabelle CustTable. Beispiele Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Rechnungsbetrag InvoiceAmount	Der Gesamtbetrag der Rechnung.
Beschreibung Dieses Attribut gibt den Gesamtbetrag der Rechnung an. Als wichtige Kennzahl für die Finanzanalyse ermöglicht es, Rechnungen nach Betrag zu gruppieren. Analysten können beispielsweise Rechnungen mit hohen Beträgen untersuchen, um das Zahlungsverhalten zu verstehen oder festzustellen, ob deren Freigabe länger dauert. Der Rechnungsbetrag ist außerdem eine wichtige Grundlage für die Berechnung des Gesamtwerts offener Rechnungen und des Days Sales Outstanding. Warum das wichtig ist Damit lässt sich die finanzielle Auswirkung analysieren. Sie können Prozesse nach Betrag filtern und gruppieren, um Rechnungen mit hohen Beträgen zu priorisieren und ihre spezifischen Prozessabläufe zu untersuchen. Woher beziehen In der Tabelle CustInvoiceJour, üblicherweise in einem Feld wie InvoiceAmount. Der Betrag ist auch in zugehörigen Transaktionstabellen verfügbar. Beispiele 5430.5012500.00750.25
	Rechnungsstatus InvoiceStatus	Der aktuelle Status der Rechnung in ihrem Lebenszyklus, zum Beispiel offen, bezahlt oder storniert.
Beschreibung Dieses Attribut zeigt den aktuellen Stand der Rechnung. Es gibt an, ob die Zahlung noch aussteht, die Rechnung vollständig bezahlt oder überfällig ist oder ob sie durch eine Gutschrift storniert wurde. Sie können damit beispielsweise nur offene Rechnungen filtern oder das Endergebnis abgeschlossener Rechnungen prüfen. So lassen sich die aktuelle Arbeitslast und die finanzielle Situation der Forderungen besser einschätzen. Warum das wichtig ist Das Attribut zeigt auf einen Blick den aktuellen Rechnungsstatus. Es erleichtert das Filtern von Cases und die Analyse der Ergebnisse verschiedener Prozessvarianten. Woher beziehen Der Status lässt sich aus dem Zahlungsstatus der Rechnung ableiten, häufig durch Prüfung, ob der Saldo des zugehörigen CustTrans-Datensatzes null ist. Ein einzelnes Statusfeld gibt es nicht immer. Beispiele OffenBezahltÜberfälligStorniert
	Verantwortlicher Benutzer UserResponsible	Der Benutzer oder Mitarbeitende, der für die Ausführung einer bestimmten Aktivität verantwortlich ist.
Beschreibung Dieses Attribut gibt an, wer eine bestimmte Aufgabe im Abrechnungsprozess ausgeführt hat, zum Beispiel eine Rechnung freigegeben oder eine Zahlung zugeordnet hat. Es ist wichtig für die Analyse der Arbeitsauslastung und den Leistungsvergleich sowie für die Ermittlung des Schulungsbedarfs. Das Dashboard „Arbeitsauslastung der Abrechnungsabteilung“ verwendet das Attribut beispielsweise, um zu prüfen, ob die Arbeit gleichmäßig verteilt ist oder einzelne Benutzer zum Engpass werden. Außerdem hilft es, die Ressourcenzuteilung und Effizienz zu beurteilen. Warum das wichtig ist Das Attribut ermöglicht Analysen auf Ressourcenebene. So lassen sich Engpässe erkennen, die Leistung einzelner Mitarbeitender oder Teams messen und die Arbeitsauslastung in der Abrechnungsabteilung untersuchen. Woher beziehen Die Daten können aus Workflow-Historien stammen, zum Beispiel aus der Tabelle WorkflowTrackingStatusTable, oder aus Zuständigkeitsfeldern wie Owner oder ModifiedBy in relevanten Tabellen. Beispiele John SmithAlicia BakerSystemadministrator
	Zahlungsziel PaymentDueDate	Das Datum, bis zu dem der Kunde die Rechnung voraussichtlich bezahlt.
Beschreibung Das Zahlungsziel ist ein wichtiges Datumsfeld. Es wird anhand des Rechnungsdatums und der Zahlungsbedingungen des Kunden berechnet und dient als Grundlage für die Messung der Zahlungspünktlichkeit. Das Attribut ist für das Dashboard „Analyse der Einhaltung von Zahlungsbedingungen“ sowie für die Berechnung von KPIs wie „Pünktliche Zahlungsquote“ und „Days Sales Outstanding“ erforderlich. Der Vergleich mit dem tatsächlichen Zahlungsdatum zeigt das Zahlungsverhalten der Kunden und die Wirksamkeit des Forderungseinzugs. Warum das wichtig ist Das Zahlungsziel ist der Maßstab für die Bewertung der Zahlungsleistung. Es ist wichtig, um die Quote pünktlicher Zahlungen zu berechnen und die Einhaltung der Zahlungsbedingungen durch Kunden zu analysieren. Woher beziehen Üblicherweise in der Tabelle CustInvoiceJour in einem Feld wie DueDate. Beispiele 2023-05-152023-06-302023-07-01
	Days Sales Outstanding DaysSalesOutstanding	Die Anzahl der Tage zwischen der Rechnungserstellung und dem Eingang der Kundenzahlung.
Beschreibung Days Sales Outstanding (DSO) ist eine wichtige Finanzkennzahl. Sie misst, wie viele Tage ein Unternehmen nach einem Verkauf durchschnittlich benötigt, um die Zahlung einzuziehen. Dieses berechnete Attribut ermittelt die Dauer für jede einzelne Rechnung. Es ist die zentrale Kennzahl im Dashboard „Trendanalyse des Days Sales Outstanding“ und für den KPI „DSO“. Die Analyse des DSO unterstützt das Cashflow-Management und die Bewertung der Effizienz von Kreditmanagement und Forderungseinzug. Warum das wichtig ist Dieser wichtige KPI misst die Liquidität eines Unternehmens und die Effizienz des Forderungseinzugs. Er zeigt, wie schnell Umsätze in liquide Mittel umgewandelt werden. Woher beziehen Dieses Attribut ist im Quellsystem nicht enthalten. Es wird als Zeitraum zwischen den Aktivitäten „Rechnung erstellt“ und „Kundenzahlung eingegangen“ berechnet. Beispiele 284592
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp gibt an, wann die Daten zu diesem Ereignis zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst, wann die Daten zuletzt aus Microsoft Dynamics 365 extrahiert oder aktualisiert wurden. Als Metadatenfeld ist es wichtig, um die Aktualität der analysierten Daten einzuschätzen. So erkennen Analysten und Fachanwender, ob sie mit den neuesten Informationen arbeiten. Außerdem ist das Attribut für die Planung von Datenaktualisierungen und die Zuverlässigkeit der Analyse relevant. Warum das wichtig ist Das Attribut zeigt, wie aktuell die Daten sind. Das ist wichtig für die Data Governance, die Verwaltung von Dashboard-Aktualisierungen und das Vertrauen in die Aktualität der Erkenntnisse. Woher beziehen Dieses Attribut wird während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Manueller Eingriff erforderlich RequiresManualIntervention	Kennzeichnet, ob eine Zahlung bei der Zahlungszuordnung manuell angepasst werden musste.
Beschreibung Dieses boolesche Attribut kennzeichnet Zahlungen, die bei der Zahlungszuordnung manuell bearbeitet oder korrigiert werden mussten. Es ist wichtig für den KPI „Abweichungsquote bei der Zahlungszuordnung“, da es die Genauigkeit und den Automatisierungsgrad der Zahlungsbuchung messbar macht. Wenn Sie die Gründe für manuelle Eingriffe ermitteln, etwa fehlende Überweisungsinformationen oder Zahlungsabweichungen, können Sie den Prozess verbessern und den Anteil der vollständig automatisierten Verarbeitung erhöhen. Warum das wichtig ist Dieses Attribut macht Reibungsverluste und Ungenauigkeiten bei der Zahlungszuordnung sichtbar. Das ist wichtig, um die Automatisierung zu verbessern und den manuellen Aufwand zu verringern. Woher beziehen Die Information lässt sich möglicherweise aus dem Benutzer ableiten, der die Zahlung gebucht hat, sofern es sich nicht um einen Systembenutzer handelt. Auch bestimmte Ursachencodes beim Zahlungsabgleich können Hinweise liefern. Ziehen Sie die Dokumentation zu Microsoft Dynamics 365 heran. Beispiele truefalse
	Nacharbeit IsRework	Kennzeichnet, ob im Rechnungsprozess Nacharbeiten erforderlich waren, zum Beispiel mehrere Freigaben.
Beschreibung Dieses berechnete boolesche Attribut kennzeichnet Rechnungen, bei denen Nacharbeiten angefallen sind. Als Nacharbeit gelten beispielsweise mehrere Ereignisse vom Typ „Rechnung freigegeben“ oder Rückbuchungen von Zahlungen. Das Attribut unterstützt gezielt das Dashboard „Rechnungsnacharbeitsanalyse“ und den KPI „Nacharbeitsquote bei Rechnungen“. Durch die gezielte Untersuchung dieser Cases können Analysten die Ursachen für Nacharbeiten ermitteln. Häufig weisen sie auf ineffiziente Prozesse, Probleme mit der Datenqualität oder fehlenden Schulungsbedarf hin. Warum das wichtig ist Das Kennzeichen macht Prozessineffizienz messbar, indem es Cases mit wiederholten oder korrigierenden Aktivitäten identifiziert. So lassen sich Ursachen für Verschwendung und Verzögerungen eingrenzen. Woher beziehen Dieses Attribut ist im Quellsystem nicht verfügbar. Es wird in der Datentransformationsschicht berechnet, indem wiederholte Aktivitäten oder bestimmte Nacharbeitsmuster innerhalb eines Cases geprüft werden. Beispiele truefalse
	Pünktliche Zahlung IsOnTimePayment	Kennzeichnet, ob die Zahlung des Kunden am oder vor dem Fälligkeitsdatum eingegangen ist.
Beschreibung Dieses berechnete boolesche Attribut vergleicht den Timestamp von „Kundenzahlung eingegangen“ mit dem Zahlungsziel. Es kennzeichnet jede Rechnung als pünktlich oder verspätet bezahlt. Das Attribut ist die Grundlage für die Berechnung des KPIs „Pünktliche Zahlungsquote“ und wird häufig im Dashboard „Analyse der Einhaltung von Zahlungsbedingungen“ verwendet. Das eindeutige Ergebnis vereinfacht die Analyse und Berichterstattung zur Zahlungsleistung. Warum das wichtig ist Das Attribut misst direkt, ob Kunden ihre Zahlungsbedingungen einhalten. Es bildet die Grundlage für den KPI „Pünktliche Zahlungsquote“ und vereinfacht die Analyse der Effektivität des Forderungseinzugs. Woher beziehen Dieses Attribut ist im Quellsystem nicht enthalten. Es wird bei der Datentransformation berechnet, indem das Zahlungsdatum mit PaymentDueDate verglichen wird. Beispiele truefalse
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt an, woher die Prozessdaten stammen. In diesem Fall kommen sie aus Microsoft Dynamics 365. In Umgebungen mit mehreren Systemen lassen sich damit Datenquellen unterscheiden und die Datenherkunft nachvollziehen. Das erleichtert die Datenvalidierung und die Fehlersuche. Warum das wichtig ist Das Attribut liefert wichtige Informationen zur Datenherkunft. Diese sind für Data Governance und Validierung sowie beim Zusammenführen von Daten aus mehreren Unternehmenssystemen unerlässlich. Woher beziehen Dieser statische Wert wird bei der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Microsoft Dynamics 365 FinanceD365 F&O
	Verkaufsauftragsnummer SalesOrderNumber	Die Kennung des Verkaufsauftrags, aus dem die Rechnung hervorgegangen ist.
Beschreibung Die Verkaufsauftragsnummer verknüpft den Abrechnungsprozess mit dem vorangegangenen Vertriebsprozess. Das ist besonders wertvoll für eine umfassende Order-to-Cash-Analyse. Analysten können untersuchen, ob Probleme im Vertrieb oder in der Auftragsabwicklung, etwa Auftragsänderungen oder Lieferverzögerungen, den Abrechnungszyklus beeinflussen. So lässt sich beispielsweise die Frage beantworten, ob Rechnungen aus komplexen Verkaufsaufträgen später bezahlt werden. Warum das wichtig ist Dieses Attribut verknüpft den Abrechnungsprozess mit dem vorgelagerten Vertriebsprozess. So wird eine umfassendere End-to-End-Analyse des Order-to-Cash-Prozesses möglich, mit der sich die Ursachen von Abrechnungsproblemen ermitteln lassen. Woher beziehen Die Nummer steht im Rechnungskopf oder in den Rechnungspositionen und verweist auf den Verkaufsauftrag. Suchen Sie in der Tabelle CustInvoiceJour nach einem Feld wie SalesId. Beispiele SO-009876SO-010234US-SO-00543
	Währung Currency	Der Währungscode des Rechnungsbetrags, zum Beispiel USD oder EUR.
Beschreibung Dieses Attribut gibt an, in welcher Währung der Rechnungsbetrag ausgewiesen ist. Es ist für international tätige Unternehmen mit mehreren Währungen unerlässlich. Ohne diese Information lassen sich Rechnungsbeträge nicht sinnvoll zusammenfassen oder vergleichen. Das Attribut ermöglicht die korrekte Währungsumrechnung sowie genaue Finanzberichte und Analysen über verschiedene Regionen hinweg. Warum das wichtig ist Das Attribut liefert den nötigen Kontext für Finanzkennzahlen wie den Rechnungsbetrag. So werden fehlerhafte Summierungen vermieden und genaue Analysen in Umgebungen mit mehreren Währungen ermöglicht. Woher beziehen In der Tabelle CustInvoiceJour, üblicherweise in einem Feld wie CurrencyCode. Beispiele USDEURGBP
	Zahlungsbedingungen PaymentTerms	Die vereinbarten Bedingungen für die Rechnungszahlung, zum Beispiel 30 oder 60 Tage netto.
Beschreibung Die Zahlungsbedingungen legen fest, wann ein Kunde eine Rechnung voraussichtlich bezahlt. Dieses Attribut dient zur Berechnung des Zahlungsziels und ist eine wichtige Dimension für die Analyse des Zahlungsverhaltens. Das Dashboard „Analyse der Einhaltung von Zahlungsbedingungen“ gruppiert Kunden und Rechnungen nach diesem Attribut. So lässt sich erkennen, welche Zahlungsbedingungen sich bewähren und bei welchen häufiger verspätete Zahlungen auftreten. Warum das wichtig ist Das Attribut erklärt, warum eine Rechnung zu einem bestimmten Datum fällig ist. Außerdem können Sie damit analysieren, ob bestimmte Zahlungsbedingungen mit verspäteten Zahlungen zusammenhängen. Woher beziehen Die Zahlungsbedingungen sind üblicherweise im Kundenstammsatz gespeichert und werden in den Rechnungskopf übernommen. Suchen Sie in der Tabelle CustInvoiceJour nach einem Feld wie Payment oder PaymTermId. Beispiele 30 Tage netto60 Tage nettoFällig bei Erhalt

Erforderlich Empfohlen Optional

Aktivitäten im Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, um den Prozess zuverlässig zu entdecken und zu analysieren.

7 Empfohlen 5 Optional

	Aktivität	Beschreibung
	Kundenzahlung eingegangen	Diese Aktivität kennzeichnet die Erstellung eines Journaleintrags zur Erfassung einer Kundenzahlung. Sie zeigt an, dass Geld eingegangen ist, aber noch keiner bestimmten Rechnung zugeordnet wurde.
Warum das wichtig ist Dies ist der Ausgangspunkt für die Messung der Durchlaufzeit bis zur Zahlungszuordnung. So lässt sich der Zahlungseingang vom Abgleich mit offenen Rechnungen unterscheiden. Woher beziehen Erfasst anhand der Erstellung oder Buchung eines Kundenzahlungsjournals. Der Vorgang wird in Tabellen wie LedgerJournalTrans protokolliert. Bei der Buchung wird anschließend eine Kundentransaktion in CustTrans angelegt. Erfassung Verwenden Sie den Buchungs-Timestamp des Kundenzahlungsjournals aus LedgerJournalTable. Ereignistyp explicit
	Rechnung abgeschlossen	Diese Aktivität kennzeichnet den Endstatus einer Rechnung. Ihr Saldo beträgt null, weil sie vollständig bezahlt oder durch Gutschriften ausgeglichen wurde. Es handelt sich nicht um eine direkte Transaktion, sondern um einen aus dem Finanzstatus der Rechnung abgeleiteten Zustand.
Warum das wichtig ist Dieses Ereignis zeigt den erfolgreichen Abschluss des Order-to-Cash-Zyklus für eine einzelne Rechnung an. Die Zeit bis zu diesem Zustand ist eine zentrale Kennzahl für die Gesamteffizienz des Prozesses. Woher beziehen Abgeleitet aus der Prüfung, ob der offene Saldo der Rechnungstransaktion in der Tabelle CustTrans null beträgt. Dazu wird der Rechnungsbetrag mit dem gesamten Ausgleichsbetrag verglichen. Erfassung Leiten Sie das Ereignis aus CustTrans-Datensätzen ab, bei denen AmountCur dem SettleAmountCur entspricht. Als Timestamp dient das Datum des letzten Ausgleichs. Ereignistyp inferred
	Rechnung an Kunden gesendet	Diese Aktivität kennzeichnet den Zeitpunkt, zu dem die Rechnung elektronisch oder postalisch an den Kunden übermittelt wurde. In Dynamics 365 kann dies als eigenes Ereignis erfasst werden, wenn der Versand über die System-E-Mail erfolgt. Ist keine spezielle Nachverfolgung eingerichtet, lässt sich der Zeitpunkt aus der Buchung ableiten.
Warum das wichtig ist Damit wird die Effizienz der Rechnungszustellung gemessen. Eine Verzögerung zwischen Genehmigung und Versand verlängert den Zahlungszyklus unnötig. Woher beziehen Bei Verwendung der E-Mail-Funktionen von D365 lässt sich der Versand explizit anhand von E-Mail-Protokollen wie SysOutgoingEmailTable erfassen. Andernfalls wird häufig der Buchungszeitpunkt der Rechnung aus CustInvoiceJour herangezogen. Erfassung Verwenden Sie den Timestamp des E-Mail-Protokolls, falls verfügbar. Andernfalls verwenden Sie den Buchungs-Timestamp der Rechnung. Ereignistyp inferred
	Rechnung erstellt	Kennzeichnet die Erstellung und Buchung des Verkaufsrechnungsdokuments im System. In Dynamics 365 ist dies eine explizite Transaktion, durch die ein rechtsgültiges Dokument und Finanzbuchungen im Nebenbuch der Debitorenbuchhaltung entstehen.
Warum das wichtig ist Damit beginnt offiziell der Abrechnungszyklus einer Rechnung. Dieses wichtige Ereignis dient dazu, den Days Sales Outstanding (DSO) und die Gesamtdauer des Prozesses zu verfolgen. Woher beziehen Erfasst anhand des Erstellungs-Timestamps des gebuchten Verkaufsrechnungssatzes in der Tabelle CustInvoiceJour. Bei der Buchung werden die zugehörigen Finanztransaktionen in den Tabellen GeneralJournalEntry und LedgerEntry angelegt. Erfassung Verwenden Sie für die gebuchte Rechnung das Feld CreatedDateTime aus der Tabelle CustInvoiceJour. Ereignistyp explicit
	Rechnung genehmigt	Kennzeichnet den Abschluss der internen Prüfung und die formelle Genehmigung der Rechnung. Das Ereignis wird vom Dynamics-365-Workflow-System protokolliert und zeigt an, dass die Rechnung an den Kunden gesendet werden kann.
Warum das wichtig ist Dieser wichtige Meilenstein dient zur Messung der Durchlaufzeit der Genehmigung. Verzögerungen in dieser Phase können die Zeit bis zum Zahlungseingang direkt verlängern. Woher beziehen Wird in den Workflow-Verlaufstabellen, etwa WorkflowTrackingStatusTable, als Abschluss- oder Genehmigungsschritt der jeweiligen Rechnungs-Workflow-Instanz erfasst. Erfassung Extrahieren Sie Workflow-Event-Logs mit dem Status „Genehmigt“ oder „Abgeschlossen“. Ereignistyp explicit
	Zahlung der Rechnung zugeordnet	Kennzeichnet den Ausgleich einer Kundenzahlung mit einer bestimmten Rechnung, wodurch sich deren offener Saldo verringert. In Dynamics 365 ist dies ein eigener Schritt, der die Zahlungstransaktion mit der Rechnungstransaktion verknüpft.
Warum das wichtig ist Dieser wichtige Meilenstein ermöglicht eine genaue Berechnung des DSO und zeigt, wie effizient das Team für Zahlungszuordnungen arbeitet. Er markiert den Zeitpunkt, an dem die Zahlung vollständig mit dem Rechnungsbetrag abgeglichen ist. Woher beziehen Wird in der Tabelle CustSettlement erfasst. Das Feld für das Ausgleichsdatum in dieser Tabelle enthält den Timestamp, zu dem eine bestimmte Zahlung einer bestimmten Rechnungstransaktion zugeordnet wurde. Erfassung Verwenden Sie TransDate oder CreatedDateTime aus der Tabelle CustSettlement. Ereignistyp explicit
	Zahlungsfälligkeit erreicht	Ein berechnetes Ereignis, das eintritt, wenn die Rechnung fällig ist und noch nicht vollständig bezahlt wurde. Es entspricht keiner Transaktion im System, sondern wird aus vorhandenen Daten abgeleitet.
Warum das wichtig ist Dieses Ereignis ist wichtig, um die Pünktlichkeit von Zahlungen zu analysieren und Rechnungen zu erkennen, die überfällig werden. Es markiert den Beginn von Maßnahmen zum Forderungseinzug und des Mahnprozesses. Woher beziehen Dieses Ereignis wird nicht protokolliert, sondern anhand des Felds DueDate in der Tabelle CustInvoiceJour berechnet. Als Ereignis-Timestamp dient das Fälligkeitsdatum selbst. Erfassung Erstellen Sie ein Ereignis, dessen Timestamp dem Wert des Felds CustInvoiceJour.DueDate entspricht. Ereignistyp calculated
	Gutschrift ausgestellt	Kennzeichnet die Erstellung einer Gutschrift, etwa zur Korrektur eines Abrechnungsfehlers, für eine Preisanpassung oder für zurückgesendete Waren. Eine Gutschrift entspricht im Wesentlichen einer negativen Rechnung.
Warum das wichtig ist Häufige Gutschriften können auf systematische Probleme bei der Auftragserfüllung oder Rechnungsstellung hindeuten. Die Gründe für Gutschriften zu analysieren, ist wichtig, um Prozesse zu verbessern und Umsatzverluste zu vermeiden. Woher beziehen Dies ist eine explizite Transaktion, die in der Tabelle CustInvoiceJour als neu gebuchte Rechnung mit negativem Betrag erfasst wird. Häufig ist sie über ein Referenzfeld mit der ursprünglichen Rechnung verknüpft. Erfassung Ermitteln Sie Datensätze in CustInvoiceJour mit einem negativen Gesamtbetrag und verknüpfen Sie diese mit der ursprünglichen Rechnung. Ereignistyp explicit
	Kundenauftrag erfüllt	Diese Aktivität kennzeichnet den Zeitpunkt, an dem Waren versendet oder Dienstleistungen für einen Kundenauftrag erbracht wurden. Damit beginnt der Abrechnungsprozess. In Microsoft Dynamics 365 lässt sich dies in der Regel aus der Buchung eines Lieferscheins ableiten, durch die sich der Status der zugehörigen Auftragspositionen ändert.
Warum das wichtig ist Dieses Ereignis ist der Ausgangspunkt für die Messung der Durchlaufzeit bis zur Rechnungserstellung. Wenn Sie die Verzögerung zwischen Auftragserfüllung und Rechnungsstellung kennen, können Sie administrative Engpässe erkennen, die den Cashflow beeinträchtigen. Woher beziehen Abgeleitet aus dem Erstellungsdatum eines Lieferscheinjournals, das mit dem Kundenauftrag verknüpft ist. Dazu gehören Tabellen wie CustPackingSlipJour und CustPackingSlipTrans, die mit dem Auftrag verknüpft sind, auf dem die Rechnung basiert. Erfassung Ermitteln Sie das jüngste Buchungsdatum eines Lieferscheins für den Kundenauftrag, der mit der Rechnung verknüpft ist. Ereignistyp inferred
	Rechnung zur Genehmigung eingereicht	Diese Aktivität zeigt an, dass eine erstellte Rechnung einem formellen Genehmigungs-Workflow übergeben wurde. Das ist in Unternehmen üblich, in denen Rechnungen vor dem Versand an Kunden von der Geschäftsleitung geprüft werden müssen. Die Aktivität wird als eigener Schritt in der D365-Workflow-Engine protokolliert.
Warum das wichtig ist Wenn Sie die Einreichung zur Genehmigung verfolgen, können Sie die Erstellungszeit der Rechnung von der Wartezeit auf die Genehmigung unterscheiden. Das ist der erste Schritt, um die Effizienz interner Prüf- und Kontrollprozesse zu analysieren. Woher beziehen Erfasst anhand der Workflow-Verlaufstabellen, etwa WorkflowTrackingStatusTable, indem das Einreichungsereignis für das Rechnungsdokument herausgefiltert wird. Erfassung Extrahieren Sie Workflow-Event-Logs mit dem Status „Eingereicht“. Ereignistyp explicit
	Zahlung storniert	Diese Aktivität kennzeichnet die Stornierung einer zuvor gebuchten Kundenzahlung. Gründe dafür können Buchungsfehler, unzureichende Deckung oder andere Zahlungsprobleme sein.
Warum das wichtig ist Stornierte Zahlungen weisen auf betriebliche Fehler oder Probleme mit Kundenzahlungen hin. Die Analyse ihrer Häufigkeit hilft, Ursachen zu erkennen und die Genauigkeit der Zahlungszuordnung zu verbessern. Woher beziehen Wird als Transaktionsstornierung im Hauptbuch erfasst. Ein storniertes Journal lässt sich in GeneralJournalEntry erkennen, häufig anhand eines speziellen Kennzeichens oder der Verknüpfung mit der ursprünglichen Transaktion. Erfassung Ermitteln Sie Journaleinträge mit einem Stornierungskennzeichen oder einem Verweis auf eine stornierte Transaktion. Ereignistyp explicit
	Zahlungserinnerung versendet	Kennzeichnet den Versand eines Mahnschreibens oder einer Zahlungserinnerung an einen Kunden zu einer überfälligen Rechnung. Dynamics 365 verfügt über einen formellen Mahnprozess, der diese Mitteilungen erstellt und protokolliert.
Warum das wichtig ist Anhand der Zahlungserinnerungen lässt sich die Wirksamkeit des Mahnprozesses bewerten. Sie können analysieren, wie viele Erinnerungen bis zum Zahlungseingang erforderlich sind. Woher beziehen Dieses explizite Ereignis wird anhand des Erstellungsdatums des Mahnjournals in der Tabelle CustCollectionLetterJour erfasst. Das Journal ist mit der überfälligen Rechnungstransaktion verknüpft. Erfassung Verwenden Sie den Erstellungs-Timestamp aus der Tabelle CustCollectionLetterJour. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Microsoft Dynamics 365

Schritte

Öffnen Sie den Data Management Workspace: Melden Sie sich bei Microsoft Dynamics 365 Finance and Operations an. Suchen Sie über die Suchleiste den Workspace Data management und öffnen Sie ihn. Hier verwalten Sie alle Datenimporte und -exporte.
Erstellen Sie ein neues Exportprojekt: Klicken Sie im Workspace Data management auf die Kachel Export, um ein neues Datenexportprojekt anzulegen. Geben Sie dem Projekt einen aussagekräftigen Namen, zum Beispiel ProcessMind_O2C_Billing_Export, und eine Beschreibung.
Wählen Sie das Zielformat aus: Legen Sie in der Projektkonfiguration das Target data format fest. Wählen Sie CSV, damit die Daten mit den meisten Datentransformationstools kompatibel sind. Passen Sie die Formatoptionen an und achten Sie auf einheitliche Trenn- und Textbegrenzungszeichen.
Fügen Sie die benötigten Data Entities hinzu: Dieser Schritt ist besonders wichtig. Fügen Sie Ihrem Projekt mehrere Standard-Data-Entities hinzu, um alle erforderlichen Aktivitäten zu erfassen. Klicken Sie für jede Entity auf Add entity und suchen Sie nach dem Namen, der im Abschnitt Query/Script aufgeführt ist. Fügen Sie diese Entities hinzu: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement und Dunning history letters.
Filtern Sie die Entities: Schränken Sie die Daten auf einen relevanten Bereich ein. Filtern Sie mindestens Sales invoice headers V2 anhand von InvoiceDate nach einem bestimmten Zeitraum, zum Beispiel den letzten 6 Monaten. Filtern Sie außerdem nach den Rechtseinheiten (Unternehmen), die Sie analysieren möchten.
Starten Sie den Export: Sobald Sie alle Entities hinzugefügt und die Filter gesetzt haben, klicken Sie im Aktionsbereich auf Export. Das System erstellt ein Auftragspaket und verarbeitet den Datenexport im Hintergrund.
Überwachen Sie den Auftrag und laden Sie die Daten herunter: Den Fortschritt sehen Sie im Abschnitt Job history. Nach erfolgreichem Abschluss können Sie das exportierte Datenpaket herunterladen. Es handelt sich um eine ZIP-Datei mit separaten CSV-Dateien für jede Data Entity.
Entpacken Sie das Paket: Extrahieren Sie den Inhalt der heruntergeladenen ZIP-Datei in einen lokalen Ordner. Dort finden Sie mehrere CSV-Dateien, jeweils eine pro Entity.
Transformieren und kombinieren Sie die Daten: Transformieren Sie die Rohdaten in ein einzelnes Event Log. Verwenden Sie dazu ein Datenaufbereitungstool wie Power Query, Python oder einen Datenbank-Staging-Bereich. Erstellen Sie für jede Quelldatei die erforderlichen Spalten: InvoiceNumber (Case-ID), ActivityName (ein festgelegter Wert für das Ereignis, zum Beispiel „Rechnung erstellt“) und EventTime (das relevante Datumsfeld aus der Quelldatei). Ordnen Sie weitere Attribute wie InvoiceAmount und CustomerName zu.
Führen Sie alle transformierten Daten zusammen: Kombinieren Sie die transformierten Daten aus allen Quelldateien mithilfe einer Union- oder Append-Operation in einer einzigen Tabelle. So entsteht das endgültige, einheitliche Event Log, in dem jede Zeile eine Aktivität im Lebenszyklus der Rechnung abbildet.
Formatieren Sie die Datei für den Upload: Vergewissern Sie sich, dass die endgültige CSV-Datei die richtigen Spaltenüberschriften enthält (InvoiceNumber, ActivityName, EventTime usw.) und die Spalte EventTime ein einheitliches Timestamp-Format verwendet, zum Beispiel YYYY-MM-DD HH:MI:SS. Anschließend können Sie die Datei in ProcessMind hochladen.

Konfiguration

Data Entities: Für den Export werden mehrere Standard-Data-Entities aus D365 verwendet. Dazu gehören Sales invoice headers V2 (Rechnungen und Gutschriften), Sales packing slip headers (Auftragsabwicklung), CustPaymentJournalLineEntity (Zahlungen), Customer settlement (Zahlungsausgleich) und Workflow tracking status table (Freigaben).
Exportformat: Als Zielformat wird CSV empfohlen, da es mit vielen Datentransformationstools kompatibel ist.
Filter für den Datumsbereich: Filtern Sie die wichtigsten Entities unbedingt nach einem Datumsbereich, insbesondere Sales invoice headers V2 anhand des Feldes InvoiceDate. Empfohlen wird ein Zeitraum von 3 bis 6 Monaten. So bleibt der Export überschaubar und enthält zugleich genügend Daten für die Analyse.
Unternehmensfilter: Filtern Sie den Export nach der Rechtseinheit oder dem Unternehmenscode, den Sie analysieren. So bleiben die Daten relevant und die Exportdatei wird kleiner.
Datenbereitstellung und -transformation: Nach dem Export müssen die Dateien außerhalb von Dynamics 365 weiterverarbeitet werden. Führen Sie sie zusammen und bringen Sie sie in das Format eines einzelnen Event Logs. Dafür eignen sich beispielsweise Power BI (Power Query), Python oder SQL.
Voraussetzungen: Der Benutzer, der den Export ausführt, benötigt in Dynamics 365 die passenden Sicherheitsrollen. Dazu gehört in der Regel eine Rolle mit Berechtigungen für den Workspace Data management und Zugriff auf die benötigten Data Entities.

a Beispielabfrage config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Schritte

Voraussetzungen: Installieren Sie Python 3.6 oder höher sowie die Bibliotheken requests und pandas. Außerdem benötigen Sie Zugangsdaten für einen Service Principal (App Registration) in Azure Active Directory, dem Zugriff auf Ihre Dynamics 365 Finance & Operations-Umgebung erteilt wurde.
Registrieren Sie die Anwendung: Registrieren Sie in Azure AD eine neue Anwendung. Erstellen Sie einen Client Secret und notieren Sie sich die Application (client) ID, Directory (tenant) ID und den Client Secret. Fügen Sie in Dynamics 365 unter System administration > Setup > Azure Active Directory applications die Anwendungs-ID hinzu und weisen Sie ihr die passenden Benutzerrechte zum Lesen der erforderlichen Data Entities zu.
Konfigurieren Sie das Skript: Öffnen Sie das bereitgestellte Python-Skript. Tragen Sie oben im Skript die Konfigurationsvariablen ein: d365_url, tenant_id, client_id, client_secret, company, start_date und end_date. Als d365_url geben Sie die Basis-URL Ihrer Dynamics 365-Umgebung an, zum Beispiel https://your-d365-instance.operations.dynamics.com.
Authentifizieren Sie sich: Die Funktion get_access_token im Skript verwendet Ihre Zugangsdaten, um automatisch ein OAuth2-Zugriffstoken bei der Identitätsplattform von Microsoft anzufordern. Dieses Token ist erforderlich, um die nachfolgenden API-Aufrufe zu autorisieren.
Extrahieren Sie die Daten: Führen Sie das Skript im Terminal mit python your_script_name.py aus. Zunächst ruft es alle gebuchten Verkaufsrechnungen (CustInvoiceJour) im angegebenen Zeitraum ab. Anschließend fragt es für jede Rechnung über weitere API-Aufrufe zugehörige Daten ab, etwa zu Zahlungen, Ausgleichen, Gutschriften und Workflow-Verläufen.
Erzeugen Sie Aktivitäten: Das Skript verarbeitet Rohdaten aus mehreren API-Endpunkten und erstellt ausdrücklich eine Zeile für jede der 12 erforderlichen Aktivitäten. Für das Ereignis „Rechnung erstellt“ verwendet es beispielsweise die Entity CustInvoiceJour. Für Ereignisse wie „Zahlung auf Rechnung verbucht“ fragt es die Entity CustSettlement ab.
Berechnete Ereignisse: Ereignisse wie „Fälligkeitsdatum der Zahlung erreicht“ und „Rechnung geschlossen“ sind keine direkten Transaktionen in Dynamics 365. Das Skript leitet diese Ereignisse aus dem Fälligkeitsdatum, dem Status und dem Ausgleichsverlauf einer Rechnung ab und fügt entsprechende Einträge in das Event Log ein.
Paginierung: Die Hilfsfunktion fetch_all_data übernimmt die Paginierung automatisch. Dynamics 365 OData-APIs geben nur eine begrenzte Anzahl von Datensätzen pro Seite zurück. Deshalb folgt diese Funktion dem in der API-Antwort enthaltenen @odata.nextLink, um den vollständigen Datensatz abzurufen.
Transformieren und ausgeben: Nach dem Abruf aller Ereignisse führt das Skript sie in einer Liste zusammen, wandelt diese in einen pandas DataFrame um und vereinheitlicht die Spaltennamen zu InvoiceNumber, ActivityName, EventTime und den weiteren erforderlichen Attributen.
Exportieren Sie die Daten als CSV: Abschließend speichert das Skript den DataFrame in der CSV-Datei d365_billing_event_log.csv. Die Datei ist für den Upload in ProcessMind oder ein anderes Process-Mining-Tool vorbereitet.

Konfiguration

D365-URL: Die Basis-URL Ihrer Dynamics 365 Finance & Operations-Instanz. Sie ist der zentrale Endpunkt für alle API-Aufrufe.
Azure-AD-Zugangsdaten: Für die Authentifizierung benötigen Sie client_id, client_secret und tenant_id. Diese Zugangsdaten müssen zu einer Anwendung gehören, die Lesezugriff auf die relevanten D365-Entities hat.
Unternehmen: Geben Sie die DataAreaId der Rechtseinheit in Dynamics 365 an, aus der Sie Daten extrahieren möchten, zum Beispiel USMF.
Datumsbereich: Legen Sie mit start_date und end_date den Zeitraum für den Export fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. So bleibt der Datensatz überschaubar und bildet zugleich genügend Prozessvarianten ab.
Wichtige OData-Entities: Das Skript fragt hauptsächlich die folgenden Entities ab: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours und WorkflowTrackingStatusTables. Vergewissern Sie sich, dass der konfigurierte Benutzer Leseberechtigungen für alle diese Entities hat.
Leistung: Bei einem langen Zeitraum oder einem sehr großen Unternehmen kann der Export aufgrund der zahlreichen sequenziellen API-Aufrufe langsam sein. Führen Sie das Skript möglichst außerhalb der Spitzenzeiten aus und beginnen Sie mit einem kleineren Datumsbereich, um die voraussichtliche Laufzeit abzuschätzen.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

if __name__ == class="hl-string">"__main__":
    main()

Möchten Sie loslegen?

Starten Sie mit diesem Template und optimieren Sie Ihre Abrechnung und Rechnungsstellung. Geben Sie Ihrem Team die nötigen Erkenntnisse an die Hand, um effizienter zu arbeiten und den Cashflow zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Beenden Sie Verzögerungen bei der Abrechnung: Optimieren Sie noch heute Ihren Order-to-Cash- und Rechnungsstellungsprozess

Verkürzen Sie die Zykluszeit Ihrer Abrechnung um 30 % und gewinnen Sie schneller Klarheit über Ihre Finanzprozesse.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Kostenlose Testphase für 14 Tage.

Ihr Daten-Template für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Ihr Daten-Template für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Attribute für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Aktivitäten im Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Anleitungen zur Datenextraktion

Export von Microsoft Dynamics 365 Data Entities

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Dynamics 365 OData Web API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Beenden Sie Verzögerungen bei der Abrechnung: Optimieren Sie noch heute Ihren Order-to-Cash- und Rechnungsstellungsprozess

Ihr Daten-Template für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Ihr Daten-Template für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Attribute für den Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Aktivitäten im Order-to-Cash-Prozess: Abrechnung und Rechnungsstellung

Anleitungen zur Datenextraktion

Export von Microsoft Dynamics 365 Data Entities

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Dynamics 365 OData Web API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Beenden Sie Verzögerungen bei der Abrechnung: Optimieren Sie noch heute Ihren Order-to-Cash- und Rechnungsstellungsprozess

Der Schutz Ihrer Daten ist uns wichtig