Ihr Daten-Template für Kreditmanagement und Forderungseinzug
Ihr Daten-Template für Kreditmanagement und Forderungseinzug
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Aktivitäten für die Prozesserkennung
- Schritt-für-Schritt-Anleitung zur Datenextraktion
Attribute für Kreditmanagement und Forderungseinzug
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Name des konkreten Geschäftsereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Kreditmanagementprozess stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Lebenszyklus einer Rechnung, etwa „Rechnung erstellt“, „Mahnverfahren eingeleitet“ oder „Zahlung eingegangen“. Jede Aktivität steht für ein eigenes Ereignis, das den Case voranbringt. Die Analyse der Abfolge und Häufigkeit von Aktivitäten ist der Kern von Process Mining. Sie macht den tatsächlichen Prozessablauf sichtbar, zeigt Engpässe auf, an denen Cases liegen bleiben, und deckt Schleifen auf, in denen Aktivitäten wiederholt werden. Außerdem können Sie den tatsächlichen Prozess mit dem geplanten oder idealen Ablauf vergleichen. Der Aktivitätsname ist grundlegend für die Erstellung von Prozessmodellen und die Berechnung der Übergangszeiten zwischen Schritten. Warum das wichtig ist Dieses Attribut legt die Schritte im Prozessmodell fest und ermöglicht es, den Lebenszyklus einer Rechnung vom Anfang bis zum Ende zu visualisieren und zu analysieren. Woher beziehen Dieses konzeptionelle Feld wird aus verschiedenen Geschäftsereignissen in Oracle Fusion Financials abgeleitet. Häufig entsteht es durch die Zuordnung von Transaktionsstatus, Ereignisdaten oder bestimmten Aktionen aus Modulen wie Receivables (AR) und Advanced Collections. Beispiele Rechnung erstelltMahnverfahren eingeleitetZahlung eingegangenStreitfall erfasst | |||
| Ereigniszeitpunkt EventTime | Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat, also der Timestamp des Ereignisses. | ||
| Beschreibung Die Ereigniszeit beziehungsweise der Timestamp hält den genauen Zeitpunkt einer Aktivität fest. Sie ist erforderlich, um Ereignisse chronologisch zu ordnen und einen korrekten Prozessablauf zu erstellen. Ohne genaue Timestamps lässt sich die Ereignisabfolge nicht zuverlässig bestimmen. Bei der Analyse dient dieses Attribut dazu, Zeitspannen und Zykluszeiten zwischen Aktivitäten zu berechnen. Das ist entscheidend für die Leistungsmessung. So lassen sich beispielsweise KPIs wie die Zykluszeit zur Klärung von Streitfällen oder die Zahlungszykluszeit einer Rechnung berechnen. Außerdem können Sie damit die Entwicklung der Prozessleistung über verschiedene Zeiträume hinweg analysieren. Warum das wichtig ist Dieser Timestamp ist erforderlich, um Ereignisse zu ordnen, Zykluszeiten und Zeitspannen zu berechnen und die Prozessleistung im Zeitverlauf zu analysieren. Woher beziehen Abgeleitet aus verschiedenen Datumsfeldern in Oracle-Fusion-Financials-Tabellen, etwa TRX_DATE in RA_CUSTOMER_TRX_ALL für die Rechnungserstellung oder dem Erstellungsdatum einer Maßnahme zum Forderungseinzug. Beispiele 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Rechnungsnummer InvoiceNumber | Eindeutige Kennung jeder Kundenrechnung und primäre Case-ID für den Kreditmanagementprozess. | ||
| Beschreibung Die Rechnungsnummer ist der zentrale Schlüssel, der alle Ereignisse und Aktivitäten zu einer Forderung verknüpft, von der Erstellung bis zum endgültigen Ausgleich oder zur Abschreibung. Sie ermöglicht eine durchgängige Sicht auf den Lebenszyklus der Rechnung. Bei der Process-Mining-Analyse dient dieses Attribut dazu, den Ablauf jeder Rechnung zu rekonstruieren. Werden alle zugehörigen Aktivitäten unter einer Rechnungsnummer gruppiert, können Analysten Prozessabläufe visualisieren, häufige und abweichende Pfade erkennen und Zykluszeiten für den gesamten Prozess oder einzelne Phasen messen, etwa für die Klärung von Streitfällen oder die Zahlungsbuchung. Warum das wichtig ist Diese unverzichtbare Case-ID verknüpft alle zugehörigen Prozessschritte. So lässt sich der Weg jeder Rechnung von der Ausstellung bis zum Abschluss rekonstruieren und analysieren. Woher beziehen Diese Kennung ist in Oracle Fusion Financials üblicherweise als TRX_NUMBER in der Tabelle RA_CUSTOMER_TRX_ALL zu finden. Beispiele INV-1005679884321AR-2023-04-112 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp gibt an, wann die Daten zu diesem Ereignis zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut kennzeichnet Datum und Uhrzeit der letzten Datenextraktion. Es handelt sich um ein Metadatenfeld, das nicht zum Geschäftsprozess selbst gehört, aber wichtig ist, um die Aktualität der analysierten Daten einzuschätzen. Analysten prüfen anhand dieses Timestamps, ob sie mit aktuellen Informationen arbeiten, und erkennen den zeitlichen Datenstand. Das ist wichtig für die Datenverwaltung und hilft, die Erwartungen der Benutzer an die Aktualität von Dashboards und Berichten zu steuern. Warum das wichtig ist Zeigt, wie aktuell die Daten sind, damit Analysten und Beteiligte deren Aktualität und Relevanz einschätzen können. Woher beziehen Dieser Wert wird während der Datenextraktion und dem Laden (ETL) erzeugt und in jeden Datensatz geschrieben. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten stammen. | ||
| Beschreibung Dieses Attribut kennzeichnet die Quellanwendung, in der die Ereignisdaten erfasst wurden. In komplexen IT-Umgebungen können mehrere Systeme an einem durchgängigen Prozess beteiligt sein. Die Angabe des Quellsystems ist wichtig für die Datenverwaltung, die Fehlerbehebung und das Verständnis des Datenkontexts. Sie hilft, Ereignisse aus verschiedenen Systemen zu unterscheiden, wenn diese in einer gemeinsamen Prozesssicht zusammengeführt werden. So bleibt die Herkunft der Daten nachvollziehbar. Warum das wichtig ist Macht die Herkunft der Daten nachvollziehbar. Das ist wichtig für die Datenvalidierung, die Datenverwaltung und das Verständnis des technischen Prozesskontexts. Woher beziehen In der Regel handelt es sich um einen statischen Wert, der bei der Datenextraktion hinzugefügt wird, um die Herkunft der Datensätze zu kennzeichnen. Beispiele Oracle Fusion FinancialsOracle AROracle Collections | |||
| Benutzer User | Der Benutzer oder die System-ID, der bzw. die die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut gibt an, welcher Mitarbeitende oder welches automatisierte System für eine Aktivität verantwortlich war, etwa für die Genehmigung eines Kreditlimits, die Buchung einer Zahlung oder die Klärung eines Rechnungseinwands. Die Analyse der Aktivitäten nach Benutzer ist wichtig, um Arbeitsverteilung, individuelle Leistung und Compliance zu verstehen. Bei automatisierten Aktivitäten lässt sich damit die Beteiligung von Systemprozessen nachverfolgen. Außerdem können Schulungsbedarf oder mögliche betrügerische Aktivitäten erkannt werden, indem das Benutzerverhalten überwacht wird. Warum das wichtig ist Ordnet Prozessaktivitäten bestimmten Personen oder automatisierten Systemen zu und ermöglicht so die Leistungserfassung, die Analyse der Arbeitsbelastung und die Prüfung. Woher beziehen Stammt aus den Spalten „CREATED_BY“ oder „LAST_UPDATED_BY“ verschiedener Transaktions- und Verlaufstabellen in Oracle Fusion Financials. Beispiele jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Fälligkeitsdatum DueDate | Das Datum, bis zu dem die Rechnung bezahlt werden muss. | ||
| Beschreibung Das Fälligkeitsdatum ist ein vertraglich vereinbarter, entscheidender Termin für die Zahlung. Es dient als Grundlage, um die Pünktlichkeit des Zahlungseingangs zu messen. Dieses Attribut ist wichtig, um überfällige Rechnungen zu erkennen und die Anzahl der Verzugstage zu berechnen. Es ist die maßgebliche Grundlage dafür, wann ein Mahnverfahren eingeleitet werden sollte, und fließt in die Berechnung von Kennzahlen wie Days Sales Outstanding (DSO) ein. Außerdem ist es für Altersstrukturanalysen erforderlich, mit denen offene Forderungen nach ihrem Alter eingeteilt werden. Warum das wichtig ist Dient als Grundlage, um überfällige Rechnungen zu erkennen, Maßnahmen zur Forderungsbeitreibung einzuleiten und eine Altersstrukturanalyse durchzuführen. Woher beziehen In der Tabelle AR_PAYMENT_SCHEDULES_ALL als DUE_DATE verfügbar. Beispiele 2023-05-302023-06-152023-07-01 | |||
| Kundennummer CustomerNumber | Eindeutige Kennung des Kunden, dem die Rechnung zugeordnet ist. | ||
| Beschreibung Die Kundennummer verknüpft eine Rechnung mit einem bestimmten Kundenkonto. So lässt sich der Kreditmanagement- und Forderungseinziehungsprozess anhand von Kundenmerkmalen segmentieren und analysieren. Mit der Kundennummer können Analysten untersuchen, ob bestimmte Kunden regelmäßig verspätet zahlen, häufiger Streitfälle melden oder mehr Maßnahmen zum Forderungseinzug erfordern. Diese Informationen sind wichtig, um individuelle Einziehungsstrategien zu entwickeln, Kreditbedingungen anzupassen und Kundensegmente mit hohem Risiko zu erkennen. Sie unterstützen direkt Analysen wie die Abschreibungsquote von Rechnungen nach Kundensegment. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach Kunden und hilft, Muster, Risiken und Ansatzpunkte für maßgeschneiderte Einziehungsstrategien zu erkennen. Woher beziehen Üblicherweise in der Tabelle RA_CUSTOMER_TRX_ALL als BILL_TO_CUSTOMER_ID zu finden. Dieses Feld verweist auf HZ_CUST_ACCOUNTS. Beispiele CUST-0012389455ACME-CORP-US | |||
| Kundensegment CustomerSegment | Einteilung eines Kunden in eine festgelegte Gruppe, beispielsweise nach Unternehmensgröße, Branche oder strategischer Bedeutung. | ||
| Beschreibung Das Kundensegment ist ein kategoriales Attribut, das Kunden anhand gemeinsamer Merkmale gruppiert. Segmente können beispielsweise nach Faktoren wie „Strategisch“, „KMU“ oder „Enterprise“ oder nach Branchen wie „Fertigung“ und „Einzelhandel“ gebildet werden. Dieses Attribut eignet sich für vergleichende Analysen. Analysten können damit die Prozessleistung verschiedener Segmente vergleichen und beispielsweise feststellen, ob ein Segment häufiger Streitfälle aufweist oder längere Zahlungszyklen hat. Die Erkenntnisse helfen, Kreditrichtlinien und Einziehungsstrategien auf die jeweiligen Anforderungen und Risiken der Segmente abzustimmen. Sie unterstützen auch Dashboards wie die Analyse der Abschreibungsquote von Rechnungen. Warum das wichtig ist Ermöglicht aussagekräftige Vergleiche und zeigt, wie sich Prozessleistung und Risiken zwischen verschiedenen Kundengruppen unterscheiden. Woher beziehen Wird häufig in den Kundenstammdaten verwaltet, etwa in HZ_CUST_ACCOUNTS oder verwandten Tabellen, oder anhand von Kundenmerkmalen wie Umsatz oder Branche abgeleitet. Beispiele GroßunternehmenKleine und mittlere UnternehmenÖffentliche VerwaltungStrategischer Partner | |||
| Mahnstufe DunningLevel | Die Stufe oder Ebene des Mahnverfahrens, das für die Rechnung angewendet wurde. | ||
| Beschreibung Die Mahnstufe gibt an, wie nachdrücklich die Zahlungserinnerung ist. In der Regel wird sie mit der Zeit erhöht. Stufe 1 könnte beispielsweise eine freundliche Erinnerung per E-Mail sein, während Stufe 3 einem formellen Schreiben oder einem Telefonanruf entspricht. Die Analyse des Prozesses nach Mahnstufe hilft dabei, die Wirksamkeit der Mahnstrategie zu beurteilen. Das Dashboard zur Wirksamkeit des Mahnverfahrens verwendet dieses Attribut, um die Übergangsquoten von den einzelnen Mahnstufen zur Zahlung darzustellen. So kann das Unternehmen feststellen, welche Mahnmaßnahmen am wirksamsten sind, und Zeitpunkt sowie Inhalt der Erinnerungen anpassen, um den Zahlungseingang zu verbessern. Warum das wichtig ist Erfasst die Eskalationsstufe der Forderungsbeitreibung und ist entscheidend für die Bewertung der Wirksamkeit der Mahnstrategie. Woher beziehen Diese Daten werden im Modul Oracle Advanced Collections verwaltet. Sie finden sich in Tabellen zum Mahnverlauf, etwa IEX_DUNNINGS. Beispiele Stufe 1: ZahlungserinnerungStufe 2: MahnungStufe 3: Letzte Mahnung | |||
| Rechnungsbetrag InvoiceAmount | Der Gesamtbetrag der Rechnung. | ||
| Beschreibung Der Rechnungsbetrag entspricht dem Gesamtwert der Waren oder Dienstleistungen, die dem Kunden in Rechnung gestellt werden. Dieses wichtige Finanzattribut zeigt die finanziellen Auswirkungen des Prozesses. Bei der Analyse hilft der Rechnungsbetrag, Maßnahmen zum Forderungseinzug zu priorisieren und sich auf überfällige Rechnungen mit hohen Beträgen zu konzentrieren. Außerdem können Sie damit Zahlungsverhalten nach Transaktionswert untersuchen und die finanziellen Auswirkungen von Abschreibungen berechnen. Dashboards wie die Analyse der Abschreibungsquote von Rechnungen verwenden diesen Wert, um das Ausmaß finanzieller Verluste zu bewerten. Warum das wichtig ist Liefert den finanziellen Kontext des Prozesses. So können Sie Rechnungen mit hohen Beträgen priorisieren und die finanziellen Auswirkungen von Prozessineffizienzen analysieren. Woher beziehen Diese Information lässt sich aus der Tabelle AR_PAYMENT_SCHEDULES_ALL ableiten, in der der fällige Rechnungsbetrag gespeichert ist. Beispiele 5000.001250.75250000.00 | |||
| Sachbearbeiter für den Forderungseinzug Collector | Name oder ID der Person, die für den Forderungseinzug bei der Rechnung zuständig ist. | ||
| Beschreibung Die für den Forderungseinzug zuständige Person oder das Team bearbeitet überfällige Rechnungen. Die Zuweisung ist ein wichtiger Schritt im Workflow für den Forderungseinzug. Dieses Attribut ist entscheidend für die Leistungssteuerung und Ressourcenplanung in der Forderungsabteilung. Anhand der Ergebnisse je zuständiger Person können Führungskräfte die Wirksamkeit beurteilen, Schulungsbedarf erkennen und die Arbeitslast ausgleichen. Das Dashboard zur Wirksamkeit der Zuweisung im Forderungseinzug stützt sich direkt auf dieses Attribut, um Erfolgsquoten und Zykluszeiten verschiedener Sachbearbeitender zu vergleichen. Warum das wichtig ist Ermöglicht die Leistungsanalyse einzelner Sachbearbeitender und Teams. So lassen sich Ressourcen gezielter einsetzen und die Effizienz des Forderungseinzugs insgesamt verbessern. Woher beziehen Diese Informationen werden in der Regel im Modul Oracle Advanced Collections gespeichert, häufig in Tabellen wie IEX_CASES_ALL_B oder zugehörigen Zuweisungstabellen. Beispiele John SmithJane DoeForderungsmanagement-Team A | |||
| Abgeschrieben? IsWrittenOff | Ein boolesches Kennzeichen dafür, ob die Rechnung als uneinbringliche Forderung abgeschrieben wurde. | ||
| Beschreibung Dieses abgeleitete Kennzeichen identifiziert Rechnungen, die das Unternehmen als uneinbringlich eingestuft und aus dem aktiven Forderungsbestand entfernt hat. Dies ist in der Regel der letzte und unerwünschte Ausgang einer Rechnung. Das Attribut ist wichtig für die Berechnung der Kennzahl zur Abschreibungsquote von Rechnungen und für die zugehörige Analyse im Dashboard. Analysten können damit erfolglose Fälle der Forderungsbeitreibung herausfiltern und gemeinsame Merkmale wie Kundensegment oder Rechnungswert ermitteln, die mit einem höheren Abschreibungsrisiko verbunden sein können. Diese Erkenntnisse helfen dabei, Kreditrichtlinien und Strategien zur Forderungsbeitreibung zu verbessern. Warum das wichtig ist Kennzeichnet erfolglose Fälle der Forderungsbeitreibung eindeutig. Das ist wichtig, um die Ursachen uneinbringlicher Forderungen zu analysieren und Abschreibungsquoten zu berechnen. Woher beziehen Dies ist ein berechnetes Feld. Es wird ermittelt, indem geprüft wird, ob für den Case eine Aktivität „Rechnung abgeschrieben“ vorliegt oder der Rechnungsstatus „Abgeschrieben“ lautet. Beispiele truefalse | |||
| Endzeit EndTime | Der Timestamp, der angibt, wann eine Aktivität mit einer bestimmten Dauer abgeschlossen wurde. | ||
| Beschreibung Bei Aktivitäten mit einem klaren Anfang und Ende erfasst dieses Attribut den Abschlusszeitpunkt. Viele Ereignisse im Process Mining treten zwar ohne Zeitdauer auf, einige, etwa die „Untersuchung eines Rechnungseinwands“, können sich jedoch über einen Zeitraum erstrecken. Eine separate Endzeit ermöglicht die genaue Berechnung der Verarbeitungszeit von Aktivitäten. Das ist präziser, als die Dauer aus der Startzeit der nächsten Aktivität abzuleiten, insbesondere bei Leerlaufzeiten. Die Endzeit ist wichtig, um die Ressourcenauslastung zu analysieren und festzustellen, welche Prozessschritte besonders viel Zeit beanspruchen. Warum das wichtig ist Ermöglicht die genaue Berechnung der Dauer einzelner Aktivitäten und liefert so detailliertere Erkenntnisse zu Engpässen und Ressourcenauslastung. Woher beziehen Häufig handelt es sich um ein konzeptionelles Attribut. Es kann aus einem Timestamp der letzten Aktualisierung oder einem bestimmten Abschlussdatumsfeld in den Quelltabellen der jeweiligen Aktivität stammen. Beispiele 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Geschäftseinheit BusinessUnit | Die Geschäftseinheit oder Organisationseinheit, die die Rechnung ausgestellt hat. | ||
| Beschreibung In großen Unternehmen sind die Geschäftsbereiche häufig auf mehrere Geschäftseinheiten verteilt. Dieses Attribut gibt an, welcher Geschäftseinheit die Rechnung zugeordnet ist. Die Analyse des Prozesses nach Geschäftseinheit ermöglicht einen Leistungsvergleich zwischen verschiedenen Unternehmensteilen. Sie kann Unterschiede bei der Anwendung von Kredit- und Forderungsbeitreibungsrichtlinien aufzeigen und erkennen lassen, welche Geschäftseinheiten ihre Forderungen wirksamer verwalten. So lassen sich bewährte Vorgehensweisen weitergeben und Prozesse bei Bedarf vereinheitlichen. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen verschiedenen Organisationseinheiten und hilft dabei, bewährte Vorgehensweisen sowie Verbesserungspotenziale zu erkennen. Woher beziehen Über das Feld ORG_ID in der Tabelle RA_CUSTOMER_TRX_ALL verfügbar. Dieses Feld verweist auf die Organisationsstruktur. Beispiele Geschäftseinheit NordamerikaGeschäftseinheit EMEAGeschäftsbereich Global Services | |||
| Grund für den Rechnungseinwand DisputeReason | Der vom Kunden angegebene Grund für den Einwand gegen eine Rechnung. | ||
| Beschreibung Wenn ein Kunde eine Rechnung beanstandet, nennt er in der Regel einen Grund, etwa „Falsche Preisangabe“, „Beschädigte Ware“ oder „Doppelte Rechnung“. Dieses Attribut erfasst den jeweiligen Grund. Die Analyse der Gründe für Rechnungseinwände ist wichtig, um Ursachen zu ermitteln. Sie hilft dabei, wiederkehrende Probleme in vorgelagerten Prozessen wie der Auftragsverwaltung oder Rechnungsstellung zu erkennen, die zu Zahlungsverzögerungen führen. Werden die verschiedenen Gründe kategorisiert und ihre Häufigkeit erfasst, kann das Unternehmen gezielte Maßnahmen zur Behebung der Ursachen ergreifen. Das trägt dazu bei, die Zykluszeit für die Klärung von Rechnungseinwänden zu verkürzen. Warum das wichtig ist Hilft, die Ursachen für Rechnungseinwände zu erkennen und vorgelagerte Prozesse gezielt zu verbessern, damit künftig weniger Einwände entstehen. Woher beziehen Diese Informationen werden in der Regel in Oracle Advanced Collections oder Oracle Channel Revenue Management erfasst, sofern das Einwandmanagement formalisiert ist. Sie können in Tabellen wie AR_DISPUTE_HISTORY gespeichert sein. Beispiele Falsche MengePreisabweichungBeschädigte WareDienstleistung nicht erbracht | |||
| Kreditlimit CreditLimitAmount | Der für den Kunden genehmigte maximale Kreditbetrag. | ||
| Beschreibung Das Kreditlimit bezeichnet das gesamte Kreditrisiko, das ein Unternehmen bei einem bestimmten Kunden einzugehen bereit ist. Es wird im Rahmen der Kreditprüfung festgelegt. Dieses Attribut ist für das Dashboard zu den Auswirkungen von Kreditlimitentscheidungen entscheidend. Durch den Abgleich des genehmigten Kreditlimits mit dem späteren Zahlungsverhalten und abgeschriebenen Forderungen kann das Unternehmen die Wirksamkeit seiner Kreditrisikorichtlinien beurteilen. Die Analyse kann zeigen, ob übermäßig hohe Kreditlimits zu mehr Forderungsausfällen beitragen, und so helfen, den Kreditgenehmigungsprozess zu verbessern. Warum das wichtig ist Entscheidend für die Bewertung von Kreditrisikorichtlinien, indem das genehmigte Kreditlimit mit Zahlungsergebnissen und abgeschriebenen Forderungen abgeglichen wird. Woher beziehen Wird in Oracle Credit Management verwaltet und in der Regel in Tabellen zu Kundenkreditprofilen gespeichert, etwa HZ_CUST_PROFILE_AMTS. Beispiele 10000.0050000.00250000.00 | |||
| Rechnungsstatus InvoiceStatus | Der aktuelle Status der Rechnung im Verlauf ihrer Bearbeitung. | ||
| Beschreibung Der Rechnungsstatus zeigt, an welchem Punkt im Prozess sich eine Rechnung aktuell befindet. Häufige Statuswerte sind „Offen“, „Bezahlt“, „Strittig“, „Überfällig“ oder „Abgeschrieben“. Dieses Attribut bietet einen Überblick über den Stand der Forderungen. Im Process Mining lässt sich dieses Attribut verwenden, um Cases nach bestimmten Gruppen zu filtern, etwa nach allen offenen, überfälligen Rechnungen. Im Dashboard „Überfällige Rechnungen: Altersstruktur und Status“ ist es eine zentrale Dimension. Es zeigt den aktuellen Stand des Rechnungsbestands und hilft dabei, Maßnahmen zur Forderungsbeitreibung zu priorisieren. Warum das wichtig ist Bietet einen schnellen Überblick über den aktuellen Rechnungsstatus und erleichtert so das Filtern und Priorisieren von Maßnahmen zur Forderungsbeitreibung. Woher beziehen In der Regel in der Tabelle AR_PAYMENT_SCHEDULES_ALL in einem Feld namens STATUS verfügbar. Beispiele OffenGeschlossenStrittigIn der Forderungsbeitreibung | |||
| Rechnungswährung InvoiceCurrency | Die Währung, in der der Rechnungsbetrag angegeben ist. | ||
| Beschreibung Dieses Attribut gibt die Währung der Rechnung an, etwa USD, EUR oder GBP. In multinationalen Organisationen werden Rechnungen häufig in verschiedenen Währungen ausgestellt. Die Analyse von Daten in mehreren Währungen erfordert besondere Sorgfalt. Mit diesem Attribut können Sie die Prozessansicht nach Währung filtern oder für konsolidierte Finanzberichte die passenden Wechselkurse anwenden. So werden Geldbeträge korrekt interpretiert und vergleichbare Beträge einander gegenübergestellt. Warum das wichtig ist Unverzichtbar für die korrekte Interpretation von Finanzdaten in einer Umgebung mit mehreren Währungen und für genaue Finanzanalysen. Woher beziehen Üblicherweise als INVOICE_CURRENCY_CODE in der Tabelle RA_CUSTOMER_TRX_ALL zu finden. Beispiele USDEURGBPJPY | |||
| Überfällig? IsOverdue | Ein boolesches Kennzeichen dafür, ob das Zahlungsziel der Rechnung überschritten ist. | ||
| Beschreibung Dieses abgeleitete Attribut gibt mit einem einfachen Ja oder Nein an, ob eine Rechnung überfällig ist. Es wird in der Regel berechnet, indem das aktuelle Datum oder das Zahlungsdatum mit dem Fälligkeitsdatum der Rechnung verglichen wird. Das Kennzeichen ist besonders hilfreich, um Daten in Analysen zu filtern und zu segmentieren. Analysten können damit schnell alle überfälligen Rechnungen herausfiltern und deren Prozessverläufe, die Wirksamkeit von Maßnahmen zur Forderungsbeitreibung sowie weitere Merkmale untersuchen. Es vereinfacht die Erstellung von Dashboards und Kennzahlen zur Verwaltung überfälliger Forderungen, etwa des Dashboards „Überfällige Rechnungen: Altersstruktur und Status“. Warum das wichtig ist Kennzeichnet überfällige Rechnungen klar und erleichtert deren Analyse. Sie stehen im Mittelpunkt des Forderungsbeitreibungsprozesses. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Beispiele truefalse | |||
| Verzugstage DaysOverdue | Die Anzahl der Tage, um die eine Rechnung überfällig ist. | ||
| Beschreibung Diese berechnete Kennzahl gibt an, wie lange eine unbezahlte Rechnung bereits überfällig ist. Sie wird als Differenz zwischen dem aktuellen Datum bei offenen Rechnungen beziehungsweise dem Zahlungsdatum bei geschlossenen Rechnungen und dem Fälligkeitsdatum berechnet. Die Verzugstage sind eine wichtige Kennzahl für die Altersstrukturanalyse und die Priorisierung von Maßnahmen zur Forderungsbeitreibung. Im Dashboard „Überfällige Rechnungen: Altersstruktur und Status“ werden Rechnungen anhand dieser Kennzahl in Altersgruppen eingeteilt, etwa in 1 bis 30 oder 31 bis 60 Tage. So kann sich das Team für Forderungsbeitreibung auf die ältesten und risikoreichsten Forderungen konzentrieren. Warum das wichtig ist Beziffert die Zahlungsverzögerung und dient als zentrale Kennzahl für die Priorisierung der Forderungsbeitreibung und die Altersstrukturanalyse. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: CurrentDate - DueDate bei offenen Rechnungen oder PaymentDate - DueDate bei geschlossenen Rechnungen. Beispiele 1545920 | |||
| Zahlungsbedingungen PaymentTerms | Die vereinbarten Bedingungen, die festlegen, wann eine Zahlung fällig ist. | ||
| Beschreibung Die Zahlungsbedingungen legen fest, bis wann ein Kunde zahlen soll, beispielsweise „Netto 30 Tage“ oder „Netto 60 Tage“. Anhand dieser Bedingungen wird das Fälligkeitsdatum der Rechnung berechnet. Die Analyse des Zahlungsverhaltens nach Zahlungsbedingungen kann interessante Muster aufzeigen. So zahlen Kunden mit kürzeren Zahlungsfristen möglicherweise häufiger verspätet. Diese Erkenntnisse können dazu beitragen, Kreditrichtlinien zu überprüfen und zu optimieren sowie Kunden unterschiedlichen Strategien zur Forderungsbeitreibung zuzuordnen. Sie liefern außerdem wertvollen Kontext, um zu verstehen, warum bestimmte Rechnungen überfällig werden. Warum das wichtig ist Liefert Kontext zu den vereinbarten Zahlungsfristen und ermöglicht die Analyse des Zahlungsverhaltens bei unterschiedlichen Kreditbedingungen. Woher beziehen Die Daten werden in der Tabelle RA_TERMS gespeichert und mit dem Rechnungsvorgang verknüpft. Beispiele Netto 30 TageNetto 60 TageFällig bei Erhalt | |||
| Zugesagtes Zahlungsdatum PromiseToPayDate | Das Datum, an dem ein Kunde eine Zahlung zugesagt hat. | ||
| Beschreibung Im Rahmen der Forderungsbeitreibung kann ein Kunde zusagen, an einem späteren Datum zu zahlen. Dieses „zugesagte Zahlungsdatum“ wird erfasst, um die Zusage nachzuverfolgen. Dieses Attribut ist wichtig, um Workflows zur Forderungsbeitreibung zu steuern und die Verlässlichkeit von Zahlungszusagen zu bewerten. Durch den Vergleich des zugesagten Zahlungsdatums mit dem tatsächlichen Zahlungseingang können Mitarbeitende die Erfolgsquote dieser Zusagen ermitteln. Das hilft bei einer genaueren Prognose der Zahlungseingänge und bei der Entscheidung, wann die Forderungsbeitreibung eskaliert werden sollte, falls eine Zusage nicht eingehalten wird. Warum das wichtig ist Erfasst Zahlungszusagen von Kunden und unterstützt so die Prognose von Zahlungseingängen sowie die Bewertung von Verhandlungen zur Forderungsbeitreibung. Woher beziehen Im Modul Oracle Advanced Collections gespeichert, wahrscheinlich in Tabellen wie IEX_PROMISES_T. Beispiele 2023-06-102023-06-252023-07-05 | |||
Aktivitäten im Kreditmanagement und Forderungseinzug
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Mahnverfahren eingeleitet | Kennzeichnet den offiziellen Beginn des Mahnverfahrens für eine überfällige Rechnung. Dazu gehört häufig der Versand des ersten offiziellen Mahnschreibens. Das Ereignis wird üblicherweise protokolliert, wenn ein Mahnlauf ausgeführt und die Rechnung darin berücksichtigt wird. | ||
| Warum das wichtig ist Die Erfassung dieser Aktivität ist wichtig, um die Wirksamkeit des Mahnwesens und die Einhaltung der Mahnrichtlinien zu messen. Sie liefert einen Ausgangspunkt dafür, wie lange es dauert, bis ein Mahnverfahren zu einer Zahlung führt. Woher beziehen Das Ereignis wird im Oracle Advanced Collections-Modul protokolliert. Das Erstellungsdatum eines Mahndatensatzes in Tabellen wie IEX_DUNNINGS kennzeichnet das Ereignis, sofern der Datensatz mit der Transaktions-ID verknüpft ist. Erfassung Erstellungsdatum des zur Rechnung gehörenden Datensatzes in der Tabelle IEX_DUNNINGS. Ereignistyp explicit | |||
| Rechnung abgeschrieben | Kennzeichnet die offizielle Entscheidung, den Forderungseinzug einzustellen und den Rechnungsbetrag als uneinbringliche Forderung abzuschreiben. Dabei handelt es sich um eine explizite Finanztransaktion, die den Rechnungssaldo auf null setzt. | ||
| Warum das wichtig ist Dies ist ein kritischer Endpunkt, der das Scheitern des Forderungseinzugs markiert. Die Analyse von Abschreibungen nach Kundensegment, Region oder Kreditlimit hilft, Kreditrichtlinien und Einziehungsstrategien anzupassen und Verluste zu verringern. Woher beziehen Explizit erfasst, wenn in der Tabelle AR_ADJUSTMENTS_ALL eine Anpassung mit einer RECEIVABLES_TRX_ID angelegt wird, die auf eine Aktivität für uneinbringliche Forderungen oder Abschreibungen verweist. Erfassung Erstellungsdatum eines Datensatzes in AR_ADJUSTMENTS_ALL mit einem Aktivitätstyp für Abschreibungen. Ereignistyp explicit | |||
| Rechnung erstellt | Kennzeichnet die Erstellung des Rechnungstransaktionsdatensatzes in Oracle Fusion Financials. Damit beginnt der offizielle Lebenszyklus der Rechnung im Modul für Forderungen. Das Ereignis dient als primärer Ausgangspunkt für die Analyse. | ||
| Warum das wichtig ist Dies ist das entscheidende Start-Event für den Rechnungsprozess. Alle nachfolgenden Berechnungen von Zykluszeiten, etwa für Days Sales Outstanding (DSO) und die Zahlungszykluszeit der Rechnung, hängen von diesem ersten Timestamp ab. Woher beziehen Dieses explizit erfasste Ereignis stammt aus der Spalte CREATION_DATE oder TRX_DATE der Tabelle RA_CUSTOMER_TRX_ALL für eine bestimmte TRX_NUMBER (Rechnungsnummer). Erfassung Der Timestamp des Ereignisses entspricht dem CREATION_DATE aus der Tabelle RA_CUSTOMER_TRX_ALL. Ereignistyp explicit | |||
| Zahlung eingegangen | Kennzeichnet den Eingang einer Zahlung des Kunden, die möglicherweise noch keiner bestimmten Rechnung zugeordnet wurde. Das Ereignis wird erfasst, wenn im System ein Zahlungseingang angelegt wird. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein im Forderungseinzug: Das Geld ist eingegangen. Die Zeit bis zur Zuordnung der Zahlung zeigt, wie effizient die internen Abläufe sind. Woher beziehen Explizit erfasst anhand von RECEIPT_DATE in der Tabelle AR_CASH_RECEIPTS_ALL. Anschließend kann der Zahlungseingang über AR_RECEIVABLE_APPLICATIONS_ALL mit der Rechnung verknüpft werden, auf die er angerechnet wurde. Erfassung RECEIPT_DATE aus AR_CASH_RECEIPTS_ALL, verknüpft über die Zuordnungstabellen. Ereignistyp explicit | |||
| Zahlung zugeordnet | Kennzeichnet die Zuordnung einer eingegangenen Zahlung zu einer bestimmten Rechnung. Dadurch verringert sich der offene Rechnungsbetrag. Mit diesem Schritt wird die Zahlung offiziell mit der Rechnung verknüpft. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um eine Rechnung als bezahlt zu erfassen. Sie markiert den tatsächlichen Endpunkt für die Berechnung des Days Sales Outstanding (DSO) und den Zahlungsbuchungszyklus. Woher beziehen Dieses explizit erfasste Ereignis stammt aus APPLY_DATE in der Tabelle AR_RECEIVABLE_APPLICATIONS_ALL. Die Tabelle verknüpft einen Zahlungseingang mit einer Kundentransaktion (Rechnung). Erfassung APPLY_DATE aus AR_RECEIVABLE_APPLICATIONS_ALL für die betreffende Rechnung. Ereignistyp explicit | |||
| Zahlungsziel überschritten | Ein berechnetes Ereignis, das eintritt, wenn das aktuelle Datum das Fälligkeitsdatum der Rechnung überschreitet und die Rechnung noch nicht vollständig bezahlt ist. Damit wechselt die Rechnung vom Status „aktuell“ zu „überfällig“. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein setzt das Forderungseinziehungs- und Mahnverfahren in Gang. Für die Steuerung des Betriebskapitals und die Bewertung des Kreditrisikos ist es entscheidend, Anzahl und Wert der Rechnungen zu analysieren, deren Fälligkeitsdatum überschritten ist. Woher beziehen Das Ereignis wird berechnet, indem das aktuelle Systemdatum mit DUE_DATE in der Tabelle AR_PAYMENT_SCHEDULES_ALL für Rechnungen mit dem STATUS „OP“ (offen) verglichen wird. Erfassung Berechnetes Ereignis: tritt ein, wenn SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Ereignistyp calculated | |||
| Forderungseinziehungsstrategie zugewiesen | Dieses Ereignis tritt ein, wenn der überfälligen Rechnung oder dem Kunden automatisch eine Strategie zur Forderungseinziehung zugewiesen wird. Sie legt die Abfolge der Schritte und Aktivitäten fest, die das System oder die zuständige Person ausführt. | ||
| Warum das wichtig ist Dieses Ereignis gibt Aufschluss darüber, wie stark der Forderungseinzug automatisiert ist. Die Analyse der zugewiesenen Strategien und ihrer Ergebnisse hilft, die Vorgehensweisen für verschiedene Kundensegmente zu optimieren. Woher beziehen Das Ereignis wird im Oracle Advanced Collections-Modul protokolliert. Es lässt sich üblicherweise anhand des Erstellungsdatums einer Strategiezuweisung in Tabellen wie IEX_STRATEGIES oder verwandten Objekten ermitteln. Erfassung Erstellungsdatum des Strategie-Arbeitselements in den Tabellen zum Forderungseinzug, verknüpft mit dem Kunden oder der Transaktion. Ereignistyp explicit | |||
| Kreditprüfung abgeschlossen | Dieses Ereignis kennzeichnet den Abschluss einer Bonitätsprüfung für den Kunden, dem die Rechnung zugeordnet ist. Es wird üblicherweise ermittelt, indem das Rechnungsdatum mit dem jüngsten Abschlussdatum einer Kreditprüfung für das Kundenkonto verknüpft wird. So entsteht eine Grundlage für Analysen rund um die Kreditvergabe. | ||
| Warum das wichtig ist Die Analyse der Zeitspanne zwischen Kreditprüfung und Auftragserteilung hilft, Verzögerungen in den frühen Phasen des Order-to-Cash-Prozesses zu erkennen. Sie bildet die Grundlage für die Messung der KPI „Kreditfreigabezeit“ und zeigt, wie sich Kreditentscheidungen auswirken. Woher beziehen Ermittelt durch Abfrage von HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE für den Kunden der Rechnung (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Als Timestamp des Ereignisses dient das LAST_CREDIT_REVIEW_DATE, das vor dem CREATION_DATE der Rechnung liegt. Erfassung Verknüpfen Sie die Rechnung mit dem Datum der letzten Kreditprüfung des Kunden vor der Rechnungserstellung. Ereignistyp inferred | |||
| Maßnahme zum Forderungseinzug abgeschlossen | Kennzeichnet eine manuelle Maßnahme der für den Forderungseinzug zuständigen Person, etwa einen Telefonanruf, eine E-Mail oder eine Gesprächsnotiz. Solche Maßnahmen werden im Modul für den Forderungseinzug als „Aktivitäten“ oder „Interaktionen“ protokolliert. | ||
| Warum das wichtig ist Die Überwachung der Maßnahmen hilft, Effizienz und Wirksamkeit des manuellen Workflows für den Forderungseinzug zu messen. So können Sie die Häufigkeit der Aktivitäten und ihren Zusammenhang mit erfolgreichen Zahlungseingängen analysieren. Woher beziehen Die Daten stammen aus Tabellen zum Interaktions- oder Aktivitätsverlauf in Oracle Advanced Collections, beispielsweise JTF_IH_ACTIVITIES. Sie sind mit dem Kunden und gegebenenfalls mit der jeweiligen Rechnung verknüpft. Erfassung Erstellungs-Timestamp der Datensätze in JTF_IH_ACTIVITIES mit einem relevanten Ergebnis- oder Ursachencode. Ereignistyp explicit | |||
| Rechnung an Kunden gesendet | Gibt an, dass die Rechnung dem Kunden offiziell zugestellt wurde, elektronisch oder in Papierform. Ein Zustellungsmodul kann dieses Ereignis explizit protokollieren; alternativ lässt es sich anhand des Druckdatums der Rechnung ableiten. | ||
| Warum das wichtig ist Mit dieser Aktivität beginnt die Zahlungsfrist des Kunden. Ihre Erfassung ermöglicht eine genaue Berechnung der Verzugstage und zeigt Verzögerungen zwischen Rechnungserstellung und Benachrichtigung des Kunden. Woher beziehen Das Ereignis lässt sich anhand von LAST_PRINTED_DATE in RA_CUSTOMER_TRX_ALL erfassen. Alternativ kann es aus Integrationsprotokollen von E-Mail-Zustellsystemen oder anderen Kommunikationsplattformen abgeleitet werden. Erfassung Verwenden Sie LAST_PRINTED_DATE aus RA_CUSTOMER_TRX_ALL oder den Status aus einem Zustellungsprotokoll. Ereignistyp inferred | |||
| Rechnung geschlossen | Das Ereignis tritt ein, wenn der offene Rechnungsbetrag auf null sinkt, sei es durch eine Zahlung, die Zuordnung eines Gutschriftsbelegs oder eine Anpassung. Damit ist der Lebenszyklus der Rechnung erfolgreich abgeschlossen. | ||
| Warum das wichtig ist Dieses Ereignis kennzeichnet einen wichtigen erfolgreichen Endpunkt des Prozesses. Die Überwachung geschlossener Rechnungen ist grundlegend, um die Gesamtsituation des Forderungsbestands zu verstehen. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle AR_PAYMENT_SCHEDULES_ALL, bei der sich STATUS in „CL“ (geschlossen) ändert. Als Timestamp dient das LAST_UPDATE_DATE dieser Änderung. Erfassung Erkennen Sie, wenn AR_PAYMENT_SCHEDULES_ALL.STATUS für die Rechnung den Wert „CL“ annimmt. Ereignistyp inferred | |||
| Streitfall erfasst | Gibt an, dass der Kunde die Rechnung ganz oder teilweise offiziell beanstandet hat. Dies wird üblicherweise durch eine Statusänderung im Zahlungsplan der Rechnung erfasst. | ||
| Warum das wichtig ist Diese Aktivität markiert den Beginn der Klärung des Streitfalls. Die Zeitspanne zwischen Erfassung und Klärung ist entscheidend, um Engpässe zu erkennen, die den Zahlungseingang verzögern. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle AR_PAYMENT_SCHEDULES_ALL, bei der das Feld STATUS auf „DS“ (beanstandet) wechselt. Der Timestamp kann aus Audit-Tabellen oder dem Datum der letzten Aktualisierung stammen. Erfassung Erkennen Sie, wenn sich AR_PAYMENT_SCHEDULES_ALL.STATUS für die Rechnung in „DS“ ändert. Ereignistyp inferred | |||
| Streitfall geklärt | Gibt an, dass ein erfasster Streitfall untersucht und eine Lösung gefunden wurde. Das Ereignis wird erfasst, wenn der Beanstandungsstatus der Rechnung aufgehoben wird. | ||
| Warum das wichtig ist Dieses Ereignis markiert das Ende des Klärungsprozesses. Die Zeitspanne zwischen „Streitfall erfasst“ und diesem Ereignis ist eine wichtige KPI zur Messung der betrieblichen Effizienz und ihrer Auswirkungen auf den Cashflow. Woher beziehen Abgeleitet, wenn sich der STATUS in AR_PAYMENT_SCHEDULES_ALL nach einem Gutschriftsbeleg oder einer Anpassung von „DS“ (beanstandet) zurück zu „OP“ (offen) oder zu „CL“ (geschlossen) ändert. Erfassung Erkennen Sie, wenn sich AR_PAYMENT_SCHEDULES_ALL.STATUS von „DS“ in einen anderen Status ändert. Ereignistyp inferred | |||
| Zahlungszusage erfasst | Kennzeichnet eine im System erfasste verbindliche Vereinbarung, in der ein Kunde zusagt, an einem bestimmten Datum zu zahlen. Sie ist ein wichtiges Ergebnis der Maßnahmen zum Forderungseinzug. | ||
| Warum das wichtig ist Die Erfassung von Zahlungszusagen und ihrer Einhaltungsquote ist eine wichtige Leistungskennzahl für die zuständigen Mitarbeitenden. Sie hilft, Zahlungseingänge aus überfälligen Forderungen vorherzusagen und die Wirksamkeit der Maßnahmen zu bewerten. Woher beziehen Wird explizit in Oracle Advanced Collections angelegt. Das Erstellungsdatum stammt aus der Tabelle IEX_PROMISE_DETAILS. Erfassung Erstellungsdatum aus der Tabelle IEX_PROMISE_DETAILS für die jeweilige Rechnung. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Oracle BI Publisher öffnen: Melden Sie sich bei Ihrer Oracle-Fusion-Financials-Umgebung an. Öffnen Sie den Bereich „Reports and Analytics“, indem Sie auf das Navigator-Symbol und anschließend auf Tools > Reports and Analytics klicken.
- Neues Datenmodell erstellen: Klicken Sie im Bereich „Reports and Analytics“ auf „Browse Catalog“. Öffnen Sie im Katalog das Dropdown-Menü „New“ und wählen Sie „Data Model“ aus.
- SQL-Query-Datensatz definieren: Klicken Sie im Editor für Datenmodelle auf das Symbol „+“, um einen Datensatz hinzuzufügen, und wählen Sie „SQL Query“ aus.
- Datenquelle konfigurieren: Geben Sie dem neuen Datensatz einen aussagekräftigen Namen, zum Beispiel „CreditCollectionsEventLog“. Wählen Sie als Datenquelle „FSCM“ oder die entsprechende Oracle-Fusion-Anwendungsdatenbank aus. Legen Sie als SQL-Typ „Standard SQL“ fest.
- SQL-Query eingeben: Kopieren Sie die vollständige SQL-Query aus dem Abschnitt „query“ dieses Dokuments und fügen Sie sie in das Textfeld „SQL Query“ ein.
- Query-Parameter definieren: Die Query verwendet Parameter wie
:P_START_DATEund:P_END_DATE, um den Zeitraum einzugrenzen. BI Publisher erkennt diese automatisch. Sie können sie als Benutzereingaben konfigurieren und den Datentyp „Date“ festlegen. - Datenmodell speichern und testen: Speichern Sie das Datenmodell in einem freigegebenen oder benutzerdefinierten Ordner. Um die Query zu prüfen, öffnen Sie die Registerkarte „Data“, geben Sie Beispielwerte für die Parameter ein, etwa einen aktuellen Zeitraum, und klicken Sie auf „View“, um eine Stichprobe der Ausgabedaten anzuzeigen. Prüfen Sie, ob alle Spalten korrekt angezeigt werden.
- Neuen Bericht erstellen: Kehren Sie zum Katalog zurück, öffnen Sie das Dropdown-Menü „New“ und wählen Sie „Report“ aus. Wählen Sie im Dialogfeld „Create Report“ die Option „Use Data Model“ und anschließend das soeben gespeicherte Datenmodell aus.
- Berichtseigenschaften konfigurieren: Für die Datenextraktion genügt im Berichtseditor ein einfaches Tabellenlayout. Legen Sie das Standardausgabeformat fest. Für Process Mining empfiehlt sich CSV. Klicken Sie dazu auf „View a List“, suchen Sie in der Liste „Output Formats“ nach „CSV“ und aktivieren Sie das Kontrollkästchen. Sie können andere Formate deaktivieren, um die Bedienung zu vereinfachen.
- Bericht speichern: Speichern Sie den Bericht im selben Ordner wie das Datenmodell.
- Extraktion planen: Sie können den Bericht für eine automatisierte Extraktion einplanen. Öffnen Sie dazu den Bericht, klicken Sie auf „Actions“ und wählen Sie „Schedule“. Legen Sie die Häufigkeit fest, zum Beispiel täglich, wählen Sie CSV als Ausgabeformat und bestimmen Sie das Ziel für die Bereitstellung, etwa ein Verzeichnis auf einem Content-Server oder einen externen Server per FTP.
Konfiguration
- Voraussetzungen: Der Benutzer, der den Bericht erstellt und ausführt, benötigt geeignete BI-Rollen, zum Beispiel „BI Administrator“ oder „BI Author“, sowie Datenzugriffsberechtigungen für die zugrunde liegenden Financials-Tabellen (AR, IEX, HZ, JTF).
- Datenquelle: Führen Sie die Query für die Hauptdatenbank der Anwendung aus, die üblicherweise „FSCM“ heißt.
- Parameter für den Zeitraum: Verwenden Sie unbedingt die Parameter
:P_START_DATEund:P_END_DATE, um das Datenvolumen zu begrenzen. Testen Sie zunächst mit einem kurzen Zeitraum, etwa einem Monat. Für den Produktivbetrieb sind rollierende Zeiträume von 3 bis 6 Monaten üblich. - Filterung: Bei großen Organisationen empfiehlt es sich, der
WHERE-Klausel im Common Table Expressioninvoices_baseeinen Parameter fürBU_NAME(Business Unit Name) hinzuzufügen. So können Sie die Daten jeweils für eine Geschäftseinheit verarbeiten. - Leistungshinweise: Die Query verknüpft mehrere große Transaktionstabellen. Bei einem langen Zeitraum ohne Filter kann die Ausführung in BI Publisher lange dauern oder wegen einer Zeitüberschreitung abbrechen. Planen Sie den Bericht außerhalb der Spitzenzeiten ein.
- Ausgabeformat: Stellen Sie sicher, dass als Standard- oder geplantes Ausgabeformat CSV festgelegt ist. So erhalten Sie eine übersichtliche Datei mit Trennzeichen, die sich problemlos in Process-Mining-Tools einlesen lässt. Prüfen Sie in den CSV-Ausgabeeigenschaften, ob Trennzeichen und Zeichenkodierung korrekt eingestellt sind.
a Beispielabfrage sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' Möchten Sie loslegen?
Bereiten Sie Ihre Daten mit diesem Template für die Analyse vor und gewinnen Sie wertvolle Erkenntnisse zu Ihrem Prozess für Kreditmanagement und Forderungseinzug. Beginnen Sie noch heute mit der Prozessoptimierung.
Optimieren Sie noch heute Ihr Kreditmanagement und Ihren Forderungseinzug
Verkürzen Sie die Zykluszeit um 30 % und verbessern Sie Ihre finanzielle Lage in Oracle Fusion.
Keine Kreditkarte erforderlich. In wenigen Minuten startklar.