> Continu verbeteren van processen > Van inkoopaanvraag tot betaling > Oracle Fusion Financials > Datatemplate

Datatemplate voor inkoopaanvragen tot betaling

Oracle Fusion Financials

Attributen voor inkoopaanvragen tot betaling(22) Activiteiten voor inkoopaanvragen tot betaling(12) Extractiegidsen(4)

Datatemplate voor inkoopaanvragen tot betaling

Deze template laat zien welke data je nodig hebt om het proces van inkoopaanvraag tot betaling te analyseren. Je vindt erin welke attributen je verzamelt, welke belangrijke activiteiten je bijhoudt en hoe je deze informatie uit Oracle Fusion Financials haalt. Zo bereid je het event log voor op process mining.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om bij te houden
Handleiding voor data-extractie uit Oracle Fusion Financials

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor inkoopaanvragen tot betaling

Dit zijn de aanbevolen datavelden voor het event log waarmee je het proces van inkoopaanvraag tot betaling grondig kunt analyseren.

5 Verplicht 7 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de bedrijfsgebeurtenis die op een bepaald moment in het aanvraagproces plaatsvond.
Beschrijving De activiteit is een afzonderlijke stap of mijlpaal in de levenscyclus van een inkoopaanvraag. Voorbeelden zijn ‘Aanvraag aangemaakt’, ‘Goedkeuringsstap goedgekeurd’ en ‘Inkooporder aangemaakt’. Deze activiteiten zijn afgeleid van statuswijzigingen, gebruikersacties of systeemgebeurtenissen die zijn vastgelegd in auditlogs of transactietabellen van het bronsysteem. 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 procesroutes, bottlenecks, herstelwerk en afwijkingen van de standaardprocedure. Waarom dit belangrijk is Dit vormt de basis van de proceskaart en maakt het mogelijk de workflow voor aanvragen te visualiseren en analyseren. Waar vind je dit? Afgeleid van statuswijzigingen in tabellen zoals POR_REQUISITION_HEADERS_ALL, de transactiegeschiedenis of workflow-auditsporen zoals FA_FUSION_SOAINFRA.WFTASK. Voorbeelden Inkoopaanvraag aangemaaktGoedkeuringsstap goedgekeurdInkoopaanvraag afgewezenInkooporder aangemaakt
	Gebeurtenistijd EventTime	De timestamp die aangeeft wanneer de activiteit plaatsvond.
Beschrijving De gebeurtenistijd legt de exacte datum en tijd vast waarop een activiteit plaatsvond. Deze timestamp is nodig om gebeurtenissen binnen een case chronologisch te ordenen. De waarde komt uit aanmaakdatums, datums van de laatste wijziging of timestamps van specifieke acties in het systeem. Bij analyses gebruik je de gebeurtenistijd om alle tijdsgebonden metrieken te berekenen, zoals doorlooptijden tussen activiteiten, wachttijden en de totale duur van een case. De tijd is belangrijk om bottlenecks te vinden, prestaties af te zetten tegen SLA’s en het verloop van het aanvraagproces in de tijd te begrijpen. Waarom dit belangrijk is Dit attribuut is nodig om tijdgerelateerde KPI’s te berekenen, gebeurtenissen in de juiste volgorde te zetten en procesprestaties en bottlenecks te analyseren. Waar vind je dit? Deze waarde komt meestal uit een kolom als ‘LAST_UPDATE_DATE’ of ‘CREATION_DATE’ bij de transactie of statuswijziging. Je vindt die vaak in tabellen zoals POR_REQUISITION_HEADERS_ALL of in tabellen met workflowgeschiedenis. Voorbeelden 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID van inkoopaanvraag PurchaseRequisitionId	De unieke identificatiecode van een inkoopaanvraag. Deze dient als case-ID voor het proces.
Beschrijving De inkoopaanvraag-ID is de centrale identificatiecode die alle activiteiten voor een specifieke aanvraag van goederen of diensten met elkaar verbindt. Elke aanvraag krijgt bij het aanmaken een unieke ID, die gedurende de hele levenscyclus hetzelfde blijft. Bij process mining gebruik je dit attribuut om alle bijbehorende gebeurtenissen, zoals het aanmaken, indienen, goedkeuren en afsluiten van de aanvraag, te groeperen in één case. Zo kun je het volledige verloop van de aanvraag analyseren, proceskaarten visualiseren, doorlooptijden berekenen en varianten per aanvraag onderzoeken. Waarom dit belangrijk is Dit is het belangrijkste attribuut om een aanvraag van begin tot eind te volgen. Het vormt de basis voor alle analyses op caseniveau en KPI-berekeningen. Waar vind je dit? 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 gehaald.
Beschrijving Dit attribuut geeft aan waar de procesdata vandaan komt. 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 de herkomst van data, het oplossen van problemen en het bewaken van de datakwaliteit. Het geeft context bij de bron van de procesgebeurtenissen die je analyseert. Waarom dit belangrijk is Geeft belangrijke context over de herkomst van data. Dat is van belang voor datagovernance en bij het combineren van data uit meerdere systemen. Waar vind je dit? Dit is een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Oracle Fusion Financials
	Laatste data-update LastDataUpdate	De timestamp van de meest recente data-update vanuit het bronsysteem.
Beschrijving Dit attribuut geeft aan wanneer de data voor het laatst uit Oracle Fusion Financials is gehaald. Het geldt voor de hele dataset, niet voor afzonderlijke gebeurtenissen. Analisten gebruiken deze informatie om te zien hoe actueel de data is en wanneer de nieuwste transacties zijn meegenomen. Dit is belangrijke metadata voor rapportages in dashboards 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 nieuwste beschikbare informatie zijn gebaseerd. Waar vind je dit? Deze timestamp wordt tijdens de data-extractie aangemaakt 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 ‘Financiën’, ‘IT’ of ‘Marketing’. De waarde komt meestal uit het gebruikersprofiel van de aanvrager in het HR-systeem. Een analyse per afdeling is een gebruikelijke manier om procesdata op te splitsen. Je ziet bijvoorbeeld of bepaalde afdelingen vaker aanvragen afgewezen krijgen of langere doorlooptijden hebben. Die informatie helpt bij gerichte procesverbeteringen. Dit is een belangrijke dimensie voor het dashboard ‘Prestatiemetrieken voor aanvragers’. Waarom dit belangrijk is Maakt het mogelijk processen per bedrijfseenheid te analyseren en patronen, prestaties en compliancekwesties per afdeling zichtbaar te maken. Waar vind je dit? Meestal afgeleid van het profiel van de aanvrager. Hiervoor moet je vaak de aanvraagtabel koppelen aan een HR-tabel of gebruikersdirectory met afdelingsgegevens. 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 het bedrijf waarvoor de aanvraag wordt gedaan. Dit is een hoger organisatieniveau dan een afdeling. Door data per bedrijfseenheid te analyseren, kun je de prestaties van verschillende delen van de organisatie op hoofdlijnen vergelijken. Het management ziet zo of procesproblemen lokaal of organisatiebreed spelen en waar verbeteringen nodig zijn. Dit is een belangrijke filterdimensie voor vrijwel alle dashboards en KPI’s. Waarom dit belangrijk is Geeft context op organisatieniveau, zodat je prestaties tussen verschillende delen van de organisatie kunt vergelijken en strategische analyses kunt uitvoeren. Waar vind je dit? Dit is een belangrijk organisatieveld in Oracle Fusion. Het is meestal beschikbaar in de aanvraagkop, in tabellen zoals POR_REQUISITION_HEADERS_ALL. Voorbeelden Bedrijfseenheid Noord-AmerikaBedrijfseenheid EuropaHoofdkantoor
	Naam aanvrager RequesterName	De naam van de medewerker die de inkoopaanvraag heeft aangemaakt en ingediend.
Beschrijving Dit attribuut geeft aan wie de aanvraag voor goederen of diensten heeft ingediend. Deze informatie wordt meestal aan het begin van het proces vastgelegd, wanneer de aanvraag wordt aangemaakt. Een analyse van procesprestaties per aanvrager is belangrijk voor het dashboard ‘Prestatiemetrieken voor aanvragers’. Je ziet ermee welke gebruikers of groepen mogelijk extra training nodig hebben, bijvoorbeeld door veel wijzigingen of afwijzingen, of lange doorlooptijden bij hun aanvragen. Zo krijg je zicht op de menselijke kant van het proces. Waarom dit belangrijk is Maakt het mogelijk prestaties per aanvrager te analyseren, opleidingsbehoeften te vinden en te zien welke gebruikers of afdelingen efficiënt werken. Waar vind je dit? Afkomstig uit de gegevens van de aanvraagkop, vaak door de ID van de aanvrager te koppelen aan een tabel met medewerkers- of gebruikersgegevens. Zoek naar velden die verband houden met ‘PREPARER_ID’ in POR_REQUISITION_HEADERS_ALL en koppel die aan PER_ALL_PEOPLE_F. Voorbeelden Jan JansenAnna de VriesEmma Bakker
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft wanneer een aanvraag of goedkeuringsstap wordt afgewezen.
Beschrijving Wanneer een aanvraag wordt afgewezen, geeft de goedkeurder meestal een reden op door een optie uit een vaste lijst te kiezen of vrije tekst in te voeren. Dit attribuut legt die toelichting vast. Dit attribuut is belangrijk voor oorzaakanalyse van procesproblemen. Het ondersteunt het dashboard ‘Trends in wijzigingen en afwijzingen’ en geeft inzicht in de reden achter afwijzingen. Door afwijzingsredenen te analyseren, vind je terugkerende problemen, zoals een onjuiste codering, budgetoverschrijdingen of overtredingen van beleid. Die kun je vervolgens aanpakken met training of systeemcontroles. Waarom dit belangrijk is Geeft inzicht in de redenen voor afgewezen aanvragen. Zo kun je gericht verbeteringen doorvoeren, herstelwerk verminderen en het percentage aanvragen dat zonder handmatige tussenkomst wordt verwerkt verhogen. Waar vind je dit? Afkomstig uit workflowopmerkingen of specifieke velden met afwijzingsredenen in het workflow-auditspoor, mogelijk in tabellen rond FA_FUSION_SOAINFRA.WFTASK of bijbehorende opslag voor opmerkingen. Voorbeelden Onjuiste grootboekrekeningBudget van kostenplaats overschredenNiet-voorkeursleverancier geselecteerdDubbele aanvraag
	Status aanvraag RequisitionStatus	De huidige of definitieve status van de inkoopaanvraag.
Beschrijving Dit attribuut geeft op een bepaald moment de algemene status van de aanvraag aan, of de uiteindelijke uitkomst, zoals ‘Goedgekeurd’, ‘Afgewezen’, ‘In behandeling’ of ‘Gesloten’. Veel activiteiten in het event log worden hieruit afgeleid. Dit attribuut is belangrijk voor het dashboard ‘Overzicht aanvraagstatus’. Het geeft een momentopname van de huidige werkvoorraad en achterstand. Je gebruikt het ook om KPI’s op basis van uitkomsten te berekenen, zoals het afwijzingspercentage van aanvragen, door cases te filteren die eindigen met een bepaalde status. Waarom dit belangrijk is Geeft een momentopname van de huidige status van aanvragen en helpt bij het bepalen van de uiteindelijke uitkomst voor KPI-berekeningen. Waar vind je dit? 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 is de som van de bedragen van alle regels in één inkoopaanvraag. Het geeft inzicht in de financiële omvang van elke aanvraag. Bij process mining kun je het totaalbedrag voor allerlei analyses gebruiken. Filter bijvoorbeeld op aanvragen met een hoge waarde, waarvoor vaak andere goedkeuringsroutes of extra controles gelden. In dashboards kun je bekijken hoe procesmetrieken, zoals doorlooptijd of afwijzingspercentage, samenhangen met de waarde van de aanvraag. Waarom dit belangrijk is Geeft financiële context, zodat je procesverbeteringen op waarde kunt prioriteren en kunt zien hoe het aanvraagbedrag het proces beïnvloedt. Waar vind je dit? Te vinden in 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 aanvraagregels in POR_REQUISITION_LINES_ALL op te tellen. Voorbeelden 550.0012500.7599.99
	Uiterste datum RequiredByDate	De datum waarop de aanvrager de goederen of diensten nodig heeft.
Beschrijving De aanvrager geeft deze datum op als uiterste datum voor ontvangst van de aangevraagde artikelen. De datum dient als interne SLA-doelstelling voor het inkoopproces. Dit attribuut vormt de basis voor het dashboard ‘Prestaties op uiterste datum’ en de KPI ‘Percentage aanvragen op tijd geleverd’. Vergelijk deze datum met de werkelijke aanmaakdatum van de inkooporder of de ontvangstdatum van de goederen. Zo zie je hoe goed het inkoopproces aan de interne vraag voldoet en waar structurele vertragingen optreden. Waarom dit belangrijk is Belangrijk om procesprestaties af te zetten tegen interne deadlines en te zien of het inkoopproces op tijd aan de bedrijfsbehoeften voldoet. Waar vind je dit? Meestal opgeslagen op het niveau van de aanvraagregel, in tabellen zoals POR_REQUISITION_LINES_ALL en een veld zoals ‘NEED_BY_DATE’. Voorbeelden 2023-11-012023-12-152024-01-31
	Artikelbeschrijving ItemDescription	De beschrijving van het product of de dienst die op een aanvraagregel wordt aangevraagd.
Beschrijving Dit attribuut bevat een tekstuele beschrijving van het artikel dat wordt ingekocht. Het geeft specifieke informatie over de aangevraagde goederen of diensten. De artikelbeschrijving is vaak ongestructureerd, maar biedt wel waardevolle context voor analyses. Je kunt ermee filteren op specifieke aankopen die niet onder het type aanvraag vallen. Een analist kan bijvoorbeeld zoeken naar alle aanvragen met ‘Softwarelicentie’ om de bijbehorende processtroom en doorlooptijd te onderzoeken. Waarom dit belangrijk is Geeft meer informatie over wat er wordt gekocht, zodat je specifieke goederen of diensten nauwkeuriger kunt filteren en analyseren. Waar vind je dit? 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 - project vierde kwartaalJaarlijkse verlenging van softwareonderhoud
	Automatisch uitgevoerd IsAutomated	Een vlag die aangeeft of een activiteit automatisch door het systeem is uitgevoerd.
Beschrijving Dit attribuut geeft aan welke gebeurtenissen in het proces zijn uitgevoerd door een systeemgebruiker of geautomatiseerde agent in plaats van een medewerker. Voorbeelden zijn statuswijzigingen die het systeem uitvoert of automatische goedkeuringen voor aanvragen met een lage waarde. Met dit attribuut kun je de mate van automatisering in het proces meten. Je kunt de snelheid en efficiëntie van automatische en handmatige stappen vergelijken en kansen voor verdere automatisering vinden. Waarom dit belangrijk is Helpt de mate van automatisering in het proces te meten en kansen te vinden om handmatige taken te automatiseren. Waar vind je dit? Afgeleid door te controleren of de gebruiker bij een activiteit een systeem- of serviceaccount is. Hiervoor is een lijst met bekende systeemgebruikers-ID’s nodig. Voorbeelden truefalse
	Gebruikersnaam UserName	De naam van de gebruiker die een specifieke activiteit heeft uitgevoerd, zoals een goedkeurder of bewerker.
Beschrijving Naam aanvrager geeft aan wie de aanvraag heeft gestart. Gebruikersnaam geeft aan wie een bepaalde gebeurtenis in het proces heeft uitgevoerd, zoals een goedkeuring of afwijzing. Dit is vooral belangrijk bij workflows met meerdere goedkeuringsstappen, waarbij verschillende mensen betrokken zijn. Dit attribuut is belangrijk om bottlenecks in het goedkeuringsproces te analyseren en de prestaties van specifieke goedkeurders of teams te meten. Het ondersteunt het dashboard ‘Bottlenecks in goedkeuringsworkflows’ doordat je de verwerkingstijden per gebruiker in de goedkeuringsketen kunt analyseren. Waarom dit belangrijk is Geeft aan wie elke gebeurtenis heeft uitgevoerd. Zo kun je overdrachtstijden, prestaties van goedkeurders en de inzet van medewerkers analyseren. Waar vind je dit? Afkomstig uit workflowgeschiedenis of tabellen met auditsporen, zoals FA_FUSION_SOAINFRA.WFTASK, waarin de gebruiker bij elke voltooide taak wordt vastgelegd. Voorbeelden David LeeSusan ChenMichael Brown
	Goedkeuringsroute ApprovalWorkflowPath	De vooraf bepaalde volgorde van goedkeurders of goedkeuringsgroepen die nodig is voor de aanvraag.
Beschrijving Dit attribuut beschrijft de verwachte, standaard goedkeuringsprocedure voor een aanvraag op basis van het bedrijfsbeleid. Daarbij spelen factoren mee zoals het aanvraagbedrag, het type aanvraag en de afdeling. Het geeft het beoogde procesmodel weer. De goedkeuringsroute is belangrijk voor compliance en conformiteitsanalyse. Het attribuut ondersteunt het dashboard ‘Compliance- en afwijkingsanalyse’ en de KPI ‘Conformiteitsindex van aanvragen’. Je kunt de werkelijk gevolgde goedkeuringsstappen rechtstreeks vergelijken met de voorgeschreven route. Afwijkingen kunnen wijzen op overtredingen van beleid of inefficiënte processen. Waarom dit belangrijk is Maakt conformiteitscontroles mogelijk door de werkelijke processtroom te vergelijken met de vereiste goedkeuringshiërarchie. Zo worden aanvragen zichtbaar die niet aan de regels voldoen. Waar vind je dit? Deze informatie is ingesteld in de Oracle Fusion BPM Worklist of Approval Management Engine (AMX). De vastgelegde route voor elke aanvraag ophalen kan ingewikkeld zijn en vereist mogelijk een query op configuratietabellen. Voorbeelden Manager > Directeur > Financieel directeurEigenaar kostenplaats > IT-beveiligingManager > Afdelingshoofd
	Inkoopordernummer PurchaseOrderNumber	De identificatiecode van de inkooporder die op basis van 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. Met deze ID kun je het vervolg van het proces na de aanvraag volgen. Je kunt er de KPI ‘Doorlooptijd van aanvraag tot inkooporder’ mee berekenen en het dashboard ‘Doorlooptijd aanvraag naar inkooporder’ ondersteunen. Ook kun je de procesdata van de aanvraag combineren met die van de inkooporder en facturatie voor een volledige analyse van inkoop tot betaling. Waarom dit belangrijk is Koppelt de aanvraag aan de daaropvolgende inkooporder. Zo kun je de doorlooptijd van aanvraag tot inkooporder meten en het volledige proces analyseren. Waar vind je dit? Deze informatie wordt opgeslagen zodra een inkooporder is aangemaakt. Je vindt die meestal via de verwijzingen naar de oorspronkelijke aanvraag in de distributietabellen van de inkooporder, zoals PO_DISTRIBUTIONS_ALL, die terugverwijzen naar de aanvraagregel. Voorbeelden IO-2023-5832IO-2023-5833IO-2023-5834
	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. De waarde wordt bepaald door te controleren of de activiteit ‘Aanvraag gewijzigd’ voorkomt in de geschiedenis van de case. Deze vlag vereenvoudigt analyses en KPI-berekeningen. Je gebruikt die rechtstreeks om de KPI ‘Wijzigingspercentage aanvragen’ te berekenen en cases te vinden die niet zonder handmatige tussenkomst zijn verwerkt. Ook kun je procesmetrieken eenvoudig vergelijken tussen gewijzigde en ongewijzigde aanvragen. Waarom dit belangrijk is Vereenvoudigt de berekening van het wijzigingspercentage en maakt het makkelijk om gewijzigde en ongewijzigde aanvragen te vergelijken. Waar vind je dit? Dit attribuut staat niet in het bronsysteem, maar wordt tijdens de datatransformatie berekend op basis van wijzigingsactiviteiten in het event log. Voorbeelden truefalse
	Naam leverancier SupplierName	De naam van de voorgestelde of vooraf geselecteerde leverancier van de goederen of diensten.
Beschrijving Dit attribuut geeft aan bij welke leverancier de goederen of diensten naar verwachting worden ingekocht. De aanvrager kan een leverancier voorstellen, of het systeem kan er een selecteren op basis van catalogi of eerdere afspraken. Een analyse per leverancier kan belangrijke inkooppatronen zichtbaar maken. Je ziet bijvoorbeeld of aanvragen voor bepaalde leveranciers langer op goedkeuring wachten of vaker worden afgewezen. Deze informatie kan helpen bij leveranciersrelaties en de inkoopstrategie. Waarom dit belangrijk is Maakt het mogelijk procesprestaties per leverancier te analyseren. Dat kan helpen bij de inkoopstrategie en het beheer van leveranciersrelaties. Waar vind je dit? Te vinden in de tabel met aanvraagregels, POR_REQUISITION_LINES_ALL, vaak gekoppeld via VENDOR_ID aan een tabel met leveranciersgegevens, zoals POZ_SUPPLIERS. Voorbeelden Kantoorbenodigdheden B.V.Global Tech SolutionsCreatief marketingbureau
	Rechtstreeks verwerkt IsStraightThrough	Een vlag die aangeeft of de aanvraag is goedgekeurd zonder wijzigingen of afwijzingen.
Beschrijving Deze berekende vlag geeft aan welke aanvragen van indiening tot goedkeuring zijn verwerkt zonder herstelwerk, zoals wijzigingen of afwijzingen. De vlag staat voor een probleemloos verlopen proces voor één case. Dit attribuut vormt de basis voor de KPI ‘Percentage aanvragen rechtstreeks verwerkt’. Door de kenmerken van zulke aanvragen te analyseren, zoals de betrokken afdelingen, aanvragers of aanvraagtypen, kun je goede werkwijzen en kansen voor automatisering vinden. Bij aanvragen die niet rechtstreeks zijn verwerkt, zie je juist wat de belangrijkste oorzaken van inefficiëntie zijn. Waarom dit belangrijk is Meet de procesefficiëntie rechtstreeks en vormt de basis voor de KPI ‘Percentage aanvragen rechtstreeks verwerkt’. Zo zie je waardoor herstelwerk ontstaat. Waar vind je dit? Dit attribuut wordt tijdens de datatransformatie berekend. Een case krijgt de waarde waar als er geen activiteiten ‘Aanvraag gewijzigd’ of ‘Goedkeuringsstap afgewezen’ voorkomen. Voorbeelden truefalse
	Type aanvraag RequisitionType	De categorie van de aanvraag, bijvoorbeeld een aanvraag voor goederen of diensten.
Beschrijving Dit attribuut deelt aanvragen in op basis van wat er wordt aangevraagd. Veelvoorkomende typen zijn goederen, diensten en kapitaaluitgaven. Het type kan invloed hebben op de vereiste goedkeuringsworkflow en de inkoopstrategie. Bij analyses kun je het type aanvraag gebruiken om data te filteren en te vergelijken. Zo kun je bijvoorbeeld nagaan of aanvragen voor diensten een langere goedkeuringsdoorlooptijd hebben dan aanvragen voor goederen. Dit helpt je te begrijpen of verschillende typen aanvragen andere procespatronen of bottlenecks hebben. Waarom dit belangrijk is Maakt het mogelijk de analyse op te splitsen en te zien hoe het proces verschilt per type aankoop, zoals goederen of diensten. Waar vind je dit? Vaak bepaald door het type of de categorie van de aanvraagregel die bij het aanmaken van de aanvraag is geselecteerd. De waarde kan zijn opgeslagen in de tabel met aanvraagregels, POR_REQUISITION_LINES_ALL. Voorbeelden GoederenDienstenKapitaaluitgaven
	Valuta CurrencyCode	De valutacode voor het aanvraagbedrag, zoals USD of EUR.
Beschrijving Dit attribuut geeft aan in welke valuta het totaalbedrag van de aanvraag is uitgedrukt. Bij internationale organisaties kunnen aanvragen in verschillende valuta worden aangemaakt. Deze informatie is nodig om financiële data goed te interpreteren en samen te voegen. Gebruik bij analyses met geldbedragen de valutacode om bedragen correct te vergelijken. Filter bijvoorbeeld op één valuta of reken alle bedragen om naar dezelfde valuta. Waarom dit belangrijk is Zorgt voor correcte financiële analyses en rapportages, vooral bij internationale organisaties die met meerdere valuta werken. Waar vind je dit? Meestal te vinden in de tabel met aanvraagkoppen, naast de bedragvelden, bijvoorbeeld in POR_REQUISITION_HEADERS_ALL. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Activiteiten voor inkoopaanvragen tot betaling

Dit zijn de belangrijke processtappen en mijlpalen voor het event log, zodat je het proces van inkoopaanvraag tot betaling goed in kaart kunt brengen.

6 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Inkoopaanvraag aangemaakt	Dit markeert het begin van het inkoopproces: een gebruiker slaat voor het eerst een nieuwe inkoopaanvraag op. In het systeem wordt dit meestal vastgelegd als een expliciete aanmaakregistratie met een bijbehorende timestamp.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het aanvraagproces. Door de tijd tussen aanmaken en indienen te analyseren, kun je vertraging bij het afronden van aanvragen opsporen. Waar vind je dit? Deze gebeurtenis staat in de tabel POR_REQUISITION_HEADERS_ALL. De waarde komt uit de kolom creation_date, die wordt vastgelegd wanneer een nieuwe aanvraag-ID wordt aangemaakt. Vastleggen Gebruik de timestamp waarop de kopregel van de aanvraag is aangemaakt. Gebeurtenistype explicit
	Inkoopaanvraag afgesloten	Dit geeft aan dat de levenscyclus van een aanvraag is afgerond. Alle regels zijn geleverd, bijvoorbeeld doordat ze zijn omgezet in inkooporders, of geannuleerd. Je kunt dit afleiden uit een laatste statuswijziging.
Waarom dit belangrijk is Dit is de belangrijkste gebeurtenis die het proces succesvol afsluit. De aanvraag is volledig verwerkt en er zijn geen verdere acties nodig. Waar vind je dit? Af te leiden uit een wijziging van de status van de aanvraagkop naar ‘CLOSED’ in POR_REQUISITION_HEADERS_ALL. Vastleggen Bepaal de timestamp waarop de documentstatus van de aanvraag verandert in ‘Closed’. Gebeurtenistype inferred
	Inkoopaanvraag afgewezen	Dit is de definitieve afwijzing van de aanvraag, waarmee het proces voor deze aanvraag eindigt. Je kunt dit afleiden uit de statuswijziging naar ‘Rejected’.
Waarom dit belangrijk is Deze activiteit is het eindpunt voor aanvragen die niet zijn goedgekeurd. Analyse ervan is belangrijk om de KPI voor het afwijzingspercentage van aanvragen en de redenen voor afwijzing te begrijpen. Waar vind je dit? Af te leiden uit de wijziging van de documentstatus naar ‘REJECTED’ in de tabel POR_REQUISITION_HEADERS_ALL. Vastleggen Bepaal de timestamp waarop de documentstatus voor het eerst op ‘Rejected’ wordt gezet. Gebeurtenistype inferred
	Inkoopaanvraag goedgekeurd	Dit markeert de definitieve goedkeuring van de inkoopaanvraag, nadat alle stappen in de workflow zijn doorlopen. Je kunt dit afleiden uit de statuswijziging naar ‘Approved’.
Waarom dit belangrijk is Dit belangrijke moment geeft aan dat de aanvraag klaar is voor verdere inkoop. Het is het eindpunt voor het meten van de totale goedkeuringsduur van de aanvraag. Waar vind je dit? Af te leiden uit een wijziging van het documentstatusveld naar ‘APPROVED’ in de tabel POR_REQUISITION_HEADERS_ALL. De datum van deze statuswijziging is het tijdstip van de gebeurtenis. Vastleggen Bepaal de timestamp waarop de documentstatus voor het eerst op ‘Approved’ wordt gezet. Gebeurtenistype inferred
	Inkoopaanvraag ingediend	Dit is het moment waarop de gebruiker de ingevulde aanvraag indient voor goedkeuring. Dit wordt vastgelegd wanneer de status verandert van ‘Incomplete’ of ‘Draft’ naar een status die aangeeft dat goedkeuring nodig is.
Waarom dit belangrijk is Deze activiteit start de goedkeuringsronde. Het is een belangrijk moment om de goedkeuringsduur van de aanvraag en de totale doorlooptijd te meten. Waar vind je dit? Af te leiden uit een statuswijziging in de tabel POR_REQUISITION_HEADERS_ALL, bijvoorbeeld wanneer de status verandert in ‘PENDING APPROVAL’. Vaak wordt ook de indieningsdatum apart opgeslagen. Vastleggen Bepaal de timestamp waarop het statusveld van het document voor het eerst verandert in ‘Pending Approval’. Gebeurtenistype inferred
	Inkooporder aangemaakt	Deze gebeurtenis vindt plaats wanneer een goedgekeurde aanvraagregel wordt gebruikt om een inkooporder aan te maken. Hiermee is het aanvraagproces gekoppeld aan het vervolg van het inkoopproces.
Waarom dit belangrijk is Dit is een belangrijk moment om de doorlooptijd van aanvraag tot inkooporder te meten. Vertraging wijst op bottlenecks bij de overdracht van goedkeuring naar inkoop. Waar vind je dit? Dit is een expliciete gebeurtenis. De koppeling tussen de aanvraag en de inkooporder staat in tabellen zoals PO_LINE_LOCATIONS_ALL. Die bevat een verwijzing naar de ID van de oorspronkelijke aanvraagregel. Vastleggen Zoek de aanmaakdatum van de inkooporder die verwijst naar de betreffende aanvraag-ID. Gebeurtenistype explicit
	Goedkeuringsstap afgewezen	Een goedkeurder wijst de aanvraag af. Meestal gaat die 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 leidt vaak tot herstelwerk en vertraging. Door afwijzingen te analyseren, kun je problemen met naleving, budgetten of onduidelijke onderbouwingen opsporen. Waar vind je dit? Haal deze gegevens op uit de actiegeschiedenis van de aanvraag. Het workflowsysteem legt de actie ‘REJECT’ vast met een timestamp. Vastleggen Gebruik de timestamp van de actie ‘REJECT’ in het actielogboek van de workflow. Gebeurtenistype explicit
	Goedkeuringsstap gestart	Dit markeert het moment waarop een aanvraag in de workflow aan een specifieke goedkeurder of goedkeuringsgroep wordt toegewezen. Je kunt dit ophalen uit het transactielogboek van de workflow-engine.
Waarom dit belangrijk is Deze activiteit is nodig om de wachttijd per goedkeuringsstap te berekenen. Zo kun je bottlenecks opsporen die worden veroorzaakt door specifieke goedkeurders of niveaus in de goedkeuringshiërarchie. Waar vind je dit? Haal deze gegevens op uit de workflowtabellen van Oracle Fusion, waarin taken aan gebruikers worden toegewezen. Gebruik de timestamp waarop de goedkeuringstaak is toegewezen. Vastleggen Gebruik de timestamp waarop de taak voor de betreffende aanvraag in de workflowgeschiedenis is aangemaakt. Gebeurtenistype explicit
	Goedkeuringsstap goedgekeurd	Dit is de actie waarmee een goedkeurder de aanvraag in de toegewezen stap van de workflow goedkeurt. De gebeurtenis wordt expliciet vastgelegd in de goedkeuringsgeschiedenis.
Waarom dit belangrijk is Door afzonderlijke goedkeuringsstappen bij te houden, kun je de werkelijke goedkeuringsroute in kaart brengen en de verwerkingstijd per niveau in de hiërarchie meten. Waar vind je dit? Haal deze gegevens op uit de actiegeschiedenis van de aanvraag. Die 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’ in het actielogboek van de workflow. Gebeurtenistype explicit
	Goedkeuringsstap teruggestuurd	Een goedkeurder stuurt de aanvraag terug naar de opsteller voor aanvullende informatie of kleine correcties, zonder de aanvraag formeel af te wijzen. Meestal wordt dit als expliciete actie vastgelegd in het workflowsysteem.
Waarom dit belangrijk is Dit wijst erop dat er verduidelijking nodig is en zorgt voor een herstelronde die de doorlooptijd verlengt. Door teruggestuurde aanvragen te onderscheiden van afwijzingen, krijg je beter zicht op waar het proces vastloopt. Waar vind je dit? Haal deze gegevens op uit de actiegeschiedenis van de aanvraag. Het workflowsysteem legt de actie ‘RETURN’ of een vergelijkbare actie vast met een timestamp. Vastleggen Gebruik de timestamp van de actie ‘RETURN’ of ‘Request for Information’ in de workflowgeschiedenis. Gebeurtenistype explicit
	Inkoopaanvraag gewijzigd	Deze gebeurtenis betekent dat een gebruiker de aanvraag na de eerste indiening heeft aangepast. Vaak moet de goedkeuringsronde dan opnieuw beginnen. Je kunt dit afleiden 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 vertraging. Deze gebeurtenis ondersteunt rechtstreeks de KPI ‘Wijzigingspercentage van aanvragen’. Waar vind je dit? Je kunt dit afleiden door versienummers van de aanvraag bij te houden of statuswijzigingen naar ‘Incomplete’ na indiening op te sporen. Wijzigingslogboeken of tabellen met auditsporen kunnen deze aanpassingen ook vastleggen. Vastleggen Bepaal wanneer na indiening een nieuwe versie is aangemaakt voor dezelfde aanvraag-ID. Gebeurtenistype inferred
	Inkoopaanvraag 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 de status wijzigt.
Waarom dit belangrijk is Door intrekkingen bij te houden, kun je achterhalen waarom aanvragen voortijdig worden beëindigd. Mogelijke oorzaken zijn gewijzigde behoeften of fouten die gebruikers na het indienen willen herstellen. Waar vind je dit? Af te leiden uit een statuswijziging naar ‘WITHDRAWN’ in de tabel POR_REQUISITION_HEADERS_ALL. De actie staat in de actiegeschiedenis van de aanvraag. Vastleggen Bepaal de timestamp waarop de status van de aanvraag verandert in ‘Withdrawn’. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Oracle Fusion Financials

Stappen

Ga naar Reports and Analytics: Meld je aan bij Oracle Fusion Financials. Open het menu Navigator, ga naar Tools en selecteer Reports and Analytics. Hier vind je de rapportagefuncties.
Maak een nieuwe analyse: Klik in de werkruimte Reports and Analytics op de knop 'Create' en selecteer 'Analysis' in het vervolgmenu. De analyse-editor van Oracle Transactional Business Intelligence (OTBI) wordt in een nieuw tabblad geopend.
Selecteer het onderwerpgebied: Je wordt gevraagd een Subject Area te selecteren. Typ 'Procurement - Requisitions Real Time' in het zoekveld en selecteer dit in de lijst. Dit onderwerpgebied bevat de benodigde data voor gebeurtenissen in de levenscyclus van aanvragen.
Stel de analyse voor aanvraaggebeurtenissen samen: Maak hiervoor een combinatie van meerdere query’s, zodat je elke afzonderlijke gebeurtenis vastlegt. Omdat de OTBI-interface geen functie UNION ALL heeft voor verschillende gebeurtenistypen, maak je één rapport met alle relevante datum- en statusvelden. Sleep op het tabblad 'Criteria' de kolommen uit het querygedeelte van het deelvenster 'Subject Areas' links naar 'Selected Columns'. Neem onder meer de aanmaakdatum, indieningsdatum, goedkeuringsdatum en datum waarop de inkooporder is aangemaakt op.
Voeg de aanvraagactiegeschiedenis toe: Neem velden uit de map 'Requisition Action History' in het onderwerpgebied op om goedkeuringsstappen zoals goedgekeurd, afgewezen, teruggestuurd en ingetrokken vast te leggen. Sleep 'Action Date', 'Action' en 'Performer' naar de geselecteerde kolommen.
Stel filters in: Ga naar het tabblad 'Prompts' om filters voor de 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 een periode in, bijvoorbeeld de afgelopen 6 maanden. Je kunt ook prompts toevoegen voor 'Business Unit' of 'Requester Name' om de data verder af te bakenen.
Voer het rapport uit en controleer de resultaten: 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 en meerdere datum- en statuskolommen.
Exporteer de ruwe data: Klik na controle van het voorbeeld op de link 'Export', meestal onderaan de resultatenpagina. Kies 'Data' > 'CSV File' als bestandsindeling. Hiermee download je de ruwe data uit de analyse.
Zet de data om naar een event log: De geëxporteerde CSV heeft 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 zet je de datumkolommen om naar één kolom 'EventTime' en maak je voor elk gebeurtenistype een bijbehorende kolom 'ActivityName', bijvoorbeeld 'Requisition Created' en 'Requisition Submitted'.
Rond de voorbereiding voor upload af: Controleer na de omzetting of het bestand de vereiste kolommen bevat: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate. Sla het event log op als CSV-bestand. Daarna kun je het uploaden naar ProcessMind.

Configuratie

Onderwerpgebied: Gebruik bij voorkeur 'Procurement - Requisitions Real Time'. Dit bevat de belangrijkste gegevens over aanvraagkoppen, regels, verdelingen en goedkeuringsgeschiedenis.
Datumbereik: Stel altijd een verplicht datumfilter in om de hoeveelheid data te beperken en de prestaties te verbeteren. Een filter op 'Requisition Header'.'Requisition Creation Date' voor de afgelopen 3 tot 6 maanden is een goed uitgangspunt.
Belangrijke filters: Overweeg filters op 'Requisition Header'.'Business Unit' en 'Requisition Header'.'Requisition Status'. Zo beperk je de extractie tot relevante bedrijfseenheden en kun je statussen uitsluiten die niet nodig zijn, zoals 'Canceled'.
Kolommen selecteren: Kies zorgvuldig welke kolommen je aan de analyse toevoegt. Te veel kolommen uit verschillende mappen (dimensies) kunnen de prestaties verslechteren. Neem alleen velden op die nodig zijn voor het event log.
Machtigingen: De gebruiker die de extractie uitvoert, moet de juiste rol hebben voor toegang tot de werkruimte Reports and Analytics en het onderwerpgebied 'Procurement - Requisitions Real Time'. Rollen zoals 'BI Author' of 'Procurement Analyst' hebben deze rechten doorgaans.

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

Meld je aan bij Oracle Fusion Financials met een gebruiker die de rol BI Author of vergelijkbare rechten heeft.
Open de werkruimte Reports and Analytics via het pictogram Navigator en selecteer Tools > Reports and Analytics.
Klik op de knop "Browse Catalog" om de catalogus van Business Intelligence Publisher te openen.
Klik in de BI Publisher-interface op "New" en selecteer "Data Model" in de vervolgkeuzelijst.
Geef het datamodel een naam en beschrijving. Klik op het pictogram "+" om een nieuwe Data Set toe te voegen en selecteer "SQL Query".
Geef de nieuwe Data Set een naam, bijvoorbeeld Requisition_Event_Log. Selecteer de juiste Data Source voor je Financials-data, bijvoorbeeld ApplicationDB_FSCM, en stel Type of SQL in op "Standard SQL".
Kopieer het volledige SQL-script uit het gedeelte "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 map in de catalogus, bijvoorbeeld Shared Folders/Custom.
Ga terug naar de catalogus om de data te exporteren. Klik op "New" en selecteer "Report". Koppel het nieuwe rapport aan het datamodel dat je zojuist hebt gemaakt.
Voer het rapport uit en vul de begin- en einddatum in. Zodra de resultaten worden weergegeven, gebruik je de functie "Export" om ze als CSV-bestand te downloaden.
Sla het uiteindelijke CSV-bestand op met UTF-8-codering en controleer of het de vereiste kolomkoppen bevat voor import in je process mining-tool.

Configuratie

Databron: De BI Publisher-databron, meestal ApplicationDB_FSCM of een vergelijkbare naam, moet zijn ingesteld met een gebruiker die leestoegang heeft tot alle tabellen in de query. Dit geldt ook voor tabellen uit Procurement (POR, PO), Human Capital Management (PER, HR) en Financials (FUN).
Filteren op datumbereik: De query gebruikt verplichte datumparameters (:p_start_date en :p_end_date) om te filteren op de aanmaakdatum van aanvragen. Bij een eerste extractie of in grote systemen is het belangrijk de data in beheersbare perioden op te halen, bijvoorbeeld telkens 3 tot 6 maanden, om time-outs te voorkomen.
Filteren op bedrijfseenheid: In een commentaarregel van de WHERE-clausule staat een filter op de naam van de bedrijfseenheid. Haal het commentaar weg en stel dit filter in om de data te beperken tot de bedrijfseenheden die relevant zijn voor je 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 moet deze gebruiker de juiste databeveiligingsrechten hebben voor toegang tot inkoopdata.

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 (gebruikersnaam en wachtwoord) nodig voor een Oracle Fusion-gebruiker met voldoende rechten om inkoopaanvragen te lezen, plus de basis-URL van je Oracle Fusion-omgeving.
Sla het Python-script op: Sla de volledige Python-code uit het gedeelte 'query' op als bestand, bijvoorbeeld extract_requisitions.py.
Stel de scriptparameters in: Open het scriptbestand in een teksteditor en pas de tijdelijke waarden bovenaan aan. Vul FUSION_URL, USERNAME en PASSWORD in voor je Oracle Fusion-omgeving. Pas START_DATE en END_DATE aan om de extractieperiode in te stellen.
Bekijk de API-eindpunten en velden: Het script gebruikt de REST API-bron purchaseRequisitions. Met de parameter fields vraagt het alleen de benodigde data op, waaronder geneste verzamelingen zoals lines (voor inkoopordergegevens) 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 data op en toont in de console hoeveel aanvragen zijn verwerkt.
Paginering afhandelen: Het script handelt paginering automatisch af. De Oracle Fusion REST API levert data in delen (pagina’s). Het script controleert de vlag hasMore in elk antwoord en verstuurt herhaaldelijk verzoeken met een bijgewerkte parameter offset totdat alle aanvragen binnen het opgegeven datumbereik zijn opgehaald.
Data omzetten: 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 en een gebeurtenis 'Requisition Submitted' op basis van SubmittedDate. Ook doorloopt het de verzameling actionHistory om voor elke goedkeuringsstap een gebeurtenis te maken: gestart, goedgekeurd, afgewezen of teruggestuurd.
Gebeurtenissen voor de eindstatus afleiden: Het script legt de uiteindelijke gebeurtenissen, zoals 'Requisition Approved' en 'Requisition Rejected', vast door de eindwaarde van DocumentStatus te controleren. LastUpdateDate wordt gebruikt als timestamp van de gebeurtenis.
Gebeurtenis voor inkooporder maken: Het script controleert elke aanvraagregel. Als een regel een PoHeaderId bevat, betekent dit dat er een inkooporder is aangemaakt. Het script voegt hiervoor een gebeurtenis toe aan het event log 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.
Maak het bestand klaar voor upload: Open de gegenereerde CSV in een spreadsheetprogramma en controleer de inhoud. 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 je Oracle Fusion-omgeving.
Filter op datumbereik: Het script bevat de variabelen START_DATE en END_DATE. Haal de data bij voorkeur op in beheersbare perioden, bijvoorbeeld telkens 3 tot 6 maanden, om time-outs en prestatieproblemen met de API te voorkomen. Het filter wordt toegepast op CreationDate van de aanvragen.
Velden selecteren: De parameter fields is belangrijk voor de prestaties. Hiermee beperk je het antwoord tot de attributen die nodig zijn voor het event log, waardoor er minder data over het netwerk gaat en minder verwerking nodig is. Verwijder geen verplichte velden zoals RequisitionId, CreationDate, actionHistory of lines.
Limiet voor paginering: De parameter limit staat op 100, een veilige waarde voor de meeste omgevingen. Je kunt deze verhogen naar 200 of 500 om de extractie mogelijk te versnellen. Houd er wel rekening mee dat een hoge waarde geheugenproblemen of API-limieten kan veroorzaken.

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 benodigde inkoopgegevens uit Oracle Fusion Financials en toegang tot de relevante Public View Objects beschikbaar zijn in je omgeving. Controleer ook of de BICC-gebruiker of het integratieaccount toestemming heeft om aanvragen, goedkeuringsgeschiedenis en inkooporderdata te extraheren. Exacte rolnamen en menulabels verschillen per Oracle-release. Gebruik daarom de bijbehorende BICC-beheeromgeving in je tenant.
Bepaal welke PVO’s nodig zijn voor de extractie en schakel deze in. Gebruik RequisitionHeaderPVO, of het bijbehorende PVO voor aanvraagkoppen in je omgeving, samen met de PVO’s voor aanvraagregels, aanvraagstatusgeschiedenis, goedkeuringsworkflowgeschiedenis en verwijzingen naar inkooporders. Ga er niet van uit dat één PVO de workflowgeschiedenis of de aanmaakgeschiedenis van inkooporders bevat. Noteer de exacte PVO-namen en beschikbare attributen in je tenant.
Stel een BICC-taak in voor een incrementele of historische bulkextractie. Stel de extractieperiode in met [Start date parameter] en [End date parameter] en laat de taak CSV-bestanden opslaan op de goedgekeurde cloudopslaglocatie. Gebruik voor de eerste extractie een voldoende ruime historische periode. Gebruik bij terugkerende extracties overlappende perioden om late updates mee te nemen. Verwijder daarna dubbele gebeurtenissen op basis van de case-ID, activiteit, timestamp van de gebeurtenis en, indien beschikbaar, de brongebeurtenis-ID.
Stel de extractiekolommen in. Neem de aanvraag-ID, ID’s van aanvraagkop en -regel, aanvrager, afdeling, bedrag, status, gewenste datum, bedrijfseenheid, reden van afwijzing, aanmaak- en updatetimestamps, timestamps van statuswijzigingen, toewijzings- en actietimestamps voor goedkeuringen, goedkeuringsactie, verwijzing naar de inkooporder en de BICC-ververstimestamp op. Gebruik de exacte attribuutnamen van de geselecteerde PVO’s. Is een attribuut niet beschikbaar, koppel het dan aan [Configure based on your system] en leg de beperking vast. Vervang het niet door een veld waarvan de betekenis niet is gecontroleerd.
Extraheer de bronbestanden als CSV en bewaar de originele bestanden. Laad elk bestand in een stagingomgeving en bewaar de naam van het bron-PVO en de bestandsnaam. Zet timestamps om naar één afgesproken tijdzone en verwerk Oracle-datum- en timestampwaarden op dezelfde manier. Behandel ID’s als tekst, zodat voorloopnullen en precisie behouden blijven.
Zet de brondata om naar een gebeurtenissentabel met één rij per expliciete bedrijfsgebeurtenis. De uitvoer moet de kolommen PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate bevatten. Voeg waar mogelijk de aanbevolen attributen toe. Vertrouw er niet op dat ProcessMind gebeurtenissen afleidt uit status- of veldwijzigingen. Maak bij de omzetting expliciet rijen aan voor alle twaalf activiteiten uit de query.
Maak gebeurtenisrijen op basis van de juiste brongegevens. 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 een nieuwe versie voor Requisition Amended, een 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 overgang van de algemene status voor Requisition Approved, Requisition Rejected en Requisition Closed. Gebruik voor Purchase Order Created een expliciet record of timestamp van de aanmaak van de inkooporder die aan de aanvraag is gekoppeld.
Verwijder dubbele gebeurtenissen op een vaste, reproduceerbare manier. Als meerdere bronrijen dezelfde gebeurtenis weergeven, behoud dan één rij met de meest specifieke timestamp en, indien beschikbaar, een stabiele bron-ID. Voeg afzonderlijke goedkeuringsstappen niet samen omdat ze dezelfde aanvraag-ID hebben. Bewaar aparte goedkeuringsgebeurtenissen voor verschillende goedkeurders of workflowstappen.
Controleer het resulterende event log. Controleer of alle vereiste activiteiten erin staan, elke gebeurtenis een case-ID en timestamp heeft, timestamps binnen de extractieperiode vallen of verklaard worden door later binnengekomen updates, en aanbevolen attributen zijn ingevuld wanneer de bron ze bevat. Vergelijk het aantal aanvragen en de koppelingen met inkooporders met de bronbestanden.
Exporteer het uiteindelijke 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 stel PurchaseRequisitionId in als case-ID, ActivityName als activiteit en EventTime als timestamp van de gebeurtenis.

Configuratie

Extractiemethode: bulkdata-extractie met Oracle BI Cloud Connector, opgeslagen als CSV-bestanden op de ingestelde cloudopslaglocatie.
Bronobjecten: gebruik RequisitionHeaderPVO en de beschikbare PVO’s voor aanvraagregels, statusgeschiedenis, goedkeuringsworkflowgeschiedenis en verwijzingen naar inkooporders in de tenant. Controleer de exacte PVO-namen en attributen in de omgeving.
Verplichte uitvoerkolommen: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate.
Aanbevolen uitvoerkolommen: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason en BusinessUnit.
Datumbereik: gebruik voor reguliere analyses een periode van drie tot zes maanden. Gebruik voor een eerste historische extractie zo nodig een ruimere periode. Gebruik bij terugkerende extracties overlappende perioden om late updates mee te nemen en verwijder daarna dubbele gebeurtenissen.
Filters: pas [Company-specific filter], [Document Type filter], [Business Unit filter] en [Date range filter] alleen toe als deze attributen beschikbaar zijn in de geselecteerde PVO’s. Controleer of het filter geldt voor de aanmaakdatum, updatedatum, datum van de statusovergang of een andere brondatum.
Incrementele extractie: gebruik bij voorkeur een updatetimestamp of een ondersteunde incrementele extractiemethode van BICC. Bewaar het tijdstip van de laatste geslaagde extractie en neem een kleine overlap mee in de volgende run.
Volledigheid van gebeurtenissen: stel aparte bronextracties in als de aanvraagkoppen geen goedkeuringsgeschiedenis, statusovergangen, wijzigingen of aanmaak van inkooporders bevatten. Met alleen een extractie van de huidige status van aanvraagkoppen kun je historische gebeurtenissen niet betrouwbaar reconstrueren.
Prestaties: beperk het datumbereik en het aantal geselecteerde kolommen, verdeel grote extracties waar dat kan, laat onnodige beschrijvende attributen weg en verwerk CSV-bestanden in batches. Bewaar de bronbestanden om resultaten te kunnen controleren.
Opslag: stel een goedgekeurde cloudopslaglocatie in met voldoende capaciteit, bewaartermijn, versleuteling en toegangsbeheer. Controleer of het extractieaccount bestanden kan opslaan en het omzettingsproces ze kan lezen.
Vereisten: BICC moet beschikbaar zijn. Je hebt toegang nodig tot de relevante inkoop- en goedkeuringsdata in Oracle Fusion, de juiste integratierechten en toegang tot de geselecteerde PVO’s. Mogelijk is ook een Oracle-abonnement of functierecht nodig. De exacte rolnamen, licenties en menupaden hangen af van de Oracle-release en de tenantconfiguratie.
Tijdzones: zet alle brontimestamps om naar een gedocumenteerde tijdzone. Bewaar de oorspronkelijke timestamp als dat nodig is voor controle achteraf.
Cases: gebruik PurchaseRequisitionId als case-ID. Gebruik geen ID van een aanvraagregel als case-ID, tenzij je het proces bewust op regelniveau modelleert.

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 het proces van inkoopaanvraag tot betaling te optimaliseren en efficiënter te maken. Zo zet je een eerste stap naar een betere inkoop.

Terug naar de verbetergids

Template downloaden

Verwerk inkoopaanvragen tot betaling 30% sneller

Maak het Oracle P2P-aanvraagproces efficiënter en verkort de doorlooptijd met 30%.

Start je gratis proefperiode

Geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.

Datatemplate voor inkoopaanvragen tot betaling

Datatemplate voor inkoopaanvragen tot betaling

Attributen voor inkoopaanvragen tot betaling

Activiteiten voor inkoopaanvragen tot betaling

Extractiegidsen

Export uit Oracle Transactional Business Intelligence (OTBI)

Stappen

Configuratie

Voorbeeldquery sql

Data-extractie met een SQL-datamodel in Oracle BI Publisher

Stappen

Configuratie

Voorbeeldquery sql

Python-script via de Oracle Fusion REST API

Stappen

Configuratie

Voorbeeldquery python

Bulkdata-extractie met Oracle BI Cloud Connector (BICC)

Stappen

Configuratie

Voorbeeldquery sql

Klaar om aan de slag te gaan?

Verwerk inkoopaanvragen tot betaling 30% sneller