> Continu verbeteren van processen > Kredietbeheer en incasso > Microsoft Dynamics 365 > Datatemplate

Datatemplate voor kredietbeheer en incasso

Microsoft Dynamics 365

Attributen voor kredietbeheer en incasso(19) Activiteiten voor kredietbeheer en incasso(12) Extractiegidsen(2)

Datatemplate voor kredietbeheer en incasso

Deze template helpt je de data te verzamelen die nodig is om het proces voor kredietbeheer en incasso te analyseren. Je vindt er de belangrijkste datavelden, de activiteiten die je kunt volgen en praktische uitleg over data-extractie. Gebruik deze bron om je data voor te bereiden en sneller met process mining aan de slag te gaan.

Aanbevolen attributen voor een volledige analyse
Belangrijke procesactiviteiten om te volgen voor een nauwkeurige analyse
Praktische uitleg over data-extractie uit je systeem

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

Template downloaden

Attributen voor kredietbeheer en incasso

Dit zijn de aanbevolen datavelden voor je event log, zodat je het proces voor kredietbeheer en incasso volledig kunt analyseren.

3 Verplicht 8 Aanbevolen 8 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de specifieke gebeurtenis of taak die op een bepaald moment in de levenscyclus van de factuur plaatsvond.
Beschrijving De activiteitsnaam beschrijft een specifieke stap of gebeurtenis in het krediet- en incassoproces, zoals 'Factuur gegenereerd', 'Aanmaningsbrief verzonden' of 'Betaling ontvangen'. Dit attribuut is essentieel voor process mining, omdat het de knooppunten op de proceskaart bepaalt. Uit de volgorde en frequentie van activiteiten blijkt hoe het proces werkelijk verloopt. Zo kun je herstelwerk, inefficiënties en procesroutes die niet aan de regels voldoen herkennen. De activiteitsnaam vormt de basis voor alle visualisaties van processtromen en wordt gebruikt om doorlooptijden tussen verschillende procesfasen te berekenen. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart en maakt het mogelijk de levenscyclus van de factuur te visualiseren en analyseren. Waar vind je dit? Dit attribuut wordt meestal afgeleid door specifieke systeemgebeurtenissen, statuswijzigingen of aanmaakdatums uit verschillende tabellen, zoals 'CustInvoiceJour', 'CustTrans', 'CustCollectionLetterJour' en 'CustPaymPromise', te koppelen aan gestandaardiseerde activiteitsnamen. Voorbeelden Factuur geboekt en verzondenAanmaningsbrief aangemaaktGeschil geregistreerdBetaling ontvangen
	Factuurnummer InvoiceNumber	De unieke identificatiecode van elke klantfactuur. Deze code is de belangrijkste case-ID voor het kredietbeheerproces.
Beschrijving Het factuurnummer is een belangrijk attribuut waarmee elke financiële transactie met een klant uniek wordt geïdentificeerd. Het verbindt alle bijbehorende activiteiten, van het aanmaken en boeken van de factuur tot het innen van de betaling en de uiteindelijke vereffening. Bij process mining gebruik je dit nummer om het volledige verloop van elke factuur te reconstrueren en de levenscyclus ervan in detail te analyseren. Door elke factuur als een aparte case te volgen, kunnen organisaties veelvoorkomende procesroutes, bottlenecks en afwijkingen van de standaardprocedure herkennen. Het nummer vormt de basis voor het berekenen van belangrijke metrieken, zoals Days Sales Outstanding, en voor het analyseren van procesvarianten. Waarom dit belangrijk is Dit is de belangrijkste Case-ID die alle procesgebeurtenissen met elkaar verbindt. Zo kun je de volledige levenscyclus van factuur tot betaling reconstrueren en analyseren. Waar vind je dit? Dit is meestal het veld 'Invoice' in de tabel 'CustInvoiceJour' van Microsoft Dynamics 365 Finance. Voorbeelden INV-0012345CIV-2023-8876SI-9510034
	Tijdstip van gebeurtenis EventTime	De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving Het tijdstip van de gebeurtenis is de exacte datum en tijd waarop een activiteit in het systeem is vastgelegd. Dit vormt de basis van process mining: de chronologische volgorde is nodig om de processtroom op te bouwen en alle tijdsgebonden metrieken te berekenen. Dit attribuut is essentieel voor het analyseren van doorlooptijden, het herkennen van bottlenecks en het bewaken van SLA’s. Zo gebruik je het tijdsverschil tussen de gebeurtenissen 'Factuur gegenereerd' en 'Betaling ontvangen' om Days Sales Outstanding (DSO) te berekenen, een belangrijke bedrijfs-KPI. Zonder nauwkeurige timestamps kun je prestaties niet analyseren en bottlenecks niet herkennen. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen op volgorde te zetten, de proceskaart te ontdekken en prestatiemetrieken zoals doorlooptijden en tijdsduur te berekenen. Waar vind je dit? Dit attribuut komt uit verschillende datum- en tijdvelden in D365-tabellen, zoals 'CreatedDateTime' in 'CustInvoiceJour' of 'TransDate' in 'CustTrans', afhankelijk van de activiteit. Voorbeelden 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Aanmaningsniveau DunningLevel	Geeft de huidige fase of ernst aan van het aanmanings- en incassoproces voor een achterstallige factuur.
Beschrijving Het aanmaningsniveau geeft de stap in een gestructureerde aanmaningsprocedure aan, bijvoorbeeld 'Niveau 1: Vriendelijke herinnering', 'Niveau 2: Formele aanmaning' of 'Niveau 3: Laatste waarschuwing'. Dit attribuut bijhouden is essentieel om de effectiviteit van de incassostrategie te beoordelen. Het dashboard 'Effectiviteit aanmaningsstrategie' gebruikt dit attribuut om te laten zien welk percentage van de facturen na elk niveau wordt betaald. Zo kunnen bedrijven hun aanmaningsworkflows verbeteren en betalingen effectiever innen, met behoud van de klantrelatie. Waarom dit belangrijk is Dit is belangrijk om de effectiviteit van de aanmaningsstrategie te meten en te begrijpen in welke fase klanten het vaakst betalen. Waar vind je dit? Deze informatie staat waarschijnlijk in tabellen voor incasso en aanmaningsbrieven, zoals 'CustCollectionLetterJour'. Voorbeelden 123 - LaatsteJuridische stappen
	Dagen achterstallig DaysOverdue	Het aantal dagen dat een factuur na de vervaldatum nog onbetaald is.
Beschrijving Dagen achterstallig is een berekende metriek die meet hoeveel tijd is verstreken sinds de vervaldatum van een onbetaalde factuur. Je berekent dit door de vervaldatum van de huidige datum af te trekken. Dit is een belangrijke prestatie-indicator voor het incassoteam, omdat die helpt bepalen welke facturen prioriteit hebben. De metriek staat centraal in het dashboard 'Achterstallige facturen per segment' en is belangrijk om de stand van de debiteuren en de effectiviteit van incassoactiviteiten te beoordelen. Waarom dit belangrijk is Dit is een belangrijke operationele metriek om incassoactiviteiten te prioriteren en de ernst van betalingsvertragingen te meten. Waar vind je dit? Dit is een berekend veld. De logica is: ALS de factuur onbetaald is, DAN (Today() - PaymentDueDate), ANDERS 0. Voorbeelden 1532910
	Factuurbedrag InvoiceAmount	De totale geldwaarde van de factuur.
Beschrijving Het factuurbedrag is de totale financiële waarde van de gefactureerde goederen of diensten. Dit is een belangrijk attribuut voor financiële analyses van het proces. Je kunt cases op bedrag indelen om te zien of facturen met een hoge waarde een ander proces volgen of langer vertraging oplopen. Dit attribuut is essentieel voor de dashboards 'Afboekingen van oninbare facturen' en 'Analyse kredietlimietbeheer'. Zo kun je de financiële impact bepalen en risico’s beoordelen. Waarom dit belangrijk is Maakt analyses van de financiële impact mogelijk, helpt facturen met een hoge waarde prioriteit te geven en laat zien hoe het factuurbedrag het procesverloop beïnvloedt. Waar vind je dit? Waarschijnlijk het veld 'InvoiceAmount' in de tabel 'CustInvoiceJour'. Voorbeelden 1500.7525000.00549.99
	Factuurstatus InvoiceStatus	De huidige status van de factuur in de levenscyclus.
Beschrijving De factuurstatus geeft een momentopname van de positie van een factuur in het proces, bijvoorbeeld 'Open', 'Betaald', 'Betwist' of 'Afgeboekt'. Het activiteitenlogboek bevat de volledige geschiedenis, maar de huidige status is een handig attribuut op caseniveau voor filters en rapportages op hoofdlijnen. Analisten kunnen de data ermee snel indelen, bijvoorbeeld om alleen openstaande achterstallige facturen te bekijken of de kenmerken van alle afgeboekte facturen te analyseren. Zo zie je eenvoudig wat de huidige status van de debiteuren is. Waarom dit belangrijk is Maakt het eenvoudig om facturen op basis van hun huidige status te filteren en analyseren, bijvoorbeeld om alle openstaande of betwiste cases te bekijken. Waar vind je dit? Afgeleid van de vereffeningsstatus van transacties in de tabel 'CustTrans'. Een open transactie is onbetaald; een gesloten transactie is vereffend. Voorbeelden OpenBetaaldGedeeltelijk betaaldAfgeboekt
	Incassomedewerker toegewezen CollectorAssigned	De naam van de incassomedewerker of het teamlid dat verantwoordelijk is voor het beheer van de achterstallige factuur.
Beschrijving Dit attribuut geeft aan welke medewerker verantwoordelijk is voor de incassoactiviteiten van een specifieke factuur. Het is belangrijk voor analyses van prestaties en werkdruk. Door de proceskaart of dashboards op incassomedewerker te filteren, kunnen managers de productiviteit beoordelen, incassostrategieën vergelijken en bepalen waar coaching nodig is. Dit attribuut is een belangrijke dimensie voor de dashboards 'Productiviteit van het incassoteam' en 'Doorlooptijd geschiloplossing', omdat het helpt procesresultaten aan specifieke medewerkers of teams toe te schrijven. Waarom dit belangrijk is Maakt prestatieanalyses van het incassoteam mogelijk, helpt de werkdruk te verdelen en laat zien welke aanpak werkt door de effectiviteit van incassomedewerkers te vergelijken. Waar vind je dit? Raadpleeg de documentatie van Microsoft Dynamics 365. Deze informatie kan afkomstig zijn uit een module voor debiteurenbeheer of uit velden voor gebruikersverantwoordelijkheid op klant- of transactierecords. Voorbeelden John SmithEmily JonesIncassoteam A
	Klantnaam CustomerName	De officiële naam van de klant aan wie de factuur is uitgereikt.
Beschrijving De klantnaam geeft aan welke klant bij een factuur hoort. Dit attribuut is een belangrijke dimensie voor filters en segmentatie. Door het proces per klant te analyseren, kun je klanten herkennen die steeds te laat betalen, geschillen melden of veel incassowerk vragen. Het is een belangrijk attribuut voor het dashboard 'Doorlooptijd geschiloplossing' en voor analyses van specifieke klantrekeningen. Waarom dit belangrijk is Maakt procesanalyses per klant mogelijk, zodat je patronen kunt herkennen en relaties met belangrijke of problematische klanten kunt beheren. Waar vind je dit? Deze informatie wordt meestal opgehaald uit 'CustTable', op basis van het klantrekeningnummer in 'CustInvoiceJour'. Voorbeelden Contoso Ltd.Adventure WorksFabrikam Inc.
	Klantsegment CustomerSegment	Een indeling van klanten, bijvoorbeeld op basis van omvang, branche of strategisch belang.
Beschrijving Klantsegment is een categorisch attribuut waarmee je klanten indeelt in betekenisvolle groepen, zoals 'Strategische klanten', 'mkb' of 'Overheid'. Deze segmentatie is belangrijk voor strategische analyses. Zo kun je vragen beantwoorden als: 'Hebben strategische klanten een lagere DSO?' of 'Worden facturen in bepaalde branches vaker afgeboekt?'. Het attribuut wordt rechtstreeks gebruikt in de dashboards 'Trend Days Sales Outstanding', 'Afboekingen van oninbare facturen' en 'Achterstallige facturen per segment'. Zo krijg je inzicht op groepsniveau, niet alleen per klant. Waarom dit belangrijk is Maakt analyses van klantgroepen mogelijk, zodat je strategische trends kunt herkennen en de incassostrategie per segment kunt aanpassen. Waar vind je dit? Dit is vaak een aangepast veld of wordt afgeleid van attributen in 'CustTable' (de klantstamgegevenstabel). Voorbeelden EnterpriseMiddelgrote bedrijvenPublieke sectorPartner
	Vervaldatum betaling PaymentDueDate	De datum waarop de factuur volgens de overeenkomst betaald moet zijn.
Beschrijving De vervaldatum van de betaling is een belangrijke datum die wordt bepaald door de met de klant afgesproken betalingsvoorwaarden. Deze datum vormt de basis om vast te stellen of een factuur achterstallig is. De vervaldatum is ook het startsein voor incassoactiviteiten, zoals het versturen van herinneringen of het starten van een formele aanmaningsprocedure. Bij process mining gebruik je deze datum om de metriek 'Dagen achterstallig' te berekenen en te controleren of het aanmaningsbeleid wordt nageleefd. Je kunt bijvoorbeeld nagaan of een herinnering binnen X dagen na de vervaldatum is verzonden. Waarom dit belangrijk is Deze datum is de maatstaf voor tijdige betalingen en vormt het startsein voor alle activiteiten rond achterstallige betalingen en incasso. Waar vind je dit? Meestal te vinden in het veld 'DueDate' van de tabellen 'CustTrans' of 'CustInvoiceJour'. Voorbeelden 2023-02-142023-03-312023-04-30
	Bronsysteem SourceSystem	Geeft aan uit welk systeem de data afkomstig is.
Beschrijving Dit attribuut geeft aan in welke brontoepassing de gebeurtenisdata is vastgelegd. In dit geval is dat 'Microsoft Dynamics 365'. Bij een analyse van één systeem lijkt dit misschien een vast gegeven, maar het is belangrijk voor datagovernance, probleemoplossing en toekomstige integraties. Als je ook data uit andere systemen opneemt, zoals een apart CRM-systeem of een incassoplatform, helpt dit veld om de bronnen van elkaar te onderscheiden en het volledige proces over systemen heen te begrijpen. Waarom dit belangrijk is Maakt de herkomst van data inzichtelijk en is essentieel voor het bewaken van de datakwaliteit en het analyseren van meerdere geïntegreerde systemen. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie wordt toegevoegd om de herkomst van de records aan te geven. Voorbeelden Microsoft Dynamics 365D365 F&O
	Doorlooptijd geschiloplossing DisputeResolutionTime	De tijd die nodig is om een klantgeschil op te lossen, gerekend vanaf de registratie ervan.
Beschrijving De doorlooptijd van geschiloplossing meet hoe efficiënt het proces voor geschillenafhandeling verloopt. Je berekent deze doorlooptijd tussen de activiteiten 'Geschil geregistreerd' en 'Geschil opgelost'. Een lange doorlooptijd kan de betaling vertragen en de klanttevredenheid verlagen. Door deze metriek uit te splitsen naar incassomedewerker of geschilreden, kun je bottlenecks en verbeterpunten in de workflow voor geschillenbeheer herkennen. Waarom dit belangrijk is Meet de efficiëntie van het proces voor geschillenafhandeling, een veelvoorkomende oorzaak van aanzienlijke betalingsvertragingen. Waar vind je dit? Berekend als de tijd tussen de timestamps van de activiteiten 'Geschil geregistreerd' en 'Geschil opgelost'. Voorbeelden 7.215.83.5
	Is betwist IsDisputed	Een booleaanse vlag die aangeeft of een factuur ooit is betwist.
Beschrijving Dit is een berekende vlag die op true wordt gezet als een factuurcase de activiteit 'Geschil geregistreerd' bevat. Zo kunnen gebruikers de processtromen van betwiste en niet-betwiste facturen eenvoudig filteren en vergelijken. Je kunt bijvoorbeeld de gemiddelde DSO van betwiste facturen vergelijken met die van niet-betwiste facturen om de invloed van geschillen op de cashflow te bepalen. Dit attribuut is handig voor dashboards op hoofdlijnen en vergelijkende analyses. Waarom dit belangrijk is Vereenvoudigt analyses en filters, zodat je betwiste en niet-betwiste facturen eenvoudig met elkaar kunt vergelijken. Waar vind je dit? Dit is een berekend veld. De logica is: ALS de case de activiteit 'Geschil geregistreerd' bevat, DAN true, ANDERS false. Voorbeelden truefalse
	Kredietlimiet CreditLimit	Het maximale kredietbedrag dat voor de klant is goedgekeurd.
Beschrijving De kredietlimiet is het totale bedrag aan schulden dat een klant mag opbouwen. Dit attribuut is belangrijk voor risicobeheer. Het dashboard 'Analyse kredietlimietbeheer' vergelijkt deze waarde met de factuurbedragen van achterstallige of afgeboekte rekeningen. Zo kun je beoordelen of kredietlimieten passend zijn vastgesteld en worden gehandhaafd, en of klanten die niet betalen onlangs een hogere limiet hebben gekregen. Dat kan wijzen op zwakke plekken in het kredietgoedkeuringsproces. Waarom dit belangrijk is Dit attribuut is essentieel voor risicobeoordeling en helpt analyseren of afboekingen verband houden met slecht beheerde of ontoereikende kredietlimieten. Waar vind je dit? Deze waarde staat meestal op de klantstamgegevens in 'CustTable'. Voorbeelden 10000.0050000.000.00
	Laatste data-update LastDataUpdate	De timestamp van de laatste data-update of -verversing.
Beschrijving Dit attribuut geeft aan wanneer de dataset voor het laatst vanuit het bronsysteem is bijgewerkt. Voor gebruikers van de process mining-analyse is dit belangrijke metadata, omdat het laat zien hoe actueel de data is. Als je weet tot welk tijdstip de data is bijgewerkt, kunnen analisten hun bevindingen goed plaatsen en de reikwijdte ervan begrijpen. Meestal wordt deze waarde tijdens de data-invoer aan de volledige dataset toegevoegd. Waarom dit belangrijk is Laat gebruikers zien hoe actueel de data is. Zo is duidelijk op welke periode de analyses betrekking hebben en voorkom je beslissingen op basis van verouderde informatie. Waar vind je dit? Deze waarde wordt tijdens de uitvoering door de ETL- of datapijplijn gegenereerd en aan de dataset toegevoegd. Voorbeelden 2023-04-01T02:00:00Z2023-04-02T02:00:00Z
	Land Country	Het land van het factuuradres van de klant.
Beschrijving Dit attribuut geeft het land aan dat bij de klantrekening hoort. Het is een veelgebruikte dimensie voor geografische analyses. Door proces-KPI’s zoals DSO of het afboekingspercentage per land uit te splitsen, kun je regionale verschillen in betaalgedrag, incassoresultaten of economische omstandigheden herkennen. Dat kan leiden tot incassostrategieën per regio of andere betalingsvoorwaarden voor bepaalde gebieden. Waarom dit belangrijk is Maakt geografische analyses mogelijk om regionale trends in betaalgedrag en de prestaties van het incassoproces te herkennen. Waar vind je dit? Dit wordt afgeleid door de klantstamgegevens ('CustTable') te koppelen aan het primaire adres, vaak in 'LogisticsPostalAddress'. Voorbeelden USADEUGBRCAN
	Reden van geschil DisputeReason	De reden die de klant opgeeft om een factuur te betwisten.
Beschrijving Wanneer een klant een factuur betwist, geeft die meestal een reden op, zoals 'Onjuiste prijs', 'Beschadigde goederen' of 'Dubbele facturering'. Dit attribuut legt die reden vast. Analyse van geschilredenen is belangrijk voor oorzaakanalyse. Zo kun je terugkerende problemen in het order-to-cash-proces herkennen, bijvoorbeeld bij verkoop, verzending of facturering. Geschillen bij de bron voorkomen is een belangrijk resultaat van deze analyse. Dat heeft rechtstreeks invloed op DSO, omdat betalingsvertragingen worden voorkomen. Waarom dit belangrijk is Levert belangrijke data voor oorzaakanalyse van betalingsvertragingen. Zo kun je problemen eerder in het proces herkennen en oplossen die tot factuurgeschillen leiden. Waar vind je dit? Raadpleeg de documentatie van Microsoft Dynamics 365. Deze informatie maakt deel uit van de functionaliteit voor geschillenbeheer of casemanagement. Voorbeelden PrijsfoutTe weinig geleverdProduct niet ontvangenDienst wijkt af van beschrijving
	Valutacode CurrencyCode	De valuta van de factuur, bijvoorbeeld USD of EUR.
Beschrijving De valutacode geeft aan in welke valuta het factuurbedrag is uitgedrukt. Dit is belangrijke context, vooral voor internationale organisaties. De code is nodig om geldbedragen goed te interpreteren en kan helpen analyseren of betalingscycli of problemen samenhangen met bepaalde valuta. Dat kan bijvoorbeeld komen door wisselkoerskwesties of de verwerking van internationale betalingen. Waarom dit belangrijk is Geeft context bij alle geldbedragen en maakt analyses mogelijk van processen met meerdere valuta. Waar vind je dit? Meestal te vinden in het veld 'CurrencyCode' van de tabel 'CustInvoiceJour'. Voorbeelden USDEURGBPCAD

Verplicht Aanbevolen Optioneel

Activiteiten voor kredietbeheer en incasso

Dit zijn de belangrijkste processtappen en mijlpalen voor je event log. Zo kun je de workflow voor kredietbeheer en incasso nauwkeurig analyseren.

9 Aanbevolen 3 Optioneel

	Activiteit	Beschrijving
	Aanmaningsbrief aangemaakt	Geeft aan dat er een formele aanmanings- of incassobrief is aangemaakt voor de achterstallige factuur. Dit wordt vastgelegd wanneer het periodieke aanmaningsproces in Dynamics 365 wordt uitgevoerd en briefrecords voor relevante facturen aanmaakt.
Waarom dit belangrijk is Hiermee volg je wanneer formele incassoacties beginnen en hoe vaak ze plaatsvinden. Dit is belangrijk om de effectiviteit van aanmaningen en de naleving van intern incassobeleid te meten. Waar vind je dit? Er wordt een expliciet record aangemaakt in de tabel Dunning History (CustCollectionLetterJour). De aanmaakdatum van het aanmaningsjournaal is de timestamp. Vastleggen Haal aanmaakgebeurtenissen op uit de tabel CustCollectionLetterJour en koppel ze aan de factuur. Gebeurtenistype explicit
	Betaling geboekt	Geeft aan dat de betaling van de klant officieel in het grootboek is geboekt en is toegewezen om een factuur te vereffenen. Dit wordt afgeleid van de boekingsdatum van het betalingsdagboek van de klant.
Waarom dit belangrijk is Hiermee is het betalingsdeel van het proces afgerond. De tijd tussen ontvangst en boeking van de betaling, de vertraging bij de verwerking van ontvangen betalingen, is een belangrijke efficiëntiemaatstaf voor de financiële afdeling. Waar vind je dit? Afgeleid van de boekingstimestamp van het betalingsdagboek van de klant (LedgerJournalTrans). Hiermee wordt bevestigd dat de betaling volledig in het grootboek is verwerkt. Vastleggen Gebruik de boekingsdatum van het geboekte betalingsdagboek van de klant. Gebeurtenistype explicit
	Betaling ontvangen	Geeft aan dat een betaling van een klant is ontvangen en in het systeem is ingevoerd, meestal via een betalingsdagboek. Deze gebeurtenis vindt plaats vóór de definitieve boeking en toewijzing van het bedrag aan de betreffende factuur.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het berekenen van Days Sales Outstanding en het begrijpen van de cashflow. De tijd tussen deze gebeurtenis en Betaling geboekt laat zien waar vertraging ontstaat bij het toewijzen van betalingen. Waar vind je dit? Een expliciete gebeurtenis, afgeleid van de aanmaakdatum van een regel in het betalingsdagboek van een klant (LedgerJournalTrans), voordat deze wordt geboekt. De gebeurtenis geeft aan op welke datum de betaling als ontvangen is geregistreerd. Vastleggen Gebruik de transactiedatum van de regels in het betalingsdagboek van de klant. Gebeurtenistype explicit
	Factuur aangemaakt	Dit markeert het aanmaken van een verkoopfactuurrecord in het systeem, voordat de factuur officieel wordt geboekt. Deze activiteit wordt meestal als expliciete gebeurtenis vastgelegd wanneer een gebruiker een verkooporder afrondt en de bijbehorende factuur aanmaakt.
Waarom dit belangrijk is Dit is de primaire Start Event voor de levenscyclus van een factuur. De tijd tussen dit moment en de betaling is belangrijk voor het meten van Days Sales Outstanding (DSO). Waar vind je dit? Vastgelegd in de tabel Sales Invoice Header (SalesInvoiceHeader) of Sales Table (SalesTable) wanneer de factuur wordt aangemaakt. De aanmaaktimestamp van het record geldt als tijdstip van de gebeurtenis. Vastleggen Leg de aanmaaktimestamp van het verkoopfactuurrecord vast. Gebeurtenistype explicit
	Factuur afgeboekt	De factuur is oninbaar verklaard en formeel afgeboekt als oninbare vordering. Dit is een expliciete handeling van een bevoegde gebruiker, waarmee de vordering wordt afgeboekt en het verlies wordt geboekt.
Waarom dit belangrijk is Dit is het belangrijkste mislukte eindpunt van het proces. Door afboekingen bij te houden, krijg je zicht op kredietrisico, mislukte incasso’s en financiële verliezen. Waar vind je dit? Afgeleid van een specifieke transactie in het grootboekdagboek voor het afboeken van oninbare vorderingen, gekoppeld aan de oorspronkelijke factuur. De boekingsdatum van het afboekingsdagboek geldt als timestamp. Vastleggen Zoek naar journaalposten met een specifiek boekingsprofiel voor afboekingen die naar de factuur verwijzen. Gebeurtenistype explicit
	Factuur geboekt en verzonden	Dit staat voor de officiële registratie van de factuur in het grootboek, waardoor deze als openstaande vordering wordt opgenomen. Dit gebeurt meestal wanneer de factuur naar de klant wordt verzonden en wordt vastgelegd zodra de boekingsroutine in Dynamics 365 is afgerond.
Waarom dit belangrijk is Dit is een belangrijk moment: vanaf hier gaan de betalingstermijn en ouderdom van de factuur lopen. Vertraging tussen het aanmaken en boeken kan wijzen op inefficiënties in het facturatieproces. Waar vind je dit? Af te leiden uit de boekingsdatum in het Customer Invoice Journal (CustInvoiceJour) of een statuswijziging naar ‘Posted’. De boektimestamp is het belangrijkste datapunt. Vastleggen Gebruik de boektimestamp uit het Customer Invoice Journal (CustInvoiceJour). Gebeurtenistype inferred
	Factuur vereffend	De factuur is volledig betaald en het openstaande saldo is nul. Daarmee is het proces succesvol afgerond. Deze status wordt afgeleid wanneer de som van de toegewezen betalingen gelijk is aan het totale factuurbedrag.
Waarom dit belangrijk is Dit is het belangrijkste succesvolle eindpunt van het proces van krediet tot betaling. Door de routes naar dit punt te analyseren, zie je welke werkwijzen goed werken en welke procesvarianten efficiënt zijn. Waar vind je dit? Afgeleid van de vereffeningsdatum in de vereffeningstabel voor klanten (CustSettlement). Dit gebeurt wanneer de velden 'AmountCur' en 'SettleAmountCur' voor de factuur in CustTrans samen nul zijn. Vastleggen Bepaal de meest recente vereffeningsdatum van de factuurtransactie waarop het saldo nul wordt. Gebeurtenistype inferred
	Geschil geregistreerd	Geeft aan dat de klant de factuur formeel heeft betwist en dat de status is bijgewerkt. Dit wordt meestal vastgelegd wanneer een gebruiker de factuurstatus in de module voor debiteurenbeheer wijzigt in 'Betwist'.
Waarom dit belangrijk is Dit is het startpunt van het geschiloplossingsproces. Door dit bij te houden, kun je meten hoe vaak er geschillen ontstaan en hoelang het duurt om ze op te lossen. Dat heeft invloed op de klanttevredenheid en de cashflow. Waar vind je dit? Afgeleid uit een statuswijziging van de klanttransactie (CustTrans) of een gerelateerde tabel voor geschillenbeheer (smmCaseDetail). Hiervoor is een logboek met timestamps van statuswijzigingen nodig. Vastleggen Bepaal wanneer het veld voor de geschilstatus van een factuurtransactie wordt ingevuld of gewijzigd in 'Betwist'. Gebeurtenistype inferred
	Vervaldatum van betaling verstreken	Een berekende gebeurtenis die plaatsvindt wanneer de huidige datum na de vervaldatum van de factuur valt. Deze activiteit komt niet overeen met een directe handeling van een gebruiker, maar wordt afgeleid door de systeemdatum te vergelijken met het veld voor de vervaldatum van de factuur.
Waarom dit belangrijk is Deze gebeurtenis vormt de aanleiding voor alle incassoactiviteiten. Je kunt hiermee het aantal achterstallige facturen en de tijdigheid van aanmaningsacties analyseren. Dat ondersteunt KPI’s zoals naleving van het aanmaningsbeleid. Waar vind je dit? Berekend door de huidige timestamp te vergelijken met het veld ‘DueDate’ in de tabel Customer Transactions (CustTrans). De gebeurtenistimestamp is de DueDate zelf. Vastleggen Maak een gebeurtenis aan wanneer ‘NOW()’ groter is dan de DueDate van de factuur. Gebeurtenistype calculated
	Betalingsafspraak aangemaakt	Een klant heeft toegezegd op een specifieke toekomstige datum te betalen en deze afspraak is in het systeem vastgelegd. De gebeurtenis wordt expliciet geregistreerd wanneer een incassomedewerker een betalingsafspraak invoert in de incassomodule.
Waarom dit belangrijk is Hiermee volg je informele betalingsafspraken en hoe vaak klanten die nakomen. Door afspraken met daadwerkelijke betalingen te vergelijken, kun je de cashflow voorspellen en de betrouwbaarheid van klanten beoordelen. Waar vind je dit? Waarschijnlijk vastgelegd in tabellen voor de incassowerkruimte of het casemanagement, specifiek voor de functie voor betalingsafspraken. De aanmaakdatum van het afspraakrecord is het tijdstip van de gebeurtenis. Vastleggen Haal aanmaakgebeurtenissen op uit een detailtabel van een betalingsbelofte of incassodossier. Gebeurtenistype explicit
	Geschil opgelost	Markeert het einde van het geschilproces, wanneer een oplossing is bereikt en vastgelegd. Deze gebeurtenis wordt geregistreerd wanneer een gebruiker de geschilstatus van een factuur wijzigt in 'Opgelost' of het bijbehorende geschillendossier sluit.
Waarom dit belangrijk is Met deze activiteit eindigt het deelproces voor geschillen. De tijd tussen de registratie en oplossing van een geschil is een belangrijke KPI om de efficiëntie van het oplossingsteam te meten. Waar vind je dit? Afgeleid uit een statuswijziging van de klanttransactie (CustTrans) of uit het sluiten van het bijbehorende geschillendossier (smmCaseDetail). De timestamp van de statuswijziging is het tijdstip van de gebeurtenis. Vastleggen Bepaal wanneer het veld voor de geschilstatus van een factuur wordt leeggemaakt of gewijzigd in 'Opgelost'. Gebeurtenistype inferred
	Incassoactiviteit vastgelegd	Dit staat voor een handmatige incassoactie, zoals een telefoongesprek of e-mail, die bij de klant of factuur wordt vastgelegd. Dit gebeurt wanneer een medewerker de functie Activities in de incassowerkruimte gebruikt om contactmomenten te registreren.
Waarom dit belangrijk is Dit geeft inzicht in het handmatige werk van het incassoteam. Door deze activiteiten te vergelijken met geslaagde betalingen, kun je de productiviteit van het team en de effectiviteit van verschillende contactmethoden meten. Waar vind je dit? Vastgelegd in Activities (smmActivities) of gerelateerde casemanagementtabellen die aan de klantrekening zijn gekoppeld. Koppel de activiteit indien mogelijk aan een specifieke factuur. Vastleggen Leg aanmaak van Activity-records vast waarbij het type ‘Telefoon’ of ‘E-mail’ is en de activiteit betrekking heeft op incasso. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Microsoft Dynamics 365

Stappen

Controleer de vereisten: Controleer of je organisatie Microsoft Dynamics 365 Finance gebruikt en of Bring Your Own Database (BYOD) is ingesteld om data-entiteiten naar een Azure SQL Database te exporteren. Je hebt leesgegevens nodig om verbinding te maken met deze Azure SQL Database.
Controleer de data-entiteiten: Controleer of de benodigde data-entiteiten vanuit Dynamics 365 naar BYOD worden geëxporteerd. Voor dit proces zijn onder andere deze entiteiten nodig: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment en CustDispute. Ontbreekt er een entiteit, stel deze dan in voor export in de Dynamics 365 Data Management-werkruimte.
Maak verbinding met de BYOD-database: Gebruik een SQL-client, zoals SQL Server Management Studio (SSMS) of Azure Data Studio, om verbinding te maken met de Azure SQL Database die als BYOD-bestemming dient.
Bereid de SQL-query voor: Kopieer de volledige T-SQL-query uit het onderdeel query van dit document naar je SQL-client. De query verzamelt alle vereiste activiteiten en attributen in één event log.
Stel de queryparameters in: Zoek de tijdelijke waarden bovenaan de query. Vervang '{CompanyCode}' door de ID van de juridische entiteit in Dynamics 365 die je wilt gebruiken, bijvoorbeeld 'USMF'. Vervang '{StartDate}' en '{EndDate}' door het gewenste datumbereik voor de analyse, in de notatie 'YYYY-MM-DD'.
Voer de query uit: Voer de aangepaste query uit op de BYOD-database. De uitvoeringstijd hangt af van de hoeveelheid data in het gekozen datumbereik.
Controleer de resultaten: Na afloop toont het resultatenvenster het event log. Elke rij staat voor een activiteit in de levenscyclus van een factuur voor kredietbeheer en incasso. Controleer of de data volledig en correct is.
Exporteer het event log: Exporteer de queryresultaten naar een CSV-bestand. De meeste SQL-clients hebben hiervoor een ingebouwde functie. Klik met de rechtermuisknop op het resultatenraster en zoek naar een optie zoals 'Save Results As' of 'Export'.
Maak het bestand klaar om te uploaden: Controleer of het geëxporteerde CSV-bestand UTF-8-codering heeft en of de kolomkoppen overeenkomen met de vereiste attributen: InvoiceNumber, ActivityName, EventTime en eventuele aanbevolen attributen die je hebt opgenomen. Je kunt het bestand nu uploaden naar ProcessMind.

Configuratie

Vereisten: Toegang tot een Microsoft Dynamics 365 for Finance-instantie waarop Bring Your Own Database (BYOD) is ingesteld en actief is. Je hebt leesrechten nodig voor de Azure SQL Database die als bestemming dient.
Data-entiteiten: Voor de extractie moeten verschillende standaarddata-entiteiten naar BYOD worden geëxporteerd. Zorg dat ten minste CustInvoiceJour, CustTrans, CustTable en CustSettlement in de BYOD-exporttaak zijn opgenomen. Voor specifieke activiteiten zijn extra entiteiten nodig, zoals CustCollectionLetterJour.
Datumbereik: Filter de query op een specifiek datumbereik om de prestaties op peil te houden. Voor een eerste analyse raden we 3 tot 6 maanden aan. De meegeleverde query gebruikt hiervoor de tijdelijke waarden '{StartDate}' en '{EndDate}'.
Bedrijfsfilter: Filter de query op één juridische entiteit (Company Code), zodat de data consistent is. Geef met de tijdelijke waarde '{CompanyCode}' aan welk bedrijf je analyseert.
Aandachtspunten voor prestaties: Bij grote datasets die meerdere jaren of bedrijven beslaan, kan de query lang duren. Voer de query zo nodig uit op een rustig moment of voeg filters toe om de hoeveelheid data te beperken. Zorg dat er geschikte indexen zijn op datum- en sleutelkolommen in de BYOD-tabellen.

Voorbeeldquery sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

Stappen

Controleer de vereisten en stel de omgeving in: Zorg dat Python 3.8 of hoger is geïnstalleerd. Installeer de benodigde bibliotheken met pip: pip install pandas requests msal. Je hebt ook inloggegevens nodig voor een service principal met toegang tot de Dynamics 365-omgeving.
Registreer een applicatie in Azure AD: Ga naar de Azure Active Directory-portal. Registreer een nieuwe applicatie om een Client ID en Tenant ID te krijgen. Maak onder 'Certificates & secrets' een client secret aan voor de applicatie. Bewaar de Client ID, Tenant ID en Client Secret veilig.
Verleen API-machtigingen: Voeg in Azure AD onder 'API permissions' bij de geregistreerde applicatie een machtiging toe. Selecteer 'Dynamics ERP' of een vergelijkbare optie voor Dynamics 365 en verleen de gedelegeerde machtiging 'user_impersonation'. Verleen namens je organisatie toestemming als beheerder.
Maak een Dynamics 365-gebruiker aan: Maak een aparte applicatiegebruiker aan in Dynamics 365 Finance and Operations en koppel deze aan de Client ID van je Azure AD-applicatie. Wijs de gebruiker een beveiligingsrol toe met leesrechten voor alle vereiste data-entiteiten, zoals CustInvoiceJour, CustCollectionLetterJour, CustSettlements en smmActivities.
Stel het Python-script in: Kopieer het meegeleverde Python-script naar een bestand, bijvoorbeeld extract_d365_collections.py. Vul bovenaan het script de tijdelijke waarden in voor de URL van je D365-omgeving, Tenant ID, Client ID, Client Secret en het standaardbedrijf (dataAreaId).
Stel de extractieparameters in: Pas de variabelen start_date en end_date in het script aan om de periode voor de data-extractie te bepalen. Voor een eerste analyse raden we 3 tot 6 maanden aan.
Voer het script uit: Voer in je terminal de opdracht python extract_d365_collections.py uit. Het script meldt zich aan, bevraagt de OData-eindpunten voor elk van de 12 activiteiten en verwerkt automatisch de API-paginering.
Haal de data per activiteit op: Het script doet achtereenvolgens API-aanroepen om data op te halen over het aanmaken en boeken van facturen, aanmaningen, betalingen en andere belangrijke gebeurtenissen. Elke query richt zich op een specifieke data-entiteit en selecteert alleen de benodigde velden om de prestaties te verbeteren.
Zet de data om en voeg deze samen: Het script gebruikt de pandas-bibliotheek om de JSON-reactie van elke API-aanroep te verwerken. Het zet de data om naar een gestructureerde tabel, maakt de kolomnamen consistent en voegt de data van alle activiteiten samen tot één event log.
Bereken afgeleide gebeurtenissen: De activiteit 'Payment Due Date Passed' staat niet als aparte gebeurtenis in het systeem. Het script berekent deze door alle facturen die binnen het opgegeven datumbereik achterstallig zijn te doorlopen en voor elke factuur een bijbehorende rij aan te maken.
Exporteer het event log: Nadat alle data is verwerkt en samengevoegd, slaat het script het uiteindelijke event log op als d365_collections_event_log.csv in dezelfde map. Het bestand is klaar om naar een process mining-tool te uploaden.

Configuratie

URL van het API-eindpunt: De basis-URL van je Dynamics 365 Finance and Operations-omgeving. Gebruik de notatie https://[your-environment-name].operations.dynamics.com.
Inloggegevens: Het script heeft een Tenant ID, Client ID en Client Secret nodig van een applicatieregistratie in Azure Active Directory. Deze applicatie moet toestemming hebben om de Dynamics 365 API te gebruiken.
Bedrijfsfilter (dataAreaId): Dynamics 365 ondersteunt meerdere bedrijven. Het script bevraagt één bedrijf met het filter dataAreaId. Stel de variabele default_company in op de juiste juridische entiteit, bijvoorbeeld 'USMF'.
Datumbereik: Met de parameters start_date en end_date stel je de extractieperiode in. Begin bij voorkeur met een recente periode van 3 tot 6 maanden. Zo beperk je de hoeveelheid data en blijft de extractie binnen een redelijke tijd. Het filter wordt vooral toegepast op de aanmaakdatum van de factuur.
Aandachtspunten voor prestaties: Bij grote datasets kan data-extractie via de OData API veel tijd kosten. Microsoft kan bovendien het aantal API-aanroepen beperken. Duurt de extractie te lang, gebruik dan een korter datumbereik of voer deze uit op een rustig moment.
Vereisten: Je hebt een Python 3.8+-omgeving nodig met de bibliotheken pandas, requests en msal. De bijbehorende Dynamics 365-gebruiker moet leesrechten hebben voor de modules voor financiën, verkoop en incassobeheer, en in het bijzonder voor de entiteiten die in het script worden genoemd.

Voorbeeldquery python

import requests
import pandas as pd
import msal
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

Klaar om aan de slag te gaan?

Gebruik deze template om je data goed voor te bereiden en waardevolle inzichten te krijgen in processen voor kredietbeheer en incasso. Begin vandaag met het optimaliseren van je proces voor een snellere cashflow.

Terug naar de verbetergids

Template downloaden

Verbeter kredietbeheer en incasso voor een snellere cashflow

Verbeter de cashflow door het order-to-cash-proces efficiënter te maken en de doorlooptijd met 30% te verkorten.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.

Datatemplate voor kredietbeheer en incasso

Datatemplate voor kredietbeheer en incasso

Attributen voor kredietbeheer en incasso

Activiteiten voor kredietbeheer en incasso

Extractiegidsen

Rechtstreeks een SQL-query uitvoeren via Bring Your Own Database (BYOD)

Stappen

Configuratie

Voorbeeldquery sql

Python-script met de Dynamics 365 OData REST API

Stappen

Configuratie

Voorbeeldquery python

Klaar om aan de slag te gaan?

Verbeter kredietbeheer en incasso voor een snellere cashflow