> Continu verbeteren van processen > Purchase to Pay Inkoopaanvraag > Coupa > Datatemplate

Datatemplate voor Purchase to Pay-aanvragen

Coupa

Attributen voor Purchase to Pay-aanvragen(21) Activiteiten voor Purchase to Pay-aanvragen(12) Extractiegidsen(3)

Datatemplate voor Purchase to Pay-aanvragen

Deze datatemplate biedt een vaste structuur voor het verzamelen van de informatie die nodig is om het Purchase to Pay-aanvraagproces te analyseren. Je vindt hierin de essentiële attributen en activiteiten voor een bruikbaar event log, plus uitleg over hoe je deze data uit Coupa haalt.

Aanbevolen attributen voor een volledige analyse
Belangrijke procesactiviteiten om vast te leggen
Praktische uitleg over data-extractie

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

Template downloaden

Attributen voor Purchase to Pay-aanvragen

Dit zijn de aanbevolen datavelden voor je event log om het Purchase to Pay-aanvraagproces volledig te analyseren.

5 Verplicht 5 Aanbevolen 11 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de bedrijfsactiviteit of gebeurtenis die op een bepaald moment voor de aanvraag plaatsvond.
Beschrijving Dit attribuut legt de afzonderlijke stappen in de levenscyclus van de inkoopaanvraag vast. Voorbeelden zijn ‘Aanvraag aangemaakt’, ‘Goedkeuringsstap goedgekeurd’ en ‘Aanvraag naar sourcing gestuurd’. Elke activiteit is een specifieke mijlpaal of actie voor de aanvraag. Door de volgorde en frequentie van deze activiteiten te analyseren, kun je proceskaarten visualiseren, veelvoorkomende routes herkennen en afwijkingen van de standaardprocedure opsporen. Dat is een belangrijk onderdeel van process mining. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart. Zo kun je het verloop van aanvragen visualiseren en analyseren. Waar vind je dit? Deze informatie komt meestal uit event logs, statuswijzigingen of auditsporen in Coupa. Mogelijk moet je de gegevens afleiden uit statusvelden of actiecodes. Voorbeelden Aanvraag aangemaaktAanvraag ingediendGoedkeuringsstap goedgekeurdAanvraag afgewezenInkooporder aangemaakt
	ID van inkoopaanvraag PurchaseRequisitionId	De unieke identificatiecode van elke inkoopaanvraag. Deze dient als primaire case-ID voor het proces.
Beschrijving De ID van de inkoopaanvraag is de centrale sleutel die alle activiteiten voor één aanvraag van goederen of diensten met elkaar verbindt. Bij het aanmaken krijgt elke aanvraag een unieke ID, die gedurende de hele levenscyclus hetzelfde blijft. Zo kun je de aanvraag van begin tot eind volgen: van aanmaken en indienen tot alle goedkeurings- of afwijzingsstappen en de uiteindelijke sourcing en afsluiting. 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 met elkaar verbindt. Zo kun je de levenscyclus van de aanvraag van begin tot eind analyseren. Waar vind je dit? Dit primaire-sleutelveld staat in de module Requisitions van Coupa en in de bijbehorende data-exportbestanden. Voorbeelden PR-102934PR-102935PR-102936
	Tijdstip van gebeurtenis EventTime	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving Het tijdstip van de gebeurtenis, oftewel de timestamp, legt het exacte moment vast waarop een activiteit voor een inkoopaanvraag is geregistreerd. Deze data is nodig om gebeurtenissen chronologisch te ordenen en het procesverloop op te bouwen. Alle tijdsanalyses zijn hierop gebaseerd, zoals het berekenen van doorlooptijden, het opsporen van bottlenecks door de tijd tussen activiteiten te meten en het vergelijken van procesprestaties over verschillende perioden. Voor een bruikbare procesanalyse zijn nauwkeurige timestamps met voldoende detail nodig. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen in de juiste volgorde te zetten en tijdsgebonden metrieken te berekenen, zoals doorlooptijden en bottlenecks. Waar vind je dit? Deze informatie staat in het auditspoor of de geschiedenisrecords 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
	Bronsysteem SourceSystem	Geeft aan uit welk bronsysteem de data is opgehaald.
Beschrijving Dit attribuut geeft aan in welk registratiesysteem de procesdata is ontstaan. Voor deze analyse is de waarde altijd ‘Coupa’. Dit veld opnemen is een goede gewoonte, vooral wanneer data uit meerdere systemen wordt samengevoegd. Het geeft inzicht in de herkomst van de data en helpt bij het beheer van datagovernance en kwaliteitsregels. Waarom dit belangrijk is Geeft duidelijkheid over de herkomst van de data. Dat is belangrijk voor datagovernance en wanneer je data uit meerdere bedrijfssystemen combineert. Waar vind je dit? Dit is meestal een vaste 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 van de laatste keer dat de data uit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie uit Coupa. Zo is duidelijk hoe actueel de geanalyseerde data is. Aan de hand van de actualiteit kun je bepalen of de inzichten de huidige bedrijfsvoering weergeven of een eerdere situatie. Dit is vooral belangrijk voor dashboards die lopende processen volgen. Waarom dit belangrijk is Laat zien hoe actueel de data is. Zo weet je op welke periode de analyse betrekking heeft en kun je beslissingen nemen op basis van recente informatie. Waar vind je dit? De datapijplijn of ETL-tool genereert deze timestamp en voegt die toe na een geslaagde data-extractie. Voorbeelden 2024-05-21T02:00:00Z
	Aanvraagstatus RequisitionStatus	De huidige of definitieve status van de inkoopaanvraag.
Beschrijving Dit attribuut geeft de algemene status van de aanvraag aan op het moment dat de data wordt opgehaald, of de uiteindelijke uitkomst. Veelvoorkomende statussen zijn ‘Wacht op goedkeuring’, ‘Goedgekeurd’, ‘Afgewezen’, ‘Ingetrokken’ en ‘Gesloten’. Je kunt deze status gebruiken om te filteren en te analyseren. Zo bereken je goedkeurings- en afwijzingspercentages, houd je de actuele werkvoorraad van open aanvragen bij en zie je hoe aanvragen uiteindelijk zijn afgehandeld. Waarom dit belangrijk is Nodig om uitkomsten van aanvragen te begrijpen, goedkeurings- en afwijzingspercentages te berekenen en de actuele status van lopende aanvragen te volgen. Waar vind je dit? Dit is een standaardveld op het object Purchase Requisition in Coupa, vaak met de naam ‘status’ of ‘state’. Voorbeelden Wacht op goedkeuringGoedgekeurdAfgewezenIngetrokkenGesloten
	Aanvrager Requester	De medewerker die de inkoopaanvraag heeft aangemaakt en ingediend.
Beschrijving Dit attribuut geeft aan wie de aanvraag heeft gestart. Door data per aanvrager te analyseren, kun je patronen bij specifieke gebruikers herkennen, zoals veel aanpassingen of afwijzingen. Dat kan erop wijzen dat extra training nodig is. Je kunt ook het aantal aanvragen en het procesgedrag van verschillende gebruikers of gebruikersgroepen analyseren. Waarom dit belangrijk is Hiermee kun je procesgedrag per gebruiker analyseren, trainingsbehoeften herkennen en zien hoe verschillende mensen het proces doorlopen. Waar vind je dit? Dit is beschikbaar als standaardveld op het object Requisition in Coupa. Het is vaak gekoppeld aan het object User en heet bijvoorbeeld ‘requester’ of ‘created_by’. Voorbeelden Alice JohnsonBob SmithCharlie Brown
	Afdeling Department	De afdeling 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, zodat managers doorlooptijden van goedkeuringen, afwijzingspercentages en compliance tussen organisatieonderdelen kunnen vergelijken. Zo worden afdelingsspecifieke problemen en goede werkwijzen zichtbaar. Waarom dit belangrijk is Hiermee kun je proces-KPI’s, zoals doorlooptijd en afwijzingspercentages, tussen bedrijfseenheden vergelijken en verbeterpunten vinden. Waar vind je dit? Dit is een standaardveld op het object Requisition in Coupa. Het is vaak gekoppeld aan het gebruikersprofiel van de aanvrager of staat op de aanvraagregels. Voorbeelden MarketingIT-bedrijfsvoeringFacilitair beheerOnderzoek en ontwikkeling
	Goedkeurder Approver	De gebruiker of groep die verantwoordelijk is voor een goedkeuringsactiviteit.
Beschrijving Dit attribuut geeft aan welke persoon of goedkeuringsgroep aan een goedkeuringsstap is toegewezen. Het wordt ingevuld bij activiteiten zoals ‘Goedkeuringsstap gestart’, ‘Goedkeuringsstap goedgekeurd’ en ‘Goedkeuringsstap afgewezen’. Door data per goedkeurder te analyseren, kun je het dashboard ‘Prestaties en werkbelasting van goedkeurders’ opbouwen. Je meet individuele goedkeuringstijden, vindt bottlenecks die door specifieke goedkeurders ontstaan en beoordeelt de verdeling van de werkbelasting. Waarom dit belangrijk is Nodig om de prestaties en werkbelasting van goedkeurders te analyseren en bottlenecks bij specifieke personen of goedkeuringsgroepen op te sporen. Waar vind je dit? Deze informatie staat in de details van de goedkeuringsketen bij elke aanvraag in Coupa. Mogelijk moet je de gegevens koppelen aan gebruikersdata. Voorbeelden David MillerFinanciële goedkeurders niveau 2Susan Chen
	Totaalbedrag TotalAmount	De totale geldwaarde van de inkoopaanvraag.
Beschrijving Dit attribuut geeft de totale kosten weer van alle goederen en diensten in de aanvraag. Het bedrag speelt een belangrijke rol in de procesanalyse, omdat het vaak invloed heeft op de complexiteit van de goedkeuringsworkflow. Voor aanvragen met een hoger bedrag zijn meestal meer goedkeuringsstappen nodig. Door procesmetrieken per bedragscategorie te analyseren, bijvoorbeeld minder dan $ 1.000 of $ 1.000 tot $ 10.000, zie je hoe het proces omgaat met aanvragen van verschillende financiële omvang. Waarom dit belangrijk is Hiermee kun je zien hoe het proces verschilt per aanvraagbedrag. Hogere bedragen leiden vaak tot complexere goedkeuringsworkflows. Waar vind je dit? Dit is een standaardveld in de header van het object Requisition in Coupa, meestal met de naam ‘total’ of ‘total_amount’. Voorbeelden 500.0012550.7599.99
	Aantal goedkeuringsstappen ApprovalStepCount	Het totale aantal goedkeuringsstappen dat een aanvraag heeft doorlopen.
Beschrijving Dit berekende attribuut telt voor elke aanvraag het aantal unieke activiteiten 'Approval Step Approved'. Zo wordt de complexiteit van de goedkeuringsworkflow per case meetbaar. Dit vormt de basis voor de KPI 'Gemiddeld aantal goedkeuringsstappen' en helpt aanvragen te vinden met ongebruikelijk lange of complexe goedkeuringsroutes. Die kunnen erop wijzen dat de workflow eenvoudiger kan. Waarom dit belangrijk is Maakt de complexiteit van de goedkeuringsworkflow per aanvraag meetbaar en helpt onnodig ingewikkelde routes te vinden die eenvoudiger kunnen. Waar vind je dit? Deze metriek wordt in de process mining-tool berekend door per Case-ID te tellen hoe vaak 'Approval Step Approved' voorkomt. Voorbeelden 253
	Aanvraagtype RequisitionType	De categorie of het type aanvraag, bijvoorbeeld ‘Investering’, ‘Bedrijfskosten’ of ‘Software’.
Beschrijving Het aanvraagtype classificeert aanvragen op basis van hun bedrijfsdoel of de aard van de aankoop. Dit attribuut is nuttig voor complianceanalyses en om te begrijpen hoe verschillende soorten aanvragen door het proces lopen. Aanvragen voor investeringen kunnen bijvoorbeeld een strengere en langere goedkeuringsroute volgen dan gewone aanvragen voor bedrijfsvoering. Door het proces per aanvraagtype te analyseren, kun je verbeterpunten vinden. Waarom dit belangrijk is Hiermee kun je analyses uitsplitsen naar het bedrijfsdoel van de aanvraag. Verschillende typen kunnen namelijk eigen procesroutes en beleidsregels hebben. Waar vind je dit? Dit is waarschijnlijk een aangepast of standaard classificatieveld op het object Requisition in Coupa. Voorbeelden InvesteringBedrijfskostenIT-hardwareProfessionele diensten
	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 wordt de wachttijd bij elke afzonderlijke stap in de goedkeuringsketen zichtbaar. Dit is nodig voor het dashboard ‘Bottlenecks bij kritieke goedkeuringsstappen’, omdat je precies kunt zien welke goedkeurders of stappen de meeste vertraging in het totale proces 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 vind je dit? Berekend in de process mining-tool door het tijdsverschil te bepalen tussen 'Approval Step Started' en de daaropvolgende afsluitende goedkeuringsgebeurtenis (Approved/Rejected). Voorbeelden 1,2 dagen4 uur3,8 dagen
	Goedkeuringsworkflowroute ApprovalWorkflowPath	Een identificatiecode voor de specifieke goedkeuringsketen of workflowtemplate die op de aanvraag van toepassing is.
Beschrijving Dit attribuut geeft de vooraf bepaalde volgorde van goedkeurders aan die een aanvraag hoort te volgen. Bedrijfsregels bepalen deze volgorde vaak op basis van factoren zoals bedrag, afdeling en aanvraagtype. Dit attribuut is een belangrijk onderdeel van het dashboard ‘Naleving van aanvraagbeleid’. Door de werkelijke volgorde van goedkeurders te vergelijken met de toegewezen workflowroute, kun je afwijkingen opsporen, nalevingspercentages meten en uitzonderingen herkennen die niet worden beheerd. Waarom dit belangrijk is Hiermee kun je de verwachte en werkelijke goedkeuringsstappen vergelijken, compliance analyseren en procesafwijkingen opsporen. Waar vind je dit? Raadpleeg de Coupa-documentatie. Dit kan worden afgeleid van de naam van de goedkeuringsketen of de workflowregel die voor de aanvraag is geactiveerd. Voorbeelden Standaardgoedkeuring < $ 5.000Goedkeuring IT-hardware > $ 10.000Beoordeling door CFO voor investering
	Inkooporder-ID PurchaseOrderId	De identificatiecode 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 inkooporder. Het verbindt het eerdere aanvraagproces met het daaropvolgende inkooporderproces. Hiermee kun je de KPI ‘Tijd tussen goedkeuring van de aanvraag en aanmaak van de 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 de volledige P2P-keten bekijken. Waar vind je dit? Dit is een standaardveld op het object Requisition in Coupa dat wordt ingevuld nadat de PO is aangemaakt. Voorbeelden PO-45000123PO-45000124PO-45000125
	Is aangepast IsAmended	Een booleaanse vlag die op waar staat als de aanvraag na de eerste indiening een of meer keer is aangepast.
Beschrijving Dit berekende attribuut is een eenvoudige vlag (waar/onwaar) die aangeeft of de activiteit ‘Aanvraag aangepast’ voor een case heeft plaatsgevonden. Zo kun je aanvragen waarvoor wijzigingen nodig waren eenvoudig filteren en analyseren. Je gebruikt dit attribuut om de KPI voor het aanpassingspercentage van aanvragen te berekenen en het dashboard ‘Aantal aangepaste aanvragen’ te vullen. Zo kun je de oorzaken van herstelwerk opsporen en de kwaliteit bij de eerste indiening verbeteren. Waarom dit belangrijk is Vereenvoudigt de berekening van het aanpassingspercentage en maakt het makkelijk om cases met en zonder herstelwerk apart te analyseren. Waar vind je dit? Dit wordt in de process mining-tool berekend door per case in het event log te controleren of de activiteit ‘Aanvraag aangepast’ voorkomt. Voorbeelden truefalse
	Naam leverancier SupplierName	De naam van de leverancier die voor de aanvraag is geselecteerd.
Beschrijving Dit attribuut geeft aan welke leverancier de goederen of diensten moet leveren. De aanvrager kan de leverancier opgeven, of deze kan later tijdens het sourcingtraject worden toegevoegd. Door procesmetrieken per leverancier te analyseren, kun je de prestaties van leveranciers beoordelen en nagaan of de samenwerking met bepaalde leveranciers leidt tot langere doorlooptijden of andere procesproblemen. Dit geeft belangrijke context voor de inkoopstrategie en het leveranciersbeheer. Waarom dit belangrijk is Hiermee kun je procesprestaties analyseren per geselecteerde leverancier. De resultaten kunnen helpen bij sourcingstrategieën en leveranciersbeheer. Waar vind je dit? Deze informatie staat op het object Requisition Line in Coupa, vaak in een veld met de naam ‘supplier’ of ‘vendor’. Voorbeelden StaplesDell TechnologiesAccentureCDW
	Productcategorie Commodity	De hoofdcategorie van de aangevraagde goederen of diensten.
Beschrijving Het attribuut Productcategorie geeft de regels in 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 productcategorieën gelden mogelijk specifieke goedkeuringsvereisten of sourcingstrategieën. Door het proces per productcategorie te analyseren, kun je de inkoop voor verschillende uitgavencategorieën verbeteren. Waarom dit belangrijk is Helpt uitgavencategorieën te analyseren en te zien of procesgedrag, zoals goedkeuringstijden, verschilt per type goederen of diensten. Waar vind je dit? Dit is een standaardveld in Coupa, meestal beschikbaar op het niveau van de aanvraagregel. Mogelijk moet je de gegevens samenvoegen op headerniveau. Voorbeelden KantoorbenodigdhedenComputerhardwareMarketingdienstenReizen
	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 op. Dit attribuut legt die toelichting vast. Door afwijzingsredenen te analyseren, krijg je rechtstreeks inzicht in waarom aanvragen mislukken. Dat helpt bij oorzaakanalyse en maakt veelvoorkomende problemen zichtbaar, zoals een onjuiste codering, een tekort aan budget of een onvoldoende onderbouwing. Vervolgens kun je die problemen aanpakken met training of procesverbeteringen. Waarom dit belangrijk is Geeft rechtstreeks inzicht in de oorzaken van procesproblemen, zodat je kunt bepalen waar gebruikerstraining of meer duidelijkheid over het proces nodig is. Waar vind je dit? Deze informatie staat meestal in het opmerkingen- of notitieveld bij een statuswijziging naar ‘Afgewezen’ in de goedkeuringsgeschiedenis van de aanvraag. Voorbeelden Onjuiste kostenplaatsOverschrijdt het budget voor dit kwartaalDubbele aanvraagOnvoldoende onderbouwing
	Urgentieniveau UrgencyLevel	Een classificatie die aangeeft hoe urgent de aanvraag is, bijvoorbeeld ‘Hoog’, ‘Gemiddeld’ of ‘Laag’.
Beschrijving Het urgentieniveau, vaak gekoppeld aan een prioriteitsveld, geeft aan dat een aanvrager een verzoek met spoed wil laten verwerken. Dit attribuut is nodig voor het dashboard ‘Verwerkingstijd van urgente aanvragen’. Door de doorlooptijden van urgente aanvragen te vergelijken met die van gewone aanvragen, kun je beoordelen of de prioritering werkt en of urgente bedrijfsbehoeften op tijd worden vervuld. Waarom dit belangrijk is Hiermee kun je nagaan of urgente aanvragen sneller worden verwerkt dan gewone aanvragen en of het prioriteringsbeleid werkt. Waar vind je dit? Dit kan een standaard- of aangepast veld zijn op het object Requisition in Coupa. 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 totale bedrag van de aanvraag is uitgedrukt. Dit is belangrijke context voor financiële analyses, vooral voor multinationale organisaties die met meerdere valuta’s werken. Zo worden geldbedragen correct geïnterpreteerd en kun je ze op de juiste manier omrekenen en samenvoegen in financiële rapportages en dashboards. Waarom dit belangrijk is Geeft de nodige context bij het attribuut ‘Totaalbedrag’, zodat financiële analyses in omgevingen met meerdere valuta’s kloppen. Waar vind je dit? Dit is een standaardveld op het object Requisition in Coupa, meestal met de naam ‘currency_code’ of iets vergelijkbaars. Voorbeelden USDEURGBP

Verplicht Aanbevolen Optioneel

Activiteiten voor Purchase to Pay-aanvragen

Leg deze belangrijke processtappen en mijlpalen vast in je event log om de workflow voor Purchase to Pay-aanvragen goed in beeld te brengen.

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 aanvraag-case. Meestal wordt dit afgeleid uit de aanmaaktimestamp van de aanvraagregistratie.
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 opsporen die ontstaan door onzekerheid bij gebruikers of een ingewikkeld systeem. Waar vind je dit? Deze gebeurtenis wordt vastgelegd aan de hand van de timestamp ‘created-at’ in de tabel ‘requisition_headers’ voor een bepaald Purchase Requisition-ID. Vastleggen Gebruik de aanmaaktimestamp van de aanvraagregistratie. Gebeurtenistype inferred
	Aanvraag afgewezen	De aanvraag wordt tijdens het goedkeuringsproces definitief afgewezen en wordt niet omgezet in een inkooporder. Dit wordt afgeleid uit de statuswijziging van de aanvraagheader naar ‘rejected’.
Waarom dit belangrijk is Deze activiteit markeert een definitief mislukte uitkomst van het proces. Door deze gebeurtenissen te analyseren, kun je het ‘Afwijzingspercentage van aanvragen’ verlagen en oorzaken opsporen, zoals beleidsovertredingen of budgetproblemen. Waar vind je dit? Afgeleid van een statuswijziging in de tabel ‘requisition_headers’, wanneer het veld ‘status’ wordt bijgewerkt naar ‘rejected’. De timestamp staat in het bijbehorende auditspoor. Vastleggen Bepaal de timestamp waarop de algemene status van de aanvraag verandert in ‘rejected’. Gebeurtenistype inferred
	Aanvraag gesloten	De aanvraag wordt formeel gesloten. Er worden dan 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 markeert het definitieve einde van de levenscyclus van de aanvraag. Zo worden cases netjes afgesloten en blijven ze niet voor onbepaalde tijd als ‘Actief’ in de procesanalyse staan. Waar vind je dit? Afgeleid van een statuswijziging in de tabel ‘requisition_headers’, wanneer het veld ‘status’ wordt bijgewerkt naar ‘closed’. De timestamp staat in het bijbehorende auditspoor. Vastleggen Bepaal de timestamp waarop de algemene status van de aanvraag verandert in ‘closed’. Gebeurtenistype inferred
	Aanvraag goedgekeurd	De aanvraag heeft alle vereiste stappen in de goedkeuringsworkflow doorlopen. Dit wordt afgeleid uit de statuswijziging van de aanvraagheader naar ‘approved’.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal: de goedkeuringscyclus is afgerond. De tijd tot deze activiteit is een belangrijke KPI en vormt het startsein voor de volgende inkoopacties. Waar vind je dit? Afgeleid van een statuswijziging in de tabel ‘requisition_headers’, wanneer het veld ‘status’ wordt bijgewerkt naar ‘approved’. De timestamp staat in het bijbehorende auditspoor. Vastleggen Bepaal de timestamp waarop de algemene status van de aanvraag verandert in ‘approved’. Gebeurtenistype inferred
	Aanvraag ingediend	De aanvrager dient de ingevulde aanvraag officieel in voor goedkeuring. Deze gebeurtenis wordt afgeleid uit de statuswijziging van ‘draft’ naar ‘pending_approval’ in de auditlogs of geschiedenistabellen van het systeem.
Waarom dit belangrijk is Na indiening begint het goedkeuringsproces. Dit is een belangrijk meetpunt voor de KPI ‘Gemiddelde doorlooptijd van goedkeuring van aanvragen’. Vertraging vóór dit moment hangt samen met de gebruiker; vertraging erna met het proces. Waar vind je dit? Afgeleid uit een statuswijziging in de tabel ‘requisition_headers’, met name wanneer het veld ‘status’ verandert in ‘pending_approval’. De timestamp van deze wijziging staat in het bijbehorende auditspoor. Vastleggen Bepaal de timestamp waarop de status van de aanvraag voor het eerst verandert in ‘pending_approval’. Gebeurtenistype inferred
	Inkooporder aangemaakt	Op basis van de goedgekeurde aanvraag wordt een inkooporder (PO) aangemaakt. Dit 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 deze gebeurtenis te analyseren, zie je eventuele uitvoeringsvertragingen. Waar vind je dit? Afgeleid van 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 timestamp ‘created-at’ van het PO-record dat aan de aanvraag-ID is gekoppeld. Gebeurtenistype inferred
	Aanvraag gewijzigd	Nadat de aanvraag is ingediend, past de aanvrager of een andere bevoegde gebruiker deze aan. Coupa registreert dit expliciet als een nieuwe versie of een auditvermelding. Vaak wordt daardoor een deel van de goedkeuringsworkflow of de hele workflow opnieuw gestart.
Waarom dit belangrijk is Wijzigingen bijhouden is belangrijk om herstelwerk en inefficiënties in het proces te begrijpen. Veel wijzigingen kunnen wijzen op onduidelijke vereisten bij de start of ingewikkeld inkoopbeleid. Dit heeft invloed op de KPI ‘Wijzigingspercentage van aanvragen’. Waar vind je dit? Dit wordt vastgelegd in auditspoordatabellen die horen bij de tabel ‘requisition_headers’. Daarin staan versieaanpassingen en specifieke acties zoals ‘edit’. Vastleggen Zoek na indiening in het geschiedenislogboek van de aanvraag naar expliciete gebeurtenissen zoals ‘edit’ of ‘update’. Gebeurtenistype explicit
	Aanvraag ingetrokken	De oorspronkelijke aanvrager annuleert de aanvraag voordat deze definitief is goedgekeurd. Deze expliciete actie wordt door de gebruiker gestart en beëindigt het proces voor die aanvraag.
Waarom dit belangrijk is Intrekkingen kunnen wijzen op veranderde bedrijfsbehoeften, dubbele aanvragen of gebruikers die het proces omzeilen. Door ze bij te houden, krijg je zicht op schommelingen in de vraag en mogelijke problemen met de naleving van het proces. Waar vind je dit? Afgeleid van een statuswijziging naar ‘withdrawn’ of een vergelijkbare status in de tabel ‘requisition_headers’, op basis van een expliciete gebruikersactie in het auditspoor. Vastleggen Bepaal de timestamp waarop de status van de aanvraag verandert in ‘withdrawn’. Gebeurtenistype inferred
	Aanvraag naar sourcing gestuurd	De goedgekeurde aanvraag wordt doorgestuurd naar een sourcingtraject, zoals een RFQ of veiling, in plaats van meteen te worden omgezet in een inkooporder. Dit wordt afgeleid wanneer de aanvraag wordt gekoppeld aan een sourcingobject.
Waarom dit belangrijk is Deze activiteit laat een belangrijke alternatieve route in het inkoopproces zien. Zo kun je gewone aankopen onderscheiden van complexere, strategische sourcingtrajecten en de doorlooptijden gerichter analyseren. Waar vind je dit? 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 sourcingtrajecten. Vastleggen Controleer op een statuswijziging naar ‘sourcing’ of op het aanmaken van een koppeling met een sourcingtraject-ID. Gebeurtenistype inferred
	Goedkeuringsstap afgewezen	Een goedkeurder wijst de aanvraag af bij zijn of haar stap in de workflow. Meestal wordt de aanvraag teruggestuurd naar de aanvrager om deze aan te passen. Coupa registreert deze expliciete actie.
Waarom dit belangrijk is Afwijzingen bij een stap leiden tot herstelwerk en langere doorlooptijden. Door te analyseren waar en waarom afwijzingen plaatsvinden, kun je het proces verbeteren en gebruikers trainen. Waar vind je dit? Afgeleid van een expliciete actie ‘afwijzen’ in de tabel ‘approvals’ of het bijbehorende auditspoor, gekoppeld aan de specifieke aanvraag en goedkeurder. Vastleggen Filter op gebeurtenissen met de actie ‘afwijzen’ in de goedkeuringsgeschiedenis van de aanvraag. Gebeurtenistype explicit
	Goedkeuringsstap gestart	Een goedkeuringstaak wordt toegewezen aan een specifieke goedkeurder of goedkeuringsgroep. De aanvraag wacht nu op hun actie. Dit wordt afgeleid uit een goedkeuringsregistratie voor de aanvraag met de status ‘pending’.
Waarom dit belangrijk is Dit markeert het begin van de wachttijd voor een specifieke goedkeuring. Door de tijd tussen dit moment en de bijbehorende stap ‘Goedkeuringsstap goedgekeurd/afgewezen’ te meten, kun je bottlenecks in de goedkeuringsketen opsporen. Waar vind je dit? Afgeleid uit de aanmaaktimestamp van een aan de aanvraag gekoppelde registratie in de tabel ‘approvals’, waarbij de actiestatus van de goedkeurder ‘pending’ of een vergelijkbare waarde is. Vastleggen Gebruik de aanmaaktimestamp van een openstaande goedkeuringsregistratie van een individuele goedkeurder in de goedkeuringsketen. Gebeurtenistype inferred
	Goedkeuringsstap goedgekeurd	Een afzonderlijke goedkeurder keurt de aanvraag goed in de workflow. Het systeem registreert deze expliciete actie met een specifieke timestamp en gebruikersgegevens.
Waarom dit belangrijk is Deze activiteit geeft gedetailleerd inzicht in het verloop van het goedkeuringsproces. Door deze stappen samen te nemen, kun je de ‘Gemiddelde wachttijd per goedkeuringsstap’ berekenen en de prestaties van goedkeurders analyseren. Waar vind je dit? Afgeleid van een expliciete actie ‘goedkeuren’ in de tabel ‘approvals’ of het bijbehorende auditspoor, gekoppeld aan de specifieke aanvraag en goedkeurder. Vastleggen Filter op gebeurtenissen met de actie ‘goedkeuren’ in de goedkeuringsgeschiedenis van de aanvraag. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Coupa

Stappen

Log in bij Coupa: Open je Coupa-omgeving met een gebruikersaccount dat rapporten mag maken en inplannen.
Ga naar de rapportagemodule: Open het tabblad 'Setup' en zoek het onderdeel 'Reporting'. Selecteer 'Reports' om het rapportagedashboard te openen.
Maak een aangepast rapport: Klik op 'Create' om een rapport op te zetten. Kies als type 'Custom Report'.
Stel de databronnen voor het rapport in: Selecteer en koppel in de rapportbuilder meerdere databronnen om alle benodigde informatie te verzamelen. Begin met 'Requisition Headers' als primaire bron. Voeg daarna deze gerelateerde objecten toe:
- 'Approvals': voor informatie over elke goedkeuringsstap, zoals de goedkeurder, status en timestamps.
- 'Requisition Lines': om totaalbedragen samen te voegen en informatie op artikelniveau op te halen.
- 'Purchase Order Headers': om vast te stellen wanneer een aanvraag wordt omgezet in een inkooporder (PO).
- 'Users': voor de volledige namen en afdelingsgegevens van aanvragers en goedkeurders.
Stel de rapportkolommen in: Sleep de benodigde velden uit de beschikbare databronnen naar de rapportindeling. Deze stap is het belangrijkst, want de kolommen vormen de basis voor het event log. 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 de aanvrager): Volledige naam, Department Name.
- Uit Approvals: Created At, Updated At, Status, Approver (Login ID).
- Uit Purchase Order Headers: PO Number, Created At.
Stel rapportfilters in: Pas filters toe om de data-extractie af te bakenen. Een veelgebruikte en effectieve filter is 'Requisition Headers - Created At' met een dynamische periode, bijvoorbeeld 'Last 90 days'. Je kunt ook filteren op specifieke bedrijfscodes, als dat van toepassing is.
Plan het rapport in: Open het tabblad 'Schedule' in de rapportbuilder. Stel in hoe vaak het rapport moet worden uitgevoerd, bijvoorbeeld dagelijks of wekelijks. Kies een tijdstip waarop het systeem weinig wordt gebruikt.
Stel de levering in: Kies hoe je het rapport wilt ontvangen. Selecteer voor automatische levering 'SFTP' en vul de servergegevens en doelmap in. Je kunt het rapport ook naar een e-mailadres sturen. Kies 'CSV' als bestandsindeling.
Sla op en activeer: Sla het rapport op en controleer of de planning is geactiveerd. Het eerste rapport wordt op het eerstvolgende geplande tijdstip uitgevoerd.
Transformeer de data: De gegenereerde CSV is een plat bestand, geen event log. Verwerk het bestand met een extern script, bijvoorbeeld in Python, of met een ETL-tool. Het script moet de data omzetten naar aparte rijen per activiteit. Maak bijvoorbeeld een rij voor 'Requisition Created' met de kolom Created At, een rij voor elke goedkeuringsstap met de kolommen uit 'Approvals' en een rij voor 'Purchase Order Created' met de PO-kolom Created At.
Genereer het definitieve event log: Laat het transformatiescript een definitief CSV-bestand maken met de vereiste kolommen: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate en andere aanbevolen attributen. Daarna kun je het bestand uploaden.

Configuratie

Primaire databronnen: Het rapport moet gegevens uit 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 goed startpunt is een voortschrijdende periode van de afgelopen 3 tot 6 maanden op basis van 'Requisition Headers - Created At'.
Incrementeel laden: Plan het rapport voor doorlopende analyses dagelijks in en haal de data van de vorige dag op, bijvoorbeeld met 'Yesterday', om incrementeel te laden.
Levering instellen: Stel levering aan een SFTP-server in voor een betrouwbare, geautomatiseerde koppeling met je datapijplijn. Zorg voor een beveiligde bestemming met voldoende opslagruimte.
Vereiste machtigingen: Het gebruikersaccount waarmee je het rapport instelt, heeft beheerdersrechten of specifieke rapportagemachtigingen nodig om alle vereiste dataobjecten (aanvragen, PO's, goedkeuringen en gebruikers) te maken, in te plannen en te openen.

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 door pip install pandas requests uit te voeren in de terminal of opdrachtprompt.
Haal een Coupa API-sleutel op: Log als beheerder in bij je Coupa-omgeving. Ga naar Setup > Company Setup > API Keys. Maak een 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 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 opgehaald.
Stel de extractieparameters in: Pas in het onderdeel main van het script de variabelen START_DATE en END_DATE aan om de periode voor de data-extractie in te stellen. Hiermee filter je aanvragen op aanmaakdatum.
Voer het script uit: Start het script vanuit de terminal met de opdracht 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 API-paginering: Het script bevat een functie die API-paginering automatisch afhandelt. Het haalt data op in pagina's van 50 records en gaat door tot alle aanvragen binnen de opgegeven periode zijn opgehaald.
Verwerk aanvraaggegevens: Voor elke opgehaalde aanvraagheader maakt het script de gebeurtenissen 'Requisition Created' en 'Requisition Submitted' aan. Daarna haalt het via extra API-aanroepen de bijbehorende goedkeurings- en inkoopordergegevens op.
Genereer activiteitsgebeurtenissen: Het script verwerkt de goedkeuringsrecords en maakt gebeurtenissen aan voor 'Approval Step Started', 'Approval Step Approved' en 'Approval Step Rejected'. Ook controleert het de eindstatus en gerelateerde data van de aanvraag om gebeurtenissen te maken zoals 'Requisition Approved', 'Purchase Order Created' en 'Requisition Withdrawn'.
Spoor wijzigingen op: Het script controleert het attribuut version van elke aanvraag. Een waarde hoger dan 1 betekent dat de aanvraag is gewijzigd. Met de timestamp updated-at van de nieuwere versie wordt de gebeurtenis 'Requisition Amended' aangemaakt.
Stel het event log samen: Alle gegenereerde gebeurtenissen worden verzameld in een gestructureerde lijst. Elke gebeurtenis bevat de vereiste attributen, zoals PurchaseRequisitionId, ActivityName en EventTime, en aanbevolen attributen, zoals Requester en TotalAmount.
Exporteer naar CSV: Nadat alle aanvragen zijn verwerkt, zet het script de lijst met gebeurtenissen om in een pandas DataFrame en slaat deze in dezelfde map op als CSV-bestand coupa_requisition_event_log.csv. Dit bestand kun je rechtstreeks uploaden naar ProcessMind.

Configuratie

Machtigingen voor API-sleutels: 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 filtert op aanmaakdatum van de aanvraag (created-at). Haal de data bij voorkeur op in behapbare perioden van bijvoorbeeld 3 tot 6 maanden om lange runtimes en time-outs van de API te voorkomen. Pas hiervoor de variabelen START_DATE en END_DATE aan.
Filteren op status: Het meegeleverde script haalt alle aanvragen op, ongeacht hun status. Voor een gerichtere analyse kun je in de eerste API-aanroep een parameter status toevoegen aan de dictionary params. Daarmee kun je filteren op specifieke statussen, zoals approved, pending_approval of ordered.
Paginering: Het script haalt per API-aanroep maximaal 50 records op (limit=50). Dit is een gangbare waarde die goed werkt met de Coupa API. Een hogere limiet verbetert de prestaties niet per se en kan bij complexe query's het risico op time-outs vergroten.
Prestaties: Voor elke aanvraag doet het script meerdere API-aanroepen: één voor de header, één voor goedkeuringen en één voor inkooporders. Data voor duizenden aanvragen ophalen kan tijd kosten en onderhevig zijn aan de snelheidslimieten van Coupa's API. Voer het script bij voorkeur buiten piekuren uit.

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 de gekozen iPaaS- of process mining-platform een goedgekeurde Coupa-connector biedt met toegang tot aanvraagheaders, aanvraaggeschiedenis of auditdata, goedkeuringsrecords, relaties met sourcing en inkooporders, en afsluitgegevens. Connectornamen, objectnamen en beschikbare velden verschillen per aanbieder. Stel de connector daarom in op basis van de documentatie en je 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 de verbinding in de doelomgeving is ingesteld.
Stel de extractieomvang in. Begin met een voortschrijdende periode van drie tot zes maanden en breid die na afstemming uit. Pas alleen filters toe die geldig zijn voor je tenant, zoals [Your company filter] of [Your document type filter]. Filter aanvragen niet alleen uit omdat hun huidige status gesloten, afgewezen, ingetrokken of goedgekeurd is. Deze cases zijn nodig voor de analyse van de levenscyclus.
Koppel de bronobjecten in de connector. Selecteer het aanvraagheaderobject, het object met aanvraaggeschiedenis of auditgegevens, het goedkeuringsobject, het sourcingrelatieobject, het inkooporderrelatieobject en eventuele beschikbare objecten met afsluit- of statusgeschiedenis. Is een vereist object niet beschikbaar, gebruik dan de ondersteunde weergave van geschiedenis- of auditgegevens van de connector, of leg de beperking vast voordat je de extractie publiceert.
Stel de case- en gebeurteniskoppelingen in. Koppel de aanvraag-ID aan PurchaseRequisitionId, het gebeurtenislabel aan ActivityName, de brontimestamp aan EventTime, de vaste bronwaarde Coupa aan SourceSystem en de vernieuwingstimestamp van de connector aan LastDataUpdate. Koppel ook de aanvrager, afdeling, het totaalbedrag, de aanvraagstatus en de goedkeurder als deze velden beschikbaar zijn.
Stel expliciete gebeurtenisregels in voor alle twaalf activiteiten. Maak Requisition Created aan op basis van de aanmaaktimestamp van de aanvraag, Requisition Submitted bij een overgang van concept naar pending_approval, Requisition Amended op basis van een versie of auditrecord na indiening, Approval Step Started op basis van een openstaande goedkeuringsrecord, Approval Step Approved op basis van een goedkeuringsactie, Approval Step Rejected op basis van een afwijzingsactie, Requisition Withdrawn op basis van een expliciete intrekkingsactie of statusovergang, Requisition Approved op basis van een overgang naar de goedgekeurde headerstatus, Requisition Rejected op basis van een overgang naar de afgewezen headerstatus, Requisition Sourced op basis van een relatie tussen aanvraag en sourcing, Purchase Order Created op basis van een inkooporder die naar de aanvraag verwijst, en Requisition Closed op basis van een afsluitactie of statusovergang.
Normaliseer de opgehaalde data voordat je de gebeurtenisstromen samenvoegt. Zet alle timestamps om naar één tijdzone, bij voorkeur UTC, behoud de precisie van de brontimestamps, zet de aanvraag-ID om naar een consistent teksttype en behoud de bronstatussen en gebruikerswaarden. Verwijder alleen technisch identieke bronrecords. Gebruik daarvoor de aanvraag-ID, activiteit, gebeurtenistimestamp, bronrecord-ID indien beschikbaar en goedkeurder als vergelijkingssleutel.
Publiceer of plan de connectorflow in. Voer eerst een volledige extractie uit voor de gekozen periode en gebruik daarna incrementele vernieuwingen op basis van de brondatum voor updates of het ondersteunde mechanisme voor wijzigingsregistratie van de connector. Stel een terugkijkperiode in, zodat late auditgegevens en gewijzigde goedkeuringsrecords worden meegenomen.
Controleer het resulterende event log aan de hand van Coupa-rapporten of het connectorvoorbeeld. Controleer of elke aanvraag een aanmaakgebeurtenis heeft, of status- en goedkeuringswijzigingen in de juiste volgorde staan en of gebeurtenissen op basis van relaties aanwezig zijn wanneer er sourcing of inkooporders zijn.
Exporteer het resultaat als een platte CSV of een andere indeling voor event logs die ProcessMind ondersteunt. Neem één rij per gebeurtenis op, gebruik PurchaseRequisitionId als case-ID, ActivityName als activiteit en EventTime als gebeurtenistimestamp. Upload het bestand of publiceer de connectordataset naar ProcessMind. Vertrouw er niet op dat ProcessMind ontbrekende gebeurtenissen afleidt.

Configuratie

Connector en toegang: Gebruik een goedgekeurde Coupa-connector van het gekozen iPaaS- of process mining-platform. Welke Coupa-machtigingen, API-scopes, modules en connectorlicenties nodig zijn, hangt af van de aanbieder en de tenantinstellingen. Controleer vóór de implementatie of je toegang hebt tot aanvraag-, geschiedenis- of auditgegevens, goedkeuringen, sourcing, inkooporders en afsluitgegevens.
Datumbereik: Begin met drie tot zes maanden aan data. Gebruik voor geplande vernieuwingen een voortschrijdende extractieperiode en neem een terugkijkperiode op om late updates, goedkeuringsacties en gewijzigde aanvragen mee te nemen.
Vereiste koppelingen: Koppel de aanvraag-ID aan PurchaseRequisitionId, het gebeurtenislabel aan ActivityName, de gebeurtenistimestamp aan EventTime, de bronwaarde aan SourceSystem en de vernieuwingstimestamp aan LastDataUpdate.
Aanbevolen koppelingen: Koppel de aanvraagstatus, aanvrager, afdeling of kostenplaats, het totaalbedrag en de goedkeurder. Behoud zowel de huidige waarden als de waarden op gebeurtenisniveau als de connector historische versies ondersteunt.
Gebeurtenisregels: Stel expliciete regels in voor het aanmaken van alle twaalf vereiste activiteiten. ProcessMind leest het event log zoals het is en leidt geen extra gebeurtenissen af.
Filters: Gebruik alleen filters die door de connector worden ondersteund en 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 daar specifiek om vraagt.
Timestamps verwerken: Zet timestamps om naar één tijdzone, behoud de precisie van de bron en bepaal een vaste volgorderegel voor gebeurtenissen met dezelfde timestamp.
Incrementeel vernieuwen: Gebruik het ondersteunde veld updated-at of de wijzigingsregistratie van de connector. Stel een terugkijkperiode in, omdat goedkeuringsgeschiedenis, sourcingrelaties, inkooporderrelaties en afsluitgegevens na de eerste aanmaak kunnen worden toegevoegd.
Prestaties: Beperk de eerste extractie op basis van datum en geldige bedrijfsfilters, haal alleen de vereiste velden op, gebruik paginering voor grote objecten en voorkom dat je volledige historische datasets steeds opnieuw koppelt. Haal relatie- en auditgegevens incrementeel op als dat wordt ondersteund.
Datakwaliteit: Vereis een ingevulde PurchaseRequisitionId, ActivityName, EventTime, SourceSystem en LastDataUpdate. Behoud bron-ID's voor probleemoplossing en het verwijderen van dubbele records als de connector deze beschikbaar maakt.
Verschillen in instellingen: 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.

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 te beginnen?

Optimaliseer vandaag nog het Purchase to Pay-aanvraagproces in Coupa met deze template. Ontdek waar verbetering mogelijk is en maak je inkoop efficiënter.

Terug naar de verbetergids

Template downloaden

Optimaliseer Coupa P2P-aanvragen en verkort de doorlooptijd

Spoor inefficiënties op en verkort de doorlooptijd van P2P-aanvragen met 30%.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten aan de slag.

Datatemplate voor Purchase to Pay-aanvragen

Datatemplate voor Purchase to Pay-aanvragen

Attributen voor Purchase to Pay-aanvragen

Activiteiten voor Purchase to Pay-aanvragen

Extractiegidsen

Geplande Coupa-rapporten voor data-export van aanvragen

Stappen

Configuratie

Voorbeeldquery config

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

Stappen

Configuratie

Voorbeeldquery python

Data-extractie met een iPaaS-connector van een externe partij

Stappen

Configuratie

Voorbeeldquery config

Klaar om te beginnen?

Optimaliseer Coupa P2P-aanvragen en verkort de doorlooptijd