> Continu verbeteren van processen > Inkoopaanvraag tot betaling > SAP Ariba > Datatemplate

Datatemplate voor Purchase to Pay - Requisition

SAP Ariba

Attributen voor Purchase to Pay - Requisition(19) Activiteiten voor Purchase to Pay - Requisition(13) Extractiegidsen(2)

Datatemplate voor Purchase to Pay - Requisition

Deze datatemplate helpt je de informatie voor de analyse van het Purchase to Pay - Requisition-proces efficiënt te verzamelen en te structureren. De template beschrijft de benodigde attributen en activiteiten voor een bruikbaar event log, waarmee je de prestaties van het proces kunt analyseren. Je vindt er ook praktische uitleg over het ophalen van data uit het bronsysteem, zodat je aan de slag kunt met process mining.

Aanbevolen attributen voor een volledige analyse
Belangrijke procesactiviteiten en mijlpalen om bij te houden
Praktische uitleg over data-extractie uit je systeem

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

Template downloaden

Attributen voor Purchase to Pay - Requisition

Dit zijn de aanbevolen datavelden voor het event log bij een volledige analyse van Purchase to Pay - Requisition. Zo mis je geen belangrijke informatie.

3 Verplicht 8 Aanbevolen 8 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsgebeurtenis die op een bepaald moment in de levenscyclus van de aanvraag plaatsvond.
Beschrijving De activiteitsnaam beschrijft één stap of mijlpaal in het aanvraagproces, zoals ‘Aanvraag aangemaakt’, ‘Goedkeuringsstap goedgekeurd’ of ‘Aanvraag gesloten’. Deze gegevens komen meestal uit event logs, statuswijzigingen of specifieke gebruikersacties in SAP Ariba. Dit attribuut is nodig om de proceskaart op te bouwen, die de activiteitenstroom visueel weergeeft. Door de volgorde en frequentie van activiteiten te analyseren, kunnen analisten veelvoorkomende procesroutes, bottlenecks, afwijkingen van de standaardprocedure en herstelwerk herkennen. Het vormt de basis van elke process mining-analyse. Waarom dit belangrijk is Dit attribuut beschrijft de processtappen en maakt het mogelijk de aanvraagworkflow zichtbaar te maken en te analyseren, inclusief bottlenecks en afwijkingen. Waar vind je dit? Afgeleid uit event logs, auditsporen of statuswijzigingen in SAP Ariba, vaak gekoppeld aan tabellen met aanvraagkoppen en aanvraagregels. Voorbeelden Aanvraag ingediendGoedkeuringsstap goedgekeurdAanvraag gewijzigdInkooporder aangemaakt
	Eventtimestamp EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond. Deze timestamp bepaalt de volgorde van events.
Beschrijving De eventtimestamp legt het exacte moment van een activiteit vast. Deze nauwkeurige gegevens zijn nodig om events binnen elke case in de juiste volgorde te zetten en de tijd tussen processtappen te berekenen. Deze timestamp vormt de basis voor alle tijdsberekeningen, zoals doorlooptijden, wachttijden en verwerkingstijden. Dashboards gebruiken de gegevens om prestaties te analyseren, bijvoorbeeld met de goedkeuringsdoorlooptijd van aanvragen en de bottleneckanalyse van goedkeuringsroutes. De nauwkeurigheid van dit veld bepaalt mede hoe betrouwbaar de prestatiemetrieken zijn. Waarom dit belangrijk is Dit attribuut bepaalt de chronologische volgorde van events en vormt de basis voor prestatie- en tijdsberekeningen, zoals doorlooptijden en bottlenecks. Waar vind je dit? Meestal te vinden bij activiteiten of statuswijzigingen in de auditsporen of transactielogtabellen van SAP Ariba. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Inkoopaanvraag-ID PurchaseRequisitionId	De unieke identificatiecode van een inkoopaanvraagdocument. Deze dient als belangrijkste case-ID voor het proces.
Beschrijving De inkoopaanvraag-ID is de centrale sleutel die alle activiteiten voor één aanvraag van goederen of diensten met elkaar verbindt. Elke aanvraag in SAP Ariba krijgt een unieke ID. Die blijft gedurende de hele levenscyclus gelijk, van aanmaak en indiening tot definitieve goedkeuring, afwijzing of afsluiting. Bij process mining is dit attribuut essentieel om cases aan elkaar te koppelen. Hiermee kun je het volledige traject van elke aanvraag reconstrueren, doorlooptijden nauwkeurig berekenen, procesvarianten herkennen en lussen met herstelwerk analyseren. Zonder deze ID zijn gebeurtenissen van verschillende aanvragen niet van elkaar te onderscheiden. Waarom dit belangrijk is Dit is de belangrijkste case-ID die alle bijbehorende activiteiten verbindt. Zo kun je het volledige aanvraagproces voor elke afzonderlijke aanvraag analyseren. Waar vind je dit? Dit is een primaire-sleutelveld in de belangrijkste kopgegevenstabellen van de datastructuur van SAP Ariba. Voorbeelden PR-102345PR-102346PR-102347
	Aanvraagstatus RequisitionStatus	De huidige status van de inkoopaanvraag in de levenscyclus.
Beschrijving Dit attribuut geeft de realtime status van een aanvraag weer, zoals ‘Opstellen’, ‘Ingediend’, ‘Goedgekeurd’, ‘Afgewezen’ of ‘Gesloten’. Het laat zien waar elke case zich op het moment van data-extractie in het proces bevindt. Process mining reconstrueert het historische verloop, maar dit attribuut is belangrijk voor operationele monitoring. Het is de belangrijkste gegevensbron voor de ‘Live Requisition Status Tracker’. Hiermee zien managers hoeveel werk er ligt en welke aanvragen vastlopen of al lang openstaan. Zo krijgen ze meteen een bruikbaar overzicht van de actieve aanvragen. Waarom dit belangrijk is Maakt realtime monitoring van de aanvragen mogelijk, zodat vastgelopen of lang openstaande aanvragen op tijd worden opgemerkt en aangepakt. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Dit is een standaardstatusveld in de kop van de aanvraag. Voorbeelden GoedgekeurdIngediendAfgewezenIn afwachting van goedkeuring
	Afdeling van aanvrager RequesterDepartment	De bedrijfsafdeling of het kostenplaatsnummer van de medewerker die de inkoopaanvraag heeft aangemaakt.
Beschrijving Dit attribuut geeft organisatorische context en laat zien welk deel van het bedrijf de aanvraag heeft ingediend. De gegevens komen meestal uit het gebruikersprofiel van de aanvrager of staan rechtstreeks op het aanvraagformulier. Bij analyses is dit een nuttige dimensie om op te filteren en mee te vergelijken. Het wordt gebruikt in vrijwel alle dashboards, zoals ‘Goedkeuringsdoorlooptijd van aanvragen’ en ‘Analyse van afwijzingspercentage van aanvragen’, om metrieken per afdeling uit te splitsen. Zo zie je welke afdelingen de langste doorlooptijden, de meeste wijzigingen of de meeste aanvragen die niet aan de regels voldoen hebben. Dat helpt om verbeteringen gericht aan te pakken. Waarom dit belangrijk is Hiermee kun je de procesprestaties van verschillende onderdelen van de organisatie vergelijken en afdelingsspecifieke problemen of goede werkwijzen herkennen. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. De gegevens staan meestal in de kopgegevens van de aanvraag en zijn vaak gekoppeld aan het gebruikersprofiel van de aanvrager. Voorbeelden MarketingIT-bedrijfsvoeringFinanciënOnderzoek en ontwikkeling
	Artikelcategorie ItemCategory	De indeling van de aangevraagde goederen of diensten, zoals ‘IT-hardware’, ‘Kantoorbenodigdheden’ of ‘Professionele diensten’.
Beschrijving De artikelcategorie geeft aan wat er wordt ingekocht. Deze indeling helpt uitgavenpatronen te begrijpen en inkoopstrategieën en beleidsregels per categorie toe te passen. Bij process mining is dit attribuut belangrijk voor het dashboard ‘Analyse van wijzigingen in aanvragen’. Je ziet ermee of bepaalde artikelcategorieën vaker worden gewijzigd, bijvoorbeeld door onduidelijke specificaties of wisselende prijzen. Ook kun je procesprestaties, zoals goedkeuringstijden, tussen verschillende soorten aankopen vergelijken en zien waar bepaalde categorieën meer vertraging oplopen. Waarom dit belangrijk is Hiermee kun je analyses uitvoeren op basis van de ingekochte goederen of diensten en bottlenecks of complianceproblemen per categorie herkennen. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Deze informatie staat meestal op regelniveau van de aanvraag. Voorbeelden IT-hardwareConsultancydienstenKantoorbenodigdhedenMarketingmateriaal
	Eventgebruiker EventUser	De gebruikers-ID of naam van de persoon die de activiteit uitvoerde, zoals de aanvrager of goedkeurder.
Beschrijving Het attribuut eventgebruiker geeft aan wie verantwoordelijk was voor een specifieke processtap. Dat kan de medewerker zijn die de aanvraag indiende, de manager die deze goedkeurde of de inkoopmedewerker die de aanvraag verwerkte. Dit attribuut is nodig om de werkbelasting te analyseren, prestaties te vergelijken en te bepalen waar training nodig is. Het voedt het dashboard ‘Werkbelasting en prestaties van goedkeurders’, waarmee je goedkeuringstijden per gebruiker kunt analyseren. Ook kun je vertragingen of afwijkingen onderzoeken door ze te herleiden naar specifieke personen of teams. Waarom dit belangrijk is Hiermee kun je de verdeling van het werk, gebruikersprestaties en de inzet van medewerkers analyseren. Zo spoor je bottlenecks op die door specifieke gebruikers of teams worden veroorzaakt. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Deze gegevens staan vaak in auditsporen of geschiedenistabellen en zijn gekoppeld aan stamgegevens van gebruikers. Voorbeelden john.doejane.smithmanager123
	Goedkeuringsroute ApprovalWorkflowPath	De vooraf bepaalde volgorde van goedkeuringsstappen die de aanvraag hoort te doorlopen.
Beschrijving Dit attribuut bepaalt welke standaardprocesvariant of goedkeuringsmatrix geldt voor een aanvraag, op basis van kenmerken zoals waarde, artikelcategorie en afdeling. Het beschrijft het gewenste proces, oftewel de ideale route. Dit is de basis voor conformancechecks en wordt gebruikt in het dashboard ‘Overzicht van naleving bij aanvragen’. Door de werkelijke activiteitenvolgorde te vergelijken met de verwachte goedkeuringsroute, kunnen analisten automatisch beleidsovertredingen, onbevoegde goedkeuringsstappen en overgeslagen controles opsporen. Dat is belangrijk voor interne audits en risicobeheer. Waarom dit belangrijk is Dit bepaalt welke standaardprocedure moet worden gevolgd. Met conformancechecks kun je afwijkingen en beleidsovertredingen automatisch opsporen. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Dit kan worden afgeleid uit de configuratie van de goedkeuringsmatrix of uit een specifiek veld op de aanvraag. Voorbeelden Standaard IT > $10kMarketingdiensten < $5kCAPEX > $100k
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft wanneer een aanvraag of goedkeuringsstap wordt afgewezen.
Beschrijving Bij een afgewezen aanvraag geven goedkeurders vaak een reden op. Dat kan vrije tekst zijn of een keuze uit een vooraf bepaalde lijst. Dit attribuut legt die feedback vast. Deze gegevens vormen de basis voor het dashboard ‘Analyse van afwijzingspercentage van aanvragen’. Door de meest voorkomende redenen te analyseren, kun je de oorzaken van problemen in het proces herkennen, zoals een onjuiste grootboekrekening, onvoldoende onderbouwing of budgetproblemen. Gebruik die inzichten om aanvragers beter te trainen en de kwaliteit van eerste indieningen te verbeteren, zodat er minder herstelwerk nodig is. Waarom dit belangrijk is Dit laat zien waarom aanvragen mislukken. Met oorzaakanalyse kun je herstelwerk beperken en het percentage aanvragen dat in één keer goed is verhogen. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Deze informatie staat meestal in de opmerkingen of geschiedenis bij een afwijzing. Voorbeelden Onjuiste grootboekrekeningBudget overschredenOnvoldoende onderbouwingDubbele aanvraag
	Totaalbedrag van aanvraag TotalRequisitionAmount	De totale geldwaarde van de inkoopaanvraag.
Beschrijving Dit attribuut bevat de financiële waarde van de volledige aanvraag. Het geeft belangrijke bedrijfscontext en helpt aanvragen in te delen en prioriteit te geven. Door procesmetrieken met dit bedrag te vergelijken, kun je patronen herkennen. Aanvragen met een hoge waarde volgen bijvoorbeeld mogelijk andere, strengere goedkeuringsroutes of hebben langere doorlooptijden. Dit attribuut is nodig om de financiële gevolgen van inefficiënte processen te begrijpen en aanvragen voor vergelijkende analyses in waardeklassen in te delen. Waarom dit belangrijk is Dit geeft financiële context en maakt het mogelijk te analyseren hoe de waarde van een aanvraag het proces beïnvloedt, bijvoorbeeld de goedkeuringstijd en de complexiteit van de workflow. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Dit is een standaardveld in de kopgegevens van de inkoopaanvraag. Voorbeelden 1500.0025000.5099.95
	Urgentieniveau UrgencyLevel	Een aanduiding van de prioriteit van de aanvraag, zoals ‘Normaal’, ‘Urgent’ of ‘Kritiek’.
Beschrijving Het urgentieniveau, vaak weergegeven als prioriteitsvlag, geeft aan dat de aanvraag sneller moet worden verwerkt. De aanvrager stelt dit meestal in om ervoor te zorgen dat dringende behoeften op tijd worden afgehandeld. Dit attribuut is bepalend voor het dashboard ‘Bewaking van urgente aanvragen’ en de KPI ‘Verwerkingstijd urgente aanvraag’. Je kunt de doorlooptijden van urgente en gewone aanvragen rechtstreeks vergelijken en nagaan of aanvragen met prioriteit inderdaad sneller worden afgehandeld. Door afwijkingen en vertragingen bij urgente aanvragen te analyseren, kun je de continuïteit van de bedrijfsvoering bewaken. Waarom dit belangrijk is Hiermee kun je analyses prioriteren en volgen of aanvragen met hoge prioriteit sneller worden verwerkt, zodat dringende bedrijfsbehoeften op tijd worden afgehandeld. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Dit is vaak een keuzelijst op het formulier voor het aanmaken van een aanvraag. Voorbeelden HoogGemiddeldLaag
	Bronsysteem SourceSystem	Het systeem waaruit de gegevens zijn gehaald.
Beschrijving Dit attribuut geeft aan waar de procesgegevens vandaan komen. In dit overzicht is de waarde steeds ‘SAP Ariba’. Als gegevens uit meerdere systemen worden samengevoegd, is dit veld belangrijk om de herkomst te volgen en problemen op te lossen. Bij analyses helpt het de herkomst van de data te bevestigen. Je kunt er ook processen mee filteren of vergelijken die meerdere systemen omvatten. Zo is duidelijk uit welke bron de gegevens komen, wat belangrijk is voor het vertrouwen van betrokkenen. Waarom dit belangrijk is Dit attribuut geeft de herkomst van de data aan. Dat is belangrijk voor gegevensbeheer, het oplossen van problemen en een goed begrip van de analyse. 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 SAP AribaSAP_ARIBA_P2PAribaCloud
	Inkoopordernummer PurchaseOrderId	De identificatiecode van de inkooporder die is aangemaakt op basis van de goedgekeurde aanvraag.
Beschrijving Dit attribuut koppelt een inkoopaanvraag aan het vervolgdocument: de inkooporder (PO). Als dit attribuut is ingevuld, is de aanvraag succesvol omgezet in een order. Dit is belangrijk voor end-to-end procesanalyse die verder kijkt dan alleen de aanvraagfase. Je kunt hiermee de KPI ‘Doorlooptijd van aanvraag tot PO’ berekenen door de gebeurtenis waarbij de aanvraag is aangemaakt te koppelen aan de gebeurtenis waarbij de PO is aangemaakt. Zo krijg je een volledig beeld van het begin van de inkoopcyclus. Waarom dit belangrijk is Koppelt de aanvraag aan de daaropvolgende inkooporder, zodat je de totale doorlooptijd van aanvraag tot PO kunt meten. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Dit staat meestal in de gegevens van de aanvraagregel nadat een PO is aangemaakt. Voorbeelden PO-4500012345PO-4500012346PO-4500012347
	Is geautomatiseerd IsAutomated	Een booleaanse vlag die aangeeft of een activiteit door een systeem of een menselijke gebruiker is uitgevoerd.
Beschrijving Dit attribuut maakt onderscheid tussen geautomatiseerde systeemgebeurtenissen, zoals automatische goedkeuringen of statuswijzigingen door het systeem, en handmatige activiteiten van gebruikers. Zo zie je in hoeverre het proces is geautomatiseerd. Bij analyses helpt dit om de menselijke inspanning goed te meten en kansen voor verdere automatisering te vinden. Als je bijvoorbeeld filtert op handmatige activiteiten, kun je de verwerkingstijd vanuit het perspectief van de gebruiker nauwkeurig berekenen. Ook kun je controleren of geautomatiseerde regels in het proces werken zoals verwacht. Waarom dit belangrijk is Maakt onderscheid tussen acties van mensen en systemen. Dat is belangrijk om de automatiseringsgraad te meten en nieuwe kansen voor automatisering te vinden. Waar vind je dit? Dit wordt meestal afgeleid door te controleren of de ‘Event User’ overeenkomt met een systeem- of batchgebruikers-ID. Voorbeelden truefalse
	Is gewijzigd IsAmended	Een booleaanse vlag die aangeeft of de aanvraag na de eerste indiening minstens één keer is gewijzigd.
Beschrijving Dit berekende attribuut geeft aan of een case minstens één activiteit ‘Aanvraag gewijzigd’ bevat. Zo kun je eenvoudig aanvragen markeren die tijdens hun levenscyclus zijn aangepast. Deze vlag wordt gebruikt om de KPI ‘Wijzigingspercentage van aanvragen’ te berekenen. Door het aantal cases met deze vlag op waar te tellen, kunnen analisten zien hoe vaak herstelwerk voorkomt. Door dit te vergelijken met andere attributen, zoals ‘Naam aanvrager’ of ‘Artikelcategorie’, kunnen ze de oorzaken onderzoeken. Waarom dit belangrijk is Maakt het eenvoudiger om de KPI voor het wijzigingspercentage te berekenen. Zo kun je herstelwerk meten en nagaan waar de eerste specificaties duidelijker moeten. Waar vind je dit? De waarde is waar als een case een of meer activiteiten ‘Aanvraag gewijzigd’ bevat, en anders onwaar. Voorbeelden truefalse
	Is herstelwerk IsRework	Een booleaanse vlag die aangeeft of er herstelwerk aan de aanvraag is geweest, bijvoorbeeld na een afwijzing of meerdere wijzigingen.
Beschrijving Dit berekende attribuut meet inefficiëntie breder dan ‘Is gewijzigd’. Het markeert cases met aanzienlijk herstelwerk, meestal wanneer er een of meer gebeurtenissen ‘Goedkeuringsstap afgewezen’ of meerdere gebeurtenissen ‘Aanvraag gewijzigd’ zijn. Deze vlag wordt gebruikt om de KPI ‘Herstelwerkpercentage van aanvragen’ te berekenen. Zo worden de verborgen kosten en vertragingen van procesfouten zichtbaar. Door cases met herstelwerk te analyseren, kun je patronen vinden bij bepaalde goedkeurders, afdelingen of aanvraagtypen die het proces vertragen. Waarom dit belangrijk is Markeert cases met aanzienlijke vertraging in het proces, bijvoorbeeld door afwijzingen. Zo kun je de oorzaken van inefficiëntie en vertraging gericht onderzoeken. Waar vind je dit? De waarde is waar als een case een afwijzingsactiviteit of meer dan één wijzigingsactiviteit bevat. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de gegevens voor deze registratie voor het laatst zijn bijgewerkt vanuit het bronsysteem.
Beschrijving Dit attribuut toont de datum en tijd van de meest recente data-extractie of update voor een event. Zo zie je hoe actueel de geanalyseerde data is. Dat is vooral belangrijk bij het volgen van lopende processen. Analisten gebruiken deze informatie om te bepalen hoe recent de inzichten zijn. In dashboards zoals ‘Live aanvraagstatus volgen’ laat dit veld zien hoe actueel de getoonde informatie is. Zo weten gebruikers hoe recent de data is. Waarom dit belangrijk is Dit geeft aan hoe actueel de data is, zodat je kunt beoordelen hoe recent en relevant de inzichten uit process mining zijn. Waar vind je dit? Deze timestamp wordt meestal tijdens het inlezen van de data aangemaakt en aan elke registratie toegevoegd. Voorbeelden 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Naam aanvrager RequesterName	De naam van de medewerker die de inkoopaanvraag heeft ingediend.
Beschrijving Dit attribuut op caseniveau geeft aan wie de inkoopaanvraag heeft aangemaakt. Het geeft context over de herkomst van de aanvraag en de betrokken medewerker. Bij analyses kun je dit attribuut gebruiken om het proces te filteren en gedrag per aanvrager te bekijken. Zo gebruiken de dashboards ‘Analyse van aanvraagwijzigingen’ en ‘Analyse van afwijzingspercentage van aanvragen’ dit attribuut om medewerkers op te sporen die mogelijk extra training nodig hebben vanwege veel wijzigingen of afwijzingen. Het helpt om feedback en verbeteracties af te stemmen op de betreffende medewerker. Waarom dit belangrijk is Geeft aan wie de aanvraag heeft aangemaakt. Zo kun je het procesverloop en de kwaliteit per aanvrager analyseren. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Dit is een standaardveld in de kop van de aanvraag, vaak aangeduid als ‘Gemaakt door’ of ‘Aanvrager’. Voorbeelden Alice WilliamsBob MillerCharles Brown
	Naam goedkeurder ApproverName	De naam van de gebruiker die is aangewezen om een specifieke stap in de workflow goed te keuren.
Beschrijving Dit attribuut geeft aan welke manager of belanghebbende verantwoordelijk is voor een goedkeuringsactiviteit. Het verschilt van de algemene ‘Event User’, omdat het specifiek betrekking heeft op goedkeuringstaken. Dit is een belangrijk attribuut voor het dashboard ‘Werkbelasting en prestaties van goedkeurders’. Je kunt ermee bijhouden hoeveel aanvragen elke goedkeurder behandelt en wat de gemiddelde goedkeuringstijd is. Zo kun je de bottlenecks per persoon opsporen, de werkbelasting verdelen en prestaties met doelstellingen vergelijken. Waarom dit belangrijk is Laat zien wie verantwoordelijk is voor een goedkeuring. Zo kun je de werkbelasting verdelen en de prestaties van goedkeurders analyseren. Waar vind je dit? Raadpleeg de documentatie van SAP Ariba. Deze informatie staat in de goedkeuringsgegevens die aan de aanvraag zijn gekoppeld. Voorbeelden Sarah JonesDavid ChenMaria Garcia

Verplicht Aanbevolen Optioneel

Activiteiten voor Purchase to Pay - Requisition

Dit zijn de belangrijkste processtappen en mijlpalen om vast te leggen in het event log. Zo kun je het proces nauwkeurig ontdekken en bottlenecks opsporen.

6 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Aanvraag aangemaakt	Dit markeert het moment waarop een gebruiker een inkoopaanvraagdocument aanmaakt. De gebeurtenis wordt vastgelegd wanneer de aanvraag voor het eerst wordt opgeslagen met de status ‘Composing’ of als concept.
Waarom dit belangrijk is Dit is het begin van de levenscyclus van de aanvraag. Door de tijd tussen aanmaken en indienen te analyseren, kun je de efficiëntie van gebruikers meten en bepalen waar training nodig is. Waar vind je dit? De aanmaaktimestamp van het inkoopaanvraagobject in SAP Ariba. Deze staat in de kopgegevens van het aanvraagdocument en geeft een expliciete aanmaakgebeurtenis weer. Vastleggen Gebruik de timestamp ‘CreateTime’ of een gelijkwaardige timestamp uit de kopgegevenstabel van het aanvraagdocument. Gebeurtenistype explicit
	Aanvraag afgewezen	Dit is de definitieve afwijzing van een inkoopaanvraag na beoordeling. Het is een eindstatus van het proces en wordt vastgelegd wanneer de status verandert in ‘Denied’.
Waarom dit belangrijk is Dit is een belangrijk eindpunt bij mislukking. Analyse van afgewezen aanvragen is nodig voor de KPI ‘afwijzingspercentage van aanvragen’, zodat je patronen kunt herkennen en de kwaliteit van aanvragen kunt verbeteren. Waar vind je dit? Af te leiden uit de documentgeschiedenis van Ariba, waarin de laatste statuswijziging van de aanvraag naar ‘Denied’ wordt vastgelegd. Vastleggen Bepaal wanneer het statusveld van de aanvraag verandert in ‘Denied’. Gebeurtenistype inferred
	Aanvraag gesloten	Dit is de definitieve administratieve afsluiting van een inkoopaanvraag nadat alle bijbehorende acties, zoals bestellen en ontvangen, zijn afgerond. De gebeurtenis wordt vastgelegd bij de laatste statuswijziging naar ‘Closed’.
Waarom dit belangrijk is Dit markeert het definitieve einde van de volledige levenscyclus van de aanvraag. Analyse van de tijd tussen het aanmaken van de inkooporder en de afsluiting kan bottlenecks bij de ontvangst of facturering aan het licht brengen. Waar vind je dit? Af te leiden uit de documentgeschiedenis van Ariba, waarin de statuswijziging van de aanvraag naar ‘Closed’ wordt vastgelegd. Vastleggen Bepaal wanneer het statusveld van de aanvraag verandert in ‘Closed’. Gebeurtenistype inferred
	Aanvraag goedgekeurd	Dit markeert de definitieve goedkeuring van de inkoopaanvraag nadat alle stappen in de workflow zijn doorlopen. De gebeurtenis wordt vastgelegd wanneer de status verandert in ‘Approved’.
Waarom dit belangrijk is Dit belangrijke moment markeert het einde van de goedkeuringsfase. Het is het eindpunt voor het meten van de ‘gemiddelde goedkeuringstijd van aanvragen’ en geeft aan dat de aanvraag klaar is voor het aanmaken van een inkooporder. Waar vind je dit? Af te leiden uit de documentgeschiedenis van Ariba, waarin de laatste statuswijziging van de aanvraag naar ‘Approved’ wordt vastgelegd. Vastleggen Bepaal wanneer het statusveld van de aanvraag verandert in ‘Approved’. Gebeurtenistype inferred
	Aanvraag ingediend	Dit is het formeel indienen van de inkoopaanvraag door de aanvrager, waarna deze de goedkeuringsworkflow ingaat. De gebeurtenis wordt vastgelegd wanneer de status verandert van ‘Composing’ naar ‘Submitted’.
Waarom dit belangrijk is Dit belangrijke moment start het goedkeuringsproces. Het is nodig om de ‘goedkeuringsdoorlooptijd van aanvragen’ en de ‘doorlooptijd van aanmaak tot indiening’ te meten. Waar vind je dit? Af te leiden uit de documentgeschiedenis of het auditlog van Ariba, waarin de statuswijziging naar ‘Submitted’ en de bijbehorende timestamp worden vastgelegd. Vastleggen Bepaal wanneer het statusveld van de aanvraag voor het eerst verandert in ‘Submitted’. Gebeurtenistype inferred
	Inkooporder aangemaakt	Dit markeert de succesvolle omzetting van een goedgekeurde inkoopaanvraag in een inkooporder. De gebeurtenis wordt vastgelegd wanneer een inkooporderdocument wordt aangemaakt dat naar de aanvraag verwijst.
Waarom dit belangrijk is Dit is het belangrijkste gewenste resultaat van het aanvraagproces. Het is nodig om de KPI ‘doorlooptijd van aanvraag tot inkooporder’ te meten. Waar vind je dit? Dit is een expliciete gebeurtenis. Gebruik de aanmaaktimestamp van het inkooporderdocument, dat een directe koppeling of verwijzing naar de oorspronkelijke inkoopaanvraag-ID bevat. Vastleggen Zoek in de kopgegevenstabel van de inkooporder de order die aan de aanvraag is gekoppeld en gebruik de aanmaaktimestamp. Gebeurtenistype explicit
	Aanvraag gewijzigd	Dit gebeurt wanneer een gebruiker een ingediende inkoopaanvraag wijzigt, vaak na een afwijzing of vraag. De gebeurtenis wordt vastgelegd wanneer het document wordt bewerkt en opnieuw ingediend.
Waarom dit belangrijk is Dit laat herstelwerk en inefficiënties in het proces zien. Veel wijzigingen wijzen mogelijk op onduidelijke eisen of beleidsregels en beïnvloeden de KPI ‘wijzigingspercentage van aanvragen’. Waar vind je dit? Af te leiden uit de versiegegevens in Ariba. Elke wijziging maakt een nieuwe versie van het aanvraagdocument aan. Een versienummer hoger dan 1 wijst op een wijziging. Vastleggen Controleer of er na de eerste status ‘Submitted’ nieuwe versies van de aanvraag zijn aangemaakt. De timestamp van de nieuwe versie is de eventtijd. Gebeurtenistype inferred
	Aanvraag ingetrokken	Dit gebeurt wanneer de oorspronkelijke aanvrager een ingediende inkoopaanvraag intrekt voordat deze volledig is goedgekeurd. De gebeurtenis wordt vastgelegd wanneer de status verandert in ‘Withdrawn’ of ‘Canceled’.
Waarom dit belangrijk is Dit betekent dat de gebruiker het proces beëindigt. Door te analyseren waarom aanvragen worden ingetrokken, komen mogelijk veranderende bedrijfsbehoeften of lange goedkeuringstijden aan het licht. Waar vind je dit? Af te leiden uit de documentgeschiedenis of het auditlog van Ariba, waarin de statuswijziging van de aanvraag naar ‘Withdrawn’ wordt vastgelegd. Vastleggen Bepaal wanneer het statusveld van de aanvraag verandert in ‘Withdrawn’. Gebeurtenistype inferred
	Aanvraag naar sourcing gestuurd	Dit gebeurt wanneer een goedgekeurde aanvraag naar de sourcingafdeling wordt gestuurd voor een sourcingtraject, zoals een RFQ, voordat een inkooporder kan worden aangemaakt. De gebeurtenis wordt vastgelegd bij een statuswijziging, bijvoorbeeld naar ‘Sourcing’.
Waarom dit belangrijk is Dit markeert een belangrijke vertakking in het proces voor dure of afwijkende artikelen. Zo kun je analyseren hoeveel de sourcingafdeling bijdraagt aan de doorlooptijd. Waar vind je dit? Af te leiden uit een statuswijziging van de aanvraag naar een waarde die aangeeft dat deze naar sourcing is gestuurd. Dit komt vaak voor bij Ariba Buying in combinatie met Ariba Sourcing. Vastleggen Bepaal wanneer het statusveld van de aanvraag verandert in ‘Sourcing’ of een vergelijkbare aangepaste status. Gebeurtenistype inferred
	Goedkeuringsstap afgewezen	Dit is de negatieve uitkomst van een goedkeuringsstap: een goedkeurder heeft de aanvraag afgewezen, meestal zodat deze kan worden gewijzigd. Dit wordt expliciet vastgelegd als actie ‘Deny’.
Waarom dit belangrijk is Dit wijst op een belangrijke oorzaak van herstelwerk en vertraging. Analyse van deze gebeurtenissen is belangrijk om het ‘herstelwerkpercentage van aanvragen’ en de redenen voor afwijzing te begrijpen. Waar vind je dit? Haal de gegevens uit de tabellen met goedkeuringsstromen van Ariba. De actie wordt met een timestamp vastgelegd wanneer een goedkeurder ‘Deny’ of ‘Reject’ kiest voor de toegewezen taak. Vastleggen Gebruik de timestamp van de actie ‘Deny’ in de goedkeuringsgeschiedenis van de betreffende stap. Gebeurtenistype explicit
	Goedkeuringsstap gestart	Dit geeft aan dat een inkoopaanvraag naar een goedkeurder of goedkeuringswachtrij is gestuurd en op actie wacht. De gebeurtenis wordt vastgelegd wanneer een goedkeuringsverzoek wordt aangemaakt en toegewezen.
Waarom dit belangrijk is Dit geeft gedetailleerd inzicht in de goedkeuringsworkflow. De gegevens zijn nodig om wachttijden te berekenen en te bepalen welke stappen bottlenecks vormen voor de ‘bottleneckanalyse van goedkeuringsroutes’. Waar vind je dit? Haal de gegevens uit de tabellen met goedkeuringsstromen van Ariba. Daarin worden het aanmaken en toewijzen van afzonderlijke goedkeuringstaken voor de aanvraag vastgelegd. Vastleggen Gebruik de aanmaaktimestamp van het goedkeuringsverzoek dat bij de aanvraag en de specifieke goedkeuringsstap hoort. Gebeurtenistype explicit
	Goedkeuringsstap goedgekeurd	Dit is de positieve uitkomst van een goedkeuringsstap: een goedkeurder heeft het toegewezen deel van de aanvraag goedgekeurd. Dit wordt expliciet vastgelegd als goedkeuringsactie.
Waarom dit belangrijk is Dit meet de verwerkingstijd van afzonderlijke goedkeurders. De gegevens zijn nodig om de ‘gemiddelde duur van een goedkeuringsstap’ te berekenen en de werkbelasting van goedkeurders te beoordelen. Waar vind je dit? Haal de gegevens uit de tabellen met goedkeuringsstromen van Ariba. De actie wordt met een timestamp vastgelegd wanneer een goedkeurder ‘Approve’ kiest voor de toegewezen taak. Vastleggen Gebruik de timestamp van de actie ‘Approve’ in de goedkeuringsgeschiedenis van de betreffende stap. Gebeurtenistype explicit
	Regel van aanvraag besteld	Dit geeft aan dat de status van een afzonderlijke aanvraagregel verandert in ‘Ordered’ nadat de regel op een inkooporder is geplaatst. Zo kun je gedetailleerder volgen dan met alleen het aanmaken van een inkooporder op kopniveau.
Waarom dit belangrijk is Hiermee kun je gedeeltelijke bestellingen en vertragingen per aanvraagregel analyseren. Die zijn niet zichtbaar als je alleen naar de kopgegevens kijkt. Dit is handig bij aanvragen met veel regels die via verschillende inkooporders worden afgehandeld. Waar vind je dit? Af te leiden uit de statuswijziging van het aanvraagregelobject. De status van de regel wordt bijgewerkt naar ‘Ordered’ zodra er een inkooporder voor is aangemaakt. Vastleggen Bepaal wanneer het statusveld van de aanvraagregel verandert in ‘Ordered’. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit SAP Ariba

Stappen

Meld je aan bij SAP Ariba: Open je SAP Ariba-omgeving met een gebruikersaccount dat rapporten mag aanmaken en uitvoeren, bijvoorbeeld met de rol ‘Reporting Analyst’.
Ga naar Analytical Reporting: Open vanuit het hoofddashboard het gedeelte voor rapportages. Dit staat meestal onder een menu als ‘Reporting’, ‘Analytics’ of ‘Manage’ > ‘Analytical Reports’.
Maak een rapport aan: Start het aanmaken van een nieuw analytisch rapport. Je wordt gevraagd het primaire gegevensgebied te kiezen, vaak aangeduid als een ‘Fact’. Kies het gegevenstype voor aanvragen, bijvoorbeeld ‘[Requisition]’ of een vergelijkbare naam uit je Ariba-configuratie.
Voeg datavelden toe: Voeg in de rapportbuilder kolommen aan het rapport toe. Je moet meerdere gegevensbronnen (Facts) combineren om alle benodigde informatie op te halen. Een gebruikelijk rapport combineert ‘[Requisition Fact]’ met ‘[Approval History Fact]’ en ‘[Purchase Order Fact]’, met de Requisition ID als sleutel. Voeg alle velden uit de queryconfiguratie toe, waaronder relevante timestamps zoals Created Date, Submitted Date, Approved Date en Action Date uit de goedkeuringsgeschiedenis.
Stel filters in: Beperk de data met filters. Het belangrijkste filter is de datumbereikfilter. Filter op ‘Requisition Created Date’ voor de gewenste periode, bijvoorbeeld de afgelopen 3 tot 6 maanden. Voeg zo nodig andere filters toe, bijvoorbeeld voor specifieke Company Codes of Realms.
Voer het rapport uit en exporteer de ruwe data: Voer het rapport uit. Exporteer de resultaten na afloop naar een CSV- of Excel-bestand. Deze eerste export heeft een ‘breed’ formaat, met één rij per aanvraag of goedkeuringsvermelding en meerdere kolommen voor datums en gebruikersacties.
Zet de data om naar het formaat van een event log: Dit is een belangrijke stap buiten SAP Ariba. Gebruik bijvoorbeeld Microsoft Excel met Power Query, een Python-script of een andere tool voor datavoorbereiding om de brede data om te zetten naar een lang formaat. Maak voor elke geëxporteerde timestampkolom, zoals ‘Created Date’, ‘Submitted Date’ en ‘Approved Date’, een aparte rij in het uiteindelijke event log. Dit proces heet vaak ‘unpivoting’ of ‘melting’.
Koppel activiteiten en attributen: Maak tijdens de omzetting de kolommen ActivityName en EventTimestamp aan. Wanneer je bijvoorbeeld de kolom ‘Submitted Date’ verwerkt, maak je rijen met ‘Requisition Submitted’ in ActivityName en de waarde uit ‘Submitted Date’ in EventTimestamp.
Voeg de data samen en maak deze schoon: Combineer de omgezette data uit alle timestampkolommen in één bestand. Controleer of PurchaseRequisitionId, ActivityName en EventTimestamp voor elke rij correct zijn ingevuld. Verwijder lege rijen en herstel eventuele opmaakproblemen.
Sla het bestand op als definitieve CSV: Sla het uiteindelijke event log op als CSV-bestand met UTF-8-codering. Het bestand is nu klaar om naar de process mining-tool te uploaden.

Configuratie

Rapporttype: Analytisch rapport via de standaardrapportage-interface van Ariba.
Belangrijkste gegevensbronnen: Combineer data uit meerdere facts, meestal ‘[Requisition Fact]’, ‘[Approval History Fact]’ en ‘[Purchase Order Fact]’. De exacte namen kunnen verschillen per Ariba-datamodel.
Datumbereik: Filter bij voorkeur op ‘Requisition Created Date’ en kies een beheersbare periode, bijvoorbeeld 3 tot 6 maanden. Gebruik voor een eerste test een kortere periode, zoals één week.
Belangrijke filters: Filter altijd op een specifiek datumbereik. Overweeg ook te filteren op ‘Company Code’ of ‘Purchasing Organization’ om de dataset te beperken tot de relevante bedrijfsactiviteiten en het rapport sneller uit te voeren.
Vereisten: De gebruiker die het rapport uitvoert, moet een rol hebben met toegang tot de module Analytical Reporting en de onderliggende gegevensbronnen voor aanvragen, goedkeuringen en inkooporders.

Voorbeeldquery config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

Stappen

Python-omgeving instellen: Zorg dat Python 3.6 of nieuwer is geïnstalleerd. Installeer de benodigde bibliotheken met pip: pip install requests pandas.
API-toegang instellen: Registreer een nieuwe applicatie in het SAP Ariba Developer Portal. Schrijf je in voor de 'Operational Reporting API for Requisitions' en haal je OAuth-inloggegevens op: Application Key (API Key), OAuth Client Secret en de Base64-gecodeerde tekenreeks [your_api_key]:[your_client_secret].
Python-script aanpassen: Open het meegeleverde Python-script. Vul bovenaan de tijdelijke variabelen in, waaronder ARIBA_REALM, BASE_URL, API_KEY en BASE64_CREDS. Stel ook START_DATE en END_DATE in voor de periode waaruit je data wilt ophalen.
Rapportpayload definiëren: Bekijk het JSON-object report_payload in het script. Hiermee bepaal je welk rapport wordt uitgevoerd. Het script is ingesteld op RequisitionFactSystemView en selecteert velden voor de benodigde activiteiten en attributen. Voeg zo nodig velden of filters toe.
Script uitvoeren: Voer het script vanuit je terminal uit met python your_script_name.py. Het script meldt zich eerst aan bij Ariba om een toegangstoken op te halen.
Rapporttaak indienen en volgen: Het script stuurt het rapportverzoek automatisch naar de Ariba API. Omdat de taak asynchroon wordt uitgevoerd, controleert het script elke 60 seconden de status via de Ariba API.
Rapportdata downloaden: Zodra de Ariba API de taak als 'COMPLETED' meldt, downloadt het script de resultaten. Dit is meestal een ZIP-bestand met één CSV-bestand.
Data verwerken en transformeren: Het script pakt het bestand uit en laadt de ruwe data in een pandas DataFrame. Daarna zet het de data om van een breed formaat (één rij per aanvraag met veel datumkolommen) naar een lang event-logformaat (meerdere rijen per aanvraag, één voor elke activiteit).
Event log maken: Het getransformeerde DataFrame heeft nu de structuur van een event log, met kolommen zoals PurchaseRequisitionId, ActivityName en EventTimestamp. Het wordt opgeslagen als ariba_requisition_event_log.csv in dezelfde map als het script.
Klaarzetten voor upload: Het CSV-bestand is klaar om te uploaden naar ProcessMind. Controleer of de kolomkoppen overeenkomen met de mapping in je ProcessMind-project.

Configuratie

API-eindpunt-URL: Het script heeft de basis-URL nodig van de API van je Ariba-instantie. Deze heeft meestal de vorm https://[your-realm].api.ariba.com/api/operationalreporting/v2/. Vervang [your-realm] door de specifieke Ariba-realmnaam van je bedrijf.
Authenticatie: Voor de data-extractie wordt OAuth 2.0 gebruikt. Je moet een geldige apiKey, clientSecret en base64EncodedCredentials opgeven. Deze gegevens haal je op uit de applicatie die je in het Ariba Developer Portal hebt geregistreerd.
View-template: Het script gebruikt RequisitionFactSystemView. Dit is een standaardview van Ariba. Controleer wel of deze in je omgeving is ingeschakeld en of je API-gebruiker toegang heeft.
Filter op datumbereik: Het filter creationDate in de rapportinhoud bepaalt hoeveel data wordt opgehaald. Voor de eerste extractie wordt een periode van 3 tot 6 maanden aanbevolen. Bij grote organisaties kun je de data beter in kleinere maandelijkse batches ophalen.
Incrementeel laden: Pas voor volgende extracties START_DATE en END_DATE aan, zodat alleen nieuwe of bijgewerkte records worden opgehaald. Het script regelt incrementele extracties niet automatisch. Je moet het datumbereik dus bij elke uitvoering handmatig instellen.
Vereisten: Je hebt een SAP Ariba-gebruikersaccount met de machtiging ‘Developer Portal Access’ nodig om de applicatie en inloggegevens aan te maken. De API-applicatie zelf heeft de rol ‘Operational Reporting API User’ nodig om rapporttaken uit te voeren.

Voorbeeldquery python

import requests
import json
import pandas as pd
import time
import zipfile
import io

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

if __name__ == class="hl-string">"__main__":
    main()

Klaar om te beginnen?

Gebruik deze template om de data efficiënter voor te bereiden en meer inzicht te krijgen in het Purchase to Pay - Requisition-proces. Begin vandaag nog met het verbeteren van je processen.

Terug naar de verbetergids

Template downloaden

Voorkom vertraging: verbeter het aanvraagproces van Purchase to Pay

Spoor inefficiënties in SAP Ariba op en verkort de doorlooptijd met 30%.

Start je gratis proefperiode

Geen creditcard nodig. Je kunt snel en eenvoudig aan de slag.

Datatemplate voor Purchase to Pay - Requisition

Datatemplate voor Purchase to Pay - Requisition

Attributen voor Purchase to Pay - Requisition

Activiteiten voor Purchase to Pay - Requisition

Extractiegidsen

CSV-/Excel-export van analytische rapporten in SAP Ariba

Stappen

Configuratie

Voorbeeldquery config

Data-extractie met een Python-script via de Operational Reporting API

Stappen

Configuratie

Voorbeeldquery python

Klaar om te beginnen?

Voorkom vertraging: verbeter het aanvraagproces van Purchase to Pay