Jouw datatemplate voor Purchase-to-Pay-requisitions
Jouw datatemplate voor Purchase-to-Pay-requisitions
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten voor process discovery
- Richtlijnen voor data-extractie
Purchase to Pay - Requisition-attributen
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteitsnaam
ActivityName
|
De naam van een specifieke bedrijfsgebeurtenis of taak die tijdens de levenscyclus van de inkoopaanvraag plaatsvond. | ||
|
Beschrijving
De Activity Name beschrijft een afzonderlijke stap in het aanvraagproces, zoals 'Requisition Created', 'Approval Step Approved' of 'Purchase Order Created'. Deze activiteiten vormen de bouwstenen van de proceskaart en staan voor het werk dat wordt uitgevoerd. Door deze activiteiten te analyseren, kun je de procesroute visualiseren, bottlenecks identificeren en meten hoeveel tijd verschillende fasen kosten. De volgorde van activiteiten voor een bepaalde Purchase Requisition ID bepaalt de route van die aanvraag. Die route kun je vervolgens vergelijken met standaardprocedures om afwijkingen of inefficiënties te vinden.
Waarom dit belangrijk is
Het definieert de stappen in het proces en maakt visualisatie van proceskaarten, analyse van procesvarianten en identificatie van bottlenecks mogelijk.
Waar je het vindt
Dit wordt meestal afgeleid uit een combinatie van de transactiestatus, systeemlogboekvermeldingen, workflowgeschiedenis of aangepaste eventtracking binnen NetSuite.
Voorbeelden
Aanvraag aangemaaktGoedkeuringsstap goedgekeurdAanvraag gewijzigdInkooporder aangemaakt
|
|||
|
Eventtijd
EventTime
|
De precieze datum en tijd waarop de activiteit plaatsvond. | ||
|
Beschrijving
Eventtijd, of de timestamp, legt het exacte moment vast waarop een activiteit plaatsvond. Deze tijdsdata is belangrijk om de dynamiek van het requisitionproces te begrijpen, waaronder de doorlooptijd, de volgorde van events en de timing. Bij procesanalyse worden timestamps gebruikt om doorlooptijden, wachttijden tussen activiteiten en naleving van service level agreements te berekenen. Ze vormen de basis voor alle tijdgebaseerde analyses. Zo kun je dashboards maken zoals 'Doorlooptijd van requisitiongoedkeuring' en KPI's zoals 'Gemiddelde doorlooptijd van requisitions'. Nauwkeurige timestamps zijn essentieel voor een betrouwbaar procesmodel.
Waarom dit belangrijk is
Deze timestamp vormt de basis voor alle prestatieanalyses, zoals het berekenen van doorlooptijden, het identificeren van vertragingen en het meten van procesefficiëntie.
Waar je het vindt
Deze timestamp wordt vastgelegd in systeemvelden zoals 'Date Created' of in de timestamps die beschikbaar zijn in de System Notes of workflowuitvoeringslogboeken voor elke transactie.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
ID inkoopaanvraag
PurchaseRequisitionId
|
De unieke identificatie voor elke inkoopaanvraag, die als primaire case-ID voor procesanalyse dient. | ||
|
Beschrijving
De Purchase Requisition ID is de centrale identificatie die alle activiteiten en gebeurtenissen voor een specifieke aanvraag van goederen of diensten koppelt. Elke aanvraag krijgt bij het aanmaken in NetSuite een unieke ID die gedurende de hele levenscyclus gelijk blijft. Bij process mining is dit attribuut de basis voor het koppelen van cases. Hiermee reconstrueer je de volledige route van elke aanvraag, van het eerste aanmaken via alle goedkeuringsstappen en wijzigingen tot de uiteindelijke uitkomst, zoals goedkeuring, afwijzing of omzetting in een inkooporder. Analyse op basis van deze ID is nodig om levenscyclusduren te berekenen, statuswijzigingen te volgen en varianten in procesroutes te identificeren.
Waarom dit belangrijk is
Dit is de sleutel om de volledige levenscyclus van één inkoopaanvraag te volgen. Zo kun je procesroutes analyseren en metrics op caseniveau berekenen.
Waar je het vindt
Dit is de interne ID of het transactienummer van het Purchase Requisition-record in NetSuite. Je vindt dit meestal in het veld 'tranid' van de transactie.
Voorbeelden
PR-001254PR-001255PR-001256
|
|||
|
Aanvrager
Requester
|
De medewerker die de purchase requisition heeft aangemaakt en ingediend. | ||
|
Beschrijving
De aanvrager start het inkoopproces door de requisition aan te maken. Dit is meestal een medewerker die bepaalde goederen of diensten nodig heeft om het werk uit te voeren. Analyse van data per aanvrager is belangrijk om patronen in gebruikersgedrag te herkennen. Zo kun je dashboards maken zoals 'Prestaties en trainingsbehoeften van aanvragers'. Die laten zien welke personen vaak worden afgewezen of regelmatig wijzigingen indienen. Deze inzichten helpen bepalen waar extra training of duidelijkere richtlijnen de kwaliteit van de eerste indiening en de efficiëntie van het proces kunnen verbeteren.
Waarom dit belangrijk is
Identificeert de initiator van het proces. Dit is belangrijk voor het analyseren van gebruikersgedrag, afwijzingspercentages per aanvrager en trainingsbehoeften.
Waar je het vindt
Dit is meestal het veld 'Employee' of 'Created By' op het transactierecord van de Purchase Requisition.
Voorbeelden
John SmithJane DoePeter Jones
|
|||
|
Afdeling
Department
|
De bedrijfsafdeling waartoe de requisition of aanvrager behoort. | ||
|
Beschrijving
Het attribuut Department staat voor de organisatie-eenheid die aan de purchase requisition is gekoppeld. Meestal is dat de afdeling van de aanvrager. Met deze informatie kun je het proces vanuit organisatorisch perspectief segmenteren en analyseren. Het is een belangrijke dimensie voor analyses zoals het vergelijken van goedkeuringsdoorlooptijden tussen afdelingen, het begrijpen van uitgavenpatronen en het identificeren van afdelingen met de hoogste afwijzingspercentages. Met deze segmentatie kan het management bronnen toewijzen, trainingen afstemmen en workflows per bedrijfsonderdeel optimaliseren.
Waarom dit belangrijk is
Maakt een gerichte segmentatie van de procesdata mogelijk, zodat je prestaties, kosten en compliance tussen verschillende bedrijfsonderdelen kunt vergelijken.
Waar je het vindt
Deze informatie is vaak gekoppeld aan het medewerkersrecord van de aanvrager of kan rechtstreeks worden ingesteld in de transactiekop van de Purchase Requisition.
Voorbeelden
MarketingITFinanciënBedrijfsvoering
|
|||
|
Requisitionstatus
RequisitionStatus
|
Geeft de huidige status van de requisition in de levenscyclus aan. | ||
|
Beschrijving
Requisition Status geeft op elk moment aan waar een purchase requisition zich in het proces bevindt. Veelvoorkomende statussen zijn 'Pending Approval', 'Fully Approved', 'Rejected' en 'Closed'. Met dit attribuut kun je dashboards maken zoals 'Requisitionstatus en ouderdom'. Daarmee volg je actieve requisitions en zie je hoe lang ze al in hun huidige status staan. Analyse van statusovergangen is een belangrijk onderdeel van process discovery. Zo krijg je zicht op zowel de normale routes als de uitzonderingen. De status wordt ook gebruikt om de uiteindelijke uitkomst van een case te bepalen.
Waarom dit belangrijk is
Geeft een momentopname van de voortgang van een case. Zo kun je verouderde requisitions analyseren en zien waar cases vastlopen.
Waar je het vindt
Dit is het veld 'Status' of 'Approval Status' in de transactiekop van de Purchase Requisition.
Voorbeelden
Wacht op goedkeuringVolledig goedgekeurdAfgewezenGesloten
|
|||
|
Totaalbedrag
TotalAmount
|
De totale geldwaarde van de purchase requisition. | ||
|
Beschrijving
Dit attribuut bevat de totale kosten van alle items op de purchase requisition. Het is een belangrijk financieel dataveld dat het proces vaak beïnvloedt, bijvoorbeeld doordat verschillende goedkeuringsworkflows worden gestart op basis van waardedrempels. Met een analyse van het totaalbedrag krijg je inzicht in uitgavenpatronen en financiële impact. Je kunt requisitions filteren op waarde, procesafwijkingen koppelen aan aanvragen met een hoge waarde en analyses prioriteren op financieel belangrijke cases. Dit is een essentieel attribuut voor financiële procesanalyses en compliance-analyses.
Waarom dit belangrijk is
Biedt financiële context. Zo kun je analyses uitvoeren op basis van waarde, die vaak de goedkeuringsroute en bedrijfsprioriteit bepaalt.
Waar je het vindt
Dit is een standaardveld op het Purchase Requisition-record, vaak met de naam 'Total' of een vergelijkbare variant.
Voorbeelden
500.001250.7525000.00
|
|||
|
Bronsysteem
SourceSystem
|
Identificeert het bronsysteem waaruit de data is geëxtraheerd. | ||
|
Beschrijving
Dit attribuut geeft aan uit welk systeem de procesdata afkomstig is, in dit geval NetSuite. Het is vooral nuttig in omgevingen waar data uit meerdere systemen wordt gecombineerd voor een integraal procesoverzicht. Bij een analyse van één systeem lijkt deze waarde misschien statisch, maar ze biedt belangrijke context en is een best practice voor datagovernance en traceerbaarheid. Zo kun je de herkomst van de data bevestigen en tijdens de analyse controleren of systeemspecifieke logica of transformaties goed worden geïnterpreteerd.
Waarom dit belangrijk is
Biedt belangrijke context over de herkomst van de data en zorgt voor duidelijkheid en goede governance, vooral in omgevingen met meerdere systemen.
Waar je het vindt
Dit is de statische waarde 'NetSuite', die tijdens het proces van data-extractie en -transformatie moet worden toegevoegd.
Voorbeelden
NetSuiteNetSuite SuitePeopleNetSuite ERP
|
|||
|
Doorlooptijd
CycleTime
|
De totale verstreken tijd vanaf het aanmaken tot de definitieve afhandeling van een requisition. | ||
|
Beschrijving
Cycle Time is een berekende metriek die de totale duur van het purchase-requisitionproces voor één case meet. Meestal wordt deze berekend als het tijdsverschil tussen de eerste activiteit, bijvoorbeeld 'Requisition Created', en de laatste afsluitende activiteit, zoals 'Requisition Fully Approved' of 'Requisition Finally Rejected'. Dit is een belangrijke KPI voor de algehele procesefficiëntie. De metriek wordt gebruikt voor de KPI 'Gemiddelde doorlooptijd van requisitions' en helpt trends, uitschieters en het effect van procesverbeteringen te herkennen. Analyse van de verdeling van doorlooptijden kan requisitions met een uitzonderlijk lange doorlooptijd zichtbaar maken. Die drukken de gemiddelde prestaties vaak sterk.
Waarom dit belangrijk is
Meet rechtstreeks de end-to-end-efficiëntie van het proces. Dit is een kernmetriek voor het herkennen van vertragingen en het beoordelen van de totale prestaties.
Waar je het vindt
Dit is een berekend attribuut dat wordt afgeleid door de timestamp van het eerste event af te trekken van de timestamp van het laatste event voor elke 'PurchaseRequisitionId'.
Voorbeelden
25920060480086400
|
|||
|
Goedkeurder
Approver
|
De medewerker of gebruiker die verantwoordelijk is voor het goedkeuren of afwijzen van een goedkeuringsstap. | ||
|
Beschrijving
De goedkeurder is de persoon die een purchase requisition in een specifieke fase van de goedkeuringsworkflow beoordeelt en afhandelt. Eén requisition kan meerdere goedkeurders hebben, elk gekoppeld aan een andere goedkeuringsactiviteit. Dit attribuut is belangrijk voor het analyseren van het goedkeuringsproces zelf. Je kunt er dashboards mee maken zoals 'Verdeling van doorlooptijden per goedkeuringsstap'. Daarmee zie je knelpunten bij individuele goedkeurders of groepen. Door bij te houden wie goedkeuringen uitvoert, kun je verantwoordelijkheden duidelijk maken, werk verdelen en vertragingen door specifieke goedkeurders herkennen.
Waarom dit belangrijk is
Identificeert de gebruiker die goedkeuringstaken uitvoert. Dit is belangrijk voor het analyseren van prestaties, werkbelasting en knelpunten bij goedkeurders.
Waar je het vindt
Deze informatie staat vaak in het workflowuitvoeringslogboek of in de System Notes die aan wijzigingen van de goedkeuringsstatus zijn gekoppeld. Ze kan ook zijn opgeslagen in aangepaste recordvelden voor de goedkeuringsworkflow.
Voorbeelden
Sarah JenkinsDavid ChenGoedkeuringsgroep financiën
|
|||
|
Is herstelwerk
IsRework
|
Een boolean-vlag die aangeeft of de requisition een afwijzings- en opnieuw-indieningscyclus heeft doorlopen. | ||
|
Beschrijving
Is Rework is een afgeleid boolean-attribuut dat de waarde true krijgt als een purchase requisition op enig moment is afgewezen en daarna is aangepast of opnieuw ter goedkeuring is ingediend. Het identificeert cases waarvoor meer werk en afhandeling nodig waren dan op de normale route. Met dit attribuut kun je procesinefficiëntie eenvoudiger analyseren. Het wordt gebruikt voor de KPI 'Aantal afwijzingscycli in het goedkeuringsproces' en helpt de impact van afwijzingen op het totale proces te kwantificeren. Door te filteren op cases waarbij Is Rework true is, kunnen analisten problematische procesvarianten isoleren en de oorzaken van de eerste afwijzingen onderzoeken, zoals slechte datakwaliteit of onduidelijkheid over beleid.
Waarom dit belangrijk is
Helpt de frequentie en impact van herstelwerklussen te kwantificeren. Zulke lussen zijn een belangrijke bron van inefficiëntie en vertraging.
Waar je het vindt
Dit is een berekend attribuut. De logica controleert of voor dezelfde case een activiteit 'Requisition Submitted for Approval' plaatsvindt na een activiteit 'Approval Step Rejected'.
Voorbeelden
truefalse
|
|||
|
Itemcategorie
ItemCategory
|
De categorie van de goederen of diensten die op de requisition worden aangevraagd. | ||
|
Beschrijving
Item Category deelt de items op een purchase requisition in logische groepen in, zoals 'IT Hardware', 'Office Supplies' of 'Professional Services'. Dit kan worden afgeleid uit de itemrecords die aan de requisitionregels zijn gekoppeld. Met dit attribuut kun je het requisitionproces gedetailleerder analyseren. Je kunt bijvoorbeeld nagaan of requisitions voor IT-hardware langer op goedkeuring wachten dan aanvragen voor kantoorbenodigdheden. Door het proces op Item Category te segmenteren, kunnen bedrijven knelpunten per categorie herkennen, uitgaven per categorie analyseren en hun inkoopstrategie daarop afstemmen.
Waarom dit belangrijk is
Maakt analyse mogelijk op basis van wat er wordt ingekocht. Zo kun je knelpunten of complianceproblemen per categorie herkennen.
Waar je het vindt
Deze informatie wordt afgeleid uit de 'Item'-records die op regelniveau aan de Purchase Requisition zijn gekoppeld. De categorie zelf kan een standaardveld of aangepast veld op het Item-record zijn.
Voorbeelden
IT-hardwareSoftwarelicentiesKantoorbenodigdhedenMarketingdiensten
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor het laatst uit het bronsysteem is geëxtraheerd of vernieuwd. | ||
|
Beschrijving
Dit attribuut legt de datum en tijd vast van de meest recente data-extractie uit NetSuite. Het is een belangrijk stukje metadata voor elk process mining-dashboard of elke analyse. Deze timestamp geeft context bij de actualiteit van de data. Zo kunnen gebruikers zien of ze realtime-informatie bekijken of een momentopname van een specifiek tijdstip. De timestamp is belangrijk voor datavalidatie en om stakeholders te laten weten hoe actueel de inzichten uit de procesanalyse zijn.
Waarom dit belangrijk is
Laat gebruikers zien hoe actueel de data is, zodat ze begrijpen hoe recent de procesinzichten zijn.
Waar je het vindt
Deze timestamp wordt gegenereerd en toegevoegd tijdens het proces van data-extractie, -transformatie en -laden (ETL).
Voorbeelden
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
|
|||
|
Naam leverancier
VendorName
|
De naam van de voorgestelde of voorkeursleverancier voor de requisition. | ||
|
Beschrijving
Het attribuut Vendor Name identificeert de leverancier bij wie de goederen of diensten naar verwachting worden ingekocht. Hoewel een requisition een intern document is, wordt vaak een voorkeursleverancier opgegeven. Analyse van dit attribuut kan patronen in leveranciersbeheer zichtbaar maken. Je kunt zien welke leveranciers het vaakst worden aangevraagd, of requisitions voor bepaalde leveranciers langer op goedkeuring wachten en of de afspraken met voorkeursleveranciers worden nageleefd. Deze informatie is nuttig voor strategische inkoop en het beheer van leveranciersrelaties.
Waarom dit belangrijk is
Helpt inkoop patronen per leverancier te analyseren, naleving van voorkeursleveranciers te controleren en procesverschillen per leverancier te herkennen.
Waar je het vindt
Dit kan een veld 'Vendor' op kopniveau zijn of op de regels van het Purchase Requisition-record worden opgegeven.
Voorbeelden
Dell Inc.StaplesMcKinsey & Company
|
|||
|
Purchase Order-ID
PurchaseOrderId
|
De identifier van de purchase order die vanuit de goedgekeurde requisition is aangemaakt. | ||
|
Beschrijving
De Purchase Order-ID is de unieke identifier van de purchase order die na goedkeuring van een requisition is aangemaakt. Dit attribuut vormt de koppeling tussen het requisitionproces en de daaropvolgende inkoopactiviteiten. Bij procesanalyse is deze koppeling belangrijk voor end-to-end P2P-analyse. Je kunt er de KPI 'Doorlooptijd tot aanmaak van de PO' mee berekenen door de tijd tussen goedkeuring van de requisition en aanmaak van de PO te meten. Ook kun je de 'Conversieratio van requisition naar PO' berekenen. Die laat zien hoe effectief requisitions worden omgezet in uitvoerbare orders.
Waarom dit belangrijk is
Koppelt de requisition aan de bijbehorende purchase order. Zo kun je de doorlooptijd tot aanmaak van de PO meten en het volledige proces analyseren.
Waar je het vindt
Dit staat op het Purchase Requisition-record, vaak op een subtab met gerelateerde records of via een link 'Created From' op de Purchase Order zelf.
Voorbeelden
PO-005432PO-005433PO-005434
|
|||
|
Reden van afwijzing
RejectionReason
|
De toelichting die een goedkeurder geeft wanneer een requisition wordt afgewezen. | ||
|
Beschrijving
Rejection Reason is een tekstattribuut waarin een goedkeurder kan aangeven waarom een purchase requisition niet aan de goedkeuringsvoorwaarden voldeed. Dit biedt kwalitatieve context bij de activiteit 'Approval Step Rejected'. Deze informatie is zeer waardevol voor oorzaakanalyse. Je kunt er dashboards mee maken zoals 'Analyse van het afwijzingspercentage van requisitions'. Die laten niet alleen zien wat is afgewezen, maar ook waarom. Veelvoorkomende redenen zijn bijvoorbeeld 'Incorrect GL Account', 'Budget Exceeded' of 'Insufficient Detail'. Door deze redenen te analyseren, kun je structurele problemen herkennen, gebruikers beter trainen en indieningsrichtlijnen verbeteren. Zo verminder je herstelwerk en afwijzingen.
Waarom dit belangrijk is
Biedt belangrijke context over de oorzaken van afwijzingen. Zo kun je de oorzaken analyseren, toekomstige afwijzingen verminderen en de kwaliteit van de eerste indiening verbeteren.
Waar je het vindt
Dit wordt vaak vastgelegd in een veld 'Memo' tijdens de afwijzingsactie of in een aangepast veld dat aan de goedkeuringsworkflow is toegevoegd. Je kunt het ook terugvinden in de System Notes.
Voorbeelden
Budget overschredenOnjuiste leverancier geselecteerdOntbrekende artikelgegevensDubbel verzoek
|
|||
|
Route van de goedkeuringsworkflow
ApprovalWorkflowPath
|
Een weergave van de volgorde van goedkeuringsstappen die een requisition heeft doorlopen. | ||
|
Beschrijving
Approval Workflow Path is een afgeleid attribuut dat de volgorde van goedkeuringsactiviteiten of statussen voor een bepaalde requisition samenvoegt, zoals 'Submitted -> Manager Approval -> Finance Approval'. Zo ontstaat een unieke handtekening van de route die elke case heeft gevolgd. Dit attribuut vormt de basis voor conformance checking en variantanalyse. Het ondersteunt rechtstreeks de dashboards 'Niet-conforme requisitionroutes' en 'Compliance van goedkeuringsworkflows'. Je kunt cases eenvoudig filteren en groeperen op hun exacte procesflow. Door werkelijke routes te vergelijken met vooraf gedefinieerde standaardroutes, kunnen organisaties compliance kwantificeren en de oorzaken van afwijkingen onderzoeken.
Waarom dit belangrijk is
Maakt gerichte variantanalyse en conformance checking mogelijk door de exacte volgorde van goedkeuringsstappen per case samen te vatten.
Waar je het vindt
Dit is een afgeleid attribuut dat wordt berekend door de waarden van 'ActivityName' voor elke 'PurchaseRequisitionId' in chronologische volgorde samen te voegen.
Voorbeelden
Aangemaakt > Ingediend > GoedgekeurdAangemaakt > Ingediend > Afgewezen > Gewijzigd > Ingediend > GoedgekeurdAangemaakt > Ingediend > Goedgekeurd > Ingetrokken
|
|||
|
Urgentieniveau
UrgencyLevel
|
Een classificatie van de prioriteit van de requisition, zoals Standard of Urgent. | ||
|
Beschrijving
Urgency Level is een categorisch attribuut dat de bedrijfsprioriteit van een purchase requisition aangeeft. Hiermee kunnen medewerkers aanvragen markeren die vanwege een dringende bedrijfsbehoefte sneller moeten worden afgehandeld. Dit attribuut ondersteunt specifiek het dashboard 'Prestaties bij de afhandeling van urgente aanvragen' en de KPI 'Afhandelingstijd van urgente requisitions'. Door de procesdata op dit attribuut te filteren, kunnen analisten de doorlooptijden en procesroutes van urgente aanvragen vergelijken met die van standaardaanvragen. Zo zie je of prioriteitsafhandeling werkt of dat knelpunten nog steeds voor vertraging zorgen.
Waarom dit belangrijk is
Maakt het mogelijk om de procesprestaties van aanvragen met hoge prioriteit te vergelijken met die van standaardaanvragen, zodat dringende behoeften efficiënt worden afgehandeld.
Waar je het vindt
Dit is meestal een aangepast transactielichaamveld op het Purchase Requisition-formulier.
Voorbeelden
HoogGemiddeldLaag
|
|||
|
Valuta
Currency
|
De valutacode voor het totaalbedrag van de requisition. | ||
|
Beschrijving
Het attribuut Currency geeft aan in welke valuta de financiële waarden van de requisition zijn uitgedrukt, zoals USD, EUR of GBP. Dit is vooral belangrijk voor multinationale organisaties die met meerdere valuta werken. Dit veld zorgt ervoor dat financiële data correct wordt geïnterpreteerd. In process mining maakt het een juiste aggregatie en vergelijking van geldbedragen mogelijk. Je kunt alle bedragen omrekenen naar één basisvaluta of de analyse per valuta segmenteren. Zo voorkom je onjuiste financiële rapportages en houd je wereldwijd inzicht in de data.
Waarom dit belangrijk is
Essentieel voor een nauwkeurige financiële analyse in multinationale organisaties, zodat geldbedragen correct worden geïnterpreteerd en samengevoegd.
Waar je het vindt
Dit is een standaardveld 'Currency' op het transactierecord van de Purchase Requisition, vooral in NetSuite-instanties met meerdere valuta.
Voorbeelden
USDEURGBP
|
|||
Purchase to Pay - Requisition-activiteiten
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Aanvraag aangemaakt
|
Een gebruiker start het inkoopproces door een nieuwe inkoopaanvraag aan te maken en op te slaan. Dit is de eerste gebeurtenis in de levenscyclus van de aanvraag en wordt vastgelegd wanneer het transactierecord voor het eerst in NetSuite wordt opgeslagen. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert de officiële start van het inkoopproces voor een specifieke behoefte. Door de tijd tussen aanmaken en indienen te analyseren, kun je vertragingen in de gegevensinvoer of het formuleren van de eerste aanvraag opsporen.
Waar je het vindt
Deze gebeurtenis wordt vastgelegd via de timestamp van de aanmaakdatum van het Purchase Requisition-transactierecord. Je vindt deze in de hoofdkop van het record of op de System Notes-subtab, waar de actie 'Create' wordt geregistreerd.
Vastleggen
Gebruik het veld 'Date Created' op het Purchase Requisition-record.
Eventtype
explicit
|
|||
|
Aanvraag definitief afgewezen
|
De inkoopaanvraag wordt definitief afgewezen en niet verder verwerkt. Deze gebeurtenis wordt afgeleid wanneer de definitieve 'Approval Status' van de aanvraag wordt bijgewerkt naar 'Rejected'. | ||
|
Waarom dit belangrijk is
Deze activiteit is het eindpunt van een niet-succesvolle aanvraag. Als je begrijpt waarom en wanneer aanvragen definitief worden afgewezen, krijg je inzicht in naleving van beleid en budgetproblemen.
Waar je het vindt
Afgeleid uit de System Notes-subtab door de timestamp te identificeren waarop het veld 'Approval Status' de definitieve status 'Rejected' krijgt.
Vastleggen
Timestamp waarop 'Approval Status' verandert in 'Rejected'.
Eventtype
inferred
|
|||
|
Aanvraag gesloten
|
De aanvraag wordt formeel gesloten. Dat betekent dat er geen verdere actie wordt verwacht. Dit gebeurt vaak automatisch nadat alle hoeveelheden op de aanvraag via gekoppelde inkooporders zijn besteld. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert het definitieve einde van de levenscyclus van de aanvraag. Het bevestigt dat aan de bedrijfsbehoefte is voldaan en dat het record is afgerond.
Waar je het vindt
Afgeleid uit de System Notes-subtab door de timestamp te identificeren waarop het veld 'Status' op regelniveau of kopniveau wordt bijgewerkt naar 'Closed'.
Vastleggen
Timestamp waarop het veld 'Status' verandert in 'Closed'.
Eventtype
inferred
|
|||
|
Aanvraag volledig goedgekeurd
|
De inkoopaanvraag doorloopt alle vereiste stappen in de goedkeuringsworkflow succesvol. Dit wordt afgeleid wanneer de definitieve 'Approval Status' van het record verandert in 'Approved'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijk mijlpaal: de aanvraag is klaar om te worden omgezet in een inkooporder. Het markeert het einde van de goedkeuringscyclus en het begin van de fase waarin de inkoop wordt uitgevoerd.
Waar je het vindt
Afgeleid uit de System Notes-subtab door de timestamp te identificeren waarop het veld 'Approval Status' de definitieve status 'Approved' krijgt.
Vastleggen
Timestamp waarop 'Approval Status' verandert in 'Approved'.
Eventtype
inferred
|
|||
|
Inkooporder aangemaakt
|
Van de volledig goedgekeurde aanvraag wordt een inkooporder (PO) gemaakt, waarmee budget officieel aan een leverancier wordt toegewezen. Dit is een expliciete gebeurtenis: er wordt een nieuw PO-transactierecord aangemaakt dat naar de oorspronkelijke aanvraag verwijst. | ||
|
Waarom dit belangrijk is
Dit is het belangrijkste resultaat van een succesvolle aanvraag en een belangrijke overdracht in het Purchase to Pay-proces. De tijd tussen goedkeuring en het aanmaken van de PO is een belangrijke KPI voor de efficiëntie van inkoop.
Waar je het vindt
Identificeer dit door een Purchase Order-record te vinden waarvan het veld 'Created From' of een vergelijkbaar koppelveld naar de Purchase Requisition ID verwijst. De aanmaakdatum van die PO is de timestamp voor deze activiteit.
Vastleggen
Zoek de PO waarvan het veld 'Created From' gelijk is aan de Requisition ID en gebruik 'Date Created' van de PO.
Eventtype
explicit
|
|||
|
Aanvraag gewijzigd
|
Een gebruiker wijzigt een veld op de inkoopaanvraag nadat deze voor het eerst is aangemaakt, vaak na een afwijzing of door veranderde vereisten. Deze gebeurtenis wordt rechtstreeks vastgelegd in de audittrailfunctie van NetSuite. | ||
|
Waarom dit belangrijk is
Het volgen van wijzigingen is belangrijk om herstelwerklussen en problemen met de datakwaliteit op te sporen. Een hoge wijzigingsfrequentie kan wijzen op onduidelijke eerste vereisten of een trainingsbehoefte bij aanvragers.
Waar je het vindt
Vastgelegd op de System Notes-subtab van het Purchase Requisition-record. Elke vermelding met een 'Type' van 'Change' of 'Edit' op een relevant veld geldt als een wijziging.
Vastleggen
Registreer een gebeurtenis voor elke vermelding van het type 'Change' in de System Notes-log.
Eventtype
explicit
|
|||
|
Aanvraag ingetrokken
|
De oorspronkelijke aanvrager of een beheerder annuleert de aanvraag voordat deze volledig is goedgekeurd of in een inkooporder is omgezet. Dit wordt meestal afgeleid uit een statuswijziging naar 'Cancelled' of 'Withdrawn'. | ||
|
Waarom dit belangrijk is
Deze activiteit staat voor een uitzondering of beëindiging van het proces op initiatief van de aanvrager. Door ingetrokken aanvragen te analyseren, zie je waar bedrijfsbehoeften zijn veranderd of aanvragen niet meer geldig zijn.
Waar je het vindt
Afgeleid uit de System Notes-subtab door de timestamp te volgen waarop het veld 'Approval Status' wordt bijgewerkt naar een waarde zoals 'Cancelled' of een aangepaste status voor intrekking.
Vastleggen
Timestamp waarop 'Approval Status' verandert in 'Cancelled' of 'Withdrawn'.
Eventtype
inferred
|
|||
|
Aanvraag ter goedkeuring ingediend
|
De aanvrager dient de ingevulde aanvraag formeel in bij de aangewezen goedkeuringsworkflow. Dit wordt vaak afgeleid uit een statuswijziging op het aanvraagrecord, bijvoorbeeld van 'Draft' of 'Pending Submission' naar 'Pending Approval'. | ||
|
Waarom dit belangrijk is
Deze activiteit start de goedkeuringscyclus en is een belangrijk beginpunt voor het meten van goedkeuringsdoorlooptijden. Je ziet hiermee hoe lang aanvragen wachten voordat het formele goedkeuringsproces begint.
Waar je het vindt
Afgeleid uit de System Notes-subtab door de timestamp te identificeren waarop het veld 'Approval Status' voor het eerst verandert in een waarde zoals 'Pending Approval'.
Vastleggen
Identificeer de eerste timestamp waarop het veld 'Approval Status' verandert in 'Pending Approval'.
Eventtype
inferred
|
|||
|
Goedkeuringsstap afgewezen
|
Een goedkeurder wijst zijn of haar toegewezen stap af, waardoor de aanvraag meestal teruggaat naar de aanvrager voor correctie. Deze actie wordt expliciet geregistreerd door de SuiteApprovals-workflowengine. | ||
|
Waarom dit belangrijk is
Deze gebeurtenis is een belangrijke aanwijzing voor herstelwerk en inefficiëntie. Door afwijzingspunten te analyseren, zie je veelvoorkomende oorzaken, zoals beleidsovertredingen of onjuiste data.
Waar je het vindt
Vastgelegd in de SuiteApprovals-log of op de System Notes-subtab, waar de afwijzingsactie, de gebruiker die de aanvraag afwees en de timestamp worden geregistreerd.
Vastleggen
Identificeer afwijzingsacties in de SuiteApprovals-log of System Notes.
Eventtype
explicit
|
|||
|
Goedkeuringsstap gestart
|
De aanvraag komt in een specifieke fase van de goedkeuringsworkflow terecht en wacht op actie van een aangewezen goedkeurder of groep. Dit wordt meestal afgeleid wanneer de workflow de aanvraag toewijst aan de volgende goedkeurder in de reeks. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert het begin van de wachttijd voor elke afzonderlijke goedkeuringsstap. Dat is belangrijk om bottlenecks in de goedkeuringshiërarchie en trage goedkeurders op te sporen.
Waar je het vindt
Afgeleid uit workflowuitvoeringslogs of wijzigingen in een veld zoals 'Current Approver' of een workflowstatusveld. Het SuiteApprovals-platform houdt de actieve goedkeuringsstap bij.
Vastleggen
Leid dit af uit workflowlogs of uit het moment waarop het record aan een nieuwe goedkeurder wordt toegewezen.
Eventtype
inferred
|
|||
|
Goedkeuringsstap goedgekeurd
|
Een bevoegde gebruiker keurt zijn of haar toegewezen stap in de workflow goed, waardoor de aanvraag dichter bij definitieve goedkeuring komt. Het SuiteApprovals-platform van NetSuite registreert deze actie expliciet, inclusief gebruiker en timestamp. | ||
|
Waarom dit belangrijk is
Deze activiteit staat voor voortgang in de goedkeuringsketen. Door de tijd tussen goedkeuringsstappen te analyseren, krijg je zicht op de efficiëntie van de workflow en van afzonderlijke goedkeurders.
Waar je het vindt
Vastgelegd in de SuiteApprovals-log of op de System Notes-subtab, waar de goedkeuringsactie, de goedkeurder en de exacte timestamp van de gebeurtenis worden geregistreerd.
Vastleggen
Identificeer goedkeuringsacties in de SuiteApprovals-log of System Notes.
Eventtype
explicit
|
|||
Extractiegidsen
Klaar om aan de slag te gaan?
Gebruik deze template om je process mining-traject te starten en waardevolle inzichten te krijgen in je NetSuite Purchase to Pay - Requisition-proces. Begin vandaag met optimaliseren voor meer efficiëntie en snellere goedkeuringen.
Optimaliseer je Purchase to Pay - Requisition-proces. Start vandaag!
Krijg 30% snellere goedkeuringen van requisitions en elimineer bottlenecks.
Je hebt geen creditcard nodig. Begin vandaag met optimaliseren.