> Continue procesverbetering > Purchase to Pay Requisition > Coupa > Datatemplate

Jouw datatemplate voor Purchase to Pay - Requisition

Coupa

Purchase to Pay - Requisition-attributen (21) Purchase to Pay - Requisition-activiteiten (12) Extractiegidsen (3)

Jouw datatemplate voor Purchase to Pay - Requisition

Deze datatemplate biedt een vaste aanpak voor het verzamelen van de informatie die je nodig hebt om je Purchase to Pay - Requisition-proces te analyseren. Je ziet welke attributen en activiteiten nodig zijn voor een bruikbaar event log. Ook vind je uitleg over hoe je deze data uit Coupa haalt.

Aanbevolen attributen voor een volledige analyse
Belangrijkste procesactiviteiten om te volgen
Praktische uitleg voor data-extractie

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, zodat je het Purchase to Pay - Requisition-proces volledig kunt analyseren.

5 Verplicht 5 Aanbevolen 11 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsactiviteit of het event dat op een bepaald moment voor de aanvraag plaatsvond.
Beschrijving Dit attribuut legt de afzonderlijke stappen in de levenscyclus van een inkoopaanvraag vast. Voorbeelden zijn ‘Aanvraag aangemaakt’, ‘Goedkeuringsstap goedgekeurd’ en ‘Aanvraag naar sourcing gestuurd’. Elke activiteit staat voor een specifiek mijlpaal of een specifieke actie voor de aanvraag. Het analyseren van de volgorde en frequentie van deze activiteiten vormt de basis van process mining. Zo kun je procesmaps visualiseren, veelvoorkomende routes herkennen en afwijkingen van de standaardprocedure opsporen. Waarom dit belangrijk is Het definieert de stappen in de procesmap, zodat je de stroom van aanvragen kunt visualiseren en analyseren. Waar je het vindt Dit wordt meestal afgeleid uit event logs, statuswijzigingen of audittrails in het Coupa-systeem. Mogelijk moet je statusvelden of actiecodes mappen. Voorbeelden Aanvraag aangemaaktAanvraag ingediendGoedkeuringsstap goedgekeurdAanvraag afgewezenInkooporder aangemaakt
	Eventtijd EventTime	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving Eventtijd, of de timestamp, legt het exacte moment vast waarop een activiteit voor een inkoopaanvraag is geregistreerd. Deze data is nodig om events chronologisch te ordenen en de processtroom op te bouwen. Alle tijdanalyses zijn hierop gebaseerd, zoals het berekenen van doorlooptijden, het vinden van bottlenecks door de tijd tussen activiteiten te meten en het analyseren van procesprestaties over verschillende perioden. Nauwkeurige timestamps op detailniveau zijn nodig voor een zinvolle procesanalyse. Waarom dit belangrijk is Deze timestamp is belangrijk om events correct te ordenen en alle tijdsgebonden metrieken te berekenen, zoals doorlooptijden en bottlenecks. Waar je het vindt Deze informatie staat in het audittrail of de historie van elke aanvraag in Coupa, vaak in een veld als ‘created_at’ of ‘updated_at’ voor elke actie. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	ID van inkoopaanvraag PurchaseRequisitionId	De unieke identificatie voor elke inkoopaanvraag. Deze dient als primaire case-ID voor het proces.
Beschrijving De ID van de inkoopaanvraag is de centrale sleutel die alle activiteiten rond één aanvraag voor goederen of diensten koppelt. Elke aanvraag krijgt bij het aanmaken een unieke ID die gedurende de hele levenscyclus gelijk blijft. Zo kun je de aanvraag van begin tot eind volgen, vanaf het aanmaken en indienen via alle goedkeurings- of afwijzingsstappen tot de uiteindelijke sourcing en sluiting. In process mining is elke regel in het event log aan deze ID gekoppeld. Daarmee kun je het volledige verloop van elke case reconstrueren. Waarom dit belangrijk is Dit is de essentiële Case ID die alle processtappen koppelt. Zo kun je de volledige levenscyclus van de aanvraag van begin tot eind analyseren. Waar je het vindt Dit is een primair sleutelveld in de Requisitions-module van Coupa en in gerelateerde data-extracties. Voorbeelden PR-102934PR-102935PR-102936
	Bronsysteem SourceSystem	Identificeert het bronsysteem waaruit de data is geëxtraheerd.
Beschrijving Dit attribuut geeft aan in welk systeem de procesdata oorspronkelijk is vastgelegd. Voor deze analyse is de waarde steeds ‘Coupa’. Dit veld opnemen is een goede werkwijze, vooral wanneer data uit meerdere systemen wordt samengevoegd. Het geeft context over de herkomst van de data en helpt bij het beheren van datagovernance- en kwaliteitsregels. Waarom dit belangrijk is Geeft een duidelijk overzicht van de herkomst van de data. Dat is belangrijk voor datagovernance en voor het combineren van data uit meerdere bedrijfssystemen. Waar je het vindt Dit is meestal een statische waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Coupa
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor het laatst vanuit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut legt de datum en tijd van de meest recente data-extractie uit Coupa vast. Zo zie je hoe actueel de geanalyseerde data is. Als je weet hoe recent de data is, kun je beter beoordelen of de inzichten de huidige bedrijfsvoering of een eerder moment weerspiegelen. Dit is vooral belangrijk voor dashboards die lopende processen monitoren. Waarom dit belangrijk is Laat zien hoe actueel de data is. Zo weten gebruikers op welke periode de analyse betrekking heeft en kunnen ze beslissingen nemen op basis van recente informatie. Waar je het vindt Deze timestamp wordt door de datapijplijn of ETL-tool gegenereerd en toegevoegd na een succesvolle data-extractie. Voorbeelden 2024-05-21T02:00:00Z
	Aanvrager Requester	De medewerker die de inkoopaanvraag heeft aangemaakt en ingediend.
Beschrijving Dit attribuut identificeert de persoon die de aanvraag heeft gestart. Door data per aanvrager te analyseren, kun je patronen bij specifieke gebruikers herkennen, zoals veel aanpassingen of frequente afwijzingen. Dat kan wijzen op behoefte aan extra training. Je gebruikt dit attribuut ook om aanvraagvolumes en procesgedrag van verschillende gebruikers of gebruikersgroepen te analyseren. Waarom dit belangrijk is Maakt analyse van procesgedrag per gebruiker mogelijk. Zo kun je trainingsbehoeften herkennen en begrijpen hoe verschillende personen met het proces omgaan. Waar je het vindt Beschikbaar als standaardveld op het Requisition-object in Coupa, vaak gekoppeld aan het User-object en met de naam ‘requester’ of ‘created_by’. Voorbeelden Alice JohnsonBob SmithCharlie Brown
	Afdeling Department	De bedrijfsafdeling of kostenplaats waaraan de aanvraag wordt toegerekend.
Beschrijving Het attribuut Afdeling koppelt elke aanvraag aan een specifieke organisatie-eenheid of kostenplaats. Dit is een belangrijke dimensie voor vergelijkende analyses. Je kunt dashboards en KPI’s per afdeling filteren en uitsplitsen. Zo kunnen managers doorlooptijden van goedkeuringen, afwijzingspercentages en compliance tussen organisatieonderdelen vergelijken. Dit helpt om problemen of goede werkwijzen per afdeling te vinden. Waarom dit belangrijk is Maakt het mogelijk om proces-KPI’s, zoals doorlooptijd en afwijzingspercentages, tussen verschillende bedrijfsonderdelen te vergelijken en verbeterpunten te vinden. Waar je het vindt Dit is een standaardveld op het Requisition-object in Coupa. Het is vaak gekoppeld aan het gebruikersprofiel van de aanvrager of wordt op de regelitems van de aanvraag vastgelegd. Voorbeelden MarketingIT-bedrijfsvoeringFacilitair beheerOnderzoek en ontwikkeling
	Goedkeurder Approver	De gebruiker of groep die verantwoordelijk is voor een goedkeuringsactiviteit.
Beschrijving Dit attribuut identificeert de persoon of goedkeuringsgroep die aan een goedkeuringsstap is toegewezen. Het wordt ingevuld voor activiteiten zoals ‘Goedkeuringsstap gestart’, ‘Goedkeuringsstap goedgekeurd’ en ‘Goedkeuringsstap afgewezen’. Door data per goedkeurder te analyseren, kun je het dashboard ‘Prestaties en werklast van goedkeurders’ opbouwen. Je meet hiermee individuele goedkeuringstijden, vindt bottlenecks door specifieke goedkeurders en beoordeelt de verdeling van de werklast. Waarom dit belangrijk is Belangrijk voor het analyseren van prestaties van goedkeurders, het verdelen van de werklast en het vinden van bottlenecks bij specifieke personen of goedkeuringsgroepen. Waar je het vindt Deze informatie staat in de details van de goedkeuringsketen die aan elke aanvraag in Coupa zijn gekoppeld. Mogelijk moet je hiervoor data met User-data combineren. Voorbeelden David MillerFinanciële goedkeurders niveau 2Susan Chen
	Status van aanvraag RequisitionStatus	De huidige of definitieve status van de inkoopaanvraag.
Beschrijving Dit attribuut geeft de algemene status van de aanvraag aan op het moment van de data-extractie of de uiteindelijke uitkomst. Veelvoorkomende statussen zijn ‘Pending Approval’, ‘Approved’, ‘Rejected’, ‘Withdrawn’ en ‘Closed’. Dit is een belangrijke dimensie voor filtering en analyse. Je gebruikt deze om goedkeurings- en afwijzingspercentages te berekenen, de huidige werklast van openstaande aanvragen te monitoren en de uiteindelijke uitkomst van aanvragen te begrijpen. Waarom dit belangrijk is Belangrijk om de uitkomsten van aanvragen te begrijpen, goedkeurings- en afwijzingspercentages te berekenen en de huidige status van lopende aanvragen te monitoren. Waar je het vindt Dit is een standaardveld op het Purchase Requisition-object in Coupa, vaak met de naam ‘status’ of ‘state’. Voorbeelden Wacht op goedkeuringGoedgekeurdAfgewezenIngetrokkenGesloten
	Totaalbedrag TotalAmount	De totale geldwaarde van de inkoopaanvraag.
Beschrijving Dit attribuut staat voor de totale kosten van alle goederen en diensten in de aanvraag. Het bedrag heeft vaak invloed op de complexiteit van de goedkeuringsworkflow. Aanvragen met een hogere waarde hebben meestal meer goedkeuringsstappen nodig. Door procesmetrieken per waardeklasse te analyseren, bijvoorbeeld < € 1.000 en € 1.000-€ 10.000, zie je hoe het proces omgaat met aanvragen van verschillende financiële omvang. Waarom dit belangrijk is Helpt analyseren hoe het proces verschilt voor aanvragen met verschillende waarden. Hogere bedragen leiden vaak tot complexere goedkeuringsworkflows. Waar je het vindt Dit is een standaardveld in de header van het Requisition-object in Coupa, meestal met de naam ‘total’ of ‘total_amount’. Voorbeelden 500.0012550.7599.99
	Aangepast IsAmended	Een boolean-vlag die true is als de aanvraag na de eerste indiening één of meerdere keren is aangepast.
Beschrijving Dit berekende attribuut is een eenvoudige vlag (True/False) die aangeeft of de activiteit ‘Aanvraag aangepast’ voor een bepaalde case heeft plaatsgevonden. Zo kun je aanvragen waarvoor wijzigingen nodig waren eenvoudig filteren en analyseren. Je gebruikt dit om de KPI voor het wijzigingspercentage van aanvragen te berekenen en het dashboard ‘Aantal aangepaste aanvragen’ te vullen. Daarmee vind je oorzaken van herstelwerk en verbeter je de kwaliteit in één keer goed. Waarom dit belangrijk is Vereenvoudigt de berekening van de KPI voor het wijzigingspercentage en maakt het eenvoudig om cases met en zonder herstelwerk van elkaar te onderscheiden. Waar je het vindt Dit wordt in de process mining-tool berekend door voor elke case te controleren of de activiteit ‘Aanvraag aangepast’ in het event log voorkomt. Voorbeelden truefalse
	Aantal goedkeuringsstappen ApprovalStepCount	Het totale aantal goedkeuringsstappen dat een aanvraag heeft doorlopen.
Beschrijving Dit berekende attribuut telt het aantal afzonderlijke activiteiten ‘Goedkeuringsstap goedgekeurd’ per aanvraag. Zo meet je de complexiteit van de goedkeuringsworkflow per case. Dit vormt de basis voor de KPI ‘Gemiddeld aantal goedkeuringsstappen’ en helpt aanvragen te vinden met ongewoon lange of complexe goedkeuringsroutes. Dat kan wijzen op een workflow die eenvoudiger kan. Waarom dit belangrijk is Maakt de complexiteit van de goedkeuringsworkflow per aanvraag meetbaar en helpt te lange of complexe routes te vinden die vereenvoudigd moeten worden. Waar je het vindt Deze metriek wordt in de process mining-tool berekend door het aantal keer dat ‘Goedkeuringsstap goedgekeurd’ voorkomt per Case ID te tellen. Voorbeelden 253
	Duur van goedkeuringsstap ApprovalStepDuration	De tijd die een aanvraag bij één goedkeuringsstap heeft gewacht.
Beschrijving Deze berekende metriek meet de tijd tussen de activiteit ‘Goedkeuringsstap gestart’ en de bijbehorende activiteit ‘Goedkeuringsstap goedgekeurd’ of ‘Goedkeuringsstap afgewezen’. Zo zie je de wachttijd bij elke afzonderlijke fase van de goedkeuringsketen. Dit is nodig voor het dashboard ‘Kritieke bottlenecks in goedkeuringsstappen’, omdat je precies ziet welke goedkeurders of fasen de grootste vertraging veroorzaken. Waarom dit belangrijk is Brengt specifieke bottlenecks in de goedkeuringsworkflow aan het licht door de wachttijd per stap te meten, in plaats van alleen de totale doorlooptijd. Waar je het vindt Berekend in de process mining-tool door het tijdsverschil te bepalen tussen ‘Goedkeuringsstap gestart’ en het daaropvolgende afsluitende goedkeurings-event (Approved/Rejected). Voorbeelden 1,2 dagen4 uur3,8 dagen
	Goederencategorie Commodity	De hoofdcategorie van de aangevraagde goederen of diensten.
Beschrijving Het attribuut Goederencategorie geeft de items op een aanvraag een gestandaardiseerde classificatie, zoals ‘Kantoorbenodigdheden’, ‘Computerhardware’ of ‘Marketingdiensten’. Zo kun je inkooppatronen en procesverschillen analyseren op basis van wat er wordt gekocht. Voor bepaalde goederencategorieën gelden specifieke goedkeuringsvereisten of sourcingstrategieën. Door het proces per goederencategorie te analyseren, kun je de inkoop voor verschillende uitgavencategorieën verbeteren. Waarom dit belangrijk is Helpt uitgavencategorieën te analyseren en te begrijpen of procesgedrag, zoals goedkeuringstijden, verschilt per type ingekochte goederen of diensten. Waar je het vindt Dit is een standaardveld in Coupa, meestal beschikbaar op het niveau van het regelitem van de aanvraag. Mogelijk moet je het aggregeren naar het niveau van de header. Voorbeelden KantoorbenodigdhedenComputerhardwareMarketingdienstenReizen
	ID van inkooporder PurchaseOrderId	De identificatie van de inkooporder die op basis van de goedgekeurde aanvraag is aangemaakt.
Beschrijving Nadat een aanvraag volledig is goedgekeurd en naar sourcing is gestuurd, wordt meestal een inkooporder aangemaakt. Dit attribuut bevat de ID van die PO. Het vormt een belangrijke koppeling tussen het upstream-proces van de aanvraag en het downstream-proces van de inkooporder. Hiermee kun je de KPI ‘Tijd van goedkeuring van aanvraag tot aanmaken van PO’ berekenen en de volledige Purchase-to-Pay-cyclus van begin tot eind analyseren. Waarom dit belangrijk is Koppelt de aanvraag aan de daaropvolgende inkooporder. Zo kun je de overdrachtstijd analyseren en een breder end-to-end-overzicht van P2P maken. Waar je het vindt Dit is een standaardveld op het Requisition-object in Coupa dat wordt ingevuld nadat de PO is aangemaakt. Voorbeelden PO-45000123PO-45000124PO-45000125
	Naam van leverancier SupplierName	De naam van de leverancier die voor de aanvraag is geselecteerd.
Beschrijving Dit attribuut identificeert de beoogde leverancier van de aangevraagde goederen of diensten. De aanvrager kan de leverancier opgeven of deze wordt later tijdens het sourcingproces toegevoegd. Door procesmetrieken per leverancier te analyseren, kun je leveranciersprestaties beoordelen en zien of interacties met bepaalde leveranciers leiden tot langere doorlooptijden of andere inefficiënties. Dit geeft belangrijke context voor de inkoopstrategie en het leveranciersbeheer. Waarom dit belangrijk is Maakt het mogelijk om procesprestaties per geselecteerde leverancier te analyseren. De uitkomsten kunnen helpen bij sourcingstrategieën en leveranciersbeheer. Waar je het vindt Deze informatie is beschikbaar op het Requisition Line-object in Coupa, vaak in een veld met de naam ‘supplier’ of ‘vendor’. Voorbeelden StaplesDell TechnologiesAccentureCDW
	Pad van goedkeuringsworkflow ApprovalWorkflowPath	Een identificatie voor de specifieke goedkeuringsketen of workflowtemplate die op de aanvraag is toegepast.
Beschrijving Dit attribuut identificeert de vooraf bepaalde volgorde van goedkeurders die een aanvraag hoort te volgen. De volgorde wordt bepaald door bedrijfsregels, vaak op basis van factoren zoals bedrag, afdeling en type aanvraag. Dit attribuut vormt de basis voor het dashboard ‘Compliance van aanvraagbeleid’. Door de werkelijke volgorde van goedkeurders te vergelijken met het toegewezen workflowpad, kun je afwijkingen detecteren, nalevingspercentages meten en uitzonderingen zonder beheer vinden. Waarom dit belangrijk is Maakt compliance-analyse mogelijk door de verwachte en werkelijke goedkeuringsstappen met elkaar te vergelijken en procesafwijkingen zichtbaar te maken. Waar je het vindt Raadpleeg de Coupa-documentatie. Dit kan worden afgeleid uit de naam van de goedkeuringsketen of workflowregel die voor de aanvraag is geactiveerd. Voorbeelden Standaardgoedkeuring <$5kGoedkeuring IT-hardware >$10kBeoordeling kapitaalinvestering door CFO
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft wanneer een aanvraag of goedkeuringsstap wordt afgewezen.
Beschrijving Wanneer een goedkeurder een aanvraag afwijst, geeft die vaak een reden voor de beslissing. Dit attribuut legt die tekstuele toelichting vast. Door afwijzingsredenen te analyseren, krijg je rechtstreeks inzicht in waarom aanvragen mislukken. Dat helpt bij het vinden van de onderliggende oorzaken, zoals onjuiste codering, een ontoereikend budget of onvoldoende onderbouwing. Vervolgens kun je deze problemen aanpakken met training of procesverbeteringen. Waarom dit belangrijk is Geeft rechtstreeks inzicht in de oorzaken van procesproblemen en helpt om behoeften aan gebruikerstraining of verduidelijking van het proces te vinden. Waar je het vindt Deze informatie staat meestal in het opmerkingen- of notitieveld bij een statuswijziging naar ‘Rejected’ in de goedkeuringsgeschiedenis van de aanvraag. Voorbeelden Onjuiste kostenplaatsBudget voor dit kwartaal overschredenDubbel verzoekOnvoldoende onderbouwing
	Type aanvraag RequisitionType	De categorie of het type van de aanvraag, zoals ‘Capital Expense’, ‘Operational Expense’ of ‘Software’.
Beschrijving Het type aanvraag is een classificatie waarmee je aanvragen indeelt op basis van hun bedrijfsdoel of de aard van de aankoop. Dit attribuut is nuttig voor compliance-analyses en om te begrijpen hoe verschillende soorten aanvragen door het proces lopen. Aanvragen voor kapitaaluitgaven kunnen bijvoorbeeld een strengere en langere goedkeuringsroute volgen dan standaardaanvragen. Door het proces per type aanvraag te analyseren, vind je mogelijkheden voor procesoptimalisatie. Waarom dit belangrijk is Maakt het mogelijk om analyses uit te splitsen naar het bedrijfsdoel van de aanvraag. Verschillende typen kunnen namelijk hun eigen procesroutes en beleidsregels hebben. Waar je het vindt Dit is waarschijnlijk een aangepast of standaardclassificatieveld op het Requisition-object in Coupa. Voorbeelden KapitaalinvesteringBedrijfskostenIT-hardwareProfessionele diensten
	Urgentieniveau UrgencyLevel	Een classificatie die de urgentie van de aanvraag aangeeft, zoals ‘High’, ‘Medium’ of ‘Low’.
Beschrijving Met het Urgentieniveau, dat vaak aan een prioriteitsveld is gekoppeld, kunnen aanvragers aangeven dat een aanvraag versneld moet worden verwerkt. Dit attribuut is nodig voor het dashboard ‘Verwerkingstijd van urgente aanvragen’. Door de doorlooptijden van aanvragen met hoge urgentie te vergelijken met standaardaanvragen, kun je beoordelen of prioritering werkt en urgente bedrijfsbehoeften op tijd worden afgehandeld. Waarom dit belangrijk is Maakt het mogelijk om te analyseren of urgente aanvragen sneller worden verwerkt dan standaardaanvragen. Zo kun je beoordelen of het prioriteringsbeleid werkt. Waar je het vindt Dit kan een standaard- of aangepast veld op het Requisition-object in Coupa zijn. Raadpleeg de Coupa-documentatie of de systeemconfiguratie. Voorbeelden HoogGemiddeldLaag
	Valuta Currency	De valutacode voor het totale bedrag van de aanvraag.
Beschrijving Dit attribuut geeft aan in welke valuta, bijvoorbeeld USD, EUR of GBP, het Totaalbedrag van de aanvraag is uitgedrukt. Deze context is nodig voor financiële analyses, vooral bij multinationale organisaties die met meerdere valuta werken. Zo worden geldbedragen correct geïnterpreteerd en kun je ze goed omrekenen en samenvoegen in financiële rapportages en dashboards. Waarom dit belangrijk is Geeft de benodigde context bij het attribuut ‘Totaalbedrag’, zodat financiële analyses in omgevingen met meerdere valuta correct zijn. Waar je het vindt Dit is een standaardveld op het Requisition-object in Coupa, meestal met de naam ‘currency_code’ of iets vergelijkbaars. Voorbeelden USDEURGBP

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 ontdekking van je Purchase to Pay - Requisition-workflow.

6 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Aanvraag aangemaakt	Een gebruiker start een nieuwe inkoopaanvraag en slaat deze op als concept. Dit is het begin van elke aanvraagcase en wordt meestal afgeleid uit de aanmaaktimestamp van het aanvraagrecord zelf.
Waarom dit belangrijk is Deze activiteit markeert het begin van de levenscyclus van de aanvraag. Door de tijd tussen aanmaken en indienen te analyseren, kun je vertragingen door onzekerheid bij gebruikers of complexiteit van het systeem herkennen. Waar je het vindt Deze gebeurtenis wordt vastgelegd via de timestamp 'created-at' in de tabel 'requisition_headers' voor een bepaald Purchase Requisition ID. Vastleggen Gebruik de aanmaaktimestamp van het aanvraagrecord in de header. Eventtype inferred
	Aanvraag afgewezen	De aanvraag wordt definitief afgewezen tijdens het goedkeuringsproces en wordt niet omgezet in een inkooporder. Dit wordt afgeleid uit de wijziging van de algemene status van de aanvraagheader naar ‘rejected’.
Waarom dit belangrijk is Deze activiteit staat voor een definitieve mislukking in het proces. Door deze events te analyseren, kun je het ‘Afwijzingspercentage van aanvragen’ verbeteren en oorzaken zoals beleidsafwijkingen of budgetproblemen opsporen. Waar je het vindt Afgeleid uit een statuswijziging in de tabel ‘requisition_headers’ wanneer het veld ‘status’ wordt bijgewerkt naar ‘rejected’. De timestamp staat in het bijbehorende audittrail. Vastleggen Bepaal de timestamp waarop de algemene status van de aanvraag verandert in ‘rejected’. Eventtype inferred
	Aanvraag gesloten	De aanvraag wordt formeel gesloten. Er worden geen verdere acties meer uitgevoerd. Dit kan gebeuren nadat een PO is aangemaakt en afgehandeld, of wanneer de aanvraag na goedkeuring maar vóór het bestellen wordt geannuleerd.
Waarom dit belangrijk is Deze activiteit vormt het definitieve eindpunt van de levenscyclus van de aanvraag. Zo krijgen cases een duidelijk einde en blijven ze niet onbeperkt als ‘actief’ zichtbaar in procesanalyses. Waar je het vindt Afgeleid uit een statuswijziging in de tabel ‘requisition_headers’ wanneer het veld ‘status’ wordt bijgewerkt naar ‘closed’. De timestamp staat in het bijbehorende audittrail. Vastleggen Bepaal de timestamp waarop de algemene status van de aanvraag verandert in ‘closed’. Eventtype inferred
	Aanvraag goedgekeurd	De aanvraag heeft alle vereiste stappen in de goedkeuringsworkflow succesvol doorlopen. Dit wordt afgeleid uit de wijziging van de algemene status van de aanvraagheader naar ‘approved’.
Waarom dit belangrijk is Dit is een belangrijk succesmoment en markeert het einde van de goedkeuringscyclus. De tijd tot deze activiteit is een belangrijke KPI en vormt de trigger voor vervolgstappen in de inkoop. Waar je het vindt Afgeleid uit een statuswijziging in de tabel ‘requisition_headers’ wanneer het veld ‘status’ wordt bijgewerkt naar ‘approved’. De timestamp staat in het bijbehorende audittrail. Vastleggen Bepaal de timestamp waarop de algemene status van de aanvraag verandert in ‘approved’. Eventtype inferred
	Aanvraag ingediend	De aanvrager dient de ingevulde aanvraag formeel in voor de goedkeuringsworkflow. Je leidt deze gebeurtenis af uit een statuswijziging van 'draft' naar 'pending_approval' in de auditlogs of historietabellen van het systeem.
Waarom dit belangrijk is De indiening start het goedkeuringsproces en is daarom een belangrijk meetpunt voor de KPI 'Average Requisition Approval Cycle Time'. Vertraging vóór dit moment is meestal gebruikersgerelateerd, terwijl vertraging erna procesgerelateerd is. Waar je het vindt Afgeleid uit een statuswijziging in de tabel 'requisition_headers', specifiek wanneer het veld 'status' verandert in 'pending_approval'. De timestamp van deze wijziging staat in het bijbehorende audittrail. Vastleggen Bepaal de timestamp waarop de status van de aanvraag voor het eerst verandert in 'pending_approval'. Eventtype inferred
	Inkooporder aangemaakt	Op basis van de goedgekeurde aanvraag wordt een inkooporder (PO) aangemaakt. Dit event wordt afgeleid wanneer een PO-record wordt aangemaakt met een verwijzing naar de ID van de oorspronkelijke aanvraag.
Waarom dit belangrijk is Dit is de belangrijkste succesvolle uitkomst van het aanvraagproces en markeert de overdracht naar de volgende fase van Purchase-to-Pay. Door de tijd tussen ‘Aanvraag goedgekeurd’ en dit event te analyseren, zie je eventuele vertragingen in de uitvoering. Waar je het vindt Afgeleid uit het aanmaken van een record in de tabel ‘purchase_orders’ met een verwijzing naar de ID van de oorspronkelijke ‘requisition_headers’ of ‘requisition_lines’. Vastleggen Gebruik de ‘created-at’-timestamp van het PO-record dat aan de aanvraag-ID is gekoppeld. Eventtype inferred
	Aanvraag gewijzigd	De aanvrager of een andere bevoegde gebruiker wijzigt de aanvraag nadat deze al is ingediend. Coupa legt dit expliciet vast als een nieuwe versie of auditvermelding. Vaak wordt daardoor een deel van of de volledige goedkeuringsworkflow opnieuw gestart.
Waarom dit belangrijk is Het volgen van wijzigingen is belangrijk om herstelwerk en inefficiëntie in het proces te begrijpen. Veel wijzigingen kunnen wijzen op onduidelijke eerste vereisten of complex inkoopbeleid. Dat heeft invloed op de KPI 'Requisition Amendment Rate'. Waar je het vindt Dit wordt vastgelegd in audittrailtabellen die aan de tabel 'requisition_headers' zijn gekoppeld. Daarin staan versiewijzigingen of specifieke acties zoals 'edit'. Vastleggen Zoek in het historie-logboek van de aanvraag naar expliciete gebeurtenissen zoals 'edit' of 'update' na de indiening. Eventtype explicit
	Aanvraag ingetrokken	De oorspronkelijke aanvrager annuleert de aanvraag voordat deze definitief is goedgekeurd. Dit is een expliciete actie van de gebruiker die het proces voor deze aanvraag beëindigt.
Waarom dit belangrijk is Intrekkingen kunnen wijzen op veranderde bedrijfsbehoeften, dubbele aanvragen of gebruikers die het proces omzeilen. Door dit bij te houden, krijg je zicht op schommelingen in de vraag en mogelijke problemen met het volgen van het proces. Waar je het vindt Afgeleid uit een statuswijziging in de tabel ‘requisition_headers’ naar ‘withdrawn’ of een vergelijkbare status, op basis van een expliciete gebruikersactie in het audittrail. Vastleggen Bepaal de timestamp waarop de status van de aanvraag verandert in ‘withdrawn’. Eventtype inferred
	Aanvraag naar sourcing gestuurd	De goedgekeurde aanvraag wordt naar een sourcing-event gestuurd, zoals een RFQ of veiling, in plaats van direct te worden omgezet in een inkooporder. Dit event wordt afgeleid wanneer de aanvraag aan een sourcing-eventobject wordt gekoppeld.
Waarom dit belangrijk is Deze activiteit laat een belangrijke alternatieve route in het inkoopproces zien. Je maakt onderscheid tussen eenvoudige aankopen en complexere, strategische sourcingactiviteiten. Zo kun je doorlooptijden gerichter analyseren. Waar je het vindt Afgeleid door een statuswijziging naar ‘sourcing’ te detecteren of vast te stellen dat er een koppeling is gemaakt tussen de tabel ‘requisition_lines’ en een tabel met sourcing-events. Vastleggen Controleer op een statuswijziging naar ‘sourcing’ of op het aanmaken van een koppeling met een sourcing-event-ID. Eventtype inferred
	Goedkeuringsstap afgewezen	Een individuele goedkeurder wijst de aanvraag in zijn of haar fase van de workflow af en stuurt deze meestal terug naar de aanvrager voor aanpassing. Dit is een expliciete actie die door Coupa wordt vastgelegd.
Waarom dit belangrijk is Afwijzingen in elke stap leiden tot herstelwerk en langere doorlooptijden. Door te analyseren waar en waarom afwijzingen plaatsvinden, kun je het proces verbeteren en gerichte training geven. Waar je het vindt Vastgelegd op basis van een expliciete actie ‘reject’ in de tabel ‘approvals’ of het bijbehorende audittrail, gekoppeld aan de specifieke aanvraag en goedkeurder. Vastleggen Filter op ‘reject’-events in de goedkeuringsgeschiedenis van de aanvraag. Eventtype explicit
	Goedkeuringsstap gestart	Een goedkeuringstaak wordt toegewezen aan een specifieke goedkeurder of goedkeuringsgroep. De aanvraag wacht nu op hun actie. Je leidt dit af wanneer een goedkeuringsrecord voor de aanvraag wordt aangemaakt met de status 'pending'.
Waarom dit belangrijk is Dit markeert het begin van de wachttijd voor een specifieke goedkeuring. Door de duur tussen dit moment en de bijbehorende 'Approval Step Approved/Rejected' te meten, zie je waar in de goedkeuringsketen knelpunten ontstaan. Waar je het vindt Afgeleid uit de aanmaaktimestamp van een record in de tabel 'approvals' dat aan de aanvraag is gekoppeld. De actiestatus van de goedkeurder is daarbij 'pending' of een gelijkwaardige status. Vastleggen Gebruik de aanmaaktimestamp van het openstaande goedkeuringsrecord van een persoon in de goedkeuringsketen. Eventtype inferred
	Goedkeuringsstap goedgekeurd	Een individuele goedkeurder in de workflow keurt de aanvraag goed. Dit is een expliciete actie die door het systeem wordt vastgelegd met een specifieke timestamp en gebruikersinformatie.
Waarom dit belangrijk is Deze activiteit geeft gedetailleerd inzicht in het verloop van het goedkeuringsproces. Door deze stappen samen te voegen, kun je de ‘Gemiddelde wachttijd per goedkeuringsstap’ berekenen en de prestaties van goedkeurders analyseren. Waar je het vindt Vastgelegd op basis van een expliciete actie ‘approve’ in de tabel ‘approvals’ of het bijbehorende audittrail, gekoppeld aan de specifieke aanvraag en goedkeurder. Vastleggen Filter op ‘approve’-events in de goedkeuringsgeschiedenis van de aanvraag. Eventtype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je jouw data uit Coupa

Stappen

Aanmelden bij Coupa: Open je Coupa-instantie met een gebruikersaccount dat rechten heeft om rapporten te maken en te plannen.
Naar de rapportagemodule gaan: Ga naar het tabblad 'Setup' en zoek het gedeelte 'Reporting'. Selecteer 'Reports' om het rapportagedashboard te openen.
Een nieuw aangepast rapport maken: Klik op de knop 'Create' om een nieuw rapport te maken. Selecteer 'Custom Report' als type.
Databronnen voor het rapport definiëren: Selecteer en koppel in de rapportbouwer meerdere databronnen om alle vereiste informatie op te halen. Begin met 'Requisition Headers' als primaire bron. Voeg daarna de volgende gerelateerde objecten toe:
- 'Approvals': voor details over elke goedkeuringsstap, waaronder goedkeurder, status en timestamps.
- 'Requisition Lines': om totaalbedragen te berekenen en details op regelniveau op te halen.
- 'Purchase Order Headers': om te bepalen wanneer een aanvraag wordt omgezet in een PO.
- 'Users': om volledige namen en afdelingsgegevens van aanvragers en goedkeurders op te halen.
Rapportkolommen configureren: Sleep de benodigde velden uit de beschikbare databronnen naar de rapportindeling. Dit is de belangrijkste stap, omdat deze kolommen worden gebruikt om het event log te maken. Neem minimaal de volgende velden op:
- Uit Requisition Headers: Requisition #, Created At, Submitted At, Updated At, Status, Created by (Login ID), Totaal, Sourced Externally?
- Uit Users (voor aanvrager): Volledige naam, Department Name.
- Uit Approvals: Created At, Updated At, Status, Approver (Login ID).
- Uit Purchase Order Headers: PO Number, Created At.
Rapportfilters instellen: Pas filters toe om de data-extractie af te bakenen. Een veelgebruikte en effectieve filter is 'Requisition Headers - Created At' met een dynamisch datumbereik, bijvoorbeeld 'Last 90 days'. Je kunt ook filteren op specifieke bedrijfscodes als dat van toepassing is.
Het rapport plannen: Ga in de rapportbouwer naar het tabblad 'Schedule'. Stel de frequentie in, bijvoorbeeld dagelijks of wekelijks, en kies een tijdstip buiten piekuren.
De levering configureren: Geef de leveringsmethode op. Kies voor automatisering 'SFTP' en vul de servergegevens en doelmap in. Je kunt het bestand ook naar een e-mailadres sturen. Kies 'CSV' als bestandsformaat.
Opslaan en activeren: Sla het rapport op en controleer of de planning is geactiveerd. Het eerste rapport wordt op het eerstvolgende geplande tijdstip uitgevoerd.
De data transformeren: Het gegenereerde CSV-bestand is een flat file en geen event log. Verwerk het bestand met een extern script, bijvoorbeeld in Python, of met een ETL-tool. Het script moet de data omzetten, met één afzonderlijke rij per activiteit, bijvoorbeeld een rij voor 'Requisition Created' op basis van de kolom Created At, een rij voor elke goedkeuringsstap op basis van de kolommen uit 'Approvals' en een rij voor 'Purchase Order Created' op basis van Created At van de PO.
Het uiteindelijke event log genereren: Het transformatiescript moet een CSV-bestand maken met de vereiste kolommen: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate en andere aanbevolen attributen. Dit bestand kan nu worden geüpload.

Configuratie

Primaire databronnen: Het rapport moet meerdere Coupa-objecten combineren. De belangrijkste bronnen zijn 'Requisition Headers', 'Approvals', 'Requisition Lines' en 'Purchase Order Headers'.
Filteren op datumbereik: Beperk de hoeveelheid data met een datumfilter. Een doorlopend venster van de laatste 3 tot 6 maanden op basis van 'Requisition Headers - Created At' is een goed startpunt.
Incrementeel laden: Plan het rapport voor doorlopende analyses dagelijks in en haal de data van de vorige dag op, bijvoorbeeld met 'Yesterday', zodat je incrementeel kunt laden.
Levering instellen: Stel de levering in naar een SFTP-server voor een betrouwbare, geautomatiseerde koppeling met je datapijplijn. Zorg dat de bestemming beveiligd is en genoeg opslagruimte heeft.
Vereiste rechten: Het gebruikersaccount waarmee je het rapport instelt, heeft beheerrechten of specifieke rapportagerechten nodig om alle vereiste dataobjecten, zoals Requisitions, POs, Approvals en Users, te maken, in te plannen en te openen.

a Voorbeeldquery config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

Stappen

Vereisten: Zorg dat Python 3 is geïnstalleerd. Installeer de benodigde bibliotheken, pandas en requests, met pip install pandas requests in je terminal of opdrachtprompt.
Vraag een Coupa API-sleutel aan: Log als beheerder in op je Coupa-instantie. Ga naar Setup > Company Setup > API Keys. Maak een nieuwe API-sleutel met minimaal leesrechten voor deze scopes: core.purchase_order.read, core.requisition.read en core.user.read.
Stel het script in: Maak een nieuw Python-bestand, bijvoorbeeld extract_coupa_reqs.py. Kopieer het meegeleverde Python-script naar dit bestand. Vervang de tijdelijke waarden voor COUPA_INSTANCE_URL door de Coupa-URL van je bedrijf, bijvoorbeeld https://yourcompany.coupahost.com, en vul bij API_KEY de sleutel in die je in de vorige stap hebt aangemaakt.
Stel de extractieparameters in: Pas in het gedeelte main van het script de variabelen START_DATE en END_DATE aan om het datavenster voor de extractie te bepalen. Hiermee filter je requisitions op aanmaakdatum.
Voer het script uit: Start het script vanuit je terminal met python extract_coupa_reqs.py. Het script maakt verbinding met de Coupa API, haalt de data op en toont de voortgang in de console.
Verwerk paginering van de API: Het script bevat een functie die paginering automatisch afhandelt. Het haalt data op in blokken van 50 records en gaat door tot alle requisitions binnen het gekozen datumbereik zijn opgehaald.
Verwerk de requisition-data: Voor elke opgehaalde requisition header maakt het script de events 'Requisition Created' en 'Requisition Submitted'. Daarna haalt het via extra API-aanroepen de bijbehorende goedkeurings- en purchase-orderdata op.
Maak activiteitevents: Het script verwerkt de goedkeuringsrecords en maakt events voor 'Approval Step Started', 'Approval Step Approved' en 'Approval Step Rejected'. Het controleert ook de eindstatus van de requisition en gerelateerde data om events te maken zoals 'Requisition Approved', 'Purchase Order Created' en 'Requisition Withdrawn'.
Detecteer wijzigingen: Het script controleert het attribuut version van elke requisition. Als de versie hoger is dan 1, gaat het om een wijziging. Het script maakt dan een event 'Requisition Amended' met de updated-at-timestamp van de nieuwere versie.
Stel het event log samen: Alle gemaakte events worden verzameld in een gestructureerde lijst. Elk event bevat de verplichte attributen, zoals PurchaseRequisitionId, ActivityName en EventTime, plus aanbevolen attributen zoals Requester en TotalAmount.
Exporteer naar CSV: Nadat alle requisitions zijn verwerkt, zet het script de eventlijst om in een pandas DataFrame en slaat die op als coupa_requisition_event_log.csv in dezelfde map. Dit bestand is klaar om rechtstreeks naar ProcessMind te uploaden.

Configuratie

Rechten voor API-sleutel: De API-sleutel voor de extractie moet leesrechten hebben voor de objecten requisition_headers, requisition_lines, approvals, purchase_orders en users in Coupa. Zonder deze rechten mislukt het script of levert het onvolledige data op.
Datumbereik: Het script gebruikt een filter op de aanmaakdatum van de requisition (created-at). Haal de data bij voorkeur op in beheersbare blokken van bijvoorbeeld 3 tot 6 maanden. Zo voorkom je lange runtijden en mogelijke time-outs van de API. Pas de variabelen START_DATE en END_DATE hierop aan.
Filteren op status: Het meegeleverde script haalt alle requisitions op, ongeacht hun status. Voor een gerichtere analyse kun je een parameter status toevoegen aan het woordenboek params in de eerste API-aanroep. Zo richt je je bijvoorbeeld op approved, pending_approval of ordered.
Limiet voor paginering: Het script haalt per API-aanroep maximaal 50 records op (limit=50). Dit is een gebruikelijke waarde voor de Coupa API. Een hogere waarde maakt het script niet per se sneller en kan bij complexe query's de kans op time-outs vergroten.
Prestaties: Het script doet meerdere API-aanroepen per requisition, één voor de header, één voor goedkeuringen en één voor POs. Duizenden requisitions ophalen kan daardoor tijd kosten en vallen onder de API-limieten van Coupa. Voer het script bij voorkeur buiten piekuren uit.

a Voorbeeldquery python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

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

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

Stappen

Controleer of het gekozen iPaaS- of process mining-platform een geverifieerde Coupa-connector biedt met toegang tot requisition headers, requisitionhistorie of auditdata, goedkeuringsrecords, sourcingrelaties, purchase-orderrelaties en sluitingsinformatie. Connectornamen, objectnamen en beschikbare velden verschillen per aanbieder. Stel de connector daarom in volgens de documentatie en jouw Coupa-tenant.
Maak via de verbindingsinterface van het platform een connectorverbinding. Vul de vereiste Coupa-tenant-URL, authenticatiemethode, inloggegevens, OAuth-gegevens en eventuele vereiste scopes in. Gebruik tijdelijke waarden zoals [Your Coupa tenant URL] en [Your connector credentials] totdat je de verbinding in de doelomgeving hebt ingesteld.
Stel de extractiescope in. Kies eerst een doorlopend datumbereik van drie tot zes maanden en breid dit na afstemming uit. Gebruik alleen filters die geldig zijn voor jouw tenant, zoals [Your company filter] of [Your document type filter]. Filter requisitions niet alleen weg omdat hun huidige status closed, rejected, withdrawn of approved is. Deze cases zijn nodig voor een analyse van de volledige levenscyclus.
Koppel de bronobjecten in de connector. Selecteer het requisition-headerobject, het object voor requisitionhistorie of audit, het approval-object, het sourcingrelatie-object, het purchase-orderrelatie-object en elk beschikbaar object voor sluitings- of statushistorie. Als een vereist object niet beschikbaar is, gebruik dan de ondersteunde historie- of auditweergave van de connector. Leg de beperking vast voordat je de extractie publiceert.
Stel de case- en eventkoppelingen in. Koppel de requisition-ID aan PurchaseRequisitionId, het eventlabel aan ActivityName, de brontimestamp aan EventTime, de vaste bronwaarde Coupa aan SourceSystem en de refresh-timestamp van de connector aan LastDataUpdate. Koppel ook requester, afdeling, totaalbedrag, requisitionstatus en approver als deze velden beschikbaar zijn.
Stel eventregels in die expliciet rijen maken voor alle twaalf activiteiten. Maak Requisition Created op basis van de aanmaaktimestamp van de requisition, Requisition Submitted bij een overgang van draft naar pending_approval, Requisition Amended op basis van een versie- of auditrecord na indiening, Approval Step Started op basis van een openstaande goedkeuring, Approval Step Approved op basis van een goedkeuringsactie, Approval Step Rejected op basis van een afwijzingsactie, Requisition Withdrawn op basis van een expliciete intrekking of statusovergang, Requisition Approved op basis van een statusovergang naar approved, Requisition Rejected op basis van een statusovergang naar rejected, Requisition Sourced op basis van een requisition-sourcingrelatie, Purchase Order Created op basis van een purchase order die naar de requisition verwijst en Requisition Closed op basis van een sluitingsactie of statusovergang.
Normaliseer de geëxtraheerde data voordat je de eventstromen samenvoegt. Zet alle timestamps om naar één tijdzone, bij voorkeur UTC. Behoud de precisie van de brontimestamp, zet de requisition-ID om naar één consistent teksttype en bewaar de bronstatus en gebruikerswaarden. Verwijder alleen technisch identieke bronrecords. Gebruik daarvoor de requisition-ID, activity name, eventtimestamp, het bronrecord-ID als dat beschikbaar is en de approver als vergelijkingssleutel.
Publiceer of plan de connectorflow. Gebruik eerst een volledige extractie voor het gekozen datumbereik. Voer daarna incrementele vernieuwingen uit op basis van de update-timestamp van de bron of het mechanisme voor wijzigingsregistratie dat de connector ondersteunt. Stel een terugkijkperiode in, zodat late auditrecords en gewijzigde goedkeuringsrecords worden meegenomen.
Controleer het resulterende event log aan de hand van Coupa-rapporten of de connectorpreview. Controleer of elke requisition een aanmaakevent heeft, of status- en goedkeuringswijzigingen in de juiste volgorde staan en of relatiegebaseerde events aanwezig zijn wanneer er sourcing of purchase orders zijn.
Exporteer het eindresultaat als een plat CSV-bestand of een ander door ProcessMind ondersteund event-logformaat. Gebruik één rij per event, PurchaseRequisitionId als case-ID, ActivityName als activiteit en EventTime als eventtimestamp. Upload het bestand of publiceer de connectordataset naar ProcessMind. Laat ProcessMind geen ontbrekende events afleiden.

Configuratie

Connector en toegang: Gebruik een geverifieerde Coupa-connector van het gekozen iPaaS- of process mining-platform. De vereiste Coupa-autorisaties, API-scopes, modules en connectorlicenties hangen af van de aanbieder en tenantconfiguratie. Controleer vóór de implementatie of je toegang hebt tot requisition-, historie- of auditdata, goedkeuringen, sourcing, purchase orders en sluitingsinformatie.
Datumbereik: Begin met drie tot zes maanden aan data. Gebruik voor geplande vernieuwingen een doorlopend extractievenster en voeg een terugkijkperiode toe voor late updates, goedkeuringsacties en gewijzigde requisitions.
Vereiste koppelingen: Koppel de requisition-ID aan PurchaseRequisitionId, het eventlabel aan ActivityName, de eventtimestamp aan EventTime, de bronwaarde aan SourceSystem en de refresh-timestamp aan LastDataUpdate.
Aanbevolen koppelingen: Koppel requisitionstatus, requester, afdeling of kostenplaats, totaalbedrag en approver. Bewaar zowel actuele waarden als waarden op eventniveau als de connector historische snapshots ondersteunt.
Eventregels: Stel expliciete eventcreatie in voor alle twaalf vereiste activiteiten. ProcessMind leest het event log zoals het is en leidt geen extra events af.
Filters: Gebruik alleen filters die de connector ondersteunt en die geldig zijn voor de tenant, zoals [Your company filter], [Your document type filter], [Your business unit filter] of [Your requisition date range]. Sluit eindstatussen niet uit, tenzij de analyse dat specifiek vereist.
Timestamps: Zet timestamps om naar één tijdzone, behoud de bronprecisie en bepaal een vaste volgorderegel voor events met dezelfde timestamp.
Incrementele vernieuwing: Gebruik het ondersteunde updated-at- of wijzigingsregistratieveld van de connector. Stel een terugkijkvenster in, omdat goedkeuringshistorie, sourcingkoppelingen, purchase-orderkoppelingen en sluitingsinformatie na de eerste aanmaak kunnen worden toegevoegd.
Prestaties: Beperk de eerste extractie op datum en geldige bedrijfsfilters, haal alleen de benodigde velden op, gebruik paginering voor grote objecten en voorkom dat je volledige historische datasets steeds opnieuw koppelt. Haal relatie- en auditdata incrementeel op als dat wordt ondersteund.
Datakwaliteit: Vereis een niet-lege PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate. Bewaar bron-ID's voor foutopsporing en het verwijderen van dubbele records als de connector deze beschikbaar maakt.
Verschillen in configuratie: Objectnamen, veldnamen, statuswaarden, auditweergaven en beschikbare relatiegegevens verschillen per Coupa-tenant en connector. Gebruik [Configure based on your system] als de connector geen gedocumenteerd equivalent biedt.

a Voorbeeldquery config

WITH
requisition_created AS (
    SELECT
        CAST(r.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        CAST(r.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(r.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your requisition header object] r
    WHERE r.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND r.created_at < CAST('[Your end date]' AS TIMESTAMP)
      AND [Your company filter]
),
requisition_submitted AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Submitted' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.previous_status AS VARCHAR(255))) = 'draft'
      AND LOWER(CAST(h.new_status AS VARCHAR(255))) = 'pending_approval'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_amended AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('amended', 'updated', 'version_created')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_started AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        CAST(a.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.status AS VARCHAR(255))) = 'pending'
      AND a.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_approved AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'approved'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_rejected AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'rejected'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_withdrawn AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('withdrawn', 'withdrawal', 'cancelled_before_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_approved AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'approved'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_rejected AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'rejected'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_sourced AS (
    SELECT
        CAST(s.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Sourced' AS ActivityName,
        CAST(s.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(s.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your sourcing relationship object] s
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(s.requisition_id AS VARCHAR(255))
    WHERE s.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND s.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
purchase_order_created AS (
    SELECT
        CAST(p.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        CAST(p.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(p.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your purchase order relationship object] p
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(p.requisition_id AS VARCHAR(255))
    WHERE p.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND p.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_closed AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('closed', 'closure', 'cancelled_after_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_submitted
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_amended
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_started
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_withdrawn
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_sourced
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM purchase_order_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_closed
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Klaar om aan de slag te gaan?

Begin vandaag met het optimaliseren van je Coupa Purchase to Pay - Requisition-proces met deze template. Krijg waardevolle inzichten en verbeter de efficiëntie van je inkoopproces.

Terug naar de verbetergids Template downloaden

Optimaliseer Coupa P2P Requisitions en verkort vandaag je doorlooptijd

Vind inefficiënties en verkort de doorlooptijd van je P2P-requisitions met 30%.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Optimaliseer je proces in enkele minuten.

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

Geplande Coupa-rapporten voor data-export van requisitions

Stappen

Configuratie

a Voorbeeldquery config

Data-extractie met een Python-script via de Coupa REST API

Stappen

Configuratie

a Voorbeeldquery python

Extractie met een iPaaS-connector van een externe partij

Stappen

Configuratie

a Voorbeeldquery config

Klaar om aan de slag te gaan?

Optimaliseer Coupa P2P Requisitions en verkort vandaag je doorlooptijd

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

Geplande Coupa-rapporten voor data-export van requisitions

Stappen

Configuratie

a Voorbeeldquery config

Data-extractie met een Python-script via de Coupa REST API

Stappen

Configuratie

a Voorbeeldquery python

Extractie met een iPaaS-connector van een externe partij

Stappen

Configuratie

a Voorbeeldquery config

Klaar om aan de slag te gaan?

Optimaliseer Coupa P2P Requisitions en verkort vandaag je doorlooptijd

We respecteren je privacy