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

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

Oracle Fusion Financials

Purchase to Pay - Requisition: Attribute (22) Purchase to Pay - Requisition: Aktivitäten (12) Extraktionsanleitungen (4)

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

Dieses Template bietet Ihnen einen klaren Leitfaden für die Erfassung der wesentlichen Daten zur Analyse Ihres Purchase-to-Pay-Prozesses für Anforderungen. Es beschreibt die wichtigsten zu erfassenden Attribute, die relevanten zu verfolgenden Aktivitäten und praktische Hinweise zur Extraktion dieser Informationen aus Oracle Fusion Financials. Damit können Sie Ihr Event Log gezielt für aussagekräftiges Process Mining vorbereiten.

Empfohlene zu erfassende Attribute
Wichtige zu verfolgende Aktivitäten
Hinweise zur Extraktion aus Oracle Fusion Financials

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

Template herunterladen

Purchase to Pay - Requisition: Attribute

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse von Purchase to Pay - Requisition in das Event Log aufnehmen sollten.

5 Erforderlich 7 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des Geschäftsereignisses, das zu einem bestimmten Zeitpunkt im Prozess der Bestellanforderung eingetreten ist.
Beschreibung Die Aktivität stellt einen einzelnen Schritt oder Meilenstein im Lebenszyklus einer Bestellanforderung dar. Beispiele sind „Requisition Created“, „Approval Step Approved“ oder „Purchase Order Created“. Diese Aktivitäten werden aus Statusänderungen, Benutzeraktionen oder Systemereignissen abgeleitet, die in Audit-Protokollen oder Transaktionstabellen des Quellsystems erfasst sind. Dieses Attribut ist für die Erstellung des Prozessmodells unverzichtbar, das den Ablauf von Bestellanforderungen visuell darstellt. Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten hilft dabei, typische Prozesspfade, Engpässe, Nacharbeitsschleifen und Abweichungen vom Standardverfahren zu erkennen. Warum das wichtig ist Es bildet das Rückgrat des Prozessmodells und ermöglicht die Visualisierung sowie Analyse des Workflows von Bestellanforderungen. Bezugsquelle Abgeleitet aus Datensätzen zu Statusänderungen in Tabellen wie POR_REQUISITION_HEADERS_ALL, aus der Transaktionshistorie oder aus Workflow-Audit-Trails wie FA_FUSION_SOAINFRA.WFTASK. Beispiele Anforderung erstelltGenehmigungsschritt genehmigtBestellanforderung abgelehntBestellung erstellt
	Ereigniszeitpunkt EventTime	Der Timestamp, der angibt, wann die Aktivität stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt erfasst das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität stattgefunden hat. Dieser Timestamp ist entscheidend für die chronologische Sortierung von Ereignissen innerhalb eines Cases. Er stammt aus Erstellungsdaten, Daten der letzten Aktualisierung oder spezifischen Aktions-Timestamps im System. In der Analyse wird der Ereigniszeitpunkt zur Berechnung aller zeitbezogenen Kennzahlen verwendet, etwa der Durchlaufzeiten zwischen Aktivitäten, der Wartezeiten und der gesamten Case-Dauer. Er ist entscheidend, um Engpässe zu erkennen, die Leistung anhand von SLAs zu messen und die zeitlichen Abläufe im Prozess der Bestellanforderung zu verstehen. Warum das wichtig ist Dieses Attribut ist unverzichtbar für die Berechnung aller zeitbezogenen KPIs, die korrekte Sortierung von Ereignissen sowie die Analyse von Prozessleistung und Engpässen. Bezugsquelle In der Regel stammt dieser Wert 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 Tabellen der Workflow-Historie. Beispiele 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID der Bestellanforderung PurchaseRequisitionId	Die eindeutige Kennung einer Bestellanforderung, die als Case ID für den Prozess dient.
Beschreibung Die ID der Bestellanforderung ist die zentrale Kennung, die alle Aktivitäten zu einem bestimmten Antrag auf Waren oder Dienstleistungen miteinander verknüpft. Jede Bestellanforderung erhält bei ihrer Erstellung eine eindeutige ID, die während ihres gesamten Lebenszyklus unverändert bleibt. Im Process Mining wird dieses Attribut verwendet, um alle zugehörigen Ereignisse, etwa Erstellung, Einreichung, Genehmigungsschritte und endgültigen Abschluss, zu einem einzelnen Case zusammenzufassen. Dadurch lässt sich der Weg der Bestellanforderung durchgängig analysieren, einschließlich der Visualisierung von Prozessmodellen, der Berechnung von Durchlaufzeiten und der Analyse von Varianten für jeden einzelnen Antrag. Warum das wichtig ist Dies ist das grundlegende Attribut für die Nachverfolgung des Lebenszyklus einer Bestellanforderung von Anfang bis Ende. Es ermöglicht sämtliche Analysen auf Case-Ebene und KPI-Berechnungen. Bezugsquelle In der Regel handelt es sich um den Primärschlüssel in der Tabelle mit den Kopfdaten der Bestellanforderung, etwa 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 an, wann die Daten zuletzt aus Oracle Fusion Financials extrahiert wurden. Es bezieht sich auf den gesamten Datensatz und nicht auf einzelne Ereignisse. Analysten verwenden diese Information, um die Aktualität der Daten einzuschätzen und zu bestätigen, wann die neuesten Transaktionen einbezogen wurden. Sie ist ein wichtiger Metadatenbestandteil für Dashboard-Berichte und stellt sicher, dass Analysen auf aktuellen Informationen basieren. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass Analysen relevant sind und auf den neuesten verfügbaren Informationen basieren. Bezugsquelle Dieser Timestamp wird während der Datenextraktion erzeugt und gespeichert, typischerweise 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 identifiziert die Herkunft der Prozessdaten. In diesem Datenmodell lautet der Wert durchgehend „Oracle Fusion Financials“. In Umgebungen mit mehreren ERP- oder integrierten Systemen ist dieses Feld für die Datenherkunft, die Fehleranalyse und die Sicherstellung der Datenqualität entscheidend. Es liefert den Kontext zur maßgeblichen Quelle der analysierten Prozessereignisse. Warum das wichtig ist Liefert wichtigen Kontext zur Datenherkunft. Das ist für Data Governance und die Integration von Daten aus mehreren Systemen entscheidend. Bezugsquelle Dies ist ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion Financials
	Ablehnungsgrund RejectionReason	Der Grund, den ein Genehmiger bei der Ablehnung einer Bestellanforderung oder eines Genehmigungsschritts angibt.
Beschreibung Bei der Ablehnung einer Bestellanforderung gibt der Genehmiger in der Regel einen Grund an, entweder durch Auswahl aus einer vordefinierten Liste oder durch Eingabe eines Freitexts. Dieses Attribut erfasst diese Begründung. Es ist entscheidend für die Ursachenanalyse von Prozessfehlern. Das Attribut unterstützt direkt das Dashboard „Trends bei Änderungen und Ablehnungen“, da es das „Warum“ hinter den Ablehnungen sichtbar macht. Die Analyse der Ablehnungsgründe hilft dabei, wiederkehrende Probleme wie falsche Kontierung, Budgetüberschreitungen oder Richtlinienverstöße zu erkennen und durch Schulungen oder Systemkontrollen zu beheben. Warum das wichtig ist Liefert direkte Erkenntnisse darüber, warum Bestellanforderungen abgelehnt werden, und ermöglicht gezielte Verbesserungen zur Verringerung von Nacharbeit sowie zur Erhöhung der Straight-Through-Processing-Rate. Bezugsquelle Stammt aus Workflow-Kommentaren oder spezifischen Feldern für Ablehnungsgrundcodes im Workflow-Audit-Trail, möglicherweise aus Tabellen im Zusammenhang mit FA_FUSION_SOAINFRA.WFTASK oder zugehörigen Kommentarspeichern. Beispiele Falsches SachkontoBudget für Kostenstelle überschrittenNicht bevorzugter Lieferant ausgewähltDoppelte Anforderung
	Abteilung DepartmentName	Die Geschäftsabteilung, der der Anforderer angehört.
Beschreibung Dieses Attribut gibt die Organisationseinheit der Person an, die die Bestellanforderung erstellt hat, etwa „Finance“, „IT“ oder „Marketing“. Es wird typischerweise aus dem Benutzerprofil des Anforderers im HR-System abgeleitet. Die Analyse nach Abteilung ist eine gängige und aussagekräftige Möglichkeit, Prozessdaten zu segmentieren. Sie hilft dabei, abteilungsspezifische Muster zu erkennen, etwa höhere Ablehnungsraten oder längere Durchlaufzeiten. Diese Erkenntnisse können gezielte Maßnahmen zur Prozessverbesserung unterstützen. Für das Dashboard „Leistungskennzahlen der Anforderer“ ist dies eine zentrale Dimension. Warum das wichtig ist Ermöglicht die nach Geschäftsbereich segmentierte Prozessanalyse und macht abteilungsspezifische Muster, Leistungswerte und Compliance-Probleme sichtbar. Bezugsquelle Wird typischerweise aus dem Profil des Anforderers abgeleitet. Dafür ist häufig eine Verknüpfung der Tabelle der Bestellanforderung mit einer HR- oder Benutzerverzeichnistabelle erforderlich, die Abteilungsinformationen enthält. Beispiele InformationstechnologieFinanzenBetriebMarketing
	Benötigt-bis-Datum RequiredByDate	Das Datum, bis zu dem der Anforderer die Waren oder Dienstleistungen benötigt.
Beschreibung Dieses Datum wird vom Anforderer angegeben und bezeichnet die Frist für den Erhalt der angeforderten Artikel. Es dient als internes Service-Level-Agreement-Ziel (SLA) für den Beschaffungsprozess. Dieses Attribut bildet die Grundlage für das Dashboard „Leistung zum Benötigt-bis-Datum“ und die KPI „Einhaltungsrate des Benötigt-bis-Datums“. Durch den Vergleich mit dem tatsächlichen Erstellungsdatum der Bestellung oder dem Wareneingangsdatum lässt sich erkennen, wie gut der Beschaffungsprozess interne Anforderungen erfüllt und an welchen Stellen systematische Verzögerungen auftreten. Warum das wichtig ist Entscheidend für die Messung der Prozessleistung anhand interner Fristen und die Beurteilung, ob der Beschaffungsprozess die Geschäftsanforderungen rechtzeitig erfüllt. Bezugsquelle Wird üblicherweise auf Ebene der Bestellanforderungsposition gespeichert, in Tabellen wie POR_REQUISITION_LINES_ALL und einem Feld wie „NEED_BY_DATE“. Beispiele 2023-11-012023-12-152024-01-31
	Gesamtbetrag der Bestellanforderung RequisitionTotalAmount	Der gesamte Geldwert der Bestellanforderung.
Beschreibung Dieses Attribut stellt die Summe der Werte aller Positionen einer einzelnen Bestellanforderung dar. Es ist ein wichtiger Datenpunkt, um die finanzielle Bedeutung jedes Antrags zu verstehen. Im Process Mining wird der Gesamtbetrag für zahlreiche Analysen verwendet. Damit lassen sich Bestellanforderungen mit hohem Wert filtern, für die häufig andere Genehmigungspfade oder eine strengere Prüfung gelten. Dashboards können anhand dieses Attributs untersuchen, wie Prozesskennzahlen wie Durchlaufzeit oder Ablehnungsrate mit dem Wert der Bestellanforderung zusammenhängen. Warum das wichtig ist Liefert den finanziellen Kontext, ermöglicht wertbasierte Analysen zur Priorisierung von Prozessverbesserungen und zeigt, wie der Wert einer Bestellanforderung das Prozessverhalten beeinflusst. Bezugsquelle Befindet sich in den Kopfdaten der Bestellanforderung, häufig in einem Feld wie REQUISITION_TOTAL in POR_REQUISITION_HEADERS_ALL. Alternativ kann der Wert durch Summieren der Positionsbeträge aus POR_REQUISITION_LINES_ALL berechnet werden. Beispiele 550.0012500.7599.99
	Geschäftseinheit BusinessUnit	Die konkrete 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 Gruppierung gegenüber einer Abteilung. Die Analyse nach Geschäftseinheit ermöglicht Leistungsvergleiche auf hoher Ebene zwischen verschiedenen Unternehmensteilen. So kann das Management erkennen, ob Prozessineffizienzen lokal begrenzt oder weit verbreitet sind und wo Verbesserungsmaßnahmen ansetzen sollten. Die Geschäftseinheit ist eine zentrale Dimension für die Filterung nahezu aller Dashboards und KPIs. Warum das wichtig ist Liefert den organisatorischen Kontext auf hoher Ebene und ermöglicht Leistungsvergleiche sowie strategische Analysen zwischen verschiedenen Unternehmensteilen. Bezugsquelle Dies ist ein grundlegendes Organisationsfeld in Oracle Fusion und typischerweise in den Kopfdaten der Bestellanforderung verfügbar, etwa in Tabellen wie POR_REQUISITION_HEADERS_ALL. Beispiele Geschäftseinheit NordamerikaGeschäftseinheit EuropaUnternehmenszentrale
	Name des Anforderers RequesterName	Der Name des Mitarbeiters, der die Bestellanforderung erstellt und eingereicht hat.
Beschreibung Dieses Attribut identifiziert die Person, die den Antrag auf Waren oder Dienstleistungen initiiert hat. Diese Information wird typischerweise zu Beginn des Prozesses erfasst, wenn die Bestellanforderung erstellt wird. Die Analyse der Prozessleistung nach Anforderer ist für das Dashboard „Leistungskennzahlen der Anforderer“ entscheidend. Sie hilft dabei, Benutzer oder Gruppen mit zusätzlichem Schulungsbedarf zu erkennen, indem sie hohe Änderungs- oder Ablehnungsraten sowie lange Durchlaufzeiten bei deren Anträgen sichtbar macht. Dadurch entsteht eine auf die beteiligten Personen ausgerichtete Sicht auf den Prozess. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Anforderer, hilft bei der Ermittlung des Schulungsbedarfs und macht effiziente Benutzer oder Abteilungen sichtbar. Bezugsquelle Stammt aus den Kopfdaten der Bestellanforderung, häufig durch Verknüpfung der Anforderer-ID mit einer Mitarbeiter- oder Benutzerstammdatentabelle. Suchen Sie nach Feldern im Zusammenhang mit „PREPARER_ID“ in POR_REQUISITION_HEADERS_ALL 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, etwa „Approved“, „Rejected“, „In Process“ oder „Closed“. Häufig werden daraus zahlreiche Aktivitäten im Event Log abgeleitet. Dieses Attribut ist zentral für das Dashboard „Übersicht zum Status der Bestellanforderungen“ und liefert eine Momentaufnahme der aktuellen Arbeitslast und des Rückstands. Außerdem wird es zur Berechnung ergebnisbezogener KPIs verwendet, etwa der Ablehnungsrate von Bestellanforderungen, indem nach Cases mit einem bestimmten Endstatus gefiltert wird. Warum das wichtig ist Liefert eine Momentaufnahme des aktuellen Zustands der Bestellanforderungen und wird zur Ermittlung endgültiger Ergebnisse für KPI-Berechnungen verwendet. Bezugsquelle Befindet sich in der Tabelle mit den Kopfdaten der Bestellanforderung, typischerweise in einem Feld wie „DOCUMENT_STATUS“ oder „APPROVAL_STATUS“ in POR_REQUISITION_HEADERS_ALL. Beispiele GENEHMIGTIN BEARBEITUNGABGELEHNTZURÜCKGEZOGEN
	Artikelbeschreibung ItemDescription	Die Beschreibung des Produkts oder der Dienstleistung, die in einer Bestellanforderungszeile angefordert wird.
Beschreibung Dieses Attribut enthält die Textbeschreibung des zu beschaffenden Artikels. Es liefert konkrete Angaben zu den angeforderten Waren oder Dienstleistungen. Obwohl die Information häufig unstrukturiert ist, bietet die Artikelbeschreibung wertvollen Kontext für die Analyse. Sie kann als Filter verwendet werden, um Bestellanforderungen für bestimmte Beschaffungsarten zu isolieren, die möglicherweise nicht durch den Typ der Bestellanforderung erfasst werden. So kann ein Analyst beispielsweise nach allen Bestellanforderungen mit „Software License“ suchen, um deren spezifischen Prozessablauf und ihre Durchlaufzeit zu untersuchen. Warum das wichtig ist Liefert detaillierten Kontext zum Beschaffungsgegenstand und ermöglicht eine granularere Filterung sowie Analyse bestimmter Waren oder Dienstleistungen. Bezugsquelle Befindet sich in der Tabelle der Bestellanforderungspositionen POR_REQUISITION_LINES_ALL, in einem Feld wie ITEM_DESCRIPTION. Beispiele Laptop mit 15 Zoll, 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 identifiziert Prozessereignisse, die von einem Systembenutzer oder einem automatisierten Agenten statt von einer Person ausgeführt wurden. Beispiele sind systemgesteuerte Statusänderungen oder automatische Genehmigungsschritte für Vorgänge mit geringem Wert. Die Analyse dieses Attributs hilft dabei, den Automatisierungsgrad des Prozesses zu quantifizieren. Sie können die Geschwindigkeit und Effizienz automatisierter und manueller Schritte vergleichen und weitere Automatisierungsmöglichkeiten erkennen. Warum das wichtig ist Hilft dabei, den Automatisierungsgrad des Prozesses zu messen und Möglichkeiten zur Automatisierung manueller Aufgaben zu erkennen. Bezugsquelle Wird daraus abgeleitet, ob der einer Aktivität zugeordnete Benutzer ein System- oder Servicekonto ist. Dafür ist eine Liste bekannter IDs von Systembenutzern erforderlich. Beispiele truefalse
	Benutzername UserName	Der Name des Benutzers, der eine bestimmte Aktivität ausgeführt hat, etwa ein Genehmiger oder Bearbeiter.
Beschreibung Während der Name des Anforderers die initiierende Person bezeichnet, gibt der Benutzername die Person an, die ein bestimmtes Ereignis im Prozess ausgeführt hat, etwa eine Genehmigung oder Ablehnung. Das ist besonders bei mehrstufigen Genehmigungs-Workflows wichtig, an denen verschiedene Personen beteiligt sind. Dieses Attribut ist entscheidend für die Analyse von Engpässen bei Genehmigungen und die Messung der Leistung einzelner Genehmiger oder Teams. Es unterstützt direkt das Dashboard „Engpässe im Genehmigungs-Workflow“, da sich damit die Bearbeitungszeiten aller an der Genehmigungskette beteiligten Benutzer analysieren lassen. Warum das wichtig ist Identifiziert den Akteur für jedes Ereignis. Das ist für die Analyse von Übergabezeiten, der Leistung von Genehmigern und der Ressourcenverteilung entscheidend. Bezugsquelle Stammt aus Tabellen der Workflow-Historie oder des Audit-Trails, etwa FA_FUSION_SOAINFRA.WFTASK, in denen der einem Aufgabenabschluss zugeordnete Benutzer 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 resultierenden Bestellung. Nach der vollständigen Genehmigung wird eine Bestellanforderung typischerweise in eine oder mehrere Bestellungen umgewandelt, die an einen Lieferanten gesendet werden. In der Analyse ist diese ID entscheidend für die Nachverfolgung des nachgelagerten Prozesses. Sie ermöglicht die Berechnung der KPI „Durchlaufzeit von der Bestellanforderung bis zur Bestellung“ und unterstützt das Dashboard „Durchlaufzeit von der Bestellanforderung bis zur Bestellung“. Außerdem lassen sich die Prozessdaten der Bestellanforderung mit den nachfolgenden Bestell- und Rechnungsprozessen verbinden, um den Purchase-to-Pay-Prozess durchgängig zu analysieren. Warum das wichtig ist Verknüpft die Bestellanforderung mit der nachfolgenden Bestellung und ermöglicht die Messung der Durchlaufzeit von der Bestellanforderung bis zur Bestellung sowie die durchgängige Prozessanalyse. Bezugsquelle Diese Information wird gespeichert, sobald eine Bestellung erstellt wurde. Sie wird typischerweise über die Referenzen auf die zugrunde liegende Bestellanforderung in den Verteilungstabellen der Bestellung ermittelt, etwa in PO_DISTRIBUTIONS_ALL, das auf die Bestellanforderungszeile verweist. Beispiele PO-2023-5832PO-2023-5833PO-2023-5834
	Name des Lieferanten SupplierName	Der Name des vorgeschlagenen oder vorausgewählten Lieferanten für die Waren oder Dienstleistungen.
Beschreibung Dieses Attribut identifiziert den Lieferanten, von dem die Waren oder Dienstleistungen voraussichtlich beschafft werden. Der Lieferant kann vom Anforderer vorgeschlagen oder vom System anhand von Katalogen oder bestehenden Vereinbarungen bestimmt werden. Die Analyse nach Lieferant kann wichtige Beschaffungsmuster sichtbar machen. So lässt sich beispielsweise erkennen, ob Bestellanforderungen für bestimmte Lieferanten länger bis zur Genehmigung benötigen oder häufiger abgelehnt werden. Diese Informationen können für das Lieferantenmanagement und die Beschaffungsstrategie wertvoll sein. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach Lieferant und kann dadurch die Beschaffungsstrategie sowie das Lieferantenmanagement unterstützen. Bezugsquelle Befindet sich in der Tabelle der Bestellanforderungspositionen POR_REQUISITION_LINES_ALL und ist häufig über VENDOR_ID mit einer Lieferantenstammdatentabelle wie POZ_SUPPLIERS verknüpft. Beispiele Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Ohne Nachbearbeitung IsStraightThrough	Ein Kennzeichen dafür, ob die Anforderung ohne Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dieses berechnete Kennzeichen identifiziert Anforderungen, die den Prozess von der Einreichung bis zur Genehmigung ohne Nachbearbeitungsschleifen, etwa Änderungen oder Ablehnungen, durchlaufen haben. Es steht für einen vollständig geradlinigen Prozess bei einem einzelnen Case. Dieses Attribut bildet die Grundlage für den KPI „Straight-Through Requisition Rate“. Die Analyse der Merkmale solcher Anforderungen, etwa häufiger Abteilungen, Anforderer oder Typen, kann Best Practices und Automatisierungsmöglichkeiten aufzeigen. Umgekehrt hilft die Analyse der nicht geradlinig bearbeiteten Anforderungen dabei, die wichtigsten Ursachen für Ineffizienz zu ermitteln. Warum das wichtig ist Misst die Prozesseffizienz direkt und bildet die Grundlage für den KPI „Straight-Through Requisition Rate“. So lassen sich die Ursachen für Nachbearbeitung identifizieren. Bezugsquelle Dieses Attribut wird während der Datentransformation berechnet. Ein Case erhält den Wert „true“, wenn keine Aktivitäten „Requisition Amended“ oder „Approval Step Rejected“ vorhanden sind. Beispiele truefalse
	Pfad des Genehmigungs-Workflows ApprovalWorkflowPath	Die vordefinierte Reihenfolge der für die Bestellanforderung erforderlichen Genehmiger oder Genehmigungsgruppen.
Beschreibung Dieses Attribut definiert den erwarteten Standardprozess für die Genehmigung einer Bestellanforderung auf Grundlage der Unternehmensrichtlinien. Dabei werden Faktoren wie Betrag, Typ und Abteilung der Bestellanforderung berücksichtigt. Es stellt den „Soll“-Prozess dar. Der Pfad des Genehmigungs-Workflows ist grundlegend für Compliance- und Konformitätsanalysen. Er unterstützt direkt das Dashboard „Compliance- und Abweichungsanalyse“ sowie die KPI „Konformitätsindex der Bestellanforderung“, da sich die tatsächlich durchlaufenen Genehmigungsschritte direkt mit dem vorgeschriebenen Pfad vergleichen lassen. Abweichungen können auf Richtlinienverstöße oder ineffiziente Abläufe hinweisen. Warum das wichtig ist Ermöglicht die Konformitätsprüfung durch den Vergleich des tatsächlichen Prozessablaufs mit der erforderlichen Genehmigungshierarchie und macht nicht konforme Bestellanforderungen sichtbar. Bezugsquelle Diese Informationen werden in der Oracle Fusion BPM Worklist oder der Approval Management Engine (AMX) konfiguriert. Das Extrahieren des definierten Pfads für jede Bestellanforderung kann komplex sein und Abfragen von Konfigurationstabellen erfordern. Beispiele Manager > Direktor > VP FinanzenKostenstellenverantwortlicher > IT-SicherheitManager > Abteilungsleitung
	Typ der Bestellanforderung RequisitionType	Die Kategorie der Bestellanforderung, etwa ein Antrag auf Waren oder Dienstleistungen.
Beschreibung Dieses Attribut klassifiziert die Bestellanforderung anhand des angeforderten Gegenstands. Übliche Typen sind Waren, Dienstleistungen oder Investitionsausgaben. Der Typ kann den erforderlichen Genehmigungs-Workflow und die Beschaffungsstrategie beeinflussen. In der Analyse dient der Typ der Bestellanforderung als wichtige Dimension für Filterung und Vergleich. So lässt sich beispielsweise untersuchen, ob Dienstleistungsanforderungen eine längere Genehmigungsdurchlaufzeit als Warenanforderungen haben. Außerdem wird sichtbar, ob sich verschiedene Antragstypen durch ein unterschiedliches Prozessverhalten oder eigene Engpässe auszeichnen. Warum das wichtig ist Ermöglicht die Segmentierung der Analyse, um Unterschiede im Prozess für verschiedene Beschaffungsarten wie Waren und Dienstleistungen zu verstehen. Bezugsquelle Wird häufig anhand des Positionstyps oder der Kategorie bestimmt, die bei der Erstellung der Bestellanforderung ausgewählt wurde. Der Wert kann in der Tabelle der Bestellanforderungspositionen POR_REQUISITION_LINES_ALL gespeichert sein. Beispiele WarenDienstleistungenInvestitionsausgaben
	Währung CurrencyCode	Der Währungscode für den Betrag der Bestellanforderung, etwa USD oder EUR.
Beschreibung Dieses Attribut gibt die Währung an, in der der Gesamtbetrag der Bestellanforderung ausgewiesen ist. In globalen Organisationen können Bestellanforderungen in verschiedenen Währungen erstellt werden. Für die korrekte Interpretation und Aggregation von Finanzdaten ist dieses Attribut unverzichtbar. Bei jeder Analyse von Geldwerten muss der Währungscode berücksichtigt werden, damit Beträge korrekt verglichen werden können, entweder durch die Filterung auf eine einzelne Währung oder durch die Umrechnung aller Beträge in eine gemeinsame Währung. Warum das wichtig ist Sichert eine korrekte Finanzanalyse und Berichterstattung, insbesondere in multinationalen Organisationen mit mehreren Währungen. Bezugsquelle Befindet sich typischerweise in der Tabelle mit den Kopfdaten der Bestellanforderung neben den Betragsfeldern, 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 Anforderung nach ihrer ursprünglichen Einreichung geändert wurde. Dazu wird geprüft, ob in der Historie des Cases eine Aktivität „Requisition Amended“ vorhanden ist. Dieses Kennzeichen vereinfacht die Analyse und die Berechnung von KPIs. Es wird direkt zur Berechnung des KPIs „Requisition Amendment Rate“ verwendet und identifiziert Cases, die nicht ohne Nachbearbeitung durch den Prozess gelaufen sind. Dadurch lassen sich Prozesskennzahlen für geänderte und nicht geänderte Anforderungen einfach filtern und vergleichen. Warum das wichtig ist Vereinfacht die Berechnung der Änderungsrate und ermöglicht einen einfachen Vergleich geänderter und nicht geänderter Anforderungen. Bezugsquelle Dieses Attribut ist im Quellsystem nicht vorhanden. Es wird während der Datentransformation anhand des Vorhandenseins änderungsbezogener Aktivitäten im Event Log berechnet. Beispiele truefalse

Erforderlich Empfohlen Optional

Purchase to Pay - Requisition: Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie für eine präzise Ermittlung Ihres Purchase-to-Pay-Prozesses für Bedarfsanforderungen im Event Log erfassen sollten.

6 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Anforderung eingereicht	Beschreibt die Aktion des Nutzers, mit der die ausgefüllte Bestellanforderung in den Genehmigungs-Workflow übergeben wird. Dieses Ereignis wird erfasst, wenn sich der Status der Bestellanforderung von „Incomplete“ oder „Draft“ in einen Status ändert, der auf eine ausstehende Genehmigung hinweist.
Warum das wichtig ist Diese Aktivität löst den Genehmigungszyklus aus. Sie ist ein wichtiger Meilenstein zur Messung der Genehmigungsdurchlaufzeit von Bestellanforderungen und der gesamten Durchlaufzeiten. Bezugsquelle Abgeleitet aus einer Statusänderung in der Tabelle POR_REQUISITION_HEADERS_ALL, zum Beispiel wenn der Status auf „PENDING APPROVAL“ wechselt. Das Einreichungsdatum ist häufig ebenfalls ausdrücklich gespeichert. Erfassen Ermitteln Sie den Timestamp, an dem sich das Dokumentstatusfeld erstmals auf „Pending Approval“ ändert. Ereignistyp inferred
	Anforderung erstellt	Kennzeichnet den Beginn des Beschaffungsprozesses, wenn ein Nutzer eine neue Bestellanforderung erstmals speichert. Dieses Ereignis wird im System in der Regel als expliziter Datensatz mit zugehörigem Timestamp erfasst.
Warum das wichtig ist Dies ist das zentrale Start-Ereignis des Requisitionsprozesses. Die Analyse der Zeit von der Erstellung bis zur Einreichung kann Verzögerungen bei der Formalisierung der Anforderung sichtbar machen. Bezugsquelle Dieses Ereignis wird in der Tabelle POR_REQUISITION_HEADERS_ALL erfasst, und zwar aus der Spalte creation_date, sobald eine neue Requisition-ID generiert wird. Erfassen Verwenden Sie den Timestamp der Erstellung für den Datensatz des Requisitionskopfs. Ereignistyp explicit
	Bestellanforderung abgelehnt	Stellt die endgültige Ablehnung der Bestellanforderung dar und beendet den Prozess für diesen Antrag. Erkannt wird dies, wenn der Gesamtstatus der Bestellanforderung auf „Rejected“ aktualisiert wird.
Warum das wichtig ist Diese Aktivität ist ein Endpunkt für erfolglose Anträge. Die Analyse dieser Fälle ist entscheidend, um die KPI zur Ablehnungsrate von Bestellanforderungen und die Gründe für das Scheitern zu verstehen. Bezugsquelle Abgeleitet aus der Änderung des Dokumentstatus in der Tabelle POR_REQUISITION_HEADERS_ALL auf „REJECTED“. Erfassen Ermitteln Sie den Timestamp, an dem der Dokumentstatus erstmals auf „Rejected“ gesetzt wird. Ereignistyp inferred
	Bestellanforderung genehmigt	Kennzeichnet die abschließende Genehmigung der Bestellanforderung, nachdem sie alle Workflow-Schritte erfolgreich durchlaufen hat. Abgeleitet wird dies aus der Änderung des Gesamtstatus der Bestellanforderung auf „Approved“.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein und zeigt an, dass der Antrag für die Beschaffung bereit ist. Er markiert den Endpunkt für die Messung der gesamten Genehmigungsdurchlaufzeit der Bestellanforderung. Bezugsquelle Abgeleitet aus der Änderung des Dokumentstatusfelds in der Tabelle POR_REQUISITION_HEADERS_ALL auf „APPROVED“. Das Datum dieser Statusänderung ist der Ereigniszeitpunkt. Erfassen Ermitteln Sie den Timestamp, an dem der Dokumentstatus erstmals auf „Approved“ gesetzt wird. Ereignistyp inferred
	Bestellanforderung geschlossen	Kennzeichnet den endgültigen Abschluss des Lebenszyklus einer Bestellanforderung. Alle Zeilen wurden erfüllt, zum Beispiel in Bestellungen umgewandelt, oder storniert. Abgeleitet wird dies aus einer abschließenden Statusaktualisierung.
Warum das wichtig ist Dies ist das zentrale erfolgreiche Endereignis des Prozesses. Es bestätigt, dass die Bestellanforderung vollständig bearbeitet wurde und keine weiteren Maßnahmen erforderlich sind. Bezugsquelle Abgeleitet aus der Änderung des Status der Bestellanforderung in POR_REQUISITION_HEADERS_ALL auf „CLOSED“. Erfassen Ermitteln Sie den Timestamp, an dem sich der Dokumentstatus der Bestellanforderung auf „Closed“ ändert. Ereignistyp inferred
	Bestellung erstellt	Dieses Ereignis tritt ein, wenn aus einer genehmigten Bestellanforderungszeile eine Bestellung erstellt wird. Es verbindet den Prozess der Bestellanforderung mit dem nachgelagerten Beschaffungsprozess.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein zur Messung der Durchlaufzeit von der Bestellanforderung bis zur Bestellung. Verzögerungen an dieser Stelle weisen auf Engpässe bei der Übergabe von der Genehmigung an den Einkauf hin. Bezugsquelle Dies ist ein ausdrückliches Ereignis. Die Verbindung zwischen Bestellanforderung und Bestellung wird in Tabellen wie PO_LINE_LOCATIONS_ALL gespeichert, die eine Referenz auf die ID der ursprünglichen Bestellanforderungszeile enthält. Erfassen 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 ihrer ersten Einreichung geändert hat. Häufig muss der Genehmigungsprozess dadurch neu gestartet werden. Erkannt wird dies anhand von Änderungen an wichtigen Datenfeldern oder durch die Erstellung einer neuen Version der Bestellanforderung.
Warum das wichtig ist Häufige Änderungen weisen auf Probleme mit der Datenqualität oder veränderte Anforderungen hin und führen zu Nacharbeit sowie Verzögerungen im Prozess. Dies unterstützt direkt die KPI „Änderungsrate von Bestellanforderungen“. Bezugsquelle Abgeleitet aus der Nachverfolgung der Versionsnummern der Bestellanforderung oder aus Statusänderungen zurück auf „Incomplete“ nach der Einreichung. Änderungsprotokolle oder Tabellen mit Audit-Trail können diese Änderungen ebenfalls erfassen. Erfassen Ermitteln Sie die Timestamps der Erstellung neuer Versionen für dieselbe Requisition ID, nachdem sie eingereicht wurde. Ereignistyp inferred
	Bestellanforderung zurückgezogen	Tritt ein, wenn der Anforderer eine eingereichte Bestellanforderung storniert oder zurückzieht, bevor sie vollständig genehmigt wurde. In der Regel handelt es sich um eine ausdrückliche Benutzeraktion, die eine Statusänderung auslöst.
Warum das wichtig ist Die Nachverfolgung zurückgezogener Bestellanforderungen hilft dabei, Gründe für einen vorzeitigen Abbruch zu erkennen, etwa geänderte Geschäftsanforderungen oder die Korrektur von Fehlern durch Benutzer nach der Einreichung. Bezugsquelle Abgeleitet aus einer Statusänderung auf „WITHDRAWN“ in der Tabelle POR_REQUISITION_HEADERS_ALL. Die Aktion wird in der Aktionshistorie der Bestellanforderung protokolliert. Erfassen Ermitteln Sie den Timestamp, an dem der Status der Bestellanforderung auf „Withdrawn“ aktualisiert wird. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Ein einzelner Genehmiger lehnt die Bestellanforderung ab. Dadurch wird sie in der Regel zur Korrektur an den Ersteller zurückgesendet oder der Antrag beendet. Diese Aktion wird ausdrücklich in der Workflow-Historie erfasst.
Warum das wichtig ist Diese Aktivität ist ein wesentlicher Treiber für Nacharbeit und Verzögerungen. Die Analyse von Ablehnungen hilft dabei, Compliance-Probleme, Budgetprobleme oder unklare Begründungen zu erkennen. Bezugsquelle Erfasst aus der Aktionshistorie der Genehmigung einer Bestellanforderung. Das Workflow-System protokolliert eine „REJECT“-Aktion mit Timestamp. Erfassen Verwenden Sie den Timestamp der Aktion „REJECT“ aus dem Protokoll der Workflow-Aktionshistorie. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Stellt die Genehmigungsaktion eines einzelnen Genehmigers für die Bestellanforderung in der ihm zugewiesenen Workflow-Stufe dar. Das Ereignis wird ausdrücklich in der Genehmigungshistorie protokolliert.
Warum das wichtig ist Die Nachverfolgung einzelner Genehmigungsschritte hilft dabei, den tatsächlichen Genehmigungspfad abzubilden und die Bearbeitungszeit auf jeder Hierarchiestufe zu messen. Bezugsquelle Erfasst aus der Aktionshistorie der Genehmigung einer Bestellanforderung, die typischerweise in Workflow-Tabellen (WF) oder Tabellen des Human Capital Management (HCM) zur Verwaltung von Genehmigungshierarchien gespeichert wird. Erfassen Verwenden Sie den Timestamp der Aktion „APPROVE“ aus dem Protokoll der Workflow-Aktionshistorie. Ereignistyp explicit
	Genehmigungsschritt gestartet	Kennzeichnet den Zeitpunkt, an dem eine Bestellanforderung einem bestimmten Genehmiger oder einer Genehmigungsgruppe im Workflow zugewiesen wird. Diese Information stammt aus dem Transaktionsprotokoll der Workflow-Engine.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung der Wartezeit je Genehmigungsschritt. Sie hilft dabei, Engpässe zu lokalisieren, die durch bestimmte Genehmiger oder Genehmigungsstufen entstehen. Bezugsquelle Wird aus den Workflow-Tabellen von Oracle Fusion abgerufen, in denen den Benutzern zugewiesene Aufgaben protokolliert werden. Verwendet wird der Zuweisungs-Timestamp der Genehmigungsaufgabe. Erfassen Verwenden Sie den Erstellungs-Timestamp der Aufgabe in der Workflow-Historie für die betreffende Bestellanforderung. Ereignistyp explicit
	Genehmigungsschritt zurückgesendet	Ein Genehmiger sendet die Bestellanforderung wegen zusätzlicher Informationen oder kleinerer Korrekturen an den Ersteller zurück, ohne sie formell abzulehnen. In der Regel handelt es sich um eine ausdrückliche Aktion im Workflow-System.
Warum das wichtig ist Dies weist auf Klärungsbedarf hin und erzeugt eine Nacharbeitsschleife, die die Durchlaufzeit verlängert. Die Unterscheidung zwischen Rücksendungen und Ablehnungen liefert tiefere Erkenntnisse über Reibungspunkte im Prozess. Bezugsquelle Erfasst aus der Aktionshistorie der Genehmigung einer Bestellanforderung. Das Workflow-System protokolliert eine „RETURN“-Aktion oder eine vergleichbare Aktion mit Timestamp. Erfassen Verwenden Sie den Timestamp der Aktion „RETURN“ oder „Request for Information“ aus der Workflow-Historie. Ereignistyp explicit

Extraktionsanleitungen

So beziehen Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Navigieren Sie zu Reports and Analytics: Melden Sie sich bei Oracle Fusion Financials an. Öffnen Sie im Navigator-Menü zunächst Tools und wählen Sie anschließend Reports and Analytics. Dies ist die zentrale Anlaufstelle für alle Reporting-Aktivitäten.
Erstellen Sie eine neue Analyse: Klicken Sie im Arbeitsbereich Reports and Analytics auf die Schaltfläche „Create“ und wählen Sie im Dropdown-Menü „Analysis“. Dadurch wird der Editor für Oracle Transactional Business Intelligence (OTBI) in einem neuen Tab geöffnet.
Wählen Sie den Subject Area aus: Sie werden aufgefordert, einen Subject Area auszuwählen. Geben Sie im Suchfeld „Procurement - Requisitions Real Time“ ein und wählen Sie den Eintrag aus der Liste. Dieser Subject Area enthält alle erforderlichen Datenpunkte für Ereignisse im Lebenszyklus einer Anforderung.
Erstellen Sie die Analyse für Anforderungsereignisse: In diesem Schritt erstellen Sie eine Union mehrerer Abfragen, um jedes einzelne Ereignis zu erfassen. Da die OTBI-Oberfläche keine direkte UNION-ALL-Funktion für unterschiedliche Ereignistypen bietet, erstellen Sie einen einzelnen Bericht, der alle relevanten Datums- und Statusfelder abruft. 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 Spalten für Erstellungsdatum, Einreichungsdatum, Genehmigungsdatum und Erstellungsdatum der Bestellung.
Fügen Sie die Aktionshistorie der Anforderung hinzu: Um detaillierte Genehmigungsschritte wie Approved, Rejected, Returned und Withdrawn zu erfassen, müssen Sie Felder aus dem Ordner „Requisition Action History“ innerhalb des Subject Area einbeziehen. Ziehen Sie „Action Date“, „Action“ und „Performer“ in die ausgewählten Spalten.
Konfigurieren Sie Filter: Wechseln Sie zum Tab „Prompts“, um Filter für Ihre Analyse zu erstellen. Begrenzen Sie das Datenvolumen unbedingt durch einen Datumsbereich. Erstellen Sie einen Filter für „Requisition Header“ und „Requisition Creation Date“ und legen Sie beispielsweise die letzten sechs Monate fest. Zusätzlich können Sie Prompts für „Business Unit“ oder „Requester Name“ hinzufügen, um die Daten weiter einzugrenzen.
Führen Sie den Bericht aus und prüfen Sie ihn: Wechseln Sie zum Tab „Results“, um die Analyse auszuführen und die Daten in der Vorschau anzuzeigen. Die Ausgabe ist eine breite Tabelle mit einer Zeile pro Anforderungsposition oder Genehmigungsaktion sowie mehreren Datums- und Statusspalten.
Exportieren Sie die Rohdaten: Wenn Sie mit der Vorschau zufrieden sind, klicken Sie auf den Link „Export“, der sich normalerweise am unteren Rand der Ergebnisseite befindet. Wählen Sie als Format „Data“ > „CSV File“. Dadurch werden die Rohdaten Ihrer Analyse heruntergeladen.
Transformieren Sie die Daten in das Event-Log-Format: Die exportierte CSV-Datei liegt in einem breiten Format vor. Sie müssen ein externes Tool, etwa ein Python-Skript, Power Query in Excel oder ein anderes Datenaufbereitungstool, verwenden, um die Daten zu transformieren. Dabei werden die Datumsspalten in eine einzelne Spalte „EventTime“ entpivotiert und für jeden Ereignistyp eine entsprechende Spalte „ActivityName“ erstellt, etwa „Requisition Created“ oder „Requisition Submitted“.
Schließen Sie die Vorbereitung für den Upload ab: Stellen Sie nach der Transformation sicher, dass die Datei die erforderlichen Spalten PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate enthält. Speichern Sie das fertige Event Log als CSV-Datei. Anschließend können Sie es in ProcessMind hochladen.

Konfiguration

Subject Area: Der primäre zu verwendende Subject Area ist „Procurement - Requisitions Real Time“. Er enthält die zentralen Informationen zu Anforderungskopf, Positionen, Verteilungen und Genehmigungshistorie.
Datumsbereich: Wenden Sie immer einen verpflichtenden Datumsfilter an, um das Datenvolumen zu begrenzen und die Leistung zu verbessern. Ein Filter für „Requisition Header“ und „Requisition Creation Date“ über die letzten drei bis sechs Monate ist ein guter Ausgangspunkt.
Wichtige Filter: Erwägen Sie Filter für „Requisition Header“ und „Business Unit“ sowie für „Requisition Header“ und „Requisition Status“, um die Extraktion auf relevante Organisationseinheiten zu konzentrieren und nicht benötigte Statuswerte wie „Canceled“ auszuschließen.
Spaltenauswahl: Wählen Sie die Spalten für Ihre Analyse gezielt aus. Zu viele Spalten, insbesondere aus zahlreichen unterschiedlichen Ordnern (Dimensionen), können die Leistung beeinträchtigen. Konzentrieren Sie sich auf die für das Event Log erforderlichen Felder.
Berechtigungen: Der Benutzer, der die Extraktion ausführt, benötigt eine Rolle mit den erforderlichen Berechtigungen für den Arbeitsbereich Reports and Analytics und den Subject Area „Procurement - Requisitions Real Time“. Typischerweise verfügen Rollen wie „BI Author“ oder „Procurement Analyst“ über diese Berechtigungen.

a 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 Benutzer bei Oracle Fusion Financials an, der über BI-Author- oder vergleichbare Berechtigungen verfügt.
Öffnen Sie den Arbeitsbereich Reports and Analytics, indem Sie auf das Navigator-Symbol klicken und anschließend Tools > Reports and Analytics auswählen.
Klicken Sie auf die Schaltfläche „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.
In den Eigenschaften des Data Model können Sie einen Namen und eine Beschreibung angeben. 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, etwa Requisition_Event_Log, wählen Sie die passende Data Source für Ihre Financials-Daten aus, etwa ApplicationDB_FSCM, und setzen Sie den SQL-Typ auf „Standard SQL“.
Kopieren Sie das vollständige SQL-Skript aus dem Abschnitt „query“ dieses Dokuments und fügen Sie es in den Textbereich „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 Data Model in einem geeigneten Katalogordner, etwa Shared Folders/Custom.
Wechseln Sie für den Datenexport zurück zum Katalog, klicken Sie auf „New“ und wählen Sie „Report“. Verknüpfen Sie den neuen Bericht mit dem gerade erstellten Data Model.
Führen Sie den Bericht aus und geben Sie die Parameter für Start- und Enddatum an. Sobald der Bericht die Daten anzeigt, verwenden Sie die Funktion „Export“, um die Ergebnisse als CSV-Datei herunterzuladen.
Stellen Sie sicher, dass die fertige CSV-Datei mit UTF-8-Kodierung gespeichert ist und die für die Aufnahme in Ihr Process-Mining-Tool erforderlichen Kopfzeilen enthält.

Konfiguration

Datenquelle: Die BI-Publisher-Data-Source, die typischerweise ApplicationDB_FSCM oder ähnlich heißt, muss mit einem Benutzer konfiguriert sein, der Lesezugriff auf alle in der Abfrage verwendeten Tabellen besitzt, einschließlich der Tabellen aus Procurement (POR, PO), Human Capital Management (PER, HR) und Financials (FUN).
Filterung nach Datumsbereich: Die Abfrage verwendet verpflichtende Datumsparameter (:p_start_date und :p_end_date), die nach dem Erstellungsdatum der Anforderung filtern. Bei ersten Extraktionen oder großen Systemen ist es wichtig, die Daten in überschaubaren Paketen zu extrahieren, beispielsweise jeweils für drei bis sechs Monate, um Zeitüberschreitungen des Systems zu vermeiden.
Filterung nach Geschäftseinheit: Ein Filter für den Namen der Geschäftseinheit ist in einem auskommentierten Abschnitt der WHERE-Klausel der Abfrage enthalten. Es wird dringend empfohlen, diesen Filter zu aktivieren und für die Analyse relevanten Geschäftseinheiten zu konfigurieren. Dadurch kann die Leistung deutlich verbessert werden.
Voraussetzungen: Der Benutzer, der den Bericht erstellt und ausführt, benötigt eine Rolle mit BI-Publisher-Berechtigungen, etwa „BI Administrator Role“ oder „BI Author Role“. Zusätzlich sind die erforderlichen Datensicherheitsberechtigungen für den Zugriff auf die Einkaufsdaten erforderlich.

a 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 in Ihrem Terminal: pip install requests. Außerdem benötigen Sie API-Zugangsdaten, also Benutzername und Passwort, für einen Oracle-Fusion-Benutzer mit ausreichenden Leseberechtigungen für Daten zu Einkaufsanforderungen sowie die Basis-URL Ihrer Oracle-Fusion-Instanz.
Speichern Sie das Python-Skript: Speichern Sie den vollständigen Python-Code aus dem Abschnitt „query“ beispielsweise als Datei extract_requisitions.py.
Konfigurieren Sie die Skriptparameter: Öffnen Sie die Skriptdatei in einem Texteditor. Ersetzen Sie die Platzhalterwerte am Anfang des Skripts. Setzen Sie FUSION_URL, USERNAME und PASSWORD entsprechend Ihrer Oracle-Fusion-Umgebung. Passen Sie START_DATE und END_DATE an, um den Extraktionszeitraum festzulegen.
Verstehen Sie API-Endpunkte und Felder: Das Skript verwendet die REST-API-Ressource purchaseRequisitions. Über den Parameter fields werden nur die erforderlichen Daten angefordert, darunter verschachtelte Sammlungen wie lines für Bestellinformationen und actionHistory für Genehmigungsereignisse. Das verbessert die Leistung.
Führen Sie das Skript aus: Starten Sie das Skript in Ihrem Terminal mit dem Befehl python extract_requisitions.py. Das Skript authentifiziert sich bei der API, beginnt mit dem Abruf der Daten und zeigt im Terminal den Fortschritt an, einschließlich der Anzahl bereits verarbeiteter Anforderungen.
Verarbeiten Sie die Seitennavigation: Das Skript verarbeitet die Seitennavigation automatisch. Die Oracle Fusion REST API liefert die Daten in Blöcken, also Seiten. Das Skript prüft das Flag hasMore in jeder Antwort und sendet wiederholt Anfragen mit einem aktualisierten Parameter offset, bis alle Anforderungen im angegebenen Datumsbereich abgerufen wurden.
Logik der Datentransformation: Für jede über die API abgerufene Anforderung erzeugt das Skript mehrere Zeilen im Event Log. Aus CreationDate wird das Ereignis „Requisition Created“ erstellt, aus SubmittedDate das Ereignis „Requisition Submitted“. Außerdem durchläuft das Skript die Sammlung actionHistory und erstellt detaillierte Ereignisse für jeden Genehmigungsschritt, etwa Started, Approved, Rejected und Returned.
Leiten Sie Ereignisse für den finalen Status ab: Das Skript erfasst abschließende Ereignisse wie „Requisition Approved“ und „Requisition Rejected“, indem es den finalen DocumentStatus der Anforderung prüft und LastUpdateDate als Ereigniszeitpunkt verwendet.
Erzeugen Sie das Ereignis für die Bestellung: Das Skript prüft jede Anforderungsposition. Enthält eine Position eine PoHeaderId, weist dies auf die Erstellung einer Bestellung hin. Für diese Aktivität wird ein Eintrag im Event Log erzeugt, der die Anforderung mit dem nachgelagerten Einkaufsprozess verknüpft.
Prüfen Sie die Ausgabedatei: Nach Abschluss des Skripts wird im selben Verzeichnis eine CSV-Datei mit dem Namen oracle_fusion_requisitions_event_log.csv erstellt. Diese Datei enthält das extrahierte Event Log.
Bereiten Sie den Upload vor: Öffnen Sie die erzeugte CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie ihren Inhalt. Stellen Sie sicher, dass Spalten und Datenformate den Anforderungen Ihres Process-Mining-Tools entsprechen. Danach kann die Datei in ProcessMind hochgeladen werden.

Konfiguration

API-Zugangsdaten: Erforderlich ist ein dediziertes Integrationsbenutzerkonto mit einer Rolle, die schreibgeschützten Zugriff auf die REST API für Purchase Requisitions 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.
Filter für den Datumsbereich: Das Skript enthält die Variablen START_DATE und END_DATE. Es wird dringend empfohlen, die Daten in überschaubaren Paketen zu extrahieren, beispielsweise jeweils für drei bis sechs Monate, um API-Zeitüberschreitungen und Leistungseinbußen zu vermeiden. Der Filter wird auf CreationDate der Anforderungen angewendet.
Feldauswahl: Der Parameter fields im Skript ist für die Leistung entscheidend. Er begrenzt die Antwort auf die für das Event Log erforderlichen Attribute und reduziert dadurch Netzwerkverkehr und Verarbeitungszeit. Entfernen Sie keine erforderlichen Felder wie RequisitionId, CreationDate, actionHistory oder lines.
Limit der Seitengröße: Der Parameter limit ist auf 100 gesetzt, ein für die meisten Umgebungen geeigneter Wert. Sie können den Wert auf 200 oder 500 erhöhen, um die Extraktion möglicherweise zu beschleunigen. Bei zu hohen Werten müssen Sie jedoch mögliche Speicherprobleme oder API-Limits berücksichtigen.

a 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

Bestätigen Sie, dass Oracle BI Cloud Connector, die erforderlichen Oracle-Fusion-Financials-Inhalte für den Einkauf 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 zur Extraktion von Anforderungs-, Genehmigungshistorien- und Bestelldaten berechtigt ist. Die genauen Rollennamen und Navigationsbezeichnungen unterscheiden sich je nach Oracle-Version. Verwenden Sie daher den entsprechenden BICC-Administrationsbereich in Ihrem Mandanten.
Identifizieren und aktivieren Sie die für die Extraktion erforderlichen PVOs. Verwenden Sie RequisitionHeaderPVO oder das entsprechende Anforderungskopf-PVO in Ihrer Umgebung sowie die PVOs, die Anforderungspositionen, die Statushistorie der Anforderung, die Historie des Genehmigungs-Workflows und Bestellreferenzen bereitstellen. Gehen Sie nicht davon aus, dass ein einzelnes PVO die Workflow-Historie oder die Historie der Bestellungserstellung enthält. Dokumentieren Sie die in Ihrem Mandanten verfügbaren PVO-Namen und Attribute.
Konfigurieren Sie einen BICC-Auftrag für eine inkrementelle oder historische Massenextraktion. Legen Sie das Extraktionsfenster mit [Start date parameter] und [End date parameter] fest und konfigurieren Sie den Auftrag so, dass CSV-Dateien am freigegebenen Cloud-Speicherort bereitgestellt werden. Verwenden Sie für die Erstbefüllung einen ausreichend großen historischen Zeitraum. Verwenden Sie bei wiederkehrenden Ladevorgängen überlappende Zeitfenster, um verspätete Aktualisierungen zu berücksichtigen. Entfernen Sie anschließend Duplikate anhand der Case-ID, Aktivität, Ereigniszeit und, sofern verfügbar, der Quellereignis-ID.
Konfigurieren Sie die Extraktionsspalten. Nehmen Sie die Kennung der Anforderung, die IDs von Anforderungskopf und -position, Anforderer, Abteilung, Betrag, Status, benötigtes Datum, Geschäftseinheit, Ablehnungsgrund, Erstellungs- und Aktualisierungszeitpunkte, Zeitpunkte von Statusübergängen, Zeitpunkte der Genehmigungszuweisung und -aktion, Genehmigungsaktion, Bestellreferenz sowie den BICC-Aktualisierungszeitpunkt auf. Verwenden Sie die exakten 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 Quell-CSV-Dateien und bewahren Sie die Originaldateien auf. Laden Sie jede Datei in einen Staging-Bereich, speichern Sie den Namen des Quell-PVOs und den Dateinamen, vereinheitlichen Sie die Timestamps auf eine abgestimmte Zeitzone und verarbeiten Sie Oracle-Datums- und Timestamp-Werte einheitlich. Behandeln Sie IDs als Zeichenfolgen, damit führende Nullen und die Genauigkeit nicht verloren gehen.
Formen Sie die Quelldaten in eine Ereignistabelle mit einer Zeile pro explizitem Geschäftsvorfall 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 Transformation muss für alle zwölf in der Abfrage aufgeführten Aktivitäten ausdrücklich Zeilen erzeugen.
Erstellen Sie die Ereigniszeilen anhand der passenden Quellnachweise. Verwenden Sie den Nachweis der Datensatzerstellung für Requisition Created, einen expliziten Einreichungsübergang für Requisition Submitted, eine explizite Rücknahmeaktion oder einen entsprechenden Übergang für Requisition Withdrawn, eine erkannte Änderung nach der Einreichung oder eine neue Version für Requisition Amended, die Workflow-Zuweisung für Approval Step Started und explizite Aktionen aus der Genehmigungshistorie für Approval Step Approved, Approval Step Rejected und Approval Step Returned. Verwenden Sie einen expliziten Übergang des Gesamtstatus für Requisition Approved, Requisition Rejected und Requisition Closed. Verwenden Sie für Purchase Order Created einen expliziten Datensatz zur Bestellungserstellung oder einen mit der Anforderung verknüpften Erstellungszeitpunkt.
Wenden Sie eine deterministische Duplikatbereinigung an. Wenn mehrere Quellzeilen dasselbe Ereignis darstellen, behalten Sie eine Zeile mit dem spezifischsten Ereigniszeitpunkt und, sofern verfügbar, einer stabilen Quellkennung. Fassen Sie unterschiedliche Genehmigungsschritte nicht allein deshalb zusammen, weil sie dieselbe Anforderungskennung besitzen. Bewahren Sie separate Genehmigungsereignisse für unterschiedliche Genehmiger oder Workflow-Schritte auf.
Validieren Sie das resultierende Event Log. Prüfen Sie, ob jede erforderliche Aktivität vertreten ist, jedes Ereignis eine Case-ID und einen Ereigniszeitpunkt besitzt, die Timestamps innerhalb des Extraktionsfensters liegen oder durch verspätet eingegangene Aktualisierungen erklärt werden und die empfohlenen Attribute ausgefüllt sind, sofern die Quelle sie bereitstellt. Stimmen Sie die Anzahl der Anforderungen und die Verknüpfungen zu Bestellungen mit den Quell-Extraktionen ab.
Exportieren Sie das fertige Event Log als UTF-8-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 Ereigniszeitpunkt.

Konfiguration

Extraktionsmethode: Oracle BI Cloud Connector für den Massenexport von Daten. Die Daten werden als CSV-Dateien am konfigurierten Cloud-Speicherort abgelegt.
Quellobjekte: Verwenden Sie RequisitionHeaderPVO sowie die im Mandanten verfügbaren PVOs für die zugehörige Anforderungszeile, Statushistorie, Genehmigungs-Workflow-Historie und Bestellreferenz. Die genauen PVO-Namen und Attribute müssen in der Umgebung bestätigt werden.
Erforderliche Ausgabespalten: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate.
Empfohlene Ausgabespalten: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason und BusinessUnit.
Datumsbereich: Verwenden Sie für routinemäßige Analysen drei bis sechs Monate. Für einen erstmaligen historischen Ladevorgang kann bei Bedarf ein größerer Zeitraum erforderlich sein. Verwenden Sie bei wiederkehrenden Extraktionen überlappende Zeitfenster, 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 diese Attribute in den ausgewählten PVOs verfügbar sind. Bestätigen Sie, ob der Filter für das Erstellungsdatum, das Aktualisierungsdatum, das Datum des Statuswechsels oder ein anderes Quelldatum gilt.
Inkrementelle Extraktion: Bevorzugen Sie einen Aktualisierungszeitstempel oder einen von BICC bereitgestellten Mechanismus für die inkrementelle Extraktion. Speichern Sie den Zeitstempel der letzten erfolgreichen Extraktion und berücksichtigen Sie beim nächsten Lauf eine kleine Überlappung.
Vollständigkeit der Ereignisse: Konfigurieren Sie separate Quell-Extraktionen, wenn die Anforderungs-Header keine Genehmigungshistorie, Statuswechsel, Änderungen oder die Erstellung von Bestellungen enthalten. Ein reiner Header-Export mit dem aktuellen Status kann historische Ereignisse nicht zuverlässig rekonstruieren.
Performance: Begrenzen Sie den Datumsbereich und die ausgewählten Spalten, partitionieren Sie große Extraktionen, sofern unterstützt, vermeiden Sie unnötige beschreibende Attribute und verarbeiten Sie CSV-Dateien stapelweise. Bewahren Sie die Quelldateien für den Abgleich auf.
Speicherung: Konfigurieren Sie einen freigegebenen Cloud-Speicherort mit ausreichender Kapazität sowie geeigneten Aufbewahrungs-, Verschlüsselungs- und Zugriffskontrollen. Bestätigen Sie, dass 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 ein erforderliches Oracle-Abonnement oder eine entsprechende Funktionsberechtigung. Die genauen Rollennamen, Lizenzen und Navigationspfade hängen vom Oracle-Release und der Mandantenkonfiguration ab.
Zeitverarbeitung: Normalisieren Sie alle Quellzeitstempel auf eine dokumentierte Zeitzone und bewahren Sie den ursprünglichen Zeitstempel auf, wenn dies für die Nachvollziehbarkeit erforderlich ist.
Case-Verarbeitung: Verwenden Sie PurchaseRequisitionId als Case-Kennung. Verwenden Sie keine Kennung einer Anforderungszeile als Case-Kennung, es sei denn, der Prozess wird bewusst auf Zeilenebene modelliert.

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

Bereit für den Start?

Verwenden Sie dieses Template als Ausgangspunkt für die Optimierung Ihres Purchase-to-Pay-Prozesses für Anforderungen und für neue Effizienzgewinne. Bereiten Sie sich darauf vor, Ihre Einkaufsprozesse weiterzuentwickeln.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Erreichen Sie 30 % schnellere Purchase-to-Pay-Prozesse für Anforderungen

Straffen Sie Ihren Oracle-P2P-Prozess für Anforderungen und verkürzen Sie die Durchlaufzeit um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, Einrichtung in wenigen Minuten.

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

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

Purchase to Pay - Requisition: Attribute

Purchase to Pay - Requisition: Aktivitäten

Extraktionsanleitungen

Export über Oracle Transactional Business Intelligence (OTBI)

Schritte

Konfiguration

a Beispielabfrage sql

SQL-basierte Datenmodell-Extraktion mit Oracle BI Publisher

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript über die Oracle Fusion REST API

Schritte

Konfiguration

a Beispielabfrage python

Massenextraktion mit Oracle BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage sql

Bereit für den Start?

Erreichen Sie 30 % schnellere Purchase-to-Pay-Prozesse für Anforderungen

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

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

Purchase to Pay - Requisition: Attribute

Purchase to Pay - Requisition: Aktivitäten

Extraktionsanleitungen

Export über Oracle Transactional Business Intelligence (OTBI)

Schritte

Konfiguration

a Beispielabfrage sql

SQL-basierte Datenmodell-Extraktion mit Oracle BI Publisher

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript über die Oracle Fusion REST API

Schritte

Konfiguration

a Beispielabfrage python

Massenextraktion mit Oracle BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage sql

Bereit für den Start?

Erreichen Sie 30 % schnellere Purchase-to-Pay-Prozesse für Anforderungen

Ihre Privatsphäre ist uns wichtig