> Continue verbetering > Purchase to Pay Factuurverwerking > Microsoft Dynamics 365 > datatemplate

Uw Purchase to Pay - Factuurverwerking Data Template

Microsoft Dynamics 365

Purchase to Pay - Factuurverwerkingsattributen (23) Purchase to Pay - Factuurverwerkingsactiviteiten (14) Extractie Guides (4)

Uw Purchase to Pay - Factuurverwerking Data Template

Deze template biedt een duidelijke handleiding voor het extraheren van de essentiële `data` die nodig is om uw Purchase to Pay - Factuurverwerking in Microsoft Dynamics 365 te analyseren. Het schetst de cruciale `attributes` om te verzamelen, de belangrijkste activiteiten om te volgen, en praktische begeleiding voor `data` extractie. Gebruik deze `resource` om ervoor te zorgen dat u alle benodigde informatie verzamelt voor uitgebreide procesanalyse en optimalisatie.

Aanbevolen `attributes` om te verzamelen voor diepgaande analyse
Belangrijke activiteiten om te volgen gedurende de gehele levenscyclus van factuurverwerking
Richtlijnen voor het extraheren van data uit Microsoft Dynamics 365

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

Template downloaden

Purchase to Pay - Factuurverwerkingsattributen

Dit zijn de aanbevolen `data fields` om op te nemen in uw `event log` voor een uitgebreide analyse van uw Purchase to Pay - Factuurverwerking.

5 Verplicht 7 Aanbevolen 11 Optioneel

	Naam	Omschrijving
	Activiteitsnaam ActivityName	De naam van het specifieke zakelijke `event` of de taak dat op een bepaald moment binnen de levenscyclus van factuurverwerking plaatsvond.
Omschrijving De Activiteitsnaam beschrijft een specifieke stap of statuswijziging in het factuurproces, zoals 'Factuur Geregistreerd', 'Factuur Ter Goedkeuring Verzonden' of 'Betaling Uitgevoerd'. Deze `data` is cruciaal voor het construeren van de proceskaart en het begrijpen van de opeenvolging van `events`. Analyse van dit `attribute` onthult de processtroom, identificeert veelvoorkomende paden en belicht afwijkingen of knelpunten. Het wordt gebruikt om doorlooptijden tussen activiteiten te berekenen, zoals de duur van goedkeuring tot boeking, en om de frequentie van specifieke `events` zoals afwijzingen of betalingsblokkades te meten. Het belang Het definieert de stappen in de proceskaart, waardoor visualisatie van de processtroom en analyse van overgangen tussen verschillende activiteiten mogelijk wordt. Vindplaats Dit `attribute` wordt doorgaans afgeleid uit een combinatie van statusvelden, transactietypes of `change log entries` binnen verschillende Dynamics 365-tabellen gerelateerd aan factuurverwerking. Voorbeelden Factuur ter goedkeuring verzondenMatchingafwijking GevondenBetaling Uitgevoerd
	Factuurnummer InvoiceNumber	De unieke identificatie voor elke leveranciersfactuur, die dient als de primaire `case ID` voor het volgen van de levenscyclus.
Omschrijving Het Factuurnummer is de unieke sleutel die alle activiteiten koppelt aan één enkele leveranciersfactuur. Het maakt end-to-end tracering mogelijk van het traject van de factuur, van ontvangst en registratie tot matching, goedkeuring en uiteindelijke betaling. In process mining-analyse is dit `attribute` fundamenteel. Het definieert de `case`, waardoor de reconstructie van de processtroom van elke factuur mogelijk wordt. Dit maakt de berekening van totale doorlooptijden, identificatie van procesvarianten en analyse van factuurspecifieke kenmerken en resultaten mogelijk. Het belang Dit is de essentiële `Case ID` die alle gerelateerde `events` verbindt, waardoor het mogelijk is de gehele levenscyclus van elke individuele factuur te analyseren. Vindplaats Dit wordt doorgaans gevonden in de hoofdtabel voor leveranciersfacturen, zoals `VendInvoiceInfoTable`, `field Num`. Voorbeelden INV-10056773245-AUS-001-98432
	Tijdstip Gebeurtenis EventTime	De precieze timestamp die aangeeft wanneer een specifieke activiteit of event heeft plaatsgevonden.
Omschrijving Event Time, of de timestamp, registreert de exacte datum en tijd waarop een activiteit plaatsvond. Dit is een cruciaal onderdeel van het event log en biedt de temporele sequentie die nodig is om activiteiten correct te ordenen en looptijden te berekenen. In analyse is deze timestamp de basis voor alle tijdgerelateerde metrics. Het wordt gebruikt om de duur van activiteiten, de doorlooptijd tussen verschillende stappen (bijv. goedkeuringstijd) en de totale end-to-end verwerkingstijd voor elke factuur te berekenen. Het maakt ook trendanalyse over de tijd mogelijk. Het belang Deze `timestamp` is essentieel voor het ordenen van `events`, het berekenen van alle doorlooptijden en duren, en het identificeren van procesknelpunten. Vindplaats Dit wordt afgeleid uit verschillende datum/tijd `fields` in meerdere tabellen, zoals de `createdDateTime` of `modifiedDateTime fields` in tabellen zoals `VendInvoiceInfoTable`, `VendTrans` of `workflow history tables`. Voorbeelden 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Bronsysteem SourceSystem	Het bronsysteem waaruit de event data is geëxtraheerd.
Omschrijving Dit `attribute` identificeert de bronapplicatie waar de activiteit `data` is ontstaan. Voor dit proces zal dit doorgaans 'Microsoft Dynamics 365' zijn. In omgevingen met meerdere systemen, zoals een externe OCR- of vastleggingsoplossing, helpt dit veld te differentiëren waar elke stap van het proces plaatsvindt. Het zorgt voor een duidelijke `data lineage` en helpt bij het oplossen van problemen met `data` extractie. Het belang Het biedt cruciale context over de herkomst van data, wat belangrijk is voor datavalidatie en het begrip van het systeemlandschap van het proces. Vindplaats Dit is een statische waarde, 'Microsoft Dynamics 365', toegevoegd tijdens `data transformation` om de herkomst van de `dataset` te labelen. Voorbeelden Microsoft Dynamics 365
	Laatste data-update LastDataUpdate	De `timestamp` die aangeeft wanneer de `data` voor dit proces voor het laatst is ververst vanuit het bronsysteem.
Omschrijving Dit `attribute` registreert wanneer de `dataset` voor het laatst is geëxtraheerd en bijgewerkt vanuit Microsoft Dynamics 365. Het is doorgaans hetzelfde voor alle records binnen een enkele `data load`. Deze informatie is van vitaal belang voor gebruikers om de actualiteit van de `data` die ze analyseren te begrijpen. Het biedt context voor hoe actueel de procesinzichten zijn en is essentieel voor het beheren van `data refresh schedules` en het valideren van `data pipelines`. Het belang Informeert gebruikers over de actualiteit van de data, zodat ze weten hoe recent de analyse is en wanneer de volgende data-update wordt verwacht. Vindplaats Deze `timestamp` wordt gegenereerd en gestempeld op de `dataset` door het `data extraction` of ETL-proces op het moment van uitvoering. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Eindtijd EndTime	De precieze `timestamp` die aangeeft wanneer een specifieke activiteit of `event` is voltooid.
Omschrijving De Eindtijd registreert wanneer een activiteit is voltooid. In combinatie met de Starttijd (`EventTime`) maakt het een precieze berekening mogelijk van hoe lang elke individuele stap duurde om te voltooien. Dit `attribute` is essentieel voor het berekenen van de 'ProcessingTime' voor elke activiteit, een belangrijke `metric` voor prestatieanalyse. Het helpt precies aan te wijzen welke stappen in het proces de meeste tijd verbruiken, wat gerichte verbeteringsinspanningen mogelijk maakt. Zo kan het de exacte duur van een handmatige coderings- of goedkeuringsstap meten. Het belang Maakt de directe berekening van activiteitsverwerkingstijden mogelijk, wat fundamenteel is voor het identificeren van de meest tijdrovende stappen in het proces. Vindplaats Net als de StartTime wordt dit afgeleid uit verschillende datum/tijd-velden. Voor sommige activiteiten kan dit de StartTime zijn van de volgende activiteit. In andere gevallen kan het een specifieke 'completed on'-timestamp zijn. Voorbeelden 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Factuurbedrag InvoiceAmount	Het totale factuurbedrag.
Omschrijving Dit `attribute` vertegenwoordigt het totale verschuldigde bedrag zoals vermeld op de leveranciersfactuur. Het is een fundamenteel financieel `datapunt` voor elke `case`. Factuurbedrag wordt veelvuldig gebruikt voor segmentatie en analyse. Het kan onthullen of facturen met een hoge waarde een ander, strenger goedkeuringsproces volgen of dat ze langer duren om te verwerken. Het wordt ook gebruikt in `dashboards` om factuurvolumes per waarde te analyseren en kan worden geaggregeerd om de totale uitgaven onder analyse te begrijpen. Het belang Maakt analyse mogelijk op basis van financiële waarde, wat helpt bij het prioriteren van procesverbeteringsinspanningen op waardevolle facturen en het begrijpen van kostendrijvers. Vindplaats Gevonden in de factuurkop-tabel, bijvoorbeeld VendInvoiceInfoTable, in een veld zoals InvoiceAmount of Amount. Voorbeelden 1500.00250.7512500.50
	Factuurstatus InvoiceStatus	De huidige status van de factuur op het moment van data-extractie.
Omschrijving De Factuurstatus geeft de huidige staat van een factuur binnen de levenscyclus aan, zoals 'Wachtend op Goedkeuring', 'Goedgekeurd', 'Geboekt' of 'Betaald'. Dit biedt een momentopname van de voortgang van de factuur. Dit `attribute` wordt voornamelijk gebruikt voor het creëren van operationele `dashboards` die de huidige werkdruk en achterstand tonen. Het helpt managers te begrijpen hoeveel facturen zich in elke fase van het proces bevinden, ter ondersteuning van resource-allocatie en operationele monitoring. Het is cruciaal voor het 'Invoice Processing Throughput & Status' `dashboard`. Het belang Biedt een actueel overzicht van alle facturen, essentieel voor operationele monitoring, werkdrukbeheer en het identificeren van actuele knelpunten. Vindplaats Dit wordt doorgaans afgeleid uit statusvelden op de hoofdfactuurtabel, zoals `VendInvoiceInfoTable`. Voorbeelden In afwachting van goedkeuringGeboektBetaald
	Gebruiker User	De gebruikers-ID of naam van de persoon die de activiteit uitvoerde.
Omschrijving Dit `attribute` identificeert de medewerker of systeemgebruiker die verantwoordelijk is voor het uitvoeren van een specifieke processtap. Voor geautomatiseerde stappen kan dit een systeem- of serviceaccount zijn. Het analyseren van het proces per gebruiker helpt bij het begrijpen van de werkdrukverdeling, het identificeren van trainingsbehoeften en het vergelijken van prestaties tussen individuen of teams. Het is cruciaal voor het analyseren van `rework loops` (herbewerkingslussen), waarbij werk heen en weer wordt gestuurd tussen gebruikers, en voor het begrijpen van variaties in hoe verschillende gebruikers dezelfde taak voltooien. Het belang Het maakt analyse van prestaties en werkdruk per gebruiker of team mogelijk, en helpt bij het identificeren van automatiseringsniveaus en oorzaken van herbewerking. Vindplaats Afgeleid uit gebruikers-ID-velden in transactie- of `workflow history tables`, zoals `createdby` of `modifiedby` velden. Deze informatie kan zich bevinden in de `workflow tracking tables`. Voorbeelden j.doea.smithAX_Admin
	Inkoopordernummer PurchaseOrderNumber	De identificatie van de Inkooporder (PO) waaraan de factuur gerelateerd is.
Omschrijving Het Inkoopordernummer koppelt een factuur aan het originele inkoopdocument. Dit is cruciaal voor processen die 2-weg of 3-weg matching omvatten tussen de factuur, PO en goederenontvangst. Dit `attribute` maakt analyse mogelijk van PO- versus niet-PO-facturen, die vaak verschillende procespaden volgen. Het is essentieel voor het begrijpen van de effectiviteit van het matchingproces, het onderzoeken van matchingafwijkingen en het meten van de ratio van geautomatiseerde verwerking voor PO-gesteunde facturen. Het belang Het onderscheidt facturen met een inkooporder (PO) van facturen zonder inkooporder, wat een belangrijke oorzaak is van procesvariatie en cruciaal is voor matchinganalyse. Vindplaats Te vinden in de factuurheader-tabel, zoals VendInvoiceInfoTable, vaak in een veld zoals PurchId. Voorbeelden PO-001234PO-005678PO-009101
	Leveranciersnummer VendorNumber	De unieke identificatie voor de leverancier of toeleverancier die de factuur heeft ingediend.
Omschrijving Het Leveranciersnummer is de `code` die een leverancier uniek identificeert in de stamdata. Het koppelt de factuurtransactie aan een specifieke leverancier, wat leveranciersgerichte analyse mogelijk maakt. Dit `attribute` is essentieel voor het segmenteren van de procesdata per leverancier. Het helpt vragen te beantwoorden zoals 'Welke leveranciers hebben de langste goedkeuringstijden?' of 'Komen matchingafwijkingen vaker voor bij bepaalde leveranciers?'. Het analyseren van prestaties per leverancier kan kansen blootleggen voor leverancierssamenwerking en procesverbetering. Het belang Maakt filtering en grondoorzaakanalyse per leverancier mogelijk, wat helpt bij het identificeren van prestatieproblemen of patronen die gekoppeld zijn aan specifieke leveranciers. Vindplaats Dit wordt doorgaans gevonden in de header van de leveranciersfactuurtabel, zoals `VendInvoiceInfoTable`, gekoppeld aan de hoofdleveranciersstamdata in `VendTable`. Voorbeelden V-1001V-2050V-8342
	Uiterste betaaldatum PaymentDueDate	De datum waarop de factuur betaald zou moeten zijn volgens de overeengekomen betalingsvoorwaarden.
Omschrijving De Betalingsvervaldatum wordt berekend op basis van de factuurdatum en de betalingsvoorwaarden van de leverancier. Het vertegenwoordigt de contractuele deadline voor betaling. Deze datum is cruciaal voor het meten van financiële prestaties en leveranciersrelatiebeheer. Het is de basislijn die wordt gebruikt om de 'On-Time Payment Rate' KPI te berekenen door deze te vergelijken met de feitelijke 'Payment Executed' datum. Het analyseren hiervan helpt bij het identificeren van systemische problemen die leiden tot late betalingen, wat kan leiden tot beschadigde leveranciersrelaties of gemiste kortingen bij vroegtijdige betaling. Het belang Dit is de benchmark voor het meten van tijdige betalingsprestaties, een belangrijke KPI voor financiële gezondheid en leveranciersrelaties. Vindplaats Deze datum wordt vaak door het systeem berekend en opgeslagen in de leverancierstransactietabel, zoals VendTrans, op basis van factuurdatum en betalingsvoorwaarden. Voorbeelden 2023-05-152023-06-302023-07-20
	`Total Cycle Time` TotalCycleTime	De totale end-to-end duur voor het verwerken van één enkele factuur, van ontvangst tot betaling.
Omschrijving Totale doorlooptijd meet de gehele duur die een factuur in het proces doorbrengt. Het wordt berekend als het tijdsverschil tussen de allereerste activiteit (bijv. 'Factuur Geregistreerd') en de allerlaatste activiteit (bijv. 'Betaling Uitgevoerd') voor een gegeven factuurnummer. Dit is een primaire KPI voor het meten van de algehele procesefficiëntie. Het biedt een overzicht op hoog niveau van de prestaties en wordt gebruikt in het 'Invoice End-to-End Cycle Time' `dashboard`. Het analyseren van trends in deze `metric` en het segmenteren ervan op `attributes` zoals leverancier of bedrag helpt bij het identificeren van brede verbetermogelijkheden. Het belang Vertegenwoordigt de belangrijkste high-level KPI voor de algehele processnelheid en efficiëntie, die de prestaties voor elke factuur samenvat. Vindplaats Dit wordt berekend op `case`-niveau binnen de process mining tool of tijdens `data preparation`. Het is het tijdsverschil tussen de eerste en laatste `event timestamps` voor elke `CaseId`. Voorbeelden P15DP22DT5H30MP7D
	Afdeling Department	Het kostenplaats of de afdeling waaraan de factuurkosten worden toegewezen.
Omschrijving De Afdeling identificeert de bedrijfseenheid of kostenplaats die verantwoordelijk is voor de kosten op de factuur. Dit wordt meestal bepaald tijdens de factuurcoderingsactiviteit. Het analyseren van het proces per afdeling is essentieel voor het begrijpen van afdelingsverschillen in uitgaven, goedkeuringstijden en compliance. Het helpt te identificeren welke afdelingen de meeste factuuruitzonderingen of de langste goedkeuringscycli hebben, wat een basis biedt voor gerichte communicatie en training. Het belang Maakt kosten- en procesanalyse per afdeling mogelijk, waarbij variaties in prestaties en compliance binnen de organisatie worden belicht. Vindplaats Afgeleid van financiële dimensies gekoppeld aan de factuurregels of header. Dit vereist het opvragen van de dimensiegerelateerde datastructuren. Voorbeelden VerkoopMarketingIT Operations
	Bedrijfscode CompanyCode	De identificatie voor de juridische entiteit of het bedrijf binnen de organisatie die de factuur verwerkt.
Omschrijving De Bedrijfscode vertegenwoordigt de specifieke juridische entiteit die financieel verantwoordelijk is voor de factuur. In een multi-company organisatie is dit een kritiek datapunt voor financiële segmentatie. Dit `attribute` maakt het mogelijk om procesanalyse te filteren of te vergelijken tussen verschillende juridische entiteiten. Het kan onthullen of procesprestaties, beleid of knelpunten specifiek zijn voor bepaalde bedrijven binnen de groep, wat gelokaliseerde procesverbeteringsinitiatieven ondersteunt. Het belang Maakt procesanalyse mogelijk die gesegmenteerd kan worden per juridische entiteit, wat cruciaal is voor grote, multi-company organisaties. Vindplaats Dit is een standaard `field` in de meeste financiële tabellen in Dynamics 365, vaak genaamd `DataAreaId`. Voorbeelden USMFDEMFGBSI
	Betalingstermijnen PaymentTerms	De betalingsvoorwaardenovereenkomst met de leverancier, zoals 'Netto 30' of '2% 10, Netto 30'.
Omschrijving Betalingsvoorwaarden definiëren de overeengekomen condities voor het betalen van de leverancier, inclusief de termijn en eventuele kortingen. Deze informatie wordt doorgaans afgeleid uit de leveranciersstamdata of de inkooporder. Dit `attribute` biedt cruciale context voor de Betalingsvervaldatum en de On-Time Payment Rate KPI. Het analyseren of bepaalde betalingsvoorwaarden correleren met late betalingen kan operationele uitdagingen blootleggen. Het helpt ook bij financiële planning en effectief werkkapitaalbeheer. Het belang Biedt context voor betalingsvervaldata en helpt de financiële impact van betalingstiming en kortingsbenutting te analyseren. Vindplaats Deze informatie is opgeslagen in de leveranciersstam (`VendTable`) en gekopieerd naar transactietabellen zoals `VendInvoiceInfoTable`. Voorbeelden Netto 30Netto 602% binnen 10 dagen, netto 30 dagen
	Bewerkingstijd ProcessingTime	De duur van een enkele activiteit, berekend als het verschil tussen de eind- en starttijd.
Omschrijving Verwerkingstijd meet de actieve tijd die aan een specifieke taak wordt besteed. Het wordt berekend door de StartTime van een `event` af te trekken van de EndTime. Dit wordt ook wel activiteitsduur genoemd. Deze `metric` is fundamenteel voor prestatieanalyse. Het helpt te identificeren welke specifieke activiteiten het meest tijdrovend zijn, in tegenstelling tot wachttijden tussen activiteiten. Dit maakt gerichte verbeteringen mogelijk, zoals het bieden van betere training om handmatige codering te versnellen of het optimaliseren van een systeemstap die traag verloopt. Het belang Meet de daadwerkelijke werkduur van activiteiten, wat helpt bij het identificeren van inefficiënte taken die rijp zijn voor optimalisatie of automatisering. Vindplaats Dit is geen `field` in het bronsysteem. Het wordt berekend tijdens `data transformation` met behulp van de formule: `EndTime` - `StartTime`. Voorbeelden PT1H30MP2DT4HPT5M15S
	Factuurvaluta InvoiceCurrency	De valutacode van het factuurbedrag (bijv. USD, EUR).
Omschrijving De Factuurvaluta specificeert de valuta waarin het factuurbedrag is uitgedrukt. Dit is belangrijk voor multinationale organisaties die werken met leveranciers uit verschillende landen. Dit `attribute` biedt de nodige context voor het Factuurbedrag en wordt gebruikt voor filtering en rapportage, met name in mondiale operaties. Het zorgt ervoor dat financiële waarden correct worden geïnterpreteerd en maakt valutaspecifieke analyse of conversie naar een standaard rapportagevaluta mogelijk. Het belang Biedt essentiële context voor financiële bedragen, wat een nauwkeurige interpretatie en analyse van factuurwaarden in verschillende regio's mogelijk maakt. Vindplaats Te vinden in de factuurheader-tabel naast het factuurbedrag, bijvoorbeeld het veld CurrencyCode in de VendInvoiceInfoTable. Voorbeelden USDEURGBP
	Is Geautomatiseerd IsAutomated	Een indicator die aangeeft of een activiteit automatisch door het systeem is uitgevoerd of door een gebruiker.
Omschrijving Dit booleaanse `attribute` (waar/onwaar) onderscheidt systeem-uitgevoerde `events` en handmatige gebruikerstaken. Bijvoorbeeld, een factuurmatchingstap kan geautomatiseerd zijn, terwijl afwijkingsafhandeling handmatig is. Het analyseren van dit `attribute` is essentieel voor het begrijpen van het automatiseringsniveau in het proces. Het helpt het succes van automatiseringsinitiatieven te meten, identificeert resterende handmatige knelpunten en benadrukt kansen voor verdere automatisering om de efficiëntie te verbeteren en fouten te verminderen. Het belang Helpt het niveau van automatisering in het proces te meten, identificeert handmatige knelpunten en kansen voor efficiëntiewinst. Vindplaats Dit wordt doorgaans afgeleid op basis van het 'User' `attribute`. Als de gebruiker een bekend systeem- of serviceaccount is, wordt deze `flag` ingesteld op `true`. Voorbeelden truefalse
	Is Tijdige Betaling IsOnTimePayment	Een berekende vlag die aangeeft of een factuur op of voor de vervaldatum is betaald.
Omschrijving Dit booleaanse `attribute` wordt afgeleid door de `timestamp` van de activiteit 'Payment Executed' te vergelijken met de 'Payment Due Date'. Als de betalingsdatum kleiner is dan of gelijk is aan de vervaldatum, is de waarde waar, anders is deze onwaar. Dit `attribute` ondersteunt direct de 'On-Time Payment Rate' KPI en het 'Payment Terms Compliance' `dashboard`. Het vereenvoudigt de analyse door een duidelijke binaire uitkomst voor elke factuur te bieden, waardoor het gemakkelijk wordt om te filteren op late betalingen en hun hoofdoorzaken per leverancier, afdeling of land te onderzoeken. Het belang Meet direct de compliance met betalingsvoorwaarden, wat de berekening van de 'Tijdige betalingspercentage' KPI en gerelateerde analyses vereenvoudigt. Vindplaats Dit `attribute` wordt berekend in de `data transformation layer`. De logica is: (Timestamp van 'Payment Executed' activiteit) <= (Payment Due Date). Voorbeelden truefalse
	Reden betalingsblokkade PaymentBlockReason	De reden (`code`) die verklaart waarom een betalingsblokkade op een factuur is toegepast.
Omschrijving Een betalingsblokkade voorkomt dat een factuur wordt betaald. Dit attribuut legt de reden voor de blokkade vast, wat meestal een gestandaardiseerde code is die door een gebruiker is geselecteerd, zoals 'Betwiste kosten' of 'Wachten op goederenontvangst'. Dit attribuut is essentieel voor het 'Betalingsblokkade frequentie & duur' dashboard. Het analyseren van de meest voorkomende redenen voor betalingsblokkades helpt onderliggende problemen in het P2P-proces te identificeren. Het oplossen van deze grondoorzaken kan betalingsvertragingen aanzienlijk verminderen en leveranciersrelaties verbeteren. Het belang Verklaart waarom betalingen opzettelijk worden vertraagd, wat helpt bij het identificeren en oplossen van upstream problemen die betalingsblokkades veroorzaken. Vindplaats Dit is doorgaans een `field` op de leverancierstransactie- of factuurrecord, vaak gerelateerd aan de betalingsblokkadestatus. Zoek in tabellen zoals `VendTrans`. Voorbeelden KwaliteitsgeschilWacht op creditnotaHandmatige blokkade
	Reden van afwijzing RejectionReason	De reden die door een fiatteur is opgegeven voor het afkeuren van een factuur.
Omschrijving Wanneer een factuur wordt afgewezen tijdens de goedkeuringsworkflow, geeft de goedkeurder doorgaans een reden op. Dit kenmerk legt die verklaring vast, wat een vooraf gedefinieerde code of vrije tekst kan zijn. Dit is een essentieel kenmerk voor het 'Invoice Rejection Analysis' dashboard. Het biedt de kwalitatieve inzichten die nodig zijn om de grondoorzaken van afwijzingen te doorgronden, zoals 'Onjuist Bestelnummer', 'Dubbele Factuur' of 'Prijsverschil'. Het analyseren van deze redenen helpt u bij het prioriteren van acties om het afwijzingspercentage te verlagen. Het belang Biedt direct inzicht in waarom facturen worden afgekeurd, waardoor gerichte acties mogelijk zijn om herbewerking te verminderen en 'first-time-right' percentages te verbeteren. Vindplaats Doorgaans te vinden in de `comments` of `history logs` van de `workflow processing tables`. Voorbeelden Incorrecte kwantiteitDubbele factuurGoedkeuringslimiet overschreden
	Type afwijking MatchingDiscrepancyType	Categoriseert het type mismatch dat is gevonden tijdens het matchingproces van facturen en inkooporders.
Omschrijving Wanneer een afwijking optreedt tijdens 2-weg of 3-weg matching, specificeert dit `attribute` de aard van het probleem, bijvoorbeeld 'Prijsafwijking', 'Hoeveelheidsafwijking' of 'Ontbrekende Goederenontvangst'. Deze `data` is cruciaal voor het 'Matching Discrepancy Resolution Time' `dashboard`. Door de frequentie van verschillende afwijkingstypes te analyseren, kan het bedrijf de hoofdoorzaken van matchingfouten identificeren. Bijvoorbeeld, frequente prijsafwijkingen kunnen wijzen op problemen met verouderde stamdata, terwijl hoeveelheidsafwijkingen kunnen duiden op verzendproblemen. Het belang Het categoriseert matchingfouten, waardoor oorzaakanalyse mogelijk wordt om het aantal afwijkingen te verminderen en de geautomatiseerde verwerking te verbeteren. Vindplaats Dit kan worden opgeslagen in een speciale matching- of uitzonderingen `log table`, of het moet mogelijk worden afgeleid uit statusberichten of `workflow comments`. Voorbeelden PrijsafwijkingHoeveelheidsafwijkingOntbrekende goederenontvangst

Verplicht Aanbevolen Optioneel

Purchase to Pay - Factuurverwerkingsactiviteiten

Dit zijn de belangrijkste processtappen en mijlpalen om in je event log vast te leggen voor een nauwkeurige discovery en analyse van de workflow voor factuurverwerking.

6 Aanbevolen 8 Optioneel

	Activiteit	Omschrijving
	Betaling Uitgevoerd	Dit is de laatste activiteit, die het boeken van het betalingsjournaal vertegenwoordigt, dat de betaling creëert en de factuur vereffent. Dit is een expliciet transactioneel `event` dat de factuurlevenscyclus afsluit.
Het belang Deze activiteit markeert het succesvolle einde van het 'invoice-to-pay' proces. Het is de basis voor het meten van de 'On-Time Payment Rate' en de totale end-to-end doorlooptijd. Vindplaats Dit is een expliciet `event` vastgelegd bij het boeken van het betalingsjournaal. De vereffeningsinformatie wordt vastgelegd in tabellen zoals `VendSettlement`, die de betaling aan de factuur koppelen. Vastleggen Boekings-timestamp van het betalingsjournaal dat de leverancierstransactie vereffent. Gebeurtenistype explicit
	Factuur geboekt	Dit is het formele boekhoudkundige `event` waarbij de goedgekeurde factuur in het Grootboek wordt opgenomen, waardoor een verplichting ontstaat. Dit is een expliciet, transactioneel `event` in het systeem.
Het belang Boeken is de laatste stap vóór betaling en een cruciaal financieel controlepunt. De tijd van 'Invoice Approved' tot 'Invoice Posted' meet de efficiëntie van de laatste boekhoudkundige stappen. Vindplaats Dit is een expliciet `event` vastgelegd bij de aanmaak van de geboekte leverancierstransactie in tabellen zoals `VendTrans` en de bijbehorende `GeneralJournalEntry` en `LedgerEntry` records. Vastleggen Aanmaak timestamp van de record in de leverancierstransactietabel (VendTrans). Gebeurtenistype explicit
	Factuur gematcht met inkooporder	Vertegenwoordigt de succesvolle voltooiing van het matchingproces, waarbij factuurdetails overeenkomen met de inkooporder- en goederenontvangstinformatie. Dit `event` wordt afgeleid wanneer de matchingstatus van de factuur wordt bijgewerkt naar 'Passed'.
Het belang Succesvolle matching is een belangrijke mijlpaal voor PO-gesteunde facturen, die de geldigheid van de kosten vóór betaling bevestigt. Het is essentieel voor het bijhouden van matching-efficiëntie en automatiseringspercentages. Vindplaats Afgeleid van de update van het matching statusveld op de leveranciersfactuurkop of -regels (bijv. VendInvoiceInfoTable) naar een 'Geslaagd' of 'Succesvol gematcht' waarde. Vastleggen Timestamp van de statuswijziging naar 'Passed' in de factuurmatching validatiedetails. Gebeurtenistype inferred
	Factuur geregistreerd	Dit is de initiële invoer van een factuur in het systeem, waardoor een placeholder record wordt gecreëerd voordat de volledige details worden verwerkt. Deze activiteit wordt vastgelegd wanneer een nieuwe record wordt aangemaakt in het leveranciersfactuurregisterjournaal.
Het belang Deze activiteit markeert de officiële start van de levenscyclus van factuurverwerking. Het analyseren van de tijd vanaf dit punt helpt de totale verwerkingsduur te meten en identificeert vertragingen in de vroege fase. Vindplaats Dit is een expliciet `event` vastgelegd bij de aanmaak van een record in het leveranciersfactuurregister, doorgaans in de `VendInvoiceRegisterJournalTable` of een vergelijkbare tabel voor openstaande facturen. Vastleggen Aanmaak timestamp van de record in het leveranciersfactuurregisterjournaal. Gebeurtenistype explicit
	Factuur Goedgekeurd	Vertegenwoordigt de definitieve, succesvolle goedkeuring van de factuur binnen de `workflow`, die deze autoriseert voor boeking en betaling. Dit is een expliciet `event` dat door de `workflow engine` wordt gelogd bij voltooiing.
Het belang Dit is een kritieke mijlpaal die het goedkeuringsproces afsluit. De tijd van 'Factuur Ter Goedkeuring Verzonden' tot dit `event` is een belangrijke maatstaf voor goedkeuringsefficiëntie en helpt knelpunten te identificeren. Vindplaats Dit is een expliciet `event` gelogd in de `workflow history tables` (bijv. `WorkflowTrackingStatusTable`) wanneer de `workflow` status verandert naar 'Approved'. Vastleggen Timestamp van de 'Approved' statusvermelding in de `workflow history`. Gebeurtenistype explicit
	Factuur ter goedkeuring verzonden	Deze activiteit markeert de formele indiening van een factuur in een `workflow` voor beoordeling en goedkeuring. De Dynamics 365 `workflow engine` registreert expliciet dit indienings `event`.
Het belang Dit is het startpunt voor het meten van de gehele goedkeuringscyclus. Het helpt te identificeren hoe lang facturen wachten voordat het goedkeuringsproces überhaupt begint en is de trigger voor goedkeuringsgerelateerde KPI's. Vindplaats Dit is een expliciet `event` gelogd in de `workflow history tables` (bijv. `WorkflowTrackingStatusTable`) wanneer een factuur wordt ingediend bij een `workflow`. Vastleggen Aanmaak timestamp van de workflow indieningsrecord in de workflowgeschiedenis. Gebeurtenistype explicit
	Betaling ingepland	Deze activiteit vindt plaats wanneer een geboekte factuur wordt opgenomen in een betalingsvoorstel of een betalingsjournaal, maar voordat de betaling wordt uitgevoerd. Het is een expliciete actie die een betalingsjournaalregel creëert.
Het belang Dit markeert de overgang van Crediteuren naar Treasury-activiteiten. Het analyseren van deze stap kan vertragingen tussen factuurboeking en betalingsinitiatie onthullen. Vindplaats Dit is een expliciet `event` vastgelegd bij de aanmaak van een regel in een betalingsjournaal (`LedgerJournalTrans`) dat de geboekte leverancierstransactie vereffent. Vastleggen Aanmaak timestamp van de betalingsjournaalregel die verwijst naar de factuur. Gebeurtenistype explicit
	Betalingsblokkade Ingesteld	Deze activiteit vindt plaats wanneer een blokkade op een factuur wordt geplaatst, waardoor deze niet kan worden betaald. Dit wordt vastgelegd door een wijziging in het betalingsblokkade- of holdstatusveld op de geboekte factuurrecord.
Het belang Betalingsblokkades zijn een primaire oorzaak van late betalingen. Het analyseren van wanneer en waarom ze worden ingesteld is cruciaal voor het verbeteren van de tijdige betalingsprestaties en leveranciersrelaties. Vindplaats Afgeleid van een wijziging van het veld voor betalingsonderbreking of -blokkade op de geboekte leverancierstransactie (VendTrans). Het wijzigingslogboek kan worden gebruikt om de timestamp vast te leggen. Vastleggen Timestamp van de update die het `payment block field` op de leverancierstransactie instelt. Gebeurtenistype inferred
	Betalingsblokkade Opgeheven	Vertegenwoordigt het opheffen van een betalingsblokkade, waardoor de factuur kan doorgaan naar betalingsplanning. Dit wordt vastgelegd wanneer het `payment block field` wordt gewist of gewijzigd naar een gedeblokkeerde status.
Het belang Meet de tijd die nodig is om problemen op te lossen die betalingsblokkades veroorzaken. Lange periodes tussen het instellen en opheffen van een blokkade duiden op inefficiënte probleemoplossende processen. Vindplaats Afgeleid van een wijziging die het veld voor betalingsonderbreking of -blokkade op de geboekte leverancierstransactie (VendTrans) wist. Het wijzigingslogboek kan de timestamp leveren. Vastleggen Timestamp van de update die het `payment block field` op de leverancierstransactie wist. Gebeurtenistype inferred
	Factuur afgewezen	Geeft aan dat een goedkeurder de factuur heeft afgewezen, waardoor het proces wordt gestopt en deze doorgaans wordt teruggestuurd voor correctie. De workflow engine logt deze afwijzing expliciet.
Het belang Het volgen van afwijzingen helpt herbewerking te kwantificeren en veelvoorkomende oorzaken van mislukking te identificeren, zoals onjuiste codering of beleidsschendingen. Dit ondersteunt direct de 'Invoice Rejection Rate' KPI. Vindplaats Dit is een expliciet `event` gelogd in de `workflow history tables` (bijv. `WorkflowTrackingStatusTable`) wanneer de `workflow` status verandert naar 'Rejected' of 'Canceled'. Vastleggen Timestamp van de 'Rejected' statusvermelding in de `workflow history`. Gebeurtenistype explicit
	Factuur gecodeerd	Deze activiteit betekent dat Grootboekrekeningverdelingen zijn toegewezen aan de factuurregels. Het wordt doorgaans afgeleid door de aanmaak of finalisatie van grootboekrekeningverdelingen gekoppeld aan de factuur.
Het belang Coderen is een cruciale stap voor financiële nauwkeurigheid. Het meten van de tijd die nodig is om facturen te coderen, helpt bij het identificeren van knelpunten in het accounting review proces en ondersteunt de 'Gemiddelde tijd van data-vastlegging tot codering' KPI. Vindplaats Afgeleid van de aanmaak en validatie van records in accounting distributietabellen (bijv. AccountingDistribution) geassocieerd met de openstaande leveranciersfactuur. Vastleggen Timestamp wanneer boekhoudkundige verdelingen voor de factuur worden opgeslagen en gevalideerd. Gebeurtenistype inferred
	Factuurgegevens vastgelegd	Vertegenwoordigt de voltooiing van data-invoer voor de factuur, inclusief header- en regeldetails, voordat deze wordt ingediend voor matching of goedkeuring. Dit wordt vaak afgeleid wanneer de factuurrecord overgaat van een 'new' of 'registered' status naar een 'ready for processing' staat.
Het belang Het volgen van deze activiteit helpt de efficiëntie van het data-invoerproces te meten, of dit nu handmatig of geautomatiseerd (OCR) is. Vertragingen hier kunnen zich door het hele proces heen verspreiden. Vindplaats Afgeleid van statuswijzigingen op de openstaande leveranciersfactuurrecord (bijv. VendInvoiceInfoTable). De event vindt plaats wanneer alle vereiste velden zijn ingevuld en de factuur klaar is voor de volgende stap. Vastleggen Detecteer statuswijziging op de tabel met openstaande facturen die de voltooiing van de data-invoer aangeeft. Gebeurtenistype inferred
	Matchingafwijking Afgehandeld	Markeert de oplossing van een eerder geïdentificeerde matching-afwijking, waardoor de factuur verder kan. Dit wordt afgeleid wanneer een factuur met een 'Failed' matchingstatus succesvol opnieuw is gematcht of handmatig is overschreven.
Het belang Deze activiteit sluit het subproces van afwijkingsresolutie af. De tijd tussen 'Matching Discrepancy Found' en dit `event` is een belangrijke KPI voor het meten van de resolutie-efficiëntie. Vindplaats Afgeleid van een succesvolle matching event ('Factuur gematcht met inkooporder') die plaatsvindt na een 'Matchingafwijking gevonden' event voor dezelfde factuur. Vastleggen Identificeer een 'Geslaagd' matching status timestamp die volgt op een 'Mislukt' status timestamp. Gebeurtenistype inferred
	Matchingafwijking Gevonden	Deze activiteit vindt plaats wanneer het factuurmatchingproces mislukt als gevolg van afwijkingen tussen de factuur, inkooporder of goederenontvangst. Het wordt vastgelegd wanneer de factuurmatchingstatus is ingesteld op 'Failed' of 'Discrepancy'.
Het belang Het identificeren van wanneer en waarom afwijkingen optreden, is cruciaal voor de 'Matchingafwijkingspercentage' KPI. Deze activiteit markeert het begin van het oplossingsproces, dat vaak een bron is van aanzienlijke vertragingen. Vindplaats Afgeleid van de update van het matching statusveld op de leveranciersfactuur (bijv. VendInvoiceInfoTable) naar een 'Mislukt' waarde. De reden voor de mislukking wordt vaak ook gelogd. Vastleggen Timestamp van de statuswijziging naar 'Failed' of 'Discrepancy' tijdens matching. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Zo haal je je data uit Microsoft Dynamics 365

Stappen

Navigeer naar de Data Management Workspace: Log in bij Microsoft Dynamics 365 Finance. Gebruik de zoekbalk om naar de Data management workspace te zoeken en te navigeren.
Maak een nieuw Exportproject aan: Selecteer binnen de workspace de tegel Export om een nieuw data-exportproject aan te maken. Geef het project een zinvolle naam, bijvoorbeeld ProcessMind_Invoice_Processing_Export.
Definieer het Dataproject: Specificeer op het tabblad General van het nieuwe project het Data format. CSV is een veelgebruikt en aanbevolen formaat. Stel andere parameters in indien nodig.
Voeg benodigde data-entiteiten toe: Ga naar de sectie Selected entities en klik op Add entity. Zoek en voeg de volgende kernentiteiten één voor één toe. U moet voor elke entiteit het doeldataformaat specificeren.
- VendInvoiceInfoTableEntity (Factuurkop leverancier)
- VendInvoiceTransEntity (Factuurregels leverancier)
- VendInvoiceRegisterHeaderEntity (Factuurregister journaalkop)
- WorkflowTrackingStatusTableEntity (Workflowgeschiedenis)
- AccountingDistributionEntity (GL-distributies)
- VendInvoiceJour (Geboekte leveranciersfacturen)
- VendTrans (Leverancierstransacties, voor betalingsblokkades)
- LedgerJournalTransVendPaymEntity (Leveranciersbetalingsjournaalregels)
- VendSettlement (Leveranciersvereffeningstransacties)
Filters toepassen: Voor elke entiteit is het cruciaal om filters toe te passen om het databereik te beperken. Selecteer een entiteit en klik op Filter. Filter minimaal op Company (Juridische entiteit) en een specifiek datumbereik op een relevant datumveld zoals CREATEDDATETIME of INVOICEDATE. Een typisch bereik voor initiële analyse is de laatste 3 tot 6 maanden.
Configureer Entiteitsmappings: Controleer voor elke entiteit de source-to-target mapping. Zorg ervoor dat alle vereiste velden voor het definitieve event log zijn opgenomen in de export. Complexe mapping-wijzigingen zijn in dit stadium doorgaans niet nodig.
Voer de Exporttaak uit: Zodra alle entiteiten zijn toegevoegd en gefilterd, klikt u op Export in het Actiepaneel om de taak te starten. U kunt deze direct uitvoeren of plannen voor buiten piekuren om de systeembelasting te minimaliseren.
Download de geëxporteerde data: Nadat de exporttaak succesvol is voltooid, navigeert u naar de taakgeschiedenis. Van daaruit kunt u het geëxporteerde datapak downloaden, dat afzonderlijke bestanden voor elke data-entiteit zal bevatten.
Transformeer data naar een Event Log: De geëxporteerde bestanden zijn entiteits-snapshots, geen geconsolideerd event log. U moet een extern hulpmiddel gebruiken, zoals een database, Python-script of Power Query, om deze bestanden te verwerken en te combineren. De conceptuele query in de query sectie biedt de volledige logica voor deze transformatie.
Voer de transformatielogica uit: Laad de geëxporteerde CSV-bestanden in uw gekozen transformatieomgeving. Voer de meegeleverde transformatiequery uit, die data van alle bronbestanden combineert om een enkele event log-tabel met één rij per bedrijfsactiviteit te creëren.
Voltooi en upload: Exporteer de definitief getransformeerde data naar een enkel CSV-bestand. Zorg ervoor dat de kolomkoppen overeenkomen met de vereisten, bijvoorbeeld InvoiceNumber, ActivityName, EventTime. Dit bestand is nu klaar om te worden geüpload naar ProcessMind.

Configuratie

Data-entiteiten: De kern van de configuratie is het selecteren van de juiste set entiteiten om de levenscyclus van facturen te dekken. Belangrijke entiteiten omvatten VendInvoiceInfoTableEntity, VendInvoiceJour en WorkflowTrackingStatusTableEntity.
Exportdataformaat: Selecteer CSV als het doeldataformaat voor eenvoudige verwerking in volgende transformatiestappen.
Filteren op Bedrijf: Het is cruciaal om elke data-entiteit te filteren op de specifieke juridische entiteit (Bedrijf) die u analyseert om te voorkomen dat irrelevante data wordt opgehaald.
Datumfilter: Pas een consistent datumbereikfilter toe op alle relevante entiteiten, zoals VendInvoiceInfoTableEntity en VendInvoiceJour, gebaseerd op aanmaak- of boekingsdata. Begin met een recente periode, bijvoorbeeld de laatste 6 maanden, om het datavolume te beheren.
Volledige push versus Incrementeel: Voer voor de initiële extractie een volledige push uit. Voor volgende refreshes kunt u een incrementele export configureren om alleen de data op te halen die sinds de laatste run is gewijzigd, wat de verwerkingstijd verkort.
Vereisten: De gebruiker die de export uitvoert, moet de juiste beveiligingsrollen in Dynamics 365 hebben, doorgaans inclusief Data management administrator of een vergelijkbare rol met machtigingen om toegang te krijgen tot de vereiste data-entiteiten.

a Voorbeeldquery config

/*
-- 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: BYOD configureren: Zorg ervoor dat de Bring Your Own Database-functionaliteit is geconfigureerd voor uw Microsoft Dynamics 365 Finance and Operations-omgeving. Dit omvat het instellen van een Azure SQL Database en het configureren van D365 om data ernaartoe te exporteren.
Data-entiteiten identificeren: Navigeer in D365 naar de Data management workspace. De kern van deze extractie berust op het exporteren van specifieke data-entiteiten. Zorg ervoor dat de volgende entiteiten zijn opgenomen in een exporttaak gericht op uw 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.
Exporttaak aanmaken en plannen: Maak in de Data management workspace een nieuw exportproject aan. Voeg de hierboven genoemde entiteiten toe aan het project. Configureer het doeldataformaat zodat het uw BYOD-database is. Stel een terugkerend schema in voor de exporttaak, bijvoorbeeld dagelijks of elk uur, om de data in uw BYOD actueel te houden.
Data in Azure SQL verifiëren: Maak verbinding met uw Azure SQL Database met behulp van een tool zoals SQL Server Management Studio (SSMS) of Azure Data Studio. Controleer of de tabellen die overeenkomen met de D365-entiteiten zijn aangemaakt en gevuld zijn met data.
SQL Query voorbereiden: Kopieer de meegeleverde SQL-query. Deze query is ontworpen om direct te worden uitgevoerd op de tabellen die zijn aangemaakt door het BYOD-exportproces in uw Azure SQL Database.
Verbinden en uitvoeren: Open een nieuw queryvenster in uw SQL-client, verbonden met de BYOD. Plak de gekopieerde SQL-query in het venster.
Queryparameters instellen: Zoek de placeholder-variabelen bovenaan het script. Vervang {StartDate}, {EndDate} en {CompanyCode} door uw gewenste startdatum, einddatum en de identifier van de juridische entiteit, respectievelijk. Bijvoorbeeld, SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Query uitvoeren: Voer het complete SQL-script uit. De query verzamelt en combineert data uit meerdere tabellen om een chronologisch event log voor elke factuur op te bouwen.
Resultaten controleren: De output zal een enkele tabel zijn die het event log bevat met kolommen voor InvoiceNumber, ActivityName, EventTime en andere gespecificeerde attributen. Controleer de resultaten om te zorgen dat ze correct en volledig lijken.
Event Log exporteren: Exporteer de queryresultaten naar een CSV-bestand. De meeste SQL-clients hebben een ingebouwde functie om resultaten naar een bestand op te slaan. Zorg ervoor dat het bestand wordt opgeslagen met UTF-8 codering.
Voorbereiden op upload: Voordat u uploadt naar een process mining tool, bevestigt u dat het CSV-bestand exact de headers heeft zoals gespecificeerd in de query (InvoiceNumber, ActivityName, etc.). Verdere transformatie van de bestandsstructuur is niet nodig.

Configuratie

Belangrijke data-entiteiten: De extractie is afhankelijk van meerdere D365 data-entiteiten die naar de BYOD worden geëxporteerd. Cruciale entiteiten zijn: VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution en VendTrans.
Filteren op datumbereik: De meegeleverde query bevat @StartDate en @EndDate parameters. Het wordt aanbevolen om te beginnen met een beperkt datumbereik, zoals 3-6 maanden data, om de prestaties te garanderen. Het filter wordt toegepast op de factuurboekingsdatum of aanmaakdatum.
Filteren op bedrijfscode: De @DataAreaId parameter is cruciaal voor multi-company omgevingen. Filter altijd op een specifieke juridische entiteit (Bedrijfscode) om te zorgen dat de datacontext correct is.
BYOD Refresh Frequentie: De actualiteit van de data is volledig afhankelijk van het schema van de D365 exporttaak. Voor near-real-time analyse is een hoge frequentie (bijv. elk uur) vereist, wat prestatie- en kostenimplicaties kan hebben voor zowel D365 als Azure.
Vereisten: Deze methode vereist een actief Azure-abonnement, een geprovisioneerde Azure SQL Database en administratorniveau toegang in D365 om de Data management workspace 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 installeren: Zorg ervoor dat u Python 3.6 of nieuwer op uw systeem hebt geïnstalleerd. Installeer de benodigde bibliotheken met pip: pip install pandas requests msal. Deze bibliotheken zijn voor datamanipulatie, het uitvoeren van HTTP-verzoeken naar de API en het afhandelen van Microsoft identity platform authenticatie.
Registreer een applicatie in Azure Active Directory: Om te authenticeren met de Dynamics 365 API, moet u een applicatie registreren in de Azure AD-tenant van uw organisatie. Maak een nieuwe App Registration aan, genereer een client secret en noteer de Application (client) ID, Directory (tenant) ID en de waarde van de client secret.
Verleen API-machtigingen: Navigeer binnen de nieuw aangemaakte App Registration in Azure AD naar API-machtigingen. Voeg een machtiging toe voor 'Dynamics ERP' of 'Dynamics 365 Business Central' (afhankelijk van uw licentie) en verleen de gedelegeerde machtiging user_impersonation. Een beheerder moet admin-toestemming verlenen voor deze machtigingen.
Maak een applicatiegebruiker aan in Dynamics 365: Navigeer in uw Dynamics 365-omgeving naar Systeembeheer > Gebruikers > Gebruikers. Maak een nieuwe gebruiker aan en voer de Application (client) ID van de Azure App Registration in het veld Applicatie-ID in. Wijs de juiste beveiligingsrollen toe aan deze gebruiker, zoals 'Systeembeheerder' of een meer beperkte rol die leestoegang heeft 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 placeholder-variabelen bovenaan bij met uw specifieke Dynamics 365-omgevings-URL, tenant ID, client ID, client secret en de bedrijfscode (dataAreaId) waaruit u data wilt extraheren.
Stel het datumbereik in: Pas de variabelen START_DATE en END_DATE in het script aan om het tijdsvenster voor de data-extractie te definiëren. Het wordt aanbevolen om te beginnen met een kleiner bereik, zoals één maand, om het script te testen en de resultaten te verifiëren.
Voer het script uit: Voer het script uit via uw commandoregel of terminal met de opdracht: python extract_invoices.py. Het script zal authenticeren, de verschillende OData-eindpunten voor elke activiteit bevragen en de data verwerken.
Monitor de uitvoering: Het script print voortgangsberichten naar de console terwijl het data ophaalt voor elke activiteit. Dit kan aanzienlijk veel tijd kosten, afhankelijk van het datumbereik en datavolume. Zoek naar eventuele foutmeldingen die kunnen wijzen op problemen met authenticatie of API-toegang.
Controleer het uitvoerbestand: Zodra het script succesvol is voltooid, genereert het een CSV-bestand met de naam d365_invoice_event_log.csv in dezelfde map. Dit bestand bevat het geconsolideerde event log.
Voorbereiden op upload: Open het CSV-bestand om ervoor te zorgen dat het correct is geformatteerd. Controleer of alle vereiste kolommen (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) aanwezig en gevuld zijn. Het bestand is nu klaar om te worden geüpload naar ProcessMind.

Configuratie

Authenticatie: Het script gebruikt de OAuth 2.0 client credentials flow. U moet een Azure AD App Registration configureren en deze API-machtigingen verlenen voor Dynamics 365. Een applicatiegebruiker met de juiste beveiligingsrollen moet in Dynamics 365 zelf worden aangemaakt.
API-eindpunt: De basis-URL voor de Dynamics 365 Finance and Operations OData API. Het formaat is doorgaans https://[your-d365-environment-name].operations.dynamics.com.
Datumbereik: Het script bevat de variabelen START_DATE en END_DATE. Deze worden gebruikt om records te filteren op basis van hun aanmaak- of wijzigingsdata om het datavolume te beheren. Voor initiële extracties wordt een periode van 3 tot 6 maanden aanbevolen.
Bedrijfsfilter: Data moet worden gefilterd op een specifieke juridische entiteit of bedrijf. Dit gebeurt door de dataAreaId te specificeren in het API-queryfilter, wat een verplichte configuratie is in het script.
Belangrijke data-entiteiten: Het script bevraagt verschillende standaard Dynamics 365 OData-entiteiten, waaronder VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines en VendSettlements. Aangepaste entiteiten kunnen nodig zijn als het standaardproces sterk is gewijzigd.
Paginering: Het script verwerkt automatisch gepagineerde responses van de API met behulp van de @odata.nextLink property om te zorgen dat alle records voor de gespecificeerde 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

Navigeer naar de Data Management Workspace: Log in bij Microsoft Dynamics 365 Finance. Gebruik de zoekbalk om naar de Data management workspace te zoeken en te navigeren.
Maak een nieuw Exportproject aan: Selecteer binnen de workspace de tegel Export om een nieuw data-exportproject aan te maken. Geef het project een zinvolle naam, bijvoorbeeld ProcessMind_Invoice_Processing_Export.
Definieer het Dataproject: Specificeer op het tabblad General van het nieuwe project het Data format. CSV is een veelgebruikt en aanbevolen formaat. Stel andere parameters in indien nodig.
Voeg benodigde data-entiteiten toe: Ga naar de sectie Selected entities en klik op Add entity. Zoek en voeg de volgende kernentiteiten één voor één toe. U moet voor elke entiteit het doeldataformaat specificeren.
- VendInvoiceInfoTableEntity (Factuurkop leverancier)
- VendInvoiceTransEntity (Factuurregels leverancier)
- VendInvoiceRegisterHeaderEntity (Factuurregister journaalkop)
- WorkflowTrackingStatusTableEntity (Workflowgeschiedenis)
- AccountingDistributionEntity (GL-distributies)
- VendInvoiceJour (Geboekte leveranciersfacturen)
- VendTrans (Leverancierstransacties, voor betalingsblokkades)
- LedgerJournalTransVendPaymEntity (Leveranciersbetalingsjournaalregels)
- VendSettlement (Leveranciersvereffeningstransacties)
Filters toepassen: Voor elke entiteit is het cruciaal om filters toe te passen om het databereik te beperken. Selecteer een entiteit en klik op Filter. Filter minimaal op Company (Juridische entiteit) en een specifiek datumbereik op een relevant datumveld zoals CREATEDDATETIME of INVOICEDATE. Een typisch bereik voor initiële analyse is de laatste 3 tot 6 maanden.
Configureer Entiteitsmappings: Controleer voor elke entiteit de source-to-target mapping. Zorg ervoor dat alle vereiste velden voor het definitieve event log zijn opgenomen in de export. Complexe mapping-wijzigingen zijn in dit stadium doorgaans niet nodig.
Voer de Exporttaak uit: Zodra alle entiteiten zijn toegevoegd en gefilterd, klikt u op Export in het Actiepaneel om de taak te starten. U kunt deze direct uitvoeren of plannen voor buiten piekuren om de systeembelasting te minimaliseren.
Download de geëxporteerde data: Nadat de exporttaak succesvol is voltooid, navigeert u naar de taakgeschiedenis. Van daaruit kunt u het geëxporteerde datapak downloaden, dat afzonderlijke bestanden voor elke data-entiteit zal bevatten.
Transformeer data naar een Event Log: De geëxporteerde bestanden zijn entiteits-snapshots, geen geconsolideerd event log. U moet een extern hulpmiddel gebruiken, zoals een database, Python-script of Power Query, om deze bestanden te verwerken en te combineren. De conceptuele query in de query sectie biedt de volledige logica voor deze transformatie.
Voer de transformatielogica uit: Laad de geëxporteerde CSV-bestanden in uw gekozen transformatieomgeving. Voer de meegeleverde transformatiequery uit, die data van alle bronbestanden combineert om een enkele event log-tabel met één rij per bedrijfsactiviteit te creëren.
Voltooi en upload: Exporteer de definitief getransformeerde data naar een enkel CSV-bestand. Zorg ervoor dat de kolomkoppen overeenkomen met de vereisten, bijvoorbeeld InvoiceNumber, ActivityName, EventTime. Dit bestand is nu klaar om te worden geüpload naar ProcessMind.

Configuratie

Data-entiteiten: De kern van de configuratie is het selecteren van de juiste set entiteiten om de levenscyclus van facturen te dekken. Belangrijke entiteiten omvatten VendInvoiceInfoTableEntity, VendInvoiceJour en WorkflowTrackingStatusTableEntity.
Exportdataformaat: Selecteer CSV als het doeldataformaat voor eenvoudige verwerking in volgende transformatiestappen.
Filteren op Bedrijf: Het is cruciaal om elke data-entiteit te filteren op de specifieke juridische entiteit (Bedrijf) die u analyseert om te voorkomen dat irrelevante data wordt opgehaald.
Datumfilter: Pas een consistent datumbereikfilter toe op alle relevante entiteiten, zoals VendInvoiceInfoTableEntity en VendInvoiceJour, gebaseerd op aanmaak- of boekingsdata. Begin met een recente periode, bijvoorbeeld de laatste 6 maanden, om het datavolume te beheren.
Volledige push versus Incrementeel: Voer voor de initiële extractie een volledige push uit. Voor volgende refreshes kunt u een incrementele export configureren om alleen de data op te halen die sinds de laatste run is gewijzigd, wat de verwerkingstijd verkort.
Vereisten: De gebruiker die de export uitvoert, moet de juiste beveiligingsrollen in Dynamics 365 hebben, doorgaans inclusief Data management administrator of een vergelijkbare rol met machtigingen om toegang te krijgen tot de vereiste data-entiteiten.

a Voorbeeldquery config

/*
-- 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;

Uw Purchase to Pay - Factuurverwerking Data Template

Uw Purchase to Pay - Factuurverwerking Data Template

Purchase to Pay - Factuurverwerkingsattributen

Purchase to Pay - Factuurverwerkingsactiviteiten

Extractie Guides

Export van Dynamics 365 Data Management Framework

Stappen

Configuratie

a Voorbeeldquery config

Directe SQL Query via Bring Your Own Database (BYOD)

Stappen

Configuratie

a Voorbeeldquery sql

Python Script met Dynamics 365 OData REST API

Stappen

Configuratie

a Voorbeeldquery python

Microsoft Power Platform Dataflow Extraction

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Begin vandaag nog met het optimaliseren van uw Purchase to Pay - Factuurverwerking

Uw Purchase to Pay - Factuurverwerking Data Template

Uw Purchase to Pay - Factuurverwerking Data Template

Purchase to Pay - Factuurverwerkingsattributen

Purchase to Pay - Factuurverwerkingsactiviteiten

Extractie Guides

Export van Dynamics 365 Data Management Framework

Stappen

Configuratie

a Voorbeeldquery config

Directe SQL Query via Bring Your Own Database (BYOD)

Stappen

Configuratie

a Voorbeeldquery sql

Python Script met Dynamics 365 OData REST API

Stappen

Configuratie

a Voorbeeldquery python

Microsoft Power Platform Dataflow Extraction

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Begin vandaag nog met het optimaliseren van uw Purchase to Pay - Factuurverwerking