> Continu verbeteren van processen > Order to cash verwerking van verkooporders > Microsoft Dynamics 365 > Datatemplate

Datatemplate voor Order to Cash - Verwerking van verkooporders

Microsoft Dynamics 365

Attributen voor Order to Cash - Verwerking van verkooporders(20) Activiteiten voor Order to Cash - Verwerking van verkooporders(13) Extractiegidsen(2)

Datatemplate voor Order to Cash - Verwerking van verkooporders

Deze template geeft een gestructureerd overzicht van de essentiële data voor de analyse van Order to Cash - Verwerking van verkooporders in Microsoft Dynamics 365. Je ziet welke attributen je verzamelt en welke activiteiten je in het event log bijhoudt. Ook vind je praktische aanwijzingen om de data uit het systeem te halen.

Aanbevolen attributen voor een volledige analyse
Belangrijke procesactiviteiten om bij te houden
Specifieke aanwijzingen voor data-extractie uit Microsoft Dynamics 365

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

Template downloaden

Attributen voor Order to Cash - Verwerking van verkooporders

Dit zijn de aanbevolen datavelden voor het event log om Order to Cash - Verwerking van verkooporders in Microsoft Dynamics 365 volledig te analyseren.

5 Verplicht 5 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment in het verkooporderproces plaatsvond.
Beschrijving Dit attribuut staat voor een afzonderlijke stap of gebeurtenis in de levenscyclus van een verkooporder, zoals ‘Verkooporder aangemaakt’, ‘Goederen verzonden’ of ‘Betaling ontvangen’. De volgorde van deze activiteiten voor een verkooporder vormt het procesverloop. De volgorde, frequentie en overgangen tussen activiteiten analyseren is de kern van process mining. Zo kun je de proceskaart visualiseren, veelvoorkomende en zeldzame procesvarianten herkennen, bottlenecks opsporen en herstelwerk of afwijkingen van de afspraken vinden. Dit attribuut laat zien wat er in het proces daadwerkelijk gebeurt. Waarom dit belangrijk is Dit attribuut bepaalt de processtappen. Daarmee kun je het procesverloop opbouwen en visualiseren, het belangrijkste doel van process mining. Waar vind je dit? Dit attribuut wordt conceptueel afgeleid door specifieke systeemgebeurtenissen of statuswijzigingen in tabellen zoals ‘SalesTable’ en gerelateerde logistieke of financiële tabellen te koppelen aan een gestandaardiseerde activiteitsnaam. Voorbeelden Verkooporder aangemaaktGoederen verzondenFactuur aangemaaktBetaling ontvangen
	Starttijd EventTime	De exacte datum en tijd waarop een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving De gebeurtenistijd, of timestamp, legt het exacte moment vast waarop een activiteit plaatsvond. Elke activiteit in de event log heeft een bijbehorende timestamp. Zo ontstaat per case een chronologisch overzicht van het proces. Dit attribuut is nodig voor alle tijdsanalyses bij process mining. Je gebruikt het om doorlooptijden tussen activiteiten en de totale duur van een case te berekenen, wachttijden te analyseren en bottlenecks te vinden waar het proces vertraging oploopt. Ook kun je de prestaties in de tijd volgen, bijvoorbeeld de doorvoer per dag, week of maand. Waarom dit belangrijk is Deze timestamp is nodig om alle tijdsmetingen te berekenen, zoals doorlooptijden en vertragingen door bottlenecks, en om gebeurtenissen chronologisch te ordenen. Waar vind je dit? Dit wordt afgeleid uit verschillende datum- en tijdvelden van specifieke transacties, zoals ‘SalesTable.CreatedDateTime’ voor het aanmaken van een order of de boekingsdatums van betalingsjournalen voor betalingen. Voorbeelden 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Verkooporder SalesOrderNumber	De unieke identificatiecode van elke verkooporder. Deze dient als primaire case-ID voor het proces.
Beschrijving Het verkoopordernummer is een unieke alfanumerieke code die in Microsoft Dynamics 365 aan elke klantorder wordt toegekend. Het is de centrale case-ID die alle bijbehorende activiteiten en gebeurtenissen vanaf de aanmaak tot de afsluiting met elkaar verbindt. Bij process mining is dit attribuut nodig om het volledige traject van elke afzonderlijke verkooporder te reconstrueren. Analisten kunnen hiermee de volledige reeks activiteiten volgen, de duur van cases meten en variaties per order analyseren. Dit vormt de basis voor de hele procesanalyse. Waarom dit belangrijk is Deze identificatiecode is nodig om alle gerelateerde gebeurtenissen met elkaar in verband te brengen en elke verkooporder van begin tot eind te analyseren. Waar vind je dit? Te vinden in de tabel ‘SalesTable’, veld ‘SalesId’. Voorbeelden SO-00102345SO-00102346SO-00102347
	Bronsysteem SourceSystem	Geeft aan uit welk informatiesysteem de data afkomstig is.
Beschrijving Dit attribuut geeft aan in welke brontoepassing de eventdata is vastgelegd. In deze context is dat meestal 'Microsoft Dynamics 365'. Bij een analyse van één systeem lijkt dit misschien overbodig. Het is wel belangrijk wanneer je data uit meerdere systemen combineert, zoals een apart CRM-systeem of een magazijnbeheersysteem. Zo blijft duidelijk waar de data vandaan komt. Ook helpt het bij het oplossen van problemen met data-extractie, omdat je de herkomst van records kunt achterhalen. Waarom dit belangrijk is Dit geeft belangrijke context over de herkomst van data, vooral wanneer je data uit meerdere systemen combineert. Zo blijft de herkomst duidelijk. Waar vind je dit? Dit is een vaste waarde die meestal tijdens de datatransformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor het laatst is vernieuwd of uit het bronsysteem is opgehaald.
Beschrijving Dit attribuut registreert de datum en tijd waarop de data voor het laatst uit Microsoft Dynamics 365 is opgehaald. Zo zie je hoe actueel de data is die je analyseert. Voor procesanalyses is het belangrijk te weten hoe recent de data is, zodat je beslissingen op actuele informatie kunt baseren. Deze timestamp laat precies zien wanneer de data voor het laatst is bijgewerkt. Zo kun je erop vertrouwen dat je conclusies op actuele informatie berusten. Waarom dit belangrijk is Zo weten gebruikers hoe actueel de data is. Dat is belangrijk voor de relevantie en nauwkeurigheid van de process mining-analyse. Waar vind je dit? Deze waarde wordt tijdens de data-extractie gegenereerd en bij het inlezen aan elk record toegevoegd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Bevestigde leverdatum ConfirmedDeliveryDate	De leverdatum die het bedrijf aan de klant heeft bevestigd en toegezegd.
Beschrijving De bevestigde leverdatum is de datum waarop de verkopende organisatie de levering van de goederen aan de klant toezegt. Deze datum wordt vastgesteld nadat interne controles zijn afgerond, bijvoorbeeld op voorraadbeschikbaarheid en productieschema's. Dit attribuut is nodig om de KPI 'Nalevingspercentage leverdatum' te berekenen vanuit het perspectief van de operationele toezegging. Het is een realistischer intern ijkpunt voor tijdige levering dan de oorspronkelijke wens van de klant. Door afwijkingen van deze datum te analyseren, kun je interne problemen in logistiek en orderafhandeling herkennen. Waarom dit belangrijk is Dit geeft de toezegging van het bedrijf aan de klant weer en vormt een belangrijk intern ijkpunt voor de betrouwbaarheid van de orderafhandeling en de operationele prestaties. Waar vind je dit? Te vinden in de gegevens van de verkooporderregels, vaak in de tabel 'SalesLine' onder een veldnaam zoals 'ConfirmedDlv'. Voorbeelden 2023-05-122023-06-012023-05-28
	Gewenste leverdatum RequestedDeliveryDate	De leverdatum waarop de klant de order wil ontvangen.
Beschrijving Dit attribuut bevat de datum waarop de klant de goederen oorspronkelijk wilde ontvangen. De datum wordt vastgelegd wanneer de order wordt aangemaakt en vormt het uitgangspunt om de leverprestaties vanuit het perspectief van de klant te meten. Deze datum is een belangrijke invoer voor het dashboard 'Naleving leverdatum'. Vergelijk 'RequestedDeliveryDate' met 'ConfirmedDeliveryDate' en de werkelijke datum van de activiteit 'Goederen geleverd' om te zien hoe goed de organisatie aan de verwachtingen van klanten voldoet. Grote verschillen kunnen wijzen op problemen met planning, voorraad of logistiek. Waarom dit belangrijk is Dit is de leververwachting van de klant en een belangrijk uitgangspunt om klanttevredenheid en prestaties van tijdige levering te meten. Waar vind je dit? Te vinden in de tabel 'SalesTable', meestal onder de naam 'DeliveryDate' of een vergelijkbare variant. Voorbeelden 2023-05-102023-06-012023-05-25
	Klantnaam CustomerName	De naam van de klant die de verkooporder heeft geplaatst.
Beschrijving Dit attribuut bevat de officiële naam van de klant bij de verkooporder. Je haalt die op door het klantrekeningnummer op de verkooporder te koppelen aan de centrale klantgegevens. Door het proces per klant te analyseren, krijg je zicht op klantgedrag en serviceniveaus. Je ziet welke klanten de meeste vertraging ervaren, waar het herstelwerk het vaakst voorkomt en welke klanten een afwijkende procesroute volgen. Dat helpt de klanttevredenheid te verbeteren en belangrijke klantrelaties goed te beheren. Waarom dit belangrijk is Hiermee kun je het proces vanuit de klant bekijken en patronen, vertragingen of problemen bij specifieke klanten herkennen. Die kunnen rechtstreeks van invloed zijn op de klanttevredenheid. Waar vind je dit? Opgezocht in 'CustTable' met het veld 'CustAccount' uit 'SalesTable'. Voorbeelden Contoso LtdAdatum CorporationFabrikam Inc.
	Orderwaarde OrderValue	De totale geldwaarde van de verkooporder.
Beschrijving Dit attribuut geeft het totale financiële bedrag van de verkooporder weer, inclusief alle artikelen, belastingen en toeslagen. Het is een belangrijke financiële metriek voor elke case. De orderwaarde is belangrijk voor procesanalyses op basis van waarde. Je kunt het proces ermee segmenteren en nagaan of orders met een hoge waarde anders worden afgehandeld of meer vertraging oplopen dan orders met een lage waarde. Zo kun je verbeteringen richten op cases met de grootste financiële impact. De waarde is ook bruikbaar in dashboards zoals 'Verkooporderwaarde per segment'. Waarom dit belangrijk is Hiermee kun je het proces financieel segmenteren, verbeteringen voor orders met een hoge waarde prioriteren en de kosten van procesafwijkingen in kaart brengen. Waar vind je dit? Te vinden in de kopgegevens van de verkooporder. Raadpleeg de documentatie van Microsoft Dynamics 365 voor de specifieke tabel en het veld. De waarde wordt vaak berekend op basis van de bedragen op de verkooporderregels. Voorbeelden 5250.7512300.00899.50
	Verkoopkanaal SalesChannel	Het kanaal waarlangs de verkooporder is binnengekomen, zoals internet, directe verkoop of een partner.
Beschrijving Het verkoopkanaal geeft aan waar de klantorder vandaan komt. Dat kan een webshop zijn, een direct verkoopteam, een winkel, een callcenter of een partnernetwerk. In Dynamics 365 wordt deze dimensie vaak ingericht op basis van de bedrijfsbehoeften. Door het proces per verkoopkanaal te analyseren, zie je verschillen in prestaties. Weborders worden bijvoorbeeld mogelijk sneller en meer automatisch verwerkt dan telefonische orders. Met die informatie kun je processen en de inzet van middelen per kanaal verbeteren. De gegevens zijn ook bruikbaar in dashboards zoals 'Verkooporderwaarde per segment'. Waarom dit belangrijk is Hiermee kun je prestaties van verkoopkanalen vergelijken en inefficiënties of goede werkwijzen herkennen die samenhangen met de manier waarop orders binnenkomen. Waar vind je dit? Deze informatie staat meestal in de kopgegevens van de verkooporder. Raadpleeg de documentatie van Microsoft Dynamics 365 voor het specifieke veld. Voorbeelden WebDirecte verkoopPartnerWinkel
	Artikelnummer ItemNumber	De unieke identificatiecode van een product of dienst op de verkooporder.
Beschrijving Het artikelnummer geeft aan welk product wordt verkocht. Omdat een verkooporder meerdere producten kan bevatten, is dit attribuut meestal gekoppeld aan eventdata op regelniveau. Door het proces per product te analyseren, kun je problemen met specifieke producten herkennen. Sommige producten kunnen bijvoorbeeld samenhangen met langere afhandeltijden, meer herstelwerk of vaker geblokkeerde orders vanwege kredietcontroles. Zo kun je verbeteringen richten op het voorraadbeheer, de productgegevens of de orderafhandeling van specifieke artikelen. Waarom dit belangrijk is Hiermee kun je het proces per product analyseren en zien of bepaalde artikelen samenhangen met vertragingen, herstelwerk of andere inefficiënties. Waar vind je dit? Te vinden in de tabel 'SalesLine', in het veld 'ItemId'. Voorbeelden PROD-00123PROD-00548SVC-00045
	Eindtijd EndTime	De exacte datum en tijd waarop een activiteit is afgerond.
Beschrijving De timestamp Eindtijd registreert het moment waarop een activiteit is afgerond. Als deze beschikbaar is, geeft die een nauwkeuriger beeld van de duur van een activiteit dan een schatting op basis van de starttijd van de volgende activiteit. Met zowel een start- als eindtijd kun je voor elke activiteit de Verwerkingstijd nauwkeurig berekenen en onderscheiden van de wachttijd tussen activiteiten. Zo zie je welke specifieke taken veel tijd kosten en bij welke processtappen lange vertragingen optreden. Waarom dit belangrijk is Hiermee bereken je de verwerkingstijd van afzonderlijke activiteiten nauwkeurig en onderscheid je actieve werktijd van wachttijd. Waar vind je dit? Net als Starttijd wordt deze waarde afgeleid uit verschillende datum- en tijdvelden. Het kan bijvoorbeeld gaan om het veld 'ModifiedDateTime' of een timestamp van een statuswijziging in tabellen zoals 'SalesTable' of 'WHSLoadTable'. Voorbeelden 2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
	Gebruikersnaam UserName	De naam van de gebruiker die de activiteit heeft uitgevoerd.
Beschrijving Dit attribuut geeft aan welke medewerker of systeemgebruiker verantwoordelijk was voor een taak, zoals het bevestigen van een order of het aanmaken van een factuur. Meestal is het gekoppeld aan een gebruikers-ID in Microsoft Dynamics 365. Door prestaties per gebruiker te analyseren, kun je opleidingsbehoeften herkennen, goede prestaties in beeld brengen en de werkverdeling controleren. Dit is ook belangrijk voor compliance en audits: zo is voor elke procesactie duidelijk wie ervoor verantwoordelijk was. Waarom dit belangrijk is Hiermee kun je procesprestaties per persoon of team analyseren en opleidingskansen, een ongelijke werkverdeling en bottlenecks door beperkte capaciteit herkennen. Waar vind je dit? Afgeleid van gebruikers-ID-velden zoals 'CreatedBy' of 'ModifiedBy' in verschillende transactietabellen. Deze worden gekoppeld aan de centrale gebruikerstabel, bijvoorbeeld 'UserInfo', om de volledige naam op te halen. Voorbeelden Alice JohnsonRobert BrownSysteembeheerder
	Is herstelwerk IsRework	Een booleaanse waarde die aangeeft of er herstelwerk aan een verkooporder is geweest, bijvoorbeeld doordat een activiteit is herhaald.
Beschrijving Dit berekende attribuut markeert cases die afwijken van de directe procesroute, de 'Ideale route'. Herstelwerk wordt herkend aan reeksen activiteiten die erop wijzen dat een stap is herhaald. Een order kan bijvoorbeeld eerst worden bevestigd, daarna ongedaan worden gemaakt en vervolgens opnieuw worden bevestigd. Ook kunnen goederen worden gepickt en daarna terug op voorraad worden gelegd. Cases met herstelwerk markeren is belangrijk voor de KPI 'Percentage verkooporders met herstelwerk'. Analisten kunnen zo inefficiënte procesroutes snel selecteren en onderzoeken wat de oorzaken zijn, zoals invoerfouten, kredietproblemen of voorraadproblemen. Herstelwerk verminderen is een belangrijk doel van veel procesverbeteringsprojecten. Waarom dit belangrijk is Helpt inefficiëntie in het proces te meten door cases met herhaalde stappen te markeren. Zo kun je gericht onderzoeken hoe je verspilling en vertraging vermindert. Waar vind je dit? De process mining-tool berekent dit door de activiteitenreeks van elke case te analyseren. Een patroon zoals (A -> B -> C -> B) markeert de case bijvoorbeeld als herstelwerk. Voorbeelden truefalse
	Land CountryRegion	Het land van het afleveradres van de klant.
Beschrijving Dit attribuut geeft het land van bestemming van de verkooporder aan. De waarde is afgeleid van de afleveradresgegevens van de klant in Dynamics 365. Door procesprestaties per land te analyseren, kun je regionale verschillen herkennen. Bij internationale zendingen zijn soms extra stappen nodig, zoals douaneafhandeling, waardoor de doorlooptijden langer worden. Deze analyse helpt de logistiek voor verschillende geografische markten te begrijpen en te verbeteren. Waarom dit belangrijk is Hiermee kun je geografische analyses uitvoeren en regionale bottlenecks, complianceproblemen of prestatieverschillen in de toeleveringsketen herkennen. Waar vind je dit? Afgeleid van het afleveradres van de klant dat aan de verkooporder is gekoppeld. De landgegevens staan meestal in de tabel 'LogisticsPostalAddress', gekoppeld via de afleveradresverwijzing in 'SalesTable'. Voorbeelden USADEUCANGBR
	Status verkooporder SalesOrderStatus	De huidige status van de verkooporder op het moment dat de data wordt opgehaald.
Beschrijving Dit attribuut geeft de algemene status van de verkooporder weer, zoals 'Open order', 'Gefactureerd', 'Geannuleerd' of 'Geleverd'. Het is een samenvattende status in de kopgegevens van de verkooporder. Het activiteitenlogboek laat zien hoe het proces verloopt, terwijl de eindstatus handig is om te filteren en te segmenteren. Analisten kunnen bijvoorbeeld alle open orders selecteren om de huidige werkvoorraad te bekijken. Ook kunnen ze afgeronde orders scheiden van geannuleerde orders en de redenen voor annulering analyseren. Waarom dit belangrijk is Geeft een momentopname van de orderstatus. Je kunt de analyse filteren op open, gesloten of geannuleerde orders. Dat is handig voor werkvoorraadbeheer en uitkomstanalyse. Waar vind je dit? Te vinden in de tabel 'SalesTable', in het veld 'SalesStatus'. Voorbeelden NaleveringGeleverdGefactureerdGeannuleerd
	Tijdige betaling OnTimePayment	Een booleaanse waarde die aangeeft of de betaling op of vóór de uiterste betaaldatum is ontvangen.
Beschrijving Dit berekende attribuut vergelijkt de timestamp van de activiteit 'Betaling ontvangen' met 'PaymentDueDate'. De waarde is 'true' als de betaling op tijd was en 'false' als die te laat was. Deze waarde vormt de kern van de KPI 'Percentage tijdige betalingen'. Je kunt klanten er snel mee indelen in klanten die op tijd betalen en klanten die te laat betalen. De analyse kan helpen bij het bepalen van kredietbeleid, incassostrategieën en klantbeheer, doordat je klanten herkent die structureel te laat betalen. Waarom dit belangrijk is Meet het betaalgedrag van klanten aan de hand van de afgesproken voorwaarden. Dat is belangrijk voor het beheer van de kasstroom en de beoordeling van kredietrisico's. Waar vind je dit? Berekend door de 'EventTime' van de activiteit 'Betaling ontvangen' te vergelijken met het attribuut 'PaymentDueDate'. Formule: ('Betaling ontvangen' Timestamp <= PaymentDueDate). Voorbeelden truefalse
	Tijdige levering OnTimeDelivery	Een booleaanse waarde die aangeeft of de goederen op of vóór de bevestigde leverdatum zijn geleverd.
Beschrijving Dit berekende attribuut vergelijkt voor elke verkooporder de timestamp van de activiteit 'Goederen geleverd' met 'ConfirmedDeliveryDate'. De waarde is 'true' als de levering op tijd of eerder plaatsvond en 'false' als die te laat was. Deze waarde vormt de basis voor de KPI 'Nalevingspercentage leverdatum'. Je kunt er eenvoudig op tijd geleverde en te laat geleverde orders mee filteren en groeperen. Zo herken je snel factoren die samenhangen met late leveringen, zoals specifieke producten, klanten, regio's of verzendmethoden. Waarom dit belangrijk is Meet de prestaties van de orderafhandeling rechtstreeks af aan de toezegging. Dat is belangrijk om de klanttevredenheid en de betrouwbaarheid van de toeleveringsketen te volgen. Waar vind je dit? Berekend door de 'EventTime' van de activiteit 'Goederen geleverd' te vergelijken met het attribuut 'ConfirmedDeliveryDate'. Formule: ('Goederen geleverd' Timestamp <= ConfirmedDeliveryDate). Voorbeelden truefalse
	Uiterste betaaldatum PaymentDueDate	De datum waarop de klant de factuur uiterlijk moet betalen.
Beschrijving De uiterste betaaldatum wordt berekend op basis van de factuurdatum en de betalingsvoorwaarden die met de klant zijn afgesproken. De datum staat op de verkoopfactuur. Dit attribuut is nodig voor de analyse 'Naleving uiterste betaaldatum' en de KPI 'Percentage tijdige betalingen'. Vergelijk 'PaymentDueDate' met de werkelijke datum van de activiteit 'Betaling ontvangen' om late betalingen te herkennen en betaalgedrag per klantsegment te analyseren. Zo kan het bedrijf maatregelen nemen om de kasstroom te verbeteren en het aantal Days Sales Outstanding te verlagen. Waarom dit belangrijk is Dit is het ijkpunt voor het meten van betaalprestaties. Het is belangrijk om de kasstroom te analyseren en openstaande klantvorderingen goed te beheren. Waar vind je dit? Te vinden in de tabel 'CustInvoiceJour', in het veld 'DueDate'. Voorbeelden 2023-05-302023-06-152023-06-30
	Verzendmethode ShippingMethod	De methode of vervoerder waarmee de goederen naar de klant worden verzonden.
Beschrijving Dit attribuut geeft de vervoersdienst voor de levering aan, zoals 'Ground Shipping', 'Air Freight' of de naam van een specifieke vervoerder. De keuze wordt tijdens de orderverwerking gemaakt op basis van de voorkeur van de klant, de kosten en de levertijd. Deze dimensie is belangrijk voor het dashboard 'Prestaties per verzendmethode'. Door doorlooptijden van 'Goederen verpakt' tot 'Goederen geleverd' per verzendmethode te analyseren, zie je welke vervoerders sneller of betrouwbaarder zijn en welke vaker vertraging oplopen. Dat helpt bij de logistieke planning en de keuze van vervoerders. Waarom dit belangrijk is Hiermee kun je de prestaties van vervoerders en verzendopties analyseren en de logistiek verbeteren op het gebied van kosten, snelheid en betrouwbaarheid. Waar vind je dit? Deze informatie staat meestal in de kopgegevens van de verkooporder of in gerelateerde gegevens over de orderafhandeling. Raadpleeg de documentatie van Microsoft Dynamics 365. Voorbeelden FedEx GroundUPS Next Day AirDHL Express

Verplicht Aanbevolen Optioneel

Activiteiten voor Order to Cash - Verwerking van verkooporders

Dit zijn de belangrijkste processtappen en mijlpalen om in het event log vast te leggen. Zo kun je de verwerking van verkooporders goed in kaart brengen en analyseren.

6 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Betaling ontvangen	Deze activiteit geeft aan dat de betaling van de klant voor de factuur is ontvangen en verwerkt. De gebeurtenis vindt plaats in de module Accounts Receivable en is gekoppeld aan de oorspronkelijke factuur.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor de analyse van de cash conversion cycle. De gebeurtenis is nodig om de KPI ‘Percentage betalingen op tijd’ te meten en vertragingen bij het innen van betalingen op te sporen. Waar vind je dit? Dit is een expliciete gebeurtenis uit de module Accounts Receivable. De gebeurtenis wordt vastgelegd op basis van de transactiedatum van de afwikkeling van de klantbetaling (CustSettlement), waarmee de factuurtransactie (CustTrans) wordt afgesloten. Vastleggen Leg de afwikkelingsdatum uit de tabel CustSettlement vast en koppel deze aan de factuur en verkooporder. Gebeurtenistype explicit
	Factuur aangemaakt	Dit is het aanmaken en boeken van de verkoopfactuur voor de verzonden goederen of diensten. Deze financiële transactie legt de schuld van de klant formeel vast.
Waarom dit belangrijk is Deze activiteit markeert het begin van de financiële afwikkeling. De tijd tussen verzending en het aanmaken van de factuur is belangrijk voor de KPI ‘Doorlooptijd facturatie’ en heeft invloed op de cashflow. Waar vind je dit? Dit is een expliciete financiële transactie. De gebeurtenis wordt vastgelegd op basis van de boekingsdatum en -tijd van het verkoopfactuurjournaal (CustInvoiceJour). Vastleggen Leg de boekingstimestamp van het verkoopfactuurjournaal vast. Gebeurtenistype explicit
	Goederen verzonden	Deze gebeurtenis geeft aan dat de verpakte goederen zijn verzonden en het magazijn hebben verlaten. In Dynamics 365 wordt dit formeel vastgelegd door de pakbon te boeken.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal: het interne afhandelingsproces is afgerond en de levering begint. De timestamp is belangrijk om te meten of verzendingen op tijd plaatsvinden. Waar vind je dit? Dit is een duidelijke, expliciete gebeurtenis, vastgelegd op basis van de boekingsdatum en -tijd van het pakbonjournaal (CustPackingSlipJour). Vastleggen Leg de boekingstimestamp van het pakbonjournaal vast. Gebeurtenistype explicit
	Order afgesloten	De eindstatus van een succesvol verwerkte verkooporder. De order is volledig verzonden en gefactureerd en er worden geen verdere transacties verwacht. Dit markeert de succesvolle afronding van het proces.
Waarom dit belangrijk is Deze activiteit is het belangrijkste eindpunt voor succesvol afgeronde cases. De activiteit is nodig om de doorlooptijd van begin tot eind en de doorvoer te berekenen. Waar vind je dit? Dit wordt afgeleid uit de statusvelden in de SalesTable. Een order geldt als afgesloten wanneer de ‘Sales status’ op ‘Invoiced’ staat en ook de status van de orderregels ‘Invoiced’ is. Vastleggen Leid de gebeurtenis af uit statusvelden in de SalesTable die veranderen in ‘Invoiced’. De timestamp is meestal de datum van de laatste gerelateerde transactie, zoals facturatie of betaling. Gebeurtenistype inferred
	Order bevestigd	Deze activiteit geeft aan dat de verkooporder formeel is bevestigd en dat de levering van de opgegeven goederen of diensten is toegezegd. In Dynamics 365 voert een gebruiker hiervoor een expliciete handeling uit, die een bevestigingsjournaal aanmaakt.
Waarom dit belangrijk is De bevestiging is een belangrijke mijlpaal en markeert de officiële start van de orderafhandeling. Door de tijd tussen aanmaak en bevestiging te meten, zie je hoe efficiënt de verwerking aan de voorkant verloopt. Waar vind je dit? Dit is een expliciete gebeurtenis, vastgelegd op basis van de boekingsdatum van het bevestigingsjournaal voor de verkooporder (SalesConfirmJour). De timestamp kan worden gekoppeld aan de SalesTable. Vastleggen Leg de boekingstimestamp van het bevestigingsjournaal voor de verkooporder vast. Gebeurtenistype explicit
	Verkooporder aangemaakt	Deze gebeurtenis markeert het moment waarop een verkoopmedewerker of een geautomatiseerd kanaal de verkooporder voor het eerst in het systeem aanmaakt. De gebeurtenis wordt expliciet vastgelegd wanneer een nieuw record wordt aangemaakt en opgeslagen in de primaire tabel voor verkooporders.
Waarom dit belangrijk is Deze activiteit is het vaste startpunt voor alle cases met verkooporders. De timestamp vormt de basis voor het berekenen van de totale doorlooptijd van een verkooporder en het analyseren van de doorvoer. Waar vind je dit? Dit is een expliciete gebeurtenis, vastgelegd op basis van het veld ‘Created date and time’ in de kopregel van het SalesTable-record in Microsoft Dynamics 365. Vastleggen Lees de timestamp van aanmaak uit de SalesTable-entiteit. Gebeurtenistype explicit
	Goederen geleverd	Geeft aan dat de zending op het opgegeven adres van de klant is afgeleverd. Deze informatie komt vaak uit het systeem van een externe vervoerder of wordt handmatig bevestigd.
Waarom dit belangrijk is Deze activiteit is belangrijk om de KPI ‘Leverdatums nakomen’ te meten en de werkelijke doorlooptijd vanuit het oogpunt van de klant te begrijpen. Ook kun je hiermee de prestaties van vervoerders beoordelen. Waar vind je dit? In standaard-D365 wordt dit niet standaard als expliciete gebeurtenis bijgehouden. Meestal wordt de gebeurtenis afgeleid uit een update van een vervoerdersintegratie of een handmatige statuswijziging van de verkooporder of zending. Vastleggen Leid de gebeurtenis af uit een geïntegreerde gegevensstroom van de vervoerder of een handmatige wijziging van een statusveld. Gebeurtenistype inferred
	Goederen verpakt	Deze activiteit markeert het einde van het verpakkingsproces. De verzamelde artikelen worden samengevoegd en klaargemaakt voor verzending. In D365 kan dit samenvallen met het aanmaken van een pakbon.
Waarom dit belangrijk is De tijd tussen verzamelen en verpakken kan bottlenecks bij de inpakstations aan het licht brengen. Dit is een belangrijke deelstap in de totale doorlooptijd van de orderafhandeling. Waar vind je dit? Dit kan een expliciete gebeurtenis zijn die wordt vastgelegd wanneer het verpakken van een container in de WMS-module is afgerond. De gebeurtenis kan ook worden afgeleid uit het aanmaken van het pakbonjournaal (CustPackingSlipJour), wat vaak het einde van het verpakken markeert. Vastleggen Leid de gebeurtenis af uit de afronding van het verpakkingswerk of de aanmaakdatum van het pakbonjournaal. Gebeurtenistype inferred
	Goederen verzameld	Geeft aan dat alle artikelen voor de order fysiek uit hun magazijnlocaties zijn verzameld. Dit wordt meestal vastgelegd wanneer een medewerker een verzamellijst of werkorder afrondt in de WMS-module.
Waarom dit belangrijk is De afrondingstijd van het verzamelen volgen is belangrijk om de efficiëntie van het magazijn te analyseren. Vertragingen in deze fase hebben direct invloed op de totale verzendtijd. Waar vind je dit? Dit is een expliciete gebeurtenis in de module Warehouse Management. De gebeurtenis wordt vastgelegd op basis van de afrondingstimestamp van het magazijnwerk (WHSWorkTable) voor het verzamelen van de verkooporder. Vastleggen Leg de timestamp vast waarop de status van het verzamelwerk wordt gewijzigd in ‘Closed’. Gebeurtenistype explicit
	Kredietcontrole uitgevoerd	Geeft aan dat de kredietcontrole voor de klant bij de verkooporder is afgerond. Dit kan een automatische systeemcontrole of een handmatige beoordeling zijn. Vaak verandert hierdoor de kredietstatus van de order.
Waarom dit belangrijk is Door de duur en uitkomsten van kredietcontroles te analyseren, kun je bottlenecks in het goedkeuringsproces van orders vinden. Regelmatige blokkeringen of lange goedkeuringstijden kunnen de afhandeling van orders flink vertragen. Waar vind je dit? Meestal afgeleid uit statuswijzigingen voor kredietbeheer in de SalesTable, bijvoorbeeld wanneer een order met de status ‘On hold’ en een kredietreden de status ‘Open’ krijgt. Als de geavanceerde module wordt gebruikt, kan de gebeurtenis ook zijn vastgelegd in tabellen voor kredietbeheer. Vastleggen Leid de gebeurtenis af uit de statuswijzigingsgeschiedenis van de SalesTable of uit gerelateerde tabellen voor kredietblokkeringen. Gebeurtenistype inferred
	Order geannuleerd	Deze gebeurtenis geeft aan dat een verkooporder is geannuleerd voordat deze volledig was verzonden en gefactureerd. Dit is een alternatieve, niet-succesvolle afsluiting van het proces.
Waarom dit belangrijk is Door annuleringen te volgen, kun je oorzaken van verloren verkopen of procesproblemen vinden. Analyse van het moment en de reden van annulering kan leiden tot procesverbeteringen. Waar vind je dit? Dit wordt afgeleid uit het veld ‘Sales status’ in de SalesTable, dat verandert in ‘Canceled’. De timestamp is het moment waarop deze statuswijziging is vastgelegd. Vastleggen Leid de gebeurtenis af uit het veld ‘Sales status’ in de SalesTable, dat verandert in ‘Canceled’. Gebeurtenistype inferred
	Voorraad gereserveerd	Deze gebeurtenis geeft aan dat de benodigde voorraad voor de verkooporderregels fysiek of automatisch in het systeem is gereserveerd. Zo zijn de artikelen beschikbaar om te verzamelen en de order af te handelen.
Waarom dit belangrijk is Door voorraadreserveringen te volgen, kun je vertragingen tussen orderbevestiging en de start van de magazijnactiviteiten analyseren. Dit is belangrijk voor de KPI ‘Doorlooptijd voorraadtoewijzing’. Waar vind je dit? Dit kan worden afgeleid uit het aanmaken of bijwerken van voorraadtransactierecords (InventTrans) die aan de verkooporderregels zijn gekoppeld. De status geeft dan aan dat de voorraad is gereserveerd, bijvoorbeeld ‘On order’ of ‘Reserved physical’. Vastleggen Leid de gebeurtenis af uit de timestamp waarop voorraadtransacties (InventTrans) voor de order als gereserveerd zijn gemarkeerd. Gebeurtenistype inferred
	Vrijgegeven aan magazijn	Markeert het moment waarop de verkooporder formeel wordt vrijgegeven aan het magazijn om de artikelen te verzamelen en te verzenden. Dit is een aparte stap in omgevingen met de module Warehouse Management (WMS).
Waarom dit belangrijk is Deze activiteit markeert de overgang van orderverwerking naar de fysieke afhandeling. Door te analyseren hoelang een order op vrijgave wacht, kun je problemen met de planning van middelen of systeemintegraties opsporen. Waar vind je dit? Dit is een expliciete gebeurtenis, vastgelegd in de magazijnvrijgaverecords (WHSLoadTable, WHSShipmentTable) die bij de verkooporder horen. Vastleggen Leg de timestamp vast waarop de bijbehorende magazijnlading of zending is aangemaakt. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Microsoft Dynamics 365

Stappen

Stel de export naar Azure Data Lake in: Controleer in je Dynamics 365 Finance and Operations-omgeving of de invoegtoepassing 'Export to Azure Data Lake' is geïnstalleerd en ingesteld. Hiervoor koppel je D365 aan een Azure-abonnement en een Azure Data Lake Storage Gen2-account als bestemming.
Selecteer tabellen voor export: Ga in Dynamics 365 naar de werkruimte 'Export to Data Lake'. Zoek de volgende tabellen en voeg ze toe aan de exportinstellingen: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable en CustTable. Activeer de export voor alle geselecteerde tabellen.
Stel Azure Synapse Analytics in: Implementeer in de Azure-portal een Azure Synapse Analytics-werkruimte. Geef deze werkruimte de benodigde rechten, zoals 'Storage Blob Data Contributor', voor het Data Lake-account waarin de D365-data staat.
Maak een serverloze SQL-database: Ga in Synapse Studio naar de hub 'Data'. Maak een serverloze SQL-database om met T-SQL-query’s toegang te krijgen tot de data in het Data Lake.
Maak weergaven voor D365-tabellen: Maak SQL-weergaven in de serverloze database die verwijzen naar de gerepliceerde D365-tabeldata in het Data Lake. Zo hoef je de onderliggende bestandspaden en -formaten niet zelf te gebruiken. Bijvoorbeeld: CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
Bereid de SQL-query voor: Open een nieuw SQL-script in Synapse Studio en maak verbinding met je serverloze database. Kopieer de volledige SQL-query uit deze documentatie naar de scripteditor.
Pas de queryparameters aan: Zoek de tijdelijke waarden bovenaan de query. Vervang '{YourDataAreaId}' door de bedrijfscode die je wilt analyseren. Vul bij '{StartDate}' en '{EndDate}' de gewenste begin- en einddatum van de extractie in.
Voer de query uit: Voer het volledige SQL-script uit. De query haalt gebeurtenissen uit verschillende tabellen op en voegt ze samen tot één gestandaardiseerd event log.
Controleer en exporteer de resultaten: Controleer na afloop in het resultatenvenster van Synapse Studio of de resultaten volledig en correct zijn opgemaakt. Gebruik de ingebouwde exportfunctie om ze als CSV-bestand op te slaan.
Maak het bestand klaar om te uploaden: Open het geëxporteerde CSV-bestand en controleer of het UTF-8-gecodeerd is. Controleer ook of de kolomkoppen exact overeenkomen met de vereiste attributen, zoals SalesOrderNumber, ActivityName en EventTime.
Upload naar ProcessMind: Upload het definitieve, gecontroleerde CSV-bestand naar je ProcessMind-project voor analyse en visualisatie.

Configuratie

Vereisten: Voor deze methode heb je een actief Azure-abonnement nodig en moet 'Export to Azure Data Lake' zijn ingesteld voor je Dynamics 365 F&O-omgeving. Je hebt de juiste rechten nodig in Azure (voor het beheer van Synapse en Storage) en in D365 (om data-exports in te stellen).
Benodigde D365-modules: Voor het vastleggen van alle gebeurtenissen, vooral magazijnactiviteiten, heb je de module Warehouse Management (WMS) nodig. Voor de belangrijkste gebeurtenissen zijn de modules Sales and Marketing en Accounts Receivable nodig.
Tabellen selecteren: Activeer de export voor alle tabellen waarnaar de query verwijst: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable en CustTable. Ontbrekende tabellen leiden tot ontbrekende activiteiten.
Filteren op datumbereik: De query gebruikt de parameters {StartDate} en {EndDate} om een datumbereik in te stellen. Voor de eerste extractie is een beperkte periode, bijvoorbeeld 3 tot 6 maanden, aan te raden. Zo blijft de query uitvoerbaar binnen een redelijke tijd.
Filteren op bedrijf (DataAreaId): Stel de tijdelijke waarde '{YourDataAreaId}' in op een specifieke juridische entiteit in je D365-omgeving. De query is niet bedoeld om meerdere bedrijven in één keer te analyseren.
Prestaties: Bij grote datasets kunnen de prestaties van een query op een serverloze SQL-pool wisselen. Plan de extractie zo nodig buiten piekuren. Als je vaak data extraheert, kun je het definitieve event log als nieuwe tabel in het Data Lake opslaan om latere verwerking te versnellen.

Voorbeeldquery sql

WITH SalesOrderBase AS (
    SELECT
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME AS CustomerName,
        ST.SHIPPINGDATECONFIRMED AS ConfirmedDeliveryDate,
        ST.DELIVERYDATE AS RequestedDeliveryDate,
        ST.PURCHORDERFORMNUM AS SalesChannel, -- Example mapping, adjust if you use a different field for Sales Channel
        SUM(SL.LINEAMOUNT) AS OrderValue
    FROM dbo.SALESTABLE ST
    LEFT JOIN dbo.SALESLINE SL ON ST.SALESID = SL.SALESID AND ST.DATAREAID = SL.DATAREAID
    LEFT JOIN dbo.CUSTTABLE CT ON ST.CUSTACCOUNT = CT.ACCOUNTNUM AND ST.DATAREAID = CT.DATAREAID
    WHERE ST.DATAREAID = '{YourDataAreaId}'
      AND ST.CREATEDDATETIME >= '{StartDate}' AND ST.CREATEDDATETIME < '{EndDate}'
    GROUP BY
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME,
        ST.SHIPPINGDATECONFIRMED,
        ST.DELIVERYDATE,
        ST.PURCHORDERFORMNUM
)
-- 1. Sales Order Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Sales Order Created' AS ActivityName,
    ST.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID

UNION ALL

-- 2. Credit Check Performed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Credit Check Performed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime, -- This assumes a status change date reflects the credit check time
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.CREDITLIMITTYPE > 0 -- Example condition for a credit check being done. Adjust based on your configuration.

UNION ALL

-- 3. Order Confirmed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Confirmed' AS ActivityName,
    CJ.CONFIRMDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTCONFIRMJOUR CJ ON SO.SALESID = CJ.SALESID AND SO.DATAREAID = CJ.DATAAREAID

UNION ALL

-- 4. Inventory Reserved (approximated by first line item reservation)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Inventory Reserved' AS ActivityName,
    MIN(SL.CREATEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESLINE SL ON SO.SALESID = SL.SALESID AND SO.DATAREAID = SL.DATAREAID
WHERE SL.RESERVATION > 0 -- Identifies lines with a reservation status
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 5. Released To Warehouse
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Released To Warehouse' AS ActivityName,
    WLT.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSLOADTABLE WLT ON SO.SALESID = WLT.SALESID AND SO.DATAREAID = WLT.DATAAREAID

UNION ALL

-- 6. Goods Picked (approximated by last pick work closure)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Picked' AS ActivityName,
    MAX(WWT.MODIFIEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSWORKTABLE WWT ON SO.SALESID = WWT.ORDERNUM AND SO.DATAREAID = WWT.DATAAREAID
WHERE WWT.WORKTYPE = 'Pick' AND WWT.WORKSTATUS = 'Closed'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 7. Goods Packed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Packed' AS ActivityName,
    PSJ.CREATEDDATETIME AS EventTime, -- Using creation time of packing slip as proxy
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 8. Goods Shipped
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Shipped' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 9. Goods Delivered (placeholder, often requires custom fields)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Delivered' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime, -- Placeholder, using shipment date. True delivery requires external data.
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID
WHERE 1 = 2 -- This will return no rows unless logic is added to read from a custom field with actual delivery dates

UNION ALL

-- 10. Invoice Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Invoice Created' AS ActivityName,
    CIJ.INVOICEDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID

UNION ALL

-- 11. Payment Received (approximated by last settlement date)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Payment Received' AS ActivityName,
    MAX(CT.SETTLEMENTDATE) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID
JOIN dbo.CUSTTRANS CT ON CIJ.INVOICEID = CT.INVOICE AND CIJ.DATAAREAID = CT.DATAAREAID
WHERE CT.TRANSTYPE = 'Payment'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 12. Order Closed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Closed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 4 -- Status for 'Invoiced'

UNION ALL

-- 13. Order Cancelled
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Cancelled' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 3; -- Status for 'Canceled'

Stappen

Vereisten en installatie: Zorg dat Python 3.6 of hoger is geïnstalleerd. Installeer de benodigde Python-bibliotheken met deze opdracht in de terminal: pip install pandas requests msal.
Registreer een toepassing in Azure AD: Registreer in de Azure-portal een nieuwe toepassing in Azure Active Directory. Deze toepassing wordt gebruikt voor verificatie bij de Dynamics 365 API. Noteer de Application (client) ID en Directory (tenant) ID.
Maak een client secret aan: Maak in de zojuist geregistreerde Azure AD-toepassing onder 'Certificates & secrets' een nieuw client secret aan. Kopieer de waarde meteen, want je kunt die later niet meer bekijken. Dit is je CLIENT_SECRET.
Ken API-rechten toe: Ga in de instellingen van de Azure AD-toepassing naar 'API permissions'. Voeg een recht toe voor 'Dynamics ERP' of 'Dynamics 365 for Finance and Operations'. Selecteer 'Delegated permissions' en ken user_impersonation toe. Voeg daarna hetzelfde recht nogmaals toe, maar selecteer 'Application permissions' en ken Financials.ReadWrite.All toe, of een beperkter alleen-lezenrecht als dat beschikbaar en voldoende is. Geef beheerderstoestemming voor deze rechten.
Maak een toepassingsgebruiker aan in Dynamics 365: Ga in je Dynamics 365-omgeving naar 'System administration' > 'Users' > 'Users'. Maak een gebruiker aan en koppel die aan de Application ID van je Azure AD-toepassingsregistratie. Wijs een beveiligingsrol toe, zoals 'System administrator' (voor volledige toegang) of een aangepaste rol met leesrechten voor de benodigde data-entiteiten, zoals SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders en SalesInvoiceHeadersV2.
Stel het Python-script in: Open het meegeleverde Python-script in een editor. Zoek bovenaan het configuratiegedeelte en vervang de tijdelijke waarden voor D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE en END_DATE door de gegevens van je omgeving.
Stel entiteitstoewijzingen in (optioneel): Controleer de entiteits- en veldnamen in het script. Als je organisatie aangepaste entiteiten of velden gebruikt om bepaalde activiteiten bij te houden, moet je mogelijk de OData-query’s in het script aanpassen.
Voer het extractiescript uit: Voer het script vanaf de opdrachtregel uit met de opdracht python your_script_name.py. Het script meldt zich aan, bevraagt voor elke activiteit de Dynamics 365 OData API en verwerkt de data. De voortgang verschijnt in de console.
Controleer het uitvoerbestand: Na een geslaagde uitvoering maakt het script in dezelfde map een CSV-bestand met de naam d365_order_to_cash_event_log.csv. Open het bestand en controleer of het event log volledig en correct is.
Upload naar ProcessMind: Het gegenereerde CSV-bestand heeft de vereiste indeling en kan direct naar ProcessMind worden geüpload voor procesanalyse.

Configuratie

D365_URL: De basis-URL van je Dynamics 365 Finance and Operations-omgeving. Deze ziet er bijvoorbeeld zo uit: https://[your-d365-environment-name].operations.dynamics.com.
TENANT_ID: De Directory (tenant) ID van je Azure Active Directory-exemplaar. Je vindt deze op de overzichtspagina van je Azure AD-toepassingsregistratie.
CLIENT_ID: De Application (client) ID van de toepassing die je in Azure AD hebt geregistreerd.
CLIENT_SECRET: De waarde van het client secret dat je voor de Azure AD-toepassing hebt aangemaakt.
COMPANY_FILTER: Hiermee geef je de juridische entiteit in Dynamics 365 op waaruit je data haalt, bijvoorbeeld 'USMF'. Dit verplichte filter zorgt ervoor dat je de data van het juiste bedrijf opvraagt.
START_DATE / END_DATE: Hiermee stel je het datumbereik voor de extractie in met de notatie 'YYYY-MM-DD'. Voor een eerste analyse is een periode van 3 tot 6 maanden aan te raden, zodat de hoeveelheid data beheersbaar blijft en je de processen goed kunt analyseren. Houd er rekening mee dat een groot datumbereik de extractie aanzienlijk kan vertragen.
Vereisten: Je hebt toegang tot Azure AD nodig om een toepassing te registreren en rechten toe te kennen. Ook heb je een Dynamics 365-gebruikersaccount nodig met rechten om een toepassingsgebruiker aan te maken en beveiligingsrollen toe te wijzen. De toegewezen rol moet leesrechten hebben voor alle entiteiten die het script opvraagt.

Voorbeeldquery python

import requests
import pandas as pd
import msal
import json
import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your D365 environment and Azure AD App details
D365_URL = class="hl-string">"https://[your-d365-environment-name].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your-Azure-AD-Tenant-ID]"
CLIENT_ID = class="hl-string">"[Your-Azure-AD-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Azure-AD-Client-Secret]"

class=class="hl-string">"hl-comment"># --- EXTRACTION PARAMETERS ---
COMPANY_FILTER = class="hl-string">"[Your-Company-Code]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SCRIPT --- 

AUTHORITY_URL = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
RESOURCE = fclass="hl-string">"{D365_URL}/"
API_ENDPOINT = fclass="hl-string">"{D365_URL}/data"

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD and returns an access token."""
    app = msal.ConfidentialClientApplication(
        client_id=CLIENT_ID,
        client_credential=CLIENT_SECRET,
        authority=AUTHORITY_URL
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        raise Exception(class="hl-string">"Could not authenticate.")

def execute_odata_query(access_token, entity, select_fields, filter_query, expand_fields=None):
    class="hl-string">"""Executes an OData query against a D365 entity and handles pagination."""
    all_results = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.maxpagesize=1000' class=class="hl-string">"hl-comment"># Request pagination
    }
    
    query_url = fclass="hl-string">"{API_ENDPOINT}/{entity}?$select={select_fields}&$filter={filter_query}&cross-company=true"
    if expand_fields:
        query_url += fclass="hl-string">"&$expand={expand_fields}"
    
    print(fclass="hl-string">"Querying {entity}...")
    while query_url:
        try:
            response = requests.get(query_url, headers=headers)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_results.extend(data.get(class="hl-string">'value', []))
            query_url = data.get(class="hl-string">'@odata.nextLink') class=class="hl-string">"hl-comment"># Get URL for the next page
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error for {entity}: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            return [] class=class="hl-string">"hl-comment"># Return empty list on error
        except json.JSONDecodeError:
            print(fclass="hl-string">"JSON Decode Error for {entity}. Response was not valid JSON.")
            print(fclass="hl-string">"Response text: {response.text}")
            return []

    print(fclass="hl-string">"...found {len(all_results)} records for {entity}.")
    return all_results

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    try:
        token = get_access_token()
    except Exception as e:
        print(e)
        return

    all_events = []
    now_utc = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for most queries
    base_select_fields = class="hl-string">"SalesOrderNumber,TotalInvoiceAmount,SalesOrderOriginCode,RequestedShippingDate,ConfirmedShippingDate,CustomerAccount"
    base_expand_fields = class="hl-string">"CustomerV3(CustomerName)"

    class=class="hl-string">"hl-comment"># Common date filter for creation/modification timestamps
    date_filter = fclass="hl-string">"(CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z)"

    class=class="hl-string">"hl-comment"># 1. Sales Order Created
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},CreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {date_filter}", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Created',
            class="hl-string">'EventTime': record.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 2. Credit Check Performed (based on status change)
    class=class="hl-string">"hl-comment"># This assumes a credit check is reflected by the CreditLimitApprovalStatus. This logic may need adjustment.
    class=class="hl-string">"hl-comment"># We look for orders modified in the period, then check the status.
    modified_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},ModifiedDateTime,CreditLimitApprovalStatus", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {modified_date_filter} and CreditLimitApprovalStatus ne 'NoCheck'", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Credit Check Performed',
            class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime'), class=class="hl-string">"hl-comment"># Using ModifiedDateTime as a proxy
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 3. Order Confirmed
    confirmation_date_filter = fclass="hl-string">"(ConfirmationDate ge {START_DATE} and ConfirmationDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesConfirmationHeaders', class="hl-string">"SalesOrderNumber,ConfirmationDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {confirmation_date_filter}")
    class=class="hl-string">"hl-comment"># We need to get details from the SalesOrderHeader
    order_numbers = class="hl-string">"'" + class="hl-string">"','".join([rec[class="hl-string">'SalesOrderNumber'] for rec in data if rec.get(class="hl-string">'SalesOrderNumber')]) + class="hl-string">"'"
    if order_numbers != class="hl-string">"''":
        header_data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', base_select_fields, fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({order_numbers})", base_expand_fields)
        header_map = {h[class="hl-string">'SalesOrderNumber']: h for h in header_data}
        for record in data:
            header = header_map.get(record.get(class="hl-string">'SalesOrderNumber'))
            if header:
                all_events.append({
                    class="hl-string">'SalesOrderNumber': header.get(class="hl-string">'SalesOrderNumber'),
                    class="hl-string">'ActivityName': class="hl-string">'Order Confirmed',
                    class="hl-string">'EventTime': str(record.get(class="hl-string">'ConfirmationDate')) + class="hl-string">'T12:00:00Z', class=class="hl-string">"hl-comment"># Date only field, adding midday time
                    class="hl-string">'OrderValue': header.get(class="hl-string">'TotalInvoiceAmount'),
                    class="hl-string">'CustomerName': header.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
                    class="hl-string">'SalesChannel': header.get(class="hl-string">'SalesOrderOriginCode'),
                    class="hl-string">'RequestedDeliveryDate': header.get(class="hl-string">'RequestedShippingDate'),
                    class="hl-string">'ConfirmedDeliveryDate': header.get(class="hl-string">'ConfirmedShippingDate')
                })
    
    class=class="hl-string">"hl-comment"># 4 & 5. Inventory Reserved & Released To Warehouse (WMS)
    class=class="hl-string">"hl-comment"># These are complex. This is a proxy based on Warehouse Work creation time.
    work_date_filter = fclass="hl-string">"(WorkCreatedDateTime ge {START_DATE}T00:00:00Z and WorkCreatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WarehouseWorkHeaders', class="hl-string">"OrderNumber,WorkCreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {work_date_filter} and WorkType eq 'SalesOrders'")
    for record in data:
        class=class="hl-string">"hl-comment"># Assuming reservation happens just before release to warehouse
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Inventory Reserved', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Released To Warehouse', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})

    class=class="hl-string">"hl-comment"># 6 & 7. Goods Picked & Goods Packed (WMS)
    class=class="hl-string">"hl-comment"># Proxy using Shipment status updates. This logic may need refinement based on specific WMS setup.
    shipment_date_filter = fclass="hl-string">"(ShipmentStatusLastUpdatedDateTime ge {START_DATE}T00:00:00Z and ShipmentStatusLastUpdatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WHSShipmentTables', class="hl-string">"SalesOrderNumber,ShipmentStatus,ShipmentStatusLastUpdatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {shipment_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Picked', class="hl-string">'Loaded', class="hl-string">'Shipped']:
             all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Picked', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Loaded', class="hl-string">'Shipped']:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Packed', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})

    class=class="hl-string">"hl-comment"># 8. Goods Shipped (Posting Packing Slip)
    packslip_date_filter = fclass="hl-string">"(ShippingDate ge {START_DATE} and ShippingDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ShippingDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Shipped', class="hl-string">'EventTime': str(record.get(class="hl-string">'ShippingDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 9. Goods Delivered
    class=class="hl-string">"hl-comment"># This is often not a standard field. We use ModifiedDateTime on Packing Slip as a placeholder.
    packslip_mod_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ModifiedDateTime,DeliveryMode", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_mod_date_filter} and DeliveryMode eq '[Your-Delivered-Status-Code]'")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Delivered', class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})

    class=class="hl-string">"hl-comment"># 10. Invoice Created
    invoice_date_filter = fclass="hl-string">"(InvoiceDate ge {START_DATE} and InvoiceDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesInvoiceHeadersV2', class="hl-string">"SalesOrderNumber,InvoiceDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': str(record.get(class="hl-string">'InvoiceDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 11. Payment Received
    class=class="hl-string">"hl-comment"># This requires looking at customer payments and settling them to invoices, then to sales orders.
    class=class="hl-string">"hl-comment"># This is a simplified proxy using the ClosedDate of the invoice.
    invoice_closed_date_filter = fclass="hl-string">"(ClosedDate ge {START_DATE} and ClosedDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'CustomerInvoices', class="hl-string">"SalesOrderNumber,ClosedDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_closed_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ClosedDate') and record.get(class="hl-string">'SalesOrderNumber'):
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Received', class="hl-string">'EventTime': str(record.get(class="hl-string">'ClosedDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 12 & 13. Order Closed & Order Cancelled
    class=class="hl-string">"hl-comment"># These are statuses on the Sales Order Header.
    status_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', class="hl-string">"SalesOrderNumber,SalesOrderStatus,ModifiedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {status_date_filter} and (SalesOrderStatus eq 'Invoiced' or SalesOrderStatus eq 'Canceled')")
    for record in data:
        activity = class="hl-string">''
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Invoiced': activity = class="hl-string">'Order Closed'
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Canceled': activity = class="hl-string">'Order Cancelled'
        if activity:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})


    class=class="hl-string">"hl-comment"># --- Final Processing ---
    if not all_events:
        print(class="hl-string">"No events found. Exiting.")
        return

    df = pd.DataFrame(all_events)
    print(fclass="hl-string">"Total events created: {len(df)}")

    class=class="hl-string">"hl-comment"># Drop events without a case ID or timestamp
    df.dropna(subset=[class="hl-string">'SalesOrderNumber', class="hl-string">'EventTime'], inplace=True)
    print(fclass="hl-string">"Events after dropping nulls: {len(df)}")

    class=class="hl-string">"hl-comment"># Fill in missing recommended attributes by merging back header details
    print(class="hl-string">"Enriching data with header attributes...")
    unique_orders = class="hl-string">"'" + class="hl-string">"','".join(df[class="hl-string">'SalesOrderNumber'].unique()) + class="hl-string">"'"
    if unique_orders != class="hl-string">"''":
        header_data_final = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields}", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({unique_orders})", base_expand_fields)
        header_df = pd.DataFrame(header_data_final)
        if not header_df.empty:
            header_df = header_df.rename(columns={
                class="hl-string">'TotalInvoiceAmount': class="hl-string">'OrderValue',
                class="hl-string">'SalesOrderOriginCode': class="hl-string">'SalesChannel',
                class="hl-string">'RequestedShippingDate': class="hl-string">'RequestedDeliveryDate',
                class="hl-string">'ConfirmedShippingDate': class="hl-string">'ConfirmedDeliveryDate'
            })
            class=class="hl-string">"hl-comment"># Extract nested customer name
            header_df[class="hl-string">'CustomerName'] = header_df[class="hl-string">'CustomerV3'].apply(lambda x: x.get(class="hl-string">'CustomerName') if isinstance(x, dict) else None)
            df = df.merge(header_df[[class="hl-string">'SalesOrderNumber', class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']], on=class="hl-string">'SalesOrderNumber', how=class="hl-string">'left', suffixes=(class="hl-string">'', class="hl-string">'_y'))
            class=class="hl-string">"hl-comment"># Fill NaNs from merge
            for col in [class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']:
                if col + class="hl-string">'_y' in df.columns:
                    df[col] = df[col].fillna(df[col + class="hl-string">'_y'])
                    df.drop(columns=[col + class="hl-string">'_y'], inplace=True)

    class=class="hl-string">"hl-comment"># Add required static columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataUpdate'] = now_utc

    class=class="hl-string">"hl-comment"># Ensure required columns exist
    final_cols = [class="hl-string">'SalesOrderNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
                  class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']
    for col in final_cols:
        if col not in df.columns:
            df[col] = None
    
    class=class="hl-string">"hl-comment"># Reorder and save
    df = df[final_cols]
    df.to_csv(class="hl-string">'d365_order_to_cash_event_log.csv', index=False)
    print(class="hl-string">"Successfully created d365_order_to_cash_event_log.csv")

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

Klaar om te beginnen?

Gebruik deze template om je data voor te bereiden en upload die daarna naar ons platform. Zo zie je waar je de verwerking van verkooporders kunt verbeteren en efficiënter maken. Ga vandaag nog aan de slag.

Terug naar de verbetergids

Template downloaden

Verbeter nu Order to Cash - Verwerking van verkooporders

Spoor inefficiënties op en verkort de doorlooptijd met 30%, zodat orders sneller worden afgehandeld.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.

Datatemplate voor Order to Cash - Verwerking van verkooporders

Datatemplate voor Order to Cash - Verwerking van verkooporders

Attributen voor Order to Cash - Verwerking van verkooporders

Activiteiten voor Order to Cash - Verwerking van verkooporders

Extractiegidsen

SQL-query op Azure Data Lake via Synapse Analytics

Stappen

Configuratie

Voorbeeldquery sql

Python-script met de Dynamics 365 OData Web API

Stappen

Configuratie

Voorbeeldquery python

Klaar om te beginnen?

Verbeter nu Order to Cash - Verwerking van verkooporders