> Continu verbeteren van processen > Factuurverwerking van inkoop tot betaling > Microsoft Dynamics 365 > Datatemplate

Datatemplate voor Purchase to Pay-factuurverwerking

Microsoft Dynamics 365

Attributen voor Purchase to Pay-factuurverwerking(22) Activiteiten voor Purchase to Pay-factuurverwerking(14) Extractiegidsen(4)

Datatemplate voor Purchase to Pay-factuurverwerking

Deze template laat zien hoe je de essentiële data verzamelt voor de analyse van Purchase to Pay-factuurverwerking in Microsoft Dynamics 365. Je vindt erin welke attributen je verzamelt, welke activiteiten je bijhoudt en hoe je de data praktisch extraheert. Zo verzamel je de gegevens die nodig zijn voor een volledige analyse en optimalisatie van het proces.

Aanbevolen attributen voor een grondige analyse
Belangrijke activiteiten om tijdens de factuurverwerking bij te houden
Instructies voor data-extractie uit Microsoft Dynamics 365

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

Template downloaden

Attributen voor Purchase to Pay-factuurverwerking

Dit zijn de aanbevolen datavelden voor het event log, zodat je Purchase to Pay-factuurverwerking volledig kunt analyseren.

5 Verplicht 7 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de bedrijfsgebeurtenis of taak die op een bepaald moment tijdens de factuurverwerking plaatsvond.
Beschrijving De activiteitsnaam beschrijft een specifieke stap of statuswijziging in het factuurproces, zoals ‘Factuur geregistreerd’, ‘Factuur ter goedkeuring ingediend’ of ‘Betaling uitgevoerd’. Deze data is nodig om de proceskaart op te bouwen en de volgorde van gebeurtenissen te begrijpen. Met een analyse van dit attribuut zie je hoe het proces verloopt, welke routes vaak voorkomen en waar afwijkingen of bottlenecks zitten. Je gebruikt het om doorlooptijden tussen activiteiten te berekenen, bijvoorbeeld van goedkeuring tot boeking, en om te meten hoe vaak gebeurtenissen zoals afwijzingen of betalingsblokkades voorkomen. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart. Zo kun je de processtroom visualiseren en overgangen tussen activiteiten analyseren. Waar vind je dit? Dit attribuut wordt meestal afgeleid uit een combinatie van statusvelden, transactietypen of vermeldingen in wijzigingslogboeken van verschillende Dynamics 365-tabellen voor de factuurverwerking. Voorbeelden Factuur ter goedkeuring ingediendVerschil bij matchen gevondenBetaling uitgevoerd
	Factuurnummer InvoiceNumber	De unieke identificatiecode van elke leveranciersfactuur. Deze dient als primaire case-ID om de levenscyclus van de factuur te volgen.
Beschrijving Het factuurnummer is de unieke sleutel die alle activiteiten van één leveranciersfactuur met elkaar verbindt. Hiermee kun je de hele route van de factuur volgen, van ontvangst en registratie tot het matchen, de goedkeuring en de uiteindelijke betaling. Bij process mining is dit attribuut essentieel. Het bepaalt de case en maakt het mogelijk de processtroom van elke factuur te reconstrueren. Zo kun je de totale doorlooptijden berekenen, procesvarianten vinden en factuurspecifieke kenmerken en resultaten analyseren. Waarom dit belangrijk is Dit is de essentiële case-ID die alle bijbehorende gebeurtenissen verbindt. Zo kun je de volledige levenscyclus van elke factuur analyseren. Waar vind je dit? Dit staat meestal in de hoofdtafel voor leveranciersfacturen, zoals het veld Num in VendInvoiceInfoTable. Voorbeelden INV-10056773245-AUS-001-98432
	Gebeurtenistijd EventTime	De precieze timestamp waarop een activiteit of gebeurtenis plaatsvond.
Beschrijving De gebeurtenistijd, oftewel de timestamp, legt de exacte datum en tijd van een activiteit vast. Dit is een belangrijk onderdeel van het event log. De tijdsgegevens bepalen de juiste volgorde van activiteiten en maken het mogelijk tijdsduur te berekenen. Deze timestamp vormt de basis voor alle tijdsgerelateerde metingen. Je gebruikt hem om de duur van activiteiten, de doorlooptijd tussen stappen zoals goedkeuring en de totale verwerkingstijd per factuur te berekenen. Ook kun je er trends over een bepaalde periode mee analyseren. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen op volgorde te zetten, doorlooptijden en tijdsduren te berekenen en bottlenecks in het proces te vinden. Waar vind je dit? Deze waarde komt uit verschillende datum- en tijdvelden in meerdere tabellen, zoals de velden createdDateTime of modifiedDateTime in VendInvoiceInfoTable, VendTrans of workflowgeschiedenistabellen. Voorbeelden 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Bronsysteem SourceSystem	Het systeem waaruit de gebeurtenisdata is gehaald.
Beschrijving Dit attribuut geeft aan uit welke brontoepassing de activiteitsdata komt. Voor dit proces is dat meestal ‘Microsoft Dynamics 365’. In omgevingen met meerdere systemen, zoals een externe OCR- of capture-oplossing, laat dit veld zien waar elke processtap plaatsvindt. Zo blijft de herkomst van de data duidelijk en kun je problemen met data-extractie opsporen. Waarom dit belangrijk is Dit geeft belangrijke context over de herkomst van de data. Dat is nodig om de data te valideren en te begrijpen welke systemen bij het proces betrokken zijn. Waar vind je dit? Dit is een vaste waarde, ‘Microsoft Dynamics 365’, die tijdens de datatransformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Microsoft Dynamics 365
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor dit proces voor het laatst vanuit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut legt vast wanneer de dataset voor het laatst uit Microsoft Dynamics 365 is gehaald en bijgewerkt. De waarde is meestal hetzelfde voor alle records in één datalading. Zo zie je hoe actueel de data is die je analyseert. De informatie geeft context bij de actualiteit van de procesinzichten en helpt bij het beheren van vernieuwingsschema’s en het controleren van datapijplijnen. Waarom dit belangrijk is Laat zien hoe actueel de data is, wanneer de analyse voor het laatst is bijgewerkt en wanneer de volgende data-update wordt verwacht. Waar vind je dit? Deze timestamp wordt tijdens de uitvoering door het data-extractie- of ETL-proces gegenereerd en aan de dataset toegevoegd. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Eindtijd EndTime	De exacte timestamp waarop een activiteit of gebeurtenis is afgerond.
Beschrijving De eindtijd registreert wanneer een activiteit is afgerond. In combinatie met de starttijd (EventTime) kun je precies berekenen hoelang elke stap duurde. Dit attribuut is nodig om de ‘ProcessingTime’ per activiteit te berekenen, een belangrijke metriek voor prestatieanalyses. Je ziet ermee welke processtappen de meeste tijd kosten en kunt verbeteringen daarop richten. Zo kun je de exacte duur van een handmatige codering of goedkeuringsstap meten. Waarom dit belangrijk is Hiermee kun je de verwerkingstijd van activiteiten rechtstreeks berekenen. Dat is nodig om te bepalen welke processtappen de meeste tijd kosten. Waar vind je dit? Net als StartTime komt dit uit verschillende datum- en tijdvelden. Bij sommige activiteiten is dit de StartTime van de volgende activiteit. In andere gevallen kan het een specifieke timestamp zijn waarop de activiteit is afgerond. Voorbeelden 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Factuurbedrag InvoiceAmount	Het totale bedrag van de factuur.
Beschrijving Dit attribuut bevat het totaalbedrag dat volgens de leveranciersfactuur moet worden betaald. Het is een belangrijk financieel gegeven voor elke case. Het factuurbedrag wordt vaak gebruikt om data uit te splitsen en te analyseren. Zo zie je bijvoorbeeld of facturen met een hoog bedrag een ander, strenger goedkeuringsproces volgen of langer nodig hebben voor verwerking. In dashboards kun je factuurvolumes per bedrag analyseren. Ook kun je de bedragen optellen om de totale uitgaven in de analyse te bepalen. Waarom dit belangrijk is Hiermee kun je analyses uitvoeren op basis van financiële waarde, verbeteringen prioriteren voor facturen met hoge bedragen en inzicht krijgen in de kostenfactoren. Waar vind je dit? Dit staat in de kop van de factuurtabel, bijvoorbeeld in VendInvoiceInfoTable, in een veld zoals InvoiceAmount of Amount. Voorbeelden 1500.00250.7512500.50
	Factuurstatus InvoiceStatus	De huidige status van de factuur op het moment dat de data wordt geëxtraheerd.
Beschrijving De factuurstatus geeft aan wat de huidige status van een factuur in de levenscyclus is, bijvoorbeeld ‘In afwachting van goedkeuring’, ‘Goedgekeurd’, ‘Geboekt’ of ‘Betaald’. Zo zie je hoe ver de factuur is. Dit attribuut wordt vooral gebruikt voor procesdashboards met de huidige werkvoorraad en achterstand. Managers zien hoeveel facturen zich in elke procesfase bevinden. Dat helpt bij de verdeling van capaciteit en het bewaken van de bedrijfsvoering. Het is belangrijk voor het dashboard ‘Factuurverwerking: doorvoer en status’. Waarom dit belangrijk is Geeft een actueel overzicht van alle facturen. Dat is nodig om de bedrijfsvoering en werkvoorraad te bewaken en huidige bottlenecks te herkennen. Waar vind je dit? Dit wordt meestal afgeleid van statusvelden in de hoofdfactuurtabel, zoals VendInvoiceInfoTable. Voorbeelden In afwachting van goedkeuringGeboektBetaald
	Gebruiker User	De gebruikers-ID of naam van de persoon die de activiteit heeft uitgevoerd.
Beschrijving Dit attribuut identificeert de medewerker of systeemgebruiker die verantwoordelijk is voor een specifieke processtap. Bij geautomatiseerde stappen kan dit een systeem- of serviceaccount zijn. Door het proces per gebruiker te analyseren, krijg je inzicht in de werkverdeling, zie je waar training nodig is en kun je prestaties van medewerkers of teams vergelijken. Dit is belangrijk bij het analyseren van herstelwerk, waarbij werk tussen gebruikers heen en weer gaat. Ook zie je zo hoe gebruikers dezelfde taak op verschillende manieren uitvoeren. Waarom dit belangrijk is Hiermee kun je prestaties en werkdruk per gebruiker of team analyseren. Ook helpt het om de mate van automatisering en oorzaken van herstelwerk te herkennen. Waar vind je dit? Afkomstig uit gebruikers-ID-velden in transactie- of workflowhistorietabellen, zoals de velden createdby of modifiedby. Deze informatie kan in de workflowtrackingtabellen staan. Voorbeelden j.doea.smithAX_Admin
	Inkoopordernummer PurchaseOrderNumber	De identificatiecode van de inkooporder (PO) waaraan de factuur is gekoppeld.
Beschrijving Het inkoopordernummer koppelt een factuur aan het oorspronkelijke inkoopdocument. Dit is belangrijk bij processen waarin de factuur wordt gematcht met de inkooporder en de goederenontvangst, in een 2-way- of 3-way-match. Met dit attribuut kun je facturen met en zonder inkooporder vergelijken. Die volgen vaak verschillende procespaden. Het helpt je te beoordelen hoe goed het matchproces werkt, verschillen bij het matchen te onderzoeken en te meten welk deel van de facturen met inkooporder automatisch wordt verwerkt. Waarom dit belangrijk is Het onderscheidt facturen met een inkooporder van facturen zonder inkooporder. Dat is een belangrijke oorzaak van procesvariatie en essentieel voor analyses van het matchproces. Waar vind je dit? Dit staat in de kop van de factuurtabel, bijvoorbeeld in VendInvoiceInfoTable, vaak in een veld zoals PurchId. Voorbeelden PO-001234PO-005678PO-009101
	Leveranciersnummer VendorNumber	De unieke identificatiecode van de leverancier die de factuur heeft ingediend.
Beschrijving Het leveranciersnummer is de code waarmee een leverancier uniek wordt geïdentificeerd in de stamgegevens. Het koppelt de factuurtransactie aan een specifieke leverancier, zodat je analyses per leverancier kunt uitvoeren. Dit attribuut is essentieel om de procesdata per leverancier uit te splitsen. Zo kun je vragen beantwoorden als: ‘Bij welke leveranciers duurt de goedkeuring het langst?’ en ‘Komen verschillen bij het matchen vaker voor bij bepaalde leveranciers?’ Door de prestaties per leverancier te analyseren, ontdek je mogelijkheden om samen te werken met leveranciers en het proces te verbeteren. Waarom dit belangrijk is Hiermee kun je filteren en oorzaakanalyses per leverancier uitvoeren, zodat je prestatieproblemen of patronen bij specifieke leveranciers kunt herkennen. Waar vind je dit? Dit staat meestal in de kop van de leverancierfactuurtabel, zoals VendInvoiceInfoTable, die is gekoppeld aan de hoofdgegevens van leveranciers in VendTable. Voorbeelden V-1001V-2050V-8342
	Uiterste betaaldatum PaymentDueDate	De datum waarop de factuur volgens de afgesproken betalingsvoorwaarden moet zijn betaald.
Beschrijving De uiterste betaaldatum wordt berekend op basis van de factuurdatum en de betalingsvoorwaarden van de leverancier. Dit is de contractuele deadline voor de betaling. Deze datum is belangrijk om financiële prestaties en de relatie met leveranciers te bewaken. Je gebruikt hem als basis voor de KPI ‘Percentage tijdige betalingen’, door hem te vergelijken met de werkelijke datum waarop de betaling is uitgevoerd. Zo kun je terugkerende oorzaken van te late betalingen herkennen. Die kunnen de relatie met leveranciers schaden of ervoor zorgen dat je korting voor vroeg betalen misloopt. Waarom dit belangrijk is Dit is de maatstaf voor tijdige betalingen en een belangrijke KPI voor de financiële gezondheid en de relatie met leveranciers. Waar vind je dit? Het systeem berekent deze datum vaak en slaat hem op in de leverancierstransactietabel, zoals VendTrans, op basis van de factuurdatum en betalingsvoorwaarden. Voorbeelden 2023-05-152023-06-302023-07-20
	Afdeling Department	De kostenplaats of afdeling waaraan de factuurkosten worden toegewezen.
Beschrijving De afdeling geeft aan welke bedrijfseenheid of kostenplaats verantwoordelijk is voor de uitgaven op de factuur. Dit wordt meestal bepaald tijdens het coderen van de factuur. Door het proces per afdeling te analyseren, krijg je inzicht in verschillen in uitgaven, goedkeuringstijden en compliance. Je ziet welke afdelingen de meeste uitzonderingen op facturen hebben of de langste goedkeuringscycli. Dat biedt aanknopingspunten voor gerichte communicatie en training. Waarom dit belangrijk is Hiermee kun je kosten en processen per afdeling analyseren en verschillen in prestaties en compliance binnen de organisatie zichtbaar maken. Waar vind je dit? Afkomstig uit financiële dimensies die aan de factuurregels of factuurkop zijn gekoppeld. Hiervoor moet je de gegevensstructuren van de dimensies raadplegen. Voorbeelden VerkoopMarketingIT-bedrijfsvoering
	Bedrijfscode CompanyCode	De identificatiecode van de juridische entiteit of het bedrijf binnen de organisatie dat de factuur verwerkt.
Beschrijving De bedrijfscode geeft aan welke juridische entiteit financieel verantwoordelijk is voor de factuur. Bij organisaties met meerdere bedrijven is dit een belangrijk gegeven om financiële data uit te splitsen. Met dit attribuut kun je procesanalyses filteren op of vergelijken tussen juridische entiteiten. Zo zie je of prestaties, beleid of bottlenecks specifiek zijn voor bepaalde bedrijven binnen de groep. Dat helpt om verbeteringen op de lokale situatie af te stemmen. Waarom dit belangrijk is Hiermee kun je procesanalyses uitsplitsen per juridische entiteit. Dat is belangrijk voor grote organisaties met meerdere bedrijven. Waar vind je dit? Dit is een standaardveld in de meeste financiële tabellen van Dynamics 365 en heet vaak DataAreaId. Voorbeelden USMFDEMFGBSI
	Betalingsvoorwaarden PaymentTerms	De betalingsafspraken met de leverancier, zoals ‘Netto 30’ of ‘2% 10, netto 30’.
Beschrijving De betalingsvoorwaarden bevatten de afspraken over de betaling aan de leverancier, waaronder de termijn en eventuele kortingen. Deze informatie komt meestal uit de stamgegevens van de leverancier of de inkooporder. Dit attribuut geeft belangrijke context bij de uiterste betaaldatum en de KPI voor het percentage tijdige betalingen. Door te analyseren of bepaalde betalingsvoorwaarden samenhangen met te late betalingen, kun je problemen in de bedrijfsvoering herkennen. De informatie helpt ook bij financiële planning en het beheer van werkkapitaal. Waarom dit belangrijk is Geeft context bij uiterste betaaldatums en helpt de financiële gevolgen van het betalingstijdstip en het benutten van kortingen te analyseren. Waar vind je dit? Deze informatie staat in de stamgegevens van de leverancier (VendTable) en wordt gekopieerd naar transactietabellen zoals VendInvoiceInfoTable. Voorbeelden Netto 30Netto 602% 10, netto 30
	Factuurvaluta InvoiceCurrency	De valutacode van het factuurbedrag, bijvoorbeeld USD of EUR.
Beschrijving De factuurvaluta geeft aan in welke valuta het factuurbedrag is uitgedrukt. Dit is belangrijk voor internationale organisaties die met leveranciers uit verschillende landen werken. Dit attribuut geeft context aan het factuurbedrag en wordt gebruikt om te filteren en rapportages te maken, vooral bij internationale bedrijfsvoering. Zo worden financiële bedragen correct geïnterpreteerd en kun je analyses per valuta uitvoeren of bedragen omrekenen naar een standaardvaluta voor rapportages. Waarom dit belangrijk is Dit geeft financiële bedragen de nodige context, zodat je factuurbedragen in verschillende regio’s correct kunt interpreteren en analyseren. Waar vind je dit? Dit staat naast het factuurbedrag in de kop van de factuurtabel, bijvoorbeeld in het veld CurrencyCode van VendInvoiceInfoTable. Voorbeelden USDEURGBP
	Is geautomatiseerd IsAutomated	Een indicator die aangeeft of het systeem of een gebruiker een activiteit heeft uitgevoerd.
Beschrijving Dit booleaanse attribuut (true/false) maakt onderscheid tussen gebeurtenissen die het systeem uitvoert en handmatige taken van gebruikers. Zo kan het matchen van een factuur geautomatiseerd zijn, terwijl het afhandelen van verschillen handmatig gebeurt. Door dit attribuut te analyseren, krijg je inzicht in de mate van automatisering van het proces. Je kunt het resultaat van automatiseringsinitiatieven meten, resterende handmatige bottlenecks herkennen en zien waar verdere automatisering de efficiëntie kan verbeteren en fouten kan verminderen. Waarom dit belangrijk is Helpt de mate van automatisering te meten, handmatige bottlenecks te herkennen en mogelijkheden voor meer efficiëntie te vinden. Waar vind je dit? Dit wordt meestal afgeleid van het attribuut ‘Gebruiker’. Als de gebruiker een bekend systeem- of serviceaccount is, krijgt deze indicator de waarde true. Voorbeelden truefalse
	Is op tijd betaald IsOnTimePayment	Een berekende indicator die aangeeft of een factuur op of vóór de uiterste betaaldatum is betaald.
Beschrijving Dit booleaanse attribuut wordt afgeleid door de timestamp van de activiteit ‘Betaling uitgevoerd’ te vergelijken met de uiterste betaaldatum. Als de betaaldatum op of vóór de uiterste betaaldatum valt, is de waarde true. Anders is de waarde false. Dit attribuut ondersteunt rechtstreeks de KPI voor het percentage tijdige betalingen en het dashboard ‘Naleving van betalingsvoorwaarden’. Het maakt de analyse eenvoudiger met een duidelijke ja/nee-uitkomst per factuur. Zo kun je te late betalingen filteren en de oorzaken onderzoeken per leverancier, afdeling of land. Waarom dit belangrijk is Meet rechtstreeks of de betalingsvoorwaarden worden nageleefd. Zo bereken je eenvoudiger de KPI voor het percentage tijdige betalingen en voer je verwante analyses uit. Waar vind je dit? Dit attribuut wordt berekend in de datatransformatielaag. De logica is: (timestamp van de activiteit ‘Betaling uitgevoerd’) <= (uiterste betaaldatum). Voorbeelden truefalse
	Reden betalingsblokkade PaymentBlockReason	De reden die aangeeft waarom een betaling van een factuur is geblokkeerd.
Beschrijving Een betalingsblokkade voorkomt dat een factuur wordt betaald. Dit attribuut bevat de reden voor de blokkade. Meestal is dat een standaardcode die een gebruiker kiest, zoals ‘Betwiste kosten’ of ‘Wachten op goederenontvangst’. Dit attribuut is nodig voor het dashboard ‘Frequentie en duur van betalingsblokkades’. Door de meest voorkomende redenen te analyseren, kun je onderliggende problemen in het P2P-proces herkennen. Als je die oorzaken aanpakt, kun je betalingsvertragingen flink terugdringen en de relatie met leveranciers verbeteren. Waarom dit belangrijk is Geeft aan waarom betalingen bewust zijn uitgesteld. Zo kun je problemen eerder in het proces herkennen en oplossen die tot betalingsblokkades leiden. Waar vind je dit? Dit is meestal een veld in de leverancierstransactie of factuurregistratie, vaak gekoppeld aan de status van de betalingsblokkade. Kijk bijvoorbeeld in tabellen zoals VendTrans. Voorbeelden KwaliteitsgeschilWachten op creditnotaHandmatige blokkade
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft voor het afwijzen van een factuur.
Beschrijving Als een factuur tijdens de goedkeuringsworkflow wordt afgewezen, geeft de goedkeurder meestal een reden op. Dit attribuut bevat die toelichting, als vooraf ingestelde code of als vrije tekst. Dit attribuut is belangrijk voor het dashboard ‘Analyse van factuurafwijzingen’. Het geeft inzicht in de oorzaken van afwijzingen, zoals ‘Onjuist inkoopordernummer’, ‘Dubbele factuur’ of ‘Prijsverschil’. Door deze redenen te analyseren, kun je bepalen welke acties de afwijzingen terugdringen. Waarom dit belangrijk is Geeft inzicht in de redenen voor factuurafwijzingen, zodat je gericht herstelwerk kunt verminderen en het percentage facturen dat in één keer goed gaat kunt verhogen. Waar vind je dit? Dit staat meestal in de opmerkingen of historielogboeken van de workflowverwerkingstabellen. Voorbeelden Onjuiste hoeveelheidDubbele factuurGoedkeuringslimiet overschreden
	Totale doorlooptijd TotalCycleTime	De totale tijd die nodig is om één factuur van ontvangst tot betaling te verwerken.
Beschrijving De totale doorlooptijd meet hoelang een factuur in het hele proces zit. Je berekent deze door de tijd tussen de eerste activiteit, bijvoorbeeld ‘Factuur geregistreerd’, en de laatste activiteit, bijvoorbeeld ‘Betaling uitgevoerd’, voor een factuurnummer te bepalen. Dit is een belangrijke KPI om de algehele procesefficiëntie te meten. De metriek geeft een overzicht van de prestaties en wordt gebruikt in het dashboard ‘Totale doorlooptijd van facturen’. Door trends te analyseren en de data uit te splitsen naar attributen zoals leverancier of bedrag, kun je algemene verbeterkansen herkennen. Waarom dit belangrijk is Dit is de belangrijkste KPI op hoofdlijnen voor de snelheid en efficiëntie van het proces. De metriek vat de prestaties per factuur samen. Waar vind je dit? Dit wordt per case berekend in de process mining-tool of tijdens de datavoorbereiding. Het is het tijdsverschil tussen de timestamps van de eerste en laatste gebeurtenis voor elke CaseId. Voorbeelden P15DP22DT5H30MP7D
	Type verschil MatchingDiscrepancyType	Deelt het type verschil in dat is gevonden bij het matchen van de factuur met de inkooporder.
Beschrijving Als er bij een 2-way- of 3-way-match een verschil wordt gevonden, geeft dit attribuut aan om welk probleem het gaat, bijvoorbeeld ‘Prijsverschil’, ‘Verschil in hoeveelheid’ of ‘Goederenontvangst ontbreekt’. Deze data vormt de basis voor het dashboard ‘Doorlooptijd van het oplossen van matchverschillen’. Door de frequentie van verschillende soorten verschillen te analyseren, kan de organisatie de oorzaken van mislukte matches herkennen. Veel prijsverschillen kunnen bijvoorbeeld wijzen op verouderde stamgegevens, terwijl verschillen in hoeveelheid op problemen met de verzending kunnen duiden. Waarom dit belangrijk is Deelt mislukte matches in categorieën in. Zo kun je de oorzaken analyseren, verschillen terugdringen en facturen vaker automatisch verwerken. Waar vind je dit? Dit kan in een aparte tabel met matchresultaten of uitzonderingen staan. Soms moet je het afleiden uit statusberichten of workflowopmerkingen. Voorbeelden PrijsverschilVerschil in hoeveelheidGoederenontvangst ontbreekt

Verplicht Aanbevolen Optioneel

Activiteiten voor Purchase to Pay-factuurverwerking

Dit zijn de belangrijkste processtappen en mijlpalen voor het event log. Zo kun je de workflow voor factuurverwerking goed in kaart brengen en analyseren.

6 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Betaling uitgevoerd	Dit is de laatste activiteit. Het betalingsjournaal wordt geboekt, waarmee de betaling wordt aangemaakt en de factuur wordt afgehandeld. Deze expliciete transactie sluit de levenscyclus van de factuur af.
Waarom dit belangrijk is Deze activiteit markeert het succesvolle einde van het proces van factuur tot betaling. De activiteit vormt de basis voor het meten van het ‘Percentage betalingen op tijd’ en de totale doorlooptijd. Waar vind je dit? Dit is een expliciete gebeurtenis die wordt vastgelegd wanneer het betalingsjournaal wordt geboekt. De afwikkelingsgegevens staan in tabellen zoals VendSettlement, die de betaling aan de factuur koppelen. Vastleggen Boekingstimestamp van het betalingsjournaal waarmee de leverancierstransactie wordt afgehandeld. Gebeurtenistype explicit
	Factuur geboekt	Dit is de formele boekhoudkundige gebeurtenis waarbij de goedgekeurde factuur in het grootboek wordt opgenomen en een verplichting ontstaat. Dit is een expliciete transactie in het systeem.
Waarom dit belangrijk is Boeken is de laatste stap vóór betaling en een belangrijk financieel controlepunt. De tijd tussen ‘Factuur goedgekeurd’ en ‘Factuur geboekt’ laat zien hoe efficiënt de laatste boekhoudkundige stappen verlopen. Waar vind je dit? Dit is een expliciete gebeurtenis die wordt vastgelegd wanneer de geboekte leverancierstransactie wordt aangemaakt in tabellen zoals VendTrans, samen met de bijbehorende records in GeneralJournalEntry en LedgerEntry. Vastleggen Aanmaaktimestamp van het record in de tabel voor leverancierstransacties (VendTrans). Gebeurtenistype explicit
	Factuur gematcht met inkooporder	Dit geeft aan dat het matchen is geslaagd: de factuurgegevens komen overeen met de inkooporder en de goederenontvangst. De gebeurtenis wordt afgeleid wanneer de matchstatus van de factuur wordt bijgewerkt naar ‘Geslaagd’.
Waarom dit belangrijk is Een geslaagde match is een belangrijke mijlpaal voor facturen met een inkooporder. De match bevestigt dat de kosten kloppen voordat de factuur wordt betaald. Dit is belangrijk om de efficiëntie en automatiseringsgraad van het matchen te volgen. Waar vind je dit? Afgeleid uit de wijziging van het veld voor de matchstatus op de kop of regels van de leveranciersfactuur, bijvoorbeeld VendInvoiceInfoTable, naar ‘Geslaagd’ of ‘Succesvol gematcht’. Vastleggen Timestamp van de statuswijziging naar ‘Geslaagd’ in de validatiegegevens voor het matchen van de factuur. Gebeurtenistype inferred
	Factuur geregistreerd	Dit is de eerste registratie van een factuur in het systeem. Er wordt een voorlopig record aangemaakt voordat alle gegevens zijn verwerkt. Deze activiteit wordt vastgelegd wanneer een nieuw record wordt aangemaakt in het journaal voor het leveranciersfactuurregister.
Waarom dit belangrijk is Deze activiteit markeert het officiële begin van de factuurverwerking. Door de tijd vanaf dit moment te meten, zie je de totale verwerkingsduur en eventuele vertragingen in een vroeg stadium. Waar vind je dit? Dit is een expliciete gebeurtenis die wordt vastgelegd wanneer een record wordt aangemaakt in het leveranciersfactuurregister, meestal in VendInvoiceRegisterJournalTable of een vergelijkbare tabel voor openstaande facturen. Vastleggen Aanmaaktimestamp van het record in het journaal voor het leveranciersfactuurregister. Gebeurtenistype explicit
	Factuur goedgekeurd	Dit geeft aan dat de factuur in de workflow definitief is goedgekeurd en klaar is om te worden geboekt en betaald. De workflow-engine legt deze gebeurtenis expliciet vast wanneer de workflow is afgerond.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal die de goedkeuring afrondt. De tijd tussen ‘Factuur ter goedkeuring ingediend’ en deze gebeurtenis is een belangrijke maatstaf voor de efficiëntie van de goedkeuring en helpt bottlenecks te vinden. Waar vind je dit? Dit is een expliciete gebeurtenis in de workflowgeschiedenistabellen, bijvoorbeeld WorkflowTrackingStatusTable, die wordt vastgelegd wanneer de workflowstatus verandert in ‘Goedgekeurd’. Vastleggen Timestamp van de status ‘Goedgekeurd’ in de workflowgeschiedenis. Gebeurtenistype explicit
	Factuur ter goedkeuring ingediend	Deze activiteit markeert het formeel indienen van een factuur in een workflow voor controle en goedkeuring. De workflow-engine van Dynamics 365 legt deze indiening expliciet vast.
Waarom dit belangrijk is Dit is het startpunt voor het meten van de volledige goedkeuringsronde. Je ziet hoelang facturen wachten voordat de goedkeuring begint. Ook vormt dit het startpunt voor KPI’s over goedkeuring. Waar vind je dit? Dit is een expliciete gebeurtenis in de workflowgeschiedenistabellen, bijvoorbeeld WorkflowTrackingStatusTable, die wordt vastgelegd wanneer een factuur bij een workflow wordt ingediend. Vastleggen Aanmaaktimestamp van het indieningsrecord in de workflowgeschiedenis. Gebeurtenistype explicit
	Betaling ingepland	Deze activiteit vindt plaats wanneer een geboekte factuur wordt opgenomen in een betalingsvoorstel of betalingsjournaal, maar voordat de betaling wordt uitgevoerd. Dit is een expliciete handeling waarbij een regel in het betalingsjournaal wordt aangemaakt.
Waarom dit belangrijk is Dit markeert de overgang van crediteurenadministratie naar treasury. Door deze stap te analyseren, zie je mogelijke vertragingen tussen het boeken van de factuur en het starten van de betaling. Waar vind je dit? Dit is een expliciete gebeurtenis die wordt vastgelegd wanneer een regel in een betalingsjournaal (LedgerJournalTrans) wordt aangemaakt om de geboekte leverancierstransactie af te wikkelen. Vastleggen Aanmaaktimestamp van de regel in het betalingsjournaal die naar de factuur verwijst. Gebeurtenistype explicit
	Betalingsblokkade ingesteld	Deze activiteit vindt plaats wanneer een factuur wordt geblokkeerd en niet kan worden betaald. Dit wordt vastgelegd wanneer het veld voor de betalingsblokkade of blokkadestatus van het geboekte factuurrecord verandert.
Waarom dit belangrijk is Betalingsblokkades zijn een belangrijke oorzaak van te late betalingen. Door te analyseren wanneer en waarom ze worden ingesteld, kun je betalingen op tijd verbeteren en de relatie met leveranciers versterken. Waar vind je dit? Afgeleid uit een wijziging van het veld voor betalingsblokkade op de geboekte leverancierstransactie (VendTrans). Het wijzigingslogboek kan de timestamp vastleggen. Vastleggen Timestamp van de wijziging waarmee het veld voor de betalingsblokkade op de leverancierstransactie wordt ingesteld. Gebeurtenistype inferred
	Betalingsblokkade opgeheven	Dit geeft aan dat de betalingsblokkade is opgeheven en de factuur kan worden ingepland voor betaling. Dit wordt vastgelegd wanneer het veld voor de betalingsblokkade wordt gewist of verandert in een status zonder blokkade.
Waarom dit belangrijk is Meet hoelang het duurt om problemen op te lossen die een betalingsblokkade veroorzaken. Een lange tijd tussen het instellen en opheffen van de blokkade wijst op een inefficiënt probleemoplossingsproces. Waar vind je dit? Afgeleid uit een wijziging waarbij het veld voor de betalingsblokkade op de geboekte leverancierstransactie (VendTrans) wordt gewist. De timestamp kan uit het wijzigingslogboek komen. Vastleggen Timestamp van de wijziging waarmee het veld voor de betalingsblokkade op de leverancierstransactie wordt gewist. Gebeurtenistype inferred
	Factuur afgewezen	Dit geeft aan dat een goedkeurder de factuur heeft afgewezen. Het proces stopt en de factuur wordt meestal teruggestuurd voor correctie. De workflow-engine legt deze afwijzing expliciet vast.
Waarom dit belangrijk is Door afwijzingen te volgen, kun je herstelwerk meten en veelvoorkomende oorzaken vinden, zoals onjuiste codering of overtreding van beleid. Dit draagt rechtstreeks bij aan de KPI ‘Afwijzingspercentage facturen’. Waar vind je dit? Dit is een expliciete gebeurtenis in de workflowgeschiedenistabellen, bijvoorbeeld WorkflowTrackingStatusTable, die wordt vastgelegd wanneer de workflowstatus verandert in ‘Afgewezen’ of ‘Geannuleerd’. Vastleggen Timestamp van de status ‘Afgewezen’ in de workflowgeschiedenis. Gebeurtenistype explicit
	Factuur gecodeerd	Deze activiteit geeft aan dat grootboekrekeningverdelingen zijn toegewezen aan de factuurregels. Dit wordt meestal afgeleid uit het aanmaken of afronden van rekeningverdelingen die aan de factuur zijn gekoppeld.
Waarom dit belangrijk is Codering is belangrijk voor de financiële nauwkeurigheid. Door te meten hoe lang het coderen van facturen duurt, vind je bottlenecks in de boekhoudkundige controle. De meting draagt ook bij aan de KPI ‘Gemiddelde tijd van gegevensinvoer tot codering’. Waar vind je dit? Afgeleid uit het aanmaken en valideren van records in tabellen voor rekeningverdelingen, bijvoorbeeld AccountingDistribution, die gekoppeld zijn aan de openstaande leveranciersfactuur. Vastleggen Timestamp waarop de rekeningverdelingen voor de factuur zijn opgeslagen en gevalideerd. Gebeurtenistype inferred
	Factuurgegevens ingevoerd	Dit geeft aan dat de gegevensinvoer voor de factuur is afgerond, inclusief kop- en regelgegevens, voordat de factuur wordt ingediend om te matchen of goed te keuren. Dit wordt vaak afgeleid uit de statuswijziging van ‘nieuw’ of ‘geregistreerd’ naar ‘klaar voor verwerking’.
Waarom dit belangrijk is Door deze activiteit te volgen, meet je hoe efficiënt de gegevensinvoer verloopt, handmatig of automatisch met OCR. Vertragingen in deze stap kunnen gevolgen hebben voor het hele proces. Waar vind je dit? Afgeleid uit statuswijzigingen van het record voor de openstaande leveranciersfactuur, bijvoorbeeld VendInvoiceInfoTable. De gebeurtenis vindt plaats wanneer alle verplichte datavelden zijn ingevuld en de factuur klaar is voor de volgende stap. Vastleggen Detecteer een statuswijziging in de tabel met openstaande facturen die aangeeft dat de gegevensinvoer is afgerond. Gebeurtenistype inferred
	Verschil bij matchen gevonden	Deze activiteit vindt plaats wanneer het matchen van de factuur mislukt door verschillen tussen de factuur, de inkooporder of de goederenontvangst. De activiteit wordt vastgelegd wanneer de matchstatus van de factuur op ‘Mislukt’ of ‘Verschil’ wordt gezet.
Waarom dit belangrijk is Weten wanneer en waarom verschillen ontstaan, is belangrijk voor de KPI ‘Percentage verschillen bij matchen’. Deze activiteit markeert het begin van het oplossen van het verschil, wat vaak veel vertraging oplevert. Waar vind je dit? Afgeleid uit de wijziging van het veld voor de matchstatus van de leveranciersfactuur, bijvoorbeeld VendInvoiceInfoTable, naar ‘Mislukt’. Vaak wordt ook de reden van de mislukte match vastgelegd. Vastleggen Timestamp van de statuswijziging naar ‘Mislukt’ of ‘Verschil’ tijdens het matchen. Gebeurtenistype inferred
	Verschil bij matchen opgelost	Dit markeert het oplossen van een eerder gevonden verschil bij het matchen, zodat de factuur verder kan. Dit wordt afgeleid wanneer een factuur met de matchstatus ‘Mislukt’ opnieuw succesvol wordt gematcht of handmatig wordt vrijgegeven.
Waarom dit belangrijk is Met deze activiteit is het deelproces voor het oplossen van het verschil afgerond. De tijd tussen ‘Verschil bij matchen gevonden’ en deze gebeurtenis is een belangrijke KPI voor de efficiëntie van de oplossing. Waar vind je dit? Afgeleid uit een geslaagde matchgebeurtenis (‘Factuur gematcht met inkooporder’) die voor dezelfde factuur plaatsvindt na de gebeurtenis ‘Verschil bij matchen gevonden’. Vastleggen Zoek een timestamp met de matchstatus ‘Geslaagd’ die volgt op een timestamp met de status ‘Mislukt’. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Microsoft Dynamics 365

Stappen

Open de Data Management-workspace: Meld je aan bij Microsoft Dynamics 365 Finance. Zoek via de zoekbalk de workspace Data management en open deze.
Maak een exportproject: Selecteer in de workspace de tegel Export om een nieuw data-exportproject aan te maken. Geef het project een herkenbare naam, bijvoorbeeld ProcessMind_Invoice_Processing_Export.
Stel het dataproject in: Geef op het tabblad Algemeen van het nieuwe project de Data format op. CSV is een gangbaar en aanbevolen formaat. Stel de overige parameters naar behoefte in.
Voeg de benodigde data-entiteiten toe: Ga naar het gedeelte Selected entities en klik op Add entity. Zoek de volgende kernentiteiten en voeg ze één voor één toe. Geef voor elke entiteit het doelformaat op.
- VendInvoiceInfoTableEntity (kopgegevens leveranciersfactuur)
- VendInvoiceTransEntity (regels leveranciersfactuur)
- VendInvoiceRegisterHeaderEntity (kopgegevens factuurregisterjournaal)
- WorkflowTrackingStatusTableEntity (workflowgeschiedenis)
- AccountingDistributionEntity (grootboekverdelingen)
- VendInvoiceJour (geboekte leveranciersfacturen)
- VendTrans (leverancierstransacties, voor betalingsblokkades)
- LedgerJournalTransVendPaymEntity (regels leveranciersbetalingsjournaal)
- VendSettlement (verrekeningstransacties van leveranciers)
Pas filters toe: Beperk de hoeveelheid data door voor elke entiteit filters in te stellen. Selecteer een entiteit en klik op Filter. Filter minimaal op Company (rechtspersoon) en op een specifieke periode voor een relevant datumveld, zoals CREATEDDATETIME of INVOICEDATE. Voor een eerste analyse is een periode van de afgelopen 3 tot 6 maanden gebruikelijk.
Stel de entiteitskoppelingen in: Controleer voor elke entiteit de koppeling van bron naar doel. Neem alle benodigde velden voor het uiteindelijke event log op in de export. In deze fase zijn meestal geen complexe aanpassingen aan de koppelingen nodig.
Voer de exporttaak uit: Klik in het Action Pane op Export zodra alle entiteiten zijn toegevoegd en gefilterd. Je kunt de taak meteen uitvoeren of plannen buiten piekuren om de systeembelasting te beperken.
Download de geëxporteerde data: Ga na afloop van de exporttaak naar de taakgeschiedenis. Daar kun je het geëxporteerde datapakket downloaden. Het bevat aparte bestanden voor elke data-entiteit.
Zet de data om naar een event log: De geëxporteerde bestanden zijn momentopnamen van entiteiten, geen samengevoegd event log. Gebruik een externe tool, zoals een database, Python-script of Power Query, om de bestanden te verwerken en samen te voegen. De conceptquery in het gedeelte query bevat de volledige logica voor deze omzetting.
Voer de omzetting uit: Laad de geëxporteerde CSV-bestanden in de gekozen omgeving voor dataverwerking. Voer de meegeleverde omzettingsquery uit. Deze combineert data uit alle bronbestanden tot één event-logtabel met één rij per bedrijfsactiviteit.
Rond af en upload: Exporteer de omgezette data naar één CSV-bestand. Controleer of de kolomkoppen overeenkomen met de vereisten, bijvoorbeeld InvoiceNumber, ActivityName en EventTime. Dit bestand is klaar om naar ProcessMind te uploaden.

Configuratie

Data-entiteiten: De configuratie draait om de juiste entiteiten voor de levenscyclus van facturen. Belangrijke entiteiten zijn onder andere VendInvoiceInfoTableEntity, VendInvoiceJour en WorkflowTrackingStatusTableEntity.
Exportformaat: Selecteer CSV als doelformaat, zodat je de data eenvoudig in volgende omzettingsstappen kunt verwerken.
Filteren op bedrijf: Filter elke data-entiteit op de specifieke rechtspersoon die je analyseert. Zo voorkom je dat irrelevante data wordt opgehaald.
Filteren op datumperiode: Gebruik voor alle relevante entiteiten, zoals VendInvoiceInfoTableEntity en VendInvoiceJour, dezelfde datumperiode op basis van aanmaak- of boekingsdatums. Begin met een recente periode, bijvoorbeeld de afgelopen 6 maanden, om de hoeveelheid data beheersbaar te houden.
Volledige of incrementele export: Voer bij de eerste extractie een volledige export uit. Voor volgende vernieuwingen kun je een incrementele export instellen. Daarmee haal je alleen data op die sinds de vorige uitvoering is gewijzigd en verkort je de verwerkingstijd.
Vereisten vooraf: De gebruiker die de export uitvoert, moet de juiste beveiligingsrollen in Dynamics 365 hebben. Meestal is dat Data management administrator of een vergelijkbare rol met toegang tot de benodigde data-entiteiten.

Voorbeeldquery sql

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Stappen

Vereiste vooraf: BYOD instellen: Controleer of Bring Your Own Database is ingesteld voor je Microsoft Dynamics 365 Finance and Operations-omgeving. Hiervoor moet je een Azure SQL Database configureren en D365 instellen om data daarheen te exporteren.
Data-entiteiten bepalen: Open in D365 de workspace Data management. Voor deze extractie moeten specifieke data-entiteiten worden geëxporteerd. Neem de volgende entiteiten op in een exporttaak die naar je BYOD-database schrijft: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements en Accounting distributions.
Exporttaak maken en plannen: Maak in de workspace Data management een nieuw exportproject aan. Voeg de bovenstaande entiteiten toe en stel je BYOD-database in als doelformaat. Plan de exporttaak periodiek, bijvoorbeeld dagelijks of elk uur, zodat de data in BYOD actueel blijft.
Data in Azure SQL controleren: Maak met een tool zoals SQL Server Management Studio (SSMS) of Azure Data Studio verbinding met je Azure SQL Database. Controleer of de tabellen voor de D365-entiteiten zijn aangemaakt en data bevatten.
SQL-query voorbereiden: Kopieer de meegeleverde SQL-query. Deze query is bedoeld om rechtstreeks uit te voeren op de tabellen die door het BYOD-exportproces in je Azure SQL Database zijn aangemaakt.
Verbinding maken en uitvoeren: Open in je SQL-client een nieuw queryvenster dat is verbonden met BYOD. Plak de gekopieerde SQL-query in het venster.
Queryparameters instellen: Zoek de tijdelijke variabelen bovenaan het script. Vervang {StartDate}, {EndDate} en {CompanyCode} door de gewenste startdatum, einddatum en identificatiecode van de rechtspersoon. Bijvoorbeeld: SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Query uitvoeren: Voer het volledige SQL-script uit. De query verzamelt en combineert data uit meerdere tabellen om voor elke factuur een chronologisch event log op te bouwen.
Resultaten controleren: De uitvoer is één tabel met het event log en kolommen als InvoiceNumber, ActivityName, EventTime en andere opgegeven attributen. Controleer of de resultaten kloppen en volledig zijn.
Event log exporteren: Exporteer de queryresultaten naar een CSV-bestand. De meeste SQL-clients hebben een ingebouwde functie om resultaten in een bestand op te slaan. Sla het bestand op met UTF-8-codering.
Klaarmaken voor upload: Controleer vóór het uploaden naar een process mining-tool of het CSV-bestand exact de kolomkoppen uit de query bevat, zoals InvoiceNumber en ActivityName. De bestandsstructuur hoeft verder niet te worden aangepast.

Configuratie

Belangrijke data-entiteiten: Voor de extractie moeten verschillende D365-data-entiteiten naar BYOD worden geëxporteerd. Belangrijke entiteiten zijn VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution en VendTrans.
Filteren op datumperiode: De meegeleverde query bevat de parameters @StartDate en @EndDate. Begin bij voorkeur met een beperkte periode, bijvoorbeeld 3 tot 6 maanden aan data, om de prestaties te bewaken. Het filter wordt toegepast op de boekingsdatum of aanmaakdatum van de factuur.
Filteren op bedrijfscode: De parameter @DataAreaId is belangrijk in omgevingen met meerdere bedrijven. Filter altijd op een specifieke rechtspersoon (bedrijfscode), zodat de data bij de juiste context hoort.
Verversingsfrequentie van BYOD: Hoe actueel de data is, hangt volledig af van het schema van de D365-exporttaak. Voor analyse die bijna realtime is, moet de export vaak draaien, bijvoorbeeld elk uur. Dit kan gevolgen hebben voor de prestaties en kosten van zowel D365 als Azure.
Vereisten vooraf: Voor deze methode heb je een actief Azure-abonnement, een ingerichte Azure SQL Database en beheerderstoegang in D365 nodig om de workspace Data management in te stellen.

Voorbeeldquery sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

Stappen

Vereisten instellen: Zorg dat Python 3.6 of hoger op je systeem is geïnstalleerd. Installeer de benodigde bibliotheken met pip: pip install pandas requests msal. Deze bibliotheken zijn bedoeld voor dataverwerking, HTTP-verzoeken aan de API en authenticatie via het Microsoft identity platform.
Een toepassing registreren in Azure Active Directory: Registreer een toepassing in de Azure AD-tenant van je organisatie om je te authenticeren bij de Dynamics 365 API. Maak een nieuwe App Registration aan, genereer een client secret en noteer de Application (client) ID, Directory (tenant) ID en de waarde van het client secret.
API-machtigingen toekennen: Ga in de nieuwe App Registration in Azure AD naar API permissions. Voeg een machtiging toe voor 'Dynamics ERP' of 'Dynamics 365 Business Central', afhankelijk van je licentie, en ken de gedelegeerde machtiging user_impersonation toe. Een beheerder moet hiervoor admin consent verlenen.
Een toepassingsgebruiker aanmaken in Dynamics 365: Ga in je Dynamics 365-omgeving naar System administration > Users > Users. Maak een gebruiker aan en vul de Application (client) ID van de Azure App Registration in bij het veld Application ID. Ken deze gebruiker passende beveiligingsrollen toe, zoals 'System administrator' of een beperktere rol met leestoegang tot alle benodigde data-entiteiten.
Het Python-script instellen: Kopieer het meegeleverde Python-script naar een bestand, bijvoorbeeld extract_invoices.py. Open het bestand en vul bovenaan de tijdelijke variabelen in met de URL van je Dynamics 365-omgeving, tenant-ID, client-ID, client secret en de bedrijfscode (dataAreaId) waarvan je data wilt ophalen.
Datumperiode instellen: Pas de variabelen START_DATE en END_DATE in het script aan om de periode voor de data-extractie in te stellen. Begin bij voorkeur met een kortere periode, bijvoorbeeld één maand, om het script te testen en de resultaten te controleren.
Het script uitvoeren: Voer het script uit via de opdrachtregel of terminal met de opdracht python extract_invoices.py. Het script meldt zich aan, bevraagt de verschillende OData-eindpunten voor elke activiteit en verwerkt de data.
De uitvoering volgen: Tijdens het ophalen van data voor elke activiteit toont het script voortgangsberichten in de console. Afhankelijk van de datumperiode en hoeveelheid data kan dit lang duren. Let op foutmeldingen die kunnen wijzen op problemen met authenticatie of API-toegang.
Het uitvoerbestand controleren: Na een geslaagde uitvoering maakt het script in dezelfde map het CSV-bestand d365_invoice_event_log.csv aan. Dit bestand bevat het samengevoegde event log.
Klaarmaken voor upload: Open het CSV-bestand en controleer de opmaak. Kijk na of alle vereiste kolommen (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) aanwezig zijn en zijn ingevuld. Het bestand is klaar om naar ProcessMind te uploaden.

Configuratie

Authenticatie: Het script gebruikt de OAuth 2.0-clientcredentialsflow. Stel een Azure AD App Registration in en geef deze API-machtigingen voor Dynamics 365. Maak ook in Dynamics 365 zelf een toepassingsgebruiker aan met de juiste beveiligingsrollen.
API-eindpunt: De basis-URL voor de Dynamics 365 Finance and Operations OData API. De indeling is meestal https://[your-d365-environment-name].operations.dynamics.com.
Datumperiode: Het script bevat de variabelen START_DATE en END_DATE. Hiermee filter je records op aanmaak- of wijzigingsdatum en houd je de hoeveelheid data beheersbaar. Voor een eerste extractie is een periode van 3 tot 6 maanden aan te raden.
Bedrijfsfilter: Filter de data op een specifieke rechtspersoon of bedrijf. Dit doe je door dataAreaId op te geven in het API-queryfilter. Dit is een verplichte instelling in het script.
Belangrijke data-entiteiten: Het script bevraagt verschillende standaard OData-entiteiten van Dynamics 365, waaronder VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines en VendSettlements. Als het standaardproces sterk is aangepast, kunnen aangepaste entiteiten nodig zijn.
Paginering: Het script verwerkt gepagineerde API-antwoorden automatisch met de eigenschap @odata.nextLink. Zo worden alle records voor de opgegeven periode opgehaald.

Voorbeeldquery python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].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]"
COMPANY_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

    if not all_events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

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

Stappen

Controleer of je toegang hebt tot Microsoft Power Platform, Power Query, de Dynamics 365-doelomgeving en de bronentiteiten of -tabellen met gegevens over leveranciersfacturen, factuurregels, grootboekverdelingen, inkooporders, ontvangsten, workflows, betalingsblokkades, boekingen en betalingsjournaalposten. Omdat Dynamics 365-implementaties verschillen, leg je de daadwerkelijke bronobjecten vast in een mappingwerkmap. Gebruik tijdelijke aanduidingen zoals [Your invoice register table] en [Your workflow event table] totdat de objecten voor de specifieke omgeving zijn bevestigd.
Maak in Power Platform een Dataflow aan in de workspace of omgeving die voor ProcessMind-extractie wordt gebruikt. Selecteer de connector die past bij de Dynamics 365-implementatie en stel de verbinding in met [Your connection string or environment reference] en [Your credentials]. Zet inloggegevens niet in de querytekst.
Voeg in Power Query de bronentiteiten toe die nodig zijn voor de extractie. Breng minimaal de bronnen voor factuurregister, factuurkop, factuurregel, grootboekverdeling, resultaat van matching met inkooporder of ontvangst, workflowgeschiedenis, geschiedenis van betalingsblokkades, boekingstransactie, betalingsvoorstel of betalingsjournaalregel en betalingsverrekening in kaart. Noteer de daadwerkelijke entiteitsnamen en kolommen in de mappingwerkmap voordat je de dataflow publiceert.
Pas op elke bron de afgesproken extractieperiode toe met [Start date] en [End date]. Filter op [Your company or legal entity filter], relevante documenttypen en leveranciersfacturen. Bewaar brontimestamps met voldoende precisie om gebeurtenissen op volgorde te zetten. Gebruik voor EventTime timestamps uit het bronsysteem, niet de timestamps van het vernieuwen.
Maak een genormaliseerde eventquery met één rij per expliciet vastgelegde of expliciet afgeleide bedrijfsgebeurtenis. De query moet de volgende waarden voor ActivityName opleveren: Invoice Registered, Invoice Data Captured, Invoice Coded, Invoice Matched To Purchase Order, Matching Discrepancy Found, Matching Discrepancy Handled, Invoice Sent For Approval, Invoice Approved, Invoice Rejected, Payment Block Set, Payment Block Released, Invoice Posted, Payment Scheduled en Payment Executed. ProcessMind leest het event log zoals het is aangeleverd. Reken er dus niet op dat ProcessMind ontbrekende activiteiten afleidt.
Koppel elke gebeurtenisbron aan de factuurcase met InvoiceNumber. Als een bron een interne factuursleutel gebruikt, koppel die dan eerst aan de factuurkop of het register en neem vervolgens het zakelijke InvoiceNumber over. Behoud waar beschikbaar VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate en EndTime. Leg voor elke bronkolom een omgevingsspecifieke koppeling vast.
Pas voorwaarden toe die bij elke gebeurtenis horen. Voor registratie is een aangemaakt leveranciersfactuurregisterrecord vereist. Voor gegevensvastlegging is de ingestelde overgang van een nieuwe of geregistreerde status naar een status die klaar is voor verwerking vereist. Voor codering moet een grootboekverdeling zijn aangemaakt of afgerond. Een geslaagde matching vereist de status Passed. Een mislukte matching vereist Failed of Discrepancy. Afhandeling van een afwijking vereist een latere geslaagde nieuwe matching of een gedocumenteerde handmatige correctie. Voor het indienen, goedkeuren of afwijzen van een workflow zijn expliciete workflowgebeurtenissen nodig. Gebeurtenissen rond betalingsblokkades vereisen een wijziging in de blokkeringsstatus. Voor boeken, plannen en uitvoeren zijn expliciete boekings-, betalingsjournaal- of verrekeningsrecords nodig.
Standaardiseer de datatypen en waarden. Stel InvoiceNumber en ActivityName in als tekst, EventTime en EndTime als datetime, InvoiceAmount als numeriek type en PaymentDueDate als date of datetime, afhankelijk van de bron. Stel SourceSystem in op Microsoft Dynamics 365. Gebruik voor LastDataUpdate in alle rijen van een vernieuwing consequent de timestamp van de dataflowvernieuwing of de bronextractie.
Verwijder rijen zonder InvoiceNumber of EventTime, tenzij een goedgekeurd uitzonderingsproces een stabiele case-ID toekent. Verwijder duplicaten alleen als dubbele bronrecords dezelfde gebeurtenis voorstellen. Gebruik waar beschikbaar de brongebeurtenis-ID. Voeg afzonderlijke herhaalde goedkeuringen, matchingpogingen, blokkades of betalingsacties niet samen.
Laad de genormaliseerde uitvoer naar de ingestelde bestemming, zoals een Power Platform-databestemming, lakehouse, datawarehouse of bestandsbestemming die de implementatie ondersteunt. Exporteer of publiceer het resultaat als een platte tabel met één gebeurtenis per rij en de verplichte kolommen InvoiceNumber, ActivityName, EventTime, SourceSystem en LastDataUpdate, plus de aanbevolen attributen waar beschikbaar.
Vernieuw de dataflow, controleer de uitvoer en voer de validatie uit. Controleer of alle 14 waarden voor ActivityName aanwezig zijn wanneer er bijbehorende bronrecords zijn, timestamps in de juiste volgorde staan en InvoiceNumber als case-ID wordt gebruikt. Exporteer de gevalideerde tabel in een door ProcessMind ondersteund formaat, zoals CSV of de ingestelde connectoruitvoer. Upload de tabel naar ProcessMind of maak er verbinding mee, met InvoiceNumber als case-ID, ActivityName als activiteit en EventTime als eventtimestamp.

Configuratie

Bronkoppelingen: Vervang elke tijdelijke aanduiding voor de omgeving door de daadwerkelijke Dynamics 365-entiteiten, tabellen, weergaven en kolommen. Ga er niet van uit dat namen hetzelfde zijn in Finance, Supply Chain Management, Dataverse, aanpassingen of integraties.
Verplichte uitvoerkolommen: Vul voor elke geaccepteerde gebeurtenisrij InvoiceNumber, ActivityName, EventTime, SourceSystem en LastDataUpdate in.
Aanbevolen uitvoerkolommen: Neem VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate en EndTime op als de bron deze gegevens bevat.
Datumperiode: Begin met 3 tot 6 maanden aan geschiedenis. Vergroot de periode pas nadat je de queryprestaties en volledigheid van gebeurtenissen hebt gecontroleerd. Gebruik waar mogelijk een inclusieve startgrens en exclusieve eindgrens om dubbele gebeurtenissen tussen vernieuwingen te voorkomen.
Filter op bedrijf of rechtspersoon: Pas [Your company or legal entity filter] op dezelfde manier toe op alle bronentiteiten. Voorkom bij koppelingen dat facturen van verschillende rechtspersonen worden samengevoegd als InvoiceNumber niet uniek is.
Filter op documenttype: Beperk de extractie tot leveranciersfacturen en de documenttypen die in het proces worden gebruikt. Stel dit in op basis van het systeem en ga niet uit van een specifieke Dynamics 365-waarde.
Statusfilters: Gebruik de ingestelde waarden voor nieuw, geregistreerd, klaar voor verwerking, Passed, Failed, Discrepancy, goedgekeurd, afgewezen, geblokkeerd en gedeblokkeerd. Statuslabels kunnen verschillen per versie, taal, aanpassing of integratie.
Betekenis van gebeurtenissen: Haal voor elke vereiste activiteit een expliciete rij op. Leid activiteiten alleen af als de beschreven bronsysteemovergang of bronrecord daarvoor betrouwbaar bewijs levert. ProcessMind leidt geen gebeurtenissen af uit andere rijen.
Keuze van timestamps: Gebruik bij voorkeur de timestamp van de brongebeurtenis. Kies op basis van de gebeurtenisdefinitie voor de timestamp van aanmaak, wijziging, workflowactie, boeking, journaalpost of verrekening. Gebruik LastDataUpdate niet als EventTime.
Vernieuwingsmetadata: Vul LastDataUpdate voor de dataflowuitvoering met één consistente vernieuwingstimestamp. Als de bestemming incrementeel vernieuwen ondersteunt, bewaar de vernieuwingswatermark apart van EventTime.
Incrementeel vernieuwen: Gebruik een stabiele bronwatermark, zoals een wijzigingstimestamp of gebeurtenis-ID, en neem een terugkijkperiode op om later binnenkomende workflow-, matching- en betalingsgebeurtenissen mee te nemen. Verwijder duplicaten met brongebeurtenis-ID’s waar die beschikbaar zijn.
Prestaties: Filter bronentiteiten vóór koppelingen, selecteer alleen benodigde kolommen, voorkom dat je factuurregels onbeperkt uitbreidt en verwerk grote bronnen in aparte stappen. Gebruik query folding als de connector dit ondersteunt. Verdeel grote datumperioden in partities of vernieuw ze incrementeel.
Koppelsleutels: Gebruik InvoiceNumber alleen als dit uniek is binnen het geselecteerde bedrijf of de rechtspersoon. Gebruik anders de omgevingsspecifieke samengestelde sleutel en neem InvoiceNumber op in de uiteindelijke uitvoer.
Vereisten vooraf: Je hebt toegang nodig tot de Dynamics 365-data, workflowgeschiedenis, boekings- en betalingsdata, de Power Platform-dataflow en de bestemming. Welke licenties en connectors nodig zijn, hangt af van de tenant, Dynamics 365-implementatie en gekozen bestemming.
Beveiliging: Gebruik beheerde verbindingen of goedgekeurde inloggegevens, beperk toegangsrechten tot wat nodig is en neem geen geheimen op in Power Query-expressies of geëxporteerde bestanden.
Valuta en bedragen: Behoud de bronvaluta of voeg de omgevingsspecifieke valutakolom toe als je financiële analyses uitvoert. Reken bedragen alleen om als daarvoor een goedgekeurde wisselkoersregel is vastgelegd.

Voorbeeldquery sql

let
    StartDate = #datetime(2025, 1, 1, 0, 0, 0),
    EndDate = #datetime(2025, 7, 1, 0, 0, 0),
    CompanyFilter = "[Your company or legal entity filter]",
    SourceSystemValue = "Microsoft Dynamics 365",
    RefreshTime = DateTimeZone.RemoveZone(DateTimeZone.UtcNow()),

    InvoiceRegister = Table.SelectRows(#"[Your invoice register table]", each [Company] = CompanyFilter and [CreatedDateTime] >= StartDate and [CreatedDateTime] < EndDate),
    InvoiceHeader = Table.SelectRows(#"[Your invoice header table]", each [Company] = CompanyFilter),
    InvoiceLines = Table.SelectRows(#"[Your invoice line table]", each [Company] = CompanyFilter),
    LedgerDistributions = Table.SelectRows(#"[Your ledger distribution table]", each [Company] = CompanyFilter and [CreatedDateTime] >= StartDate and [CreatedDateTime] < EndDate),
    MatchingResults = Table.SelectRows(#"[Your invoice matching result table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    WorkflowEvents = Table.SelectRows(#"[Your workflow event table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PaymentHoldHistory = Table.SelectRows(#"[Your payment hold history table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PostingEvents = Table.SelectRows(#"[Your invoice posting table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PaymentScheduleEvents = Table.SelectRows(#"[Your payment proposal or payment journal line table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PaymentExecutionEvents = Table.SelectRows(#"[Your payment settlement table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),

    HeaderColumns = Table.SelectColumns(InvoiceHeader, {"InvoiceNumber", "VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "InvoiceStatus", "PaymentDueDate"}),
    HeaderDistinct = Table.Distinct(HeaderColumns, {"InvoiceNumber"}),

    RegisterEvents = Table.RenameColumns(Table.SelectColumns(InvoiceRegister, {"InvoiceNumber", "CreatedDateTime", "User"}), {{"CreatedDateTime", "EventTime"}}),
    RegisterWithActivity = Table.AddColumn(RegisterEvents, "ActivityName", each "Invoice Registered", type text),

    DataCapturedBase = Table.SelectRows(InvoiceHeader, each ([PreviousStatus] = "new" or [PreviousStatus] = "registered") and [InvoiceStatus] = "ready for processing"),
    DataCapturedEvents = Table.RenameColumns(Table.SelectColumns(DataCapturedBase, {"InvoiceNumber", "StatusChangedDateTime", "User"}), {{"StatusChangedDateTime", "EventTime"}}),
    DataCapturedWithActivity = Table.AddColumn(DataCapturedEvents, "ActivityName", each "Invoice Data Captured", type text),

    CodedBase = Table.SelectRows(LedgerDistributions, each [DistributionStatus] = "Finalized" or [DistributionStatus] = "Created"),
    CodedEvents = Table.RenameColumns(Table.SelectColumns(CodedBase, {"InvoiceNumber", "EventDateTime", "User"}), {}),
    CodedWithActivity = Table.AddColumn(CodedEvents, "ActivityName", each "Invoice Coded", type text),

    MatchedBase = Table.SelectRows(MatchingResults, each [MatchingStatus] = "Passed"),
    MatchedEvents = Table.SelectColumns(MatchedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    MatchedWithActivity = Table.AddColumn(MatchedEvents, "ActivityName", each "Invoice Matched To Purchase Order", type text),

    DiscrepancyBase = Table.SelectRows(MatchingResults, each [MatchingStatus] = "Failed" or [MatchingStatus] = "Discrepancy"),
    DiscrepancyEvents = Table.SelectColumns(DiscrepancyBase, {"InvoiceNumber", "EventDateTime", "User"}),
    DiscrepancyWithActivity = Table.AddColumn(DiscrepancyEvents, "ActivityName", each "Matching Discrepancy Found", type text),

    HandledBase = Table.SelectRows(MatchingResults, each ([MatchingStatus] = "Passed" and ([PreviousMatchingStatus] = "Failed" or [PreviousMatchingStatus] = "Discrepancy")) or [ManualOverride] = true),
    HandledEvents = Table.SelectColumns(HandledBase, {"InvoiceNumber", "EventDateTime", "User"}),
    HandledWithActivity = Table.AddColumn(HandledEvents, "ActivityName", each "Matching Discrepancy Handled", type text),

    SubmittedBase = Table.SelectRows(WorkflowEvents, each [WorkflowEventType] = "Submitted"),
    SubmittedEvents = Table.SelectColumns(SubmittedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    SubmittedWithActivity = Table.AddColumn(SubmittedEvents, "ActivityName", each "Invoice Sent For Approval", type text),

    ApprovedBase = Table.SelectRows(WorkflowEvents, each [WorkflowEventType] = "Approved"),
    ApprovedEvents = Table.SelectColumns(ApprovedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    ApprovedWithActivity = Table.AddColumn(ApprovedEvents, "ActivityName", each "Invoice Approved", type text),

    RejectedBase = Table.SelectRows(WorkflowEvents, each [WorkflowEventType] = "Rejected"),
    RejectedEvents = Table.SelectColumns(RejectedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    RejectedWithActivity = Table.AddColumn(RejectedEvents, "ActivityName", each "Invoice Rejected", type text),

    BlockSetBase = Table.SelectRows(PaymentHoldHistory, each [HoldStatus] = "Blocked" and ([PreviousHoldStatus] <> "Blocked" or [PreviousHoldStatus] = null)),
    BlockSetEvents = Table.SelectColumns(BlockSetBase, {"InvoiceNumber", "EventDateTime", "User"}),
    BlockSetWithActivity = Table.AddColumn(BlockSetEvents, "ActivityName", each "Payment Block Set", type text),

    BlockReleasedBase = Table.SelectRows(PaymentHoldHistory, each ([HoldStatus] = "Unblocked" or [HoldStatus] = "") and [PreviousHoldStatus] = "Blocked"),
    BlockReleasedEvents = Table.SelectColumns(BlockReleasedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    BlockReleasedWithActivity = Table.AddColumn(BlockReleasedEvents, "ActivityName", each "Payment Block Released", type text),

    PostedBase = Table.SelectRows(PostingEvents, each [PostingStatus] = "Posted"),
    PostedEvents = Table.SelectColumns(PostedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    PostedWithActivity = Table.AddColumn(PostedEvents, "ActivityName", each "Invoice Posted", type text),

    ScheduledBase = Table.SelectRows(PaymentScheduleEvents, each [PaymentJournalLineStatus] = "Created" or [PaymentJournalLineStatus] = "Included"),
    ScheduledEvents = Table.SelectColumns(ScheduledBase, {"InvoiceNumber", "EventDateTime", "User"}),
    ScheduledWithActivity = Table.AddColumn(ScheduledEvents, "ActivityName", each "Payment Scheduled", type text),

    ExecutedBase = Table.SelectRows(PaymentExecutionEvents, each [SettlementStatus] = "Posted" or [PaymentStatus] = "Executed"),
    ExecutedEvents = Table.SelectColumns(ExecutedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    ExecutedWithActivity = Table.AddColumn(ExecutedEvents, "ActivityName", each "Payment Executed", type text),

    AllEvents = Table.Combine({RegisterWithActivity, DataCapturedWithActivity, CodedWithActivity, MatchedWithActivity, DiscrepancyWithActivity, HandledWithActivity, SubmittedWithActivity, ApprovedWithActivity, RejectedWithActivity, BlockSetWithActivity, BlockReleasedWithActivity, PostedWithActivity, ScheduledWithActivity, ExecutedWithActivity}),
    EventsWithHeader = Table.NestedJoin(AllEvents, {"InvoiceNumber"}, HeaderDistinct, {"InvoiceNumber"}, "Header", JoinKind.LeftOuter),
    ExpandedHeader = Table.ExpandTableColumn(EventsWithHeader, "Header", {"VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "InvoiceStatus", "PaymentDueDate"}, {"VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "InvoiceStatus", "PaymentDueDate"}),
    WithSourceSystem = Table.AddColumn(ExpandedHeader, "SourceSystem", each SourceSystemValue, type text),
    WithLastDataUpdate = Table.AddColumn(WithSourceSystem, "LastDataUpdate", each RefreshTime, type datetime),
    WithEndTime = Table.AddColumn(WithLastDataUpdate, "EndTime", each [EventTime], type datetime),
    SelectedColumns = Table.SelectColumns(WithEndTime, {"InvoiceNumber", "ActivityName", "EventTime", "SourceSystem", "LastDataUpdate", "VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "User", "InvoiceStatus", "PaymentDueDate", "EndTime"}),
    TypedColumns = Table.TransformColumnTypes(SelectedColumns, {{"InvoiceNumber", type text}, {"ActivityName", type text}, {"EventTime", type datetime}, {"SourceSystem", type text}, {"LastDataUpdate", type datetime}, {"VendorNumber", type text}, {"PurchaseOrderNumber", type text}, {"InvoiceAmount", type number}, {"User", type text}, {"InvoiceStatus", type text}, {"PaymentDueDate", type date}, {"EndTime", type datetime}}),
    ValidEvents = Table.SelectRows(TypedColumns, each [InvoiceNumber] <> null and [InvoiceNumber] <> "" and [EventTime] <> null),
    SortedEvents = Table.Sort(ValidEvents, {{"InvoiceNumber", Order.Ascending}, {"EventTime", Order.Ascending}, {"ActivityName", Order.Ascending}})
in
    SortedEvents

Klaar om aan de slag te gaan?

Gebruik deze template als startpunt voor process mining en ontdek hoe je facturen sneller en nauwkeuriger verwerkt. Begin vandaag nog met het verbeteren van je bedrijfsvoering.

Terug naar de verbetergids

Template downloaden

Optimaliseer vandaag nog Purchase to Pay-factuurverwerking

Spoor inefficiënties op en verkort de doorlooptijd van facturen met 30% of meer.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.

Datatemplate voor Purchase to Pay-factuurverwerking

Datatemplate voor Purchase to Pay-factuurverwerking

Attributen voor Purchase to Pay-factuurverwerking

Activiteiten voor Purchase to Pay-factuurverwerking

Extractiegidsen

Export via het Data Management Framework van Dynamics 365

Stappen

Configuratie

Voorbeeldquery sql

Directe SQL-query via Bring Your Own Database (BYOD)

Stappen

Configuratie

Voorbeeldquery sql

Python-script met de Dynamics 365 OData REST API

Stappen

Configuratie

Voorbeeldquery python

Data-extractie met Microsoft Power Platform Dataflow

Stappen

Configuratie

Voorbeeldquery sql

Klaar om aan de slag te gaan?

Optimaliseer vandaag nog Purchase to Pay-factuurverwerking