> Continue procesverbetering > Order to Cash Facturatie en factuurverwerking > Microsoft Dynamics 365 > Datatemplate

Jouw datatemplate voor Order-to-Cash, facturatie en factuurverwerking

Microsoft Dynamics 365

Attributen voor Order to Cash - Facturatie en factuurverwerking (18) Activiteiten voor Order to Cash - Facturatie en factuurverwerking (12) Extractiegidsen (2)

Jouw datatemplate voor Order-to-Cash, facturatie en factuurverwerking

Deze template geeft je een duidelijk plan voor het verzamelen van de datapunten die je nodig hebt om je Order-to-Cash-proces voor facturatie en factuurverwerking te analyseren. Je vindt er aanbevolen attributen voor je event log, belangrijke activiteiten om te volgen en praktische aanwijzingen voor het ophalen van deze informatie. Zo zet je je data snel klaar voor process mining.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Extractiehandleiding voor Microsoft Dynamics 365

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

Template downloaden

Attributen voor Order to Cash - Facturatie en factuurverwerking

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van Order to Cash - Facturatie en factuurverwerking.

3 Verplicht 6 Aanbevolen 9 Optioneel

	Naam	Beschrijving
	Factuurnummer InvoiceNumber	De unieke identificatie van elke klantfactuur, die dient als primaire case-identificatie voor het facturatieproces.
Beschrijving Het Invoice Number is de centrale sleutel waarmee alle activiteiten rond één facturatiedocument worden gegroepeerd. Hiermee kun je de volledige levenscyclus van een factuur analyseren, van generatie en goedkeuring tot klantbetaling en uiteindelijke afsluiting. Als je dit als Case ID gebruikt, hoort elke event-logvermelding bij een specifieke factuur. Zo kun je varianten gedetailleerd analyseren, doorlooptijden berekenen en de prestaties van elke factuurtransactie monitoren. Waarom dit belangrijk is Dit attribuut is essentieel om de volledige levenscyclus van een factuur te volgen en de procesefficiëntie, bottlenecks en afwijkingen per facturatiedocument te analyseren. Waar je het vindt Je vindt dit meestal in de module Sales and marketing, in tabellen zoals CustInvoiceJour (veld InvoiceId), of via datatiteiten zoals SalesInvoiceHeaderV2. Voorbeelden CIV-001254INV-2023-9876US-004321
	Activiteitnaam ActivityName	De naam van de bedrijfsactiviteit of gebeurtenis die op een specifiek moment in de levenscyclus van de factuur plaatsvond.
Beschrijving Dit attribuut beschrijft een specifieke stap of mijlpaal in het facturatieproces, zoals 'Invoice Generated', 'Invoice Approved' of 'Customer Payment Received'. De volgorde van deze activiteiten vormt de procesflow. Het analyseren van activiteiten is een basis voor process mining, omdat je hiermee procesmodellen ontdekt, varianten identificeert en prestaties tussen verschillende stappen meet. Waarom dit belangrijk is Het definieert de stappen in het proces. Daarmee kun je proceskaarten visualiseren, procesvarianten analyseren en bottlenecks of afwijkingen van de standaardprocedure vinden. Waar je het vindt Dit attribuut wordt meestal afgeleid uit meerdere bronnen, zoals velden voor statuswijzigingen, bijvoorbeeld DocumentState, ingevulde datumvelden of workflowhistorielogs binnen Microsoft Dynamics 365. Voorbeelden Factuur gegenereerdFactuur goedgekeurdKlantbetaling ontvangenCreditnota uitgegeven
	Gebeurtenistijd EventTime	De precieze timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving Event Time, ook wel de timestamp genoemd, registreert de exacte datum en tijd van elke activiteit in het proces. Deze data is belangrijk voor alle tijdgebaseerde process-mininganalyses. Je gebruikt de data om doorlooptijden tussen activiteiten en de totale duur van een case te berekenen en om de procesprestaties in de tijd te begrijpen. Nauwkeurige en betrouwbare timestamps vormen de basis voor KPI's zoals Days Sales Outstanding en Invoice Generation Time. Waarom dit belangrijk is Dit is het basisattribuut voor alle prestatie- en tijdanalyses. Hiermee kun je doorlooptijden, duur en verwerkingscapaciteit berekenen om de procesefficiëntie te meten. Waar je het vindt Timestamps komen uit verschillende datum- en tijdvelden in meerdere tabellen van Dynamics 365, zoals CreatedDateTime in de tabel CustInvoiceJour voor factuurgeneratie of specifieke timestamps uit de workflowhistorie. 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 Met dit attribuut koppel je een activiteit of gebruiker aan een specifieke afdeling, zoals 'Accounts Receivable' of 'Sales'. Zo krijg je een overzicht van de procesprestaties op een hoger niveau dan dat van de individuele gebruiker. Analyse per afdeling helpt om overdrachten tussen functies te begrijpen, de efficiëntie van teams te vergelijken en bottlenecks op afdelingsniveau te herkennen, zoals nodig is voor het dashboard 'Billing Department Activity Load'. 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 je het vindt Dit is meestal geen rechtstreeks veld op de factuurtransactie. Je leidt het af door de UserResponsible-ID te koppelen aan de medewerkers- of gebruikersdirectory met informatie over de afdeling. Voorbeelden DebiteurenadministratieFinanciënFacturatie
	Factuurbedrag InvoiceAmount	De totale geldwaarde van de factuur.
Beschrijving Dit attribuut staat voor het totale bedrag dat op de factuur moet worden betaald. Het is een belangrijke maatstaf voor financiële analyse, omdat je facturen op waarde kunt segmenteren. Analisten kunnen zich bijvoorbeeld richten op facturen met een hoge waarde om betalingsgedrag te begrijpen of te zien of grotere facturen langer op goedkeuring wachten. Het is ook nodig om de totale waarde van openstaande facturen en DSO te berekenen. Waarom dit belangrijk is Hiermee kun je de financiële impact analyseren. Je kunt processen filteren en segmenteren op geldwaarde, prioriteit geven aan facturen met een hoge waarde en hun specifieke procesgedrag begrijpen. Waar je het vindt 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, Paid of Canceled.
Beschrijving Dit attribuut laat zien waar de factuur momenteel staat. Je ziet of de factuur nog op betaling wacht, volledig is betaald, achterstallig is of via een creditnota is geannuleerd. Dit is handig om cases te filteren, bijvoorbeeld voor een analyse van alleen openstaande facturen, of om de einduitkomst van een gesloten factuur te controleren. Zo krijg je inzicht in de huidige werklast en de financiële positie van openstaande vorderingen. Waarom dit belangrijk is Je krijgt snel een beeld van de huidige status van de factuur. Dat is handig om cases te filteren en de uitkomsten van verschillende procesvarianten te begrijpen. Waar je het vindt Je kunt dit afleiden uit de betaalstatus van de factuur, vaak door te controleren of het saldo op de gekoppelde CustTrans-record nul is. Er is niet altijd één veld met de naam 'status'. Voorbeelden OpenBetaaldAchterstalligGeannuleerd
	Klantnaam CustomerName	De naam van de klant aan wie de factuur is uitgegeven.
Beschrijving De klantnaam is een leesbare identificatie van de organisatie of persoon aan wie de factuur wordt gestuurd. Met process mining kun je het facturatieproces hiermee per klant segmenteren. Zo zie je welke klanten consequent op tijd betalen, welke vaak te laat zijn en of bepaalde klantgroepen met afwijkingen of vertragingen te maken hebben. Dit is belangrijk voor dashboards over betaalgedrag en voor analyses van Days Sales Outstanding. Waarom dit belangrijk is Hiermee kun je de procesanalyse per klant segmenteren en klantgedrag, betaalpatronen en procesproblemen herkennen. Waar je het vindt Deze informatie haal je op door de factuurdata te koppelen aan de tabel met stamgegevens van klanten, meestal CustTable, op basis van het klantrekeningnummer. Voorbeelden Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Verantwoordelijke gebruiker UserResponsible	De gebruiker of medewerker die verantwoordelijk is voor het uitvoeren van een specifieke activiteit.
Beschrijving Dit attribuut identificeert de persoon die een bepaalde taak in het facturatieproces heeft uitgevoerd, zoals het goedkeuren van een factuur of het toewijzen van een betaling. Het is belangrijk voor werklastanalyses, prestatievergelijkingen en het vaststellen van trainingsbehoeften. Het dashboard 'Billing Department Activity Load' gebruikt dit attribuut bijvoorbeeld om te controleren of het werk gelijkmatig is verdeeld en of bepaalde gebruikers een bottleneck vormen. Ook krijg je hiermee inzicht in de verdeling van capaciteit en de efficiëntie. Waarom dit belangrijk is Hiermee kun je op resource-niveau analyseren, bottlenecks herkennen, individuele of teamprestaties meten en de verdeling van de werklast binnen de facturatieafdeling bekijken. Waar je het vindt Deze informatie kan afkomstig zijn uit workflowhistorie, bijvoorbeeld WorkflowTrackingStatusTable, of uit eigenaarschapsvelden zoals Owner of ModifiedBy in relevante tabellen. Voorbeelden John SmithAlicia BakerSysteembeheerder
	Vervaldatum betaling PaymentDueDate	De datum waarop de klant de factuur uiterlijk hoort te betalen.
Beschrijving De vervaldatum van de betaling is een belangrijk datumveld dat wordt berekend op basis van de factuurdatum en de betaalvoorwaarden van de klant. Deze datum vormt de basis voor het meten van tijdige betalingen. Het attribuut is essentieel voor het dashboard 'Payment Terms Adherence Analysis' en voor KPI's zoals 'On-Time Payment Rate' en 'Days Sales Outstanding'. Door deze datum te vergelijken met de werkelijke betaaldatum zie je hoe klanten betalen en hoe effectief het incassoproces is. Waarom dit belangrijk is Dit is de referentie voor het meten van betaalprestaties. Je gebruikt de datum om het percentage tijdige betalingen te berekenen en te analyseren of klanten zich aan hun betaalvoorwaarden houden. Waar je het vindt Dit veld staat meestal in de tabel CustInvoiceJour, bijvoorbeeld in het veld DueDate. Voorbeelden 2023-05-152023-06-302023-07-01
	Betaalvoorwaarden PaymentTerms	De afgesproken voorwaarden voor het betalen van een factuur, bijvoorbeeld Net 30 of Net 60.
Beschrijving De betaalvoorwaarden bepalen wanneer een klant een factuur hoort te betalen. Je gebruikt dit attribuut om de vervaldatum te berekenen en om betaalgedrag te analyseren. Het dashboard 'Payment Terms Adherence Analysis' gebruikt dit attribuut om klanten en facturen te groeperen. Zo zie je of bepaalde betaalvoorwaarden beter werken of vaker samengaan met te late betalingen. Waarom dit belangrijk is Dit geeft context bij de vervaldatum van een factuur. Ook kun je de analyse ermee segmenteren om te zien of bepaalde betaalvoorwaarden samenhangen met te late betalingen. Waar je het vindt Dit staat meestal op de stamkaart van de klant en wordt gekopieerd naar de factuurkop. Zoek op de CustInvoiceJour-tabel naar een veld zoals Payment of PaymTermId. Voorbeelden Netto 30Netto 60Vervalt bij ontvangst
	Bronsysteem SourceSystem	Het systeem waaruit de data is geëxtraheerd.
Beschrijving Dit attribuut identificeert de herkomst van de procesdata. In deze context geeft het aan dat de data uit Microsoft Dynamics 365 komt. Dat is belangrijk in omgevingen met meerdere systemen, zodat je databronnen kunt onderscheiden en de herkomst van de data duidelijk blijft. Dit helpt bij datavalidatie en het oplossen van problemen. Waarom dit belangrijk is Het geeft belangrijke context over de herkomst van de data. Dat is nodig voor datagovernance, validatie en het samenvoegen van data uit meerdere bedrijfssystemen. Waar je het vindt Dit is een statische waarde die tijdens het data-extractie- en transformatieproces aan de dataset wordt toegevoegd om de herkomst ervan te markeren. Voorbeelden Microsoft Dynamics 365 FinanceD365 F&O
	Dagen openstaande verkoopfacturen DaysSalesOutstanding	Het aantal dagen tussen het aanmaken van de factuur en het ontvangen van de betaling van de klant.
Beschrijving Days Sales Outstanding (DSO) is een belangrijke financiële maatstaf voor het gemiddelde aantal dagen dat een organisatie nodig heeft om een betaling na een verkoop te innen. Dit berekende attribuut bepaalt die duur voor elke afzonderlijke factuur. Het is de belangrijkste maatstaf voor het dashboard 'Days Sales Outstanding Trend Analysis' en de KPI 'DSO'. Met een DSO-analyse beheer je de cashflow en beoordeel je de efficiëntie van kredietbeheer en incasso. Waarom dit belangrijk is Dit is een belangrijke KPI voor de gezondheid van de cashflow en de efficiëntie van het incassoproces. De KPI maakt zichtbaar hoe snel omzet in geld wordt omgezet. Waar je het vindt Dit attribuut staat niet in het bronsysteem. Je berekent het als de duur tussen de activiteit 'Invoice Generated' en de activiteit 'Customer Payment Received'. Voorbeelden 284592
	Handmatige interventie vereist RequiresManualIntervention	Een vlag die aangeeft of een betaling tijdens het toewijzen van de betaling handmatig moest worden aangepast.
Beschrijving Dit boolean-attribuut markeert betalingen waarvoor tijdens het toewijzen van betalingen handmatige interventie of correctie nodig was. Het is belangrijk voor de KPI 'Cash Application Discrepancy Rate', omdat je hiermee de nauwkeurigheid en automatiseringsgraad van het boeken van betalingen meet. Door de redenen voor handmatige interventie te herkennen, zoals ontbrekende betalingsinformatie of betalingsverschillen, kun je het proces verbeteren en het percentage straight-through processing verhogen. Waarom dit belangrijk is Met dit attribuut herken je wrijving en fouten in de stap voor het toewijzen van betalingen. Dat helpt om de automatisering te verbeteren en handmatig werk te verminderen. Waar je het vindt Je kunt deze informatie afleiden uit de gebruiker die de betaling heeft geboekt, als dit geen systeemgebruiker is, of uit specifieke redenencodes tijdens de betalingsafstemming. Raadpleeg de documentatie van Microsoft Dynamics 365. Voorbeelden truefalse
	Is herwerk IsRework	Een vlag die aangeeft of het facturatieproces herwerk bevatte, zoals meerdere goedkeuringen.
Beschrijving Dit is een berekend boolean-attribuut dat facturen markeert waaraan is herwerkt. Herwerk kan bijvoorbeeld betekenen dat er meerdere 'Invoice Approved'-events zijn of dat betalingen zijn teruggedraaid. Dit attribuut ondersteunt specifiek het dashboard 'Invoice Rework Analysis' en de KPI 'Invoice Rework Rate'. Door deze cases apart te bekijken, kunnen analisten de oorzaken van herwerk onderzoeken. Die wijzen vaak op inefficiënte processen, problemen met datakwaliteit of hiaten in training. Waarom dit belangrijk is Deze vlag maakt procesinefficiëntie meetbaar door cases met herhaalde of corrigerende acties te herkennen. Zo kun je de oorzaken van verspilling en vertraging vinden. Waar je het vindt Dit attribuut is niet beschikbaar in het bronsysteem. Je berekent het in de data-transformatielaag door herhaalde activiteiten of specifieke herwerkpatronen binnen een case te controleren. Voorbeelden truefalse
	Is tijdige betaling IsOnTimePayment	Een vlag die aangeeft of de betaling van de klant op of vóór de vervaldatum is ontvangen.
Beschrijving Dit berekende boolean-attribuut vergelijkt de timestamp van 'Customer Payment Received' met de 'Payment Due Date'. Het markeert elke factuur als op tijd betaald of te laat betaald. Dit is de basis voor de KPI 'On-Time Payment Rate' en wordt veel gebruikt in het dashboard 'Payment Terms Adherence Analysis'. Je krijgt hiermee een duidelijke uitkomst voor de betaalprestatie, waardoor analyse en rapportage eenvoudiger worden. Waarom dit belangrijk is Dit meet rechtstreeks of klanten zich aan hun betaalvoorwaarden houden. Het vormt de basis voor de KPI On-Time Payment Rate en maakt de analyse van de effectiviteit van het incassoproces eenvoudiger. Waar je het vindt Dit attribuut staat niet in het bronsysteem. Je berekent het tijdens de data-transformatie door de betaaldatum te vergelijken met PaymentDueDate. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst uit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut registreert wanneer de data voor het laatst uit Microsoft Dynamics 365 is geëxtraheerd of bijgewerkt. Het is een metadataveld dat belangrijk is om te begrijpen 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 datarefreshschema's en het betrouwbaar houden van de analyse. Waarom dit belangrijk is Het zorgt ervoor dat gebruikers weten hoe recent de data is. Dat is belangrijk voor datagovernance, het beheer van dashboardvernieuwingen en het vertrouwen in de actualiteit van inzichten. Waar je het vindt Dit attribuut wordt tijdens het ETL-proces voor data-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. Het is belangrijk voor multinationale organisaties die met verschillende valuta werken. Zonder deze context hebben het optellen en vergelijken van factuurbedragen weinig betekenis. Met deze informatie kun je valuta correct omrekenen en financiële rapportages en analyses voor verschillende regio's nauwkeurig uitvoeren. Waarom dit belangrijk is Het geeft essentiële context voor financiële maatstaven zoals Invoice Amount. Zo voorkom je onjuiste totalen en kun je data in omgevingen met meerdere valuta nauwkeurig analyseren. Waar je het vindt 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 ontstaan.
Beschrijving Het verkoopordernummer koppelt het facturatieproces aan het voorafgaande verkoopproces. Dat is waardevol voor een bredere end-to-end Order-to-Cash-analyse. Je kunt onderzoeken hoe problemen in verkoop en fulfilment, zoals orderwijzigingen of vertragingen bij verzending, de facturatiecyclus beïnvloeden. Zo kun je bijvoorbeeld beantwoorden: 'Worden facturen uit complexe verkooporders later betaald?'. Waarom dit belangrijk is Dit attribuut koppelt het facturatieproces aan het voorafgaande verkoopproces. Daarmee kun je een volledige end-to-end Order-to-Cash-analyse uitvoeren en de oorzaken van facturatieproblemen vinden. Waar je het vindt Dit staat in de factuurkop of bij de factuurregels en verwijst terug naar de verkooporder. Zoek op de CustInvoiceJour-tabel 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 die je in je event log vastlegt voor een nauwkeurige procesontdekking en analyse.

7 Aanbevolen 5 Optioneel

	Activiteit	Beschrijving
	Betaling aan factuur toegewezen	Dit staat voor het afwikkelen van een klantbetaling tegen een specifieke factuur, waardoor het openstaande saldo van de factuur afneemt. Dit is een afzonderlijke stap in Dynamics 365 die de betalingstransactie aan de factuurtransactie koppelt.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het nauwkeurig berekenen van DSO en het begrijpen van de efficiëntie van het team dat ontvangen betalingen verwerkt. Het markeert het moment waarop de betaling volledig is afgestemd met het gefactureerde bedrag. Waar je het vindt Vastgelegd in de tabel CustSettlement. Het datumveld voor de afwikkeling in deze tabel geeft de timestamp waarop een specifieke betaling aan een specifieke factuurtransactie is toegewezen. Vastleggen Gebruik TransDate of CreatedDateTime uit de tabel CustSettlement. Eventtype explicit
	Factuur gegenereerd	Dit staat voor het aanmaken en boeken van het verkoopfactuurdocument in het systeem. Het is een expliciete transactie in Dynamics 365 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 facturatiecyclus van een factuur. Het is een belangrijke gebeurtenis voor het volgen van Days Sales Outstanding (DSO) en de totale procesduur. Waar je het vindt Vastgelegd via de aanmaaktimestamp van het geboekte verkoopfactuurrecord 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. Eventtype explicit
	Factuur gesloten	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 status van de factuur.
Waarom dit belangrijk is Deze gebeurtenis betekent dat de Order to Cash-cyclus voor één factuur succesvol is afgerond. De tijd tot deze status is een belangrijke maatstaf voor de totale efficiëntie van het proces. Waar je het vindt Afgeleid door te controleren of de factuurtransactie in de tabel CustTrans een resterend saldo van nul heeft. Dit wordt bepaald door het factuurbedrag te vergelijken met het totale bedrag dat ermee is verrekend. Vastleggen Leid dit af uit CustTrans-records waarvoor AmountCur gelijk is aan SettleAmountCur. De timestamp is de datum van de laatste afwikkeling. Eventtype inferred
	Factuur goedgekeurd	Markeert de afronding van het interne beoordelingsproces, waarbij de factuur formeel wordt goedgekeurd. Deze gebeurtenis wordt vastgelegd door het Dynamics 365-workflowsysteem en betekent dat de factuur klaar is om naar de klant te worden verstuurd.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het meten van de doorlooptijd van goedkeuring. Vertragingen in deze fase kunnen de totale tijd tot ontvangst van de klantbetaling rechtstreeks verlengen. Waar je het vindt Vastgelegd in workflowhistorietabellen, zoals WorkflowTrackingStatusTable, als afrondings- of goedkeuringsstap voor de specifieke factuurworkflowinstantie. Vastleggen Extraheer workflow-event logs waarin de status 'Approved' of 'Completed' is. Eventtype explicit
	Factuur naar klant verzonden	Deze activiteit staat voor het moment waarop de factuur naar de klant is verzonden, elektronisch of op papier. In Dynamics 365 kan dit een expliciete gebeurtenis zijn wanneer de factuur via systeeme-mail is verstuurd. Als specifieke tracking niet is ingeschakeld, kan het moment van boeken als verzendtijd worden gebruikt.
Waarom dit belangrijk is Meet de efficiëntie van het factuurbezorgingsproces. Een vertraging tussen goedkeuring en verzending verlengt de betalingscyclus onnodig. Waar je het vindt Kan expliciet worden vastgelegd in e-maillogs zoals SysOutgoingEmailTable wanneer je de e-mailmogelijkheden van D365 gebruikt. Anders wordt vaak de boektijd van de factuur uit CustInvoiceJour gebruikt. Vastleggen Gebruik de timestamp uit de e-maillog als die beschikbaar is. Gebruik anders de timestamp van het boeken van de factuur. Eventtype inferred
	Klantbetaling ontvangen	Deze activiteit markeert het aanmaken van een journaalpost voor een ontvangen klantbetaling. Er is dan geld ontvangen, maar het is nog niet aan een specifieke factuur toegewezen.
Waarom dit belangrijk is Dit is het startpunt voor het meten van de doorlooptijd van de verwerking van ontvangen geld. Zo maak je onderscheid tussen het ontvangen van geld en het daadwerkelijk afstemmen ervan met openstaande facturen. Waar je het vindt Vastgelegd bij het aanmaken of boeken van een klantbetalingsjournaal. Dit wordt geregistreerd in tabellen zoals LedgerJournalTrans, waarna bij het boeken een klanttransactie in CustTrans wordt aangemaakt. Vastleggen Gebruik de boektimestamp van het klantbetalingsjournaal uit LedgerJournalTable. Eventtype explicit
	Vervaldatum van betaling bereikt	Een berekende gebeurtenis die plaatsvindt wanneer de vervaldatum van de factuur is bereikt zonder dat de betaling 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 voor het analyseren van tijdige betalingen en het vinden van facturen die achterstallig dreigen te raken. Ze vormt het startpunt voor incasso- en aanmaningsactiviteiten. Waar je het vindt Dit wordt niet als gebeurtenis vastgelegd. 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 waarvan de timestamp de waarde van het veld CustInvoiceJour.DueDate is. Eventtype calculated
	Betaling teruggedraaid	Deze activiteit staat voor het terugdraaien van een eerder geboekte klantbetaling. Dit kan gebeuren door fouten zoals een onjuiste boeking, onvoldoende saldo of andere betalingsproblemen.
Waarom dit belangrijk is Teruggedraaide betalingen wijzen op operationele fouten of problemen met klantbetalingen. Door de frequentie ervan te analyseren, vind je oorzaken en verbeter je de nauwkeurigheid van het verwerken van ontvangen betalingen. Waar je het vindt Vastgelegd als een terugdraaiingstransactie in het grootboek. Een teruggedraaid journaal is herkenbaar in GeneralJournalEntry, vaak via een specifieke vlag of de relatie met de oorspronkelijke transactie. Vastleggen Identificeer journaalposten met een terugdraaiingsvlag of een verwijzing naar een teruggedraaide transactie. Eventtype explicit
	Betalingsherinnering verstuurd	Dit staat voor het versturen van een aanmaning of incassobericht aan een klant over een achterstallige factuur. Dynamics 365 heeft een formeel aanmaningsproces dat deze communicatie genereert en vastlegt.
Waarom dit belangrijk is Door herinneringen te volgen, kun je de effectiviteit van het aanmaningsproces beoordelen. Je ziet hoeveel herinneringen nodig zijn voordat een betaling wordt ontvangen. Waar je het vindt Dit is een expliciete gebeurtenis die wordt vastgelegd via de aanmaakdatum van het journaal voor de aanmaningsbrief in de tabel CustCollectionLetterJour. Dit journaal is gekoppeld aan de transactie van de achterstallige factuur. Vastleggen Gebruik de aanmaaktimestamp uit de tabel CustCollectionLetterJour. Eventtype explicit
	Creditnota uitgegeven	Dit staat voor het aanmaken van een creditnota of creditmemo, 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 het orderverwerkings- of facturatieproces. Door te analyseren waarom creditnota's worden uitgegeven, kun je het proces verbeteren en omzetverlies beperken. Waar je het vindt Dit is een expliciete transactie die als een nieuwe geboekte factuur met een negatief bedrag wordt vastgelegd in de tabel CustInvoiceJour. Vaak is deze via een referentieveld aan de oorspronkelijke factuur gekoppeld. Vastleggen Identificeer records in CustInvoiceJour met een negatief totaalbedrag en koppel ze aan de oorspronkelijke factuur. Eventtype explicit
	Factuur ter goedkeuring ingediend	Deze activiteit geeft aan dat een gegenereerde factuur is ingediend in een formele goedkeuringsworkflow. Dit komt vaak voor bij organisaties waar controles een managementbeoordeling vereisen voordat een factuur naar een klant wordt verstuurd. Dit wordt als een specifieke stap vastgelegd in de D365-workflowengine.
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 beoordelings- en controleprocessen. Waar je het vindt Vastgelegd in workflowhistorietabellen, zoals WorkflowTrackingStatusTable, door te filteren op de indieningsgebeurtenis die bij het factuurdocument hoort. Vastleggen Extraheer workflow-event logs waarin de status 'Submitted' is. Eventtype explicit
	Verkooporder uitgevoerd	Deze activiteit markeert het moment waarop goederen zijn verzonden of diensten zijn geleverd voor een verkooporder, waarmee het facturatieproces start. 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 van factuurgeneratie. Door de vertraging tussen uitvoering en facturatie te begrijpen, vind je administratieve bottlenecks die de cashflow kunnen beïnvloeden. Waar je het vindt Afgeleid van de aanmaakdatum van een pakbonjournaalpost die aan de verkooporder is gekoppeld. Hierbij gaat het om tabellen zoals CustPackingSlipJour en CustPackingSlipTrans, die gekoppeld zijn aan de verkooporder waarop de factuur is gebaseerd. Vastleggen Bepaal de meest recente boekingsdatum van de pakbon voor de verkooporder die aan de factuur is gekoppeld. Eventtype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data op uit Microsoft Dynamics 365

Stappen

Open de werkruimte Data management: Meld je aan bij Microsoft Dynamics 365 Finance and Operations. Gebruik de zoekbalk om de werkruimte Data management te vinden en te openen. Dit is het centrale punt voor alle import- en exportbewerkingen van data.
Maak een nieuw exportproject: Klik in de werkruimte Data management op de tegel Export om een nieuw data-exportproject te maken. Geef het project een duidelijke naam, zoals ProcessMind_O2C_Billing_Export, en voeg een beschrijving toe.
Selecteer het doelformaat: Geef in de projectconfiguratie het Target data format op. Kies voor compatibiliteit met de meeste datatransformatietools CSV. Stel de formaatopties naar behoefte in en gebruik een gangbaar scheidingsteken en een gangbare tekstkwalificatie.
Voeg de vereiste data-entiteiten toe: Dit is de belangrijkste stap. Voeg meerdere standaarddata-entiteiten toe om alle vereiste activiteiten vast te leggen. Klik per entiteit op Add entity en zoek naar de entiteitsnaam in de sectie Query/Script. Voeg de volgende entiteiten toe: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement en Dunning history letters.
Pas filters op entiteiten toe: Beperk de data tot een relevante scope door filters op je entiteiten toe te passen. Filter minimaal Sales invoice headers V2 op InvoiceDate voor een bepaalde periode, bijvoorbeeld de afgelopen 6 maanden. Filter ook op de specifieke juridische entiteiten die je wilt analyseren.
Voer de exporttaak uit: Als alle entiteiten zijn toegevoegd en de filters zijn ingesteld, klik je in het actiedeelvenster op Export. Het systeem maakt een taakpakket en start de data-extractie op de achtergrond.
Controleer en download de data: Je kunt de voortgang volgen in de sectie Job history. Zodra de taak succesvol is afgerond, kun je het geëxporteerde datapakket downloaden. Het pakket is een ZIP-bestand met afzonderlijke CSV-bestanden voor elke data-entiteit.
Pak het pakket uit: Pak de inhoud van het gedownloade ZIP-bestand uit in een lokale map. Je hebt nu meerdere CSV-bestanden, één per entiteit.
Transformeer en combineer de data: De bronbestanden moeten worden omgezet naar één event log. Gebruik hiervoor een datavoorbereidingstool zoals Power Query, Python of een staginggebied in een database. Maak voor elk bronbestand de vereiste kolommen aan: InvoiceNumber (Case ID), ActivityName (een vaste waarde voor de gebeurtenis, zoals 'Invoice Generated') en EventTime (het relevante datumveld uit het bronbestand). Koppel ook andere attributen, zoals InvoiceAmount en CustomerName.
Voeg alle getransformeerde data samen: Combineer de getransformeerde data uit alle bronbestanden in één tabel met een union- of append-bewerking. Zo ontstaat het uiteindelijke, uniforme event log waarin elke rij één activiteit in de levenscyclus van een factuur vertegenwoordigt.
Maak het bestand klaar voor upload: Controleer of het uiteindelijke CSV-bestand de juiste kolomkoppen heeft (InvoiceNumber, ActivityName, EventTime, enzovoort) en of de kolom EventTime één consistent timestamp-formaat gebruikt, bijvoorbeeld YYYY-MM-DD HH:MI:SS. Het bestand is nu klaar om naar ProcessMind te uploaden.

Configuratie

Data-entiteiten: De extractie gebruikt een aantal standaard D365-data-entiteiten. Belangrijke entiteiten zijn Sales invoice headers V2 (voor facturen en creditnota's), Sales packing slip headers (voor orderfulfilment), CustPaymentJournalLineEntity (voor betalingen), Customer settlement (voor het toewijzen van betalingen) en Workflow tracking status table (voor goedkeuringen).
Exportformaat: Het aanbevolen doelformaat is CSV, omdat dit breed wordt ondersteund door datatransformatietools.
Filter op datumbereik: Pas een filter op datumbereik toe op de belangrijkste entiteiten, vooral op het veld InvoiceDate van Sales invoice headers V2. Een periode van 3 tot 6 maanden is aan te raden. Zo blijft de export beheersbaar en bevat deze toch voldoende data voor analyse.
Filter op bedrijf: Filter de export op de specifieke juridische entiteit of bedrijfscode die je analyseert. Zo blijft de data relevant en beperk je de omvang van de export.
Data-staging en transformatie: Na de export is een verwerkingsstap buiten Dynamics 365 nodig. Combineer de geëxporteerde bestanden en zet ze om naar één event log. Hiervoor gebruik je meestal tools zoals Power BI (Power Query), Python of SQL.
Vereisten: De gebruiker die de export uitvoert, moet in Dynamics 365 de juiste beveiligingsrollen hebben. Meestal gaat het om een rol met rechten voor de werkruimte Data management en toegang tot de vereiste data-entiteiten.

a 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: Zorg dat Python 3.6 of hoger is geïnstalleerd, samen met de libraries requests en pandas. Je hebt ook inloggegevens nodig voor een service principal (App Registration) in Azure Active Directory die toegang heeft tot de omgeving van Dynamics 365 Finance & Operations.
Applicatieregistratie: 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 geef de applicatie de juiste gebruikersrechten om de vereiste data-entiteiten te lezen.
Configureer het script: Open het meegeleverde Python-script. Vul de configuratievariabelen bovenaan in, waaronder d365_url, tenant_id, client_id, client_secret, company, start_date en end_date. d365_url moet de basis-URL van je Dynamics 365-omgeving zijn, bijvoorbeeld https://your-d365-instance.operations.dynamics.com.
Authenticatie: Het script bevat een functie get_access_token die je inloggegevens automatisch gebruikt om een OAuth2-access token aan te vragen bij het identiteitsplatform van Microsoft. Dit token is nodig om de volgende API-aanroepen te autoriseren.
Data-extractie: Voer het script uit in je terminal met python your_script_name.py. Het script haalt eerst alle geboekte verkoopfacturen (CustInvoiceJour) binnen het opgegeven datumbereik op. Daarna doet het per factuur extra API-aanroepen voor gerelateerde data over betalingen, afstemmingen, creditnota's en workflowhistorie.
Activiteiten genereren: Het script verwerkt de onbewerkte data uit meerdere API-endpoints. Het maakt expliciet een rij aan voor elk van de 12 vereiste activiteiten. Zo gebruikt het de entiteit CustInvoiceJour voor het event 'Invoice Generated' en de entiteit CustSettlement voor events als 'Cash Applied to Invoice'.
Berekende events: Events zoals 'Payment Due Date Reached' en 'Invoice Closed' zijn geen rechtstreekse transacties in Dynamics 365. Het script leidt deze events af uit de vervaldatum, status en afstemmingshistorie van een factuur en maakt daarvoor overeenkomstige regels in het event log.
Paginering verwerken: De helperfunctie fetch_all_data verwerkt paginering automatisch. Dynamics 365 OData-API's geven per pagina een beperkt aantal records terug. Daarom volgt deze functie de @odata.nextLink in de API-respons om de volledige dataset op te halen.
Datatransformatie en uitvoer: Nadat alle events zijn verzameld, zet het script ze in één lijst, converteert die naar een pandas DataFrame en maakt de kolomnamen uniform: InvoiceNumber, ActivityName, EventTime en andere vereiste attributen.
Export naar CSV: Tot slot slaat het script de DataFrame op als d365_billing_event_log.csv. Dit bestand is opgemaakt en klaar om naar ProcessMind of een andere process-miningtool te uploaden.

Configuratie

D365-URL: De basis-URL van je Dynamics 365 Finance & Operations-instantie. Dit is het primaire endpoint voor alle API-aanroepen.
Azure AD-referenties: Voor authenticatie zijn een client_id, client_secret en tenant_id nodig. Deze moeten horen bij een applicatie met leestoegang tot de relevante D365-entiteiten.
Bedrijf: Geef de DataAreaId op. Deze komt overeen met de juridische entiteit in Dynamics 365 waaruit je data wilt extraheren, bijvoorbeeld 'USMF'.
Datumbereik: Stel een start_date en end_date in om de extractie te beperken. Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan. Zo blijft de dataset beheersbaar en bevat deze toch voldoende procesvariatie.
Belangrijkste OData-entiteiten: Het script bevraagt voornamelijk de volgende entiteiten: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours en WorkflowTrackingStatusTables. Controleer of de geconfigureerde gebruiker leesrechten heeft voor al deze entiteiten.
Prestaties: Het extraheren van data over een lange periode of uit een zeer groot bedrijf kan traag verlopen door de meerdere opeenvolgende API-aanroepen. Het is verstandig om het script buiten piekuren uit te voeren en met een kleiner datumbereik te beginnen, zodat je de totale uitvoeringstijd kunt inschatten.

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

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: optimaliseer Order-to-Cash en factuurverwerking vandaag

Verkort de doorlooptijd van je facturatiecyclus met 30% en krijg sneller helderheid over je financiële situatie.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Gratis proefperiode van 14 dagen.

Jouw datatemplate voor Order-to-Cash, facturatie en factuurverwerking

Jouw 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

Export van Microsoft Dynamics 365-data-entiteiten

Stappen

Configuratie

a Voorbeeldquery config

Python-script met de Dynamics 365 OData Web API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Maak een einde aan facturatievertragingen: optimaliseer Order-to-Cash en factuurverwerking vandaag

Jouw datatemplate voor Order-to-Cash, facturatie en factuurverwerking

Jouw 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

Export van Microsoft Dynamics 365-data-entiteiten

Stappen

Configuratie

a Voorbeeldquery config

Python-script met de Dynamics 365 OData Web API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Maak een einde aan facturatievertragingen: optimaliseer Order-to-Cash en factuurverwerking vandaag

We respecteren je privacy