> Continue procesverbetering > Order to Cash verwerking van verkooporders > Microsoft Dynamics 365 > Datatemplate

Jouw datatemplate voor Order to Cash-salesorderverwerking

Microsoft Dynamics 365

Order to Cash - kenmerken van verkooporderverwerking (20) Order to Cash - activiteiten voor verkooporderverwerking (13) Extractiegidsen (2)

Jouw datatemplate voor Order to Cash-salesorderverwerking

Deze template geeft een gestructureerd overzicht van de essentiële data die je nodig hebt om je Order to Cash-salesorderverwerking in Microsoft Dynamics 365 te analyseren. Je ziet welke belangrijke attributen je verzamelt en welke activiteiten je in je event log volgt. Daarnaast vind je praktische aanwijzingen om deze data effectief uit je systeem te halen.

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

Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Template downloaden

Order to Cash - kenmerken van verkooporderverwerking

Dit zijn de aanbevolen datavelden voor je event log, zodat je de verkooporderverwerking binnen Order to Cash in Microsoft Dynamics 365 volledig kunt analyseren.

5 Verplicht 5 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment binnen het verkooporderproces plaatsvond.
Beschrijving Dit attribuut staat voor een afzonderlijke stap of gebeurtenis in de levenscyclus van een verkooporder, zoals 'Sales Order Created', 'Goods Shipped' of 'Payment Received'. De volgorde van deze activiteiten voor een bepaalde verkooporder vormt de procesflow. Het analyseren van de volgorde, frequentie en overgangen tussen activiteiten vormt de kern van process mining. Hiermee kun je de proceskaart visualiseren, veelvoorkomende en zeldzame procesvarianten herkennen, knelpunten opsporen en plekken met herstelwerk of non-compliance vinden. Dit attribuut is essentieel om te begrijpen wat er in het proces werkelijk gebeurt. Waarom dit belangrijk is Het definieert de processtappen. Daardoor kun je de procesflow opbouwen en visualiseren, het belangrijkste doel van process mining. Waar je het vindt 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 Salesorder aangemaaktGoederen verzondenFactuur aangemaaktBetaling ontvangen
	Salesorder SalesOrderNumber	De unieke identificatie van elke salesorder, die als primaire case-ID voor het proces dient.
Beschrijving Het Sales Order Number is een unieke alfanumerieke code die in Microsoft Dynamics 365 aan elke klantorder wordt toegekend. Het is de centrale Case ID waaraan alle gerelateerde activiteiten en gebeurtenissen van aanmaak tot afsluiting zijn gekoppeld. Binnen process mining is dit attribuut essentieel om de end-to-end journey van elke afzonderlijke verkooporder te reconstrueren. Analisten kunnen hiermee de volledige reeks activiteiten volgen, de doorlooptijd per case meten en varianten per order analyseren. Daarmee vormt het de basis van de volledige procesanalyse. Waarom dit belangrijk is Deze identifier is belangrijk om alle gerelateerde gebeurtenissen aan elkaar te koppelen. Zo kun je de volledige levenscyclus van elke verkooporder end-to-end analyseren. Waar je het vindt Te vinden in de tabel 'SalesTable', veld 'SalesId'. Voorbeelden SO-00102345SO-00102346SO-00102347
	Starttijd EventTime	De exacte datum en tijd waarop een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving De Event Time, oftewel timestamp, legt het exacte moment vast waarop een activiteit plaatsvond. Elke activiteit in het event log heeft een bijbehorende timestamp. Zo ontstaat voor elke case een chronologisch overzicht van het proces. Dit attribuut is essentieel voor alle tijdgebaseerde analyses binnen process mining. Je gebruikt het om doorlooptijden tussen activiteiten te berekenen, de totale duur van een case te meten, wachttijden te analyseren en knelpunten te vinden waar het proces vertraging oploopt. Ook kun je prestaties door de tijd volgen, bijvoorbeeld de throughput per dag, week of maand. Waarom dit belangrijk is Deze timestamp is essentieel voor het berekenen van alle duurgebaseerde meetwaarden, zoals doorlooptijden en knelpunten, en voor het chronologisch ordenen van gebeurtenissen. Waar je het vindt Dit wordt afgeleid uit verschillende datum- en tijdvelden die aan specifieke transacties zijn gekoppeld, zoals 'SalesTable.CreatedDateTime' voor het aanmaken van een order of boekingsdata uit betalingsjournalen voor betalingen. Voorbeelden 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Bronsysteem SourceSystem	Identificeert het informatiesysteem waaruit de data afkomstig is.
Beschrijving Dit attribuut geeft aan in welke bronapplicatie de eventdata is vastgelegd. In deze context is dat meestal 'Microsoft Dynamics 365'. Bij een analyse van één systeem lijkt dit misschien overbodig. Zodra je data uit meerdere systemen samenvoegt, bijvoorbeeld uit een apart CRM- of magazijnbeheersysteem, wordt het belangrijk. Het maakt de herkomst van data inzichtelijk en helpt bij het oplossen van problemen met data-extractie, omdat je kunt zien waar de records vandaan komen. Waarom dit belangrijk is Het geeft belangrijke context over de herkomst van data, vooral wanneer je data uit meerdere systemen combineert. Zo blijft de herkomst van de data duidelijk. Waar je het vindt Dit is een statische 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 uit het bronsysteem is vernieuwd of opgehaald.
Beschrijving Dit attribuut legt de datum en tijd vast waarop de data voor het laatst uit Microsoft Dynamics 365 is opgehaald. Zo zie je hoe actueel de geanalyseerde data is. Voor elke procesanalyse is het belangrijk om te weten hoe recent de data is. Deze timestamp geeft vertrouwen in de data, omdat je precies ziet wanneer die voor het laatst is bijgewerkt. Zo baseer je conclusies op actuele informatie. 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 je het vindt Dit wordt gegenereerd tijdens de data-extractie en tijdens het data-innameproces aan elk record toegevoegd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Aangevraagde leverdatum RequestedDeliveryDate	De leverdatum die de klant voor de order heeft aangevraagd.
Beschrijving Dit attribuut bevat de datum waarop de klant de goederen oorspronkelijk wilde ontvangen. De datum wordt vastgelegd bij het aanmaken van de order en vormt het uitgangspunt om de leverprestatie vanuit het perspectief van de klant te meten. Deze datum is een belangrijke invoer voor het dashboard 'Delivery Date Adherence'. Door 'RequestedDeliveryDate' te vergelijken met 'ConfirmedDeliveryDate' en de werkelijke datum van 'Goods Delivered', zie je in hoeverre de organisatie aan de verwachtingen van klanten voldoet. Grote verschillen kunnen wijzen op problemen met planning, voorraad of logistiek. Waarom dit belangrijk is Is de leververwachting van de klant en vormt een belangrijke basis voor het meten van klanttevredenheid en tijdige levering. Waar je het vindt Te vinden in de tabel 'SalesTable', meestal met de naam 'DeliveryDate' of een vergelijkbare variant. Voorbeelden 2023-05-102023-06-012023-05-25
	Bevestigde leverdatum ConfirmedDeliveryDate	De leverdatum die het bedrijf aan de klant heeft bevestigd en toegezegd.
Beschrijving De Confirmed Delivery Date is de datum waarop de verkopende organisatie de levering van de goederen aan de klant belooft. Deze datum wordt vastgesteld nadat interne controles, zoals de beschikbaarheid van voorraad en productieschema's, zijn afgerond. Dit attribuut is essentieel voor het berekenen van de KPI 'Delivery Date Adherence Rate' vanuit het perspectief van de operationele toezegging. Het biedt een realistischer interne referentie voor tijdige levering dan de oorspronkelijke aanvraag van de klant. Door afwijkingen van deze datum te analyseren, vind je problemen in logistiek en orderafhandeling. Waarom dit belangrijk is Vertegenwoordigt de toezegging van het bedrijf aan de klant en vormt daarmee een belangrijke interne referentie voor het meten van de betrouwbaarheid van de orderafhandeling en de operationele prestaties. Waar je het vindt Te vinden in de gegevens van verkooporderregels, vaak in de tabel 'SalesLine' met een veldnaam zoals 'ConfirmedDlv'. Voorbeelden 2023-05-122023-06-012023-05-28
	Klantnaam CustomerName	De naam van de klant die de verkooporder heeft geplaatst.
Beschrijving Dit attribuut bevat de wettelijke naam van de klant die aan de verkooporder is gekoppeld. De naam wordt opgehaald door het klantrekeningnummer op de verkooporder te koppelen aan de centrale klantgegevens. Een analyse per klant is belangrijk om klantgedrag en serviceniveaus te begrijpen. Je ziet welke klanten de meeste vertraging ervaren, welke klanten het meeste herstelwerk veroorzaken en welke klanten niet-standaard procesroutes volgen. Dat helpt om de klanttevredenheid te verbeteren en belangrijke klantrelaties goed te beheren. Waarom dit belangrijk is Maakt klantgerichte analyse mogelijk. Zo vind je patronen, vertragingen of problemen die specifiek zijn voor bepaalde klanten en direct invloed hebben op de klanttevredenheid. Waar je het vindt 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 staat voor het totale financiële bedrag van de verkooporder, inclusief alle artikelen, belastingen en toeslagen. Het is een belangrijke financiële meetwaarde die aan elke case is gekoppeld. Order Value is essentieel voor procesanalyse op basis van waarde. Je kunt het proces segmenteren om te zien of orders met een hoge waarde anders worden afgehandeld of meer vertraging oplopen dan orders met een lage waarde. Zo richt je verbeteringen op de financieel belangrijkste cases en ondersteun je dashboards zoals 'Sales Order Value by Segment'. Waarom dit belangrijk is Maakt financiële segmentatie van het proces mogelijk. Zo kun je verbeteringen bij orders met een hoge waarde prioriteit geven en de financiële gevolgen van procesafwijkingen begrijpen. Waar je het vindt 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 bedragen op verkooporderregels. Voorbeelden 5250.7512300.00899.50
	Verkoopkanaal SalesChannel	Het kanaal waarlangs de verkooporder is ontvangen, zoals Web, Direct Sales of Partner.
Beschrijving Het Sales Channel geeft aan waar de klantorder vandaan komt. Dat kan een e-commercewebsite, een direct salesteam, een winkel, een callcenter of een partnernetwerk zijn. In Dynamics 365 wordt deze dimensie meestal ingericht op basis van de behoeften van de organisatie. Door het proces per verkoopkanaal te analyseren, zie je prestatieverschillen tussen kanalen. Weborders worden bijvoorbeeld sneller en meer automatisch verwerkt dan orders die telefonisch binnenkomen. Dit inzicht helpt bij kanaalspecifieke procesoptimalisatie en capaciteitsverdeling. Het ondersteunt dashboards zoals 'Sales Order Value by Segment'. Waarom dit belangrijk is Maakt het mogelijk om prestaties tussen verschillende verkoopkanalen te vergelijken. Zo worden inefficiënties en goede werkwijzen zichtbaar die specifiek zijn voor de manier waarop orders binnenkomen. Waar je het vindt Deze informatie staat meestal in de kopgegevens van de verkooporder. Raadpleeg de documentatie van Microsoft Dynamics 365 voor het specifieke veld. Voorbeelden WebDirectPartnerRetail
	Artikelnummer ItemNumber	De unieke identifier van een product of dienst op de verkooporder.
Beschrijving Het Item Number identificeert het specifieke product dat 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, vind je problemen die specifiek met een product te maken hebben. Bepaalde producten kunnen bijvoorbeeld samenhangen met langere afhandelingstijden, meer herstelwerk of vaker geblokkeerde orders door kredietcontroles. Zo kun je gericht verbeteringen doorvoeren in voorraadbeheer, productgegevens of de orderafhandeling van specifieke artikelen. Waarom dit belangrijk is Maakt analyse op productniveau mogelijk, zodat je ziet of bepaalde artikelen samenhangen met procesvertragingen, herstelwerk of andere inefficiënties. Waar je het vindt Staat in de tabel 'SalesLine', veld 'ItemId'. Voorbeelden PROD-00123PROD-00548SVC-00045
	Betaling op tijd OnTimePayment	Een booleaanse vlag die aangeeft of de betaling op of vóór de vervaldatum 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 is ontvangen en 'false' als de betaling te laat was. Deze vlag is de kern van de KPI 'Percentage betalingen op tijd'. Je kunt klanten snel indelen in klanten die op tijd betalen en klanten die te laat betalen. Deze analyse helpt bij het bepalen van kredietbeleid, incassostrategieën en klantbeheer, doordat je klanten identificeert die structureel te laat betalen. Waarom dit belangrijk is Meet het betaalgedrag van klanten af tegen de afgesproken voorwaarden. Dat is belangrijk voor het beheer van de kasstroom en de beoordeling van kredietrisico. Waar je het vindt Wordt berekend door de 'EventTime' van de activiteit 'Betaling ontvangen' te vergelijken met het attribuut 'PaymentDueDate'. Formule: ('Betaling ontvangen' Timestamp <= PaymentDueDate). Voorbeelden truefalse
	Eindtijd EndTime	De exacte datum en tijd waarop een activiteit is afgerond.
Beschrijving De End Time-timestamp legt het moment vast waarop een activiteit eindigt. Als deze beschikbaar is, kun je de duur van een activiteit nauwkeuriger meten dan wanneer je die afleidt uit de starttijd van de volgende activiteit. Met zowel een start- als eindtijd kun je de 'Processing Time' van elke activiteit precies berekenen. Zo maak je onderscheid tussen actieve verwerkingstijd en 'Waiting Time' tussen activiteiten. Dat helpt om te bepalen welke taken veel tijd kosten en bij welke processtappen vooral lange vertragingen ontstaan. Waarom dit belangrijk is Maakt het mogelijk om de verwerkingstijd van afzonderlijke activiteiten precies te berekenen en actieve werktijd te onderscheiden van inactieve wachttijd. Waar je het vindt Net als Start Time wordt dit afgeleid uit verschillende datum- en tijdvelden. Het kan bijvoorbeeld gaan om een veld 'ModifiedDateTime' of een specifieke timestamp voor 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 identificeert de specifieke medewerker of systeemgebruiker die verantwoordelijk is voor een taak, zoals het bevestigen van een order of het aanmaken van een factuur. Het is meestal gekoppeld aan een gebruikers-ID in Microsoft Dynamics 365. Door prestaties per gebruiker te analyseren, zie je waar training nodig is, herken je goed presterende medewerkers en kun je de werklast beter verdelen. Het is ook belangrijk voor compliance en audits, omdat je voor elke actie in het proces kunt vaststellen wie verantwoordelijk was. Waarom dit belangrijk is Hiermee kun je procesprestaties per medewerker of team analyseren. Zo vind je kansen voor training, onevenwichtige werkverdeling en knelpunten die met capaciteit te maken hebben. Waar je het vindt Afgeleid uit gebruikers-IDvelden zoals 'CreatedBy' of 'ModifiedBy' in verschillende transactietabellen. Deze worden vervolgens gekoppeld aan de centrale gebruikerstabel, bijvoorbeeld 'UserInfo', om de volledige naam op te halen. Voorbeelden Alice JohnsonRobert BrownSysteembeheerder
	Is herstelwerk IsRework	Een booleaanse vlag die aangeeft of een verkooporder herstelwerk heeft ondergaan, bijvoorbeeld doordat een activiteit opnieuw is uitgevoerd.
Beschrijving Dit berekende attribuut identificeert cases die afwijken van een directe procesflow, de zogenoemde 'happy path'. Herstelwerk wordt vastgesteld door reeksen activiteiten te herkennen waarin een stap opnieuw wordt uitgevoerd. Denk aan een order die eerst wordt gedeblokkeerd en daarna opnieuw wordt bevestigd, of goederen die worden verzameld en vervolgens weer op voorraad worden gelegd. Het markeren van cases met herstelwerk is essentieel voor de KPI 'Herstelwerkpercentage verkooporders'. Analisten kunnen zo inefficiënte procesflows snel selecteren en onderzoeken. Daarmee achterhalen ze de oorzaken van herstelwerk, zoals invoerfouten, kredietproblemen of voorraadproblemen. Herstelwerk verminderen is een belangrijk doel van veel procesverbeteringsprojecten. Waarom dit belangrijk is Helpt procesinefficiëntie te kwantificeren door cases met herhaalde stappen te markeren. Zo kun je gericht analyseren hoe je verspilling en vertragingen vermindert. Waar je het vindt De process mining-tool berekent dit door de activiteitenvolgorde per case te analyseren. Een patroon als (A -> B -> C -> B) markeert de case bijvoorbeeld als herstelwerk. Voorbeelden truefalse
	Land CountryRegion	Het land van het verzendadres van de klant.
Beschrijving Dit attribuut geeft het bestemmingsland voor de verzending van de verkooporder aan. Het is afgeleid van de afleveradresgegevens van de klant die in Dynamics 365 zijn opgeslagen. Door de procesprestaties per land te analyseren, zie je regionale verschillen. Bij internationale zendingen zijn soms extra stappen nodig, zoals inklaring. Daardoor kunnen de doorlooptijden oplopen. Met deze analyse krijg je inzicht in de logistiek van verschillende geografische markten en kun je die verbeteren. Waarom dit belangrijk is Maakt geografische analyse mogelijk, zodat je regionale knelpunten, complianceproblemen of prestatieverschillen in de toeleveringsketen kunt identificeren. Waar je het vindt Afgeleid van het afleveradres van de klant, dat aan de verkooporder is gekoppeld. De landinformatie staat meestal in de tabel 'LogisticsPostalAddress', gekoppeld via de afleveradreslink in 'SalesTable'. Voorbeelden USADEUCANGBR
	Op tijd geleverd OnTimeDelivery	Een booleaanse vlag die aangeeft of de goederen op of vóór de bevestigde leverdatum zijn geleverd.
Beschrijving Dit berekende attribuut vergelijkt de timestamp van de activiteit 'Goederen geleverd' met 'ConfirmedDeliveryDate' voor elke verkooporder. De waarde is 'true' als de levering op tijd of eerder plaatsvond en 'false' als de levering te laat was. Deze vlag vormt de basis voor de KPI 'Nalevingspercentage leverdatum'. Je kunt er eenvoudig op filteren en orders die op tijd of te laat zijn geleverd met elkaar vergelijken. Zo zie je snel welke factoren samenhangen met te late leveringen, zoals specifieke producten, klanten, regio's of verzendmethoden. Waarom dit belangrijk is Meet de leveringsprestatie rechtstreeks af tegen de gemaakte afspraak. Dat is belangrijk voor het bewaken van klanttevredenheid en de betrouwbaarheid van de toeleveringsketen. Waar je het vindt Wordt berekend door de 'EventTime' van de activiteit 'Goederen geleverd' te vergelijken met het attribuut 'ConfirmedDeliveryDate'. Formule: ('Goederen geleverd' Timestamp <= ConfirmedDeliveryDate). Voorbeelden truefalse
	Status verkooporder SalesOrderStatus	De huidige status van de verkooporder op het moment van data-extractie.
Beschrijving Dit attribuut geeft de algemene status van de verkooporder weer, zoals 'Open order', 'Gefactureerd', 'Geannuleerd' of 'Geleverd'. Het gaat om een samenvattende status die op de kop van de verkooporder wordt bijgehouden. Het activiteitenlogboek geeft een dynamisch beeld van het proces, terwijl de eindstatus handig is voor filters en segmentatie. Zo kun je alle open orders selecteren om de huidige werkvoorraad te bekijken. Je kunt ook succesvol afgeronde orders scheiden van geannuleerde orders en de redenen voor annulering analyseren. Waarom dit belangrijk is Geeft een momentopname van de orderstatus. Zo kun je de analyse filteren op open, gesloten of geannuleerde orders, wat helpt bij werkvoorraadbeheer en analyse van resultaten. Waar je het vindt Staat in de tabel 'SalesTable', veld 'SalesStatus'. Voorbeelden BackorderGeleverdGefactureerdGeannuleerd
	Vervaldatum betaling PaymentDueDate	De datum waarop de klant de factuur uiterlijk moet betalen.
Beschrijving De Payment Due Date wordt berekend op basis van de factuurdatum en de betalingstermijnen die met de klant zijn afgesproken. Deze datum staat op de klantfactuur. Dit attribuut vormt de basis voor de analyse 'Payment Due Date Compliance' en de KPI 'On-Time Payment Rate'. Door 'PaymentDueDate' te vergelijken met de werkelijke datum van 'Payment Received', kan het bedrijf late betalingen herkennen, betaalgedrag per klantsegment analyseren en proactief de cashflow verbeteren en days sales outstanding (DSO) verlagen. Waarom dit belangrijk is Dit is de referentie voor het meten van betaalprestaties. Dat is belangrijk voor het analyseren van cashflow en het effectief beheren van openstaande vorderingen. Waar je het vindt Te vinden in de tabel 'CustInvoiceJour', veld 'DueDate'. Voorbeelden 2023-05-302023-06-152023-06-30
	Verzendmethode ShippingMethod	De methode of vervoerder die wordt gebruikt om de goederen naar de klant te verzenden.
Beschrijving Dit attribuut geeft aan welke transportdienst voor de levering wordt gebruikt, zoals 'Ground Shipping', 'Air Freight' of de naam van een specifieke vervoerder. De keuze wordt tijdens de orderverwerking gemaakt op basis van klantvoorkeur, kosten en levertijd. Voor het dashboard 'Shipping Method Performance' is deze dimensie essentieel. Door doorlooptijden van 'Goods Packed' tot 'Goods Delivered' per verzendmethode te analyseren, zie je welke vervoerders sneller en betrouwbaarder zijn of vaker vertraging veroorzaken. Dit helpt bij een betere logistieke planning en vervoerderskeuze. Waarom dit belangrijk is Maakt prestatieanalyse van verschillende vervoerders en verzendopties mogelijk. Zo kun je logistiek optimaliseren op kosten, snelheid en betrouwbaarheid. Waar je het vindt 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

Order to Cash - activiteiten voor verkooporderverwerking

Dit zijn de belangrijkste processtappen en kritieke mijlpalen die je in je event log moet vastleggen voor een nauwkeurige ontdekking en analyse van de verkooporderverwerking.

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 wordt gekoppeld aan de oorspronkelijke factuur.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het analyseren van de cash-conversiecyclus. De gebeurtenis is nodig voor het meten van de KPI 'On-Time Payment Rate' en het vinden van vertragingen bij het innen van betalingen. Waar je het vindt Dit is een expliciete gebeurtenis uit de module Accounts Receivable. De gebeurtenis wordt vastgelegd via de transactiedatum van de afwikkeling van de klantbetaling (CustSettlement), waarmee de factuurtransactie (CustTrans) wordt afgesloten. Vastleggen Leg de afwikkelingsdatum uit de CustSettlement-tabel vast en koppel deze aan de factuur en salesorder. Eventtype explicit
	Factuur aangemaakt	Dit staat voor het genereren en boeken van de salesfactuur voor de verzonden goederen of diensten. Het is een financiële hoofdtransactie waarmee de schuld van de klant formeel wordt vastgelegd.
Waarom dit belangrijk is Deze activiteit markeert het begin van de financiële afwikkeling van het proces. De tijd tussen verzending en het aanmaken van de factuur is belangrijk voor de KPI 'Invoice Generation Cycle Time' en heeft invloed op de cashflow. Waar je het vindt Dit is een expliciete financiële transactie. De gebeurtenis wordt vastgelegd via de boekingsdatum en -tijd van het Sales Invoice-journaal (CustInvoiceJour). Vastleggen Leg de boekingstimestamp van het Sales Invoice-journaal vast. Eventtype explicit
	Goederen verzonden	Deze gebeurtenis geeft aan dat de verpakte goederen voor de order 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. De interne fulfilment eindigt hier en de leveringsfase begint. De timestamp is belangrijk voor het berekenen van prestaties rond tijdige verzending. Waar je het vindt Dit is een zeer duidelijke en expliciete gebeurtenis uit de boekingsdatum en -tijd van het Packing Slip-journaal (CustPackingSlipJour). Vastleggen Leg de boekingstimestamp van het Packing Slip-journaal vast. Eventtype explicit
	Order afgesloten	De eindstatus van een succesvol verwerkte salesorder. De order is volledig verzonden en gefactureerd en er worden geen verdere transacties verwacht. Hiermee is het proces succesvol afgerond.
Waarom dit belangrijk is Deze activiteit is het belangrijkste eindpunt voor succesvol afgeronde cases. De activiteit is nodig voor het berekenen van end-to-end-doorlooptijden en verwerkingscapaciteit. Waar je het vindt Dit wordt afgeleid uit de statusvelden in de SalesTable. Een order geldt als afgesloten wanneer 'Sales status' de waarde 'Invoiced' heeft en ook de regelstatussen 'Invoiced' zijn. 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. Eventtype inferred
	Order bevestigd	Deze activiteit staat voor de formele bevestiging van de salesorder, waarmee je je vastlegt op de levering van de opgegeven goederen of diensten. In Dynamics 365 is dit een expliciete gebruikersactie die een bevestigingsjournaal aanmaakt.
Waarom dit belangrijk is De bevestiging is een belangrijk mijlpaal die het fulfilmentproces officieel start. Door de tijd tussen aanmaak en bevestiging te meten, zie je hoe efficiënt de verwerking aan de voorkant van het proces verloopt. Waar je het vindt Dit is een expliciete gebeurtenis uit de boekingsdatum van het Sales Order Confirmation-journaal (SalesConfirmJour). De timestamp kan worden gekoppeld aan de SalesTable. Vastleggen Leg de boekingstimestamp van het Sales Order Confirmation-journaal vast. Eventtype explicit
	Salesorder aangemaakt	Deze gebeurtenis markeert het aanmaken van de salesorder in het systeem door een verkoper of via een geautomatiseerd kanaal. De gebeurtenis wordt expliciet vastgelegd wanneer een nieuw record wordt aangemaakt en opgeslagen in de primaire salesordertabel.
Waarom dit belangrijk is Deze activiteit is het universele startpunt voor alle salesordercases. De activiteit levert de eerste timestamp voor het berekenen van de totale doorlooptijd van de salesorder en het analyseren van de verwerkingscapaciteit. Waar je het vindt Dit is een expliciete gebeurtenis uit het veld 'Created date and time' van het SalesTable-headerrecord in Microsoft Dynamics 365. Vastleggen Lees de timestamp voor het aanmaken uit de SalesTable-entiteit. Eventtype explicit
	Goederen geleverd	Dit geeft aan dat de zending succesvol is afgeleverd op het opgegeven adres van de klant. Deze informatie komt vaak uit het systeem van een externe vervoerder of wordt handmatig bevestigd.
Waarom dit belangrijk is Deze activiteit is belangrijk voor het meten van de KPI 'Delivery Date Adherence' en voor inzicht in de werkelijke doorlooptijd vanuit klantperspectief. Ook kun je hiermee de prestaties van vervoerders beoordelen. Waar je het vindt Dit wordt in standaard-D365 niet standaard als expliciete gebeurtenis bijgehouden. Meestal wordt de gebeurtenis afgeleid uit een update van een vervoerdersintegratie of een handmatige statuswijziging op de salesorder of zending. Vastleggen Leid de gebeurtenis af uit een geïntegreerde feed van de vervoerder of een handmatige update van een statusveld. Eventtype inferred
	Goederen gepickt	Dit staat voor het afronden van het fysieke picken van alle orderartikelen op hun magazijnlocaties. Dit wordt meestal vastgelegd wanneer een picker een picklijst of werkorder in de WMS-module afrondt.
Waarom dit belangrijk is Door de afrondingstijd van picking te volgen, kun je de efficiëntie van het magazijn analyseren. Vertragingen in deze fase hebben direct invloed op de totale tijd tot verzending. Waar je het vindt Dit is een expliciete gebeurtenis in de Warehouse Management-module. De gebeurtenis wordt vastgelegd via de afrondingstimestamp van het magazijnwerk (WHSWorkTable) voor het picken van de salesorder. Vastleggen Leg de timestamp vast waarop de status van het pickwerk wordt gewijzigd in 'Closed'. Eventtype explicit
	Goederen verpakt	Deze activiteit markeert het afronden van het verpakkingsproces. De gepickte 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 picking en verpakken kan bottlenecks bij verpakkingsstations aan het licht brengen. Dit is een belangrijke subprocess binnen de totale fulfilmentdoorlooptijd. Waar je het vindt Dit kan een expliciete gebeurtenis zijn na het afronden van het verpakken van containers in de WMS-module. Je kunt de gebeurtenis ook afleiden uit het aanmaken van het Packing Slip-journaal (CustPackingSlipJour), dat vaak het einde van het verpakken markeert. Vastleggen Leid de gebeurtenis af uit het afronden van het verpakkingswerk of de aanmaakdatum van het Packing Slip-journaal. Eventtype inferred
	Kredietcontrole uitgevoerd	Dit staat voor het afronden van een kredietcontrole voor de klant die aan de salesorder is gekoppeld. Het kan gaan om een automatische systeemcontrole of een handmatige beoordeling, vaak met een wijziging van de kredietstatus van de order als resultaat.
Waarom dit belangrijk is Door de duur en uitkomsten van kredietcontroles te analyseren, zie je waar bottlenecks in het ordergoedkeuringsproces zitten. Veel blokkeringen of lange goedkeuringstijden kunnen de orderafhandeling aanzienlijk vertragen. Waar je het vindt Dit wordt meestal afgeleid uit statuswijzigingen voor kredietbeheer in de SalesTable, bijvoorbeeld van 'On hold' met een kredietreden naar 'Open'. Bij gebruik van de geavanceerde module kan de gebeurtenis ook in tabellen voor kredietbeheer worden vastgelegd. Vastleggen Leid de gebeurtenis af uit de geschiedenis van statuswijzigingen in de SalesTable of uit gerelateerde tabellen voor kredietblokkeringen. Eventtype inferred
	Order geannuleerd	Deze gebeurtenis staat voor het annuleren van een salesorder voordat deze volledig is verzonden en gefactureerd. Dit is een alternatief, niet-succesvol einde van het proces.
Waarom dit belangrijk is Door annuleringen te volgen, zie je mogelijke oorzaken van verloren omzet of procesfouten. Door te analyseren wanneer en waarom orders worden geannuleerd, kun je het proces verbeteren. Waar je het vindt Dit wordt afgeleid uit het veld 'Sales status' in de SalesTable, wanneer de waarde verandert in 'Canceled'. De timestamp is het moment waarop deze statuswijziging is vastgelegd. Vastleggen Leid de gebeurtenis af uit het veld voor de SalesTable-status wanneer dit verandert in 'Canceled'. Eventtype inferred
	Voorraad gereserveerd	Deze gebeurtenis geeft aan dat de benodigde voorraad voor de salesorderregels fysiek of automatisch in het systeem is gereserveerd. Zo zijn de artikelen beschikbaar voor picking en fulfilment.
Waarom dit belangrijk is Door voorraadreserveringen te volgen, kun je vertragingen tussen orderbevestiging en de start van magazijnactiviteiten analyseren. Dit is belangrijk voor de KPI 'Inventory Allocation Lead Time'. Waar je het vindt Dit kan worden afgeleid uit het aanmaken of bijwerken van voorraadtransactierecords (InventTrans) die aan de salesorderregels zijn gekoppeld, waarbij de status een reservering aangeeft, bijvoorbeeld 'On order' of 'Reserved physical'. Vastleggen Leid de gebeurtenis af uit de timestamp waarop voorraadtransacties (InventTrans) voor de order als gereserveerd zijn gemarkeerd. Eventtype inferred
	Vrijgegeven aan magazijn	Dit markeert het moment waarop de salesorder formeel wordt vrijgegeven aan het magazijn voor picking en verzending. Dit is een aparte stap in omgevingen die de Warehouse Management-module (WMS) gebruiken.
Waarom dit belangrijk is Deze activiteit scheidt orderverwerking van fysieke fulfilment. Door te analyseren hoelang een order op vrijgave wacht, kun je problemen met capaciteitsplanning of systeemintegraties vinden. Waar je het vindt Dit is een expliciete gebeurtenis uit de magazijnvrijgaverecords (WHSLoadTable, WHSShipmentTable) die aan de salesorder zijn gekoppeld. Vastleggen Leg de aanmaaktimestamp van de bijbehorende magazijnlading of zending vast. Eventtype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Microsoft Dynamics 365

Stappen

Export naar Azure Data Lake configureren: Controleer in je Dynamics 365 Finance and Operations-omgeving of de add-in 'Export to Azure Data Lake' is geïnstalleerd en geconfigureerd. Hiervoor koppel je D365 aan een Azure-abonnement en een doelaccount voor Azure Data Lake Storage Gen2.
Tabellen voor export selecteren: Ga in Dynamics 365 naar de werkruimte 'Export to Data Lake'. Zoek de volgende tabellen en voeg ze toe aan de exportconfiguratie: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable en CustTable. Activeer de export voor alle geselecteerde tabellen.
Azure Synapse Analytics instellen: 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 wordt opgeslagen.
Een serverless SQL-database maken: Ga in Synapse Studio naar de hub 'Data'. Maak een nieuwe serverless SQL-database om via T-SQL query's uit te voeren op de data in je lake.
Views voor D365-tabellen maken: Maak in je serverless database SQL-views die verwijzen naar de gerepliceerde D365-tabeldata in het data lake. Zo hoef je de onderliggende bestandspaden en indelingen niet zelf te gebruiken. Bijvoorbeeld: CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
De SQL-query voorbereiden: Open in Synapse Studio een nieuw SQL-script en maak verbinding met je serverless database. Kopieer de volledige SQL-query uit deze documentatie naar de scripteditor.
Queryparameters aanpassen: Zoek de placeholders bovenaan de query. Vervang '{YourDataAreaId}' door de bedrijfs code die je wilt analyseren. Pas de placeholders '{StartDate}' en '{EndDate}' aan om de gewenste periode voor de extractie in te stellen.
De query uitvoeren: Voer het volledige SQL-script uit. De query verzamelt events uit verschillende tabellen en voegt ze samen tot één gestandaardiseerd event log.
Resultaten controleren en exporteren: Controleer na afloop de resultaten in het resultatenvenster van Synapse Studio. Zo weet je zeker dat ze volledig en correct opgemaakt zijn. Gebruik de ingebouwde exportfunctie om de resultaten als CSV-bestand op te slaan.
Upload voorbereiden: 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.
Uploaden naar ProcessMind: Upload het definitieve, gevalideerde CSV-bestand naar je ProcessMind-project voor analyse en visualisatie.

Configuratie

Vereisten: Voor deze methode heb je een actief Azure-abonnement nodig en moet de functie 'Export to Azure Data Lake' voor je Dynamics 365 F&O-instantie zijn geconfigureerd. Je hebt de juiste rechten nodig in zowel Azure, om Synapse en Storage te beheren, als D365, om data-exporten te configureren.
Vereiste D365-modules: Voor volledige eventregistratie, vooral van magazijnactiviteiten, heb je de module Warehouse Management (WMS) nodig. De belangrijkste events zijn afhankelijk van de modules Sales and Marketing en Accounts Receivable.
Tabellen selecteren: Het is belangrijk dat je de export activeert voor alle tabellen waarnaar in de query wordt verwezen: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable en CustTable. Ontbrekende tabellen leiden tot ontbrekende activiteiten.
Filteren op periode: De query is ontworpen om te filteren op een periode met de parameters {StartDate} en {EndDate}. Gebruik voor de eerste extracties een beperkte periode, bijvoorbeeld 3 tot 6 maanden. Zo blijven de uitvoeringstijden beheersbaar.
Filteren op bedrijf (DataAreaId): Configureer de placeholder '{YourDataAreaId}' voor een specifieke juridische entiteit binnen je D365-omgeving. De query is niet bedoeld voor analyse van meerdere bedrijven in één uitvoering.
Prestaties: Bij zeer grote datasets kunnen de queryprestaties van een serverless SQL-pool variëren. Plan de extractie eventueel buiten piekuren. Als je vaak extraheert, kun je het definitieve event log als nieuwe tabel in het data lake opslaan. Dat verbetert de prestaties van vervolgstappen.

a 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 nieuwer is geïnstalleerd. Installeer de benodigde Python-bibliotheken met de volgende opdracht in je terminal: pip install pandas requests msal.
Een applicatie registreren in Azure AD: Ga naar de Azure-portal en registreer een nieuwe applicatie onder Azure Active Directory. Deze applicatie gebruik je voor authenticatie bij de Dynamics 365 API. Noteer de Application (client) ID en Directory (tenant) ID.
Een client secret maken: Maak in je nieuw geregistreerde Azure AD-applicatie onder 'Certificates & secrets' een nieuwe client secret. Kopieer de waarde meteen, want die wordt daarna niet meer weergegeven. Dit is je CLIENT_SECRET.
API-rechten toekennen: Ga in de instellingen van de Azure AD-applicatie naar 'API permissions'. Voeg rechten toe voor 'Dynamics ERP' of 'Dynamics 365 for Finance and Operations'. Selecteer 'Delegated permissions' en ken user_impersonation toe. Voeg daarna dezelfde machtiging opnieuw toe, maar selecteer 'Application permissions' en ken Financials.ReadWrite.All toe, of een beperktere alleen-lezenmachtiging als die beschikbaar en voldoende is. Verleen admin consent voor deze rechten.
Een applicatiegebruiker maken in Dynamics 365: Ga in je Dynamics 365-omgeving naar 'System administration' > 'Users' > 'Users'. Maak een nieuwe gebruiker aan en koppel die aan de Application ID van je Azure AD-appregistratie. Wijs een beveiligingsrol toe, zoals 'System administrator' voor volledige toegang, of een aangepaste rol met leestoegang tot de benodigde data-entiteiten, zoals SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders en SalesInvoiceHeadersV2.
Het Python-script configureren: Open het meegeleverde Python-script in een editor. Zoek bovenaan het bestand de configuratiesectie en vervang de placeholderwaarden voor D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE en END_DATE door de gegevens van jouw omgeving.
Entiteitskoppelingen definiëren (optioneel): Controleer de entiteits- en veldnamen die in het script worden gebruikt. Als je organisatie aangepaste entiteiten of velden gebruikt om bepaalde activiteiten bij te houden, moet je de OData-query's in het script mogelijk aanpassen.
Het extractiescript uitvoeren: Voer het script uit vanaf de opdrachtregel met python your_script_name.py. Het script meldt zich aan, bevraagt de Dynamics 365 OData API voor elke activiteit en verwerkt de data. De voortgang wordt in de console weergegeven.
Het uitvoerbestand controleren: Na een geslaagde uitvoering maakt het script in dezelfde map een CSV-bestand met de naam d365_order_to_cash_event_log.csv. Open dit bestand om te controleren of het geëxtraheerde event log volledig en correct is.
Uploaden naar ProcessMind: Het gegenereerde CSV-bestand heeft het vereiste schema en kan rechtstreeks 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-instantie. Je vindt deze op de overzichtspagina van je Azure AD-appregistratie.
CLIENT_ID: De Application (client) ID van de applicatie die je in Azure AD hebt geregistreerd.
CLIENT_SECRET: De waarde van de client secret die je voor de Azure AD-applicatie hebt gegenereerd.
COMPANY_FILTER: Geeft de juridische entiteit van Dynamics 365 aan, bijvoorbeeld 'USMF', waaruit je data extraheert. Dit verplichte filter zorgt ervoor dat je de juiste bedrijfsdata opvraagt.
START_DATE / END_DATE: Bepalen de periode voor de extractie in de notatie 'YYYY-MM-DD'. Voor een eerste analyse wordt een periode van 3 tot 6 maanden aanbevolen, zodat de hoeveelheid data en de inzichten in balans blijven. Houd er rekening mee dat een lange periode de extractietijd flink kan verhogen.
Vereisten: Je hebt toegang tot Azure AD nodig om een applicatie te registreren en rechten toe te kennen. Ook heb je een Dynamics 365-gebruikersaccount nodig met rechten om een applicatiegebruiker te maken en beveiligingsrollen toe te wijzen. De toegewezen rol moet leestoegang hebben tot alle entiteiten die het script bevraagt.

a 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 aan de slag te gaan?

Gebruik deze template om je data voor te bereiden en upload de data daarna naar ons platform. Zo krijg je waardevolle inzichten en verbeter je de efficiëntie van je salesorderverwerking. Begin vandaag met optimaliseren.

Terug naar de verbetergids Template downloaden

Optimaliseer Order to Cash-salesorderverwerking nu

Vind inefficiënties en verkort de doorlooptijd met 30% voor snellere fulfilment.

Start je gratis proefperiode

Geen creditcard nodig. Je bent binnen enkele minuten klaar.

Jouw datatemplate voor Order to Cash-salesorderverwerking

Jouw datatemplate voor Order to Cash-salesorderverwerking

Order to Cash - kenmerken van verkooporderverwerking

Order to Cash - activiteiten voor verkooporderverwerking

Extractiegidsen

SQL-query op Azure Data Lake via Synapse Analytics

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met Dynamics 365 OData Web API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer Order to Cash-salesorderverwerking nu

Jouw datatemplate voor Order to Cash-salesorderverwerking

Jouw datatemplate voor Order to Cash-salesorderverwerking

Order to Cash - kenmerken van verkooporderverwerking

Order to Cash - activiteiten voor verkooporderverwerking

Extractiegidsen

SQL-query op Azure Data Lake via Synapse Analytics

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met Dynamics 365 OData Web API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Optimaliseer Order to Cash-salesorderverwerking nu

We respecteren je privacy