> Kontinuierliche Prozessverbesserung > Purchase to Pay Anforderung > Oracle Fusion Financials > Daten Template

Ihr Daten-Template für Purchase-to-Pay-Anforderungen

Oracle Fusion Financials

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Purchase-to-Pay-Anforderungen(22) Aktivitäten bei Purchase-to-Pay-Anforderungen(12) Anleitungen zur Datenextraktion(4)

Ihr Daten-Template für Purchase-to-Pay-Anforderungen

Dieses Template zeigt Ihnen, welche Daten Sie für die Analyse Ihres Purchase-to-Pay-Anforderungsprozesses erfassen sollten. Es enthält die wichtigsten Attribute und Aktivitäten sowie praktische Hinweise zum Extrahieren der Daten aus Oracle Fusion Financials. Damit können Sie Ihr Event Log für aussagekräftiges Process Mining vorbereiten.

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 Purchase-to-Pay-Anforderungen

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Purchase-to-Pay-Anforderungen umfassend zu analysieren.

5 Erforderlich 7 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die Bezeichnung des Geschäftsereignisses, das zu einem bestimmten Zeitpunkt im Bestellanforderungsprozess eingetreten ist.
Beschreibung Die Aktivität bezeichnet einen einzelnen Schritt oder Meilenstein im Lebenszyklus einer Bestellanforderung. Beispiele sind „Bestellanforderung erstellt“, „Genehmigungsschritt genehmigt“ oder „Bestellung erstellt“. Diese Aktivitäten werden aus Statusänderungen, Benutzeraktionen oder Systemereignissen abgeleitet, die in den Audit-Protokollen oder Transaktionstabellen des Quellsystems erfasst sind. Dieses Attribut ist unverzichtbar für den Aufbau der Prozesslandkarte, die den Ablauf der Bestellanforderungen visualisiert. Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten zeigt häufige Prozesspfade, Engpässe, Nacharbeitsschleifen und Abweichungen von der Standardvorgehensweise. Warum das wichtig ist Dieses Attribut bildet das Rückgrat der Prozesslandkarte und ermöglicht es, den Workflow der Bestellanforderung zu visualisieren und zu analysieren. Woher beziehen Abgeleitet aus Statusänderungen in Tabellen wie POR_REQUISITION_HEADERS_ALL, aus der Transaktionshistorie oder aus Workflow-Audit-Trails wie FA_FUSION_SOAINFRA.WFTASK. Beispiele Bestellanforderung erstelltGenehmigungsschritt genehmigtBestellanforderung abgelehntBestellung erstellt
	Ereigniszeitpunkt EventTime	Der Timestamp, der angibt, wann die Aktivität stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt erfasst Datum und Uhrzeit, zu denen eine bestimmte Aktivität stattgefunden hat. Dieser Timestamp ist entscheidend, um Ereignisse innerhalb eines Case chronologisch zu ordnen. Er stammt aus Erstellungs- und Aktualisierungsdaten oder aus Zeitstempeln bestimmter Aktionen im System. In der Analyse dient der Ereigniszeitpunkt zur Berechnung aller zeitbezogenen Kennzahlen, etwa der Zykluszeiten zwischen Aktivitäten, der Wartezeiten und der gesamten Case-Dauer. Er ist wichtig, um Engpässe zu erkennen, die Leistung anhand von SLAs zu messen und den zeitlichen Verlauf des Bestellanforderungsprozesses zu verstehen. Warum das wichtig ist Dieses Attribut ist unverzichtbar, um zeitbezogene KPIs zu berechnen, Ereignisse korrekt zu ordnen und Prozessleistung sowie Engpässe zu analysieren. Woher beziehen Der Wert stammt in der Regel aus einer Spalte wie „LAST_UPDATE_DATE“ oder „CREATION_DATE“, die der Transaktion oder Statusänderung zugeordnet ist. Solche Spalten finden sich häufig in Tabellen wie POR_REQUISITION_HEADERS_ALL oder in Workflow-Historientabellen. Beispiele 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	Purchase Requisition ID PurchaseRequisitionId	Die eindeutige Kennung einer Bestellanforderung. Sie dient als Case-ID des Prozesses.
Beschreibung Die Bestellanforderungs-ID ist die zentrale Kennung, über die alle Aktivitäten zu einer bestimmten Anfrage nach Waren oder Dienstleistungen verknüpft werden. Beim Anlegen erhält jede Bestellanforderung eine eindeutige ID, die während ihres gesamten Lebenszyklus unverändert bleibt. Im Process Mining dient dieses Attribut dazu, alle zugehörigen Ereignisse, etwa das Anlegen, Einreichen, die einzelnen Genehmigungsschritte und den abschließenden Abschluss, zu einem Case zusammenzufassen. So lässt sich der gesamte Ablauf der Bestellanforderung analysieren. Prozesslandkarten können visualisiert, Durchlaufzeiten berechnet und Varianten für einzelne Anforderungen untersucht werden. Warum das wichtig ist Dieses grundlegende Attribut bildet die Basis, um den Lebenszyklus einer Bestellanforderung von Anfang bis Ende nachzuverfolgen. Es ermöglicht Analysen auf Case-Ebene und die Berechnung von KPIs. Woher beziehen Dieses Attribut ist in der Regel der Primärschlüssel in der Kopfdatentabelle der Bestellanforderungen, zum Beispiel POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID in Oracle Fusion Financials. Beispiele 100234810023491002350
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Datenaktualisierung aus dem Quellsystem.
Beschreibung Dieses Attribut gibt Datum und Uhrzeit der letzten Datenextraktion aus Oracle Fusion Financials an. Es gilt für den gesamten Datensatz und nicht für einzelne Ereignisse. Anhand dieser Information können Analysten die Aktualität der Daten beurteilen und feststellen, wann die neuesten Transaktionen einbezogen wurden. Als wichtige Metadaten unterstützt sie die Berichterstellung in Dashboards und stellt sicher, dass Analysen auf aktuellen Informationen beruhen. Warum das wichtig ist Informiert Benutzer darüber, wie aktuell die Daten sind, damit Analysen relevant bleiben und auf den neuesten verfügbaren Informationen beruhen. Woher beziehen Dieser Timestamp wird während der Datenextraktion erzeugt und gespeichert, in der Regel durch das ETL-Tool oder die Datenpipeline. Beispiele 2023-10-27T02:00:00Z
	Quellsystem SourceSystem	Das Informationssystem, aus dem diese Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Prozessdaten an. In diesem Datenmodell lautet der Wert durchgehend „Oracle Fusion Financials“. In Umgebungen mit mehreren ERP- oder integrierten Systemen ist dieses Feld wichtig für die Datenherkunft, die Fehlerbehebung und die Sicherung der Datenqualität. Es gibt an, welches System für die analysierten Prozessereignisse als Quelle der Wahrheit dient. Warum das wichtig ist Gibt wichtigen Aufschluss über die Herkunft der Daten. Das ist für die Data Governance und die Integration von Daten aus mehreren Systemen entscheidend. Woher beziehen Dieser statische Wert wird während der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion Financials
	Ablehnungsgrund RejectionReason	Der Grund, den ein Genehmiger angibt, wenn eine Bestellanforderung oder ein Genehmigungsschritt abgelehnt wird.
Beschreibung Wird eine Bestellanforderung abgelehnt, gibt der Genehmiger in der Regel einen Grund an, indem er einen Eintrag aus einer vorgegebenen Liste auswählt oder einen Freitext eingibt. Dieses Attribut erfasst die Begründung. Es ist entscheidend, um die Ursachen von Prozessfehlern zu analysieren. Das Dashboard „Trends bei Änderungen und Ablehnungen“ zeigt damit, warum Bestellanforderungen abgelehnt werden. Die Analyse der Ablehnungsgründe macht häufige Probleme sichtbar, etwa falsche Kontierung, Budgetüberschreitungen oder Verstöße gegen Richtlinien. Diese lassen sich anschließend durch Schulungen oder Systemkontrollen angehen. Warum das wichtig ist Zeigt direkt, warum Bestellanforderungen abgelehnt werden. So können Sie gezielt Nacharbeit reduzieren und den Anteil der durchgängig verarbeiteten Anforderungen erhöhen. Woher beziehen Stammt aus Workflow-Kommentaren oder speziellen Feldern für Ablehnungsgrundcodes im Workflow-Audit-Trail, möglicherweise aus Tabellen zu FA_FUSION_SOAINFRA.WFTASK oder der zugehörigen Kommentarablage. Beispiele Falsches SachkontoBudget der Kostenstelle überschrittenNicht bevorzugten Lieferanten ausgewähltDoppelte Anforderung
	Abteilung DepartmentName	Die Fachabteilung, der der Anforderer angehört.
Beschreibung Dieses Attribut gibt die Organisationseinheit der Person an, die die Bestellanforderung erstellt hat, zum Beispiel „Finanzen“, „IT“ oder „Marketing“. In der Regel wird es aus dem Benutzerprofil des Anforderers im HR-System abgeleitet. Die Analyse nach Abteilung ist eine gängige Möglichkeit, Prozessdaten zu segmentieren. Sie zeigt abteilungsspezifische Muster, etwa höhere Ablehnungsquoten oder längere Durchlaufzeiten, und liefert damit eine Grundlage für gezielte Prozessverbesserungen. Für das Dashboard „Kennzahlen zur Leistung von Anforderern“ ist dieses Attribut eine wichtige Dimension. Warum das wichtig ist Ermöglicht die Prozessanalyse nach Geschäftseinheit und macht abteilungsspezifische Muster, Leistungsunterschiede und Compliance-Probleme sichtbar. Woher beziehen Wird in der Regel aus dem Profil des Anforderers abgeleitet. Dazu ist häufig eine Verknüpfung der Bestellanforderungstabelle mit einer HR- oder Benutzerverzeichnistabelle erforderlich, die Abteilungsinformationen enthält. Beispiele InformationstechnologieFinanzenBetriebMarketing
	Benötigt bis RequiredByDate	Das Datum, bis zu dem der Anforderer die Waren oder Dienstleistungen benötigt.
Beschreibung Der Anforderer gibt dieses Datum als Frist für den Erhalt der angeforderten Artikel an. Es dient im Beschaffungsprozess als internes Service-Level-Agreement-Ziel (SLA). Dieses Attribut bildet die Grundlage für das Dashboard „Leistung nach benötigtem Datum“ und den KPI „Einhaltungsquote des benötigten Datums“. Durch den Vergleich mit dem tatsächlichen Erstellungsdatum der Bestellung oder dem Wareneingangsdatum zeigt die Analyse, wie gut der Beschaffungsprozess den internen Bedarf erfüllt und wo systematische Verzögerungen auftreten. Warum das wichtig ist Entscheidend, um die Prozessleistung anhand interner Fristen zu messen und festzustellen, ob der Beschaffungsprozess den Geschäftsbedarf rechtzeitig erfüllt. Woher beziehen Wird üblicherweise auf Positionsebene der Bestellanforderung gespeichert, etwa in POR_REQUISITION_LINES_ALL in einem Feld wie „NEED_BY_DATE“. Beispiele 2023-11-012023-12-152024-01-31
	Gesamtbetrag der Bestellanforderung RequisitionTotalAmount	Der Gesamtwert der Bestellanforderung.
Beschreibung Dieses Attribut entspricht der Summe der Beträge aller Positionen einer Bestellanforderung. Es ist eine wichtige Kennzahl, um die finanzielle Bedeutung der einzelnen Anfragen einzuschätzen. Im Process Mining ermöglicht der Gesamtbetrag vielfältige Analysen. So können Sie beispielsweise Bestellanforderungen mit hohem Wert herausfiltern, für die häufig andere Genehmigungswege oder strengere Prüfungen gelten. Dashboards können zeigen, wie Prozesskennzahlen wie Durchlaufzeit oder Ablehnungsquote mit dem Wert der Bestellanforderung zusammenhängen. Warum das wichtig ist Liefert den finanziellen Kontext für wertbezogene Analysen. So lassen sich Prozessverbesserungen priorisieren und die Auswirkungen des Anforderungswerts auf den Prozess nachvollziehen. Woher beziehen Steht in der Kopfdatentabelle der Bestellanforderung, häufig in einem Feld wie REQUISITION_TOTAL in POR_REQUISITION_HEADERS_ALL. Alternativ lässt sich der Wert durch Addition der Positionsbeträge aus POR_REQUISITION_LINES_ALL berechnen. Beispiele 550.0012500.7599.99
	Geschäftseinheit BusinessUnit	Die Geschäftseinheit innerhalb der Organisation, zu der die Bestellanforderung gehört.
Beschreibung Die Geschäftseinheit bezeichnet eine eigenständige rechtliche oder funktionale Einheit des Unternehmens, für die die Bestellanforderung gestellt wird. Sie ist eine übergeordnete organisatorische Einheit im Vergleich zur Abteilung. Die Analyse nach Geschäftseinheit ermöglicht Leistungsvergleiche auf hoher Ebene zwischen verschiedenen Unternehmensbereichen. So kann die Geschäftsleitung erkennen, ob Prozessineffizienzen auf einzelne Bereiche begrenzt sind oder sich durch das gesamte Unternehmen ziehen und wo Verbesserungen ansetzen sollten. Die Geschäftseinheit ist eine wichtige Filterdimension für nahezu alle Dashboards und KPIs. Warum das wichtig ist Liefert den organisatorischen Kontext für Leistungsvergleiche und strategische Analysen verschiedener Unternehmensbereiche. Woher beziehen Dieses grundlegende Organisationsfeld in Oracle Fusion ist üblicherweise in der Kopfdatentabelle der Bestellanforderung verfügbar, etwa in POR_REQUISITION_HEADERS_ALL. Beispiele Geschäftseinheit NordamerikaGeschäftseinheit EuropaUnternehmenszentrale
	Name des Anforderers RequesterName	Der Name des Mitarbeitenden, der die Bestellanforderung erstellt und eingereicht hat.
Beschreibung Dieses Attribut gibt an, wer die Anfrage nach Waren oder Dienstleistungen gestellt hat. Die Information wird in der Regel zu Beginn des Prozesses erfasst, wenn die Bestellanforderung angelegt wird. Die Analyse der Prozessleistung nach Anforderer ist für das Dashboard „Kennzahlen zur Leistung von Anforderern“ entscheidend. Sie zeigt, bei welchen Benutzern oder Gruppen zusätzlicher Schulungsbedarf bestehen könnte, etwa bei häufigen Änderungen oder Ablehnungen sowie langen Durchlaufzeiten ihrer Anforderungen. So wird der Prozess aus der Perspektive der beteiligten Mitarbeitenden sichtbar. Warum das wichtig ist Ermöglicht die Analyse der Leistung nach Anforderer. So lassen sich Schulungsbedarf erkennen und effiziente Benutzer oder Abteilungen identifizieren. Woher beziehen Stammt aus den Kopfdaten der Bestellanforderung. Dazu wird die ID des Anforderers häufig mit einer Mitarbeiter- oder Benutzerstammdatentabelle verknüpft. Suchen Sie in POR_REQUISITION_HEADERS_ALL nach Feldern wie „PREPARER_ID“ und verknüpfen Sie diese mit PER_ALL_PEOPLE_F. Beispiele John SmithJane DoeEmily Jones
	Status der Bestellanforderung RequisitionStatus	Der aktuelle oder endgültige Status der Bestellanforderung.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Bestellanforderung zu einem bestimmten Zeitpunkt oder ihr endgültiges Ergebnis an, zum Beispiel „Genehmigt“, „Abgelehnt“, „In Bearbeitung“ oder „Abgeschlossen“. Häufig werden daraus viele Aktivitäten im Event Log abgeleitet. Das Attribut ist entscheidend für das Dashboard „Übersicht über den Status der Bestellanforderungen“, das einen Überblick über die aktuelle Arbeitslast und den Rückstand bietet. Außerdem dient es zur Berechnung ergebnisbezogener KPIs wie der Ablehnungsquote, indem Cases mit einem bestimmten Endstatus herausgefiltert werden. Warum das wichtig ist Zeigt den aktuellen Status der Bestellanforderungen und dient dazu, die endgültigen Ergebnisse für KPI-Berechnungen zu bestimmen. Woher beziehen Steht in der Kopfdatentabelle der Bestellanforderung, üblicherweise in einem Feld wie „DOCUMENT_STATUS“ oder „APPROVAL_STATUS“ in POR_REQUISITION_HEADERS_ALL. Beispiele GENEHMIGTIN BEARBEITUNGABGELEHNTZURÜCKGEZOGEN
	Art der Bestellanforderung RequisitionType	Die Kategorie der Bestellanforderung, zum Beispiel eine Anfrage nach Waren oder Dienstleistungen.
Beschreibung Dieses Attribut klassifiziert die Bestellanforderung nach dem angeforderten Bedarf. Übliche Arten sind Waren, Dienstleistungen oder Investitionsausgaben. Die Art kann den erforderlichen Genehmigungs-Workflow und die Beschaffungsstrategie beeinflussen. In der Analyse dient die Art der Bestellanforderung als wichtige Dimension für Filter und Vergleiche. So lässt sich beispielsweise untersuchen, ob Dienstleistungsanforderungen länger genehmigt werden als Warenanforderungen. Das Attribut zeigt, ob sich Prozessverhalten und Engpässe je nach Art der Anfrage unterscheiden. Warum das wichtig ist Ermöglicht die Segmentierung der Analyse, um Unterschiede im Prozess für verschiedene Beschaffungsarten, etwa Waren und Dienstleistungen, zu erkennen. Woher beziehen Wird häufig durch die bei der Erstellung der Bestellanforderung ausgewählte Positionsart oder Kategorie bestimmt. Das Attribut kann in der Positionstabelle POR_REQUISITION_LINES_ALL gespeichert sein. Beispiele WarenDienstleistungenInvestitionsausgaben
	Artikelbeschreibung ItemDescription	Die Beschreibung des Produkts oder der Dienstleistung, die in einer Position der Bestellanforderung angefordert wird.
Beschreibung Dieses Attribut enthält die Textbeschreibung des zu beschaffenden Artikels. Sie liefert Einzelheiten zu den angeforderten Waren oder Dienstleistungen. Auch wenn die Beschreibung häufig unstrukturiert ist, bietet sie wertvollen Kontext für die Analyse. Mit Filtern lassen sich Bestellanforderungen für bestimmte Beschaffungsarten herausgreifen, die von der Art der Bestellanforderung nicht erfasst werden. So kann ein Analyst beispielsweise nach allen Anforderungen mit dem Begriff „Softwarelizenz“ suchen, um deren Prozessablauf und Durchlaufzeit zu untersuchen. Warum das wichtig ist Liefert detaillierte Informationen zum Beschaffungsgegenstand und ermöglicht eine genauere Filterung und Analyse bestimmter Waren oder Dienstleistungen. Woher beziehen Steht in der Positionstabelle POR_REQUISITION_LINES_ALL, beispielsweise in einem Feld wie ITEM_DESCRIPTION. Beispiele 15-Zoll-Laptop, 16 GB RAMBeratungsleistungen, Projekt Q4Jährliche Verlängerung der Softwarewartung
	Automatisiert IsAutomated	Ein Kennzeichen dafür, ob eine Aktivität automatisch vom System ausgeführt wurde.
Beschreibung Dieses Attribut kennzeichnet Prozessereignisse, die von einem Systembenutzer oder einem automatisierten Agenten statt von einem Menschen ausgeführt wurden. Beispiele sind systemgesteuerte Statusänderungen oder automatische Genehmigungsschritte für Bestellungen mit geringem Wert. Die Analyse dieses Attributs zeigt den Automatisierungsgrad des Prozesses. Damit können Sie Geschwindigkeit und Effizienz automatisierter und manueller Schritte vergleichen und Möglichkeiten für weitere Automatisierung erkennen. Warum das wichtig ist Hilft, den Automatisierungsgrad des Prozesses zu messen und Möglichkeiten zur Automatisierung manueller Aufgaben zu erkennen. Woher beziehen Wird ermittelt, indem geprüft wird, ob der einer Aktivität zugeordnete Benutzer ein System- oder Servicekonto ist. Dafür ist eine Liste bekannter Systembenutzer-IDs erforderlich. Beispiele truefalse
	Benutzername UserName	Der Name des Benutzers, der eine bestimmte Aktivität ausgeführt hat, zum Beispiel ein Genehmiger oder Bearbeiter.
Beschreibung Während der Name des Anforderers die Person bezeichnet, die den Prozess angestoßen hat, gibt der Benutzername an, wer ein bestimmtes Ereignis im Prozess ausgeführt hat, etwa eine Genehmigung oder Ablehnung. Das ist besonders bei mehrstufigen Genehmigungs-Workflows wichtig, an denen mehrere Personen beteiligt sind. Dieses Attribut ist entscheidend, um Engpässe bei Genehmigungen zu analysieren und die Leistung einzelner Genehmiger oder Teams zu messen. Es unterstützt direkt das Dashboard „Engpässe im Genehmigungs-Workflow“, indem sich die Bearbeitungszeiten für jeden Benutzer in der Genehmigungskette untersuchen lassen. Warum das wichtig ist Gibt für jedes Ereignis die ausführende Person an. Das ist wichtig, um Übergabezeiten, die Leistung von Genehmigern und die Ressourcenzuweisung zu analysieren. Woher beziehen Stammt aus Workflow-Historien oder Audit-Trail-Tabellen wie FA_FUSION_SOAINFRA.WFTASK, in denen der Benutzer für den Abschluss jeder Aufgabe protokolliert wird. Beispiele David LeeSusan ChenMichael Brown
	Bestellnummer PurchaseOrderNumber	Die Kennung der Bestellung, die aus der genehmigten Bestellanforderung erstellt wurde.
Beschreibung Dieses Attribut verknüpft eine Bestellanforderung mit der daraus entstandenen Bestellung. Nach der vollständigen Genehmigung wird eine Bestellanforderung üblicherweise in eine oder mehrere Bestellungen umgewandelt, die an einen Lieferanten gesendet werden. Für die Analyse ist diese ID unverzichtbar, um den Prozess nach der Bestellanforderung weiterzuverfolgen. Sie ermöglicht die Berechnung des KPIs „Durchlaufzeit von Bestellanforderung bis Bestellung“ und unterstützt das Dashboard „Zykluszeit von Bestellanforderung bis Bestellung“. Außerdem lassen sich damit Daten zum Bestellanforderungsprozess mit den nachfolgenden Bestell- und Rechnungsprozessen kombinieren, um den Purchase-to-Pay-Prozess durchgängig zu analysieren. Warum das wichtig ist Verknüpft die Bestellanforderung mit der nachfolgenden Bestellung. So lassen sich die Zykluszeit bis zur Bestellung messen und der Prozess durchgängig analysieren. Woher beziehen Diese Information wird gespeichert, sobald eine Bestellung erstellt wird. Sie lässt sich üblicherweise über die Verweise auf die zugrunde liegende Bestellanforderung in den Verteilungstabellen der Bestellung ermitteln, etwa in PO_DISTRIBUTIONS_ALL, die auf die Position der Bestellanforderung verweist. Beispiele PO-2023-5832PO-2023-5833PO-2023-5834
	Durchgängig verarbeitet IsStraightThrough	Ein Kennzeichen dafür, ob die Bestellanforderung ohne Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dieses berechnete Kennzeichen identifiziert Bestellanforderungen, die vom Einreichen bis zur Genehmigung ohne Nacharbeitsschleifen wie Änderungen oder Ablehnungen durchlaufen wurden. Es steht für einen fehlerfreien Prozessablauf bei einem einzelnen Case. Dieses Attribut bildet die Grundlage für den KPI „Anteil durchgängig verarbeiteter Bestellanforderungen“. Die Analyse typischer Merkmale solcher Anforderungen, etwa Abteilungen, Anforderer oder Arten, kann bewährte Vorgehensweisen und Automatisierungsmöglichkeiten aufzeigen. Umgekehrt hilft die Analyse nicht durchgängig verarbeiteter Anforderungen, die wichtigsten Ursachen für Ineffizienzen zu erkennen. Warum das wichtig ist Misst die Prozesseffizienz direkt und bildet die Grundlage für den KPI zum Anteil durchgängig verarbeiteter Bestellanforderungen. So lassen sich Ursachen für Nacharbeit erkennen. Woher beziehen Dieses Attribut wird während der Datentransformation berechnet. Ein Case erhält den Wert „true“, wenn keine Aktivitäten „Bestellanforderung geändert“ oder „Genehmigungsschritt abgelehnt“ vorhanden sind. Beispiele truefalse
	Genehmigungs-Workflow-Pfad ApprovalWorkflowPath	Die festgelegte Reihenfolge der Genehmiger oder Genehmigungsgruppen für die Bestellanforderung.
Beschreibung Dieses Attribut legt anhand der Unternehmensrichtlinien den erwarteten Standardprozess für die Genehmigung einer Bestellanforderung fest. Dabei werden Faktoren wie Betrag, Art und Abteilung berücksichtigt. Es bildet den Sollprozess ab. Der Genehmigungs-Workflow-Pfad ist grundlegend für Compliance und Konformitätsprüfungen. Er unterstützt direkt das Dashboard „Compliance- und Abweichungsanalyse“ sowie den KPI „Konformitätsindex der Bestellanforderungen“, indem sich die tatsächlich durchlaufenen Genehmigungsschritte mit dem vorgeschriebenen Pfad vergleichen lassen. Abweichungen können auf Richtlinienverstöße oder ineffiziente Abläufe hindeuten. Warum das wichtig ist Ermöglicht die Konformitätsprüfung, indem der tatsächliche Prozessablauf mit der vorgeschriebenen Genehmigungshierarchie verglichen wird. So werden nicht konforme Bestellanforderungen sichtbar. Woher beziehen Diese Information wird in der Oracle Fusion BPM Worklist oder der Approval Management Engine (AMX) konfiguriert. Den festgelegten Pfad für jede Bestellanforderung zu extrahieren, kann komplex sein und Abfragen von Konfigurationstabellen erfordern. Beispiele Manager > Direktor > FinanzvorstandKostenstellenverantwortlicher > IT-SicherheitManager > Abteilungsleitung
	Lieferantenname SupplierName	Der Name des vorgeschlagenen oder vorausgewählten Lieferanten für die Waren oder Dienstleistungen.
Beschreibung Dieses Attribut gibt den Lieferanten an, bei dem die Waren oder Dienstleistungen voraussichtlich beschafft werden. Der Anforderer kann den Lieferanten vorschlagen oder das System bestimmt ihn anhand von Katalogen oder bestehenden Vereinbarungen. Die Analyse nach Lieferant kann wichtige Beschaffungsmuster aufzeigen. So lässt sich beispielsweise feststellen, ob Bestellanforderungen für bestimmte Lieferanten länger bis zur Genehmigung brauchen oder häufiger abgelehnt werden. Diese Informationen können für das Lieferantenmanagement und die Beschaffungsstrategie hilfreich sein. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach Lieferant und kann die Beschaffungsstrategie sowie das Lieferantenmanagement unterstützen. Woher beziehen Steht in der Positionstabelle POR_REQUISITION_LINES_ALL und ist häufig über VENDOR_ID mit einer Lieferantenstammdatentabelle wie POZ_SUPPLIERS verknüpft. Beispiele Bürobedarf GmbH.Global Tech SolutionsCreative Marketing Agency
	Währung CurrencyCode	Der Währungscode für den Betrag der Bestellanforderung, zum Beispiel USD oder EUR.
Beschreibung Dieses Attribut gibt an, in welcher Währung der Gesamtbetrag der Bestellanforderung ausgewiesen ist. In global tätigen Unternehmen können Bestellanforderungen in verschiedenen Währungen erstellt werden. Für die korrekte Interpretation und Aggregation von Finanzdaten ist diese Information unverzichtbar. Bei Analysen mit Geldbeträgen muss der Währungscode berücksichtigt werden, damit Beträge korrekt verglichen werden können. Dazu können Sie nach einer einzelnen Währung filtern oder alle Beträge in eine gemeinsame Währung umrechnen. Warum das wichtig ist Sorgt für korrekte Finanzanalysen und Berichte, insbesondere in multinationalen Unternehmen mit mehreren Währungen. Woher beziehen Steht üblicherweise neben den Betragsfeldern in der Kopfdatentabelle der Bestellanforderung, zum Beispiel in POR_REQUISITION_HEADERS_ALL. Beispiele USDEURGBPJPY
	Wurde geändert IsAmendedFlag	Ein boolesches Kennzeichen, das den Wert „true“ hat, wenn die Bestellanforderung mindestens einmal geändert wurde.
Beschreibung Dieses berechnete Attribut gibt an, ob eine Bestellanforderung nach dem ersten Einreichen geändert wurde. Es wird anhand der Prozesshistorie ermittelt, indem geprüft wird, ob die Aktivität „Bestellanforderung geändert“ vorhanden ist. Das Kennzeichen vereinfacht Analysen und KPI-Berechnungen. Es fließt direkt in die Berechnung des KPIs „Änderungsquote der Bestellanforderungen“ ein und hilft, Cases zu erkennen, die nicht durchgängig verarbeitet wurden. Außerdem lassen sich Prozesskennzahlen geänderter und unveränderter Bestellanforderungen einfach filtern und vergleichen. Warum das wichtig ist Vereinfacht die Berechnung der Änderungsquote und ermöglicht den einfachen Vergleich geänderter und unveränderter Bestellanforderungen. Woher beziehen Dieses Attribut ist im Quellsystem nicht vorhanden. Es wird während der Datentransformation anhand von Änderungsaktivitäten im Event Log berechnet. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten bei Purchase-to-Pay-Anforderungen

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess für Purchase-to-Pay-Anforderungen präzise zu entdecken.

6 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Bestellanforderung abgelehnt	Bezeichnet die endgültige Ablehnung der Bestellanforderung, durch die der Prozess für diesen Antrag beendet wird. Das Ereignis lässt sich daran erkennen, dass der Gesamtstatus der Bestellanforderung auf „Rejected“ gesetzt wird.
Warum das wichtig ist Diese Aktivität beendet einen erfolglosen Antrag. Die Analyse solcher Fälle ist wichtig, um die KPI „Ablehnungsquote von Bestellanforderungen“ und die Gründe für Ablehnungen zu verstehen. Woher beziehen Das Ereignis wird erkannt, wenn sich der Dokumentstatus in der Tabelle POR_REQUISITION_HEADERS_ALL in „REJECTED“ ändert. Erfassung Ermitteln Sie den Timestamp, zu dem der Dokumentstatus erstmals auf „Rejected“ gesetzt wird. Ereignistyp inferred
	Bestellanforderung eingereicht	Bezeichnet die Aktion, mit der ein Benutzer die ausgefüllte Bestellanforderung in den Genehmigungsworkflow übermittelt. Das Ereignis wird erfasst, wenn sich der Status von „Incomplete“ oder „Draft“ in einen Status ändert, der eine ausstehende Genehmigung anzeigt.
Warum das wichtig ist Mit dieser Aktivität beginnt der Genehmigungszyklus. Sie ist ein wichtiger Meilenstein für die Messung der Genehmigungsdauer von Bestellanforderungen und der gesamten Durchlaufzeit. Woher beziehen Das Ereignis wird aus einer Statusänderung in der Tabelle POR_REQUISITION_HEADERS_ALL abgeleitet, zum Beispiel wenn der Status auf „PENDING APPROVAL“ wechselt. Das Einreichungsdatum ist häufig ebenfalls explizit gespeichert. Erfassung Ermitteln Sie den Timestamp, zu dem sich das Statusfeld des Dokuments erstmals in „Pending Approval“ ändert. Ereignistyp inferred
	Bestellanforderung erstellt	Kennzeichnet den Beginn des Einkaufsprozesses: Ein Benutzer speichert erstmals eine neue Bestellanforderung. Dieses Ereignis wird im System in der Regel als expliziter Datensatz mit dem zugehörigen Timestamp erfasst.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses für Bestellanforderungen. Eine Analyse der Zeit zwischen Erstellung und Einreichung kann Verzögerungen bei der Formalisierung von Anforderungen aufdecken. Woher beziehen Dieses Ereignis wird in der Tabelle POR_REQUISITION_HEADERS_ALL erfasst. Als Zeitpunkt dient der Wert in der Spalte creation_date, wenn eine neue Requisition ID angelegt wird. Erfassung Verwenden Sie den Erstellungs-Timestamp des Datensatzes für den Kopf der Bestellanforderung. Ereignistyp explicit
	Bestellanforderung genehmigt	Kennzeichnet die endgültige Genehmigung der Bestellanforderung, nachdem sie alle Schritte des Workflows erfolgreich durchlaufen hat. Das Ereignis lässt sich daran erkennen, dass sich der Gesamtstatus der Bestellanforderung in „Approved“ ändert.
Warum das wichtig ist Dieser wichtige Meilenstein zeigt an, dass der Einkauf mit der Bearbeitung beginnen kann. Er markiert das Ende der Genehmigungsdauer für die Bestellanforderung. Woher beziehen Das Ereignis wird erkannt, wenn sich das Statusfeld des Dokuments in der Tabelle POR_REQUISITION_HEADERS_ALL in „APPROVED“ ändert. Das Datum dieser Statusänderung ist der Ereigniszeitpunkt. Erfassung Ermitteln Sie den Timestamp, zu dem der Dokumentstatus erstmals auf „Approved“ gesetzt wird. Ereignistyp inferred
	Bestellanforderung geschlossen	Kennzeichnet den endgültigen Abschluss des Lebenszyklus einer Bestellanforderung. Alle Positionen wurden erfüllt, zum Beispiel in Bestellungen umgewandelt, oder storniert. Das Ereignis lässt sich aus einer abschließenden Statusänderung ableiten.
Warum das wichtig ist Dies ist das reguläre End-Event für einen erfolgreich abgeschlossenen Prozess. Es bestätigt, dass die Bestellanforderung vollständig bearbeitet wurde und keine weiteren Schritte erforderlich sind. Woher beziehen Das Ereignis wird erkannt, wenn sich der Status des Kopfdatensatzes der Bestellanforderung in POR_REQUISITION_HEADERS_ALL in „CLOSED“ ändert. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Dokumentstatus der Bestellanforderung in „Closed“ ändert. Ereignistyp inferred
	Bestellung erstellt	Dieses Ereignis tritt ein, wenn aus einer genehmigten Position der Bestellanforderung eine Bestellung erstellt wird. Es verbindet den Prozess für Bestellanforderungen mit dem nachgelagerten Einkaufsprozess.
Warum das wichtig ist Dieser wichtige Meilenstein dient zur Messung der Durchlaufzeit von der Bestellanforderung bis zur Bestellung. Verzögerungen weisen auf Engpässe bei der Übergabe von der Genehmigung an den Einkauf hin. Woher beziehen Dieses Ereignis wird explizit erfasst. Die Verknüpfung zwischen Bestellanforderung und Bestellung ist in Tabellen wie PO_LINE_LOCATIONS_ALL gespeichert. Diese enthält einen Verweis auf die ID der ursprünglichen Bestellanforderungsposition. Erfassung Ermitteln Sie das Erstellungsdatum der Bestellung, die auf die angegebene Requisition ID verweist. Ereignistyp explicit
	Bestellanforderung geändert	Dieses Ereignis zeigt an, dass ein Benutzer eine Bestellanforderung nach der ersten Einreichung geändert hat. Häufig muss der Genehmigungsprozess daraufhin erneut beginnen. Das Ereignis lässt sich anhand von Änderungen an wichtigen Datenfeldern oder einer neuen Version der Bestellanforderung erkennen.
Warum das wichtig ist Häufige Änderungen weisen auf Probleme mit der Datenqualität oder veränderte Anforderungen hin. Sie verursachen Nacharbeit und verzögern den Prozess. Dieses Ereignis fließt direkt in die KPI „Änderungsquote bei Bestellanforderungen“ ein. Woher beziehen Das Ereignis lässt sich anhand der Versionsnummern der Bestellanforderung oder einer Statusänderung zurück zu „Incomplete“ nach der Einreichung ableiten. Änderungen können auch in Änderungsprotokollen oder Audit-Tabellen erfasst sein. Erfassung Ermitteln Sie die Timestamps, zu denen nach der Einreichung neue Versionen derselben Requisition ID erstellt werden. Ereignistyp inferred
	Bestellanforderung zurückgezogen	Dieses Ereignis tritt ein, wenn der Anfordernde eine eingereichte Bestellanforderung zurückzieht oder storniert, bevor sie vollständig genehmigt wurde. In der Regel handelt es sich um eine explizite Benutzeraktion, die eine Statusänderung auslöst.
Warum das wichtig ist Die Erfassung zurückgezogener Bestellanforderungen hilft, Gründe für den vorzeitigen Abbruch zu erkennen, etwa geänderte geschäftliche Anforderungen oder Fehlerkorrekturen nach der Einreichung. Woher beziehen Das Ereignis wird aus einer Statusänderung zu „WITHDRAWN“ in der Tabelle POR_REQUISITION_HEADERS_ALL abgeleitet. Die Aktion wird im Aktionsverlauf der Bestellanforderung protokolliert. Erfassung Ermitteln Sie den Timestamp, zu dem der Status der Bestellanforderung auf „Withdrawn“ gesetzt wird. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Eine genehmigende Person lehnt die Bestellanforderung ab. In der Regel wird sie dadurch zur Korrektur an die erstellende Person zurückgesendet oder der Antrag beendet. Diese Aktion wird explizit im Workflow-Verlauf erfasst.
Warum das wichtig ist Diese Aktivität ist eine wesentliche Ursache für Nacharbeit und Verzögerungen. Die Analyse von Ablehnungen hilft, Compliance-Probleme, Budgetfragen oder unklare Begründungen zu erkennen. Woher beziehen Das Ereignis stammt aus dem Aktionsverlauf der Genehmigung für die Bestellanforderung. Das Workflow-System protokolliert eine Aktion „REJECT“ mit Timestamp. Erfassung Verwenden Sie den Timestamp der Aktion „REJECT“ aus dem Aktionsprotokoll des Workflows. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Bezeichnet die Genehmigung der Bestellanforderung durch eine einzelne genehmigende Person im ihr zugewiesenen Workflow-Schritt. Das Ereignis wird explizit im Genehmigungsverlauf protokolliert.
Warum das wichtig ist Die Erfassung einzelner Genehmigungsschritte bildet den tatsächlichen Genehmigungspfad ab und ermöglicht die Messung der Bearbeitungszeit auf jeder Ebene der Hierarchie. Woher beziehen Das Ereignis stammt aus dem Aktionsverlauf der Genehmigung für die Bestellanforderung. Dieser ist in der Regel in Workflow- (WF-) oder Human-Capital-Management-Tabellen (HCM) gespeichert, in denen die Genehmigungshierarchien verwaltet werden. Erfassung Verwenden Sie den Timestamp der Aktion „APPROVE“ aus dem Aktionsprotokoll des Workflows. Ereignistyp explicit
	Genehmigungsschritt gestartet	Kennzeichnet den Zeitpunkt, zu dem eine Bestellanforderung im Workflow einer bestimmten genehmigenden Person oder einer Genehmigungsgruppe zugewiesen wird. Das Ereignis wird im Transaktionsprotokoll der Workflow-Engine erfasst.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung der Wartezeit in jedem Genehmigungsschritt. Sie hilft, Engpässe durch bestimmte Genehmigende oder Genehmigungsebenen zu erkennen. Woher beziehen Die Daten stammen aus den Workflow-Tabellen von Oracle Fusion, in denen Aufgaben für Benutzer protokolliert werden. Verwendet wird der Zuweisungs-Timestamp der Genehmigungsaufgabe. Erfassung Verwenden Sie den Erstellungs-Timestamp der Aufgabe im Workflow-Verlauf der betreffenden Bestellanforderung. Ereignistyp explicit
	Genehmigungsschritt zurückgegeben	Eine genehmigende Person sendet die Bestellanforderung zur Ergänzung von Informationen oder für kleinere Korrekturen an die erstellende Person zurück, ohne sie formell abzulehnen. In der Regel wird diese Aktion explizit im Workflow-System erfasst.
Warum das wichtig ist Dieses Ereignis weist auf Klärungsbedarf hin und löst eine Nacharbeitsschleife aus, die den Durchlauf verlängert. Wenn Sie Rückgaben von Ablehnungen unterscheiden, erkennen Sie Reibungspunkte im Prozess genauer. Woher beziehen Das Ereignis stammt aus dem Aktionsverlauf der Genehmigung für die Bestellanforderung. Das Workflow-System protokolliert eine Aktion „RETURN“ oder eine vergleichbare Aktion mit Timestamp. Erfassung Verwenden Sie den Timestamp der Aktion „RETURN“ oder „Request for Information“ aus dem Workflow-Verlauf. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Zu „Reports and Analytics“ navigieren: Melden Sie sich bei Oracle Fusion Financials an. Öffnen Sie über das Menü „Navigator“ den Bereich „Tools“ und wählen Sie anschließend „Reports and Analytics“. Hier finden Sie die zentrale Arbeitsumgebung für Berichte.
Neue Analyse erstellen: Klicken Sie im Arbeitsbereich „Reports and Analytics“ auf „Create“ und wählen Sie im Dropdown-Menü „Analysis“. Der Editor für Oracle Transactional Business Intelligence (OTBI) wird in einem neuen Tab geöffnet.
Subject Area auswählen: Wählen Sie im nächsten Schritt eine Subject Area aus. Geben Sie in das Suchfeld „Procurement - Requisitions Real Time“ ein und wählen Sie den Eintrag aus der Liste aus. Diese Subject Area enthält die erforderlichen Daten für Ereignisse im Lebenszyklus einer Anforderung.
Analyse der Anforderungsereignisse erstellen: Für jedes einzelne Ereignis müssen Sie mehrere Abfragen zusammenführen. Da die OTBI-Oberfläche keine direkte UNION-ALL-Funktion für verschiedene Ereignistypen bietet, erstellen Sie einen einzelnen Bericht mit allen relevanten Datums- und Statusfeldern. Ziehen Sie im Tab „Criteria“ die im Abfrageabschnitt aufgeführten Spalten aus dem Bereich „Subject Areas“ links in den Bereich „Selected Columns“. Dazu gehören unter anderem Erstellungs-, Einreichungs- und Genehmigungsdatum sowie das Datum der Bestellerstellung.
Aktionsverlauf der Anforderung ergänzen: Um einzelne Genehmigungsschritte wie „Approved“, „Rejected“, „Returned“ und „Withdrawn“ zu erfassen, nehmen Sie Felder aus dem Ordner „Requisition Action History“ in der Subject Area auf. Ziehen Sie „Action Date“, „Action“ und „Performer“ in die ausgewählten Spalten.
Filter konfigurieren: Wechseln Sie zum Tab „Prompts“, um Filter für Ihre Analyse einzurichten. Ein Datumsbereich ist wichtig, um das Datenvolumen zu begrenzen. Erstellen Sie einen Filter für „Requisition Header“ > „Requisition Creation Date“ und legen Sie einen Zeitraum fest, zum Beispiel die letzten 6 Monate. Mit zusätzlichen Prompts für „Business Unit“ oder „Requester Name“ können Sie die Daten weiter eingrenzen.
Bericht ausführen und prüfen: Öffnen Sie den Tab „Results“, um die Analyse auszuführen und eine Vorschau der Daten anzuzeigen. Die Ausgabe ist eine breite Tabelle mit einer Zeile pro Anforderungsposition oder Genehmigungsaktion und mehreren Datums- und Statusspalten.
Rohdaten exportieren: Wenn Sie mit der Vorschau zufrieden sind, klicken Sie auf den Link „Export“, der sich üblicherweise unten auf der Ergebnisseite befindet. Wählen Sie als Format „Data“ > „CSV File“. Dadurch werden die Rohdaten aus Ihrer Analyse heruntergeladen.
Daten in ein Event-Log-Format umwandeln: Die exportierte CSV-Datei liegt in einem breiten Format vor. Verwenden Sie ein externes Werkzeug, etwa ein Python-Skript, Power Query in Excel oder ein anderes Datenaufbereitungstool, um die Daten umzuwandeln. Dabei werden die Datumsspalten in einer einzelnen Spalte „EventTime“ zusammengeführt und für jeden Ereignistyp eine passende Spalte „ActivityName“ angelegt, zum Beispiel „Requisition Created“ oder „Requisition Submitted“.
Datei fertigstellen und für den Upload vorbereiten: Stellen Sie nach der Umwandlung sicher, dass die Datei die erforderlichen Spalten enthält: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate. Speichern Sie das fertige Event Log als CSV-Datei. Anschließend können Sie es in ProcessMind hochladen.

Konfiguration

Subject Area: Verwenden Sie vorzugsweise „Procurement - Requisitions Real Time“. Sie enthält die wichtigsten Informationen zu Anforderungskopf, Positionen, Kontierungen und Genehmigungsverlauf.
Datumsbereich: Begrenzen Sie das Datenvolumen und verbessern Sie die Leistung mit einem obligatorischen Datumsfilter. Ein Filter für „Requisition Header“ > „Requisition Creation Date“ auf die letzten 3 bis 6 Monate ist ein guter Ausgangspunkt.
Wichtige Filter: Ergänzen Sie gegebenenfalls Filter für „Requisition Header“ > „Business Unit“ und „Requisition Header“ > „Requisition Status“. So können Sie die Extraktion auf relevante Organisationseinheiten beschränken und nicht benötigte Statuswerte wie „Canceled“ ausschließen.
Spaltenauswahl: Wählen Sie die Spalten für Ihre Analyse gezielt aus. Zu viele Spalten, insbesondere aus verschiedenen Ordnern (Dimensionen), können die Leistung beeinträchtigen. Nehmen Sie nur die Felder auf, die für das Event Log erforderlich sind.
Berechtigungen: Das Benutzerkonto für die Extraktion benötigt eine Rolle mit den erforderlichen Berechtigungen für den Arbeitsbereich „Reports and Analytics“ und die Subject Area „Procurement - Requisitions Real Time“. Typische Rollen mit diesen Berechtigungen sind „BI Author“ und „Procurement Analyst“.

Beispielabfrage sql

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

Schritte

Melden Sie sich mit einem Benutzerkonto mit BI-Author- oder vergleichbaren Berechtigungen bei Oracle Fusion Financials an.
Öffnen Sie den Arbeitsbereich „Reports and Analytics“, indem Sie auf das Symbol „Navigator“ und anschließend auf „Tools“ > „Reports and Analytics“ klicken.
Klicken Sie auf „Browse Catalog“, um den Katalog von Business Intelligence Publisher zu öffnen.
Klicken Sie in der BI-Publisher-Oberfläche auf „New“ und wählen Sie im Dropdown-Menü „Data Model“ aus.
Geben Sie in den Eigenschaften des Datenmodells einen Namen und eine Beschreibung ein. Klicken Sie auf das Symbol „+“, um einen neuen Data Set hinzuzufügen, und wählen Sie „SQL Query“ aus.
Geben Sie im Dialogfeld für den neuen Data Set einen Namen ein, zum Beispiel Requisition_Event_Log. Wählen Sie die passende Data Source für Ihre Financials-Daten aus, etwa ApplicationDB_FSCM, und legen Sie als SQL-Typ „Standard SQL“ fest.
Kopieren Sie das vollständige SQL-Skript aus dem Abschnitt „query“ dieses Dokuments und fügen Sie es in das Textfeld „SQL Query“ ein.
Die Abfrage enthält die Parameter :p_start_date und :p_end_date. BI Publisher erkennt diese automatisch. Bei Bedarf können Sie Standardwerte festlegen.
Speichern Sie das Datenmodell in einem geeigneten Katalogordner, zum Beispiel „Shared Folders/Custom“.
Um die Daten zu exportieren, kehren Sie zum Katalog zurück, klicken Sie auf „New“ und wählen Sie „Report“. Verknüpfen Sie den neuen Bericht mit dem soeben erstellten Datenmodell.
Führen Sie den Bericht mit Start- und Enddatum aus. Sobald die Daten angezeigt werden, exportieren Sie die Ergebnisse über die Funktion „Export“ als CSV-Datei.
Speichern Sie die fertige CSV-Datei mit UTF-8-Kodierung und den erforderlichen Spaltenüberschriften für den Import in Ihr Process-Mining-Tool.

Konfiguration

Datenquelle: Die Datenquelle von BI Publisher, üblicherweise „ApplicationDB_FSCM“ oder ähnlich, muss mit einem Benutzerkonto konfiguriert sein, das Lesezugriff auf alle Tabellen der Abfrage hat. Dazu gehören Tabellen aus Procurement (POR, PO), Human Capital Management (PER, HR) und Financials (FUN).
Datumsbereichsfilter: Die Abfrage enthält obligatorische Datumsparameter (:p_start_date und :p_end_date), die nach dem Erstellungsdatum der Anforderung filtern. Bei ersten Extraktionen oder großen Systemen sollten Sie die Daten in überschaubaren Abschnitten extrahieren, zum Beispiel jeweils für 3 bis 6 Monate. So vermeiden Sie Zeitüberschreitungen.
Filter für Geschäftseinheiten: Im WHERE-Abschnitt der Abfrage ist ein Filter für den Namen der Geschäftseinheit auskommentiert. Heben Sie die Auskommentierung auf und konfigurieren Sie den Filter, um die Daten auf die für Ihre Analyse relevanten Geschäftseinheiten zu begrenzen. Das kann die Leistung deutlich verbessern.
Voraussetzungen: Zum Erstellen und Ausführen des Berichts benötigt der Benutzer eine Rolle mit BI-Publisher-Berechtigungen, etwa „BI Administrator Role“ oder „BI Author Role“. Außerdem muss das Benutzerkonto über die erforderlichen Datensicherheitsberechtigungen für den Zugriff auf Beschaffungsdaten verfügen.

Beispielabfrage sql

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

Schritte

Voraussetzungen und Einrichtung der Umgebung: Stellen Sie sicher, dass Python 3 auf Ihrem System installiert ist. Installieren Sie die erforderliche Bibliothek requests mit folgendem Befehl im Terminal: pip install requests. Außerdem benötigen Sie API-Zugangsdaten (Benutzername und Passwort) für ein Oracle-Fusion-Benutzerkonto mit ausreichenden Leseberechtigungen für Einkaufsanforderungen sowie die Basis-URL Ihrer Oracle-Fusion-Instanz.
Python-Skript speichern: Speichern Sie den vollständigen Python-Code aus dem Abschnitt „query“ als Datei, zum Beispiel extract_requisitions.py.
Skriptparameter konfigurieren: Öffnen Sie die Skriptdatei in einem Texteditor und ändern Sie die Platzhalterwerte am Anfang des Skripts. Tragen Sie unter FUSION_URL, USERNAME und PASSWORD die Angaben für Ihre Oracle-Fusion-Umgebung ein. Legen Sie mit START_DATE und END_DATE den Extraktionszeitraum fest.
API-Endpunkte und Felder verstehen: Das Skript greift auf die REST-API-Ressource purchaseRequisitions zu. Über den Parameter fields fordert es nur die erforderlichen Daten an, darunter verschachtelte Sammlungen wie lines (für Bestellinformationen) und actionHistory (für Genehmigungsereignisse). Das verbessert die Leistung.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_requisitions.py. Das Skript authentifiziert sich bei der API, ruft die Daten ab und zeigt im Terminal den Fortschritt sowie die Anzahl der verarbeiteten Anforderungen an.
Seitennavigation verarbeiten: Das Skript verarbeitet die Seitennavigation automatisch. Die Oracle-Fusion-REST-API gibt die Daten in mehreren Seiten zurück. Das Skript prüft in jeder Antwort das Flag hasMore und sendet wiederholt Anfragen mit einem aktualisierten Parameter offset, bis alle Anforderungen im festgelegten Datumsbereich abgerufen wurden.
Datenumwandlung: Für jede über die API abgerufene Anforderung erstellt das Skript mehrere Zeilen im Event Log. Aus CreationDate wird das Ereignis „Anforderung erstellt“, aus SubmittedDate das Ereignis „Anforderung eingereicht“. Außerdem durchläuft das Skript die Sammlung actionHistory und erstellt für jeden Genehmigungsschritt ein Ereignis, etwa „Gestartet“, „Genehmigt“, „Abgelehnt“ oder „Zurückgegeben“.
Ereignisse für den endgültigen Status ableiten: Das Skript erfasst abschließende Ereignisse wie „Anforderung genehmigt“ und „Anforderung abgelehnt“, indem es den endgültigen Wert von DocumentStatus prüft und LastUpdateDate als Ereigniszeitstempel verwendet.
Bestellereignis erstellen: Das Skript prüft jede Anforderungsposition. Ist für eine Position eine PoHeaderId vorhanden, weist dies auf eine erstellte Bestellung hin. Das Skript fügt dafür einen Eintrag im Event Log hinzu, der die Anforderung mit dem nachgelagerten Beschaffungsprozess verknüpft.
Ausgabedatei prüfen: Nach Abschluss erstellt das Skript im selben Verzeichnis eine CSV-Datei mit dem Namen oracle_fusion_requisitions_event_log.csv. Diese Datei enthält das extrahierte Event Log.
Für den Upload vorbereiten: Öffnen Sie die erstellte CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie den Inhalt. Stellen Sie sicher, dass Spalten und Datenformate den Anforderungen Ihres Process-Mining-Tools entsprechen. Anschließend können Sie die Datei in ProcessMind hochladen.

Konfiguration

API-Zugangsdaten: Erforderlich ist ein dediziertes Integrationskonto mit einer Rolle, die Lesezugriff auf die REST-API für Einkaufsanforderungen gewährt. Beispiele sind „Procurement Manager“ oder eine benutzerdefinierte Integrationsrolle.
REST-API-Endpunkt: Das Skript verwendet den Endpunkt .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Stellen Sie sicher, dass die Versionsnummer in der URL mit Ihrer Oracle-Fusion-Umgebung übereinstimmt.
Datumsbereichsfilter: Das Skript enthält die Variablen START_DATE und END_DATE. Extrahieren Sie die Daten möglichst in überschaubaren Abschnitten, zum Beispiel jeweils für 3 bis 6 Monate. So vermeiden Sie API-Zeitüberschreitungen und Leistungsprobleme. Der Filter wird auf CreationDate der Anforderungen angewendet.
Feldauswahl: Der Parameter fields ist entscheidend für die Leistung. Er beschränkt die Antwort auf die für das Event Log erforderlichen Attribute und reduziert so Netzwerkverkehr und Verarbeitungszeit. Entfernen Sie keine erforderlichen Felder wie RequisitionId, CreationDate, actionHistory oder lines.
Seitengröße: Der Parameter limit ist auf 100 gesetzt. Dieser Wert eignet sich für die meisten Umgebungen. Sie können ihn auf 200 oder 500 erhöhen, um die Extraktion möglicherweise zu beschleunigen. Bei zu hohen Werten sind jedoch Speicherprobleme oder API-Beschränkungen möglich.

Beispielabfrage python

import requests
import csv
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 instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

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

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

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

Schritte

Prüfen Sie, ob Oracle BI Cloud Connector, die erforderlichen Beschaffungsinhalte von Oracle Fusion Financials und der Zugriff auf die relevanten Public View Objects in Ihrer Umgebung verfügbar sind. Stellen Sie sicher, dass der BICC-Benutzer oder das Integrationskonto zum Extrahieren von Anforderungs-, Genehmigungsverlaufs- und Bestelldaten berechtigt ist. Die genauen Rollennamen und Navigationsbezeichnungen unterscheiden sich je nach Oracle-Version. Verwenden Sie daher den entsprechenden BICC-Verwaltungsbereich in Ihrem Mandanten.
Ermitteln und aktivieren Sie die für die Extraktion erforderlichen PVOs. Verwenden Sie RequisitionHeaderPVO oder das entsprechende PVO für Anforderungsköpfe in Ihrer Umgebung sowie die PVOs für Anforderungspositionen, Statusverlauf, Genehmigungs-Workflow-Verlauf und Bestellreferenzen. Gehen Sie nicht davon aus, dass ein einzelnes PVO den Workflow-Verlauf oder den Verlauf der Bestellerstellung enthält. Dokumentieren Sie die genauen PVO-Namen und verfügbaren Attribute in Ihrem Mandanten.
Richten Sie einen BICC-Auftrag für eine inkrementelle oder historische Massenextraktion ein. Legen Sie den Extraktionszeitraum mit [Start date parameter] und [End date parameter] fest und konfigurieren Sie die Bereitstellung der CSV-Dateien am freigegebenen Cloud-Speicherort. Verwenden Sie für den initialen Ladevorgang einen ausreichend langen historischen Zeitraum. Planen Sie bei wiederkehrenden Ladevorgängen überlappende Zeiträume ein, um verspätete Aktualisierungen zu erfassen. Entfernen Sie anschließend Duplikate anhand der Case-ID, Aktivität, des Ereigniszeitstempels und, sofern verfügbar, der Quellereignis-ID.
Konfigurieren Sie die Extraktionsspalten. Nehmen Sie die Anforderungs-ID, IDs für Anforderungskopf und -position, Anforderer, Abteilung, Betrag, Status, benötigtes Datum, Geschäftseinheit, Ablehnungsgrund, Erstellungs- und Aktualisierungszeitstempel, Zeitstempel für Statusänderungen, Zuweisungs- und Aktionszeitstempel der Genehmigung, Genehmigungsaktion, Bestellreferenz und BICC-Aktualisierungszeitstempel auf. Verwenden Sie die genauen Attributnamen der ausgewählten PVOs. Falls ein Attribut nicht verfügbar ist, ordnen Sie es [Configure based on your system] zu und dokumentieren Sie die Einschränkung, statt ein nicht verifiziertes Feld zu verwenden.
Extrahieren Sie die CSV-Dateien aus dem Quellsystem und bewahren Sie die Originaldateien auf. Laden Sie jede Datei in einen Staging-Bereich, speichern Sie den Namen des Quell-PVOs und der Datei, vereinheitlichen Sie die Zeitzone der Zeitstempel und verarbeiten Sie Oracle-Datums- und Zeitstempelwerte einheitlich. Behandeln Sie IDs als Zeichenfolgen, damit führende Nullen und die Genauigkeit erhalten bleiben.
Formen Sie die Quelldaten in eine Ereignistabelle mit einer Zeile pro explizitem Geschäftsereignis um. Die Ausgabe muss PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate enthalten. Ergänzen Sie die empfohlenen Attribute, sofern verfügbar. Verlassen Sie sich nicht darauf, dass ProcessMind Ereignisse aus Status- oder Feldänderungen ableitet. Die Datentransformation muss explizit Zeilen für alle zwölf im Abfrageabschnitt aufgeführten Aktivitäten erstellen.
Erstellen Sie die Ereigniszeilen anhand geeigneter Quelldaten. Verwenden Sie den Erstellungsnachweis für „Anforderung erstellt“, einen expliziten Statusübergang für „Anforderung eingereicht“, eine explizite Rücknahmeaktion oder einen entsprechenden Statusübergang für „Anforderung zurückgezogen“, eine erkannte Änderung nach der Einreichung oder eine neue Version für „Anforderung geändert“, die Workflow-Zuweisung für „Genehmigungsschritt gestartet“ und explizite Aktionen aus dem Genehmigungsverlauf für „Genehmigungsschritt genehmigt“, „Genehmigungsschritt abgelehnt“ und „Genehmigungsschritt zurückgegeben“. Verwenden Sie einen expliziten Gesamtstatusübergang für „Anforderung genehmigt“, „Anforderung abgelehnt“ und „Anforderung geschlossen“. Verwenden Sie für „Bestellung erstellt“ einen expliziten Bestellerstellungsdatensatz oder einen mit der Anforderung verknüpften Erstellungszeitstempel.
Entfernen Sie Duplikate nach einem eindeutigen, reproduzierbaren Verfahren. Wenn mehrere Quellzeilen dasselbe Ereignis darstellen, behalten Sie eine Zeile mit dem genauesten Ereigniszeitstempel und, sofern verfügbar, einer stabilen Quell-ID. Fassen Sie unterschiedliche Genehmigungsschritte nicht allein deshalb zusammen, weil sie dieselbe Anforderungs-ID haben. Bewahren Sie separate Genehmigungsereignisse für unterschiedliche Genehmigende oder Workflow-Schritte.
Prüfen Sie das fertige Event Log. Stellen Sie sicher, dass alle erforderlichen Aktivitäten enthalten sind, jedes Ereignis eine Case-ID und einen Ereigniszeitstempel hat und die Zeitstempel innerhalb des Extraktionszeitraums liegen oder durch verspätete Aktualisierungen erklärbar sind. Prüfen Sie außerdem, ob empfohlene Attribute ausgefüllt sind, sofern die Quelle sie bereitstellt. Gleichen Sie die Anzahl der Anforderungen und die Bestellverknüpfungen mit den Quellextrakten ab.
Exportieren Sie das fertige Event Log als UTF-8-kodierte CSV-Datei mit einer Kopfzeile und einem Ereignis pro Zeile. Verwenden Sie exakt die Spaltennamen PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate sowie die empfohlenen Attribute. Laden Sie die CSV-Datei in ProcessMind hoch und konfigurieren Sie PurchaseRequisitionId als Case-ID, ActivityName als Aktivität und EventTime als Ereigniszeitstempel.

Konfiguration

Extraktionsmethode: Massenextraktion mit Oracle BI Cloud Connector. Die CSV-Dateien werden am konfigurierten Cloud-Speicherort abgelegt.
Quellobjekte: Verwenden Sie RequisitionHeaderPVO sowie die in Ihrem Mandanten verfügbaren PVOs für Anforderungspositionen, Statusverlauf, Genehmigungs-Workflow-Verlauf und Bestellreferenzen. Prüfen Sie die genauen PVO-Namen und Attribute in Ihrer Umgebung.
Erforderliche Ausgabespalten: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate.
Empfohlene Ausgabespalten: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason und BusinessUnit.
Datumsbereich: Verwenden Sie für regelmäßige Analysen einen Zeitraum von drei bis sechs Monaten. Für einen initialen historischen Ladevorgang können Sie bei Bedarf einen längeren Zeitraum wählen. Verwenden Sie bei wiederkehrenden Extraktionen überlappende Zeiträume, um verspätete Aktualisierungen zu erfassen, und entfernen Sie anschließend Duplikate.
Filter: Wenden Sie [Company-specific filter], [Document Type filter], [Business Unit filter] und [Date range filter] nur an, wenn die entsprechenden Attribute in den ausgewählten PVOs verfügbar sind. Prüfen Sie, ob der Filter für das Erstellungsdatum, das Aktualisierungsdatum, das Datum des Statusübergangs oder ein anderes Quelldatum gilt.
Inkrementelle Extraktion: Verwenden Sie bevorzugt einen Aktualisierungszeitstempel oder einen von BICC unterstützten Mechanismus für inkrementelle Extraktionen. Speichern Sie den Zeitstempel der letzten erfolgreichen Extraktion und berücksichtigen Sie beim nächsten Lauf einen kurzen Überlappungszeitraum.
Vollständigkeit der Ereignisse: Richten Sie separate Quellextraktionen ein, wenn die Anforderungsköpfe keinen Genehmigungsverlauf, keine Statusübergänge, Änderungen oder Bestellerstellungen enthalten. Aus einem Extrakt mit ausschließlich aktuellen Kopfdatensätzen lassen sich historische Ereignisse nicht zuverlässig rekonstruieren.
Leistung: Begrenzen Sie den Datumsbereich und die ausgewählten Spalten, teilen Sie große Extraktionen nach Möglichkeit in Partitionen auf, vermeiden Sie unnötige beschreibende Attribute und verarbeiten Sie CSV-Dateien stapelweise. Bewahren Sie die Quelldateien zum Abgleich auf.
Speicherung: Richten Sie einen freigegebenen Cloud-Speicherort mit ausreichender Kapazität, Aufbewahrungsdauer, Verschlüsselung und Zugriffskontrollen ein. Prüfen Sie, ob das Extraktionskonto Dateien schreiben und der Transformationsprozess sie lesen kann.
Voraussetzungen: Verfügbarkeit von BICC, Zugriff auf die relevanten Beschaffungs- und Genehmigungsdaten in Oracle Fusion, geeignete Integrationsberechtigungen, Zugriff auf die ausgewählten PVOs sowie gegebenenfalls erforderliche Oracle-Abonnements oder Funktionsberechtigungen. Die genauen Rollennamen, Lizenzen und Navigationspfade hängen von der Oracle-Version und der Mandantenkonfiguration ab.
Umgang mit Zeitangaben: Vereinheitlichen Sie alle Zeitstempel aus den Quelldaten anhand einer dokumentierten Zeitzone. Bewahren Sie den ursprünglichen Zeitstempel auf, wenn dies für die Auditierbarkeit erforderlich ist.
Zuordnung von Cases: Verwenden Sie PurchaseRequisitionId als Case-ID. Verwenden Sie eine ID der Anforderungsposition nur dann als Case-ID, wenn der Prozess bewusst auf Positionsebene modelliert wird.

Beispielabfrage sql

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Möchten Sie loslegen?

Verwenden Sie dieses Template als Ausgangspunkt, um Ihren Purchase-to-Pay-Anforderungsprozess zu optimieren und die Effizienz zu steigern. Bereiten Sie sich darauf vor, Ihre Beschaffungsabläufe zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Purchase-to-Pay-Anforderungen 30 % schneller bearbeiten

Vereinfachen Sie Ihren Oracle-P2P-Anforderungsprozess und verkürzen Sie die Zykluszeit um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für Purchase-to-Pay-Anforderungen

Ihr Daten-Template für Purchase-to-Pay-Anforderungen

Attribute für Purchase-to-Pay-Anforderungen

Aktivitäten bei Purchase-to-Pay-Anforderungen

Anleitungen zur Datenextraktion

Export aus Oracle Transactional Business Intelligence (OTBI)

Schritte

Konfiguration

Beispielabfrage sql

Datenextraktion mit SQL-basiertem Datenmodell in Oracle BI Publisher

Schritte

Konfiguration

Beispielabfrage sql

Python-Skript über die Oracle-Fusion-REST-API

Schritte

Konfiguration

Beispielabfrage python

Massenextraktion von Daten mit Oracle BI Cloud Connector (BICC)

Schritte

Konfiguration

Beispielabfrage sql

Möchten Sie loslegen?

Purchase-to-Pay-Anforderungen 30 % schneller bearbeiten