> Continue procesverbetering > Purchase to Pay Requisition > Oracle Fusion Financials > Datatemplate

Jouw datatemplate voor Purchase to Pay - Requisition

Oracle Fusion Financials

Purchase to Pay - Requisition-attributen (22) Purchase to Pay - Requisition-activiteiten (12) Extractiegidsen (4)

Jouw datatemplate voor Purchase to Pay - Requisition

Deze template geeft je een duidelijk overzicht van de essentiële data die je nodig hebt om je Purchase to Pay - Requisition-proces te analyseren. Je ziet welke attributen je verzamelt, welke activiteiten je volgt en hoe je deze informatie uit Oracle Fusion Financials haalt. Zo bereid je je event log goed voor op process mining.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Extractie-instructies voor Oracle Fusion Financials

Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Template downloaden

Purchase to Pay - Requisition-attributen

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van Purchase to Pay - Requisition.

5 Verplicht 7 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de bedrijfsgebeurtenis die op een specifiek moment in het aanvraagproces plaatsvond.
Beschrijving De activiteit staat voor een afzonderlijke stap of mijlpaal in de levenscyclus van een inkoopaanvraag. Voorbeelden zijn 'Requisition Created', 'Approval Step Approved' en 'Purchase Order Created'. Deze activiteiten worden afgeleid uit statuswijzigingen, gebruikersacties of systeemgebeurtenissen die in auditlogs of transactietabellen van het bronsysteem zijn vastgelegd. Dit attribuut is nodig om de proceskaart op te bouwen, die de stroom van aanvragen visueel weergeeft. Door de volgorde en frequentie van activiteiten te analyseren, zie je veelvoorkomende procespaden, knelpunten, herstelwerk-lussen en afwijkingen van de standaardprocedure. Waarom dit belangrijk is Dit vormt de basis van de proceskaart en maakt het mogelijk de workflow van aanvragen te visualiseren en analyseren. Waar je het vindt Afgeleid uit registraties van statuswijzigingen in tabellen zoals POR_REQUISITION_HEADERS_ALL, transact geschiedenis of workflowaudittrails zoals FA_FUSION_SOAINFRA.WFTASK. Voorbeelden Aanvraag aangemaaktGoedkeuringsstap goedgekeurdAanvraag afgewezenInkooporder aangemaakt
	Gebeurtenistijd EventTime	De timestamp die aangeeft wanneer de activiteit plaatsvond.
Beschrijving De gebeurtenistijd legt de exacte datum en tijd vast waarop een specifieke activiteit plaatsvond. Deze timestamp is nodig om gebeurtenissen binnen een case chronologisch te ordenen. De waarde komt uit aanmaakdatums, datums van de laatste update of specifieke actietimestamps in het systeem. In analyses wordt de gebeurtenistijd gebruikt om alle metriek op basis van tijdsduur te berekenen, zoals doorlooptijden tussen activiteiten, wachttijden en de totale duur van een case. Dit is belangrijk om knelpunten te herkennen, prestaties ten opzichte van SLA's te meten en de tijdsdynamiek van het aanvraagproces te begrijpen. Waarom dit belangrijk is Dit attribuut is nodig voor het berekenen van alle tijdgerelateerde KPI's, het correct ordenen van gebeurtenissen en het analyseren van procesprestaties en knelpunten. Waar je het vindt Deze waarde komt meestal uit een kolom 'LAST_UPDATE_DATE' of 'CREATION_DATE' die bij de transactie of statuswijziging hoort, vaak in tabellen zoals POR_REQUISITION_HEADERS_ALL of workflowgeschiedenistabellen. Voorbeelden 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID van de inkoopaanvraag PurchaseRequisitionId	De unieke identificatie van een inkoopaanvraag, die als case-ID voor het proces dient.
Beschrijving De ID van de inkoopaanvraag is de centrale identificatie die alle activiteiten rond een specifieke aanvraag voor goederen of diensten koppelt. Elke aanvraag krijgt bij het aanmaken een unieke ID die gedurende de hele levenscyclus gelijk blijft. In process mining wordt dit attribuut gebruikt om alle bijbehorende gebeurtenissen, zoals aanmaken, indienen, goedkeuringsstappen en definitief sluiten, in één case te groeperen. Zo kun je de aanvraag van begin tot eind analyseren, proceskaarten visualiseren, doorlooptijden berekenen en varianten per aanvraag analyseren. Waarom dit belangrijk is Dit is het belangrijkste attribuut om de levenscyclus van een aanvraag van begin tot eind te volgen. Het vormt de basis voor alle analyses op caseniveau en KPI-berekeningen. Waar je het vindt Dit is meestal de primaire sleutel in de tabel met aanvraagkoppen, zoals POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID in Oracle Fusion Financials. Voorbeelden 100234810023491002350
	Bronsysteem SourceSystem	Het informatiesysteem waaruit deze data is geëxtraheerd.
Beschrijving Dit attribuut identificeert de herkomst van de procesdata. In dit datamodel is de waarde altijd 'Oracle Fusion Financials'. In omgevingen met meerdere ERP-systemen of geïntegreerde systemen is dit veld belangrijk voor data lineage, probleemoplossing en het bewaken van de datakwaliteit. Het geeft context over de bron die leidend is voor de geanalyseerde procesgebeurtenissen. Waarom dit belangrijk is Geeft belangrijke context over de herkomst van de data. Dat is van belang voor datagovernance en bij het combineren van data uit meerdere systemen. Waar je het vindt Dit is een statische waarde die tijdens het extraheren en transformeren van de data wordt toegevoegd om de herkomst van de dataset te markeren. Voorbeelden Oracle Fusion Financials
	Laatste data-update LastDataUpdate	De timestamp van de meest recente datarefresh vanuit het bronsysteem.
Beschrijving Dit attribuut geeft aan op welke datum en tijd de data voor het laatst uit Oracle Fusion Financials is geëxtraheerd. Het geldt voor de volledige dataset en niet voor afzonderlijke gebeurtenissen. Analisten gebruiken deze informatie om te bepalen hoe actueel de data is en wanneer de nieuwste transacties zijn opgenomen. Het is belangrijke metadata voor dashboardrapportages en om te controleren of analyses op actuele informatie zijn gebaseerd. Waarom dit belangrijk is Laat zien hoe recent de data is, zodat analyses relevant blijven en op de laatst beschikbare informatie zijn gebaseerd. Waar je het vindt Deze timestamp wordt tijdens het data-extractieproces gegenereerd en opgeslagen, meestal door de ETL-tool of datapijplijn. Voorbeelden 2023-10-27T02:00:00Z
	Afdeling DepartmentName	De bedrijfsafdeling waartoe de aanvrager behoort.
Beschrijving Dit attribuut geeft de organisatorische eenheid aan van de persoon die de aanvraag heeft aangemaakt, zoals 'Finance', 'IT' of 'Marketing'. De waarde wordt meestal afgeleid uit het gebruikersprofiel van de aanvrager in het HR-systeem. Analyseren per afdeling is een gebruikelijke en effectieve manier om procesdata te segmenteren. Zo zie je afdelingsspecifieke patronen, zoals hogere afwijzingspercentages of langere doorlooptijden. Dat helpt bij gerichte procesverbetering. Het is een belangrijke dimensie voor het dashboard 'Prestatiemetrieken aanvragers'. Waarom dit belangrijk is Maakt procesanalyse per bedrijfseenheid mogelijk. Zo zie je afdelingsspecifieke patronen, prestaties en complianceproblemen. Waar je het vindt Meestal afgeleid uit het profiel van de aanvrager. Vaak is daarvoor een koppeling nodig tussen de aanvraagtabel en een HR- of gebruikersdirectory met afdelingsinformatie. Voorbeelden InformatietechnologieFinanciënBedrijfsvoeringMarketing
	Bedrijfseenheid BusinessUnit	De specifieke bedrijfseenheid binnen de organisatie waartoe de aanvraag behoort.
Beschrijving De bedrijfseenheid is een afzonderlijke juridische of functionele entiteit binnen de organisatie waarvoor de aanvraag wordt gedaan. Het is een organisatorisch niveau boven de afdeling. Door data per bedrijfseenheid te analyseren, kun je prestaties op hoofdlijnen tussen verschillende delen van de organisatie vergelijken. Zo ziet het management of inefficiënties lokaal of breed voorkomen en waar verbeteringen nodig zijn. Het is een belangrijke dimensie voor het filteren van vrijwel alle dashboards en KPI's. Waarom dit belangrijk is Geeft context op organisatieniveau en maakt prestatievergelijking en strategische analyse tussen verschillende delen van de organisatie mogelijk. Waar je het vindt Dit is een belangrijk organisatieveld in Oracle Fusion. Het is meestal beschikbaar op de aanvraagkop in tabellen zoals POR_REQUISITION_HEADERS_ALL. Voorbeelden BU Noord-AmerikaBU EuropaHoofdkantoor
	Benodigd op-datum RequiredByDate	De datum waarop de aanvrager de goederen of diensten nodig heeft.
Beschrijving De aanvrager geeft deze datum op als deadline voor ontvangst van de gevraagde artikelen. Het is een interne SLA-doelstelling voor het inkoopproces. Dit attribuut vormt de basis voor het dashboard 'Prestaties op benodigd-op-datum' en de KPI 'Nalevingspercentage benodigd-op-datum'. Door deze datum te vergelijken met de werkelijke aanmaakdatum van de inkooporder of de ontvangstdatum van de goederen, zie je hoe goed het inkoopproces aan interne klantbehoeften voldoet en waar structurele vertragingen ontstaan. Waarom dit belangrijk is Belangrijk voor het meten van procesprestaties ten opzichte van interne deadlines en om te bepalen of het inkoopproces op tijd aan de bedrijfsbehoeften voldoet. Waar je het vindt Meestal opgeslagen op regelniveau van de aanvraag, in tabellen zoals POR_REQUISITION_LINES_ALL, in een veld zoals 'NEED_BY_DATE'. Voorbeelden 2023-11-012023-12-152024-01-31
	Naam aanvrager RequesterName	De naam van de medewerker die de inkoopaanvraag heeft aangemaakt en ingediend.
Beschrijving Dit attribuut identificeert de persoon die de aanvraag voor goederen of diensten heeft gestart. Deze informatie wordt meestal aan het begin van het proces vastgelegd, wanneer de aanvraag wordt aangemaakt. Het analyseren van procesprestaties per aanvrager is belangrijk voor het dashboard 'Prestatiemetrieken aanvragers'. Zo zie je welke gebruikers of groepen extra training nodig hebben, bijvoorbeeld door veel wijzigingen, afwijzingen of lange doorlooptijden bij hun aanvragen. Het geeft een menselijk perspectief op het proces. Waarom dit belangrijk is Maakt prestatieanalyse per aanvrager mogelijk. Zo zie je waar training nodig is en welke gebruikers of afdelingen efficiënt werken. Waar je het vindt Afkomstig uit de gegevens van de aanvraagkop. Vaak wordt de ID van de aanvrager gekoppeld aan een tabel met medewerkers- of gebruikersgegevens. Zoek naar velden die verband houden met 'PREPARER_ID' in POR_REQUISITION_HEADERS_ALL en koppel deze aan PER_ALL_PEOPLE_F. Voorbeelden John SmithJane DoeEmily Jones
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft wanneer een aanvraag of goedkeuringsstap wordt afgewezen.
Beschrijving Bij een afwijzing geeft de goedkeurder meestal een reden op. Dat kan door een vooraf gedefinieerde optie te selecteren of vrije tekst in te voeren. Dit attribuut legt die onderbouwing vast. Dit attribuut is belangrijk voor een oorzaakanalyse van procesproblemen. Het ondersteunt rechtstreeks het dashboard 'Trends in wijzigingen en afwijzingen' door te laten zien waarom aanvragen worden afgewezen. Door afwijzingsredenen te analyseren, zie je veelvoorkomende problemen, zoals onjuiste codering, budgetoverschrijdingen of beleidsovertredingen. Die kun je vervolgens aanpakken met training of systeemcontroles. Waarom dit belangrijk is Geeft direct inzicht in de redenen voor afwijzing van aanvragen. Zo kun je gericht verbeteren, herstelwerk verminderen en het percentage straight-through processing verhogen. Waar je het vindt Afkomstig uit workflowopmerkingen of specifieke velden met afwijzingsredenen in de workflowaudittrail, mogelijk in tabellen rond FA_FUSION_SOAINFRA.WFTASK of bijbehorende opslag voor opmerkingen. Voorbeelden Onjuiste grootboekrekeningBudget voor kostenplaats overschredenNiet-voorkeursleverancier geselecteerdDubbel verzoek
	Status aanvraag RequisitionStatus	De huidige of definitieve status van de inkoopaanvraag.
Beschrijving Dit attribuut geeft de algemene status van de aanvraag op een bepaald moment of de definitieve uitkomst aan, zoals 'Approved', 'Rejected', 'In Process' of 'Closed'. Veel activiteiten in het event log worden hieruit afgeleid. Dit attribuut is de basis voor het dashboard 'Overzicht aanvraagstatus'. Het geeft een momentopname van de huidige werkvoorraad en achterstand. Ook wordt het gebruikt voor KPI's op basis van uitkomsten, zoals het afwijzingspercentage van aanvragen, door cases te filteren die met een bepaalde status eindigen. Waarom dit belangrijk is Geeft een momentopname van de huidige status van aanvragen en wordt gebruikt om definitieve uitkomsten voor KPI-berekeningen te bepalen. Waar je het vindt Te vinden in de tabel met aanvraagkoppen, meestal in een veld zoals 'DOCUMENT_STATUS' of 'APPROVAL_STATUS' in POR_REQUISITION_HEADERS_ALL. Voorbeelden GOEDGEKEURDIN BEHANDELINGAFGEWEZENINGETROKKEN
	Totaalbedrag aanvraag RequisitionTotalAmount	De totale geldwaarde van de inkoopaanvraag.
Beschrijving Dit attribuut staat voor de som van de waarde van alle regels in één inkoopaanvraag. Het is een belangrijk gegeven om de financiële betekenis van elke aanvraag te begrijpen. In process mining wordt het totaalbedrag voor verschillende analyses gebruikt. Je kunt er aanvragen met een hoge waarde mee filteren. Die hebben vaak een ander goedkeuringspad of worden strenger gecontroleerd. Dashboards kunnen dit attribuut gebruiken om te analyseren hoe procesmetriek, zoals doorlooptijd of afwijzingspercentage, samenhangt met de waarde van de aanvraag. Waarom dit belangrijk is Geeft financiële context. Zo kun je verbeteringen prioriteren op basis van waarde en begrijpen hoe de waarde van een aanvraag het procesgedrag beïnvloedt. Waar je het vindt Staat op de aanvraagkop, vaak in een veld zoals REQUISITION_TOTAL in POR_REQUISITION_HEADERS_ALL. Je kunt het bedrag ook berekenen door de bedragen van de regels in POR_REQUISITION_LINES_ALL op te tellen. Voorbeelden 550.0012500.7599.99
	Artikelomschrijving ItemDescription	De omschrijving van het product of de dienst die op een aanvraagregel wordt aangevraagd.
Beschrijving Dit attribuut bevat de tekstuele omschrijving van het artikel dat wordt ingekocht. Het geeft specifieke informatie over de aangevraagde goederen of diensten. Hoewel de informatie vaak ongestructureerd is, geeft de artikelomschrijving waardevolle context voor analyses. Je kunt ermee filteren op specifieke soorten aankopen die niet altijd door het type aanvraag worden afgedekt. Een analist kan bijvoorbeeld zoeken naar alle aanvragen met 'Software License' om de specifieke processtroom en doorlooptijd te analyseren. Waarom dit belangrijk is Geeft gedetailleerde context over wat wordt ingekocht en maakt fijnmaziger filtering en analyse van specifieke goederen of diensten mogelijk. Waar je het vindt Te vinden in de tabel met aanvraagregels, POR_REQUISITION_LINES_ALL, in een veld zoals ITEM_DESCRIPTION. Voorbeelden Laptop van 15 inch, 16 GB RAMConsultancydiensten - Q4-projectJaarlijkse verlenging van softwareonderhoud
	Gebruikersnaam UserName	De naam van de gebruiker die een specifieke activiteit heeft uitgevoerd, zoals een goedkeurder of bewerker.
Beschrijving De naam van de aanvrager identificeert de initiator. De gebruikersnaam geeft aan wie een specifieke gebeurtenis in het proces heeft uitgevoerd, zoals een goedkeuring of afwijzing. Dit is vooral belangrijk bij goedkeuringsworkflows met meerdere stappen en verschillende betrokkenen. Dit attribuut is belangrijk voor het analyseren van goedkeuringsknelpunten en het meten van de prestaties van specifieke goedkeurders of teams. Het ondersteunt rechtstreeks het dashboard 'Knelpunten in goedkeuringsworkflows', omdat je hiermee de verwerkingstijd per gebruiker in de goedkeuringsketen kunt analyseren. Waarom dit belangrijk is Identificeert de uitvoerder van elke gebeurtenis. Dat is belangrijk voor het analyseren van overdrachtstijden, prestaties van goedkeurders en de inzet van medewerkers. Waar je het vindt Afkomstig uit workflowgeschiedenis- of audittrailtabellen, zoals FA_FUSION_SOAINFRA.WFTASK, waarin de gebruiker bij elke voltooide taak wordt vastgelegd. Voorbeelden David LeeSusan ChenMichael Brown
	Is geautomatiseerd IsAutomated	Een vlag die aangeeft of een activiteit automatisch door het systeem is uitgevoerd.
Beschrijving Dit attribuut identificeert gebeurtenissen in het proces die door een systeemgebruiker of geautomatiseerde agent zijn uitgevoerd in plaats van door een persoon. Voorbeelden zijn door het systeem uitgevoerde statuswijzigingen of automatische goedkeuringsstappen voor items met een lage waarde. Met dit attribuut meet je de mate van automatisering in het proces. Je kunt de snelheid en efficiëntie van geautomatiseerde stappen vergelijken met handmatige stappen en zien welke handmatige taken verder geautomatiseerd kunnen worden. Waarom dit belangrijk is Helpt de mate van automatisering in het proces te meten en mogelijkheden te vinden om handmatige taken te automatiseren. Waar je het vindt Wordt bepaald door te controleren of de gebruiker die aan een activiteit is gekoppeld een systeem- of serviceaccount is. Hiervoor heb je een lijst met bekende systeemgebruikers-ID's nodig. Voorbeelden truefalse
	Is gewijzigd IsAmendedFlag	Een booleaanse vlag die waar is als de aanvraag minstens één keer is gewijzigd.
Beschrijving Dit berekende attribuut geeft aan of een aanvraag na de eerste indiening is gewijzigd. Het wordt bepaald door te controleren of de activiteit 'Requisition Amended' voorkomt in de geschiedenis van de case. Deze vlag vereenvoudigt de analyse en de berekening van KPI's. De vlag wordt rechtstreeks gebruikt voor de KPI 'Requisition Amendment Rate' en om cases te identificeren die niet straight-through zijn. Zo kun je procesmetrics van gewijzigde en ongewijzigde aanvragen eenvoudig filteren en vergelijken. Waarom dit belangrijk is Vereenvoudigt de berekening van het wijzigingspercentage en maakt het eenvoudig om gewijzigde en ongewijzigde aanvragen te vergelijken. Waar je het vindt Dit attribuut staat niet in het bronsysteem, maar wordt tijdens de data-transformatie berekend op basis van de aanwezigheid van wijzigingsgerelateerde activiteiten in het event log. Voorbeelden truefalse
	Is straight-through IsStraightThrough	Een vlag die aangeeft of de aanvraag zonder wijzigingen of afwijzingen is goedgekeurd.
Beschrijving Deze berekende vlag identificeert aanvragen die het proces van indiening tot goedkeuring hebben doorlopen zonder rework-lussen, zoals wijzigingen of afwijzingen. Dit staat voor een perfect uitgevoerd proces voor één case. Dit attribuut vormt de basis voor de KPI 'Straight-Through Requisition Rate'. Door de kenmerken van straight-through-aanvragen te analyseren, zoals veelvoorkomende afdelingen, aanvragers of typen, ontdek je best practices en mogelijkheden voor automatisering. Door ook aanvragen te analyseren die niet straight-through zijn, zie je beter wat de belangrijkste oorzaken van inefficiëntie zijn. Waarom dit belangrijk is Meet de procesefficiëntie rechtstreeks en vormt de basis voor de KPI Straight-Through Requisition Rate. Zo zie je beter wat rework veroorzaakt. Waar je het vindt Dit attribuut wordt tijdens de data-transformatie berekend. Een case krijgt de waarde true als de activiteiten 'Requisition Amended' en 'Approval Step Rejected' niet voorkomen. Voorbeelden truefalse
	Naam leverancier SupplierName	De naam van de voorgestelde of vooraf geselecteerde leverancier voor de goederen of diensten.
Beschrijving Dit attribuut identificeert de leverancier bij wie de goederen of diensten naar verwachting worden ingekocht. De aanvrager kan de leverancier voorstellen, of het systeem bepaalt deze op basis van catalogi of bestaande overeenkomsten. Door per leverancier te analyseren, zie je belangrijke inkooppatronen. Je kunt bijvoorbeeld nagaan of aanvragen voor bepaalde leveranciers langer op goedkeuring wachten of vaker worden afgewezen. Deze informatie helpt bij leveranciersbeheer en de inkoopstrategie. Waarom dit belangrijk is Maakt analyse van procesprestaties per leverancier mogelijk. Dat helpt bij de inkoopstrategie en het leveranciersbeheer. Waar je het vindt Te vinden in de tabel met aanvraagregels, POR_REQUISITION_LINES_ALL, vaak gekoppeld via VENDOR_ID aan een leverancierstabel zoals POZ_SUPPLIERS. Voorbeelden Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Nummer inkooporder PurchaseOrderNumber	De identificatie van de inkooporder die vanuit de goedgekeurde aanvraag is aangemaakt.
Beschrijving Dit attribuut koppelt een inkoopaanvraag aan de bijbehorende inkooporder. Nadat een aanvraag volledig is goedgekeurd, wordt deze meestal omgezet in een of meer inkooporders die naar een leverancier worden gestuurd. In analyses is deze ID nodig om het proces na de aanvraag te volgen. Hiermee kun je de KPI 'Doorlooptijd van aanvraag tot inkooporder' berekenen en het dashboard 'Doorlooptijd aanvraag tot inkooporder' ondersteunen. Ook kun je de data van het aanvraagproces combineren met de daaropvolgende inkooporder- en facturatieprocessen voor een volledige Purchase-to-Pay-analyse. Waarom dit belangrijk is Koppelt de aanvraag aan de daaropvolgende inkooporder. Zo kun je de doorlooptijd van aanvraag tot inkooporder meten en het proces van begin tot eind analyseren. Waar je het vindt Deze informatie wordt opgeslagen zodra een inkooporder is aangemaakt. Je vindt deze meestal door de verwijzingen naar de onderliggende aanvraag in distributietabellen van de inkooporder te bekijken, zoals PO_DISTRIBUTIONS_ALL, die terugverwijst naar de aanvraagregel. Voorbeelden PO-2023-5832PO-2023-5833PO-2023-5834
	Pad van goedkeuringsworkflow ApprovalWorkflowPath	De vooraf bepaalde volgorde van goedkeurders of goedkeuringsgroepen die voor de aanvraag nodig zijn.
Beschrijving Dit attribuut beschrijft het verwachte, standaard goedkeuringsproces voor een aanvraag op basis van bedrijfsbeleid. Daarbij wordt rekening gehouden met factoren zoals bedrag, type en afdeling van de aanvraag. Het staat voor het 'to-be'-procesmodel. Het pad van de goedkeuringsworkflow vormt de basis voor compliance- en conformanceanalyses. Het ondersteunt rechtstreeks het dashboard 'Compliance- en afwijkingsanalyse' en de KPI 'Conformance-index aanvragen', omdat je de werkelijk doorlopen goedkeuringsstappen kunt vergelijken met het voorgeschreven pad. Afwijkingen kunnen wijzen op beleidsovertredingen of inefficiënte processen. Waarom dit belangrijk is Maakt conformancecontrole mogelijk door de werkelijke processtroom te vergelijken met de vereiste goedkeuringshiërarchie. Zo zie je welke aanvragen niet aan de regels voldoen. Waar je het vindt Deze informatie wordt geconfigureerd in de Oracle Fusion BPM Worklist of Approval Management Engine (AMX). Het ophalen van het gedefinieerde pad per aanvraag kan complex zijn en vereist mogelijk query's op configuratietabellen. Voorbeelden Manager > Directeur > VP FinanciënEigenaar kostenplaats > IT-beveiligingManager > Afdelingshoofd
	Type aanvraag RequisitionType	De categorie van de aanvraag, zoals een aanvraag voor goederen of diensten.
Beschrijving Dit attribuut classificeert de aanvraag op basis van wat wordt aangevraagd. Veelvoorkomende typen zijn goederen, diensten of kapitaaluitgaven. Het type kan invloed hebben op de vereiste goedkeuringsworkflow en inkoopstrategie. In analyses is het type aanvraag een nuttige dimensie om te filteren en vergelijken. Je kunt bijvoorbeeld onderzoeken of aanvragen voor diensten een langere goedkeuringsdoorlooptijd hebben dan aanvragen voor goederen. Zo zie je of verschillende typen aanvragen ander procesgedrag of andere knelpunten vertonen. Waarom dit belangrijk is Maakt segmentatie mogelijk, zodat je kunt zien hoe het proces verschilt per type aankoop, zoals goederen versus diensten. Waar je het vindt Wordt vaak bepaald door het type of de categorie van de regel die bij het aanmaken van de aanvraag is geselecteerd. De waarde kan zijn opgeslagen in de aanvraagtabel voor regels, POR_REQUISITION_LINES_ALL. Voorbeelden GoederenDienstenKapitaaluitgaven
	Valuta CurrencyCode	De valutacode voor het bedrag van de aanvraag, zoals USD of EUR.
Beschrijving Dit attribuut geeft aan in welke valuta het totaalbedrag van de aanvraag is uitgedrukt. In internationale organisaties kunnen aanvragen in verschillende valuta worden aangemaakt. Dit is nodig om financiële data correct te interpreteren en samen te voegen. Bij analyses met geldbedragen moet je de valutacode gebruiken om bedragen goed te vergelijken. Dat kan door één valuta te selecteren of alle bedragen om te rekenen naar een gemeenschappelijke valuta. Waarom dit belangrijk is Zorgt voor een correcte financiële analyse en rapportage, vooral in internationale organisaties die met meerdere valuta werken. Waar je het vindt Meestal te vinden in de tabel met aanvraagkoppen, naast de bedragvelden, bijvoorbeeld in POR_REQUISITION_HEADERS_ALL. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Purchase to Pay - Requisition-activiteiten

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log vastlegt voor een nauwkeurige procesontdekking van het Purchase to Pay - Requisition-proces.

6 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Aanvraag aangemaakt	Dit markeert de start van het inkoopproces, wanneer een gebruiker een nieuwe inkoopaanvraag voor het eerst opslaat. In het systeem wordt dit meestal vastgelegd als een expliciete recordaanmaak met een bijbehorende timestamp.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het aanvraagproces. Door de tijd tussen aanmaak en indiening te analyseren, kunnen vertragingen bij het formaliseren van aanvragen zichtbaar worden. Waar je het vindt Deze gebeurtenis wordt vastgelegd in de tabel POR_REQUISITION_HEADERS_ALL, op basis van de kolom creation_date wanneer een nieuwe Requisition-ID wordt aangemaakt. Vastleggen Gebruik de timestamp van de aanmaak van het aanvraagheaderrecord. Eventtype explicit
	Aanvraag afgewezen	Dit staat voor de definitieve afwijzing van de aanvraag, waarmee het proces voor deze aanvraag wordt beëindigd. Dit wordt afgeleid wanneer de algemene status van de aanvraag wordt bijgewerkt naar 'Rejected'.
Waarom dit belangrijk is Deze activiteit is het eindpunt van een mislukte aanvraag. Door deze cases te analyseren, krijg je zicht op de KPI voor het afwijzingspercentage van aanvragen en de redenen voor mislukking. Waar je het vindt Afgeleid uit de wijziging van de documentstatus in de tabel POR_REQUISITION_HEADERS_ALL naar 'REJECTED'. Vastleggen Bepaal de timestamp waarop de documentstatus voor het eerst wordt ingesteld op 'Rejected'. Eventtype inferred
	Aanvraag gesloten	Geeft aan dat de levenscyclus van een aanvraag definitief is afgesloten. Alle regels zijn afgehandeld, bijvoorbeeld omgezet in inkooporders, of geannuleerd. Dit wordt afgeleid uit een laatste statuswijziging.
Waarom dit belangrijk is Dit is de belangrijkste succesvolle eindgebeurtenis van het proces. De aanvraag is volledig verwerkt en er is geen verdere actie nodig. Waar je het vindt Afgeleid uit de wijziging van de status van de aanvraagkop in POR_REQUISITION_HEADERS_ALL naar 'CLOSED'. Vastleggen Bepaal de timestamp waarop de documentstatus van de aanvraag verandert in 'Closed'. Eventtype inferred
	Aanvraag goedgekeurd	Markeert de definitieve goedkeuring van de inkoopaanvraag nadat deze alle workflowstappen succesvol heeft doorlopen. Dit wordt afgeleid uit de wijziging van de algemene status van de aanvraag naar 'Approved'.
Waarom dit belangrijk is Dit is een belangrijk ijkpunt dat aangeeft dat de aanvraag klaar is voor inkoop. Het is het eindpunt voor het meten van de totale doorlooptijd van de goedkeuringscyclus van de aanvraag. Waar je het vindt Afgeleid uit de wijziging van het documentstatusveld in de tabel POR_REQUISITION_HEADERS_ALL naar 'APPROVED'. De datum van deze statuswijziging is de gebeurtenistijd. Vastleggen Bepaal de timestamp waarop de documentstatus voor het eerst wordt ingesteld op 'Approved'. Eventtype inferred
	Aanvraag ingediend	Dit staat voor de actie waarbij de gebruiker de ingevulde aanvraag indient voor de goedkeuringsworkflow. De gebeurtenis wordt vastgelegd wanneer de status van de aanvraag verandert van 'Incomplete' of 'Draft' naar een status die aangeeft dat goedkeuring nodig is.
Waarom dit belangrijk is Deze activiteit start de goedkeuringscyclus. Het is een belangrijk ijkpunt voor het meten van de doorlooptijd van de goedkeuring van de aanvraag en de totale doorlooptijden. Waar je het vindt Afgeleid van een statuswijziging in de tabel POR_REQUISITION_HEADERS_ALL, bijvoorbeeld wanneer de status verandert in 'PENDING APPROVAL'. De indieningsdatum wordt vaak ook expliciet opgeslagen. Vastleggen Bepaal de timestamp waarop het documentstatusveld voor het eerst verandert in 'Pending Approval'. Eventtype inferred
	Inkooporder aangemaakt	Deze gebeurtenis vindt plaats wanneer een goedgekeurde aanvraagregel wordt gebruikt om een inkooporder aan te maken. Hiermee wordt het aanvraagproces gekoppeld aan het daaropvolgende inkoopproces.
Waarom dit belangrijk is Dit is een belangrijk ijkpunt voor het meten van de doorlooptijd van aanvraag tot inkooporder. Vertragingen hier wijzen op knelpunten bij de overdracht van goedkeuring naar inkoop. Waar je het vindt Dit is een expliciete gebeurtenis. De koppeling tussen de aanvraag en de inkooporder wordt opgeslagen in tabellen zoals PO_LINE_LOCATIONS_ALL. Deze tabel bevat een verwijzing naar de ID van de bronaanvraagregel. Vastleggen Zoek de aanmaakdatum van de inkooporder die verwijst naar de opgegeven aanvraag-ID. Eventtype explicit
	Aanvraag gewijzigd	Deze gebeurtenis betekent dat een gebruiker een aanvraag na de eerste indiening heeft gewijzigd. Vaak moet het goedkeuringsproces dan opnieuw beginnen. Dit wordt afgeleid uit wijzigingen in belangrijke datavelden of uit het aanmaken van een nieuwe versie van de aanvraag.
Waarom dit belangrijk is Veel wijzigingen wijzen op problemen met de datakwaliteit of veranderende eisen. Dat leidt tot herstelwerk en vertragingen in het proces. Deze activiteit ondersteunt rechtstreeks de KPI 'Wijzigingspercentage aanvragen'. Waar je het vindt Afgeleid door versienummers van de aanvraag te volgen of statuswijzigingen terug naar 'Incomplete' na indiening te herkennen. Wijzigingslogboeken of audittrailtabellen kunnen deze aanpassingen ook vastleggen. Vastleggen Bepaal de timestamps waarop na indiening een nieuwe versie voor dezelfde aanvraag-ID wordt aangemaakt. Eventtype inferred
	Aanvraag ingetrokken	Dit gebeurt wanneer de aanvrager een ingediende aanvraag annuleert of intrekt voordat deze volledig is goedgekeurd. Meestal gaat het om een expliciete gebruikersactie die leidt tot een statuswijziging.
Waarom dit belangrijk is Door intrekkingen te volgen, zie je waarom aanvragen voortijdig worden beëindigd, bijvoorbeeld door veranderde bedrijfsbehoeften of omdat gebruikers fouten na indiening corrigeren. Waar je het vindt Afgeleid van een statuswijziging naar 'WITHDRAWN' in de tabel POR_REQUISITION_HEADERS_ALL. De actie wordt vastgelegd in de actiegeschiedenis van de aanvraag. Vastleggen Detecteer de timestamp waarop de status van de aanvraag wordt bijgewerkt naar 'Withdrawn'. Eventtype inferred
	Goedkeuringsstap afgewezen	Een individuele goedkeurder wijst de aanvraag af. Meestal gaat deze dan terug naar de opsteller voor correctie of wordt de aanvraag beëindigd. Deze actie wordt expliciet vastgelegd in de workflowgeschiedenis.
Waarom dit belangrijk is Deze activiteit veroorzaakt vaak herstelwerk en vertragingen. Door afwijzingen te analyseren, zie je problemen met compliance, budgetten of onduidelijke onderbouwingen. Waar je het vindt Vastgelegd in de goedkeuringsactiegeschiedenis van de aanvraag. Het workflowsysteem registreert een actie 'REJECT' met een timestamp. Vastleggen Gebruik de timestamp van de actie 'REJECT' uit het logboek met workflowacties. Eventtype explicit
	Goedkeuringsstap gestart	Markeert het moment waarop een aanvraag binnen de workflow aan een specifieke goedkeurder of goedkeuringsgroep wordt toegewezen. Dit wordt vastgelegd in het transactielogboek van de workflow-engine.
Waarom dit belangrijk is Deze activiteit is belangrijk voor het berekenen van de wachttijd per goedkeuringsstap. Zo zie je welke goedkeurders of goedkeuringsniveaus voor knelpunten zorgen. Waar je het vindt Opgehaald uit de workflowtabellen van Oracle Fusion, waarin aan gebruikers toegewezen taken worden vastgelegd. De toewijzingstimestamp van de goedkeuringstaak wordt gebruikt. Vastleggen Gebruik de aanmaaktimestamp van de taak in de workflowgeschiedenis voor de betreffende aanvraag. Eventtype explicit
	Goedkeuringsstap goedgekeurd	Dit staat voor de actie van een individuele goedkeurder die de aanvraag in de toegewezen workflowstap goedkeurt. De gebeurtenis wordt expliciet vastgelegd in de goedkeuringsgeschiedenis.
Waarom dit belangrijk is Door afzonderlijke goedkeuringsstappen te volgen, kun je het werkelijke goedkeuringspad in kaart brengen en de verwerkingstijd per niveau van de hiërarchie meten. Waar je het vindt Vastgelegd in de goedkeuringsactiegeschiedenis van de aanvraag. Deze staat meestal in workflowtabellen (WF) of tabellen van Human Capital Management (HCM) waarin goedkeuringshiërarchieën worden beheerd. Vastleggen Gebruik de timestamp van de actie 'APPROVE' uit het logboek met workflowacties. Eventtype explicit
	Goedkeuringsstap teruggestuurd	Een goedkeurder stuurt de aanvraag terug naar de opsteller voor aanvullende informatie of kleine correcties, zonder deze formeel af te wijzen. Dit is meestal een expliciete actie in het workflowsysteem.
Waarom dit belangrijk is Dit wijst op behoefte aan verduidelijking en creëert een herstelwerk-lus die de doorlooptijd verlengt. Door teruggestuurde aanvragen te onderscheiden van afwijzingen, krijg je beter zicht op wrijving in het proces. Waar je het vindt Vastgelegd in de goedkeuringsactiegeschiedenis van de aanvraag. Het workflowsysteem registreert een actie 'RETURN' of een vergelijkbare actie met een timestamp. Vastleggen Gebruik de timestamp van de actie 'RETURN' of 'Request for Information' uit de workflowgeschiedenis. Eventtype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Oracle Fusion Financials

Stappen

Ga naar Reports and Analytics: Log in bij Oracle Fusion Financials. Open het menu Navigator, ga naar Tools en selecteer Reports and Analytics. Dit is de centrale plek voor alle rapportages.
Maak een nieuwe analyse: Klik in het werkgebied Reports and Analytics op de knop 'Create' en selecteer 'Analysis' in het vervolgmenu. De editor voor Oracle Transactional Business Intelligence (OTBI)-analyses wordt in een nieuw tabblad geopend.
Selecteer het subject area: Je wordt gevraagd een subject area te selecteren. Typ 'Procurement - Requisitions Real Time' in het zoekveld en selecteer deze in de lijst. Dit subject area bevat alle benodigde datapunten voor gebeurtenissen in de levenscyclus van een aanvraag.
Bouw de analyse voor aanvraaggebeurtenissen: In deze stap maak je een combinatie van meerdere query's om elke afzonderlijke gebeurtenis vast te leggen. Omdat de OTBI-interface geen directe UNION ALL-functie heeft voor verschillende gebeurtenistypen, maak je één rapport met alle relevante datum- en statusvelden. Sleep op het tabblad 'Criteria' de kolommen uit de querysectie van het deelvenster 'Subject Areas' links naar 'Selected Columns'. Dit zijn onder andere kolommen voor aanmaakdatum, indieningsdatum, goedkeuringsdatum en aanmaakdatum van de PO.
Voeg de actievgeschiedenis van de aanvraag toe: Neem voor gedetailleerde goedkeuringsstappen, zoals Approved, Rejected, Returned en Withdrawn, velden op uit de map 'Requisition Action History' binnen het subject area. Sleep 'Action Date', 'Action' en 'Performer' naar je geselecteerde kolommen.
Stel filters in: Ga naar het tabblad 'Prompts' om filters voor je analyse te maken. Filteren op een datumbereik is belangrijk om de hoeveelheid data beheersbaar te houden. Maak een filter op 'Requisition Header'.'Requisition Creation Date' en stel bijvoorbeeld de laatste 6 maanden in. Je kunt ook prompts toevoegen voor 'Business Unit' of 'Requester Name' om de data verder te beperken.
Voer het rapport uit en controleer het: Ga naar het tabblad 'Results' om de analyse uit te voeren en de data te bekijken. De uitvoer is een brede tabel met één rij per aanvraagregel of goedkeuringsactie, met meerdere datum- en statuskolommen.
Exporteer de onbewerkte data: Klik na controle van het voorbeeld op de link 'Export', meestal onderaan de resultatenpagina. Kies 'Data' > 'CSV File' als indeling. Hiermee download je de onbewerkte data uit je analyse.
Zet de data om naar event-logindeling: De geëxporteerde CSV staat in een brede indeling. Gebruik een externe tool, zoals een Python-script, Power Query in Excel of een andere datavoorbereidingstool, om de data om te zetten. Daarbij maak je van de datumkolommen één kolom 'EventTime' en voeg je voor elk gebeurtenistype een bijbehorende kolom 'ActivityName' toe, bijvoorbeeld 'Requisition Created' en 'Requisition Submitted'.
Rond af en bereid de upload voor: Controleer na de transformatie of het bestand de vereiste kolommen bevat: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate. Sla het definitieve event log op als CSV-bestand. Daarna kun je het uploaden naar ProcessMind.

Configuratie

Subject area: Het belangrijkste subject area is 'Procurement - Requisitions Real Time'. Dit bevat alle kerninformatie over aanvraagkoppen, regels, distributies en goedkeuringsgeschiedenis.
Datumbereik: Pas altijd een verplicht datumfilter toe om de hoeveelheid data te beperken en de prestaties te verbeteren. Een filter op 'Requisition Header'.'Requisition Creation Date' voor de laatste 3 tot 6 maanden is een goed uitgangspunt.
Belangrijke filters: Overweeg filters voor 'Requisition Header'.'Business Unit' en 'Requisition Header'.'Requisition Status'. Zo beperk je de extractie tot relevante organisatieonderdelen en sluit je statussen uit die je niet nodig hebt, zoals 'Canceled'.
Kolomselectie: Wees selectief met de kolommen die je aan de analyse toevoegt. Te veel kolommen, vooral uit verschillende mappen of dimensies, kunnen de prestaties negatief beïnvloeden. Richt je op de velden die je voor het event log nodig hebt.
Rechten: De gebruiker die de extractie uitvoert, moet een rol hebben met de juiste rechten voor het werkgebied Reports and Analytics en het subject area 'Procurement - Requisitions Real Time'. Rollen zoals 'BI Author' of 'Procurement Analyst' hebben deze rechten meestal.

a Voorbeeldquery 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'

Stappen

Log in bij Oracle Fusion Financials met een gebruiker die over BI Author- of vergelijkbare rechten beschikt.
Ga naar het werkgebied Reports and Analytics door op het pictogram Navigator te klikken en daarna Tools > Reports and Analytics te selecteren.
Klik op de knop "Browse Catalog" om de Business Intelligence Publisher-catalogus te openen.
Klik in de BI Publisher-interface op "New" en selecteer "Data Model" in het vervolgmenu.
Geef in de eigenschappen van het datamodel een naam en beschrijving op. Klik op het pictogram "+" om een nieuwe Data Set toe te voegen en selecteer "SQL Query".
Geef in het dialoogvenster voor de nieuwe Data Set een naam op, bijvoorbeeld Requisition_Event_Log. Selecteer de juiste Data Source voor je Financials-data, bijvoorbeeld ApplicationDB_FSCM, en stel het SQL-type in op "Standard SQL".
Kopieer het volledige SQL-script uit de sectie "query" van dit document en plak het in het tekstvak SQL Query.
De query bevat de parameters :p_start_date en :p_end_date. BI Publisher herkent deze automatisch. Je kunt desgewenst standaardwaarden instellen.
Sla het datamodel op in een geschikte catalogusmap, bijvoorbeeld Shared Folders/Custom.
Ga terug naar de catalogus, klik op "New" en selecteer "Report" om de data te exporteren. Koppel dit nieuwe rapport aan het datamodel dat je zojuist hebt gemaakt.
Voer het rapport uit en geef de parameters voor de begin- en einddatum op. Zodra het rapport de data toont, gebruik je de functie "Export" om de resultaten als CSV-bestand te downloaden.
Controleer of het definitieve CSV-bestand UTF-8-codering gebruikt en de vereiste kolomkoppen voor inladen in je process mining-tool bevat.

Configuratie

Databron: De BI Publisher-databron, meestal ‘ApplicationDB_FSCM’ of een vergelijkbare naam, moet zijn geconfigureerd met een gebruiker die leestoegang heeft tot alle tabellen in de query, waaronder tabellen uit Procurement (POR, PO), Human Capital Management (PER, HR) en Financials (FUN).
Filteren op periode: De query bevat verplichte datumparameters (:p_start_date en :p_end_date) die filteren op de aanmaakdatum van de requisition. Bij de eerste extracties of in grote systemen is het belangrijk om de data in beheersbare batches te extraheren, bijvoorbeeld 3 tot 6 maanden per keer, om time-outs te voorkomen.
Filteren op bedrijfseenheid: In een uitgecommentarieerd gedeelte van de WHERE-clausule van de query staat een filter voor de naam van de bedrijfseenheid. Het is sterk aan te raden dit filter te activeren en in te stellen voor de bedrijfseenheden die relevant zijn voor de analyse. Dit kan de prestaties aanzienlijk verbeteren.
Vereisten: De gebruiker die het rapport maakt en uitvoert, heeft een rol met BI Publisher-rechten nodig, zoals ‘BI Administrator Role’ of ‘BI Author Role’. Daarnaast heeft deze gebruiker de juiste databeveiligingsrechten nodig voor toegang tot de procurementdata.

a Voorbeeldquery 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'

Stappen

Vereisten en omgeving instellen: Zorg dat Python 3 op je systeem is geïnstalleerd. Installeer de benodigde requests-bibliotheek met de volgende opdracht in je terminal: pip install requests. Je hebt ook API-inloggegevens nodig, zoals gebruikersnaam en wachtwoord, voor een Oracle Fusion-gebruiker met voldoende rechten om gegevens over inkoopaanvragen te lezen. Daarnaast heb je de basis-URL van je Oracle Fusion-instantie nodig.
Sla het Python-script op: Sla de volledige Python-code uit de sectie 'query' op als bestand, bijvoorbeeld extract_requisitions.py.
Stel de scriptparameters in: Open het scriptbestand in een teksteditor. Pas de tijdelijke waarden bovenaan het script aan. Stel FUSION_URL, USERNAME en PASSWORD in op de gegevens van jouw Oracle Fusion-omgeving. Pas START_DATE en END_DATE aan voor de periode die je wilt extraheren.
Begrijp de API-eindpunten en velden: Het script gebruikt de purchaseRequisitions REST API-resource. Met de parameter fields vraagt het alleen de benodigde data op, waaronder geneste verzamelingen zoals lines voor PO-informatie en actionHistory voor goedkeuringsgebeurtenissen. Dat verbetert de prestaties.
Voer het script uit: Start het script vanuit je terminal met de opdracht python extract_requisitions.py. Het script meldt zich aan bij de API, haalt de data op en toont voortgangsinformatie in de console, waaronder het aantal verwerkte aanvragen.
Verwerk paginering: Het script verwerkt paginering automatisch. De Oracle Fusion REST API retourneert data in delen, oftewel pagina's. Het script controleert de vlag hasMore in elke respons en verstuurt opnieuw verzoeken met een bijgewerkte parameter offset totdat alle aanvragen binnen het opgegeven datumbereik zijn opgehaald.
Logica voor datatransformatie: Voor elke aanvraag die via de API wordt opgehaald, maakt het script meerdere rijen in het event log. Het maakt een gebeurtenis 'Requisition Created' op basis van CreationDate, een gebeurtenis 'Requisition Submitted' op basis van SubmittedDate en doorloopt de verzameling actionHistory om gedetailleerde gebeurtenissen voor elke goedkeuringsstap te maken, zoals Started, Approved, Rejected en Returned.
Leid gebeurtenissen voor de eindstatus af: Het script legt gebeurtenissen voor de einduitkomst vast, zoals 'Requisition Approved' en 'Requisition Rejected', door de uiteindelijke DocumentStatus van de aanvraag te controleren en LastUpdateDate als timestamp van de gebeurtenis te gebruiken.
Maak een Purchase Order-gebeurtenis: Het script controleert elke aanvraagregel. Als een regel een PoHeaderId bevat, betekent dit dat er een Purchase Order is aangemaakt. Het script voegt hiervoor een rij aan het event log toe en koppelt de aanvraag aan het daaropvolgende inkoopproces.
Controleer het uitvoerbestand: Na afloop maakt het script in dezelfde map een CSV-bestand met de naam oracle_fusion_requisitions_event_log.csv. Dit bestand bevat het geëxtraheerde event log.
Bereid de upload voor: Open het gegenereerde CSV-bestand in een spreadsheetprogramma om de inhoud te controleren. Controleer of de kolommen en data-indelingen voldoen aan de vereisten van je process mining-tool. Daarna kun je het bestand uploaden naar ProcessMind.

Configuratie

API-inloggegevens: Je hebt een speciaal integratieaccount nodig met een rol die alleen-lezen-toegang geeft tot de Purchase Requisitions REST API. Voorbeelden zijn Procurement Manager of een aangepaste integratierol.
REST API-eindpunt: Het script gebruikt het eindpunt .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Controleer of het versienummer in de URL overeenkomt met jouw Oracle Fusion-omgeving.
Filter op datumbereik: Het script bevat de variabelen START_DATE en END_DATE. Het is sterk aan te raden om de data in beheersbare batches te extraheren, bijvoorbeeld 3 tot 6 maanden per keer. Zo voorkom je API-time-outs en prestatieproblemen. Het filter wordt toegepast op de CreationDate van de aanvragen.
Veldselectie: De parameter fields in het script is belangrijk voor de prestaties. Deze beperkt de respons tot de attributen die het event log nodig heeft, waardoor netwerkverkeer en verwerkingstijd afnemen. Verwijder verplichte velden zoals RequisitionId, CreationDate, actionHistory en lines niet.
Pagineringlimiet: De parameter limit staat op 100, een veilige waarde voor de meeste omgevingen. Je kunt proberen deze te verhogen naar 200 of 500 om de extractie mogelijk te versnellen. Houd wel rekening met geheugenproblemen of API-limieten bij een te hoge waarde.

a Voorbeeldquery 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()

Stappen

Controleer of Oracle BI Cloud Connector, de vereiste Oracle Fusion Financials-inkoopcontent en toegang tot de relevante Public View Objects beschikbaar zijn in jouw omgeving. Controleer ook of de BICC-gebruiker of het integratieaccount toestemming heeft om aanvraag-, goedkeuringsgeschiedenis- en Purchase Order-data te extraheren. De exacte rolnamen en navigatielabels verschillen per Oracle-release. Gebruik daarom het bijbehorende BICC-beheergebied in jouw tenant.
Bepaal welke PVO's je voor de extractie nodig hebt en activeer deze. Gebruik RequisitionHeaderPVO, of het bijbehorende aanvraagkop-PVO in jouw omgeving, samen met de PVO's die aanvraagregels, de geschiedenis van aanvraagstatussen, de geschiedenis van goedkeuringsworkflows en Purchase Order-verwijzingen beschikbaar maken. Ga er niet van uit dat één PVO de workflowgeschiedenis of de geschiedenis van het aanmaken van Purchase Orders bevat. Noteer de exacte PVO-namen en attributen die in jouw tenant beschikbaar zijn.
Configureer een BICC-job voor een incrementele of historische bulkextractie. Stel het extractievenster in met [Start date parameter] en [End date parameter] en configureer de job om CSV-bestanden naar de goedgekeurde cloudopslaglocatie te sturen. Gebruik voor een eerste inlading een voldoende brede historische periode. Gebruik voor terugkerende inladingen overlappende vensters om late updates op te vangen. Verwijder daarna dubbele gebeurtenissen op basis van de case-ID, activiteit, timestamp van de gebeurtenis en, als die beschikbaar is, de brongebeurtenis-ID.
Configureer de extractiekolommen. Neem de aanvraag-ID, ID's van aanvraagkop en -regel, aanvrager, afdeling, bedrag, status, benodigde datum, bedrijfseenheid, reden van afwijzing, aanmaak- en updatetimestamps, timestamps van statusovergangen, timestamps van toewijzing en acties voor goedkeuring, goedkeuringsactie, Purchase Order-verwijzing en de BICC-verversingstimestamp op. Gebruik de exacte attribuutnamen die door de geselecteerde PVO's beschikbaar worden gemaakt. Als een attribuut niet beschikbaar is, koppel je dit aan [Configure based on your system] en documenteer je de beperking. Vervang het niet door een niet-gecontroleerd veld.
Extraheer de bron-CSV-bestanden en bewaar de originele bestanden. Laad elk bestand in een staginggebied, bewaar de naam van het bron-PVO en de bestandsnaam, normaliseer timestamps naar één afgesproken tijdzone en verwerk Oracle-datum- en timestampwaarden op een consistente manier. Behandel ID's als tekst om verlies van voorloopnullen of precisie te voorkomen.
Zet de brondata om naar een eventtabel met één rij per expliciete bedrijfsgebeurtenis. De uitvoer moet PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate bevatten. Voeg de aanbevolen attributen toe als die beschikbaar zijn. Laat ProcessMind geen gebeurtenissen afleiden uit status- of veldwijzigingen. De transformatie moet expliciet rijen maken voor alle twaalf activiteiten uit de query.
Bouw de eventrijen op basis van het juiste bronbewijs. Gebruik bewijs van het aanmaken van een record voor Requisition Created, een expliciete indieningsovergang voor Requisition Submitted, een expliciete intrekkingsactie of -overgang voor Requisition Withdrawn, een vastgestelde wijziging na indiening of nieuwe versie voor Requisition Amended, workflowtoewijzing voor Approval Step Started en expliciete acties uit de goedkeuringsgeschiedenis voor Approval Step Approved, Approval Step Rejected en Approval Step Returned. Gebruik een expliciete statusovergang voor Requisition Approved, Requisition Rejected en Requisition Closed. Gebruik een expliciet record of aanmaaktimestamp van een Purchase Order die aan de aanvraag is gekoppeld voor Purchase Order Created.
Pas deterministische deduplicatie toe. Als meerdere bronrijen dezelfde gebeurtenis vertegenwoordigen, bewaar je één rij met de meest specifieke timestamp van de gebeurtenis en, als die beschikbaar is, een stabiele bron-ID. Voeg afzonderlijke goedkeuringsstappen niet samen alleen omdat ze dezelfde aanvraag-ID hebben. Bewaar afzonderlijke goedkeuringsgebeurtenissen voor verschillende goedkeurders of workflowstappen.
Valideer het uiteindelijke event log. Controleer of elke verplichte activiteit voorkomt, elke gebeurtenis een case-ID en timestamp heeft, timestamps binnen het extractievenster vallen of verklaard worden door laat binnengekomen updates en aanbevolen attributen zijn ingevuld als de bron deze levert. Stem het aantal aanvragen en de koppelingen met Purchase Orders af op de bronextracties.
Exporteer het definitieve event log als UTF-8-CSV met één kopregel en één gebeurtenis per rij. Gebruik exact de kolomnamen PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate, plus de aanbevolen attributen. Upload de CSV naar ProcessMind en configureer PurchaseRequisitionId als case-ID, ActivityName als activiteit en EventTime als timestamp van de gebeurtenis.

Configuratie

Extractiemethode: Oracle BI Cloud Connector bulkdata-extractie, geleverd als CSV-bestanden op de geconfigureerde locatie voor cloudopslag.
Bronobjecten: gebruik RequisitionHeaderPVO en de bijbehorende PVO's voor requisitionregels, statushistorie, geschiedenis van de goedkeuringsworkflow en verwijzingen naar inkooporders die in de tenant beschikbaar zijn. De exacte PVO-namen en attributen moeten in de omgeving worden bevestigd.
Vereiste uitvoerkolommen: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate.
Aanbevolen uitvoerkolommen: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason en BusinessUnit.
Datumbereik: gebruik drie tot zes maanden voor routinematige analyses. Gebruik indien nodig een ruimer bereik voor een eerste historische lading. Gebruik bij terugkerende extracties overlappende extractievensters om late updates vast te leggen en verwijder daarna dubbele records.
Filters: pas [Company-specific filter], [Document Type filter], [Business Unit filter] en [Date range filter] alleen toe wanneer deze attributen beschikbaar zijn in de geselecteerde PVO's. Bevestig of het filter betrekking heeft op de aanmaakdatum, updatedatum, datum van de statusovergang of een andere datum uit de bron.
Incrementele extractie: geef de voorkeur aan een updatetimestamp of een door BICC ondersteund mechanisme voor incrementele extractie. Bewaar de watermark van de laatste geslaagde extractie en neem een kleine overlap op in de volgende run.
Volledigheid van events: configureer afzonderlijke bronextracties wanneer requisitionheaders geen goedkeuringshistorie, statusovergangen, wijzigingen of het aanmaken van inkooporders bevatten. Met alleen een headerextract van de huidige status kun je historische events niet betrouwbaar reconstrueren.
Prestaties: beperk het datumbereik en de geselecteerde kolommen, partitioneer grote extracties waar dat wordt ondersteund, vermijd onnodige beschrijvende attributen en verwerk CSV-bestanden in batches. Bewaar bronbestanden voor reconciliatie.
Opslag: configureer een goedgekeurde locatie voor cloudopslag met voldoende capaciteit, bewaartermijn, encryptie en toegangsbeheer. Bevestig dat het extractieaccount bestanden kan schrijven en dat het transformatieproces ze kan lezen.
Vereisten: beschikbaarheid van BICC, toegang tot de relevante Oracle Fusion-gegevens voor inkoop en goedkeuringen, de juiste integratieautorisaties, toegang tot de geselecteerde PVO's en eventuele vereiste Oracle-abonnementen of toegekende functies. De exacte rolnamen, licenties en navigatiepaden hangen af van de Oracle-release en de configuratie van de tenant.
Tijdverwerking: normaliseer alle timestamps uit de bron naar een gedocumenteerde tijdzone en bewaar de oorspronkelijke timestamp wanneer dit nodig is voor controleerbaarheid.
Caseverwerking: gebruik PurchaseRequisitionId als case-identificatie. Gebruik geen identificatie van een requisitionregel als case-identificatie, tenzij het proces bewust op regelniveau is gemodelleerd.

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

Klaar om aan de slag te gaan?

Gebruik deze template om je Purchase to Pay - Requisition-proces te optimaliseren en nieuwe efficiëntie te bereiken. Maak je klaar om je inkoopprocessen te verbeteren.

Terug naar de verbetergids Template downloaden

Bereik 30% snellere Purchase to Pay - Requisition

Maak je Oracle P2P Requisition efficiënter en verkort de doorlooptijd met 30%.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Je bent in een paar minuten klaar.

Jouw datatemplate voor Purchase to Pay - Requisition

Jouw datatemplate voor Purchase to Pay - Requisition

Purchase to Pay - Requisition-attributen

Purchase to Pay - Requisition-activiteiten

Extractiegidsen

Oracle Transactional Business Intelligence (OTBI)-export

Stappen

Configuratie

a Voorbeeldquery sql

Oracle BI Publisher-extractie op basis van een SQL-datamodel

Stappen

Configuratie

a Voorbeeldquery sql

Python-script via de Oracle Fusion REST API

Stappen

Configuratie

a Voorbeeldquery python

Oracle BI Cloud Connector (BICC)-bulkdata-extractie

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Bereik 30% snellere Purchase to Pay - Requisition

Jouw datatemplate voor Purchase to Pay - Requisition

Jouw datatemplate voor Purchase to Pay - Requisition

Purchase to Pay - Requisition-attributen

Purchase to Pay - Requisition-activiteiten

Extractiegidsen

Oracle Transactional Business Intelligence (OTBI)-export

Stappen

Configuratie

a Voorbeeldquery sql

Oracle BI Publisher-extractie op basis van een SQL-datamodel

Stappen

Configuratie

a Voorbeeldquery sql

Python-script via de Oracle Fusion REST API

Stappen

Configuratie

a Voorbeeldquery python

Oracle BI Cloud Connector (BICC)-bulkdata-extractie

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Bereik 30% snellere Purchase to Pay - Requisition

We respecteren je privacy