Jouw datatemplate voor Purchase to Pay-aanvragen
Jouw datatemplate voor Purchase to Pay-aanvragen
- Aanbevolen attributen voor een gedetailleerde analyse
- Belangrijke activiteiten voor process discovery
- Instructies voor data-extractie uit SAP S/4HANA
Van inkoop tot betaling - attributen van inkoopaanvragen
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit die op een specifiek moment in het proces van de inkoopaanvraag plaatsvond. | ||
| Beschrijving De activiteitsnaam beschrijft een specifieke gebeurtenis of taak binnen de levenscyclus van een inkoopaanvraag. Deze activiteiten zijn afgeleid uit systeemlogboeken, zoals wijzigingsdocumenten en workflowgeschiedenissen, en vertegenwoordigen belangrijke procesmomenten zoals 'Inkoopaanvraag aangemaakt', 'Goedkeuringsstap gestart' of 'Inkooporder aangemaakt'. Door deze activiteiten te analyseren, kun je de procesflow visualiseren, knelpunten vinden en meten hoeveel tijd verschillende fasen kosten. Als je de volgorde en frequentie van activiteiten zoals 'Inkoopaanvraag gewijzigd' of 'Inkoopaanvraag afgewezen' begrijpt, zie je waar het proces inefficiënt is en waar verbetering mogelijk is. Waarom dit belangrijk is Dit attribuut definieert de processtappen. Daarmee vormt het de basis van de procesmap en kun je de procesflow, varianten en knelpunten analyseren. Waar je het vindt Dit is een afgeleid attribuut dat meestal wordt samengesteld door data uit wijzigingsdocumenttabellen (CDHDR, CDPOS) en workflowlogboeken, zoals SWWLOGHIST, te interpreteren. Voorbeelden Inkoopaanvraag aangemaaktGoedkeuringsstap voltooidInkoopaanvraag goedgekeurdInkooporder aangemaakt | |||
| Gebeurtenistijd EventTime | De exacte datum en tijd waarop een specifieke activiteit plaatsvond. | ||
| Beschrijving Gebeurtenistijd is de timestamp die vastlegt wanneer een activiteit plaatsvond. Deze data is nodig om gebeurtenissen binnen een case chronologisch te ordenen en vormt de basis voor alle berekeningen van doorlooptijden en prestaties in process mining. Zo bepaalt het tijdsverschil tussen de gebeurtenissen 'Inkoopaanvraag ingediend' en 'Inkoopaanvraag goedgekeurd' de doorlooptijd van de goedkeuring. Nauwkeurige timestamps zijn essentieel om procesprestaties en vertragingen te analyseren en naleving van service level agreements te bewaken. Met dit attribuut kun je dashboards maken die doorlooptijden tonen, aanvragen volgen die blijven liggen en prestaties over verschillende perioden vergelijken. Waarom dit belangrijk is Deze timestamp is essentieel voor het ordenen van gebeurtenissen, het berekenen van doorlooptijden en het analyseren van procesprestaties en knelpunten. Waar je het vindt Timestamps komen meestal uit kopteksten van wijzigingsdocumenten (CDHDR-UDATE, CDHDR-UTIME) of uit workflowlogboeken. Voorbeelden 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID van inkoopaanvraag PurchaseRequisitionId | De unieke identificatie van een document voor een inkoopaanvraag. | ||
| Beschrijving Het ID van de inkoopaanvraag is de primaire sleutel waarmee elk verzoek om goederen of diensten binnen SAP S/4HANA uniek wordt geïdentificeerd. Het dient als centrale case-identificatie en koppelt alle activiteiten en wijzigingen aan een specifieke inkoopaanvraag, vanaf het aanmaken tot de eindstatus, zoals goedkeuring, afwijzing of omzetting naar een inkooporder. In process mining is dit attribuut essentieel om de end-to-end-levenscyclus van elke inkoopaanvraag te reconstrueren. Door alle bijbehorende gebeurtenissen onder één ID van een inkoopaanvraag te groeperen, kunnen analisten doorlooptijden nauwkeurig meten, statuswijzigingen volgen en de verschillende routes analyseren die een aanvraag door de goedkeuringsworkflow kan nemen. Waarom dit belangrijk is Dit is de essentiële case-identificatie die alle bijbehorende processtappen koppelt. Zo krijg je een volledig en samenhangend beeld van de levenscyclus van de inkoopaanvraag. Waar je het vindt Dit attribuut is het nummer van de inkoopaanvraag. Je vindt het in tabel EBAN, veld BANFN. Voorbeelden 100178901001789110017892 | |||
| Afdeling Department | De afdeling of kostenplaats waaraan de kosten van de inkoopaanvraag worden toegewezen. | ||
| 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 die op regelniveau aan een inkoopaanvraag wordt toegewezen. In process mining is dit attribuut nodig voor analyses van prestaties per afdeling. Je kunt dashboards maken die KPI's zoals doorlooptijd, wijzigingspercentage en afwijzingspercentage tussen afdelingen vergelijken. Zo zie je welke afdelingen goed presteren en welke werkwijzen elders kunnen worden overgenomen. Ook wordt duidelijk waar extra training of procesondersteuning nodig is. Waarom dit belangrijk is Maakt prestatievergelijkingen tussen bedrijfseenheden mogelijk. Zo zie je verschillen in doorlooptijden of afwijzingspercentages en vind je goede werkwijzen en verbeterpunten. Waar je het vindt Dit is de kostenplaats. Je vindt deze meestal 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 kostenwaarde van de aangevraagde goederen of diensten. Deze waarde bepaalt vaak de complexiteit en duur van de goedkeuringsworkflow. Voor aanvragen met een hogere waarde zijn meestal meer goedkeuringsniveaus nodig. Door dit attribuut te analyseren, kun je het proces indelen op basis van waarde. Je kunt bijvoorbeeld nagaan of aanvragen met een hoge waarde langer op goedkeuring wachten of welke waarde aanvragen hebben die vaak worden afgewezen. Dit is een belangrijke dimensie om de financiële impact van procesinefficiënties te begrijpen. Waarom dit belangrijk is Helpt het proces in te delen op financiële impact. De waarde hangt vaak samen met de complexiteit van de goedkeuring en de doorlooptijd. Dit is belangrijk voor procesanalyses op basis van waarde. Waar je het vindt De totale waarde staat in tabel EBAN, veld GFWERT. De waarde op itemniveau staat in EBAN-PREIS. Voorbeelden 1500.0075000.50250.75 | |||
| Gebruikers-ID UserId | De identificatie van de gebruiker die de inkoopaanvraag heeft aangemaakt of een specifieke activiteit heeft uitgevoerd. | ||
| Beschrijving Het gebruikers-ID identificeert de medewerker of systeemgebruiker die verantwoordelijk is voor een specifieke gebeurtenis in de levenscyclus van de inkoopaanvraag. 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. Door op gebruikers-ID te analyseren, krijg je inzicht in gedrag per gebruiker, de verdeling van werk en prestaties. Je ziet welke training nodig is, welke medewerkers goed presteren en waar verantwoordelijkheid ligt. In combinatie met gebruikersstamgegevens ondersteunt dit ook analyses van prestaties per afdeling. Waarom dit belangrijk is Maakt analyses mogelijk van gebruikersprestaties, werkverdeling en naleving van het proces. Dit helpt bij het vinden van trainingsmogelijkheden en knelpunten in de beschikbare capaciteit. Waar je het vindt Voor de aanmaker vind je dit in EBAN-ERNAM. Voor latere wijzigingen staat het in CDHDR-USERNAME. Voor goedkeuringen staat het in workflowlogboeken. Voorbeelden JSMITHRROEWF-BATCH | |||
| ID van goedkeurder ApproverId | De identificatie van de gebruiker die een goedkeurings- of afwijzingsstap heeft uitgevoerd. | ||
| Beschrijving Het ID van de goedkeurder identificeert specifiek de gebruiker die een goedkeurings- of afwijzingsactiviteit heeft afgerond. Dit verschilt van het algemene gebruikers-ID, omdat het alleen gaat om de besluitvormers in de goedkeuringsworkflow. Deze informatie is nodig voor een gedetailleerde analyse van het goedkeuringsproces. Met dit attribuut kun je goedkeuringsgedrag analyseren. Je ziet bijvoorbeeld welke managers lang over goedkeuringen doen of vaak inkoopaanvragen afwijzen. Het vormt de basis voor dashboards over doorlooptijden per goedkeuringsstap en analyses van knelpunten in workflows. Zo vind je specifieke personen of rollen die vertraging veroorzaken. Waarom dit belangrijk is Laat zien wie de specifieke besluitvormer in een goedkeuringsstap is. Daarmee kun je doorlooptijden en knelpunten per persoon of rol analyseren. Waar je het vindt Deze informatie wordt meestal gehaald uit SAP Business Workflow-tabellen zoals SWW_WI2OBJ en SWWLOGHIST. Deze koppelen werkitems 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 dit vaak weergegeven met de vrijgave-indicator, die laat zien of een aanvraag geblokkeerd is, in goedkeuring staat, gedeeltelijk is goedgekeurd of volledig is goedgekeurd. De status verandert wanneer de aanvraag door de workflow gaat. Het volgen van de status in de tijd is nodig om de procesflow te begrijpen. Je ziet waar aanvragen vastlopen en hoe lang dat duurt. Door overgangen tussen statussen te analyseren, krijg je een gedetailleerd beeld van het goedkeuringsproces en de varianten daarin. Waarom dit belangrijk is Geeft de huidige status van een inkoopaanvraag aan. Dit is belangrijk om voortgang te volgen, knelpunten te vinden en de procesflow te analyseren. Waar je het vindt De vrijgavestatus wordt vaak bepaald door de vrijgave-indicator in tabel EBAN, veld FRGZU. Voorbeelden B1S | |||
| Type inkoopaanvraag RequisitionType | Een code die de inkoopaanvraag classificeert, bijvoorbeeld voor standaardartikelen, diensten of kapitaaluitgaven. | ||
| 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 bedrijfsdoelen worden gebruikt, zoals standaardvoorraadartikelen, externe diensten of activa. 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 ontdek je of bepaalde typen aanvragen efficiënter zijn en kun je procesverbeteringen gerichter vormgeven. Waarom dit belangrijk is Classificeert inkoopaanvragen voor vergelijkende analyses. Zo zie je of verschillende typen aanvragen andere procesflows, knelpunten of doorlooptijden hebben. Waar je het vindt Dit is het veld Document Type in tabel EBAN, veld BSART. Voorbeelden NBFORV | |||
| Benodigd op datum RequiredByDate | De datum waarop de aanvrager de aangevraagde goederen of diensten nodig heeft. | ||
| Beschrijving De datum Benodigd op, in SAP ook leverdatum genoemd, geeft aan wanneer de goederen of diensten op het aanvraagitem nodig zijn. De aanvrager stelt deze datum in. Het is een doel voor het volledige inkoopproces. Dit attribuut is nodig om de KPI voor het percentage op tijd afgeronde inkoopaanvragen te berekenen. Door de datum Benodigd op te vergelijken met de definitieve goedkeuring of het aanmaken van de inkooporder, meet je in hoeverre de organisatie interne serviceniveaus en bedrijfsbehoeften haalt. Aanvragen die deze datum niet halen, kunnen structurele vertragingen in het inkoopproces aan het licht brengen. Waarom dit belangrijk is Bepaalt de gewenste einddatum van een aanvraag. Zo kun je tijdige levering en naleving van interne serviceniveaus meten. Waar je het vindt Dit is de leverdatum op itemniveau in tabel EBAN, veld LFDAT. Voorbeelden 2023-11-152023-12-012024-01-20 | |||
| Bronsysteem SourceSystem | Identificeert de specifieke SAP S/4HANA-instantie waaruit de data is geëxtraheerd. | ||
| Beschrijving Het attribuut Bronsysteem geeft aan in welk oorspronkelijke systeem de procesdata is gegenereerd. Organisaties met meerdere SAP-instanties hebben bijvoorbeeld aparte systemen voor ontwikkeling, kwaliteitsborging en productie, of voor verschillende regio's. In zulke situaties is dit veld belangrijk voor datagovernance en context. Het zorgt ervoor dat data uit verschillende bronnen van elkaar te onderscheiden is. Zo voorkom je onjuiste aggregatie en kun je systeemspecifieke analyses uitvoeren. Het is een verplicht attribuut om de herkomst van data bij te houden en de traceerbaarheid van procesdata te waarborgen. Waarom dit belangrijk is Geeft belangrijke context over de herkomst en governance van data, vooral in omgevingen met meerdere systemen, en zorgt voor traceerbaarheid. Waar je het vindt Dit is meestal de SAP System ID (SID), die je uit systeemvariabelen of configuratietabellen kunt halen. Voorbeelden S4PECCS4H_PROD_01 | |||
| Eindtijd EndTime | De exacte datum en tijd waarop een specifieke activiteit is afgerond. | ||
| Beschrijving EndTime is de timestamp waarop wordt vastgelegd wanneer een activiteit is afgerond. Veel door het systeem gegenereerde events vinden direct plaats, waardoor StartTime gelijk is aan EndTime. Bij handmatige taken, zoals goedkeuringen, kunnen de start- en eindtijd wel verschillen. Deze timestamp markeert het einde van het werk. Met een aparte EndTime kun je actieve verwerkingstijd nauwkeuriger onderscheiden van wachttijd. Samen met StartTime wordt deze gebruikt om de metric ProcessingTime te berekenen. Zo krijg je een gedetailleerder beeld van het gebruik van bronnen en de efficiëntie van handmatige taken. Waarom dit belangrijk is Markeert het einde van een activiteit. Daarmee kun je de actieve verwerkingstijd berekenen en krijg je een gedetailleerder beeld van de taakduur. Waar je het vindt Dit is afgeleid van workflowlogs waarin mogelijk zowel het moment waarop een werkitem is aangemaakt (StartTime) als het moment waarop het is afgerond (EndTime) wordt vastgelegd. Voorbeelden 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Geautomatiseerd IsAutomated | Een indicator die aangeeft of een activiteit door een systeemgebruiker in plaats van door een persoon is uitgevoerd. | ||
| Beschrijving Het attribuut Is Automated is een booleaanse vlag die true is als een activiteit door een systeem- of batchgebruiker is uitgevoerd, zoals 'WF-BATCH' voor workflowacties. Hiermee kun je handmatige en geautomatiseerde stappen in het proces van elkaar onderscheiden. Dit attribuut is essentieel om de automatiseringsgraad in 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 verkort je verwerkingstijden en verminder je handmatig werk. Waarom dit belangrijk is Maakt onderscheid tussen activiteiten die door mensen en door systemen worden uitgevoerd. Dat is belangrijk om automatiseringspercentages te meten en mogelijkheden te vinden om handmatige taken te automatiseren. Waar je het vindt 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 | |||
| Is herwerk IsRework | Een vlag die aangeeft of een activiteit herstelwerk is, zoals een wijziging na indiening. | ||
| Beschrijving Is Rework is een berekende booleaanse vlag die activiteiten identificeert die geen waarde toevoegen of steeds opnieuw worden uitgevoerd. Een veelvoorkomend voorbeeld in dit proces is de activiteit 'Requisition Amended' nadat de aanvraag al ter goedkeuring is ingediend. Daardoor moet het goedkeuringsproces opnieuw beginnen. Met dit attribuut kun je de hoeveelheid herstelwerk in het proces en de invloed daarvan op de totale doorlooptijden meten. Het dashboard Requisition Amendment and Rework Rate gebruikt deze vlag om inefficiënties zichtbaar te maken. Minder herstelwerk is vaak een belangrijk doel van procesverbetering, omdat je daarmee rechtstreeks tijd en moeite bespaart. Waarom dit belangrijk is Markeert activiteiten die verspilde moeite of herhaling vertegenwoordigen. Zo kun je herstelwerk en de invloed daarvan op de procesefficiëntie rechtstreeks meten. Waar je het vindt Dit is een berekend attribuut. De logica markeert meestal elke activiteit 'Requisition Amended' die plaatsvindt na de eerste activiteit 'Requisition Submitted For Approval' als herstelwerk. Voorbeelden truefalse | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor dit record voor het laatst vanuit het bronsysteem is vernieuwd. | ||
| Beschrijving Dit attribuut legt de datum en tijd vast van de meest recente data-extractie of update vanuit het bronsysteem. Het is belangrijke metadata om te bepalen hoe actueel de geanalyseerde data is. Analisten en zakelijke gebruikers gebruiken deze timestamp om te controleren of de procesdata de actuele stand van de bedrijfsvoering weergeeft. Bij elke procesanalyse is het belangrijk om te weten hoe actueel de data is, zodat je onderbouwde beslissingen kunt nemen. Dit attribuut helpt verwachtingen van gebruikers te managen 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 vertrouwen en op tijd zakelijke beslissingen te nemen. Waar je het vindt Deze timestamp wordt gegenereerd en toegevoegd tijdens het ETL-proces voor extractie, transformatie en laden van data. 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 Approval Step Name geeft een begrijpelijke beschrijving van een bepaalde fase in de goedkeuringsworkflow, zoals 'Manager Approval' of 'VP Finance Approval'. Dit is duidelijker dan een generieke activiteit als 'Approval Step Completed'. Dit attribuut is belangrijk voor de dashboards Approval Step Cycle Time en Workflow Bottleneck Analysis. Je krijgt hiermee een gedetailleerd beeld van het goedkeuringsproces. Zo zie je precies welke goedkeuringsfasen de grootste vertraging veroorzaken en waar werk zich ophoopt. Die informatie heb je nodig om gericht verbeteringen door te voeren in de goedkeuringsketen. Waarom dit belangrijk is Geeft gedetailleerde informatie over goedkeuringsfasen, zodat je knelpunten in de goedkeuringsworkflow met meerdere niveaus precies kunt vinden. Waar je het vindt Deze informatie is afgeleid van de beschrijving van de workflowtaak. Je vindt die door het workflowlog te koppelen aan tabellen met taakdefinities, zoals T528T. Voorbeelden Goedkeuring door managerGoedkeuring door directeurGoedkeuring door vicepresident Financiën | |||
| Nummer van inkooporder PurchaseOrderNumber | Het nummer van de inkooporder die vanuit de inkoopaanvraag is aangemaakt. | ||
| Beschrijving Het nummer van de inkooporder is de identificatie van het officiële inkoopdocument dat vanuit een goedgekeurde aanvraag is aangemaakt. Het aanmaken van een inkooporder is vaak het succesvolle eindresultaat van een inkoopaanvraag. De aanvraag is dan omgezet in een formele order bij een leverancier. Dit attribuut is nodig om de KPI voor de doorlooptijd van inkoopaanvraag naar inkooporder en het totale conversiepercentage te meten. Het koppelt het proces voor inkoopaanvragen aan het daaropvolgende inkoopproces, zodat je de volledige Purchase-to-Pay-cyclus end-to-end kunt bekijken. Waarom dit belangrijk is Koppelt de inkoopaanvraag aan het daaropvolgende inkoopdocument. Zo kun je het conversiepercentage en de doorlooptijd van inkoopaanvraag naar inkooporder meten. Waar je het vindt Je vindt dit in tabel EBAN, veld EBELN, zodra vanuit het aanvraagitem een inkooporder is aangemaakt. Voorbeelden 450001789045000178914500017892 | |||
| 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, zie je de oorzaken van inefficiënties en herstelwerk. Als 'Onjuiste kostenplaats' bijvoorbeeld vaak voorkomt, kan dat wijzen op behoefte aan betere gebruikerstraining of validatie in het systeem. Dit attribuut vormt de basis voor het dashboard voor afwijzingsanalyses van inkoopaanvragen en helpt bij gerichte procesverbetering. Waarom dit belangrijk is Geeft de oorzaak van problemen in het proces aan. Zo kun je gericht verbeteren, herstelwerk verminderen en het percentage aanvragen dat in één keer goed is verhogen. Waar je het vindt Dit is vaak geen standaardveld. De informatie kan staan in workflowcontainerelementen, lange tekst bij de inkoopaanvraag of aangepaste velden. Voorbeelden Budget overschredenOnjuiste leverancierDubbele aanvraag | |||
| Urgentieniveau UrgencyLevel | Een classificatie van de urgentie van de aanvraag, die invloed kan hebben op de verwerkingsprioriteit. | ||
| Beschrijving Urgency Level geeft de prioriteit van de inkoopaanvraag aan. Hoewel hiervoor geen standaardveld bestaat, gebruiken sommige organisaties velden zoals Requirement Tracking Number om deze informatie vast te leggen. Aanvragers kunnen hiermee aangeven dat het om een kritieke behoefte gaat die met voorrang moet worden verwerkt. Het is belangrijk om de invloed van urgentie te analyseren. Zo 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. Daarmee zie je of de prioriteitsbehandeling werkt zoals bedoeld. Waarom dit belangrijk is Maakt het mogelijk om te analyseren hoe de procesprestaties verschillen voor aanvragen met een hoge prioriteit. Zo kun je controleren of urgente aanvragen echt sneller worden verwerkt. Waar je het vindt 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 inkoopaanvraag is uitgedrukt, bijvoorbeeld USD, EUR of JPY. Het biedt de nodige context voor het attribuut Bedrag van inkoopaanvraag, vooral bij multinationale organisaties die met meerdere valuta werken. Voor nauwkeurige financiële analyses en rapportages moet je rekening houden met de valuta. Als je bedragen van inkoopaanvragen optelt of vergelijkt, moeten alle bedragen naar één gemeenschappelijke valuta worden omgerekend. Dit attribuut is daarvoor een vereiste. Waarom dit belangrijk is Geeft de nodige context voor het bedrag van de inkoopaanvraag en maakt nauwkeurige financiële analyses en vergelijkingen in omgevingen met meerdere valuta mogelijk. Waar je het vindt Je vindt dit in tabel EBAN, veld WAERS. Voorbeelden USDEURGBP | |||
Van inkoop tot betaling - activiteiten van inkoopaanvragen
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Goedkeuringsstap voltooid | Dit gebeurt wanneer een goedkeurder positief beslist over een inkoopaanvraag en daarmee één stap in de goedkeuringsworkflow met meerdere niveaus afrondt. Je leidt dit af uit een wijziging in de vrijgavestatus van de aanvraag. | ||
| Waarom dit belangrijk is Met deze activiteit kun je de goedkeuringsworkflow gedetailleerd analyseren en meten hoeveel tijd elke afzonderlijke stap kost. Zo zie je welke goedkeurders efficiënt werken en waar knelpunten ontstaan. Waar je het vindt Dit wordt afgeleid uit wijzigingsdocumenten (CDHDR/CDPOS) voor de EBAN-tabel. Een wijziging van de status van een vrijgavecode, bijvoorbeeld in veld FRGZU, van niet-vrijgegeven naar vrijgegeven voor een specifieke code betekent dat deze gebeurtenis heeft plaatsgevonden. Vastleggen Volg de wijzigingen in de velden voor de vrijgavestatus in EBAN voor elke vrijgavecode die in de procedure is gedefinieerd. Eventtype 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 aanmaaktimestamp. | ||
| Waarom dit belangrijk is Deze activiteit is het primaire startpunt voor de analyse van de levenscyclus van de inkoopaanvraag. Je hebt dit moment 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 je het vindt Dit is een expliciete gebeurtenis uit de EBAN-tabel, gebaseerd op de velden voor aanmaakdatum (ERDAT) en aanmaaktijd (ERZEIT) voor het specifieke nummer van de inkoopaanvraag (BANFN). Vastleggen Gebruik voor elke inkoopaanvraag (BANFN) de velden voor de aanmaaktimestamp (ERDAT, ERZEIT) uit de EBAN-tabel. Eventtype explicit | |||
| Inkoopaanvraag afgewezen | Dit is de definitieve afwijzing van de inkoopaanvraag door een goedkeurder, waardoor het proces stopt. Je legt dit vast met een specifieke statuswijziging die afwijzing aangeeft. | ||
| Waarom dit belangrijk is Deze activiteit is een belangrijk eindpunt bij een mislukte aanvraag. Door de frequentie, redenen en processtappen van afwijzingen te analyseren, zie je problemen met beleidsnaleving, budgetten of de kwaliteit van aanvragen. Waar je het vindt Dit wordt afgeleid uit een statuswijziging in de EBAN-tabel. De verwerkingsstatus (PROCSTAT) of een vrijgave-indicator krijgt een waarde die expliciet 'Afgewezen' betekent. Vastleggen Bepaal via wijzigingsdocumenten de timestamp waarop de algemene status in EBAN wordt bijgewerkt naar 'Afgewezen'. Eventtype inferred | |||
| Inkoopaanvraag gesloten | Dit geeft aan dat het aanvraagitem volledig is verwerkt en dat er geen nieuwe inkooporders meer vanuit kunnen worden aangemaakt. Deze status wordt meestal automatisch ingesteld zodra de volledige hoeveelheid is besteld. | ||
| Waarom dit belangrijk is Deze activiteit markeert de succesvolle afronding van de levenscyclus van het aanvraagitem. Het bevestigt dat de bedrijfsbehoefte volledig is vertaald naar een inkooporder. Waar je het vindt Dit wordt afgeleid uit de EBAN-tabel. De gebeurtenis vindt plaats wanneer de indicator 'Gesloten' (EBAKZ) wordt ingesteld. Dat gebeurt meestal wanneer de in inkooporders bestelde hoeveelheid gelijk is aan de aangevraagde hoeveelheid. Vastleggen Identificeer via wijzigingsdocumenten de gebeurtenis waarbij de indicator 'Gesloten' (EBAKZ) in tabel EBAN wordt ingesteld. Eventtype inferred | |||
| Inkoopaanvraag goedgekeurd | Dit markeert de volledige en definitieve goedkeuring van de inkoopaanvraag. De aanvraag kan nu worden omgezet in een inkooporder. Je leidt dit ijkpunt af wanneer de algemene vrijgavestatus de definitieve goedgekeurde status bereikt. | ||
| Waarom dit belangrijk is Dit is een belangrijk succesmoment en een veelgebruikt eindpunt voor analyses van doorlooptijden. Het betekent dat de inkoopaanvraag alle controles heeft doorlopen en klaar is voor verwerking door de inkoopafdeling. Waar je het vindt Dit wordt afgeleid uit een statuswijziging in de EBAN-tabel, met name wanneer de algemene vrijgave-indicator (FRGZU) of verwerkingsstatus (PROCSTAT) wordt bijgewerkt naar de definitieve waarde 'Goedgekeurd'. Vastleggen Bepaal de timestamp waarop de laatste vrijgavecode wordt toegepast of de algemene status van de inkoopaanvraag verandert naar 'Goedgekeurd'. Eventtype inferred | |||
| Inkooporder aangemaakt | Dit geeft aan dat er een inkooporder is aangemaakt die naar het aanvraagitem verwijst. Het is een expliciete systeemgebeurtenis die de inkoopaanvraag koppelt aan een volgend inkoopdocument. | ||
| Waarom dit belangrijk is Dit is een belangrijk ijkpunt en een geslaagd resultaat van het proces voor inkoopaanvragen. De tijd tussen goedkeuring van de aanvraag en het aanmaken van de inkooporder is een belangrijke KPI voor de efficiëntie van inkoop. Waar je het vindt Dit wordt expliciet vastgelegd wanneer een inkooporderitem wordt aangemaakt. De koppeling staat in de EKPO-tabel (inkooporderitem), met daarin het nummer van de inkoopaanvraag (BANFN) en het itemnummer (BNFPO). Vastleggen Koppel de EKPO-tabel op basis van het nummer en item van de inkoopaanvraag terug aan EBAN. De aanmaakdatum van het inkooporderitem markeert de gebeurtenis. Eventtype explicit | |||
| Bron van levering toegewezen | Dit is de actie waarbij een inkoper een specifieke leverancier, een contract of een info-record koppelt aan een goedgekeurd aanvraagitem. Dit is een belangrijke stap in de voorbereiding van het aanmaken van een inkooporder. | ||
| Waarom dit belangrijk is Deze activiteit vormt de schakel tussen goedkeuring en bestellen. Door de tijd tot het toewijzen van een bron te meten, zie je vertragingen in de werkvoorraad van inkopers en in de efficiëntie van het vinden van een leverancier. Waar je het vindt Dit wordt afgeleid wanneer een waarde wordt ingevuld in velden in de EBAN-tabel die met de bron van levering te maken hebben, zoals vaste leverancier (LIFNR), info-record (INFNR) of contract (KONNR). Vastleggen Volg via wijzigingsdocumenten wanneer velden zoals LIFNR, INFNR of KONNR in de EBAN-tabel worden gevuld. Eventtype inferred | |||
| Goedkeuring opnieuw ingesteld | Dit is een gebeurtenis waarbij de volledige goedkeuringsworkflow opnieuw wordt ingesteld, vaak na een ingrijpende wijziging van de inkoopaanvraag. Daardoor begint het goedkeuringsproces opnieuw bij het eerste niveau. | ||
| Waarom dit belangrijk is Deze activiteit laat ingrijpend herstelwerk zien dat de doorlooptijd sterk beïnvloedt. Door de oorzaken van het opnieuw instellen van goedkeuringen te achterhalen, kun je het proces vereenvoudigen en vertragingen verminderen. Waar je het vindt Dit wordt afgeleid uit wijzigingsdocumenten (CDHDR/CDPOS) voor de EBAN-tabel. De gebeurtenis wordt herkend wanneer velden voor de vrijgavestatus, zoals FRGKZ of FRGZU, worden leeggemaakt nadat ze gedeeltelijk of volledig waren ingevuld. Vastleggen Zoek in de wijzigingslogboeken naar een wijziging van een vrijgegeven status terug naar een niet-vrijgegeven status. Eventtype inferred | |||
| Goedkeuringsstap gestart | Dit geeft aan dat een inkoopaanvraag wacht op actie van een specifieke goedkeurder of goedkeuringsgroep. Je leidt dit af wanneer de status van de aanvraag aangeeft dat een specifieke vrijgavecode in behandeling is. | ||
| Waarom dit belangrijk is Deze activiteit helpt je knelpunten in de goedkeuringsketen te vinden. Door de duur van deze status te analyseren, zie je welke aanvragen blijven liggen en welke goedkeurders te veel werk hebben. Waar je het vindt Dit wordt afgeleid uit de velden voor de vrijgavestatus in de EBAN-tabel, zoals FRGZU, en uit de onderliggende configuratie van de vrijgaveprocedure. De gebeurtenis start wanneer een specifieke vrijgavecode als volgende moet worden verwerkt. Vastleggen Bepaal op basis van workflowlogboeken of statusvelden wanneer een inkoopaanvraag een status krijgt waarin een specifieke vrijgavecode op goedkeuring wacht. Eventtype inferred | |||
| Inkoopaanvraag gewijzigd | Dit gebeurt wanneer een gebruiker na het aanmaken een belangrijk veld in de inkoopaanvraag wijzigt, zoals de hoeveelheid, prijs of het materiaal. Deze actie wordt expliciet vastgelegd in het SAP-systeem voor wijzigingsdocumenten. | ||
| Waarom dit belangrijk is Door wijzigingen bij te houden, zie je waar herstelwerk ontstaat en welk effect dit heeft op de doorlooptijden. Veel wijzigingen wijzen vaak op problemen met de datakwaliteit of veranderende eisen. Dat zijn belangrijke aandachtspunten voor procesverbetering. Waar je het vindt Dit wordt expliciet vastgelegd in de SAP-tabellen voor wijzigingsdocumenten (CDHDR en CDPOS) voor wijzigingen in tabel EBAN. Elke wijziging in een gevolgd veld maakt een vermelding aan. Vastleggen Extraheer wijzigingsgebeurtenissen uit CDHDR/CDPOS waarbij de objectklasse BANF is voor inkoopaanvragen. Eventtype explicit | |||
| Inkoopaanvraag ingetrokken | Dit gebeurt wanneer de oorspronkelijke aanvrager de inkoopaanvraag annuleert of verwijdert voordat deze volledig is verwerkt. Meestal is dit een expliciete actie waarbij een verwijderingsindicator op het aanvraagitem wordt gezet. | ||
| Waarom dit belangrijk is Door intrekkingen bij te houden, krijg je inzicht in veranderende behoeften en redenen voor annulering. Dit is een eindstatus voor de inkoopaanvraag, waardoor verdere verwerking niet meer mogelijk is. Waar je het vindt Dit wordt expliciet vastgelegd wanneer het veld voor de verwijderingsindicator (LOEKZ) in de EBAN-tabel voor een aanvraagitem wordt ingesteld. De wijziging wordt vastgelegd in CDHDR/CDPOS. Vastleggen Identificeer de gebeurtenis waarbij de verwijderingsindicator (LOEKZ) in tabel EBAN op 'L' wordt gezet. Eventtype explicit | |||
| Inkoopaanvraag ter goedkeuring ingediend | Dit is het moment waarop de aanvrager de inkoopaanvraag formeel indient en de goedkeuringsworkflow start. Meestal leid je dit af uit het vaststellen van de vrijgaveprocedure en een statuswijziging naar 'In goedkeuring'. | ||
| Waarom dit belangrijk is Dit is een belangrijk ijkpunt voor KPI's rond de doorlooptijd van goedkeuringen. Door de tijd tussen aanmaken en indienen te analyseren, zie je vertragingen in de voorbereidingsfase van de inkoopaanvraag. Waar je het vindt Dit wordt afgeleid uit wijzigingsdocumenten (CDHDR/CDPOS) voor de EBAN-tabel, met name wanneer velden voor de vrijgaveprocedure, zoals FRGST, worden gevuld of de algemene status (PROCSTAT) verandert naar een status die aangeeft dat de aanvraag in goedkeuring is. Vastleggen Zoek de eerste vermelding in de wijzigingsdocumenten die het begin van de goedkeuringsworkflow of een statuswijziging naar 'In goedkeuring' aangeeft. Eventtype inferred | |||
Extractiegidsen
Stappen
- Vereisten: Zorg dat je een gebruiker hebt met de juiste autorisaties in SAP S/4HANA om toegang te krijgen tot de benodigde CDS-views. Dit omvat meestal rechten voor objecten zoals S_TABU_NAM en toegang tot tools voor het bekijken van data.
- Bepaal de methode voor systeemtoegang: 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) of SQL-clients van derden, zoals DBeaver, die via de SAP HANA-databaseclient verbinding kunnen maken.
- Bekijk de SQL-query: Maak jezelf vertrouwd met het meegeleverde SQL-script. Het gebruikt Common Table Expressions (CTE's) om data voor verschillende activiteiten te verzamelen en deze samen te voegen tot één event log.
- Vervang placeholders: Zoek de placeholders in de query en vervang ze. Stel de datums voor de extractieperiode in met de notatie
[YYYY-MM-DD]en geef de relevante bedrijfsnummers op met[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 de gekozen periode kan dit enige tijd duren.
- Controleer de data eerst: Bekijk na afloop de eerste rijen van de uitvoer. Controleer of alle kolommen, zoals PurchaseRequisitionId, ActivityName en EventTime, zijn gevuld zoals verwacht en of de dataformaten kloppen.
- Verwerk de data indien nodig: De query levert data op in een formaat dat geschikt is voor process mining. De functies
CASTenCONCATzorgen voor consistente datatypen. Na uitvoering is normaal gesproken geen grote nabewerking nodig. - Exporteer het event log: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Gebruik UTF-8 als bestandsencoding om problemen met tekens te voorkomen.
- Bereid de upload voor: Controleer vóór het uploaden naar een process-miningtool of het CSV-bestand de juiste kopteksten bevat (
PurchaseRequisitionId,ActivityName,EventTime, enzovoort) en of de datum- en tijdnotatie vanEventTimeconsistent is en door het doelplatform wordt ondersteund. - Upload naar ProcessMind: Upload het definitieve CSV-bestand naar je ProcessMind-project. Configureer het project door
PurchaseRequisitionIdals Case ID,ActivityNameals Activity enEventTimeals Timestamp te koppelen.
Configuratie
- Belangrijkste CDS-views: Voor de extractie worden vooral
I_PurchaseRequisitionAPI01voor de basisdata van aanvragen,I_ChangeDocumentenI_ChangeDocumentItemvoor het volgen van wijzigingen en statusupdates, enI_PurchaseOrderItemAPI01voor de koppeling met inkooporders gebruikt. - Autorisatie: De gebruiker die de extractie uitvoert, heeft leestoegang nodig tot de genoemde CDS-views. Vraag je SAP-securityteam welke rollen en autorisaties nodig zijn.
- Filter op periode: Het is belangrijk om een periodefilter toe te passen op de aanmaakdatum van de aanvraag (
CreationDate) om de hoeveelheid data te beperken. Voor een eerste analyse raden we 3 tot 6 maanden data aan. - Organisatiefilter: Filter op
CompanyCodeom het proces voor de juiste bedrijfseenheid te analyseren. Je kunt ook filteren opPurchaseRequisitionTypeom specifieke inkoopprocessen te bekijken, bijvoorbeeld standaardgoederen versus diensten. - Configuratie van wijzigingsdocumenten: Of activiteiten zoals 'Requisition Amended' en verschillende goedkeuringsstappen worden vastgelegd, hangt ervan af of logging van wijzigingsdocumenten actief is voor de relevante velden in je SAP-systeem. Ontbreken deze events, controleer dan de systeemconfiguratie voor tabel EBAN.
- Prestaties: In zeer grote systemen met miljoenen aanvragen kan een query over een lange periode de systeemprestaties beïnvloeden. Voer de query bij voorkeur buiten piekuren uit of gebruik een niet-productieomgeving met recent vernieuwde data.
a 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 wijzigingsdocumenten en inkoopdocumentobjecten in jouw systeem worden gebruikt voor wijzigingen aan aanvragen, vrijgaveverwerking, bron toewijzen, verwijzingen naar inkooporders en afsluiting. Deze objecten en velden kunnen per release en configuratie verschillen. Vervang daarom elke placeholder tussen vierkante haken in de query door het bijbehorende object of veld uit jouw systeem.
- Gebruik in SAP GUI transactie SE16H of een goedgekeurde tool voor databasebeheer om EBAN en EBKN te bekijken. Controleer de sleutelvelden van de aanvraag en de beschikbare velden voor datum, tijd, gebruiker, status, verwijdering, vrijgave, rekeningtoewijzing en verwijzingen naar inkoopdocumenten. Gebruik SE11 of het SAP-datadictionary om velddefinities te controleren. Stel tijdens het testen geen productiegegevens bloot.
- Bepaal de geconfigureerde bron voor wijzigingsdocumenten voor aanpassingen aan aanvragen en wijzigingen in goedkeuringen. De query verwacht een genormaliseerde wijzigingsbron met de naam [Your requisition change document source]. Deze bron bevat velden voor aanvraagnummer, positienummer, gewijzigd veld, oude waarde, nieuwe waarde, wijzigingsdatum, wijzigingstijd en gebruiker. Koppel deze bron vóór uitvoering aan de relevante SAP-tabellen voor wijzigingsdocumenten of aan de CDS-view in jouw systeem.
- Bepaal de geconfigureerde workflow- of vrijgavebron voor indiening, reset van goedkeuringen, start en afronding van goedkeuringsstappen, definitieve goedkeuring en afwijzing. De query verwacht [Your requisition approval event source], met één rij per status- of vrijgaveovergang en velden voor aanvraagnummer, positienummer, eventtype, vrijgavecode of goedkeuringsgroep, goedkeurder, eventdatum, eventtijd en status. Koppel deze bron aan de vrijgave- of workflowopslag die in jouw S/4HANA-configuratie wordt gebruikt.
- Bepaal de bronnen voor bron toewijzen, 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 placeholders aan goedgekeurde tabellen of views in jouw systeem. Het aanmaken van een inkooporder moet worden weergegeven door een expliciete verwijzing van de inkooporderpositie naar de aanvraagpositie. Leid dit niet af uit niet-gerelateerde inkoopactiviteiten.
- Stel het extractievenster in met [Start date] en [End date]. Voor de eerste run 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 aanvraag-ID als Case ID.
- Voer de query uit in een goedgekeurde SQL-client die met SAP HANA is verbonden. Vervang alleen verbindingsgegevens buiten de query, datumparameters, bedrijfsspecifieke filters en de expliciet beschreven placeholders voor bronnen en velden. Laat de uitvoerkolommen exact staan als PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount en RequisitionStatus.
- Controleer dubbele events, timestampprecisie, tijdzoneverwerking en de granulariteit op positie- versus documentniveau. De query levert documentniveau-Case ID's op en gebruikt de positiecontext intern. Als meerdere posities dezelfde activiteit en timestamp opleveren, behoud dan afzonderlijke rijen, tenzij je ProcessMind-ontwerp expliciet deduplicatie vereist.
- Controleer of elke vereiste activiteit als waarde in ActivityName voorkomt, of EventTime is gevuld 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 door ProcessMind ondersteund tabelindeling. Voeg een koptekst toe, behoud ISO-compatibele timestamps, laat null-waarden leeg en upload het bestand met PurchaseRequisitionId als Case ID, ActivityName als activity-kolom en EventTime als timestamp-kolom.
Configuratie
- Case identifier: Gebruik het documentnummer van de inkoopaanvraag uit EBAN, weergegeven als PurchaseRequisitionId. Als het proces op positieniveau is ingericht, gebruik dan een gedocumenteerde samengestelde sleutel, zoals aanvraagnummer plus positienummer, en pas dezelfde sleutel toe op elk event.
- Primaire bron: EBAN bevat de gegevens van aanvraagposities. EBKN wordt gebruikt voor rekeningtoewijzing en verrijking met afdeling of kostenplaats. Controleer de exacte veldnamen en datatypen in het SAP-datadictionary voordat je de query uitvoert.
- Eventbronnen: De query gebruikt bewust duidelijke placeholders voor bronnen van wijzigingen, goedkeuringen, bron toewijzen, verwijzingen naar inkooporders en afsluiting. Deze bronnen hangen af van de S/4HANA-release, het workflowontwerp, de vrijgaveprocedure, geactiveerde bedrijfsfuncties en klantspecifieke uitbreidingen.
- Periode: Begin met drie tot zes maanden. Gebruik waar mogelijk een begrensde periode op geïndexeerde velden of datumvelden die partition pruning ondersteunen. Laat extractievensters bij incrementele loads voldoende overlappen om laat binnengekomen wijzigingen mee te nemen. Verwijder daarna dubbele records op basis van case, activiteit, timestamp, positie en de sleutel van het bron-event.
- Bedrijfsfilters: Configureer [Company code filter], [Document type filter], [Purchasing group filter] en [Plant filter] alleen als deze velden beschikbaar zijn en hun betekenis voor de bedrijfsvoering is bevestigd. Filter niet op status als je de volledige levenscyclus wilt vastleggen.
- Statusmapping: Configureer de waarden voor In Approval, final approved, rejected, reset, pending release code en closed volgens de vrijgavestrategie of workflowconfiguratie in het doelsysteem. Ga er niet van uit dat één statuscode in alle SAP-clients hetzelfde is.
- Mapping van aanpassingen: Neem wijzigingen op in hoeveelheid, prijs, materiaal, leverdatum, rekeningtoewijzing en andere velden die jouw proces als sleutelvelden definieert. De query bevat expliciete voorwaarden voor de genoemde sleutelvelden en vereist dat de bron de naam van het gewijzigde veld beschikbaar maakt.
- Timestampverwerking: Combineer eventdatum en eventtijd in de tijdzone van de database en documenteer daarna elke omzetting naar UTC. Als een bron alleen een datum opslaat, gebruik dan alleen middernacht als er geen nauwkeurigere timestamp beschikbaar is en leg deze beperking vast.
- Prestaties: Beperk de eerste extractie op periode en bedrijfsbereik, selecteer alleen de benodigde kolommen, vermijd onbeperkte joins met grote wijzigings- of workflowhistorieën en controleer het uitvoeringsplan van HANA. Materialiseer of stage genormaliseerde eventbronnen als je de extractie vaker uitvoert.
- Autorisaties en vereisten: Regel leestoegang tot EBAN, EBKN, de geconfigureerde wijzigings- en workflowbronnen, gegevens voor bron toewijzen, gegevens met verwijzingen naar inkooporders en afsluitgegevens. Controleer of directe databasetoegang is goedgekeurd, de relevante inkoop- en workflowfunctionaliteit actief is en eventuele vereiste SAP HANA-databaselicenties of beheertools beschikbaar zijn.
- Beveiliging: Pas het principe van minimale rechten toe, bescherm gebruikers- en goedkeurders-ID's en volg de organisatieregels voor het extraheren van inkoop- en financiële informatie.
a 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 aan de slag te gaan?
Gebruik deze template om je data goed voor te bereiden en meer uit process mining te halen voor je Purchase to Pay-aanvraagproces. Begin vandaag nog met optimaliseren.
Stop vertragingen in P2P-requisitions: optimaliseer je workflow nu!
Maak processen efficiënter, verkort doorlooptijden en verminder de cyclustijd met 30%.
Je hebt geen creditcard nodig. Je bent in 5 minuten klaar met instellen.