> Continue procesverbetering > Purchase to pay factuurverwerking > Microsoft Dynamics 365 > Datatemplate

Jouw datatemplate voor Purchase to Pay-factuurverwerking

Microsoft Dynamics 365

Purchase to Pay - attributen voor factuurverwerking (22) Purchase to Pay - activiteiten voor factuurverwerking (14) Extractiegidsen (4)

Jouw datatemplate voor Purchase to Pay-factuurverwerking

Deze template geeft je een duidelijke leidraad voor het extraheren van de essentiële data die je nodig hebt om Purchase to Pay-factuurverwerking in Microsoft Dynamics 365 te analyseren. De template beschrijft welke attributen je moet verzamelen, welke activiteiten je moet volgen en hoe je data praktisch extraheert. Gebruik deze bron om alle benodigde informatie voor een volledige procesanalyse en optimalisatie te verzamelen.

Aanbevolen attributen voor een grondige analyse
Belangrijke activiteiten om gedurende de levenscyclus van de factuur te volgen
Richtlijnen voor het extraheren van data uit Microsoft Dynamics 365

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

Template downloaden

Purchase to Pay - attributen voor factuurverwerking

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

5 Verplicht 7 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteitnaam ActivityName	De naam van het specifieke bedrijfsevent of de specifieke taak die op een bepaald moment in de levenscyclus van de factuur plaatsvond.
Beschrijving De activiteitnaam beschrijft een specifieke stap of statuswijziging in het factuurproces, zoals 'Factuur geregistreerd', 'Factuur ter goedkeuring verzonden' of 'Betaling uitgevoerd'. Deze data is belangrijk voor het opbouwen van de proceskaart en het begrijpen van de volgorde van events. Door dit attribuut te analyseren, zie je de procesflow, herken je veelvoorkomende routes en vind je afwijkingen of bottlenecks. Je gebruikt het om doorlooptijden tussen activiteiten te berekenen, zoals de tijd van goedkeuring tot boeking, en om de frequentie van specifieke events te meten, zoals afwijzingen of betalingsblokkades. Waarom dit belangrijk is Het bepaalt de stappen in de proceskaart, zodat je de procesflow kunt visualiseren en overgangen tussen verschillende activiteiten kunt analyseren. Waar je het vindt Dit attribuut wordt meestal afgeleid uit een combinatie van statusvelden, transactietypen of vermeldingen in wijzigingslogs binnen verschillende Dynamics 365-tabellen voor factuurverwerking. Voorbeelden Factuur ter goedkeuring verzondenMatchingsverschil gevondenBetaling uitgevoerd
	Eventtijd EventTime	De precieze timestamp die aangeeft wanneer een specifieke activiteit of event plaatsvond.
Beschrijving Eventtijd, ofwel de timestamp, registreert de exacte datum en tijd waarop een activiteit plaatsvond. Dit is een belangrijk onderdeel van het event log, omdat je hiermee de tijdvolgorde van activiteiten bepaalt en doorlooptijden berekent. In analyses vormt deze timestamp de basis voor alle tijdgerelateerde metingen. Je gebruikt hem om de duur van activiteiten, de doorlooptijd tussen processtappen, bijvoorbeeld de goedkeuringstijd, en de totale end-to-endverwerkingstijd per factuur te berekenen. Ook maakt de timestamp trendanalyses over tijd mogelijk. Waarom dit belangrijk is Deze timestamp is nodig om events te ordenen, alle doorlooptijden en tijdsduur te berekenen en bottlenecks in het proces te vinden. Waar je het vindt Deze data komt uit verschillende datum- en tijdvelden in meerdere tabellen, zoals de velden createdDateTime of modifiedDateTime in tabellen als VendInvoiceInfoTable, VendTrans of workflowhistorietabellen. Voorbeelden 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Factuurnummer InvoiceNumber	De unieke identificatie van elke leveranciersfactuur, die als primaire case-ID dient om de levenscyclus te volgen.
Beschrijving Het factuurnummer is de unieke sleutel die alle activiteiten van één leveranciersfactuur aan elkaar koppelt. Hiermee kun je de factuur van begin tot eind volgen, van ontvangst en registratie tot matching, goedkeuring en uiteindelijke betaling. In process-mininganalyse is dit attribuut essentieel. Het bepaalt de case, zodat je de procesflow van elke factuur kunt reconstrueren. Daarmee kun je totale doorlooptijden berekenen, procesvarianten identificeren en factuurspecifieke kenmerken en resultaten analyseren. Waarom dit belangrijk is Dit is de essentiële case-ID die alle gerelateerde events koppelt. Zo kun je de volledige levenscyclus van elke afzonderlijke factuur analyseren. Waar je het vindt Dit staat meestal in de hoofdtafel voor leveranciersfacturen, zoals VendInvoiceInfoTable, in het veld Num. Voorbeelden INV-10056773245-AUS-001-98432
	Bronsysteem SourceSystem	Het systeem waarin de oorspronkelijke registratie staat en waaruit de eventdata is geëxtraheerd.
Beschrijving Dit attribuut identificeert de bronapplicatie waar de activiteitendata vandaan komt. Voor dit proces is dat meestal 'Microsoft Dynamics 365'. In omgevingen met meerdere systemen, zoals een externe OCR- of captureoplossing, helpt dit veld om te onderscheiden waar elke processtap plaatsvindt. Zo blijft de herkomst van de data duidelijk en kun je problemen met data-extractie beter onderzoeken. Waarom dit belangrijk is Het geeft belangrijke context over de herkomst van de data. Dat helpt bij datavalidatie en bij het begrijpen van de systeemomgeving van het proces. Waar je het vindt Dit is een statische 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 die aangeeft wanneer de data voor dit proces voor het laatst vanuit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut registreert wanneer de dataset voor het laatst uit Microsoft Dynamics 365 is geëxtraheerd en bijgewerkt. Binnen één data-load is deze waarde meestal voor alle records gelijk. Deze informatie helpt je te begrijpen hoe actueel de data is die je analyseert. Ze geeft context bij de actualiteit van de procesinzichten en is belangrijk voor het beheren van vernieuwingsschema's en het controleren van datapijplijnen. Waarom dit belangrijk is Het laat zien hoe actueel de data is, zodat gebruikers weten hoe recent de analyse is en wanneer de volgende data-update wordt verwacht. Waar je het vindt 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 precieze timestamp die aangeeft wanneer een specifieke 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 afzonderlijke processtap duurde. Dit attribuut is essentieel voor het berekenen van de 'ProcessingTime' per activiteit, een belangrijke metriek voor prestatieanalyse. Zo zie je precies welke processtappen de meeste tijd kosten en waar gerichte verbeteracties nodig zijn. Je kunt bijvoorbeeld de exacte duur van een handmatige coderings- of goedkeuringsstap meten. Waarom dit belangrijk is Maakt het mogelijk om de verwerkingstijd per activiteit rechtstreeks te berekenen. Dat is de basis voor het herkennen van de tijdrovendste processtappen. Waar je het vindt Net als StartTime komt dit uit verschillende datum- en tijdvelden. Voor sommige activiteiten kan dit de StartTime van de volgende activiteit zijn. In andere gevallen is het een specifieke timestamp voor 'completed on'. Voorbeelden 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Factuurbedrag InvoiceAmount	De totale geldwaarde van de factuur.
Beschrijving Dit attribuut staat voor het totale verschuldigde bedrag op de leveranciersfactuur. Het is een belangrijk financieel gegeven voor elke case. Het factuurbedrag wordt veel gebruikt voor segmentatie en analyse. Je kunt ermee zien of facturen met een hoge waarde een strenger goedkeuringsproces volgen of langer duren. Ook gebruik je het in dashboards om factuurvolumes per waarde te analyseren en de totale uitgaven binnen de analyse te berekenen. Waarom dit belangrijk is Hiermee kun je analyseren op basis van financiële waarde. Zo kun je verbeteracties prioriteren voor facturen met een hoge waarde en begrijpen welke factoren de kosten bepalen. Waar je het vindt Dit staat in de factuurkoptabel, bijvoorbeeld VendInvoiceInfoTable, in een veld als 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 de huidige status van een factuur binnen de levenscyclus aan, zoals 'In afwachting van goedkeuring', 'Goedgekeurd', 'Geboekt' of 'Betaald'. Zo krijg je een momentopname van de voortgang van de factuur. Dit attribuut wordt vooral gebruikt voor operationele dashboards die de huidige werkvoorraad en achterstand tonen. Het helpt managers te zien hoeveel facturen zich in elke processtap bevinden. Zo kunnen ze capaciteit verdelen en de bedrijfsvoering monitoren. Het attribuut is belangrijk voor het dashboard 'Invoice Processing Throughput & Status'. Waarom dit belangrijk is Geeft een actueel overzicht van alle facturen. Dit is essentieel voor monitoring van de bedrijfsvoering, werkvoorraadbeheer en het herkennen van huidige knelpunten. Waar je het vindt Dit wordt meestal afgeleid van statusvelden in de hoofdtabel voor facturen, 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 verdeling van werk, zie je waar training nodig is en kun je prestaties tussen personen of teams vergelijken. Het is belangrijk voor het analyseren van herstelwerklussen, waarbij werk heen en weer gaat tussen gebruikers, en voor het begrijpen van verschillen in de manier waarop gebruikers dezelfde taak uitvoeren. Waarom dit belangrijk is Hiermee kun je prestaties en werkbelasting per gebruiker of team analyseren. Ook helpt het om de automatiseringsgraad en bronnen van herstelwerk te vinden. Waar je het vindt Dit komt 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 identificatie van de inkooporder (PO) waaraan de factuur is gekoppeld.
Beschrijving Het inkoopordernummer koppelt een factuur aan het oorspronkelijke inkoopdocument. Dit is belangrijk voor processen met 2-way of 3-way matching tussen de factuur, de inkooporder en de goederenontvangst. Met dit attribuut kun je facturen met en zonder inkooporder analyseren. Die volgen vaak verschillende procesroutes. Het is belangrijk om de effectiviteit van matching te begrijpen, matchingsverschillen te onderzoeken en het percentage straight-through processing voor facturen met een inkooporder te meten. Waarom dit belangrijk is Het onderscheidt facturen met een inkooporder van facturen zonder inkooporder. Dat is een belangrijke oorzaak van procesvariatie en van groot belang voor matchinganalyses. Waar je het vindt Dit staat in de factuurkoptabel, zoals VendInvoiceInfoTable, vaak in een veld als PurchId. Voorbeelden PO-001234PO-005678PO-009101
	Leveranciersnummer VendorNumber	De unieke identificatie van de leverancier die de factuur heeft ingediend.
Beschrijving Het leveranciersnummer is de code die een leverancier uniek identificeert in de stamdata. Het koppelt de factuurtransactie aan een specifieke leverancier, zodat je het proces per leverancier kunt analyseren. Dit attribuut is belangrijk om procesdata per leverancier te segmenteren. Je kunt er vragen mee beantwoorden als 'Welke leveranciers hebben de langste goedkeuringstijden?' en 'Komen matchingsverschillen bij bepaalde leveranciers vaker voor?'. Door prestaties per leverancier te analyseren, vind je kansen voor samenwerking met leveranciers en procesverbetering. Waarom dit belangrijk is Hiermee kun je filteren en oorzaken analyseren per leverancier. Zo vind je prestatieproblemen of patronen die aan specifieke leveranciers zijn gekoppeld. Waar je het vindt Dit staat meestal in de kop van de leveranciersfactuurtabel, zoals VendInvoiceInfoTable, gekoppeld aan de belangrijkste leveranciersstamdata in VendTable. Voorbeelden V-1001V-2050V-8342
	Vervaldatum betaling PaymentDueDate	De datum waarop de factuur volgens de afgesproken betalingsvoorwaarden moet zijn betaald.
Beschrijving De vervaldatum van de betaling wordt berekend op basis van de factuurdatum en de betalingsvoorwaarden van de leverancier. De datum vormt de contractuele deadline voor betaling. Deze datum is belangrijk voor het meten van financiële prestaties en het beheren van leveranciersrelaties. Hij vormt de basis voor de KPI 'On-Time Payment Rate', die de datum vergelijkt met de werkelijke datum van 'Payment Executed'. Met deze analyse kun je structurele oorzaken van te late betalingen vinden. Die kunnen leiden tot slechtere leveranciersrelaties of gemiste kortingen voor vroeg betalen. Waarom dit belangrijk is Dit is de benchmark voor het meten van tijdige betalingen, een belangrijke KPI voor financiële gezondheid en leveranciersrelaties. Waar je het vindt Deze datum wordt vaak door het systeem berekend en opgeslagen in de transactietabel voor leveranciers, zoals VendTrans, op basis van de factuurdatum en betalingsvoorwaarden. Voorbeelden 2023-05-152023-06-302023-07-20
	Afdeling Department	Het kostenplaatsnummer of de afdeling waaraan de factuurkosten worden toegewezen.
Beschrijving De afdeling identificeert de bedrijfseenheid of kostenplaats die verantwoordelijk is voor de kosten op de factuur. Dit wordt meestal bepaald tijdens de activiteit voor het coderen van de factuur. Door het proces per afdeling te analyseren, krijg je zicht op verschillen in uitgaven, goedkeuringstijden en compliance. Je ziet welke afdelingen de meeste factuuruitzonderingen of de langste goedkeuringscycli hebben. Dat biedt een basis voor gerichte communicatie en training. Waarom dit belangrijk is Maakt kosten- en procesanalyse per afdeling mogelijk en laat verschillen in prestaties en compliance binnen de organisatie zien. Waar je het vindt Komt uit financiële dimensies die aan de factuurregels of de kop zijn gekoppeld. Hiervoor moet je de datastructuren voor dimensies raadplegen. Voorbeelden VerkoopMarketingIT-bedrijfsvoering
	Bedrijfscode CompanyCode	De identificatie van de juridische entiteit of het bedrijf binnen de organisatie dat de factuur verwerkt.
Beschrijving De bedrijfscode staat voor de specifieke juridische entiteit die financieel verantwoordelijk is voor de factuur. In een organisatie met meerdere bedrijven is dit een belangrijk dataveld voor financiële segmentatie. Met dit attribuut kun je procesanalyses filteren op of vergelijken tussen verschillende juridische entiteiten. Zo zie je of prestaties, beleid of knelpunten specifiek zijn voor bepaalde bedrijven binnen de groep. Dat ondersteunt gerichte procesverbetering per bedrijf. Waarom dit belangrijk is Maakt procesanalyse per juridische entiteit mogelijk. Dat is belangrijk voor grote organisaties met meerdere bedrijven. Waar je het vindt Dit is een standaardveld in de meeste financiële tabellen van Dynamics 365 en heet vaak DataAreaId. Voorbeelden USMFDEMFGBSI
	Betaling op tijd IsOnTimePayment	Een berekende vlag die aangeeft of een factuur op of vóór de vervaldatum is betaald.
Beschrijving Dit booleaanse attribuut wordt afgeleid door de timestamp van de activiteit 'Payment Executed' te vergelijken met de 'Payment Due Date'. Als de betaaldatum kleiner dan of gelijk aan de vervaldatum is, is de waarde true. Anders is de waarde false. Dit attribuut ondersteunt rechtstreeks de KPI 'On-Time Payment Rate' en het dashboard 'Payment Terms Compliance'. Het vereenvoudigt de analyse met een duidelijke binaire uitkomst per factuur. Zo kun je eenvoudig te late betalingen filteren en de oorzaken onderzoeken per leverancier, afdeling of land. Waarom dit belangrijk is Meet rechtstreeks of aan de betalingsvoorwaarden wordt voldaan en vereenvoudigt de berekening van de KPI On-Time Payment Rate en bijbehorende analyses. Waar je het vindt Dit attribuut wordt berekend in de data-transformatielaag. De logica is: (Timestamp van de activiteit 'Payment Executed') <= (Payment Due Date). Voorbeelden truefalse
	Betalingsvoorwaarden PaymentTerms	De afgesproken betalingsvoorwaarden met de leverancier, zoals 'Net 30' of '2% 10, Net 30'.
Beschrijving De betalingsvoorwaarden bepalen de afgesproken condities voor het betalen van de leverancier, waaronder de betalingstermijn en eventuele kortingen. Deze informatie komt meestal uit de stamgegevens van de leverancier of de inkooporder. Dit attribuut geeft belangrijke context bij de vervaldatum van de betaling en de KPI On-Time Payment Rate. Door te analyseren of bepaalde betalingsvoorwaarden samenhangen met te late betalingen, kun je operationele problemen vinden. Ook helpt dit bij financiële planning en effectief werkkapitaalbeheer. Waarom dit belangrijk is Geeft context bij vervaldata van betalingen en helpt de financiële impact van het betalingstijdstip en het benutten van kortingen te analyseren. Waar je het vindt Deze informatie staat in de leveranciersstam (VendTable) en wordt gekopieerd naar transactietabellen zoals VendInvoiceInfoTable. Voorbeelden Netto 30Netto 602% 10, netto 30
	Factuurvaluta InvoiceCurrency	De valutacode voor het factuurbedrag, bijvoorbeeld USD of EUR.
Beschrijving De factuurvaluta geeft aan in welke valuta het factuurbedrag is uitgedrukt. Dit is belangrijk voor multinationale organisaties die met leveranciers uit verschillende landen werken. Dit attribuut geeft de nodige context bij het factuurbedrag en wordt gebruikt voor filtering en rapportage, vooral in internationale bedrijfsvoering. Zo worden financiële waarden correct geïnterpreteerd en kun je analyses per valuta uitvoeren of bedragen omrekenen naar een standaardrapportagevaluta. Waarom dit belangrijk is Het geeft belangrijke context bij financiële bedragen, zodat je factuurwaarden uit verschillende regio's correct kunt interpreteren en analyseren. Waar je het vindt Dit staat in de factuurkoptabel naast het factuurbedrag, bijvoorbeeld in het veld CurrencyCode van VendInvoiceInfoTable. Voorbeelden USDEURGBP
	Is geautomatiseerd IsAutomated	Een vlag die aangeeft of een activiteit automatisch door het systeem of handmatig door een gebruiker is uitgevoerd.
Beschrijving Dit booleaanse attribuut (true/false) maakt onderscheid tussen gebeurtenissen die door het systeem zijn uitgevoerd en handmatige gebruikerstaken. Zo kan het matchen van een factuur geautomatiseerd zijn, terwijl het afhandelen van een afwijking handmatig gebeurt. Met dit attribuut krijg je zicht op de automatiseringsgraad van het proces. Je kunt het succes van automatiseringsinitiatieven meten, resterende handmatige knelpunten vinden en kansen voor verdere automatisering herkennen. Zo verbeter je de efficiëntie en verminder je fouten. Waarom dit belangrijk is Helpt de automatiseringsgraad van het proces te meten en handmatige knelpunten en kansen voor efficiëntieverbetering te vinden. Waar je het vindt Dit wordt meestal afgeleid van het attribuut 'User'. Als de gebruiker een bekend systeem- of serviceaccount is, wordt deze vlag op true gezet. Voorbeelden truefalse
	Reden betalingsblokkade PaymentBlockReason	De reden die verklaart waarom een betalingsblokkade op een factuur is toegepast.
Beschrijving Een betalingsblokkade voorkomt dat een factuur wordt betaald. Dit attribuut legt de reden voor de blokkade vast. Meestal is dit een gestandaardiseerde code die een gebruiker selecteert, zoals 'Betwiste kosten' of 'Wachten op goederenontvangst'. Dit attribuut is essentieel voor het dashboard 'Payment Block Frequency & Duration'. Door de meest voorkomende redenen voor betalingsblokkades te analyseren, vind je onderliggende problemen in het P2P-proces. Door deze oorzaken op te lossen, kun je betalingsvertragingen sterk verminderen en leveranciersrelaties verbeteren. Waarom dit belangrijk is Legt uit waarom betalingen bewust worden uitgesteld. Zo kun je problemen eerder in het proces vinden en oplossen die betalingsblokkades veroorzaken. Waar je het vindt Dit is meestal een veld in de leverancierstransactie of de factuurregistratie en hangt vaak samen met de status van de betalingsblokkade. Kijk in tabellen zoals VendTrans. Voorbeelden KwaliteitsgeschilIn afwachting van creditnotaHandmatige blokkering
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft voor het afwijzen van een factuur.
Beschrijving Wanneer een factuur tijdens de goedkeuringsworkflow wordt afgewezen, geeft de goedkeurder meestal een reden op. Dit attribuut legt die toelichting vast. Dat kan een vooraf gedefinieerde code of vrije tekst zijn. Dit is een belangrijk attribuut voor het dashboard 'Invoice Rejection Analysis'. Het geeft de kwalitatieve informatie die nodig is om de oorzaken van afwijzingen te begrijpen, zoals 'Onjuist PO-nummer', 'Dubbele factuur' of 'Prijsverschil'. Met deze analyse kun je acties prioriteren om het afwijzingspercentage te verlagen. Waarom dit belangrijk is Geeft rechtstreeks inzicht in de redenen waarom facturen worden afgewezen. Zo kun je gerichte acties nemen om herstelwerk te verminderen en het first-time-right-percentage te verbeteren. Waar je het vindt Dit staat meestal in opmerkingen of historielogboeken van workflowverwerkingstabellen. Voorbeelden Onjuist aantalDubbele factuurGoedkeuringslimiet overschreden
	Totale doorlooptijd TotalCycleTime	De totale doorlooptijd van begin tot eind voor het verwerken van één factuur, van ontvangst tot betaling.
Beschrijving De totale doorlooptijd meet hoelang een factuur in het volledige proces zit. Je berekent dit als het tijdsverschil tussen de allereerste activiteit, bijvoorbeeld 'Invoice Registered', en de allerlaatste activiteit, bijvoorbeeld 'Payment Executed', voor een bepaald factuurnummer. Dit is een belangrijke KPI voor het meten van de algehele procesefficiëntie. Het geeft een overzicht op hoofdlijnen en wordt gebruikt in het dashboard 'Invoice End-to-End Cycle Time'. Door trends in deze metriek te analyseren en te segmenteren op attributen zoals leverancier of bedrag, vind je brede kansen voor verbetering. Waarom dit belangrijk is Dit is de belangrijkste KPI op hoofdlijnen voor de snelheid en efficiëntie van het totale proces. De KPI vat de prestaties per factuur samen. Waar je het vindt Dit wordt op case-niveau 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 afwijking MatchingDiscrepancyType	Classificeert het type verschil dat tijdens het matchen van de factuur met de inkooporder is gevonden.
Beschrijving Wanneer tijdens 2-way- of 3-way-matching een afwijking ontstaat, geeft dit attribuut aan wat voor probleem het is, bijvoorbeeld 'Prijsverschil', 'Hoeveelheidsverschil' of 'Ontbrekende goederenontvangst'. Deze data is de basis voor het dashboard 'Matching Discrepancy Resolution Time'. Door de frequentie van verschillende afwijkingstypen te analyseren, kan de organisatie de oorzaken van mislukte matches vinden. Veel prijsverschillen kunnen bijvoorbeeld wijzen op verouderde stamgegevens, terwijl hoeveelheidsverschillen op problemen met verzending kunnen duiden. Waarom dit belangrijk is Classificeert mislukte matches. Zo kun je de oorzaken analyseren, het aantal afwijkingen verlagen en straight-through processing verbeteren. Waar je het vindt Dit kan in een aparte tabel voor matching of uitzonderingen staan. Het kan ook nodig zijn om het af te leiden uit statusberichten of workflowopmerkingen. Voorbeelden PrijsverschilVerschil in aantalOntbrekende goederenontvangst

Verplicht Aanbevolen Optioneel

Purchase to Pay - activiteiten voor factuurverwerking

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log vastlegt voor een nauwkeurige ontdekking en analyse van je factuurworkflow.

6 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Betaling uitgevoerd	Dit is de laatste activiteit. Het betalingsjournaal wordt geboekt, de betaling wordt aangemaakt en de factuur wordt afgeletterd. Dit expliciete transactionele event sluit de levenscyclus van de factuur af.
Waarom dit belangrijk is Deze activiteit markeert het succesvolle einde van het factuur-tot-betalingsproces. De activiteit vormt de basis voor het meten van het 'Percentage betalingen op tijd' en de totale end-to-enddoorlooptijd. Waar je het vindt Dit is een expliciet event dat wordt vastgelegd bij het boeken van het betalingsjournaal. De afwikkelingsinformatie wordt opgeslagen in tabellen zoals VendSettlement, waarmee de betaling aan de factuur wordt gekoppeld. Vastleggen Boekingstimestamp van het betalingsjournaal waarmee de leverancierstransactie wordt afgeletterd. Eventtype explicit
	Factuur geboekt	Dit is het formele boekhoudkundige event waarbij de goedgekeurde factuur in het grootboek wordt opgenomen en een verplichting ontstaat. Het is een expliciet transactioneel event in het systeem.
Waarom dit belangrijk is Boeken is de laatste stap vóór betaling en een belangrijk financieel controlemoment. De tijd tussen 'Factuur goedgekeurd' en 'Factuur geboekt' meet de efficiëntie van de laatste boekhoudkundige stappen. Waar je het vindt Dit is een expliciet event dat 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 met leverancierstransacties, VendTrans. Eventtype explicit
	Factuur gematcht met inkooporder	Dit staat voor het succesvol afronden van het matchingproces. De factuurgegevens komen dan overeen met de inkooporder en de ontvangst van de goederen. Dit event wordt afgeleid wanneer de matchingstatus van de factuur wordt bijgewerkt naar 'Passed'.
Waarom dit belangrijk is Een succesvolle match is een belangrijk moment voor facturen met een inkooporder. Het bevestigt dat de kosten kloppen voordat de factuur wordt betaald. Dit is belangrijk om de efficiëntie van matching en de automatiseringsgraad te volgen. Waar je het vindt Dit wordt afgeleid uit de update van het veld voor de matchingstatus op de kop of regels van de leveranciersfactuur, bijvoorbeeld VendInvoiceInfoTable, naar de waarde 'Passed' of 'Successfully Matched'. Vastleggen Timestamp van de statuswijziging naar 'Passed' in de validatiedetails van de factuurmatching. Eventtype inferred
	Factuur geregistreerd	Dit is de eerste registratie van een factuur in het systeem. Er wordt een voorlopig record aangemaakt voordat alle details 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 de officiële start van de levenscyclus van de factuur. Door de tijd vanaf dit moment te analyseren, kun je de totale verwerkingsduur meten en vertragingen aan het begin van het proces vinden. Waar je het vindt Dit is een expliciet event dat 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. Eventtype explicit
	Factuur goedgekeurd	Dit staat voor de definitieve, succesvolle goedkeuring van de factuur in de workflow. De factuur is daarmee goedgekeurd voor boeking en betaling. De workflow-engine registreert dit expliciet bij het afronden van de workflow.
Waarom dit belangrijk is Dit is een belangrijk moment dat het goedkeuringsproces afsluit. De tijd tussen 'Factuur ter goedkeuring verzonden' en dit event is een belangrijke maatstaf voor de efficiëntie van goedkeuring en helpt bottlenecks te vinden. Waar je het vindt Dit is een expliciet event in de workflowhistorietabellen, bijvoorbeeld WorkflowTrackingStatusTable, wanneer de workflowstatus verandert naar 'Approved'. Vastleggen Timestamp van de statusvermelding 'Approved' in de workflowhistorie. Eventtype explicit
	Factuur ter goedkeuring verzonden	Deze activiteit markeert het formeel indienen van een factuur in een workflow voor controle en goedkeuring. De workflow-engine van Dynamics 365 registreert dit indienevent expliciet.
Waarom dit belangrijk is Dit is het startpunt voor het meten van de volledige goedkeuringscyclus. Je ziet hiermee hoe lang facturen wachten voordat het goedkeuringsproces begint. Het event vormt ook de basis voor KPI's rond goedkeuring. Waar je het vindt Dit is een expliciet event in de workflowhistorietabellen, bijvoorbeeld WorkflowTrackingStatusTable, wanneer een factuur bij een workflow wordt ingediend. Vastleggen Aanmaaktimestamp van het record voor de workflowindiening in de workflowhistorie. Eventtype explicit
	Betaling ingepland	Deze activiteit vindt plaats wanneer een geboekte factuur wordt opgenomen in een betalingsvoorstel of betalingsjournaal, maar voordat de betaling wordt uitgevoerd. Het is een expliciete actie 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, kun je vertragingen tussen het boeken van de factuur en het starten van de betaling vinden. Waar je het vindt Dit is een expliciet event dat wordt vastgelegd wanneer een regel in een betalingsjournaal, LedgerJournalTrans, wordt aangemaakt om de geboekte leverancierstransactie af te wikkelen. Vastleggen Aanmaaktimestamp van de betalingsjournaalregel die naar de factuur verwijst. Eventtype explicit
	Betalingsblokkade ingesteld	Deze activiteit vindt plaats wanneer een blokkade op een factuur wordt gezet, waardoor betaling niet mogelijk is. Dit wordt vastgelegd door een wijziging in het veld voor de betalingsblokkade of wachtstatus op het geboekte factuurrecord.
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 en de relatie met leveranciers verbeteren. Waar je het vindt Dit wordt afgeleid uit een wijziging in het veld voor de betalingsblokkade of wachtstatus op de geboekte leverancierstransactie, VendTrans. De timestamp kan uit het wijzigingslog worden gehaald. Vastleggen Timestamp van de update waarmee het veld voor de betalingsblokkade op de leverancierstransactie wordt ingesteld. Eventtype inferred
	Betalingsblokkade opgeheven	Dit staat voor het verwijderen van een betalingsblokkade, zodat de factuur kan worden ingepland voor betaling. Dit wordt vastgelegd wanneer het veld voor de betalingsblokkade wordt leeggemaakt of verandert naar een niet-geblokkeerde status.
Waarom dit belangrijk is Hiermee meet je hoe lang het duurt om problemen achter betalingsblokkades op te lossen. Een lange tijd tussen het instellen en opheffen van een blokkade wijst op een inefficiënt oplossingsproces. Waar je het vindt Dit wordt afgeleid uit een wijziging waarmee het veld voor de betalingsblokkade of wachtstatus op de geboekte leverancierstransactie, VendTrans, wordt leeggemaakt. De timestamp kan uit het wijzigingslog komen. Vastleggen Timestamp van de update waarmee het veld voor de betalingsblokkade op de leverancierstransactie wordt leeggemaakt. Eventtype inferred
	Factuur afgewezen	Dit betekent dat een goedkeurder de factuur heeft afgewezen. Het proces stopt en de factuur wordt meestal teruggestuurd voor correctie. De workflow-engine registreert deze afwijzing expliciet.
Waarom dit belangrijk is Door afwijzingen te volgen, kun je herstelwerk meten en veelvoorkomende oorzaken vinden, zoals onjuiste codering of beleidsovertredingen. Dit ondersteunt rechtstreeks de KPI 'Percentage afgewezen facturen'. Waar je het vindt Dit is een expliciet event in de workflowhistorietabellen, bijvoorbeeld WorkflowTrackingStatusTable, wanneer de workflowstatus verandert naar 'Rejected' of 'Canceled'. Vastleggen Timestamp van de statusvermelding 'Rejected' in de workflowhistorie. Eventtype explicit
	Factuur gecodeerd	Deze activiteit betekent dat grootboekrekeningverdelingen zijn toegewezen aan de factuurregels. Meestal wordt dit afgeleid uit het aanmaken of afronden van grootboekrekeningverdelingen die aan de factuur zijn gekoppeld.
Waarom dit belangrijk is Codering is belangrijk voor financiële nauwkeurigheid. Door de benodigde tijd voor het coderen van facturen te meten, vind je bottlenecks in het boekhoudkundige controleproces en ondersteun je de KPI 'Gemiddelde tijd van dataregistratie tot codering'. Waar je het vindt Dit wordt afgeleid uit het aanmaken en valideren van records in tabellen voor boekhoudkundige verdelingen, bijvoorbeeld AccountingDistribution, die aan de openstaande leveranciersfactuur zijn gekoppeld. Vastleggen Timestamp waarop de boekhoudkundige verdelingen voor de factuur zijn opgeslagen en gevalideerd. Eventtype inferred
	Factuurdata vastgelegd	Dit staat voor het afronden van de gegevensinvoer voor de factuur, inclusief kop- en regelgegevens, voordat de factuur wordt ingediend voor matching of goedkeuring. Vaak wordt dit afgeleid wanneer de factuurstatus verandert 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 geautomatiseerd met OCR. Vertragingen op dit punt kunnen doorwerken in het hele proces. Waar je het vindt Dit wordt afgeleid uit statuswijzigingen op het record van de openstaande leveranciersfactuur, bijvoorbeeld VendInvoiceInfoTable. Het event vindt plaats wanneer alle verplichte velden zijn ingevuld en de factuur klaar is voor de volgende stap. Vastleggen Detecteer de statuswijziging in de tabel met openstaande facturen die aangeeft dat de gegevensinvoer is afgerond. Eventtype inferred
	Matchingsverschil gevonden	Deze activiteit vindt plaats wanneer het factuurmatchingproces mislukt door verschillen tussen de factuur, inkooporder of goederenontvangst. Het event wordt vastgelegd wanneer de matchingstatus van de factuur op 'Failed' of 'Discrepancy' wordt gezet.
Waarom dit belangrijk is Door vast te leggen wanneer en waarom verschillen ontstaan, kun je de KPI 'Percentage matchingsverschillen' berekenen. Deze activiteit markeert het begin van het oplossingsproces, dat vaak voor flinke vertraging zorgt. Waar je het vindt Dit wordt afgeleid uit de update van het veld voor de matchingstatus op de leveranciersfactuur, bijvoorbeeld VendInvoiceInfoTable, naar de waarde 'Failed'. De reden voor de fout wordt vaak ook vastgelegd. Vastleggen Timestamp van de statuswijziging naar 'Failed' of 'Discrepancy' tijdens de matching. Eventtype inferred
	Matchingsverschil opgelost	Dit markeert het oplossen van een eerder gevonden matchingsverschil, zodat de factuur verder kan. Het event wordt afgeleid wanneer een factuur met de matchingstatus 'Failed' opnieuw succesvol wordt gematcht of handmatig wordt vrijgegeven.
Waarom dit belangrijk is Deze activiteit sluit het deelproces voor het oplossen van het verschil af. De tijd tussen 'Matchingsverschil gevonden' en dit event is een belangrijke KPI voor de efficiëntie van de oplossing. Waar je het vindt Dit wordt afgeleid uit een succesvol matchingevent ('Factuur gematcht met inkooporder') dat na een event 'Matchingsverschil gevonden' voor dezelfde factuur plaatsvindt. Vastleggen Identificeer een timestamp met de matchingstatus 'Passed' die volgt op een timestamp met de status 'Failed'. Eventtype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Microsoft Dynamics 365

Stappen

Ga naar de Data Management Workspace: Meld je aan bij Microsoft Dynamics 365 Finance. Gebruik de zoekbalk om de workspace Data management te vinden en te openen.
Maak een nieuw exportproject: Selecteer in de workspace de tegel Export om een nieuw data-exportproject te maken. Geef het project een duidelijke naam, bijvoorbeeld ProcessMind_Invoice_Processing_Export.
Definieer het dataproject: Geef op het tabblad Algemeen van het nieuwe project de Data format op. CSV is een veelgebruikte en aanbevolen indeling. Stel de overige parameters naar behoefte in.
Voeg de vereiste data-entiteiten toe: Ga naar de sectie Selected entities en klik op Add entity. Zoek de volgende centrale entiteiten en voeg ze één voor één toe. Geef voor elke entiteit de gewenste doelindeling op.
- VendInvoiceInfoTableEntity (kop van leveranciersfactuur)
- VendInvoiceTransEntity (factuurregels van leverancier)
- VendInvoiceRegisterHeaderEntity (kop van factuurregisterjournaal)
- WorkflowTrackingStatusTableEntity (workflowgeschiedenis)
- AccountingDistributionEntity (grootboekverdelingen)
- VendInvoiceJour (geboekte leveranciersfacturen)
- VendTrans (leverancierstransacties, voor betalingsblokkades)
- LedgerJournalTransVendPaymEntity (regels van leveranciersbetalingsjournaal)
- VendSettlement (vereffeningstransacties van leveranciers)
Pas filters toe: Pas voor elke entiteit filters toe om de scope van de data te beperken. Selecteer een entiteit en klik op Filter. Filter minimaal op Company (juridische entiteit) en op een specifieke periode via een relevant datumveld, zoals CREATEDDATETIME of INVOICEDATE. Voor een eerste analyse is een periode van de afgelopen 3 tot 6 maanden gebruikelijk.
Configureer entiteitskoppelingen: Controleer voor elke entiteit de koppeling van bron naar doel. Zorg dat alle velden die nodig zijn voor het definitieve event log in de export zijn opgenomen. In deze fase zijn meestal geen complexe wijzigingen in de koppeling nodig.
Voer de exporttaak uit: Klik, zodra alle entiteiten zijn toegevoegd en gefilterd, op Export in het actievenster om de taak te starten. Je kunt de taak meteen uitvoeren of plannen buiten piekuren om de systeembelasting te beperken.
Download de geëxporteerde data: Ga na een geslaagde export naar de taakgeschiedenis. Daar kun je het geëxporteerde datapakket downloaden, met afzonderlijke bestanden voor elke data-entiteit.
Zet de data om in een event log: De geëxporteerde bestanden zijn momentopnamen van entiteiten, geen geconsolideerd event log. Gebruik een externe tool, zoals een database, Python-script of Power Query, om de bestanden te verwerken en samen te voegen. De conceptuele query in de sectie query bevat de volledige logica voor deze transformatie.
Voer de transformatieregels uit: Laad de geëxporteerde CSV-bestanden in de gekozen transformatieomgeving. Voer de meegeleverde transformatiequery uit. Deze voegt data uit alle bronbestanden samen tot één eventlogtabel met één rij per bedrijfsactiviteit.
Rond af en upload: Exporteer de definitieve getransformeerde data naar één CSV-bestand. Controleer of de kolomkoppen aan de vereisten voldoen, bijvoorbeeld InvoiceNumber, ActivityName en EventTime. Het bestand kan nu naar ProcessMind worden geüpload.

Configuratie

Data-entiteiten: De kern van de configuratie is het selecteren van de juiste entiteiten voor de volledige levenscyclus van de factuur. Belangrijke entiteiten zijn VendInvoiceInfoTableEntity, VendInvoiceJour en WorkflowTrackingStatusTableEntity.
Dataformaat voor export: Selecteer CSV als doelformaat, zodat je de data in de volgende omzettingsstappen eenvoudig kunt verwerken.
Filteren op bedrijf: Filter elke data-entiteit op de specifieke rechtspersoon die je analyseert. Zo voorkom je dat je irrelevante data ophaalt.
Filteren op periode: Pas op alle relevante entiteiten, zoals VendInvoiceInfoTableEntity en VendInvoiceJour, dezelfde periodefilter toe op basis van aanmaak- of boekingsdatums. Begin met een recente periode, bijvoorbeeld de laatste 6 maanden, om de hoeveelheid data beheersbaar te houden.
Volledige push versus incrementeel: Voer bij de eerste extractie een volledige push uit. Voor volgende vernieuwingen kun je een incrementele export instellen die alleen data ophaalt die sinds de vorige run is gewijzigd. Zo verkort je de verwerkingstijd.
Vereisten: De gebruiker die de export uitvoert, moet de juiste beveiligingsrollen in Dynamics 365 hebben. Meestal gaat het om Data management administrator of een vergelijkbare rol met toegang tot de vereiste data-entiteiten.

a 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: configureer BYOD: Zorg dat de functie Bring Your Own Database is geconfigureerd voor je Microsoft Dynamics 365 Finance and Operations-omgeving. Dit houdt in dat je een Azure SQL Database instelt en D365 configureert om data daarheen te exporteren.
Identificeer data-entiteiten: Ga in D365 naar de workspace Data management. Voor deze extractie exporteer je specifieke data-entiteiten. Zorg dat de volgende entiteiten zijn opgenomen in een exporttaak naar je BYOD-database: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements en Accounting distributions.
Maak een exporttaak en plan deze in: Maak in de workspace Data management een nieuw exportproject. Voeg de bovenstaande entiteiten toe. Stel je BYOD-database in als doelformaat. Plan de exporttaak terugkerend in, bijvoorbeeld dagelijks of elk uur, zodat de data in je BYOD actueel blijft.
Controleer de data in Azure SQL: Maak verbinding met je Azure SQL Database via een tool zoals SQL Server Management Studio (SSMS) of Azure Data Studio. Controleer of de tabellen voor de D365-entiteiten zijn aangemaakt en data bevatten.
Bereid de SQL-query voor: Kopieer de meegeleverde SQL-query. Deze query is bedoeld om rechtstreeks uit te voeren op de tabellen die het BYOD-exportproces in je Azure SQL Database heeft aangemaakt.
Maak verbinding en voer de query uit: Open een nieuw queryvenster in je SQL-client, verbonden met BYOD. Plak de gekopieerde SQL-query in het venster.
Stel de queryparameters in: Zoek de variabelen met tijdelijke waarden bovenaan het script. Vervang {StartDate}, {EndDate} en {CompanyCode} door respectievelijk de gewenste begindatum, einddatum en identificatie van de rechtspersoon. Bijvoorbeeld: SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Voer de query uit: Voer het volledige SQL-script uit. De query verzamelt data uit meerdere tabellen en voegt deze samen tot een chronologisch event log voor elke factuur.
Controleer de resultaten: De uitvoer is één tabel met het event log en kolommen voor InvoiceNumber, ActivityName, EventTime en andere opgegeven attributen. Controleer of de resultaten correct en volledig zijn.
Exporteer het event log: Exporteer de queryresultaten naar een CSV-bestand. De meeste SQL-clients hebben een ingebouwde functie om resultaten naar een bestand op te slaan. Gebruik UTF-8-codering.
Bereid de upload voor: Controleer vóór het uploaden naar een process mining-tool of het CSV-bestand exact de koppen uit de query bevat (InvoiceNumber, ActivityName, enzovoort). De bestandsstructuur hoeft niet verder te worden aangepast.

Configuratie

Belangrijke data-entiteiten: Voor deze extractie worden verschillende D365-data-entiteiten naar BYOD geëxporteerd. Belangrijke entiteiten zijn VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution en VendTrans.
Filteren op periode: De meegeleverde query bevat de parameters @StartDate en @EndDate. Begin bij voorkeur met een beperkte periode, bijvoorbeeld 3 tot 6 maanden, om de prestaties te bewaken. De 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 één specifieke rechtspersoon of bedrijfscode, zodat de juiste datacontext wordt gebruikt.
BYOD-verversingsfrequentie: Hoe actueel de data is, hangt volledig af van de planning van de D365-exporttaak. Voor analyse die bijna realtime is, is een hoge frequentie nodig, bijvoorbeeld elk uur. Dat kan gevolgen hebben voor de prestaties en kosten van zowel D365 als Azure.
Vereisten: Voor deze methode heb je een actief Azure-abonnement, een ingerichte Azure SQL Database en beheerderstoegang in D365 nodig om de workspace Data management te configureren.

a 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 nieuwer op je systeem is geïnstalleerd. Installeer de benodigde bibliotheken met pip: pip install pandas requests msal. Deze bibliotheken gebruik je voor dataverwerking, HTTP-aanroepen naar de API en authenticatie via het Microsoft identity platform.
Registreer een applicatie in Azure Active Directory: Om je te authenticeren bij de Dynamics 365 API, moet je een applicatie registreren in de Azure AD-tenant van je organisatie. Maak een nieuwe App Registration, genereer een client secret en noteer de Application (client) ID, Directory (tenant) ID en waarde van het client secret.
Ken API-machtigingen toe: 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 voor deze machtigingen admin consent geven.
Maak een applicatiegebruiker in Dynamics 365: Ga in je Dynamics 365-omgeving naar System administration > Users > Users. Maak een nieuwe gebruiker en vul de Application (client) ID uit de Azure App Registration in bij het veld Application ID. Ken deze gebruiker de juiste beveiligingsrollen toe, zoals 'System administrator', of een beperktere rol met leestoegang tot alle vereiste data-entiteiten.
Configureer het Python-script: Kopieer het meegeleverde Python-script naar een bestand, bijvoorbeeld extract_invoices.py. Open het bestand en werk de tijdelijke waarden bovenaan bij met de URL van je Dynamics 365-omgeving, tenant ID, client ID, client secret en bedrijfscode (dataAreaId) waaruit je data wilt ophalen.
Stel de periode in: Pas de variabelen START_DATE en END_DATE in het script aan om de periode voor de data-extractie vast te leggen. Begin bij voorkeur met een korte periode, bijvoorbeeld één maand, om het script te testen en de resultaten te controleren.
Voer het script uit: Start het script vanaf de opdrachtregel of terminal met de opdracht python extract_invoices.py. Het script authenticeert zich, bevraagt de verschillende OData-endpoints voor elke activiteit en verwerkt de data.
Houd de uitvoering in de gaten: Het script toont voortgangsberichten in de console terwijl het data voor elke activiteit ophaalt. Dit kan afhankelijk van de periode en hoeveelheid data behoorlijk wat tijd kosten. Let op foutmeldingen die kunnen wijzen op problemen met authenticatie of API-toegang.
Controleer het uitvoerbestand: Na een succesvolle uitvoering maakt het script in dezelfde map een CSV-bestand met de naam d365_invoice_event_log.csv. Dit bestand bevat het geconsolideerde event log.
Bereid de upload voor: Open het CSV-bestand en controleer of de indeling klopt. Controleer of alle vereiste kolommen (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) aanwezig en gevuld zijn. Je kunt het bestand nu uploaden naar ProcessMind.

Configuratie

Authenticatie: Het script gebruikt de OAuth 2.0-clientcredentialsflow. Je moet een Azure AD App Registration configureren en API-machtigingen voor Dynamics 365 toekennen. In Dynamics 365 zelf moet je ook een applicatiegebruiker met de juiste beveiligingsrollen aanmaken.
API-endpoint: De basis-URL voor de Dynamics 365 Finance and Operations OData API. De indeling is meestal https://[your-d365-environment-name].operations.dynamics.com.
Periode: Het script bevat de variabelen START_DATE en END_DATE. Deze filteren records op aanmaak- of wijzigingsdatum om de hoeveelheid data te beperken. Voor een eerste extractie wordt een periode van 3 tot 6 maanden aanbevolen.
Bedrijfsfilter: Filter de data op één 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 Dynamics 365 OData-entiteiten, waaronder VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines en VendSettlements. Bij sterk aangepaste processen kunnen aangepaste entiteiten nodig zijn.
Paginering: Het script verwerkt gepagineerde antwoorden van de API automatisch via de eigenschap @odata.nextLink, zodat alle records voor de opgegeven periode worden opgehaald.

a 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 betreffende Dynamics 365-omgeving en de bronentiteiten of tabellen met gegevens over leveranciersfacturen, factuurregels, grootboekverdelingen, inkooporders, ontvangsten, workflows, betalingsblokkades, boekingen en betalingsjournalen. Omdat Dynamics 365-implementaties verschillen, leg je de werkelijke bronobjecten vast in een mappingwerkmap. Gebruik tijdelijke aanduidingen zoals [Your invoice register table] en [Your workflow event table] totdat de objectspecifieke bronnen zijn bevestigd.
Maak in Power Platform een Dataflow in de workspace of omgeving die je voor de ProcessMind-extractie gebruikt. Selecteer de connector die past bij je Dynamics 365-implementatie en configureer de verbinding met [Your connection string or environment reference] en [Your credentials]. Zet geen inloggegevens in de querytekst.
Voeg in Power Query de bronentiteiten toe die je voor de extractie nodig hebt. Koppel minimaal het factuurregister, de factuurkop, factuurregels, grootboekverdeling, het resultaat van de koppeling met inkooporder of ontvangst, workflowgeschiedenis, geschiedenis van betalingsblokkades, boekingstransactie, betalingsvoorstel of betalingsjournaalregel en betalingsvereffeningsbronnen. Noteer de werkelijke 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. Behoud timestamps uit de bron met voldoende precisie om gebeurtenissen te ordenen. Gebruik voor EventTime timestamps uit het bronsysteem, niet timestamps van de vernieuwing.
Maak een genormaliseerde event-query 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. Laat ProcessMind dus geen ontbrekende activiteiten afleiden.
Koppel elke gebeurtenisbron aan de factuurcase via InvoiceNumber. Als een bron een interne factuursleutel gebruikt, koppel je die eerst aan de factuurkop of het register en neem je de zakelijke InvoiceNumber over. Behoud VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate en EndTime waar beschikbaar. Gebruik voor elke bronkolom een gedocumenteerde mapping die specifiek is voor de omgeving.
Pas voorwaarden per gebeurtenis toe. Registratie vereist dat een leveranciersfactuurrecord wordt aangemaakt. Data capture vereist de geconfigureerde overgang van een nieuwe of geregistreerde status naar een status die klaar is voor verwerking. Codering vereist het aanmaken of voltooien van grootboekverdelingen. Een geslaagde matching vereist de uitkomst Passed. Een mislukte matching vereist Failed of Discrepancy. Afhandeling van een afwijking vereist een latere succesvolle hermatching of een gedocumenteerde handmatige correctie. Indienen, goedkeuren en afwijzen in de workflow vereisen expliciete workflowgebeurtenissen. Gebeurtenissen rond betalingsblokkades vereisen een wijziging in de blokkeringsstatus. Boeken, inplannen en uitvoeren vereisen expliciete boekings-, betalingsjournaal- of vereffeningsrecords.
Standaardiseer 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. Stel LastDataUpdate voor alle rijen in een vernieuwing consistent in op de timestamp van de dataflowvernieuwing of de bronextractie.
Verwijder rijen zonder InvoiceNumber of EventTime, tenzij een goedgekeurd uitzonderingsproces een stabiele case-identificatie toekent. Verwijder dubbele rijen alleen wanneer dubbele bronrecords dezelfde gebeurtenis vertegenwoordigen. Gebruik waar beschikbaar de brongebeurtenis-ID. Voeg afzonderlijke herhaalde goedkeuringen, matchingpogingen, blokkades of betalingsacties niet samen.
Laad de genormaliseerde uitvoer naar de geconfigureerde bestemming, zoals een Power Platform-databestemming, lakehouse, datawarehouse of bestandsbestemming die door de implementatie wordt ondersteund. Exporteer of publiceer het resultaat als een platte tabel met één gebeurtenis per rij en de vereiste 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 ActivityName-waarden aanwezig zijn wanneer de bijbehorende bronrecords bestaan, of de timestamps in de juiste volgorde staan en of de case-identificatie InvoiceNumber is. Exporteer de gevalideerde tabel in een door ProcessMind ondersteund formaat, zoals CSV of de geconfigureerde connectoruitvoer, en upload deze naar ProcessMind of maak de verbinding. Gebruik InvoiceNumber als case-identificatie, ActivityName als activiteit en EventTime als event-timestamp.

Configuratie

Bronmapping: Vervang elke tijdelijke aanduiding die specifiek is voor de omgeving door de werkelijke Dynamics 365-entiteiten, tabellen, weergaven en kolommen. Ga er niet van uit dat namen gelijk zijn in Finance, Supply Chain Management, Dataverse, aanpassingen of integraties.
Vereiste uitvoerkolommen: InvoiceNumber, ActivityName, EventTime, SourceSystem en LastDataUpdate moeten voor elke geaccepteerde eventrij zijn gevuld.
Aanbevolen uitvoerkolommen: Neem VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate en EndTime op wanneer de bron deze gegevens levert.
Periode: Begin met 3 tot 6 maanden historie. Breid de periode pas uit nadat je de queryprestaties en volledigheid van de gebeurtenissen hebt gecontroleerd. Gebruik waar mogelijk een inclusieve begingrens en exclusieve eindgrens om dubbele gebeurtenissen tussen vernieuwingen te voorkomen.
Filter op bedrijf of rechtspersoon: Pas [Your company or legal entity filter] consequent toe op alle bronentiteiten. Zorg dat joins geen facturen van verschillende rechtspersonen combineren wanneer InvoiceNumber niet wereldwijd uniek is.
Filter op documenttype: Beperk de extractie tot leveranciersfacturen en de documenttypen die het proces gebruikt. Stel dit in op basis van het systeem en ga niet uit van een specifieke Dynamics 365-waarde.
Statusfilters: Gebruik de geconfigureerde waarden voor new, registered, ready for processing, Passed, Failed, Discrepancy, approved, rejected, blocked en unblocked. Statuslabels kunnen verschillen per versie, taal, aanpassing of integratie.
Betekenis van gebeurtenissen: Extraheer voor elke vereiste activiteit een expliciete rij. Afgeleide activiteiten zijn alleen toegestaan wanneer de genoemde bronovergang of het bronrecord betrouwbaar bewijs levert. ProcessMind leidt geen gebeurtenissen af uit andere rijen.
Keuze van timestamp: Gebruik bij voorkeur de timestamp van de gebeurtenis in de bron. Gebruik aanmaak-, wijzigings-, workflowactie-, boekings-, journaal- of vereffeningstimestamps volgens de definitie van de gebeurtenis. Gebruik LastDataUpdate niet als EventTime.
Vernieuwingsmetadata: Vul LastDataUpdate met één consistente timestamp voor de dataflowrun. Als de bestemming incrementeel vernieuwen ondersteunt, bewaar de vernieuwingswatermark dan afzonderlijk van EventTime.
Incrementeel vernieuwen: Gebruik een stabiele bronwatermark, zoals een wijzigingstimestamp of gebeurtenis-ID uit de bron, en neem een terugkijkperiode op voor laat binnenkomende workflow-, matching- en betalingsgebeurtenissen. Verwijder dubbele rijen waar mogelijk op basis van brongebeurtenis-ID's.
Prestaties: Filter bronentiteiten vóór joins, selecteer alleen vereiste kolommen, voorkom het onbeperkt uitvouwen van factuurregels en zet grote bronnen afzonderlijk klaar. Gebruik query folding wanneer de connector dit ondersteunt. Deel grote perioden op of vernieuw ze incrementeel.
Joinsleutels: Gebruik InvoiceNumber alleen wanneer dit uniek is binnen de geselecteerde onderneming of rechtspersoon. Gebruik anders de omgevingsspecifieke samengestelde sleutel en neem InvoiceNumber op in de uiteindelijke uitvoer.
Vereisten: Je hebt machtigingen nodig voor de Dynamics 365-data, workflowgeschiedenis, boekings- en betalingsdata en de Power Platform-dataflow en -bestemming. Vereiste licenties en beschikbare connectors hangen af van de tenant, Dynamics 365-implementatie en gekozen bestemming.
Beveiliging: Gebruik beheerde verbindingen of goedgekeurde inloggegevens, pas het principe van minimale toegang toe en zet geen geheimen in Power Query-expressies of geëxporteerde bestanden.
Valuta en bedragen: Behoud de bronvaluta of voeg de omgevingsspecifieke valutakolom toe als financiële analyse dit vereist. Zet bedragen niet om tenzij er een goedgekeurde regel voor wisselkoersen is vastgelegd.

a 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 je process mining-traject en krijg inzicht in snellere en nauwkeurigere factuurverwerking. Begin vandaag nog met het verbeteren van je bedrijfsvoering.

Terug naar de verbetergids Template downloaden

Begin vandaag met het optimaliseren van Purchase to Pay - Invoice Processing

Breng inefficiënties aan het licht 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.

Jouw datatemplate voor Purchase to Pay-factuurverwerking

Jouw datatemplate voor Purchase to Pay-factuurverwerking

Purchase to Pay - attributen voor factuurverwerking

Purchase to Pay - activiteiten voor factuurverwerking

Extractiegidsen

Export via het Data Management Framework van Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

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

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met de Dynamics 365 OData REST API

Stappen

Configuratie

a Voorbeeldquery python

Data-extractie met een Microsoft Power Platform Dataflow

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Begin vandaag met het optimaliseren van Purchase to Pay - Invoice Processing

Jouw datatemplate voor Purchase to Pay-factuurverwerking

Jouw datatemplate voor Purchase to Pay-factuurverwerking

Purchase to Pay - attributen voor factuurverwerking

Purchase to Pay - activiteiten voor factuurverwerking

Extractiegidsen

Export via het Data Management Framework van Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

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

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met de Dynamics 365 OData REST API

Stappen

Configuratie

a Voorbeeldquery python

Data-extractie met een Microsoft Power Platform Dataflow

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Begin vandaag met het optimaliseren van Purchase to Pay - Invoice Processing

We respecteren je privacy