> Kontinuierliche Prozessverbesserung > Forderungen aus Lieferungen und Leistungen > HighRadius > Daten Template

Ihr Daten-Template für das Forderungsmanagement

HighRadius

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Forderungsmanagements(19) Aktivitäten im Forderungsmanagement(13) Anleitungen zum Datenexport(2)

Ihr Daten-Template für das Forderungsmanagement

Dieses Template zeigt die wesentlichen Bestandteile für die Analyse Ihrer Rechnungs-Workflows in HighRadius. Es bietet einen strukturierten Überblick über die erforderlichen Datenpunkte, Prozessmeilensteine und technischen Schritte zum Aufbau eines umfassenden Event Logs. Mit dieser Anleitung können Sie Ihren Forderungseinzug abbilden und Möglichkeiten zur Verbesserung Ihres Cashflows erkennen.

Spezifische Datenattribute für Ihren Prozess
Standardisierte Aktivitätsmeilensteine
Anleitung zum Datenexport aus HighRadius

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

Template herunterladen

Attribute des Forderungsmanagements

Diese Tabelle enthält die empfohlenen Datenfelder für ein detailliertes Event Log, mit dem Sie Ihre Rechnungsverwaltung und den Erfolg Ihres Forderungseinzugs analysieren können.

3 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die Bezeichnung des Ereignisses oder der Aktion, die für die Rechnung ausgeführt wurde.
Beschreibung Dieses Attribut erfasst den konkreten Schritt oder die Aktion im Credit-to-Cash-Lebenszyklus. Dazu zählen beispielsweise die Rechnungserstellung, automatisierte Schreiben, Anrufe im Forderungseinzug, die Erfassung von Streitfällen und die Zuordnung von Zahlungen. Analysten verwenden dieses Feld, um den Prozessablauf zu rekonstruieren und die Reihenfolge der Schritte darzustellen. Abweichungen in der Abfolge machen Prozessabweichungen, Nachbearbeitungsschleifen und nicht konformes Verhalten sichtbar. Warum das wichtig ist Es definiert die Prozessschritte und ist für die Prozesserkennung und Variantenanalyse unverzichtbar. Woher beziehen Aktivitätsprotokoll, Notizenverlauf oder Transaktionsverlauf von HighRadius Beispiele Rechnung erstelltZahlungserinnerung versendetZahlungsstreitfall eröffnetVollständige Zahlung eingegangen
	Ereignis-Timestamp EventDateTime	Datum und Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt eines Ereignisses im HighRadius-System. Es liefert die zeitliche Grundlage, um Aktivitäten zu ordnen und die Dauer zwischen Prozessschritten zu berechnen. In der Analyse dient der Timestamp zur Berechnung von Durchlaufzeiten, etwa der Days Sales Outstanding (DSO) oder der Dauer bis zur Klärung eines Streitfalls. Außerdem ermöglicht er, Durchsatz und Ressourcenauslastung für bestimmte Zeiträume auszuwerten. Warum das wichtig ist Genaue Zeitangaben sind erforderlich, um alle zeitbasierten KPIs zu berechnen und Ereignisse korrekt zu ordnen. Woher beziehen Timestamp-Spalte der HighRadius-Transaktionsprotokolle Beispiele 2023-10-01T08:30:00Z2023-10-15T14:22:10Z2023-11-05T09:15:00Z
	Rechnungsnummer InvoiceNumber	Die eindeutige Kennung des Rechnungsbelegs, die als Case-ID dient.
Beschreibung Die Rechnungsnummer ist die zentrale Kennung, mit der die Zahlungsverpflichtung von der Erstellung bis zum endgültigen Ausgleich verfolgt wird. Sie verknüpft alle zugehörigen Aktivitäten, darunter Streitfälle, Zahlungszusagen und Zahlungen, in einer gemeinsamen Case-Historie. In der Analyse dient dieses Attribut dazu, Event Logs nach einzelnen Prozessinstanzen zu gruppieren. So lassen sich Durchlaufzeiten pro Rechnung berechnen. Außerdem ist es der Primärschlüssel, über den Prozessdaten mit anderen Stammdatentabellen in HighRadius oder im Quell-ERP verknüpft werden. Warum das wichtig ist Damit wird der eindeutige Case identifiziert und sichergestellt, dass alle Ereignisse der richtigen Finanztransaktion zugeordnet sind. Woher beziehen Rechnungsdaten von HighRadius, Rechnungskopftabelle oder Quell-ERP (z. B. SAP VBAK, Oracle Headers) Beispiele INV-2023-001900123456US-102938550002931
	Abweichung von Zahlungszielen PaymentTermVariance	Anzahl der Tage zwischen Fälligkeitsdatum und Zahlungseingang.
Beschreibung Dieses berechnete Attribut misst die Abweichung von den vereinbarten Zahlungsbedingungen. Ein positiver Wert bedeutet eine verspätete Zahlung, ein negativer Wert eine vorzeitige Zahlung. Es ist die direkte Kennzahl für die Prüfung der Einhaltung von Zahlungszielen. Durch die Auswertung dieser Abweichungen können Unternehmen systematische Spätzahler erkennen und ihre Kreditbedingungen oder Inkassostrategien entsprechend anpassen. Warum das wichtig ist Direktes Maß dafür, ob Kunden die vertraglichen Zahlungsbedingungen einhalten. Woher beziehen Berechnet aus Fälligkeitsdatum und Zahlungsdatum Beispiele 5 Tage-2 Tage0 Tage
	Automatisiert IsAutomated	Kennzeichnet, ob das System die Aktivität ohne menschliches Eingreifen ausgeführt hat.
Beschreibung Dieses boolesche Attribut unterscheidet zwischen Schritten, die von der Automatisierungs-Engine von HighRadius ausgeführt werden, etwa automatisierten Schreiben oder der Zahlungszuordnung, und manuellen Schritten von Benutzern. Es ist wichtig für den Tracker zur Automatisierung der Zahlungszuordnung und die KPI zur automatisierten Rechnungsbearbeitung. Analysten können damit den ROI der Automatisierung messen und Prozessschritte erkennen, die weiterhin umfangreiche manuelle Bearbeitung erfordern. Warum das wichtig ist Misst die Effizienz der HighRadius-Implementierung. Woher beziehen Aktivitätsprotokoll (Abgleich von Systembenutzer und menschlichem Benutzer) Beispiele truefalse
	Fälligkeitsdatum DueDate	Das Datum, bis zu dem der Kunde vertraglich zur Zahlung verpflichtet ist.
Beschreibung Das Fälligkeitsdatum ergibt sich aus den Zahlungsbedingungen und dem Rechnungsdatum. Es ist der maßgebliche Termin für den Forderungseinzug. Durch den Vergleich mit dem Datum des vollständigen Zahlungseingangs lässt sich die Einhaltungsquote der Zahlungsbedingungen berechnen. So wird ermittelt, ob eine Zahlung fristgerecht, verspätet oder vorzeitig eingeht. Warum das wichtig ist Dient als Bezugspunkt, um Zahlungsverzug festzustellen und Days Sales Outstanding (DSO) zu berechnen. Woher beziehen Rechnungskopftabelle (Fälligkeitsdatumsfeld) Beispiele 2023-11-302023-12-15
	Kundenname CustomerName	Der Name des Kundenkontos, dem die Rechnung zugeordnet ist.
Beschreibung Dieses Attribut bezeichnet die Partei, die für die Zahlung der Rechnung verantwortlich ist. In HighRadius ist es mit dem Debitorenstammsatz verknüpft. Die Auswertung der Prozessleistung nach Kundennamen zeigt, welche Konten eine angepasste Einzugsstrategie erfordern oder regelmäßig verspätet zahlen. Sie unterstützt das Dashboard zur Kundenrisiko- und Außenstandsmatrix. Warum das wichtig ist Unverzichtbar, um die Analyse nach Kundenkonten aufzuschlüsseln und problematische Kunden zu erkennen. Woher beziehen Kundenstammdaten oder Rechnungskopf Beispiele Acme CorpGlobal IndustriesTechStart IncRetail Giant Ltd
	Name des Mitarbeitenden im Forderungseinzug CollectorName	Der Name des Mitarbeitenden oder Benutzers, der für die Aktivität im Forderungseinzug verantwortlich ist.
Beschreibung Dieses Attribut identifiziert den HighRadius-Benutzer oder Mitarbeitenden, der manuelle Aktivitäten ausgeführt hat, etwa einen Anruf protokolliert, eine individuelle E-Mail versendet oder einen Streitfall geprüft hat. Im Dashboard zu Produktivitätskennzahlen im Forderungseinzug dient es dazu, die individuelle Leistung und die Arbeitsverteilung zu bewerten. So können Führungskräfte Schulungsbedarf erkennen oder die Fallbestände im Team neu verteilen. Warum das wichtig ist Ermöglicht die Analyse der Leistung auf Ressourcenebene. Woher beziehen Aktivitätsprotokoll/Benutzertabelle Beispiele John DoeJane SmithSystemadministratorCollectionAgent_01
	Rechnungsbetrag InvoiceAmount	Der Gesamtbetrag der Rechnung.
Beschreibung Dieses Attribut enthält den ursprünglich dem Kunden in Rechnung gestellten Gesamtbetrag. Er dient als Grundlage für die Berechnung offener Salden und die Bewertung der finanziellen Auswirkungen von Streitfällen oder Verzögerungen. Bei der Process-Mining-Analyse werden Cases anhand dieses Felds nach ihrem Wert gewichtet. So lassen sich beispielsweise vorrangig zu bearbeitende Forderungen mit hohem Wert von geringfügigen administrativen Fällen unterscheiden, die in die KPI zum Volumen geringfügiger Streitfälle einfließen. Warum das wichtig ist Ermöglicht eine Gewichtung der Analyse nach finanziellen Auswirkungen statt allein nach der Anzahl der Cases. Woher beziehen Rechnungskopftabelle (Betragsfeld) Beispiele 1500.00250.5010000.00
	Bonitätseinstufung CreditRating	Der Bonitätsscore oder die Bonitätseinstufung des Kunden.
Beschreibung Dieses Attribut gibt die Risikostufe des Kunden an. Die Daten stammen häufig von Auskunfteien oder aus internen Bewertungen in der HighRadius Credit Cloud. In der Kundenrisiko- und Fälligkeitsmatrix dient es als Dimension. Werden überfällige Forderungen nach Bonitätseinstufung ausgewertet, lassen sich hohe Risiken erkennen, etwa wenn Kunden mit schlechter Bonität hohe offene Beträge haben. Warum das wichtig ist Unverzichtbar für das Risikomanagement und die Priorisierung des Inkassos. Woher beziehen Kreditmanagementmodul / Kundenstamm Beispiele AAAB+Hohes RisikoGeringes Risiko
	Geschäftseinheit BusinessUnit	Der interne Geschäftsbereich oder die Tochtergesellschaft, die die Rechnung ausgestellt hat.
Beschreibung Dieses Attribut gliedert Daten nach der Organisationsstruktur, etwa nach „Vertrieb Nordamerika“, „Dienstleistungen EMEA“ oder einzelnen Produktbereichen. Damit können Sie bei der Prüfung der Einhaltung von Zahlungsbedingungen die Leistung verschiedener Organisationseinheiten vergleichen. So lässt sich feststellen, ob Probleme beim Forderungseinzug die gesamte Organisation betreffen oder auf bestimmte Geschäftspraktiken beschränkt sind. Warum das wichtig ist Ermöglicht den Vergleich verschiedener Geschäftsbereiche. Woher beziehen Rechnungskopf/ERP-Zuordnung Beispiele UnterhaltungselektronikIndustrieteileSoftwaredienstleistungenNordamerika-West
	Grundcode des Zahlungsstreitfalls DisputeReasonCode	Der einem Streitfall zugewiesene Kategoriecode.
Beschreibung Dieses Attribut klassifiziert den Grund, aus dem ein Kunde die Zahlung verweigert, etwa „Preisfehler“, „beschädigte Ware“ oder „fehlende Unterlagen“. In HighRadius Deductions Cloud sind dafür Standardcodes hinterlegt. Die Auswertung dieser Codes hilft, die Ursachen ausbleibender Zahlungen zu erkennen. Durch die Zusammenführung der Daten kann das Unternehmen vorgelagerte Probleme in Vertrieb oder Logistik beheben, die den Forderungseinzug verzögern. Warum das wichtig ist Entscheidend für die Ursachenanalyse verspäteter Zahlungen. Woher beziehen Modul für die Verwaltung von Streitfällen und Abzügen Beispiele P01 (Preisgestaltung)Q02 (Qualität)S03 (Fehlmenge)Administrativer Fehler
	Kundensegment CustomerSegment	Einteilung des Kunden nach Größe, Branche oder strategischem Wert.
Beschreibung Dieses Attribut ordnet Kunden Kategorien wie „Strategisch“, „Mittelstand“, „KMU“ oder „Hohes Risiko“ zu. Im Dashboard zur Leistung bei der Streitfallklärung zeigt es, ob Kunden verschiedener Segmente unterschiedlich betreut werden. So können Sie prüfen, ob Kunden mit hohem Wert im Inkassoprozess angemessen berücksichtigt werden. Warum das wichtig ist Segmentanalysen zur Abstimmung auf die Geschäftsstrategie und Service-Level-Vereinbarungen. Woher beziehen Kundenstammdaten Beispiele Strategischer SchlüsselkundeGroßhandelEinzelhandelÖffentlicher Sektor
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung der Daten im Process-Mining-Modell.
Beschreibung Dieses Attribut erfasst, wann der Datensatz aus dem Process-Mining-Datensatz extrahiert oder zuletzt aktualisiert wurde. So erkennen Analysten, wie aktuell die Daten sind und mit welchen Verzögerungen in Berichten zu rechnen ist. Bei Dashboards zur laufenden Überwachung ist diese Information besonders wichtig. Benutzer sehen so, ob die Daten aktuell sind oder aus einer Momentaufnahme vom Vortag stammen. Warum das wichtig ist Es macht transparent, wie aktuell die für KPIs verwendeten Daten sind. Woher beziehen ETL-Timestamp Beispiele 2023-12-01T00:00:00Z2023-12-02T06:00:00Z
	Offener Betrag OpenAmount	Der noch nicht beglichene Restbetrag der Rechnung.
Beschreibung Dieses Attribut erfasst den Betrag, den der Kunde noch schuldet. Es wird aktualisiert, sobald Teilzahlungen verbucht werden. Für die Analyse der Komplexität von Teilzahlungen ist es unverzichtbar. Analysten können damit vollständig offene von teilweise bezahlten Rechnungen unterscheiden und Inkassomaßnahmen auf hohe offene Beträge konzentrieren. Warum das wichtig ist Entscheidend für die Bewertung des aktuellen Forderungsrisikos und des Erfolgs bei Teilzahlungen. Woher beziehen Rechnungskopf / Tabelle offener Posten Beispiele 0.00500.0012000.00
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Dieses Attribut zeigt an, ob ein Datenpunkt direkt in einem Modul der HighRadius-Plattform entstanden ist, etwa in Collections Cloud oder Cash Application Cloud, oder aus einem externen ERP-System wie SAP oder Oracle übernommen wurde. Es unterstützt die Datenherkunftsanalyse und Validierung. Wenn Sie Prozessverzögerungen untersuchen, hilft die Kenntnis des Quellsystems dabei, Verzögerungen bei der Integration von der Verarbeitungszeit im System zu unterscheiden. Warum das wichtig ist Es gibt Aufschluss über die Datenherkunft, insbesondere wenn mehrere ERP-Systeme Daten an HighRadius liefern. Woher beziehen Systemkonfiguration oder fest anhand der Extraktionslogik hinterlegt Beispiele HighRadiusSAP ECCOracle NetSuiteMicrosoft Dynamics
	Region Region	Geografische Region der Rechnung oder des Kunden.
Beschreibung Dieses Attribut bezeichnet das für die Transaktion relevante geografische Gebiet, zum Beispiel „Nordamerika“, „EMEA“ oder „APAC“. Es ermöglicht regionale Vergleiche und zeigt, wie sich kulturelle oder regulatorische Unterschiede auf das Zahlungsverhalten und die Dauer des Inkassos auswirken. Zudem eignet es sich für Berichte auf Führungsebene. Warum das wichtig ist Ermöglicht die Analyse der Leistung nach geografischen Regionen. Woher beziehen Kundenstammdaten oder Rechnungskopf Beispiele NordamerikaEMEALateinamerikaAPAC
	Währungscode CurrencyCode	Der ISO-Währungscode des Rechnungsbetrags.
Beschreibung Dieses Attribut gibt an, in welcher Währung die Rechnung ausgestellt wurde, zum Beispiel USD, EUR oder GBP. Bei der Analyse eines globalen Prozesses ist diese Angabe erforderlich, um die Felder Rechnungsbetrag und offener Betrag korrekt auszuwerten. Sie stellt sicher, dass Summen richtig gebildet werden, in der Regel durch Umrechnung in eine Berichtswährung. Warum das wichtig ist Erforderlich für korrekte Finanzsummen in Umgebungen mit mehreren Währungen. Woher beziehen Rechnungskopf Beispiele USDEURGBPJPY
	Zugesagtes Zahlungsdatum PromiseToPayDate	Das Datum, an dem der Kunde eine Zahlung zugesagt hat.
Beschreibung Dieses Attribut erfasst das Datum, zu dem sich ein Kunde während eines Inkassogesprächs zur Zahlung verpflichtet hat. Es ist eine wichtige Funktion der HighRadius Collections Cloud. Für den Index zur Zuverlässigkeit von Zahlungszusagen wird dieses Datum mit dem tatsächlichen Zahlungseingang verglichen. So lässt sich feststellen, ob der Kunde seine Zusage eingehalten hat. Außerdem können Sie damit die Verbindlichkeit der Zusage und die Verhandlungsführung des zuständigen Mitarbeitenden bewerten. Warum das wichtig ist Wichtig für die Cashflow-Prognose und die Bewertung der Zuverlässigkeit von Kunden. Woher beziehen Inkassomodul / P2P-Transaktionstabelle Beispiele 2023-12-102023-12-20

Erforderlich Empfohlen Optional

Aktivitäten im Forderungsmanagement

Diese Einträge stehen für wichtige Prozessschritte und Transaktionsmeilensteine, die Sie erfassen sollten, um den gesamten Rechnungsprozess zu visualisieren.

8 Empfohlen 5 Optional

	Aktivität	Beschreibung
	Kontoauszugsposten zugeordnet	Die Zahlungszuordnungs-Engine oder ein Benutzer ordnet erfolgreich eine Position des Kontoauszugs dieser Rechnung zu.
Warum das wichtig ist Zentrale Kennzahl für die automatisierte Zahlungszuordnungsquote. Sie unterscheidet zwischen dem Eingang und der Zuordnung von Zahlungen. Woher beziehen Modul „Cash Application“; Erstellung des Zuordnungsdatensatzes. Erfassung Wird protokolliert, wenn eine Zuordnungsregel ausgeführt wird. Ereignistyp explicit
	Rechnung ausgeglichen	Die abschließende Statusänderung: Der offene Rechnungsbetrag beträgt null und die Rechnung wird im System geschlossen.
Warum das wichtig ist Liefert den End-Timestamp für die durchschnittlichen Days Sales Outstanding. Markiert den Abschluss des Prozesses. Woher beziehen Rechnungskopftabelle; Status = „Geschlossen“ oder „Ausgeglichen“. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred
	Rechnung erstellt	Die Rechnung wird erstmals erstellt oder aus dem ERP-System in die HighRadius-Plattform übernommen. Damit beginnt der Forderungseinzug.
Warum das wichtig ist Liefert den Ausgangs-Timestamp für die Berechnung der Außenstandsdauer und der Kennzahl Days Sales Outstanding (DSO). Woher beziehen Tabelle „Offene Rechnungen“ oder Datenintegrationsprotokolle, in denen die Rechnungsnummer erstmals erscheint. Erfassung Wird protokolliert, wenn ein Datensatz in die Rechnungskopftabelle eingefügt wird. Ereignistyp explicit
	Vollständige Zahlung eingegangen	Der Zahlungseingang gleicht die Forderung vollständig aus. Für die Berechnung der Außenstandsdauer gilt dies als Zahlungsdatum.
Warum das wichtig ist Dient zur Berechnung der Quote eingehaltenen Zahlungszusagen und zum Vergleich des tatsächlichen mit dem erwarteten Cashflow. Woher beziehen Transaktionsdatum der Zahlung, das dem abschließenden Ausgleichsbeleg zugeordnet ist. Erfassung Protokolliertes Transaktionsdatum der Ausgleichszahlung. Ereignistyp explicit
	Zahlungserinnerung versendet	Ein automatisiertes Schreiben (E-Mail oder Brief), das über das Collections-Modul an den Kunden gesendet wird. Damit wird die Ausführung der Mahnstrategie erfasst.
Warum das wichtig ist Wichtig für das Dashboard zur Wirksamkeit von Zahlungserinnerungen: Es zeigt, ob ein Schreiben tatsächlich eine Zahlung auslöst. Woher beziehen Register „Korrespondenzverlauf“ oder Mitteilungsprotokolle mit Bezug zur Rechnungs-ID. Erfassung Wird protokolliert, wenn die Mahnstrategie eine Aktion ausführt. Ereignistyp explicit
	Zahlungsstreitfall eröffnet	Ein Abzugs- oder Streitfall wird mit der Rechnung verknüpft. Dies zeigt an, dass der Kunde die Zahlung eines Teils oder des gesamten offenen Betrags verweigert.
Warum das wichtig ist Löst die Analyse der Leistung bei der Klärung von Zahlungsstreitigkeiten aus und setzt das reguläre Mahnverfahren für den strittigen Betrag aus. Woher beziehen Modul „Abzüge/Streitfälle“; Erstellungs-Timestamp der mit der Rechnung verknüpften Case-ID. Erfassung Wird protokolliert, wenn ein Streitfall erstellt wird. Ereignistyp explicit
	Zahlungsstreitfall geklärt	Die Prüfung des Streitfalls ist abgeschlossen und führt zu einer Entscheidung, etwa zur Anerkennung eines berechtigten Abzugs oder zur Ablehnung einer unbegründeten Forderung.
Warum das wichtig ist Beendet die Messung der Durchlaufzeit zur Klärung des Streitfalls. Verzögerungen an dieser Stelle wirken sich direkt auf die Außenstandsdauer aus. Woher beziehen Abzugsmodul; Statuswechsel zu „Geschlossen“, „Geklärt“ oder „Genehmigt“. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred
	Zahlungszusage erfasst	Eine formelle Zusage im System, in der ein Kunde verspricht, einen bestimmten Betrag bis zu einem festgelegten Datum zu zahlen.
Warum das wichtig ist Wichtig für den Zuverlässigkeitsindex von Zahlungszusagen: Er dient dazu, den Cashflow vorherzusagen und die Zuverlässigkeit der Kunden zu messen. Woher beziehen Mit der Rechnung verknüpftes P2P-Modul/Register. Erfassung Wird protokolliert, wenn ein P2P-Datensatz erstellt wird. Ereignistyp explicit
	Gutschrift ausgestellt	Eine Gutschrift wird erstellt, um den Rechnungsbetrag zu mindern. Häufig ist dies die Folge eines berechtigten Streitfalls oder einer Rücksendung.
Warum das wichtig ist Erfasst die Effizienz der Gutschriftenbearbeitung und die Zeit zwischen der Klärung eines Streitfalls und der Buchung. Woher beziehen Synchronisierungsprotokolle des ERP-Systems oder Gutschriftentabelle mit Bezug zur ursprünglichen Rechnungs-ID. Erfassung Wird protokolliert, wenn das Gutschriftsdokument mit der Rechnung verknüpft wird. Ereignistyp explicit
	Teilzahlung gebucht	Eine Zahlung wird verbucht, die nur einen Teil des Rechnungsbetrags abdeckt. Ein Restbetrag bleibt offen.
Warum das wichtig ist Fließt in die Komplexitätsanalyse von Teilzahlungen ein und weist auf mögliche Schwierigkeiten bei der Zahlungszuordnung hin. Woher beziehen Modul „Cash Application“; Zahlungstransaktion mit der Rechnung verknüpft, bei der der Zahlungsbetrag unter dem offenen Betrag liegt. Erfassung Wird protokolliert, wenn eine Zahlung zugeordnet wird, der Status aber weiterhin „Offen“ lautet. Ereignistyp explicit
	Telefonat zum Forderungseinzug protokolliert	Eine manuelle Notiz oder Interaktion eines Mitarbeitenden im Forderungsmanagement zu dieser Rechnung. Sie weist auf einen manuellen Eingriff in den Prozess hin.
Warum das wichtig ist Unterstützt die Auswertung von Produktivitätskennzahlen im Forderungseinzug und unterscheidet zwischen automatisierten und manuellen Aktivitäten. Woher beziehen Register „Notizen/Verlauf“ im Collections-Modul. Erfassung Wird protokolliert, wenn ein Benutzer eine Gesprächsnotiz speichert. Ereignistyp explicit
	Zahlungsfrist abgelaufen	Ein berechnetes Ereignis, das anzeigt, dass die Rechnung nach dem vereinbarten Zahlungstermin noch offen ist.
Warum das wichtig ist Wichtig für die Prüfung der Einhaltung von Zahlungsbedingungen. Markiert den Übergang von „Aktuell“ zu „Überfällig“. Woher beziehen Wird berechnet, indem das Fälligkeitsdatum der Rechnung mit dem aktuellen Datum (bei offenen Rechnungen) oder dem Zahlungsdatum (bei ausgeglichenen Rechnungen) verglichen wird. Erfassung Durch Vergleich des Felds „Fälligkeitsdatum“ mit dem Aktivitätsdatum ermitteln. Ereignistyp calculated
	Zahlungsstreitfall in Prüfung	Der Streitfall wechselt von „Neu“ in den Status „Aktive Prüfung“. Damit beginnt die eigentliche Bearbeitung durch den Analysten.
Warum das wichtig ist Wird im Engpass-Finder für Streitfall-Workflows verwendet, um die Zeit zwischen der Erstellung und dem Beginn der aktiven Bearbeitung zu messen. Woher beziehen Prüfprotokoll des Abzugsmoduls; Statuswechsel zu „In Bearbeitung“ oder „Wird geprüft“. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred

Anleitungen zum Datenexport

So exportieren Sie Ihre Daten aus HighRadius

Schritte

Melden Sie sich bei der HighRadius Integrated Receivables-Plattform an und öffnen Sie das Modul Analytics oder Reports.
Suchen Sie die Berichtsvorlage Transaction History oder Open Items. Wahrscheinlich müssen Sie drei separate Exporte einrichten, um den gesamten Lebenszyklus abzubilden: Rechnungskopfdaten, Aktivitäten zum Forderungseinzug und Streitfall-/Abzugshistorie.
Richten Sie den Export der Rechnungskopfdaten ein: Wählen Sie die Spalten Invoice Number, Customer Name, Invoice Amount, Invoice Date, Due Date, Clear Date und Final Status aus. Filtern Sie nach den relevanten Company Codes und einem Erstellungszeitraum, der Ihr Process-Mining-Zeitfenster abdeckt.
Richten Sie den Export der Aktivitäten zum Forderungseinzug ein: Wählen Sie die Spalten Invoice Number, Activity Type (Call, Email, Note), Activity Date, Collector Name und Promise to Pay aus. Achten Sie darauf, sowohl automatisierte Systemaktionen als auch manuelle Benutzereinträge einzubeziehen.
Richten Sie den Export der Streitfallhistorie ein: Wählen Sie die Spalten Invoice Number, Dispute Case ID, Dispute Amount, Status Change Date, Reason Code und Resolution Date aus. Damit wird der Lebenszyklus von Abzügen erfasst.
Richten Sie den Export für Zahlungen und Cash Application ein: Wählen Sie die Spalten Invoice Number, Payment Reference, Payment Date, Payment Amount und Payment Type (Partial, Full, Credit Memo) aus.
Führen Sie die Berichte aus und exportieren Sie die Ergebnisse im CSV-Format.
Importieren Sie diese CSV-Dateien in eine Staging-Datenbank oder ein Datentransformationstool, etwa Python/Pandas oder eine SQL-Datenbank, um die Daten zusammenzuführen.
Führen Sie das im Abschnitt Query bereitgestellte Transformationsskript aus. Es vereinheitlicht die Spaltennamen, berechnet abgeleitete Ereignisse wie Due Date Passed und führt die verschiedenen Quellen in einem Event Log zusammen.
Prüfen Sie, ob die Datumsformate einheitlich sind (ISO 8601 wird empfohlen) und die Invoice Number in allen Dateien gleich formatiert ist, zum Beispiel ohne führende Nullen, falls diese uneinheitlich sind.
Exportieren Sie das fertige Ergebnis als einzelne CSV-Datei.
Laden Sie die fertige CSV-Datei in ProcessMind hoch und ordnen Sie InvoiceNumber der Case-ID, EventDateTime dem Timestamp und ActivityName der Aktivität zu.

Konfiguration

Datumsbereich: Wählen Sie anhand des Erstellungsdatums der Rechnung einen rollierenden Zeitraum, zum Beispiel die vergangenen 12 Monate, damit der gesamte Lebenszyklus erfasst wird.
Datenquellen: Sie benötigen Zugriff auf die Module Collections, Cash Application und Deductions in HighRadius.
Granularität: Erstellen Sie die Berichte auf Rechnungsebene, nicht auf Konto- oder Zusammenfassungsebene.
Benutzerberechtigungen: Der Benutzer, der die Daten exportiert, benötigt Reporting- oder Analytics-Administratorrechte, um auf historische Aktivitätsprotokolle zuzugreifen.
Systemaktionen: Aktivieren Sie ausdrücklich Filter, die System- oder automatisierte Benutzeraktionen in den Aktivitätsprotokollen einschließen, damit automatisierte Korrespondenz erfasst wird.
Erforderliche Zuordnung: HighRadius-Aktivitätstypen müssen möglicherweise standardisierten Process-Mining-Aktivitätsnamen zugeordnet werden, zum Beispiel „Dunning Letter“ zu „Zahlungserinnerung versendet“.

Beispielabfrage sql

/* 
Title: HighRadius Event Log Transformation Script
Description: This script assumes the raw CSV exports from HighRadius have been loaded into four staging tables:
1. STG_INVOICES (Header data)
2. STG_ACTIVITIES (Collections notes, calls, correspondence)
3. STG_DISPUTES (Deduction and dispute lifecycle)
4. STG_PAYMENTS (Cash application details)
*/

/* 1. Invoice Created */
SELECT 
    InvoiceNumber AS InvoiceNumber,
    'Invoice Created' AS ActivityName,
    InvoiceDate AS EventDateTime,
    CustomerName AS CustomerName,
    InvoiceAmount AS InvoiceAmount,
    DueDate AS DueDate,
    'System' AS CollectorName,
    'True' AS IsAutomated,
    NULL AS PaymentTermVariance,
    0 AS DaysSalesOutstanding
FROM STG_INVOICES

UNION ALL

/* 2. Payment Reminder Sent */
SELECT 
    InvoiceNumber,
    'Payment Reminder Sent',
    ActivityDate,
    CustomerName,
    NULL,
    NULL,
    UserName AS CollectorName,
    CASE WHEN UserName = 'System' THEN 'True' ELSE 'False' END,
    NULL,
    NULL
FROM STG_ACTIVITIES
WHERE ActivityType IN ('Dunning', 'Correspondence', 'Email Sent')

UNION ALL

/* 3. Collection Call Logged */
SELECT 
    InvoiceNumber,
    'Collection Call Logged',
    ActivityDate,
    CustomerName,
    NULL,
    NULL,
    UserName AS CollectorName,
    'False' AS IsAutomated,
    NULL,
    NULL
FROM STG_ACTIVITIES
WHERE ActivityType IN ('Call', 'Outbound Call')

UNION ALL

/* 4. Promise to Pay Created */
SELECT 
    InvoiceNumber,
    'Promise to Pay Created',
    PromiseDate,
    CustomerName,
    PromiseAmount,
    NULL,
    UserName AS CollectorName,
    'False' AS IsAutomated,
    NULL,
    NULL
FROM STG_ACTIVITIES
WHERE ActivityType = 'Promise to Pay' AND PromiseDate IS NOT NULL

UNION ALL

/* 5. Dispute Case Opened */
SELECT 
    InvoiceNumber,
    'Dispute Case Opened',
    CreateDate,
    CustomerName,
    DisputeAmount,
    NULL,
    AnalystName AS CollectorName,
    'False' AS IsAutomated,
    NULL,
    NULL
FROM STG_DISPUTES

UNION ALL

/* 6. Dispute Under Review */
SELECT 
    InvoiceNumber,
    'Dispute Under Review',
    StatusDate,
    CustomerName,
    NULL,
    NULL,
    AnalystName AS CollectorName,
    'False' AS IsAutomated,
    NULL,
    NULL
FROM STG_DISPUTES
WHERE Status = 'In Review'

UNION ALL

/* 7. Dispute Resolved */
SELECT 
    InvoiceNumber,
    'Dispute Resolved',
    ResolutionDate,
    CustomerName,
    NULL,
    NULL,
    AnalystName AS CollectorName,
    'False' AS IsAutomated,
    NULL,
    NULL
FROM STG_DISPUTES
WHERE Status IN ('Closed', 'Resolved', 'Denied', 'Approved')

UNION ALL

/* 8. Credit Memo Issued */
SELECT 
    InvoiceNumber,
    'Credit Memo Issued',
    PaymentDate,
    CustomerName,
    PaymentAmount,
    NULL,
    'System' AS CollectorName,
    'True' AS IsAutomated,
    NULL,
    NULL
FROM STG_PAYMENTS
WHERE PaymentType = 'Credit Memo'

UNION ALL

/* 9. Partial Payment Posted */
SELECT 
    P.InvoiceNumber,
    'Partial Payment Posted',
    P.PaymentDate,
    I.CustomerName,
    P.PaymentAmount,
    I.DueDate,
    'System' AS CollectorName,
    'True' AS IsAutomated,
    DATEDIFF(day, I.DueDate, P.PaymentDate) AS PaymentTermVariance,
    DATEDIFF(day, I.InvoiceDate, P.PaymentDate) AS DaysSalesOutstanding
FROM STG_PAYMENTS P
JOIN STG_INVOICES I ON P.InvoiceNumber = I.InvoiceNumber
WHERE P.PaymentType = 'Payment' AND P.PaymentAmount < I.InvoiceAmount

UNION ALL

/* 10. Bank Statement Matched */
SELECT 
    InvoiceNumber,
    'Bank Statement Matched',
    MatchDate,
    CustomerName,
    NULL,
    NULL,
    'CashApp System' AS CollectorName,
    'True' AS IsAutomated,
    NULL,
    NULL
FROM STG_PAYMENTS
WHERE MatchDate IS NOT NULL

UNION ALL

/* 11. Full Payment Received */
SELECT 
    P.InvoiceNumber,
    'Full Payment Received',
    P.PaymentDate,
    I.CustomerName,
    P.PaymentAmount,
    I.DueDate,
    'System' AS CollectorName,
    'True' AS IsAutomated,
    DATEDIFF(day, I.DueDate, P.PaymentDate) AS PaymentTermVariance,
    DATEDIFF(day, I.InvoiceDate, P.PaymentDate) AS DaysSalesOutstanding
FROM STG_PAYMENTS P
JOIN STG_INVOICES I ON P.InvoiceNumber = I.InvoiceNumber
WHERE P.PaymentType = 'Payment' AND P.PaymentAmount >= I.InvoiceAmount

UNION ALL

/* 12. Due Date Passed */
SELECT 
    InvoiceNumber,
    'Due Date Passed',
    DueDate,
    CustomerName,
    InvoiceAmount,
    DueDate,
    'System' AS CollectorName,
    'True' AS IsAutomated,
    NULL,
    DATEDIFF(day, InvoiceDate, DueDate) AS DaysSalesOutstanding
FROM STG_INVOICES
WHERE DueDate < GETDATE() AND (ClearDate IS NULL OR ClearDate > DueDate)

UNION ALL

/* 13. Invoice Cleared */
SELECT 
    InvoiceNumber,
    'Invoice Cleared',
    ClearDate,
    CustomerName,
    InvoiceAmount,
    DueDate,
    'System' AS CollectorName,
    'True' AS IsAutomated,
    DATEDIFF(day, DueDate, ClearDate) AS PaymentTermVariance,
    DATEDIFF(day, InvoiceDate, ClearDate) AS DaysSalesOutstanding
FROM STG_INVOICES
WHERE ClearDate IS NOT NULL

Schritte

Voraussetzungen und Einrichtung der Umgebung Stellen Sie sicher, dass Python 3.8 oder höher installiert ist. Sie benötigen die Bibliotheken requests und pandas. Installieren Sie sie bei Bedarf mit pip. Fragen Sie Ihre Systemadministration nach Ihrer HighRadius API Client ID, Ihrem Client Secret und der Base URL. Diese Angaben finden Sie in HighRadius üblicherweise im Bereich Administration oder Developer Portal.
API-Zugangsdaten konfigurieren Öffnen Sie das bereitgestellte Python-Skript. Suchen Sie den Konfigurationsabschnitt am Anfang und ersetzen Sie die Platzhalter CLIENT_ID, CLIENT_SECRET und BASE_URL. Stellen Sie sicher, dass der Benutzer zu diesen Zugangsdaten auf die Module Collections, Cash Application und Deductions zugreifen darf.
Parameter für den Datenexport festlegen Legen Sie im Skript die Variablen START_DATE und END_DATE fest. Um Zeitüberschreitungen zu vermeiden, empfiehlt es sich, die Daten monats- oder quartalsweise zu exportieren. Das Skript erwartet Datumsangaben im ISO-8601-Format (YYYY-MM-DD).
Skriptausführung: Authentifizierung Das Skript führt zunächst einen OAuth2-Ablauf aus, um ein Bearer-Token abzurufen. Dieses Token ist nur begrenzte Zeit gültig, in der Regel eine Stunde. Das Skript ruft das Token automatisch ab.
Skriptausführung: Datenabruf Das Skript fragt nacheinander bestimmte Endpunkte ab. Zuerst ruft es die Rechnungsdaten auf Kopfebene ab. Anschließend fragt es die zugehörigen Endpunkte für Aktivitäten (Notizen), Zahlungszusagen, Streitfälle und Zahlungshistorie ab. Dabei verwendet es bei Bedarf die Rechnungsnummern als Referenzschlüssel.
Datentransformation und Zuordnung von Aktivitäten Das Skript wandelt die JSON-Rohdaten in eine flache Event-Log-Struktur um. Dabei ordnet es bestimmte HighRadius-Codes den erforderlichen Aktivitätsnamen zu. Beispielsweise vergleicht es invoice_balance mit total_amount, um zwischen „Teilzahlung verbucht“ und „Vollständige Zahlung eingegangen“ zu unterscheiden. Außerdem berechnet es das Ereignis „Fälligkeitsdatum überschritten“, indem es das Fälligkeitsdatum mit dem Ausgleichsdatum oder dem aktuellen Datum vergleicht.
Seitennummerierung verarbeiten HighRadius-APIs liefern Ergebnisse üblicherweise seitenweise. Das bereitgestellte Skript ruft in einer Schleife alle Seiten ab, bis keine weiteren Datensätze zurückgegeben werden. Achten Sie währenddessen auf eine stabile Netzwerkverbindung.
Daten zusammenführen Alle exportierten Listen (Rechnungen, Aktivitäten, Streitfälle und Zahlungen) werden in einem Pandas DataFrame zusammengeführt. Das Skript sortiert diesen DataFrame nach InvoiceNumber und EventDateTime, damit die Ereignisse chronologisch angeordnet sind.
Validierung und Qualitätsprüfung Vor dem Abschluss gibt das Skript eine Zusammenfassung der eindeutigen Aktivitäten aus. Prüfen Sie, ob die Anzahl im Verhältnis zu Ihren operativen Volumina plausibel ist. Kontrollieren Sie außerdem, ob die Spalte EventDateTime das Format YYYY-MM-DD HH:MM:SS aufweist.
Als CSV exportieren Der fertige DataFrame wird in eine Datei namens HighRadius_EventLog.csv exportiert. Sie enthält die für ProcessMind erforderlichen Spalten.
Abschließende Prüfung Öffnen Sie die CSV-Datei und prüfen Sie, ob InvoiceNumber oder ActivityName NULL-Werte enthalten. Stellen Sie sicher, dass keine Daten in der Zukunft liegen, es sei denn, es handelt sich um erwartete Fälligkeitstermine. EventDateTime sollte immer in der Vergangenheit oder Gegenwart liegen.
In ProcessMind hochladen Importieren Sie die erzeugte CSV-Datei in ProcessMind. Ordnen Sie InvoiceNumber der Case-ID, ActivityName der Aktivität und EventDateTime dem Timestamp zu.

Konfiguration

API Base URL: Stellen Sie fest, ob Sie eine Produktions- oder Sandbox-Umgebung verwenden. Die URL-Struktur unterscheidet sich üblicherweise, zum Beispiel https://[client].highradius.com/api gegenüber https://[client]-sandbox.highradius.com/api.
Client-Berechtigungen: Stellen Sie sicher, dass der API Client über read-Zugriff auf die Bereiche radiusOne, collections, deductions und cashApp verfügt.
Datumsbereich: Bei hohem Transaktionsvolumen (mehr als 100.000 Rechnungen pro Monat) sollten Sie pro Durchlauf höchstens drei Monate exportieren.
Seitengröße: Das Skript verwendet standardmäßig 1.000 Datensätze pro Seite. Passen Sie den Parameter limit in den API-Aufrufen an, wenn der Server Zeitüberschreitungen meldet.
Drosselung und Ratenbegrenzung: HighRadius kann Ratenbegrenzungen durchsetzen. Wenn HTTP-429-Fehler auftreten, fügen Sie in den Seitenschleifen den Befehl time.sleep(1) ein.

Beispielabfrage python

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

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
BASE_URL = class="hl-string">"https://[Your Instance].highradius.com/api/v1"
TOKEN_URL = class="hl-string">"https://[Your Instance].highradius.com/oauth/token"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"
SCOPE = class="hl-string">"read_write"

class=class="hl-string">"hl-comment"># Extraction Window
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"

class=class="hl-string">"hl-comment"># Global container for event log rows
event_log = []

def get_access_token():
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'scope': SCOPE
    }
    try:
        response = requests.post(TOKEN_URL, data=payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return None

def fetch_paged_data(endpoint, token, params={}):
    headers = {class="hl-string">"Authorization": fclass="hl-string">"Bearer {token}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    all_records = []
    page = 1
    while True:
        params[class="hl-string">'page'] = page
        params[class="hl-string">'limit'] = 1000
        try:
            resp = requests.get(fclass="hl-string">"{BASE_URL}/{endpoint}", headers=headers, params=params)
            if resp.status_code != 200:
                break
            data = resp.json()
            records = data.get(class="hl-string">'data', [])
            if not records:
                break
            all_records.extend(records)
            page += 1
        except Exception:
            break
    return all_records

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

    class=class="hl-string">"hl-comment"># 1. Fetch Invoices (Header Data)
    print(class="hl-string">"Fetching Invoices...")
    invoices = fetch_paged_data(class="hl-string">"invoices", token, {class="hl-string">"filter_date_from": START_DATE, class="hl-string">"filter_date_to": END_DATE})
    
    class=class="hl-string">"hl-comment"># Process Invoice Headers and Derived Events
    invoice_ids = []
    for inv in invoices:
        inv_num = str(inv.get(class="hl-string">'invoice_number', class="hl-string">''))
        cust_name = inv.get(class="hl-string">'customer_name', class="hl-string">'')
        amount = float(inv.get(class="hl-string">'amount', 0.0))
        create_date = inv.get(class="hl-string">'create_date')  class=class="hl-string">"hl-comment"># YYYY-MM-DD
        due_date = inv.get(class="hl-string">'due_date')
        clear_date = inv.get(class="hl-string">'clear_date')
        status = inv.get(class="hl-string">'status', class="hl-string">'Open')
        
        invoice_ids.append(inv_num)
        
        class=class="hl-string">"hl-comment"># Event: Invoice Created
        event_log.append({
            class="hl-string">"InvoiceNumber": inv_num,
            class="hl-string">"ActivityName": class="hl-string">"Invoice Created",
            class="hl-string">"EventDateTime": fclass="hl-string">"{create_date} 00:00:00",
            class="hl-string">"CustomerName": cust_name,
            class="hl-string">"InvoiceAmount": amount,
            class="hl-string">"DueDate": due_date,
            class="hl-string">"IsAutomated": True
        })
        
        class=class="hl-string">"hl-comment"># Event: Invoice Cleared
        if status.lower() in [class="hl-string">'closed', class="hl-string">'cleared'] and clear_date:
             event_log.append({
                class="hl-string">"InvoiceNumber": inv_num,
                class="hl-string">"ActivityName": class="hl-string">"Invoice Cleared",
                class="hl-string">"EventDateTime": fclass="hl-string">"{clear_date} 23:59:59",
                class="hl-string">"CustomerName": cust_name,
                class="hl-string">"InvoiceAmount": amount,
                class="hl-string">"DueDate": due_date,
                class="hl-string">"IsAutomated": True
            })
             
        class=class="hl-string">"hl-comment"># Event: Due Date Passed (Calculated)
        class=class="hl-string">"hl-comment"># Logic: If closed and cleared after due date OR if open and today is after due date
        d_due = datetime.strptime(due_date, class="hl-string">"%Y-%m-%d")
        limit_date = datetime.strptime(clear_date, class="hl-string">"%Y-%m-%d") if clear_date else datetime.now()
        
        if limit_date > d_due:
            overdue_ts = d_due + timedelta(days=1)
            event_log.append({
                class="hl-string">"InvoiceNumber": inv_num,
                class="hl-string">"ActivityName": class="hl-string">"Due Date Passed",
                class="hl-string">"EventDateTime": overdue_ts.strftime(class="hl-string">"%Y-%m-%d %H:%M:%S"),
                class="hl-string">"CustomerName": cust_name,
                class="hl-string">"InvoiceAmount": amount,
                class="hl-string">"DueDate": due_date,
                class="hl-string">"IsAutomated": True
            })

        class=class="hl-string">"hl-comment"># Event: Credit Memo Issued
        if inv.get(class="hl-string">'document_type', class="hl-string">'').lower() == class="hl-string">'credit_memo':
             event_log.append({
                class="hl-string">"InvoiceNumber": inv_num,
                class="hl-string">"ActivityName": class="hl-string">"Credit Memo Issued",
                class="hl-string">"EventDateTime": fclass="hl-string">"{create_date} 12:00:00",
                class="hl-string">"CustomerName": cust_name,
                class="hl-string">"InvoiceAmount": amount,
                class="hl-string">"DueDate": due_date,
                class="hl-string">"IsAutomated": True
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Activities / Notes (Calls, Reminders)
    print(class="hl-string">"Fetching Activities...")
    class=class="hl-string">"hl-comment"># In a real scenario, you might iterate invoice_ids in chunks if the API requires filtering by ID
    class=class="hl-string">"hl-comment"># Here we assume an endpoint allowing date filtering similar to invoices
    activities = fetch_paged_data(class="hl-string">"activities", token, {class="hl-string">"date_from": START_DATE, class="hl-string">"date_to": END_DATE})
    
    for act in activities:
        inv_num = str(act.get(class="hl-string">'invoice_number', class="hl-string">''))
        act_type = act.get(class="hl-string">'activity_type', class="hl-string">'').lower()
        act_date = act.get(class="hl-string">'activity_date') class=class="hl-string">"hl-comment"># Assume valid timestamp
        user = act.get(class="hl-string">'performed_by', class="hl-string">'System')
        
        activity_name = None
        if class="hl-string">'email' in act_type or class="hl-string">'letter' in act_type or class="hl-string">'reminder' in act_type:
            activity_name = class="hl-string">"Payment Reminder Sent"
        elif class="hl-string">'call' in act_type:
            activity_name = class="hl-string">"Collection Call Logged"
            
        if activity_name:
            event_log.append({
                class="hl-string">"InvoiceNumber": inv_num,
                class="hl-string">"ActivityName": activity_name,
                class="hl-string">"EventDateTime": act_date,
                class="hl-string">"CollectorName": user,
                class="hl-string">"IsAutomated": user == class="hl-string">'System'
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Promises to Pay
    print(class="hl-string">"Fetching Promises to Pay...")
    ptps = fetch_paged_data(class="hl-string">"promises", token, {class="hl-string">"created_from": START_DATE, class="hl-string">"created_to": END_DATE})
    for ptp in ptps:
        event_log.append({
            class="hl-string">"InvoiceNumber": str(ptp.get(class="hl-string">'invoice_number', class="hl-string">'')),
            class="hl-string">"ActivityName": class="hl-string">"Promise to Pay Created",
            class="hl-string">"EventDateTime": ptp.get(class="hl-string">'created_at'),
            class="hl-string">"CollectorName": ptp.get(class="hl-string">'created_by'),
            class="hl-string">"IsAutomated": False
        })

    class=class="hl-string">"hl-comment"># 4. Fetch Disputes
    print(class="hl-string">"Fetching Disputes...")
    disputes = fetch_paged_data(class="hl-string">"disputes", token, {class="hl-string">"date_from": START_DATE, class="hl-string">"date_to": END_DATE})
    for disp in disputes:
        inv_num = str(disp.get(class="hl-string">'invoice_number', class="hl-string">''))
        create_ts = disp.get(class="hl-string">'create_date')
        status_history = disp.get(class="hl-string">'status_history', [])
        
        class=class="hl-string">"hl-comment"># Event: Dispute Case Opened
        event_log.append({
            class="hl-string">"InvoiceNumber": inv_num,
            class="hl-string">"ActivityName": class="hl-string">"Dispute Case Opened",
            class="hl-string">"EventDateTime": create_ts,
            class="hl-string">"IsAutomated": False
        })
        
        class=class="hl-string">"hl-comment"># Process Audit Trail for Status Changes
        for history in status_history:
            status = history.get(class="hl-string">'status', class="hl-string">'').lower()
            hist_date = history.get(class="hl-string">'date')
            
            if status == class="hl-string">'in_review' or status == class="hl-string">'investigation':
                event_log.append({
                    class="hl-string">"InvoiceNumber": inv_num,
                    class="hl-string">"ActivityName": class="hl-string">"Dispute Under Review",
                    class="hl-string">"EventDateTime": hist_date,
                    class="hl-string">"IsAutomated": False
                })
            elif status == class="hl-string">'resolved' or status == class="hl-string">'closed':
                 event_log.append({
                    class="hl-string">"InvoiceNumber": inv_num,
                    class="hl-string">"ActivityName": class="hl-string">"Dispute Resolved",
                    class="hl-string">"EventDateTime": hist_date,
                    class="hl-string">"IsAutomated": False
                })

    class=class="hl-string">"hl-comment"># 5. Fetch Payments
    print(class="hl-string">"Fetching Payments...")
    payments = fetch_paged_data(class="hl-string">"payments", token, {class="hl-string">"date_from": START_DATE, class="hl-string">"date_to": END_DATE})
    for pay in payments:
        inv_num = str(pay.get(class="hl-string">'invoice_number', class="hl-string">''))
        pay_date = pay.get(class="hl-string">'payment_date')
        pay_amount = float(pay.get(class="hl-string">'payment_amount', 0.0))
        inv_total = float(pay.get(class="hl-string">'invoice_total_amount', 0.0))
        is_matched = pay.get(class="hl-string">'is_matched', False)
        
        class=class="hl-string">"hl-comment"># Determine Partial vs Full
        class=class="hl-string">"hl-comment"># Note: logic simplified; usually compare accumulated payments
        if pay_amount < inv_total:
            act_name = class="hl-string">"Partial Payment Posted"
        else:
            act_name = class="hl-string">"Full Payment Received"
            
        event_log.append({
            class="hl-string">"InvoiceNumber": inv_num,
            class="hl-string">"ActivityName": act_name,
            class="hl-string">"EventDateTime": pay_date,
            class="hl-string">"InvoiceAmount": inv_total,
            class="hl-string">"IsAutomated": True
        })
        
        class=class="hl-string">"hl-comment"># Event: Bank Statement Matched
        class=class="hl-string">"hl-comment"># Trigger if the system flags this payment as successfully matched to bank line
        if is_matched:
             event_log.append({
                class="hl-string">"InvoiceNumber": inv_num,
                class="hl-string">"ActivityName": class="hl-string">"Bank Statement Matched",
                class="hl-string">"EventDateTime": pay_date, class=class="hl-string">"hl-comment"># Often same time as posting
                class="hl-string">"IsAutomated": True
            })

    class=class="hl-string">"hl-comment"># Export
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure required columns exist even if empty
    required_cols = [class="hl-string">"InvoiceNumber", class="hl-string">"ActivityName", class="hl-string">"EventDateTime"]
    for col in required_cols:
        if col not in df.columns:
            df[col] = None
            
    class=class="hl-string">"hl-comment"># Fill recommended cols with None if missing
    recommended_cols = [class="hl-string">"CustomerName", class="hl-string">"InvoiceAmount", class="hl-string">"DueDate", class="hl-string">"CollectorName", class="hl-string">"IsAutomated"]
    for col in recommended_cols:
        if col not in df.columns:
            df[col] = None

    df.dropna(subset=[class="hl-string">"InvoiceNumber", class="hl-string">"ActivityName", class="hl-string">"EventDateTime"], inplace=True)
    df.sort_values(by=[class="hl-string">"InvoiceNumber", class="hl-string">"EventDateTime"], inplace=True)
    
    output_file = class="hl-string">"HighRadius_EventLog.csv"
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Extraction Complete. {len(df)} rows saved to {output_file}")

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

Möchten Sie loslegen?

Bilden Sie noch heute den Lebenszyklus Ihrer Rechnungen ab, um Ihre Liquidität zu verbessern und Ihre Days Sales Outstanding zu senken. Unser Team unterstützt Sie bei der technischen Implementierung.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie Ihr Forderungsmanagement und verbessern Sie Ihren Cashflow

Senken Sie Ihre DSO mit automatisierten Prozesserkenntnissen um 15 bis 20 Tage

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Einrichtung in wenigen Minuten

Ihr Daten-Template für das Forderungsmanagement

Ihr Daten-Template für das Forderungsmanagement

Attribute des Forderungsmanagements

Aktivitäten im Forderungsmanagement

Anleitungen zum Datenexport

Datenexport aus HighRadius Analytics und Reporting

Schritte

Konfiguration

Beispielabfrage sql

Datenexport über die HighRadius-REST-API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie Ihr Forderungsmanagement und verbessern Sie Ihren Cashflow