> Kontinuierliche Prozessverbesserung > Forderungsmanagement > Microsoft Dynamics 365 > Daten Template

Ihr Daten-Template für das Forderungsmanagement

Microsoft Dynamics 365

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Forderungsmanagements(21) Aktivitäten im Forderungsmanagement(15) Anleitungen zur Datenextraktion(2)

Ihr Daten-Template für das Forderungsmanagement

Dieses Template bietet einen umfassenden Rahmen, um Ihren Rechnungs- bis Zahlungseingangsprozess in Microsoft Dynamics 365 abzubilden. Es beschreibt die erforderlichen Datenfelder und Meilensteine, mit denen Sie ein hochwertiges Event Log für Process Mining erstellen. Anhand dieser Struktur erkennen Sie Zahlungsverzögerungen genauer und können Ihre Workflows im Forderungseinzug effizienter gestalten.

Wichtige Datenfelder für die Analyse des Hauptbuchs
Wichtige Prozessmeilensteine zur Nachverfolgung
Technische Anleitung 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 des Forderungsmanagements

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um die Leistung Ihres Forderungsmanagements umfassend zu analysieren.

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, zum Beispiel „Rechnung gebucht“, „Zahlung eingegangen“ oder „Streitfall eröffnet“. In Microsoft Dynamics 365 werden diese Angaben häufig aus dem Transaktionstyp (TransType) oder der Tabelle abgeleitet, in der der Datensatz protokolliert wird, etwa CustSettlement für Zahlungen. Das Attribut ist wichtig für die Visualisierung des Prozessablaufs. Warum das wichtig ist Es legt die Knoten im Prozessablauf fest und ermöglicht die Analyse des Prozessflusses sowie die Ermittlung von Varianten. Woher beziehen Abgeleitet aus der TransType-Aufzählung oder dem Tabellenkontext (CustTrans, CustSettlement usw.) Beispiele Rechnung gebuchtZahlung eingegangenMahnschreiben versendetZinsrechnung gebucht
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt, zu dem ein Ereignis im System protokolliert wurde. Es dient dazu, Zeitabstände zwischen Aktivitäten und Prozessdurchlaufzeiten zu berechnen sowie Ereignisse in die richtige Reihenfolge zu bringen. In D365 stammen die Werte üblicherweise aus CreatedDateTime oder TransDate, ergänzt um eine Uhrzeit. Warum das wichtig ist Timestamps sind entscheidend für die Berechnung aller zeitbasierten Kennzahlen, etwa der Rechnungszykluszeit und der Versandvorlaufzeit. Woher beziehen In verschiedenen Tabellen üblicherweise die Felder CreatedDateTime oder TransDate Beispiele 2023-10-15T08:30:00Z2023-10-15T14:45:22Z2023-11-01T09:00:00Z
	Rechnungsnummer InvoiceNumber	Eindeutige Kennung des Finanzbelegs für die Rechnung.
Beschreibung Die Rechnungsnummer ist der zentrale Schlüssel, um den Lebenszyklus einer Forderung in Microsoft Dynamics 365 nachzuverfolgen. Sie verknüpft den ursprünglichen Kundenauftrag, die gebuchte Rechnung, spätere Zahlungen und alle Aktivitäten zum Forderungseinzug zu einem einzelnen Case. In der Analyse dient dieses Attribut als Case-ID, anhand derer sich der gesamte Prozessablauf rekonstruieren lässt. Warum das wichtig ist Sie ist die grundlegende Analyseeinheit für die Debitorenbuchhaltung. Die Process-Mining-Engine kann damit einzelne Ereignisse zu einem zusammenhängenden Case gruppieren. Woher beziehen CustInvoiceJour.InvoiceId oder CustTrans.Invoice Beispiele INV-2023-001CIV-88921US-004321DE-99120
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der Datenextraktion oder -aktualisierung.
Beschreibung Dieses Attribut zeigt an, wann die Daten zuletzt aus Microsoft Dynamics 365 abgerufen wurden. Es hilft Benutzern, die Aktualität der Analyse und die Aussagekraft der KPIs einzuschätzen. In der Regel wird der Wert zum Zeitpunkt der Abfrage vom Extraktionstool erzeugt. Warum das wichtig ist Es gibt Aufschluss über die Datenlatenz und hilft Benutzern, die Aktualität der Dashboards einzuschätzen. Woher beziehen 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 gibt an, welches System die Daten führend verwaltet. In diesem Fall ist es Microsoft Dynamics 365. Das ist hilfreich, wenn Daten aus mehreren ERP-Instanzen oder externen Erfassungstools in einer gemeinsamen Ansicht zusammengeführt werden. So können Analysten Prozesse nach dem Ursprungssystem filtern oder segmentieren. Warum das wichtig ist So lassen sich die Datenherkunft und die Rückverfolgbarkeit sicherstellen, insbesondere in Umgebungen mit mehreren Systemen. Woher beziehen 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 gibt an, wer den jeweiligen Prozessschritt ausgeführt hat. Es wird aus den Feldern CreatedBy oder ModifiedBy abgeleitet. Damit lassen sich die Ressourcenauslastung analysieren, Schulungsbedarf erkennen und automatisierte Systemaufgaben von manuellen Eingriffen durch Benutzer unterscheiden. Warum das wichtig ist Ermöglicht die Analyse der Ressourcenleistung und die Berechnung des Automatisierungsgrads. Woher beziehen Feld CreatedBy in den Transaktionstabellen Beispiele AdministratorJSmithWorkflowAgentBSmith
	Buchungskreis CompanyCode	Die Kennung der juristischen Person in D365.
Beschreibung Dieses Attribut entspricht DataAreaId in D365 und bezeichnet die juristische Person oder das Unternehmen, in dem die Transaktion stattgefunden hat. Es ist wichtig, um Daten in Umgebungen mit mehreren Unternehmen zu filtern. Außerdem stellt es sicher, dass Rechnungsnummern, die in verschiedenen Unternehmen mehrfach vorkommen können, eindeutig zugeordnet werden. Warum das wichtig ist Entscheidend für die eindeutige Zuordnung in Umgebungen mit mehreren Unternehmen und für regionale Analysen. Woher beziehen Feld DataAreaId in allen Tabellen Beispiele USMFDEMFGBSI
	Fälligkeitsdatum DueDate	Das Datum, bis zu dem die Zahlung eingehen soll.
Beschreibung Das Fälligkeitsdatum ist der Zahlungstermin, der sich aus den Zahlungsbedingungen ergibt. Der Vergleich mit dem tatsächlichen Zahlungsdatum zeigt, ob Zahlungen fristgerecht eingehen, und ermöglicht die Berechnung der Days Sales Outstanding (DSO). Es ist ein Standardfeld im Kundentransaktionsdatensatz. Warum das wichtig ist Grundlage für die Berechnung der fristgerechten Zahlungsquote und die Analyse überfälliger Rechnungen. Woher beziehen CustTrans.DueDate Beispiele 2023-11-302023-12-15
	Geschäftseinheit BusinessUnit	Die für die Rechnung zuständige operative Einheit oder Abteilung.
Beschreibung Dieses Attribut segmentiert Daten nach der internen Organisationsstruktur, etwa nach Elektronik- oder Dienstleistungssparte. In D365 handelt es sich häufig um eine mit der Transaktion verknüpfte Finanzdimension. Im Dashboard zur Durchlaufzeit der Rechnungserstellung ermöglicht es den Vergleich verschiedener Geschäftseinheiten. Warum das wichtig ist Ermöglicht interne Vergleiche, um die effizientesten Abteilungen zu ermitteln. Woher beziehen Finanzdimensionen (DefaultDimension) in CustInvoiceJour Beispiele BU-001Vertrieb-NordDienstleistungen-Global
	Ist automatisiert IsAutomated	Kennzeichen dafür, ob die Aktivität von einem Systemkonto ausgeführt wurde.
Beschreibung Dieses Attribut gibt an, ob ein bestimmter Schritt von einem Benutzer oder einem automatisierten Batchauftrag ausgeführt wurde. Es wird berechnet, indem das Attribut Benutzer mit einer Liste bekannter Systemkonten, etwa „Workflow“ oder „Batch“, abgeglichen wird. Es dient als Grundlage für die KPI „Manuelle Ausgleichsquote“. Warum das wichtig ist Entscheidend, um Automatisierungsmöglichkeiten zu erkennen und den aktuellen Automatisierungsgrad zu messen. Woher beziehen Aus der Logik des Felds User abgeleitet Beispiele truefalse
	Kundengruppe CustomerGroup	Die Klassifizierung oder das Segment, zu dem der Kunde gehört.
Beschreibung Dieses Attribut ordnet Kunden logischen Gruppen zu, etwa Großhandel, Einzelhandel oder konzerninternen Kunden. Es dient dem Vergleich verschiedener Gruppen, zum Beispiel um festzustellen, ob bestimmte Segmente längere Zahlungszyklen oder mehr Streitfälle aufweisen. In D365 entspricht es dem Feld CustGroup. Warum das wichtig ist Ermöglicht den Vergleich der Prozessleistung in verschiedenen Marktsegmenten. Woher beziehen CustTable.CustGroup Beispiele GroßhandelEinzelhandelKonzerninternExport
	Kundenkonto CustomerAccount	Die eindeutige Kennung oder Kontonummer des Kunden.
Beschreibung Das Kundenkonto bezeichnet den konkreten Rechnungsempfänger. In D365 entspricht es dem Feld AccountNum. Eine Gruppierung nach diesem Attribut ermöglicht Analysen zum Zahlungsverhalten, zur Häufigkeit von Streitfällen und zu Ausgleichszeiten für verschiedene Kunden. Warum das wichtig ist Wichtig, um Kunden mit hohem Risiko zu identifizieren und die Leistung nach Kunde zu segmentieren. Woher beziehen CustInvoiceJour.InvoiceAccount oder CustTrans.AccountNum Beispiele US-001DE-550CUST-9921
	Rechnungsbetrag InvoiceAmount	Der Gesamtbetrag der Rechnung.
Beschreibung Dieses Attribut gibt den Geldwert des Rechnungsdokuments an. Es dient dazu, das Gesamtforderungsvolumen in der Debitorenbuchhaltung zu berechnen und das Einziehen hoher Forderungen zu priorisieren. Das Feld befindet sich üblicherweise in der Rechnungstabelle. Warum das wichtig ist Entscheidend für die Analyse finanzieller Auswirkungen und die Identifizierung von Engpässen mit hohen Beträgen. Woher beziehen CustInvoiceJour.InvoiceAmount Beispiele 1500.00250.5010000.00
	Ist ausgeglichen IsCleared	Kennzeichen dafür, ob die Rechnung vollständig ausgeglichen wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob der Saldo der Rechnung durch Zahlung oder Abschreibung auf null gesunken ist. Damit lassen sich offene und abgeschlossene Cases schnell filtern und die durchschnittliche Rechnungszykluszeit berechnen. Warum das wichtig ist Unterscheidet zwischen aktiven und historischen Cases. Woher beziehen Aus dem Vorhandensein eines Datums in CustTrans.Closed abgeleitet 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 dem Kunden ausgestellte Gutschrift darstellt. Es dient zur Berechnung der Gutschriftenquote und zum Ausschluss regulärer Rechnungen aus der Nacharbeitsanalyse. Warum das wichtig ist Dient direkt als Grundlage für das Dashboard zu Gutschriften und Nacharbeitshäufigkeit. Woher beziehen Abgeleitet aus CustInvoiceJour.InvoiceAmount < 0 oder TransType Beispiele truefalse
	Skontofrist CashDiscountDate	Das Datum, bis zu dem ein Skonto für vorzeitige Zahlung gilt.
Beschreibung Dieses Attribut gibt an, bis wann der Kunde Skonto für eine vorzeitige Zahlung erhalten kann. Der Vergleich mit dem Zahlungsdatum ermöglicht die Berechnung der KPI „Entgangene Skonti“ und eine Analyse der Wirksamkeit von Skontoanreizen. Warum das wichtig ist Wichtige Grundlage für das Dashboard zur Optimierung von Skonti bei vorzeitiger Zahlung. Woher beziehen CustTrans.CashDisc oder aus CashDiscCode berechnet Beispiele 2023-11-102023-11-15
	Streitgrund DisputeReason	Der Grundcode, der einem strittigen Case zugewiesen wird.
Beschreibung Dieses Attribut erfasst den Grund für einen Streitfall zu einer Rechnung, etwa „Preisfehler“ oder „beschädigte Ware“. Im Dashboard zum Lebenszyklus der Streitfallbearbeitung hilft es, die Ursachen für Zahlungsverzögerungen zu ermitteln. Warum das wichtig ist Ermöglicht die Ursachenanalyse für die KPI „Bearbeitungszeit von Streitfällen“. Woher beziehen CustTrans.ReasonRefRecId oder die zugehörige Tabelle für Inkassofälle Beispiele PreisabweichungWare beschädigtBestellung fehltServicequalität
	Tage überfällig DaysOverdue	Die Anzahl der Tage, um die die Zahlung nach dem Fälligkeitsdatum einging.
Beschreibung Diese Kennzahl berechnet die Differenz zwischen Zahlungs- und Fälligkeitsdatum. Positive Werte stehen für verspätete, negative Werte für vorzeitige Zahlungen. So lässt sich die Zahlungsleistung genauer beurteilen als mit einfachen Ja-Nein-Kennzeichen. Warum das wichtig ist Ergänzt die Analyse der KPI „Fristgerechte Zahlungsquote“ um weitere Details. Woher beziehen Berechnet: PaymentDate - DueDate Beispiele 50-230
	Verkaufsauftrags-ID SalesOrderId	Die Referenznummer des der Rechnung zugeordneten Verkaufsauftrags.
Beschreibung Dieses Attribut verknüpft die Rechnung mit dem ursprünglichen Verkaufsauftrag. Wenn Daten aus dem Order-to-Cash-Prozess verfügbar sind, ermöglicht es prozessübergreifende Analysen und hilft, vorgelagerte Ursachen für Abrechnungsprobleme zu untersuchen. Warum das wichtig ist Verknüpft den Abrechnungsprozess mit dem Vertriebsprozess. Woher beziehen CustInvoiceJour.SalesId Beispiele SO-10022SO-55912
	Währung Currency	Der Währungscode der Rechnungstransaktion.
Beschreibung Dieses Attribut gibt die Währung an, in der die Rechnung ausgestellt wurde, zum Beispiel USD oder EUR. Es ist wichtig, um Geldbeträge für globale Analysen über verschiedene Regionen hinweg vergleichbar zu machen. Warum das wichtig ist Erforderlich, um die Verteilung von Beträgen in Systemen mit mehreren Währungen zu verstehen. Woher beziehen CustInvoiceJour.CurrencyCode Beispiele USDEURGBPJPY
	Zahlungsbedingungen PaymentTerms	Der Code, der den vereinbarten Zahlungszeitraum festlegt.
Beschreibung Dieses Attribut enthält den Code, der den Zahlungstermin festlegt, zum Beispiel Net30 oder Net60. Damit lässt sich prüfen, ob Kunden ihre jeweiligen Zahlungsbedingungen einhalten und ob das Fälligkeitsdatum korrekt berechnet wurde. Warum das wichtig ist Liefert Kontext zum Fälligkeitsdatum und hilft festzustellen, ob die Zahlungsbedingungen zu großzügig oder zu streng sind. Woher beziehen CustInvoiceJour.Payment oder CustTable.PaymTermId Beispiele Net30Net45CODEOM

Erforderlich Empfohlen Optional

Aktivitäten im Forderungsmanagement

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Zahlungsausgleich zuverlässig zu ermitteln.

8 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Gutschrift ausgestellt	Eine Gutschrift wird gebucht, um den ursprünglichen Rechnungsbetrag zu mindern. Häufig ist sie das Ergebnis eines geklärten Streitfalls oder einer Rücksendung.
Warum das wichtig ist Eine hohe Häufigkeit weist auf Umsatzverluste und Qualitätsprobleme in vorgelagerten Prozessen hin. Anders als eine Zahlung stellt eine Gutschrift einen Ausgleich ohne Geldfluss dar. Woher beziehen Tabelle CustTrans mit Type „Credit Note“ oder CustInvoiceJour mit einem negativen InvoiceAmount. Erfassung Erfasst, wenn die Transaktion in CustTrans gebucht wird Ereignistyp explicit
	Rechnung ausgeglichen	Der abschließende Statuswechsel: Der offene Rechnungsbetrag sinkt auf null und die Transaktion wird im System als „Closed“ gekennzeichnet.
Warum das wichtig ist Das endgültige Ende des Prozessfalls. Dient zur Berechnung der gesamten Zykluszeit. Woher beziehen Datumsfeld CustTrans.Closed. Das Datum wird eingetragen, wenn die Summe der Ausgleichsbuchungen dem Rechnungsbetrag entspricht. Erfassung Aus dem Datumsfeld CustTrans.Closed abgeleitet Ereignistyp inferred
	Rechnung gebucht	Die Rechnung wird erstmals im Finanzbuch erfasst. Dieser Vorgang dokumentiert die Entstehung der Zahlungsverpflichtung in der Tabelle CustInvoiceJour.
Warum das wichtig ist Kennzeichnet den offiziellen Beginn des Debitorenprozesses und den Start der Zahlungsfrist. Wichtig für die Berechnung der Days Sales Outstanding (DSO). Woher beziehen Tabelle CustInvoiceJour. Das Feld CreatedDateTime oder InvoiceDate dient als Timestamp. Erfassung Erfasst, wenn die Transaktion in CustInvoiceJour gebucht wird Ereignistyp explicit
	Rechnung versendet	Die Rechnung wird per E-Mail, Post oder EDI an den Kunden gesendet. Der Versand lässt sich häufig anhand der Erhöhung des Zählers „Printed“ oder über Protokolle der Druckverwaltung ableiten.
Warum das wichtig ist Verzögerungen zwischen Buchung und Versand verkürzen die tatsächliche Zahlungsfrist für den Kunden und können dazu führen, dass Zahlungen als verspätet wahrgenommen werden. Woher beziehen Abgeleitet aus einer Änderung von CustInvoiceJour.PrintedOriginals von 0 auf 1 oder erfasst über die Tabelle PrintJobHeader, sofern die Protokollierung aktiviert ist. Erfassung Statusfeld vorher und nachher vergleichen oder das Protokoll in PrintJobHeader prüfen Ereignistyp inferred
	Streitfall eröffnet	Im Modul Case Management wird ein mit der Rechnung verknüpfter Fall angelegt, der einen Einwand des Kunden kennzeichnet. Dadurch wird der reguläre Forderungseinzug unterbrochen.
Warum das wichtig ist Streitfälle sind eine der Hauptursachen für verspätete Zahlungen. Ihre Erfassung hilft, Qualitätsprobleme in vorgelagerten Prozessen wie Preisgestaltung oder Auftragsabwicklung zu erkennen. Woher beziehen Tabelle CaseDetailBase, in der Category dem Bereich Collections/AR zugeordnet ist und RefRecId auf den Rechnungskontext verweist. Erfassung Erfasst, wenn Transaktion X in Case Management ausgeführt wird Ereignistyp explicit
	Teilzahlung gebucht	Eine Zahlung wird erfasst, deckt den offenen Rechnungsbetrag jedoch nicht vollständig ab. Häufig muss der Restbetrag anschließend weiter eingefordert werden.
Warum das wichtig ist Unterscheidet Ratenzahlungen von vollständigen Ausgleichen. Wichtig für genaue Cashflow-Prognosen. Woher beziehen Tabelle CustSettlement, die eine Zahlung (CustTrans) mit der Rechnung (CustTrans) verknüpft, wobei SettlementAmount < InvoiceAmount gilt. Erfassung Erfasst, wenn Transaktion X in CustSettlement ausgeführt wird Ereignistyp explicit
	Vollständige Zahlung eingegangen	Eine Zahlungstransaktion wird gebucht und deckt den verbleibenden Rechnungsbetrag ab. Damit fließt Geld ein.
Warum das wichtig ist Das wichtigste Ereignis für den Prozesserfolg. Dient zur Berechnung der pünktlichen Zahlungsquote und zur Bewertung von Skontobedingungen. Woher beziehen Tabelle CustTrans mit Type „Payment“, über CustSettlement mit der Rechnung verknüpft, sodass der offene Betrag auf null sinkt. Erfassung Erfasst, wenn die Transaktion in CustTrans gebucht und ausgeglichen wird Ereignistyp explicit
	Zahlungserinnerung versendet	Erfasst den Versand eines formellen Mahnschreibens an den Kunden. Die Daten stammen aus dem Mahnjournal.
Warum das wichtig ist Kennzeichnet den Beginn aktiver Maßnahmen zum Forderungseinzug. Eine Häufigkeitsanalyse hilft, die Mahnstrategie zu verbessern und Verwaltungskosten zu senken. Woher beziehen Tabelle CustCollectionLetterJour. Erfasst das Datum, an dem der Mahncode für die jeweilige Rechnungstransaktion gebucht wurde. Erfassung Erfasst, wenn die Transaktion in CustCollectionLetterJour gebucht wird Ereignistyp explicit
	Forderung abgeschrieben	Die Rechnung wird als uneinbringlich eingestuft und der offene Betrag über ein Abschreibungsjournal ausgebucht. Dies entspricht einem finanziellen Verlust.
Warum das wichtig ist Endzustand eines erfolglosen Forderungseinzugs. Wichtig für die Analyse uneinbringlicher Forderungen und der Wirksamkeit der Kreditrichtlinien. Woher beziehen Tabelle CustTrans mit Type „WriteOff“ oder ein GeneralJournalEntry, das mit einem Abschreibungsgrundcode gekennzeichnet ist. Erfassung Erfasst, wenn die Transaktion mit dem Type WriteOff gebucht wird Ereignistyp explicit
	Kontoauszug abgeglichen	Beim Abgleich wird eine in der Debitorenbuchhaltung erfasste Zahlung einer Position im importierten Kontoauszug zugeordnet.
Warum das wichtig ist Bestätigt, dass das Geld tatsächlich auf dem Bankkonto eingegangen ist. Verzögerungen weisen auf Ineffizienzen in den Prozessen für Kassen- und Bankverwaltung hin. Woher beziehen Abgeglichener Status in BankReconciliationLine oder BankAccountTrans. Erfordert das Modul Advanced Bank Reconciliation. Erfassung Erfasst, wenn die Transaktion im Bankabgleich zugeordnet wird Ereignistyp explicit
	Streitfall geklärt	Der Streitfall wird geschlossen und die Rechnung kann bezahlt oder gutgeschrieben werden. Damit endet der Teilprozess zur Bearbeitung von Ausnahmefällen.
Warum das wichtig ist Die Zeitspanne zwischen „Opened“ und „Resolved“ ist eine wichtige Kennzahl für die Verwaltungseffizienz. Woher beziehen Tabelle CaseDetailBase, in der sich der Status zu Closed/Resolved ändert. Erfassung Statusfeld in CaseDetailBase vorher und nachher vergleichen Ereignistyp inferred
	Streitfall in Prüfung	Zeigt an, dass der Streitfall vom Status „Opened“ in den Status „In Process“ gewechselt ist. Erfasst die Bearbeitungszeit des Klärungsteams.
Warum das wichtig ist Engpässe an dieser Stelle verlängern den Cash Conversion Cycle. Die Kennzahl trennt Wartezeit von aktiver Bearbeitungszeit. Woher beziehen Abgeleitet aus Änderungen des Felds CaseDetailBase.Status oder aus Einträgen in CaseLog, die den Statusverlauf dokumentieren. Erfassung Statusfeld in CaseDetailBase vorher und nachher vergleichen Ereignistyp inferred
	Zahlungsziel überschritten	Ein berechneter Meilenstein: Das aktuelle Datum liegt nach dem Fälligkeitsdatum der Rechnung, die weiterhin offen ist. Die Rechnung gilt damit als überfällig.
Warum das wichtig ist Wichtig für die Altersstrukturanalyse und das Auslösen von Workflows für den Forderungseinzug. Trennt die reguläre Abrechnung vom Forderungsmanagement. Woher beziehen Berechnet durch den Vergleich von CustInvoiceJour.DueDate mit der aktuellen Simulationszeit oder dem Zahlungs-Timestamp. Erfassung Durch Vergleich des Felds DueDate mit der aktuellen Zeit ableiten Ereignistyp calculated
	Zahlungszusage eingegangen	Eine konkrete Zusage, die ein Mitarbeitender im Forderungseinzug erfasst: Der Kunde wird bis zu einem bestimmten Datum zahlen. Die Daten stammen aus dem Modul Collections Management.
Warum das wichtig ist Misst die Wirksamkeit von Gesprächen zum Forderungseinzug. Der Vergleich dieses Datums mit dem tatsächlichen Zahlungseingang zeigt, wie verlässlich Kundenzusagen sind. Woher beziehen Tabelle CustPromiseToPay. Über TransRecId mit der Kundentransaktion verknüpft. Erfassung Erfasst, wenn ein Datensatz in CustPromiseToPay erstellt wird Ereignistyp explicit
	Zinsrechnung erstellt	Bei überfälligen Zahlungen wird eine Zinsrechnung erstellt. Sie weist eine finanzielle Belastung des Kundenkontos aus.
Warum das wichtig ist Weist auf einen erheblichen Zahlungsverzug hin. Die Analyse zeigt, ob Verzugszinsen Zahlungen tatsächlich beschleunigen oder die Kundenbeziehung belasten. Woher beziehen Tabelle CustInterestJour. Sie protokolliert Zinsrechnungen für bestimmte Kundentransaktionen. Erfassung Erfasst, wenn die Transaktion in CustInterestJour gebucht wird Ereignistyp explicit

Anleitungen zur Datenextraktion

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Azure-Ressourcen konfigurieren: Richten Sie eine Azure SQL Database als Ziel für Bring Your Own Database (BYOD) ein. Achten Sie darauf, dass die Verbindungszeichenfolge Zugangsdaten 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 Data Management-Arbeitsbereich ein neues Exportprojekt. Fügen Sie dem Projekt die folgenden Standardentitäten hinzu: CustInvoiceJournalHeaderEntity, CustTransactionEntity, CustSettlementEntity, CustCollectionLetterJournalHeaderEntity, CaseDetailEntity, CaseAssociationEntity, CustInterestJournalEntity, BankAccountTransEntity und CustPromiseToPayEntity.
Quelle und Ziel zuordnen: Prüfen Sie, ob alle Felder korrekt zugeordnet sind. Achten Sie insbesondere darauf, dass RecId und CreatedDateTime enthalten sind, da diese Felder für die zeitliche Reihenfolge der Ereignisse entscheidend sind.
Ersten Export ausführen: Starten Sie den Exportauftrag manuell (Auftragstyp: Export), um historische Daten vollständig in die Azure SQL Database zu laden. Prüfen Sie die Ausführungsübersicht, um sicherzustellen, dass alle Datensätze übertragen wurden.
Inkrementelle Aktualisierungen planen: Richten Sie einen wiederkehrenden Datenauftrag ein, der das Exportprojekt 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: Stellen Sie mit SQL Server Management Studio (SSMS) oder einem ähnlichen Tool eine Verbindung zur BYOD Azure SQL Database her.
Transformationsskript ausführen: Führen Sie das SQL-Skript aus dem folgenden Abfrageabschnitt für die BYOD-Tabellen aus. Das Skript führt die unterschiedlichen Tabellen in einer einheitlichen Event-Log-Struktur zusammen.
Ergebnis prüfen und exportieren: Prüfen Sie die Konsistenz der Ausgabe (siehe Validierungsschritte). Exportieren Sie das Ergebnis als CSV- oder Parquet-Datei, um es in ProcessMind zu laden.

Konfiguration

Exportmethode: Bring Your Own Database (BYOD) oder Azure Data Lake Storage Gen2 (ADLS).
Aktualisierungsstrategie: Vollständiger Push für den ersten Ladevorgang, danach „Incremental push“ für regelmäßige Aktualisierungen, um die Leistung möglichst wenig zu beeinträchtigen.
Erforderliche Entitäten: CustInvoiceJournalHeaderEntity (Rechnungen), CustSettlementEntity (Zahlungen/Ausgleich), CustCollectionLetterJournalHeaderEntity (Mahnungen), CaseDetailEntity (Streitfälle), BankAccountTransEntity (Bankabgleich).
Unternehmensfilter: Filtern Sie nach der Spalte „DataAreaId“, wenn die Analyse auf bestimmte juristische Personen beschränkt werden soll.
Datumsbereich: Empfohlen wird ein rollierender Zeitraum von 12 Monaten auf Grundlage von „InvoiceDate“ oder „TransDate“.
Änderungsnachverfolgung: Damit der inkrementelle Export effizient funktioniert, muss sie für die SQL-Tabellen in D365 aktiviert sein.

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ührungsrechner installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pandas, requests und msal (falls Sie die Microsoft Authentication Library verwenden, obwohl dieses Skript der Einfachheit halber direkte REST-Aufrufe nutzt).
Azure-App-Registrierung: Registrieren Sie eine Anwendung in Azure Active Directory (Entra ID), damit sie auf Dynamics 365 zugreifen kann. Notieren Sie sich Client ID, Client Secret und Tenant ID. Stellen Sie sicher, dass die App über API-Berechtigungen für Dynamics ERP (OData) verfügt.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript. Aktualisieren Sie das config-Dictionary am Anfang des Skripts mit Ihrer D365-URL, Client ID, Client Secret, Tenant ID und dem Zielunternehmenscode (dataAreaId).
Datumsbereich festlegen: Passen Sie im Skript die Variablen start_date und end_date an den gewünschten Extraktionszeitraum an. Für inkrementelle Ladevorgänge empfiehlt sich ein gleitender Zeitraum von 90 bis 180 Tagen.
Daten extrahieren: Führen Sie das Skript aus. Es authentifiziert sich bei Azure AD, ruft ein Zugriffstoken ab und fragt mehrere OData-Entitäten (CustomerInvoices, PaymentJournals, CaseDetails usw.) nacheinander ab.
Daten verarbeiten: Das Skript transformiert die Daten automatisch. Dazu gehören die Umbenennung von Spalten entsprechend dem ProcessMind-Schema, die Berechnung von Ereignissen wie „Fälligkeitsdatum überschritten“ anhand des Systemdatums und die Unterscheidung zwischen Teil- und Vollzahlungen anhand der Transaktionsbeträge.
Zusammenführen und sortieren: Das Skript führt alle Aktivitäts-DataFrames in einem Event Log zusammen und sortiert sie nach InvoiceNumber und EventTimestamp.
Exportieren: Der abschließende DataFrame wird in eine CSV-Datei namens AR_Event_Log.csv exportiert. Prüfen Sie, ob die Datei im Skriptverzeichnis erstellt wurde.
Validieren: Öffnen Sie die CSV-Datei und prüfen Sie, ob die Daten im ISO-Format (YYYY-MM-DD HH:MM:SS) vorliegen und alle erforderlichen Spalten ausgefüllt sind.
Upload: Importieren Sie die erstellte CSV-Datei mit dem standardmäßigen Datei-Upload-Assistenten in ProcessMind. Ordnen Sie die Spalten InvoiceNumber der Case-ID, Activity der Aktivität und EventTimestamp dem Timestamp zu.

Konfiguration

Stapelgröße: Das Skript verwendet eine vom Server festgelegte Standardseitengröße, häufig 1.000 Datensätze. 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 erheblich.
Unternehmensfilter: D365 speichert Daten für mehrere juristische Personen. 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.
Entitätsauswahl: Verwendet Standardentitäten wie CustomerInvoices, CustomerPaymentJournalLines und CaseDetail. Wenn Ihre Organisation benutzerdefinierte Entitäten nutzt, müssen die Endpunkte im Dictionary endpoints angepasst werden.
Berechnete Ereignisse: Ereignisse wie „Fälligkeitsdatum überschritten“ werden während der Skriptausführung berechnet, da sie in der Datenbank kein eigenes Transaktionsprotokoll erzeugen.

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 loslegen?

Verbessern Sie Ihre Finanzprozesse und setzen Sie dieses Daten-Template noch heute ein. Unser Team unterstützt Sie dabei, Ihre Microsoft-Dynamics-365-Daten den Anforderungen entsprechend zuzuordnen.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie Ihr Forderungsmanagement und verbessern Sie jetzt Ihren Cashflow

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

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, Einrichtung in 5 Minuten

Ihr Daten-Template für das Forderungsmanagement

Ihr Daten-Template für das Forderungsmanagement

Attribute des Forderungsmanagements

Aktivitäten im Forderungsmanagement

Anleitungen zur Datenextraktion

Export von Entitäten über das Data Management Framework in D365

Schritte

Konfiguration

Beispielabfrage sql

Python-OData-API-Extraktion für Forderungsereignisse

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie Ihr Forderungsmanagement und verbessern Sie jetzt Ihren Cashflow