> Kontinuierliche Prozessverbesserung > Purchase to Pay: Rechnungsverarbeitung > Oracle Fusion Financials > Daten Template

Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Oracle Fusion Financials

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess (20) Aktivitäten bei der Rechnungsverarbeitung im Purchase-to-Pay-Prozess (15) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Dieses Template unterstützt Sie dabei, die wichtigsten Daten für die Analyse der Rechnungsverarbeitung im Purchase-to-Pay-Prozess in Oracle Fusion Financials zusammenzustellen. Es beschreibt die relevanten Attribute und Aktivitäten und erläutert, wie Sie diese Informationen aus Ihrem System extrahieren. So können Sie ein präzises und umfassendes Event Log für Process Mining erstellen.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Nachverfolgung
Anleitung zur Datenextraktion aus Oracle Fusion Financials

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

Template herunterladen

Attribute für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie die Rechnungsverarbeitung im Purchase-to-Pay-Prozess umfassend analysieren können.

3 Erforderlich 7 Empfohlen 10 Optional

	Name	Beschreibung
	Rechnungsnummer InvoiceNumber	Die eindeutige Kennung einer Lieferantenrechnung.
Beschreibung Die Rechnungsnummer dient als primäre Case-ID. Sie verknüpft alle Aktivitäten und Ereignisse zu einer einzelnen Lieferantenrechnung, von ihrer Erstellung bis zur abschließenden Zahlung. Jede Rechnung wird in der Prozessanalyse als eigener Case behandelt. Beim Process Mining ist dieses Attribut entscheidend, um den gesamten Ablauf jeder Rechnung zu rekonstruieren. Es ermöglicht die Analyse von Prozessabläufen, Zykluszeiten und Abweichungen für jede einzelne Rechnung. Über die Rechnungsnummer lassen sich Aktivitäten wie Validierung, Freigabe und Zahlung zu einem zusammenhängenden Prozessverlauf verbinden. Warum das wichtig ist Diese wichtige Case-ID verknüpft alle zugehörigen Prozessschritte und ermöglicht es, den gesamten Lebenszyklus einer Rechnung nachzuverfolgen. Woher beziehen Dieses Attribut befindet sich üblicherweise in der Tabelle AP_INVOICES_ALL, in der Spalte INVOICE_NUM. Beispiele INV-2023-001987654321ACME-FIN-5501
	Aktivität ActivityName	Der Name der geschäftlichen Aktivität oder des Ereignisses im Rechnungsprozess.
Beschreibung Dieses Attribut bezeichnet einen bestimmten Schritt oder eine Statusänderung im Lebenszyklus einer Rechnung, etwa „Rechnung erstellt“, „Rechnung freigegeben“ oder „Zahlung ausgeführt“. Die Abfolge dieser Ereignisse bildet den Prozessablauf. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten ist ein Kernbestandteil des Process Mining. Sie hilft dabei, den tatsächlichen Prozessablauf zu ermitteln, Engpässe durch verzögerte Aktivitäten zu erkennen und Abweichungen oder Nacharbeitsschleifen aufzudecken, etwa wenn eine Rechnung nach der Freigabe abgelehnt wird. Warum das wichtig ist Dieses Attribut legt die Prozessschritte fest. Das ist wichtig, um die Prozesslandkarte zu visualisieren, Ablaufvarianten zu analysieren und Engpässe zu erkennen. Woher beziehen Dieses Attribut wird üblicherweise aus einer Kombination von Statusfeldern, Audit-Tabellen oder Workflow-Protokollen in Oracle Fusion Financials abgeleitet, etwa aus AP_INVOICES_ALL.WFAPPROVAL_STATUS oder zugehörigen Workflow-Tabellen. Beispiele Rechnung validiertRechnung gesperrtRechnung freigegebenZahlung ausgeführt
	Startzeit EventTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Dieses Attribut enthält Datum und Uhrzeit jeder Aktivität im Rechnungsprozess. Es ist für alle zeitbezogenen Prozessanalysen entscheidend, darunter die Berechnung von Zykluszeiten, Prozessdauern und Wartezeiten zwischen Schritten. Anhand dieses Timestamps können Process-Mining-Werkzeuge die Ereignisse chronologisch ordnen und so die genaue Abfolge der Aktivitäten für jede Rechnung rekonstruieren. Dadurch lassen sich wichtige Leistungskennzahlen wie die durchschnittliche Rechnungszykluszeit berechnen und die Prozessphasen ermitteln, die am meisten Zeit beanspruchen. Warum das wichtig ist Dieser Timestamp ist entscheidend für die Berechnung aller zeitbezogenen Leistungskennzahlen, etwa Zykluszeiten und Engpässe. Woher beziehen Dieser Timestamp wird aus verschiedenen Datumsfeldern in Oracle-Fusion-Tabellen abgeleitet, etwa aus CREATION_DATE oder LAST_UPDATE_DATE in Tabellen wie AP_INVOICES_ALL sowie in zugehörigen Workflow- und Zahlungstabellen. Beispiele 2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
	Benutzername UserName	Name des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut gibt an, welcher Benutzer oder Systemagent für eine Aktivität verantwortlich war, etwa für die Prüfung einer Rechnung, das Setzen einer Zahlungssperre oder die Freigabe einer Zahlung. Damit lässt sich der Prozess nach menschlichen oder systemseitigen Ressourcen auswerten. Eine Auswertung nach Benutzern zeigt, wie sich die Arbeitslast verteilt, wer besonders leistungsstark ist und wo möglicherweise Schulungsbedarf oder Compliance-Probleme bestehen. So lässt sich beispielsweise feststellen, ob bestimmte Benutzer regelmäßig in Nacharbeits-Schleifen eingebunden sind oder ob einzelne Genehmigungsschritte stets von derselben Person bearbeitet werden. Dadurch kann ein potenzieller Ausfallpunkt entstehen. Warum das wichtig ist Ermöglicht die Analyse der Ressourcenleistung und der Arbeitslastverteilung sowie die Ermittlung der Benutzer oder Teams, die an bestimmten Prozessschritten beteiligt sind. Woher beziehen Diese Informationen sind häufig in Audit-Spalten wie CREATED_BY oder LAST_UPDATED_BY in Tabellen wie AP_INVOICES_ALL oder in zugehörigen Workflow-Protokollen gespeichert. Beispiele john.doejane.smithSystem.Admin
	Endzeit EndTime	Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit markiert den Abschluss einer bestimmten Aktivität. Während die Startzeit den Beginn angibt, bildet die Endzeit den Schlusspunkt. So lässt sich die Dauer einzelner Schritte präzise berechnen. In der Analyse ergibt die Differenz zwischen Endzeit und Startzeit die Verarbeitungszeit jeder Aktivität. Das ist für eine detaillierte Leistungsanalyse wichtig, denn so lassen sich aktive Bearbeitungszeit und Wartezeit unterscheiden. Beispielsweise können Sie messen, wie lange eine genehmigende Person tatsächlich mit einer Genehmigungsaufgabe beschäftigt war und wie lange diese in ihrer Warteschlange lag. Warum das wichtig ist Ermöglicht die präzise Berechnung der Verarbeitungszeiten von Aktivitäten und trennt aktive Arbeitszeit von Wartezeit. Woher beziehen Dieses konzeptionelle Attribut wird aus der Startzeit des nachfolgenden Ereignisses in der Sequenz eines bestimmten Cases abgeleitet. Beispiele 2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
	Lieferantenname VendorName	Name des Lieferanten, der die Rechnung ausgestellt hat.
Beschreibung Dieses Attribut gibt an, von welchem Lieferanten die Rechnung stammt. Die Lieferanteninformationen liefern wichtigen geschäftlichen Kontext zur Finanztransaktion. Eine Auswertung des Prozesses nach Lieferanten kann wichtige Erkenntnisse zu Lieferantenbeziehungen und deren Leistung liefern. Sie zeigt beispielsweise, ob Rechnungen bestimmter Lieferanten häufiger Abweichungen beim Abgleich, Zahlungssperren oder Verzögerungen aufweisen. Diese Informationen können dazu beitragen, die Aufnahme neuer Lieferanten, die Kommunikation und die Effizienz der gesamten Lieferkette zu verbessern. Sie helfen auch dabei, mögliche Doppelzahlungen zu erkennen. Warum das wichtig ist Ermöglicht eine lieferantenspezifische Prozessanalyse, mit der sich Probleme bei einzelnen Lieferanten erkennen lassen, die Verzögerungen oder Ausnahmen verursachen. Woher beziehen In der Tabelle POZ_SUPPLIERS zu finden. Die Rechnungstabelle AP_INVOICES_ALL enthält eine VENDOR_ID, über die sich die Tabelle mit den Lieferantendaten verknüpfen lässt. Beispiele Acme CorporationGlobal Tech Inc.Office Supplies Co.
	Rechnungsbetrag InvoiceAmount	Gesamtbetrag der Rechnung.
Beschreibung Der Rechnungsbetrag entspricht der Gesamtsumme, die laut Rechnung an den Lieferanten zu zahlen ist. Dieses wichtige Finanzattribut beeinflusst den gesamten Prozess. Es bestimmt häufig den Genehmigungsweg, den Prüfaufwand und die Zahlungspriorität. In der Process-Mining-Analyse dient der Rechnungsbetrag als zentrale Dimension für Filter und Segmentierungen. So können Analysten den Prozess für Rechnungen mit hohen und niedrigen Beträgen vergleichen und prüfen, ob unterschiedliche Abläufe oder deutlich abweichende Zykluszeiten auftreten. Der Betrag ist außerdem wichtig für die Berechnung finanzieller KPIs und die Bewertung der finanziellen Auswirkungen von Prozessineffizienzen wie verspäteten Zahlungen. Warum das wichtig ist Dieser Wert ist entscheidend für die Finanzanalyse, die Untersuchung wertabhängiger Prozessabweichungen und KPIs wie die Genehmigungskonformitätsrate. Woher beziehen In der Tabelle AP_INVOICES_ALL in der Spalte INVOICE_AMOUNT zu finden. Beispiele 1500.00250.75125000.50
	Rechnungsstatus InvoiceStatus	Aktueller Status der Rechnung im Verlauf ihres Lebenszyklus.
Beschreibung Dieses Attribut gibt den zuletzt bekannten Status der Rechnung wieder, zum Beispiel „Validiert“, „Erneute Validierung erforderlich“, „Bezahlt“ oder „Storniert“. Es zeigt jederzeit, an welcher Stelle des Prozesses sich eine Rechnung befindet. Der Rechnungsstatus ist entscheidend für das Dashboard „Verteilung der aktuellen Rechnungsstatus“. Damit können Betriebsverantwortliche Rückstände erkennen und den Gesamtzustand der Rechnungsverarbeitung überwachen. Eine Analyse der Statusänderungen im Zeitverlauf bietet außerdem einen vereinfachten Überblick über den Prozessfluss. Warum das wichtig ist Zeigt den aktuellen Status der Rechnungen an und ist damit eine wichtige Grundlage für operative Dashboards zur Überwachung von Rückständen und Arbeitslast. Woher beziehen Ziehen Sie die Dokumentation zu Oracle Fusion Financials heran. Der Status kann aus Feldern wie WFAPPROVAL_STATUS in AP_INVOICES_ALL oder aus zugehörigen Genehmigungs- und Zahlungstabellen abgeleitet werden. Beispiele ValidiertBezahltStorniertErneute Validierung erforderlich
	Unternehmenscode CompanyCode	Kennung der juristischen Person oder des Unternehmens, das die Rechnung verarbeitet.
Beschreibung Der Unternehmenscode bezeichnet die Geschäftseinheit innerhalb der Organisation, die finanziell für die Rechnung verantwortlich ist. In Organisationen mit mehreren Unternehmen ist dies ein grundlegendes Organisationsmerkmal. Mit diesem Attribut lässt sich der Prozess nach juristischen Personen segmentieren. So können Sie die Prozessleistung in verschiedenen Unternehmensbereichen vergleichen, spezifische Engpässe oder Compliance-Probleme erkennen und KPIs auf Unternehmensebene ausweisen. Der Unternehmenscode beeinflusst häufig auch die Auswahl des passenden Genehmigungs-Workflows. Warum das wichtig ist Ermöglicht den Vergleich von Prozessen und Leistungskennzahlen zwischen verschiedenen juristischen Personen oder Geschäftseinheiten innerhalb der Organisation. Woher beziehen In AP_INVOICES_ALL wird dies üblicherweise durch das Feld LEGAL_ENTITY_ID oder ein ähnliches Feld angegeben. Über eine Verknüpfung mit Hauptbuchtabellen lässt sich der zugehörige Code oder Name ermitteln. Beispiele 1001US01DE01
	Zahlungsziel PaymentDueDate	Datum, bis zu dem die Rechnung an den Lieferanten bezahlt werden muss.
Beschreibung Das Zahlungsziel wird anhand der mit dem Lieferanten vereinbarten Zahlungsbedingungen berechnet. Es ist die Frist für die Zahlung, mit der sich Strafgebühren vermeiden, gute Lieferantenbeziehungen pflegen und mögliche Skonti nutzen lassen. Dieses Attribut ist für das Dashboard „Pünktliche Zahlungsleistung“ und den zugehörigen KPI erforderlich. Durch den Vergleich des tatsächlichen Zahlungszeitpunkts mit dem Zahlungsziel lässt sich die Zahlung als pünktlich oder verspätet einstufen. So kann die Organisation die Pünktlichkeit ihrer Zahlungen überwachen und verbessern. Warum das wichtig ist Dient als Grundlage für die Messung der Zahlungspünktlichkeit, einem wichtigen KPI für das Lieferantenmanagement und die finanzielle Gesundheit. Woher beziehen Dieses Datum ist häufig in Zahlungstermin-Tabellen wie AP_PAYMENT_SCHEDULES_ALL verfügbar, die mit der Rechnung verknüpft sind. Beispiele 2023-05-152023-06-012023-06-30
	Bestellnummer PurchaseOrderNumber	Kennung der Bestellung, die der Rechnung zugeordnet ist.
Beschreibung Dieses Attribut verknüpft die Rechnung mit der zugehörigen Bestellung (PO), mit der die Beschaffung der Waren oder Dienstleistungen beauftragt wurde. Rechnungen können sich auf eine Bestellung beziehen oder ohne Bestellbezug vorliegen. Eine Auswertung nach Bestellnummer stellt den Bezug zum Beschaffungsteil des P2P-Prozesses her. Sie zeigt, wie gut der Beschaffungsprozess die Vorgaben einhält und ob Probleme bei der Rechnungsstellung, etwa Abweichungen beim Abgleich, auf Fehler in der ursprünglichen Bestellung zurückzuführen sind. Anhand der Bestellnummer lässt sich der Rechnungsverarbeitungsprozess in Abläufe mit und ohne Bestellbezug unterteilen und analysieren. Warum das wichtig ist Verknüpft die Rechnung mit dem Beschaffungsprozess und ist ein wichtiges Attribut für die Analyse von Rechnungsabläufen mit und ohne Bestellbezug. Woher beziehen Diese Informationen sind verfügbar, wenn die Rechnungspositionen in AP_INVOICE_LINES_ALL über PO_DISTRIBUTION_ID mit den Bestellverteilungen verknüpft werden. Beispiele PO-2023-5001600789PO-FIN-9981
	Grund der Abweichung beim Abgleich MatchingDiscrepancyReason	Konkreter Grund für eine Abweichung zwischen Rechnung, Bestellung und Wareneingang.
Beschreibung Dieses Attribut gibt an, warum eine Rechnung den automatisierten Abgleich nicht bestanden hat. Häufige Gründe sind Abweichungen bei Preis, Menge oder Artikelnummer zwischen Rechnung und zugehöriger Bestellung oder Wareneingang. Diese Informationen sind wichtig für das Dashboard „Abweichungsrate beim Rechnungsabgleich“. Durch die Kategorisierung und Analyse der Abweichungsgründe können Unternehmen systematische Probleme in der Beschaffung oder im Wareneingang erkennen. Auf dieser Grundlage lassen sich Korrekturmaßnahmen ergreifen, um den Anteil der Rechnungen zu erhöhen, die ohne manuelle Bearbeitung verarbeitet werden. Warum das wichtig ist Erklärt, warum Rechnungen den automatisierten Abgleich nicht bestehen, und liefert Erkenntnisse, um die Trefferquote beim ersten Abgleich zu verbessern und manuelle Nacharbeit zu reduzieren. Woher beziehen Ziehen Sie die Dokumentation zu Oracle Fusion Financials heran. Der Grund kann als bestimmter Sperrgrund in AP_HOLDS_ALL oder in zugehörigen Tabellen mit Abgleichdetails gespeichert sein. Beispiele Stückpreis weicht von der Bestellung abAbgerechnete Menge > gelieferte MengeUngültiger Artikel auf der Rechnung
	Grund der Zahlungssperre HoldReason	Grund, aus dem eine Rechnung gesperrt oder mit einer Zahlungssperre versehen wurde.
Beschreibung Wird eine Rechnung gesperrt, gibt dieses Attribut den Grund an, zum Beispiel „Preisabweichung“, „Mengenabweichung“ oder „Wareneingang ausstehend“. So wird nachvollziehbar, warum der reguläre Prozessfluss unterbrochen wurde. Dieses Attribut ist die zentrale Dimension des Dashboards „Trends und Analyse von Zahlungssperren“. Durch die Analyse der Häufigkeit verschiedener Sperrgründe kann das Unternehmen die Ursachen von Zahlungssperren erkennen und beheben, etwa Probleme im Beschaffungsprozess oder Fehler bei der Rechnungsstellung durch Lieferanten. So lassen sich Verzögerungen bei der Verarbeitung reduzieren. Warum das wichtig ist Zeigt die Ursachen von Zahlungssperren auf und ermöglicht gezielte Verbesserungen, um Sperren und Zahlungsverzögerungen zu reduzieren. Woher beziehen Informationen zu Zahlungssperren sind üblicherweise in der Tabelle AP_HOLDS_ALL gespeichert. Diese ist mit der Rechnung verknüpft und enthält einen Sperrgrund oder -code. Beispiele PreisabweichungAbgerechnete Menge übersteigt gelieferte MengeUngültige Bestellnummer
	Letzte Datenaktualisierung LastUpdateDate	Timestamp der letzten Aktualisierung des Datensatzes im Quellsystem.
Beschreibung Dieses Attribut gibt an, wann die zugrunde liegenden Daten in Oracle Fusion Financials zuletzt geändert wurden. Es dient dazu, inkrementelle Datenladungen zu steuern und das Process-Mining-Modell aktuell zu halten. Für die Analyse des Prozessflusses wird dieser technische Timestamp zwar nicht direkt verwendet, für die Aktualität und Integrität der Daten ist er jedoch entscheidend. Datenpipelines können damit effizient nur neue oder seit der letzten Aktualisierung geänderte Datensätze abfragen. Das reduziert die Belastung des Quellsystems. Warum das wichtig ist Ermöglicht effiziente, inkrementelle Datenladungen und hält die Prozessanalyse aktuell, ohne dass ein vollständiges Neuladen erforderlich ist. Woher beziehen In vielen Oracle-Fusion-Tabellen, darunter AP_INVOICES_ALL, häufig als LAST_UPDATE_DATE zu finden. Beispiele 2023-05-20T11:00:00Z2023-05-21T16:45:00Z
	Nacharbeit IsRework	Boolesches Kennzeichen, das Aktivitäten in einer Nacharbeits-Schleife identifiziert.
Beschreibung Dieses Kennzeichen wird für Aktivitäten auf „true“ gesetzt, die auf eine Abweichung vom idealen Prozessfluss hindeuten, etwa „Rechnung korrigiert“ oder eine erneute Aktivität „Rechnung validiert“ nach einer Ablehnung. So lässt sich ineffiziente Nacharbeit gezielt kennzeichnen und quantifizieren. Dieses Attribut ist wichtig für das Dashboard „Nacharbeits- und Ausnahmebehandlungsrate“. Mit gekennzeichneten Nacharbeitsaktivitäten können Analysten Umfang und Kosten der Nacharbeit ermitteln, deren Ursachen erkennen und die Wirkung von Verbesserungsmaßnahmen messen, mit denen Fehler von Anfang an vermieden werden sollen. Warum das wichtig ist Kennzeichnet und quantifiziert Nacharbeit ausdrücklich. So lassen sich Häufigkeit, Ursachen und Auswirkungen von Prozessineffizienzen leichter analysieren. Woher beziehen Dieses Attribut wird berechnet. Die Logik wird bei der Datentransformation festgelegt, um Aktivitätssequenzen zu identifizieren, die Nacharbeit darstellen. Beispiele truefalse
	Name der genehmigenden Person ApproverName	Name der Person, die die Rechnung genehmigt oder abgelehnt hat.
Beschreibung Dieses Attribut erfasst die Person, die im Genehmigungsschritt eine Aktion ausgeführt hat. Es wird für Aktivitäten wie „Rechnung genehmigt“ oder „Rechnung abgelehnt“ gespeichert. In der Analyse dient der Name der genehmigenden Person dazu, die Arbeitslast bei Genehmigungen zu untersuchen, individuelle Genehmigungszykluszeiten zu messen und die Einhaltung von Genehmigungsrichtlinien zu prüfen. Für den KPI „Genehmigungskonformitätsrate“ lässt sich das Attribut anhand der Vertretungsregeln prüfen, die für den Rechnungsbetrag und den Unternehmenscode gelten. Warum das wichtig ist Unverzichtbar für die Analyse von Genehmigungszykluszeiten, die Prüfung der Einhaltung von Genehmigungsmatrix-Richtlinien und die Untersuchung der Arbeitslastverteilung. Woher beziehen Diese Informationen sind in den Oracle-Fusion-Workflow- oder Genehmigungsverlaufstabellen zum Rechnungsobjekt gespeichert. Beispiele David WilsonSarah JohnsonMichael Brown
	Quellsystem SourceSystem	Gibt an, in welchem Ursprungssystem die Ereignisdaten erfasst wurden.
Beschreibung Dieses Attribut bezeichnet die Quellanwendung oder das Modul, das die Daten erzeugt hat, zum Beispiel Oracle Fusion Financials. In Umgebungen mit mehreren integrierten Systemen hilft dieses Feld, die Herkunft der einzelnen Prozessschritte zu unterscheiden. Die Kenntnis des Quellsystems ist für die Datenvalidierung, die Fehlerbehebung und die Analyse systemspezifischer Prozessabweichungen hilfreich. Sie schafft Klarheit in komplexen IT-Landschaften, in denen eine Rechnung mehrere Anwendungen durchläuft. Warum das wichtig ist Das Attribut gibt Aufschluss über die Herkunft der Daten. Das ist wichtig für Data Governance, Fehlerbehebung und die Analyse systemspezifischer Prozessabläufe. Woher beziehen Häufig wird während der Datenextraktion ein statischer Wert hinzugefügt, der die Herkunft des Datensatzes kennzeichnet. Beispiele Oracle Fusion FinancialsOracle Payables Cloud
	Rechnungsdatum InvoiceDate	Datum auf dem Rechnungsdokument des Lieferanten.
Beschreibung Dieses Attribut gibt das Datum an, an dem der Lieferant die Rechnung offiziell ausgestellt hat. Es ist eine wichtige Angabe auf dem Quelldokument und dient als Ausgangspunkt für die Berechnung des Zahlungsziels anhand der vereinbarten Zahlungsbedingungen. Das Rechnungsdatum markiert zwar nicht immer den Beginn des internen Prozesses, liefert aber wichtigen Kontext. Zusammen mit Lieferantenname und Rechnungsbetrag hilft es, mögliche Doppelrechnungen zu erkennen. Auch die Verzögerung zwischen dem Rechnungsdatum und der Erfassung der Rechnung im System kann auf Ineffizienzen bei der Poststelle oder der Rechnungserfassung hinweisen. Warum das wichtig ist Wichtige Angabe, um Doppelrechnungen zu erkennen und Zahlungsziele zu berechnen. Woher beziehen Standardfeld in der Tabelle AP_INVOICES_ALL mit dem Namen INVOICE_DATE. Beispiele 2023-04-102023-05-012023-05-25
	Währung InvoiceCurrencyCode	Währung des Rechnungsbetrags.
Beschreibung Dieses Attribut gibt an, in welcher Währung der Rechnungsbetrag ausgewiesen ist, zum Beispiel USD, EUR oder GBP. Es liefert den erforderlichen Kontext zum Feld Rechnungsbetrag. In einem global tätigen Unternehmen ist die Auswertung von Rechnungen nach Währung für die Finanzberichterstattung und die Untersuchung regionaler Prozessunterschiede wichtig. So werden Geldbeträge korrekt interpretiert und Zahlungspraktiken oder Genehmigungsschwellen lassen sich währungsspezifisch analysieren. Warum das wichtig ist Liefert den nötigen Kontext für Geldbeträge und ermöglicht deren korrekte Interpretation und Analyse, insbesondere in multinationalen Unternehmen. Woher beziehen In der Tabelle AP_INVOICES_ALL in der Spalte INVOICE_CURRENCY_CODE zu finden. Beispiele USDEURGBPCAD
	Zahlung pünktlich IsOnTimePayment	Boolesches Kennzeichen dafür, ob die Rechnung bis zum Zahlungsziel bezahlt wurde.
Beschreibung Dieses Kennzeichen wird auf „true“ gesetzt, wenn die Zahlung am oder vor dem angegebenen Zahlungsziel ausgeführt wurde, andernfalls auf „false“. Damit lässt sich jede bezahlte Rechnung eindeutig einstufen. Dieses berechnete Attribut unterstützt direkt den KPI „Pünktliche Zahlungsquote“ und das zugehörige Dashboard. Es vereinfacht die Analyse: Benutzer können den Anteil verspäteter und pünktlicher Zahlungen filtern, zählen und visualisieren, ohne Datumsvergleiche jeweils neu berechnen zu müssen. So lässt sich das Ausmaß von Zahlungsverzögerungen schnell erkennen und die Entwicklung im Zeitverlauf verfolgen. Warum das wichtig ist Vereinfacht die Analyse der Zahlungspünktlichkeit und dient direkt als Grundlage für die Berechnung des KPI „Pünktliche Zahlungsquote“. Woher beziehen Dieses berechnete Attribut ergibt sich aus dem Vergleich des Timestamps der Aktivität „Zahlung ausgeführt“ mit dem Attribut „PaymentDueDate“. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten bei der Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, um den Prozess präzise zu entdecken.

6 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Rechnung erstellt	Dieses Ereignis bezeichnet die erstmalige Anlage eines Rechnungssatzes im System, etwa durch manuelle Eingabe, Scannen oder elektronische Übermittlung. Es wird üblicherweise erfasst, wenn eine neue Zeile in die zentrale Rechnungstabelle eingefügt wird.
Warum das wichtig ist Damit beginnt der Lebenszyklus der Rechnungsverarbeitung. Die Zeitspanne ab diesem Ereignis gibt Aufschluss über die Effizienz der Dateneingabe und Verzögerungen zu Prozessbeginn. Woher beziehen In Oracle Fusion Financials entspricht dies dem Erstellungs-Timestamp des Datensatzes in der Tabelle AP_INVOICES_ALL, genauer dem Feld CREATION_DATE. Erfassung Timestamp der Datensatzerstellung in AP_INVOICES_ALL. Ereignistyp explicit
	Rechnung freigegeben	Alle erforderlichen Beteiligten haben die Rechnung im Workflow freigegeben. Sie ist nun für die Buchhaltung und die Zahlungsplanung bereit.
Warum das wichtig ist Ein wichtiger Meilenstein, der den erfolgreichen Abschluss des Freigabeprozesses kennzeichnet. Verzögerungen vor diesem Schritt sind eine häufige Ursache für Engpässe. Woher beziehen Abgeleitet aus der Änderung von APPROVAL_STATUS in AP_INVOICES_ALL zu einem abschließenden Freigabestatus wie „Approved“ oder „Workflow Approved“. Der Audit-Verlauf dieses Felds enthält den Timestamp. Erfassung Abgeleitet aus der Änderung von AP_INVOICES_ALL.APPROVAL_STATUS zu „Approved“. Ereignistyp inferred
	Rechnung mit Bestellung abgeglichen	Diese Aktivität zeigt an, dass eine Rechnungsposition erfolgreich mit der entsprechenden Bestellposition abgeglichen wurde. Damit wird bestätigt, dass die berechneten Waren oder Dienstleistungen bestellt wurden. Der Vorgang wird üblicherweise als automatisierte oder manuelle Aktion im System erfasst.
Warum das wichtig ist Der Abgleich von Bestellung, Wareneingang und Rechnung ist entscheidend für den Drei-Wege-Abgleich. Fehler in diesem Schritt sind eine häufige Ursache für Ausnahmen und Verzögerungen. Woher beziehen Das Ereignis lässt sich aus Datensätzen in AP_INVOICE_DISTRIBUTIONS_ALL ableiten, die die Rechnung mit einer Bestellverteilung (PO_DISTRIBUTION_ID) verknüpfen. Auch der Abgleichstatus auf Positionsebene in AP_INVOICE_LINES_ALL kann herangezogen werden. Erfassung Abgeleitet aus den Bestellverteilungsdaten auf den Rechnungspositionen. Ereignistyp inferred
	Rechnung verbucht	Die Rechnung wird erfolgreich im Hauptbuch verbucht und erzeugt Buchungssätze. Dieses Ereignis bestätigt, dass die finanziellen Auswirkungen der Rechnung offiziell erfasst wurden.
Warum das wichtig ist Ein wichtiger finanzieller Kontrollpunkt und Voraussetzung für die Zahlung. Er bestätigt, dass die Rechnung vollständig validiert und freigegeben wurde und beglichen werden kann. Woher beziehen Abgeleitet aus dem Status in AP_INVOICE_DISTRIBUTIONS_ALL (ACCRUAL_POSTED_FLAG = 'Y') oder anhand entsprechender Buchungssätze in den Hauptbuchtabellen, etwa XLA_AE_HEADERS. Erfassung Abgeleitet aus Kennzeichen in AP_INVOICE_DISTRIBUTIONS_ALL oder verknüpften Hauptbucheinträgen. Ereignistyp inferred
	Rechnung zur Freigabe eingereicht	Die Rechnung wird auf Grundlage der konfigurierten Geschäftsregeln in einen Freigabe-Workflow überführt. Damit beginnt der formelle Freigabezyklus.
Warum das wichtig ist Damit beginnt ein wichtiger Teil des Prozesses. Die Erfassung des Startzeitpunkts ist entscheidend, um die Zykluszeit der Rechnungsfreigabe zu messen und zu optimieren. Woher beziehen Abgeleitet aus einer Statusänderung in AP_INVOICES_ALL, bei der APPROVAL_STATUS beispielsweise zu „Initiated“ oder „Pending Approval“ wechselt. Das Ereignis kann auch in den Workflow-Tabellen enthalten sein. Erfassung Abgeleitet aus der Änderung von AP_INVOICES_ALL.APPROVAL_STATUS zu „Initiated“. Ereignistyp inferred
	Zahlung ausgeführt	Dies ist die abschließende Bestätigung, dass die Zahlung erfolgt und verrechnet wurde. Bei Schecks ist dies das Verrechnungsdatum, bei elektronischen Zahlungen die Bestätigung der Bank.
Warum das wichtig ist Dies ist die letzte Aktivität im Lebenszyklus der Rechnung und kennzeichnet den erfolgreichen Abschluss des Prozesses. Sie bildet den Endpunkt für die Berechnung der durchschnittlichen Rechnungszykluszeit und der Quote pünktlicher Zahlungen. Woher beziehen Abgeleitet aus der Aktualisierung des Zahlungsstatus in AP_CHECKS_ALL zu „Cleared“ oder „Reconciled“ (anhand von CLEARED_DATE) oder aus Daten zum Bankabgleich im Cash-Management-Modul (CE_STATEMENT_LINES). Erfassung Abgeleitet aus Statusaktualisierungen in AP_CHECKS_ALL oder dem Abgleich im CE-Modul. Ereignistyp inferred
	Abweichung beim Abgleich festgestellt	Dieses Ereignis tritt auf, wenn das System oder ein Benutzer eine Abweichung zwischen Rechnung, Bestellung und Wareneingang feststellt, etwa beim Preis oder bei der Menge. Häufig wird die Rechnung daraufhin vom System gesperrt.
Warum das wichtig ist Das Ereignis macht Prozessausnahmen sichtbar, die manuelle Eingriffe erfordern. Es ist wichtig, diese Fälle für die KPI „Abweichungsquote beim Rechnungsabgleich“ und die Ursachenanalyse zu erfassen. Woher beziehen Häufig wird dieses Ereignis als bestimmter Sperrgrund für die Rechnung protokolliert. Prüfen Sie in der Tabelle AP_HOLDS_ALL die Sperrgründe für den Abgleich, zum Beispiel „QTY REC“ oder „PRICE“. HOLD_DATE enthält den Timestamp. Erfassung Datensatz in AP_HOLDS_ALL mit einem Sperrgrund im Zusammenhang mit dem Abgleich erstellt. Ereignistyp explicit
	Rechnung abgelehnt	Ein Freigebender hat die Rechnung im Freigabe-Workflow abgelehnt. In der Regel wird sie daraufhin zur Korrektur oder Stornierung zurückgesendet, wodurch eine Nacharbeitsschleife beginnt.
Warum das wichtig ist Die Ablehnung ist ein negatives Ergebnis und eine wichtige Ursache für Nacharbeit und längere Zykluszeiten. Die Erfassung von Ablehnungen hilft, Probleme mit der Rechnungsqualität oder der Einhaltung von Bestellvorgaben zu erkennen. Woher beziehen Abgeleitet aus der Änderung von APPROVAL_STATUS in AP_INVOICES_ALL zu „Rejected“. Der Workflow-Verlauf enthält Angaben dazu, wer die Rechnung wann abgelehnt hat. Erfassung Abgeleitet aus der Änderung von AP_INVOICES_ALL.APPROVAL_STATUS zu „Rejected“. Ereignistyp inferred
	Rechnung gesperrt	Allgemeine Aktivität für jede Sperre einer Rechnung, die ihre weitere Verarbeitung bis zur Zahlung verhindert. Gründe können beispielsweise Probleme beim Abgleich, unzureichende Mittel oder manuelle Eingriffe sein.
Warum das wichtig ist Sperren wirken sich unmittelbar auf die Zykluszeit aus und können zu verspäteten Zahlungen führen. Ihre Analyse hilft, systemische Prozessprobleme zu erkennen und zu beheben. Sie unterstützt außerdem die Analyse von Zahlungssperren. Woher beziehen Wird ausdrücklich in der Tabelle AP_HOLDS_ALL protokolliert. Jede Zeile steht für eine Sperre und enthält ein Erstellungsdatum (HOLD_DATE) sowie einen Grund. Erfassung Datensatz in der Tabelle AP_HOLDS_ALL erstellt. Ereignistyp explicit
	Rechnung korrigiert	Dieses Ereignis tritt ein, wenn ein Benutzer eine Rechnung ändert, häufig als Reaktion auf eine Ablehnung oder zur Korrektur eines Eingabefehlers. Es handelt sich um einen manuellen Nacharbeitsschritt im Prozess.
Warum das wichtig ist Diese Aktivität ist ein eindeutiger Hinweis auf Nacharbeit. Ihre Häufigkeit zeigt, wie ineffizient der Prozess ist, und fließt in die KPI „Nacharbeitsquote bei Rechnungen“ ein. Woher beziehen Das Ereignis lässt sich ableiten, indem wesentliche Änderungen am Rechnungsdatensatz in AP_INVOICES_ALL erfasst werden, nachdem die Rechnung bereits validiert oder zur Freigabe eingereicht wurde. Dafür sind der Timestamp LAST_UPDATE_DATE und Audit-Trail-Daten erforderlich. Erfassung Abgeleitet aus dem Vergleich von LAST_UPDATE_DATE nach einer Ablehnung oder Sperre. Ereignistyp inferred
	Rechnung storniert	Die Rechnung wurde für ungültig erklärt oder storniert. Sie wird weder weiterverarbeitet noch bezahlt. Damit ist der Prozess endgültig beendet.
Warum das wichtig ist Ein wichtiger Endpunkt für Rechnungen, die nicht zu einer Zahlung führen. Die Analyse von Stornierungen kann Probleme mit doppelten Rechnungen oder fehlerhaften Lieferanteneinreichungen aufdecken. Woher beziehen Abgeleitet aus einer Statusänderung in AP_INVOICES_ALL. Das Feld CANCELLED_DATE enthält den Timestamp der Stornierung. Erfassung Das Feld CANCELLED_DATE in der Tabelle AP_INVOICES_ALL wird befüllt. Ereignistyp explicit
	Rechnung validiert	Die Rechnung hat die Systemprüfungen auf Vollständigkeit und Korrektheit der Kopf- und Positionsdaten bestanden. Dieses Ereignis wird häufig aus einer Statusänderung des Rechnungsdatensatzes abgeleitet.
Warum das wichtig ist Ein wichtiger Meilenstein vor dem Abgleich und der Freigabe. Verzögerungen an dieser Stelle können auf Probleme mit der Datenqualität der Rechnung oder der Systemkonfiguration hinweisen. Woher beziehen Abgeleitet aus der Änderung des Rechnungsstatus in AP_INVOICES_ALL zu „Validated“. Dazu kann der Änderungsverlauf oder der Audit-Trail des Felds VALIDATION_STATUS herangezogen werden. Erfassung Abgeleitet aus einer Änderung des Felds AP_INVOICES_ALL.VALIDATION_STATUS. Ereignistyp inferred
	Rechnungssperre aufgehoben	Dieses Ereignis kennzeichnet die Aufhebung einer zuvor für die Rechnung eingerichteten Sperre. Ein Benutzer oder ein automatisierter Prozess hebt die Blockierung auf, sodass die Rechnung weiterverarbeitet werden kann.
Warum das wichtig ist Die Zeit zwischen dem Einrichten und dem Aufheben einer Sperre ist eine wichtige Kennzahl für die Effizienz der Ausnahmebearbeitung. Sie fließt in die KPI „Durchschnittliche Dauer der Ausnahmebehebung“ ein. Woher beziehen Wird in der Tabelle AP_HOLDS_ALL protokolliert. Bei Aufhebung einer Sperre werden die Felder RELEASE_LOOKUP_CODE und RELEASE_REASON sowie LAST_UPDATE_DATE befüllt. Erfassung Datensatz in AP_HOLDS_ALL aktualisiert, um die Aufhebung der Sperre zu kennzeichnen. Ereignistyp explicit
	Zahlung erstellt	Das System hat den Zahlungsauftrag für die Rechnung erstellt. Dabei kann es sich um einen Scheck, eine Datei für eine elektronische Überweisung (EFT) oder ein anderes Zahlungsinstrument handeln.
Warum das wichtig ist An diesem Punkt stellt die Organisation die Mittel für die Zahlung bereit. Das ist ein wichtiger Meilenstein, bevor das Geld das Bankkonto verlässt. Woher beziehen Wird in der Tabelle AP_CHECKS_ALL erfasst, die Informationen zu allen Zahlungen enthält. CHECK_DATE gibt an, wann das Zahlungsdokument erstellt wurde. Erfassung Datensatz in der Tabelle AP_CHECKS_ALL erstellt. Ereignistyp explicit
	Zahlung geplant	Die Rechnung wird ausgewählt und in einen Zahlungsprozessauftrag aufgenommen, der häufig als Zahlungslauf oder Zahlungslaufstapel bezeichnet wird. Sie ist nun zur Zahlung vorgemerkt.
Warum das wichtig ist Dieser Schritt liegt zwischen der Buchung und der tatsächlichen Zahlung. Seine Dauer wirkt sich auf die Cashflow-Prognose und die Möglichkeit aus, Skonti für frühzeitige Zahlungen zu nutzen. Woher beziehen Der Vorgang wird in AP_INVOICE_PAYMENTS_ALL erfasst, sobald ein Zahlungsdatensatz angelegt, die Zahlung aber noch nicht als erfolgt bestätigt wurde. Auch Zahlungslauftabellen wie IBY_PAYMENT_PROCESS_REQUESTS können entsprechende Daten enthalten. Erfassung Datensatz für eine geplante Zahlung in AP_INVOICE_PAYMENTS_ALL erstellt. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Bei Oracle Fusion Cloud anmelden: Melden Sie sich mit einem Benutzerkonto mit der Rolle BI Cloud Connector Administrator (BICC_ADMIN) bei Ihrer Oracle-Fusion-Cloud-Umgebung an.
BI Cloud Connector öffnen: Wählen Sie im Hauptmenü Tools > BI Cloud Connector. Die BICC-Konsole wird geöffnet.
Angebot auswählen: Wählen Sie in der BICC-Konsole das Angebot für Ihre Finanzdaten aus. Es heißt in der Regel „Financials“.
Externen Speicher konfigurieren: Öffnen Sie den Bereich „Configure External Storage“. Richten Sie die Verbindung zu dem Cloud-Speicher ein, in den die extrahierten CSV-Dateien übertragen werden sollen, zum Beispiel Oracle Cloud Infrastructure (OCI) Object Storage.
Angebote für die Extraktion aktivieren: Öffnen Sie „Manage Offerings and PVOs“ oder einen vergleichbaren Bereich. Wählen Sie das Angebot „Financials“ aus und aktivieren Sie es für die Extraktion.
Public View Objects (PVOs) auswählen: Suchen Sie nach den für den Rechnungsprozess erforderlichen PVOs und wählen Sie sie aus. Dazu gehören: FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO, FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO, FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO und FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO.
Extraktionsauftrag planen: Öffnen Sie „Manage Extract Schedules“. Erstellen Sie einen Auftrag, vergeben Sie einen aussagekräftigen Namen und wählen Sie alle PVOs aus, die Sie im vorherigen Schritt aktiviert haben. Legen Sie einen Zeitplan fest. Führen Sie den ersten Export für den gewünschten historischen Zeitraum aus. Richten Sie spätere Exporte als inkrementelle Extraktionen auf Basis von LastUpdateDate ein.
Daten überwachen und abrufen: Verfolgen Sie den Fortschritt des Auftrags in der BICC-Konsole. Nach erfolgreichem Abschluss öffnen Sie den konfigurierten Cloud-Speicher. Dort finden Sie die extrahierten Daten als komprimierte CSV-Dateien, jeweils eine pro PVO.
Daten in einen Staging-Bereich laden: Entpacken Sie die Dateien und laden Sie die CSV-Dateien in eine Staging-Datenbank oder Datenverarbeitungsplattform, etwa ein Data Warehouse oder einen Data Lake, in der Sie SQL-Abfragen ausführen können. Laden Sie jede CSV-Datei in eine eigene Tabelle.
Daten in ein Event Log umwandeln: Führen Sie die bereitgestellte SQL-Abfrage für die Tabellen in Ihrem Staging-Bereich aus. Die Abfrage führt Daten aus den verschiedenen Tabellen zusammen und erstellt daraus eine einheitliche Event-Log-Tabelle.
Für ProcessMind exportieren: Exportieren Sie das Ergebnis der SQL-Abfrage als einzelne CSV-Datei. Achten Sie darauf, dass die Spaltenüberschriften den erforderlichen Attributen entsprechen (InvoiceNumber, ActivityName, EventTime usw.), bevor Sie die Datei in ProcessMind hochladen.

Konfiguration

Wichtige Public View Objects (PVOs): Für die Extraktion werden mehrere zentrale PVOs aus dem Angebot „Financials“ benötigt. Mindestens müssen Sie folgende PVOs einbeziehen:
- FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO: Enthält grundlegende Rechnungsdaten sowie Ereignisse zur Erstellung, Validierung und Stornierung.
- FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO: Enthält alle Ereignisse zum Setzen und Aufheben von Rechnungssperren.
- FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO: Erfasst detaillierte Schritte im Freigabe-Workflow, etwa Einreichung, Freigabe und Ablehnung.
- FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO: Enthält Ereignisse zur Erstellung und Ausführung von Zahlungen.
- FscmTopModelAM.FinApInvPmtsAM.InstallmentPVO: Zeigt, wann eine Rechnung zur Zahlung eingeplant wird.
Inkrementelle Extraktionen: Richten Sie den BICC-Auftrag für die laufende Überwachung als inkrementelle Extraktion ein. Verwenden Sie die in den meisten PVOs verfügbare Spalte LastUpdateDate als Filter, damit nur neue oder seit dem letzten Lauf geänderte Datensätze extrahiert werden.
Filter für den Zeitraum: Für den ersten Export historischer Daten empfiehlt sich ein überschaubarer Zeitraum, zum Beispiel die letzten 6 bis 12 Monate. Mit einem globalen Filter im Zeitplan des BICC-Auftrags können Sie die Extraktion auf einen bestimmten Zeitraum begrenzen.
Filter für Geschäftseinheiten: Begrenzen Sie den Umfang der Extraktion, indem Sie in der BICC-Auftragskonfiguration nach BusinessUnitName oder einem ähnlichen Attribut filtern. Das ist in Umgebungen mit mehreren Gesellschaften wichtig, um das Datenvolumen zu steuern.
Voraussetzungen: Ihr Benutzerkonto benötigt die erforderlichen Rollen, insbesondere BI Cloud Connector Administrator (BICC_ADMIN) und Functional Setup User (FSM_IMPLEMENTATION_CONSULTANT), um Extraktionsaufträge einzurichten und auszuführen. Außerdem benötigen Sie einen konfigurierten und zugänglichen Cloud-Speicher, zum Beispiel OCI Object Storage oder UCM.

a Beispielabfrage sql

-- This script is designed to be run on the CSV files after they have been extracted by BICC and loaded into a staging database.
-- Each CTE (e.g., Invoices, Holds) represents a table created from a corresponding PVO's CSV file.

WITH Invoices AS (
    SELECT 
        InvoiceId,
        InvoiceNumber,
        InvoiceAmount,
        SupplierName AS VendorName,
        CreationDate,
        CreatedBy AS UserName, 
        LastUpdateDate, 
        LastUpdatedBy, 
        ValidatedDate,
        ApprovalStatus,
        WfApprovalStatus,
        PayablesAccountingStatus,
        CancelledDate,
        CancelledBy,
        BusinessUnitName AS CompanyCode
    FROM FscmTopModelAM_FinApInvQuickInvoicesAM_InvoiceHeaderPVO
    WHERE LastUpdateDate >= '[Specify Start Date]'
),
Holds AS (
    SELECT 
        InvoiceId,
        HoldDate,
        ReleasedDate,
        HoldReason,
        CreatedBy,
        LastUpdatedBy
    FROM FscmTopModelAM_FinApInvHoldAM_InvoiceHoldPVO
),
ApprovalHistory AS (
    SELECT
        InvoiceId,
        ActionDate,
        Action,
        Performer AS UserName
    FROM FscmTopModelAM_FinApInvSharedAM_InvoiceApprovalHistoryPVO
),
Installments AS (
    SELECT 
        InvoiceId,
        DueDate AS PaymentDueDate,
        PaymentStatusFlag,
        LastUpdateDate
    FROM FscmTopModelAM_FinApInvPmtsAM_InstallmentPVO
),
Payments AS (
    SELECT
        InvoiceId,
        PaymentId,
        CreationDate,
        CreatedBy AS UserName,
        PaymentDate
    FROM FscmTopModelAM_FinApPmtsInvPmtsAM_PaymentPVO
)

-- 1. Invoice Created
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    i.CreationDate AS "EventTime",
    i.CreationDate AS "EndTime",
    i.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId

UNION ALL

-- 2. Invoice Validated
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Validated' AS "ActivityName",
    i.ValidatedDate AS "EventTime",
    i.ValidatedDate AS "EndTime",
    i.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Validated' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.ValidatedDate IS NOT NULL

UNION ALL

-- 3. Invoice Matched to PO (Inferred from hold release)
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Matched to PO' AS "ActivityName",
    h.ReleasedDate AS "EventTime",
    h.ReleasedDate AS "EndTime",
    h.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE h.HoldReason IN ('QTY ORD', 'AMT ORD', 'PRICE') AND h.ReleasedDate IS NOT NULL

UNION ALL

-- 4. Matching Discrepancy Identified
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Matching Discrepancy Identified' AS "ActivityName",
    h.HoldDate AS "EventTime",
    h.HoldDate AS "EndTime",
    h.CreatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'On Hold' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE h.HoldReason IN ('QTY ORD', 'AMT ORD', 'PRICE')

UNION ALL

-- 5. Hold Placed on Invoice
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Hold Placed on Invoice' AS "ActivityName",
    h.HoldDate AS "EventTime",
    h.HoldDate AS "EndTime",
    h.CreatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'On Hold' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId

UNION ALL

-- 6. Hold Released from Invoice
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Hold Released from Invoice' AS "ActivityName",
    h.ReleasedDate AS "EventTime",
    h.ReleasedDate AS "EndTime",
    h.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE h.ReleasedDate IS NOT NULL

UNION ALL

-- 7. Invoice Sent for Approval
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Sent for Approval' AS "ActivityName",
    ah.ActionDate AS "EventTime",
    ah.ActionDate AS "EndTime",
    ah.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Initiated' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN ApprovalHistory ah ON i.InvoiceId = ah.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE ah.Action = 'SUBMITTED'

UNION ALL

-- 8. Invoice Approved
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Approved' AS "ActivityName",
    ah.ActionDate AS "EventTime",
    ah.ActionDate AS "EndTime",
    ah.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Workflow approved' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN ApprovalHistory ah ON i.InvoiceId = ah.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE ah.Action = 'APPROVED'

UNION ALL

-- 9. Invoice Rejected
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Rejected' AS "ActivityName",
    ah.ActionDate AS "EventTime",
    ah.ActionDate AS "EndTime",
    ah.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Rejected' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN ApprovalHistory ah ON i.InvoiceId = ah.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE ah.Action = 'REJECTED'

UNION ALL

-- 10. Invoice Corrected (Inferred from update after rejection)
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Corrected' AS "ActivityName",
    i.LastUpdateDate AS "EventTime",
    i.LastUpdateDate AS "EndTime",
    i.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.WfApprovalStatus = 'WORKFLOW_REJECTED' AND i.LastUpdatedBy <> 'FUSION_APPS_PRC_SOA_APPID'

UNION ALL

-- 11. Invoice Accounted
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Accounted' AS "ActivityName",
    i.LastUpdateDate AS "EventTime",
    i.LastUpdateDate AS "EndTime",
    i.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Accounted' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.PayablesAccountingStatus = 'ACCOUNTED'

UNION ALL

-- 12. Payment Scheduled
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    inst.LastUpdateDate AS "EventTime",
    inst.LastUpdateDate AS "EndTime",
    i.LastUpdatedBy AS "UserName", -- User who ran the PPR is not in this PVO
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Selected for Payment' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE inst.PaymentStatusFlag = 'Y'

UNION ALL

-- 13. Payment Created
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Payment Created' AS "ActivityName",
    p.CreationDate AS "EventTime",
    p.CreationDate AS "EndTime",
    p.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Paid' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Payments p ON i.InvoiceId = p.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId

UNION ALL

-- 14. Payment Executed
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    p.PaymentDate AS "EventTime",
    p.PaymentDate AS "EndTime",
    p.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Paid' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Payments p ON i.InvoiceId = p.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE p.PaymentDate IS NOT NULL

UNION ALL

-- 15. Invoice Canceled
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Canceled' AS "ActivityName",
    i.CancelledDate AS "EventTime",
    i.CancelledDate AS "EndTime",
    i.CancelledBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Cancelled' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.CancelledDate IS NOT NULL;

Schritte

Oracle BI Publisher öffnen: Melden Sie sich mit einem Benutzerkonto mit der Rolle BI Administrator oder einer vergleichbaren Rolle bei Oracle Fusion Applications an. Öffnen Sie im Navigator-Menü den Bereich Tools und wählen Sie anschließend Reports and Analytics.
Katalog öffnen: Klicken Sie im Arbeitsbereich Reports and Analytics auf die Schaltfläche Browse Catalog, um die Oracle-BI-Publisher-Oberfläche zu öffnen.
Datenmodell erstellen: Öffnen Sie im BI-Publisher-Katalog einen geeigneten Ordner, zum Beispiel Shared Folders > Custom. Klicken Sie auf das Dropdown-Menü New und wählen Sie Data Model.
SQL-Abfragedatensatz definieren: Klicken Sie im Datenmodell-Editor auf das Symbol „+“, um einen neuen Datensatz hinzuzufügen, und wählen Sie SQL Query aus der Liste.
Datensatz konfigurieren: Geben Sie im Dialogfeld New Data Set einen Namen ein, zum Beispiel P2P_Invoice_Events. Wählen Sie die passende Datenquelle aus. Für Finanzdaten ist dies in der Regel ApplicationDB_FSCM. Stellen Sie sicher, dass als SQL-Typ Standard SQL festgelegt ist.
SQL-Abfrage eingeben: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt query dieses Dokuments und fügen Sie sie in das Textfeld SQL Query ein.
Parameter definieren: Die Abfrage verwendet Filterparameter. Erstellen Sie in den Eigenschaften des Datenmodells drei Parameter: p_start_date, p_end_date und p_bu_name. Legen Sie für alle den Datentyp String fest. Bei der Berichtsausführung geben Sie Werte ein, zum Beispiel „2023-01-01“ für Datumsangaben und den Namen der gewünschten Geschäftseinheit.
Datenmodell speichern: Speichern Sie das Datenmodell in Ihrem benutzerdefinierten Ordner. Beispieldaten können Sie auf der Registerkarte „Data“ anzeigen, indem Sie Werte für die erstellten Parameter eingeben.
Bericht erstellen: Kehren Sie zum Katalog zurück, klicken Sie auf das Dropdown-Menü New und wählen Sie Report. Wählen Sie im Berichtsassistenten die Option „Use Data Model“ und anschließend das soeben gespeicherte Datenmodell aus.
Berichtslayout und Ausgabe konfigurieren: Im Berichts-Editor genügt ein einfaches Tabellenlayout. Entscheidend ist das Standardausgabeformat. Klicken Sie auf „View a List“ und stellen Sie sicher, dass CSV als einziges Format aktiviert und als Standard festgelegt ist. So erhalten Sie eine unveränderte Datendatei ohne Formatierung.
Bericht planen: Speichern Sie den Bericht. Sie können ihn bei Bedarf ausführen oder für eine bessere Leistung außerhalb der Spitzenzeiten einplanen. Richten Sie den Zeitplan so ein, dass die CSV-Ausgabe an ein bestimmtes Ziel übertragen wird, etwa an den Universal Content Management (UCM)-Server. Von dort können Sie die Datei zum Upload abrufen.
Daten exportieren und vorbereiten: Laden Sie nach Abschluss des Berichtsauftrags die erzeugte CSV-Datei herunter. Prüfen Sie vor dem Upload in das Process-Mining-Tool, ob die Spaltenüberschriften den erforderlichen Attributen entsprechen (InvoiceNumber, ActivityName, EventTime usw.).

Konfiguration

Datenquelle: Führen Sie die Abfrage für die Anwendungsdatenbank von Fusion Financials aus. In BI Publisher ist diese in der Regel über die JNDI-Datenquelle ApplicationDB_FSCM angebunden.
Parameter: Konfigurieren Sie das Datenmodell mit den folgenden Parametern, damit Sie die Daten flexibel extrahieren können:
- p_start_date: Startdatum des Extraktionszeitraums im Format „YYYY-MM-DD“.
- p_end_date: Enddatum des Extraktionszeitraums im Format „YYYY-MM-DD“.
- p_bu_name: Name der Geschäftseinheit (Company Code), nach der die Daten gefiltert werden. Verwenden Sie ein Platzhalterzeichen wie „%“, um alle Geschäftseinheiten zu extrahieren.
Zeitraum: Für die erste Extraktion empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. So erhalten Sie einen aussagekräftigen Datensatz und können zugleich die Leistung bei der Extraktion im Blick behalten.
Leistungshinweise: Die Extraktion langer Zeiträume oder aller Geschäftseinheiten auf einmal kann viele Ressourcen beanspruchen und zu Zeitüberschreitungen führen. Führen Sie umfangreiche Extraktionen daher in kleineren, aufeinanderfolgenden Abschnitten aus, zum Beispiel Monat für Monat, oder planen Sie sie außerhalb der Spitzenzeiten.
Voraussetzungen: Das Benutzerkonto für die Erstellung und Ausführung des Berichts benötigt eine Rolle mit Zugriff auf BI Publisher, zum Beispiel BI Administrator, sowie die erforderlichen Datenzugriffsrechte für die zugrunde liegenden Kreditorenbuchhaltungstabellen (AP_INVOICES_ALL, AP_PAYMENTS_ALL usw.) der betreffenden Geschäftseinheiten.

a Beispielabfrage sql

WITH INVOICE_BASE AS (
    SELECT 
        AIA.INVOICE_ID,
        AIA.INVOICE_NUM,
        AIA.INVOICE_AMOUNT,
        AIA.CREATION_DATE,
        AIA.CREATED_BY,
        AIA.LAST_UPDATE_DATE,
        AIA.LAST_UPDATED_BY,
        AIA.CANCELLED_DATE,
        AIA.CANCELLED_BY,
        AIA.WFAPPROVAL_STATUS,
        AIA.TERMS_DATE AS PAYMENT_DUE_DATE,
        PSV.VENDOR_NAME,
        FABUV.BU_NAME AS COMPANY_CODE
    FROM 
        AP_INVOICES_ALL AIA
    JOIN 
        POZ_SUPPLIERS_V PSV ON AIA.VENDOR_ID = PSV.VENDOR_ID
    JOIN
        FUN_ALL_BUSINESS_UNITS_V FABUV ON AIA.ORG_ID = FABUV.BU_ID
    WHERE 
        AIA.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
        AND FABUV.BU_NAME LIKE :p_bu_name
)
-- 1. Invoice Created
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    CAST(IB.CREATION_DATE AS TIMESTAMP) AS "EventTime",
    CAST(IB.CREATION_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = IB.CREATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    INVOICE_BASE IB

UNION ALL

-- 2. Invoice Validated
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Validated' AS "ActivityName",
    CAST(AIA.LAST_UPDATE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AIA.LAST_UPDATE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AIA.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    AIA.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_INVOICES_ALL AIA
JOIN 
    INVOICE_BASE IB ON AIA.INVOICE_ID = IB.INVOICE_ID
WHERE 
    AIA.WFAPPROVAL_STATUS IN ('VALIDATED', 'NEEDS REVALIDATION', 'STOPPED')

UNION ALL

-- 3. Invoice Matched to PO
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Matched to PO' AS "ActivityName",
    CAST(MIN(AID.CREATION_DATE) AS TIMESTAMP) AS "EventTime",
    CAST(MIN(AID.CREATION_DATE) AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = MIN(AID.CREATED_BY) AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_INVOICE_DISTRIBUTIONS_ALL AID
JOIN 
    INVOICE_BASE IB ON AID.INVOICE_ID = IB.INVOICE_ID
WHERE
    AID.PO_DISTRIBUTION_ID IS NOT NULL
GROUP BY
    IB.INVOICE_NUM, IB.INVOICE_AMOUNT, IB.VENDOR_NAME, IB.PAYMENT_DUE_DATE, IB.WFAPPROVAL_STATUS, IB.COMPANY_CODE

UNION ALL

-- 4. Matching Discrepancy Identified & 5. Hold Placed on Invoice
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    CASE 
        WHEN AH.HOLD_LOOKUP_CODE IN ('QTY ORD', 'QTY REC', 'PRICE', 'AMT ORD', 'AMT REC') THEN 'Matching Discrepancy Identified'
        ELSE 'Hold Placed on Invoice'
    END AS "ActivityName",
    CAST(AH.HOLD_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AH.HOLD_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AH.CREATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_HOLDS_ALL AH
JOIN 
    INVOICE_BASE IB ON AH.INVOICE_ID = IB.INVOICE_ID

UNION ALL

-- 6. Hold Released from Invoice
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Hold Released from Invoice' AS "ActivityName",
    CAST(AH.RELEASE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AH.RELEASE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AH.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_HOLDS_ALL AH
JOIN 
    INVOICE_BASE IB ON AH.INVOICE_ID = IB.INVOICE_ID
WHERE 
    AH.RELEASE_LOOKUP_CODE IS NOT NULL AND AH.RELEASE_DATE IS NOT NULL

UNION ALL

-- 7. Invoice Sent for Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    CASE 
        WHEN AAH.ACTION = 'INITIATED' THEN 'Invoice Sent for Approval'
        WHEN AAH.ACTION = 'APPROVED' THEN 'Invoice Approved'
        WHEN AAH.ACTION = 'REJECTED' THEN 'Invoice Rejected'
    END AS "ActivityName",
    CAST(AAH.RESPONSE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AAH.RESPONSE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AAH.RESPONSE_ID AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_INV_APRVL_HIST_ALL AAH
JOIN 
    INVOICE_BASE IB ON AAH.INVOICE_ID = IB.INVOICE_ID
WHERE
    AAH.ACTION IN ('INITIATED', 'APPROVED', 'REJECTED') AND AAH.RESPONSE_DATE IS NOT NULL

UNION ALL

-- 10. Invoice Corrected
SELECT DISTINCT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Corrected' AS "ActivityName",
    CAST(IB.LAST_UPDATE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(IB.LAST_UPDATE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = IB.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    INVOICE_BASE IB
WHERE
    IB.LAST_UPDATE_DATE > IB.CREATION_DATE
    AND IB.LAST_UPDATED_BY <> IB.CREATED_BY 
    AND EXISTS (
        SELECT 1 FROM AP_INV_APRVL_HIST_ALL AAH 
        WHERE AAH.INVOICE_ID = IB.INVOICE_ID AND AAH.ACTION = 'REJECTED' AND IB.LAST_UPDATE_DATE > AAH.RESPONSE_DATE
    )

UNION ALL

-- 11. Invoice Accounted
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Accounted' AS "ActivityName",
    CAST(MIN(XAH.ACCOUNTING_DATE) AS TIMESTAMP) AS "EventTime",
    CAST(MIN(XAH.ACCOUNTING_DATE) AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = MIN(XAH.CREATED_BY) AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM XLA_AE_HEADERS XAH
JOIN XLA_TRANSACTION_ENTITIES XTE ON XAH.ENTITY_ID = XTE.ENTITY_ID
JOIN INVOICE_BASE IB ON XTE.SOURCE_ID_INT_1 = IB.INVOICE_ID
WHERE XTE.APPLICATION_ID = 200
AND XTE.ENTITY_CODE = 'AP_INVOICES'
AND XAH.ACCOUNTING_ENTRY_STATUS_CODE = 'F' -- Final
GROUP BY
    IB.INVOICE_NUM, IB.INVOICE_AMOUNT, IB.VENDOR_NAME, IB.PAYMENT_DUE_DATE, IB.WFAPPROVAL_STATUS, IB.COMPANY_CODE

UNION ALL

-- 12. Payment Scheduled
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    CAST(MIN(APISC.CREATION_DATE) AS TIMESTAMP) AS "EventTime",
    CAST(MIN(APISC.CREATION_DATE) AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = MIN(APISC.CREATED_BY) AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM AP_INV_SELECTION_CRITERIA_ALL APISC
JOIN AP_INVOICES_ALL AIA ON APISC.CHECKRUN_NAME = AIA.PAYMENT_STATUS_FLAG
JOIN INVOICE_BASE IB ON AIA.INVOICE_ID = IB.INVOICE_ID
GROUP BY
    IB.INVOICE_NUM, IB.INVOICE_AMOUNT, IB.VENDOR_NAME, IB.PAYMENT_DUE_DATE, IB.WFAPPROVAL_STATUS, IB.COMPANY_CODE

UNION ALL

-- 13. Payment Created
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Payment Created' AS "ActivityName",
    CAST(AIPA.CREATION_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AIPA.CREATION_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AIPA.CREATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM AP_INVOICE_PAYMENTS_ALL AIPA
JOIN INVOICE_BASE IB ON AIPA.INVOICE_ID = IB.INVOICE_ID

UNION ALL

-- 14. Payment Executed
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    CAST(AC.CLEARED_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AC.CLEARED_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AC.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM AP_INVOICE_PAYMENTS_ALL AIPA
JOIN AP_CHECKS_ALL AC ON AIPA.CHECK_ID = AC.CHECK_ID
JOIN INVOICE_BASE IB ON AIPA.INVOICE_ID = IB.INVOICE_ID
WHERE AC.CLEARED_DATE IS NOT NULL

UNION ALL

-- 15. Invoice Canceled
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Canceled' AS "ActivityName",
    CAST(IB.CANCELLED_DATE AS TIMESTAMP) AS "EventTime",
    CAST(IB.CANCELLED_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = IB.CANCELLED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    INVOICE_BASE IB
WHERE
    IB.CANCELLED_DATE IS NOT NULL

Schritte

Voraussetzungen: Installieren Sie Python 3.6 oder höher sowie die Bibliotheken requests und pandas. Installieren Sie diese mit pip: pip install requests pandas.
Oracle-Fusion-API einrichten: Öffnen Sie in Ihrer Oracle-Fusion-Instanz die Security Console. Erstellen Sie eine vertrauliche Anwendung, um API-Zugriff zu erhalten. Notieren Sie sich die zugewiesene Client ID und das Client Secret. Stellen Sie sicher, dass der Anwendungsbenutzer über die erforderlichen Rollen zum Lesen von Rechnungs- und Zahlungsdaten verfügt, zum Beispiel Financials - Payables Invoice Inquiry Duty.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_fusion_invoices.py. Öffnen Sie die Datei und tragen Sie oben im Skript die Werte für die Platzhaltervariablen ein: CLIENT_ID, CLIENT_SECRET, TOKEN_URL, FUSION_HOST, START_DATE und END_DATE. Als FUSION_HOST geben Sie die Basis-URL Ihrer Oracle-Cloud-Anwendungen an.
Extraktionszeitraum festlegen: Passen Sie die Variablen START_DATE und END_DATE an, um den Zeitraum für die Datenextraktion festzulegen. Testen Sie das Skript zunächst mit einem kürzeren Zeitraum, etwa einem Monat, und prüfen Sie die Ausgabe.
Skript ausführen: Wechseln Sie in der Befehlszeile oder im Terminal in das Verzeichnis des Skripts und führen Sie python extract_fusion_invoices.py aus. Das Skript authentifiziert sich, ruft die Daten ab und zeigt den Fortschritt in der Konsole an.
Authentifizierung: Zunächst sendet das Skript Ihre Client-Zugangsdaten an den Oracle-Identitätsanbieter (TOKEN_URL), um ein OAuth-Zugriffstoken abzurufen. Dieses Token wird anschließend im Header aller API-Anfragen an die Fusion-Financials-API mitgesendet.
Datenabruf und Paginierung: Das Skript fragt den REST-API-Endpunkt invoices ab und ruft Datensätze ab, die innerhalb des angegebenen Zeitraums erstellt wurden. Es verarbeitet die Paginierung automatisch: Anhand des Flags hasMore in der API-Antwort erkennt es, ob weitere Datensätze vorliegen, und sendet weitere Anfragen mit einem angepassten Parameter offset, bis alle Rechnungsdaten abgerufen sind.
Detaillierte Daten abrufen: Für jede abgerufene Rechnung sendet das Skript zusätzliche API-Anfragen, um zugehörige Details abzurufen. Über den Endpunkt /child/holds ruft es Informationen zu Sperren und deren Aufhebung ab. Über den Endpunkt /payments, gefiltert nach Rechnungsnummer, ermittelt es die Zahlungsdaten.
Event Log erstellen: Die zentrale Skriptlogik verarbeitet die Rohdaten im JSON-Format. Sie prüft bestimmte Datumsangaben, Statuswerte und untergeordnete Datensätze, um für jede der 15 erforderlichen Geschäftsaktivitäten eine eigene Zeile zu erstellen. Ist beispielsweise ein CancelledDate vorhanden, wird das Ereignis „Rechnung storniert“ erzeugt.
Ausgabe prüfen: Nach Abschluss erstellt das Skript im selben Verzeichnis die Datei invoice_event_log.csv. Öffnen Sie diese CSV-Datei in einer Tabellenkalkulationsanwendung und prüfen Sie, ob alle erforderlichen Spalten (InvoiceNumber, ActivityName, EventTime) und empfohlenen Attribute enthalten sind.
Upload vorbereiten: Achten Sie darauf, dass die Spaltenüberschriften in der CSV-Datei den erforderlichen Attributnamen entsprechen. Weitere Formatierung ist in der Regel nicht erforderlich. Anschließend können Sie die Datei in Ihr Process-Mining-Tool hochladen.

Konfiguration

Authentifizierungsdaten: Erforderlich sind eine Client ID und ein Client Secret für eine vertrauliche Anwendung, die in der Security Console von Oracle Fusion registriert ist. Außerdem benötigen Sie die Token URL Ihrer Identitätsdomäne.
API-Host-URL: Legen Sie für die Variable FUSION_HOST die Basis-URL Ihrer Oracle-Fusion-Instanz fest, zum Beispiel https://[your-instance].fa.us2.oraclecloud.com.
Zeitraum: Die Variablen START_DATE und END_DATE bestimmen den Umfang der Extraktion. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenvolumen und Leistung auszubalancieren.
Verwendete API-Endpunkte: Das Skript greift hauptsächlich auf die Endpunkte fscmRestApi/resources/11.13.18.05/invoices und fscmRestApi/resources/11.13.18.05/payments zu. Außerdem verwendet es die Unterressource /invoices/{InvoiceId}/child/holds.
Paginierungslimit: Die Variable LIMIT im Skript legt fest, wie viele Datensätze pro API-Anfrage abgerufen werden. Der Standardwert ist 100. Ein höherer Wert kann die Anzahl der API-Aufrufe verringern, erhöht aber den Speicherbedarf pro Anfrage. Bei Zeitüberschreitungen kann ein niedrigerer Wert erforderlich sein.
Erforderliche Berechtigungen: Das Benutzerkonto zu den API-Zugangsdaten benötigt Lesezugriff auf Kreditorenrechnungen, Rechnungssperren, Zahlungen und Lieferanteninformationen. Die Rolle Payables Invoice Inquiry Duty bietet in der Regel die erforderlichen Berechtigungen.

a Beispielabfrage python

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

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion credentials and instance details
CLIENT_ID = class="hl-string">'[Your Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'
TOKEN_URL = class="hl-string">'[Your Oracle Identity Cloud Service Token URL, e.g., https://idcs-....identity.oraclecloud.com/oauth2/v1/token]'
FUSION_HOST = class="hl-string">'[Your Fusion Host URL, e.g., https://your-fusion-instance.fa.ocs.oraclecloud.com]'

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the invoice extraction (YYYY-MM-DD)
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># API request settings
LIMIT = 100

class=class="hl-string">"hl-comment"># --- Helper Functions ---
def get_access_token():
    class="hl-string">"""Authenticates and retrieves an OAuth2 access token."""
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    data = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'scope': class="hl-string">'urn:opc:resource:consumer::all'
    }
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data, auth=(CLIENT_ID, CLIENT_SECRET))
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def fetch_data(api_url, headers, params):
    class="hl-string">"""Fetches data from a given API endpoint with pagination handling."""
    all_items = []
    offset = 0
    has_more = True

    while has_more:
        params[class="hl-string">'offset'] = offset
        try:
            response = requests.get(api_url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            items = data.get(class="hl-string">'items', [])
            all_items.extend(items)
            has_more = data.get(class="hl-string">'hasMore', False)
            offset += len(items)
            print(fclass="hl-string">"Fetched {len(all_items)} records so far...")
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {api_url}: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
    return all_items

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    class="hl-string">"""Main function to extract, transform, and save invoice data."""
    access_token = get_access_token()
    if not access_token:
        print(class="hl-string">"Could not obtain access token. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }

    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch Invoices
    print(class="hl-string">"Starting invoice extraction...")
    invoice_url = fclass="hl-string">'{FUSION_HOST}/fscmRestApi/resources/11.13.18.05/invoices'
    invoice_params = {
        class="hl-string">'q': fclass="hl-string">'CreationDate between \'{START_DATE}T00:00:00.000Z\class="hl-string">' and \'{END_DATE}T23:59:59.999Z\class="hl-string">'',
        class="hl-string">'onlyData': class="hl-string">'true',
        class="hl-string">'limit': LIMIT,
        class="hl-string">'fields': class="hl-string">'InvoiceId,InvoiceNumber,InvoiceAmount,CreationDate,CreatedBy,LastUpdateDate,LastUpdatedBy,SupplierName,ValidationDate,CancelledDate,ApprovalStatus,AccountingDate,PaymentStatus,DueDate,InvoiceStatus,BusinessUnitName'
    }
    invoices = fetch_data(invoice_url, headers, invoice_params)
    print(fclass="hl-string">"Total invoices fetched: {len(invoices)}")

    class=class="hl-string">"hl-comment"># 2. Process each invoice to create events
    for inv in invoices:
        case_id = inv.get(class="hl-string">'InvoiceNumber')
        if not case_id:
            continue

        base_event = {
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'EndTime': None,
            class="hl-string">'InvoiceAmount': inv.get(class="hl-string">'InvoiceAmount'),
            class="hl-string">'VendorName': inv.get(class="hl-string">'SupplierName'),
            class="hl-string">'PaymentDueDate': inv.get(class="hl-string">'DueDate'),
            class="hl-string">'InvoiceStatus': inv.get(class="hl-string">'InvoiceStatus'),
            class="hl-string">'CompanyCode': inv.get(class="hl-string">'BusinessUnitName')
        }

        class=class="hl-string">"hl-comment"># Activity: Invoice Created
        if inv.get(class="hl-string">'CreationDate'):
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': inv[class="hl-string">'CreationDate'], class="hl-string">'UserName': inv.get(class="hl-string">'CreatedBy')})

        class=class="hl-string">"hl-comment"># Activity: Invoice Validated
        if inv.get(class="hl-string">'ValidationDate'):
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Validated', class="hl-string">'EventTime': inv[class="hl-string">'ValidationDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        
        class=class="hl-string">"hl-comment"># Activities based on Approval Status
        if inv.get(class="hl-string">'ApprovalStatus') in [class="hl-string">'Initiated', class="hl-string">'Required']:
             event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Sent for Approval', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        elif inv.get(class="hl-string">'ApprovalStatus') in [class="hl-string">'Approved', class="hl-string">'Not required', class="hl-string">'Workflow approved']:
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Approved', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'Rejected':
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Rejected', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        
        class=class="hl-string">"hl-comment"># This is an inference, might represent corrections after rejection or validation failure
        if inv.get(class="hl-string">'InvoiceStatus') == class="hl-string">'Needs revalidation':
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Corrected', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># Activity: Invoice Accounted
        if inv.get(class="hl-string">'AccountingDate'):
             event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Accounted', class="hl-string">'EventTime': inv[class="hl-string">'AccountingDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># Activity: Invoice Canceled
        if inv.get(class="hl-string">'CancelledDate'):
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Canceled', class="hl-string">'EventTime': inv[class="hl-string">'CancelledDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        
        class=class="hl-string">"hl-comment"># Activity: Matched to PO - Inference based on PaymentStatus which can indicate matching holds resolved
        if inv.get(class="hl-string">'PaymentStatus') == class="hl-string">'Available':
             event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Matched to PO', class="hl-string">'EventTime': inv.get(class="hl-string">'ValidationDate') or inv.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># 3. Fetch Holds for the Invoice
        holds_url = fclass="hl-string">'{FUSION_HOST}/fscmRestApi/resources/11.13.18.05/invoices/{inv["InvoiceId"]}/child/holds'
        holds = fetch_data(holds_url, headers, {class="hl-string">'onlyData': class="hl-string">'true'})
        for hold in holds:
            class=class="hl-string">"hl-comment"># Activity: Hold Placed on Invoice
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Hold Placed on Invoice', class="hl-string">'EventTime': hold[class="hl-string">'HoldDate'], class="hl-string">'UserName': hold.get(class="hl-string">'LastUpdatedBy')})
            if hold.get(class="hl-string">'HoldReason') in [class="hl-string">'Price', class="hl-string">'Qty Ord', class="hl-string">'Qty Rec', class="hl-string">'Quality']:
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Identified', class="hl-string">'EventTime': hold[class="hl-string">'HoldDate'], class="hl-string">'UserName': hold.get(class="hl-string">'LastUpdatedBy')})
            
            class=class="hl-string">"hl-comment"># Activity: Hold Released from Invoice
            if hold.get(class="hl-string">'ReleaseDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Hold Released from Invoice', class="hl-string">'EventTime': hold[class="hl-string">'ReleaseDate'], class="hl-string">'UserName': hold.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># 4. Fetch Payments for the Invoice
        if inv.get(class="hl-string">'PaymentStatus') in [class="hl-string">'Paid', class="hl-string">'Partially paid']:
            payment_url = fclass="hl-string">'{FUSION_HOST}/fscmRestApi/resources/11.13.18.05/payments'
            payment_params = {
                class="hl-string">'q': fclass="hl-string">'InvoiceNumber=\'{case_id}\class="hl-string">'',
                class="hl-string">'onlyData': class="hl-string">'true',
                class="hl-string">'fields': class="hl-string">'PaymentId,CreationDate,CreatedBy,ClearedDate,PaymentDate'
            }
            payments = fetch_data(payment_url, headers, payment_params)
            for pmt in payments:
                 class=class="hl-string">"hl-comment"># Activity: Payment Scheduled (Approximation using Payment Creation Date)
                 event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': pmt[class="hl-string">'CreationDate'], class="hl-string">'UserName': pmt.get(class="hl-string">'CreatedBy')})
                 class=class="hl-string">"hl-comment"># Activity: Payment Created
                 event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Payment Created', class="hl-string">'EventTime': pmt[class="hl-string">'PaymentDate'], class="hl-string">'UserName': pmt.get(class="hl-string">'CreatedBy')})
                 class=class="hl-string">"hl-comment"># Activity: Payment Executed
                 if pmt.get(class="hl-string">'ClearedDate'):
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': pmt[class="hl-string">'ClearedDate'], class="hl-string">'UserName': pmt.get(class="hl-string">'CreatedBy')})

    class=class="hl-string">"hl-comment"># 5. Create and Save DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. Please check your date range and API responses.")
        return

    df = pd.DataFrame(event_log)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    if class="hl-string">'EndTime' in df.columns:
         df[class="hl-string">'EndTime'] = pd.to_datetime(df[class="hl-string">'EndTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

    output_filename = class="hl-string">'invoice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template vor und beginnen Sie, Ihre Rechnungsverarbeitung zu optimieren. Gewinnen Sie wertvolle Erkenntnisse und verbessern Sie die Effizienz in Ihrem Unternehmen.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie jetzt Ihre P2P-Rechnungsverarbeitung und verkürzen Sie Durchlaufzeiten um 30 %

Beseitigen Sie Engpässe in Oracle Fusion Financials und verkürzen Sie die Durchlaufzeit um 30 %.

Kostenlose Testphase starten

Keine Kreditkarte erforderlich. Erste Ergebnisse innerhalb weniger Tage.

Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Attribute für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Aktivitäten bei der Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Anleitungen zur Datenextraktion

Oracle BI Cloud Connector (BICC): Massenexport von Daten

Schritte

Konfiguration

a Beispielabfrage sql

Oracle-BI-Publisher-Bericht mit benutzerdefiniertem SQL-Datenmodell

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion mit einem Python-Skript über die Fusion-Financials-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie jetzt Ihre P2P-Rechnungsverarbeitung und verkürzen Sie Durchlaufzeiten um 30 %

Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Attribute für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Aktivitäten bei der Rechnungsverarbeitung im Purchase-to-Pay-Prozess

Anleitungen zur Datenextraktion

Oracle BI Cloud Connector (BICC): Massenexport von Daten

Schritte

Konfiguration

a Beispielabfrage sql

Oracle-BI-Publisher-Bericht mit benutzerdefiniertem SQL-Datenmodell

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion mit einem Python-Skript über die Fusion-Financials-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie jetzt Ihre P2P-Rechnungsverarbeitung und verkürzen Sie Durchlaufzeiten um 30 %

Der Schutz Ihrer Daten ist uns wichtig