> Kontinuierliche Prozessverbesserung > Auftragsabwicklung vom Auftrag bis zum Zahlungseingang > Microsoft Dynamics 365 > Daten Template

Ihr Daten-Template für Order to Cash – Auftragsabwicklung

Microsoft Dynamics 365

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Order to Cash – Auftragsabwicklung(20) Aktivitäten für Order to Cash – Auftragsabwicklung(13) Anleitungen zur Datenextraktion(2)

Ihr Daten-Template für Order to Cash – Auftragsabwicklung

Dieses Template bietet einen strukturierten Überblick über die wesentlichen Datenelemente, die Sie für die Analyse der Auftragsabwicklung im Order-to-Cash-Prozess in Microsoft Dynamics 365 benötigen. Es beschreibt die wichtigen Attribute, die Sie erfassen sollten, und die zentralen Aktivitäten, die in Ihrem Event Log nachverfolgt werden. Außerdem finden Sie praktische Hinweise dazu, wie Sie diese Daten effizient aus Ihrem System extrahieren.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Prozessaktivitäten zur Nachverfolgung
Konkrete Hinweise zur Datenextraktion aus Microsoft Dynamics 365

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

Template herunterladen

Attribute für Order to Cash – Auftragsabwicklung

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie die Auftragsabwicklung im Order-to-Cash-Prozess in Microsoft Dynamics 365 umfassend analysieren können.

5 Erforderlich 5 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die Bezeichnung des konkreten Geschäftsereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Vertriebsauftragsprozess stattgefunden hat.
Beschreibung Dieses Attribut bezeichnet einen einzelnen Schritt oder ein Ereignis im Lebenszyklus eines Vertriebsauftrags, etwa „Vertriebsauftrag erstellt“, „Waren versandt“ oder „Zahlung eingegangen“. Die Abfolge dieser Aktivitäten für einen Vertriebsauftrag bildet den Prozessfluss. Die Analyse der Reihenfolge, Häufigkeit und Übergänge zwischen Aktivitäten ist der Kern des Process Mining. Sie hilft, den Prozess zu visualisieren, häufige und seltene Prozessvarianten zu erkennen, Engpässe aufzudecken und Bereiche mit Nacharbeit oder Verstößen gegen Vorgaben zu ermitteln. Dieses Attribut ist grundlegend, um zu verstehen, was im Prozess tatsächlich geschieht. Warum das wichtig ist Das Attribut legt die Prozessschritte fest. So lässt sich der Prozessfluss erstellen und visualisieren, ein zentrales Ziel des Process Mining. Woher beziehen Dieses Attribut wird konzeptionell abgeleitet, indem bestimmte Systemereignisse oder Statusänderungen in Tabellen wie „SalesTable“ sowie zugehörigen Logistik- oder Finanztabellen einer standardisierten Aktivitätsbezeichnung zugeordnet werden. Beispiele Vertriebsauftrag erstelltWaren versandtRechnung erstelltZahlung eingegangen
	Startzeit EventTime	Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt, also der Timestamp, hält den genauen Zeitpunkt einer Aktivität fest. Jede Aktivität im Event Log hat einen zugehörigen Timestamp. So entsteht für jeden Case ein chronologischer Prozessverlauf. Dieses Attribut ist für alle zeitbasierten Analysen im Process Mining entscheidend. Es dient dazu, Durchlaufzeiten zwischen Aktivitäten und die Gesamtdauer eines Cases zu berechnen, Wartezeiten zu analysieren und Engpässe zu erkennen, an denen sich der Prozess verzögert. Außerdem ermöglicht es die zeitliche Überwachung der Leistung, etwa anhand des Durchsatzes pro Tag, Woche oder Monat. Warum das wichtig ist Dieser Timestamp ist unverzichtbar, um alle zeitbezogenen Kennzahlen wie Durchlaufzeiten und Engpässe zu berechnen und Ereignisse chronologisch zu ordnen. Woher beziehen Das Attribut wird aus verschiedenen Datums- und Uhrzeitfeldern zu bestimmten Transaktionen abgeleitet, etwa aus „SalesTable.CreatedDateTime“ für die Auftragserstellung oder aus den Buchungsdaten des Zahlungsjournals für Zahlungen. Beispiele 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Vertriebsauftrag SalesOrderNumber	Der eindeutige Identifikator jedes Vertriebsauftrags. Er dient als primäre Case-ID des Prozesses.
Beschreibung Die Vertriebsauftragsnummer ist ein eindeutiger alphanumerischer Code, der jedem Kundenauftrag in Microsoft Dynamics 365 zugewiesen wird. Sie dient als zentrale Case-ID und verknüpft alle zugehörigen Aktivitäten und Ereignisse von der Erstellung bis zum Abschluss. Im Process Mining ist dieses Attribut unverzichtbar, um den End-to-End-Ablauf jedes einzelnen Vertriebsauftrags zu rekonstruieren. Analysten können damit die vollständige Aktivitätsfolge nachverfolgen, die Dauer eines Cases messen und Abweichungen für jeden Auftrag untersuchen. So bildet das Attribut die Grundlage für die gesamte Prozessanalyse. Warum das wichtig ist Dieser Identifikator ist entscheidend, um alle zugehörigen Ereignisse miteinander zu verknüpfen und jeden Vertriebsauftrag vollständig von Anfang bis Ende zu analysieren. Woher beziehen In der Tabelle „SalesTable“, Feld „SalesId“. Beispiele SO-00102345SO-00102346SO-00102347
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs aus Microsoft Dynamics 365. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Für fundierte Entscheidungen in der Prozessanalyse ist entscheidend, wie aktuell die Daten sind. Der Timestamp zeigt genau, wann die letzte Aktualisierung stattgefunden hat. So können Benutzer darauf vertrauen, dass ihre Schlussfolgerungen auf aktuellen Informationen beruhen. Warum das wichtig ist So wissen Benutzer, wie aktuell die Daten sind. Das ist entscheidend für die Relevanz und Genauigkeit der Process-Mining-Analyse. Woher beziehen Dieser Wert wird bei der Datenextraktion erzeugt und während der Datenübernahme an jeden Datensatz angefügt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem Informationssystem die Daten stammen.
Beschreibung Dieses Attribut gibt an, aus welcher Quellanwendung die Ereignisdaten stammen. In diesem Fall ist das in der Regel „Microsoft Dynamics 365“. Bei einer Analyse mit nur einem System mag das überflüssig erscheinen. Sobald Daten aus mehreren Systemen zusammengeführt werden, etwa aus einem separaten CRM- oder Lagerverwaltungssystem, ist die Angabe jedoch entscheidend. Sie macht die Datenherkunft nachvollziehbar und erleichtert die Fehlersuche bei der Datenextraktion, da sich der Ursprung der Datensätze eindeutig bestimmen lässt. Warum das wichtig ist Das Attribut liefert wichtige Informationen zur Datenherkunft. Besonders bei der Integration mehrerer Systeme sorgt es für eine klare Rückverfolgbarkeit der Daten. Woher beziehen Dieser statische Wert wird in der Regel während der Datentransformation ergänzt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
	Bestätigtes Lieferdatum ConfirmedDeliveryDate	Das Lieferdatum, das das Unternehmen dem Kunden bestätigt und zugesagt hat.
Beschreibung Das bestätigte Lieferdatum ist der Termin, zu dem das verkaufende Unternehmen die Warenlieferung zusagt. Es wird festgelegt, nachdem interne Prüfungen, etwa zur Bestandsverfügbarkeit und Produktionsplanung, abgeschlossen sind. Dieses Attribut ist wichtig, um die KPI „Einhaltungsquote der Liefertermine“ anhand der betrieblichen Zusage zu berechnen. Als interner Vergleichswert für termingerechte Lieferungen ist es realistischer als der ursprünglich vom Kunden gewünschte Termin. Die Analyse von Abweichungen zeigt interne Probleme in Logistik und Auftragsabwicklung auf. Warum das wichtig ist Gibt die Zusage des Unternehmens gegenüber dem Kunden wieder und ist damit ein wichtiger interner Vergleichswert für die Zuverlässigkeit der Auftragsabwicklung und die betriebliche Leistung. Woher beziehen Befindet sich in den Positionsdaten der Verkaufsbestellung, häufig in der Tabelle „SalesLine“ in einem Feld wie „ConfirmedDlv“. Beispiele 2023-05-122023-06-012023-05-28
	Bestellwert OrderValue	Der Gesamtwert der Verkaufsbestellung.
Beschreibung Dieses Attribut gibt den Gesamtbetrag der Verkaufsbestellung an, einschließlich aller Positionen, Steuern und Gebühren. Es ist eine wichtige finanzielle Kennzahl für jeden Case. Der Bestellwert ist für eine wertbasierte Prozessanalyse entscheidend. Damit können Sie den Prozess nach Auftragswert segmentieren und prüfen, ob Bestellungen mit hohem Wert anders bearbeitet werden oder häufiger Verzögerungen aufweisen als Bestellungen mit niedrigem Wert. So lassen sich Verbesserungsmaßnahmen auf die finanziell bedeutendsten Cases konzentrieren. Außerdem unterstützt das Attribut Dashboards wie „Bestellwert nach Segment“. Warum das wichtig ist Ermöglicht die finanzielle Segmentierung des Prozesses. So können Sie Verbesserungen bei Bestellungen mit hohem Wert priorisieren und die finanziellen Auswirkungen von Prozessabweichungen nachvollziehen. Woher beziehen Der Wert befindet sich in den Kopfdaten der Verkaufsbestellung. Die genaue Tabelle und das Feld finden Sie in der Microsoft-Dynamics-365-Dokumentation. Häufig wird der Wert aus den Beträgen der Verkaufspositionen berechnet. Beispiele 5250.7512300.00899.50
	Kundenname CustomerName	Der Name des Kunden, der die Verkaufsbestellung aufgegeben hat.
Beschreibung Dieses Attribut enthält den offiziellen Namen des Kunden, der der Verkaufsbestellung zugeordnet ist. Es wird ermittelt, indem die Kundennummer in der Verkaufsbestellung mit den zentralen Kundendaten verknüpft wird. Die Analyse nach Kunden ist grundlegend, um kundenspezifisches Verhalten und Servicequalität zu verstehen. Sie zeigt, bei welchen Kunden die größten Verzögerungen oder die meisten Nacharbeiten auftreten und welche Kunden von den Standardprozesspfaden abweichen. Diese Erkenntnisse helfen, die Kundenzufriedenheit zu verbessern und wichtige Kundenbeziehungen gezielt zu betreuen. Warum das wichtig ist Ermöglicht eine kundenbezogene Analyse, mit der sich kundenspezifische Muster, Verzögerungen und Probleme erkennen lassen. Diese wirken sich direkt auf die Kundenzufriedenheit aus. Woher beziehen Wird anhand des Felds „CustAccount“ aus der Tabelle „SalesTable“ in der Tabelle „CustTable“ nachgeschlagen. Beispiele Contoso LtdAdatum CorporationFabrikam Inc.
	Vertriebskanal SalesChannel	Der Kanal, über den die Verkaufsbestellung eingegangen ist, zum Beispiel Web, Direktvertrieb oder Partner.
Beschreibung Der Vertriebskanal gibt an, über welchen Weg die Kundenbestellung eingegangen ist. Das kann eine E-Commerce-Website, ein Direktvertriebsteam, ein Ladengeschäft, ein Callcenter oder ein Partnernetzwerk sein. In Dynamics 365 wird diese Dimension häufig entsprechend den geschäftlichen Anforderungen konfiguriert. Die Analyse nach Vertriebskanälen macht Leistungsunterschiede sichtbar. Webbestellungen werden beispielsweise möglicherweise schneller und stärker automatisiert bearbeitet als telefonische Bestellungen. Diese Erkenntnisse unterstützen die gezielte Optimierung der Abläufe und die Ressourcenplanung für einzelne Kanäle. Sie eignen sich auch für Dashboards wie „Bestellwert nach Segment“. Warum das wichtig ist Ermöglicht den Leistungsvergleich verschiedener Vertriebskanäle. So werden Ineffizienzen und bewährte Vorgehensweisen bei der Auftragserfassung sichtbar. Woher beziehen Diese Information ist in der Regel in den Kopfdaten der Verkaufsbestellung gespeichert. Das genaue Feld finden Sie in der Microsoft-Dynamics-365-Dokumentation. Beispiele WebDirektvertriebPartnerEinzelhandel
	Vom Kunden gewünschtes Lieferdatum RequestedDeliveryDate	Das vom Kunden gewünschte Lieferdatum der Bestellung.
Beschreibung Dieses Attribut speichert das Datum, an dem der Kunde ursprünglich die Lieferung seiner Waren erwartet hat. Es wird bei der Auftragserstellung erfasst und dient als Grundlage, um die Lieferleistung aus Kundensicht zu messen. Das Datum ist eine wichtige Eingangsgröße für das Dashboard „Einhaltung des Liefertermins“. Ein Vergleich von „RequestedDeliveryDate“ mit „ConfirmedDeliveryDate“ und dem tatsächlichen Datum der Aktivität „Waren geliefert“ zeigt, wie gut das Unternehmen die Kundenerwartungen erfüllt. Große Abweichungen können auf Probleme bei der Planung, im Bestand oder in der Logistik hinweisen. Warum das wichtig ist Gibt die Liefererwartung des Kunden wieder und dient als wichtige Grundlage für die Messung der Kundenzufriedenheit und der Leistung bei termingerechter Lieferung. Woher beziehen Befindet sich in der Tabelle „SalesTable“ und heißt häufig „DeliveryDate“ oder ähnlich. Beispiele 2023-05-102023-06-012023-05-25
	Artikelnummer ItemNumber	Die eindeutige Kennung eines Produkts oder einer Dienstleistung in der Verkaufsbestellung.
Beschreibung Die Artikelnummer identifiziert das verkaufte Produkt. Da eine Verkaufsbestellung mehrere Produkte enthalten kann, ist dieses Attribut in den Ereignisdaten in der Regel der einzelnen Position zugeordnet. Die Analyse nach Produkten macht produktspezifische Probleme sichtbar. Bestimmte Produkte können beispielsweise mit längeren Abwicklungszeiten, mehr Nacharbeit oder häufigeren Kreditsperren verbunden sein. So lassen sich Bestandsverwaltung, Produktdaten oder Auftragsabwicklung für einzelne Artikel gezielt verbessern. Warum das wichtig ist Ermöglicht die Analyse auf Produktebene und zeigt, ob bestimmte Artikel mit Verzögerungen, Nacharbeit oder anderen Ineffizienzen verbunden sind. Woher beziehen Befindet sich in der Tabelle „SalesLine“ im Feld „ItemId“. Beispiele PROD-00123PROD-00548SVC-00045
	Benutzername UserName	Der Name des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut gibt an, welcher Mitarbeiter oder Systembenutzer eine bestimmte Aufgabe ausgeführt hat, etwa eine Bestellung bestätigt oder eine Rechnung erstellt. In der Regel ist es über eine Benutzer-ID mit Microsoft Dynamics 365 verknüpft. Die Analyse der Leistung nach Benutzern hilft dabei, Schulungsbedarf zu erkennen, besonders leistungsstarke Mitarbeitende zu identifizieren und die Arbeitslast angemessen zu verteilen. Auch für Compliance und Audits ist das Attribut wichtig, da sich jede ausgeführte Aktion eindeutig zuordnen lässt. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach einzelnen Benutzern oder Teams. So lassen sich Schulungsbedarf, eine ungleich verteilte Arbeitslast und ressourcenbedingte Engpässe erkennen. Woher beziehen Wird aus Benutzer-ID-Feldern wie „CreatedBy“ oder „ModifiedBy“ in verschiedenen Transaktionstabellen abgeleitet. Diese werden mit der zentralen Benutzertabelle, beispielsweise „UserInfo“, verknüpft, um den vollständigen Namen abzurufen. Beispiele Alice JohnsonRobert BrownSystemadministrator
	Endzeit EndTime	Datum und Uhrzeit, zu denen eine Aktivität abgeschlossen wurde.
Beschreibung Der Timestamp für die Endzeit erfasst den Zeitpunkt, an dem eine Aktivität abgeschlossen wird. Wenn dieser Wert verfügbar ist, lässt sich die Dauer einer Aktivität genauer bestimmen, als wenn sie aus der Startzeit der nächsten Aktivität abgeleitet wird. Liegen Start- und Endzeit vor, lässt sich die „Verarbeitungszeit“ jeder Aktivität genau berechnen und von der „Wartezeit“ zwischen Aktivitäten unterscheiden. So erkennen Sie, welche Aufgaben besonders viel Zeit beanspruchen und bei welchen Prozessschritten lange Verzögerungen auftreten. Warum das wichtig ist Ermöglicht die genaue Berechnung der Verarbeitungszeit einzelner Aktivitäten und unterscheidet aktive Arbeitszeit von Wartezeit. Woher beziehen Wie die Startzeit wird dieser Wert aus verschiedenen Datums- und Uhrzeitfeldern abgeleitet. Möglich sind beispielsweise das Feld „ModifiedDateTime“ oder ein Timestamp für eine Statusänderung in Tabellen wie „SalesTable“ oder „WHSLoadTable“. Beispiele 2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
	Land CountryRegion	Das Land der Lieferadresse des Kunden.
Beschreibung Dieses Attribut gibt das Zielland der Lieferung zur Verkaufsbestellung an. Es wird aus den in Dynamics 365 gespeicherten Lieferadressdaten des Kunden abgeleitet. Die Analyse der Prozessleistung nach Ländern ist wichtig, um regionale Unterschiede zu erkennen. Bei internationalen Lieferungen können zusätzliche Schritte wie die Zollabfertigung die Zykluszeiten verlängern. Die Analyse hilft, die Logistik für verschiedene geografische Märkte besser zu verstehen und zu optimieren. Warum das wichtig ist Ermöglicht geografische Auswertungen, mit denen sich regionale Engpässe, Compliance-Probleme und Leistungsunterschiede in der Lieferkette erkennen lassen. Woher beziehen Wird aus der Lieferadresse des Kunden abgeleitet, die mit der Verkaufsbestellung verknüpft ist. Die Länderangabe befindet sich in der Regel in der Tabelle „LogisticsPostalAddress“, die über die Lieferadressverknüpfung mit „SalesTable“ verbunden ist. Beispiele USADEUCANGBR
	Nacharbeit IsRework	Ein boolesches Kennzeichen, das angibt, ob bei einer Verkaufsbestellung Nacharbeit aufgetreten ist, zum Beispiel durch eine wiederholte Aktivität.
Beschreibung Dieses berechnete Attribut kennzeichnet Cases, deren Prozessverlauf vom direkten „Happy Path“ abweicht. Nacharbeit wird anhand von Aktivitätsfolgen erkannt, die auf einen wiederholten Schritt hindeuten, etwa wenn eine Bestellung zunächst nicht bestätigt und später erneut bestätigt wird oder Waren kommissioniert und anschließend wieder eingelagert werden. Die Kennzeichnung von Cases mit Nacharbeit ist für die KPI „Nacharbeitsquote bei Verkaufsbestellungen“ entscheidend. Analysten können ineffiziente Prozessverläufe schnell herausfiltern und untersuchen, um die Ursachen der Nacharbeit zu ermitteln. Dazu zählen beispielsweise Eingabefehler, Kreditprobleme oder Bestandsprobleme. Nacharbeit zu verringern ist ein zentrales Ziel vieler Prozessverbesserungsprojekte. Warum das wichtig ist Macht Prozessineffizienzen messbar, indem Cases mit wiederholten Schritten gekennzeichnet werden. So können Sie gezielt Verschwendung und Verzögerungen verringern. Woher beziehen Das Process-Mining-Tool berechnet dieses Attribut anhand der Aktivitätsfolge für jeden Case. Das Muster (A -> B -> C -> B) weist beispielsweise auf Nacharbeit hin. Beispiele truefalse
	Pünktliche Zahlung OnTimePayment	Ein boolesches Kennzeichen, das angibt, ob die Zahlung am oder vor dem Fälligkeitsdatum eingegangen ist.
Beschreibung Dieses berechnete Attribut vergleicht den Timestamp der Aktivität „Zahlung eingegangen“ mit „PaymentDueDate“. Es erhält den Wert „true“, wenn die Zahlung pünktlich eingegangen ist, und „false“, wenn sie verspätet war. Dieses Kennzeichen ist die zentrale Grundlage für die KPI „Quote pünktlicher Zahlungen“. Damit lassen sich Kunden schnell in pünktliche und verspätete Zahler segmentieren. Die Analyse kann in die Gestaltung von Kreditrichtlinien, Mahnstrategien und Kundenbeziehungen einfließen, indem sie Kunden mit regelmäßig verspäteten Zahlungen identifiziert. Warum das wichtig ist Misst das Zahlungsverhalten der Kunden anhand der vereinbarten Bedingungen. Das ist grundlegend für die Steuerung des Cashflows und die Bewertung des Kreditrisikos. Woher beziehen Wird berechnet, indem der „EventTime“-Wert der Aktivität „Zahlung eingegangen“ mit dem Attribut „PaymentDueDate“ verglichen wird. Formel: (Timestamp von „Zahlung eingegangen“ <= PaymentDueDate). Beispiele truefalse
	Status der Verkaufsbestellung SalesOrderStatus	Der aktuelle Status der Verkaufsbestellung zum Zeitpunkt der Datenextraktion.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Verkaufsbestellung wieder, zum Beispiel „Offene Bestellung“, „Fakturiert“, „Storniert“ oder „Geliefert“. Es handelt sich um einen zusammenfassenden Status, der in den Kopfdaten der Verkaufsbestellung geführt wird. Das Aktivitätsprotokoll zeigt den Prozessverlauf. Der Endstatus eignet sich dagegen zum Filtern und Segmentieren. Analysten können damit alle offenen Bestellungen anzeigen, um die aktuelle Arbeitslast zu überblicken, oder erfolgreich abgeschlossene Bestellungen von stornierten trennen und die Gründe für Stornierungen untersuchen. Warum das wichtig ist Zeigt den aktuellen Stand der Bestellung. Damit lassen sich offene, abgeschlossene oder stornierte Bestellungen für Analysen filtern, etwa zur Arbeitslaststeuerung und Ergebnisanalyse. Woher beziehen Befindet sich in der Tabelle „SalesTable“ im Feld „SalesStatus“. Beispiele RückstandGeliefertFakturiertStorniert
	Termingerechte Lieferung OnTimeDelivery	Ein boolesches Kennzeichen, das angibt, ob die Waren am bestätigten Lieferdatum oder früher geliefert wurden.
Beschreibung Dieses berechnete Attribut vergleicht den Timestamp der Aktivität „Waren geliefert“ mit dem „ConfirmedDeliveryDate“ der jeweiligen Verkaufsbestellung. Es erhält den Wert „true“, wenn die Lieferung pünktlich oder früher erfolgte, und „false“, wenn sie verspätet war. Dieses Kennzeichen bildet die Grundlage für die KPI „Einhaltungsquote der Liefertermine“. Es vereinfacht die Analyse, da sich pünktliche und verspätete Bestellungen leicht filtern und zusammenfassen lassen. So erkennen Sie schnell, welche Faktoren mit verspäteten Lieferungen zusammenhängen, etwa bestimmte Produkte, Kunden, Regionen oder Versandarten. Warum das wichtig ist Misst die Auftragsabwicklung direkt an der zugesagten Lieferfrist. Das ist entscheidend, um die Kundenzufriedenheit und die Zuverlässigkeit der Lieferkette zu überwachen. Woher beziehen Wird berechnet, indem der „EventTime“-Wert der Aktivität „Waren geliefert“ mit dem Attribut „ConfirmedDeliveryDate“ verglichen wird. Formel: (Timestamp von „Waren geliefert“ <= ConfirmedDeliveryDate). Beispiele truefalse
	Versandart ShippingMethod	Die Versandart oder der Transportdienstleister, mit dem die Waren an den Kunden geliefert werden.
Beschreibung Dieses Attribut gibt den für die Lieferung verwendeten Transportdienst an, zum Beispiel „Bodenversand“, „Luftfracht“ oder den Namen eines bestimmten Transportunternehmens. Die Auswahl erfolgt während der Auftragsbearbeitung anhand der Kundenwünsche, der Kosten und der Liefergeschwindigkeit. Für das Dashboard „Leistung nach Versandart“ ist diese Dimension entscheidend. Ein Vergleich der Zykluszeiten von „Waren verpackt“ bis „Waren geliefert“ nach Versandart zeigt, welche Transportunternehmen schneller und zuverlässiger sind oder häufiger Verzögerungen verursachen. Diese Erkenntnisse unterstützen eine bessere Logistikplanung und die Auswahl geeigneter Transportunternehmen. Warum das wichtig ist Ermöglicht die Analyse verschiedener Transportunternehmen und Versandoptionen. So lässt sich die Logistik im Hinblick auf Kosten, Geschwindigkeit und Zuverlässigkeit optimieren. Woher beziehen Diese Information ist in der Regel in den Kopfdaten der Verkaufsbestellung oder in zugehörigen Datensätzen zur Auftragsabwicklung gespeichert. Weitere Informationen finden Sie in der Microsoft-Dynamics-365-Dokumentation. Beispiele FedEx GroundUPS Next Day AirDHL Express
	Zahlungsziel PaymentDueDate	Das Datum, bis zu dem der Kunde die Rechnung bezahlen muss.
Beschreibung Das Zahlungsziel wird anhand des Rechnungsdatums und der mit dem Kunden vereinbarten Zahlungsbedingungen berechnet. Es ist auf der Kundenrechnung gespeichert. Dieses Attribut ist eine wichtige Grundlage für die Analyse „Einhaltung des Zahlungsziels“ und die KPI „Quote pünktlicher Zahlungen“. Durch den Vergleich von „PaymentDueDate“ mit dem tatsächlichen Datum der Aktivität „Zahlung eingegangen“ kann das Unternehmen verspätete Zahlungen erkennen, das Zahlungsverhalten nach Kundensegment analysieren und gezielt den Cashflow verbessern sowie die Außenstandsdauer von Forderungen (Days Sales Outstanding) verringern. Warum das wichtig ist Dient als Vergleichswert für die Messung der Zahlungsleistung. Das ist wichtig, um den Cashflow zu analysieren und Forderungen effektiv zu verwalten. Woher beziehen Befindet sich in der Tabelle „CustInvoiceJour“ im Feld „DueDate“. Beispiele 2023-05-302023-06-152023-06-30

Erforderlich Empfohlen Optional

Aktivitäten für Order to Cash – Auftragsabwicklung

Dies sind die zentralen Prozessschritte und wichtigen Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um Ihre Auftragsabwicklung zuverlässig zu entdecken und zu analysieren.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Auftrag abgeschlossen	Der Abschlussstatus eines erfolgreich bearbeiteten Vertriebsauftrags zeigt an, dass der Auftrag vollständig versandt und fakturiert wurde und keine weiteren Transaktionen zu erwarten sind. Damit ist der Prozess erfolgreich abgeschlossen.
Warum das wichtig ist Diese Aktivität ist der zentrale Endpunkt erfolgreich abgeschlossener Cases. Sie ist wichtig für die Berechnung der End-to-End-Durchlaufzeit und des Durchsatzes. Woher beziehen Der Abschluss wird aus den Statusfeldern der SalesTable abgeleitet. Ein Auftrag gilt als abgeschlossen, wenn der „Sales status“ und die Status aller Positionen auf „Invoiced“ stehen. Erfassung Aus einer Änderung der Statusfelder in der SalesTable auf „Invoiced“ ableiten. Als Timestamp dient üblicherweise das Datum der letzten zugehörigen Transaktion, etwa der Rechnungsstellung oder Zahlung. Ereignistyp inferred
	Auftrag bestätigt	Diese Aktivität kennzeichnet die formelle Bestätigung des Vertriebsauftrags und die verbindliche Zusage, die angegebenen Waren oder Dienstleistungen zu liefern. In Dynamics 365 löst eine explizite Benutzeraktion die Erstellung eines Bestätigungsjournals aus.
Warum das wichtig ist Die Bestätigung ist ein wichtiger Meilenstein und markiert den offiziellen Beginn der Auftragsabwicklung. Die Zeit von der Erstellung bis zur Bestätigung zeigt, wie effizient die Bearbeitung im Vertriebsinnendienst ist. Woher beziehen Dieses explizite Ereignis wird anhand des Buchungsdatums des Journals zur Vertriebsauftragsbestätigung (SalesConfirmJour) erfasst. Der Timestamp lässt sich der SalesTable zuordnen. Erfassung Buchungs-Timestamp des Journals zur Vertriebsauftragsbestätigung erfassen. Ereignistyp explicit
	Rechnung erstellt	Dieses Ereignis kennzeichnet die Erstellung und Buchung der Verkaufsrechnung für die versandten Waren oder erbrachten Dienstleistungen. Als zentrale Finanztransaktion erfasst sie die Forderung gegenüber dem Kunden.
Warum das wichtig ist Diese Aktivität markiert den Beginn der finanziellen Abwicklung. Die Zeit zwischen Versand und Rechnungserstellung ist entscheidend für die KPI „Durchlaufzeit der Rechnungserstellung“ und wirkt sich auf den Cashflow aus. Woher beziehen Dies ist eine explizite Finanztransaktion. Das Ereignis wird anhand von Datum und Uhrzeit der Buchung des Verkaufsrechnungsjournals (CustInvoiceJour) erfasst. Erfassung Buchungs-Timestamp des Verkaufsrechnungsjournals erfassen. Ereignistyp explicit
	Vertriebsauftrag erstellt	Dieses Ereignis kennzeichnet die erstmalige Erfassung eines Vertriebsauftrags im System, entweder durch einen Vertriebsmitarbeitenden oder über einen automatisierten Kanal. Es wird explizit erfasst, wenn ein neuer Datensatz in der zentralen Tabelle für Vertriebsaufträge angelegt und gespeichert wird.
Warum das wichtig ist Diese Aktivität ist der gemeinsame Startpunkt aller Vertriebsauftrags-Cases. Ihr Timestamp dient als Ausgangspunkt für die Berechnung der gesamten Durchlaufzeit des Vertriebsauftrags und die Analyse des Durchsatzes. Woher beziehen Dieses explizite Ereignis wird aus dem Feld „Created date and time“ des Kopfsatzes in der Tabelle SalesTable erfasst. Erfassung Erstellungs-Timestamp aus der Entität SalesTable auslesen. Ereignistyp explicit
	Waren versandt	Dieses Ereignis zeigt an, dass die verpackten Waren des Auftrags versandt wurden und das Lager verlassen haben. In Dynamics 365 wird der Versand durch die Buchung des Lieferscheins dokumentiert.
Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende der internen Auftragsabwicklung und den Beginn der Lieferphase. Der Timestamp ist eine zentrale Grundlage für die Berechnung der Pünktlichkeit des Versands. Woher beziehen Dieses eindeutige, explizite Ereignis wird anhand von Datum und Uhrzeit der Buchung des Lieferscheinjournals (CustPackingSlipJour) erfasst. Erfassung Buchungs-Timestamp des Lieferscheinjournals erfassen. Ereignistyp explicit
	Zahlung eingegangen	Diese Aktivität zeigt an, dass die Zahlung des Kunden für die Rechnung eingegangen und zugeordnet wurde. Das Ereignis tritt im Debitorenmodul auf und ist mit der ursprünglichen Rechnung verknüpft.
Warum das wichtig ist Dieser wichtige Meilenstein ist für die Analyse des Cash Conversion Cycle entscheidend. Er ist die Grundlage für die Messung der KPI „Anteil pünktlicher Zahlungen“ und hilft, Verzögerungen beim Zahlungseingang zu erkennen. Woher beziehen Dieses explizite Ereignis stammt aus dem Debitorenmodul. Es wird anhand des Buchungsdatums des Zahlungsausgleichs des Kunden (CustSettlement) erfasst, durch den die Rechnungstransaktion (CustTrans) ausgeglichen wird. Erfassung Aus der Tabelle CustSettlement das Ausgleichsdatum erfassen und mit der Rechnung und dem Vertriebsauftrag verknüpfen. Ereignistyp explicit
	An Lager freigegeben	Kennzeichnet den Zeitpunkt, zu dem der Vertriebsauftrag offiziell für Kommissionierung und Versand an das Lager freigegeben wird. Dieser Schritt ist in Umgebungen mit dem Warehouse-Management-Modul (WMS) eindeutig erkennbar.
Warum das wichtig ist Diese Aktivität trennt die Auftragsbearbeitung von der physischen Auftragsabwicklung. Die Analyse der Wartezeit bis zur Freigabe kann Probleme bei der Ressourcenplanung oder Systemintegration aufdecken. Woher beziehen Dieses explizite Ereignis wird aus den Lagerfreigabedatensätzen (WHSLoadTable, WHSShipmentTable) erfasst, die dem Vertriebsauftrag zugeordnet sind. Erfassung Erstellungs-Timestamp der zugehörigen Lagerladung oder Sendung erfassen. Ereignistyp explicit
	Auftrag storniert	Dieses Ereignis kennzeichnet die Stornierung eines Vertriebsauftrags, bevor er vollständig versandt und fakturiert wurde. Es ist ein alternativer, nicht erfolgreicher Prozessabschluss.
Warum das wichtig ist Die Erfassung von Stornierungen hilft, Gründe für verlorene Verkäufe oder Prozessfehler zu erkennen. Die Analyse, wann und warum Aufträge storniert werden, kann zu Prozessverbesserungen beitragen. Woher beziehen Das Ereignis wird aus einer Änderung des Felds „Sales status“ in der SalesTable auf „Canceled“ abgeleitet. Als Timestamp dient der Zeitpunkt, zu dem diese Statusänderung protokolliert wurde. Erfassung Aus einer Änderung des Statusfelds in der SalesTable auf „Canceled“ ableiten. Ereignistyp inferred
	Bestand reserviert	Dieses Ereignis zeigt an, dass der für die Vertriebsauftragspositionen benötigte Bestand im System physisch oder automatisch reserviert wurde. Damit stehen die Artikel für Kommissionierung und Auftragsabwicklung bereit.
Warum das wichtig ist Die Erfassung der Bestandsreservierung hilft, Verzögerungen zwischen Auftragsbestätigung und Beginn der Lagerprozesse zu analysieren. Sie ist eine wichtige Grundlage für die KPI „Vorlaufzeit der Bestandszuweisung“. Woher beziehen Das Ereignis lässt sich aus dem Anlegen oder Aktualisieren von Bestandsbuchungen (InventTrans) ableiten, die den Vertriebsauftragspositionen zugeordnet sind. Der Status zeigt dabei eine Reservierung an, zum Beispiel „On order“ oder „Reserved physical“. Erfassung Aus dem Timestamp ableiten, zu dem die Bestandsbuchungen (InventTrans) des Auftrags als reserviert gekennzeichnet werden. Ereignistyp inferred
	Bonitätsprüfung durchgeführt	Diese Aktivität kennzeichnet den Abschluss einer Bonitätsprüfung für den Kunden des Vertriebsauftrags. Dabei kann es sich um eine automatisierte Systemprüfung oder eine manuelle Prüfung handeln. Häufig ändert sich dadurch der Kreditstatus des Auftrags.
Warum das wichtig ist Die Analyse von Dauer und Ergebnissen der Bonitätsprüfungen hilft, Engpässe im Auftragsfreigabeprozess zu erkennen. Häufige Sperren oder lange Freigabezeiten können die Auftragsabwicklung erheblich verzögern. Woher beziehen Das Ereignis wird üblicherweise aus Änderungen des Kreditmanagementstatus in der SalesTable abgeleitet, etwa wenn ein Auftrag mit einem Kreditgrund von „On hold“ auf „Open“ wechselt. Bei Verwendung des erweiterten Moduls kann das Ereignis auch in Tabellen des Kreditmanagements protokolliert sein. Erfassung Aus dem Änderungsverlauf des Status in der SalesTable oder aus zugehörigen Tabellen zu Kreditsperren ableiten. Ereignistyp inferred
	Waren geliefert	Zeigt an, dass die Sendung erfolgreich an die vom Kunden angegebene Adresse geliefert wurde. Diese Information wird häufig aus dem System eines externen Frachtführers übernommen oder manuell bestätigt.
Warum das wichtig ist Diese Aktivität ist wichtig, um die KPI „Termintreue bei Lieferungen“ zu messen und die tatsächliche, für den Kunden relevante Durchlaufzeit zu ermitteln. Sie hilft außerdem, die Leistung der Frachtführer zu bewerten. Woher beziehen In D365 wird dieses Ereignis standardmäßig nicht explizit erfasst. Üblicherweise wird es aus einer Aktualisierung durch die Integration mit einem Frachtführer oder einer manuellen Statusänderung am Vertriebsauftrag oder Sendungsdatensatz abgeleitet. Erfassung Aus einer integrierten Datenübermittlung des Frachtführers oder einer manuellen Aktualisierung des Statusfelds ableiten. Ereignistyp inferred
	Waren kommissioniert	Diese Aktivität kennzeichnet den Abschluss der physischen Kommissionierung aller Artikel des Auftrags an ihren Lagerplätzen. Üblicherweise wird sie erfasst, wenn ein Kommissionierer eine Kommissionierliste oder einen Arbeitsauftrag im WMS-Modul abschließt.
Warum das wichtig ist Die Erfassung der Kommissionierdauer ist wichtig für die Analyse der Lagereffizienz. Verzögerungen in dieser Phase wirken sich unmittelbar auf die gesamte Versanddauer aus. Woher beziehen Dieses explizite Ereignis wird im Warehouse-Management-Modul erfasst. Als Grundlage dient der Abschluss-Timestamp des Lagerarbeitsauftrags (WHSWorkTable), der mit der Kommissionierung des Vertriebsauftrags verknüpft ist. Erfassung Timestamp erfassen, zu dem der Status „Work“ der Kommissionierung auf „Closed“ gesetzt wird. Ereignistyp explicit
	Waren verpackt	Diese Aktivität kennzeichnet den Abschluss der Verpackung. Dabei werden die kommissionierten Artikel zusammengefasst und für den Versand vorbereitet. In D365 kann dies mit der Erstellung eines Lieferscheins zusammenfallen.
Warum das wichtig ist Die Zeit zwischen Kommissionierung und Verpackung kann Engpässe an den Packstationen sichtbar machen. Sie ist ein wichtiger Teil der gesamten Durchlaufzeit der Auftragsabwicklung. Woher beziehen Das Ereignis kann explizit beim Abschluss der Verpackung eines Containers im WMS-Modul erfasst oder aus der Erstellung des Lieferscheinjournals (CustPackingSlipJour) abgeleitet werden, die häufig das Ende der Verpackung kennzeichnet. Erfassung Aus dem Abschluss der Verpackungsarbeit oder dem Erstellungsdatum des Lieferscheinjournals ableiten. Ereignistyp inferred

Anleitungen zur Datenextraktion

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Richten Sie den Export in Azure Data Lake ein: Stellen Sie in Ihrer Dynamics-365-Finance-and-Operations-Umgebung sicher, dass das Add-in „Export to Azure Data Lake“ installiert und konfiguriert ist. Dazu verknüpfen Sie D365 mit einem Azure-Abonnement und einem Azure-Data-Lake-Storage-Gen2-Zielkonto.
Wählen Sie die zu exportierenden Tabellen aus: Öffnen Sie in Dynamics 365 den Arbeitsbereich „Export to Data Lake“. Suchen Sie die folgenden Tabellen und fügen Sie sie der Exportkonfiguration hinzu: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable und CustTable. Aktivieren Sie den Export für alle ausgewählten Tabellen.
Richten Sie Azure Synapse Analytics ein: Stellen Sie im Azure-Portal einen Azure-Synapse-Analytics-Arbeitsbereich bereit. Erteilen Sie diesem Arbeitsbereich die erforderlichen Berechtigungen, zum Beispiel „Storage Blob Data Contributor“, für das Data-Lake-Konto, in dem die D365-Daten gespeichert sind.
Erstellen Sie eine serverlose SQL-Datenbank: Öffnen Sie in Synapse Studio den Bereich „Data“. Erstellen Sie eine neue serverlose SQL-Datenbank, um über eine T-SQL-Abfrageschnittstelle auf die Daten in Ihrem Data Lake zuzugreifen.
Erstellen Sie Views für D365-Tabellen: Erstellen Sie SQL-Views in Ihrer serverlosen Datenbank, die auf die replizierten D365-Tabellendaten im Data Lake verweisen. So müssen Sie die zugrunde liegenden Dateipfade und Formate nicht direkt berücksichtigen. Beispiel: CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
Bereiten Sie die SQL-Abfrage vor: Öffnen Sie in Synapse Studio ein neues SQL-Skript und stellen Sie eine Verbindung zu Ihrer serverlosen Datenbank her. Kopieren Sie die vollständige SQL-Abfrage aus dieser Dokumentation in den Skripteditor.
Passen Sie die Abfrageparameter an: Suchen Sie die Platzhalter am Anfang der Abfrage. Ersetzen Sie '{YourDataAreaId}' durch den Unternehmenscode, den Sie analysieren möchten. Legen Sie für den gewünschten Extraktionszeitraum die Werte für '{StartDate}' und '{EndDate}' fest.
Führen Sie die Abfrage aus: Führen Sie das vollständige SQL-Skript aus. Die Abfrage sammelt Ereignisse aus verschiedenen Tabellen und führt sie in einem einheitlichen Event-Log-Format zusammen.
Prüfen und exportieren Sie die Ergebnisse: Prüfen Sie nach Abschluss der Abfrage im Ergebnisbereich von Synapse Studio, ob die Ergebnisse vollständig und korrekt formatiert sind. Speichern Sie sie über die integrierte Exportfunktion als CSV-Datei.
Bereiten Sie den Upload vor: Öffnen Sie die exportierte CSV-Datei und prüfen Sie, ob sie UTF-8-codiert ist. Vergewissern Sie sich, dass die Spaltenüberschriften genau den erforderlichen Attributen entsprechen, zum Beispiel SalesOrderNumber, ActivityName und EventTime.
Laden Sie die Daten in ProcessMind hoch: Laden Sie die finale, geprüfte CSV-Datei in Ihr ProcessMind-Projekt hoch, um sie zu analysieren und zu visualisieren.

Konfiguration

Voraussetzungen: Für diese Methode benötigen Sie ein aktives Azure-Abonnement und das Add-in „Export to Azure Data Lake“, das für Ihre Dynamics-365-F&O-Instanz konfiguriert ist. Sie benötigen außerdem die entsprechenden Berechtigungen in Azure für die Verwaltung von Synapse und Storage sowie in D365 für die Konfiguration von Datenexporten.
Erforderliche D365-Module: Für die vollständige Erfassung von Ereignissen, insbesondere bei Lageraktivitäten, ist das Modul Warehouse Management (WMS) erforderlich. Zentrale Ereignisse stammen aus den Modulen Sales and Marketing und Accounts Receivable.
Tabellenauswahl: Aktivieren Sie den Export unbedingt für alle in der Abfrage referenzierten Tabellen: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable und CustTable. Fehlen Tabellen, werden auch Aktivitäten nicht erfasst.
Filter für den Datumsbereich: Die Abfrage verwendet die Parameter {StartDate} und {EndDate}, um den Datumsbereich einzugrenzen. Für die erste Extraktion empfiehlt sich ein begrenzter Zeitraum, etwa 3 bis 6 Monate, damit die Abfrage in einer angemessenen Zeit ausgeführt werden kann.
Filter für das Unternehmen (DataAreaId): Konfigurieren Sie den Platzhalter '{YourDataAreaId}' für eine bestimmte rechtliche Einheit in Ihrer D365-Umgebung. Die Abfrage ist nicht dafür ausgelegt, mehrere Unternehmen in einem einzigen Durchlauf zu analysieren.
Leistungsaspekte: Bei sehr großen Datenmengen kann die Abfrageleistung in einem serverlosen SQL-Pool variieren. Planen Sie die Extraktion gegebenenfalls für Zeiten mit geringerer Auslastung. Bei häufigen Extraktionen können Sie das finale Event Log als neue Tabelle im Data Lake materialisieren, um die nachgelagerte Verarbeitung zu beschleunigen.

Beispielabfrage sql

WITH SalesOrderBase AS (
    SELECT
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME AS CustomerName,
        ST.SHIPPINGDATECONFIRMED AS ConfirmedDeliveryDate,
        ST.DELIVERYDATE AS RequestedDeliveryDate,
        ST.PURCHORDERFORMNUM AS SalesChannel, -- Example mapping, adjust if you use a different field for Sales Channel
        SUM(SL.LINEAMOUNT) AS OrderValue
    FROM dbo.SALESTABLE ST
    LEFT JOIN dbo.SALESLINE SL ON ST.SALESID = SL.SALESID AND ST.DATAREAID = SL.DATAREAID
    LEFT JOIN dbo.CUSTTABLE CT ON ST.CUSTACCOUNT = CT.ACCOUNTNUM AND ST.DATAREAID = CT.DATAREAID
    WHERE ST.DATAREAID = '{YourDataAreaId}'
      AND ST.CREATEDDATETIME >= '{StartDate}' AND ST.CREATEDDATETIME < '{EndDate}'
    GROUP BY
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME,
        ST.SHIPPINGDATECONFIRMED,
        ST.DELIVERYDATE,
        ST.PURCHORDERFORMNUM
)
-- 1. Sales Order Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Sales Order Created' AS ActivityName,
    ST.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID

UNION ALL

-- 2. Credit Check Performed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Credit Check Performed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime, -- This assumes a status change date reflects the credit check time
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.CREDITLIMITTYPE > 0 -- Example condition for a credit check being done. Adjust based on your configuration.

UNION ALL

-- 3. Order Confirmed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Confirmed' AS ActivityName,
    CJ.CONFIRMDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTCONFIRMJOUR CJ ON SO.SALESID = CJ.SALESID AND SO.DATAREAID = CJ.DATAAREAID

UNION ALL

-- 4. Inventory Reserved (approximated by first line item reservation)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Inventory Reserved' AS ActivityName,
    MIN(SL.CREATEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESLINE SL ON SO.SALESID = SL.SALESID AND SO.DATAREAID = SL.DATAREAID
WHERE SL.RESERVATION > 0 -- Identifies lines with a reservation status
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 5. Released To Warehouse
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Released To Warehouse' AS ActivityName,
    WLT.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSLOADTABLE WLT ON SO.SALESID = WLT.SALESID AND SO.DATAREAID = WLT.DATAAREAID

UNION ALL

-- 6. Goods Picked (approximated by last pick work closure)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Picked' AS ActivityName,
    MAX(WWT.MODIFIEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSWORKTABLE WWT ON SO.SALESID = WWT.ORDERNUM AND SO.DATAREAID = WWT.DATAAREAID
WHERE WWT.WORKTYPE = 'Pick' AND WWT.WORKSTATUS = 'Closed'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 7. Goods Packed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Packed' AS ActivityName,
    PSJ.CREATEDDATETIME AS EventTime, -- Using creation time of packing slip as proxy
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 8. Goods Shipped
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Shipped' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 9. Goods Delivered (placeholder, often requires custom fields)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Delivered' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime, -- Placeholder, using shipment date. True delivery requires external data.
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID
WHERE 1 = 2 -- This will return no rows unless logic is added to read from a custom field with actual delivery dates

UNION ALL

-- 10. Invoice Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Invoice Created' AS ActivityName,
    CIJ.INVOICEDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID

UNION ALL

-- 11. Payment Received (approximated by last settlement date)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Payment Received' AS ActivityName,
    MAX(CT.SETTLEMENTDATE) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID
JOIN dbo.CUSTTRANS CT ON CIJ.INVOICEID = CT.INVOICE AND CIJ.DATAAREAID = CT.DATAAREAID
WHERE CT.TRANSTYPE = 'Payment'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 12. Order Closed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Closed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 4 -- Status for 'Invoiced'

UNION ALL

-- 13. Order Cancelled
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Cancelled' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 3; -- Status for 'Canceled'

Schritte

Voraussetzungen und Einrichtung: Installieren Sie Python 3.6 oder höher. Installieren Sie die erforderlichen Python-Bibliotheken, indem Sie im Terminal folgenden Befehl ausführen: pip install pandas requests msal.
Registrieren Sie eine Anwendung in Azure AD: Registrieren Sie im Azure-Portal unter Azure Active Directory eine neue Anwendung. Diese Anwendung dient der Authentifizierung bei der Dynamics-365-API. Notieren Sie sich die Application (client) ID und die Directory (tenant) ID.
Erstellen Sie ein Client Secret: Erstellen Sie in Ihrer neu registrierten Azure-AD-Anwendung unter „Certificates & secrets“ ein neues Client Secret. Kopieren Sie den Wert sofort, da er später nicht mehr angezeigt wird. Dies ist Ihr CLIENT_SECRET.
Erteilen Sie API-Berechtigungen: Öffnen Sie in den Einstellungen der Azure-AD-Anwendung den Bereich „API permissions“. Fügen Sie eine Berechtigung für „Dynamics ERP“ oder „Dynamics 365 for Finance and Operations“ hinzu. Wählen Sie „Delegated permissions“ und erteilen Sie user_impersonation. Fügen Sie anschließend dieselbe Berechtigung erneut hinzu, wählen Sie diesmal „Application permissions“ und erteilen Sie Financials.ReadWrite.All oder, falls verfügbar und ausreichend, eine stärker eingeschränkte Leseberechtigung. Erteilen Sie für diese Berechtigungen die Administratorzustimmung.
Erstellen Sie einen Anwendungsbenutzer in Dynamics 365: Öffnen Sie in Ihrer Dynamics-365-Umgebung „System administration“ > „Users“ > „Users“. Erstellen Sie einen Benutzer und verknüpfen Sie ihn mit der Application ID Ihrer Azure-AD-App-Registrierung. Weisen Sie ihm eine Sicherheitsrolle zu, etwa „System administrator“ für Vollzugriff oder eine benutzerdefinierte Rolle mit Lesezugriff auf die erforderlichen Datenentitäten (SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders, SalesInvoiceHeadersV2 usw.).
Konfigurieren Sie das Python-Skript: Öffnen Sie das bereitgestellte Python-Skript in einem Editor. Ersetzen Sie im Konfigurationsabschnitt am Anfang der Datei die Platzhalterwerte für D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE und END_DATE durch die Angaben zu Ihrer Umgebung.
Legen Sie optional Entitätszuordnungen fest: Prüfen Sie die im Skript verwendeten Entitäts- und Feldnamen. Wenn Ihr Unternehmen angepasste Entitäten oder Felder verwendet, um bestimmte Aktivitäten nachzuverfolgen, müssen Sie möglicherweise die OData-Abfragen im Skript entsprechend anpassen.
Führen Sie das Extraktionsskript aus: Starten Sie das Skript über die Befehlszeile mit dem Befehl python your_script_name.py. Das Skript authentifiziert sich, fragt die Dynamics-365-OData-API zu jeder Aktivität ab und verarbeitet die Daten. Den Fortschritt sehen Sie in der Konsole.
Prüfen Sie die Ausgabedatei: Nach erfolgreicher Ausführung erstellt das Skript im selben Verzeichnis eine CSV-Datei mit dem Namen d365_order_to_cash_event_log.csv. Öffnen Sie die Datei und prüfen Sie, ob das extrahierte Event Log korrekt und vollständig ist.
Laden Sie die Daten in ProcessMind hoch: Die erstellte CSV-Datei entspricht dem erforderlichen Schema und kann direkt in ProcessMind hochgeladen werden, um den Prozess zu analysieren.

Konfiguration

D365_URL: Die Basis-URL Ihrer Dynamics-365-Finance-and-Operations-Umgebung. Sie hat beispielsweise das Format https://[your-d365-environment-name].operations.dynamics.com.
TENANT_ID: Die Directory (tenant) ID Ihrer Azure-Active-Directory-Instanz. Sie finden sie auf der Übersichtsseite Ihrer Azure-AD-App-Registrierung.
CLIENT_ID: Die Application (client) ID der Anwendung, die Sie in Azure AD registriert haben.
CLIENT_SECRET: Der Wert des Client Secret, das Sie für die Azure-AD-Anwendung erstellt haben.
COMPANY_FILTER: Gibt die rechtliche Einheit in Dynamics 365 an, aus der Daten extrahiert werden sollen, zum Beispiel 'USMF'. Dieser Pflichtfilter stellt sicher, dass Sie die Daten des richtigen Unternehmens abfragen.
START_DATE / END_DATE: Legt den Extraktionszeitraum im Format 'YYYY-MM-DD' fest. Für die erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenmenge und Erkenntnisgewinn auszubalancieren. Beachten Sie, dass ein großer Datumsbereich die Extraktionsdauer deutlich verlängern kann.
Voraussetzungen: Sie benötigen Zugriff auf Azure AD, um eine Anwendung zu registrieren und Berechtigungen zu erteilen. Außerdem ist ein Dynamics-365-Benutzerkonto erforderlich, mit dem Sie einen Anwendungsbenutzer erstellen und Sicherheitsrollen zuweisen können. Die zugewiesene Rolle muss Lesezugriff auf alle vom Skript abgefragten Entitäten haben.

Beispielabfrage python

import requests
import pandas as pd
import msal
import json
import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your D365 environment and Azure AD App details
D365_URL = class="hl-string">"https://[your-d365-environment-name].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your-Azure-AD-Tenant-ID]"
CLIENT_ID = class="hl-string">"[Your-Azure-AD-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Azure-AD-Client-Secret]"

class=class="hl-string">"hl-comment"># --- EXTRACTION PARAMETERS ---
COMPANY_FILTER = class="hl-string">"[Your-Company-Code]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SCRIPT --- 

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

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD and returns an access token."""
    app = msal.ConfidentialClientApplication(
        client_id=CLIENT_ID,
        client_credential=CLIENT_SECRET,
        authority=AUTHORITY_URL
    )
    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"))
        raise Exception(class="hl-string">"Could not authenticate.")

def execute_odata_query(access_token, entity, select_fields, filter_query, expand_fields=None):
    class="hl-string">"""Executes an OData query against a D365 entity and handles pagination."""
    all_results = []
    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.maxpagesize=1000' class=class="hl-string">"hl-comment"># Request pagination
    }
    
    query_url = fclass="hl-string">"{API_ENDPOINT}/{entity}?$select={select_fields}&$filter={filter_query}&cross-company=true"
    if expand_fields:
        query_url += fclass="hl-string">"&$expand={expand_fields}"
    
    print(fclass="hl-string">"Querying {entity}...")
    while query_url:
        try:
            response = requests.get(query_url, headers=headers)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_results.extend(data.get(class="hl-string">'value', []))
            query_url = data.get(class="hl-string">'@odata.nextLink') class=class="hl-string">"hl-comment"># Get URL for the next page
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error for {entity}: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            return [] class=class="hl-string">"hl-comment"># Return empty list on error
        except json.JSONDecodeError:
            print(fclass="hl-string">"JSON Decode Error for {entity}. Response was not valid JSON.")
            print(fclass="hl-string">"Response text: {response.text}")
            return []

    print(fclass="hl-string">"...found {len(all_results)} records for {entity}.")
    return all_results

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    try:
        token = get_access_token()
    except Exception as e:
        print(e)
        return

    all_events = []
    now_utc = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for most queries
    base_select_fields = class="hl-string">"SalesOrderNumber,TotalInvoiceAmount,SalesOrderOriginCode,RequestedShippingDate,ConfirmedShippingDate,CustomerAccount"
    base_expand_fields = class="hl-string">"CustomerV3(CustomerName)"

    class=class="hl-string">"hl-comment"># Common date filter for creation/modification timestamps
    date_filter = fclass="hl-string">"(CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z)"

    class=class="hl-string">"hl-comment"># 1. Sales Order Created
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},CreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {date_filter}", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Created',
            class="hl-string">'EventTime': record.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 2. Credit Check Performed (based on status change)
    class=class="hl-string">"hl-comment"># This assumes a credit check is reflected by the CreditLimitApprovalStatus. This logic may need adjustment.
    class=class="hl-string">"hl-comment"># We look for orders modified in the period, then check the status.
    modified_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},ModifiedDateTime,CreditLimitApprovalStatus", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {modified_date_filter} and CreditLimitApprovalStatus ne 'NoCheck'", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Credit Check Performed',
            class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime'), class=class="hl-string">"hl-comment"># Using ModifiedDateTime as a proxy
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 3. Order Confirmed
    confirmation_date_filter = fclass="hl-string">"(ConfirmationDate ge {START_DATE} and ConfirmationDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesConfirmationHeaders', class="hl-string">"SalesOrderNumber,ConfirmationDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {confirmation_date_filter}")
    class=class="hl-string">"hl-comment"># We need to get details from the SalesOrderHeader
    order_numbers = class="hl-string">"'" + class="hl-string">"','".join([rec[class="hl-string">'SalesOrderNumber'] for rec in data if rec.get(class="hl-string">'SalesOrderNumber')]) + class="hl-string">"'"
    if order_numbers != class="hl-string">"''":
        header_data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', base_select_fields, fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({order_numbers})", base_expand_fields)
        header_map = {h[class="hl-string">'SalesOrderNumber']: h for h in header_data}
        for record in data:
            header = header_map.get(record.get(class="hl-string">'SalesOrderNumber'))
            if header:
                all_events.append({
                    class="hl-string">'SalesOrderNumber': header.get(class="hl-string">'SalesOrderNumber'),
                    class="hl-string">'ActivityName': class="hl-string">'Order Confirmed',
                    class="hl-string">'EventTime': str(record.get(class="hl-string">'ConfirmationDate')) + class="hl-string">'T12:00:00Z', class=class="hl-string">"hl-comment"># Date only field, adding midday time
                    class="hl-string">'OrderValue': header.get(class="hl-string">'TotalInvoiceAmount'),
                    class="hl-string">'CustomerName': header.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
                    class="hl-string">'SalesChannel': header.get(class="hl-string">'SalesOrderOriginCode'),
                    class="hl-string">'RequestedDeliveryDate': header.get(class="hl-string">'RequestedShippingDate'),
                    class="hl-string">'ConfirmedDeliveryDate': header.get(class="hl-string">'ConfirmedShippingDate')
                })
    
    class=class="hl-string">"hl-comment"># 4 & 5. Inventory Reserved & Released To Warehouse (WMS)
    class=class="hl-string">"hl-comment"># These are complex. This is a proxy based on Warehouse Work creation time.
    work_date_filter = fclass="hl-string">"(WorkCreatedDateTime ge {START_DATE}T00:00:00Z and WorkCreatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WarehouseWorkHeaders', class="hl-string">"OrderNumber,WorkCreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {work_date_filter} and WorkType eq 'SalesOrders'")
    for record in data:
        class=class="hl-string">"hl-comment"># Assuming reservation happens just before release to warehouse
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Inventory Reserved', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Released To Warehouse', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})

    class=class="hl-string">"hl-comment"># 6 & 7. Goods Picked & Goods Packed (WMS)
    class=class="hl-string">"hl-comment"># Proxy using Shipment status updates. This logic may need refinement based on specific WMS setup.
    shipment_date_filter = fclass="hl-string">"(ShipmentStatusLastUpdatedDateTime ge {START_DATE}T00:00:00Z and ShipmentStatusLastUpdatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WHSShipmentTables', class="hl-string">"SalesOrderNumber,ShipmentStatus,ShipmentStatusLastUpdatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {shipment_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Picked', class="hl-string">'Loaded', class="hl-string">'Shipped']:
             all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Picked', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Loaded', class="hl-string">'Shipped']:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Packed', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})

    class=class="hl-string">"hl-comment"># 8. Goods Shipped (Posting Packing Slip)
    packslip_date_filter = fclass="hl-string">"(ShippingDate ge {START_DATE} and ShippingDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ShippingDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Shipped', class="hl-string">'EventTime': str(record.get(class="hl-string">'ShippingDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 9. Goods Delivered
    class=class="hl-string">"hl-comment"># This is often not a standard field. We use ModifiedDateTime on Packing Slip as a placeholder.
    packslip_mod_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ModifiedDateTime,DeliveryMode", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_mod_date_filter} and DeliveryMode eq '[Your-Delivered-Status-Code]'")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Delivered', class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})

    class=class="hl-string">"hl-comment"># 10. Invoice Created
    invoice_date_filter = fclass="hl-string">"(InvoiceDate ge {START_DATE} and InvoiceDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesInvoiceHeadersV2', class="hl-string">"SalesOrderNumber,InvoiceDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': str(record.get(class="hl-string">'InvoiceDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 11. Payment Received
    class=class="hl-string">"hl-comment"># This requires looking at customer payments and settling them to invoices, then to sales orders.
    class=class="hl-string">"hl-comment"># This is a simplified proxy using the ClosedDate of the invoice.
    invoice_closed_date_filter = fclass="hl-string">"(ClosedDate ge {START_DATE} and ClosedDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'CustomerInvoices', class="hl-string">"SalesOrderNumber,ClosedDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_closed_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ClosedDate') and record.get(class="hl-string">'SalesOrderNumber'):
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Received', class="hl-string">'EventTime': str(record.get(class="hl-string">'ClosedDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 12 & 13. Order Closed & Order Cancelled
    class=class="hl-string">"hl-comment"># These are statuses on the Sales Order Header.
    status_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', class="hl-string">"SalesOrderNumber,SalesOrderStatus,ModifiedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {status_date_filter} and (SalesOrderStatus eq 'Invoiced' or SalesOrderStatus eq 'Canceled')")
    for record in data:
        activity = class="hl-string">''
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Invoiced': activity = class="hl-string">'Order Closed'
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Canceled': activity = class="hl-string">'Order Cancelled'
        if activity:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})


    class=class="hl-string">"hl-comment"># --- Final Processing ---
    if not all_events:
        print(class="hl-string">"No events found. Exiting.")
        return

    df = pd.DataFrame(all_events)
    print(fclass="hl-string">"Total events created: {len(df)}")

    class=class="hl-string">"hl-comment"># Drop events without a case ID or timestamp
    df.dropna(subset=[class="hl-string">'SalesOrderNumber', class="hl-string">'EventTime'], inplace=True)
    print(fclass="hl-string">"Events after dropping nulls: {len(df)}")

    class=class="hl-string">"hl-comment"># Fill in missing recommended attributes by merging back header details
    print(class="hl-string">"Enriching data with header attributes...")
    unique_orders = class="hl-string">"'" + class="hl-string">"','".join(df[class="hl-string">'SalesOrderNumber'].unique()) + class="hl-string">"'"
    if unique_orders != class="hl-string">"''":
        header_data_final = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields}", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({unique_orders})", base_expand_fields)
        header_df = pd.DataFrame(header_data_final)
        if not header_df.empty:
            header_df = header_df.rename(columns={
                class="hl-string">'TotalInvoiceAmount': class="hl-string">'OrderValue',
                class="hl-string">'SalesOrderOriginCode': class="hl-string">'SalesChannel',
                class="hl-string">'RequestedShippingDate': class="hl-string">'RequestedDeliveryDate',
                class="hl-string">'ConfirmedShippingDate': class="hl-string">'ConfirmedDeliveryDate'
            })
            class=class="hl-string">"hl-comment"># Extract nested customer name
            header_df[class="hl-string">'CustomerName'] = header_df[class="hl-string">'CustomerV3'].apply(lambda x: x.get(class="hl-string">'CustomerName') if isinstance(x, dict) else None)
            df = df.merge(header_df[[class="hl-string">'SalesOrderNumber', class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']], on=class="hl-string">'SalesOrderNumber', how=class="hl-string">'left', suffixes=(class="hl-string">'', class="hl-string">'_y'))
            class=class="hl-string">"hl-comment"># Fill NaNs from merge
            for col in [class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']:
                if col + class="hl-string">'_y' in df.columns:
                    df[col] = df[col].fillna(df[col + class="hl-string">'_y'])
                    df.drop(columns=[col + class="hl-string">'_y'], inplace=True)

    class=class="hl-string">"hl-comment"># Add required static columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataUpdate'] = now_utc

    class=class="hl-string">"hl-comment"># Ensure required columns exist
    final_cols = [class="hl-string">'SalesOrderNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
                  class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']
    for col in final_cols:
        if col not in df.columns:
            df[col] = None
    
    class=class="hl-string">"hl-comment"># Reorder and save
    df = df[final_cols]
    df.to_csv(class="hl-string">'d365_order_to_cash_event_log.csv', index=False)
    print(class="hl-string">"Successfully created d365_order_to_cash_event_log.csv")

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

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template vor und laden Sie sie anschließend auf unsere Plattform hoch. So gewinnen Sie aussagekräftige Erkenntnisse und verbessern die Effizienz Ihrer Auftragsabwicklung. Beginnen Sie noch heute mit der Optimierung!

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie jetzt Ihre Order-to-Cash-Auftragsabwicklung

Erkennen Sie Ineffizienzen und verkürzen Sie die Durchlaufzeit um 30 %, damit Aufträge schneller erfüllt werden.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für Order to Cash – Auftragsabwicklung

Ihr Daten-Template für Order to Cash – Auftragsabwicklung

Attribute für Order to Cash – Auftragsabwicklung

Aktivitäten für Order to Cash – Auftragsabwicklung

Anleitungen zur Datenextraktion

SQL-Abfrage über Azure Data Lake mit Synapse Analytics

Schritte

Konfiguration

Beispielabfrage sql

Python-Skript mit der Dynamics-365-OData-Web-API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie jetzt Ihre Order-to-Cash-Auftragsabwicklung