Datatemplate voor inkoop-tot-betaling, aanvraag
Datatemplate voor inkoop-tot-betaling, aanvraag
- Aanbevolen attributen voor een gedetailleerde analyse
- Belangrijke activiteiten om vast te leggen voor procesontdekking
- Instructies voor data-extractie uit SAP S/4HANA
Attributen voor inkoop-tot-betaling, aanvraag
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit die op een bepaald moment in het aanvraagproces plaatsvond. | ||
| Beschrijving De activiteitsnaam beschrijft een gebeurtenis of taak binnen de levenscyclus van een inkoopaanvraag. De activiteiten zijn afgeleid uit systeemlogboeken, zoals wijzigingsdocumenten en workflowgeschiedenis. Ze markeren belangrijke procesmomenten, zoals 'Inkoopaanvraag aangemaakt', 'Goedkeuringsstap gestart' of 'Inkooporder aangemaakt'. Door deze activiteiten te analyseren, kun je de processtroom visualiseren, bottlenecks opsporen en meten hoeveel tijd verschillende fasen kosten. Inzicht in de volgorde en frequentie van activiteiten zoals 'Inkoopaanvraag gewijzigd' of 'Inkoopaanvraag afgewezen' helpt om inefficiënties en verbeterkansen te vinden. Waarom dit belangrijk is Dit attribuut beschrijft de processtappen en vormt de basis van de proceskaart. Zo kun je de processtroom, variaties en bottlenecks analyseren. Waar vind je dit? Dit is een afgeleid attribuut, dat doorgaans wordt samengesteld door gegevens uit wijzigingsdocumenttabellen (CDHDR, CDPOS) en workflowlogboeken (bijvoorbeeld SWWLOGHIST) te interpreteren. Voorbeelden Inkoopaanvraag aangemaaktGoedkeuringsstap afgerondInkoopaanvraag goedgekeurdInkooporder aangemaakt | |||
| ID van inkoopaanvraag PurchaseRequisitionId | De unieke identificatiecode van een document voor een inkoopaanvraag. | ||
| Beschrijving Het ID van de inkoopaanvraag is de primaire sleutel waarmee elke aanvraag voor goederen of diensten in SAP S/4HANA uniek wordt geïdentificeerd. Dit is de centrale case-ID die alle activiteiten en wijzigingen voor een specifieke aanvraag koppelt, vanaf het aanmaken tot de eindstatus, zoals goedkeuring, afwijzing of omzetting naar een inkooporder. Bij process mining is dit attribuut essentieel om de volledige levenscyclus van elke aanvraag te reconstrueren. Door alle bijbehorende gebeurtenissen onder één ID van de inkoopaanvraag te groeperen, kunnen analisten doorlooptijden nauwkeurig meten, statuswijzigingen volgen en de verschillende routes door het goedkeuringsproces analyseren. Waarom dit belangrijk is Dit is de belangrijkste case-ID die alle bijbehorende processtappen met elkaar verbindt. Zo ontstaat een volledig en samenhangend beeld van de levenscyclus van de aanvraag. Waar vind je dit? Dit attribuut is het nummer van de inkoopaanvraag, te vinden in de tabel EBAN, veld BANFN. Voorbeelden 100178901001789110017892 | |||
| Tijdstip van gebeurtenis EventTime | De exacte datum en tijd waarop een specifieke activiteit plaatsvond. | ||
| Beschrijving Het tijdstip van de gebeurtenis is de timestamp waarop een activiteit plaatsvond. Deze data is nodig om gebeurtenissen binnen een case chronologisch te ordenen en vormt de basis voor alle berekeningen van duur en prestaties bij process mining. Zo bepaalt het tijdsverschil tussen de gebeurtenissen 'Inkoopaanvraag ingediend' en 'Inkoopaanvraag goedgekeurd' de doorlooptijd van de goedkeuring. Nauwkeurige timestamps zijn nodig om procesprestaties te analyseren, vertragingen op te sporen en naleving van service level agreements te volgen. Met dit attribuut kun je dashboards maken die doorlooptijden tonen, vastgelopen aanvragen signaleren en prestaties over verschillende perioden vergelijken. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen te ordenen, doorlooptijden te berekenen en procesprestaties en bottlenecks te analyseren. Waar vind je dit? Timestamps komen doorgaans uit de kopregels van wijzigingsdocumenten (CDHDR-UDATE, CDHDR-UTIME) of uit workflowlogboeken. Voorbeelden 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Afdeling Department | De afdeling of het kostenplaatsnummer waaraan de kosten van de aanvraag worden toegerekend. | ||
| Beschrijving Het attribuut Afdeling, in SAP vaak weergegeven als kostenplaats, identificeert de bedrijfseenheid die verantwoordelijk is voor de aangevraagde aankoop. Dit is belangrijke financiële en organisatorische informatie op regelniveau van een aanvraag. Bij process mining is dit attribuut nodig om prestaties per afdeling te analyseren. Dashboards kunnen belangrijke metrieken, zoals doorlooptijd, wijzigingspercentage en afwijzingspercentage, per afdeling vergelijken. Zo zie je welke werkwijzen van goed presterende afdelingen elders bruikbaar zijn en waar extra training of procesondersteuning nodig is. Waarom dit belangrijk is Maakt het mogelijk prestaties tussen bedrijfseenheden te vergelijken. Verschillen in doorlooptijden of afwijzingspercentages laten zien waar goede werkwijzen bestaan en waar verbetering nodig is. Waar vind je dit? Dit is de kostenplaats, doorgaans te vinden in de rekeningtoewijzingstabel EBKN, veld KOSTL. Voorbeelden FIN-1001IT-2005MKT-3010 | |||
| Bedrag van inkoopaanvraag RequisitionAmount | De totale geldwaarde van de inkoopaanvraag. | ||
| Beschrijving Het bedrag van de inkoopaanvraag is de totale geschatte kostenpost voor de aangevraagde goederen of diensten. Dit bedrag bepaalt vaak hoe ingewikkeld en lang de goedkeuringsworkflow is. Voor aanvragen met een hoger bedrag zijn doorgaans meer goedkeuringsniveaus nodig. Met dit attribuut kun je het proces indelen op basis van bedrag. Zo kun je bijvoorbeeld nagaan of aanvragen met een hoge waarde langer op goedkeuring wachten of wat de waarde is van aanvragen die vaak worden afgewezen. Dit is een belangrijke dimensie om de financiële gevolgen van procesinefficiënties te begrijpen. Waarom dit belangrijk is Helpt het proces in te delen naar financiële impact, die vaak samenhangt met de complexiteit van goedkeuringen en de doorlooptijd. Belangrijk voor procesanalyses op basis van waarde. Waar vind je dit? De totale waarde staat in de tabel EBAN, veld GFWERT. De waarde per regel staat in EBAN-PREIS. Voorbeelden 1500.0075000.50250.75 | |||
| Gebruikers-ID UserId | De identificatiecode van de gebruiker die de aanvraag heeft aangemaakt of een specifieke activiteit heeft uitgevoerd. | ||
| Beschrijving De gebruikers-ID identificeert de medewerker of systeemgebruiker die verantwoordelijk is voor een gebeurtenis in de levenscyclus van de aanvraag. Dit kan de persoon zijn die de aanvraag heeft aangemaakt, de manager die deze heeft goedgekeurd of de medewerker die de aanvraag heeft gewijzigd. Bij geautomatiseerde stappen kan het om een systeem- of batchgebruikers-ID gaan. Met analyses op basis van gebruikers-ID krijg je inzicht in gedrag per gebruiker, de verdeling van de werkdruk en prestaties. Dit helpt bij het vaststellen van trainingsbehoeften, het herkennen van goed presterende medewerkers en het toewijzen van verantwoordelijkheid binnen het proces. In combinatie met stamgegevens van gebruikers kun je ook prestaties per afdeling analyseren. Waarom dit belangrijk is Maakt analyses mogelijk van gebruikersprestaties, werkverdeling en naleving van processen. Helpt bij het vaststellen van trainingsbehoeften en bottlenecks in de inzet van medewerkers. Waar vind je dit? Voor de aanmaker staat dit in EBAN-ERNAM. Bij latere wijzigingen vind je de ID in CDHDR-USERNAME. Voor goedkeuringen staan de gegevens in workflowlogboeken. Voorbeelden JSMITHRROEWF-BATCH | |||
| ID van goedkeurder ApproverId | De identificatiecode van de gebruiker die een goedkeurings- of afwijzingsstap heeft uitgevoerd. | ||
| Beschrijving De ID van de goedkeurder identificeert specifiek de gebruiker die een aanvraag heeft goedgekeurd of afgewezen. Dit verschilt van de algemene gebruikers-ID, omdat het alleen gaat om de besluitvormers in de goedkeuringsworkflow. Deze informatie is nodig om het goedkeuringsproces in detail te analyseren. Met dit attribuut kun je goedkeuringsgedrag analyseren, bijvoorbeeld welke managers lang over goedkeuringen doen of aanvragen vaak afwijzen. Het is een belangrijke basis voor dashboards over de doorlooptijd per goedkeuringsstap en bottlenecks in de workflow. Zo kun je achterhalen welke personen of rollen vertraging veroorzaken. Waarom dit belangrijk is Laat zien wie de beslissing neemt bij een goedkeuringsstap. Zo kun je doorlooptijden en bottlenecks per persoon of rol analyseren. Waar vind je dit? Deze informatie komt doorgaans uit SAP Business Workflow-tabellen zoals SWW_WI2OBJ en SWWLOGHIST, die werkitems koppelen aan de gebruiker die ze heeft afgerond. Voorbeelden MJOHNSONCWILLIAMSLBLACK | |||
| Status van inkoopaanvraag RequisitionStatus | De huidige verwerkings- of goedkeuringsstatus van de inkoopaanvraag. | ||
| Beschrijving De status van de inkoopaanvraag geeft de huidige fase in de levenscyclus aan. In SAP wordt deze vaak weergegeven met de vrijgave-indicator, die laat zien of een aanvraag geblokkeerd is, op goedkeuring wacht, gedeeltelijk is goedgekeurd of volledig is goedgekeurd. De status verandert wanneer de aanvraag de workflow doorloopt. Door de status in de tijd te volgen, krijg je inzicht in de processtroom. Je ziet waar aanvragen vastlopen en hoelang dat duurt. Een analyse van statusovergangen geeft een gedetailleerd beeld van het goedkeuringsproces en de verschillende varianten. Waarom dit belangrijk is Geeft de huidige status van een aanvraag aan. Dit is belangrijk om de voortgang te volgen, bottlenecks op te sporen en de processtroom te analyseren. Waar vind je dit? De vrijgavestatus wordt vaak bepaald door de vrijgave-indicator in de tabel EBAN, veld FRGZU. Voorbeelden B1S | |||
| Type inkoopaanvraag RequisitionType | Een code waarmee de inkoopaanvraag wordt ingedeeld, bijvoorbeeld voor standaardartikelen, diensten of investeringsuitgaven. | ||
| Beschrijving Het type inkoopaanvraag, in SAP ook documenttype genoemd, is een belangrijk configuratieveld waarmee inkoopaanvragen worden ingedeeld. Verschillende typen kunnen andere goedkeuringsworkflows starten, andere veldinstellingen hebben en voor verschillende zakelijke doeleinden worden gebruikt, zoals standaardvoorraadartikelen, externe diensten of aankopen van bedrijfsmiddelen. Door het proces per type inkoopaanvraag te analyseren, zie je hoe verschillende soorten aanvragen worden afgehandeld. Je kunt prestaties, doorlooptijden en goedkeuringsroutes per categorie vergelijken. Zo wordt duidelijk of bepaalde typen aanvragen efficiënter verlopen en waar procesverbeteringen nodig zijn. Waarom dit belangrijk is Deelt aanvragen in categorieën in voor vergelijkende analyses. Zo zie je of verschillende typen aanvragen andere processtromen, bottlenecks of doorlooptijden hebben. Waar vind je dit? Dit is het veld Document Type in de tabel EBAN, veld BSART. Voorbeelden NBFORV | |||
| Automatisch uitgevoerd IsAutomated | Een indicator die aangeeft of een activiteit is uitgevoerd door een systeemgebruiker in plaats van een persoon. | ||
| Beschrijving Het attribuut Is Automated is een booleaanse vlag die op true staat als een activiteit is uitgevoerd door een systeem- of batchgebruiker, zoals 'WF-BATCH' bij workflowacties. Zo kun je handmatige en geautomatiseerde processtappen van elkaar onderscheiden. Dit attribuut is essentieel om de automatiseringsgraad van het aanvraagproces te meten en de KPI 'Automated Approval Rate' te berekenen. Door te filteren op geautomatiseerde of handmatige stappen kunnen analisten de efficiëntie vergelijken en mogelijkheden voor verdere automatisering vinden. Zo kunnen de doorlooptijden en de benodigde handmatige inspanning omlaag. Waarom dit belangrijk is Maakt onderscheid tussen activiteiten van medewerkers en activiteiten die door systemen worden uitgevoerd. Dat is belangrijk om de automatiseringsgraad te meten en mogelijkheden te vinden om handmatige taken te automatiseren. Waar vind je dit? Dit is een afgeleid attribuut, meestal gebaseerd op een regel die controleert of de User ID van een event voorkomt in een lijst met bekende systeem- of batchgebruikers. Voorbeelden truefalse | |||
| Bronsysteem SourceSystem | Identificeert de specifieke SAP S/4HANA-instantie waaruit de data is opgehaald. | ||
| Beschrijving Het attribuut Bronsysteem geeft aan uit welk systeem de procesdata afkomstig is. Organisaties kunnen meerdere SAP-instanties hebben, bijvoorbeeld voor ontwikkeling, kwaliteitscontrole en productie, of voor verschillende regio’s. Dit veld is belangrijk voor gegevensbeheer en de juiste context. Het maakt onderscheid tussen data uit verschillende bronnen. Zo voorkom je dat gegevens onterecht worden samengevoegd en kun je systemen afzonderlijk analyseren. Dit verplichte attribuut houdt de herkomst van de data bij en maakt de procesdata traceerbaar. Waarom dit belangrijk is Geeft inzicht in de herkomst en het beheer van data, vooral in omgevingen met meerdere systemen, en zorgt ervoor dat data traceerbaar blijft. Waar vind je dit? Dit is doorgaans de SAP System ID (SID), die je kunt ophalen uit systeemvariabelen of configuratietabellen. Voorbeelden S4PECCS4H_PROD_01 | |||
| Eindtijd EndTime | De exacte datum en tijd waarop een activiteit is afgerond. | ||
| Beschrijving EndTime is de timestamp die vastlegt wanneer een activiteit is afgerond. Veel systeemgebeurtenissen vinden direct plaats, waardoor StartTime en EndTime gelijk zijn. Bij handmatige taken, zoals goedkeuringen, kunnen de start- en eindtijd verschillen. Deze timestamp markeert het moment waarop het werk klaar is. Met een aparte EndTime kun je de actieve verwerkingstijd nauwkeuriger meten, los van de wachttijd. Samen met StartTime wordt deze gebruikt om de metriek ProcessingTime te berekenen. Dit detail maakt het eenvoudiger om het gebruik van middelen en de efficiëntie van handmatige taken te analyseren. Waarom dit belangrijk is Markeert wanneer een activiteit is afgerond. Zo kun je de actieve verwerkingstijd berekenen en de duur van een taak nauwkeuriger analyseren. Waar vind je dit? Dit is afgeleid van workflowlogs waarin mogelijk zowel het aanmaken van een werkitem (StartTime) als de afronding ervan (EndTime) wordt vastgelegd. Voorbeelden 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Gewenste leverdatum RequiredByDate | De datum waarop de aanvrager de goederen of diensten nodig heeft. | ||
| Beschrijving De gewenste leverdatum, in SAP de leverdatum genoemd, geeft aan wanneer de goederen of diensten van de aanvraagregel nodig zijn. De aanvrager stelt deze datum in. De datum is het streefdoel voor het volledige inkoopproces. Dit attribuut is nodig om de KPI 'Percentage inkoopaanvragen op tijd afgerond' te berekenen. Door de gewenste leverdatum te vergelijken met de datum van de definitieve goedkeuring of het aanmaken van de inkooporder, kan de organisatie meten of interne serviceniveaus en zakelijke behoeften worden gehaald. Aanvragen die deze datum niet halen, kunnen structurele vertragingen in het inkoopproces aan het licht brengen. Waarom dit belangrijk is Bepaalt de streefdatum voor het afronden van een aanvraag. Zo kun je tijdige levering en naleving van interne serviceniveaus meten. Waar vind je dit? Dit is de leverdatum op regelniveau in de tabel EBAN, veld LFDAT. Voorbeelden 2023-11-152023-12-012024-01-20 | |||
| Inkoopordernummer PurchaseOrderNumber | Het nummer van de inkooporder die vanuit de aanvraag is aangemaakt. | ||
| Beschrijving Het inkoopordernummer identificeert het officiële inkoopdocument dat is aangemaakt vanuit een goedgekeurde aanvraag. Het aanmaken van een inkooporder is vaak het succesvolle eindresultaat van een aanvraag: de aanvraag is omgezet in een officiële bestelling bij een leverancier. Met dit attribuut kun je de KPI voor de doorlooptijd van inkoopaanvraag tot inkooporder en het totale omzettingspercentage meten. Het koppelt het aanvraagproces aan het daaropvolgende inkoopproces en geeft zo een breder, end-to-endbeeld van de volledige Purchase-to-Pay-cyclus. Waarom dit belangrijk is Koppelt de aanvraag aan het daaropvolgende inkoopdocument. Zo kun je het omzettingspercentage en de doorlooptijd van aanvraag naar inkooporder meten. Waar vind je dit? Te vinden in de tabel EBAN, veld EBELN, zodra er vanuit de aanvraagregel een inkooporder is aangemaakt. Voorbeelden 450001789045000178914500017892 | |||
| Is herstelwerk IsRework | Een vlag die aangeeft of een activiteit herstelwerk is, zoals een wijziging nadat de aanvraag is ingediend. | ||
| Beschrijving Is Rework is een berekende booleaanse vlag die activiteiten markeert die geen waarde toevoegen of werk herhalen. Een voorbeeld in dit proces is de activiteit 'Requisition Amended' nadat de aanvraag al ter goedkeuring is ingediend. Hierdoor moet het goedkeuringsproces opnieuw beginnen. Met dit attribuut kun je de hoeveelheid herstelwerk in het proces meten en het effect ervan op de totale doorlooptijden bepalen. Het dashboard Requisition Amendment and Rework Rate gebruikt deze vlag om inefficiënties in het proces zichtbaar te maken. Herstelwerk verminderen is vaak een belangrijk doel bij procesverbetering, omdat je daarmee tijd en moeite bespaart. Waarom dit belangrijk is Markeert activiteiten die tijd verspillen of werk herhalen. Zo kun je herstelwerk en het effect ervan op de procesefficiëntie meten. Waar vind je dit? Dit is een berekend attribuut. De logica markeert doorgaans elke activiteit 'Requisition Amended' na de eerste activiteit 'Requisition Submitted For Approval' als herstelwerk. Voorbeelden truefalse | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor deze registratie voor het laatst is vernieuwd vanuit het bronsysteem. | ||
| Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update vanuit het bronsysteem. Deze metadata laat zien hoe actueel de geanalyseerde data is. Analisten en zakelijke gebruikers kunnen aan de timestamp zien of de procesdata de meest recente stand van zaken in de bedrijfsvoering weergeeft. Bij procesanalyse is het belangrijk te weten hoe actueel de data is, zodat je goed onderbouwde beslissingen kunt nemen. Dit attribuut helpt verwachtingen te beheren en zorgt ervoor dat conclusies zijn gebaseerd op data die actueel genoeg is voor de analyse. Waarom dit belangrijk is Geeft aan hoe actueel de data is. Dat is belangrijk om de analyse te kunnen beoordelen en tijdig zakelijke beslissingen te nemen. Waar vind je dit? Deze timestamp wordt aangemaakt en toegevoegd tijdens het proces van data-extractie, transformatie en laden (ETL). Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Naam goedkeuringsstap ApprovalStepName | De specifieke naam of beschrijving van een goedkeuringsstap in de workflow. | ||
| Beschrijving De naam van de goedkeuringsstap geeft een begrijpelijke beschrijving van een fase in de goedkeuringsworkflow, zoals 'Goedkeuring door manager' of 'Goedkeuring door financieel directeur'. Dit is duidelijker dan een algemene activiteit als 'Approval Step Completed'. Dit attribuut is essentieel voor de dashboards Approval Step Cycle Time en Bottleneck Analysis van de workflow. Het geeft een gedetailleerd beeld van het goedkeuringsproces. Zo zie je precies welke goedkeuringsstappen de meeste vertraging veroorzaken en waar het werk zich ophoopt. Die informatie is nodig om gericht in te grijpen en de goedkeuringsketen te verbeteren. Waarom dit belangrijk is Geeft gedetailleerd inzicht in de goedkeuringsstappen, zodat je bottlenecks in de goedkeuringsworkflow met meerdere niveaus precies kunt aanwijzen. Waar vind je dit? Deze informatie is afgeleid van de beschrijving van de workflowtaak. Je kunt die vinden door het workflowlog te koppelen aan taakdefinitietabellen zoals T528T. Voorbeelden Goedkeuring door managerGoedkeuring door directeurGoedkeuring door financieel directeur | |||
| Reden van afwijzing RejectionReason | De reden die wordt opgegeven wanneer een inkoopaanvraag wordt afgewezen. | ||
| Beschrijving De reden van afwijzing legt uit waarom een goedkeurder een inkoopaanvraag heeft afgewezen. Mogelijke redenen zijn een overschrijding van het budget, onjuiste informatie, niet-naleving van beleid of een dubbele aanvraag. Deze informatie geeft belangrijke context bij problemen in het proces. Door afwijzingsredenen te analyseren, kun je de oorzaken van inefficiënties en herstelwerk opsporen. Als 'Onjuiste kostenplaats' bijvoorbeeld vaak voorkomt, kan dat wijzen op behoefte aan betere gebruikerstraining of controles in het systeem. Dit attribuut vormt de basis voor het dashboard voor analyse van afgewezen inkoopaanvragen en helpt verbeteringen gericht aan te pakken. Waarom dit belangrijk is Laat de oorzaken van problemen in het proces zien. Zo kun je gericht verbeteringen doorvoeren, herstelwerk beperken en het percentage aanvragen dat in één keer goed is verhogen. Waar vind je dit? Dit is vaak geen standaardveld. De reden kan zijn vastgelegd in workflow-containerelementen, lange tekst bij de aanvraag of aangepaste velden. Voorbeelden Budget overschredenOnjuiste leverancierDubbele aanvraag | |||
| Urgentieniveau UrgencyLevel | Een indeling van de urgentie van de aanvraag, die invloed kan hebben op de verwerkingsprioriteit. | ||
| Beschrijving Het urgentieniveau geeft de prioriteit van de inkoopaanvraag aan. Er is geen standaardveld voor dit gegeven, maar sommige organisaties gebruiken bijvoorbeeld het veld Requirement Tracking Number. Aanvragers kunnen hiermee aangeven dat een aanvraag kritisch is en met voorrang moet worden verwerkt. Door het effect van urgentie te analyseren, kun je beoordelen of het proces kritieke aanvragen inderdaad voorrang geeft. Het dashboard Urgency Level Impact Analysis gebruikt dit attribuut om doorlooptijden en goedkeuringspercentages van urgente en standaardaanvragen te vergelijken. Zo zie je of de prioriteitsbehandeling werkt zoals bedoeld. Waarom dit belangrijk is Maakt het mogelijk om de prestaties van het proces bij aanvragen met hoge prioriteit te analyseren en te controleren of urgente aanvragen echt sneller worden afgehandeld. Waar vind je dit? Er is geen standaardveld voor urgentie. Sommige bedrijven gebruiken hiervoor Requirement Tracking Number (EBAN-BEDAR). Het kan ook om een aangepast veld gaan. Voorbeelden HoogGemiddeldLaag | |||
| Valuta Currency | De valutacode voor het bedrag van de inkoopaanvraag. | ||
| Beschrijving Dit attribuut geeft aan in welke valuta het bedrag van de aanvraag is uitgedrukt, bijvoorbeeld USD, EUR of JPY. Het biedt de nodige context bij het attribuut Bedrag van inkoopaanvraag, vooral voor internationale organisaties die met meerdere valuta werken. Voor nauwkeurige financiële analyses en rapportages moet je rekening houden met de valuta. Om aanvraagbedragen op te tellen of te vergelijken, moeten alle bedragen worden omgerekend naar dezelfde valuta. Dit attribuut is nodig voor die omrekening. Waarom dit belangrijk is Geeft de nodige context bij het bedrag van de inkoopaanvraag en maakt nauwkeurige financiële analyses en vergelijkingen mogelijk wanneer meerdere valuta worden gebruikt. Waar vind je dit? Dit staat in de tabel EBAN, veld WAERS. Voorbeelden USDEURGBP | |||
Activiteiten voor inkoop-tot-betaling, aanvraag
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Goedkeuringsstap afgerond | Dit gebeurt wanneer een goedkeurder een aanvraag goedkeurt en daarmee een stap in de goedkeuringsworkflow met meerdere niveaus afrondt. Dit wordt afgeleid uit een wijziging van de vrijgavestatus van de aanvraag. | ||
| Waarom dit belangrijk is Met deze activiteit kun je de goedkeuringsworkflow in detail analyseren en de tijd per stap meten. Zo zie je welke goedkeurders efficiënt werken en waar bottlenecks ontstaan. Waar vind je dit? Afgeleid uit wijzigingsdocumenten (CDHDR/CDPOS) voor de tabel EBAN. Een wijziging van de status van een vrijgavecode (bijvoorbeeld in veld FRGZU) van niet-vrijgegeven naar vrijgegeven voor een specifieke code duidt op deze gebeurtenis. Vastleggen Volg in EBAN de wijzigingen van de velden voor de vrijgavestatus voor elke vrijgavecode in de strategie. Gebeurtenistype inferred | |||
| Inkoopaanvraag aangemaakt | Dit markeert het moment waarop het document voor de inkoopaanvraag voor het eerst in het systeem wordt aangemaakt. De gebeurtenis wordt expliciet vastgelegd wanneer een gebruiker een nieuwe aanvraag voor het eerst opslaat, inclusief de timestamp van het aanmaken. | ||
| Waarom dit belangrijk is Deze activiteit is het belangrijkste startpunt voor de analyse van de levenscyclus van een inkoopaanvraag. De activiteit is nodig om de end-to-end-doorlooptijd te meten, vanaf het vaststellen van de behoefte tot de definitieve goedkeuring of omzetting naar een inkooporder. Waar vind je dit? Dit is een expliciete gebeurtenis uit de tabel EBAN. De aanmaakdatum (ERDAT) en aanmaaktijd (ERZEIT) worden gebruikt voor het betreffende nummer van de inkoopaanvraag (BANFN). Vastleggen Gebruik voor elke aanvraag (BANFN) de velden voor de aanmaaktimestamp (ERDAT, ERZEIT) uit de tabel EBAN. Gebeurtenistype explicit | |||
| Inkoopaanvraag afgesloten | Dit geeft aan dat de aanvraagregel volledig is verwerkt en dat er geen inkooporders meer voor kunnen worden aangemaakt. Deze status wordt doorgaans automatisch ingesteld zodra de volledige hoeveelheid is besteld. | ||
| Waarom dit belangrijk is Deze activiteit markeert de definitieve, succesvolle afronding van de levenscyclus van de aanvraagregel. De zakelijke behoefte is hiermee volledig omgezet in een inkooporder. Waar vind je dit? Afgeleid uit de tabel EBAN. Dit gebeurt wanneer de indicator 'Closed' (EBAKZ) wordt ingesteld, meestal zodra de bestelde hoeveelheid in inkooporders gelijk is aan de aangevraagde hoeveelheid. Vastleggen Zoek via wijzigingsdocumenten naar de gebeurtenis waarbij de indicator 'Closed' (EBAKZ) wordt ingesteld in de tabel EBAN. Gebeurtenistype inferred | |||
| Inkoopaanvraag afgewezen | Dit is de definitieve afwijzing van de inkoopaanvraag door een goedkeurder, waardoor het proces stopt. De afwijzing wordt vastgelegd met een specifieke statuswijziging. | ||
| Waarom dit belangrijk is Deze activiteit is een eindpunt waarop het proces mislukt. Door te analyseren hoe vaak aanvragen worden afgewezen, waarom dat gebeurt en in welke procesfase, kun je problemen met beleidsregels, budgetten of de kwaliteit van aanvragen opsporen. Waar vind je dit? Afgeleid uit een statuswijziging in de tabel EBAN. De verwerkingsstatus (PROCSTAT) of een vrijgave-indicator krijgt een waarde die expliciet 'Rejected' betekent. Vastleggen Bepaal via de wijzigingsdocumenten de timestamp waarop de algemene status in EBAN wordt bijgewerkt naar 'Rejected'. Gebeurtenistype inferred | |||
| Inkoopaanvraag goedgekeurd | Dit markeert de definitieve goedkeuring van de inkoopaanvraag. Daarna kan de aanvraag worden omgezet in een inkooporder. Dit moment wordt afgeleid uit de algemene vrijgavestatus, zodra die de definitieve goedkeuringsstatus bereikt. | ||
| Waarom dit belangrijk is Dit is een belangrijk succesmoment en een veelgebruikt eindpunt voor analyses van doorlooptijden. Het geeft aan dat de aanvraag alle controles heeft doorstaan en klaar is voor verwerking door de inkoopafdeling. Waar vind je dit? Afgeleid uit een statuswijziging in de tabel EBAN. Dit gebeurt wanneer de algemene vrijgave-indicator (FRGZU) of verwerkingsstatus (PROCSTAT) wordt bijgewerkt naar de definitieve waarde 'Approved'. Vastleggen Bepaal de timestamp waarop de laatste vrijgavecode wordt toegepast of de algemene status van de aanvraag verandert naar 'Approved'. Gebeurtenistype inferred | |||
| Inkooporder aangemaakt | Dit geeft aan dat er een inkooporder is aangemaakt die verwijst naar de aanvraagregel. Het is een expliciete systeemgebeurtenis die de aanvraag koppelt aan een volgend inkoopdocument. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal en een geslaagd resultaat voor het aanvraagproces. De tijd tussen goedkeuring van de aanvraag en het aanmaken van de inkooporder is een belangrijke KPI voor de efficiëntie van het inkoopproces. Waar vind je dit? Dit wordt expliciet vastgelegd wanneer een inkooporderregel wordt aangemaakt. De koppeling staat in de tabel EKPO (inkooporderregel), met daarin het nummer van de oorspronkelijke inkoopaanvraag (BANFN) en het regelnummer (BNFPO). Vastleggen Koppel de tabel EKPO aan EBAN op basis van het aanvraagnummer en de regel. De aanmaakdatum van de inkooporderregel markeert de gebeurtenis. Gebeurtenistype explicit | |||
| Goedkeuring opnieuw gestart | Dit is een gebeurtenis waarbij de volledige goedkeuringsworkflow opnieuw wordt gestart, vaak na een ingrijpende wijziging van de aanvraag. De goedkeuring begint dan weer bij het eerste niveau. | ||
| Waarom dit belangrijk is Deze activiteit wijst op veel herstelwerk dat de doorlooptijd sterk verlengt. Als je de oorzaken van opnieuw gestarte goedkeuringen achterhaalt, kun je het proces verbeteren en vertragingen beperken. Waar vind je dit? Afgeleid uit wijzigingsdocumenten (CDHDR/CDPOS) voor de tabel EBAN. De gebeurtenis wordt herkend wanneer velden voor de vrijgavestatus, zoals FRGKZ of FRGZU, worden gewist nadat ze gedeeltelijk of volledig waren ingevuld. Vastleggen Zoek in de wijzigingslogboeken naar een wijziging van een vrijgegeven status naar een niet-vrijgegeven status. Gebeurtenistype inferred | |||
| Goedkeuringsstap gestart | Dit geeft aan dat een aanvraag wacht op actie van een specifieke goedkeurder of goedkeuringsgroep. Dit wordt afgeleid uit de status van de aanvraag, die aangeeft dat een specifieke vrijgavecode in behandeling is. | ||
| Waarom dit belangrijk is Deze activiteit helpt bottlenecks in de goedkeuringsketen op te sporen. De duur van deze status laat zien welke aanvragen stilliggen en welke goedkeurders overbelast zijn. Waar vind je dit? Afgeleid uit de velden voor de vrijgavestatus in de tabel EBAN (bijvoorbeeld FRGZU) en de bijbehorende configuratie van de vrijgavestrategie. De gebeurtenis begint wanneer een specifieke vrijgavecode als volgende moet worden verwerkt. Vastleggen Bepaal aan de hand van workflowlogboeken of statusvelden wanneer een aanvraag in een status komt waarin een specifieke vrijgavecode op goedkeuring wacht. Gebeurtenistype inferred | |||
| Inkoopaanvraag gewijzigd | Dit gebeurt wanneer een gebruiker na het aanmaken een belangrijk veld in de aanvraag wijzigt, zoals de hoeveelheid, prijs of het materiaal. Deze wijziging wordt expliciet vastgelegd in het wijzigingsdocumentensysteem van SAP. | ||
| Waarom dit belangrijk is Door wijzigingen bij te houden, kun je herstelwerk en de invloed daarvan op doorlooptijden herkennen. Veel wijzigingen wijzen mogelijk op problemen met de datakwaliteit of veranderende eisen. Dat zijn belangrijke aanknopingspunten voor procesverbetering. Waar vind je dit? Wijzigingen in de tabel EBAN worden expliciet vastgelegd in de SAP-tabellen voor wijzigingsdocumenten (CDHDR en CDPOS). Elke wijziging aan een gevolgd veld levert een vermelding op. Vastleggen Haal wijzigingsgebeurtenissen op uit CDHDR/CDPOS waarbij de objectklasse BANF is voor inkoopaanvragen. Gebeurtenistype explicit | |||
| Inkoopaanvraag ingetrokken | Dit gebeurt wanneer de oorspronkelijke aanvrager de aanvraag annuleert of verwijdert voordat deze volledig is verwerkt. Meestal wordt hiervoor expliciet een verwijderingsindicator ingesteld op de aanvraagregel. | ||
| Waarom dit belangrijk is Door intrekkingen bij te houden, krijg je inzicht in schommelingen in de vraag en redenen voor annulering. De aanvraag komt hiermee in een eindstatus en kan niet verder worden verwerkt. Waar vind je dit? Dit wordt expliciet vastgelegd wanneer het veld voor de verwijderingsindicator (LOEKZ) in de tabel EBAN wordt ingesteld voor een aanvraagregel. De wijziging wordt geregistreerd in CDHDR/CDPOS. Vastleggen Zoek de gebeurtenis waarbij de verwijderingsindicator (LOEKZ) in de tabel EBAN wordt ingesteld op 'L'. Gebeurtenistype explicit | |||
| Inkoopaanvraag ter goedkeuring ingediend | Dit is het moment waarop de aanvrager de aanvraag officieel indient en de goedkeuringsworkflow start. Dit wordt doorgaans afgeleid uit het bepalen van de vrijgavestrategie voor de aanvraag en de statuswijziging naar 'In Approval'. | ||
| Waarom dit belangrijk is Dit is een belangrijk moment dat de klok start voor KPI’s over de doorlooptijd van goedkeuringen. De tijd tussen het aanmaken en indienen kan vertragingen in de voorbereidingsfase van de aanvraag aan het licht brengen. Waar vind je dit? Afgeleid uit wijzigingsdocumenten (CDHDR/CDPOS) voor de tabel EBAN. Dit gebeurt wanneer de velden voor de vrijgavestrategie (bijvoorbeeld FRGST) worden ingevuld of de algemene status (PROCSTAT) verandert naar een status die aangeeft dat goedkeuring loopt. Vastleggen Zoek de eerste vermelding in de wijzigingsdocumenten die aangeeft dat de goedkeuringsworkflow is gestart of dat de status is gewijzigd naar 'In Approval'. Gebeurtenistype inferred | |||
| Inkoopbron toegewezen | Dit is het moment waarop een inkoper een specifieke leverancier, een contract of een info-record toewijst aan een goedgekeurde aanvraagregel. Dit is een belangrijke stap in de voorbereiding van het aanmaken van een inkooporder. | ||
| Waarom dit belangrijk is Deze activiteit vormt de verbinding tussen goedkeuring en bestellen. Door de tijd tot het toewijzen van een inkoopbron te meten, kun je vertragingen in de werkvoorraad van inkopers en de efficiëntie van het inkoopproces opsporen. Waar vind je dit? Afgeleid uit een ingevulde waarde in velden voor de inkoopbron in de tabel EBAN, zoals vaste leverancier (LIFNR), info-record (INFNR) of contract (KONNR). Vastleggen Volg via wijzigingsdocumenten wanneer velden zoals LIFNR, INFNR of KONNR in de tabel EBAN worden ingevuld. Gebeurtenistype inferred | |||
Extractiegidsen
Stappen
- Vereisten: Zorg dat je een gebruiker hebt met de juiste autorisaties in SAP S/4HANA om de benodigde CDS-views te openen. Dit vereist doorgaans rechten voor objecten zoals S_TABU_NAM en toegang tot tools om data weer te geven.
- Bepaal hoe je verbinding maakt met het systeem: Bepaal hoe je verbinding maakt met de SAP S/4HANA-database om SQL-query’s uit te voeren. Veelgebruikte tools zijn SAP HANA Studio, de Eclipse IDE met ADT (ABAP Development Tools) en SQL-clients van derden, zoals DBeaver, die verbinding kunnen maken via de SAP HANA-databaseclient.
- Bekijk de SQL-query: Lees het meegeleverde SQL-script door. Het gebruikt Common Table Expressions (CTE’s) om data voor verschillende activiteiten op te halen en samen te voegen tot één event log.
- Vervang de tijdelijke waarden: Zoek de tijdelijke waarden in de query en vervang ze. Stel de datumbereiknotatie in op
[YYYY-MM-DD]voor de extractieperiode en geef de relevante bedrijfscodes op ([Your Company Code]). - Voer de query uit: Voer de volledige, aangepaste SQL-query uit op de SAP S/4HANA-database. Afhankelijk van de hoeveelheid data en het gekozen datumbereik kan dit even duren.
- Controleer de eerste resultaten: Bekijk na afloop de eerste rijen van de uitvoer. Controleer of alle kolommen, zoals PurchaseRequisitionId, ActivityName en EventTime, de verwachte waarden bevatten en of de data de juiste notatie heeft.
- Controleer de datatransformatie: De query is zo opgezet dat de uitvoer klaar is voor process mining. De functies
CASTenCONCATzorgen voor consistente datatypen. Na uitvoering is er normaal gesproken geen grote datatransformatie nodig. - Exporteer het event log: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Gebruik UTF-8-codering om problemen met tekens te voorkomen.
- Bereid het bestand voor op upload: Controleer vóór het uploaden naar een process mining-tool of het CSV-bestand de juiste kolomkoppen bevat (
PurchaseRequisitionId,ActivityName,EventTimeenzovoort) en of de datum- en tijdnotatie vanEventTimeconsistent is en door het doelplatform wordt ondersteund. - Upload naar ProcessMind: Upload het uiteindelijke CSV-bestand naar je ProcessMind-project. Stel het project in door
PurchaseRequisitionIdte koppelen aan Case ID,ActivityNameaan Activiteit enEventTimeaan Timestamp.
Configuratie
- Belangrijkste CDS-views: De extractie gebruikt vooral
I_PurchaseRequisitionAPI01voor de aanvraaggegevens,I_ChangeDocumentenI_ChangeDocumentItemom wijzigingen en statusupdates bij te houden, enI_PurchaseOrderItemAPI01om aanvragen aan inkooporders te koppelen. - Autorisatie: De gebruiker die de query uitvoert, heeft leestoegang nodig tot de genoemde CDS-views. Vraag het SAP-beveiligingsteam welke rollen en autorisaties nodig zijn.
- Filter op datumbereik: Beperk de hoeveelheid data door te filteren op de aanmaakdatum van de aanvraag (
CreationDate). Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan. - Filter op organisatie: Filter op
CompanyCodeom het proces van de juiste bedrijfseenheid te analyseren. Je kunt ook filteren opPurchaseRequisitionTypeom je te richten op specifieke inkoopprocessen, zoals standaardgoederen of diensten. - Configuratie van wijzigingsdocumenten: Activiteiten als 'Requisition Amended' en verschillende goedkeuringsstappen worden alleen vastgelegd als logging van wijzigingsdocumenten voor de relevante velden in SAP is ingeschakeld. Ontbreken deze events, controleer dan de systeemconfiguratie voor tabel EBAN.
- Prestaties: In grote systemen met miljoenen aanvragen kan een query over een lange periode de systeemprestaties beïnvloeden. Voer de query zo mogelijk uit op rustige momenten of in een niet-productieomgeving met recent bijgewerkte data.
Voorbeeldquery sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Stappen
- Controleer of je directe leestoegang hebt tot het SAP HANA-schema met EBAN en EBKN. Bepaal ook welke wijzigingsdocument- en inkoopdocumentobjecten je systeem gebruikt voor wijzigingen aan aanvragen, vrijgaveverwerking, bronkoppeling, verwijzingen naar inkooporders en afsluiting. Deze objecten en velden kunnen per release en configuratie verschillen. Vervang daarom elke tijdelijke waarde tussen vierkante haken in de query door het bijbehorende object of veld uit je systeem.
- Gebruik in SAP GUI transactie SE16H of een goedgekeurde databasebeheertool om EBAN en EBKN te bekijken. Controleer de sleutelvelden van de aanvraag en welke velden beschikbaar zijn voor datum, tijd, gebruiker, status, verwijdering, vrijgave, rekeningtoewijzing en verwijzing naar het inkoopdocument. Controleer velddefinities met SE11 of het SAP-datawoordenboek. Stel testdata uit productie niet bloot.
- Bepaal welke bron in je systeem is geconfigureerd voor wijzigingsdocumenten van aanvragen en goedkeuringswijzigingen. De query verwacht een genormaliseerde wijzigingsbron met de naam [Your requisition change document source], met velden voor aanvraagnummer, itemnummer, gewijzigd veld, oude waarde, nieuwe waarde, wijzigingsdatum, wijzigingstijd en gebruiker. Koppel deze bron vóór uitvoering aan de relevante SAP-wijzigingsdocumenttabellen of CDS-view in je systeem.
- Bepaal welke workflow- of vrijgavebron is geconfigureerd voor indiening, opnieuw instellen van goedkeuring, start en afronding van goedkeuringsstappen, definitieve goedkeuring en afwijzing. De query verwacht [Your requisition approval event source], met één rij per status- of vrijgavetransitie en velden voor aanvraagnummer, itemnummer, eventtype, vrijgavecode of goedkeuringsgroep, goedkeurder, eventdatum, eventtijd en status. Koppel deze bron aan de vrijgave- of workflowopslag die in je S/4HANA-configuratie wordt gebruikt.
- Bepaal welke bronnen worden gebruikt voor bronkoppeling, verwijzingen naar inkooporders en afsluiting. De query verwacht [Your requisition source assignment source], [Your requisition purchase order reference source] en [Your requisition closure source]. Koppel deze tijdelijke waarden aan goedgekeurde tabellen of views in je systeem. Het aanmaken van een inkooporder moet blijken uit een expliciete verwijzing van het inkooporderitem naar het aanvraagitem. Leid dit niet af uit niet-gerelateerde inkoopactiviteiten.
- Stel de extractieperiode in met [Start date] en [End date]. Voor de eerste uitvoering raden we een periode van drie tot zes maanden aan. Gebruik pas een langere periode nadat je de databaseprestaties en het aantal events hebt gecontroleerd. De query filtert op aanmaak- en eventdatums en behoudt het aanvraagnummer als case-ID.
- Voer de query uit in een goedgekeurde SQL-client die verbinding heeft met SAP HANA. Vervang alleen de verbindingsgegevens buiten de query, datumparameters, bedrijfsspecifieke filters en de expliciet beschreven tijdelijke waarden voor bronnen en velden. Laat de namen van de uitvoerkolommen exact staan als PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount en RequisitionStatus.
- Controleer dubbele events, de precisie van timestamps, de tijdzone en het detailniveau per item of document. De query gebruikt documentniveau-ID’s voor cases en neemt de itemcontext intern mee. Als meerdere items dezelfde activiteit en timestamp opleveren, behoud dan aparte rijen, tenzij je ProcessMind-ontwerp expliciet om ontdubbeling vraagt.
- Controleer of elke vereiste activiteit voorkomt als waarde in ActivityName, of EventTime is ingevuld en chronologisch aannemelijk is, en of de vereiste case-ID niet leeg is. Vergelijk de aantallen met SAP-rapporten of goedgekeurde operationele extracten voor dezelfde periode.
- Exporteer het resultaat als UTF-8-CSV of een ander tabelvormig formaat dat ProcessMind ondersteunt. Voeg een kopregel toe, behoud timestamps die compatibel zijn met ISO-notatie, laat null-waarden leeg en upload het bestand met PurchaseRequisitionId als case-ID, ActivityName als activiteitskolom en EventTime als timestampkolom.
Configuratie
- Case-ID: Gebruik het documentnummer van de inkoopaanvraag uit EBAN, weergegeven als PurchaseRequisitionId. Is het proces op itemniveau ingericht, gebruik dan een gedocumenteerde samengestelde sleutel, bijvoorbeeld aanvraagnummer en itemnummer, en gebruik diezelfde sleutel voor elk event.
- Primaire bron: EBAN bevat de aanvraagitemgegevens. EBKN bevat de rekeningtoewijzing en aanvullende gegevens over afdeling of kostenplaats. Controleer vóór uitvoering de exacte veldnamen en datatypen in het SAP-datawoordenboek.
- Eventbronnen: De query gebruikt bewust tijdelijke waarden voor wijzigings-, goedkeurings-, bronkoppelings-, inkooporderverwijzings- en afsluitingsbronnen. Deze bronnen hangen af van de S/4HANA-release, het workflowontwerp, de vrijgaveprocedure, geactiveerde bedrijfsfuncties en klantspecifieke uitbreidingen.
- Datumbereik: Begin met drie tot zes maanden. Gebruik waar mogelijk een begrensd bereik op geïndexeerde datumvelden of velden waarmee partities kunnen worden overgeslagen. Laat bij incrementele ladingen extractieperioden voldoende overlappen om laat binnengekomen wijzigingen mee te nemen. Ontdubbel daarna op basis van case, activiteit, timestamp, item en bronevent-ID.
- Bedrijfsfilters: Stel [Company code filter], [Document type filter], [Purchasing group filter] en [Plant filter] alleen in als deze velden beschikbaar zijn en hun betekenis voor het bedrijf is bevestigd. Filter niet op status als je de volledige levenscyclus wilt vastleggen.
- Statusmapping: Stel de waarden voor In Approval, final approved, rejected, reset, pending release code en closed in op basis van de vrijgavestrategie of workflowconfiguratie van het doelsysteem. Ga er niet van uit dat één statuscode in alle SAP-clients hetzelfde betekent.
- Mapping van wijzigingen: Neem wijzigingen op in hoeveelheid, prijs, materiaal, leverdatum, rekeningtoewijzing en andere velden die in je proces als sleutelvelden gelden. De query bevat expliciete voorwaarden voor de genoemde sleutelvelden. De bron moet de naam van het gewijzigde veld beschikbaar stellen.
- Tijdstempels: Combineer de eventdatum en -tijd in de tijdzone van de database en documenteer eventuele omzetting naar UTC. Slaat een bron alleen een datum op, gebruik dan alleen middernacht als er geen nauwkeuriger timestamp beschikbaar is en leg die beperking vast.
- Prestaties: Beperk de eerste extractie op datum en bedrijfsbereik, selecteer alleen de benodigde kolommen, vermijd onbeperkte joins met grote wijzigings- of workflowgeschiedenissen en controleer het uitvoeringsplan van HANA. Materialiseer of stage genormaliseerde eventbronnen als je vaker data moet ophalen.
- Autorisaties en vereisten: Regel leestoegang tot EBAN, EBKN, de geconfigureerde wijzigings- en workflowbronnen, bronkoppelingsdata, verwijzingsdata van inkooporders en afsluitingsdata. Controleer of directe databasetoegang is goedgekeurd, de relevante inkoop- en workflowfuncties actief zijn en eventuele vereiste SAP HANA-databaselicenties of beheertools beschikbaar zijn.
- Beveiliging: Beperk toegang tot wat nodig is, bescherm gebruikers- en goedkeurders-ID’s en volg de organisatieregels voor het extraheren van inkoop- en financiële gegevens.
Voorbeeldquery sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Klaar om te beginnen?
Gebruik deze template om je data met zekerheid voor te bereiden en het meeste uit process mining voor het aanvraagproces van inkoop tot betaling te halen. Begin vandaag met het verbeteren van de efficiëntie.
Voorkom vertraging bij P2P-aanvragen: verbeter nu je workflow!
Maak processen efficiënter, verkort de doorlooptijden en verklein de cyclustijd met 30%.
Geen creditcard nodig. Je bent in 5 minuten klaar.