> Continu verbeteren van processen > Order to Cash facturatie en factuurverwerking > Microsoft Dynamics 365 > Datatemplate

De datatemplate voor order-to-cash-facturatie en -factuurverwerking

Microsoft Dynamics 365

← Terug naar de verbetergids

Attributen voor order-to-cash-facturatie en -factuurverwerking(18) Activiteiten voor order-to-cash-facturatie en -factuurverwerking(12) Extractiegidsen(2)

De datatemplate voor order-to-cash-facturatie en -factuurverwerking

Deze template laat zien welke data je nodig hebt om het order-to-cash-proces voor facturatie en factuurverwerking te analyseren. Je vindt er aanbevolen attributen voor het event log, activiteiten om bij te houden en praktische uitleg over het ophalen van de data. Zo kun je snel je data voorbereiden voor process mining.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om bij te houden
Data ophalen 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-facturatie en -factuurverwerking

Dit zijn de aanbevolen datavelden voor het event log, zodat je order-to-cash-facturatie en -factuurverwerking volledig kunt analyseren.

3 Verplicht 6 Aanbevolen 9 Optioneel

	Naam	Beschrijving
	Factuurnummer InvoiceNumber	De unieke identificatiecode van elke klantfactuur. Dit is de belangrijkste case-identificatie voor het facturatieproces.
Beschrijving Het factuurnummer is de centrale sleutel waarmee alle activiteiten voor één factuur worden gegroepeerd. Hiermee kun je de volledige levenscyclus van de factuur analyseren, van aanmaak en goedkeuring tot betaling door de klant en definitieve afsluiting. Als je dit als Case-ID gebruikt, hoort elke regel in het event log bij een specifieke factuur. Zo kun je varianten gedetailleerd analyseren, doorlooptijden berekenen en de prestaties van elke factuurtransactie volgen. Waarom dit belangrijk is Dit attribuut is essentieel om de volledige levenscyclus van een factuur te volgen en per factuurdocument de procesefficiëntie, bottlenecks en afwijkingen te analyseren. Waar vind je dit? Je vindt dit meestal in de module Sales and marketing, in tabellen zoals CustInvoiceJour (veld InvoiceId) of via data-entiteiten zoals SalesInvoiceHeaderV2. Voorbeelden CIV-001254INV-2023-9876US-004321
	Activiteitsnaam ActivityName	De naam van de bedrijfsactiviteit of gebeurtenis die op een bepaald moment in de levenscyclus van de factuur plaatsvond.
Beschrijving Dit attribuut beschrijft een specifieke stap of mijlpaal in het facturatieproces, zoals 'Factuur aangemaakt', 'Factuur goedgekeurd' of 'Betaling van klant ontvangen'. De volgorde van deze activiteiten vormt het procesverloop. Activiteiten analyseren is essentieel voor process mining: zo kun je procesmodellen ontdekken, varianten herkennen en de prestaties tussen verschillende stappen meten. Waarom dit belangrijk is Dit attribuut bepaalt welke stappen het proces bevat. Daarmee kun je proceskaarten visualiseren, procesvarianten analyseren en bottlenecks of afwijkingen van de standaardprocedure opsporen. Waar vind je dit? Dit attribuut wordt meestal afgeleid uit meerdere bronnen, zoals velden voor statuswijzigingen (bijvoorbeeld DocumentState), ingevulde datumvelden of workflowgeschiedenis in Microsoft Dynamics 365. Voorbeelden Factuur aangemaaktFactuur goedgekeurdBetaling van klant ontvangenCreditnota aangemaakt
	Tijdstip van gebeurtenis EventTime	De exacte timestamp waarop een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving Tijdstip van gebeurtenis, ook wel de timestamp genoemd, registreert de exacte datum en tijd van elke activiteit in het proces. Deze data is essentieel voor alle tijdsgebonden process mining-analyses. Je gebruikt de gegevens om doorlooptijden tussen activiteiten en de totale duur van een case te berekenen en de procesprestaties in de loop van de tijd te volgen. Nauwkeurige en betrouwbare timestamps vormen de basis voor KPI’s zoals Days Sales Outstanding en de tijd tot het aanmaken van een factuur. Waarom dit belangrijk is Dit attribuut vormt de basis voor alle analyses van prestaties en tijd. Hiermee kun je doorlooptijden, duur en doorvoer berekenen om de procesefficiëntie te meten. Waar vind je dit? De timestamps komen uit verschillende datum- en tijdvelden in Dynamics 365-tabellen, zoals CreatedDateTime in de tabel CustInvoiceJour voor het aanmaken van facturen, of uit specifieke timestamps in de workflowgeschiedenis. Voorbeelden 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Afdeling Department	De bedrijfsafdeling die bij de gebruiker of activiteit hoort.
Beschrijving Dit attribuut koppelt een activiteit of gebruiker aan een specifieke afdeling, zoals ‘Debiteuren’ of ‘Verkoop’. Zo kun je de prestaties van het proces op een hoger niveau bekijken dan dat van individuele gebruikers. Met een analyse per afdeling krijg je zicht op overdrachten tussen teams, kun je de efficiëntie vergelijken en bottlenecks op afdelingsniveau herkennen. Dat is ook nodig voor het dashboard ‘Werklast activiteiten facturatieafdeling’. Waarom dit belangrijk is Hiermee kun je prestaties op organisatieniveau analyseren, de efficiëntie van teams vergelijken en zien hoe overdrachten tussen afdelingen het proces beïnvloeden. Waar vind je dit? Dit is meestal geen rechtstreeks veld in de factuurtransactie. Je leidt het af door de ID van UserResponsible te koppelen aan de medewerkers- of gebruikersdirectory met afdelingsgegevens. Voorbeelden DebiteurenFinanciënFacturatie
	Factuurbedrag InvoiceAmount	Het totale bedrag van de factuur.
Beschrijving Dit attribuut geeft het totaalbedrag van de factuur weer. Het is een belangrijke metriek voor financiële analyses en maakt het mogelijk facturen op bedrag in te delen. Analisten kunnen bijvoorbeeld facturen met hoge bedragen bekijken om het betaalgedrag te onderzoeken of na te gaan of de goedkeuring ervan langer duurt. Het attribuut is ook nodig om het totaalbedrag van openstaande facturen en Days Sales Outstanding te berekenen. Waarom dit belangrijk is Hiermee kun je de financiële impact analyseren en processen op bedrag filteren en indelen. Zo kun je facturen met hoge bedragen prioriteit geven en hun specifieke procesverloop onderzoeken. Waar vind je dit? Te vinden in de tabel CustInvoiceJour, meestal in een veld zoals InvoiceAmount. Ook beschikbaar in gerelateerde transactietabellen. Voorbeelden 5430.5012500.00750.25
	Factuurstatus InvoiceStatus	De huidige status van de factuur in de levenscyclus, bijvoorbeeld Open, Betaald of Geannuleerd.
Beschrijving Dit attribuut laat zien wat de huidige status van de factuur is. Je ziet of de factuur nog betaald moet worden, volledig is betaald, achterstallig is of met een creditnota is geannuleerd. Je kunt cases ermee filteren, bijvoorbeeld om alleen openstaande facturen te analyseren of de uitkomst van een afgesloten factuur te controleren. Zo krijg je inzicht in de huidige werklast en de financiële situatie van de debiteuren. Waarom dit belangrijk is Dit geeft snel de huidige status van de factuur weer. Je kunt cases ermee filteren en de uitkomsten van verschillende procesvarianten bekijken. Waar vind je dit? Je kunt dit afleiden uit de betaalstatus van de factuur, bijvoorbeeld door te controleren of het saldo in de bijbehorende CustTrans-record nul is. Er is niet altijd één veld voor de status. Voorbeelden OpenBetaaldAchterstalligGeannuleerd
	Klantnaam CustomerName	De naam van de klant aan wie de factuur is verstuurd.
Beschrijving De klantnaam is een herkenbare aanduiding van het bedrijf of de persoon aan wie de factuur is gericht. Met process mining kun je het facturatieproces per klant analyseren. Zo zie je welke klanten op tijd betalen, welke vaak te laat zijn en of bepaalde klantgroepen te maken hebben met afwijkingen of vertragingen in het proces. Dit attribuut is belangrijk voor dashboards over betaalgedrag van klanten en Days Sales Outstanding. Waarom dit belangrijk is Hiermee kun je het proces per klant analyseren en klantgebonden gedrag, betaalpatronen of procesproblemen herkennen. Waar vind je dit? Deze informatie wordt opgehaald door de factuurdata op basis van het klantrekeningnummer te koppelen aan de stamgegevens van klanten, meestal in CustTable. Voorbeelden Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Uiterste betaaldatum PaymentDueDate	De datum waarop de klant de factuur uiterlijk moet betalen.
Beschrijving De uiterste betaaldatum is een belangrijke datum die wordt berekend op basis van de factuurdatum en de betalingsvoorwaarden van de klant. Deze datum dient als uitgangspunt om te meten of betalingen op tijd binnenkomen. Het attribuut is nodig voor het dashboard ‘Analyse naleving betalingsvoorwaarden’ en voor KPI’s zoals ‘Percentage betalingen op tijd’ en Days Sales Outstanding. Door deze datum te vergelijken met de werkelijke betaaldatum krijg je inzicht in het betaalgedrag van klanten en de effectiviteit van het incassoproces. Waarom dit belangrijk is Dit is de maatstaf voor de betaalprestaties. Je hebt deze datum nodig om het percentage betalingen op tijd te berekenen en na te gaan of klanten zich aan de betalingsvoorwaarden houden. Waar vind je dit? Meestal te vinden in de tabel CustInvoiceJour, in een veld zoals DueDate. Voorbeelden 2023-05-152023-06-302023-07-01
	Verantwoordelijke gebruiker UserResponsible	De gebruiker of medewerker die verantwoordelijk is voor het uitvoeren van een specifieke activiteit.
Beschrijving Dit attribuut geeft aan wie een bepaalde taak in het facturatieproces heeft uitgevoerd, zoals een factuur goedkeuren of een betaling verwerken. Het is belangrijk voor werklastanalyses, prestatievergelijkingen en het vaststellen van opleidingsbehoeften. Het dashboard ‘Werklast activiteiten facturatieafdeling’ gebruikt dit attribuut bijvoorbeeld om te zien of het werk gelijkmatig is verdeeld en of bepaalde gebruikers een bottleneck vormen. Ook helpt het bij inzicht in de verdeling van capaciteit en de efficiëntie. Waarom dit belangrijk is Hiermee kun je op gebruikersniveau analyseren, bottlenecks herkennen, prestaties van individuele medewerkers of teams meten en de werklast binnen de facturatieafdeling bekijken. Waar vind je dit? Deze informatie kan afkomstig zijn uit logboeken van de workflowgeschiedenis, zoals WorkflowTrackingStatusTable, of uit eigenaarschapsvelden zoals Owner of ModifiedBy in relevante tabellen. Voorbeelden John SmithAlicia BakerSysteembeheerder
	Betaling op tijd IsOnTimePayment	Een aanduiding die aangeeft of de betaling van de klant op of vóór de uiterste betaaldatum is ontvangen.
Beschrijving Dit berekende booleaanse attribuut vergelijkt de timestamp van ‘Betaling klant ontvangen’ met de ‘Uiterste betaaldatum’. Het geeft per factuur aan of de betaling op tijd of te laat was. Dit is de basis voor de KPI ‘Percentage betalingen op tijd’ en wordt veel gebruikt in het dashboard ‘Analyse naleving betalingsvoorwaarden’. De uitkomst is duidelijk en eenvoudig te gebruiken in analyses en rapportages. Waarom dit belangrijk is Dit meet rechtstreeks of klanten zich aan de betalingsvoorwaarden houden en vormt de basis voor de KPI Percentage betalingen op tijd. Zo kun je de effectiviteit van het incassoproces eenvoudiger analyseren. Waar vind je dit? Dit attribuut staat niet in het bronsysteem. Het wordt tijdens de datatransformatie berekend door de betaaldatum te vergelijken met PaymentDueDate. Voorbeelden truefalse
	Betalingsvoorwaarden PaymentTerms	De afgesproken voorwaarden voor het betalen van een factuur, bijvoorbeeld binnen 30 of 60 dagen.
Beschrijving De betalingsvoorwaarden bepalen wanneer een klant een factuur moet betalen. Dit attribuut wordt gebruikt om de uiterste betaaldatum te berekenen en is een belangrijke dimensie voor analyses van betaalgedrag. Het dashboard ‘Analyse naleving betalingsvoorwaarden’ gebruikt dit attribuut om klanten en facturen in te delen. Zo zie je of bepaalde betalingsvoorwaarden beter werken of vaker samengaan met te late betalingen. Waarom dit belangrijk is Dit verklaart waarom een factuur op een bepaalde datum moet worden betaald. Je kunt de analyse ermee indelen en nagaan of bepaalde betalingsvoorwaarden samengaan met te late betalingen. Waar vind je dit? Dit staat meestal in de stamgegevens van de klant en wordt gekopieerd naar de factuurkop. Zoek in de tabel CustInvoiceJour naar een veld zoals Payment of PaymTermId. Voorbeelden Binnen 30 dagenBinnen 60 dagenTe betalen bij ontvangst
	Bronsysteem SourceSystem	Het systeem waaruit de data is geëxtraheerd.
Beschrijving Dit attribuut geeft aan waar de procesdata vandaan komt. In dit geval komt de data uit Microsoft Dynamics 365. Dat is belangrijk in omgevingen met meerdere systemen: zo kun je bronnen van elkaar onderscheiden en de herkomst van de data volgen. Dit helpt bij datavalidatie en het oplossen van problemen. Waarom dit belangrijk is Dit geeft belangrijke context over de herkomst van de data. Die is nodig voor datagovernance en validatie, en wanneer je data uit meerdere bedrijfssystemen samenvoegt. Waar vind je dit? Dit is een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Microsoft Dynamics 365 FinanceD365 F&O
	Days Sales Outstanding DaysSalesOutstanding	Het aantal dagen tussen het aanmaken van de factuur en de ontvangst van de betaling van de klant.
Beschrijving Days Sales Outstanding (DSO) is een financiële metriek die het gemiddelde aantal dagen meet tussen een verkoop en de ontvangst van de betaling. Dit berekende attribuut bepaalt die periode voor elke afzonderlijke factuur. Het is de belangrijkste metriek voor het dashboard ‘Trendanalyse Days Sales Outstanding’ en de KPI ‘DSO’. Met een DSO-analyse kun je de cashflow beheren en de efficiëntie van kredietbeheer en incasso beoordelen. Waarom dit belangrijk is Dit is een belangrijke KPI voor de cashflow van een bedrijf en de efficiëntie van het incassoproces. De metriek laat zien hoe snel omzet wordt omgezet in geld. Waar vind je dit? Dit attribuut staat niet in het bronsysteem. Het wordt berekend als de tijd tussen de activiteit ‘Factuur aangemaakt’ en de activiteit ‘Betaling klant ontvangen’. Voorbeelden 284592
	Handmatige tussenkomst vereist RequiresManualIntervention	Een aanduiding die aangeeft of een betaling handmatig moest worden aangepast bij de verwerking.
Beschrijving Dit booleaanse attribuut markeert betalingen waarvoor tijdens de verwerking handmatige tussenkomst of correctie nodig was. Het is belangrijk voor de KPI ‘Percentage afwijkingen bij betalingsverwerking’, omdat je hiermee de nauwkeurigheid en mate van automatisering van de betalingsverwerking kunt meten. Als je de redenen voor handmatige tussenkomst achterhaalt, zoals ontbrekende betalingsinformatie of afwijkende bedragen, kun je het proces verbeteren en meer betalingen zonder handmatige tussenkomst verwerken. Waarom dit belangrijk is Dit attribuut helpt problemen en onnauwkeurigheden bij de betalingsverwerking te herkennen. Zo kun je de automatisering verbeteren en handmatig werk verminderen. Waar vind je dit? Deze informatie kan worden afgeleid uit de gebruiker die de betaling heeft geboekt, als dat geen systeemgebruiker is, of uit specifieke redenencodes bij de betalingsafstemming. Raadpleeg de documentatie van Microsoft Dynamics 365. Voorbeelden truefalse
	Herhaalwerk IsRework	Een aanduiding die aangeeft of er herhaalwerk in het facturatieproces was, bijvoorbeeld doordat een factuur meerdere keren is goedgekeurd.
Beschrijving Dit is een berekend booleaans attribuut dat facturen markeert waarbij herhaalwerk is voorgekomen. Daarvan kan sprake zijn bij meerdere gebeurtenissen ‘Factuur goedgekeurd’ of bij terugboekingen van betalingen. Dit attribuut is bedoeld voor het dashboard ‘Analyse van herhaalwerk bij facturen’ en de KPI ‘Percentage facturen met herhaalwerk’. Door deze cases apart te bekijken, kunnen analisten de oorzaken van herhaalwerk onderzoeken. Die wijzen vaak op inefficiënte processen, problemen met datakwaliteit of opleidingsbehoeften. Waarom dit belangrijk is Deze aanduiding maakt inefficiëntie zichtbaar door cases met herhaalde of corrigerende handelingen te herkennen. Zo kun je de oorzaken van verspilling en vertraging achterhalen. Waar vind je dit? Dit attribuut is niet beschikbaar in het bronsysteem. Het wordt berekend in de datatransformatielaag door herhaalde activiteiten of specifieke patronen van herhaalwerk binnen een case te herkennen. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst is vernieuwd vanuit het bronsysteem.
Beschrijving Dit attribuut registreert wanneer de data voor het laatst uit Microsoft Dynamics 365 is geëxtraheerd of bijgewerkt. Het is een metadataveld dat aangeeft hoe actueel de geanalyseerde data is. Zo weten analisten en zakelijke gebruikers of ze naar de meest recente informatie kijken. Ook helpt het bij het beheren van verversingsschema’s en het bewaken van de betrouwbaarheid van de analyse. Waarom dit belangrijk is Zo zien gebruikers hoe recent de data is. Dat is belangrijk voor datagovernance, het beheer van dashboardverversingen en het vertrouwen in de actualiteit van de inzichten. Waar vind je dit? Dit attribuut wordt tijdens het ETL-proces (extractie, transformatie en laden) gegenereerd en aan de dataset toegevoegd. Voorbeelden 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Valuta Currency	De valutacode voor het factuurbedrag (bijvoorbeeld USD of EUR).
Beschrijving Dit attribuut geeft aan in welke valuta het factuurbedrag is uitgedrukt. Dat is nodig voor internationale organisaties die met verschillende valuta werken. Zonder deze context zijn totalen en vergelijkingen van factuurbedragen niet zinvol. De valuta maakt een correcte omrekening en nauwkeurige financiële rapportages en analyses voor verschillende regio’s mogelijk. Waarom dit belangrijk is Dit geeft essentiële context bij financiële metrieken zoals Factuurbedrag. Zo voorkom je onjuiste totalen en kun je nauwkeurig analyseren in omgevingen met meerdere valuta. Waar vind je dit? Te vinden in de tabel CustInvoiceJour, meestal in een veld zoals CurrencyCode. Voorbeelden USDEURGBP
	Verkoopordernummer SalesOrderNumber	De identificatie van de verkooporder waaruit de factuur is voortgekomen.
Beschrijving Het verkoopordernummer koppelt het facturatieproces aan het voorafgaande verkoopproces. Die koppeling is waardevol voor een bredere, end-to-endanalyse van Order-to-Cash. Analisten kunnen onderzoeken hoe problemen in de verkoop- en leveringsprocessen, zoals wijzigingen in orders of vertragingen bij verzending, de facturatiecyclus beïnvloeden. Zo kun je bijvoorbeeld nagaan of facturen voor complexe verkooporders later worden betaald. Waarom dit belangrijk is Dit attribuut koppelt het facturatieproces aan het voorafgaande verkoopproces. Zo kun je Order-to-Cash van begin tot eind analyseren en de oorzaken van facturatieproblemen achterhalen. Waar vind je dit? Te vinden in de factuurkop of factuurregels, waar het naar de verkooporder verwijst. Zoek in de tabel CustInvoiceJour naar een veld zoals SalesId. Voorbeelden SO-009876SO-010234US-SO-00543

Verplicht Aanbevolen Optioneel

Activiteiten voor order-to-cash-facturatie en -factuurverwerking

Dit zijn de belangrijkste processtappen en mijlpalen voor het event log. Zo kun je het proces goed ontdekken en analyseren.

7 Aanbevolen 5 Optioneel

	Activiteit	Beschrijving
	Betaling aan factuur gekoppeld	Dit is de afwikkeling van een klantbetaling tegen een specifieke factuur, waardoor het openstaande saldo van de factuur daalt. In Dynamics 365 is dit een afzonderlijke stap die de betalingstransactie aan de factuurtransactie koppelt.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het nauwkeurig berekenen van de DSO en het beoordelen van de efficiëntie van het team dat betalingen verwerkt. De betaling is nu volledig afgestemd op het gefactureerde bedrag. Waar vind je dit? Geregistreerd in de tabel CustSettlement. Het veld met de afwikkelingsdatum in deze tabel geeft de timestamp aan waarop een specifieke betaling aan een specifieke factuurtransactie is gekoppeld. Vastleggen Gebruik TransDate of CreatedDateTime uit de tabel CustSettlement. Gebeurtenistype explicit
	Betaling van klant ontvangen	Deze activiteit markeert het aanmaken van een journaalpost voor een ontvangen klantbetaling. Het geld is ontvangen, maar nog niet aan een specifieke factuur gekoppeld.
Waarom dit belangrijk is Dit is het startpunt voor het meten van de verwerkingstijd van een betaling. Zo maak je onderscheid tussen het ontvangen van het geld en het afstemmen ervan met openstaande facturen. Waar vind je dit? Vastgelegd bij het aanmaken of boeken van een klantbetalingsjournaal. Dit wordt geregistreerd in tabellen zoals LedgerJournalTrans. Na het boeken wordt een klanttransactie aangemaakt in CustTrans. Vastleggen Gebruik de boekingstimestamp van het klantbetalingsjournaal uit LedgerJournalTable. Gebeurtenistype explicit
	Factuur aangemaakt	Dit is het aanmaken en boeken van het verkoopfactuurdocument in het systeem. In Dynamics 365 is dit een expliciete transactie die een juridisch document en financiële boekingen in het subgrootboek debiteuren aanmaakt.
Waarom dit belangrijk is Dit is het officiële begin van de levenscyclus van een factuur. Deze gebeurtenis is belangrijk om de Days Sales Outstanding (DSO) en de totale procesduur te volgen. Waar vind je dit? Vastgelegd aan de hand van de aanmaaktimestamp van de geboekte verkoopfactuur in de tabel CustInvoiceJour. Bij het boeken worden de bijbehorende financiële transacties aangemaakt in de tabellen GeneralJournalEntry en LedgerEntry. Vastleggen Gebruik het veld CreatedDateTime uit de tabel CustInvoiceJour voor de geboekte factuur. Gebeurtenistype explicit
	Factuur afgesloten	Deze activiteit markeert de eindstatus van een factuur. Het saldo is nul omdat de factuur volledig is betaald of met creditnota’s is verrekend. Dit is geen rechtstreekse transactie, maar een afgeleide status op basis van de financiële gegevens van de factuur.
Waarom dit belangrijk is Deze gebeurtenis geeft aan dat de Order to Cash-cyclus voor één factuur succesvol is afgerond. De tijd tot dit moment is een belangrijke maatstaf voor de algehele procesefficiëntie. Waar vind je dit? Afgeleid door te controleren of het resterende saldo van de factuurtransactie in de tabel CustTrans nul is. Dit bepaal je door het factuurbedrag te vergelijken met het totaalbedrag dat ermee is verrekend. Vastleggen Leid dit af uit CustTrans-records waarin AmountCur gelijk is aan SettleAmountCur. De timestamp is de datum van de laatste afwikkeling. Gebeurtenistype inferred
	Factuur goedgekeurd	Dit markeert het einde van de interne beoordeling: de factuur is formeel goedgekeurd. Het Dynamics 365-workflowsysteem registreert deze gebeurtenis. De factuur is nu klaar om naar de klant te worden verstuurd.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het meten van de doorlooptijd van de goedkeuring. Vertragingen in deze fase kunnen de totale tijd tot betaling door de klant verlengen. Waar vind je dit? Geregistreerd in de workflowgeschiedenistabellen, zoals WorkflowTrackingStatusTable, als een voltooide of goedgekeurde stap in de workflowinstantie van de betreffende factuur. Vastleggen Haal workflow-eventlogs op met de status 'Approved' of 'Completed'. Gebeurtenistype explicit
	Factuur naar klant verzonden	Deze activiteit geeft aan wanneer de factuur naar de klant is verstuurd, digitaal of op papier. In Dynamics 365 kan dit een expliciete gebeurtenis zijn als de factuur via e-mail vanuit het systeem is verstuurd. Als er geen specifieke registratie is ingeschakeld, wordt het verzendmoment afgeleid van het boekingsmoment.
Waarom dit belangrijk is Meet hoe efficiënt facturen worden verstuurd. Vertraging tussen goedkeuring en verzending verlengt de betalingscyclus onnodig. Waar vind je dit? Als je de e-mailmogelijkheden van D365 gebruikt, kun je dit expliciet vastleggen in e-maillogs zoals SysOutgoingEmailTable. Anders wordt het verzendmoment vaak gelijkgesteld aan het boekingsmoment van de factuur in CustInvoiceJour. Vastleggen Gebruik de timestamp uit de e-maillog als die beschikbaar is. Gebruik anders de timestamp van de factuurboeking. Gebeurtenistype inferred
	Vervaldatum bereikt	Een berekende gebeurtenis die plaatsvindt wanneer de vervaldatum van de factuur is bereikt en de betaling nog niet volledig is verwerkt. Deze activiteit komt niet overeen met een transactie in het systeem, maar wordt afgeleid uit bestaande data.
Waarom dit belangrijk is Deze gebeurtenis is belangrijk om tijdige betalingen te analyseren en facturen op te sporen die achterstallig dreigen te raken. Het is het startpunt voor incasso- en aanmaningsactiviteiten. Waar vind je dit? Deze gebeurtenis wordt niet als zodanig geregistreerd. De gebeurtenis wordt berekend met het veld DueDate uit de tabel CustInvoiceJour. De timestamp van de gebeurtenis is de vervaldatum zelf. Vastleggen Maak een gebeurtenis aan met als timestamp de waarde van het veld CustInvoiceJour.DueDate. Gebeurtenistype calculated
	Betaling teruggedraaid	Deze activiteit geeft aan dat een eerder geboekte klantbetaling is teruggedraaid. Dit kan gebeuren door een foutieve boeking, onvoldoende saldo of een andere betalingsfout.
Waarom dit belangrijk is Teruggedraaide betalingen wijzen op fouten in de bedrijfsvoering of problemen met klantbetalingen. Door te analyseren hoe vaak dit gebeurt, kun je de oorzaken opsporen en de verwerking van betalingen nauwkeuriger maken. Waar vind je dit? Vastgelegd als een terugboeking in het grootboek. Een teruggedraaid journaal is te herkennen in GeneralJournalEntry, vaak aan een specifieke markering of de koppeling met de oorspronkelijke transactie. Vastleggen Zoek journaalposten met een markering voor terugboeking of een verwijzing naar een teruggedraaide transactie. Gebeurtenistype explicit
	Betalingsherinnering verstuurd	Dit is het versturen van een aanmaning of incassobericht aan een klant over een achterstallige factuur. Dynamics 365 heeft een formeel aanmaningsproces dat deze berichten aanmaakt en registreert.
Waarom dit belangrijk is Door herinneringen te volgen, kun je de effectiviteit van het aanmaningsproces beoordelen. Je kunt analyseren hoeveel herinneringen nodig zijn voordat een betaling binnenkomt. Waar vind je dit? Dit is een expliciete gebeurtenis, vastgelegd aan de hand van de aanmaakdatum van het incassobrievenjournaal in de tabel CustCollectionLetterJour. Dit journaal is gekoppeld aan de transactie van de achterstallige factuur. Vastleggen Gebruik de aanmaaktimestamp uit de tabel CustCollectionLetterJour. Gebeurtenistype explicit
	Creditnota aangemaakt	Dit is het aanmaken van een creditnota, meestal om een facturatiefout te corrigeren, een prijsaanpassing toe te passen of geretourneerde goederen te verwerken. Een creditnota is in feite een negatieve factuur.
Waarom dit belangrijk is Veel creditnota’s kunnen wijzen op structurele problemen in de orderafhandeling of facturatie. Door te onderzoeken waarom creditnota’s worden aangemaakt, kun je het proces verbeteren en omzetverlies beperken. Waar vind je dit? Dit is een expliciete transactie: een nieuwe geboekte factuur met een negatief bedrag in de tabel CustInvoiceJour. Vaak is er via een referentieveld een koppeling met de oorspronkelijke factuur. Vastleggen Zoek in CustInvoiceJour naar records met een negatief totaalbedrag en koppel deze aan de oorspronkelijke factuur. Gebeurtenistype explicit
	Factuur ter goedkeuring ingediend	Deze activiteit geeft aan dat een aangemaakte factuur is ingediend bij een formele goedkeuringsworkflow. Dit komt vaak voor bij organisaties waar een manager de factuur moet controleren voordat deze naar de klant wordt verstuurd. De D365-workflowengine registreert dit als een afzonderlijke stap.
Waarom dit belangrijk is Door de indiening ter goedkeuring te volgen, kun je de aanmaaktijd van de factuur onderscheiden van de wachttijd op goedkeuring. Dit is de eerste stap bij het analyseren van de efficiëntie van interne controles en beoordelingen. Waar vind je dit? Vastgelegd in de workflowgeschiedenistabellen, zoals WorkflowTrackingStatusTable, door te filteren op de indieningsgebeurtenis voor het factuurdocument. Vastleggen Haal workflow-eventlogs op met de status 'Submitted'. Gebeurtenistype explicit
	Verkooporder afgehandeld	Deze activiteit geeft aan dat goederen zijn verzonden of diensten zijn geleverd voor een verkooporder. Daarmee begint het facturatieproces. In Microsoft Dynamics 365 wordt dit meestal afgeleid uit het boeken van een pakbon of leveringsbon, waardoor de status van de bijbehorende verkooporderregels verandert.
Waarom dit belangrijk is Deze gebeurtenis is het startpunt voor het meten van de doorlooptijd tot het aanmaken van een factuur. Door de tijd tussen de afhandeling van de order en de facturatie te meten, kun je administratieve bottlenecks opsporen die de cashflow beïnvloeden. Waar vind je dit? Afgeleid van de aanmaakdatum van een pakbonjournaalpost die aan de verkooporder is gekoppeld. Hiervoor worden onder meer de tabellen CustPackingSlipJour en CustPackingSlipTrans gebruikt. Deze zijn gekoppeld aan de verkooporder waarop de factuur is gebaseerd. Vastleggen Bepaal de meest recente boekingsdatum van een pakbon voor de verkooporder die bij de factuur hoort. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Microsoft Dynamics 365

Stappen

Ga naar de werkruimte Data management: Meld je aan bij Microsoft Dynamics 365 Finance and Operations. Zoek via de zoekbalk de werkruimte Data management en open deze. Hier beheer je het importeren en exporteren van data.
Maak een nieuw exportproject: Klik in de werkruimte Data management op de tegel Export om een exportproject te maken. Geef het project een duidelijke naam, bijvoorbeeld ProcessMind_O2C_Billing_Export, en voeg een beschrijving toe.
Kies het doelformaat voor de data: Stel in de projectconfiguratie Target data format in. Kies CSV voor compatibiliteit met de meeste tools voor datatransformatie. Stel de formaatopties in, met een gangbaar scheidingsteken en tekstscheidingsteken.
Voeg de benodigde data-entiteiten toe: Dit is de belangrijkste stap. Voeg meerdere standaarddata-entiteiten toe om alle benodigde activiteiten vast te leggen. Klik voor elke entiteit op Add entity en zoek de naam op die in het gedeelte Query/Script staat. Voeg deze entiteiten toe aan het project: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement en Dunning history letters.
Stel filters in voor de entiteiten: Beperk de data tot een relevante periode en scope. Filter minimaal Sales invoice headers V2 op InvoiceDate, bijvoorbeeld voor de afgelopen 6 maanden. Filter ook op de rechtspersonen (bedrijven) die je wilt analyseren.
Voer de exporttaak uit: Klik in het actiedeelvenster op Export zodra alle entiteiten zijn toegevoegd en de filters zijn ingesteld. Het systeem maakt een taakpakket aan en start de data-extractie op de achtergrond.
Volg de voortgang en download de data: Je kunt de voortgang volgen in het gedeelte Job history. Download het geëxporteerde datapakket zodra de taak is afgerond. Het ZIP-bestand bevat voor elke data-entiteit een apart CSV-bestand.
Pak het pakket uit: Pak de inhoud van het gedownloade ZIP-bestand uit in een lokale map. Je hebt nu meerdere CSV-bestanden, één voor elke entiteit.
Transformeer en combineer de data: Zet de bronbestanden om naar één event log. Gebruik hiervoor bijvoorbeeld Power Query, Python of een stagingdatabase. Voeg voor elk bronbestand de benodigde kolommen toe: InvoiceNumber (Case-ID), ActivityName (een vaste waarde voor de gebeurtenis, zoals 'Factuur aangemaakt') en EventTime (het relevante datumveld uit het bronbestand). Koppel ook andere attributen, zoals InvoiceAmount en CustomerName.
Voeg alle getransformeerde data samen: Combineer de omgezette data uit alle bronbestanden in één tabel met een union- of append-bewerking. Zo ontstaat één event log waarin elke rij een activiteit in de levenscyclus van een factuur weergeeft.
Maak het bestand klaar om te uploaden: Controleer of de kolomkoppen in het uiteindelijke CSV-bestand kloppen (InvoiceNumber, ActivityName, EventTime enzovoort) en of de kolom EventTime overal hetzelfde timestamp-formaat gebruikt (bijvoorbeeld YYYY-MM-DD HH:MI:SS). Het bestand is nu klaar om naar ProcessMind te uploaden.

Configuratie

Data-entiteiten: Voor de extractie gebruik je een reeks standaard D365-data-entiteiten. Belangrijke entiteiten zijn Sales invoice headers V2 (voor facturen en creditnota's), Sales packing slip headers (voor orderafhandeling), CustPaymentJournalLineEntity (voor betalingen), Customer settlement (voor het verwerken van ontvangen betalingen) en Workflow tracking status table (voor goedkeuringen).
Exportformaat: CSV is het aanbevolen doelformaat, omdat het met veel tools voor datatransformatie werkt.
Filter op datumbereik: Stel een datumbereikfilter in voor de belangrijkste entiteiten, vooral voor het veld InvoiceDate van Sales invoice headers V2. Een periode van 3 tot 6 maanden houdt de export beheersbaar en levert genoeg data op voor analyse.
Filter op bedrijf: Filter de export op de rechtspersoon of bedrijfscode die je analyseert. Zo blijft de data relevant en wordt het exportbestand kleiner.
Data klaarzetten en transformeren: Na de export is een bewerkingsstap buiten Dynamics 365 nodig. Combineer de geëxporteerde bestanden en zet ze om naar één event log. Hiervoor kun je bijvoorbeeld Power BI (Power Query), Python of SQL gebruiken.
Vereisten vooraf: De gebruiker die de export uitvoert, moet in Dynamics 365 de juiste beveiligingsrollen hebben. Meestal is een rol nodig met rechten voor de werkruimte Data management en toegang tot de benodigde data-entiteiten.

Voorbeeldquery config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Stappen

Vereisten vooraf: Zorg dat Python 3.6 of hoger is geïnstalleerd, samen met de bibliotheken requests en pandas. Je hebt ook inloggegevens nodig voor een service principal (App Registration) in Azure Active Directory, met toegang tot de Dynamics 365 Finance & Operations-omgeving.
Registreer de applicatie: Registreer in Azure AD een nieuwe applicatie. Maak een client secret aan en noteer de Application (client) ID, Directory (tenant) ID en client secret. Voeg in Dynamics 365 deze applicatie-ID toe via System administration > Setup > Azure Active Directory applications en ken de juiste gebruikersrechten toe om de benodigde data-entiteiten te lezen.
Configureer het script: Open het meegeleverde Python-script. Vul bovenaan de configuratievariabelen in, waaronder d365_url, tenant_id, client_id, client_secret, company, start_date en end_date. De d365_url is de basis-URL van je Dynamics 365-omgeving, bijvoorbeeld https://your-d365-instance.operations.dynamics.com.
Authenticatie: Het script bevat de functie get_access_token. Deze gebruikt je inloggegevens om automatisch een OAuth2-access token aan te vragen bij het identiteitsplatform van Microsoft. Dit token is nodig om volgende API-aanroepen te autoriseren.
Data-extractie: Voer het script in je terminal uit met python your_script_name.py. Het script haalt eerst alle geboekte verkoopfacturen (CustInvoiceJour) binnen de opgegeven periode op. Daarna doet het voor elke factuur extra API-aanroepen om gerelateerde data op te halen voor activiteiten zoals betalingen, verrekeningen, creditnota's en workflowgeschiedenis.
Activiteiten aanmaken: Het script verwerkt de ruwe data uit meerdere API-eindpunten en maakt expliciet een rij aan voor elk van de 12 benodigde activiteiten. Zo gebruikt het de entiteit CustInvoiceJour voor het event 'Factuur aangemaakt' en bevraagt het de entiteit CustSettlement voor events 'Betaling verwerkt voor factuur'.
Afgeleide events: Events zoals 'Vervaldatum betaling bereikt' en 'Factuur gesloten' zijn geen rechtstreekse transacties in Dynamics 365. Het script leidt deze af uit de vervaldatum, status en verrekeningsgeschiedenis van een factuur en voegt de bijbehorende regels toe aan het event log.
Paginering verwerken: De hulpfunctie fetch_all_data verwerkt paginering automatisch. Dynamics 365 OData-API's geven per pagina een beperkt aantal records terug. De functie volgt daarom de @odata.nextLink in het API-antwoord om alle data op te halen.
Data transformeren en uitvoeren: Nadat alle events zijn verzameld, voegt het script ze samen in één lijst, zet die om naar een pandas DataFrame en standaardiseert de kolomnamen naar InvoiceNumber, ActivityName, EventTime en de overige benodigde attributen.
Exporteren naar CSV: Het script slaat de DataFrame op in het CSV-bestand d365_billing_event_log.csv. Dit bestand is klaar om naar ProcessMind of een andere process mining-tool te uploaden.

Configuratie

D365-URL: De basis-URL van je Dynamics 365 Finance & Operations-omgeving. Dit is het belangrijkste eindpunt voor alle API-aanroepen.
Azure AD-inloggegevens: Voor authenticatie zijn client_id, client_secret en tenant_id nodig. Gebruik gegevens van een applicatie met leestoegang tot de relevante D365-entiteiten.
Bedrijf: Geef de DataAreaId op. Deze verwijst naar de rechtspersoon in Dynamics 365 waaruit je data wilt ophalen, bijvoorbeeld 'USMF'.
Datumbereik: Stel start_date en end_date in om de extractieperiode te beperken. Voor een eerste analyse is 3 tot 6 maanden aan data aanbevolen. Zo blijft de dataset beheersbaar en bevat deze genoeg procesvariatie.
Belangrijke OData-entiteiten: Het script bevraagt voornamelijk de volgende entiteiten: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours en WorkflowTrackingStatusTables. Controleer of de ingestelde gebruiker leesrechten heeft voor al deze entiteiten.
Prestaties: Data over een lange periode ophalen of uit een zeer groot bedrijf kan traag zijn, omdat meerdere API-aanroepen na elkaar worden uitgevoerd. Voer het script bij voorkeur buiten piekuren uit en begin met een kortere periode om de totale uitvoertijd in te schatten.

Voorbeeldquery python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

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

Klaar om te beginnen?

Gebruik deze template om je facturatie en factuurverwerking te verbeteren. Geef je team de inzichten die nodig zijn om efficiënter te werken en de cashflow te verbeteren.

Terug naar de verbetergids

Template downloaden

Maak een einde aan facturatievertragingen: verbeter vandaag nog order-to-cash en factuurverwerking

Verkort de doorlooptijd van facturatie met 30% en krijg sneller inzicht in je financiële situatie.

Start je gratis proefperiode

Geen creditcard nodig. Gratis proefperiode van 14 dagen.

De datatemplate voor order-to-cash-facturatie en -factuurverwerking

De datatemplate voor order-to-cash-facturatie en -factuurverwerking

Attributen voor order-to-cash-facturatie en -factuurverwerking

Activiteiten voor order-to-cash-facturatie en -factuurverwerking

Extractiegidsen

Data-entiteiten exporteren uit Microsoft Dynamics 365

Stappen

Configuratie

Voorbeeldquery config

Python-script voor de Dynamics 365 OData Web API

Stappen

Configuratie

Voorbeeldquery python

Klaar om te beginnen?

Maak een einde aan facturatievertragingen: verbeter vandaag nog order-to-cash en factuurverwerking