> Kontinuierliche Prozessoptimierung > Purchase to Pay – Purchase Requisition > Oracle Fusion Financials > Datenvorlage

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Oracle Fusion Financials

Purchase-to-Pay – Purchase Requisitions-Attribute (22) Purchase-to-Pay – Purchase Requisitions-Aktivitäten (12) Extraktionsanleitungen (4)

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Diese Vorlage dient als strukturierter Leitfaden für die Erfassung der relevanten Daten, die zur Analyse Ihres Procure-to-Pay-Anforderungsprozesses erforderlich sind. Sie skizziert die zu sammelnden Schlüsselattribute, die zu verfolgenden kritischen Aktivitäten und praktische Anleitungen zur Extraktion dieser Informationen aus Oracle Fusion Financials. Damit können Sie Ihr Event Log effektiv für ein fundierte Process-Mining-Analysen vorbereiten.

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

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

Vorlage herunterladen

Purchase-to-Pay – Purchase Requisitions-Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log (Event Log) aufnehmen sollten, um eine vollständige Analyse des Procure-to-Pay-Anforderungsprozesses zu ermöglichen.

5 Erforderlich 7 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des Geschäfts-Ereignisse, das zu einem bestimmten Zeitpunkt im Anforderungsprozess aufgetreten ist.
Beschreibung Die Aktivität stellt einen separaten Schritt oder Meilenstein im Lebenszyklus der Purchase Requisition dar. Beispiele hierfür sind 'Anforderung erstellt', 'Genehmigungsschritt genehmigt' oder 'Bestellung erstellt'. Diese Aktivitäten werden aus Statusänderungen, Benutzeraktionen oder Systemereignissen abgeleitet, die in den Audit-Logs oder Transaktionstabellen des Quellsystems aufgezeichnet wurden.\n\nDieses Attribut ist wichtig für die Erstellung der Prozessablauf, die den Fluss der Anforderungen visuell darstellt. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten hilft, gängige Prozesspfade, Engpässe, Nacharbeitsschleifen und Abweichungen vom Standardverfahren zu identifizieren. Bedeutung Es ist die Basis der Prozessablauf und ermöglicht die Visualisierung und Analyse des Purchase Requisitions-Workflows. Datenquelle Abgeleitet aus StatusänderungsDatensätzen in Tabellen wie POR_REQUISITION_HEADERS_ALL, der Transaktionshistorie oder Workflow-Audit-Trails wie FA_FUSION_SOAINFRA.WFTASK. Beispiele Anforderung erstelltGenehmigungsschritt genehmigtPurchase Requisition abgelehntBestellung erstellt
	Ereigniszeit EventTime	Der Zeitstempel, der angibt, wann die Aktivität stattfand.
Beschreibung Die Event Time (Ereigniszeit) erfasst das genaue Datum und die Uhrzeit, zu der eine spezifische Aktivität stattfand. Dieser Zeitstempel ist wesentlich für die chronologische Anordnung von Ereignisse innerhalb eines Case und wird aus ErstellungsDaten, letzten AktualisierungsDaten oder spezifischen Aktions-Zeitstempels im System bezogen.\n\nIn der Analyse wird die Event Time verwendet, um alle zeitbasierten Kennzahlen zu berechnen, wie z.B. Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und die gesamte Case-Dauer. Sie ist maßgeblich für die Identifizierung von Engpässe, die Messung der Leistungsfähigkeit anhand von SLAs und das Verständnis der zeitlichen Dynamik des Anforderungsprozesses. Bedeutung Dieses Attribut ist wesentlich für die Berechnung aller zeitbezogenen KPIs, die korrekte Anordnung von Ereignisse und die Analyse der Prozessleistung und von Engpässe. Datenquelle Dies wird in der Regel aus einer 'LAST_UPDATE_DATE'- oder 'CREATION_DATE'-Spalte bezogen, die mit der Transaktion oder Statusänderung verbunden ist, oft in Tabellen wie POR_REQUISITION_HEADERS_ALL oder Workflow-Verlauf-Tabellen gefunden. Beispiele 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	Purchase Requisitions-ID PurchaseRequisitionId	Der eindeutige Identifikator für eine Purchase Requisition, der als Case-ID für den Prozess dient.
Beschreibung Die Purchase Requisitions-ID ist die zentrale Kennung, die alle Aktivitäten verknüpft, die sich auf eine spezifische Anfrage für Waren oder Dienstleistungen beziehen. Jeder Anforderung wird bei der Erstellung eine einzigartige ID zugewiesen, die während ihres gesamten Lebenszyklus konstant bleibt.\n\nIm Process Mining wird dieses Attribut verwendet, um alle zugehörigen Ereignisse, wie Erstellung, Einreichung, Genehmigungsschritte und endgültigen Abschluss, in einem einzigen Case zu gruppieren. Dies ermöglicht eine End-to-End-Analyse des Anforderungsweges, wodurch Prozessablaufn visualisiert, Durchlaufzeiten berechnet und Varianten für jede einzelne Anfrage analysiert werden können. Bedeutung Dies ist das wesentliche Attribut zur Verfolgung des Lebenszyklus einer Anforderung von Anfang bis Ende, das alle Analysen auf Fallebene und KPI-Berechnungen ermöglicht. Datenquelle Dies ist in der Regel der Primärschlüssel in der Anforderungs-Header-Tabelle, wie z.B. POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID in Oracle Fusion Financials. Beispiele 100234810023491002350
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel der aktuellsten Datenaktualisierung aus dem Quellsystem.
Beschreibung Dieses Attribut gibt das Datum und die Uhrzeit an, zu der den Antrag bearbeitet.ie Daten zuletzt aus Oracle Fusion Financials extrahiert wurden. Es bezieht sich auf den gesamten Datensatz und nicht auf einzelne Ereignisse.\n\nAnalysten einsetzen diese Information, um die Aktualität der Daten zu verstehen und zu bestätigen, wann die neuesten Transaktionen eingeschlossen wurden. Es ist ein wichtiges MetaDatenelement für das Dashboard-Reporting und die Sicherstellung, dass Analysen auf aktuellen Informationen basieren. Bedeutung Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass Analysen relevant sind und auf den neuesten verfügbaren Informationen basieren. Datenquelle Dieser Zeitstempel wird während des Datenextraktionsprozesses generiert und gespeichert, in der Regel vom ETL-Tool oder den Antrag bearbeitet.er Datenpipeline. Beispiele 2023-10-27T02:00:00Z
	Quellsystem SourceSystem	Das Informationssystem, aus dem diese Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert den Ursprung der ProzessDaten. Für dieses Datenmodell wird es konsistent 'Oracle Fusion Financials' sein.\n\nIn Umgebungen mit mehreren ERPs oder integrierten Systemen ist dieses Feld wichtig für die Datenherkunft, Fehlerbehebung und Sicherstellung der Datenqualität. Es liefert Kontext zur Quelle der Wahrheit für die analysierten Prozess-Ereignisse. Bedeutung Bietet wesentlichen Kontext zur Datenherkunft, was wichtig für die Daten Governance und bei der Integration von Daten aus mehreren Systemen ist. Datenquelle Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion Financials
	Ablehnungsgrund RejectionReason	Der Grund, der von einem Genehmiger angegeben wird, wenn eine Anforderung oder ein Genehmigungsschritt abgelehnt wird.
Beschreibung Wenn eine Anforderung abgelehnt wird, gibt der Genehmiger in der Regel einen Grund an, entweder den Antrag bearbeitet.urch Auswahl aus einer vordefinierten Listee oder den Antrag bearbeitet.urch Eingabe von Freitext. Dieses Attribut erfasst diese Begründung.\n\nDies ist ein kritisches Attribut für die Ursachenanalyse von Prozessfehlern. Es unterstützt direkt das Dashboard 'Änderungs- und Ablehnungstrends', indem es das 'Warum' hinter Ablehnungen liefert. Die Analyse der Ablehnungsgründe hilft, gängige Probleme wie Neine Codierung, Budgetüberschreitungen oder Richtlinienverstöße zu identifizieren, die dann durch Schulungen oder Systemkontrollen angegangen werden können. Bedeutung Bietet direkte Einblicke, warum Anforderungen abgelehnt werden, und ermöglicht gezielte Verbesserungen zur Reduzierung von Nacharbeit und zur Erhöhung der Straight-Through-Processing-Rate. Datenquelle Abgeleitet aus Workflow-Kommentaren oder spezifischen Ablehnungsgrund-Codefeldern im Workflow-Audit-Trail, potenziell innerhalb von Tabellen, die mit FA_FUSION_SOAINFRA.WFTASK oder zugehörigem Kommentar-Speicher verknüpft. Beispiele Falsches GL-KontoÜberschreitet Budget für KostenstelleNicht bevorzugter Lieferant ausgewähltDoppelte Anfrage
	Abteilung DepartmentName	Die Geschäftsabteilung, der den Antrag bearbeitet.er Anforderer angehört.
Beschreibung Dieses Attribut gibt die Organisationseinheit der Person an, die die Anforderung erstellt hat, wie z.B. 'Finanzen', 'IT' oder 'Marketing'. Es wird in der Regel aus dem Benutzerprofil des Anforderers im HR-System abgeleitet.\n\nDie Analyse nach Abteilung ist eine gängige und leistungsstarke Methode zur Segmentierung von ProzessDaten. Sie hilft, abteilungsspezifische Verhaltensweisen zu identifizieren, wie z.B. höhere Ablehnungsraten oder längere Durchlaufzeiten, die als Grundlage für gezielte Prozessoptimierungsinitiativen dienen können. Dies ist eine Schlüsseldimension für das Dashboard 'Performance-Metriken der Anforderer'. Bedeutung Ermöglicht die Prozessanalyse segmentiert nach Geschäftseinheit, wodurch abteilungsspezifische Muster, Leistungsfähigkeit und Compliance-Verstöße aufgedeckt werden. Datenquelle Typischerweise aus dem Profil des Anforderers abgeleitet, erfordert oft einen Join von der Anforderungstabelle zu einer HR- oder Benutzerverzeichnis-Tabelle, die AbteilungsDaten enthält. Beispiele InformationstechnologieFinanzenOperationsMarketing
	Erforderliches Lieferdatum RequiredByDate	Das Datum, bis zu dem der Anforderer die Waren oder Dienstleistungen benötigt.
Beschreibung Dieses Datum wird vom Anforderer festgelegt, um die Frist für den Empfang der angefragten Artikel anzugeben. Es dient als internes Service Level Agreement (SLA)-Ziel für den Beschaffungsprozess.\n\nDieses Attribut ist die Grundlage für das Dashboard 'Leistung der Benötigt-bis-Datum' und den KPI 'Einhaltungsrate des Benötigt-bis-Datums'. Durch den Vergleich dieses Datums mit dem tatsächlichen Erstellungsdatum der Bestellung oder den Antrag bearbeitet.em Wareneingangsdatum kann die Analyse aufzeigen, wie gut der Beschaffungsprozess interne Kundenanforderungen erfüllt und systemische Verzögerungen identifiziert. Bedeutung Wesentlich für die Messung der Prozess-Leistungsfähigkeit im Vergleich zu internen Fristen und um zu verstehen, ob der Beschaffungsprozess die geschäftlichen Anforderungen zeitnah erfüllt. Datenquelle Wird normalerweise auf Positionsebene der Anforderung gespeichert, in Tabellen wie POR_REQUISITION_LINES_ALL in einem Feld wie 'NEED_BY_DATE'. Beispiele 2023-11-012023-12-152024-01-31
	Gesamtbetrag der Purchase Requisition RequisitionTotalAmount	Der Gesamtbetrag der Purchase Requisition.
Beschreibung Dieses Attribut repräsentiert die Summe des Werts aller Positionen einer einzelnen Purchase Requisition. Es ist ein kritischer Datenpunkt, um die finanzielle Bedeutung jeder Anfrage zu verstehen.\n\nIm Process Mining wird der Gesamtbetrag für eine Vielzahl von Analysen verwendet. Er kann zum Filtern nach hochwertigen Anforderungen geverwendet werden, die oft unterschiedliche Genehmigungswege oder eine höhere Prüfung erfordern. Dashboards können dieses Attribut verwenden, um zu analysierenn, wie Prozessmetriken, wie z.B. Zykluszeit oder Ablehnungsrate, mit dem Wert der Anforderung korrelieren. Bedeutung Bietet finanziellen Kontext, der eine wertbasierte Analyse ermöglicht, um Prozessoptimierungen zu priorisieren und zu verstehen, wie der Wert der Anforderung das Prozessverhalten beeinflusst. Datenquelle Befindet sich im Anforderungs-Header, oft in einem Feld wie REQUISITION_TOTAL in POR_REQUISITION_HEADERS_ALL. Es kann auch durch Summieren der Positionsbeträge aus POR_REQUISITION_LINES_ALL berechnet werden. Beispiele 550.0012500.7599.99
	Geschäftseinheit BusinessUnit	Die spezifische Geschäftseinheit innerhalb der Organisation, zu der den Antrag bearbeitet.ie Anforderung gehört.
Beschreibung Die Business Unit repräsentiert eine eigenständige rechtliche oder funktionale Einheit innerhalb des Unternehmens, für die die Anforderung gestellt wird. Es handelt sich um eine übergeordnete organisatorische Gruppierung im Vergleich zu einer Abteilung.\n\nDie Analyse von Daten nach Business Unit ermöglicht übergeordnete Leistungsvergleiche über verschiedene Teile der Organisation hinweg. Dies hilft dem oberen Management zu verstehen, ob Prozessineffizienzen lokal begrenzt oder weit verbreitet sind und wo Anstrengungen zur Verbesserung konzentriert werden sollten. Es ist eine Schlüsseldimension zum Filtern nahezu aller Dashboards und KPIs. Bedeutung Bietet einen übergeordneten organisatorischen Kontext, der Leistungsvergleiche und strategische Analysen über verschiedene Unternehmensbereiche hinweg ermöglicht. Datenquelle Dies ist ein wesentliches Organisationsfeld in Oracle Fusion, in der Regel im Anforderungs-Header in Tabellen wie POR_REQUISITION_HEADERS_ALL verfügbar. Beispiele BU North AmericaBU EuropaUnternehmenszentrale
	Name des Anfragenden RequesterName	Der Name des Mitarbeiters, der den Antrag bearbeitet.ie Purchase Requisition erstellt und eingereicht hat.
Beschreibung Dieses Attribut identifiziert die Person, die die Anfrage für Waren oder Dienstleistungen initiiert hat. Diese Information wird in der Regel zu Beginn des Prozesses erfasst, wenn die Anforderung erstmals erstellt wird.\n\nDie Analyse der Prozessleistung nach Anforderer ist maßgeblich für das Dashboard 'Performance-Metriken der Anforderer'. Sie hilft zu identifizieren, welche Benutzer oder Gruppen zusätzlichen Schulungsbedarf haben könnten, indem sie hohe Raten von Änderungen, Ablehnungen oder lange Durchlaufzeiten im Zusammenhang mit ihren Anfragen hervorhebt. Sie bietet eine nutzerzentrierte Sicht auf den Prozess. Bedeutung Ermöglicht die Leistungsfähigkeit-Analyse nach Anforderer, was hilft, Schulungsbedarfe zu identifizieren und effiziente Benutzer oder Abteilungen hervorzuheben. Datenquelle Abgeleitet aus den Anforderungs-Header-Daten, oft durch Verknüpfen der ID des Anforderers mit einer Mitarbeiter- oder Benutzer-StammDatentabelle. Suchen Sie nach Feldern, die mit 'PREPARER_ID' in POR_REQUISITION_HEADERS_ALL zusammenhängen, und verknüpfen Sie diese mit PER_ALL_PEOPLE_F. Beispiele John SmithJane DoeEmily Jones
	Purchase Requisitionsstatus RequisitionStatus	Der aktuelle oder endgültige Status der Purchase Requisition.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Anforderung zu einem bestimmten Zeitpunkt oder ihr Endergebnis an, wie z.B. 'Genehmigt', 'Abgelehnt', 'In Bearbeitung' oder 'Geschlossen'. Dies ist oft die Quelle, aus der viele Aktivitäten im Event Log abgeleitet werden.\n\nDieses Attribut ist maßgeblich für das Dashboard 'Anforderungsstatus-Übersicht', da es einen Überblick über die aktuelle Arbeitslast und den Rückstand bietet. Es wird auch verwendet, um ergebnisbasierte KPIs, wie die Anforderungs-Ablehnungsrate, zu berechnen, indem nach Fälle gefiltert wird, die in einem bestimmten Status enden. Bedeutung Bietet einen Überblick über den aktuellen Status von Anforderungen und wird zur Ermittlung der Endergebnisse für KPI-Berechnungen verwendet. Datenquelle Gefunden in der Purchase Requisitions-Header-Tabelle, in der Regel in einem Feld wie 'DOCUMENT_STATUS' oder 'APPROVAL_STATUS' in POR_REQUISITION_HEADERS_ALL. Beispiele GENEHMIGTIN PROCESSREJECTEDZURÜCKGEZOGEN
	Anforderungstyp RequisitionType	Die Kategorie der Anforderung, z.B. eine Anfrage für Waren oder Dienstleistungen.
Beschreibung Dieses Attribut klassifiziert die Anforderung basierend darauf, was angefragt wird. Gängige Typn umfassen Waren, Dienstleistungen oder Investitionsausgaben. Der Typ kann den erforderlichen Genehmigungs-Workflow und die Beschaffungsstrategie beeinflussen.\n\nIn der Analyse dient der Anforderungstyp als hilfreiche Dimension zum Filtern und Vergleichen. Man könnte beispielsweise analysierenn, ob Dienstleistungsanforderungen eine längere Genehmigungszykluszeit aufweisen als Warenanforderungen. Dies hilft zu verstehen, ob verschiedene Arten von Anfragen unterschiedliche Prozessverhaltensweisen oder Engpässe aufweisen. Bedeutung Ermöglicht die Segmentierung der Analyse, um zu verstehen, wie sich der Prozess für verschiedene Arten von Einkäufen, wie Waren im Vergleich zu Dienstleistungen, unterscheidet. Datenquelle Dies wird oft durch den Positionstyp oder den Antrag bearbeitet.ie Kategorie bestimmt, die während der Anforderungserstellung ausgewählt wurde. Es kann in der Anforderungspositionstabelle, POR_REQUISITION_LINES_ALL, gespeichert werden. Beispiele WarenDienstleistungenInvestitionsausgaben
	Artikelbeschreibung ItemDescription	Die Beschreibung des Produkts oder den Antrag bearbeitet.er Dienstleistung, die in einer Anforderungsposition angefragt wird.
Beschreibung Dieses Attribut enthält die textuelle Beschreibung des zu beschaffenden Artikels. Es liefert spezifische Details zu den angefragten Waren oder Dienstleistungen.\n\nObwohl oft unstrukturiert, bietet die Artikelbeschreibung wertvollen Kontext für die Analyse. Sie kann in Filtern verwendet werden, um Anforderungen für spezifische Arten von Käufen zu isolieren, die möglicherweise nicht vom Anforderungstyp erfasst werden. Zum Beispiel könnte ein Analyst nach allen Anforderungen suchen, die 'Softwarelizenz' enthalten, um deren spezifischen Prozessfluss und Zykluszeit zu verstehen. Bedeutung Bietet detaillierten Kontext zu dem, was gekauft wird, und ermöglicht so eine granularere Filterung und Analyse spezifischer Waren oder Dienstleistungen. Datenquelle Befindet sich in der Positionstabelle der Anforderung, POR_REQUISITION_LINES_ALL, in einem Feld wie ITEM_DESCRIPTION. Beispiele 15 inch Laptop, 16GB RAMBeratungsleistungen: Q4-ProjektJährliche Software-Wartungsverlängerung
	Benutzername UserName	Der Name des Benutzers, der eine spezifische Aktivität ausgeführt hat, z.B. ein Genehmiger oder ein Bearbeiter.
Beschreibung Während der Anforderername den Initiator identifiziert, gibt der Benutzername die Person an, die ein bestimmtes Event im Prozess ausgeführt hat, z.B. eine Genehmigung oder Ablehnung. Dies ist besonders wichtig für mehrstufige Genehmigungs-Workflows, bei denen verschiedene Personen involviert sind.\n\nDieses Attribut ist maßgeblich für die Analyse von Genehmigungs-Engpässe und die Messung der Leistung spezifischer Genehmiger oder Teams. Es unterstützt direkt das Dashboard 'Genehmigungs-Workflow-Engpässe', indem es die Analyse der Bearbeitungszeiten für jeden in der Genehmigungskette involvierten Benutzer ermöglicht. Bedeutung Identifiziert den Akteur für jedes Event, was wichtig ist für die Analyse von Übergabezeiten, der Leistungsfähigkeit von Genehmigern und der Ressourcenallokation. Datenquelle Abgeleitet aus Workflow-Verlauf oder Audit-Trail-Tabellen, wie z.B. FA_FUSION_SOAINFRA.WFTASK, die den mit jeder Aufgabenvervollständigung verbundenen Benutzer protokolliert. Beispiele David LeeSusan ChenMichael Brown
	Bestellnummer PurchaseOrderNumber	Die Kennung der aus der genehmigten Anforderung erstellten Bestellung.
Beschreibung Dieses Attribut verknüpft eine Purchase Requisition mit der den Antrag bearbeitet.araus resultierenden Bestellung. Sobald eine Anforderung vollständig genehmigt ist, wird sie in der Regel in eine oder mehrere Bestellungen umgewandelt, die an einen Lieferanten gesendet werden.\n\nIn der Analyse ist diese ID unerlässlich, um den Prozess nach der Anforderung zu verfolgen. Sie ermöglicht die Berechnung des KPIs 'Anforderung-zu-Bestellung-Vorlaufzeit' und unterstützt das Dashboard 'Anforderung-zu-Bestellung-Zykluszeit'. Es ermöglicht auch die Kombination der AnforderungsprozessDaten mit den nachfolgenden Bestell- und Rechnungsprozessen für eine echte End-to-End Einkauf zu Bezahlung-Analyse. Bedeutung Verknüpft die Anforderung mit der nachfolgenden Bestellung, ermöglicht die Messung der Durchlaufzeit von der Anforderung bis zur Bestellung und eine End-to-End-Prozessanalyse. Datenquelle Diese Information wird gespeichert, sobald eine Bestellung erstellt ist. Sie wird in der Regel durch die Suche nach den unterstützenden Anforderungsreferenzen in den Bestellverteilungstabellen, wie PO_DISTRIBUTIONS_ALL, gefunden, die auf die Anforderungsposition zurückverweisen. Beispiele PO-2023-5832PO-2023-5833PO-2023-5834
	Genehmigungs-Workflow-Pfad ApprovalWorkflowPath	Die vordefinierte Reihenfolge der Genehmiger oder Genehmigungsgruppen, die für die Anforderung erforderlich sind.
Beschreibung Dieses Attribut definiert den erwarteten, standardmäßigen Genehmigungsprozess für eine gegebene Anforderung basierend auf Unternehmensrichtlinien, unter Berücksichtigung von Faktoren wie Anforderungsbetrag, Typ und Abteilung. Es repräsentiert das 'Soll'-Prozessmodell.\n\nDer Genehmigungs-Workflow-Pfad ist die Basis für Compliance- und Konformitätsanalysen. Er unterstützt direkt das Dashboard 'Compliance- und Abweichungsanalyse' und den KPI 'Anforderungskonformitätsindex', indem er einen direkten Vergleich der tatsächlich durchgeführten Genehmigungsschritte mit dem vorgeschriebenen Pfad ermöglicht. Abweichungen können auf Richtlinienverstöße oder Prozessineffizienzen hinweisen. Bedeutung Ermöglicht die Konformitätsprüfung durch den Vergleich des tatsächlichen Prozessflusses mit der erforderlichen Genehmigungshierarchie, wobei nicht-konforme Purchase Requisitionen hervorgehoben werden. Datenquelle Diese Information wird in der Oracle Fusion BPM Worklist oder den Antrag bearbeitet.er Approval Management Engine (AMX) konfiguriert. Das Extrahieren des definierten Pfads für jede Anforderung kann komplex sein und erfordert möglicherweise das Abfragen von Konfigurationstabellen. Beispiele Manager > Direktor > VP FinanzenKostenstellenverantwortlicher > IT-SicherheitManager > Abteilungsleiter
	Ist `Straight Through` IsStraightThrough	Ein Flag, das anzeigt, ob die Purchase Requisition ohne Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dieses berechnete Flag identifiziert Anforderungen, die den Prozess von der Einreichung bis zur Genehmigung ohne Nacharbeitsschleifen, wie Änderungen oder Ablehnungen, durchlaufen haben. Es kennzeichnet einen perfekt ausgeführten Prozess für einen einzelnen Case.\n\nDieses Attribut ist die Grundlage für den KPI 'Rate der den Antrag bearbeitet.urchgängig bearbeiteten Anforderungen'. Die Analyse der Merkmale von durchgängig bearbeiteten Anforderungen (z.B. gemeinsame Abteilungen, Anforderer oder Typn) kann Best Practices und Automatisierungsmöglichkeiten aufdecken. Umgekehrt hilft die Analyse der nicht durchgängig bearbeiteten Fälle, die Hauptursachen für Ineffizienz zu identifizieren. Bedeutung Misst direkt die Prozesseffizienz und ist die Basis für den KPI der Straight-Through Requisition Rate, was hilft, die Treiber von Nacharbeit zu identifizieren. Datenquelle Dieses Attribut wird während der Datentransformation berechnet. Ein Case wird als wahr gekennzeichnet, wenn keine Aktivitäten 'Anforderung geändert' oder 'Genehmigungsschritt abgelehnt' vorhanden sind. Beispiele JaNein
	Ist automatisiert IsAutomated	Ein Kennzeichen, das angibt, ob eine Aktivität automatisch vom System ausgeführt wurde.
Beschreibung Dieses Attribut identifiziert Ereignisse im Prozess, die von einem Systembenutzer oder einem automatisierten Agenten anstatt von einem Menschen ausgeführt wurden. Beispiele könnten systemgesteuerte Statusänderungen oder automatisierte Genehmigungsschritte für Artikel mit geringem Wert sein.\n\nDie Analyse dieses Attributs hilft, den Automatisierungsgrad im Prozess zu quantifizieren. Es kann verwendet werden, um die Geschwindigkeit und Effizienz von automatisierten Schritten im Vergleich zu manuellen zu vergleichen und Möglichkeiten für weitere Automatisierung zu identifizieren. Bedeutung Hilft, den Automatisierungsgrad im Prozess zu messen und Möglichkeiten zur Automatisierung manueller Aufgaben zu identifizieren. Datenquelle Abgeleitet durch die Überprüfung, ob der einer Aktivität zugeordnete Benutzer ein System- oder Servicekonto ist. Dies erfordert eine Listee bekannter System-Benutzer-IDs. Beispiele JaNein
	Lieferantenname 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 gekauft werden sollen. Der Lieferant kann vom Anforderer vorgeschlagen oder vom System basierend auf Katalogen oder früheren Vereinbarungen bestimmt werden.\n\nDie Analyse nach Lieferanten kann wichtige Beschaffungsmuster aufdecken. Zum Beispiel kann sie helfen zu identifizieren, ob Anforderungen für bestimmte Lieferanten länger zur Genehmigung benötigen oder höhere Ablehnungsraten aufweisen. Diese Information kann für das Lieferantenbeziehungsmanagement und die Beschaffungsstrategie wertvoll sein. Bedeutung Ermöglicht die Analyse der Prozess-Leistungsfähigkeit nach Lieferant, was bei der Beschaffungsstrategie und dem Lieferantenbeziehungsmanagement helfen kann. Datenquelle Befindet sich in der Positionstabelle der Anforderung, POR_REQUISITION_LINES_ALL, oft über eine VENDOR_ID mit einer Lieferanten-StammDatentabelle wie POZ_SUPPLIERS verknüpft. Beispiele Office Supplies Inc.Global Tech Solutions`Kreativmarketingagentur`
	Währung CurrencyCode	Der Währungscode für den Anforderungsbetrag, z.B. USD oder EUR.
Beschreibung Dieses Attribut gibt die Währung an, in der den Antrag bearbeitet.er Gesamtbetrag der Anforderung denominiert ist. Für globale Organisationen können Anforderungen in verschiedenen Währungen erstellt werden.\n\nEs ist wesentlich für die korrekte Interpretation und Aggregation von FinanzDaten. Bei jeder Analyse, die Geldwerte beinhaltet, muss der Währungscode verwendet werden, um sicherzustellen, dass Beträge genau verglichen werden, entweder den Antrag bearbeitet.urch Filtern nach einer einzelnen Währung oder den Antrag bearbeitet.urch Umrechnung aller Beträge in eine gemeinsame Währung. Bedeutung Stellt eine genaue Finanzanalyse und Berichterstattung sicher, insbesondere in multinationalen Organisationen, die mit mehreren Währungen handeln. Datenquelle Typischerweise in der Anforderungs-Header-Tabelle neben den Betragsfeldern gefunden, z.B. in POR_REQUISITION_HEADERS_ALL. Beispiele USDEURGBPJPY
	Wurde geändert IsAmendedFlag	Ein boolesches Flag, das 'wahr' ist, wenn die Purchase Requisition mindestens einmal geändert wurde.
Beschreibung Dieses berechnete Attribut gibt an, ob eine Anforderung nach ihrer erstmaligen Einreichung Änderungen erfahren hat. Es wird abgeleitet, indem auf das Vorhandensein einer Aktivität 'Anforderung geändert' im Verlauf des Case geprüft wird.\n\nDieses Flag vereinfacht die Analyse und KPI-Berechnung. Es wird direkt zur Berechnung des KPIs 'Anforderungsänderungsrate' verwendet und um Fälle zu identifizieren, die nicht durchgängig sind. Es ermöglicht ein einfaches Filtern und Vergleichen von Prozessmetriken zwischen geänderten und nicht geänderten Anforderungen. Bedeutung Vereinfacht die Berechnung der Änderungsrate und ermöglicht einen einfachen Vergleich von geänderten und nicht geänderten Anforderungen. Datenquelle Dieses Attribut ist nicht im Quellsystem vorhanden, wird aber während der Datentransformation basierend auf dem Vorhandensein von änderungsbezogenen Aktivitäten im Event Log berechnet. Beispiele JaNein

Erforderlich Empfohlen Optional

Purchase-to-Pay – Purchase Requisitions-Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Einkauf zu Bezahlung-Anforderungsprozess präzise zu entdecken.

6 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Anforderung erstellt	Markiert den Beginn des Beschaffungsprozesses, wenn ein Benutzer eine neue Purchase Requisition zum ersten Mal speichert. Dieses Event wird in der Regel als explizite Datensatz-Erstellung mit einem entsprechenden Zeitstempel im System erfasst.
Bedeutung Dies ist das primäre Start-Event für den Anforderungsprozess. Die Analyse der Zeit von der Erstellung bis zur Einreichung kann Verzögerungen bei der Formalisierung der Anfrage aufdecken. Datenquelle Dieses Event wird in der Tabelle POR_REQUISITION_HEADERS_ALL erfasst, entnommen aus der Spalte creation_date, wenn eine neue Anforderungs-ID generiert wird. Erfassen Verwenden Sie den Erstellungs-Zeitstempel für den Anforderungs-Header-Datensatz. Ereignistyp explicit
	Bestellung erstellt	Dieses Event tritt auf, wenn eine genehmigte Anforderungsposition zur Generierung einer Bestellung verwendet wird. Es verknüpft den Anforderungsprozess mit dem nachgelagerten Beschaffungsprozess.
Bedeutung Dies ist ein kritischer Meilenstein für die Messung der Anforderung-zu-Bestellung-Vorlaufzeit. Verzögerungen hier deuten auf Engpässe bei der Übergabe von der Genehmigung zur Beschaffung hin. Datenquelle Dies ist ein explizites Event. Die Verknüpfung zwischen der Anforderung und der Bestellung wird in Tabellen wie PO_LINE_LOCATIONS_ALL gespeichert, die einen Verweis auf die Quell-Anforderungspositions-ID enthält. Erfassen Finden Sie das Erstellungsdatum der Bestellung, die auf die gegebene Requisition ID verweist. Ereignistyp explicit
	Purchase Requisition abgelehnt	Stellt die endgültige Ablehnung der Anforderung dar, die den Prozess für diese Anfrage beendet. Dies wird abgeleitet, wenn der Gesamtstatus der Anforderung auf 'Abgelehnt' aktualisiert wird.
Bedeutung Diese Aktivität ist ein Endpunkt für erfolglose Anfragen. Die Analyse dieser Fälle ist unerlässlich, um den KPI der Ablehnungsrate von Anforderungen und die Gründe für das Scheitern zu verstehen. Datenquelle Abgeleitet vom Dokumentstatus in der Tabelle POR_REQUISITION_HEADERS_ALL, der sich zu 'REJECTED' ändert. Erfassen Den Zeitstempel identifizieren, wann der Dokumentstatus zum ersten Mal auf 'Rejected' gesetzt wird. Ereignistyp inferred
	Purchase Requisition abgeschlossen	Zeigt den endgültigen Abschluss des Lebenszyklus einer Purchase Requisition an, d. h. alle ihre Positionen wurden erfüllt (z.B. in Bestellungen umgewandelt) oder storniert. Dies wird aus einem finalen Statusupdate abgeleitet.
Bedeutung Dies ist das primäre erfolgreiche End-Event für den Prozess. Es bestätigt, dass die Anforderung vollständig bearbeitet wurde und keine weiteren Maßnahmen erforderlich sind. Datenquelle Abgeleitet vom Purchase Requisitions-Header-Status in POR_REQUISITION_HEADERS_ALL, der sich zu 'CLOSED' ändert. Erfassen Den Zeitstempel identifizieren, wann der Dokumentstatus der Purchase Requisition auf 'Closed' wechselt. Ereignistyp inferred
	Purchase Requisition genehmigt	Markiert die endgültige Genehmigung der Purchase Requisition, nachdem sie alle Schritte im Workflow erfolgreich durchlaufen hat. Dies wird aus der Änderung des Gesamtstatus der Anforderung auf 'Genehmigt' abgeleitet.
Bedeutung Dies ist ein wichtiger Meilenstein, der anzeigt, dass die Anfrage für Beschaffungsmaßnahmen bereit ist. Es ist der Endpunkt zur Messung der gesamten Genehmigungszykluszeit der Anforderung. Datenquelle Abgeleitet vom Dokumentstatusfeld in der Tabelle POR_REQUISITION_HEADERS_ALL, das sich zu 'APPROVED' ändert. Das Datum dieser Statusänderung ist die Event Time. Erfassen Den Zeitstempel identifizieren, wann der Dokumentstatus zum ersten Mal auf 'Approved' gesetzt wird. Ereignistyp inferred
	Stellenanforderung eingereicht	Stellt die Benutzeraktion dar, die abgeschlossene Anforderung in den Genehmigungs-Workflow einzureichen. Dies wird erfasst, wenn sich der Anforderungsstatus von 'Unvollständig' oder 'Entwurf' in einen Status ändert, der auf eine ausstehende Zahlungen identifizieren.ende Genehmigung hinweist.
Bedeutung Diese Aktivität löst den Genehmigungszyklus aus. Sie ist ein kritischer Meilenstein für die Messung der Genehmigungszykluszeit von Anforderungen und der gesamten Durchlaufzeiten. Datenquelle Abgeleitet von einer Statusänderung in der Tabelle POR_REQUISITION_HEADERS_ALL (z.B. Status wechselt zu 'PENDING APPROVAL'). Das Einreichungsdatum wird oft ebenfalls explizit gespeichert. Erfassen Den Zeitstempel identifizieren, wann das Dokumentstatusfeld zum ersten Mal auf 'Pending Approval' wechselt. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Ein einzelner Genehmiger lehnt die Purchase Requisition ab, wodurch sie in der Regel zur Korrektur an den Ersteller zurückgesandt oder den Antrag bearbeitet.er Antrag beendet wird. Diese Aktion wird explizit in der Workflow-Verlauf protokolliert.
Bedeutung Diese Aktivität ist ein zentrale Faktor für Nacharbeit und Verzögerungen. Die Analyse von Ablehnungen hilft, Compliance-Verstöße, Budgetprobleme oder unklare Begründungen zu identifizieren. Datenquelle Erfasst aus der Aktionshistorie der Genehmigung einer Purchase Requisition. Das Workflow-System protokolliert eine 'REJECT'-Aktion mit einem Zeitstempel. Erfassen Verwenden Sie den Zeitstempel der Aktion 'ABLEHNEN' aus dem Workflow-Aktionsverlauf-Log. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Stellt die Aktion eines einzelnen Genehmigers dar, die Anforderung in seinem vorgesehenen Schritt im Workflow zu genehmigen. Das Event wird explizit im Genehmigungsverlauf protokolliert.
Bedeutung Das Verfolgen einzelner Genehmigungsschritte hilft, den tatsächlichen Genehmigungspfad abzubilden und die Bearbeitungszeit in jeder Stufe der Hierarchie zu messen. Datenquelle Erfasst aus der Aktionshistorie der Genehmigung einer Purchase Requisition, die in der Regel in Workflow- (WF) oder Human CAPItal Management (HCM)-Tabellen gespeichert ist, die Genehmigungshierarchien verwalten. Erfassen Verwenden Sie den Zeitstempel der Aktion 'GENEHMIGEN' aus dem Workflow-Aktionsverlauf-Log. Ereignistyp explicit
	Genehmigungsschritt gestartet	Markiert den Zeitpunkt, zu dem eine Anforderung einem bestimmten Genehmiger oder einer Genehmigungsgruppe innerhalb des Workflows zugewiesen wird. Dies wird aus dem Transaktions-Log des Workflow-Engines erfasst.
Bedeutung Diese Aktivität ist maßgeblich für die Berechnung der Wartezeit für jeden Genehmigungsschritt. Sie hilft, Engpässe zu identifizieren, die durch spezifische Genehmiger oder Genehmigungsstufen verursacht werden. Datenquelle Abgerufen aus den Workflow-Tabellen von Oracle Fusion, die den Benutzern zugewiesene Aufgaben protokollieren. Der Zuweisungs-Zeitstempel für die Genehmigungsaufgabe wird verwendet. Erfassen Verwenden Sie den Erstellungs-Zeitstempel der Aufgabe in der Workflow-Verlauf für die gegebene Anforderung. Ereignistyp explicit
	Genehmigungsschritt zurückgegeben	Ein Genehmiger sendet die Purchase Requisition an den Ersteller zurück, um zusätzliche Informationen oder geringfügige Korrekturen zu erhalten, ohne sie formell abzulehnen. Dies ist in der Regel eine explizite Aktion im Workflow-System.
Bedeutung Dies deutet auf Klärungsbedarf hin und erzeugt eine Nacharbeits-Schleife, die die Zykluszeit verlängert. Die Unterscheidung von Rücksendungen und Ablehnungen bietet tiefere Einblicke in die Prozessreibung. Datenquelle Erfasst aus der Aktionshistorie der Genehmigung einer Purchase Requisition. Das Workflow-System protokolliert eine 'RETURN'- oder ähnliche Aktion mit einem Zeitstempel. Erfassen Verwenden Sie den Zeitstempel der Aktion 'ZURÜCKGEBEN' oder 'Anfrage für Informationen' aus der Workflow-Verlauf. Ereignistyp explicit
	Purchase Requisition geändert	Dieses Event bedeutet, dass ein Benutzer eine Anforderung nach ihrer erstmaligen Einreichung geändert hat, was oft einen Neustart des Genehmigungsprozesses erfordert. Dies wird durch die Erkennung von Änderungen an wichtigen Datenfeldern oder den Antrag bearbeitet.ie Erstellung einer neuen Version der Anforderung abgeleitet.
Bedeutung Häufige Änderungen weisen auf Probleme mit der Datenqualität oder wechselnde Anforderungen hin, was zu Nacharbeit und Prozessverzögerungen führt. Dies unterstützt direkt den KPI der 'Requisition Amendment Rate' und hilft, die Treiber von Nacharbeit zu identifizieren. Datenquelle Abgeleitet durch Verfolgung der Versionsnummern der Purchase Requisition oder den Antrag bearbeitet.urch Identifizierung von Statusänderungen zurück zu 'Incomplete' nach der Einreichung. Änderungs-Logs oder Audit-Trail-Tabellen können diese Modifikationen ebenfalls erfassen. Erfassen Neue Zeitstempel für die Versionserstellung für dieselbe Requisition ID identifizieren, nachdem sie eingereicht wurde. Ereignistyp inferred
	Purchase Requisition zurückgezogen	Tritt auf, wenn der Anforderer eine eingereichte Anforderung storniert oder zurückzieht, bevor sie vollständig genehmigt wurde. Dies ist in der Regel eine explizite Benutzeraktion, die zu einer Statusänderung führt.
Bedeutung Das Verfolgen von Rückzügen hilft, Gründe für vorzeitige Beendigung zu identifizieren, wie z.B. geänderte geschäftliche Anforderungen oder Benutzer, die Fehler nach der Einreichung korrigieren. Datenquelle Abgeleitet von einer Statusänderung zu 'WITHDRAWN' in der Tabelle POR_REQUISITION_HEADERS_ALL. Die Aktion wird in der Aktionshistorie der Purchase Requisition protokolliert. Erfassen Den Zeitstempel erkennen, wann der Status der Purchase Requisition auf 'Withdrawn' aktualisiert wird. Ereignistyp inferred

Extraktionsanleitungen

So erhalten Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Zu "Reports and Analysen" bewältigen: Melden Sie sich bei Oracle Fusion Financials an. Verwenden Sie das Navigator-Menü, um zu "Tools" und dann zu "Reports and Analysen" zu bewältigen. Dies ist die zentrale Anlaufstelle für alle Berichtsaktivitäten.
Eine neue Analyse erstellen: Klicken Sie im Arbeitsbereich "Reports and Analysen" auf die Schaltfläche 'Create' und wählen Sie 'Analysis' aus dem Dropdown-Menü. Dadurch wird der Oracle Transactional Business Intelligence (OTBI)-Analyseeditor in einem neuen Tab gestartet.
Subject Area auswählen: Sie werden aufgefordert, ein Subject Area auszuwählen. Geben Sie in das Suchfeld 'Beschaffung – Requisitions Real Time' ein und wählen Sie es aus der Listee aus. Dieses Subject Area enthält alle erforderlichen Datenpunkte für Lebenszyklusereignisse von Purchase Requisitionen.
Analyse für Purchase Requisitionsereignisse erstellen: Dieser Schritt erfordert die Erstellung einer Vereinigung mehrerer Abfragen, um jedes einzelne Ereignis zu erfassen. Da die OTBI-Benutzeroberfläche keine direkte UNION ALL-Funktion für verschiedene Ereignistypen besitzt, 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' auf der linken Seite in den Bereich 'Selected Columns'. Dies beinhaltet Spalten für Erstellungsdatum, Einreichungsdatum, Genehmigungsdatum, Bestelldatum usw.
Aktionshistorie der Purchase Requisition hinzufügen: Um detaillierte Genehmigungsschritte (Approved, Rejected, Returned, 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 Ihre ausgewählten Spalten.
Filter konfigurieren: Wechseln Sie zum Tab 'Prompts', um Filter für Ihre Analyse zu erstellen. Es ist unerlässlich, nach einem Datumsbereich zu filtern, um das Datenvolumen zu steuern. Erstellen Sie einen Filter für 'Requisition Header'.'Requisition Creation Date' und setzen Sie ihn auf einen Bereich, zum Beispiel die letzten 6 Monate. Sie können auch Prompts für 'Business Unit' oder 'Requester Name' hinzufügen, um die Daten einzugrenzen.
Bericht ausführen und überprüfen: Gehen Sie zum Tab 'Results', um die Analyse auszuführen und die Daten vorab anzuzeigen. Die Ausgabe ist eine 'breite' Tabelle mit einer Zeile pro Purchase Requisitionsposition oder Genehmigungsaktion, die mehrere Datums- und Statusspalten enthält.
RohDaten exportieren: Sobald Sie mit der Einblicke zufrieden sind, klicken Sie auf den Link 'Export', der sich normalerweise am unteren Rand der Resultateite befindet. Wählen Sie 'Daten' > 'CSV File' als Format. Dadurch werden die RohDaten Ihrer Analyse heruntergeladen.
Daten in Event Log-Format umwandeln: Die exportierte CSV-Datei liegt in einem breiten Format vor. Sie müssen ein externes Tool (wie ein Python-Skript, Power Query in Excel oder ein anderes Datenvorbereitungstool) verwenden, um diese Daten zu modernisieren. Der Prozess beinhaltet das 'Entpivotieren' der Datumsspalten in eine einzige 'Ereigniszeitpunkt (Event Time)'-Spalte und die Erstellung einer entsprechenden 'ActivityName'-Spalte für jeden Ereignistyp (z. B. 'Requisition Created', 'Requisition Submitted').
Finalisieren und für den Upload vorbereiten: Stellen Sie nach der Transformation sicher, dass die Datei die erforderlichen Spalten enthält: PurchaseRequisitionId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem) und LastDatenUpdate. Speichern Sie das endgültige Event Log als CSV-Datei, die dann in ProcessMind hochgeladen werden kann.

Konfiguration

Subject Area: Das primäre Subject Area, das verwendet werden sollte, ist 'Beschaffung – Requisitions Real Time'. Dieses enthält alle wichtigen Informationen zu Requisition-Header, -Positionen, -Verteilungen und zur Genehmigungshistorie.
Datumsbereich: Wenden Sie immer einen obligatorischen Datumsfilter an, um das Datenvolumen zu begrenzen und die Leistungsfähigkeit zu verbessern. Ein Filter auf 'Requisition Header'.'Requisition Creation Date' für die letzten 3 bis 6 Monate ist ein guter Ausgangspunkt.
Schlüsselfilter: Erwägen Sie das Hinzufügen von Filtern für 'Requisition Header'.'Business Unit' und 'Requisition Header'.'Requisition Status', um die Extraktion auf relevante Organisationseinheiten zu konzentrieren und irrelevante Status wie 'Abbrechened' auszuschließen, falls diese für die Analyse nicht benötigt werden.
Spaltenauswahl: Seien Sie wählerisch bei den Spalten, die Sie der Analyse hinzufügen. Die Aufnahme zu vieler Spalten, insbesondere aus vielen verschiedenen Ordnern (Dimensionen), kann die Leistungsfähigkeit negativ beeinflussen. Konzentrieren Sie sich nur auf die Felder, die für das Event Log erforderlich sind.
Berechtigungen: Der Benutzer, der den Antrag bearbeitet.ie Extraktion ausführt, muss über eine Rolle mit den erforderlichen Berechtigungen verfügen, um auf den Arbeitsbereich 'Reports and Analysen' und das Subject Area 'Beschaffung – Requisitions Real Time' zugreifen zu können. Typischerweise verfügen Rollen wie 'BI Author' oder 'Beschaffung Analyst' über diese Privilegien.

a Beispielabfrage config

/*
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 bei Oracle Fusion Financials mit einem Benutzer an, der BI Author- oder ähnliche Berechtigungen besitzt.
Navigieren Sie zum Arbeitsbereich "Reports and Analysen", indem Sie auf das Navigator-Symbol klicken und dann "Tools > Reports and Analysen" auswählen.
Klicken Sie auf die Schaltfläche "Browse Catalog", um den Business Intelligence Publisher-Katalog zu öffnen.
Klicken Sie in der BI Publisher-Oberfläche auf "New" und wählen Sie "Daten Model" aus der Dropdown-Listee.
In den Daten Model-Eigenschaften können Sie einen Namen und eine Beschreibung eingeben. Klicken Sie auf das "+"-Symbol, um ein neues Daten Set hinzuzufügen und wählen Sie "SQL Query".
Geben Sie im neuen Daten Set-Dialog einen Namen ein (z. B. Requisition_Event_Log), wählen Sie die entsprechende Datenquelle für Ihre Financials-Daten aus (z. B. ApplicationDB_FSCM) und stellen Sie den SQL-Typ auf "Standard SQL" ein.
Kopieren Sie das vollständige SQL-Skript aus dem Abschnitt "query" dieses Dokuments und fügen Sie es in den SQL Query-Textbereich ein.
Die Abfrage enthält die Parameter :p_start_date und :p_end_date. Diese werden von BI Publisher automatisch erkannt. Bei Bedarf können Sie Standardwerte festlegen.
Speichern Sie das Daten Model in einem geeigneten Katalogordner (z. B. Shared Folders/Custom).
Um die Daten zu exportieren, bewältigen Sie zurück zum Katalog, klicken Sie auf "New" und wählen Sie "Report". Verknüpfen Sie diesen neuen Bericht mit dem soeben erstellten Daten Model.
Führen Sie den Bericht aus und geben Sie die Start- und Enddatumsparameter an. Sobald der Bericht die Daten anzeigt, verwenden Sie die "Export"-Funktion, um die Resultate als CSV-Datei herunterzuladen.
Stellen Sie sicher, dass die endgültige CSV-Datei mit UTF-8-Kodierung gespeichert wird und die erforderlichen Header für die Aufnahme in Ihr Process-Mining-Tool enthält.

Konfiguration

Datenquelle: Die BI Publisher-Datenquelle, in der Regel 'ApplicationDB_FSCM' oder ähnlich benannt, muss mit einem Benutzer konfiguriert werden, der Lesezugriff auf alle Tabellen in der Abfrage hat, einschließlich derer aus Beschaffung (POR, PO), Human CAPItal Management (PER, HR) und Financials (FUN).
Datumsbereichsfilterung: Die Abfrage ist mit obligatorischen Datumsparametern (:p_start_date und :p_end_date) konzipiert, die nach dem Erstellungsdatum der Requisition filtern. Für Ersterfassungen oder große Systeme ist es wichtig, Daten in überschaubaren Batches, z. B. 3 bis 6 Monate auf einmal, zu extrahieren, um System-Timeouts zu verhindern.
Filterung nach Geschäftseinheit: Ein Filter für den Namen der Geschäftseinheit ist in einem kommentierten Abschnitt der WHERE-Klausel der Abfrage enthalten. Es wird dringend empfohlen, diesen Filter zu entkommentieren und zu konfigurieren, um die Daten auf die für Ihre Analyse relevanten Geschäftseinheiten zu beschränken, was die Leistungsfähigkeit erheblich verbessern kann.
Voraussetzungen: Der Benutzer, der den Antrag bearbeitet.en Bericht erstellt und ausführt, benötigt eine Rolle mit BI Publisher-Berechtigungen, wie z. B. 'BI Administrator Role' oder 'BI Author Role'. Zusätzlich benötigt dieser Benutzer die erforderlichen Datensicherheitsberechtigungen, um auf die BeschaffungsDaten zugreifen zu können.

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 Umgebungseinrichtung: Stellen Sie sicher, dass Python 3 auf Ihrem System installiert ist. Installieren Sie die erforderliche requests-Bibliothek, indem Sie den folgenden Befehl in Ihrem Terminal ausführen: pip install requests. Sie benötigen außerdem API-ZugangsDaten (Benutzername, Passwort) für einen Oracle Fusion-Benutzer mit ausreichenden Berechtigungen zum Lesen von Purchase RequisitionsDaten sowie die Basis-URL für Ihre Oracle Fusion-Instanz.
Python-Skript speichern: Speichern Sie den vollständigen Python-Code, der im Abschnitt 'query' bereitgestellt wird, als Datei, z. B. extract_requisitions.py.
Skriptparameter konfigurieren: Öffnen Sie die Skriptdatei in einem Texteditor. Ändern Sie die Platzhalterwerte am Anfang des Skripts. Setzen Sie FUSION_URL, USERNAME und PASSWORD so, dass sie den Details Ihrer Oracle Fusion-Umgebung entsprechen. Passen Sie START_DATE und END_DATE an, um den Extraktionszeitraum zu definieren.
API-Endpunkte und Felder verstehen: Das Skript zielt auf die purchaseRequisitions REST API-Ressource ab. Es verwendet den fields-Parameter, um nur die notwendigen Daten anzufordern, einschließlich verschachtelter Sammlungen wie lines (für BestellDaten) und actionHistory (für Genehmigungsereignisse), was die Leistungsfähigkeit verbessert.
Skript ausführen: Führen Sie das Skript von Ihrem Terminal aus mit dem Befehl: python extract_requisitions.py aus. Das Skript authentifiziert sich bei der API, beginnt mit dem Abrufen von Daten und gibt Fortschrittsaktualisierungen auf der Konsole aus, die anzeigen, wie viele Purchase Requisitionen verarbeitet wurden.
Paginierung handhaben: Das Skript handhabt die Paginierung automatisch. Die Oracle Fusion REST API gibt Daten in Blöcken (Seiten) zurück. Das Skript prüft das hasMore-Flag in jeder Antwort und sendet wiederholt Anfragen mit einem aktualisierten offset-Parameter, bis alle Purchase Requisitionen innerhalb des angegebenen Datumsbereichs abgerufen wurden.
Datenumwandlungslogik: Für jede von der API abgerufene Purchase Requisition generiert das Skript mehrere Zeilen im Event Log. Es erstellt ein 'Requisition Created'-Ereignis aus dem CreationDate, ein 'Requisition Submitted'-Ereignis aus dem SubmittedDate und iteriert durch die actionHistory-Sammlung, um detaillierte Ereignisse für jeden Genehmigungsschritt (Started, Approved, Rejected, Returned) zu erstellen.
Finale Statusereignisse ableiten: Das Skript erfasst die finalen Ergebnisereignisse wie 'Requisition Approved' und 'Requisition Rejected', indem es den endgültigen DocumentStatus der Purchase Requisition prüft und das LastUpdateDate als Ereigniszeitstempel verwendet.
Ereignis zur Erstellung einer Bestellung generieren: Das Skript prüft jede Purchase Requisitionsposition. Wenn eine Position eine PoHeaderId hat, bedeutet dies, dass eine Bestellung erstellt wurde. Ein Event Log-Eintrag wird für diese Aktivität generiert, der den Antrag bearbeitet.ie Purchase Requisition mit dem nachgelagerten Beschaffungsprozess verknüpft.
Ausgabedatei überprüfen: Sobald das Skript beendet ist, wird es eine CSV-Datei namens oracle_fusion_requisitions_Event_log.csv im selben Verzeichnis erstellen. Diese Datei enthält das extrahierte Event Log.
Für den Upload vorbereiten: Öffnen Sie die generierte CSV-Datei in einem Tabellenkalkulationsprogramm, um deren Inhalt zu überprüfen. Stellen Sie sicher, dass die Spalten und Datenformate den Anforderungen Ihres Process-Mining-Tools entsprechen. Die Datei ist nun bereit, in ProcessMind hochgeladen zu werden.

Konfiguration

API-ZugangsDaten: Ein dediziertes Integrationsbenutzerkonto mit einer Rolle, die Lesezugriff auf die Purchase Requisitions REST API gewährt, ist erforderlich. Beispiele für Rollen sind 'Beschaffung Manager' oder eine benutzerdefinierte Integrationsrolle.
REST API-Endpunkt: Das Skript ist für die Verwendung des Endpunkts .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions konfiguriert. Stellen Sie sicher, dass die Versionsnummer in der URL Ihrer Oracle Fusion-Umgebung entspricht.
Datumsbereichsfilter: Das Skript enthält die Variablen START_DATE und END_DATE. Es wird dringend empfohlen, Daten in überschaubaren Batches, z. B. 3 bis 6 Monate auf einmal, zu extrahieren, um API-Timeouts und Leistungsprobleme zu vermeiden. Der Filter wird auf das CreationDate der Requisitionen angewendet.
Feldauswahl: Der fields-Parameter im Skript ist maßgeblich für die Leistungsfähigkeit. Er begrenzt die Antwort-Payload auf die Attribute, die für das Event Log benötigt werden, was den Netzwerkverkehr und die Verarbeitungszeit reduziert. Entfernen Sie keine erforderlichen Felder wie RequisitionId, CreationDate, actionHistory oder lines.
Paginierungslimit: Der limit-Parameter ist auf 100 gesetzt, was ein sicherer Wert für die meisten Umgebungen ist. Sie können versuchen, diesen auf 200 oder 500 zu erhöhen, um möglicherweise eine schnellere Extraktion zu erreichen, aber beachten Sie potenzielle Speicherprobleme oder API-Limits, wenn der Wert zu hoch angesetzt wird.

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

Zu "Reports and Analysen" bewältigen: Melden Sie sich bei Oracle Fusion Financials an. Verwenden Sie das Navigator-Menü, um zu "Tools" und dann zu "Reports and Analysen" zu bewältigen. Dies ist die zentrale Anlaufstelle für alle Berichtsaktivitäten.
Eine neue Analyse erstellen: Klicken Sie im Arbeitsbereich "Reports and Analysen" auf die Schaltfläche 'Create' und wählen Sie 'Analysis' aus dem Dropdown-Menü. Dadurch wird der Oracle Transactional Business Intelligence (OTBI)-Analyseeditor in einem neuen Tab gestartet.
Subject Area auswählen: Sie werden aufgefordert, ein Subject Area auszuwählen. Geben Sie in das Suchfeld 'Beschaffung – Requisitions Real Time' ein und wählen Sie es aus der Listee aus. Dieses Subject Area enthält alle erforderlichen Datenpunkte für Lebenszyklusereignisse von Purchase Requisitionen.
Analyse für Purchase Requisitionsereignisse erstellen: Dieser Schritt erfordert die Erstellung einer Vereinigung mehrerer Abfragen, um jedes einzelne Ereignis zu erfassen. Da die OTBI-Benutzeroberfläche keine direkte UNION ALL-Funktion für verschiedene Ereignistypen besitzt, 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' auf der linken Seite in den Bereich 'Selected Columns'. Dies beinhaltet Spalten für Erstellungsdatum, Einreichungsdatum, Genehmigungsdatum, Bestelldatum usw.
Aktionshistorie der Purchase Requisition hinzufügen: Um detaillierte Genehmigungsschritte (Approved, Rejected, Returned, 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 Ihre ausgewählten Spalten.
Filter konfigurieren: Wechseln Sie zum Tab 'Prompts', um Filter für Ihre Analyse zu erstellen. Es ist unerlässlich, nach einem Datumsbereich zu filtern, um das Datenvolumen zu steuern. Erstellen Sie einen Filter für 'Requisition Header'.'Requisition Creation Date' und setzen Sie ihn auf einen Bereich, zum Beispiel die letzten 6 Monate. Sie können auch Prompts für 'Business Unit' oder 'Requester Name' hinzufügen, um die Daten einzugrenzen.
Bericht ausführen und überprüfen: Gehen Sie zum Tab 'Results', um die Analyse auszuführen und die Daten vorab anzuzeigen. Die Ausgabe ist eine 'breite' Tabelle mit einer Zeile pro Purchase Requisitionsposition oder Genehmigungsaktion, die mehrere Datums- und Statusspalten enthält.
RohDaten exportieren: Sobald Sie mit der Einblicke zufrieden sind, klicken Sie auf den Link 'Export', der sich normalerweise am unteren Rand der Resultateite befindet. Wählen Sie 'Daten' > 'CSV File' als Format. Dadurch werden die RohDaten Ihrer Analyse heruntergeladen.
Daten in Event Log-Format umwandeln: Die exportierte CSV-Datei liegt in einem breiten Format vor. Sie müssen ein externes Tool (wie ein Python-Skript, Power Query in Excel oder ein anderes Datenvorbereitungstool) verwenden, um diese Daten zu modernisieren. Der Prozess beinhaltet das 'Entpivotieren' der Datumsspalten in eine einzige 'Ereigniszeitpunkt (Event Time)'-Spalte und die Erstellung einer entsprechenden 'ActivityName'-Spalte für jeden Ereignistyp (z. B. 'Requisition Created', 'Requisition Submitted').
Finalisieren und für den Upload vorbereiten: Stellen Sie nach der Transformation sicher, dass die Datei die erforderlichen Spalten enthält: PurchaseRequisitionId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem) und LastDatenUpdate. Speichern Sie das endgültige Event Log als CSV-Datei, die dann in ProcessMind hochgeladen werden kann.

Konfiguration

Subject Area: Das primäre Subject Area, das verwendet werden sollte, ist 'Beschaffung – Requisitions Real Time'. Dieses enthält alle wichtigen Informationen zu Requisition-Header, -Positionen, -Verteilungen und zur Genehmigungshistorie.
Datumsbereich: Wenden Sie immer einen obligatorischen Datumsfilter an, um das Datenvolumen zu begrenzen und die Leistungsfähigkeit zu verbessern. Ein Filter auf 'Requisition Header'.'Requisition Creation Date' für die letzten 3 bis 6 Monate ist ein guter Ausgangspunkt.
Schlüsselfilter: Erwägen Sie das Hinzufügen von Filtern für 'Requisition Header'.'Business Unit' und 'Requisition Header'.'Requisition Status', um die Extraktion auf relevante Organisationseinheiten zu konzentrieren und irrelevante Status wie 'Abbrechened' auszuschließen, falls diese für die Analyse nicht benötigt werden.
Spaltenauswahl: Seien Sie wählerisch bei den Spalten, die Sie der Analyse hinzufügen. Die Aufnahme zu vieler Spalten, insbesondere aus vielen verschiedenen Ordnern (Dimensionen), kann die Leistungsfähigkeit negativ beeinflussen. Konzentrieren Sie sich nur auf die Felder, die für das Event Log erforderlich sind.
Berechtigungen: Der Benutzer, der den Antrag bearbeitet.ie Extraktion ausführt, muss über eine Rolle mit den erforderlichen Berechtigungen verfügen, um auf den Arbeitsbereich 'Reports and Analysen' und das Subject Area 'Beschaffung – Requisitions Real Time' zugreifen zu können. Typischerweise verfügen Rollen wie 'BI Author' oder 'Beschaffung Analyst' über diese Privilegien.

a Beispielabfrage config

/*
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'

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Purchase-to-Pay – Purchase Requisitions-Attribute

Purchase-to-Pay – Purchase Requisitions-Aktivitäten

Extraktionsanleitungen

Oracle Transactional Business Intelligence (OTBI) Export

Schritte

Konfiguration

a Beispielabfrage config

Oracle BI Publisher SQL-basierte Datenmodell-Extraktion

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript via Oracle Fusion REST API

Schritte

Konfiguration

a Beispielabfrage python

Oracle BI Cloud Connector (BICC) Bulk Daten Extract

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Erreichen Sie eine 30% schnellere Purchase-to-Pay: Purchase Requisition

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Purchase-to-Pay – Purchase Requisitions-Attribute

Purchase-to-Pay – Purchase Requisitions-Aktivitäten

Extraktionsanleitungen

Oracle Transactional Business Intelligence (OTBI) Export

Schritte

Konfiguration

a Beispielabfrage config

Oracle BI Publisher SQL-basierte Datenmodell-Extraktion

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript via Oracle Fusion REST API

Schritte

Konfiguration

a Beispielabfrage python

Oracle BI Cloud Connector (BICC) Bulk Daten Extract

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Erreichen Sie eine 30% schnellere Purchase-to-Pay: Purchase Requisition