> Kontinuierliche Prozessverbesserung > Forderungen aus Lieferungen und Leistungen > Microsoft Dynamics 365 > Daten Template

Ihr Daten-Template für die Debitorenbuchhaltung

Microsoft Dynamics 365

← Zurück zum Leitfaden zur Verbesserung

Attribute der Debitorenbuchhaltung (21) Aktivitäten der Debitorenbuchhaltung (15) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für die Debitorenbuchhaltung

Dieses Template bietet einen umfassenden Rahmen für die Abbildung Ihres Invoice-to-Cash-Prozesses in Microsoft Dynamics 365. Es beschreibt die erforderlichen Datenfelder und Meilensteine, um ein hochwertiges Event Log für Process Mining zu erstellen. Mit dieser Struktur gewinnen Sie detaillierte Erkenntnisse zu Zahlungsverzögerungen und gestalten Ihre Workflows im Forderungseinzug effizienter.

Wichtige Datenfelder für die Analyse der Debitorenbuchhaltung
Standardmeilensteine zur Prozessverfolgung
Technische Anleitung zur Datenextraktion aus Microsoft Dynamics 365

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

Template herunterladen

Attribute der Debitorenbuchhaltung

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie die Leistung Ihrer Debitorenbuchhaltung umfassend analysieren können.

5 Erforderlich 8 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivität Activity	Das konkrete Ereignis oder die Aufgabe, die für die Rechnung ausgeführt wird.
Beschreibung Dieses Attribut beschreibt den jeweiligen Prozessschritt, etwa „Invoice Posted“, „Payment Received“ oder „Dispute Opened“. In Microsoft Dynamics 365 werden diese Werte häufig aus dem Transaktionstyp (TransType) oder aus der Tabelle abgeleitet, in der der Datensatz protokolliert wird, beispielsweise CustSettlement für Zahlungen. Das Attribut ist für die Visualisierung der Prozessdarstellung entscheidend. Warum das wichtig ist Es definiert die Knoten in der Prozessdarstellung und ermöglicht die Analyse des Prozessflusses sowie die Erkennung von Varianten. Bezugsquelle Abgeleitet aus der TransType-Enumeration oder dem Tabellenkontext (CustTrans, CustSettlement usw.) Beispiele Rechnung gebuchtZahlung eingegangenMahnschreiben gesendetZinsbeleg gebucht
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den konkreten Zeitpunkt, zu dem ein Ereignis im System protokolliert wurde. Es dient zur Berechnung der Dauer zwischen Aktivitäten, zur Ermittlung von Prozessdurchlaufzeiten und zur chronologischen Sortierung von Ereignissen. In D365 handelt es sich typischerweise um CreatedDateTime oder TransDate in Verbindung mit einer Zeitangabe. Warum das wichtig ist Timestamps sind für die Berechnung aller zeitbezogenen KPIs entscheidend, etwa der Invoice Cycle Time und der Dispatch Lead Time. Bezugsquelle Häufig die Felder CreatedDateTime oder TransDate in verschiedenen Tabellen Beispiele 2023-10-15T08:30:00Z2023-10-15T14:45:22Z2023-11-01T09:00:00Z
	Rechnungsnummer InvoiceNumber	Die eindeutige Kennung des Finanzdokuments Rechnung.
Beschreibung Die Invoice Number ist der Primärschlüssel zur Nachverfolgung des Lebenszyklus einer Forderung in Microsoft Dynamics 365. Sie verknüpft den ursprünglichen Verkaufsauftrag, die gebuchte Rechnung, nachfolgende Zahlungen und alle Aktivitäten des Forderungseinzugs zu einem einzigen Case. In der Analyse dient dieses Attribut als Case-Kennung, um den vollständigen Prozessablauf zu rekonstruieren. Warum das wichtig ist Sie ist die grundlegende Analyseeinheit der Debitorenbuchhaltung und ermöglicht es der Process-Mining-Engine, unterschiedliche Ereignisse zu einem zusammenhängenden Case zu gruppieren. Bezugsquelle CustInvoiceJour.InvoiceId oder CustTrans.Invoice Beispiele INV-2023-001CIV-88921US-004321DE-99120
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten extrahiert oder aktualisiert wurden.
Beschreibung Dieses Attribut zeigt an, wann die Daten zuletzt aus Microsoft Dynamics 365 abgerufen wurden. Es hilft Ihnen, die Aktualität der Analyse und die Aussagekraft der KPIs einzuschätzen. In der Regel wird es vom Extraktionstool zum Zeitpunkt der Abfrage erzeugt. Warum das wichtig ist Es liefert Kontext zur Datenlatenz und unterstützt das Vertrauen der Nutzer in die Aktualität der Dashboards. Bezugsquelle Vom ETL- oder Extraktionsskript erzeugt Beispiele 2023-11-05T00:00:00Z2023-11-05T12:00:00Z
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Dieses Attribut identifiziert das führende System der Daten, in diesem Kontext Microsoft Dynamics 365. Es ist hilfreich, wenn Daten aus mehreren ERP-Instanzen oder externen Tools für den Forderungseinzug in einer gemeinsamen Ansicht zusammengeführt werden. So können Analysten Prozesse nach ihrer Ursprungsumgebung filtern oder segmentieren. Warum das wichtig ist Es stellt Datenherkunft und Nachvollziehbarkeit sicher, insbesondere in Systemlandschaften mit mehreren Anwendungen. Bezugsquelle Bei der Extraktion fest codiert oder aus der Verbindungszeichenfolge abgeleitet Beispiele D365 F&O ProdD365 FinanceDynamics AX 2012
	Benutzer User	Die Benutzer-ID der Person oder des Systemkontos, die bzw. das die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut identifiziert, wer den jeweiligen Prozessschritt ausgeführt hat. Die Information wird aus den Feldern CreatedBy oder ModifiedBy abgeleitet. Sie unterstützt die Analyse der Ressourcenauslastung, die Ermittlung von Schulungsbedarf sowie die Unterscheidung zwischen automatisierten Systemaufgaben und manuellen Eingriffen durch Benutzer. Warum das wichtig ist Ermöglicht die Analyse der Ressourcenleistung und die Berechnung des Automatisierungsgrads. Bezugsquelle Feld CreatedBy in Transaktionstabellen Beispiele AdministrationJSmithWorkflowAgentBSmith
	Fälligkeitsdatum DueDate	Das Datum, bis zu dem der Zahlungseingang erwartet wird.
Beschreibung Das Fälligkeitsdatum ist die gemäß den Zahlungsbedingungen festgelegte Zahlungsfrist. Es wird mit dem tatsächlichen Zahlungsdatum verglichen, um die termingerechte Zahlung zu bewerten und die Außenstandsdauer (DSO) zu berechnen. Es ist ein Standardfeld im Datensatz der Kundenbuchung. Warum das wichtig ist Grundlage für die Berechnung der Quote termingerechter Zahlungen und die Analyse überfälliger Rechnungen. Bezugsquelle CustTrans.DueDate Beispiele 2023-11-302023-12-15
	Firmencode CompanyCode	Die Kennung der juristischen Einheit innerhalb von D365.
Beschreibung Dieses Attribut bildet die DataAreaId in D365 ab. Sie entspricht der juristischen Einheit oder dem Unternehmen, in dem die Transaktion stattgefunden hat. Das ist für die Filterung von Daten in Umgebungen mit mehreren Unternehmen entscheidend. Außerdem stellt es sicher, dass Rechnungsnummern, die in verschiedenen Unternehmen mehrfach vorkommen können, eindeutig unterschieden werden. Warum das wichtig ist Entscheidend für die Eindeutigkeit in Umgebungen mit mehreren juristischen Einheiten und für regionale Analysen. Bezugsquelle Feld DataAreaId in allen Tabellen Beispiele USMFDEMFGBSI
	Geschäftseinheit BusinessUnit	Die für die Rechnung verantwortliche operative Einheit oder Abteilung.
Beschreibung Dieses Attribut segmentiert Daten nach der internen Organisationsstruktur, etwa nach der Elektroniksparte oder der Servicesparte. In D365 handelt es sich häufig um eine mit der Transaktion verknüpfte Finanzdimension. Es unterstützt das Dashboard zur Durchlaufzeit der Rechnungserstellung, indem Vergleiche zwischen Einheiten möglich werden. Warum das wichtig ist Ermöglicht internes Benchmarking, um die effizientesten Abteilungen zu ermitteln. Bezugsquelle Finanzdimensionen (DefaultDimension) in CustInvoiceJour Beispiele BU-001Vertrieb-NordServices-Global
	Ist automatisiert IsAutomated	Kennzeichen dafür, ob die Aktivität von einem Systemkonto ausgeführt wurde.
Beschreibung Dieses Attribut bestimmt, ob ein bestimmter Schritt von einem Benutzer oder einem automatisierten Batch-Job ausgeführt wurde. Es wird berechnet, indem das Attribut User mit einer Liste bekannter Systemkonten wie „Workflow“ oder „Batch“ verglichen wird. Es unterstützt die KPI zur manuellen Ausgleichsquote. Warum das wichtig ist Entscheidend für die Identifizierung von Automatisierungsmöglichkeiten und die Messung des aktuellen Automatisierungsgrads. Bezugsquelle Abgeleitet aus der Logik des Felds User Beispiele truefalse
	Kundengruppe CustomerGroup	Die Klassifizierung oder das Segment, dem der Kunde angehört.
Beschreibung Dieses Attribut ordnet Kunden logischen Gruppen wie Großhandel, Einzelhandel oder konzerninternen Kunden zu. Es dient der vergleichenden Analyse, etwa um zu prüfen, ob bestimmte Segmente längere Zahlungszyklen oder höhere Streitfallquoten aufweisen. In D365 ist dies das Feld CustGroup. Warum das wichtig ist Ermöglicht den Vergleich der Prozessleistung über verschiedene Marktsegmente hinweg. Bezugsquelle CustTable.CustGroup Beispiele GroßhandelEinzelhandelKonzerninternExport
	Kundenkonto CustomerAccount	Die eindeutige Kennung oder Kontonummer des Kunden.
Beschreibung Das Kundenkonto identifiziert die konkrete Einheit, für die die Rechnung erstellt wird. In D365 entspricht es dem Feld AccountNum. Die Gruppierung nach diesem Attribut ermöglicht die Analyse von Zahlungsverhalten, Häufigkeit von Streitfällen und Verrechnungszeiten über verschiedene Kunden hinweg. Warum das wichtig ist Unverzichtbar, um Kunden mit hohem Risiko zu identifizieren und die Performance nach Kunden zu segmentieren. Bezugsquelle CustInvoiceJour.InvoiceAccount oder CustTrans.AccountNum Beispiele US-001DE-550CUST-9921
	Rechnungsbetrag InvoiceAmount	Der gesamte Geldwert der Rechnung.
Beschreibung Dieses Attribut bildet den finanziellen Wert des Rechnungsdokuments ab. Es dient dazu, das gesamte Forderungsrisiko in der Debitorenbuchhaltung zu berechnen und das Inkasso für Rechnungen mit hohem Wert zu priorisieren. Dieses Feld befindet sich üblicherweise in der Rechnungstabelle. Warum das wichtig ist Entscheidend für die Analyse finanzieller Auswirkungen und die Identifizierung wertbezogener Engpässe. Bezugsquelle CustInvoiceJour.InvoiceAmount Beispiele 1500.00250.5010000.00
	Auftrags-ID SalesOrderId	Die Referenznummer des mit der Rechnung verknüpften Kundenauftrags.
Beschreibung Dieses Attribut verknüpft die Rechnung mit dem ursprünglichen Kundenauftrag. Wenn Daten aus dem Order-to-Cash-Prozess verfügbar sind, ermöglicht es eine prozessübergreifende Analyse und unterstützt die Untersuchung vorgelagerter Ursachen von Abrechnungsproblemen. Warum das wichtig ist Verknüpft den Abrechnungsprozess mit dem Vertriebsprozess. Bezugsquelle CustInvoiceJour.SalesId Beispiele SO-10022SO-55912
	Ist ausgeglichen IsCleared	Kennzeichen dafür, ob die Rechnung vollständig beglichen wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob der Saldo der Rechnung durch Zahlung oder Abschreibung auf null gesunken ist. Es ermöglicht die schnelle Filterung offener und abgeschlossener Cases zur Berechnung der durchschnittlichen Rechnungsdurchlaufzeit. Warum das wichtig ist Unterscheidet zwischen aktiven und historischen Cases. Bezugsquelle Abgeleitet aus dem Vorhandensein des Datums CustTrans.Closed Beispiele truefalse
	Ist eine Gutschrift IsCreditMemo	Kennzeichen dafür, ob es sich bei dem Dokument um eine Gutschrift handelt.
Beschreibung Dieses boolesche Attribut gibt an, ob die Transaktion eine für den Kunden ausgestellte Gutschrift darstellt. Es dient zur Berechnung der Gutschriftausstellungsquote und zum Herausfiltern von Standardrechnungen aus der Nacharbeitsanalyse. Warum das wichtig ist Unterstützt direkt das Dashboard zu Gutschriften und Nacharbeitsquote. Bezugsquelle Abgeleitet aus CustInvoiceJour.InvoiceAmount < 0 oder TransType Beispiele truefalse
	Skontofrist CashDiscountDate	Das Datum, bis zu dem ein Skonto für frühzeitige Zahlung gültig ist.
Beschreibung Dieses Attribut gibt die Frist an, innerhalb derer der Kunde einen Skonto für frühzeitige Zahlung erhalten kann. Es wird mit dem Zahlungsdatum verglichen, um die KPI zur Quote entgangener Skonti zu berechnen und die Wirksamkeit von Skontoanreizen zu analysieren. Warum das wichtig ist Zentral für das Dashboard zur Optimierung von Skonti bei frühzeitiger Zahlung. Bezugsquelle CustTrans.CashDisc oder berechnet aus CashDiscCode Beispiele 2023-11-102023-11-15
	Streitfallgrund DisputeReason	Der Grundcode, der einem strittigen Case zugewiesen wird.
Beschreibung Dieses Attribut erfasst den kategorisierten Grund, aus dem eine Rechnung beanstandet wurde, etwa „Preisfehler“ oder „beschädigte Ware“. Es ist für das Dashboard zum Lebenszyklus der Streitfallbearbeitung entscheidend, um die Ursachen von Zahlungsverzögerungen zu identifizieren. Warum das wichtig ist Ermöglicht die Ursachenanalyse für die KPI zur Dauer der Streitfallbearbeitung. Bezugsquelle CustTrans.ReasonRefRecId oder zugehörige Tabelle für Inkasso-Cases Beispiele PreisdifferenzBeschädigte WarenFehlende BestellungServicequalität
	Überfällige Tage DaysOverdue	Die Anzahl der Tage, um die die Zahlung im Vergleich zum Fälligkeitsdatum verspätet war.
Beschreibung Diese Kennzahl berechnet die Differenz zwischen Zahlungsdatum und Fälligkeitsdatum. Positive Werte weisen auf verspätete Zahlungen hin, negative Werte auf frühzeitige Zahlungen. Damit lässt sich die Zahlungsleistung detaillierter bewerten als mit einfachen booleschen Kennzeichen. Warum das wichtig ist Erweitert die Analyse der KPI zur Quote termingerechter Zahlungen. Bezugsquelle Berechnet: PaymentDate - DueDate Beispiele 50-230
	Währung Currency	Der Währungscode der Rechnungstransaktion.
Beschreibung Dieses Attribut gibt die Währung an, in der die Rechnung ausgestellt wurde, etwa USD oder EUR. Es ist wichtig, um Finanzwerte zu normalisieren, wenn eine globale Analyse über verschiedene Regionen hinweg erforderlich ist. Warum das wichtig ist Erforderlich, um die Wertverteilung in Systemen mit mehreren Währungen zu verstehen. Bezugsquelle CustInvoiceJour.CurrencyCode Beispiele USDEURGBPJPY
	Zahlungsbedingungen PaymentTerms	Der Code, der den vereinbarten Zahlungsplan definiert.
Beschreibung Dieses Attribut enthält den Code, der festlegt, wann die Zahlung fällig ist, etwa Net30 oder Net60. Es dient dazu zu analysieren, ob Kunden ihre individuellen Zahlungsbedingungen einhalten, und zu prüfen, ob das Fälligkeitsdatum korrekt berechnet wurde. Warum das wichtig ist Liefert den Kontext zum Fälligkeitsdatum und hilft zu erkennen, ob Zahlungsbedingungen zu großzügig oder zu streng sind. Bezugsquelle CustInvoiceJour.Payment oder CustTable.PaymTermId Beispiele Netto 30Netto 45CODEOM

Erforderlich Empfohlen Optional

Aktivitäten der Debitorenbuchhaltung

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Ablauf des Rechnungsausgleichs präzise zu ermitteln.

8 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Gutschrift erstellt	Die Buchung einer Gutschrift, die den ursprünglichen Rechnungsbetrag ausgleicht. Häufig ist sie das Ergebnis eines gelösten Streitfalls oder einer Retoure.
Warum das wichtig ist Eine hohe Häufigkeit weist auf Umsatzverluste und Qualitätsprobleme in vorgelagerten Prozessen hin. Im Gegensatz zu einer Zahlung handelt es sich um eine nicht zahlungswirksame Verrechnung. Bezugsquelle Tabelle CustTrans mit Type „Credit Note“ oder CustInvoiceJour mit einem negativen InvoiceAmount. Erfassen Erfasst, wenn die Transaktion in CustTrans gebucht wurde Ereignistyp explicit
	Rechnung gebucht	Die erstmalige Erfassung der Rechnung im Finanzbuch. Diese Aktivität dokumentiert die Entstehung der finanziellen Verpflichtung in der Tabelle CustInvoiceJour.
Warum das wichtig ist Kennzeichnet den offiziellen Beginn des Lebenszyklus der Debitorenbuchhaltung und den Start der Zahlungsfrist. Dieser Zeitpunkt ist für die Berechnung der Days Sales Outstanding (DSO) erforderlich. Bezugsquelle Tabelle CustInvoiceJour. Das Feld CreatedDateTime oder InvoiceDate dient als Timestamp. Erfassen Erfasst, wenn die Transaktion in CustInvoiceJour gebucht wurde Ereignistyp explicit
	Rechnung verrechnet	Die abschließende Statusänderung, bei der der Rechnungssaldo auf null sinkt und die Transaktion im System als „Closed“ gekennzeichnet wird.
Warum das wichtig ist Das endgültige Ende der Prozessinstanz. Wird zur Berechnung der gesamten Cycle Time verwendet. Bezugsquelle Feld CustTrans.Closed (Datum). Dieses Datum wird gefüllt, sobald die Summe der Verrechnungen dem Rechnungsbetrag entspricht. Erfassen Abgeleitet aus dem Datumsfeld CustTrans.Closed Ereignistyp inferred
	Rechnung versendet	Das Ereignis, bei dem die Rechnung per E-Mail, als Ausdruck oder über EDI an den Kunden gesendet wird. Es wird häufig aus der Erhöhung des Zählers „Printed“ oder aus Protokollen der Druckverwaltung abgeleitet.
Warum das wichtig ist Verzögerungen zwischen Buchung und Versand verkürzen das effektive Zahlungsfenster des Kunden und führen dadurch zu vermeintlich verspäteten Zahlungen. Bezugsquelle Abgeleitet aus einer Änderung von CustInvoiceJour.PrintedOriginals von 0 auf 1 oder über die Tabelle PrintJobHeader, sofern die Protokollierung aktiviert ist. Erfassen Statusfeld vor und nach dem Ereignis oder Protokoll von PrintJobHeader vergleichen Ereignistyp inferred
	Streitfall eröffnet	Die Erstellung eines mit der Rechnung verknüpften Falls im Case-Management-Modul signalisiert einen Widerspruch des Kunden. Dadurch werden reguläre Abläufe des Forderungseinzugs unterbrochen.
Warum das wichtig ist Streitfälle sind eine der wichtigsten Ursachen verspäteter Zahlungen. Ihre Nachverfolgung macht Qualitätsprobleme in vorgelagerten Prozessen wie Preisgestaltung oder Auftragsabwicklung sichtbar. Bezugsquelle Tabelle CaseDetailBase, in der Category auf Collections/AR verweist und RefRecId den Bezug zur Rechnung herstellt. Erfassen Erfasst, wenn Transaktion X im Case Management ausgeführt wurde Ereignistyp explicit
	Teilzahlung gebucht	Die Erfassung einer Zahlung, die den offenen Rechnungsbetrag nicht vollständig abdeckt. Häufig bleibt dadurch ein Restbetrag bestehen, der weiter eingefordert werden muss.
Warum das wichtig ist Unterscheidet zwischen Ratenzahlungen und vollständigen Verrechnungen. Das ist wichtig für eine präzise Cashflow-Prognose. Bezugsquelle Tabelle CustSettlement, die eine Zahlung (CustTrans) mit der Rechnung (CustTrans) verknüpft, wobei SettlementAmount < InvoiceAmount gilt. Erfassen Erfasst, wenn Transaktion X in CustSettlement ausgeführt wurde Ereignistyp explicit
	Vollständige Zahlung erhalten	Die Buchung einer Zahlungstransaktion, die den verbleibenden Rechnungsbetrag abdeckt. Dies ist das Ereignis des Zahlungseingangs.
Warum das wichtig ist Das wichtigste Erfolgsergebnis. Es dient zur Berechnung der pünktlichen Zahlungsquote und der Wirksamkeit von Skontobedingungen. Bezugsquelle Tabelle CustTrans mit Type „Payment“, über CustSettlement mit der Rechnung verknüpft, sodass der Saldo auf null sinkt. Erfassen Erfasst, wenn die Transaktion in CustTrans gebucht und verrechnet wurde Ereignistyp explicit
	Zahlungserinnerung versendet	Dokumentiert den Versand eines formellen Mahnschreibens an den Kunden. Die Information stammt aus dem Collection Letter Journal.
Warum das wichtig ist Kennzeichnet den Beginn aktiver Einzugsmaßnahmen. Eine Häufigkeitsanalyse hilft, die Mahnstrategie zu verbessern und administrative Kosten zu senken. Bezugsquelle Tabelle CustCollectionLetterJour. Sie erfasst das Datum, an dem der Mahncode für die jeweilige Rechnungstransaktion gebucht wurde. Erfassen Erfasst, wenn die Transaktion in CustCollectionLetterJour gebucht wurde Ereignistyp explicit
	Fälligkeitsdatum überschritten	Ein berechneter Meilenstein, der anzeigt, dass das aktuelle Datum das Fälligkeitsdatum der Rechnung überschritten hat, während die Rechnung noch offen ist. Die Rechnung wird dadurch als überfällig gekennzeichnet.
Warum das wichtig ist Dieser Meilenstein ist für die Altersstrukturanalyse und das Auslösen von Workflows im Forderungseinzug entscheidend. Er trennt die reguläre Abrechnung vom Forderungsmanagement. Bezugsquelle Berechnet durch den Vergleich von CustInvoiceJour.DueDate mit der aktuellen Simulationszeit oder dem Zahlungs-Timestamp. Erfassen Durch den Vergleich des Felds DueDate mit der aktuellen Zeit ableiten Ereignistyp calculated
	Kontoauszug abgeglichen	Das Abstimmungsereignis, bei dem die in der Debitorenbuchhaltung erfasste Zahlung einer Position im importierten Kontoauszug zugeordnet wird.
Warum das wichtig ist Bestätigt, dass sich die Mittel tatsächlich auf dem Bankkonto befinden. Verzögerungen weisen auf Ineffizienzen in den Prozessen für Cash and Bank Management hin. Bezugsquelle Status „matched“ in BankReconciliationLine oder BankAccountTrans. Erfordert das Modul Advanced Bank Reconciliation. Erfassen Erfasst, wenn die Transaktion in Bank Reconciliation abgeglichen wurde Ereignistyp explicit
	Streitfall gelöst	Das Schließen des Streitfalls ermöglicht, dass die Rechnung weiter bezahlt oder gutgeschrieben wird. Damit endet der Subprozess der Ausnahmebearbeitung.
Warum das wichtig ist Die Differenz zwischen den Timestamps von „Opened“ und „Resolved“ ist eine wichtige KPI für die administrative Effizienz. Bezugsquelle Tabelle CaseDetailBase, in der sich Status in „Closed“ oder „Resolved“ ändert. Erfassen Statusfeld in CaseDetailBase vor und nach dem Ereignis vergleichen Ereignistyp inferred
	Streitfall in Prüfung	Zeigt an, dass der Streitfall vom Status „Opened“ in den Status „In Process“ übergegangen ist. Dieser Zeitraum entspricht der aktiven Bearbeitungszeit des Lösungsteams.
Warum das wichtig ist Engpässe in diesem Abschnitt verlängern den Cash Conversion Cycle. So lässt sich Wartezeit von aktiver Bearbeitungszeit unterscheiden. Bezugsquelle Abgeleitet aus Änderungen im Feld CaseDetailBase.Status oder aus Einträgen in der Tabelle CaseLog, die dem Statusverlauf entsprechen. Erfassen Statusfeld in CaseDetailBase vor und nach dem Ereignis vergleichen Ereignistyp inferred
	Zahlung abgeschrieben	Die Erklärung einer Rechnung als uneinbringlich und die Ausbuchung des Saldos über ein Abschreibungsjournal. Dies stellt einen finanziellen Verlust dar.
Warum das wichtig ist Endstatus eines erfolglosen Forderungseinzugs. Er ist für die Analyse der Quote uneinbringlicher Forderungen und der Wirksamkeit der Kreditrichtlinie erforderlich. Bezugsquelle Tabelle CustTrans mit Type „WriteOff“ oder GeneralJournalEntry, das mit spezifischen Gründen für die Abschreibung gekennzeichnet ist. Erfassen Erfasst, wenn eine Transaktion mit dem Type „WriteOff“ gebucht wurde Ereignistyp explicit
	Zahlungszusage erhalten	Eine konkrete Zusage eines Mitarbeiters im Forderungsmanagement, dass der Kunde bis zu einem bestimmten Datum zahlen wird. Die Information stammt aus dem Modul Collections Management.
Warum das wichtig ist Misst die Wirksamkeit von Gesprächen im Forderungseinzug. Der Vergleich dieses Datums mit dem tatsächlichen Zahlungseingang zeigt, wie zuverlässig Kundenzusagen sind. Bezugsquelle Tabelle CustPromiseToPay. Verknüpft mit der Kundentransaktion über TransRecId. Erfassen Erfasst, wenn der Datensatz in CustPromiseToPay erstellt wurde Ereignistyp explicit
	Zinsnote erstellt	Die Erstellung einer Zinsnote für überfällige Zahlungen. Sie stellt eine finanzielle Belastung des Kundenkontos dar.
Warum das wichtig ist Weist auf einen erheblichen Zahlungsverzug hin. Die Analyse zeigt, ob Gebühren Zahlungen tatsächlich beschleunigen oder die Kundenbeziehung belasten. Bezugsquelle Tabelle CustInterestJour. Sie protokolliert für bestimmte Kundentransaktionen erstellte Zinsnoten. Erfassen Erfasst, wenn die Transaktion in CustInterestJour gebucht wurde Ereignistyp explicit

Anleitungen zur Datenextraktion

So erhalten Sie Ihre Daten aus Microsoft Dynamics 365

Schritte

Azure-Ressourcen konfigurieren: Stellen Sie eine Azure SQL Database als Ziel für Bring Your Own Database (BYOD) bereit. Stellen Sie sicher, dass die Verbindungszeichenfolge Anmeldedaten mit Lese- und Schreibberechtigungen enthält.
Datenverwaltung in D365 konfigurieren: Navigieren Sie zu System Administration > Workspaces > Data Management. Klicken Sie auf die Kachel „Configure Entity Export to Database“. Geben Sie die Verbindungszeichenfolge aus dem vorherigen Schritt ein, um die externe Datenbank zu registrieren.
Erforderliche Entitäten auswählen: Erstellen Sie im Arbeitsbereich Data Management ein neues Export Project. Fügen Sie dem Projekt die folgenden Standardentitäten hinzu: CustInvoiceJournalHeaderEntity, CustTransactionEntity, CustSettlementEntity, CustCollectionLetterJournalHeaderEntity, CaseDetailEntity, CaseAssociationEntity, CustInterestJournalEntity, BankAccountTransEntity und CustPromiseToPayEntity.
Quelle und Ziel zuordnen: Stellen Sie sicher, dass alle Felder korrekt zugeordnet sind. Achten Sie insbesondere darauf, dass die Felder RecId und CreatedDateTime enthalten sind, da sie für die Ereignisreihenfolge entscheidend sind.
Ersten Export ausführen: Führen Sie den Exportauftrag manuell aus (Auftragstyp: Export), um historische Daten vollständig in die Azure SQL Database zu laden. Überwachen Sie die Ausführungsübersicht, um sicherzustellen, dass alle Datensätze erfolgreich übertragen wurden.
Inkrementelle Aktualisierungen planen: Konfigurieren Sie einen wiederkehrenden Datenauftrag, der das Export Project regelmäßig ausführt, zum Beispiel alle 4 Stunden oder jede Nacht. Verwenden Sie „Incremental push“, damit nur geänderte Datensätze aktualisiert werden.
Mit Azure SQL verbinden: Verwenden Sie SQL Server Management Studio (SSMS) oder ein vergleichbares Tool, um eine Verbindung zur BYOD Azure SQL Database herzustellen.
Transformationsskript ausführen: Führen Sie das im folgenden Query-Abschnitt bereitgestellte SQL-Skript für die BYOD-Tabellen aus. Das Skript führt die unterschiedlichen Tabellen in einer einheitlichen Event-Log-Struktur zusammen.
Prüfen und extrahieren: Kontrollieren Sie die Ausgabe auf Konsistenz, siehe Validierungsschritte. Exportieren Sie das Ergebnis als CSV- oder Parquet-Datei, um es in ProcessMind zu importieren.

Konfiguration

Exportmethode: Bring Your Own Database (BYOD) oder Azure Data Lake Storage Gen2 (ADLS).
Aktualisierungsstrategie: Full push für den ersten Ladevorgang, Incremental push für wiederkehrende Aktualisierungen, um die Leistung möglichst wenig zu beeinträchtigen.
Erforderliche Entitäten: CustInvoiceJournalHeaderEntity (Rechnungen), CustSettlementEntity (Zahlungen/Ausgleich), CustCollectionLetterJournalHeaderEntity (Zahlungserinnerungen), CaseDetailEntity (Streitfälle), BankAccountTransEntity (Bankabgleich).
Unternehmensfilter: Wenden Sie Filter auf die Spalte „DataAreaId“ an, wenn die Analyse auf bestimmte rechtliche Einheiten beschränkt werden soll.
Zeitraum: Empfohlen wird ein rollierendes 12-Monats-Fenster auf Basis von „InvoiceDate“ oder „TransDate“.
Änderungsnachverfolgung: Für einen effizienten inkrementellen Export muss Change Tracking für die SQL-Tabellen in D365 aktiviert sein.

a Beispielabfrage sql

/* SQL Transformation Script for D365 BYOD Tables */
/* Target: Azure SQL Database containing exported entities */

WITH InvoiceBasics AS (
    SELECT 
        InvoiceNumber AS InvoiceId,
        InvoiceDate,
        DueDate,
        InvoiceAccount AS CustomerAccount,
        SalesId,
        DataAreaId AS CompanyCode,
        InvoiceAmount,
        Currency
    FROM dbo.CustInvoiceJournalHeaderEntity
    WHERE InvoiceDate >= DATEADD(month, -12, GETDATE())
)

/* 1. Invoice Posted */
SELECT 
    T1.InvoiceId AS InvoiceNumber,
    'Invoice Posted' AS Activity,
    CAST(T1.InvoiceDate AS DATETIME) AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL AS CustomerGroup,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL AS [User],
    NULL AS BusinessUnit,
    T1.CompanyCode,
    1 AS IsAutomated
FROM InvoiceBasics T1

UNION ALL

/* 2. Invoice Dispatched (Inferred from Document Date as Proxy if Print Log unavailable) */
SELECT 
    T1.InvoiceId,
    'Invoice Dispatched' AS Activity,
    DATEADD(minute, 5, CAST(T1.InvoiceDate AS DATETIME)) AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL,
    NULL,
    T1.CompanyCode,
    1
FROM InvoiceBasics T1

UNION ALL

/* 3. Due Date Passed (Synthetic Event) */
SELECT 
    T1.InvoiceId,
    'Due Date Passed' AS Activity,
    CAST(T1.DueDate AS DATETIME) AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL,
    NULL,
    T1.CompanyCode,
    1
FROM InvoiceBasics T1
WHERE GETDATE() > T1.DueDate

UNION ALL

/* 4. Payment Reminder Sent */
SELECT 
    Inv.InvoiceId,
    'Payment Reminder Sent' AS Activity,
    CL.JournalDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CL.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustCollectionLetterJournalHeaderEntity CL
JOIN dbo.CustCollectionLetterLineEntity CLL ON CL.JournalNumber = CLL.JournalNumber AND CL.DataAreaId = CLL.DataAreaId
JOIN InvoiceBasics Inv ON CLL.InvoiceId = Inv.InvoiceId AND CLL.DataAreaId = Inv.CompanyCode

UNION ALL

/* 5. Promise to Pay Received */
SELECT 
    Inv.InvoiceId,
    'Promise to Pay Received' AS Activity,
    PTP.PromiseDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    NULL,
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustPromiseToPayEntity PTP
JOIN InvoiceBasics Inv ON PTP.Invoice = Inv.InvoiceId AND PTP.DataAreaId = Inv.CompanyCode

UNION ALL

/* 6. Dispute Case Opened */
SELECT 
    Inv.InvoiceId,
    'Dispute Case Opened' AS Activity,
    CD.CreatedDateTime AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CD.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CaseDetailEntity CD
JOIN dbo.CaseAssociationEntity CA ON CD.CaseId = CA.CaseId AND CD.DataAreaId = CA.DataAreaId
JOIN InvoiceBasics Inv ON CA.RefRecId = Inv.InvoiceId /* Logic assumes linking via Invoice Number or manual mapping might be needed depending on RefTableId */
WHERE CA.RefEntityName = 'CustInvoiceTable'

UNION ALL

/* 7. Dispute Under Review */
SELECT 
    Inv.InvoiceId,
    'Dispute Under Review' AS Activity,
    CD.ModifiedDateTime AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CD.ModifiedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CaseDetailEntity CD
JOIN dbo.CaseAssociationEntity CA ON CD.CaseId = CA.CaseId AND CD.DataAreaId = CA.DataAreaId
JOIN InvoiceBasics Inv ON CA.RefRecId = Inv.InvoiceId
WHERE CD.Status = 'InProcess'

UNION ALL

/* 8. Dispute Resolved */
SELECT 
    Inv.InvoiceId,
    'Dispute Resolved' AS Activity,
    CD.ClosedDateTime AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CD.ModifiedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CaseDetailEntity CD
JOIN dbo.CaseAssociationEntity CA ON CD.CaseId = CA.CaseId AND CD.DataAreaId = CA.DataAreaId
JOIN InvoiceBasics Inv ON CA.RefRecId = Inv.InvoiceId
WHERE CD.Status = 'Closed'

UNION ALL

/* 9. Credit Memo Issued */
SELECT 
    T1.InvoiceId,
    'Credit Memo Issued' AS Activity,
    T1.InvoiceDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL,
    NULL,
    T1.CompanyCode,
    0
FROM dbo.CustInvoiceJournalHeaderEntity T1
WHERE T1.InvoiceAmount < 0

UNION ALL

/* 10. Interest Note Generated */
SELECT 
    Inv.InvoiceId,
    'Interest Note Generated' AS Activity,
    IJ.InterestDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    IJ.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    1
FROM dbo.CustInterestJournalEntity IJ
JOIN InvoiceBasics Inv ON IJ.AccountDisplayValue = Inv.CustomerAccount AND IJ.DataAreaId = Inv.CompanyCode
/* Note: Direct link to specific Invoice ID is often via CustInterestTrans, requiring an additional join */

UNION ALL

/* 11. Partial Payment Posted */
SELECT 
    Inv.InvoiceId,
    'Partial Payment Posted' AS Activity,
    Sett.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Sett.SettleAmountCur AS InvoiceAmount,
    Inv.DueDate,
    Sett.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustSettlementEntity Sett
JOIN dbo.CustTransactionEntity Trans ON Sett.TransRecId = Trans.RecId
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE ABS(Sett.SettleAmountCur) < ABS(Trans.AmountCur) AND Sett.SettleAmountCur <> 0

UNION ALL

/* 12. Full Payment Received */
SELECT 
    Inv.InvoiceId,
    'Full Payment Received' AS Activity,
    Sett.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Sett.SettleAmountCur AS InvoiceAmount,
    Inv.DueDate,
    Sett.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustSettlementEntity Sett
JOIN dbo.CustTransactionEntity Trans ON Sett.TransRecId = Trans.RecId
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE ABS(Sett.SettleAmountCur) >= ABS(Trans.AmountCur)

UNION ALL

/* 13. Bank Statement Matched */
SELECT 
    Inv.InvoiceId,
    'Bank Statement Matched' AS Activity,
    Bank.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Bank.AmountCur AS InvoiceAmount,
    Inv.DueDate,
    NULL,
    NULL,
    Inv.CompanyCode,
    1
FROM dbo.BankAccountTransEntity Bank
JOIN dbo.CustSettlementEntity Sett ON Bank.Voucher = Sett.OffsetTransVoucher AND Bank.DataAreaId = Sett.DataAreaId
JOIN dbo.CustTransactionEntity Trans ON Sett.TransRecId = Trans.RecId
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId

UNION ALL

/* 14. Payment Written Off */
SELECT 
    Inv.InvoiceId,
    'Payment Written Off' AS Activity,
    Trans.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Trans.AmountCur AS InvoiceAmount,
    Inv.DueDate,
    Trans.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustTransactionEntity Trans
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE Trans.TransactionType = 'WriteOff'

UNION ALL

/* 15. Invoice Cleared */
SELECT 
    Inv.InvoiceId,
    'Invoice Cleared' AS Activity,
    Trans.ClosedDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    NULL,
    NULL,
    Inv.CompanyCode,
    1
FROM dbo.CustTransactionEntity Trans
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE Trans.ClosedDate IS NOT NULL AND Trans.ClosedDate <> '1900-01-01'

Schritte

Voraussetzungen einrichten: Stellen Sie sicher, dass Python 3.x auf dem Ausführungsgerät installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pandas, requests und msal, falls Sie die Microsoft Authentication Library verwenden. Das Skript greift der Einfachheit halber direkt über REST zu.
Azure-App registrieren: Registrieren Sie eine Anwendung in Azure Active Directory (Entra ID), damit sie auf Dynamics 365 zugreifen kann. Notieren Sie Client-ID, Client Secret und Mandanten-ID. Stellen Sie sicher, dass die Anwendung über API-Berechtigungen für Dynamics ERP (OData) verfügt.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript. Aktualisieren Sie das Dictionary config am Anfang des Skripts mit Ihrer D365-URL, Client-ID, Client Secret, Mandanten-ID und dem Zielunternehmenscode (dataAreaId).
Datumsbereich festlegen: Ändern Sie die Variablen start_date und end_date, um das Extraktionsfenster festzulegen. Für inkrementelle Ladevorgänge wird ein gleitendes Fenster der letzten 90 bis 180 Tage empfohlen.
Extraktion ausführen: Führen Sie das Skript aus. Es authentifiziert sich bei Azure AD, ruft ein Zugriffstoken ab und durchläuft mehrere OData-Entitäten wie CustomerInvoices, PaymentJournals und CaseDetails, um Daten abzurufen.
Daten verarbeiten: Das Skript führt automatisch Datentransformationen aus. Dazu gehören die Umbenennung von Spalten entsprechend dem ProcessMind-Schema, die Berechnung von Ereignissen für „Due Date Passed“ anhand des Systemdatums sowie die Unterscheidung zwischen Teil- und Vollzahlungen anhand der Transaktionsbeträge.
Zusammenführen und sortieren: Das Skript führt alle Aktivitäts-DataFrames zu einem Event Log zusammen und sortiert sie nach InvoiceNumber und EventTimestamp.
Exportieren: Der finale DataFrame wird in eine CSV-Datei mit dem Namen AR_Event_Log.csv exportiert. Prüfen Sie, ob die Datei im Verzeichnis des Skripts erstellt wurde.
Validieren: Öffnen Sie die CSV-Datei und prüfen Sie, ob die Datumswerte im ISO-Format (YYYY-MM-DD HH:MM:SS) vorliegen und alle erforderlichen Spalten befüllt sind.
Hochladen: Importieren Sie die erzeugte CSV-Datei mit dem Standardassistenten zum Datei-Upload in ProcessMind. Ordnen Sie InvoiceNumber der Case-ID, Aktivität der Aktivität und EventTimestamp dem Timestamp zu.

Konfiguration

Batch-Größe: Das Skript verwendet eine standardmäßige Seitengröße, häufig 1.000 Datensätze, die vom Server vorgegeben wird. Die Seitennavigation erfolgt automatisch über die Eigenschaft @odata.nextLink.
Datumsfilter: Der OData-Parameter $filter beschränkt den Datenabruf auf relevante Zeiträume, zum Beispiel InvoiceDate ge 2023-01-01T00:00:00Z. Das verbessert die Leistung deutlich.
Unternehmensfilterung: D365 speichert Daten für mehrere rechtliche Einheiten. Das Skript filtert nach dataAreaId, damit nur Daten der relevanten Geschäftseinheit extrahiert werden.
Authentifizierung: Verwendet OAuth 2.0 (Client-Credentials-Flow). Sie benötigen ein gültiges Client Secret und eine App-Registrierung.
Auswahl der Entitäten: Verwendet Standardentitäten wie CustomerInvoices, CustomerPaymentJournalLines und CaseDetail. Wenn Ihr Unternehmen benutzerdefinierte Entitäten verwendet, müssen Sie die Endpunkte im endpoints-Dictionary aktualisieren.
Berechnete Ereignisse: Ereignisse wie „Due Date Passed“ werden während der Skriptausführung berechnet, da sie kein eigenes Transaktionsprotokoll in der Datenbank erzeugen.

a Beispielabfrage python

import requests
import pandas as pd
import datetime
from datetime import  timedelta
import json

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
config = {
    class="hl-string">"resource": class="hl-string">"https://[YourOrg].operations.dynamics.com",
    class="hl-string">"tenant_id": class="hl-string">"[Your-Tenant-ID]",
    class="hl-string">"client_id": class="hl-string">"[Your-Client-ID]",
    class="hl-string">"client_secret": class="hl-string">"[Your-Client-Secret]",
    class="hl-string">"company_code": class="hl-string">"USMF",  class=class="hl-string">"hl-comment"># Example Company Code
    class="hl-string">"start_date": class="hl-string">"2023-01-01T00:00:00Z"
}

class=class="hl-string">"hl-comment"># === AUTHENTICATION ===
def get_token(config):
    token_url = fclass="hl-string">"https://login.microsoftonline.com/{config['tenant_id']}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': config[class="hl-string">'client_id'],
        class="hl-string">'client_secret': config[class="hl-string">'client_secret'],
        class="hl-string">'resource': config[class="hl-string">'resource']
    }
    response = requests.post(token_url, data=payload)
    if response.status_code == 200:
        return response.json().get(class="hl-string">'access_token')
    else:
        raise Exception(fclass="hl-string">"Auth Failed: {response.text}")

class=class="hl-string">"hl-comment"># === ODATA FETCHER ===
def get_odata_data(token, entity_url, filter_str):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'Accept': class="hl-string">'application/json'}
    results = []
    next_link = fclass="hl-string">"{config['resource']}/data/{entity_url}?$filter={filter_str}&$format=json"
    
    while next_link:
        print(fclass="hl-string">"Fetching: {next_link}")
        try:
            res = requests.get(next_link, headers=headers)
            if res.status_code != 200:
                print(fclass="hl-string">"Error fetching data: {res.text}")
                break
            data = res.json()
            results.extend(data.get(class="hl-string">'value', []))
            next_link = data.get(class="hl-string">'@odata.nextLink', None)
        except Exception as e:
            print(fclass="hl-string">"Exception: {e}")
            break
    return pd.DataFrame(results)

class=class="hl-string">"hl-comment"># === MAIN EXTRACTION ===
def main():
    token = get_token(config)
    all_events = []
    company_filter = fclass="hl-string">"dataAreaId eq '{config['company_code']}'"
    date_filter = fclass="hl-string">"InvoiceDate ge {config['start_date']}"

    class=class="hl-string">"hl-comment"># 1. INVOICE BASIC EVENTS (Posted, Dispatched, Credit Memo, Cleared)
    class=class="hl-string">"hl-comment"># Entity: CustomerInvoices (or SalesInvoiceHeaders)
    print(class="hl-string">"Processing Invoices...")
    df_inv = get_odata_data(token, class="hl-string">"CustomerInvoices", fclass="hl-string">"{company_filter} and {date_filter}")
    
    if not df_inv.empty:
        class=class="hl-string">"hl-comment"># Activity: Invoice Posted
        posted = df_inv.copy()
        posted[class="hl-string">'Activity'] = class="hl-string">'Invoice Posted'
        posted[class="hl-string">'EventTimestamp'] = posted[class="hl-string">'InvoiceDate']
        all_events.append(posted)

        class=class="hl-string">"hl-comment"># Activity: Invoice Dispatched (Assumed same day as posted if not tracked separately)
        dispatched = df_inv.copy()
        dispatched[class="hl-string">'Activity'] = class="hl-string">'Invoice Dispatched'
        dispatched[class="hl-string">'EventTimestamp'] = dispatched[class="hl-string">'InvoiceDate']  class=class="hl-string">"hl-comment"># Often inferred
        all_events.append(dispatched)

        class=class="hl-string">"hl-comment"># Activity: Credit Memo Issued
        credit_memos = df_inv[df_inv[class="hl-string">'InvoiceAmount'] < 0].copy()
        credit_memos[class="hl-string">'Activity'] = class="hl-string">'Credit Memo Issued'
        credit_memos[class="hl-string">'EventTimestamp'] = credit_memos[class="hl-string">'InvoiceDate']
        all_events.append(credit_memos)

        class=class="hl-string">"hl-comment"># Activity: Invoice Cleared (Closed)
        class=class="hl-string">"hl-comment"># Note: ClosedDate might need to be cast to datetime
        cleared = df_inv[df_inv[class="hl-string">'ClosedDate'].notnull()].copy()
        if not cleared.empty:
            cleared[class="hl-string">'Activity'] = class="hl-string">'Invoice Cleared'
            cleared[class="hl-string">'EventTimestamp'] = cleared[class="hl-string">'ClosedDate']
            all_events.append(cleared)

        class=class="hl-string">"hl-comment"># Activity: Due Date Passed (Calculated)
        class=class="hl-string">"hl-comment"># Logic: If not closed, and DueDate < Now
        now = datetime.datetime.now()
        overdue = df_inv[(df_inv[class="hl-string">'ClosedDate'].isnull())].copy()
        class=class="hl-string">"hl-comment"># Convert DueDate to datetime objects for comparison
        overdue[class="hl-string">'DueDate_DT'] = pd.to_datetime(overdue[class="hl-string">'DueDate'])
        overdue = overdue[overdue[class="hl-string">'DueDate_DT'] < now]
        if not overdue.empty:
            overdue[class="hl-string">'Activity'] = class="hl-string">'Due Date Passed'
            class=class="hl-string">"hl-comment"># Timestamp is the day it became overdue
            overdue[class="hl-string">'EventTimestamp'] = overdue[class="hl-string">'DueDate'] 
            all_events.append(overdue)

    class=class="hl-string">"hl-comment"># 2. PAYMENTS (Partial, Full, WriteOff)
    class=class="hl-string">"hl-comment"># Entity: CustomerPaymentJournalLines
    print(class="hl-string">"Processing Payments...")
    class=class="hl-string">"hl-comment"># Note: Filter by TransDate usually
    df_pay = get_odata_data(token, class="hl-string">"CustomerPaymentJournalLines", fclass="hl-string">"{company_filter}")
    
    if not df_pay.empty:
        class=class="hl-string">"hl-comment"># Activity: Partial vs Full Payment
        class=class="hl-string">"hl-comment"># Logic requires comparing payment amount to invoice balance. simplified here based on Amount
        class=class="hl-string">"hl-comment"># Assuming we join with invoices later, strictly classifying based on available fields
        class=class="hl-string">"hl-comment"># Here we assume a field class="hl-string">'PaymentStatus' or we treat all as Partial unless marked Settled
        
        class=class="hl-string">"hl-comment"># Full Payment
        full_pay = df_pay.copy()
        full_pay[class="hl-string">'Activity'] = class="hl-string">'Full Payment Received'
        full_pay[class="hl-string">'EventTimestamp'] = full_pay[class="hl-string">'TransDate']
        all_events.append(full_pay)
        
        class=class="hl-string">"hl-comment"># Partial Payment (In a real scenario, this requires logic checking settlement vs invoice total)
        class=class="hl-string">"hl-comment"># Adding a duplicate row for demonstration of structure
        partial_pay = df_pay[df_pay[class="hl-string">'Amount'] < 1000].copy() class=class="hl-string">"hl-comment"># Placeholder logic
        partial_pay[class="hl-string">'Activity'] = class="hl-string">'Partial Payment Posted'
        partial_pay[class="hl-string">'EventTimestamp'] = partial_pay[class="hl-string">'TransDate']
        all_events.append(partial_pay)

        class=class="hl-string">"hl-comment"># Activity: Payment Written Off
        class=class="hl-string">"hl-comment"># Filter by specific Transaction Type or Journal Name
        write_off = df_pay[df_pay[class="hl-string">'JournalName'].str.contains(class="hl-string">'WriteOff', case=False, na=False)].copy()
        write_off[class="hl-string">'Activity'] = class="hl-string">'Payment Written Off'
        write_off[class="hl-string">'EventTimestamp'] = write_off[class="hl-string">'TransDate']
        all_events.append(write_off)

    class=class="hl-string">"hl-comment"># 3. COLLECTIONS (Reminders, Promise to Pay)
    class=class="hl-string">"hl-comment"># Entity: CollectionLetterJournals
    print(class="hl-string">"Processing Collections...")
    df_col = get_odata_data(token, class="hl-string">"CollectionLetterJournals", fclass="hl-string">"{company_filter}")
    if not df_col.empty:
        reminders = df_col.copy()
        reminders[class="hl-string">'Activity'] = class="hl-string">'Payment Reminder Sent'
        reminders[class="hl-string">'EventTimestamp'] = reminders[class="hl-string">'LetterDate']
        all_events.append(reminders)

    class=class="hl-string">"hl-comment"># Entity: CustomerPromiseToPay
    df_promise = get_odata_data(token, class="hl-string">"CustomerPromiseToPay", fclass="hl-string">"{company_filter}")
    if not df_promise.empty:
        promises = df_promise.copy()
        promises[class="hl-string">'Activity'] = class="hl-string">'Promise to Pay Received'
        promises[class="hl-string">'EventTimestamp'] = promises[class="hl-string">'CreatedDateTime']
        all_events.append(promises)

    class=class="hl-string">"hl-comment"># 4. DISPUTES (Opened, Review, Resolved)
    class=class="hl-string">"hl-comment"># Entity: CaseDetails (requires filtering for Collections/Dispute category)
    print(class="hl-string">"Processing Disputes...")
    df_case = get_odata_data(token, class="hl-string">"CaseDetails", fclass="hl-string">"{company_filter} and Category eq 'Collections'")
    if not df_case.empty:
        class=class="hl-string">"hl-comment"># Opened
        opened = df_case.copy()
        opened[class="hl-string">'Activity'] = class="hl-string">'Dispute Case Opened'
        opened[class="hl-string">'EventTimestamp'] = opened[class="hl-string">'CreatedDateTime']
        all_events.append(opened)

        class=class="hl-string">"hl-comment"># Under Review (In Process)
        in_process = df_case[df_case[class="hl-string">'Status'] == class="hl-string">'InProcess'].copy()
        in_process[class="hl-string">'Activity'] = class="hl-string">'Dispute Under Review'
        in_process[class="hl-string">'EventTimestamp'] = in_process[class="hl-string">'ModifiedDateTime']
        all_events.append(in_process)

        class=class="hl-string">"hl-comment"># Resolved (Closed)
        resolved = df_case[df_case[class="hl-string">'Status'] == class="hl-string">'Closed'].copy()
        resolved[class="hl-string">'Activity'] = class="hl-string">'Dispute Resolved'
        resolved[class="hl-string">'EventTimestamp'] = resolved[class="hl-string">'ClosedDateTime']
        all_events.append(resolved)

    class=class="hl-string">"hl-comment"># 5. INTEREST
    class=class="hl-string">"hl-comment"># Entity: InterestNotes
    print(class="hl-string">"Processing Interest Notes...")
    df_interest = get_odata_data(token, class="hl-string">"InterestNotes", fclass="hl-string">"{company_filter}")
    if not df_interest.empty:
        interest = df_interest.copy()
        interest[class="hl-string">'Activity'] = class="hl-string">'Interest Note Generated'
        interest[class="hl-string">'EventTimestamp'] = interest[class="hl-string">'NoteDate']
        all_events.append(interest)

    class=class="hl-string">"hl-comment"># 6. BANK RECONCILIATION
    class=class="hl-string">"hl-comment"># Entity: BankReconciliationLines (Placeholder for matching)
    print(class="hl-string">"Processing Bank Reconciliation...")
    class=class="hl-string">"hl-comment"># This entity availability varies by version
    df_bank = get_odata_data(token, class="hl-string">"BankReconciliationLines", fclass="hl-string">"{company_filter}")
    if not df_bank.empty:
        matched = df_bank[df_bank[class="hl-string">'Reconciled'] == True].copy()
        matched[class="hl-string">'Activity'] = class="hl-string">'Bank Statement Matched'
        matched[class="hl-string">'EventTimestamp'] = matched[class="hl-string">'TransactionDate']
        class=class="hl-string">"hl-comment"># Need to join with Invoice via Payment Reference ideally
        class=class="hl-string">"hl-comment"># For this script, we assume InvoiceNumber is present or mapped
        all_events.append(matched)

    class=class="hl-string">"hl-comment"># === UNIFICATION & EXPORT ===
    if not all_events:
        print(class="hl-string">"No events extracted.")
        return

    final_df = pd.concat(all_events, ignore_index=True)

    class=class="hl-string">"hl-comment"># Map columns to schema
    class=class="hl-string">"hl-comment"># Note: Column names class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAccount' etc. depend on exact Entity schema
    class=class="hl-string">"hl-comment"># You may need to rename based on your D365 entity fields, e.g., class="hl-string">'InvoiceNum' -> class="hl-string">'InvoiceNumber'
    schema_map = {
        class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber',
        class="hl-string">'InvoiceId': class="hl-string">'InvoiceNumber', class=class="hl-string">"hl-comment"># Alternative common name
        class="hl-string">'InvoiceAccount': class="hl-string">'CustomerAccount',
        class="hl-string">'CustomerAccount': class="hl-string">'CustomerAccount',
        class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount',
        class="hl-string">'Amount': class="hl-string">'InvoiceAmount', class=class="hl-string">"hl-comment"># Fallback for payments
        class="hl-string">'CurrencyCode': class="hl-string">'Currency',
        class="hl-string">'DueDate': class="hl-string">'DueDate',
        class="hl-string">'CreatedBy': class="hl-string">'User',
        class="hl-string">'BusinessUnit': class="hl-string">'BusinessUnit',
        class="hl-string">'DataAreaId': class="hl-string">'CompanyCode'
    }
    
    class=class="hl-string">"hl-comment"># Normalize columns
    for col in final_df.columns:
        if col in schema_map:
            final_df.rename(columns={col: schema_map[col]}, inplace=True)

    class=class="hl-string">"hl-comment"># Add constant fields
    final_df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft D365'
    final_df[class="hl-string">'LastDataUpdate'] = datetime.datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Select final columns (fill missing with None)
    required_cols = [
        class="hl-string">'InvoiceNumber', class="hl-string">'Activity', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'CustomerAccount', class="hl-string">'CustomerGroup', class="hl-string">'InvoiceAmount', class="hl-string">'DueDate', class="hl-string">'User',
        class="hl-string">'BusinessUnit', class="hl-string">'CompanyCode', class="hl-string">'IsAutomated'
    ]
    
    for col in required_cols:
        if col not in final_df.columns:
            final_df[col] = None
            
    output_df = final_df[required_cols]
    
    class=class="hl-string">"hl-comment"># Export
    output_df.to_csv(class="hl-string">"AR_Event_Log.csv", index=False)
    print(class="hl-string">"Extraction complete. Saved to AR_Event_Log.csv")

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

Möchten Sie beginnen?

Beginnen Sie noch heute damit, Ihre Finanzprozesse mit diesem Daten-Template weiterzuentwickeln. Unser Team unterstützt Sie dabei, Ihre Microsoft-Dynamics-365-Daten auf diese Anforderungen abzustimmen.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie Ihre Debitorenbuchhaltung und verbessern Sie jetzt Ihren Cashflow

Schließen Sie sich Teams an, die ihre DSO in Microsoft Dynamics 365 um 15 bis 20 Tage reduzieren

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, Einrichtung in 5 Minuten

Ihr Daten-Template für die Debitorenbuchhaltung

Ihr Daten-Template für die Debitorenbuchhaltung

Attribute der Debitorenbuchhaltung

Aktivitäten der Debitorenbuchhaltung

Anleitungen zur Datenextraktion

Entitätsexport über das D365 Data Management Framework

Schritte

Konfiguration

a Beispielabfrage sql

Python-OData-API-Extraktion für Debitorenereignisse

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie beginnen?

Optimieren Sie Ihre Debitorenbuchhaltung und verbessern Sie jetzt Ihren Cashflow

Ihr Daten-Template für die Debitorenbuchhaltung

Ihr Daten-Template für die Debitorenbuchhaltung

Attribute der Debitorenbuchhaltung

Aktivitäten der Debitorenbuchhaltung

Anleitungen zur Datenextraktion

Entitätsexport über das D365 Data Management Framework

Schritte

Konfiguration

a Beispielabfrage sql

Python-OData-API-Extraktion für Debitorenereignisse

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie beginnen?

Optimieren Sie Ihre Debitorenbuchhaltung und verbessern Sie jetzt Ihren Cashflow

Ihre Privatsphäre ist uns wichtig