> Kontinuierliche Prozessoptimierung > Beschaffung bis zur Zahlung – Rechnungsverarbeitung > Oracle Fusion Financials > Datenvorlage

Ihr Daten-Template für die Rechnungsverarbeitung im Einkauf zu Zahlung

Oracle Fusion Financials

← Zurück zum Optimierungsleitfaden

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsattribute (21) Beschaffung bis zur Zahlung – Rechnungsverarbeitungsaktivitäten (15) Extraktionsleitfäden (3)

Ihr Daten-Template für die Rechnungsverarbeitung im Einkauf zu Zahlung

Dieses Template wurde entwickelt, um Sie bei der Erfassung der wesentlichen Daten für die Analyse Ihrer Beschaffung bis zur Zahlung, insbesondere der Rechnungsverarbeitung, innerhalb von Oracle Fusion Financials zu leiten. Es umreißt die entscheidenden Attribute, Schlüsselaktivitäten und bietet Anleitungen zur Extraktion dieser Informationen aus Ihrem System. Die Verwendung dieses Templates hilft Ihnen, einen genauen und umfassenden Event Log für Process Mining vorzubereiten.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung für Oracle Fusion Financials

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsattribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihren Event Log für eine umfassende Beschaffung bis zur Zahlung – Rechnungsverarbeitungsanalyse aufnehmen sollten.

3 Erforderlich 7 Empfohlen 11 Optional

	Name	Beschreibung
	Rechnungsnummer InvoiceNumber	Die eindeutige Kennung für eine Lieferantenrechnung.
Beschreibung Die Rechnungsnummer dient als primärer Case-Identifier und verknüpft alle Aktivitäten und Events, die mit einer einzelnen Lieferantenrechnung von ihrer Erstellung bis zur finalen Zahlung zusammenhängen. Jede Rechnung wird als einzigartige Case-Instanz in der Prozessanalyse behandelt. Im Process Mining ist dieses Attribut grundlegend, um den End-to-End-Verlauf jeder Rechnung zu rekonstruieren. Es ermöglicht die Analyse von Prozessflüssen, Zykluszeiten und Variationen auf Rechnungsbasis. Es ist der Schlüssel, um verschiedene Aktivitäten wie Validierung, Genehmigung und Zahlung zu einer kohärenten Prozessbeschreibung zu verbinden. Bedeutung Dies ist der wesentliche Case-Identifier, der alle verbundenen Prozessschritte miteinander verknüpft und es ermöglicht, den gesamten Lebenszyklus einer Rechnung zu verfolgen. Datenquelle Dies findet sich typischerweise in der Tabelle AP_INVOICES_ALL, in der Spalte INVOICE_NUM. Beispiele INV-2023-001987654321ACME-FIN-5501
	Aktivität ActivityName	Der Name der Geschäftsaktivität oder des Events, das im Rechnungsprozess aufgetreten ist.
Beschreibung Dieses Attribut beschreibt einen spezifischen Schritt oder Statuswechsel im Rechnungslebenszyklus, wie 'Rechnung erstellt', 'Rechnung genehmigt' oder 'Zahlung ausgeführt'. Es bildet die Abfolge von Events, die den Prozessfluss bilden. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten ist der Kern des Process Mining. Sie hilft dabei, den tatsächlichen Prozesspfad zu entdecken, Engpässe zu identifizieren, bei denen Aktivitäten verzögert werden, und Abweichungen oder Nachbearbeitungsschleifen zu erkennen, wie beispielsweise eine Rechnung, die nach der Genehmigung abgelehnt wird. Bedeutung Es definiert die Prozessschritte, was für die Visualisierung der Prozesskarte, die Analyse von Flussvariationen und die Identifizierung von Engpässen unerlässlich ist. Datenquelle Dieses Attribut wird typischerweise aus einer Kombination von Statusfeldern, Audit-Tabellen oder Workflow-Logs innerhalb von Oracle Fusion Financials abgeleitet, wie AP_INVOICES_ALL.WFAPPROVAL_STATUS oder verwandten Workflow-Tabellen. Beispiele Rechnung validiertRechnung gesperrtRechnung freigegebenZahlung ausgeführt
	Startzeit EventTime	Der timestamp, der angibt, wann eine Aktivität oder ein Event stattgefunden hat.
Beschreibung Dieses Attribut liefert Datum und Uhrzeit für jede Aktivität im Rechnungsprozess. Es ist entscheidend für alle zeitbasierten Prozessanalysen, einschließlich der Berechnung von Zykluszeiten, Dauern und Wartezeiten zwischen den Schritten. Durch die chronologische Anordnung der Events mithilfe dieses Timestamp können Process Mining Tools die genaue Abfolge der Aktivitäten für jede Rechnung rekonstruieren. Dies ermöglicht die Berechnung wichtiger Performance-Indikatoren wie der durchschnittlichen Rechnungszykluszeit und hilft zu identifizieren, welche Prozessphasen die meiste Zeit beanspruchen. Bedeutung Dieser Timestamp ist entscheidend für die Berechnung aller Performance-Metriken im Zusammenhang mit Dauer und Zeit, wie Zykluszeiten und Engpässe. Datenquelle Dieser Timestamp wird aus verschiedenen Datumsfeldern in Oracle Fusion Tabellen abgeleitet, wie CREATION_DATE oder LAST_UPDATE_DATE in Tabellen wie AP_INVOICES_ALL oder verwandten Workflow- und Zahlungstabellen. Beispiele 2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
	Benutzername UserName	Der Name des Benutzers, der die Aktivität durchgeführt hat.
Beschreibung Dieses Attribut identifiziert den spezifischen Benutzer oder System-Agenten, der für die Ausführung einer Aktivität verantwortlich ist, z.B. die Validierung einer Rechnung, das Setzen einer Sperre oder die Genehmigung einer Zahlung. Es bietet eine menschliche oder systemische Ressourcendimension für den Prozess. Die Analyse nach Benutzer hilft beim Verständnis der Workload-Verteilung, der Identifizierung von Top-Performern und der Erkennung potenzieller Schulungsbedarfe oder Compliance-Probleme. Zum Beispiel kann sie aufzeigen, ob bestimmte Benutzer konsistent mit Nachbearbeitungsschleifen verbunden sind oder ob spezifische Genehmigungsschritte immer von derselben Person bearbeitet werden, was einen potenziellen Single Point of Failure schafft. Bedeutung Es ermöglicht die Analyse der Ressourcenleistung, den Lastenausgleich und die Identifizierung, welche Benutzer oder Teams in bestimmte Prozessschritte involviert sind. Datenquelle Diese Informationen werden oft in Audit-Spalten wie CREATED_BY oder LAST_UPDATED_BY in Tabellen wie AP_INVOICES_ALL oder in verwandten Workflow-Logs gespeichert. Beispiele john.doejane.smithSystem.Admin
	Buchungskreis CompanyCode	Der Bezeichner für die juristische Einheit oder das Unternehmen, das die Rechnung bearbeitet.
Beschreibung Der Firmen-Code repräsentiert die spezifische Geschäftseinheit innerhalb der Organisation, die finanziell für die Rechnung verantwortlich ist. In Multi-Company-Organisationen ist dies ein grundlegender organisatorischer Datenpunkt. Dieses Attribut ermöglicht es, die Prozessanalyse nach juristischen Einheiten zu segmentieren. Dies ist nützlich, um die Prozess-Performance in verschiedenen Geschäftsbereichen zu vergleichen, entitiespezifische Engpässe oder Compliance-Probleme zu identifizieren und sicherzustellen, dass KPIs auf Unternehmensebene berichtet werden können. Es ist oft auch ein Faktor bei der Bestimmung des korrekten Genehmigungs-Workflows. Bedeutung Es ermöglicht Prozessvergleiche und Performance-Benchmarking über verschiedene Rechtseinheiten oder Geschäftseinheiten innerhalb der Organisation. Datenquelle Dies wird typischerweise durch die LEGAL_ENTITY_ID oder ein ähnliches Feld in AP_INVOICES_ALL repräsentiert, das mit Hauptbuchhaltungstabellen verknüpft werden kann, um einen Code oder Namen zu erhalten. Beispiele 1001US01DE01
	Endzeit EndTime	Der Timestamp, der anzeigt, wann eine Aktivität oder ein Event abgeschlossen wurde.
Beschreibung Die End Time markiert den Abschluss einer spezifischen Aktivität. Während die Start Time den Beginn signalisiert, definiert die End Time den Endpunkt. Dies ermöglicht eine präzise Berechnung der Dauer einzelner Prozessschritte. In der Analyse ergibt die Differenz zwischen End Time und Start Time die Bearbeitungszeit für jede Aktivität. Dies ist für eine detaillierte Performance-Analyse entscheidend, um zwischen aktiver Bearbeitungszeit und Wartezeiten zu unterscheiden. So lässt sich beispielsweise messen, wie viel Zeit ein Genehmiger tatsächlich für eine Aufgabe aufgewendet hat, im Vergleich zu der Zeit, die der Vorgang unbearbeitet in der Warteschlange verbrachte. Bedeutung Es ermöglicht die präzise Berechnung von Aktivitätsverarbeitungszeiten, wobei die aktive Arbeitszeit von der Wartezeit getrennt wird. Datenquelle Dies ist ein konzeptionelles Attribut, abgeleitet von der Startzeit des nachfolgenden Events in der Sequenz für einen gegebenen Case. Beispiele 2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
	Lieferantenname VendorName	Der Name des Lieferanten, der die Rechnung ausgestellt hat.
Beschreibung Dieses Attribut identifiziert die Lieferanten-Entität, von der die Rechnung stammt. Lieferanteninformationen bieten einen kritischen Geschäftskontext für die Finanztransaktion. Die Analyse des Prozesses nach Lieferant kann wichtige Einblicke in Lieferantenbeziehungen und Performance liefern. Zum Beispiel kann sie aufzeigen, ob Rechnungen von bestimmten Lieferanten anfälliger für Abgleichs-Diskrepanzen, Sperren oder Verzögerungen sind. Diese Informationen können zur Verbesserung des Lieferanten-Onboardings, der Kommunikation und der gesamten Supply Chain Effizienz verwendet werden. Sie wird auch zur Identifizierung potenzieller Doppelzahlungen eingesetzt. Bedeutung Es ermöglicht eine lieferantenspezifische Prozessanalyse, die hilft, Probleme mit bestimmten Lieferanten zu identifizieren, die Verzögerungen oder Ausnahmen verursachen. Datenquelle Gefunden in der Tabelle `POZ_SUPPLIERS`. Die Rechnungstabelle `AP_INVOICES_ALL` enthält eine `VENDOR_ID`, die verwendet werden kann, um mit der Lieferantentabelle zu verknüpfen. Beispiele Acme CorporationGlobal Tech Inc.Bürobedarf GmbH
	Rechnungsbetrag InvoiceAmount	Der monetäre Gesamtwert der Rechnung.
Beschreibung Der Rechnungsbetrag stellt die gesamte dem Lieferanten geschuldete Summe dar, wie auf der Rechnung angegeben. Dies ist ein kritisches Finanzattribut, das den gesamten Prozess beeinflusst und oft den Genehmigungspfad, den Prüfungsgrad und die Zahlungspriorität bestimmt. In der Process Mining Analyse ist der Rechnungsbetrag eine Schlüsseldimension für Filterung und Segmentierung. Zum Beispiel können Analysten den Prozess für Rechnungen mit hohem Wert im Vergleich zu Rechnungen mit niedrigem Wert vergleichen, um zu sehen, ob unterschiedliche Pfade verfolgt werden oder ob sich die Zykluszeiten signifikant unterscheiden. Er ist auch entscheidend für die Berechnung von Finanz-KPIs und die Bewertung der monetären Auswirkungen von Prozesseffizienzproblemen wie verspäteten Zahlungen. Bedeutung Dieser Wert ist entscheidend für die Finanzanalyse, das Verständnis von Prozessabweichungen basierend auf dem Wert und für KPIs wie die Genehmigungs-Compliance-Rate. Datenquelle Gefunden in der Tabelle `AP_INVOICES_ALL`, in der Spalte `INVOICE_AMOUNT`. Beispiele 1500.00250.75125000.50
	Rechnungsstatus InvoiceStatus	Der aktuelle Status der Rechnung in ihrem Lebenszyklus.
Beschreibung Dieses Attribut spiegelt den letzten bekannten Status der Rechnung wider, z.B. 'Validiert', 'Muss erneut validiert werden', 'Bezahlt' oder 'Storniert'. Es bietet einen Schnappschuss darüber, wo sich eine Rechnung zu einem bestimmten Zeitpunkt im Prozess befindet. Der Rechnungsstatus ist entscheidend für das Dashboard 'Aktuelle Rechnungsstatusverteilung', das Betriebsleitern hilft, Rückstände zu identifizieren und den allgemeinen Zustand der Rechnungsverarbeitungspipeline zu überwachen. Die Analyse, wie sich Statusse im Laufe der Zeit ändern, kann auch eine vereinfachte Ansicht des Prozessflusses bieten. Bedeutung Es bietet eine Ist-Ansicht von Rechnungen, die für operative Dashboards, die Rückstände und Arbeitslast verfolgen, unerlässlich ist. Datenquelle Konsultieren Sie die Oracle Fusion Financials Dokumentation. Der Status kann aus Feldern wie `WFAPPROVAL_STATUS` in `AP_INVOICES_ALL` oder verwandten Genehmigungs- und Zahlungstabellen abgeleitet werden. Beispiele ValidiertBezahltStorniertNeubewertung erforderlich
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Datum, bis zu dem die Rechnung zu zahlen ist.
Beschreibung Das Zahlungsfälligkeitsdatum wird basierend auf den mit dem Lieferanten vereinbarten Zahlungsbedingungen berechnet. Es dient als Frist für die Zahlung, um Strafen zu vermeiden, gute Lieferantenbeziehungen aufrechtzuerhalten und potenzielle Skontoerträge zu nutzen. Dieses Attribut ist entscheidend für das 'On-Time Payment Performance' Dashboard und den zugehörigen KPI. Durch den Vergleich des tatsächlichen Zahlungsausführungs-Timestamp mit dem Zahlungsfälligkeitsdatum kann die Analyse Zahlungen als pünktlich oder verspätet klassifizieren, was der Organisation hilft, ihre Zahlungsaktualität zu überwachen und zu verbessern. Bedeutung Dies ist die Grundlage für die Messung der Pünktlichkeits-Performance von Zahlungen, ein kritischer KPI für das Lieferantenmanagement und die finanzielle Gesundheit. Datenquelle Dieses Datum ist oft in Zahlungsplantabellen wie AP_PAYMENT_SCHEDULES_ALL verfügbar, die mit der Rechnung verknüpft sind. Beispiele 2023-05-152023-06-012023-06-30
	Bearbeitungszeit ProcessingTime	Die Dauer der Zeit, die für eine einzelne Aktivität aufgewendet wurde.
Beschreibung Die Bearbeitungszeit misst die aktive Arbeitsdauer für einen bestimmten Prozessschritt. Sie wird als Differenz zwischen der Endzeit und der Startzeit einer Aktivität berechnet. Diese berechnete Metrik ist entscheidend für die Performance-Analyse, da sie hilft, die aktive Bearbeitungszeit von der untätigen Wartezeit zu unterscheiden. Zum Beispiel kann sie zeigen, dass eine Genehmigungsaktivität 5 Minuten aktive Arbeit erforderte, aber 3 Tage in einer Warteschlange verbrachte. Diese Erkenntnis ermöglicht es Managern, Verbesserungsbemühungen entweder auf die Reduzierung der Arbeitszeit durch Schulung oder Automatisierung oder auf die Reduzierung der Wartezeit durch besseres Workload-Management zu konzentrieren. Bedeutung Es isoliert die aktive Arbeitszeit für eine Aktivität und hilft so, zwischen ineffizienten Aufgaben und langen Wartezeiten zu unterscheiden. Datenquelle Dies ist ein berechnetes Attribut, abgeleitet durch Subtraktion der Startzeit von der Endzeit (Endzeit - Startzeit). Beispiele PT5MPT1H30MP2D
	Bestellnummer PurchaseOrderNumber	Die Kennung der mit der Rechnung verknüpften Bestellung.
Beschreibung Dieses Attribut verknüpft die Rechnung mit der entsprechenden Bestellung (PO), die die Beschaffung der Waren oder Dienstleistungen autorisiert hat. Rechnungen können PO-gestützt oder nicht-PO-gestützt sein. Die Analyse nach PO bietet eine Verknüpfung zum Beschaffungsteil des P2P-Prozesses. Sie hilft zu verstehen, wie Compliance-konform der Beschaffungsprozess ist und ob Probleme bei der Rechnungsstellung, wie z.B. Abgleichs-Diskrepanzen, aus Problemen mit der ursprünglichen PO resultieren. Das Vorhandensein oder Fehlen einer PO-Nummer ist eine primäre Methode zur Segmentierung und Analyse unterschiedlicher Rechnungsverarbeitungspfade. Bedeutung Es verknüpft die Rechnung mit dem Beschaffungsprozess und ist ein Schlüsselattribut für die Analyse von PO- versus Nicht-PO-Rechnungsflüssen. Datenquelle Diese Informationen sind verfügbar, indem die Rechnungszeilenpositionen in AP_INVOICE_LINES_ALL über die PO_DISTRIBUTION_ID mit den PO-Verteilungen verknüpft werden. Beispiele PO-2023-5001600789PO-FIN-9981
	Grund der Abweichung beim Abgleich MatchingDiscrepancyReason	Der spezifische Grund für eine Diskrepanz zwischen Rechnung, Bestellung und Wareneingang.
Beschreibung Dieses Attribut beschreibt detailliert, warum eine Rechnung den automatisierten Abgleichsprozess nicht bestanden hat. Häufige Gründe sind Preis-, Mengen- oder Artikelcode-Unterschiede zwischen der Rechnung und der entsprechenden Bestellung oder dem Wareneingang. Diese Informationen sind entscheidend für das Dashboard 'Rechnungs-Abgleichs-Diskrepanzrate'. Durch die Kategorisierung und Analyse der Gründe für Diskrepanzen können Unternehmen systemische Probleme in ihren Beschaffungs- oder Wareneingangsprozessen identifizieren. Dies ermöglicht korrigierende Maßnahmen, die die Rate der durchgängigen, berührungslosen Rechnungsverarbeitung erhöhen können. Bedeutung Es erklärt, warum Rechnungen beim automatisierten Abgleich fehlschlagen, und liefert die notwendigen Erkenntnisse zur Verbesserung der Erstabgleichsquoten und zur Reduzierung manueller Nacharbeit. Datenquelle Konsultieren Sie die Oracle Fusion Financials Dokumentation. Dies kann als spezifische Art von `hold reason` in `AP_HOLDS_ALL` oder in verwandten `matching detail tables` erfasst werden. Beispiele Stückpreis weicht von PO abRechnungsmenge > empfangene MengeUngültiger Posten auf Rechnung
	Ist Nacharbeit IsRework	Ein boolesches Flag, das Aktivitäten identifiziert, die Teil einer Nacharbeits-Schleife sind.
Beschreibung Dieses Flag ist auf 'true' gesetzt für Aktivitäten, die eine Abweichung vom idealen Prozessfluss anzeigen, wie 'Rechnung korrigiert' oder eine zweite Instanz von 'Rechnung validiert' nach einer Ablehnung. Es hilft, ineffiziente Prozessschleifen explizit zu kennzeichnen und zu quantifizieren. Dieses Attribut ist entscheidend für das Dashboard 'Nachbearbeitungs- und Ausnahmebehandlungsrate'. Durch die Kennzeichnung von Nachbearbeitungsaktivitäten können Analysten das Volumen und die Kosten der Nachbearbeitung leicht quantifizieren, deren Grundursachen identifizieren und die Auswirkungen von Prozessverbesserungsinitiativen messen, die darauf abzielen, Dinge gleich beim ersten Mal richtig zu machen. Bedeutung Es identifiziert und quantifiziert explizit Nacharbeit, wodurch es einfacher wird, die Häufigkeit, Ursachen und Auswirkungen von Prozessineffizienzen zu analysieren. Datenquelle Dies ist ein berechnetes Attribut. Die Logik wird während der Daten-Transformation definiert, um Abfolgen von Aktivitäten zu identifizieren, die Nachbearbeitung darstellen. Beispiele truefalsch
	Ist pünktliche Zahlung IsOnTimePayment	Ein boolesches Flag, das anzeigt, ob die Rechnung bis zum Fälligkeitsdatum bezahlt wurde.
Beschreibung Dieses Flag ist auf 'true' gesetzt, wenn die Zahlung am oder vor dem angegebenen Zahlungsfälligkeitsdatum ausgeführt wurde, und 'false' andernfalls. Es bietet eine einfache, klare Klassifizierung für jede bezahlte Rechnung. Dieses berechnete Attribut unterstützt direkt den KPI 'Pünktliche Zahlungsrate' und das entsprechende Dashboard. Es vereinfacht die Analyse, indem es Benutzern ermöglicht, den Anteil verspäteter gegenüber pünktlicher Zahlungen einfach zu filtern, zu zählen und zu visualisieren, ohne Datumsvergleiche ad hoc durchzuführen. Dies hilft, das Ausmaß von Zahlungsverzögerungen schnell zu identifizieren und Verbesserungen im Laufe der Zeit zu verfolgen. Bedeutung Dies vereinfacht die Analyse der Pünktlichkeit von Zahlungen und ist die direkte Eingabe für die Berechnung des KPI 'Pünktliche Zahlungsrate'. Datenquelle Dies ist ein berechnetes Attribut, abgeleitet durch den Vergleich des Timestamp der Aktivität 'Zahlung ausgeführt' mit dem Attribut 'PaymentDueDate'. Beispiele truefalsch
	Letzte Datenaktualisierung LastUpdateDate	Timestamp, der angibt, wann der Datensatz zuletzt im Quellsystem aktualisiert wurde.
Beschreibung Dieses Attribut spiegelt die letzte Änderungszeit der zugrunde liegenden Daten in Oracle Fusion Financials wider. Es wird verwendet, um inkrementelle Datenladungen zu verwalten und sicherzustellen, dass das Process Mining Modell aktuell ist. Obwohl nicht direkt für die Prozessflussanalyse verwendet, ist dieser technische Timestamp entscheidend für die Aufrechterhaltung der Datenaktualität und -integrität. Er ermöglicht Datenpipelines, effizient nur neue oder geänderte Datensätze seit dem letzten Update abzufragen, wodurch die Last auf dem Quellsystem reduziert wird. Bedeutung Stellt sicher, dass Datenpipelines effizient und inkrementell ausgeführt werden können, wodurch die Prozessanalyse ohne vollständige Neuladungen aktuell bleibt. Datenquelle Häufig als `LAST_UPDATE_DATE` in vielen Oracle Fusion-Tabellen, einschließlich `AP_INVOICES_ALL`, gefunden. Beispiele 2023-05-20T11:00:00Z2023-05-21T16:45:00Z
	Name des Genehmigers ApproverName	Der Name der Person, die die Rechnung genehmigt oder abgelehnt hat.
Beschreibung Dieses Attribut erfasst die Identität der Person, die während des Genehmigungsschritts gehandelt hat. Dies wird für Aktivitäten wie 'Rechnung genehmigt' oder 'Rechnung abgelehnt' aufgezeichnet. In der Analyse wird der Name des Genehmigers verwendet, um Genehmigungs-Workloads zu verstehen, individuelle Genehmigungs-Zykluszeiten zu messen und die Compliance mit Genehmigungsrichtlinien zu prüfen. Für den KPI 'Genehmigungs-Compliance-Rate' kann dieses Attribut anhand von Delegationsregeln überprüft werden, basierend auf dem Rechnungsbetrag und dem Firmen-Code. Bedeutung Dies ist wesentlich für die Analyse von Genehmigungszykluszeiten, die Sicherstellung der Compliance mit Genehmigungsmatrixrichtlinien und das Verständnis der Workload-Verteilung. Datenquelle Diese Informationen befinden sich in den Oracle Fusion Workflow- oder Genehmigungshistorientabellen, die dem Rechnungsobjekt zugeordnet sind. Beispiele David WilsonSarah JohnsonMichael Brown
	Quellsystem SourceSystem	Kennzeichnet das Ursprungssystem, in dem die Event-Daten erfasst wurden.
Beschreibung Dieses Attribut gibt die Quellanwendung oder das Modul an, das die Daten generiert hat, z.B. Oracle Fusion Financials. In Umgebungen mit mehreren integrierten Systemen hilft dieses Feld, den Ursprung unterschiedlicher Prozessschritte zu unterscheiden. Das Verständnis des Quellsystems ist wertvoll für die Datenvalidierung, Fehlerbehebung und Analyse von Prozessvariationen, die für ein bestimmtes System spezifisch sein können. Es sorgt für Klarheit in komplexen IT-Landschaften, in denen der Weg einer Rechnung mehrere Anwendungen umfassen kann. Bedeutung Es liefert Kontext zur Datenherkunft, was wichtig für Data Governance, Fehlerbehebung und die Analyse systemspezifischen Prozessverhaltens ist. Datenquelle Dies ist oft ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion FinancialsOracle Payables Cloud
	Rechnungsdatum InvoiceDate	Das auf dem Rechnungsdokument des Lieferanten angegebene Datum.
Beschreibung Dieses Attribut ist das Datum, an dem der Lieferant die Rechnung offiziell ausgestellt hat. Es ist eine wichtige Information auf dem Quelldokument und wird als Ausgangspunkt für die Berechnung des Zahlungsfälligkeitsdatums basierend auf vereinbarten Zahlungsbedingungen verwendet. Obwohl nicht immer der Beginn des internen Prozesses, ist das Rechnungsdatum ein entscheidender Kontext. Es wird in Kombination mit Lieferantenname und Rechnungsbetrag verwendet, um potenzielle doppelte Rechnungen zu identifizieren. Die Analyse der Verzögerung zwischen dem Rechnungsdatum und dem Datum, an dem die Rechnung im System erstellt wird, kann auch Ineffizienzen im Posteingang oder im Rechnungs-Ingestion-Prozess aufzeigen. Bedeutung Es ist ein wichtiger Datenpunkt zur Identifizierung doppelter Rechnungen und zur Berechnung von Fälligkeitsdaten von Zahlungen. Datenquelle Dies ist ein Standardfeld in der Tabelle AP_INVOICES_ALL mit dem Namen INVOICE_DATE. Beispiele 2023-04-102023-05-012023-05-25
	Sperrgrund HoldReason	Der Grund, warum eine Sperre oder Zahlungsblockade für eine Rechnung verhängt wurde.
Beschreibung Wenn eine Rechnung auf Sperre gesetzt wird, gibt dieses Attribut den Grund an, wie 'Preisabweichung', 'Mengen-Diskrepanz' oder 'Warenausgang ausstehend'. Dies liefert Kontext, warum der normale Prozessfluss unterbrochen wurde. Dieses Attribut ist die primäre Dimension für das Dashboard 'Zahlungssperren-Trends und Analyse'. Durch die Analyse der Häufigkeit verschiedener Sperrgründe kann das Unternehmen die Grundursachen für Zahlungssperren identifizieren und angehen, wie z.B. Probleme mit Beschaffungsprozessen oder der Rechnungsgenauigkeit von Lieferanten, wodurch die Bearbeitungsverzögerungen letztendlich reduziert werden. Bedeutung Es liefert die Grundursache für Zahlungsblockierungen und ermöglicht gezielte Verbesserungen zur Reduzierung der Häufigkeit von Blockierungen und Zahlungsverzögerungen. Datenquelle Halteinformationen werden typischerweise in der Tabelle `AP_HOLDS_ALL` gespeichert, die mit der Rechnung verknüpft ist und einen Haltegrund oder -code enthält. Beispiele PreisabweichungFakturierte Menge übersteigt erhaltene MengeUngültige Bestellnummer (PO)
	Währung InvoiceCurrencyCode	Die Währung des Rechnungsbetrags.
Beschreibung Dieses Attribut gibt die Währung an, in der die Rechnung denominiert ist, z.B. USD, EUR oder GBP. Es ist ein wesentlicher Kontext für das Feld Rechnungsbetrag. In einer globalen Organisation ist die Analyse von Rechnungen nach Währung wichtig für die Finanzberichterstattung und das Verständnis von Prozessvariationen nach Regionen. Sie stellt sicher, dass Geldwerte korrekt interpretiert werden und ermöglicht eine währungsspezifische Analyse von Zahlungspraktiken oder Genehmigungsschwellenwerten. Bedeutung Liefert den notwendigen Kontext für alle Finanzbeträge und gewährleistet eine präzise Interpretation und Analyse, insbesondere in multinationalen Operationen. Datenquelle Gefunden in der Tabelle `AP_INVOICES_ALL` in der Spalte `INVOICE_CURRENCY_CODE`. Beispiele USDEURGBPCAD

Erforderlich Empfohlen Optional

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsaktivitäten

Dies sind die wichtigen Prozessschritte und Meilensteine, die Sie in Ihrem `Event Log` für eine genaue `Process Discovery` erfassen sollten.

6 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Rechnung erstellt	Stellt die erstmalige Erstellung eines Rechnungsdatensatzes im System dar, entweder durch manuelle Eingabe, Scannen oder elektronische Übermittlung. Dieses Event wird typischerweise erfasst, wenn eine neue Zeile in die Hauptrechnungstabelle eingefügt wird.
Bedeutung Markiert den Beginn des Rechnungsverarbeitungszyklus. Die Analyse der Zeit ab diesem Event hilft, die Effizienz der Datenerfassung und allgemeine Verzögerungen beim Prozessstart zu verstehen. Datenquelle In Oracle Fusion Financials entspricht dies dem Erstellungs-Timestamp des Datensatzes in der Tabelle `AP_INVOICES_ALL`, genauer gesagt der Spalte `CREATION_DATE`. Erfassen Datensatz-Erstellungs-Timestamp in AP_INVOICES_ALL. Ereignistyp explicit
	Rechnung freigegeben	Die Rechnung wurde von allen erforderlichen Parteien im Workflow vollständig genehmigt. Sie ist nun bereit für die Buchhaltung und Zahlungsplanung.
Bedeutung Ein wichtiger Meilenstein, der den erfolgreichen Abschluss des Genehmigungsprozesses kennzeichnet. Verzögerungen vor diesem Schritt sind häufige Engpässe. Datenquelle Abgeleitet von der Änderung des `APPROVAL_STATUS` in der Tabelle `AP_INVOICES_ALL` in einen finalen genehmigten Zustand wie 'Approved' oder 'Workflow Approved'. Die Audit-Historie dieses Feldes liefert den Timestamp. Erfassen Abgeleitet von der Änderung des `AP_INVOICES_ALL.APPROVAL_STATUS` zu 'Approved'. Ereignistyp inferred
	Rechnung mit Bestellung abgeglichen	Diese Aktivität zeigt den erfolgreichen Abgleich einer Rechnungszeile mit einer entsprechenden Bestellzeile (Purchase Order) an und bestätigt, dass die fakturierten Waren oder Dienstleistungen bestellt wurden. Dies ist typischerweise eine automatisierte oder manuelle Aktion, die im System erfasst wird.
Bedeutung Entscheidend für den Drei-Wege-Abgleich, der die Bestellung (PO), den Wareneingang und die Rechnung umfasst. Fehler in dieser Phase sind eine Hauptursache für Ausnahmen und Verzögerungen. Datenquelle Kann aus der Erstellung von Datensätzen in der Tabelle `AP_INVOICE_DISTRIBUTIONS_ALL` abgeleitet werden, die die Rechnung mit einer PO-Verteilung (`PO_DISTRIBUTION_ID`) verknüpfen. Der `line level match status` in `AP_INVOICE_LINES_ALL` kann ebenfalls verwendet werden. Erfassen Abgeleitet von der Bestückung von `PO distribution data` in Rechnungszeilen. Ereignistyp inferred
	Rechnung verbucht	Die Rechnung wird erfolgreich im Hauptbuch verbucht, wodurch Journaleinträge erstellt werden. Dieses Event bestätigt, dass die finanziellen Auswirkungen der Rechnung formell erfasst wurden.
Bedeutung Ein kritischer finanzieller Kontrollpunkt und eine Voraussetzung für die Zahlung. Es bestätigt, dass die Rechnung vollständig validiert, genehmigt und zur Begleichung bereit ist. Datenquelle Abgeleitet vom Status in der Tabelle `AP_INVOICE_DISTRIBUTIONS_ALL` (`ACCRUAL_POSTED_FLAG` = 'Y') oder durch Überprüfung auf entsprechende Journaleinträge in den Hauptbuchtabellen wie `XLA_AE_HEADERS`. Erfassen Abgeleitet von Flags in `AP_INVOICE_DISTRIBUTIONS_ALL` oder verknüpften GL-Einträgen. Ereignistyp inferred
	Rechnung zur Genehmigung gesendet	Die Rechnung wird in einen Genehmigungs-Workflow eingereicht, basierend auf konfigurierten Geschäftsregeln. Dies markiert den Beginn des formellen Genehmigungszyklus.
Bedeutung Leitet einen kritischen Teil des Prozesses ein. Die Verfolgung dieser Startzeit ist wesentlich für die Messung und Optimierung der 'Rechnungsfreigabe-Cycle Time'. Datenquelle Abgeleitet von einer Statusänderung in der Tabelle `AP_INVOICES_ALL`, wobei `APPROVAL_STATUS` in einen Zustand wie 'Initiated' oder 'Pending Approval' übergeht. Die Workflow-Tabellen können dieses Event ebenfalls enthalten. Erfassen Abgeleitet von der Änderung des `AP_INVOICES_ALL.APPROVAL_STATUS` zu 'Initiated'. Ereignistyp inferred
	Zahlung ausgeführt	Die endgültige Bestätigung, dass die Zahlung ausgeführt und verrechnet wurde. Bei Schecks wäre dies das Verrechnungsdatum, bei elektronischen Zahlungen die Bestätigung der Bank.
Bedeutung Dies ist die letzte Aktivität im Rechnungslebenszyklus, die den erfolgreichen Abschluss des Prozesses markiert. Es ist der Endpunkt für die Berechnung der 'Durchschnittlichen Rechnungszykluszeit' und der 'Pünktlichen Zahlungsrate'. Datenquelle Abgeleitet von der Aktualisierung des Zahlungsstatus auf 'Cleared' oder 'Reconciled' in der Tabelle `AP_CHECKS_ALL` (unter Verwendung des `CLEARED_DATE`) oder durch data aus der Bankabstimmung im Cash Management-Modul (`CE_STATEMENT_LINES`). Erfassen Abgeleitet von Statusaktualisierungen in `AP_CHECKS_ALL` oder der Abstimmung im CE-Modul. Ereignistyp inferred
	Abweichung beim Abgleich identifiziert	Tritt auf, wenn das System oder ein Benutzer eine Diskrepanz zwischen Rechnungs-, Bestell- und Empfangsinformationen feststellt, z.B. bei Preis oder Menge. Dies führt oft zu einer systemseitigen Sperre der Rechnung.
Bedeutung Hebt Prozessausnahmen hervor, die manuelle Eingriffe erfordern. Die Verfolgung dieser Events ist wesentlich für den KPI 'Rechnungsabgleich-Abweichungsrate' und die Ursachenanalyse. Datenquelle Dies wird oft als spezifischer Sperrtyp für eine Rechnung protokolliert. Überprüfen Sie die Tabelle AP_HOLDS_ALL auf Sperrtypen, die sich auf den Abgleich beziehen, z.B. 'QTY REC' oder 'PRICE'. Das Feld HOLD_DATE gibt den Timestamp an. Erfassen Erstellung eines Datensatzes in `AP_HOLDS_ALL` mit einem `matching-related hold type`. Ereignistyp explicit
	Blockierung von Rechnung freigegeben	Dieses Event markiert die Aufhebung einer zuvor auf die Rechnung gelegten Sperre. Ein Benutzer oder ein automatisierter Prozess ergreift Maßnahmen, um die Blockade zu entfernen, wodurch die Rechnung ihren Lebenszyklus fortsetzen kann.
Bedeutung Die Zeit zwischen dem Setzen und Aufheben einer Sperre ist ein kritisches Maß für die Effizienz der Ausnahmebehandlung. Dies unterstützt den KPI 'Durchschnittliche Lösungszeit für Ausnahmen'. Datenquelle Protokolliert in der Tabelle AP_HOLDS_ALL. Wenn eine Sperre aufgehoben wird, werden die Felder RELEASE_LOOKUP_CODE und RELEASE_REASON zusammen mit einem LAST_UPDATE_DATE gefüllt. Erfassen Aktualisierung eines Datensatzes in der Tabelle AP_HOLDS_ALL, der die Sperre als aufgehoben markiert. Ereignistyp explicit
	Rechnung abgelehnt	Ein Genehmiger hat die Rechnung während des Genehmigungs-Workflows abgelehnt. Diese Aktion sendet die Rechnung typischerweise zur Korrektur oder Stornierung zurück und initiiert eine Nacharbeits-Schleife.
Bedeutung Stellt ein negatives Ergebnis und einen Haupttreiber für Nachbearbeitung und erhöhte Zykluszeiten dar. Das Verfolgen von Ablehnungen hilft, Probleme mit der Rechnungsqualität oder PO-Compliance zu identifizieren. Datenquelle Abgeleitet von der Änderung des `APPROVAL_STATUS` in der Tabelle `AP_INVOICES_ALL` zu 'Rejected'. Die Workflow-Historie enthält Details darüber, wer es wann abgelehnt hat. Erfassen Abgeleitet von der Änderung des `AP_INVOICES_ALL.APPROVAL_STATUS` zu 'Rejected'. Ereignistyp inferred
	Rechnung gesperrt	Eine generische Aktivität, die jede Art von Blockierung einer Rechnung darstellt, die deren Weiterleitung zur Zahlung verhindert. Dies kann verschiedene Gründe haben, wie Abgleichprobleme, unzureichende Mittel oder manuelle Intervention.
Bedeutung Wirkt sich direkt auf die Cycle Time aus und kann zu verspäteten Zahlungen führen. Die Analyse von Blockierungen ist entscheidend, um systemische Prozessprobleme zu identifizieren und zu lösen, und unterstützt die Analyse von 'Zahlungsblockierungstrends'. Datenquelle Explizit in der Tabelle `AP_HOLDS_ALL` protokolliert. Jede Zeile stellt eine Blockierung mit einem Erstellungsdatum (`HOLD_DATE`) und einem Grund dar. Erfassen Erstellung eines Datensatzes in der Tabelle `AP_HOLDS_ALL`. Ereignistyp explicit
	Rechnung korrigiert	Tritt auf, wenn ein Benutzer eine Rechnung ändert, oft als Reaktion auf eine Ablehnung oder zur Korrektur eines Dateneingabefehlers. Dies stellt einen manuellen Nachbearbeitungsschritt im Prozess dar.
Bedeutung Diese Aktivität ist ein klarer Indikator für Nachbearbeitung. Die Analyse ihrer Häufigkeit hilft, die Prozesseffizienz zu quantifizieren und unterstützt den KPI 'Rechnungs-Nachbearbeitungsrate'. Datenquelle Kann durch die Verfolgung signifikanter Aktualisierungen des Rechnungsdatensatzes in `AP_INVOICES_ALL` abgeleitet werden, nachdem diese bereits validiert oder zur Genehmigung eingereicht wurde. Der `LAST_UPDATE_DATE`-Timestamp zusammen mit `audit trail data` wäre erforderlich. Erfassen Abgeleitet durch Vergleich des `LAST_UPDATE_DATE` nach einer Ablehnung oder Blockierung. Ereignistyp inferred
	Rechnung storniert	Die Rechnung wurde annulliert oder storniert und wird nicht weiter bearbeitet oder bezahlt. Dies stellt einen terminalen Endzustand für den Prozess dar.
Bedeutung 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. Datenquelle Abgeleitet von einer Statusänderung in `AP_INVOICES_ALL`. Die Spalte `CANCELLED_DATE` wird mit dem Stornierungs-Timestamp gefüllt. Erfassen Das Feld CANCELLED_DATE in der Tabelle AP_INVOICES_ALL wird gefüllt. Ereignistyp explicit
	Rechnung validiert	Bedeutet, dass die Rechnung die Validierungsprüfungen des Systems hinsichtlich Vollständigkeit und Korrektheit der Kopf- und Positionsinformationen bestanden hat. Dies wird oft aus einer Statusänderung des Rechnungsdatensatzes abgeleitet.
Bedeutung Ein wichtiger Meilenstein vor dem Abgleich und der Genehmigung. Verzögerungen hier können auf Probleme mit der Rechnungsdatenqualität oder der Systemkonfiguration hindeuten. Datenquelle Abgeleitet vom Statuswechsel der Rechnung zu 'Validated' in der Tabelle `AP_INVOICES_ALL`. Die Änderungshistorie oder der `Audit Trail` für die Spalte `VALIDATION_STATUS` kann verwendet werden. Erfassen Abgeleitet von der Änderung des Feldes `AP_INVOICES_ALL.VALIDATION_STATUS`. Ereignistyp inferred
	Zahlung erstellt	Die Zahlungsanweisung für die Rechnung wurde vom System generiert. Dies könnte die Erstellung eines Schecks, einer Datei für den elektronischen Zahlungsverkehr (EFT) oder eines anderen Zahlungsinstruments sein.
Bedeutung Dies ist der Zeitpunkt, an dem die Organisation die Gelder für die Zahlung freigibt. Es ist ein wichtiger Meilenstein, kurz bevor das Geld das Bankkonto verlässt. Datenquelle Aufgezeichnet in der Tabelle AP_CHECKS_ALL, die Informationen über alle Zahlungen speichert. Das Feld CHECK_DATE gibt an, wann das Zahlungsdokument erstellt wurde. Erfassen Erstellung eines Datensatzes in der Tabelle `AP_CHECKS_ALL`. Ereignistyp explicit
	Zahlung terminiert	Die Rechnung wird ausgewählt und in eine Zahlungsanforderungsanfrage aufgenommen, oft als Zahlungslauf oder Zahlungsstapel bezeichnet. Sie ist nun zur Zahlung vorgemerkt.
Bedeutung Der Schritt zwischen Buchhaltung und tatsächlicher Zahlung. Die Dauer dieser Phase beeinflusst die Cashflow-Prognose und die Möglichkeit, Skontoerträge zu nutzen. Datenquelle Dies wird in der Tabelle AP_INVOICE_PAYMENTS_ALL aufgezeichnet, wenn ein Zahlungsdatensatz erstellt, aber noch nicht als bezahlt bestätigt wurde. Es kann auch in Zahlungsstapeltabellen wie IBY_PAYMENT_PROCESS_REQUESTS gefunden werden. Erfassen Erstellung eines Datensatzes in `AP_INVOICE_PAYMENTS_ALL` für eine geplante Zahlung. Ereignistyp explicit

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Bei Oracle Fusion Cloud anmelden: Greifen Sie auf Ihre Oracle Fusion Cloud-Umgebung mit einem Benutzer zu, der die Rolle BI Cloud Connector Administrator (BICC_ADMIN) besitzt.
Zu BI Cloud Connector navigieren: Gehen Sie im Hauptnavigationsmenü zu „Tools > BI Cloud Connector“. Dadurch wird die BICC-Konsole geöffnet.
Angebot auswählen: Wählen Sie in der BICC-Konsole das Angebot aus, das Ihren Finanzdaten entspricht. Dies wird typischerweise 'Financials' genannt.
Externen Speicher konfigurieren: Navigieren Sie zum Abschnitt „Configure External Storage“. Richten Sie die Verbindung zu Ihrem Cloud-Speicher ein, wo die extrahierten CSV-Dateien abgelegt werden, z.B. Oracle Cloud Infrastructure (OCI) Object Storage.
Angebote für die Extraktion aktivieren: Gehen Sie zum Abschnitt „Manage Offerings and PVOs“ oder einem ähnlichen Bereich. Wählen Sie das 'Financials'-Angebot aus und aktivieren Sie es für die Extraktion.
Public View Objects (PVOs) auswählen: Suchen und wählen Sie die spezifischen PVOs aus, die für den Rechnungsprozess erforderlich sind. Die wichtigsten PVOs sind: FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO, FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO, FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO und FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO.
Extraktionsjob planen: Navigieren Sie zu „Manage Extract Schedules“. Erstellen Sie einen neuen Job, geben Sie ihm einen aussagekräftigen Namen und wählen Sie alle PVOs aus, die Sie im vorherigen Schritt aktiviert haben. Planen Sie die Ausführung des Jobs. Für die erste Ladung führen Sie ihn für den gewünschten historischen Datumsbereich aus. Für nachfolgende Läufe konfigurieren Sie ihn so, dass inkrementelle Extraktionen basierend auf dem LastUpdateDate durchgeführt werden.
Daten überwachen und abrufen: Überwachen Sie den Fortschritt des Jobs in der BICC-Konsole. Sobald er erfolgreich abgeschlossen ist, navigieren Sie zu Ihrem konfigurierten Cloud-Speicherort. Dort finden Sie die extrahierten Daten als Satz von komprimierten CSV-Dateien, eine für jedes PVO.
Daten in Staging-Bereich laden: Entpacken Sie die Dateien und laden Sie die CSVs in eine Staging-Datenbank oder Datenverarbeitungsplattform (wie ein Data Warehouse oder Data Lake), wo Sie SQL-Abfragen ausführen können. Jede CSV-Datei sollte in eine eigene Tabelle geladen werden.
Daten in Event Log umwandeln: Führen Sie die bereitgestellte SQL-Abfrage für die Tabellen in Ihrem Staging-Bereich aus. Diese Abfrage vereinigt Daten aus den verschiedenen Tabellen, um eine einzige, vereinheitlichte Event Log-Tabelle zu erstellen.
Für ProcessMind exportieren: Exportieren Sie das Ergebnis der SQL-Abfrage als einzelne CSV-Datei. Stellen Sie sicher, dass die Spaltenüberschriften den erforderlichen Attributen (InvoiceNumber, ActivityName, EventTime, etc.) für den Upload in die ProcessMind-Anwendung entsprechen.

Konfiguration

Wichtige Public View Objects (PVOs): Die Extraktion basiert auf mehreren zentralen PVOs des Financials-Angebots. Mindestens müssen Sie Folgendes einschließen:
- FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO: Für die Kernrechnungsdaten, Erstellungs-, Validierungs- und Stornierungsereignisse.
- FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO: Für alle Rechnungsblockierungs- und Freigabeereignisse.
- FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO: Um detaillierte Genehmigungs-Workflow-Schritte wie Einreichung, Genehmigung und Ablehnung zu erfassen.
- FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO: Für Ereignisse zur Zahlungserstellung und -ausführung.
- FscmTopModelAM.FinApInvPmtsAM.InstallmentPVO: Um zu identifizieren, wann eine Rechnung zur Zahlung fällig ist.
Inkrementelle Extraktionen: Für die kontinuierliche Überwachung konfigurieren Sie den BICC-Job so, dass inkrementelle Extraktionen durchgeführt werden. Verwenden Sie die in den meisten PVOs verfügbare Spalte LastUpdateDate als Filterkriterium, um nur neue oder geänderte Datensätze seit dem letzten Lauf zu extrahieren.
Datumsbereichsfilterung: Für die anfängliche historische Datenladung wird empfohlen, einen überschaubaren Zeitraum zu extrahieren, z.B. die letzten 6 bis 12 Monate an Daten. Sie können einen globalen Filter im BICC-Job-Zeitplan anwenden, um die Extraktion auf einen bestimmten Datumsbereich zu beschränken.
Geschäftseinheitenfilter: Um den Umfang der Extraktion zu begrenzen, wenden Sie einen Filter auf BusinessUnitName oder ein ähnliches Attribut innerhalb der BICC-Job-Konfiguration an. Dies ist in Umgebungen mit mehreren Einheiten entscheidend, um das Datenvolumen zu steuern.
Voraussetzungen: Ihr Benutzerkonto benötigt die entsprechenden Rollen, hauptsächlich BICC Administrator (BICC_ADMIN) und Functional Setup User (FSM_IMPLEMENTATION_CONSULTANT), um Extraktionsjobs zu konfigurieren und auszuführen. Sie müssen auch einen konfigurierten und zugänglichen Cloud-Speicherort (wie OCI Object Storage, UCM) haben.

a Beispielabfrage config

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

Zugriff auf Oracle BI Publisher: Melden Sie sich bei Oracle Fusion Applications mit einem Benutzer an, der die Rolle BI Administrator oder eine ähnliche Rolle besitzt. Navigieren Sie zum Tool „Reports and Analytics“, indem Sie das Navigator-Menü öffnen, dann „Tools“ auswählen und schließlich auf „Reports and Analytics“ klicken.
Zum Katalog navigieren: Im Arbeitsbereich „Reports and Analytics“ klicken Sie auf die Schaltfläche „Browse Catalog“, um die Oracle BI Publisher-Oberfläche zu öffnen.
Neues Datenmodell erstellen: Im BI Publisher-Katalog navigieren Sie zu einem geeigneten Ordner (z.B. „Shared Folders > Custom“). Klicken Sie auf das Dropdown-Menü „New“ und wählen Sie „Data Model“ aus.
SQL Query Data Set definieren: Im Datenmodell-Editor klicken Sie auf das '+' Symbol, um ein neues Data Set hinzuzufügen, und wählen Sie „SQL Query“ aus der Liste.
Data Set konfigurieren: Im Dialogfeld „New Data Set“ geben Sie einen Namen wie P2P_Invoice_Events an. Wählen Sie die entsprechende Data Source, die typischerweise ApplicationDB_FSCM für Finanzdaten ist. Stellen Sie sicher, dass der Typ von SQL auf Standard SQL eingestellt ist.
SQL Query eingeben: Kopieren Sie die vollständige SQL, die im Abschnitt query dieses Dokuments bereitgestellt wird, und fügen Sie sie in das Textfeld „SQL Query“ ein.
Parameter definieren: Die Abfrage verwendet Parameter zur Filterung. In den Eigenschaften des Data Models erstellen Sie drei Parameter: p_start_date, p_end_date und p_bu_name. Setzen Sie deren Datentypen auf „String“. Der Benutzer wird diese Werte beim Ausführen des Berichts angeben, z.B. '2023-01-01' für Daten und den spezifischen Namen der Geschäftseinheit.
Datenmodell speichern: Speichern Sie das Datenmodell in Ihrem benutzerdefinierten Ordner. Sie können Beispieldaten anzeigen, indem Sie auf die Registerkarte 'Data' klicken und Werte für die von Ihnen erstellten Parameter eingeben.
Bericht erstellen: Navigieren Sie zurück zum Katalog, klicken Sie auf das Dropdown-Menü „New“ und wählen Sie „Report“ aus. Im Berichterstellungs-Assistenten wählen Sie die Option 'Use Data Model' und suchen Sie das soeben gespeicherte Datenmodell.
Berichtslayout und Ausgabe konfigurieren: Im Berichts-Editor ist ein einfaches Tabellenlayout ausreichend. Der wichtigste Schritt ist die Konfiguration des Standardausgabeformats. Klicken Sie auf 'View a List' und stellen Sie sicher, dass CSV das Standardformat und das einzige aktivierte Format ist. Dies gewährleistet, dass die Ausgabe eine saubere, unformatierte Datendatei ist.
Bericht planen: Speichern Sie den Bericht. Sie können ihn nun bei Bedarf ausführen oder, für eine bessere Leistung, zur Ausführung außerhalb der Spitzenzeiten planen. Der Zeitplan kann so konfiguriert werden, dass die CSV-Ausgabe an ein bestimmtes Ziel, wie z.B. den Universal Content Management (UCM) Server, geliefert wird, von wo aus sie zum Upload abgerufen werden kann.
Daten exportieren und vorbereiten: Sobald der Berichtsauftrag abgeschlossen ist, laden Sie die resultierende CSV-Datei herunter. Überprüfen Sie, ob die Spaltenüberschriften den erforderlichen Attributen (InvoiceNumber, ActivityName, EventTime, etc.) entsprechen, bevor Sie sie in das Process Mining Tool hochladen.

Konfiguration

Datenquelle: Die Abfrage muss in der Fusion Financials Anwendungsdatenbank ausgeführt werden, typischerweise über die ApplicationDB_FSCM JNDI-Datenquelle in BI Publisher verbunden.
Parameter: Das Datenmodell sollte mit den folgenden Parametern konfiguriert werden, um eine flexible Datenextraktion zu ermöglichen:
- p_start_date: Das Startdatum für den Extraktionszeitraum im Format 'YYYY-MM-DD'.
- p_end_date: Das Enddatum für den Extraktionszeitraum im Format 'YYYY-MM-DD'.
- p_bu_name: Der Name der Geschäftseinheit (Buchungskreis), um die Daten zu filtern. Verwenden Sie ein Platzhalterzeichen wie '%' für die Extraktion aller Geschäftseinheiten.
Datumsbereich: Für die erstmalige Extraktion wird empfohlen, einen Datumsbereich von 3 bis 6 Monaten zu verwenden. Dies gewährleistet ein Gleichgewicht zwischen einem repräsentativen Datensatz und der Verwaltung der Extraktionsleistung.
Leistungsaspekte: Das Extrahieren von Daten für lange Zeiträume oder für alle Geschäftseinheiten gleichzeitig kann ressourcenintensiv sein und zu Timeouts führen. Es wird empfohlen, große Extraktionen in kleineren, sequenziellen Stapeln (z.B. Monat für Monat) durchzuführen oder sie außerhalb der Spitzenzeiten zu planen.
Voraussetzungen: Der Benutzer, der den Bericht erstellt und ausführt, benötigt eine Rolle mit Berechtigungen für den Zugriff auf das BI Publisher Tool (z.B. BI Administrator) und die erforderlichen Datensicherheitsberechtigungen, um die zugrunde liegenden Kreditorenbuchhaltungstabellen (AP_INVOICES_ALL, AP_PAYMENTS_ALL, etc.) für die Zielgeschäftseinheiten anzuzeigen.

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: Stellen Sie sicher, dass Python 3.6+ auf Ihrem System installiert ist, zusammen mit den Bibliotheken requests und pandas. Sie können diese mit pip installieren: pip install requests pandas.
Oracle Fusion API-Einrichtung: Navigieren Sie in Ihrer Oracle Fusion-Instanz zur Security Console. Erstellen Sie eine neue vertrauliche Anwendung, um API-Zugriff zu erhalten. Notieren Sie sich die zugewiesene Client ID und das Client Secret. Stellen Sie sicher, dass der Anwendungsbenutzer die erforderlichen Rollen zum Lesen von Rechnungs- und Zahlungsdaten hat, wie z.B. die Rolle Financials - Payables Invoice Inquiry Duty.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, z.B. extract_fusion_invoices.py. Öffnen Sie die Datei und füllen Sie die Platzhaltervariablen am Anfang des Skripts aus. Dazu gehören CLIENT_ID, CLIENT_SECRET, TOKEN_URL, FUSION_HOST, START_DATE und END_DATE. Die FUSION_HOST sollte die Basis-URL für Ihre Oracle Cloud-Anwendungen sein.
Extraktionszeitraum festlegen: Ändern Sie die Variablen START_DATE und END_DATE, um das Zeitfenster für die Datenextraktion zu definieren. Es wird empfohlen, mit einem kleineren Zeitraum, z.B. einem Monat, zu beginnen, um das Skript zu testen und die Ausgabe zu überprüfen.
Skript ausführen: Führen Sie das Skript von Ihrer Befehlszeile oder Ihrem Terminal aus, indem Sie in das Verzeichnis navigieren und python extract_fusion_invoices.py eingeben. Das Skript authentifiziert sich, ruft die Daten ab und zeigt Fortschrittsmeldungen in der Konsole an.
Authentifizierungsprozess: Das Skript sendet zunächst eine Anfrage mit Ihren Client-Anmeldeinformationen an den Oracle Identity Provider (TOKEN_URL), um ein OAuth-Zugriffstoken zu erhalten. Dieses Token wird dann im Header aller nachfolgenden API-Anfragen eingefügt, um sich bei der Fusion Financials API zu authentifizieren.
Datenabruf und Paginierung: Das Skript fragt den invoices REST API-Endpunkt ab und ruft Datensätze ab, die innerhalb Ihres angegebenen Datumsbereichs erstellt wurden. Es handhabt die Paginierung automatisch, indem es das hasMore-Flag in der API-Antwort überprüft und nachfolgende Anfragen mit einem aktualisierten offset-Parameter stellt, bis alle Rechnungsdaten abgerufen wurden.
Detaillierter Datenabruf: Für jede abgerufene Rechnung führt das Skript zusätzliche API-Aufrufe durch, um zugehörige Details abzurufen. Es fragt den /child/holds-Endpunkt nach Halte- und Freigabeinformationen und den /payments-Endpunkt (gefiltert nach Rechnungsnummer), um Zahlungsdaten zu sammeln.
Event Log-Generierung: Die Kernlogik des Skripts verarbeitet die Roh-JSON-Daten von der API. Es prüft auf bestimmte Daten, Status und untergeordnete Datensätze, um unterschiedliche Zeilen für jede der 15 erforderlichen Geschäftsaktivitäten zu generieren. Zum Beispiel erzeugt das Vorhandensein eines CancelledDate ein 'Invoice Canceled'-Ereignis.
Ausgabe überprüfen: Sobald das Skript abgeschlossen ist, wird eine Datei namens invoice_event_log.csv im selben Verzeichnis erstellt. Öffnen Sie diese CSV-Datei mit einer Tabellenkalkulationsanwendung, um die Daten zu überprüfen. Prüfen Sie, ob alle erforderlichen Spalten (InvoiceNumber, ActivityName, EventTime) und empfohlenen Attribute vorhanden sind.
Für den Upload vorbereiten: Stellen Sie sicher, dass die Spaltenüberschriften in der CSV-Datei mit den erforderlichen Attributnamen übereinstimmen. Es ist normalerweise keine weitere Formatierung erforderlich. Die Datei ist nun bereit, in Ihr Process Mining Tool hochgeladen zu werden.

Konfiguration

Authentifizierungsdaten: Eine Client ID und ein Client Secret einer vertraulichen Anwendung, die in der Oracle Fusion Security Console registriert ist, sind erforderlich. Die Token URL für Ihre Identitätsdomäne muss ebenfalls angegeben werden.
API-Host-URL: Die Variable FUSION_HOST muss auf die Basis-URL Ihrer Oracle Fusion Instanz gesetzt werden, zum Beispiel https://[your-instance].fa.us2.oraclecloud.com.
Datumsbereich: Die Variablen START_DATE und END_DATE sind entscheidend für die Steuerung des Extraktionsumfangs. Es wird empfohlen, für eine erste Analyse 3 bis 6 Monate an Daten zu extrahieren, um ein Gleichgewicht zwischen Datenvolumen und Leistung sicherzustellen.
Verwendete API-Endpunkte: Das Skript interagiert hauptsächlich mit den API-Endpunkten fscmRestApi/resources/11.13.18.05/invoices und fscmRestApi/resources/11.13.18.05/payments. Es verwendet auch die Unterressource /invoices/{InvoiceId}/child/holds.
Paginierungslimit: Die Variable LIMIT im Skript steuert, wie viele Datensätze pro API-Anfrage abgerufen werden. Der Standardwert ist 100. Ein höherer Wert kann die Anzahl der API-Aufrufe reduzieren, aber den Speicherverbrauch pro Anfrage erhöhen. Ein niedrigerer Wert kann notwendig sein, wenn Timeouts auftreten.
Erforderliche Berechtigungen: Das Benutzerkonto, das mit den API-Anmeldeinformationen verknüpft ist, benötigt Lesezugriff auf Kreditorenrechnungen, Rechnungsblockierungen, Zahlungen und Lieferanteninformationen. Die Rolle Payables Invoice Inquiry Duty bietet typischerweise ausreichende 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()

Ihr Daten-Template für die Rechnungsverarbeitung im Einkauf zu Zahlung

Ihr Daten-Template für die Rechnungsverarbeitung im Einkauf zu Zahlung

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsattribute

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsaktivitäten

Extraktionsleitfäden

Oracle BI Cloud Connector (BICC) `Bulk Data Export`

Schritte

Konfiguration

a Beispielabfrage config

Oracle BI Publisher Bericht mit benutzerdefiniertem SQL-Datenmodell

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript-Extraktion mittels Fusion Financials REST API

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Optimieren Sie jetzt Ihre P2P-Rechnungsverarbeitung für 30% schnellere Zyklen

Ihr Daten-Template für die Rechnungsverarbeitung im Einkauf zu Zahlung

Ihr Daten-Template für die Rechnungsverarbeitung im Einkauf zu Zahlung

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsattribute

Beschaffung bis zur Zahlung – Rechnungsverarbeitungsaktivitäten

Extraktionsleitfäden

Oracle BI Cloud Connector (BICC) `Bulk Data Export`

Schritte

Konfiguration

a Beispielabfrage config

Oracle BI Publisher Bericht mit benutzerdefiniertem SQL-Datenmodell

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript-Extraktion mittels Fusion Financials REST API

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Optimieren Sie jetzt Ihre P2P-Rechnungsverarbeitung für 30% schnellere Zyklen