> Continue procesverbetering > Van vastlegging tot rapportage journaalpost > Microsoft Dynamics 365 > Datatemplate

Jouw datatemplate voor Record to Report - journaalposten

Microsoft Dynamics 365

Van vastlegging tot rapportage - attributen van journaalposten (20) Van vastlegging tot rapportage - activiteiten van journaalposten (12) Extractiegidsen (4)

Jouw datatemplate voor Record to Report - journaalposten

Deze template geeft je een volledig overzicht van de datapunten die je nodig hebt om je Record to Report-proces voor journaalposten te analyseren. Je ziet welke belangrijke attributen je verzamelt en welke activiteiten je volgt, zodat je alle informatie vastlegt voor een goede process mining-analyse. Daarnaast vind je praktische uitleg over het ophalen van deze data uit je bronsysteem.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Uitleg voor data-extractie uit Microsoft Dynamics 365

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

Template downloaden

Van vastlegging tot rapportage - attributen van journaalposten

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van vastlegging tot rapportage en journaalposten.

3 Verplicht 7 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteitnaam ActivityName	De naam van de specifieke stap of gebeurtenis in het bedrijfsproces die heeft plaatsgevonden.
Beschrijving Dit attribuut beschrijft één gebeurtenis of taak binnen de levenscyclus van een journaalpost, zoals 'Journal Entry Created', 'Journal Submitted For Approval' of 'Journal Entry Posted'. Deze activiteiten vormen de knooppunten van de ontdekte proceskaart. Het analyseren van de volgorde en frequentie van deze activiteiten is de kern van process mining. Je ziet de werkelijke processtroom, ontdekt afwijkingen van de standaardprocedure en vindt bottlenecks waar activiteiten langer duren dan verwacht of worden herhaald. Waarom dit belangrijk is Dit attribuut definieert de processtappen. Daarmee vormt het de basis van de proceskaart en kun je de processtroom en varianten analyseren. Waar je het vindt Dit is een conceptueel attribuut dat wordt afgeleid uit systeemgebeurtenissen, statuswijzigingen of workflowlogboeken in Microsoft Dynamics 365. Voorbeelden Journaalpost aangemaaktJournaal ingediend ter goedkeuringJournaal goedgekeurdJournaalpost geboekt
	ID journaalpost JournalEntryId	De unieke identificatie van een journaalpost, die als primaire case-identificatie dient.
Beschrijving Het Journal Entry ID koppelt alle activiteiten en datapunten van één journaaltransactie uniek aan elkaar. Zo kun je de volledige levenscyclus van een journaalpost volgen, van aanmaak en beoordeling tot de uiteindelijke boeking in het grootboek. In process-mininganalyse is dit attribuut essentieel voor het reconstrueren van de processtroom. Elk uniek Journal Entry ID staat voor één procesinstantie. Daarmee kun je procesvarianten, doorlooptijden en compliance per financiële transactie gedetailleerd analyseren. Waarom dit belangrijk is Dit is de essentiële sleutel om een journaalpost van begin tot eind te volgen. Zo kun je de volledige processtroom per case analyseren. Waar je het vindt Deze identificatie staat meestal in de journaalkoptabel, zoals LedgerJournalTable, vaak in een veld met de naam JournalNum. Voorbeelden JRN-0012345JV-2023-08-156GENJ0000891
	Tijdstip van gebeurtenis EventTime	De precieze timestamp die aangeeft wanneer een activiteit of gebeurtenis plaatsvond.
Beschrijving Event Time registreert de datum en tijd waarop een specifieke activiteit in het journaalpostproces plaatsvond. Deze chronologische data is essentieel om gebeurtenissen te ordenen en de tijd ertussen te berekenen. In analyses gebruik je deze timestamp om de tijdlijn per case op te bouwen. Dat is nodig voor alle tijdgebaseerde metingen, zoals doorlooptijden, verwerkingstijden en wachttijden. Zo kun je vertragingen tussen stappen vinden en dashboards maken over bottlenecks en SLA-compliance. Waarom dit belangrijk is Deze timestamp is essentieel om gebeurtenissen correct te ordenen en alle doorlooptijd-KPI's te berekenen, zoals de cyclustijd en vertragingen in de verwerking. Waar je het vindt Event-timestamps staan meestal in workflowhistorielogboeken, audittrailtabellen, zoals SysDatabaseLog, of als aanmaak- en wijzigingstimestamps op gerelateerde records, zoals LedgerJournalTable en LedgerJournalTrans. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	Eindtijd van gebeurtenis EventEndTime	De timestamp die aangeeft wanneer een activiteit of gebeurtenis is afgerond.
Beschrijving Event End Time markeert het einde van een specifieke activiteit. Waar StartTime aangeeft wanneer een gebeurtenis begint, geeft EndTime de andere grens aan. Zo kun je de duur van afzonderlijke taken nauwkeurig berekenen. In process mining kun je met zowel een start- als eindtijd de verwerkingstijd van een activiteit berekenen. Die verschilt van de wachttijd. Dit is belangrijk voor dashboards die gebruikersprestaties analyseren en laten zien welke taken, en niet alleen welke tussenliggende wachttijden, de meeste tijd kosten. Waarom dit belangrijk is Maakt een nauwkeurige berekening mogelijk van de tijd die elke activiteit kost. Dat is belangrijk voor het analyseren van gebruikersprestaties en het vinden van taken die veel bronnen vragen. Waar je het vindt Deze data kan expliciet in workflowlogboeken staan of moet worden afgeleid met de StartTime van de volgende activiteit in de reeks. Voorbeelden 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Gebruikersnaam UserName	De naam van de gebruiker die de activiteit heeft uitgevoerd.
Beschrijving Dit attribuut identificeert de medewerker of systeemgebruiker die verantwoordelijk is voor een specifieke activiteit, zoals het aanmaken, goedkeuren of boeken van een journaalpost. Het koppelt processtappen aan personen. Het analyseren van prestaties per gebruiker is een belangrijke mogelijkheid van process mining. Zo kun je het dashboard 'Journal Entry User Performance' maken om activiteitenduren en verwerkingsvolumes van verschillende gebruikers of teams te vergelijken. Dit kan goed presterende gebruikers zichtbaar maken, trainingsbehoeften aanwijzen en helpen bij het verdelen van de werklast. Waarom dit belangrijk is Koppelt procesactiviteiten aan specifieke personen. Zo kun je gebruikersprestaties, werkverdeling en de inzet van bronnen analyseren. Waar je het vindt Gebruikersinformatie staat meestal in de velden createdBy of modifiedBy van tabellen zoals LedgerJournalTable, of in gekoppelde workflowhistorielogboeken. Voorbeelden Alice SmithBob Johnsonsystem.batch
	Journaalstatus JournalStatus	De huidige of definitieve status van de journaalpost.
Beschrijving Dit attribuut geeft de status van de journaalpost op een bepaald moment aan, zoals 'Draft', 'In Review', 'Approved', 'Rejected' of 'Posted'. Het laat zien waar de post zich in de levenscyclus bevindt. Door de status te analyseren, krijg je inzicht in de uitkomsten van cases. Je kunt bijvoorbeeld alle afgewezen journaalposten filteren of het aantal journaalposten in een bepaalde fase volgen. Dit attribuut geeft context aan meerdere dashboards over verwerkingsvolume en status. Waarom dit belangrijk is Geeft voor elke journaalpost een duidelijke uitkomst. Zo kun je succespercentages, afwijzingspercentages en het werkvolume in verschillende fasen analyseren. Waar je het vindt De status staat vaak in de journaalkoptabel LedgerJournalTable of wordt afgeleid uit de workflowstatus. Voorbeelden ConceptIngediendGoedgekeurdGeboektAfgewezen
	Journaaltype JournalType	De classificatie van de journaalpost, zoals General Journal of Accrual.
Beschrijving Journal Type deelt journaalposten in op basis van hun bedrijfsdoel, bijvoorbeeld dagelijkse boekingen, overlopende posten, allocaties of eliminaties. Deze indeling is belangrijk om verschillende procespaden en patronen te begrijpen. Met dit attribuut kun je het proces per journaaltype filteren en vergelijken. Het is essentieel voor het dashboard 'Journal Entry Throughput Volume by Type', waarmee je analyseert of bepaalde journaaltypen vaker vertragingen, afwijzingen of herstelwerk veroorzaken. Waarom dit belangrijk is Maakt het mogelijk de analyse op te splitsen naar verschillende bedrijfsdoelen. Die kunnen elk hun eigen procespad, doorlooptijden en goedkeuringsvereisten hebben. Waar je het vindt Dit staat meestal in de journaalkoptabel LedgerJournalTable, in een veld dat aan journaalnamen of -typen is gekoppeld, zoals JournalName. Voorbeelden Algemene journaalpostAanpassing overlopende postIntercompany-overboekingSalarisadministratie
	Juridische entiteit LegalEntity	De juridische entiteit of bedrijfscode waarvoor de journaalpost wordt vastgelegd.
Beschrijving De juridische entiteit staat voor het specifieke bedrijf of de specifieke bedrijfseenheid binnen een organisatie waarvoor de financiële transactie wordt vastgelegd. Dit is een belangrijke organisatorische dimensie in financiële systemen. Met process mining kun je het proces van journaalposten in verschillende delen van de organisatie vergelijken. Zo zie je bijvoorbeeld of bepaalde juridische entiteiten efficiënter werken, vaker worden afgewezen of langere doorlooptijden hebben. Dat helpt om best practices te vinden en te delen. Waarom dit belangrijk is Hiermee kun je de procesprestaties van verschillende bedrijven of bedrijfseenheden vergelijken en verschillen en verbetermogelijkheden zichtbaar maken. Waar je het vindt Dit is een kernveld in Dynamics 365. Je vindt het vaak in transactietabellen zoals LedgerJournalTable, meestal gekoppeld aan DataAreaId. Voorbeelden USMFDEMFGBSI
	Reden van afwijzing RejectionReason	De reden die wordt opgegeven wanneer een journaalpost tijdens het goedkeuringsproces wordt afgewezen.
Beschrijving Wanneer een journaalpost wordt afgewezen, geeft de goedkeurder vaak een reden op. Dit attribuut legt die informatie vast en is zeer waardevol voor oorzaakanalyse. Dit is het belangrijkste attribuut voor het dashboard 'Journal Entry Rejection Rate Analysis'. Door afwijsredenen te categoriseren en analyseren, kunnen organisaties veelvoorkomende problemen vinden, zoals onjuiste documentatie, beleidsovertredingen of fouten bij de data-invoer. Daarna kunnen ze gerichte training of procesverbeteringen inzetten. Waarom dit belangrijk is Legt uit waarom herstelwerk ontstaat. Zo krijg je de informatie die nodig is om afwijzingspercentages te verlagen en goedkeuring in één keer goed te laten verlopen. Waar je het vindt Deze informatie wordt meestal opgeslagen in de workflowgeschiedenis of in het opmerkingenveld bij de afwijzingsstap. Voorbeelden Onvoldoende ondersteunende documentatieOnjuiste rekening gebruiktGoedkeuringsdrempel overschredenDubbele boeking
	Totaalbedrag journaalpost JournalTotalAmount	De totale geldwaarde van de journaalpost, meestal de som van de debetbedragen.
Beschrijving Dit attribuut staat voor de totale financiële waarde van de journaalpost. Je kunt journaalposten hiermee indelen in waardeklassen, zoals laag, gemiddeld en hoog. Door het proces op basis van financiële waarde te analyseren, komen belangrijke patronen naar voren. Journaalposten met een hoge waarde kunnen bijvoorbeeld een strenger goedkeuringsproces volgen, met meer stappen en langere doorlooptijden. Dit attribuut is belangrijk voor materialiteitsanalyses en om de financiële impact van inefficiënte processen te begrijpen. Waarom dit belangrijk is Hiermee kun je het proces indelen op financiële waarde. Die hangt vaak samen met procescomplexiteit, risico en goedkeuringsworkflows. Waar je het vindt Deze waarde moet mogelijk worden berekend door de debetbedragen uit de journaalregeltabel, LedgerJournalTrans, per journaalpost op te tellen. Voorbeelden 1500.75125000.0050.25
	Afdeling DepartmentName	De afdeling of kostenplaats die aan de journaalpost is gekoppeld.
Beschrijving De afdeling of kostenplaats identificeert de interne bedrijfseenheid die verantwoordelijk is voor de financiële transactie of erdoor wordt geraakt. Dit is een belangrijke dimensie voor interne managementrapportage. Met dit attribuut kun je het proces van journaalposten per afdeling analyseren. Je kunt er vragen mee beantwoorden als: welke afdelingen dienen de meeste journaalposten in? Hebben bepaalde afdelingen vaker afwijzingen of langere goedkeuringstijden? Dat helpt bij gerichte procesverbetering. Waarom dit belangrijk is Hiermee kun je de procesprestaties per bedrijfsfunctie analyseren en knelpunten of trainingsbehoeften per afdeling vinden. Waar je het vindt Deze informatie staat meestal op regelniveau van de journaalpost, in LedgerJournalTrans, als financiële dimensie. Voorbeelden VerkoopFinanciënMarketingBedrijfsvoering
	Automatisch boeken IsAutomatedPosting	Een vlag die aangeeft of de journaalpost automatisch is aangemaakt of geboekt.
Beschrijving Dit booleaanse attribuut maakt onderscheid tussen journaalposten die handmatig door een gebruiker zijn aangemaakt en journaalposten die automatisch door het systeem of een subsysteem zijn gegenereerd, bijvoorbeeld door een systeemintegratie of een geautomatiseerd allocatieproces. Met dit attribuut kun je de efficiëntie en foutpercentages van geautomatiseerde en handmatige processen vergelijken. Het kan laten zien waar verdere automatisering mogelijk is, bijvoorbeeld als handmatige journaalposten vaker fouten, herstelwerk of vertragingen veroorzaken. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en geautomatiseerde processen, zodat je efficiëntie, nauwkeurigheid en compliance kunt vergelijken. Waar je het vindt Dit kan blijken uit de gebruiker bij 'Aangemaakt door', bijvoorbeeld een systeem- of batchgebruiker, of uit een specifieke vlag in de journaalkop of typeconfiguratie. Voorbeelden truefalse
	Boekingsdatum PostingDate	De datum waarop de journaalpost in het grootboek wordt geboekt.
Beschrijving De boekingsdatum is de officiële datum waarop de transactie de saldi in het grootboek beïnvloedt. Deze datum is belangrijk voor financiële rapportage en het afsluiten van perioden. Met dit attribuut kun je de vertraging tussen goedkeuring en boeking analyseren. Dat is de basis van de KPI 'Doorlooptijd van journaalpost tot boeking'. Het verkorten van deze vertraging is vaak een belangrijk doel om de financiële afsluiting te versnellen. Je kunt hiermee ook boekingsvolumes over tijd analyseren. Waarom dit belangrijk is Belangrijk voor het berekenen van de KPI voor de doorlooptijd tot boeking en voor inzicht in vertragingen tussen goedkeuring en het moment waarop een transactie officieel in het grootboek staat. Waar je het vindt Deze datum wordt meestal opgeslagen in de journaalkop, LedgerJournalTable, of in gerelateerde tabellen met geboekte transacties. Voorbeelden 2023-10-282023-11-012023-10-31
	Bronsysteem SourceSystem	Het systeem waarin de bronregistratie staat en waaruit de data is geëxtraheerd.
Beschrijving Dit attribuut identificeert de brontoepassing waaruit de journaalpostdata afkomstig is. Voor dit proces is de waarde meestal constant, bijvoorbeeld 'Microsoft Dynamics 365'. In een bredere analyse, vooral in omgevingen met meerdere ERP's of geïntegreerde systemen, helpt dit veld processen en databronnen van elkaar te onderscheiden. Het maakt de herkomst van de data duidelijk en is belangrijk voor datagovernance en validatie. Waarom dit belangrijk is Identificeert de herkomst van de data. Dat is belangrijk voor datagovernance en analyses die meerdere bedrijfssystemen omvatten. Waar je het vindt Dit is een statische waarde die tijdens het ETL-proces wordt toegevoegd om de herkomst van de dataset te markeren. Voorbeelden Microsoft Dynamics 365D365 F&O
	Goedkeuringsniveau ApprovalLevel	Geeft de huidige of afgeronde fase in een goedkeuringsworkflow met meerdere niveaus aan.
Beschrijving Bij journaalposten waarvoor meerdere goedkeuringen nodig zijn, houdt dit attribuut bij welk hiërarchische niveau de post heeft bereikt, bijvoorbeeld 'Goedkeuring door manager' of 'Goedkeuring door directeur'. Dit attribuut helpt om goedkeuringsknelpunten verder te analyseren. Je ziet ermee of vertragingen steeds op hetzelfde niveau in de goedkeuringsketen ontstaan. Dat kan wijzen op een herontwerp van het proces of een andere verdeling van capaciteit op dat niveau. Waarom dit belangrijk is Geeft inzicht in goedkeuringsworkflows met meerdere fasen en helpt knelpunten op specifieke goedkeuringsniveaus te vinden. Waar je het vindt Deze informatie wordt afgeleid uit het workflowgeschiedenislog, waarin de afronding van verschillende goedkeuringsstappen wordt bijgehouden. Voorbeelden Niveau 1: managerNiveau 2: directeurNiveau 3: financieel directeur
	Herstelwerk IsRework	Een vlag die activiteiten identificeert die deel uitmaken van een herstel- of correctielus.
Beschrijving Dit berekende booleaanse attribuut krijgt de waarde true voor activiteiten na een afwijzing, zoals 'Journaalpost gecorrigeerd' of een herhaalde 'Journaalpost ingediend ter goedkeuring'. Zo kun je herstelwerk afzonderlijk bekijken en kwantificeren. Dit attribuut vormt de basis voor het dashboard 'Herstelwerk en correctielussen in journaalposten' en de KPI 'Herstelwerkpercentage'. Door herstelwerk te markeren, kun je de frequentie en impact van correctierondes eenvoudig visualiseren en meten. Die zijn vaak een belangrijke bron van inefficiëntie in het proces. Waarom dit belangrijk is Markeert inefficiënte herstellussen rechtstreeks, zodat je de impact van afwijzingen en correcties op de totale doorlooptijd en kosten kunt kwantificeren. Waar je het vindt Dit is een berekend attribuut dat tijdens de datatransformatie wordt afgeleid door de volgorde van activiteiten binnen een case te analyseren. Voorbeelden truefalse
	In één keer goed IsFirstTimeRight	Een vlag die aangeeft of de journaalpost zonder eerdere afwijzingen is goedgekeurd.
Beschrijving Dit booleaanse attribuut op caseniveau is true als een journaalpost van indiening naar goedkeuring gaat zonder tussentijdse activiteiten als 'Journaalpost afgewezen' of 'Journaalpost gecorrigeerd'. Het is een belangrijke maatstaf voor proceskwaliteit. De KPI 'Goedkeuringspercentage in één keer goed' wordt rechtstreeks op basis van dit attribuut berekend. Een hoog percentage wijst op een efficiënt proces van goede kwaliteit. Een laag percentage kan wijzen op structurele problemen met de kwaliteit van de eerste gegevens, de duidelijkheid van vereisten of de indieningsprocedure. Waarom dit belangrijk is Dit is een belangrijke maatstaf voor proceskwaliteit. Je ziet ermee hoeveel journaalposten zonder herstelwerk soepel door het goedkeuringsproces gaan. Waar je het vindt Dit is een berekend attribuut op caseniveau, afgeleid uit de volgorde van activiteiten voor elke Journal Entry ID. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor het laatst vanuit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut geeft de datum en tijd van de meest recente data-extractie uit het bronsysteem aan. Zo zie je hoe actueel de analyse en de opgenomen data zijn. Door deze informatie in dashboards te tonen, weten gebruikers hoe recent de data is en welke periode de huidige procesanalyse beslaat. Dit is belangrijke metadata voor elk process-miningproject. Waarom dit belangrijk is Geeft belangrijke context over de actualiteit van de data, zodat gebruikers weten hoe recent de procesanalyse is. Waar je het vindt Deze timestamp wordt gegenereerd en opgeslagen tijdens het ETL-proces. Voorbeelden 2023-10-27T02:00:00Z
	Status goedkeurings-SLA ApprovalSlaState	Geeft aan of de goedkeuring van de journaalpost binnen de afgesproken servicenorm viel.
Beschrijving Dit attribuut deelt de goedkeuringscyclus van elke journaalpost in op basis van de vraag of die binnen de doeltermijn uit de Service Level Agreement (SLA) is afgerond. Mogelijke waarden zijn meestal 'Gehaald' of 'Overschreden'. Dit is de kernmetriek voor het dashboard 'SLA-compliance voor goedkeuring van journaalposten'. Je krijgt hiermee een duidelijk bedrijfsmatig beeld van de prestaties ten opzichte van de doelen. Zo kun je de snelheid van het goedkeuringsproces volgen en verbeteren waar SLA's vaak niet worden gehaald. Waarom dit belangrijk is Zet ruwe gegevens over doorlooptijden om in een duidelijke bedrijfsuitkomst, gehaald of overschreden, zodat je prestaties ten opzichte van belangrijke doelen eenvoudig kunt volgen. Waar je het vindt Dit is een berekend attribuut. De logica vergelijkt de berekende KPI voor de goedkeuringsdoorlooptijd met een vooraf ingestelde SLA-doelwaarde. Voorbeelden GehaaldOverschreden
	Valutacode CurrencyCode	De valuta van het bedrag van de journaalpost.
Beschrijving Dit attribuut geeft aan in welke valuta de journaalpost is uitgedrukt, zoals USD, EUR of GBP. Het geeft de nodige context bij het totale bedrag van de journaalpost. De valuta wordt niet altijd gebruikt om de processtroom zelf te analyseren, maar is wel belangrijk voor financiële rapportage en analyses op basis van journaalbedragen. Zo kun je waarden correct optellen en vergelijken, vooral in multinationale organisaties. Waarom dit belangrijk is Geeft de nodige context voor financiële analyses, zodat geldbedragen correct worden geïnterpreteerd, vooral in omgevingen met meerdere valuta. Waar je het vindt De valutacode is meestal beschikbaar in de journaalregeltabel, LedgerJournalTrans. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Van vastlegging tot rapportage - activiteiten van journaalposten

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

5 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Journaal afgewezen	Een beoordelaar of goedkeurder heeft de journaalpost afgewezen en correctie is nodig. Deze gebeurtenis wordt vastgelegd via een statuswijziging op de journaalpost, bijvoorbeeld naar 'Rejected' of 'Needs Correction'.
Waarom dit belangrijk is Door afwijzingen te volgen, kun je het afwijzingspercentage berekenen en de oorzaken van herstelwerk vinden. Zo worden problemen met datakwaliteit, compliance of gebruikerstraining zichtbaar. Waar je het vindt Dit wordt afgeleid uit een wijziging in een statusveld, bijvoorbeeld wanneer ApprovalStatus verandert in 'Rejected' in LedgerJournalTable, of uit het workflowhistorielogboek. Vastleggen Bepaal de timestamp waarop de journaalstatus verandert in 'Rejected'. Eventtype inferred
	Journaal goedgekeurd	De aangewezen bevoegde persoon heeft de journaalpost goedgekeurd. Daarmee is de laatste stap in de goedkeuringsworkflow afgerond. Meestal wordt dit vastgelegd via een statuswijziging op de journaalkop, bijvoorbeeld naar 'Approved'.
Waarom dit belangrijk is Dit is een belangrijk mijlpaalmoment dat het goedkeuringsproces afsluit en boeken mogelijk maakt. Je gebruikt het om de doorlooptijd van goedkeuring, de doorlooptijd tot boeken en het first-time-right-percentage te berekenen. Waar je het vindt Dit wordt afgeleid uit een wijziging in een statusveld, bijvoorbeeld wanneer ApprovalStatus verandert in 'Approved' in LedgerJournalTable, of uit de workflowhistorietabel die een definitieve goedkeuringsstatus bevat. Vastleggen Bepaal de timestamp waarop de journaalstatus verandert in 'Approved'. Eventtype inferred
	Journaal ingediend ter goedkeuring	Dit is het formeel indienen van een voltooide journaalpost voor beoordeling en goedkeuring. Meestal wordt dit afgeleid uit een statuswijziging op de journaalkop, bijvoorbeeld van 'Draft' naar 'In Review' of 'Submitted'.
Waarom dit belangrijk is Dit is een belangrijk mijlpaalmoment dat de goedkeuringscyclus start. Door de tijd tussen indienen en definitieve goedkeuring te meten, vind je bottlenecks in het beoordelingsproces en kun je SLA-compliance volgen. Waar je het vindt Dit wordt afgeleid uit een wijziging in een statusveld, bijvoorbeeld wanneer ApprovalStatus verandert in 'InReview' in LedgerJournalTable, of uit de workflowhistorie die aan de journaalpost is gekoppeld. Vastleggen Bepaal de timestamp waarop de journaalstatus verandert in 'submitted' of 'in review'. Eventtype inferred
	Journaalpost aangemaakt	Deze activiteit markeert de start van een nieuwe journaalpost. De activiteit wordt vastgelegd wanneer een gebruiker een nieuw journaalkoprecord aanmaakt. Daarbij ontstaat een uniek Journal Entry ID dat als case-identificatie dient voor procesanalyse.
Waarom dit belangrijk is Dit is de primaire startgebeurtenis van het proces. Door de tijd vanaf dit moment tot het boeken te analyseren, kun je de end-to-end-doorlooptijd meten en vertragingen bij de eerste data-invoer vinden. Waar je het vindt Deze gebeurtenis wordt vastgelegd via de aanmaaktimestamp van de journaalkop in de entiteit GeneralJournalEntry of LedgerJournalTable. Meestal gaat het om een expliciete recordaanmaak. Vastleggen Gebruik het veld 'createdDateTime' in GeneralJournalEntry of LedgerJournalTable. Eventtype explicit
	Journaalpost geboekt	Deze activiteit markeert het succesvol boeken van de journaalpost in het grootboek, waarmee deze een officieel financieel record wordt. Dit is een belangrijke gebeurtenis die wordt vastgelegd wanneer de status van de journaalkop wordt bijgewerkt naar 'Posted'.
Waarom dit belangrijk is Dit is de primaire succesvolle eindgebeurtenis van het proces. Je gebruikt deze om de end-to-end-doorlooptijd en de doorlooptijd tot boeken te berekenen, belangrijke indicatoren voor de efficiëntie van de financiële afsluiting. Waar je het vindt Dit wordt vastgelegd via een wijziging in een statusveld, bijvoorbeeld wanneer JournalStatus verandert in 'Posted' in LedgerJournalTable, en via het aanmaken van bijbehorende records in de tabel GeneralJournalAccountEntry. Vastleggen Bepaal de timestamp waarop de status van de journaalpost 'Posted' wordt. Eventtype inferred
	Beoordeling van journaal gestart	Deze activiteit markeert het moment waarop een beoordelaar actief aan een ingediende journaalpost begint te werken. Je kunt dit afleiden wanneer de journaalpost aan een beoordelaar wordt toegewezen of wanneer die de record voor het eerst opent.
Waarom dit belangrijk is Met deze activiteit meet je de overdrachtstijd naar de beoordelaar, oftewel de vertraging tussen indienen en de start van de beoordeling. Zo kunnen problemen met de toewijzing van bronnen of meldingen aan het licht komen. Waar je het vindt Dit wordt vaak niet expliciet vastgelegd. Je kunt het afleiden uit workflowtoewijzingen of door de indieningstimestamp te vergelijken met de eerste wijziging door een beoordelaar. Vastleggen Hiervoor moet je workflowlogboeken met gebruikerstoewijzingen of gebruikersactiviteiten analyseren. Die zijn mogelijk niet standaard beschikbaar. Eventtype inferred
	Journaal opnieuw ingediend ter goedkeuring	Een gecorrigeerde journaalpost wordt opnieuw naar de goedkeuringsworkflow gestuurd voor een nieuwe beoordelingsronde. Dit wordt afgeleid uit een statuswijziging van 'Rejected' of 'Draft' terug naar 'In Review' of 'Submitted'.
Waarom dit belangrijk is Deze activiteit markeert het begin van een herstelronde. Door deze gebeurtenissen te tellen, kun je het herstelpercentage en het gemiddelde aantal goedkeuringsrondes per journaalpost berekenen. Waar je het vindt Dit wordt afgeleid uit de workflowhistorie of door statuswijzigingen in LedgerJournalTable te volgen, waarbij de status van afgewezen teruggaat naar ingediend. Vastleggen Zoek voor dezelfde journaalpost naar een gebeurtenis met status 'Submitted' die volgt op een gebeurtenis met status 'Rejected'. Eventtype inferred
	Journaalpost gecorrigeerd	Deze activiteit geeft aan dat een eerder afgewezen journaalpost door een gebruiker is gewijzigd. Meestal wordt dit afgeleid door een wijziging in de journaalkop of de regels nadat de status 'Rejected' is vastgelegd.
Waarom dit belangrijk is Deze activiteit maakt herstelwerk expliciet zichtbaar. Door de frequentie en duur van correctierondes te analyseren, kun je het proces efficiënter maken en handmatig werk verminderen. Waar je het vindt Dit wordt afgeleid door de velden 'modifiedDateTime' en 'modifiedBy' in de tabellen LedgerJournalTable of LedgerJournalTrans te volgen nadat de gebeurtenis 'Journal Rejected' heeft plaatsgevonden. Vastleggen Vergelijk de timestamp van een status 'Rejected' met latere wijzigingstimestamps door de aanmaker. Eventtype inferred
	Journaalpost teruggedraaid	Dit markeert het einde van het terugdraaiproces, waarbij een terugdraaiende journaalpost succesvol is geboekt. Dit is een alternatief eindpunt in de levenscyclus van een onjuiste journaalpost.
Waarom dit belangrijk is Deze activiteit sluit gecorrigeerde journaalposten af en helpt de totale inspanning voor aanpassingen na het boeken te analyseren. Die inspanning heeft invloed op de algehele procesefficiëntie. Waar je het vindt Dit wordt vastgelegd wanneer de nieuwe terugdraaiende journaalpost zelf de status 'Posted' krijgt. De koppeling met de oorspronkelijke journaalpost blijft behouden via een referentieveld. Vastleggen Zoek de gebeurtenis met status 'Posted' voor de bijbehorende terugdraaiende journaalpost. Eventtype inferred
	Journaalregel toegevoegd	Deze gebeurtenis betekent dat een debet- of creditregel aan de journaalpost is toegevoegd. De gebeurtenis wordt vastgelegd telkens wanneer een nieuwe transactieregel wordt aangemaakt en aan de journaalkop wordt gekoppeld.
Waarom dit belangrijk is Door het aanmaken van afzonderlijke regels te volgen, krijg je inzicht in de complexiteit en de benodigde data-invoer voor verschillende journaaltypen. Je kunt ook vertragingen tussen het aanmaken van de kop en het afronden van de regels zichtbaar maken. Waar je het vindt De gebeurtenis wordt vastgelegd via de aanmaaktimestamp van records in de entiteit LedgerJournalTrans, gekoppeld aan de journaalkop. Elke aangemaakte regel is een afzonderlijke gebeurtenis. Vastleggen Gebruik het veld 'createdDateTime' voor elk record in de tabel LedgerJournalTrans. Eventtype explicit
	Poging tot boeken van journaalpost	Deze activiteit betekent dat een gebruiker het boeken van een goedgekeurde journaalpost heeft gestart. Je kunt dit expliciet vastleggen als het systeem het begin van de boekingstaak logt.
Waarom dit belangrijk is Door de poging tot boeken te onderscheiden van het succesvol boeken, kun je problemen met systeemprestaties of vertragingen in batchtaken opsporen die de financiële afsluiting beïnvloeden. Waar je het vindt Dit kan een expliciete gebeurtenis zijn in een tabel met batchtaakhistorie of worden afgeleid uit een statuswijziging naar 'Posting in progress' in LedgerJournalTable. Vastleggen Hiervoor moet je batchtaak- of systeemlogboeken analyseren die betrekking hebben op de boekingsroutine van het grootboek. Eventtype explicit
	Terugdraaien van journaalpost gestart	Deze gebeurtenis markeert de start van het terugdraaien van een eerder geboekte journaalpost. De gebeurtenis wordt vastgelegd wanneer een gebruiker de terugdraaiactie in het systeem start.
Waarom dit belangrijk is Door terugdraaiingen te volgen, zie je hoe vaak en waarom geboekte journaalposten worden gecorrigeerd. Dit kan wijzen op onderliggende problemen bij de eerste data-invoer of in de goedkeuringsfase. Waar je het vindt Dit is meestal een expliciete gebruikersactie die je kunt vastleggen via audit trails of door het aanmaken van een nieuwe terugdraaiende journaalpost te herkennen die aan de oorspronkelijke post is gekoppeld. Vastleggen Gebruik de aanmaakgebeurtenis van een nieuwe journaalpost die is gemarkeerd als terugdraaiing van een geboekte journaalpost. Eventtype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Microsoft Dynamics 365

Stappen

Ga naar de Data Management-werkruimte: Meld je aan bij je Microsoft Dynamics 365-omgeving. Gebruik de hoofdzoekbalk om de werkruimte 'Data management' te vinden en te openen.
Maak een nieuw exportproject: Kies in de Data Management-werkruimte de tegel 'Export' om een nieuw data-exportproject te maken. Geef het project een duidelijke naam, zoals 'ProcessMind_JournalEntry_Export'.
Kies het dataformaat: Geef in de projectgegevens het gewenste dataformaat op. Kies 'CSV' of 'Excel', zodat je de data daarna eenvoudig kunt transformeren.
Voeg de benodigde data-entiteiten toe: Dit is de belangrijkste stap. Voeg meerdere entiteiten aan het project toe om alle benodigde activiteiten en attributen vast te leggen. Klik per entiteit op 'Add entity' en zoek naar de volgende entiteitsnamen. Voeg ze bij voorkeur één voor één toe.
- Ledger journal headers: Legt gebeurtenissen vast voor aanmaken, boeken en terugdraaien.
- Ledger journal lines: Legt het toevoegen van afzonderlijke debet- en creditregels vast.
- Workflow tracking status table: Legt alle workflowgebeurtenissen vast, zoals indienen, goedkeuren en afwijzen.
Stel filters voor entiteiten in: Kies voor elke toegevoegde entiteit de optie 'Filter'. Gebruik filters om de omvang van de export te beperken. Filter minimaal op 'Legal entity' (bedrijf) en op een specifieke periode in een relevant datumveld, zoals CREATEDDATETIME in Ledger journal headers. Zo blijft de hoeveelheid data beheersbaar. Exporteer bijvoorbeeld de afgelopen 3 tot 6 maanden.
Koppel de entiteitsvelden: Controleer de veldkoppelingen voor elke entiteit. Zorg dat alle velden voor de uiteindelijke attributen in het exportbestand staan. Het systeem neemt standaard meestal alle velden op.
Voer de exporttaak uit: Klik na het instellen van het project op 'Export' in het Action Pane. Het systeem maakt een datapakket met afzonderlijke bestanden voor elke data-entiteit.
Download de geëxporteerde data: Ga na een geslaagde exporttaak naar de taakgeschiedenis en download het gegenereerde datapakket. Dit is een zipbestand.
Transformeer de data naar een event log: Voer deze stap buiten Dynamics 365 uit met een script, bijvoorbeeld Python of PowerShell, of met een datavoorbereidingstool. Combineer en transformeer de data uit de geëxporteerde bestanden naar één CSV-bestand met een event log. Maak voor elk bronbestand rijen voor specifieke activiteiten. Bijvoorbeeld:
- Maak in het bestand Ledger journal headers gebeurtenissen voor 'Journaalpost aangemaakt' op basis van de aanmaaktimestamp en voor 'Journaalpost geboekt' op basis van de boekingstimestamp.
- Maak in het bestand Ledger journal lines gebeurtenissen voor 'Journaalregel toegevoegd'.
- Koppel Workflow tracking status table aan de kopgegevens en maak gebeurtenissen voor 'Journaalpost ingediend ter goedkeuring', 'Journaalpost goedgekeurd' en 'Journaalpost afgewezen' op basis van de workflowstatus en timestamps.
- Leid gebeurtenissen zoals 'Journaalpost gecorrigeerd' af door te zoeken naar een gewijzigde timestamp na een gebeurtenis 'Journaalpost afgewezen'.
Structureer het uiteindelijke CSV-bestand: Zorg dat het getransformeerde bestand de verplichte kolommen bevat: JournalEntryId, ActivityName en EventTime, plus aanbevolen attributen. Sorteer het bestand eerst op JournalEntryId en daarna op EventTime.
Upload naar ProcessMind: Het uiteindelijke CSV-bestand met één event log is nu klaar om naar het ProcessMind-platform te uploaden voor analyse.

Configuratie

Data-entiteiten: De kern van de configuratie is het kiezen van de juiste entiteiten. De belangrijkste zijn Ledger journal headers, Ledger journal lines en Workflow tracking status table. Afhankelijk van je specifieke workflowconfiguratie heb je mogelijk extra entiteiten nodig.
Exportformaat: CSV wordt aanbevolen, omdat dit een universeel formaat is dat eenvoudig kan worden verwerkt met scripttalen en datatools voor de benodigde transformatiestap.
Filteren: Filteren op Legal Entity (bedrijf) is essentieel om te voorkomen dat je data uit irrelevante bedrijfseenheden exporteert. Een datumfilter, bijvoorbeeld op CREATEDDATETIME, is belangrijk om de prestaties en bestandsgrootte beheersbaar te houden. Voor een eerste analyse is een periode van 3 tot 6 maanden gebruikelijk.
Incrementele exports: Stel voor doorlopende monitoring incrementele exports in. Hiermee haal je alleen records op die sinds de vorige run zijn gewijzigd. Dat is veel efficiënter dan telkens een volledige export uitvoeren.
Rechten: Het gebruikersaccount waarmee je de exporttaak instelt en uitvoert, moet de rol 'Data management administrator' of gelijkwaardige rechten hebben voor toegang tot de Data Management-werkruimte en de onderliggende data-entiteiten.

a Voorbeeldquery sql

/*
This is not a single executable query. Instead, it defines the configuration of a Data Management Framework export project. The following entities and fields must be selected and then combined using an external script to build the final event log.
*/

-- Configuration for Entity 1: Ledger journal headers
-- Purpose: Extracts core journal header data for Created, Posted, and Reversal events.
-- Source Entity: Ledger journal headers
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Entry Created')
--   CREATEDBY -> UserName (for 'Journal Entry Created')
--   LedgerJournalWFApprovalStatus -> JournalStatus (for workflow context)
--   JournalType -> JournalType
--   company -> LegalEntity
--   PostedDateTime -> EventTime (for 'Journal Entry Posted')
--   PostedBy -> UserName (for 'Journal Entry Posted')
--   ReverseDate -> EventTime (for 'Journal Entry Reversal Initiated')
--   MODIFIEDDATETIME -> Used to infer 'Journal Entry Corrected'
--   MODIFIEDBY -> UserName

-- Configuration for Entity 2: Ledger journal lines
-- Purpose: Extracts individual transaction lines to create 'Journal Line Added' events.
-- Source Entity: Ledger journal lines
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Line Added')
--   CREATEDBY -> UserName (for 'Journal Line Added')
--   AmountInTransactionCurrency -> JournalTotalAmount (Note: Must be aggregated per JournalEntryId)
--   company -> LegalEntity

-- Configuration for Entity 3: Workflow tracking status table
-- Purpose: Extracts detailed workflow history for approval and rejection events.
-- Source Entity: Workflow tracking status table
-- Key Fields to Map:
--   ContextRecId -> (This needs to be joined back to the RecId of the LedgerJournalTable to get the JournalBatchNumber)
--   ContextTableId -> (Used to filter for Journal related workflows)
--   CREATEDDATETIME -> EventTime
--   User -> UserName
--   TrackingStatus -> Used to derive ActivityName ('Submitted For Approval', 'Journal Approved', 'Journal Rejected')
--   Comment -> RejectionReason

-- **Post-Processing Transformation Logic (to be implemented in an external script)**

-- 1. For each row in 'Ledger journal headers' export:
--    - Create one row with ActivityName = 'Journal Entry Created', EventTime = CREATEDDATETIME.
--    - If PostedDateTime is not null, create one row with ActivityName = 'Journal Entry Posted', EventTime = PostedDateTime.
--    - If ReverseDate is not null, create one row with ActivityName = 'Journal Entry Reversal Initiated', EventTime = ReverseDate. (A separate 'Journal Entry Reversed' event may need to be derived from the creation of the reversing journal).

-- 2. For each row in 'Ledger journal lines' export:
--    - Create one row with ActivityName = 'Journal Line Added', EventTime = CREATEDDATETIME.

-- 3. For each row in 'Workflow tracking status table' export (after joining to get JournalBatchNumber):
--    - IF TrackingStatus indicates submission, create ActivityName = 'Journal Submitted For Approval'.
--    - IF TrackingStatus indicates approval, create ActivityName = 'Journal Approved'.
--    - IF TrackingStatus indicates rejection, create ActivityName = 'Journal Rejected'.
--    - Other activities like 'Journal Review Started', 'Journal Entry Corrected', 'Journal Resubmitted For Approval', and 'Journal Posting Attempted' are often not explicitly logged. They must be inferred from status changes, user actions within a timeframe, or modification timestamps on the journal header after a rejection event.

Stappen

Stel de export van D365 naar Azure Data Lake in: Controleer voordat je query's uitvoert of de native functie 'Export to Azure Data Lake' van Microsoft Dynamics 365 is ingesteld en actief is. Selecteer de benodigde data-entiteiten voor het journaalpostproces, minimaal LedgerJournalTable, LedgerJournalTrans, GeneralJournalEntry, GeneralJournalAccountEntry en WorkflowTrackingStatusTable. Geef de eerste datasynchronisatie tijd om af te ronden.
Open Azure Synapse Analytics: Open Azure Portal en ga naar de Synapse Analytics-werkruimte die is gekoppeld aan het Azure Data Lake Storage-account met je Dynamics 365-data.
Open de SQL-database: Ga in Synapse Studio naar de hub 'Data'. Zoek de serverless SQL-database die boven op je data lake-bestanden is aangemaakt. De D365-entiteiten zijn beschikbaar als tabellen of views waarop je query's kunt uitvoeren.
Maak een nieuw SQL-script: Open de hub 'Develop' en maak een nieuw, leeg SQL-script. Hier bouw je de query voor het event log.
Kopieer en pas de query aan: Kopieer de volledige SQL-query uit de sectie 'query' van dit document naar de nieuwe scripteditor in Synapse Studio.
Werk placeholders bij: Controleer de query zorgvuldig en vervang alle placeholderwaarden. Werk de databasenaam en schemanaam bij, bijvoorbeeld [YourD365DB].[dbo], en stel de gewenste parameters StartDate en EndDate in voor je analyseperiode.
Voer de query uit: Voer het script uit met de serverless SQL-pool. De uitvoeringstijd hangt af van de periode en de hoeveelheid data in je systeem.
Controleer de resultaten: Na afloop toont het resultatenvenster het gegenereerde event log. Controleer kort of de kolommen (JournalEntryId, ActivityName, EventTime, enzovoort) en de data kloppen.
Exporteer het event log: Gebruik de exportfunctie in je querytool of Synapse Studio om de resultatenset als CSV-bestand op te slaan. Klik met de rechtermuisknop op de resultaten en kies een optie zoals 'Save as CSV'.
Bereid de upload voor: Controleer of het geëxporteerde CSV-bestand UTF-8-gecodeerd is en of de kolomkoppen overeenkomen met de vereisten van ProcessMind. Verdere datatransformatie is niet nodig.

Configuratie

Vereisten vooraf: Voor deze methode heb je een werkende integratie nodig tussen Microsoft Dynamics 365 Finance en een Azure Data Lake Storage Gen2-account. Je moet ook een Azure Synapse Analytics-werkruimte hebben ingesteld en geconfigureerd om deze data te bevragen. Gebruikers hebben de juiste leesrechten nodig in zowel Azure Synapse als het data lake.
Data-entiteiten: Zorg dat de volgende D365-entiteiten naar het data lake worden geëxporteerd: LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry en UserInfo.
Filteren op periode: De query bevat de parameters @StartDate en @EndDate. Begin bij voorkeur met een beperkte periode, bijvoorbeeld 3 tot 6 maanden, om queryprestaties en kosten beheersbaar te houden. Analyseer een representatieve periode van bedrijfsactiviteiten.
Filteren op juridische entiteit: Filter de query op DataAreaId (Legal Entity) om de analyse op één bedrijf te richten. In grote D365-omgevingen is dit een belangrijk prestatiefilter. Vervang de placeholder [YourLegalEntity].
Workflowconfiguratie: De logica voor goedkeurings- en afwijzingsgebeurtenissen in de query gaat uit van de standaardworkflowengine van D365, die data naar WorkflowTrackingStatusTable schrijft. Als je organisatie een ander of aangepast goedkeuringsmechanisme gebruikt, moet je de query aanpassen.

a Voorbeeldquery sql

DECLARE @StartDate DATETIME = '2023-01-01';
DECLARE @EndDate DATETIME = '2023-12-31';

WITH JournalHeaders AS (
    SELECT 
        JOURNALBATCHNUMBER AS JournalEntryId,
        JOURNALTYPE AS JournalType,
        DOCUMENTSTATUS AS JournalStatus, -- Captures Posted, etc.
        APPROVALSTATUS AS ApprovalStatus, -- Captures Draft, InReview, Approved, Rejected
        LOG AS RejectionReason, -- Often contains rejection comments
        POSTEDDATETIME, 
        CREATEDDATETIME,
        CREATEDBY,
        MODIFIEDDATETIME,
        MODIFIEDBY,
        DATA indignationId
    FROM 
        [YourD365DB].[dbo].LedgerJournalTable
    WHERE 
        CREATEDDATETIME BETWEEN @StartDate AND @EndDate
        AND DATA indignationId = '[YourLegalEntity]'
),
WorkflowEvents AS (
    SELECT 
        wtst.CONTEXTRECID,
        wtst.CONTEXTTABLEID,
        wtst.USERID,
        wtst.CREATEDDATETIME,
        wtst.TRACKINGSTATUS, -- Submitted, Approved, Rejected
        wtsi.INSTANCENUMBER
    FROM 
        [YourD365DB].[dbo].WorkflowTrackingStatusTable wtst
    JOIN 
        [YourD365DB].[dbo].WorkflowTrackingTable wtsi ON wtst.WORKFLOWTRACKINGTABLEINSTANCENUMBER = wtsi.RECID
    WHERE 
        wtst.CONTEXTTABLEID = (SELECT TABLEID FROM [YourD365DB].[dbo].SysTableIdTable WHERE NAME = 'LedgerJournalTable')
)

-- 1. Journal Entry Created
SELECT 
    jh.JournalEntryId AS JournalEntryId,
    'Journal Entry Created' AS ActivityName,
    jh.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    (SELECT SUM(ABS(jlt.AMOUNTCREDIT)) FROM [YourD365DB].[dbo].LedgerJournalTrans jlt WHERE jlt.JOURNALBATCHNUMBER = jh.JournalEntryId) AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.CREATEDBY = u.ID

UNION ALL

-- 2. Journal Line Added
SELECT 
    jlt.JOURNALBATCHNUMBER AS JournalEntryId,
    'Journal Line Added' AS ActivityName,
    jlt.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jlt.DATA indignationId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    [YourD365DB].[dbo].LedgerJournalTrans jlt
JOIN 
    JournalHeaders jh ON jlt.JOURNALBATCHNUMBER = jh.JournalEntryId AND jlt.DATA indignationId = jh.DataAreaId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jlt.CREATEDBY = u.ID

UNION ALL

-- 3. Journal Submitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Submitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted

UNION ALL

-- 4. Journal Review Started (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Review Started' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGTYPE = 5 -- Work item creation

UNION ALL

-- 5. Journal Approved
SELECT 
    jh.JournalEntryId,
    'Journal Approved' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Approved' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 5 -- Completion

UNION ALL

-- 6. Journal Rejected
SELECT 
    jh.JournalEntryId,
    'Journal Rejected' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Rejected' AS JournalStatus,
    jh.RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 3 -- Rejection

UNION ALL

-- 7. Journal Entry Corrected (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Entry Corrected' AS ActivityName,
    jh.MODIFIEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Corrected' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.MODIFIEDDATETIME > jh.CREATEDDATETIME AND
    EXISTS (
        SELECT 1 FROM WorkflowEvents we 
        WHERE we.CONTEXTRECID = jh.RecId AND we.TRACKINGSTATUS = 3 -- Rejection
        AND jh.MODIFIEDDATETIME > we.CREATEDDATETIME
    )

UNION ALL

-- 8. Journal Resubmitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Resubmitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted
    AND EXISTS (
        SELECT 1 FROM WorkflowEvents rej_we 
        WHERE rej_we.CONTEXTRECID = jh.RecId AND rej_we.TRACKINGSTATUS = 3 -- Rejection
        AND we.CREATEDDATETIME > rej_we.CREATEDDATETIME
    )

UNION ALL

-- 9. Journal Posting Attempted (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Posting Attempted' AS ActivityName,
    DATEADD(second, -5, jh.POSTEDDATETIME) AS EventTime, -- Approximated as just before posting
    jh.POSTEDDATETIME AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posting' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID -- Often posted by the last modifier or a system account
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 10. Journal Entry Posted
SELECT 
    jh.JournalEntryId,
    'Journal Entry Posted' AS ActivityName,
    jh.POSTEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posted' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 11. Journal Entry Reversal Initiated
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversal Initiated' AS ActivityName,
    gje_rev.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversing' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    [YourD365DB].[dbo].GeneralJournalEntry gje_rev ON gje.JOURNALNUMBER = gje_rev.OriginalJournalNumber
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje_rev.CREATEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes'

UNION ALL

-- 12. Journal Entry Reversed
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversed' AS ActivityName,
    gje.REVERSEDDATE AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversed' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje.MODIFIEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes' AND gje.REVERSEDDATE IS NOT NULL;

Stappen

Vereisten en omgeving instellen: Installeer Python 3.x op je computer. Installeer de benodigde Python-bibliotheken met pip: pip install pandas requests adal. De bibliotheek adal wordt gebruikt voor authenticatie met Azure Active Directory, die nodig is voor Dynamics 365.
Registreer een applicatie in Azure AD: Om toegang te krijgen tot de Dynamics 365 API, registreer je een applicatie in Azure Active Directory. Noteer de Application (client) ID en Directory (tenant) ID en maak een client secret aan. Geef deze applicatie gedelegeerde rechten voor Dynamics 365 Finance & Operations, zoals Financials.Read.
Configureer het Python-script: Kopieer het meegeleverde Python-script naar een bestand, bijvoorbeeld extract_journals.py. Vul de placeholdervariabelen bovenaan het script in met je Azure AD- en Dynamics 365-gegevens: TENANT_ID, CLIENT_ID, CLIENT_SECRET en D365_URL.
Stel extractieparameters in: Pas de variabelen START_DATE en END_DATE in het script aan om de periode voor de data-extractie vast te leggen. Je kunt ook de lijst LEGAL_ENTITIES aanpassen om specifieke bedrijfscodes te selecteren.
Voer het extractiescript uit: Start het script vanaf de opdrachtregel met python extract_journals.py. Het script meldt zich aan bij Azure AD, haalt een access token op en bevraagt de Dynamics 365 OData API naar journaalkop- en journaalregeldata binnen de opgegeven periode.
Volg de uitvoering van het script: Tijdens het ophalen van datapagina's uit de API toont het script voortgangsberichten in de console. Dit kan afhankelijk van de hoeveelheid data behoorlijk wat tijd kosten. Het script verwerkt paginering van de API automatisch en haalt alle relevante records op.
Controleer de onbewerkte data, optioneel: Het script slaat de opgehaalde data eerst op in raw_journal_headers.csv en raw_journal_lines.csv. Je kunt deze bestanden controleren om te zien of de eerste data-ophaling is gelukt voordat de transformatiestap wordt uitgevoerd.
Begrijp hoe events worden afgeleid: Het script verwerkt de onbewerkte data om de 12 vereiste procesactiviteiten af te leiden. 'Journaalpost ingediend ter goedkeuring' wordt bijvoorbeeld afgeleid wanneer het veld WorkflowApprovalStatus verandert van 'Draft' naar 'Submitted'. Voor zulke gebeurtenissen wordt de timestamp uit het veld ModifiedDateTime gebruikt.
Genereer het uiteindelijke event log: Na de verwerking combineert het script alle afgeleide gebeurtenissen in één gestructureerd event log. Het maakt de verplichte kolommen JournalEntryId, ActivityName en EventTime, plus andere aanbevolen attributen.
Exporteer en controleer het CSV-bestand: Het uiteindelijke event log wordt opgeslagen als journal_entry_event_log.csv. Open dit bestand om de structuur en inhoud te controleren. Controleer of de verwachte kolommen aanwezig zijn en of er data voor verschillende activiteiten is gegenereerd.
Bereid de upload naar ProcessMind voor: Het gegenereerde CSV-bestand heeft het juiste formaat voor upload. Controleer of het bestand UTF-8-gecodeerd is. Je kunt het nu als databron in ProcessMind gebruiken om je Record to Report-proces voor journaalposten te analyseren.

Configuratie

API-eindpunt-URL: De basis-URL voor je Dynamics 365 Finance & Operations OData-API. Stel deze in de variabele D365_URL in het script in, bijvoorbeeld https://your-org.operations.dynamics.com.
Azure AD-inloggegevens: Het script vereist een Azure AD-toepassingsregistratie. Je moet TENANT_ID, CLIENT_ID en CLIENT_SECRET opgeven voor de authenticatie.
Vereiste API-machtigingen: De Azure AD-toepassing heeft gedelegeerde machtigingen nodig om data uit Dynamics 365 te lezen. De machtiging Financials.Read is meestal voldoende voor toegang tot journaaldata.
Datumbereik: De variabelen START_DATE en END_DATE in het script bepalen de extractieperiode. Voor een eerste analyse raden we een periode van 3 tot 6 maanden aan. Zo houd je de hoeveelheid data beheersbaar en krijg je toch bruikbare procesinzichten.
Filter voor juridische entiteiten: Met de lijst LEGAL_ENTITIES in het script geef je op welke bedrijfscodes (dataAreaId) je in de extractie wilt opnemen. Dit is belangrijk om de analyse op de relevante delen van de bedrijfsvoering te richten.
Data-entiteiten: Het script bevraagt voornamelijk de OData-entiteiten LedgerJournalHeaders en LedgerJournalLines. Dit zijn standaardentiteiten voor journaalpostdata in Dynamics 365.
Toewijzing van statusvelden: De logica in het script om activiteiten af te leiden, is gebaseerd op het standaardveld WorkflowApprovalStatus. Als jouw implementatie een aangepast veld gebruikt om de journaalstatus bij te houden, moet je de veldnaam in het script aanpassen.

a Voorbeeldquery python

import adal
import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Azure AD Application Details
TENANT_ID = class="hl-string">'[Your Tenant ID]'
CLIENT_ID = class="hl-string">'[Your Application Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'

class=class="hl-string">"hl-comment"># Dynamics 365 F&O Environment Details
D365_URL = class="hl-string">'https://[your-d365-url].operations.dynamics.com'
RESOURCE = D365_URL
AUTHORITY_URL = fclass="hl-string">'https://login.microsoftonline.com/{TENANT_ID}'

class=class="hl-string">"hl-comment"># Extraction Parameters
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'
LEGAL_ENTITIES = [class="hl-string">'[YourLegalEntity1]', class="hl-string">'[YourLegalEntity2]'] class=class="hl-string">"hl-comment"># e.g., [class="hl-string">'USMF']

class=class="hl-string">"hl-comment"># --- OData Helper Functions ---

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    context = adal.AuthenticationContext(AUTHORITY_URL)
    token = context.acquire_token_with_client_credentials(RESOURCE, CLIENT_ID, CLIENT_SECRET)
    if class="hl-string">'accessToken' not in token:
        raise Exception(fclass="hl-string">"Failed to get access token: {token.get('error_description')}")
    return token[class="hl-string">'accessToken']

def execute_odata_query(entity_url, headers):
    class="hl-string">"""Executes a paginated OData query and returns a list of records."""
    all_records = []
    next_link = entity_url
    page_num = 1
    while next_link:
        print(fclass="hl-string">"Fetching page {page_num} for entity: {entity_url.split('/')[-1].split('?')[0]}...")
        response = requests.get(next_link, headers=headers)
        if response.status_code != 200:
            raise Exception(fclass="hl-string">"Query failed with status {response.status_code}: {response.text}")
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        next_link = data.get(class="hl-string">'@odata.nextLink')
        page_num += 1
    return all_records

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

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Journal Entry data extraction...")
    
    class=class="hl-string">"hl-comment"># 1. Get Access Token
    access_token = get_access_token()
    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">'Accept': class="hl-string">'application/json'
    }

    class=class="hl-string">"hl-comment"># 2. Build and Execute Queries
    legal_entity_filter = class="hl-string">" or ".join([fclass="hl-string">"dataAreaId eq '{le}'" for le in LEGAL_ENTITIES])
    date_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"

    class=class="hl-string">"hl-comment"># Query LedgerJournalHeaders
    headers_fields = [
        class="hl-string">'JournalBatchNumber', class="hl-string">'dataAreaId', class="hl-string">'LedgerJournalType', class="hl-string">'WorkflowApprovalStatus',
        class="hl-string">'CreatedBy', class="hl-string">'CreatedDateTime', class="hl-string">'ModifiedBy', class="hl-string">'ModifiedDateTime', class="hl-string">'PostedDateTime',
        class="hl-string">'JournalTotalDebit', class="hl-string">'Reversed', class="hl-string">'ReversedDate', class="hl-string">'RejectionReasonComment' class=class="hl-string">"hl-comment"># Assuming a field for rejection reason
    ]
    headers_select = fclass="hl-string">"$select={','.join(headers_fields)}"
    headers_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({date_filter})"
    headers_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalHeaders?{headers_select}&{headers_filter}&cross-company=true"
    
    journal_headers_raw = execute_odata_query(headers_url, headers)
    if not journal_headers_raw:
        print(class="hl-string">"No journal headers found for the specified criteria. Exiting.")
        exit()

    df_headers = pd.DataFrame(journal_headers_raw)
    df_headers.to_csv(class="hl-string">'raw_journal_headers.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_headers)} journal headers.")

    class=class="hl-string">"hl-comment"># Query LedgerJournalLines for class="hl-string">'Line Added' activity
    journal_batch_numbers = df_headers[class="hl-string">'JournalBatchNumber'].unique().tolist()
    journal_batch_filter = class="hl-string">" or ".join([fclass="hl-string">"JournalBatchNumber eq '{jbn}'" for jbn in journal_batch_numbers])
    
    lines_fields = [class="hl-string">'JournalBatchNumber', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']
    lines_select = fclass="hl-string">"$select={','.join(lines_fields)}"
    lines_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({journal_batch_filter})"
    lines_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalLines?{lines_select}&{lines_filter}&cross-company=true"

    journal_lines_raw = execute_odata_query(lines_url, headers)
    df_lines = pd.DataFrame(journal_lines_raw)
    df_lines.to_csv(class="hl-string">'raw_journal_lines.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_lines)} journal lines.")

    class=class="hl-string">"hl-comment"># 3. Transform Data into Event Log Format
    print(class="hl-string">"Transforming raw data into event log...")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Rename columns for consistency
    df_headers.rename(columns={
        class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId',
        class="hl-string">'dataAreaId': class="hl-string">'LegalEntity',
        class="hl-string">'LedgerJournalType': class="hl-string">'JournalType',
        class="hl-string">'JournalTotalDebit': class="hl-string">'JournalTotalAmount',
        class="hl-string">'WorkflowApprovalStatus': class="hl-string">'JournalStatus',
        class="hl-string">'RejectionReasonComment': class="hl-string">'RejectionReason'
    }, inplace=True)
    df_lines.rename(columns={class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId'}, inplace=True)

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Created
    df_created = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_created[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
    df_created.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_created)

    class=class="hl-string">"hl-comment"># Activity: Journal Line Added
    df_line_added = df_lines[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_line_added[class="hl-string">'ActivityName'] = class="hl-string">'Journal Line Added'
    df_line_added.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_line_added)

    class=class="hl-string">"hl-comment"># Activities inferred from status changes and modifications
    class=class="hl-string">"hl-comment"># This part requires a more stateful analysis if audit trails are not directly available
    class=class="hl-string">"hl-comment"># We use ModifiedDateTime as a proxy for the event time of status changes.
    
    class=class="hl-string">"hl-comment"># NOTE: The logic below is a simplified inference. A real implementation might require parsing audit trail logs for precise timestamps.
    status_events_map = {
        class="hl-string">'Submitted': class="hl-string">'Journal Submitted For Approval',
        class="hl-string">'InProgress': class="hl-string">'Journal Review Started', class=class="hl-string">"hl-comment"># Approximation
        class="hl-string">'Approved': class="hl-string">'Journal Approved',
        class="hl-string">'Rejected': class="hl-string">'Journal Rejected',
        class="hl-string">'ChangeRequested': class="hl-string">'Journal Rejected', class=class="hl-string">"hl-comment"># Map another status to Rejected
        class="hl-string">'Canceled': class="hl-string">'Journal Rejected' class=class="hl-string">"hl-comment"># Map another status to Rejected
    }

    status_change_df = df_headers[df_headers[class="hl-string">'JournalStatus'].isin(status_events_map.keys())].copy()
    status_change_df[class="hl-string">'ActivityName'] = status_change_df[class="hl-string">'JournalStatus'].map(status_events_map)
    status_change_df.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(status_change_df[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'RejectionReason']])

    class=class="hl-string">"hl-comment"># Activity: Journal Resubmitted For Approval & Journal Entry Corrected
    class=class="hl-string">"hl-comment"># Infer this by finding a class="hl-string">'Submitted' status that occurred after a class="hl-string">'Rejected' status for the same journal.
    class=class="hl-string">"hl-comment"># For simplicity, we assume any modification after rejection is a correction.
    df_rejected = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Rejected']
    for index, row in df_rejected.iterrows():
        class=class="hl-string">"hl-comment"># Check for modifications on the header after rejection
        header_row = df_headers[df_headers[class="hl-string">'JournalEntryId'] == row[class="hl-string">'JournalEntryId']].iloc[0]
        if pd.to_datetime(header_row[class="hl-string">'ModifiedDateTime']) > pd.to_datetime(row[class="hl-string">'EventTime']):
            class=class="hl-string">"hl-comment"># Add Corrected Event
            corrected_event = row.copy()
            corrected_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Corrected'
            corrected_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
            corrected_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
            event_log_frames.append(pd.DataFrame([corrected_event]))
            
            class=class="hl-string">"hl-comment"># If status went back to submitted, it's a resubmission
            if header_row[class="hl-string">'JournalStatus'] == class="hl-string">'Submitted':
                resubmitted_event = row.copy()
                resubmitted_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Resubmitted For Approval'
                resubmitted_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
                resubmitted_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
                event_log_frames.append(pd.DataFrame([resubmitted_event]))

    class=class="hl-string">"hl-comment"># Activity: Journal Posting Attempted (Approximation)
    class=class="hl-string">"hl-comment"># This is difficult to capture. We'll use the approval time as a proxy.
    df_approved_for_posting = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Approved'].copy()
    df_approved_for_posting[class="hl-string">'ActivityName'] = class="hl-string">'Journal Posting Attempted'
    event_log_frames.append(df_approved_for_posting[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Posted
    df_posted = df_headers[df_headers[class="hl-string">'PostedDateTime'].notna()].copy()
    if not df_posted.empty:
        df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Posted'
        class=class="hl-string">"hl-comment"># Use PostedDateTime if available, otherwise fallback to ModifiedDateTime
        df_posted[class="hl-string">'EventTime'] = df_posted[class="hl-string">'PostedDateTime'].fillna(df_posted[class="hl-string">'ModifiedDateTime'])
        df_posted.rename(columns={class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_posted[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Reversal Initiated & Reversed
    df_reversed = df_headers[df_headers[class="hl-string">'Reversed'] == True].copy()
    if not df_reversed.empty:
        class=class="hl-string">"hl-comment"># Reversal Initiated (approximated by modification date when Reversed flag is set)
        df_reversal_initiated = df_reversed.copy()
        df_reversal_initiated[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Initiated'
        df_reversal_initiated.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversal_initiated[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])
        class=class="hl-string">"hl-comment"># Reversed (using the specific ReversedDate)
        df_reversed_final = df_reversed[df_reversed[class="hl-string">'ReversedDate'].notna()].copy()
        df_reversed_final[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversed'
        df_reversed_final.rename(columns={class="hl-string">'ReversedDate': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversed_final[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># 4. Assemble Final Event Log
    print(class="hl-string">"Assembling the final event log...")
    final_event_log = pd.concat(event_log_frames, ignore_index=True)

    class=class="hl-string">"hl-comment"># Merge attributes from the header file
    attributes_to_merge = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'LegalEntity', class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason']].drop_duplicates()
    final_event_log = pd.merge(final_event_log, attributes_to_merge, on=class="hl-string">'JournalEntryId', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Clean up and order columns
    final_event_log[class="hl-string">'EventTime'] = pd.to_datetime(final_event_log[class="hl-string">'EventTime'])
    final_event_log.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'], inplace=True)
    final_event_log.drop_duplicates(subset=[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Define column order
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'LegalEntity',
        class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason'
    ]
    class=class="hl-string">"hl-comment"># Add missing columns with None
    for col in final_columns:
        if col not in final_event_log.columns:
            final_event_log[col] = None
    final_event_log = final_event_log[final_columns]
    
    class=class="hl-string">"hl-comment"># Add EventEndTime (optional, can be populated if duration is known)
    final_event_log[class="hl-string">'EventEndTime'] = None
    
    class=class="hl-string">"hl-comment"># 5. Export to CSV
    final_event_log.to_csv(class="hl-string">'journal_entry_event_log.csv', index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log with {len(final_event_log)} events saved to journal_entry_event_log.csv")

Stappen

Controleer of Power Platform Dataflows, de standaardconnector voor Dynamics 365 en de vereiste Dynamics 365-data-entiteiten beschikbaar zijn in de doelomgeving. Regel de machtigingen die nodig zijn om journaalkopregels, journaalregels, workflow- of goedkeuringshistorie, statushistorie, gebruikersinformatie, gegevens over juridische entiteiten en historie van terugboekingen of boekingen te lezen. Welke entiteiten precies beschikbaar zijn, hangt af van de Dynamics 365-applicatie en configuratie. Gebruik [Your table name] of [Configure based on your system] als de vereiste bron niet door de connector beschikbaar wordt gesteld.
Open in Power Apps de doelomgeving en maak een dataflow. Selecteer de standaardconnector voor Dynamics 365, geef de verbindingsgegevens van de omgeving op en meld je aan met een account dat gemachtigd is om de vereiste entiteiten te lezen. Neem geen inloggegevens op in de transformatielogica.
Voeg de entiteit voor journaalkopregels, de entiteit voor journaalregels en elke geconfigureerde bron toe waarin workflow-, status-, toewijzings-, audit-, boekings- en terugboekingsgebeurtenissen worden vastgelegd. Selecteer de velden die nodig zijn om het journaal, de timestamp van de gebeurtenis, de gebruiker, het journaaltype, de status, de reden voor afwijzing, de juridische entiteit en het totale bedrag te identificeren. Leg de werkelijke toewijzing van entiteiten en velden vast in de documentatie van de dataflow.
Pas in Power Query het geconfigureerde datumbereik en de filters voor bedrijf of juridische entiteit toe. Behoud de timestamps uit de bron en normaliseer ze naar één gedocumenteerde tijdzone. Zet identificatiegegevens om naar tekst, timestamps naar één consistent datetime-type, bedragen naar een numeriek type en statuswaarden naar consistente tekstwaarden. Verwijder records zonder bruikbare JournalEntryId of EventTime, tenzij je ze in een aparte uitzonderingsoutput bewaart.
Maak voor elk van de twaalf vereiste activiteiten één eventquery. Elke query moet expliciet rijen opleveren met JournalEntryId, ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity en JournalTotalAmount. Laat ProcessMind activiteiten niet afleiden uit statuswijzigingen of veldwijzigingen.
Implementeer de gebeurtenisregels met de beschikbare brondata. Gebruik timestamps voor het aanmaken van journaals voor Journal Entry Created, timestamps voor het aanmaken van regels voor Journal Line Added, workflow- of statusovergangen voor indiening, beoordeling, goedkeuring en afwijzing, wijzigingen na afwijzing voor Journal Entry Corrected, daaropvolgende indieningsovergangen voor Journal Resubmitted For Approval, registraties van de start en voltooiing van de boeking voor Journal Posting Attempted en Journal Entry Posted, en registraties van de start en voltooiing van een terugboeking voor Journal Entry Reversal Initiated en Journal Entry Reversed. Als een vereiste gebeurtenis niet expliciet beschikbaar is, configureer dan een controleerbare afleiding uit de bronhistorie en documenteer de regel.
Voeg alle twaalf eventqueries samen in één event-logquery. Controleer of elke uitvoerrij exact de vereiste kolomnamen heeft, ActivityName alleen de gedocumenteerde activiteitslabels bevat en EventTime is ingevuld. Sorteer op JournalEntryId en EventTime en pas daarna een deterministische tie-breaker toe als de bron die biedt.
Configureer de bestemming van de dataflow, bijvoorbeeld een ondersteunde lake, warehouse, database of bestandsbestemming die door het ProcessMind-ingestieproces wordt gebruikt. Sla het event log op als een platte tabel of bestand met scheidingstekens, met één rij per gebeurtenis. Behoud UTF-8-codering, ISO-compatibele datetime-waarden en een stabiel schema.
Vernieuw de dataflow voor de geselecteerde periode, controleer vernieuwingsfouten en afgewezen rijen en vergelijk de aantallen gebeurtenissen met de bronentiteiten en -historie. Corrigeer toewijzingen of filters voordat je de output publiceert.
Exporteer het voltooide event log of maak het beschikbaar voor upload naar ProcessMind. Wijs JournalEntryId toe als case-identificatie, ActivityName als activiteit, EventTime als timestamp van de gebeurtenis en de overige kolommen als gebeurtenis- of case-attributen. ProcessMind leest het event log zoals het is aangeleverd. Controleer daarom of alle activiteiten die nodig zijn voor de procesvisualisatie al als rijen aanwezig zijn.

Configuratie

Verbinding: Gebruik de standaardconnector voor Dynamics 365 via Power Platform Dataflows. Configureer de omgeving en authenticatie via de verbindingsinstellingen van het platform, niet in de querytekst.
Bronentiteiten: Selecteer de geconfigureerde entiteiten voor journaalkopregels, journaalregels, workflow- of goedkeuringshistorie, statushistorie, audithistorie, boekingshistorie, terugboekingshistorie, gebruikers en juridische entiteiten. De exacte namen verschillen per Dynamics 365-applicatie en aanpassing. Wijs ze daarom toe met [Your table name].
Vereiste uitvoerkolommen: JournalEntryId, ActivityName en EventTime moeten voor elke gebeurtenisrij zijn ingevuld.
Aanbevolen uitvoerkolommen: EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity en JournalTotalAmount.
Datumbereik: Begin met drie tot zes maanden historie. Breid het bereik pas uit nadat je de vernieuwingsduur, bronbewaartermijn en volledigheid van de gebeurtenissen hebt gecontroleerd. Neem een terugkijkperiode op als gebeurtenissen na de geselecteerde startdatum kunnen worden voltooid.
Filters: Pas filters voor bedrijfscode of juridische entiteit, journaaltype, documenttype, journaalstatus en EventTime alleen toe als ze overeenkomen met de analysedoelstelling. Filter afgewezen, gecorrigeerde, opnieuw ingediende, teruggeboekte of geboekte records die nodig zijn om de volledige levenscyclus te reconstrueren niet weg.
Incrementeel vernieuwen: Gebruik waar mogelijk een betrouwbare timestamp voor bronwijzigingen. Behoud laat binnengekomen workflow-, audit-, boekings- en terugboekingsrecords en verwijder duplicaten met een stabiele bronidentificatie voor de gebeurtenis of een gedocumenteerde samengestelde sleutel.
Tijdzones: Zet alle timestamps uit de bron om naar één gedocumenteerde tijdzone. Bewaar de oorspronkelijke timestamp als dat nodig is voor auditafstemming.
Prestaties: Filter waar mogelijk in de bron, selecteer alleen de vereiste kolommen, vermijd onnodige joins, aggregeer journaalregels voordat je totalen koppelt en partitioneer grote historische datasets of vernieuw ze incrementeel.
Datakwaliteit: Wijs rijen zonder JournalEntryId of EventTime af of rapporteer ze afzonderlijk. Normaliseer statuslabels en gebruikersidentificaties voordat je de eventqueries samenvoegt.
Vereisten: Mogelijkheid om Power Platform Dataflows te gebruiken, een verbinding met de Dynamics 365-connector, leestoegang tot alle geselecteerde entiteiten, toegang tot workflow-, audit-, boekings- en terugboekingshistorie waar nodig en een gelicentieerde of geautoriseerde ProcessMind-bestemming of uploadroute.
Configuratieafhankelijkheid: Dynamics 365 stelt niet in elke applicatie of implementatie dezelfde entiteiten en historische velden beschikbaar. Vervang de tijdelijke aanduidingen door de werkelijke geconfigureerde toewijzingen van entiteiten en velden voordat je de oplossing implementeert.

a Voorbeeldquery sql

WITH
JournalHeader AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [CreatedDateTime] AS CreatedDateTime,
        [ModifiedDateTime] AS ModifiedDateTime,
        [CreatedBy] AS CreatedBy,
        [ModifiedBy] AS ModifiedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal header entity]
    WHERE [CreatedDateTime] >= '[Start date parameter]'
      AND [CreatedDateTime] < '[End date parameter]'
      AND ([LegalEntity] IN ([Your company filter]) OR [Your company filter] IS NULL)
),
JournalLines AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [CreatedDateTime] AS EventTime,
        [CreatedBy] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal line entity]
    WHERE [CreatedDateTime] >= '[Start date parameter]'
      AND [CreatedDateTime] < '[End date parameter]'
),
StatusHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [StatusChangeDateTime] AS EventTime,
        [StatusChangeEndDateTime] AS EventEndTime,
        [ChangedBy] AS UserName,
        [PreviousStatus] AS PreviousStatus,
        [NewStatus] AS NewStatus,
        [JournalType] AS JournalType,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal status history entity]
    WHERE [StatusChangeDateTime] >= '[Start date parameter]'
      AND [StatusChangeDateTime] < '[End date parameter]'
),
ReviewHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ReviewStartDateTime] AS EventTime,
        [ReviewEndDateTime] AS EventEndTime,
        [Reviewer] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal review history entity]
    WHERE [ReviewStartDateTime] >= '[Start date parameter]'
      AND [ReviewStartDateTime] < '[End date parameter]'
),
PostingHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [PostingAttemptDateTime] AS PostingAttemptDateTime,
        [PostingDateTime] AS PostingDateTime,
        [PostingEndDateTime] AS PostingEndTime,
        [PostedBy] AS PostedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal posting history entity]
    WHERE [PostingAttemptDateTime] >= '[Start date parameter]'
      AND [PostingAttemptDateTime] < '[End date parameter]'
),
ReversalHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ReversalInitiatedDateTime] AS ReversalInitiatedDateTime,
        [ReversalCompletedDateTime] AS ReversalCompletedDateTime,
        [ReversalCompletedBy] AS ReversalCompletedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal reversal history entity]
    WHERE [ReversalInitiatedDateTime] >= '[Start date parameter]'
      AND [ReversalInitiatedDateTime] < '[End date parameter]'
),
CorrectionHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ModificationDateTime] AS EventTime,
        [ModificationEndDateTime] AS EventEndTime,
        [ModifiedBy] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal audit or modification history entity]
    WHERE [ModificationDateTime] >= '[Start date parameter]'
      AND [ModificationDateTime] < '[End date parameter]'
),
EventLog AS (
    SELECT JournalEntryId, 'Journal Entry Created' AS ActivityName, CreatedDateTime AS EventTime, CreatedDateTime AS EventEndTime, CreatedBy AS UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM JournalHeader WHERE JournalEntryId IS NOT NULL AND CreatedDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Line Added' AS ActivityName, EventTime, EventTime AS EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM JournalLines WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Submitted For Approval' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND (NewStatus IN ('In Review', 'Submitted') OR (PreviousStatus = 'Draft' AND NewStatus IN ('In Review', 'Submitted')))
    UNION ALL
    SELECT JournalEntryId, 'Journal Review Started' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM ReviewHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Approved' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND NewStatus = 'Approved'
    UNION ALL
    SELECT JournalEntryId, 'Journal Rejected' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND NewStatus IN ('Rejected', 'Needs Correction')
    UNION ALL
    SELECT c.JournalEntryId, 'Journal Entry Corrected' AS ActivityName, c.EventTime, c.EventEndTime, c.UserName, c.JournalType, c.JournalStatus, c.RejectionReason, c.LegalEntity, c.JournalTotalAmount FROM CorrectionHistory c WHERE c.JournalEntryId IS NOT NULL AND c.EventTime IS NOT NULL AND EXISTS (SELECT 1 FROM StatusHistory s WHERE s.JournalEntryId = c.JournalEntryId AND s.NewStatus IN ('Rejected', 'Needs Correction') AND s.EventTime < c.EventTime)
    UNION ALL
    SELECT JournalEntryId, 'Journal Resubmitted For Approval' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND PreviousStatus IN ('Rejected', 'Needs Correction', 'Draft') AND NewStatus IN ('In Review', 'Submitted')
    UNION ALL
    SELECT JournalEntryId, 'Journal Posting Attempted' AS ActivityName, PostingAttemptDateTime AS EventTime, PostingAttemptDateTime AS EventEndTime, PostedBy AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM PostingHistory WHERE JournalEntryId IS NOT NULL AND PostingAttemptDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Posted' AS ActivityName, PostingDateTime AS EventTime, PostingEndTime AS EventEndTime, PostedBy AS UserName, JournalType, 'Posted' AS JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM PostingHistory WHERE JournalEntryId IS NOT NULL AND PostingDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Reversal Initiated' AS ActivityName, ReversalInitiatedDateTime AS EventTime, ReversalInitiatedDateTime AS EventEndTime, CAST(NULL AS varchar(255)) AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM ReversalHistory WHERE JournalEntryId IS NOT NULL AND ReversalInitiatedDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Reversed' AS ActivityName, ReversalCompletedDateTime AS EventTime, ReversalCompletedDateTime AS EventEndTime, ReversalCompletedBy AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM ReversalHistory WHERE JournalEntryId IS NOT NULL AND ReversalCompletedDateTime IS NOT NULL
)
SELECT
    JournalEntryId,
    ActivityName,
    EventTime,
    EventEndTime,
    UserName,
    JournalType,
    JournalStatus,
    RejectionReason,
    LegalEntity,
    JournalTotalAmount
FROM EventLog
WHERE JournalEntryId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY JournalEntryId, EventTime, ActivityName;

Klaar om aan de slag te gaan?

Met deze template heb je alles wat je nodig hebt om je Record to Report-proces voor journaalposten te verbeteren. Gebruik je data om efficiënter te werken en je financiële rapportagecycli vandaag nog te versnellen.

Terug naar de verbetergids Template downloaden

Verbeter journaalposten in Dynamics 365 en rapporteer sneller

Verwijder knelpunten en verkort de doorlooptijd van R2R-journaalposten met 30%.

Start je gratis proefperiode

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

Jouw datatemplate voor Record to Report - journaalposten

Jouw datatemplate voor Record to Report - journaalposten

Van vastlegging tot rapportage - attributen van journaalposten

Van vastlegging tot rapportage - activiteiten van journaalposten

Extractiegidsen

Export uit het Data Management Framework van Microsoft Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

Azure Data Lake-query via Synapse voor Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

Data-extractie met een Python-script via de Dynamics 365 OData API

Stappen

Configuratie

a Voorbeeldquery python

Extractie met Power Platform Dataflows uit Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Verbeter journaalposten in Dynamics 365 en rapporteer sneller

Jouw datatemplate voor Record to Report - journaalposten

Jouw datatemplate voor Record to Report - journaalposten

Van vastlegging tot rapportage - attributen van journaalposten

Van vastlegging tot rapportage - activiteiten van journaalposten

Extractiegidsen

Export uit het Data Management Framework van Microsoft Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

Azure Data Lake-query via Synapse voor Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

Data-extractie met een Python-script via de Dynamics 365 OData API

Stappen

Configuratie

a Voorbeeldquery python

Extractie met Power Platform Dataflows uit Dynamics 365

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Verbeter journaalposten in Dynamics 365 en rapporteer sneller

We respecteren je privacy