> Kontinuierliche Prozessverbesserung > Kreditmanagement und Forderungseinzug > Microsoft Dynamics 365 > Daten Template

Ihr Daten-Template für Kredit- und Forderungsmanagement

Microsoft Dynamics 365

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Kredit- und Forderungsmanagement (19) Aktivitäten im Kredit- und Forderungsmanagement (12) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für Kredit- und Forderungsmanagement

Dieses Template zeigt, welche Daten Sie für die Analyse Ihres Kredit- und Forderungsmanagements erfassen sollten. Es enthält wichtige Datenattribute, relevante Aktivitäten für die Nachverfolgung und praktische Hinweise zur Datenextraktion. Damit bereiten Sie Ihre Daten effizient vor und können schneller mit Process Mining beginnen.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Prozessaktivitäten für eine präzise Analyse
Praktische Hinweise zur Datenextraktion aus Ihrem System

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

Template herunterladen

Attribute für Kredit- und Forderungsmanagement

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihr Kredit- und Forderungsmanagement umfassend zu analysieren.

3 Erforderlich 8 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des konkreten Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Lebenszyklus der Rechnung stattgefunden hat.
Beschreibung Der Aktivitätsname bezeichnet einen bestimmten Schritt oder ein Ereignis im Kredit- und Inkassoprozess, zum Beispiel „Rechnung erstellt“, „Mahnung versendet“ oder „Zahlung eingegangen“. Dieses Attribut ist für Process Mining grundlegend, da es die Knoten in der Prozessübersicht definiert. Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten zeigt den tatsächlichen Prozessablauf und macht Nacharbeitsschleifen, Ineffizienzen und nicht konforme Prozesspfade sichtbar. Das Attribut bildet die Grundlage für alle Visualisierungen des Prozessablaufs und dient dazu, Durchlaufzeiten zwischen den einzelnen Prozessphasen zu berechnen. Warum das wichtig ist Dieses Attribut definiert die Schritte in der Prozessübersicht und ermöglicht so die Visualisierung und Analyse des Rechnungslebenszyklus. Woher beziehen Dieses Attribut wird in der Regel abgeleitet, indem bestimmte Systemereignisse, Statusänderungen oder Erstellungsdaten aus verschiedenen Tabellen, etwa „CustInvoiceJour“, „CustTrans“, „CustCollectionLetterJour“ und „CustPaymPromise“, standardisierten Aktivitätsnamen zugeordnet werden. Beispiele Rechnung gebucht und versendetMahnschreiben erstelltStreitfall registriertZahlung eingegangen
	Ereigniszeitpunkt EventTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt ist das genaue Datum und die Uhrzeit, zu der eine Aktivität im System erfasst wurde. Er ist eine zentrale Grundlage des Process Mining: Die chronologische Reihenfolge der Ereignisse ermöglicht es, den Prozessablauf abzubilden und alle zeitbezogenen Kennzahlen zu berechnen. Dieses Attribut ist unverzichtbar, um Dauern zu analysieren, Engpässe zu erkennen und SLAs zu überwachen. Die Zeit zwischen den Ereignissen „Rechnung erstellt“ und „Zahlung eingegangen“ dient beispielsweise zur Berechnung der Days Sales Outstanding (DSO), einer wichtigen Geschäftskennzahl. Ohne genaue Timestamps lassen sich weder die Leistung analysieren noch Engpässe erkennen. Warum das wichtig ist Dieser Timestamp ist unverzichtbar, um Ereignisse zeitlich zu ordnen, die Prozessübersicht zu ermitteln und Leistungskennzahlen wie Durchlaufzeiten und Dauern zu berechnen. Woher beziehen Dieses Attribut stammt je nach Aktivität aus verschiedenen Datums- und Zeitfeldern in D365-Tabellen, zum Beispiel aus „CreatedDateTime“ in „CustInvoiceJour“ oder „TransDate“ in „CustTrans“. Beispiele 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Rechnungsnummer InvoiceNumber	Die eindeutige Kennung jeder Kundenrechnung und die primäre Case-ID für den Kreditmanagementprozess.
Beschreibung Die Rechnungsnummer ist ein wichtiges Attribut, das jede Finanztransaktion mit einem Kunden eindeutig identifiziert. Sie verknüpft alle zugehörigen Aktivitäten, von der Rechnungserstellung und -buchung bis zum Zahlungseinzug und endgültigen Ausgleich. Beim Process Mining dient diese Nummer dazu, den gesamten Ablauf jeder Rechnung zu rekonstruieren und ihren Lebenszyklus detailliert zu analysieren. Wenn Unternehmen jede Rechnung als eigenen Case verfolgen, können sie häufige Prozesspfade, Engpässe und Abweichungen von der Standardvorgehensweise erkennen. Die Rechnungsnummer bildet die Grundlage für Kennzahlen wie Days Sales Outstanding und für die Analyse von Prozessvarianten. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle Prozessereignisse verknüpft und so die Rekonstruktion und Analyse des gesamten Ablaufs von der Rechnung bis zum Zahlungseingang ermöglicht. Woher beziehen In der Regel ist dies das Feld „Invoice“ in der Tabelle „CustInvoiceJour“ von Microsoft Dynamics 365 Finance. Beispiele INV-0012345CIV-2023-8876SI-9510034
	Inkassoverantwortlicher zugewiesen CollectorAssigned	Der Name des Inkassomitarbeitenden oder Teammitglieds, das für die Bearbeitung der überfälligen Rechnung zuständig ist.
Beschreibung Dieses Attribut gibt an, welcher Mitarbeitende für die Inkassomaßnahmen zu einer bestimmten Rechnung verantwortlich ist. Es ist wichtig für die Leistungs- und Arbeitslastanalyse. Wenn Führungskräfte die Prozessübersicht oder Dashboards nach Inkassoverantwortlichen filtern, können sie die individuelle Produktivität bewerten, Inkassostrategien vergleichen und Möglichkeiten für gezielte Unterstützung erkennen. Das Attribut ist eine wichtige Dimension in den Dashboards „Produktivität des Inkassoteams“ und „Durchlaufzeit der Streitfallklärung“, da es Prozessresultate bestimmten Personen oder Teams zuordnet. Warum das wichtig ist Ermöglicht die Leistungsanalyse des Inkassoteams, unterstützt eine ausgewogene Arbeitsverteilung und macht durch den Vergleich der Wirksamkeit einzelner Inkassoverantwortlicher bewährte Vorgehensweisen sichtbar. Woher beziehen Lesen Sie die Dokumentation zu Microsoft Dynamics 365. Die Daten könnten aus einem Inkassomodul oder aus Feldern zur Benutzerverantwortung in Kunden- oder Transaktionsdatensätzen stammen. Beispiele John SmithEmily JonesInkassoteam A
	Kundenname CustomerName	Der offizielle Name des Kunden, an den die Rechnung ausgestellt wurde.
Beschreibung Der Kundenname gibt an, welcher Kunde einer Rechnung zugeordnet ist. Dieses Attribut ist eine wichtige Dimension zum Filtern und Gruppieren. Eine Analyse nach Kunden zeigt, welche Kunden wiederholt verspätet zahlen, Streitfälle melden oder umfangreiche Inkassomaßnahmen erfordern. Das Attribut ist wichtig für das Dashboard „Durchlaufzeit der Streitfallklärung“ und für detaillierte Analysen einzelner Kundenkonten. Warum das wichtig ist Ermöglicht Prozessanalysen für einzelne Kunden. So lassen sich Muster erkennen und Beziehungen zu wichtigen oder problematischen Kundenkonten gezielt steuern. Woher beziehen Diese Information wird in der Regel anhand der in „CustInvoiceJour“ enthaltenen Kundennummer aus „CustTable“ übernommen. Beispiele Contoso Ltd.Adventure WorksFabrikam Inc.
	Kundensegment CustomerSegment	Eine Einteilung der Kunden, zum Beispiel nach Größe, Branche oder strategischer Bedeutung.
Beschreibung Das Kundensegment ist ein kategoriales Attribut, mit dem Kunden in aussagekräftige Gruppen eingeteilt werden, zum Beispiel „Strategische Kunden“, „KMU“ oder „Öffentlicher Sektor“. Diese Segmentierung ist für strategische Analysen wichtig. Sie hilft bei Fragen wie: „Haben strategische Kunden einen niedrigeren DSO?“ oder „Treten Abschreibungen in bestimmten Branchen häufiger auf?“ Das Attribut wird direkt in den Dashboards „Days Sales Outstanding im Zeitverlauf“, „Abschreibungen uneinbringlicher Rechnungen“ und „Überfällige Rechnungen nach Segment“ verwendet. So werden Erkenntnisse auf einer übergeordneten Ebene möglich, die über einzelne Kunden hinausgehen. Warum das wichtig ist Ermöglicht aggregierte Analysen von Kundengruppen, macht strategische Trends sichtbar und unterstützt die Anpassung der Inkassostrategien an die jeweiligen Segmente. Woher beziehen Dies ist häufig ein benutzerdefiniertes Feld oder wird aus Attributen der „CustTable“ (Kundenstammtabelle) abgeleitet. Beispiele EnterpriseMittelstandÖffentlicher SektorPartner
	Mahnstufe DunningLevel	Gibt die aktuelle Stufe oder Dringlichkeit des Mahn- und Inkassoprozesses für eine überfällige Rechnung an.
Beschreibung Die Mahnstufe bezeichnet den Schritt in einem strukturierten Mahnverfahren, zum Beispiel „Stufe 1: freundliche Erinnerung“, „Stufe 2: formelle Mahnung“ oder „Stufe 3: letzte Mahnung“. Die Erfassung dieses Attributs ist wichtig, um die Wirksamkeit der Inkassostrategie zu bewerten. Das Dashboard „Wirksamkeit der Mahnstrategie“ zeigt damit, welcher Anteil der Rechnungen nach Erreichen der jeweiligen Stufe bezahlt wird. So können Unternehmen ihre Mahn-Workflows verbessern, um Zahlungseingänge zu sichern und gleichzeitig die Kundenbeziehungen zu pflegen. Warum das wichtig ist Diese Kennzahl ist entscheidend, um die Wirksamkeit der Mahnstrategie zu messen und festzustellen, in welcher Phase Kunden am ehesten zahlen. Woher beziehen Diese Information findet sich in Tabellen zu Inkasso und Mahnschreiben, zum Beispiel in „CustCollectionLetterJour“. Beispiele 123 - Letzte MahnungRechtliche Schritte
	Rechnungsbetrag InvoiceAmount	Der Gesamtbetrag der Rechnung.
Beschreibung Der Rechnungsbetrag entspricht dem Gesamtwert der abgerechneten Waren oder Dienstleistungen. Dieses Attribut ist eine wichtige Grundlage für die Finanzanalyse des Prozesses. Anhand des Rechnungswerts lassen sich Cases gruppieren und Unterschiede erkennen: Folgen Rechnungen mit hohem Wert einem anderen Prozess oder kommt es bei ihnen häufiger zu Verzögerungen? Das Attribut ist wichtig für die Dashboards „Abschreibungen uneinbringlicher Rechnungen“ und „Analyse des Kreditlimits“. Damit lässt sich die finanzielle Auswirkung beziffern und das Risiko bewerten. Warum das wichtig ist Ermöglicht die Analyse finanzieller Auswirkungen, die Priorisierung hochwertiger Rechnungen und die Untersuchung, wie sich der Rechnungswert auf den Prozess auswirkt. Woher beziehen Wahrscheinlich das Feld „InvoiceAmount“ in der Tabelle „CustInvoiceJour“. Beispiele 1500.7525000.00549.99
	Rechnungsstatus InvoiceStatus	Der aktuelle Status der Rechnung in ihrem Lebenszyklus.
Beschreibung Der Rechnungsstatus zeigt, an welcher Stelle des Prozesses sich eine Rechnung befindet, zum Beispiel „Offen“, „Bezahlt“, „Beanstandet“ oder „Abgeschrieben“. Das Aktivitätsprotokoll enthält zwar den detaillierten Verlauf, doch der aktuelle Status eignet sich gut als Case-Attribut zum Filtern und für Berichte auf hoher Ebene. Analysten können die Daten damit schnell eingrenzen, etwa auf offene überfällige Rechnungen, oder die Merkmale aller abgeschriebenen Rechnungen untersuchen. So lässt sich der aktuelle Stand der Forderungen einfach nachvollziehen. Warum das wichtig ist Ermöglicht das schnelle Filtern und Analysieren von Rechnungen nach ihrem aktuellen Status, zum Beispiel die Konzentration auf alle offenen oder beanstandeten Cases. Woher beziehen Abgeleitet aus dem Ausgleichsstatus der Transaktionen in der Tabelle „CustTrans“. Eine offene Transaktion ist unbezahlt, eine geschlossene ist ausgeglichen. Beispiele OffenBezahltTeilweise bezahltAbgeschrieben
	Überfällige Tage DaysOverdue	Die Anzahl der Tage, um die eine Rechnung nach ihrem Zahlungsfälligkeitsdatum überfällig ist.
Beschreibung „Überfällige Tage“ ist eine berechnete Kennzahl, die misst, wie viel Zeit seit dem Zahlungsfälligkeitsdatum einer unbezahlten Rechnung vergangen ist. Sie wird berechnet, indem das Zahlungsfälligkeitsdatum vom aktuellen Datum abgezogen wird. Für das Inkassoteam ist dies eine wichtige Leistungskennzahl, da sie dabei hilft, Rechnungen zu priorisieren. Sie ist die zentrale Kennzahl im Dashboard „Überfällige Rechnungen nach Segment“ und grundlegend für die Bewertung der Forderungen und der Wirksamkeit von Inkassomaßnahmen. Warum das wichtig ist Diese wichtige operative Kennzahl hilft dabei, Inkassomaßnahmen zu priorisieren und das Ausmaß von Zahlungsverzögerungen zu messen. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: WENN die Rechnung unbezahlt ist, DANN (Heute() - Zahlungsfälligkeitsdatum), SONST 0. Beispiele 1532910
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Datum, bis zu dem die Rechnung laut Zahlungsbedingungen zu begleichen ist.
Beschreibung Das Zahlungsfälligkeitsdatum ist ein wichtiges Datumsattribut, das sich aus den mit dem Kunden vereinbarten Zahlungsbedingungen ergibt. Es dient als Grundlage dafür, festzustellen, ob eine Rechnung überfällig ist. Außerdem löst es Inkassomaßnahmen aus, etwa den Versand von Zahlungserinnerungen oder den Beginn eines formellen Mahnverfahrens. Beim Process Mining wird es zur Berechnung der Kennzahl „Überfällige Tage“ und zur Prüfung der Einhaltung von Mahnrichtlinien verwendet. So lässt sich beispielsweise kontrollieren, ob eine Zahlungserinnerung innerhalb von X Tagen nach Fälligkeit versendet wurde. Warum das wichtig ist Dieses Datum dient als Maßstab für die Pünktlichkeit von Zahlungen und löst alle Aktivitäten im Zusammenhang mit überfälligen Rechnungen und dem Inkasso aus. Woher beziehen In der Regel ist dies das Feld „DueDate“ in den Tabellen „CustTrans“ oder „CustInvoiceJour“. Beispiele 2023-02-142023-03-312023-04-30
	Beanstandet IsDisputed	Ein boolesches Kennzeichen dafür, ob eine Rechnung jemals beanstandet wurde.
Beschreibung Dieses berechnete Kennzeichen wird auf „true“ gesetzt, wenn ein Rechnungs-Case die Aktivität „Streitfall registriert“ enthält. Es vereinfacht die Analyse, da Benutzer die Prozessabläufe beanstandeter und nicht beanstandeter Rechnungen einfach filtern und vergleichen können. So lässt sich beispielsweise der durchschnittliche DSO beanstandeter Rechnungen mit dem nicht beanstandeter Rechnungen vergleichen, um die Auswirkungen von Streitfällen auf den Cashflow zu beziffern. Das Attribut eignet sich für Dashboards auf hoher Ebene und vergleichende Analysen. Warum das wichtig ist Vereinfacht Analyse und Filterung, da sich beanstandete und nicht beanstandete Rechnungen leicht vergleichen lassen. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: WENN der Case die Aktivität „Streitfall registriert“ enthält, DANN true, SONST false. Beispiele truefalse
	Dauer der Streitfallklärung DisputeResolutionTime	Die Zeit von der erstmaligen Registrierung eines Streitfalls bis zu seiner Klärung.
Beschreibung Die Dauer der Streitfallklärung misst die Effizienz des Prozesses zur Bearbeitung von Streitfällen. Sie wird als Zeitspanne zwischen den Aktivitäten „Streitfall registriert“ und „Streitfall geklärt“ berechnet. Eine lange Klärungsdauer kann Zahlungen verzögern und die Kundenzufriedenheit beeinträchtigen. Wird die Kennzahl nach Inkassoverantwortlichem oder Beanstandungsgrund aufgeschlüsselt, lassen sich Engpässe und Verbesserungsmöglichkeiten im Workflow zur Streitfallverwaltung erkennen. Warum das wichtig ist Misst die Effizienz der Bearbeitung von Streitfällen, die häufig zu erheblichen Zahlungsverzögerungen führen. Woher beziehen Berechnet als Zeitspanne zwischen den Timestamps der Aktivitäten „Streitfall registriert“ und „Streitfall geklärt“. Beispiele 7.215.83.5
	Grund der Beanstandung DisputeReason	Der vom Kunden angegebene Grund für die Beanstandung einer Rechnung.
Beschreibung Wenn Kunden eine Rechnung beanstanden, geben sie in der Regel einen Grund an, zum Beispiel „Falsche Preisangabe“, „Ware beschädigt“ oder „Doppelte Abrechnung“. Dieses Attribut erfasst den jeweiligen Grund. Die Analyse der Beanstandungsgründe ist wichtig, um Ursachen zu ermitteln. Sie macht wiederkehrende Probleme im Prozess von der Bestellung bis zum Zahlungseingang sichtbar, etwa in den Bereichen Vertrieb, Versand oder Abrechnung. Beanstandungen an ihrer Ursache zu reduzieren, ist ein wichtiges Ziel dieser Analyse. So lassen sich Zahlungsverzögerungen vermeiden und der DSO direkt beeinflussen. Warum das wichtig ist Liefert wichtige Daten zur Ursachenanalyse von Zahlungsverzögerungen und hilft, vorgelagerte Probleme zu erkennen und zu beheben, die zu Rechnungsbeanstandungen führen. Woher beziehen Lesen Sie die Dokumentation zu Microsoft Dynamics 365. Die Daten gehören zur Funktion für Streitfall- oder Fallverwaltung. Beispiele PreisfehlerFehlende MengeProdukt nicht erhaltenLeistung weicht von der Beschreibung ab
	Kreditlimit CreditLimit	Der für den Kunden genehmigte maximale Kreditbetrag.
Beschreibung Das Kreditlimit ist der maximale Schuldenbetrag, den ein Kunde eingehen darf. Dieses Attribut ist für das Risikomanagement entscheidend. Das Dashboard „Analyse des Kreditlimits“ vergleicht den Wert mit den Rechnungsbeträgen überfälliger oder abgeschriebener Kundenkonten. So lässt sich feststellen, ob Kreditlimits angemessen festgelegt und eingehalten werden. Außerdem wird sichtbar, ob Kunden, die ihre Zahlungen einstellen, kurz zuvor eine Erhöhung ihres Limits erhalten haben. Das kann auf Schwachstellen im Kreditgenehmigungsprozess hinweisen. Warum das wichtig ist Dieses Attribut ist für die Risikobewertung wichtig. Damit lässt sich untersuchen, ob Abschreibungen mit schlecht verwalteten oder zu niedrig angesetzten Kreditlimits zusammenhängen. Woher beziehen Dieser Wert ist in der Regel im Kundenstammsatz in „CustTable“ gespeichert. Beispiele 10000.0050000.000.00
	Land Country	Das Land der Rechnungsadresse des Kunden.
Beschreibung Dieses Attribut gibt das Land des Kundenkontos an. Es ist eine gängige Dimension für geografische Analysen. Werden Prozesskennzahlen wie DSO oder Abschreibungsquoten nach Ländern aufgeschlüsselt, zeigen sich regionale Unterschiede beim Zahlungsverhalten, bei der Wirksamkeit des Inkassos oder bei den wirtschaftlichen Rahmenbedingungen. Daraus können regional angepasste Inkassostrategien oder unterschiedliche Zahlungsbedingungen für bestimmte Regionen abgeleitet werden. Warum das wichtig ist Ermöglicht geografische Analysen, um regionale Muster beim Zahlungsverhalten und bei der Leistung des Inkassoprozesses zu erkennen. Woher beziehen Dieser Wert wird abgeleitet, indem der Kundenstammsatz („CustTable“) mit dem primären Adressdatensatz verknüpft wird, der sich häufig in „LogisticsPostalAddress“ befindet. Beispiele USADEUGBRCAN
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Datenaktualisierung oder -aktualisierung.
Beschreibung Dieses Attribut gibt an, wann der Datensatz zuletzt aus dem Quellsystem aktualisiert wurde. Für Benutzer der Process-Mining-Analyse ist diese Metainformation wichtig, da sie zeigt, wie aktuell die Daten sind. Wenn bekannt ist, bis zu welchem Zeitpunkt die Daten reichen, können Analysten fundierte Entscheidungen treffen und die Reichweite ihrer Erkenntnisse einschätzen. Der Wert wird in der Regel während der Datenaufnahme auf den gesamten Datensatz angewendet. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten. So ist klar, welchen Zeitraum die Analysen abdecken, und Entscheidungen auf Grundlage veralteter Informationen werden vermieden. Woher beziehen Dieser Wert wird bei der Ausführung von der ETL- beziehungsweise Datenpipeline erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-04-01T02:00:00Z2023-04-02T02:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem System die Daten stammen.
Beschreibung Dieses Attribut gibt die Quellanwendung an, in der die Ereignisdaten erfasst wurden. In diesem Fall wäre das „Microsoft Dynamics 365“. Bei einer Analyse mit nur einem System mag der Wert unveränderlich erscheinen, doch für Data Governance, Fehlerbehebung und künftige Integrationen ist er wichtig. Werden Daten aus weiteren Systemen einbezogen, etwa aus einem separaten CRM oder einem Portal eines Inkassodienstleisters, lassen sich die Quellen anhand dieses Feldes unterscheiden und der systemübergreifende Prozess vollständig nachvollziehen. Warum das wichtig ist Sorgt für eine klare Datenherkunft und ist wichtig, um die Datenqualität zu sichern und Analysen über mehrere integrierte Systeme hinweg zu ermöglichen. Woher beziehen In der Regel wird während der Datenextraktion ein statischer Wert hinzugefügt, der die Herkunft der Datensätze kennzeichnet. Beispiele Microsoft Dynamics 365D365 F&O
	Währungscode CurrencyCode	Die Währung der Rechnung, zum Beispiel USD oder EUR.
Beschreibung Der Währungscode gibt die Transaktionswährung des Rechnungsbetrags an. Für international tätige Unternehmen ist dieses Kontextattribut besonders wichtig. Es ermöglicht die korrekte Interpretation von Finanzwerten und kann zeigen, ob Zahlungszyklen oder Probleme mit bestimmten Währungen zusammenhängen, etwa aufgrund von Wechselkursfragen oder der Abwicklung internationaler Zahlungen. Warum das wichtig ist Liefert den nötigen Kontext für alle Geldbeträge und ermöglicht die Analyse von Prozessen mit mehreren Währungen. Woher beziehen In der Regel ist dies das Feld „CurrencyCode“ in der Tabelle „CustInvoiceJour“. Beispiele USDEURGBPCAD

Erforderlich Empfohlen Optional

Aktivitäten im Kredit- und Forderungsmanagement

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Workflow im Kredit- und Forderungsmanagement präzise zu analysieren.

9 Empfohlen 3 Optional

	Aktivität	Beschreibung
	Mahnschreiben erstellt	Zeigt an, dass für die überfällige Rechnung ein formelles Mahn- oder Einzugsschreiben erstellt wurde. Das Ereignis wird erfasst, wenn der regelmäßige Mahnlauf in Dynamics 365 ausgeführt wird und Schreiben für die betreffenden Rechnungen erstellt.
Warum das wichtig ist Erfasst den Beginn und die Häufigkeit formeller Einzugsmaßnahmen. Diese Daten sind wichtig, um die Wirksamkeit des Mahnverfahrens und die Einhaltung interner Richtlinien für den Forderungseinzug zu messen. Woher beziehen In der Tabelle Dunning History (CustCollectionLetterJour) wird ein expliziter Datensatz erstellt. Das Erstellungsdatum des Mahnjournals dient als Timestamp. Erfassung Extrahieren Sie Erstellungsereignisse aus der Tabelle CustCollectionLetterJour und verknüpfen Sie sie mit der jeweiligen Rechnung. Ereignistyp explicit
	Rechnung abgeschrieben	Die Rechnung gilt als uneinbringlich und wird offiziell als Forderungsausfall abgeschrieben. Diese Aktion führt ein autorisierter Benutzer explizit aus. Dabei wird die Forderung ausgebucht und der Verlust verbucht.
Warum das wichtig ist Dies ist der wichtigste erfolglose Endpunkt des Prozesses. Die Erfassung von Abschreibungen ist entscheidend, um Kreditrisiken, fehlgeschlagene Inkassomaßnahmen und finanzielle Verluste zu verstehen. Woher beziehen Erfasst anhand einer bestimmten Hauptbuchtransaktion zur Abschreibung uneinbringlicher Forderungen, die mit der ursprünglichen Rechnung verknüpft ist. Als Timestamp dient das Buchungsdatum des Abschreibungsjournals. Erfassung Ermitteln Sie Journaleinträge mit einem bestimmten Buchungsprofil für Abschreibungen, die auf die Rechnung verweisen. Ereignistyp explicit
	Rechnung ausgeglichen	Die Rechnung ist vollständig bezahlt und ihr Saldo beträgt null. Damit ist der Prozess erfolgreich abgeschlossen. Dieser Status wird abgeleitet, wenn die Summe der zugeordneten Zahlungen dem Rechnungsbetrag entspricht.
Warum das wichtig ist Dies ist der wichtigste erfolgreiche Endpunkt des Prozesses von der Kreditvergabe bis zum Zahlungseingang. Die Analyse der Pfade, die hier enden, zeigt bewährte Vorgehensweisen und effiziente Prozessvarianten. Woher beziehen Abgeleitet aus dem Ausgleichsdatum in der Kundenausgleichstabelle (CustSettlement). Dies ist der Fall, wenn die Felder „AmountCur“ und „SettleAmountCur“ für die Rechnung in CustTrans zusammen null ergeben. Erfassung Ermitteln Sie das letzte Ausgleichsdatum der Rechnungstransaktion, durch das der Saldo auf null sinkt. Ereignistyp inferred
	Rechnung erstellt	Kennzeichnet die Erstellung eines Verkaufsrechnungsdatensatzes im System, bevor die Rechnung offiziell gebucht wird. Diese Aktivität wird in der Regel als explizites Ereignis erfasst, wenn ein Benutzer einen Verkaufsauftrag abschließt und das zugehörige Rechnungsdokument erstellt.
Warum das wichtig ist Dies ist das primäre Start-Event im Lebenszyklus einer Rechnung. Die Zeitspanne von diesem Zeitpunkt bis zum Zahlungseingang ist entscheidend für die Messung des Days Sales Outstanding (DSO). Woher beziehen Wird bei der Rechnungserstellung in der Tabelle Sales Invoice Header (SalesInvoiceHeader) oder Sales Table (SalesTable) erfasst. Der Erstellungs-Timestamp des Datensatzes dient als Ereigniszeitpunkt. Erfassung Erfassen Sie den Erstellungs-Timestamp des Verkaufsrechnungsdatensatzes. Ereignistyp explicit
	Rechnung gebucht und versendet	Bezeichnet die offizielle Erfassung der Rechnung im Hauptbuch, durch die sie zu einer formalen Forderung wird. Dieses Ereignis fällt in der Regel mit dem Versand der Rechnung an den Kunden zusammen und wird erfasst, sobald der Buchungslauf in Dynamics 365 abgeschlossen ist.
Warum das wichtig ist Dieser wichtige Meilenstein setzt den Beginn der Zahlungsfrist und der Fälligkeitsberechnung. Verzögerungen zwischen Erstellung und Buchung können auf Ineffizienzen im Abrechnungsprozess hinweisen. Woher beziehen Abgeleitet aus dem Buchungsdatum im Customer Invoice Journal (CustInvoiceJour) oder einer Statusänderung zu „Gebucht“. Der Buchungs-Timestamp ist der entscheidende Datenpunkt. Erfassung Verwenden Sie den Buchungs-Timestamp aus dem Customer Invoice Journal (CustInvoiceJour). Ereignistyp inferred
	Streitfall registriert	Zeigt an, dass der Kunde die Rechnung offiziell beanstandet hat und ihr Status entsprechend aktualisiert wurde. Dies wird in der Regel erfasst, wenn ein Benutzer den Rechnungsstatus im Inkassomodul auf „Beanstandet“ setzt.
Warum das wichtig ist Dies ist der Ausgangspunkt für die Klärung des Streitfalls. Die Erfassung hilft dabei, die Häufigkeit von Streitfällen und die Dauer bis zu ihrer Klärung zu messen. Beides wirkt sich auf die Kundenzufriedenheit und den Cashflow aus. Woher beziehen Abgeleitet aus einer Statusänderung in der Kundentransaktion (CustTrans) oder einer zugehörigen Tabelle für die Streitfallverwaltung (smmCaseDetail). Erforderlich ist ein mit Timestamp versehener Änderungsprotokolleintrag. Erfassung Ermitteln Sie, wann das Feld für den Streitfallstatus einer Rechnung befüllt oder auf „Beanstandet“ geändert wird. Ereignistyp inferred
	Zahlung eingegangen	Zeigt an, dass eine Kundenzahlung eingegangen und im System erfasst wurde, in der Regel über ein Zahlungsjournal. Dieses Ereignis liegt vor der endgültigen Buchung und Zuordnung des Zahlungseingangs zur jeweiligen Rechnung.
Warum das wichtig ist Dieser Meilenstein ist entscheidend für die Berechnung des DSO und das Verständnis des Cashflows. Die Zeit zwischen diesem Ereignis und „Zahlung gebucht“ macht Engpässe bei der Zuordnung von Zahlungseingängen sichtbar. Woher beziehen Ein explizites Ereignis, erfasst anhand des Erstellungsdatums einer Zeile im Kundenzahlungsjournal (LedgerJournalTrans), bevor diese gebucht wird. Es entspricht dem Datum, an dem der Zahlungseingang erfasst wurde. Erfassung Verwenden Sie das Transaktionsdatum aus den Zeilen des Kundenzahlungsjournals. Ereignistyp explicit
	Zahlung gebucht	Steht für die offizielle Buchung der Kundenzahlung im Hauptbuch und ihre Zuordnung zum Ausgleich einer Rechnung. Erfasst wird das Buchungsdatum des Kundenzahlungsjournals.
Warum das wichtig ist Damit ist der Zahlungsteil des Prozesses abgeschlossen. Die Zeit zwischen Zahlungseingang und Buchung, die Verzögerung bei der Zuordnung von Zahlungseingängen, ist eine wichtige Effizienzkennzahl für die Finanzabteilung. Woher beziehen Erfasst anhand des Buchungs-Timestamps des Kundenzahlungsjournals (LedgerJournalTrans). Damit wird bestätigt, dass die Zahlung vollständig im Hauptbuch verarbeitet wurde. Erfassung Verwenden Sie das Buchungsdatum des gebuchten Kundenzahlungsjournals. Ereignistyp explicit
	Zahlungsziel überschritten	Ein berechnetes Ereignis, das eintritt, wenn das aktuelle Datum nach dem Fälligkeitsdatum der Rechnung liegt. Diese Aktivität entspricht keiner direkten Benutzeraktion, sondern wird durch den Vergleich des Systemdatums mit dem Fälligkeitsfeld der Rechnung abgeleitet.
Warum das wichtig ist Dieses Ereignis löst alle Maßnahmen zum Forderungseinzug aus. Es ermöglicht die Analyse überfälliger Rechnungen und der Rechtzeitigkeit von Mahnmaßnahmen und unterstützt Kennzahlen wie die Einhaltung der Mahnrichtlinien. Woher beziehen Wird berechnet, indem der aktuelle Timestamp mit dem Feld „DueDate“ in der Tabelle Customer Transactions (CustTrans) verglichen wird. Als Ereigniszeitpunkt dient das DueDate selbst. Erfassung Erstellen Sie ein Ereignis, wenn „NOW()“ nach dem DueDate der Rechnung liegt. Ereignistyp calculated
	Einzugsaktivität protokolliert	Bezeichnet eine manuelle Maßnahme zum Forderungseinzug, etwa einen Anruf oder eine E-Mail, die beim Kunden oder bei der Rechnung protokolliert wird. Das Ereignis wird erfasst, wenn ein Mitarbeitender im Forderungseinzug die Funktion „Aktivitäten“ im Arbeitsbereich für den Forderungseinzug verwendet, um den Kontakt zu dokumentieren.
Warum das wichtig ist Macht den manuellen Aufwand des Teams im Forderungseinzug sichtbar. Durch den Vergleich dieser Aktivitäten mit dem Zahlungserfolg lassen sich die Produktivität des Teams und die Wirksamkeit verschiedener Kontaktwege messen. Woher beziehen Wird in den Tabellen Activities (smmActivities) oder in zugehörigen Fallmanagementtabellen zum Kundenkonto protokolliert. Verknüpfen Sie die Aktivität nach Möglichkeit mit einer bestimmten Rechnung. Erfassung Erfassen Sie die Erstellung von Activity-Datensätzen mit dem Typ „Phone Call“ oder „Email“, die sich auf den Forderungseinzug beziehen. Ereignistyp explicit
	Streitfall geklärt	Kennzeichnet den Abschluss des Streitfalls, nachdem eine Lösung gefunden und dokumentiert wurde. Das Ereignis wird erfasst, wenn ein Benutzer den Streitfallstatus einer Rechnung auf „Geklärt“ setzt oder den zugehörigen Streitfall schließt.
Warum das wichtig ist Mit dieser Aktivität endet der Teilprozess zur Klärung des Streitfalls. Die Dauer zwischen der Registrierung und der Klärung ist eine wichtige KPI zur Messung der Effizienz des Klärungsteams. Woher beziehen Abgeleitet aus einer Statusänderung in der Kundentransaktion (CustTrans) oder aus dem Schließen des zugehörigen Streitfalls (smmCaseDetail). Der Timestamp dieser Statusänderung ist der Ereigniszeitpunkt. Erfassung Ermitteln Sie, wann das Feld für den Streitfallstatus einer Rechnung geleert oder auf „Geklärt“ geändert wird. Ereignistyp inferred
	Zahlungszusage erfasst	Ein Kunde sagt zu, an einem bestimmten zukünftigen Datum zu zahlen, und diese Zusage wird im System erfasst. Das Ereignis wird ausdrücklich protokolliert, wenn ein Mitarbeitender im Forderungseinzug im entsprechenden Modul eine Zahlungszusage einträgt.
Warum das wichtig ist Erfasst informelle Zahlungsvereinbarungen und deren Einhaltungsquote. Der Vergleich von Zusagen mit tatsächlichen Zahlungseingängen kann bei der Cashflow-Prognose helfen und Aufschluss über die Zuverlässigkeit von Kunden geben. Woher beziehen Wird wahrscheinlich in Tabellen zum Arbeitsbereich für den Forderungseinzug oder zum Fallmanagement erfasst, insbesondere in Tabellen für Zahlungszusagen. Der Erstellungszeitpunkt des Zusagedatensatzes dient als Ereigniszeitpunkt. Erfassung Erfassen Sie Erstellungsereignisse aus einer Detailtabelle zu Zahlungszusagen oder Inkassofällen. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Microsoft Dynamics 365

Schritte

Voraussetzungen prüfen: Stellen Sie sicher, dass Ihre Organisation Microsoft Dynamics 365 Finance verwendet und Bring Your Own Database (BYOD) eingerichtet ist, sodass Datenentitäten aktiv in eine Azure SQL Database exportiert werden. Sie benötigen Anmeldedaten mit Lesezugriff auf diese Azure SQL Database.
Datenentitäten ermitteln: Prüfen Sie, ob die erforderlichen Datenentitäten aus Dynamics 365 in Ihre BYOD-Datenbank exportiert werden. Für diesen Prozess sind insbesondere folgende Entitäten relevant: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment und CustDispute. Falls Entitäten fehlen, richten Sie ihren Export im Data Management-Arbeitsbereich von Dynamics 365 ein.
Mit der BYOD-Datenbank verbinden: Stellen Sie mit einem SQL-Client, zum Beispiel SQL Server Management Studio (SSMS) oder Azure Data Studio, eine Verbindung zur Azure SQL Database her, die als BYOD-Ziel dient.
SQL-Abfrage vorbereiten: Kopieren Sie die vollständige T-SQL-Abfrage aus dem Abschnitt query dieses Dokuments in Ihren SQL-Client. Die Abfrage führt alle erforderlichen Aktivitäten und Attribute in einem Event-Log-Format zusammen.
Abfrageparameter festlegen: Suchen Sie die Platzhalter am Anfang der Abfrage. Ersetzen Sie '{CompanyCode}' durch die ID der Dynamics-365-Gesellschaft, die Sie analysieren möchten, zum Beispiel „USMF“. Ersetzen Sie '{StartDate}' und '{EndDate}' durch den gewünschten Datumsbereich im Format „YYYY-MM-DD“.
Abfrage ausführen: Führen Sie die angepasste Abfrage für die BYOD-Datenbank aus. Die Ausführungszeit hängt vom Datenvolumen im ausgewählten Zeitraum ab.
Ergebnisse prüfen: Nach Abschluss der Abfrage wird das Event Log im Ergebnisbereich angezeigt. Jede Zeile steht für eine bestimmte Aktivität im Lebenszyklus einer Rechnung im Kredit- und Forderungsmanagement. Prüfen Sie die Daten auf Vollständigkeit und Richtigkeit.
Event Log exportieren: Exportieren Sie die Abfrageergebnisse in eine CSV-Datei. Die meisten SQL-Clients bieten dafür eine integrierte Funktion. Klicken Sie mit der rechten Maustaste auf das Ergebnisraster und wählen Sie eine Option wie „Save Results As“ oder „Export“.
Upload vorbereiten: Stellen Sie sicher, dass die exportierte CSV-Datei UTF-8-codiert ist und die Spaltenüberschriften den erforderlichen Attributen entsprechen: InvoiceNumber, ActivityName, EventTime sowie den empfohlenen Attributen, die Sie aufgenommen haben. Anschließend können Sie die Datei in ProcessMind hochladen.

Konfiguration

Voraussetzungen: Zugriff auf eine Microsoft-Dynamics-365-for-Finance-Instanz, in der Bring Your Own Database (BYOD) eingerichtet ist und ausgeführt wird. Für die Azure SQL Database, in die exportiert wird, ist Lesezugriff erforderlich.
Datenentitäten: Für die Extraktion müssen mehrere Standarddatenentitäten in BYOD exportiert werden. Stellen Sie mindestens sicher, dass CustInvoiceJour, CustTrans, CustTable und CustSettlement im BYOD-Exportauftrag enthalten sind. Für bestimmte Aktivitäten werden weitere Entitäten benötigt, etwa CustCollectionLetterJour.
Datumsbereich: Begrenzen Sie die Abfrage unbedingt auf einen bestimmten Zeitraum, um die Leistung zu sichern. Für eine erste Analyse empfehlen sich Daten aus einem Zeitraum von 3 bis 6 Monaten. Die bereitgestellte Abfrage verwendet dafür die Platzhalter '{StartDate}' und '{EndDate}'.
Unternehmensfilter: Filtern Sie die Abfrage nach einer bestimmten juristischen Person (Company Code), damit die Daten konsistent sind. Geben Sie das zu analysierende Unternehmen über den Platzhalter '{CompanyCode}' an.
Leistungsaspekte: Bei sehr großen Datensätzen, die mehrere Jahre oder Unternehmen umfassen, kann die Abfrage lange dauern. Führen Sie sie nach Möglichkeit außerhalb der Spitzenzeiten aus oder schränken Sie den Datenumfang mit zusätzlichen Filtern ein. Stellen Sie sicher, dass in den BYOD-Tabellen geeignete Indizes für Datums- und Schlüsselfelder vorhanden sind.

a Beispielabfrage sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

Schritte

Voraussetzungen und Einrichtung der Umgebung: Stellen Sie sicher, dass Python 3.8 oder neuer installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install pandas requests msal. Außerdem benötigen Sie die Anmeldedaten eines Service Principals mit Zugriff auf die Dynamics-365-Umgebung.
Anwendung in Azure AD registrieren: Öffnen Sie das Azure-Active-Directory-Portal und registrieren Sie eine neue Anwendung, um eine Client-ID und eine Tenant-ID zu erhalten. Erstellen Sie im Bereich „Certificates & secrets“ ein neues Client Secret für die Anwendung. Bewahren Sie Client-ID, Tenant-ID und Client Secret sicher auf.
API-Berechtigungen erteilen: Fügen Sie in den Einstellungen „API permissions“ der registrierten Anwendung in Azure AD eine Berechtigung hinzu. Wählen Sie „Dynamics ERP“ oder einen vergleichbaren Eintrag für Dynamics 365 und erteilen Sie die delegierte Berechtigung „user_impersonation“. Erteilen Sie anschließend die Administratorzustimmung für Ihre Organisation.
Dynamics-365-Benutzer erstellen: Erstellen Sie in Dynamics 365 Finance and Operations einen dedizierten Anwendungsbenutzer. Verknüpfen Sie ihn mit der Client-ID Ihrer Azure-AD-Anwendung. Weisen Sie diesem Benutzer eine Sicherheitsrolle mit Lesezugriff auf alle erforderlichen Datenentitäten zu, zum Beispiel CustInvoiceJour, CustCollectionLetterJour, CustSettlements und smmActivities.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_d365_collections.py. Tragen Sie oben im Skript die Platzhalterwerte für Ihre D365-Umgebungs-URL, Tenant-ID, Client-ID, Client Secret und das Standardunternehmen (dataAreaId) ein.
Extraktionsparameter festlegen: Passen Sie die Variablen start_date und end_date im Skript an den gewünschten Zeitraum für die Datenextraktion an. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_d365_collections.py. Das Skript authentifiziert sich, fragt die OData-Endpunkte für jede der 12 Aktivitäten ab und verarbeitet die API-Seitennavigation automatisch.
Daten für jede Aktivität abrufen: Das Skript ruft nacheinander Daten zur Rechnungserstellung, Buchung, Mahnung, Zahlung und zu weiteren wichtigen Ereignissen ab. Jede Abfrage richtet sich an eine bestimmte Datenentität und wählt nur die erforderlichen Felder aus, um die Leistung zu verbessern.
Daten transformieren und zusammenführen: Mit der Bibliothek pandas verarbeitet das Skript die JSON-Antworten der API-Aufrufe. Es wandelt die Daten in eine strukturierte Tabelle um, vereinheitlicht die Spaltennamen und führt anschließend die Daten aller Aktivitäten in einem gemeinsamen Event Log zusammen.
Abgeleitete Ereignisse berechnen: Die Aktivität „Zahlungsfälligkeit überschritten“ wird nicht direkt im System erfasst. Das Skript durchläuft alle im angegebenen Zeitraum überfälligen Rechnungen und erzeugt für jede eine entsprechende Zeile.
Event Log exportieren: Nach der Verarbeitung und Zusammenführung speichert das Skript das fertige Event Log im selben Verzeichnis als CSV-Datei mit dem Namen d365_collections_event_log.csv. Diese Datei ist für den Upload in ein Process-Mining-Tool vorbereitet.

Konfiguration

API-Endpunkt-URL: Die Basis-URL Ihrer Dynamics-365-Finance-and-Operations-Umgebung. Verwenden Sie das Format https://[your-environment-name].operations.dynamics.com.
Anmeldedaten: Das Skript benötigt eine Tenant-ID, eine Client-ID und ein Client Secret aus der Registrierung einer Azure-Active-Directory-Anwendung. Diese Anwendung muss die Berechtigung für den Zugriff auf die Dynamics-365-API erhalten.
Unternehmensfilter (dataAreaId): Dynamics 365 unterstützt mehrere Unternehmen. Das Skript fragt über den Filter dataAreaId ein bestimmtes Unternehmen ab. Setzen Sie die Variable default_company auf die richtige juristische Person, zum Beispiel „USMF“.
Datumsbereich: Mit den Parametern start_date und end_date legen Sie den Extraktionszeitraum fest. Beginnen Sie am besten mit einem aktuellen Zeitraum von 3 bis 6 Monaten, um das Datenvolumen zu begrenzen und die Extraktion zeitnah abzuschließen. Der Filter wird hauptsächlich auf das Erstellungsdatum der Rechnung angewendet.
Leistungsaspekte: Bei sehr großen Datensätzen kann die Extraktion über die OData-API lange dauern und von Microsoft gedrosselt werden. Bei Leistungsproblemen empfiehlt es sich, kleinere Zeiträume abzufragen oder die Extraktion außerhalb der Spitzenzeiten auszuführen.
Voraussetzungen: Erforderlich ist eine Python-Umgebung ab Version 3.8 mit den Bibliotheken pandas, requests und msal. Der zugehörige Dynamics-365-Benutzer benötigt Lesezugriff auf die Module für Finanzen, Vertrieb und Forderungsmanagement, insbesondere auf die im Skript genannten Entitäten.

a Beispielabfrage python

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

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template gezielt vor und gewinnen Sie wertvolle Erkenntnisse zu Ihrem Kredit- und Forderungsmanagement. Optimieren Sie Ihren Prozess noch heute, damit Zahlungen schneller eingehen.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie Ihr Kredit- und Forderungsmanagement für schnellere Zahlungseingänge

Verbessern Sie Ihren Cashflow, indem Sie den Credit-to-Cash-Prozess effizienter gestalten und die Durchlaufzeit um 30 % senken.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für Kredit- und Forderungsmanagement

Ihr Daten-Template für Kredit- und Forderungsmanagement

Attribute für Kredit- und Forderungsmanagement

Aktivitäten im Kredit- und Forderungsmanagement

Anleitungen zur Datenextraktion

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

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Dynamics 365 OData REST API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie Ihr Kredit- und Forderungsmanagement für schnellere Zahlungseingänge

Ihr Daten-Template für Kredit- und Forderungsmanagement

Ihr Daten-Template für Kredit- und Forderungsmanagement

Attribute für Kredit- und Forderungsmanagement

Aktivitäten im Kredit- und Forderungsmanagement

Anleitungen zur Datenextraktion

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

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Dynamics 365 OData REST API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie Ihr Kredit- und Forderungsmanagement für schnellere Zahlungseingänge

Der Schutz Ihrer Daten ist uns wichtig