> Continue verbetering > Order to Cash Facturatie en Debiteurenbeheer > Microsoft Dynamics 365 > datatemplate

Uw Order to Cash - Facturatie en Debiteurenbeheer Data Template

Microsoft Dynamics 365

Order to Cash - Facturatie en Debiteurenbeheer Attributes (18) Order to Cash - Facturatie en Debiteurenbeheer Activiteiten (12) Extractie Guides (2)

Uw Order to Cash - Facturatie en Debiteurenbeheer Data Template

Deze template biedt een duidelijke roadmap voor het verzamelen van de essentiële data points die nodig zijn om uw Order to Cash - Facturatie en Debiteurenbeheer proces te analyseren. U vindt er aanbevolen attributes om op te nemen in uw event log, key activities om te volgen en praktische begeleiding bij het extraheren van deze informatie. Het is ontworpen om u te helpen uw data snel in te richten voor inzichtelijke process mining.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Extractiehandleiding voor Microsoft Dynamics 365

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Order to Cash - Facturatie en Debiteurenbeheer Attributes

Dit zijn de aanbevolen data velden om op te nemen in uw event log voor uitgebreide Order to Cash - Facturatie en Debiteurenbeheer analyse.

3 Verplicht 6 Aanbevolen 9 Optioneel

	Naam	Omschrijving
	Factuurnummer InvoiceNumber	De unieke identifier voor elke klantenfactuur, dienend als de primaire case identifier voor het facturatieproces.
Omschrijving Het Invoice Number is de centrale sleutel die alle activiteiten groepeert die gerelateerd zijn aan één facturatiedocument. Het maakt een complete, end-to-end analyse van de factuur lifecycle mogelijk, van generatie en goedkeuring tot klantbetaling en definitieve afsluiting. Door dit als de Case ID te gebruiken, correspondeert elke event log entry met een specifieke factuur, wat gedetailleerde variantanalyse, cyclustijdberekening en prestatiemonitoring voor elke facturatietransactie mogelijk maakt. Het belang Dit attribute is essentieel voor het volgen van de gehele lifecycle van een factuur, waardoor de analyse van procesefficiëntie, knelpunten en afwijkingen voor elk individueel facturatiedocument mogelijk wordt. Vindplaats Dit is typisch te vinden in de Sales and marketing module, binnen tabellen zoals CustInvoiceJour (veld InvoiceId) of blootgesteld via data entities zoals SalesInvoiceHeaderV2. Voorbeelden CIV-001254INV-2023-9876US-004321
	Activiteitsnaam ActivityName	De naam van de zakelijke `activity` of `event` die heeft plaatsgevonden op een specifiek punt in de factuurlevenscyclus.
Omschrijving Dit attribute beschrijft een specifieke stap of mijlpaal binnen het facturatieproces, zoals 'Factuur Gegenereerd', 'Factuur Goedgekeurd' of 'Klantbetaling Ontvangen'. De sequentie van deze activiteiten vormt de procesflow. Het analyseren van de activiteiten is fundamenteel voor process mining, aangezien het de ontdekking van procesmodellen, identificatie van varianten en meting van prestaties tussen verschillende stappen mogelijk maakt. Het belang Het definieert de stappen in het proces, waardoor visualisatie van proceskaarten, analyse van procesvarianten en identificatie van knelpunten of afwijkingen van de standaardprocedure mogelijk is. Vindplaats Dit attribute wordt doorgaans afgeleid van meerdere bronnen, zoals statuswijzigingsvelden (bijv. DocumentState), specifieke datumvelden die worden gevuld, of workflow history logs binnen Microsoft Dynamics 365. Voorbeelden Factuur OpgesteldFactuur GoedgekeurdKlantbetaling OntvangenCreditnota uitgegeven
	Tijdstip Gebeurtenis EventTime	De precieze timestamp die aangeeft wanneer een specifieke activiteit of event heeft plaatsgevonden.
Omschrijving Event Time, also known as the timestamp, records de exact date en time voor elke activity in het process. This data is critical voor alle time-based process mining analyses. It is used to calculate cycle times between activities, measure de total duration van een case, en understand process performance over time. Accurate en reliable timestamps zijn de foundation voor KPI's like Days Sales Outstanding en Factuurgeneratietijd. Het belang Dit is het fundamentele attribute voor alle prestatie- en tijdgerelateerde analyse, wat de berekening van cyclustijden, duur en throughput mogelijk maakt om procesefficiëntie te meten. Vindplaats Timestamps zijn afkomstig van verschillende datum- en tijdvelden in diverse tabellen in Dynamics 365, zoals CreatedDateTime op de CustInvoiceJour tabel voor factuurgeneratie, of specifieke workflow history timestamps. Voorbeelden 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Afdeling Department	De afdeling die geassocieerd is met de gebruiker of de activity.
Omschrijving Dit attribute wijst een activity of gebruiker toe aan een specifieke organisatieafdeling, zoals 'Debiteuren' of 'Sales'. Het maakt een hoger-niveau weergave van procesprestaties mogelijk dan op individueel gebruikersniveau. Analyseren per afdeling helpt bij het begrijpen van cross-functionele overdrachten, het vergelijken van efficiëntie tussen teams en het identificeren van knelpunten op afdelingsniveau, zoals vereist door het 'Billing Department Activity Load' dashboard. Het belang Maakt performance analyse op organisatieniveau mogelijk, waarbij de efficiëntie tussen verschillende teams wordt vergeleken en wordt begrepen hoe interdepartementale handoffs het proces beïnvloeden. Vindplaats Dit is typisch geen direct veld op de factuurtransactie. Het wordt afgeleid door de UserResponsible ID te joinen met de employee of user directory die afdelingsinformatie bevat. Voorbeelden DebiteurenbeheerFinanciënFacturatiewerkzaamheden
	Factuurbedrag InvoiceAmount	Het totale factuurbedrag.
Omschrijving Dit attribute vertegenwoordigt het totale verschuldigde bedrag op de factuur. Het is een kritische metric voor financiële analyse, waardoor segmentatie van facturen op waarde mogelijk is. Analisten kunnen zich bijvoorbeeld richten op facturen met hoge waarde om hun betalingsgedrag te begrijpen of om te identificeren of grotere facturen langere goedkeuringstijden kennen. Het is ook fundamenteel voor het berekenen van de totale waarde van openstaande facturen en voor DSO berekeningen. Het belang Het maakt financiële impactanalyse mogelijk, waardoor u processen kunt filteren en segmenteren op monetaire waarde om facturen met hoge waarde te prioriteren en hun specifieke procesgedrag te begrijpen. Vindplaats Gevonden in de CustInvoiceJour table, typically in een field like InvoiceAmount. Also available in related transaction tables. Voorbeelden 5430.5012500.00750.25
	Factuurstatus InvoiceStatus	De huidige status van de factuur in zijn lifecycle (bijv. Open, Betaald, Geannuleerd).
Omschrijving Dit attribute biedt een momentopname van de huidige status van de factuur. Het geeft aan of een factuur nog wacht op betaling, volledig is betaald, achterstallig is, of is geannuleerd via een creditnota. Dit is nuttig voor het filteren van cases om alleen openstaande facturen te analyseren of om de uiteindelijke uitkomst van een gesloten factuur te bevestigen. Het helpt bij het begrijpen van de huidige workload en de financiële status van debiteuren. Het belang Biedt een snel overzicht van de huidige staat van de factuur, wat nuttig is voor het filteren van cases en het begrijpen van de uitkomsten van verschillende procesvarianten. Vindplaats Dit kan worden afgeleid van de betalingsstatus van de factuur, vaak door te controleren of het saldo op de gerelateerde CustTrans record nul is. Er is niet altijd een enkel 'status' veld. Voorbeelden OpenBetaaldAchterstalligGeannuleerd
	Klantnaam CustomerName	De naam van de klant aan wie de factuur is verzonden.
Omschrijving De klantnaam biedt een menselijk leesbare identificatie voor het bedrijf of de persoon aan wie wordt gefactureerd. In process mining analyse maakt dit segmentatie van het facturatieproces per klant mogelijk. Dit kan onthullen welke klanten consequent op tijd betalen, welke vaak te laat zijn, of als bepaalde klantgroepen unieke procesvariaties of vertragingen ervaren. Het is essentieel voor dashboards met betrekking tot klantbetalingsgedrag en Days Sales Outstanding analyse. Het belang Dit maakt procesanalyse mogelijk om te worden gesegmenteerd per klant, wat helpt bij het identificeren van klantspecifiek gedrag, betalingspatronen of procesproblemen. Vindplaats Deze informatie wordt opgehaald door de factuurdata te joinen met de klantstamdata tabel, typisch CustTable, gebaseerd op het klantrekeningnummer. Voorbeelden Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Uiterste betaaldatum PaymentDueDate	De datum waarop de klant de factuur naar verwachting zal betalen.
Omschrijving De Payment Due Date is een kritiek datumveld dat wordt berekend op basis van de factuurdatum en de betalingstermijnen van de klant. Het dient als de basislijn voor het meten van de tijdigheid van betalingen. Dit attribute is essentieel voor het 'Payment Terms Adherence Analysis' dashboard en voor het berekenen van KPI's zoals 'On-Time Payment Rate' en 'Days Sales Outstanding'. Het vergelijken van deze datum met de werkelijke betalingsdatum onthult het betalingsgedrag van klanten en de effectiviteit van het incassoproces. Het belang Dit is de benchmark voor het meten van betalingsprestaties. Het is essentieel voor het berekenen van op tijd betaalde percentages en het analyseren van de naleving van klantbetalingstermijnen. Vindplaats Dit is typisch te vinden in de CustInvoiceJour tabel 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 activity.
Omschrijving Dit attribute identificeert de persoon die een specifieke taak heeft uitgevoerd in het facturatieproces, zoals het goedkeuren van een factuur of het toepassen van cash. Het is cruciaal voor workload analyse, prestatievergelijking en het identificeren van trainingsbehoeften. Het 'Billing Department Activity Load' dashboard vertrouwt bijvoorbeeld op dit attribute om te zien of werk gelijkmatig is verdeeld of dat bepaalde gebruikers knelpunten zijn. Het helpt ook bij het begrijpen van resource-allocatie en efficiëntie. Het belang Het maakt analyse op resourceniveau mogelijk, wat helpt bij het identificeren van knelpunten, het meten van individuele of teamprestaties en het analyseren van de werkverdeling binnen de facturatieafdeling. Vindplaats Dit kan afkomstig zijn uit workflow history logs (bijv. WorkflowTrackingStatusTable) of ownership velden zoals Owner of ModifiedBy op relevante tabellen. Voorbeelden John SmithAlicia BakerSysteembeheerder
	Betalingstermijnen PaymentTerms	De overeengekomen voorwaarden voor factuurbetaling (bijv. Netto 30, Netto 60).
Omschrijving Payment Terms definiëren de regels voor wanneer een klant wordt verwacht een factuur te betalen. Dit attribute wordt gebruikt om de Payment Due Date te berekenen en is een belangrijke dimensie voor het analyseren van betalingsgedrag. Het 'Payment Terms Adherence Analysis' dashboard gebruikt dit attribute om klanten en facturen te groeperen om te zien of bepaalde payment terms meer of minder effectief zijn of geassocieerd worden met hogere percentages late betalingen. Het belang Het biedt context waarom een factuur op een bepaalde datum vervalt en maakt segmentatieanalyse mogelijk om te zien of bepaalde betalingstermijnen correleren met late betalingen. Vindplaats Dit wordt typisch opgeslagen in de customer master record, maar gekopieerd naar de factuurheader. Zoek naar een Payment of PaymTermId veld op de CustInvoiceJour tabel. Voorbeelden Netto 30Netto 60Verschuldigd bij ontvangst
	Bronsysteem SourceSystem	Het systeem waaruit de data is geëxtraheerd.
Omschrijving Dit attribute identificeert de oorsprong van de procesdata. In deze context specificeert het dat de data afkomstig is van Microsoft Dynamics 365. Dit is belangrijk in multi-systeem omgevingen om databronnen te onderscheiden en data lineage duidelijk te waarborgen, wat helpt bij data validatie en troubleshooting. Het belang Het biedt cruciale context over de data oorsprong, wat essentieel is voor data governance, validatie en bij het samenvoegen van data uit meerdere enterprise systemen. Vindplaats Dit is een statische waarde die tijdens het data-extractie- en transformatieproces wordt toegevoegd om de oorsprong van de dataset te labelen. Voorbeelden Microsoft Dynamics 365 FinanceD365 F&O
	Debiteurendagen DaysSalesOutstanding	Het aantal dagen tussen factuurgeneratie en het ontvangen van klantbetaling.
Omschrijving Days Sales Outstanding (DSO) is een key financial metric die het average number of days meet dat een company takes om payment te collecten after een sale has been made. This calculated attribute computes this duration voor elke individual invoice. It is de primary metric voor het 'Days Sales Outstanding Trend Analysis' dashboard en de 'DSO' KPI. Analyzing DSO helpt in managing cash flow en evaluating de efficiency van de credit en collections function. Het belang Dit is een kritische KPI voor het meten van de gezondheid van de cashflow van een bedrijf en de efficiëntie van het incassoproces. Het kwantificeert hoe snel omzet wordt omgezet in cash. Vindplaats Dit attribute bevindt zich niet in het bronsysteem. Het wordt berekend als de duur tussen de 'Invoice Generated' activity en de 'Customer Payment Received' activity. Voorbeelden 284592
	Is herstelwerk IsRework	Een vlag die aangeeft of het facturatieproces rework activities, zoals meerdere goedkeuringen, omvatte.
Omschrijving Dit is een berekend boolean attribute dat facturen markeert die rework hebben ondergaan. Rework kan worden gedefinieerd als het hebben van meerdere 'Invoice Approved' events of annuleringen van betalingen. Dit attribute is specifiek ontworpen om het 'Invoice Rework Analysis' dashboard en de 'Invoice Rework Rate' KPI te ondersteunen. Door deze cases te isoleren, kunnen analisten de hoofdoorzaken van rework onderzoeken, die vaak wijzen op procesinefficiënties, data quality issues of training gaps. Het belang Deze flag kwantificeert direct procesinefficiëntie door cases met repetitieve of corrigerende acties te identificeren, wat helpt bij het aanwijzen van hoofdoorzaken van verspilling en vertraging. Vindplaats Dit attribute is niet beschikbaar in het bronsysteem. Het wordt berekend in de data transformatie laag door te controleren op herhaalde activiteiten of specifieke rework patterns binnen een case. Voorbeelden truefalse
	Is Tijdige Betaling IsOnTimePayment	Een vlag die aangeeft of de klantbetaling op of vóór de vervaldatum is ontvangen.
Omschrijving Dit berekende boolean attribute vergelijkt de 'Customer Payment Received' timestamp met de 'Payment Due Date'. Het markeert elke factuur als ofwel op tijd betaald of te laat. Dit is de kerncomponent voor het berekenen van de 'On-Time Payment Rate' KPI en wordt veel gebruikt in het 'Payment Terms Adherence Analysis' dashboard. Het biedt een duidelijk, binair resultaat voor betalingsprestaties, wat analyse en rapportage vereenvoudigt. Het belang Meet direct customer adherence aan payment terms en is de basis voor de On-Time Payment Rate KPI, simplifying de analysis van collection effectiveness. Vindplaats Dit attribute bevindt zich niet in het bronsysteem. Het wordt berekend tijdens data transformatie door de betalingsdatum te vergelijken met de PaymentDueDate. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De `timestamp` die aangeeft wanneer de `data` voor deze `event` voor het laatst is ververst vanuit het bronsysteem.
Omschrijving Dit attribute registreert wanneer de data voor het laatst is geëxtraheerd of bijgewerkt uit Microsoft Dynamics 365. Het is een metadata veld dat cruciaal is voor het begrijpen van de actualiteit van de geanalyseerde data. Dit helpt analisten en zakelijke gebruikers te weten of zij naar de meest actuele informatie kijken en is van vitaal belang voor het beheren van data refresh schedules en het waarborgen van de betrouwbaarheid van de analyse. Het belang Het zorgt ervoor dat gebruikers de actualiteit van de data begrijpen, wat essentieel is voor data governance, dashboard refresh management en het vertrouwen in de tijdigheid van de inzichten. Vindplaats Dit attribute wordt gegenereerd en gestempeld op de dataset tijdens het data-extractie-, transformatie- en laadproces (ETL). Voorbeelden 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Valuta Currency	De valutacode van het factuurbedrag (bijv. USD, EUR).
Omschrijving Dit attribute specificeert de valuta waarin het factuurbedrag is uitgedrukt. Het is essentieel voor multinationale organisaties die met verschillende valuta's te maken hebben. Zonder deze context zou het aggregeren of vergelijken van factuurbedragen zinloos zijn. Het maakt een correcte valutaomrekening en nauwkeurige financiële rapportage en analyse in verschillende regio's mogelijk. Het belang Het biedt essentiële context voor financiële metrics zoals Invoice Amount, voorkomt incorrecte aggregaties en maakt accurate analyse mogelijk in multi-currency omgevingen. Vindplaats Gevonden in de CustInvoiceJour table, typically in een field like CurrencyCode. Voorbeelden USDEURGBP
	Vereist Handmatige Interventie RequiresManualIntervention	Een vlag die aangeeft of een betaling handmatige aanpassing vereiste tijdens de cash application.
Omschrijving Dit boolean attribute markeert betalingen die handmatige interventie of correctie nodig hadden tijdens het cash application proces. Dit is cruciaal voor de 'Cash Application Discrepancy Rate' KPI, aangezien het helpt de nauwkeurigheid en het automatisatieniveau van betalingsboeking te kwantificeren. Het identificeren van de redenen voor handmatige interventie, zoals ontbrekende remittance information of betalingsdiscrepanties, kan leiden tot procesverbeteringen die de straight-through processing rates verhogen. Het belang Dit attribute helpt bij het identificeren van proceswrijving en onnauwkeurigheden in de cash application stap, wat cruciaal is voor het verbeteren van automatisering en het verminderen van handmatige inspanning. Vindplaats Deze informatie kan worden afgeleid van de gebruiker die de betaling heeft geboekt (indien het geen systeemgebruiker is) of van specifieke reason codes die worden gebruikt tijdens betalingsreconciliatie. Raadpleeg de Microsoft Dynamics 365 documentatie. Voorbeelden truefalse
	Verkoopordernummer SalesOrderNumber	De identifier van de verkooporder die de factuur heeft voortgebracht.
Omschrijving Het Sales Order Number koppelt het facturatieproces terug aan het voorafgaande verkoopproces. Deze connectie is van onschatbare waarde voor een bredere, end-to-end Order to Cash analyse. Het stelt analisten in staat te onderzoeken hoe problemen in het verkoop- en fulfillmentproces, zoals orderwijzigingen of verzendvertragingen, de facturatiecyclus kunnen beïnvloeden. Het kan bijvoorbeeld helpen vragen te beantwoorden als 'Duurt het langer om facturen van complexe verkooporders betaald te krijgen?'. Het belang Dit attribute verbindt het facturatieproces met het upstream verkoopproces, wat een meer uitgebreide end-to-end Order to Cash analyse mogelijk maakt om hoofdoorzaken van facturatieproblemen te identificeren. Vindplaats Gevonden op de invoice header of line details, linking back to de sales order. Look for een field like SalesId on de CustInvoiceJour table. Voorbeelden SO-009876SO-010234US-SO-00543

Verplicht Aanbevolen Optioneel

Order to Cash - Facturatie en Debiteurenbeheer Activiteiten

Dit zijn de belangrijkste `processtappen` en `mijlpalen` om vast te leggen in uw `event log` voor accurate `process discovery` en `analyse`.

7 Aanbevolen 5 Optioneel

	Activiteit	Omschrijving
	Betalingsvervaldatum Bereikt	Een berekende gebeurtenis die optreedt wanneer de vervaldatum van de factuur wordt bereikt zonder dat een betaling volledig is afgeschreven. Deze activity komt niet overeen met een transactie in het systeem, maar is afgeleid van bestaande data.
Het belang Deze event is cruciaal voor het analyseren van op tijd betaalde percentages en het identificeren van facturen die achterstallig worden. Het fungeert als een triggerpoint voor incasso- en aanmaningsactiviteiten. Vindplaats Dit wordt niet als een event vastgelegd. Het wordt berekend met behulp van het DueDate veld uit de CustInvoiceJour tabel. De event timestamp is de vervaldatum zelf. Vastleggen Creëer een event waarvan de timestamp de value is van het CustInvoiceJour.DueDate field. Gebeurtenistype calculated
	Contant geld toegewezen aan factuur	Vertegenwoordigt de verrekening van een klantbetaling met een specifieke factuur, waardoor het openstaande saldo van de factuur wordt verminderd. Dit is een aparte stap in Dynamics 365 die de betalingstransactie koppelt aan de factuurtransactie.
Het belang Dit is een kritieke mijlpaal voor het nauwkeurig berekenen van DSO en het begrijpen van de efficiëntie van het cash application team. Het markeert het punt waarop de betaling volledig is gereconcilieerd met wat gefactureerd is. Vindplaats Vastgelegd in de CustSettlement tabel. Het settlement date veld in deze tabel levert de timestamp voor wanneer een specifieke betaling werd toegepast op een specifieke factuurtransactie. Vastleggen Gebruik de TransDate of CreatedDateTime uit de CustSettlement tabel. Gebeurtenistype explicit
	Factuur afgesloten	Deze activity markeert de uiteindelijke staat van een factuur, waarbij het saldo nul is omdat deze volledig is betaald of verrekend met creditnota's. Dit is geen directe transactie, maar een afgeleide staat gebaseerd op de financiële status van de factuur.
Het belang Deze event duidt op de succesvolle voltooiing van de Order to Cash cyclus voor een enkele factuur. De tijd die nodig is om deze staat te bereiken is een primaire maatstaf voor de algehele efficiëntie van het proces. Vindplaats Afgeleid door te controleren of de factuurtransactie in de CustTrans tabel een resterend saldo van nul heeft. Dit wordt bepaald door het factuurbedrag te vergelijken met het totale verrekende bedrag daarvan. Vastleggen Afleiden uit CustTrans records waar AmountCur gelijk is aan SettleAmountCur. De timestamp is de datum van de laatste aflettering. Gebeurtenistype inferred
	Factuur Goedgekeurd	Markeert de voltooiing van het interne reviewproces, waar de factuur formeel wordt goedgekeurd. Deze event wordt gelogd door het Dynamics 365 workflow systeem en geeft aan dat de factuur klaar is om naar de klant te worden verzonden.
Het belang Dit is een belangrijke mijlpaal voor het meten van de approval cycle time. Vertragingen in dit stadium kunnen de totale tijd om betaling van de klant te ontvangen direct verlengen. Vindplaats Vastgelegd in de workflow history tabellen, zoals WorkflowTrackingStatusTable, als een voltooiings- of goedkeuringsstap voor de specifieke factuur workflow instance. Vastleggen Extraheer workflow event logs waar de status 'Goedgekeurd' of 'Voltooid' is. Gebeurtenistype explicit
	Factuur naar Klant Verzonden	Deze activity vertegenwoordigt het moment dat de factuur naar de klant werd verzonden, hetzij elektronisch of fysiek. In Dynamics 365 kan dit een expliciete event zijn indien verzonden via systeem-e-mail, of afgeleid worden plaats te vinden op het moment van boeking indien geen specifieke tracking is ingeschakeld.
Het belang Meet de efficiëntie van het factuurbezorgingsproces. Een vertraging tussen goedkeuring en verzending van de factuur verlengt de betalingscyclus onnodig. Vindplaats Kan expliciet worden vastgelegd uit email logs zoals SysOutgoingEmailTable indien D365's email mogelijkheden worden gebruikt. Anders wordt het vaak afgeleid als zijnde gelijk aan de invoice posting time uit CustInvoiceJour. Vastleggen Gebruik de e-mail log timestamp indien beschikbaar; anders, gebruik de factuurboekings timestamp. Gebeurtenistype inferred
	Factuur Opgesteld	Vertegenwoordigt de creatie en boeking van het verkoopfactuurdocument in het systeem. Dit is een expliciete transactie in Dynamics 365 die een juridisch document en financiële posten creëert in het debiteuren subgrootboek.
Het belang Dit is de officiële start van de billing lifecycle voor een factuur. Het is een kritische event voor het volgen van Days Sales Outstanding (DSO) en de totale procesduur. Vindplaats Vastgelegd vanaf de creation timestamp van de posted sales invoice record in de CustInvoiceJour table. De corresponderende financial transactions zijn created in de GeneralJournalEntry en LedgerEntry tables upon posting. Vastleggen Gebruik het CreatedDateTime veld uit de CustInvoiceJour tabel voor de geboekte factuur. Gebeurtenistype explicit
	Klantbetaling Ontvangen	Deze activity markeert de creatie van een journaalpost om een van een klant ontvangen betaling te registreren. Het betekent dat cash is ontvangen, maar het is nog niet toegepast op een specifieke factuur.
Het belang Dit is het startpunt voor het meten van de cash application lead time. Het maakt onderscheid tussen het ontvangen van het geld en het daadwerkelijk reconciliëren ervan met openstaande facturen. Vindplaats Vastgelegd vanuit de creation of posting van een customer payment journal. Dit wordt recorded in tables zoals LedgerJournalTrans, which then creates a customer transaction in CustTrans upon posting. Vastleggen Gebruik de posting timestamp van het klantbetalingsjournaal uit LedgerJournalTable. Gebeurtenistype explicit
	Betaling Geannuleerd	Deze activity duidt op de annulering van een eerder geboekte klantbetaling. Dit gebeurt als gevolg van fouten zoals incorrecte boeking, onvoldoende saldo of andere betalingsproblemen.
Het belang Betalingsannuleringen benadrukken operationele fouten of problemen met klantbetalingen. Het analyseren van hun frequentie helpt hoofdoorzaken te identificeren en de nauwkeurigheid van het cash application proces te verbeteren. Vindplaats Vastgelegd als een transactie reversal in het general ledger. Een reversed journal kan worden geïdentificeerd in GeneralJournalEntry, vaak met een specifieke flag of door zijn relationship tot de original transaction. Vastleggen Identificeer journaalposten met een annuleringsvlag of een verwijzing naar een geannuleerde transactie. Gebeurtenistype explicit
	Betalingsherinnering Verzonden	Vertegenwoordigt het versturen van een aanmaningsbrief of incassokennisgeving aan een klant betreffende een achterstallige factuur. Dynamics 365 heeft een formeel aanmaningsproces dat deze communicaties genereert en logt.
Het belang Het volgen van herinneringen helpt bij het evalueren van de effectiviteit van het aanmaningsproces. Het maakt analyse mogelijk van hoeveel herinneringen nodig zijn voordat een betaling wordt ontvangen. Vindplaats Dit is een expliciete event vastgelegd vanuit de creatiedatum van het incassobriefjournaal in de CustCollectionLetterJour tabel, dat is gekoppeld aan de achterstallige factuurtransactie. Vastleggen Gebruik de creation timestamp uit de CustCollectionLetterJour tabel. Gebeurtenistype explicit
	Creditnota uitgegeven	Vertegenwoordigt de creatie van een creditnota, typisch om een factureringsfout te corrigeren, een prijscorrectie toe te kennen of teruggaven van goederen te verantwoorden. Een creditnota is in essentie een negatieve factuur.
Het belang Frequent credit notes kunnen systemic issues in de order fulfillment of billing process indiceren. Analyzing why credit notes worden issued is key to process improvement en reducing revenue leakage. Vindplaats Dit is een expliciete transactie, vastgelegd als een nieuwe geboekte factuur met een negatief bedrag in de CustInvoiceJour tabel. Het is vaak gekoppeld aan de oorspronkelijke factuur via een referentieveld. Vastleggen Identificeer records in CustInvoiceJour met een negatief totaalbedrag en koppel deze aan de oorspronkelijke factuur. Gebeurtenistype explicit
	Factuur ter goedkeuring ingediend	Deze activity geeft aan dat een gegenereerde factuur is ingediend in een formele goedkeuringsworkflow. Dit is gebruikelijk in organisaties met controles die management review vereisen voordat een factuur naar een klant wordt verzonden. Dit wordt gelogd als een specifieke stap in de D365 workflow engine.
Het belang Het volgen van de indiening ter goedkeuring helpt de factuurcreatietijd te scheiden van de wachttijd voor goedkeuring. Het is de eerste stap in het analyseren van de efficiëntie van de interne review- en controleprocessen. Vindplaats Vastgelegd uit de workflow history tables, such as WorkflowTrackingStatusTable, by filtering for the submission event related to the invoice document. Vastleggen Extraheer workflow event logs waar de status 'Ingediend' is. Gebeurtenistype explicit
	Verkooporder Uitgevoerd	Deze activity markeert het punt waarop goederen zijn verzonden of diensten zijn geleverd voor een verkooporder, wat het facturatieproces activeert. Het wordt typisch afgeleid van het boeken van een pakbon of afleverbon in Microsoft Dynamics 365, wat de status van de gerelateerde verkooporderregels wijzigt.
Het belang Deze event dient als startpunt voor het meten van de cyclustijd voor factuurgeneratie. Het begrijpen van de vertraging tussen fulfillment en facturatie helpt bij het identificeren van administratieve knelpunten die de cashflow kunnen beïnvloeden. Vindplaats Afgeleid van de creatiedatum van een pakbonjournaalpost gekoppeld aan de verkooporder. Dit betreft tabellen zoals CustPackingSlipJour en CustPackingSlipTrans, die gerelateerd zijn aan de verkooporder waarop de factuur is gebaseerd. Vastleggen Identificeer de meest recente boekingsdatum van de pakbon voor de verkooporder die aan de factuur is gekoppeld. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Zo haal je je data uit Microsoft Dynamics 365

Stappen

Navigeer naar de Data Management Workspace: Log in bij Microsoft Dynamics 365 Finance and Operations. Gebruik de zoekbalk om de Data management workspace te vinden en hiernaartoe te navigeren. Dit is het centrale punt voor alle data import- en exportoperaties.
Maak een nieuw Export Project aan: Klik binnen de Data management workspace op de Export tegel om een nieuw data export project aan te maken. Geef het project een zinvolle naam, zoals ProcessMind_O2C_Billing_Export, en een description.
Selecteer Target Data Format: Geef in de projectconfiguratie het Target data format op. Voor compatibiliteit met de meeste data transformatie tools, selecteer CSV. Configureer de format options naar behoefte, zorg voor een gemeenschappelijke delimiter en text qualifier.
Voeg Vereiste Data Entities toe: Dit is de meest kritieke stap. U voegt meerdere standaard data entities toe aan uw project om alle vereiste activities vast te leggen. Klik voor elke entity op Add entity en zoek naar de entity naam die in de Query/Script sectie wordt vermeld. Voeg elk van de volgende entities toe aan uw project: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement en Dunning history letters.
Pas Entity Filters toe: Om de data te beperken tot een relevante scope, past u filters toe op uw entities. Filter minimaal Sales invoice headers V2 op InvoiceDate voor een specifieke periode, bijvoorbeeld de laatste 6 maanden. Filter ook op de specifieke legal entities (companies) die u wilt analyseren.
Voer de Export Job uit: Zodra alle entities zijn toegevoegd en filters zijn toegepast, klikt u op de Export knop in het actiepaneel. Het systeem maakt een job package aan en begint de data-extractie op de achtergrond te verwerken.
Monitor en Download de Data: U kunt de voortgang van de job volgen in de Job history sectie. Zodra de job succesvol is voltooid, kunt u het geëxporteerde data package downloaden. Het package is een ZIP-bestand dat afzonderlijke CSV-bestanden voor elke data entity bevat.
Pak het Package uit: Pak de inhoud van het gedownloade ZIP-bestand uit naar een lokale map. U hebt nu meerdere CSV-bestanden, één voor elke entity.
Transformeer en Combineer Data: De ruwe bestanden moeten worden getransformeerd naar een enkel event log. Gebruik een data preparation tool zoals Power Query, Python of een database staging area. Maak voor elk bronbestand de vereiste kolommen aan: InvoiceNumber (Case ID), ActivityName (een hardcoded value die de event vertegenwoordigt, zoals 'Invoice Generated') en EventTime (het relevante date veld uit het bronbestand). Map andere attributes zoals InvoiceAmount en CustomerName.
Combineer alle Getransformeerde Data: Combineer de getransformeerde data van alle bronbestanden tot één tabel met behulp van een union- of append-operatie. Dit creëert het uiteindelijke, unified event log waarbij elke rij één activity in de invoice lifecycle vertegenwoordigt.
Eindformatteer voor Upload: Zorg ervoor dat het uiteindelijke CSV-bestand de juiste kolomheaders (InvoiceNumber, ActivityName, EventTime, etc.) heeft en dat de EventTime kolom in een consistent timestamp format (bijv. YYYY-MM-DD HH:MI:SS) is. Dit bestand is nu klaar voor upload naar ProcessMind.

Configuratie

Data Entities: De extractie is gebaseerd op een reeks standaard D365 data entities. Belangrijke entities zijn onder meer Sales invoice headers V2 (voor facturen en creditnota's), Sales packing slip headers (voor orderafhandeling), CustPaymentJournalLineEntity (voor betalingen), Customer settlement (voor cash application) en Workflow tracking status table (voor goedkeuringen).
Export Format: Het aanbevolen target data format is CSV vanwege de brede compatibiliteit met data transformatie tools.
Date Range Filtering: Het is cruciaal om een date range filter toe te passen op de primaire entities, vooral Sales invoice headers V2 op het InvoiceDate veld. Een bereik van 3 tot 6 maanden wordt aanbevolen om de export beheersbaar te houden en tegelijkertijd voldoende data voor analyse te bieden.
Company Filtering: De export moet worden gefilterd op de specifieke legal entity of company code die u analyseert om data relevantie te waarborgen en de exportgrootte te verminderen.
Data Staging and Transformation: Een post-processing stap buiten Dynamics 365 is vereist. De geëxporteerde bestanden moeten worden gecombineerd en opnieuw gevormd tot een enkel event log format. Dit omvat doorgaans het gebruik van tools zoals Power BI (Power Query), Python of SQL.
Prerequisites: De gebruiker die de export uitvoert, moet de juiste security roles hebben toegewezen in Dynamics 365, doorgaans inclusief een rol met permissions voor de Data management workspace en toegang tot de vereiste data entities.

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

Prerequisites: Zorg ervoor dat u Python 3.6+ hebt geïnstalleerd met de requests en pandas libraries. U hebt ook credentials nodig voor een service principal (App Registration) in Azure Active Directory die toegang heeft gekregen tot de Dynamics 365 Finance & Operations-omgeving.
Application Registration: Registreer in Azure AD een nieuwe applicatie. Maak een client secret aan en noteer de Application (client) ID, Directory (tenant) ID en het client secret. Voeg in Dynamics 365 deze applicatie ID toe onder Systeembeheer > Setup > Azure Active Directory applications en wijs deze de juiste gebruikersrechten toe om de vereiste data entities te lezen.
Configure the Script: Open het meegeleverde Python-script. Vul de configuratievariabelen bovenaan het script in, inclusief d365_url, tenant_id, client_id, client_secret, company, start_date en end_date. De d365_url moet de basis-URL van uw Dynamics 365-omgeving zijn, bijvoorbeeld https://your-d365-instance.operations.dynamics.com.
Authentication: Het script bevat een functie get_access_token die automatisch uw credentials gebruikt om een OAuth2 access token aan te vragen bij Microsoft's identity platform. Dit token is vereist om latere API calls te autoriseren.
Data Extraction: Voer het script uit vanuit uw terminal met python your_script_name.py. Het script begint met het ophalen van alle geboekte verkoopfacturen (CustInvoiceJour) binnen het opgegeven datumbereik. Voor elke factuur maakt het vervolgens aanvullende API calls om gerelateerde data op te halen voor activities zoals payments, settlements, credit notes en workflow history.
Activity Generation: Het script verwerkt de ruwe data van meerdere API-endpoints. Het genereert expliciet een rij voor elk van de 12 vereiste activities. Het gebruikt bijvoorbeeld de CustInvoiceJour entity voor de 'Invoice Generated' event en bevraagt de CustSettlement entity om 'Cash Applied to Invoice' events te creëren.
Calculated Events: Merk op dat events zoals 'Payment Due Date Reached' en 'Invoice Closed' geen directe transacties zijn in Dynamics 365. Het script leidt deze events af op basis van de vervaldatum, status en settlement history van een factuur, en creëert corresponderende entries in het event log.
Handling Pagination: De fetch_all_data helper functie is ontworpen om pagination automatisch af te handelen. Dynamics 365 OData APIs retourneren een beperkt aantal records per pagina, dus deze functie volgt de @odata.nextLink in de API response om de complete dataset op te halen.
Data Transformation and Output: Na het verzamelen van alle events, compileert het script ze in een enkele lijst, converteert deze naar een pandas DataFrame en standaardiseert de kolomnamen naar InvoiceNumber, ActivityName, EventTime en andere vereiste attributes.
Export to CSV: Tenslotte slaat het script de resulterende DataFrame op in een CSV-bestand met de naam d365_billing_event_log.csv. Dit bestand is geformatteerd en klaar voor upload naar ProcessMind of een andere process mining tool.

Configuratie

D365 URL: De basis-URL van uw Dynamics 365 Finance & Operations-instantie. Dit is het primaire eindpunt voor alle API calls.
Azure AD Credentials: Een client_id, client_secret en tenant_id zijn vereist voor authenticatie. Deze moeten behoren tot een applicatie met leesrechten voor de relevante D365-entiteiten.
Company: Geef de DataAreaId op, die overeenkomt met de juridische entiteit in Dynamics 365 waaruit u data wilt extraheren (bijv. 'USMF').
Date Range: Definieer een start_date en end_date om de extractieomvang te beperken. Voor een eerste analyse wordt een periode van 3 tot 6 maanden aanbevolen om een beheersbare datasetgrootte te garanderen en tegelijkertijd voldoende procesvariaties vast te leggen.
Key OData Entities: Het script bevraagt voornamelijk de volgende entiteiten: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours en WorkflowTrackingStatusTables. Zorg ervoor dat de geconfigureerde gebruiker machtigingen heeft om van al deze entiteiten te lezen.
Performance: Data extraheren voor een lange periode of van een zeer groot bedrijf kan traag zijn vanwege de aard van het uitvoeren van meerdere sequentiële API calls. Het is raadzaam om het script buiten de piekuren uit te voeren en te beginnen met een kleiner datumbereik om de totale uitvoeringstijd te schatten.

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()

Uw Order to Cash - Facturatie en Debiteurenbeheer Data Template

Uw Order to Cash - Facturatie en Debiteurenbeheer Data Template

Order to Cash - Facturatie en Debiteurenbeheer Attributes

Order to Cash - Facturatie en Debiteurenbeheer Activiteiten

Extractie Guides

Microsoft Dynamics 365 Data Entity Export

Stappen

Configuratie

a Voorbeeldquery config

Python Script met Dynamics 365 OData Web API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te starten?

Beëindig Facturatievertragingen: Optimaliseer Van Order tot Cash & Facturering Vandaag

Uw Order to Cash - Facturatie en Debiteurenbeheer Data Template

Uw Order to Cash - Facturatie en Debiteurenbeheer Data Template

Order to Cash - Facturatie en Debiteurenbeheer Attributes

Order to Cash - Facturatie en Debiteurenbeheer Activiteiten

Extractie Guides

Microsoft Dynamics 365 Data Entity Export

Stappen

Configuratie

a Voorbeeldquery config

Python Script met Dynamics 365 OData Web API

Stappen

Configuratie

a Voorbeeldquery python

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Beëindig Facturatievertragingen: Optimaliseer Van Order tot Cash & Facturering Vandaag