Jouw datatemplate voor Purchase to Pay - Purchase Order
Jouw datatemplate voor Purchase to Pay - Purchase Order
- Aanbevolen data-attributen
- Belangrijkste procesactiviteiten
- Stappen voor data-extractie uit Coupa
Purchase to Pay - attributen voor inkooporders
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
ActivityName
|
De naam van het specifieke event of de taak die op een bepaald moment tijdens de levenscyclus van de purchase order plaatsvond. | ||
|
Beschrijving
De activiteitsnaam beschrijft één stap in het purchase-to-pay-proces, zoals 'Purchase Order Approved' of 'Goods Receipt Posted'. Deze reeks activiteiten vormt de procesflow van elke purchase order. Dit attribuut is de basis van process mining. Het wordt gebruikt om de proceskaart op te bouwen, procesvarianten te ontdekken en de frequentie en volgorde van events te analyseren. Zo worden knelpunten, herstelrondes en afwijkingen van de standaardprocesflow zichtbaar. Een analyse van de reeks 'Purchase Order Changed'-activiteiten kan bijvoorbeeld inefficiënties in de nauwkeurigheid van orders aan het licht brengen.
Waarom dit belangrijk is
Het definieert de stappen in het proces. Daarmee kun je de procesflow visualiseren en knelpunten, herstelwerk en afwijkingen vinden.
Waar je het vindt
Afgeleid uit event logs, audittrails of records van statuswijzigingen die aan Purchase Order-objecten in Coupa zijn gekoppeld.
Voorbeelden
Purchase Requisition goedgekeurdPurchase Order ingediendGoederenontvangst verwerktFactuur voor PO ontvangen
|
|||
|
Inkooporder
PurchaseOrderNumber
|
De unieke identificatie van een purchase order, die als primaire case-ID voor het proces dient. | ||
|
Beschrijving
Het Purchase Order-nummer is de centrale case-ID die alle activiteiten verbindt, van de eerste aanvraag tot de definitieve bevestiging van de ontvangst van goederen of diensten. Elk uniek Purchase Order-nummer staat voor één afzonderlijke uitvoering van het inkoopproces. In een process mining-analyse is dit attribuut nodig om het volledige verloop van elke aankoop te volgen. Analisten kunnen hiermee proceskaarten visualiseren, varianten herkennen en KPI's op caseniveau berekenen, zoals de totale doorlooptijd van een order. Alle events en bijbehorende data worden onder deze identificatie samengevoegd voor een samenhangend beeld van het proces.
Waarom dit belangrijk is
Dit is nodig om de volledige levenscyclus van elke aankoop te volgen en afzonderlijke procesinstanties te reconstrueren voor een gedetailleerde analyse.
Waar je het vindt
Dit is een standaardveld voor de primaire sleutel op het Purchase Order-object in Coupa.
Voorbeelden
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Starttijd
EventTime
|
De exacte timestamp die aangeeft wanneer een activiteit of event plaatsvond. | ||
|
Beschrijving
Event Time registreert de datum en tijd waarop een specifieke activiteit is uitgevoerd. Voor elke activiteit in het proces is er een bijbehorende timestamp die het moment van uitvoering markeert. Dit attribuut is nodig voor alle tijdgebaseerde analyses in process mining. Het wordt gebruikt om doorlooptijden tussen activiteiten te berekenen, de procesduur te meten en vertragingen te vinden. Zo wordt het verschil tussen de timestamps van 'Purchase Order Drafted' en 'Purchase Order Approved' gebruikt om de KPI voor de goedkeuringsdoorlooptijd van de PO te berekenen.
Waarom dit belangrijk is
Het geeft elk event een tijdscontext. Die is nodig om doorlooptijden te berekenen, prestaties te analyseren en knelpunten te vinden.
Waar je het vindt
Te vinden in de event logs of audittrails van Coupa, meestal gekoppeld aan elke statuswijziging of actie op een purchase order.
Voorbeelden
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de procesdata is geëxtraheerd. | ||
|
Beschrijving
Dit attribuut identificeert het oorspronkelijke informatiesysteem waarin de eventdata is vastgelegd. Voor dit proces is de waarde steeds 'Coupa'. In bedrijfsomgevingen waar data uit meerdere systemen kan komen, bijvoorbeeld Coupa voor inkoop en een ander ERP-systeem voor facturatie, helpt dit attribuut om de bronnen van elkaar te onderscheiden. Het maakt de herkomst van de data duidelijk en kan worden gebruikt om de analyse te filteren op het perspectief van één specifiek systeem.
Waarom dit belangrijk is
Het geeft belangrijke context over de herkomst van de data. Zo blijft de data traceerbaar en is goed databeheer mogelijk, vooral wanneer meerdere systemen worden gebruikt.
Waar je het vindt
Dit is een statische waarde die meestal tijdens de data-extractie en -transformatie wordt toegevoegd om de dataset te labelen.
Voorbeelden
Coupa
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor dit proces voor het laatst is vernieuwd. | ||
|
Beschrijving
Dit attribuut registreert wanneer de dataset voor het laatst vanuit het bronsysteem is bijgewerkt. Het is een metadataveld dat geldt voor de volledige dataset en niet voor afzonderlijke events. In elk analytisch dashboard is deze timestamp belangrijk om te weten hoe actueel de data is. Zo zie je of de inzichten op recente informatie zijn gebaseerd en weet je wat je van de actualiteit van de data kunt verwachten. De timestamp wordt meestal duidelijk in dashboards weergegeven.
Waarom dit belangrijk is
Laat zien hoe actueel de data is. Zo weten gebruikers hoe recent de procesanalyse en KPI's zijn.
Waar je het vindt
Deze timestamp wordt aangemaakt en opgeslagen door de ETL-pijplijn voor data-extractie en -laden wanneer deze wordt uitgevoerd.
Voorbeelden
2023-11-01T05:00:00Z
|
|||
|
Afdeling
Department
|
De bedrijfsafdeling of kostenplaats waaraan de purchase order wordt toegerekend. | ||
|
Beschrijving
Het attribuut Department geeft aan welke organisatie-eenheid de aankoop heeft gestart of de kosten ervan draagt. Dit is vaak gekoppeld aan de aanvrager of aan de kostenplaatsgegevens op de orderregels. Deze dimensie is belangrijk om procesanalyses en KPI's te segmenteren. Managers kunnen hiermee procesefficiëntie, compliance en uitgavenpatronen in verschillende delen van de organisatie vergelijken. Het dashboard 'Spend Analysis by Purchase Category' gebruikt Department bijvoorbeeld om te laten zien hoe verschillende bedrijfsonderdelen hun budget besteden.
Waarom dit belangrijk is
Hiermee kun je proces- en uitgavenanalyses filteren en vergelijken tussen verschillende bedrijfsonderdelen. Zo worden verschillen in efficiëntie en compliance zichtbaar.
Waar je het vindt
Beschikbaar op de Purchase Order-header of regelitems in Coupa, vaak gekoppeld aan een Cost Center of organisatorische eenheid.
Voorbeelden
MarketingInformatietechnologieBedrijfsvoeringFinanciën
|
|||
|
Gebruiker
User
|
De gebruikers-ID of naam van de persoon die de activiteit heeft uitgevoerd, zoals een goedkeurder of aanvrager. | ||
|
Beschrijving
Dit attribuut identificeert de persoon die verantwoordelijk is voor het uitvoeren van een specifiek event in het proces. Dat kan de persoon zijn die de order opstelde, de manager die deze goedkeurde of de medewerker die de goederenontvangst verwerkte. Door prestaties per gebruiker te analyseren, kun je opleidingsbehoeften, goed presterende medewerkers en de verdeling van de werklast herkennen. Het dashboard 'PO Approval Cycle Time Performance' gebruikt dit attribuut bijvoorbeeld om goedkeuringstijden per goedkeurder uit te splitsen en zichtbaar te maken wie mogelijk een knelpunt in het proces vormt.
Waarom dit belangrijk is
Hiermee kun je procesprestaties per persoon of rol analyseren en knelpunten, opleidingsmogelijkheden en problemen met de verdeling van capaciteit vinden.
Waar je het vindt
Gekoppeld aan elk event in de audittrail of geschiedenisl logs van de Purchase Order in Coupa. Velden zoals 'Created By', 'Approved By' en 'Updated By' zijn veelgebruikte bronnen.
Voorbeelden
j.doea.smithm.jones
|
|||
|
Inkoopcategorie
PurchaseCategory
|
De classificatie van de ingekochte goederen of diensten, zoals IT Hardware of Professional Services. | ||
|
Beschrijving
Purchase Category, ook bekend als Commodity of Material Group, is een classificatie om vergelijkbare aankopen te groeperen. Met deze gestructureerde data kun je uitgaven en inkoopprocessen systematisch analyseren. Binnen process mining is dit attribuut een bruikbare dimensie voor filtering en segmentatie. Het dashboard ‘Spend Analysis by Purchase Category’ gebruikt het om uitgavenpatronen uit te splitsen. Je kunt er ook mee zien of bepaalde categorieën, zoals complexe diensten, langere doorlooptijden of hogere wijzigingspercentages hebben dan andere categorieën, zoals standaardkantoorartikelen.
Waarom dit belangrijk is
Maakt analyse van uitgaven en processen per categorie mogelijk. Zo kun je inkooppatronen herkennen, met leveranciers onderhandelen en procescontroles afstemmen.
Waar je het vindt
Meestal te vinden op het niveau van het regelitem van de Purchase Order in Coupa, vaak gekoppeld aan een commoditycode of inkoopcatalogus.
Voorbeelden
IT-hardwareKantoorbenodigdhedenProfessionele dienstverleningMarketingmaterialen
|
|||
|
Naam leverancier
VendorName
|
De naam van de leverancier van wie goederen of diensten worden ingekocht. | ||
|
Beschrijving
De naam van de leverancier identificeert de externe partij die de items op de purchase order levert. Deze informatie is essentieel voor inkoopanalyses. Door procesprestaties per leverancier te analyseren, krijg je inzicht in leveranciersrelaties. Zo kun je de ‘Supplier Lead Time Performance’ beoordelen, vertragingen in het ‘Goods Receipt Process’ identificeren en de kwaliteit van leveranciers meten met de ‘Goods Return Rate’. Dit attribuut is ook nodig voor het berekenen van de KPI ‘Spend by Non-Preferred Vendor Ratio’.
Waarom dit belangrijk is
Maakt analyse van leveranciersprestaties mogelijk. Zo kun je leveranciers beter selecteren, gunstigere voorwaarden onderhandelen en goed en minder goed presterende leveranciers identificeren.
Waar je het vindt
Een standaardveld op de Purchase Order-header in Coupa, gekoppeld aan de Supplier Master Data.
Voorbeelden
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Totale orderwaarde
TotalOrderAmount
|
De totale geldwaarde van de purchase order. | ||
|
Beschrijving
Dit attribuut staat voor de totale kosten van alle goederen en diensten in de purchase order, uitgedrukt in een specifieke valuta. Het is een attribuut op case-niveau dat voor de hele order geldt. Deze financiële data is belangrijk voor spendanalyse en voor het bepalen van prioriteiten bij procesverbetering. Voor orders met een hoge waarde zijn mogelijk extra controles of andere goedkeuringsroutes nodig. De waarde wordt rechtstreeks gebruikt in het dashboard ‘Spend Analysis by Purchase Category’ en bij het berekenen van de KPI ‘Spend by Non-Preferred Vendor Ratio’.
Waarom dit belangrijk is
Geeft financiële context bij elke aankoop. Daarmee kun je uitgaven analyseren, orders met een hoge waarde prioriteren en de financiële impact beoordelen.
Waar je het vindt
Beschikbaar op de Purchase Order-header in Coupa, meestal als ‘Total’ of ‘Grand Total’.
Voorbeelden
1500.00250.7512500.50
|
|||
|
Gewenste leverdatum
RequestedDeliveryDate
|
De datum waarop de aanvrager de goederen of diensten geleverd wil hebben. | ||
|
Beschrijving
Dit attribuut is de gewenste leverdatum die de zakelijke gebruiker tijdens het aanvraagproces heeft opgegeven. Het geeft aan wanneer de organisatie verwacht dat de order wordt uitgevoerd. Deze datum is een belangrijke referentie voor het meten van leveranciersprestaties en interne prestaties. Je gebruikt de datum rechtstreeks voor de KPI ‘Supplier Delivery Date Adherence’ door deze te vergelijken met de werkelijke datum van ‘Goods Receipt Posted’. Het dashboard ‘Delivery Date Variance and Returns’ laat afwijkingen tussen de gewenste en werkelijke leverdatum zien. Zo kun je verwachtingen beter beheren en nauwkeuriger voorspellen.
Waarom dit belangrijk is
Dient als belangrijke referentie voor het meten van tijdige levering door leveranciers en de efficiëntie van het interne ontvangstproces.
Waar je het vindt
Een standaardveld op het regelitem van de Purchase Order in Coupa.
Voorbeelden
2023-11-152023-12-012024-01-10
|
|||
|
Is goedgekeurd in één keer
IsFirstPassApproval
|
Een berekende vlag die true is als de PO na het opstellen zonder wijzigingen is goedgekeurd. | ||
|
Beschrijving
Deze booleaanse vlag krijgt de waarde true als de route van ‘Purchase Order Drafted’ naar ‘Purchase Order Approved’ geen activiteiten ‘Purchase Order Changed’ of ‘Purchase Order Rejected’ bevat. Dit attribuut meet rechtstreeks de KPI ‘First-Pass PO Approval Rate’. Een hoog percentage wijst op een efficiënt en nauwkeurig proces bij de eerste verwerking. Door cases met de waarde false te analyseren, kun je oorzaken van herstelwerk vinden en de kwaliteit van de orderdata aan het begin van het proces verbeteren.
Waarom dit belangrijk is
Meet rechtstreeks de efficiëntie van het eerste aanmaak- en goedkeuringsproces en laat zien hoeveel orders zonder herstelwerk door het proces gaan.
Waar je het vindt
Berekend tijdens de data-transformatie door de volgorde van events voor elke PurchaseOrderNumber te analyseren.
Voorbeelden
truefalse
|
|||
|
Is herstelwerk
IsRework
|
Een berekende vlag die aangeeft of een purchase order een wijzigingsactiviteit heeft gehad. | ||
|
Beschrijving
Deze booleaanse vlag krijgt de waarde true voor elke purchase order met minstens één ‘Purchase Order Changed’-event in de geschiedenis. Het is een attribuut op case-niveau dat uit het event log wordt afgeleid. Dit attribuut vereenvoudigt de berekening van KPI’s zoals ‘Purchase Order Change Rate’. Je kunt de data eenvoudig filteren en segmenteren om processen met en zonder herstelwerk te vergelijken. Zo meet je de impact van wijzigingen op doorlooptijd en kosten. Het attribuut is een belangrijk onderdeel van het dashboard ‘Purchase Order Change Analysis’.
Waarom dit belangrijk is
Vereenvoudigt de analyse van herstelwerk door alle purchase orders die minstens één keer zijn gewijzigd eenvoudig te kunnen filteren en aggregeren.
Waar je het vindt
Berekend tijdens de data-transformatie door per PurchaseOrderNumber te controleren of de activiteit ‘Purchase Order Changed’ voorkomt.
Voorbeelden
truefalse
|
|||
|
Is op tijd geleverd
IsDeliveryOnTime
|
Een berekende vlag die aangeeft of de goederen op of vóór de gewenste leverdatum zijn ontvangen. | ||
|
Beschrijving
Dit booleaanse attribuut wordt berekend door de timestamp van het event ‘Goods Receipt Posted’ te vergelijken met ‘RequestedDeliveryDate’. De waarde wordt true als de ontvangstdatum op of vóór de gewenste datum ligt. Deze vlag ondersteunt rechtstreeks de KPI ‘Supplier Delivery Date Adherence’ en het dashboard ‘Delivery Date Variance and Returns’. De vlag geeft een duidelijke binaire uitkomst voor tijdige levering die eenvoudig te aggregeren en visualiseren is. Zo zie je snel waar problemen ontstaan bij leveranciers of in het interne ontvangstproces.
Waarom dit belangrijk is
Geeft een duidelijke binaire maatstaf voor leverprestaties. Daarmee worden de berekening van KPI’s voor tijdige levering en trendanalyse eenvoudiger.
Waar je het vindt
Berekend tijdens de data-transformatie door ‘RequestedDeliveryDate’ te vergelijken met de timestamp van de activiteit ‘Goods Receipt Posted’.
Voorbeelden
truefalse
|
|||
|
Is voorkeursleverancier
IsPreferredVendor
|
Een booleaanse vlag die aangeeft of de aankoop bij een voorkeursleverancier of strategische leverancier is gedaan. | ||
|
Beschrijving
Deze vlag geeft aan of de leverancier op de purchase order deel uitmaakt van een vooraf goedgekeurde lijst met strategische leveranciers. Meestal bepaal je dit door de naam of ID van de leverancier te vergelijken met een masterlijst van voorkeursleveranciers. Dit attribuut is belangrijk voor strategische sourcing en spendmanagement. Je gebruikt het voor de KPI ‘Spend by Non-Preferred Vendor Ratio’. Daarmee kunnen organisaties inkopen buiten het beleid volgen en beperken, en uitgaven bundelen bij belangrijke partners om volumekortingen en betere voorwaarden te krijgen.
Waarom dit belangrijk is
Helpt de naleving van inkoopbeleid en doelstellingen voor strategische sourcing te volgen door uitgaven bij voorkeursleveranciers en andere leveranciers te vergelijken.
Waar je het vindt
Dit is vaak geen standaardveld in Coupa. Je leidt het af door de Vendor ID op de PO te vergelijken met een externe lijst van voorkeursleveranciers.
Voorbeelden
truefalse
|
|||
|
Naam aanvrager
RequesterName
|
De naam van de persoon die de goederen of diensten oorspronkelijk heeft aangevraagd. | ||
|
Beschrijving
Dit attribuut identificeert de medewerker die de inkoopaanvraag heeft aangemaakt die tot de purchase order heeft geleid. De aanvrager is de zakelijke gebruiker met de behoefte. Dat kan iemand anders zijn dan de inkoper of goedkeurder. Door procesgedrag per aanvrager te analyseren, kun je patronen bij specifieke gebruikers of afdelingen herkennen. Het dashboard ‘Purchase Order Change Analysis’ gebruikt dit om te zien of bepaalde aanvragers vaker orderwijzigingen hebben. Dat kan wijzen op behoefte aan betere training over specificatievereisten.
Waarom dit belangrijk is
Helpt de zakelijke oorsprong van een aankoop te bepalen. Zo kun je inkoopgedrag en nauwkeurigheid op het niveau van de aanvrager analyseren.
Waar je het vindt
Deze informatie wordt meestal opgeslagen op de oorspronkelijke Purchase Requisition en overgenomen in de Purchase Order in Coupa.
Voorbeelden
Alice CooperBob DylanCharlie Parker
|
|||
|
Nummer inkoopaanvraag
PurchaseRequisitionNumber
|
De unieke identificatie van de inkoopaanvraag die aan de purchase order voorafging. | ||
|
Beschrijving
Dit attribuut koppelt een purchase order aan de oorspronkelijke inkoopaanvraag. Eén aanvraag kan leiden tot één of meer purchase orders. Deze koppeling is nodig om de volledige doorlooptijd van ‘Requisition-to-Order’ te analyseren. Door het aanmaken van de aanvraag te verbinden met het aanmaken en verzenden van de purchase order, kun je de efficiëntie van het volledige startproces van de inkoop meten, van aanvraag tot uitvoering.
Waarom dit belangrijk is
Verbindt de aanvraag- en orderfase van het proces. Zo kun je de doorlooptijd van aanvraag tot order en conversiepercentages analyseren.
Waar je het vindt
Dit is meestal een referentieveld op de regelitems van de Purchase Order in Coupa, met een koppeling naar de oorspronkelijke aanvraag.
Voorbeelden
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
Ontvangstlocatie
ReceivingLocation
|
De fysieke locatie, zoals een magazijn of kantoor, waar de goederen worden geleverd. | ||
|
Beschrijving
De Receiving Location geeft de bestemming aan van de goederen op de PO. Dit kan een specifiek magazijn, een fabriek of een kantooradres zijn. Je gebruikt dit attribuut om logistieke prestaties en ontvangstprestaties per locatie te analyseren. In het dashboard ‘Goods Receipt Process Delays’ kun je hierop filteren om te bepalen of bepaalde locaties inkomende zendingen trager verwerken. Zo spoor je inefficiënties of capaciteitsproblemen op specifieke locaties op.
Waarom dit belangrijk is
Maakt locatiegerichte analyse van het ontvangstproces mogelijk en laat prestatieverschillen tussen magazijnen, fabrieken en kantoren zien.
Waar je het vindt
Deze informatie maakt deel uit van het ‘Ship-To’-adres op de Purchase Order in Coupa.
Voorbeelden
Magazijn A - ChicagoGebouw 5 - kantoor in LondenFabriek in Frankfurt
|
|||
|
Reden van afwijzing
RejectionReason
|
De reden die wordt opgegeven wanneer een inkoopaanvraag of purchase order tijdens een goedkeuringsstap wordt afgewezen. | ||
|
Beschrijving
Wanneer een goedkeurder een purchase order afwijst, geeft die vaak een reden op. Dit attribuut bevat die tekstuele toelichting, zoals ‘Onjuiste budgetcode’ of ‘Overschrijdt de bestedingslimiet’. Door afwijsredenen te analyseren, krijg je rechtstreeks inzicht in de oorzaken van herstelwerk en procesfouten. Je kunt deze kwalitatieve data gebruiken om veelvoorkomende fouten in het aanvraagproces te vinden. Dat helpt bij gerichte training of systeemverbeteringen, zodat toekomstige afwijzingen afnemen en het percentage goedkeuringen in één keer stijgt.
Waarom dit belangrijk is
Geeft concrete inzichten in de redenen waarom purchase orders worden afgewezen. Zo kun je de oorzaken van herstelwerk en vertragingen aanpakken.
Waar je het vindt
Meestal vastgelegd in het opmerkingen- of notitieveld bij de activiteit ‘Purchase Order Rejected’ of ‘Purchase Requisition Rejected’ in de goedkeuringsworkflow van Coupa.
Voorbeelden
Dubbele aanvraagBudget niet goedgekeurdOnjuiste leverancier geselecteerd
|
|||
|
Reden van wijziging
ChangeReason
|
De reden die wordt opgegeven voor een wijziging aan een purchase order na de oorspronkelijke aanmaak. | ||
|
Beschrijving
Dit attribuut bevat de reden waarom een purchase order is gewijzigd, bijvoorbeeld ‘Aantal aangepast’ of ‘Prijs gecorrigeerd’. Deze informatie staat vaak in het audittrail wanneer een gebruiker de activiteit ‘Purchase Order Changed’ uitvoert. Inzicht in de redenen voor orderwijzigingen is belangrijk voor het dashboard ‘Purchase Order Change Analysis’. Je kunt hiermee onderscheid maken tussen onvermijdelijke wijzigingen, zoals voorraadproblemen bij de leverancier, en vermijdbare wijzigingen, zoals een fout bij de eerste invoer. Zo kun je de ordernauwkeurigheid verbeteren en de KPI ‘Purchase Order Change Rate’ verlagen.
Waarom dit belangrijk is
Verklaart de oorzaken van PO-wijzigingen. Zo kun je gericht werken aan een hogere nauwkeurigheid bij de eerste invoer en minder herstelwerk in het proces.
Waar je het vindt
Vaak te vinden in auditlogs of opmerkingen bij wijzigingsactiviteiten voor een Purchase Order in Coupa.
Voorbeelden
Prijswijziging van leverancierLeverdatum aangepastGecorrigeerde artikelcode
|
|||
|
Valuta
Currency
|
De valutacode voor de geldbedragen op de purchase order. | ||
|
Beschrijving
Dit attribuut geeft aan in welke valuta, bijvoorbeeld USD, EUR of GBP, de Total Order Amount is uitgedrukt. Dat is nodig om financiële data in een internationale organisatie goed te interpreteren. Voor multinationals kan een uitgavenanalyse zonder rekening te houden met valuta een verkeerd beeld geven. Met dit attribuut kun je valuta correct omrekenen en financiële rapportages in dashboards consistent houden. Zo vergelijk je bedragen op dezelfde basis.
Waarom dit belangrijk is
Zorgt voor een nauwkeurige financiële analyse en rapportage in internationale omgevingen door de benodigde informatie voor valutaomrekening te leveren.
Waar je het vindt
Een standaardveld op de Purchase Order-header in Coupa.
Voorbeelden
USDEURGBPJPY
|
|||
Purchase to Pay - activiteiten voor inkooporders
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Goederenontvangst verwerkt
|
Dit is de formele bevestiging dat de goederen zijn ontvangen, geïnspecteerd en geaccepteerd. Het event werkt de voorraadgegevens bij en betekent dat de leverancier aan zijn verplichting voor deze levering heeft voldaan. | ||
|
Waarom dit belangrijk is
Deze belangrijke mijlpaal markeert het einde van de levertijd van de leverancier en wordt gebruikt om naleving van de leverdatum te meten. Vertraging bij het verwerken van ontvangsten kan het zicht op de werkelijke voorraadniveaus vertroebelen.
Waar je het vindt
Dit is een kerntransactie in Coupa, vastgelegd op het Receipt-object. Het event wordt geregistreerd wanneer de status van de ontvangst verandert naar 'Posted' of 'Received'.
Vastleggen
Wordt vastgelegd wanneer de goederenontvangst in het systeem is afgerond.
Eventtype
explicit
|
|||
|
Purchase Order geannuleerd
|
Deze activiteit staat voor het annuleren van een purchase order voordat deze is afgerond. Annulering kan in verschillende fasen plaatsvinden, bijvoorbeeld wanneer de aanvraag niet meer geldig is of de PO per ongeluk is aangemaakt. | ||
|
Waarom dit belangrijk is
Als alternatieve procesuitkomst is het belangrijk om annuleringen te volgen. Zo krijg je zicht op uitval in het proces en op redenen waarom inkoopaanvragen worden stopgezet.
Waar je het vindt
Dit wordt afgeleid uit een statuswijziging op het Purchase Order-object naar 'Canceled'. De timestamp van deze statuswijziging wordt gebruikt als tijdstip van het event.
Vastleggen
Afgeleid van de timestamp van de statuswijziging naar 'Canceled'.
Eventtype
inferred
|
|||
|
Purchase Order gesloten
|
Dit is de laatste activiteit en betekent dat de purchase order is afgerond. De PO geldt als gesloten wanneer deze volledig is ontvangen en gefactureerd en er geen verdere transacties worden verwacht. | ||
|
Waarom dit belangrijk is
Met deze activiteit eindigt de levenscyclus van de PO officieel. Door de tijd tot sluiting te analyseren, kun je inefficiënties in de laatste afstemming en administratie vinden.
Waar je het vindt
Dit wordt afgeleid uit een statuswijziging op het Purchase Order-object naar 'Closed'. Coupa stelt deze status vaak automatisch in op basis van bedrijfsregels voor ontvangst- en facturatoleranties.
Vastleggen
Afgeleid van de timestamp van de statuswijziging naar 'Closed'.
Eventtype
inferred
|
|||
|
Purchase Order goedgekeurd
|
Deze mijlpaal betekent dat de purchase order de interne goedkeuringsworkflow heeft doorlopen en mag worden uitgegeven aan de leverancier. Dit is meestal de laatste goedkeuringsstap in een proces met meerdere stappen. | ||
|
Waarom dit belangrijk is
Deze mijlpaal is belangrijk voor het berekenen van de goedkeuringsdoorlooptijd van PO's en het vinden van goedkeuringsknelpunten. Ook is dit een belangrijk controlepunt voor compliance.
Waar je het vindt
Wordt vastgelegd in de goedkeuringsgeschiedenis van de Purchase Order in Coupa. De timestamp van de laatste goedkeuringsactie bepaalt het tijdstip van het event.
Vastleggen
Wordt in de goedkeuringsgeschiedenis vastgelegd wanneer de laatste goedkeurder de taak afrondt.
Eventtype
explicit
|
|||
|
Purchase Order naar leverancier verstuurd
|
Deze activiteit markeert het moment waarop de goedgekeurde purchase order officieel naar de leverancier wordt verstuurd, bijvoorbeeld per e-mail of via het Coupa Supplier Portal. Hiermee verandert de PO van een intern document in een externe verplichting. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal. Hiermee eindigt de interne doorlooptijd van aanvraag tot order en begint de levertijd van de leverancier. De informatie is belangrijk om zowel interne efficiëntie als leveranciersprestaties te meten.
Waar je het vindt
Dit wordt vaak afgeleid uit een statuswijziging van de PO naar 'Ordered' of 'Sent'. Coupa kan ook een specifiek veld bevatten, zoals 'last_exported_at' of 'sent_to_supplier_at', met de timestamp op het PO-record.
Vastleggen
Afgeleid van de timestamp van de statuswijziging naar 'Ordered' of van een specifiek veld met de verzendtimestamp.
Eventtype
inferred
|
|||
|
Purchase Requisition aangemaakt
|
Deze activiteit markeert het aanmaken van een purchase requisition. Dit is het formele verzoek om goederen of diensten dat voorafgaat aan een purchase order. In Coupa is dit een expliciet event dat wordt vastgelegd wanneer een gebruiker een nieuwe requisition opslaat en indient. | ||
|
Waarom dit belangrijk is
Als gebruikelijk startpunt van het inkoopproces is deze activiteit nodig om de volledige doorlooptijd van aanvraag tot order te meten en de efficiëntie van het voorafgaande proces te begrijpen.
Waar je het vindt
Dit event komt overeen met het aanmaakrecord in het object of de tabel Purchase Requisitions in Coupa. De timestamp staat in het veld 'created_at' of in een vergelijkbaar, door het systeem gegenereerd veld voor de aanmaakdatum.
Vastleggen
Wordt meteen bij het aanmaken van een nieuwe requisition vastgelegd.
Eventtype
explicit
|
|||
|
Dienstenbevestiging ingevoerd
|
Bij purchase orders voor diensten is deze activiteit het equivalent van een goederenontvangst. Hiermee wordt bevestigd dat een dienst volgens de voorwaarden van de PO is geleverd. | ||
|
Waarom dit belangrijk is
Door dienstenbevestigingen te volgen, kun je uitgaven aan diensten beter beheren en ervoor zorgen dat alleen wordt betaald voor werk waarvan is vastgesteld dat het is afgerond.
Waar je het vindt
Dit event wordt vastgelegd bij het aanmaken of goedkeuren van een ontvangstbewijs voor diensten of een service entry sheet die in Coupa aan de Purchase Order is gekoppeld.
Vastleggen
Wordt vastgelegd bij het aanmaken en goedkeuren van een service entry sheet.
Eventtype
explicit
|
|||
|
Factuur voor PO ontvangen
|
Dit event markeert de ontvangst en invoer van een leveranciersfactuur die naar de purchase order verwijst. Hiermee begint de factuurverwerking en betalingsfase van de P2P-cyclus. | ||
|
Waarom dit belangrijk is
Hoewel dit onderdeel is van het AP-proces, geeft het koppelen van de factuur aan de PO een end-to-end-overzicht van de transactielevenscyclus. Ook kun je zo het verschil tussen levering en facturatie analyseren.
Waar je het vindt
Vastgelegd via de aanmaaktimestamp van het Invoice-document in Coupa, waarbij de factuur wordt gematcht met het bijbehorende Purchase Order-nummer.
Vastleggen
Wordt vastgelegd bij het aanmaken van een factuurrecord dat aan de PO is gekoppeld.
Eventtype
explicit
|
|||
|
Goederen geretourneerd
|
Deze activiteit wordt vastgelegd wanneer eerder ontvangen goederen naar de leverancier worden teruggestuurd. Dit gebeurt meestal door kwaliteitsproblemen, schade of een verkeerde levering. | ||
|
Waarom dit belangrijk is
Het volgen van retouren is belangrijk om het retourpercentage van goederen te berekenen en problemen met leverancierskwaliteit of ordernauwkeurigheid te vinden. Veel retouren wijzen vaak op kostbare fouten in het proces.
Waar je het vindt
Dit wordt vastgelegd via een transactie 'Return to Supplier' of een negatieve ontvangsttransactie in Coupa. De timestamp van deze transactie dient als tijdstip van het event.
Vastleggen
Wordt vastgelegd wanneer een retourtransactie die aan de oorspronkelijke PO of ontvangst is gekoppeld, wordt aangemaakt.
Eventtype
explicit
|
|||
|
Kwaliteitsinspectie uitgevoerd
|
Dit event betekent dat een ontvangen artikel een kwaliteitsinspectie heeft ondergaan en is goedgekeurd. Afhankelijk van het proces van de organisatie kan dit een afzonderlijke stap zijn nadat de goederenontvangst is verwerkt. | ||
|
Waarom dit belangrijk is
Deze activiteit is belangrijk om de efficiëntie van het kwaliteitscontroleproces te meten. Vertragingen kunnen knelpunten veroorzaken tussen ontvangst en beschikbaarheid voor gebruik.
Waar je het vindt
Dit kan worden vastgelegd als een statuswijziging op de ontvangstregel of via een afzonderlijk inspectieobject in Coupa. Of deze data beschikbaar is, hangt af van het gebruik van de kwaliteitsmodule of een aangepaste workflow.
Vastleggen
Afgeleid van een statuswijziging op de ontvangst of een timestamp op een gekoppeld inspectierecord.
Eventtype
inferred
|
|||
|
Leverancier heeft order bevestigd
|
Dit event betekent dat de leverancier de purchase order heeft ontvangen en bevestigd. Deze bevestiging wordt vaak elektronisch vastgelegd via een leveranciersportaal, zoals het Coupa Supplier Portal (CSP). | ||
|
Waarom dit belangrijk is
Bevestigingen van leveranciers geven zekerheid dat een order wordt verwerkt. Dat maakt leveringsprognoses nauwkeuriger en verkleint onzekerheid in de supply chain.
Waar je het vindt
Deze informatie staat meestal op de Purchase Order als de leverancier via het Coupa Supplier Portal de actie 'Acknowledge' uitvoert. De timestamp van deze actie wordt gebruikt.
Vastleggen
Wordt vastgelegd wanneer een leverancier de actie 'Acknowledge' uitvoert in het leveranciersportaal.
Eventtype
explicit
|
|||
|
Ontvangst van goederen gestart
|
Deze activiteit staat voor de start van het ontvangstproces, bijvoorbeeld wanneer bij fysieke ontvangst van goederen een ontvangstbewijs in Coupa wordt aangemaakt. De goederen zijn nog niet formeel in de voorraad verwerkt of als ontvangen bevestigd. | ||
|
Waarom dit belangrijk is
Dit event is het startpunt voor het meten van de KPI voor de verwerkingstijd van goederenontvangsten. Zo kun je onderscheid maken tussen de tijd dat goederen op de losplaats wachten en de tijd die nodig is voor verwerking in het systeem.
Waar je het vindt
Dit kan worden afgeleid uit de aanmaaktimestamp van een ontvangstbewijs met de status 'Draft' of 'Pending'. Het event vindt plaats vóór de definitieve verwerking van de ontvangst.
Vastleggen
Afgeleid van de aanmaaktimestamp van een ontvangstrecord dat nog niet is verwerkt.
Eventtype
inferred
|
|||
|
Purchase Order afgewezen
|
Deze activiteit vindt plaats wanneer een goedkeurder de purchase order tijdens de goedkeuringsworkflow afwijst. De PO wordt daarna meestal teruggestuurd naar de maker voor aanpassing of annulering. | ||
|
Waarom dit belangrijk is
Door afwijzingen te analyseren, kun je problemen met datakwaliteit, beleidsovertredingen of kennishiaten vinden. Ook worden herstelrondes zichtbaar die voor flinke vertraging zorgen.
Waar je het vindt
Dit is een expliciet event in de goedkeuringsgeschiedenis van de Purchase Order in Coupa. In het log staat een actie 'Reject' met een bijbehorende timestamp.
Vastleggen
Wordt in de goedkeuringsgeschiedenis vastgelegd met de status 'Reject'.
Eventtype
explicit
|
|||
|
Purchase Order gewijzigd
|
Dit event staat voor elke wijziging aan de purchase order nadat het eerste concept is opgesteld. In Coupa worden wijzigingen vaak bijgehouden via versies van het PO-document. | ||
|
Waarom dit belangrijk is
Het volgen van wijzigingen is belangrijk voor KPI's zoals het wijzigingspercentage van Purchase Orders en het percentage niet-conforme PO's. Veel wijzigingen wijzen op instabiliteit in het proces of onnauwkeurige eerste aanvragen.
Waar je het vindt
Dit kan worden afgeleid door verschillende versies van een Purchase Order te volgen. Elk nieuw versienummer dat hoger is dan het eerste, wijst op een wijziging. De aanmaakdatum van de nieuwe versie dient als timestamp van het event.
Vastleggen
Afgeleid van de aanmaaktimestamp van een nieuwe PO-versie.
Eventtype
inferred
|
|||
|
Purchase Order ingediend
|
Nadat een purchase order is opgesteld, wordt deze formeel ingediend in de goedkeuringsworkflow. Dit is een afzonderlijke gebruikersactie die de PO van de conceptstatus naar de status 'in afwachting van goedkeuring' brengt. | ||
|
Waarom dit belangrijk is
Dit event maakt onderscheid tussen de tijd die nodig is om de PO op te stellen en het moment waarop de PO daadwerkelijk op goedkeuring wacht. Zo krijg je beter zicht op gebruikersgedrag en overdrachtsmomenten in het proces.
Waar je het vindt
Wordt afgeleid uit een statuswijziging op het Purchase Order-object, bijvoorbeeld van 'draft' naar 'pending approval'. De timestamp van deze specifieke statuswijziging wordt gebruikt.
Vastleggen
Afgeleid van de timestamp van de statuswijziging naar 'pending approval'.
Eventtype
inferred
|
|||
|
Purchase Order opgesteld
|
Dit event staat voor het voor het eerst aanmaken van het Purchase Order-document in het systeem, vaak vanuit een goedgekeurde requisition. In deze fase is de PO nog een intern concept en is deze nog niet ter goedkeuring ingediend of naar de leverancier verstuurd. | ||
|
Waarom dit belangrijk is
Hiermee begint de meting van de KPI voor de goedkeuringsdoorlooptijd van de PO. Dit is de eerste formele stap in de levenscyclus van de purchase order.
Waar je het vindt
Dit komt overeen met de aanmaaktimestamp van het Purchase Order-record in Coupa, meestal in een veld zoals 'created_at'.
Vastleggen
Wordt vastgelegd via de door het systeem gegenereerde aanmaaktimestamp van het PO-record.
Eventtype
explicit
|
|||
|
Purchase Requisition goedgekeurd
|
Een purchase requisition doorloopt een goedkeuringsworkflow voordat deze kan worden omgezet in een purchase order. Dit event betekent dat de requisition definitief is goedgekeurd en klaar is om te bestellen. | ||
|
Waarom dit belangrijk is
Door goedkeuringen van requisitions te volgen, kun je knelpunten in de fase vóór het bestellen vinden. Vertragingen hier hebben direct invloed op hoe snel een purchase order kan worden uitgegeven.
Waar je het vindt
Dit wordt meestal vastgelegd in de goedkeuringsgeschiedenis van het requisition-object in Coupa. Bij de laatste goedkeuringsactie horen een timestamp en een gebruiker.
Vastleggen
Wordt in de goedkeuringsgeschiedenis vastgelegd wanneer de laatste goedkeurder actie onderneemt.
Eventtype
explicit
|
|||
Extractiegidsen
Klaar om aan de slag te gaan?
Gebruik deze template om je data voor process mining voor te bereiden en bruikbare inzichten te krijgen. Begin vandaag nog met het optimaliseren van je Purchase to Pay - Purchase Order-proces.
Optimaliseer je P2P-inkooporders en verbeter vandaag nog je efficiëntie
Verlaag je P2P-doorlooptijd met 30% en zie snel resultaat.
Geen creditcard nodig. Je bent binnen enkele minuten klaar.