> Kontinuierliche Prozessoptimierung > Procure to Pay – Rechnungsverarbeitung > Microsoft Dynamics 365 > Datenvorlage

Ihr Purchase-to-Pay – Rechnungsbearbeitungs-Datentemplate

Microsoft Dynamics 365

Procure-to-Pay – Rechnungsverarbeitungsattribute (23) Procure-to-Pay – Rechnungsverarbeitungsaktivitäten (14) Extraktionsleitfäden (4)

Ihr Purchase-to-Pay – Rechnungsbearbeitungs-Datentemplate

Diese Vorlage bietet einen klaren Leitfaden zur Extraktion der wesentlichen Daten, die für die Analyse Ihrer Procure-to-Pay – Rechnungsverarbeitung in Microsoft Dynamics 365 benötigt werden. Sie skizziert die entscheidenden Attribute, die gesammelt werden müssen, die Schlüsselaktivitäten, die verfolgt werden sollten, und praktische Anleitungen zur Datenextraktion. Nutzen Sie diese Ressource, um sicherzustellen, dass Sie alle notwendigen Informationen für eine umfassende Prozessanalyse und -optimierung sammeln.

Empfohlene Attribute für eine detaillierte Analyse
Wichtige Aktivitäten, die während des gesamten Rechnungsverarbeitungszyklus verfolgt werden sollten
Anleitung zur Datenextraktion aus Microsoft Dynamics 365

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Procure-to-Pay – Rechnungsverarbeitungsattribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihrem Event Log für eine umfassende Analyse Ihrer Procure-to-Pay – Rechnungsverarbeitung aufnehmen sollten.

5 Erforderlich 7 Empfohlen 11 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Geschäftsereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt innerhalb des Rechnungsverarbeitungszyklus aufgetreten ist.
Beschreibung Der Aktivitätsname beschreibt einen spezifischen Schritt oder eine Statusänderung im Rechnungsprozess, wie z.B. 'Rechnung registriert', 'Rechnung zur Genehmigung gesendet' oder 'Zahlung ausgeführt'. Diese Daten sind entscheidend für die Erstellung der Prozesslandkarte und das Verständnis der Abfolge der Ereignisse. Die Analyse dieses Attributs enthüllt den Prozessablauf, identifiziert gemeinsame Wege und hebt Abweichungen oder Engpässe hervor. Es wird verwendet, um Zykluszeiten zwischen Aktivitäten zu berechnen, wie z.B. die Dauer von der Genehmigung bis zur Buchung, und um die Häufigkeit spezifischer Ereignisse wie Ablehnungen oder Zahlungssperren zu messen. Bedeutung Es definiert die Schritte in der Prozesslandkarte, was die Visualisierung des Prozessablaufs und die Analyse von Übergängen zwischen verschiedenen Aktivitäten ermöglicht. Datenquelle Dieses Attribut wird typischerweise aus einer Kombination von Statusfeldern, Transaktionstypen oder Änderungslog-Einträgen innerhalb verschiedener Dynamics 365-Tabellen abgeleitet, die sich auf die Rechnungsverarbeitung beziehen. Beispiele Rechnung zur Genehmigung gesendetAbweichung im Abgleich gefundenZahlung ausgeführt
	Ereigniszeit EventTime	Der genaue Zeitstempel, der angibt, wann eine spezifische Aktivität oder ein Ereignis stattfand.
Beschreibung Die Ereigniszeit, oder der Timestamp, zeichnet das genaue Datum und die Uhrzeit auf, zu der eine Aktivität stattgefunden hat. Dies ist ein kritischer Bestandteil des Event Logs, der die zeitliche Abfolge liefert, die erforderlich ist, um Aktivitäten korrekt zu ordnen und Dauern zu berechnen. In der Analyse ist dieser Timestamp die Grundlage für alle zeitbezogenen Metriken. Er wird verwendet, um die Dauer von Aktivitäten, die Durchlaufzeit zwischen verschiedenen Schritten (z.B. Genehmigungszeit) und die gesamte End-to-End-Bearbeitungszeit für jede Rechnung zu berechnen. Er ermöglicht auch die Trendanalyse über die Zeit. Bedeutung Dieser Timestamp ist unerlässlich für die Sortierung von Ereignissen, die Berechnung aller Zykluszeiten und Dauern sowie die Identifizierung von Prozessengpässen. Datenquelle Dies wird aus verschiedenen Datums-/Zeitfeldern über mehrere Tabellen hinweg bezogen, wie z.B. den createdDateTime- oder modifiedDateTime-Feldern in Tabellen wie VendInvoiceInfoTable, VendTrans oder Workflow-Historientabellen. Beispiele 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Rechnungsnummer InvoiceNumber	Der eindeutige Identifikator für jede Lieferantenrechnung, der als primäre Case ID zur Verfolgung ihres Lebenszyklus dient.
Beschreibung Die Rechnungsnummer ist der eindeutige Schlüssel, der alle Aktivitäten einer einzelnen Lieferantenrechnung miteinander verbindet. Sie ermöglicht die End-to-End-Verfolgung des Weges der Rechnung, vom Eingang und der Registrierung über den Abgleich, die Genehmigung bis zur finalen Zahlung. In der Process Mining-Analyse ist dieses Attribut fundamental. Es definiert den Case und ermöglicht die Rekonstruktion des Prozessflusses jeder Rechnung. Dies erlaubt die Berechnung der Gesamtzykluszeiten, die Identifizierung von Prozessvarianten und die Analyse rechnungsspezifischer Merkmale und Ergebnisse. Bedeutung Dies ist die essentielle Case ID, die alle zugehörigen Ereignisse verbindet und es ermöglicht, den gesamten Lebenszyklus jeder einzelnen Rechnung zu analysieren. Datenquelle Dies findet sich typischerweise in der Hauptlieferantenrechnungstabelle, wie VendInvoiceInfoTable, Feld Num. Beispiele INV-10056773245-AUS-001-98432
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut zeichnet auf, wann der Datensatz zuletzt aus Microsoft Dynamics 365 extrahiert und aktualisiert wurde. Es ist typischerweise für alle Records innerhalb eines einzigen Data Loads dasselbe. Diese Information ist entscheidend, damit Benutzer die Aktualität der von ihnen analysierten Daten verstehen. Sie liefert Kontext für die Gegenwärtigkeit der Prozesseinblicke und ist essentiell für die Verwaltung von Datenaktualisierungsplänen und die Validierung von Datenpipelines. Bedeutung Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie wissen, wie aktuell die Analyse ist und wann die nächste Datenaktualisierung erwartet wird. Datenquelle Dieser Timestamp wird vom Datenextraktions- oder ETL-Prozess zum Zeitpunkt der Ausführung generiert und auf den Datensatz gestempelt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Quellsystem SourceSystem	Das führende System, aus dem die Event-Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert die Quellanwendung, aus der die Aktivitätsdaten stammen. Für diesen Prozess wird es typischerweise 'Microsoft Dynamics 365' sein. In Umgebungen mit mehreren Systemen, wie z.B. einer externen OCR- oder Erfassungslösung, hilft dieses Feld zu differenzieren, wo jeder Schritt des Prozesses stattfindet. Es stellt sicher, dass die Datenherkunft klar ist und hilft bei der Fehlerbehebung bei Datenextraktionsproblemen. Bedeutung Es liefert entscheidenden Kontext zur Datenherkunft, der für die Datenvalidierung und das Verständnis der Systemlandschaft des Prozesses wichtig ist. Datenquelle Dies ist ein statischer Wert, 'Microsoft Dynamics 365', der während der Data Transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Microsoft Dynamics 365
	Benutzer User	Die User-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut identifiziert den Mitarbeiter oder Systembenutzer, der für die Ausführung eines spezifischen Prozessschritts verantwortlich ist. Bei automatisierten Schritten könnte dies ein System- oder Dienstkonto sein. Die Analyse des Prozesses nach Benutzer hilft, die Arbeitslastverteilung zu verstehen, Schulungsbedarfe zu identifizieren und die Leistung über Einzelpersonen oder Teams hinweg zu vergleichen. Sie ist entscheidend für die Analyse von Nacharbeitsschleifen, bei denen die Arbeit zwischen Benutzern hin- und hergegeben wird, und für das Verständnis von Variationen, wie verschiedene Benutzer dieselbe Aufgabe erledigen. Bedeutung Es ermöglicht die Analyse von Leistung und Arbeitslast nach Benutzer oder Team und hilft, Automatisierungsgrade und Quellen für Nacharbeit zu identifizieren. Datenquelle Stammt aus Benutzer-ID-Feldern in Transaktions- oder Workflow-Historientabellen, wie z.B. createdby- oder modifiedby-Feldern. Diese Informationen können in den Workflow-Tracking-Tabellen enthalten sein. Beispiele j.doea.smithAX_Admin
	Bestellnummer PurchaseOrderNumber	Der Identifikator der Bestellung (PO), auf die sich die Rechnung bezieht.
Beschreibung Die Bestellnummer verbindet eine Rechnung mit dem ursprünglichen Beschaffungsdokument. Dies ist entscheidend für Prozesse, die einen 2-Wege- oder 3-Wege-Abgleich zwischen der Rechnung, der Bestellung (PO) und dem Wareneingang beinhalten. Dieses Attribut ermöglicht die Analyse von PO- versus nicht-PO-Rechnungen, die oft unterschiedliche Prozesspfade verfolgen. Es ist entscheidend, um die Wirksamkeit des Abgleichsprozesses zu verstehen, Abgleichsdifferenzen zu untersuchen und die Automatisierungsrate für bestellbezogene Rechnungen zu messen. Bedeutung Es unterscheidet bestellbezogene Rechnungen von nicht-bestellbezogenen Rechnungen, was ein Haupttreiber für Prozessvariationen ist und für die Abgleichsanalyse entscheidend ist. Datenquelle Befindet sich in der Rechnungskopftabelle, wie VendInvoiceInfoTable, oft in einem Feld wie PurchId. Beispiele PO-001234PO-005678PO-009101
	Endzeit EndTime	Der genaue Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit zeichnet auf, wann eine Aktivität abgeschlossen wurde. In Kombination mit der StartTime (EventTime) ermöglicht sie die präzise Berechnung, wie lange jeder einzelne Schritt gedauert hat. Dieses Attribut ist essentiell für die Berechnung der 'ProcessingTime' für jede Aktivität, einer Schlüsselmetrik für die Leistungsanalyse. Es hilft, genau zu identifizieren, welche Schritte im Prozess die meiste Zeit in Anspruch nehmen, und ermöglicht gezielte Verbesserungsmaßnahmen. Zum Beispiel kann es die genaue Dauer eines manuellen Codierungs- oder Genehmigungsschritts messen. Bedeutung Ermöglicht die direkte Berechnung von Bearbeitungszeiten für Aktivitäten, was grundlegend ist, um die zeitaufwendigsten Schritte im Prozess zu identifizieren. Datenquelle Wie StartTime wird dies aus verschiedenen Datums-/Zeitfeldern bezogen. Bei einigen Aktivitäten könnte es die StartTime der nächsten Aktivität sein. In anderen Fällen könnte es ein spezifischer 'completed on'-Timestamp sein. Beispiele 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Lieferantennummer VendorNumber	Der eindeutige Identifikator für den Lieferanten oder Anbieter, der die Rechnung eingereicht hat.
Beschreibung Die Lieferantennummer ist der Code, der einen Lieferanten in den Stammdaten eindeutig identifiziert. Sie verbindet die Rechnungstransaktion mit einem spezifischen Lieferanten und ermöglicht eine lieferantenzentrierte Analyse. Dieses Attribut ist essentiell, um die Prozessdaten nach Lieferanten zu segmentieren. Es hilft, Fragen zu beantworten wie 'Welche Lieferanten haben die längsten Genehmigungszeiten?' oder 'Sind Abweichungen im Abgleich bei bestimmten Lieferanten häufiger?'. Die Leistungsanalyse nach Lieferant kann Möglichkeiten zur Lieferantenzusammenarbeit und Prozessverbesserung aufzeigen. Bedeutung Ermöglicht die Filterung und Ursachenanalyse nach Lieferant, um Leistungsprobleme oder Muster bei bestimmten Lieferanten zu identifizieren. Datenquelle Dies findet sich typischerweise im Kopf der Lieferantenrechnungstabelle, wie VendInvoiceInfoTable, verknüpft mit den Hauptlieferantenstammdaten in VendTable. Beispiele V-1001V-2050V-8342
	Rechnungsbetrag InvoiceAmount	Der monetäre Gesamtwert der Rechnung.
Beschreibung Dieses Attribut repräsentiert den auf der Lieferantenrechnung ausgewiesenen Gesamtbetrag. Es ist ein fundamentaler Finanzdatenpunkt für jeden Case. Der Rechnungsbetrag wird häufig für die Segmentierung und Analyse verwendet. Er kann aufzeigen, ob Rechnungen mit hohem Wert einem anderen, strengeren Genehmigungsprozess folgen oder länger zur Bearbeitung benötigen. Er wird auch in Dashboards verwendet, um Rechnungsvolumen nach Wert zu analysieren und kann aggregiert werden, um die Gesamtausgaben unter Analyse zu verstehen. Bedeutung Ermöglicht die Analyse basierend auf dem Finanzwert, hilft bei der Priorisierung von Prozessverbesserungsmaßnahmen bei Rechnungen mit hohem Wert und beim Verständnis von Kostentreibern. Datenquelle Gefunden in der Rechnungs-Header-Tabelle, zum Beispiel VendInvoiceInfoTable, in einem Feld wie InvoiceAmount oder Amount. Beispiele 1500.00250.7512500.50
	Rechnungsstatus InvoiceStatus	Der aktuelle Status der Rechnung zum Zeitpunkt der Datenextraktion.
Beschreibung Der Rechnungsstatus gibt den aktuellen Zustand einer Rechnung innerhalb ihres Lebenszyklus an, wie z.B. 'Zur Genehmigung ausstehend', 'Genehmigt', 'Gebucht' oder 'Bezahlt'. Dies bietet eine Momentaufnahme des Fortschritts der Rechnung. Dieses Attribut wird primär zur Erstellung operativer Dashboards verwendet, die die aktuelle Arbeitslast und den Rückstand anzeigen. Es hilft Managern zu verstehen, wie viele Rechnungen sich in jeder Phase des Prozesses befinden, und unterstützt die Ressourcenzuweisung und das operative Monitoring. Es ist entscheidend für das 'Invoice Processing Throughput & Status'-Dashboard. Bedeutung Bietet einen Überblick über den aktuellen Status aller Rechnungen, wesentlich für operatives Monitoring, Workload-Management und die Identifizierung aktueller Engpässe. Datenquelle Dies wird typischerweise aus Statusfeldern der Hauptrechnungstabelle abgeleitet, wie VendInvoiceInfoTable. Beispiele Genehmigung ausstehendGebuchtBezahlt
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Datum, bis zu dem die Rechnung gemäß den vereinbarten Zahlungsbedingungen bezahlt werden sollte.
Beschreibung Das Zahlungsfälligkeitsdatum wird basierend auf dem Rechnungsdatum und den Zahlungsbedingungen des Lieferanten berechnet. Es stellt die vertragliche Frist für die Zahlung dar. Dieses Datum ist entscheidend für die Messung der finanziellen Leistung und des Lieferantenbeziehungsmanagements. Es ist die Grundlage, die zur Berechnung des 'On-Time Payment Rate' KPI verwendet wird, indem es mit dem tatsächlichen 'Payment Executed'-Datum verglichen wird. Die Analyse hilft, systemische Probleme zu identifizieren, die verspätete Zahlungen verursachen, was zu geschädigten Lieferantenbeziehungen oder verpassten Skontoabzügen führen kann. Bedeutung Dies ist der Benchmark für die Messung der Pünktlichkeitsrate bei Zahlungen, ein Schlüssel-KPI für die finanzielle Gesundheit und Lieferantenbeziehungen. Datenquelle Dieses Datum wird oft vom System berechnet und in der Lieferantentransaktionstabelle, wie VendTrans, basierend auf Rechnungsdatum und Zahlungsbedingungen gespeichert. Beispiele 2023-05-152023-06-302023-07-20
	Ablehnungsgrund RejectionReason	Der Grund, den ein Genehmiger für die Ablehnung einer Rechnung angegeben hat.
Beschreibung Wenn eine Rechnung im Genehmigungs-Workflow abgelehnt wird, gibt der Genehmiger in der Regel einen Grund an. Dieses Attribut erfasst diese Erklärung, die ein vordefinierter Code oder Freitext sein kann. Dies ist ein kritisches Attribut für das 'Rechnungsablehnungsanalyse'-Dashboard. Es liefert qualitative Einblicke, um die Ursachen von Ablehnungen wie 'Falsche Bestellnummer', 'Doppelte Rechnung' oder 'Preisabweichung' zu verstehen. Die Analyse dieser Gründe hilft, Maßnahmen zur Reduzierung der Ablehnungsrate zu priorisieren. Bedeutung Bietet direkten Einblick, warum Rechnungen abgelehnt werden, was gezielte Maßnahmen zur Reduzierung von Nacharbeit und zur Verbesserung der First-Time-Right-Raten ermöglicht. Datenquelle Typischerweise in den Kommentaren oder Historie-Logs der Workflow-Verarbeitungstabellen zu finden. Beispiele Falsche MengeDoppelte RechnungGenehmigungslimit überschritten
	Abteilung Department	Die Kostenstelle oder Abteilung, der die Rechnungskosten zugeordnet werden.
Beschreibung Die Abteilung identifiziert die Geschäftseinheit oder Kostenstelle, die für die Ausgaben auf der Rechnung verantwortlich ist. Dies wird normalerweise während der Rechnungszuordnungsaktivität bestimmt. Die Analyse des Prozesses nach Abteilung ist entscheidend, um abteilungsspezifische Unterschiede bei Ausgaben, Genehmigungszeiten und Compliance zu verstehen. Sie hilft zu identifizieren, welche Abteilungen die meisten Rechnungsausnahmen oder die längsten Genehmigungszyklen aufweisen, und bietet eine Grundlage für gezielte Kommunikation und Schulung. Bedeutung Ermöglicht Kosten- und Prozessanalysen nach Abteilungen, wodurch Leistungs- und Compliance-Variationen in der gesamten Organisation hervorgehoben werden. Datenquelle Stammt aus Finanzdimensionen, die mit den Rechnungszeilen oder dem Kopf verknüpft sind. Dies erfordert das Abfragen der dimensionsbezogenen Datenstrukturen. Beispiele VertriebMarketingIT-Betrieb
	Art der Abweichung MatchingDiscrepancyType	Kategorisiert die Art der Abweichung, die während des Rechnungs- und Bestellungsabgleichs gefunden wurde.
Beschreibung Wenn eine Diskrepanz während des 2-Wege- oder 3-Wege-Abgleichs auftritt, spezifiziert dieses Attribut die Art des Problems, zum Beispiel 'Preisabweichung', 'Mengenabweichung' oder 'Fehlender Wareneingang'. Diese Daten sind zentral für das 'Matching Discrepancy Resolution Time'-Dashboard. Durch die Analyse der Häufigkeit verschiedener Diskrepanztypen kann das Unternehmen die Grundursachen von Abgleichsfehlern identifizieren. Zum Beispiel können häufige Preisabweichungen auf Probleme mit veralteten Stammdaten hindeuten, während Mengenabweichungen auf Versandprobleme hinweisen könnten. Bedeutung Es kategorisiert Abgleichsfehler und ermöglicht eine Ursachenanalyse, um die Rate von Diskrepanzen zu reduzieren und die durchgängige Verarbeitung zu verbessern. Datenquelle Dies kann in einer dedizierten Abgleichs- oder Ausnahme-Logtabelle gespeichert sein oder muss möglicherweise aus Statusmeldungen oder Workflow-Kommentaren abgeleitet werden. Beispiele PreisabweichungMengenabweichungFehlender Wareneingang
	Bearbeitungszeit ProcessingTime	Die Dauer einer einzelnen Aktivität, berechnet als die Differenz zwischen ihrer End- und Startzeit.
Beschreibung Processing Time misst die aktive Zeit, die für eine bestimmte Aufgabe aufgewendet wird. Sie wird berechnet, indem die StartTime eines Ereignisses von seiner EndTime subtrahiert wird. Dies wird auch als Aktivitätsdauer bezeichnet. Diese Metrik ist fundamental für die Leistungsanalyse. Sie hilft zu identifizieren, welche spezifischen Aktivitäten am zeitaufwendigsten sind, im Gegensatz zu Wartezeiten zwischen Aktivitäten. Dies ermöglicht gezielte Verbesserungen, wie z.B. die Bereitstellung besserer Schulungen zur Beschleunigung der manuellen Zuordnung oder die Optimierung eines langsam laufenden Systemschritts. Bedeutung Misst die tatsächliche Arbeitsdauer von Aktivitäten und hilft, ineffiziente Aufgaben zu identifizieren, die für Optimierung oder Automatisierung reif sind. Datenquelle Dies ist kein Feld im Quellsystem. Es wird während der Data Transformation mithilfe der Formel: EndTime - StartTime berechnet. Beispiele PT1H30MP2DT4HPT5M15S
	Buchungskreis CompanyCode	Der Identifikator für die juristische Einheit oder das Unternehmen innerhalb der Organisation, die die Rechnung verarbeitet.
Beschreibung Der Firmen-Code repräsentiert die spezifische juristische Einheit, die finanziell für die Rechnung verantwortlich ist. In einer Multi-Unternehmensorganisation ist dies ein kritischer Datenpunkt für die finanzielle Segmentierung. Dieses Attribut ermöglicht es, die Prozessanalyse über verschiedene juristische Einheiten hinweg zu filtern oder zu vergleichen. Es kann aufzeigen, ob die Prozessleistung, Richtlinien oder Engpässe für bestimmte Unternehmen innerhalb der Gruppe spezifisch sind, und unterstützt so lokalisierte Prozessverbesserungsinitiativen. Bedeutung Ermöglicht die Segmentierung der Prozessanalyse nach juristischen Einheiten, was für große, Mehrmandanten-Organisationen entscheidend ist. Datenquelle Dies ist ein Standardfeld in den meisten Finanztabellen in Dynamics 365, oft als DataAreaId bezeichnet. Beispiele USMFDEMFGBSI
	Gesamtdurchlaufzeit TotalCycleTime	Die gesamte End-to-End-Dauer für die Verarbeitung einer einzelnen Rechnung, vom Eingang bis zur Zahlung.
Beschreibung Total Cycle Time misst die gesamte Dauer, die eine Rechnung im Prozess verbringt. Sie wird als Zeitdifferenz zwischen der allerersten Aktivität (z.B. 'Rechnung registriert') und der allerletzten Aktivität (z.B. 'Zahlung ausgeführt') für eine gegebene Rechnungsnummer berechnet. Dies ist ein primärer KPI zur Messung der Gesamtprozesseffizienz. Er bietet eine High-Level-Ansicht der Leistung und wird im 'Invoice End-to-End Cycle Time'-Dashboard verwendet. Die Analyse von Trends in dieser Metrik und die Segmentierung nach Attributen wie Lieferant oder Betrag hilft, umfassende Verbesserungsmöglichkeiten zu identifizieren. Bedeutung Stellt den wichtigsten High-Level-KPI für die Gesamtprozessgeschwindigkeit und -effizienz dar, der die Leistung für jede Rechnung zusammenfasst. Datenquelle Dies wird auf Case-Ebene innerhalb des Process Mining-Tools oder während der Datenaufbereitung berechnet. Es ist die Zeitdifferenz zwischen dem ersten und letzten Event Timestamp für jede Case ID. Beispiele P15DP22DT5H30MP7D
	Grund der Zahlungssperre PaymentBlockReason	Der Ursachencode, der erklärt, warum eine Zahlungssperre auf eine Rechnung angewendet wurde.
Beschreibung Eine Zahlungsblockade verhindert, dass eine Rechnung bezahlt wird. Dieses Attribut erfasst den Grund für die Blockade, der in der Regel ein standardisierter, vom Benutzer gewählter Code ist, wie z. B. „Strittige Forderungen“ oder „Warten auf Wareneingang“. Dieses Attribut ist entscheidend für das Dashboard „Zahlungsblockaden-Häufigkeit & Dauer“. Die Analyse der häufigsten Gründe für Zahlungsblockaden hilft, zugrunde liegende Probleme im P2P-Prozess zu identifizieren. Die Behebung dieser Grundursachen kann Zahlungsverzögerungen erheblich reduzieren und die Lieferantenbeziehungen verbessern. Bedeutung Erklärt, warum Zahlungen absichtlich verzögert werden, und hilft dabei, vorgelagerte Probleme zu identifizieren und zu lösen, die Zahlungsblockaden verursachen. Datenquelle Dies ist typischerweise ein Feld im Lieferantentransaktions- oder Rechnungsdatensatz, oft bezogen auf den Payment Block Status. Suchen Sie in Tabellen wie VendTrans. Beispiele QualitätsstreitigkeitWarten auf GutschriftManuelle Sperre
	Ist automatisiert IsAutomated	Kennzeichen (Flag), ob eine Aktivität automatisch vom System oder manuell durch einen Benutzer ausgeführt wurde.
Beschreibung Dieses boolesche Attribut (wahr/falsch) unterscheidet zwischen vom System ausgeführten Events und manuellen User-Tasks. Zum Beispiel könnte ein Rechnungsabgleichsschritt automatisiert sein, während die Diskrepanzbehandlung manuell erfolgt. Die Analyse dieses Attributs ist entscheidend, um den Automatisierungsgrad im Prozess zu verstehen. Es hilft, den Erfolg von Automatisierungsinitiativen zu messen, verbleibende manuelle Engpässe zu identifizieren und Möglichkeiten für weitere Automatisierung zur Verbesserung der Effizienz und Reduzierung von Fehlern aufzuzeigen. Bedeutung Hilft, den Automatisierungsgrad im Prozess zu messen, manuelle Engpässe und Möglichkeiten für Effizienzsteigerungen zu identifizieren. Datenquelle Dies wird typischerweise basierend auf dem Attribut 'Benutzer' abgeleitet. Wenn der Benutzer ein bekanntes System- oder Dienstkonto ist, wird dieses Flag auf wahr gesetzt. Beispiele truefalsch
	Ist pünktliche Zahlung IsOnTimePayment	Ein berechnetes Kennzeichen, das angibt, ob eine Rechnung am oder vor ihrem Fälligkeitsdatum bezahlt wurde.
Beschreibung Dieses boolesche Attribut wird abgeleitet, indem der Timestamp der Aktivität 'Payment Executed' mit dem 'Payment Due Date' verglichen wird. Wenn das Zahlungsdatum kleiner oder gleich dem Fälligkeitsdatum ist, ist der Wert wahr, andernfalls ist er falsch. Dieses Attribut unterstützt direkt den 'On-Time Payment Rate' KPI und das 'Payment Terms Compliance'-Dashboard. Es vereinfacht die Analyse, indem es ein klares binäres Ergebnis für jede Rechnung liefert, wodurch es einfach wird, nach verspäteten Zahlungen zu filtern und deren Grundursachen nach Lieferant, Abteilung oder Land zu untersuchen. Bedeutung Misst direkt die Einhaltung der Zahlungsbedingungen und vereinfacht die Berechnung des KPI für die pünktliche Zahlungsrate und verwandte Analysen. Datenquelle Dieses Attribut wird in der Data Transformation Layer berechnet. Die Logik ist: (Timestamp der Aktivität 'Payment Executed') <= (Payment Due Date). Beispiele truefalsch
	Rechnungswährung InvoiceCurrency	Der Währungscode für den Rechnungsbetrag (z.B. USD, EUR).
Beschreibung Die Rechnungs-Währung gibt die Währung an, in der der Rechnungsbetrag denominiert ist. Dies ist wichtig für multinationale Unternehmen, die mit Lieferanten aus verschiedenen Ländern zusammenarbeiten. Dieses Attribut liefert den notwendigen Kontext für den Rechnungsbetrag und wird für Filterung und Berichterstattung, insbesondere in globalen Operationen, verwendet. Es stellt sicher, dass Finanzwerte korrekt interpretiert werden und ermöglicht eine währungsspezifische Analyse oder Umrechnung in eine Standardberichtswährung. Bedeutung Bietet wesentlichen Kontext für Finanzbeträge, was eine genaue Interpretation und Analyse von Rechnungswerten in verschiedenen Regionen ermöglicht. Datenquelle Befindet sich in der Rechnungskopftabelle neben dem Rechnungsbetrag, zum Beispiel im VendInvoiceInfoTable-Feld CurrencyCode. Beispiele USDEURGBP
	Zahlungsbedingungen PaymentTerms	Die Zahlungsbedingungen-Vereinbarung mit dem Lieferanten, wie 'Netto 30' oder '2% 10, Netto 30'.
Beschreibung Zahlungsbedingungen definieren die vereinbarten Konditionen für die Zahlung an den Lieferanten, einschließlich des Zeitrahmens und potenzieller Skontoabzüge. Diese Informationen stammen in der Regel aus den Lieferantenstammdaten oder der Bestellung. Dieses Attribut liefert entscheidenden Kontext für das Zahlungsfälligkeitsdatum und den KPI für die Pünktlichkeitsrate der Zahlungen. Die Analyse, ob bestimmte Zahlungsbedingungen mit verspäteten Zahlungen korrelieren, kann operative Herausforderungen aufzeigen. Es hilft auch bei der Finanzplanung und dem effektiven Management des Betriebskapitals. Bedeutung Bietet Kontext für Zahlungsfälligkeiten und hilft, die finanziellen Auswirkungen von Zahlungszeitpunkten und Skontoabrufraten zu analysieren. Datenquelle Diese Informationen sind in den Lieferantenstammdaten (VendTable) gespeichert und werden in Transaktionstabellen wie VendInvoiceInfoTable kopiert. Beispiele Netto 30Netto 602% 10, Netto 30

Erforderlich Empfohlen Optional

Procure-to-Pay – Rechnungsverarbeitungsaktivitäten

Das sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten – für eine präzise Process Discovery und die Analyse Ihres Workflows für die Eingangsrechnungsverarbeitung.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Rechnung freigegeben	Stellt die endgültige, erfolgreiche Genehmigung der Rechnung innerhalb des Workflows dar, die sie zur Buchung und Zahlung freigibt. Dies ist ein explizites Ereignis, das von der Workflow-Engine nach Abschluss protokolliert wird.
Bedeutung Dies ist ein kritischer Meilenstein, der den Genehmigungsprozess abschließt. Die Zeit von 'Rechnung zur Genehmigung gesendet' bis zu diesem Ereignis ist ein Schlüsselmaß für die Genehmigungseffizienz und hilft, Engpässe zu identifizieren. Datenquelle Dies ist ein explizites Ereignis, das in den Workflow-Historientabellen (z.B. WorkflowTrackingStatusTable) protokolliert wird, wenn der Workflow-Status auf 'Genehmigt' wechselt. Erfassen Timestamp des 'Genehmigt'-Statuseintrags in der Workflow-Historie. Ereignistyp explicit
	Rechnung gebucht	Dies ist das formale Buchungsereignis, bei dem die genehmigte Rechnung im Hauptbuch erfasst wird und eine Verbindlichkeit entsteht. Dies ist ein explizites, transaktionales Ereignis im System.
Bedeutung Die Buchung ist der letzte Schritt vor der Zahlung und ein wichtiger finanzieller Kontrollpunkt. Die Zeit von 'Rechnung genehmigt' bis 'Rechnung gebucht' misst die Effizienz der abschließenden Buchungsschritte. Datenquelle Dies ist ein explizites Ereignis, das aus der Erstellung der gebuchten Lieferantentransaktion in Tabellen wie VendTrans und den zugehörigen GeneralJournalEntry- und LedgerEntry-Datensätzen erfasst wird. Erfassen Erstellungs-Timestamp des Datensatzes in der Kreditorentransaktionstabelle (VendTrans). Ereignistyp explicit
	Rechnung mit Bestellung abgeglichen	Stellt den erfolgreichen Abschluss des Abgleichsprozesses dar, bei dem die Rechnungsdetails mit der Bestellung und den Wareneingangsinformationen übereinstimmen. Dieses Ereignis wird abgeleitet, wenn der Abgleichsstatus der Rechnung auf 'Bestanden' aktualisiert wird.
Bedeutung Ein erfolgreicher Abgleich ist ein Schlüsselmeilenstein für bestellbezogene Rechnungen, der die Gültigkeit der Forderung vor der Zahlung bestätigt. Er ist wesentlich für die Verfolgung der Abgleichseffizienz und Automatisierungsraten. Datenquelle Abgeleitet aus der Aktualisierung des Abgleichstatusfeldes im Kreditorenrechnungskopf oder in den Positionen (z.B. VendInvoiceInfoTable) auf einen 'Bestanden'- oder 'Erfolgreich abgeglichen'-Wert. Erfassen Timestamp der Statusänderung auf 'Bestanden' in den Rechnungsabgleichs-Validierungsdetails. Ereignistyp inferred
	Rechnung registriert	Dies ist die initiale Erfassung einer Rechnung im System, die einen Platzhalterdatensatz erstellt, bevor alle Details verarbeitet werden. Diese Aktivität wird erfasst, wenn ein neuer Datensatz im Lieferantenrechnungsregisterjournal erstellt wird.
Bedeutung Diese Aktivität markiert den offiziellen Beginn des Rechnungsverarbeitungszyklus. Die Analyse der Zeit ab diesem Punkt hilft, die Gesamtverarbeitungsdauer zu messen und Verzögerungen in der Frühphase zu identifizieren. Datenquelle Dies ist ein explizites Ereignis, das aus der Erstellung eines Datensatzes im Lieferantenrechnungsregister erfasst wird, typischerweise in der VendInvoiceRegisterJournalTable oder einer ähnlichen Tabelle für offene Rechnungen. Erfassen Erstellungs-Timestamp des Datensatzes im Kreditorenrechnungs-Registerjournal. Ereignistyp explicit
	Rechnung zur Genehmigung gesendet	Diese Aktivität kennzeichnet die formale Übermittlung einer Rechnung in einen Workflow zur Überprüfung und Genehmigung. Die Dynamics 365 Workflow-Engine protokolliert dieses Einreichungsereignis explizit.
Bedeutung Dies ist der Startpunkt für die Messung des gesamten Genehmigungszyklus. Es hilft zu identifizieren, wie lange Rechnungen warten, bevor der Genehmigungsprozess überhaupt beginnt, und ist der Auslöser für genehmigungsbezogene KPIs. Datenquelle Dies ist ein explizites Ereignis, das in den Workflow-Historientabellen (z.B. WorkflowTrackingStatusTable) protokolliert wird, wenn eine Rechnung an einen Workflow übermittelt wird. Erfassen Erstellungs-Timestamp des Workflow-Einreichungsdatensatzes in der Workflow-Historie. Ereignistyp explicit
	Zahlung ausgeführt	Dies ist die finale Aktivität, die die Buchung des Payment Journals repräsentiert, das die Zahlung erstellt und die Rechnung begleicht. Dies ist ein explizites Transaktionsereignis, das den Rechnungslebenszyklus abschließt.
Bedeutung Diese Aktivität markiert das erfolgreiche Ende des Rechnung-zu-Zahlung-Prozesses. Sie ist die Basis für die Messung der 'On-Time Payment Rate' und der gesamten End-to-End-Zykluszeit. Datenquelle Dies ist ein explizites Ereignis, das aus der Buchung des Payment Journals erfasst wird. Die Abwicklungsinformationen werden in Tabellen wie VendSettlement aufgezeichnet und verknüpfen die Zahlung mit der Rechnung. Erfassen Buchungs-Timestamp des Zahlungsjournals, das die Lieferantentransaktion begleicht. Ereignistyp explicit
	Abweichung im Abgleich behoben	Bezeichnet die Behebung einer zuvor identifizierten Abweichung im Abgleich, wodurch die Rechnung weiterverarbeitet werden kann. Dies wird abgeleitet, wenn eine Rechnung mit dem Abgleichsstatus 'Fehlgeschlagen' erfolgreich neu abgeglichen oder manuell überschrieben wird.
Bedeutung Diese Aktivität schließt den Unterprozess der Abweichungsbehebung ab. Die Zeit zwischen 'Abweichung im Abgleich gefunden' und diesem Ereignis ist ein Schlüssel-KPI zur Messung der Effizienz der Behebung. Datenquelle Abgeleitet durch ein erfolgreiches Abstimmungsereignis ('Rechnung mit Bestellung abgeglichen'), das nach einem 'Abstimmungsabweichung gefunden'-Ereignis für dieselbe Rechnung auftritt. Erfassen Einen 'Bestanden'-Abgleichsstatus-Timestamp identifizieren, der einem 'Fehlgeschlagen'-Status-Timestamp folgt. Ereignistyp inferred
	Abweichung im Abgleich gefunden	Diese Aktivität tritt auf, wenn der Rechnungsabgleichsprozess aufgrund von Fehlanpassungen zwischen der Rechnung, der Bestellung oder dem Wareneingang fehlschlägt. Sie wird erfasst, wenn der Rechnungsabgleichsstatus auf 'Fehlgeschlagen' oder 'Diskrepanz' gesetzt wird.
Bedeutung Die Identifizierung, wann und warum Abweichungen auftreten, ist entscheidend für den KPI 'Abstimmungsabweichungsrate'. Diese Aktivität markiert den Beginn des Lösungsprozesses, der oft eine Quelle erheblicher Verzögerungen ist. Datenquelle Abgeleitet aus der Aktualisierung des Abgleichstatusfeldes auf der Kreditorenrechnung (z.B. VendInvoiceInfoTable) auf einen 'Fehlgeschlagen'-Wert. Der Grund für den Fehler wird oft ebenfalls protokolliert. Erfassen Timestamp der Statusänderung auf 'Fehlgeschlagen' oder 'Diskrepanz' während des Abgleichs. Ereignistyp inferred
	Rechnung abgelehnt	Gibt an, dass ein Genehmiger die Rechnung abgelehnt hat, wodurch der Prozess gestoppt und die Rechnung in der Regel zur Korrektur zurückgesendet wird. Die Workflow-Engine protokolliert dieses Ablehnungsereignis explizit.
Bedeutung Das Verfolgen von Ablehnungen hilft, Nacharbeit zu quantifizieren und häufige Fehlerursachen zu identifizieren, wie z.B. falsche Zuordnung oder Richtlinienverstöße. Dies unterstützt direkt den 'Rechnungsablehnungsrate'-KPI. Datenquelle Dies ist ein explizites Ereignis, das in den Workflow-Historientabellen (z.B. WorkflowTrackingStatusTable) protokolliert wird, wenn der Workflow-Status auf 'Abgelehnt' oder 'Storniert' wechselt. Erfassen Timestamp des 'Abgelehnt'-Statuseintrags in der Workflow-Historie. Ereignistyp explicit
	Rechnung kontiert	Diese Aktivität bedeutet, dass Hauptbuchkontenzuordnungen den Rechnungszeilen zugewiesen wurden. Dies wird typischerweise durch die Erstellung oder Finalisierung von Hauptbuchkontenzuordnungen, die mit der Rechnung verknüpft sind, abgeleitet.
Bedeutung Die Kontierung ist ein entscheidender Schritt für die finanzielle Genauigkeit. Die Messung der Zeit, die für die Kontierung von Rechnungen benötigt wird, hilft, Engpässe im Buchhaltungsprüfungsprozess zu identifizieren und unterstützt den KPI 'Durchschnittliche Zeit von Datenerfassung bis Kontierung'. Datenquelle Abgeleitet aus der Erstellung und Validierung von Datensätzen in Buchungsverteilungstabellen (z.B. AccountingDistribution), die mit der ausstehenden Kreditorenrechnung verbunden sind. Erfassen Timestamp, wann die Buchhaltungszuordnungen für die Rechnung gespeichert und validiert werden. Ereignistyp inferred
	Rechnungsdaten erfasst	Stellt den Abschluss der Dateneingabe für die Rechnung dar, einschließlich Kopf- und Positionsdetails, bevor sie zum Abgleich oder zur Genehmigung eingereicht wird. Dies wird oft abgeleitet, wenn der Rechnungsdatensatz von einem 'neuen' oder 'registrierten' Status in einen 'bereit zur Verarbeitung'-Status wechselt.
Bedeutung Das Verfolgen dieser Aktivität hilft, die Effizienz des Datenerfassungsprozesses zu messen, sei er manuell oder automatisiert (OCR). Verzögerungen hier können sich durch den gesamten Prozess ziehen. Datenquelle Abgeleitet von Statusänderungen im Datensatz der ausstehenden Kreditorenrechnung (z.B. VendInvoiceInfoTable). Das Ereignis tritt ein, wenn alle erforderlichen Felder ausgefüllt sind und die Rechnung für den nächsten Schritt bereit ist. Erfassen Erkennung von Statusänderungen in der Tabelle der ausstehenden Rechnungen, die den Abschluss der Datenerfassung signalisieren. Ereignistyp inferred
	Zahlung terminiert	Diese Aktivität tritt auf, wenn eine gebuchte Rechnung in einen Zahlungsvorschlag oder ein Zahlungsjournal aufgenommen wird, aber bevor die Zahlung ausgeführt wird. Es ist eine explizite Aktion, die eine Zahlungsjournalzeile erstellt.
Bedeutung Dies markiert den Übergang von der Kreditorenbuchhaltung zum Treasury-Bereich. Die Analyse dieses Schritts kann Verzögerungen zwischen Rechnungsbuchung und Zahlungsinitiierung aufzeigen. Datenquelle Dies ist ein explizites Event, das aus der Erstellung einer Zeile in einem Payment Journal (LedgerJournalTrans) erfasst wird, das die Vendor Transaction begleicht. Erfassen Erstellungs-Timestamp der Zahlungsjournalzeile, die auf die Rechnung verweist. Ereignistyp explicit
	Zahlungssperre freigegeben	Stellt die Aufhebung einer Zahlungssperre dar, wodurch die Rechnung zur Zahlungsplanung übergehen kann. Dies wird erfasst, wenn das Zahlungssperrfeld gelöscht oder in einen entsperrten Zustand geändert wird.
Bedeutung Misst die Zeit, die zur Behebung von Problemen benötigt wird, die Zahlungssperren verursachen. Lange Dauern zwischen dem Setzen und Aufheben einer Sperre weisen auf ineffiziente Problemlösungsprozesse hin. Datenquelle Abgeleitet aus einer Änderung, die das Zahlungs-Halte- oder Blockierfeld in der gebuchten Kreditorentransaktion (VendTrans) löscht. Das Änderungslog kann den Timestamp liefern. Erfassen Timestamp der Aktualisierung, die das Zahlungssperrfeld in der Lieferantentransaktion löscht. Ereignistyp inferred
	Zahlungssperre gesetzt	Diese Aktivität tritt auf, wenn eine Rechnung gesperrt wird, wodurch ihre Zahlung verhindert wird. Dies wird durch eine Änderung im Zahlungssperr- oder Sperrstatusfeld im gebuchten Rechnungsdatensatz erfasst.
Bedeutung Zahlungssperren sind eine Hauptursache für verspätete Zahlungen. Die Analyse, wann und warum sie gesetzt werden, ist entscheidend für die Verbesserung der Pünktlichkeitsrate bei Zahlungen und der Lieferantenbeziehungen. Datenquelle Abgeleitet aus einer Änderung des Zahlungs-Halte- oder Blockierfeldes in der gebuchten Kreditorentransaktion (VendTrans). Das Änderungslog kann verwendet werden, um den Timestamp zu erfassen. Erfassen Timestamp der Aktualisierung, die das Zahlungssperrfeld in der Lieferantentransaktion setzt. Ereignistyp inferred

Extraktionsleitfäden

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Zum Arbeitsbereich Datenverwaltung navigieren: Melden Sie sich bei Microsoft Dynamics 365 Finance an. Verwenden Sie die Suchleiste, um den Arbeitsbereich Data management zu finden und dorthin zu navigieren.
Neues Exportprojekt erstellen: Wählen Sie im Arbeitsbereich die Kachel Export, um ein neues Datenexportprojekt zu erstellen. Geben Sie einen aussagekräftigen Namen für das Projekt an, z. B. ProcessMind_Invoice_Processing_Export.
Datenprojekt definieren: Geben Sie auf der Registerkarte General des neuen Projekts das Data format an. CSV ist ein gängiges und empfohlenes Format. Legen Sie weitere Parameter nach Bedarf fest.
Erforderliche Datenentitäten hinzufügen: Gehen Sie zum Abschnitt Selected entities und klicken Sie auf Add entity. Suchen und fügen Sie die folgenden Kernentitäten einzeln hinzu. Sie müssen das Zieldatenformat für jede Entität angeben.
- VendInvoiceInfoTableEntity (Kreditorenrechnungskopf)
- VendInvoiceTransEntity (Kreditorenrechnungspositionen)
- VendInvoiceRegisterHeaderEntity (Rechnungsregister-Journal-Kopf)
- WorkflowTrackingStatusTableEntity (Workflow-Historie)
- AccountingDistributionEntity (Sachkontenverteilungen)
- VendInvoiceJour (Gebuchte Kreditorenrechnungen)
- VendTrans (Kreditorentransaktionen, für Zahlungsblockaden)
- LedgerJournalTransVendPaymEntity (Kreditorenzahlungsjournalpositionen)
- VendSettlement (Kreditorenverrechnungstransaktionen)
Filter anwenden: Für jede Entität ist es entscheidend, Filter anzuwenden, um den Datenumfang zu begrenzen. Wählen Sie eine Entität aus und klicken Sie auf Filter. Filtern Sie mindestens nach Company (Juristische Einheit) und einem spezifischen Datumsbereich in einem relevanten Datumsfeld wie CREATEDDATETIME oder INVOICEDATE. Ein typischer Bereich für die Erstanalysen sind die letzten 3 bis 6 Monate.
Entitätszuordnungen konfigurieren: Überprüfen Sie für jede Entität die Quell-zu-Ziel-Zuordnung. Stellen Sie sicher, dass alle für das finale Event Log erforderlichen Felder in den Export einbezogen werden. Komplexere Zuordnungsänderungen sind in der Regel in diesem Stadium nicht erforderlich.
Exportauftrag ausführen: Nachdem alle Entitäten hinzugefügt und gefiltert wurden, klicken Sie im Aktionsbereich auf Export, um den Auftrag zu starten. Sie können ihn sofort ausführen oder für Randzeiten planen, um die Systemlast zu minimieren.
Exportierte Daten herunterladen: Nachdem der Exportauftrag erfolgreich abgeschlossen wurde, navigieren Sie zur Auftragshistorie. Dort können Sie das exportierte Datenpaket herunterladen, das separate Dateien für jede Datenentität enthält.
Daten in ein Event Log transformieren: Die exportierten Dateien sind Entitäts-Snapshots, kein konsolidiertes Event Log. Sie müssen ein externes Tool wie eine Datenbank, ein Python-Skript oder Power Query verwenden, um diese Dateien zu verarbeiten und zu kombinieren. Die konzeptionelle Abfrage im Abschnitt query liefert die vollständige Logik für diese Transformation.
Transformationslogik ausführen: Laden Sie die exportierten CSV-Dateien in Ihre gewählte Transformationsumgebung. Führen Sie die bereitgestellte Transformationsabfrage aus, die Daten aus allen Quelldateien zusammenführt, um eine einheitliche Event Log-Tabelle mit einer Zeile pro Geschäftsaktivität zu erstellen.
Finalisieren und Hochladen: Exportieren Sie die final transformierten Daten in eine einzige CSV-Datei. Stellen Sie sicher, dass die Spaltenüberschriften den Anforderungen entsprechen, z. B. InvoiceNumber, ActivityName, EventTime. Diese Datei ist nun bereit zum Hochladen in ProcessMind.

Konfiguration

Datenentitäten: Der Kern der Konfiguration ist die Auswahl des korrekten Satzes von Entitäten, um den Rechnungslebenszyklus abzudecken. Zu den wichtigsten Entitäten gehören VendInvoiceInfoTableEntity, VendInvoiceJour und WorkflowTrackingStatusTableEntity.
Exportdatenformat: Wählen Sie CSV als Zieldatenformat für eine einfache Verarbeitung in nachfolgenden Transformationsschritten.
Filterung nach Unternehmen: Es ist entscheidend, jede Datenentität nach der spezifischen juristischen Einheit (Unternehmen) zu filtern, die Sie analysieren, um das Abrufen irrelevanter Daten zu vermeiden.
Datumsbereichsfilterung: Wenden Sie einen konsistenten Datumsbereichsfilter auf alle relevanten Entitäten, wie VendInvoiceInfoTableEntity und VendInvoiceJour, basierend auf Erstellungs- oder Buchungsdaten an. Beginnen Sie mit einem aktuellen Zeitraum, z. B. den letzten 6 Monaten, um das Datenvolumen zu steuern.
Vollständiger vs. inkrementeller Export: Führen Sie für die anfängliche Extraktion einen vollständigen Export durch. Für nachfolgende Aktualisierungen können Sie einen inkrementellen Export konfigurieren, um nur die Daten abzurufen, die sich seit dem letzten Lauf geändert haben, wodurch die Verarbeitungszeit reduziert wird.
Voraussetzungen: Der Benutzer, der den Export ausführt, muss über entsprechende Sicherheitsrollen in Dynamics 365 verfügen, typischerweise einschließlich Data management administrator oder einer ähnlichen Rolle mit Berechtigungen für den Zugriff auf die erforderlichen Datenentitäten.

a Beispielabfrage config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Schritte

Voraussetzung: BYOD konfigurieren: Stellen Sie sicher, dass die Funktion "Bring Your Own Database" für Ihre Microsoft Dynamics 365 Finance and Operations-Umgebung konfiguriert ist. Dies beinhaltet die Einrichtung einer Azure SQL-Datenbank und die Konfiguration von D365 zum Export von Daten dorthin.
Datenentitäten identifizieren: Navigieren Sie in D365 zum Arbeitsbereich Data management. Der Kern dieser Extraktion basiert auf dem Export spezifischer Datenentitäten. Stellen Sie sicher, dass die folgenden Entitäten in einem Exportauftrag enthalten sind, der auf Ihre BYOD-Datenbank abzielt: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements und Accounting distributions.
Exportauftrag erstellen und planen: Erstellen Sie im Arbeitsbereich Data management ein neues Exportprojekt. Fügen Sie die oben genannten Entitäten dem Projekt hinzu. Konfigurieren Sie das Zieldatenformat als Ihre BYOD-Datenbank. Richten Sie einen wiederkehrenden Zeitplan für den Exportauftrag ein, z. B. täglich oder stündlich, um die Daten in Ihrer BYOD frisch zu halten.
Daten in Azure SQL überprüfen: Verbinden Sie sich mit Ihrer Azure SQL-Datenbank mithilfe eines Tools wie SQL Server Management Studio (SSMS) oder Azure Data Studio. Überprüfen Sie, ob die den D365-Entitäten entsprechenden Tabellen erstellt und mit Daten gefüllt wurden.
SQL-Abfrage vorbereiten: Kopieren Sie die bereitgestellte SQL-Abfrage. Diese Abfrage ist so konzipiert, dass sie direkt auf den Tabellen ausgeführt wird, die durch den BYOD-Exportprozess in Ihrer Azure SQL-Datenbank erstellt wurden.
Verbinden und ausführen: Öffnen Sie ein neues Abfragefenster in Ihrem SQL-Client, der mit der BYOD verbunden ist. Fügen Sie die kopierte SQL-Abfrage in das Fenster ein.
Abfrageparameter festlegen: Suchen Sie die Platzhaltervariablen am Anfang des Skripts. Ersetzen Sie {StartDate}, {EndDate} und {CompanyCode} durch Ihr gewünschtes Startdatum, Enddatum bzw. die Kennung der juristischen Einheit. Zum Beispiel: SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Abfrage ausführen: Führen Sie das vollständige SQL-Skript aus. Die Abfrage sammelt und führt Daten aus mehreren Tabellen zusammen, um ein chronologisches Event Log für jede Rechnung zu erstellen.
Ergebnisse überprüfen: Die Ausgabe ist eine einzelne Tabelle, die das Event Log mit Spalten für InvoiceNumber, ActivityName, EventTime und andere spezifizierte Attribute enthält. Überprüfen Sie die Ergebnisse, um sicherzustellen, dass sie korrekt und vollständig erscheinen.
Event Log exportieren: Exportieren Sie die Abfrageergebnisse in eine CSV-Datei. Die meisten SQL-Clients verfügen über eine integrierte Funktion zum Speichern von Ergebnissen in einer Datei. Stellen Sie sicher, dass die Datei mit UTF-8-Kodierung gespeichert wird.
Für den Upload vorbereiten: Bestätigen Sie vor dem Upload in ein Process Mining-Tool, dass die CSV-Datei die exakten Header aufweist, wie in der Abfrage angegeben (InvoiceNumber, ActivityName, etc.). Es ist keine weitere Transformation der Dateistruktur erforderlich.

Konfiguration

Wesentliche Datenentitäten: Die Extraktion basiert darauf, dass mehrere D365-Datenentitäten in die BYOD exportiert werden. Kritische Entitäten sind: VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution und VendTrans.
Datumsbereichsfilterung: Die bereitgestellte Abfrage enthält die Parameter @StartDate und @EndDate. Es wird empfohlen, mit einem begrenzten Datumsbereich, z. B. 3-6 Monate an Daten, zu beginnen, um die Performance sicherzustellen. Der Filter wird auf das Rechnungsbuchungsdatum oder das Erstellungsdatum angewendet.
Unternehmenscode-Filterung: Der @DataAreaId-Parameter ist entscheidend für Mehrmandanten-Umgebungen. Filtern Sie immer nach einer spezifischen juristischen Einheit (Company Code), um sicherzustellen, dass der Datenkontext korrekt ist.
BYOD-Aktualisierungsfrequenz: Die Aktualität der Daten hängt vollständig vom Zeitplan des D365-Exportauftrags ab. Für eine Echtzeitanalyse ist eine hohe Frequenz (z. B. stündlich) erforderlich, was Performance- und Kostenfolgen sowohl für D365 als auch für Azure haben kann.
Voraussetzungen: Diese Methode erfordert ein aktives Azure-Abonnement, eine bereitgestellte Azure SQL-Datenbank und Administratorzugriff in D365, um den Arbeitsbereich Data management zu konfigurieren.

a Beispielabfrage sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

Schritte

Voraussetzungen für die Einrichtung: Stellen Sie sicher, dass Python 3.6 oder neuer auf Ihrem System installiert ist. Installieren Sie die notwendigen Bibliotheken mit pip: pip install pandas requests msal. Diese Bibliotheken dienen der Datenmanipulation, dem Stellen von HTTP-Anfragen an die API und der Authentifizierung mit der Microsoft Identity Platform.
Anwendung in Azure Active Directory registrieren: Um sich bei der Dynamics 365 API zu authentifizieren, müssen Sie eine Anwendung in Ihrem Azure AD-Mandanten registrieren. Erstellen Sie eine neue App Registration, generieren Sie einen Client Secret und notieren Sie sich die Application (client) ID, Directory (tenant) ID und den Wert des Client Secret.
API-Berechtigungen erteilen: Navigieren Sie innerhalb der neu erstellten App Registration in Azure AD zu API permissions. Fügen Sie eine Berechtigung für 'Dynamics ERP' oder 'Dynamics 365 Business Central' (je nach Ihrer Lizenz) hinzu und erteilen Sie die delegierte Berechtigung user_impersonation. Ein Administrator muss die Admin-Zustimmung für diese Berechtigungen erteilen.
Anwendungsbenutzer in Dynamics 365 erstellen: Navigieren Sie in Ihrer Dynamics 365-Umgebung zu System administration > Users > Users. Erstellen Sie einen neuen Benutzer und geben Sie die Application (client) ID aus der Azure App Registration in das Feld Application ID ein. Weisen Sie diesem Benutzer entsprechende Sicherheitsrollen zu, wie z. B. 'System administrator' oder eine restriktivere Rolle, die Lesezugriff auf alle erforderlichen Datenentitäten hat.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, z. B. extract_invoices.py. Öffnen Sie die Datei und aktualisieren Sie die Platzhaltervariablen am Anfang mit Ihrer spezifischen Dynamics 365 Umgebungs-URL, Mandanten-ID, Client-ID, Client Secret und dem Unternehmenscode (dataAreaId), aus dem Sie Daten extrahieren möchten.
Datumsbereich festlegen: Passen Sie die Variablen START_DATE und END_DATE im Skript an, um das Zeitfenster für die Datenextraktion zu definieren. Es wird empfohlen, mit einem kleineren Bereich, z. B. einem Monat, zu beginnen, um das Skript zu testen und die Ergebnisse zu überprüfen.
Skript ausführen: Führen Sie das Skript von Ihrer Befehlszeile oder Ihrem Terminal aus mit dem Befehl: python extract_invoices.py. Das Skript authentifiziert sich, fragt die verschiedenen OData-Endpunkte für jede Aktivität ab und verarbeitet die Daten.
Ausführung überwachen: Das Skript gibt Fortschrittsmeldungen auf der Konsole aus, während es Daten für jede Aktivität abruft. Dies kann je nach Datumsbereich und Datenvolumen eine erhebliche Zeit in Anspruch nehmen. Achten Sie auf Fehlermeldungen, die auf Probleme mit der Authentifizierung oder dem API-Zugriff hinweisen könnten.
Ausgabedatei überprüfen: Sobald das Skript erfolgreich abgeschlossen ist, wird eine CSV-Datei namens d365_invoice_event_log.csv im selben Verzeichnis generiert. Diese Datei enthält das konsolidierte Event Log.
Für den Upload vorbereiten: Öffnen Sie die CSV-Datei, um sicherzustellen, dass sie korrekt formatiert ist. Überprüfen Sie, ob alle erforderlichen Spalten (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) vorhanden und ausgefüllt sind. Die Datei ist nun bereit zum Hochladen in ProcessMind.

Konfiguration

Authentifizierung: Das Skript verwendet den OAuth 2.0 Client Credentials Flow. Sie müssen eine Azure AD App Registration konfigurieren und dieser API-Berechtigungen für Dynamics 365 erteilen. Ein Anwendungsbenutzer mit entsprechenden Sicherheitsrollen muss in Dynamics 365 selbst erstellt werden.
API-Endpunkt: Die Basis-URL für die Dynamics 365 Finance and Operations OData API. Das Format ist typischerweise https://[your-d365-environment-name].operations.dynamics.com.
Datumsbereich: Das Skript enthält die Variablen START_DATE und END_DATE. Diese werden verwendet, um Datensätze basierend auf ihren Erstellungs- oder Änderungsdaten zu filtern und das Datenvolumen zu steuern. Für anfängliche Extraktionen wird ein Zeitraum von 3 bis 6 Monaten empfohlen.
Unternehmensfilter: Daten müssen nach einer spezifischen juristischen Einheit oder einem Unternehmen gefiltert werden. Dies geschieht durch die Angabe der dataAreaId im API-Abfragefilter, was eine obligatorische Konfiguration im Skript ist.
Wesentliche Datenentitäten: Das Skript fragt mehrere Standard-Dynamics 365 OData-Entitäten ab, darunter VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines und VendSettlements. Kundenspezifische Entitäten können erforderlich sein, wenn der Standardprozess stark modifiziert wurde.
Paginierung: Das Skript verarbeitet paginierte Antworten von der API automatisch mithilfe der @odata.nextLink-Eigenschaft, um sicherzustellen, dass alle Datensätze für den angegebenen Zeitraum abgerufen werden.

a Beispielabfrage python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].operations.dynamics.com"
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_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

    if not all_events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

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

Schritte

Zum Arbeitsbereich Datenverwaltung navigieren: Melden Sie sich bei Microsoft Dynamics 365 Finance an. Verwenden Sie die Suchleiste, um den Arbeitsbereich Data management zu finden und dorthin zu navigieren.
Neues Exportprojekt erstellen: Wählen Sie im Arbeitsbereich die Kachel Export, um ein neues Datenexportprojekt zu erstellen. Geben Sie einen aussagekräftigen Namen für das Projekt an, z. B. ProcessMind_Invoice_Processing_Export.
Datenprojekt definieren: Geben Sie auf der Registerkarte General des neuen Projekts das Data format an. CSV ist ein gängiges und empfohlenes Format. Legen Sie weitere Parameter nach Bedarf fest.
Erforderliche Datenentitäten hinzufügen: Gehen Sie zum Abschnitt Selected entities und klicken Sie auf Add entity. Suchen und fügen Sie die folgenden Kernentitäten einzeln hinzu. Sie müssen das Zieldatenformat für jede Entität angeben.
- VendInvoiceInfoTableEntity (Kreditorenrechnungskopf)
- VendInvoiceTransEntity (Kreditorenrechnungspositionen)
- VendInvoiceRegisterHeaderEntity (Rechnungsregister-Journal-Kopf)
- WorkflowTrackingStatusTableEntity (Workflow-Historie)
- AccountingDistributionEntity (Sachkontenverteilungen)
- VendInvoiceJour (Gebuchte Kreditorenrechnungen)
- VendTrans (Kreditorentransaktionen, für Zahlungsblockaden)
- LedgerJournalTransVendPaymEntity (Kreditorenzahlungsjournalpositionen)
- VendSettlement (Kreditorenverrechnungstransaktionen)
Filter anwenden: Für jede Entität ist es entscheidend, Filter anzuwenden, um den Datenumfang zu begrenzen. Wählen Sie eine Entität aus und klicken Sie auf Filter. Filtern Sie mindestens nach Company (Juristische Einheit) und einem spezifischen Datumsbereich in einem relevanten Datumsfeld wie CREATEDDATETIME oder INVOICEDATE. Ein typischer Bereich für die Erstanalysen sind die letzten 3 bis 6 Monate.
Entitätszuordnungen konfigurieren: Überprüfen Sie für jede Entität die Quell-zu-Ziel-Zuordnung. Stellen Sie sicher, dass alle für das finale Event Log erforderlichen Felder in den Export einbezogen werden. Komplexere Zuordnungsänderungen sind in der Regel in diesem Stadium nicht erforderlich.
Exportauftrag ausführen: Nachdem alle Entitäten hinzugefügt und gefiltert wurden, klicken Sie im Aktionsbereich auf Export, um den Auftrag zu starten. Sie können ihn sofort ausführen oder für Randzeiten planen, um die Systemlast zu minimieren.
Exportierte Daten herunterladen: Nachdem der Exportauftrag erfolgreich abgeschlossen wurde, navigieren Sie zur Auftragshistorie. Dort können Sie das exportierte Datenpaket herunterladen, das separate Dateien für jede Datenentität enthält.
Daten in ein Event Log transformieren: Die exportierten Dateien sind Entitäts-Snapshots, kein konsolidiertes Event Log. Sie müssen ein externes Tool wie eine Datenbank, ein Python-Skript oder Power Query verwenden, um diese Dateien zu verarbeiten und zu kombinieren. Die konzeptionelle Abfrage im Abschnitt query liefert die vollständige Logik für diese Transformation.
Transformationslogik ausführen: Laden Sie die exportierten CSV-Dateien in Ihre gewählte Transformationsumgebung. Führen Sie die bereitgestellte Transformationsabfrage aus, die Daten aus allen Quelldateien zusammenführt, um eine einheitliche Event Log-Tabelle mit einer Zeile pro Geschäftsaktivität zu erstellen.
Finalisieren und Hochladen: Exportieren Sie die final transformierten Daten in eine einzige CSV-Datei. Stellen Sie sicher, dass die Spaltenüberschriften den Anforderungen entsprechen, z. B. InvoiceNumber, ActivityName, EventTime. Diese Datei ist nun bereit zum Hochladen in ProcessMind.

Konfiguration

Datenentitäten: Der Kern der Konfiguration ist die Auswahl des korrekten Satzes von Entitäten, um den Rechnungslebenszyklus abzudecken. Zu den wichtigsten Entitäten gehören VendInvoiceInfoTableEntity, VendInvoiceJour und WorkflowTrackingStatusTableEntity.
Exportdatenformat: Wählen Sie CSV als Zieldatenformat für eine einfache Verarbeitung in nachfolgenden Transformationsschritten.
Filterung nach Unternehmen: Es ist entscheidend, jede Datenentität nach der spezifischen juristischen Einheit (Unternehmen) zu filtern, die Sie analysieren, um das Abrufen irrelevanter Daten zu vermeiden.
Datumsbereichsfilterung: Wenden Sie einen konsistenten Datumsbereichsfilter auf alle relevanten Entitäten, wie VendInvoiceInfoTableEntity und VendInvoiceJour, basierend auf Erstellungs- oder Buchungsdaten an. Beginnen Sie mit einem aktuellen Zeitraum, z. B. den letzten 6 Monaten, um das Datenvolumen zu steuern.
Vollständiger vs. inkrementeller Export: Führen Sie für die anfängliche Extraktion einen vollständigen Export durch. Für nachfolgende Aktualisierungen können Sie einen inkrementellen Export konfigurieren, um nur die Daten abzurufen, die sich seit dem letzten Lauf geändert haben, wodurch die Verarbeitungszeit reduziert wird.
Voraussetzungen: Der Benutzer, der den Export ausführt, muss über entsprechende Sicherheitsrollen in Dynamics 365 verfügen, typischerweise einschließlich Data management administrator oder einer ähnlichen Rolle mit Berechtigungen für den Zugriff auf die erforderlichen Datenentitäten.

a Beispielabfrage config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Ihr Purchase-to-Pay – Rechnungsbearbeitungs-Datentemplate

Ihr Purchase-to-Pay – Rechnungsbearbeitungs-Datentemplate

Procure-to-Pay – Rechnungsverarbeitungsattribute

Procure-to-Pay – Rechnungsverarbeitungsaktivitäten

Extraktionsleitfäden

Dynamics 365 Data Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Direkte SQL-Abfrage über Bring Your Own Database (BYOD)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit Dynamics 365 OData REST API

Schritte

Konfiguration

a Beispielabfrage python

Microsoft Power Platform Dataflow Extraktion

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Beginnen Sie noch heute mit der Optimierung Ihrer Procure-to-Pay – Rechnungsverarbeitung

Ihr Purchase-to-Pay – Rechnungsbearbeitungs-Datentemplate

Ihr Purchase-to-Pay – Rechnungsbearbeitungs-Datentemplate

Procure-to-Pay – Rechnungsverarbeitungsattribute

Procure-to-Pay – Rechnungsverarbeitungsaktivitäten

Extraktionsleitfäden

Dynamics 365 Data Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Direkte SQL-Abfrage über Bring Your Own Database (BYOD)

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit Dynamics 365 OData REST API

Schritte

Konfiguration

a Beispielabfrage python

Microsoft Power Platform Dataflow Extraktion

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Beginnen Sie noch heute mit der Optimierung Ihrer Procure-to-Pay – Rechnungsverarbeitung