> Continu verbeteren van processen > Record to Report journaalposten > Microsoft Dynamics 365 > Datatemplate

Datatemplate voor registratie tot rapportage van journaalposten

Microsoft Dynamics 365

Attributen voor het proces van vastlegging tot rapportage voor journaalposten(20) Activiteiten in het proces van vastlegging tot rapportage voor journaalposten(12) Extractiegidsen(4)

Datatemplate voor registratie tot rapportage van journaalposten

Deze template geeft een praktisch overzicht van de gegevens die je nodig hebt om het proces van vastlegging tot rapportage voor journaalposten te analyseren. Je leest welke attributen je verzamelt en welke activiteiten je volgt, zodat je event log alle informatie bevat voor een goede process mining-analyse. Ook vind je uitleg over hoe je deze data uit het bronsysteem haalt.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Extractie-instructies voor Microsoft Dynamics 365

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

Template downloaden

Attributen voor het proces van vastlegging tot rapportage voor journaalposten

Dit zijn de aanbevolen datavelden voor je event log, zodat je het proces van vastlegging tot rapportage voor journaalposten volledig kunt analyseren.

3 Verplicht 7 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de specifieke processtap of gebeurtenis die heeft plaatsgevonden.
Beschrijving Dit attribuut beschrijft één gebeurtenis of taak binnen de levenscyclus van een journaalpost, zoals 'Journaalpost aangemaakt', 'Journaalpost ter goedkeuring ingediend' of 'Journaalpost geboekt'. Deze activiteiten vormen de knooppunten van de ontdekte proceskaart. De volgorde en frequentie van deze activiteiten analyseren is een belangrijk onderdeel van process mining. Zo zie je hoe het proces werkelijk verloopt, kun je afwijkingen van de standaardprocedure opsporen en bottlenecks vinden waar activiteiten langer duren dan verwacht of worden herhaald. Waarom dit belangrijk is Dit attribuut beschrijft de processtappen. Daarmee vormt het de basis van de proceskaart en kun je de processtroom en variaties analyseren. Waar vind je dit? Dit is een conceptueel attribuut dat wordt afgeleid uit systeemgebeurtenissen, statuswijzigingen of workflowlogboeken in Microsoft Dynamics 365. Voorbeelden Journaalpost aangemaaktJournaalpost ter goedkeuring ingediendJournaalpost goedgekeurdJournaalpost geboekt
	ID van journaalpost JournalEntryId	De unieke identificatiecode van een journaalpost, die als primaire case-ID dient.
Beschrijving Het ID van de journaalpost koppelt alle activiteiten en datapunten van één journaaltransactie op unieke wijze aan elkaar. Zo kun je de volledige levenscyclus van een journaalpost volgen, van aanmaak en beoordeling tot de uiteindelijke boeking in het grootboek. Bij process mining is dit attribuut essentieel om de processtroom te reconstrueren. Elk uniek ID staat voor één procesinstantie. Zo kun je procesvarianten, doorlooptijden en compliance voor afzonderlijke financiële transacties in detail analyseren. Waarom dit belangrijk is Dit is de sleutel waarmee je een journaalpost van begin tot eind volgt en de volledige processtroom per case analyseert. Waar vind je dit? Deze identificatiecode staat meestal in de tabel met journaalkoppen, zoals LedgerJournalTable, vaak in een veld met de naam JournalNum. Voorbeelden JRN-0012345JV-2023-08-156GENJ0000891
	Tijdstip van gebeurtenis EventTime	De precieze timestamp waarop een activiteit of gebeurtenis plaatsvond.
Beschrijving Het tijdstip van de gebeurtenis legt de datum en tijd vast waarop een specifieke activiteit in het journaalpostproces plaatsvond. Deze chronologische data is nodig om gebeurtenissen op volgorde te zetten en de tijd ertussen te berekenen. Bij analyses gebruik je deze timestamp om voor elke case een tijdlijn op te bouwen. Dat is nodig om tijdsgebonden metrieken te berekenen, zoals doorlooptijden, verwerkingstijden en wachttijden. Zo kun je vertragingen tussen stappen opsporen en dashboards maken over bottlenecks en naleving van SLA’s. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen in de juiste volgorde te zetten en alle tijdsgebonden KPI’s te berekenen, zoals doorlooptijden en vertragingen in de verwerking. Waar vind je dit? Timestamps van gebeurtenissen staan meestal in workflowgeschiedenislogboeken, tabellen met auditsporen (bijvoorbeeld SysDatabaseLog) of als aanmaak- en wijzigingstimestamps van 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 waarop een activiteit of gebeurtenis is afgerond.
Beschrijving De eindtijd van de gebeurtenis geeft aan wanneer een specifieke activiteit is afgerond. StartTime geeft aan wanneer een gebeurtenis begint; EndTime vormt de andere grens en maakt het mogelijk de duur van afzonderlijke taken nauwkeurig te berekenen. Met zowel een begin- als eindtijd kun je bij process mining de verwerkingstijd van een activiteit berekenen, los van de wachttijd. Dit is belangrijk voor dashboards die gebruikersprestaties analyseren en laten zien welke taken de meeste tijd kosten, niet alleen de wachttijd ertussen. Waarom dit belangrijk is Maakt het mogelijk om nauwkeurig te berekenen hoelang elke activiteit duurt. Zo kun je gebruikersprestaties analyseren en taken opsporen die veel middelen vragen. Waar vind je dit? Deze data kan expliciet zijn opgeslagen in workflowlogboeken. Je kunt de eindtijd ook afleiden uit 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 geeft aan welke medewerker of systeemgebruiker verantwoordelijk is voor een activiteit, zoals het aanmaken, goedkeuren of boeken van een journaalpost. Zo koppel je processtappen aan gebruikers. Prestaties per gebruiker analyseren is een belangrijke functie van process mining. Je kunt er het dashboard 'Prestaties van gebruikers bij journaalposten' mee maken en de activiteitsduur en doorvoer van verschillende gebruikers of teams vergelijken. Zo zie je wie goed presteert, waar training nodig is en hoe je het werk beter kunt verdelen. Waarom dit belangrijk is Koppelt procesactiviteiten aan specifieke personen. Zo kun je gebruikersprestaties, werkverdeling en de inzet van middelen analyseren. Waar vind je dit? Gebruikersgegevens staan meestal in de velden createdBy of modifiedBy van tabellen zoals LedgerJournalTable, of in bijbehorende workflowgeschiedenislogboeken. 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 ‘Concept’, ‘In beoordeling’, ‘Goedgekeurd’, ‘Afgewezen’ of ‘Geboekt’. Zo zie je in welke fase van de levenscyclus de post zich bevindt. Door de status te analyseren, krijg je inzicht in de uitkomsten van cases. Je kunt bijvoorbeeld alle afgewezen journaalposten filteren of bijhouden hoeveel posten zich in een bepaalde fase bevinden. Dit attribuut geeft context aan doorvoer- en statusanalyses in verschillende dashboards. Waarom dit belangrijk is Geeft voor elke journaalpost een duidelijke uitkomst. Zo kun je slagings- en afwijzingspercentages analyseren en zien hoeveel werk zich in elke fase bevindt. Waar vind je dit? De status staat vaak in de tabel met journaalkoppen, LedgerJournalTable, of is af te leiden uit de workflowstatus. Voorbeelden ConceptIngediendGoedgekeurdGeboektAfgewezen
	Rechtspersoon LegalEntity	De rechtspersoon of bedrijfscode waarvoor de journaalpost wordt vastgelegd.
Beschrijving De rechtspersoon is het specifieke bedrijf of de 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 dit attribuut gebruiken om het proces voor journaalposten in verschillende delen van de organisatie te vergelijken. Zo zie je of bepaalde rechtspersonen efficiënter werken, vaker posten afwijzen of langere doorlooptijden hebben. Dat helpt om goede werkwijzen te vinden en te delen. Waarom dit belangrijk is Maakt het mogelijk om de procesprestaties van verschillende bedrijven of bedrijfseenheden te vergelijken en verschillen en verbeterkansen zichtbaar te maken. Waar vind je dit? Dit is een standaardveld 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 waardevol voor oorzaakanalyse. Dit is het belangrijkste attribuut voor het dashboard ‘Analyse van afwijzingen van journaalposten’. Door afwijzingsredenen te categoriseren en analyseren, kunnen organisaties terugkerende problemen opsporen, zoals ontbrekende documentatie, beleidsovertredingen of invoerfouten. Vervolgens kunnen ze gerichte trainingen geven of processen verbeteren. Waarom dit belangrijk is Laat zien waarom herstelwerk nodig is. Zo kun je afwijzingen verminderen en journaalposten vaker in één keer goedgekeurd krijgen. Waar vind je dit? Deze informatie staat meestal in de workflowgeschiedenis of in de opmerkingen bij de afwijzingsstap. Voorbeelden Onvoldoende onderbouwende documentatieVerkeerde rekening gebruiktOverschrijdt de goedkeuringslimietDubbele invoer
	Totaalbedrag journaalpost JournalTotalAmount	De totale geldwaarde van de journaalpost, meestal de som van de debetbedragen.
Beschrijving Dit attribuut geeft de totale financiële waarde van de journaalpost weer. Je kunt posten indelen in waardeklassen, bijvoorbeeld laag, gemiddeld en hoog. Een analyse op basis van financiële waarde kan belangrijke patronen aan het licht brengen. Journaalposten met een hoge waarde doorlopen bijvoorbeeld mogelijk een strenger goedkeuringsproces, met meer stappen en langere doorlooptijden. Dit attribuut is belangrijk voor materialiteitsanalyses en om de financiële gevolgen van procesinefficiëntie te begrijpen. Waarom dit belangrijk is Maakt het mogelijk om het proces op financiële waarde in te delen. Die waarde hangt vaak samen met de complexiteit, risico’s en goedkeuringsworkflows. Waar vind je dit? Mogelijk moet je dit bedrag berekenen door voor elke journaalpost de debetbedragen uit de journaalregeltabel LedgerJournalTrans op te tellen. Voorbeelden 1500.75125000.0050.25
	Type journaalpost JournalType	De classificatie van de journaalpost, bijvoorbeeld algemeen journaal of transitorische post.
Beschrijving Het type journaalpost deelt journaalposten in op basis van hun bedrijfsdoel, bijvoorbeeld dagelijkse boekingen, transitorische posten, toewijzingen of eliminaties. Met deze indeling kun je verschillende procesroutes en werkwijzen beter begrijpen. Met dit attribuut kun je het proces voor verschillende typen journaalposten filteren en vergelijken. Het is nodig voor het dashboard 'Doorvoer van journaalposten per type'. Daarmee kun je analyseren of bepaalde typen vaker vertraging oplopen, worden afgewezen of herstelwerk vragen. Waarom dit belangrijk is Hiermee kun je de analyse opdelen en processen voor verschillende bedrijfsdoelen vergelijken. Die kunnen elk hun eigen procesroute, doorlooptijd en goedkeuringsvereisten hebben. Waar vind je dit? Dit staat meestal in de tabel met journaalkoppen, LedgerJournalTable, in een veld voor journaalnamen of -typen, bijvoorbeeld JournalName. Voorbeelden Algemeen journaalOverlopende correctieIntercompany-overboekingSalarisadministratie
	Afdeling DepartmentName	De afdeling of kostenplaats die bij de journaalpost hoort.
Beschrijving De afdeling of kostenplaats geeft aan welke interne bedrijfseenheid verantwoordelijk is voor de financiële transactie of erdoor wordt geraakt. Dit is een belangrijke dimensie voor interne managementrapportages. Met dit attribuut kun je het proces voor journaalposten per afdeling analyseren. Zo kun je vragen beantwoorden als: Welke afdelingen dienen de meeste journaalposten in? Worden posten van bepaalde afdelingen vaker afgewezen of duurt de goedkeuring daar langer? Dit helpt bij gerichte procesverbetering. Waarom dit belangrijk is Maakt het mogelijk om procesprestaties per bedrijfsfunctie te analyseren en afdelingsspecifieke bottlenecks of trainingsbehoeften op te sporen. Waar vind je dit? Deze informatie staat meestal op regelniveau in LedgerJournalTrans, als financiële dimensie. Voorbeelden VerkoopFinanciënMarketingBedrijfsvoering
	Automatisch geboekt IsAutomatedPosting	Een aanduiding 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 posten die automatisch door het systeem of een subsysteem zijn gegenereerd, bijvoorbeeld via een systeemintegratie of automatische toewijzing. Door dit attribuut te analyseren, kun je de efficiëntie en foutpercentages van automatische en handmatige processen vergelijken. Je ziet waar verdere automatisering mogelijk is, bijvoorbeeld als handmatige invoer vaker leidt tot fouten, herstelwerk of vertragingen. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en automatische processen, zodat je de efficiëntie, nauwkeurigheid en compliance kunt vergelijken. Waar vind je dit? Dit kan blijken uit de gebruiker bij ‘Gemaakt door’ (bijvoorbeeld een systeem- of batchgebruiker) of uit een specifieke aanduiding in de configuratie van de journaalkop of het journaaltype. 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 invloed heeft op de saldi in het grootboek. Deze datum is belangrijk voor financiële rapportages en afsluitperioden. Met dit attribuut analyseer je de tijd tussen goedkeuring en boeking. Dat is waar de KPI ‘Doorlooptijd tot boeking van journaalposten’ op gericht is. Die tijd verkorten is vaak een belangrijk doel om de financiële afsluiting te versnellen. Je kunt er ook boekingsvolumes over een bepaalde periode mee analyseren. Waarom dit belangrijk is Belangrijk voor de KPI voor de doorlooptijd tot boeking en om vertragingen te begrijpen tussen goedkeuring en het moment waarop een transactie officieel in het grootboek staat. Waar vind je dit? Deze datum staat meestal in de tabel met journaalkoppen (LedgerJournalTable) of in gerelateerde tabellen met geboekte transacties. Voorbeelden 2023-10-282023-11-012023-10-31
	Bronsysteem SourceSystem	Het systeem waaruit de data is opgehaald.
Beschrijving Dit attribuut geeft aan uit welke brontoepassing de journaalpostgegevens komen. Voor dit proces is de waarde meestal een vaste aanduiding, zoals 'Microsoft Dynamics 365'. Bij bredere analyses, vooral in omgevingen met meerdere ERP- of geïntegreerde systemen, helpt dit veld processen en databronnen van elkaar te onderscheiden. Het maakt duidelijk waar de data vandaan komt en is belangrijk voor datagovernance en validatie. Waarom dit belangrijk is Geeft aan waar de data vandaan komt. Dat is belangrijk voor datagovernance en analyses die meerdere bedrijfssystemen omvatten. Waar vind je dit? Dit is een vaste waarde die tijdens het proces van data-extractie, transformatie en laden (ETL) wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Microsoft Dynamics 365D365 F&O
	Goedkeuringsniveau ApprovalLevel	Geeft de huidige of afgeronde fase aan in een workflow met meerdere goedkeuringsniveaus.
Beschrijving Bij journaalposten waarvoor meerdere goedkeuringen nodig zijn, houdt dit attribuut bij welk niveau van de hiërarchie de post heeft bereikt, bijvoorbeeld ‘Goedkeuring door manager’ of ‘Goedkeuring door directeur’. Dit attribuut helpt om bottlenecks in het goedkeuringsproces nader te analyseren. Je kunt ermee vaststellen of vertragingen steeds op hetzelfde niveau in de goedkeuringsketen ontstaan. Dat kan aanleiding zijn om het proces opnieuw in te richten of op dat niveau middelen anders in te zetten. Waarom dit belangrijk is Geeft inzicht in workflows met meerdere goedkeuringsfasen en helpt bottlenecks op specifieke goedkeuringsniveaus op te sporen. Waar vind je dit? Deze informatie is af te leiden uit het workflowlogboek, waarin de afronding van de verschillende goedkeuringsstappen wordt bijgehouden. Voorbeelden Niveau 1: managerNiveau 2: directeurNiveau 3: financieel directeur
	Herstelwerk IsRework	Een aanduiding voor activiteiten 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 ter goedkeuring ingediend’. Zo kun je herstelwerk afzonderlijk bekijken en kwantificeren. Dit attribuut is belangrijk voor het dashboard ‘Herstel- en correctielussen bij journaalposten’ en de KPI ‘Herstelpercentage’. Met deze aanduiding kun je de frequentie en impact van correctierondes eenvoudig in beeld brengen en meten. Die rondes zijn een belangrijke bron van inefficiëntie in het proces. Waarom dit belangrijk is Markeert herstelwerk in inefficiënte lussen, zodat je eenvoudig kunt meten wat afwijzingen en correcties betekenen voor de totale doorlooptijd en kosten. Waar vind je dit? Dit berekende attribuut wordt afgeleid tijdens de datatransformatie, door de volgorde van activiteiten binnen een case te analyseren. Voorbeelden truefalse
	In één keer goedgekeurd IsFirstTimeRight	Een aanduiding die aangeeft of het journaal is goedgekeurd zonder eerdere afwijzingen.
Beschrijving Dit booleaanse attribuut op caseniveau is true als een journaalpost na indiening wordt goedgekeurd zonder tussentijdse activiteiten als ‘Journaal afgewezen’ of ‘Journaalpost gecorrigeerd’. Het is een belangrijke maatstaf voor de 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 duiden op structurele problemen met de kwaliteit van de eerste invoer, onduidelijke vereisten of de manier waarop posten worden ingediend. Waarom dit belangrijk is Dit is een belangrijke maatstaf voor de proceskwaliteit. Je ziet hoeveel journaalposten het goedkeuringsproces doorlopen zonder herstelwerk. Waar vind je dit? Dit berekende attribuut wordt op caseniveau afgeleid door de activiteitenvolgorde voor elke journaalpost-ID te analyseren. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor het laatst uit het bronsysteem is bijgewerkt.
Beschrijving Dit attribuut geeft de datum en tijd aan waarop de data voor het laatst uit het bronsysteem is opgehaald. Zo weet je hoe actueel de analyse en de gebruikte data zijn. Door deze informatie op dashboards te tonen, zien gebruikers hoe recent de data is en welke periode de huidige procesanalyse bestrijkt. Dit is belangrijke metadata voor elk process mining-project. Waarom dit belangrijk is Geeft belangrijke informatie over hoe actueel de data is, zodat gebruikers weten hoe recent de procesanalyse is. Waar vind je dit? Deze timestamp wordt aangemaakt en opgeslagen tijdens het proces van data-extractie, transformatie en laden (ETL). 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 de post binnen de streeftijd uit de Service Level Agreement (SLA) is afgehandeld. Mogelijke waarden zijn meestal ‘Gehaald’ en ‘Overschreden’. Dit is de belangrijkste metriek voor het dashboard ‘SLA-compliance voor goedkeuring van journaalposten’. Je ziet hoe de prestaties zich verhouden tot de doelen. Zo kun je de tijdigheid van het goedkeuringsproces volgen en bijsturen wanneer SLA’s vaak niet worden gehaald. Waarom dit belangrijk is Zet ruwe gegevens over doorlooptijden om in een duidelijke uitkomst voor de bedrijfsvoering (gehaald of overschreden), zodat je prestaties eenvoudig met doelen kunt vergelijken. Waar vind je dit? Dit is een berekend attribuut. De berekening vergelijkt de berekende KPI voor de goedkeuringscyclus met een vooraf bepaald SLA-doel. Voorbeelden GehaaldOverschreden
	Valutacode CurrencyCode	De valuta van het bedrag van de journaalpost.
Beschrijving Dit attribuut geeft aan in welke valuta het bedrag van de journaalpost is uitgedrukt, bijvoorbeeld USD, EUR of GBP. Zo krijgt het totaalbedrag van de journaalpost de juiste context. De valuta is niet altijd nodig om de processtroom zelf te analyseren, maar wel voor financiële rapportages en analyses op basis van journaalbedragen. Je kunt bedragen zo correct optellen en vergelijken, vooral binnen multinationale organisaties. Waarom dit belangrijk is Geeft financiële analyses de nodige context, zodat geldbedragen correct worden geïnterpreteerd, vooral wanneer meerdere valuta worden gebruikt. Waar vind je dit? De valutacode staat meestal in de journaalregeltabel LedgerJournalTrans. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Activiteiten in het proces van vastlegging tot rapportage voor journaalposten

Leg deze belangrijke processtappen en mijlpalen vast in je event log voor een nauwkeurige procesontdekking en -analyse.

5 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Journaalpost aangemaakt	Deze activiteit markeert het begin van een nieuwe journaalpost. De activiteit wordt vastgelegd wanneer een gebruiker een nieuwe journaalkop in het systeem aanmaakt. Daarbij krijgt de journaalpost een uniek ID dat als case-ID dient voor procesanalyse.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. Door de tijd vanaf dit moment tot aan het boeken te analyseren, kun je de totale doorlooptijd meten en vertragingen bij de eerste gegevensinvoer opsporen. Waar vind je dit? Deze gebeurtenis wordt vastgelegd aan de hand van de aanmaaktimestamp van de journaalkop in de entiteit GeneralJournalEntry of LedgerJournalTable. Meestal gaat het om een expliciete gebeurtenis waarbij een record wordt aangemaakt. Vastleggen Gebruik het veld 'createdDateTime' in GeneralJournalEntry of LedgerJournalTable. Gebeurtenistype explicit
	Journaalpost afgewezen	Een beoordelaar of goedkeurder heeft de journaalpost afgewezen en er zijn correcties nodig. Deze gebeurtenis wordt vastgelegd als een statuswijziging van 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 opsporen. Zo worden problemen met datakwaliteit, compliance of gebruikerstraining zichtbaar. Waar vind je dit? Dit wordt afgeleid uit een wijziging van een statusveld, bijvoorbeeld wanneer ApprovalStatus verandert in 'Rejected' in LedgerJournalTable, of uit het workflowlogboek. Vastleggen Bepaal de timestamp waarop de status van de journaalpost verandert in 'Rejected'. Gebeurtenistype inferred
	Journaalpost geboekt	Deze activiteit markeert het succesvol boeken van de journaalpost in het grootboek. Daarmee wordt het een officieel financieel record. De gebeurtenis wordt vastgelegd wanneer de status van de journaalkop wordt bijgewerkt naar 'Posted'.
Waarom dit belangrijk is Dit is de belangrijkste eindgebeurtenis bij een geslaagd proces. Je gebruikt deze om de totale doorlooptijd en de tijd tot het boeken te berekenen, belangrijke indicatoren voor de efficiëntie van de financiële afsluiting. Waar vind je dit? Dit wordt vastgelegd aan de hand van een wijziging van een statusveld, bijvoorbeeld wanneer JournalStatus verandert in 'Posted' in LedgerJournalTable, en het aanmaken van bijbehorende records in de tabel GeneralJournalAccountEntry. Vastleggen Bepaal de timestamp waarop de status van de journaalpost verandert in 'Posted'. Gebeurtenistype inferred
	Journaalpost goedgekeurd	De aangewezen verantwoordelijke heeft de journaalpost goedgekeurd. Daarmee is de laatste stap van de goedkeuringsworkflow afgerond. Dit wordt meestal vastgelegd als een statuswijziging van de journaalkop, bijvoorbeeld naar 'Goedgekeurd'.
Waarom dit belangrijk is Dit belangrijke moment sluit het goedkeuringsproces af en maakt het boeken mogelijk. Het is nodig om de doorlooptijd van de goedkeuring, de tijd tot het boeken en het percentage in één keer goed te berekenen. Waar vind je dit? Dit wordt afgeleid uit een wijziging van een statusveld, bijvoorbeeld wanneer ApprovalStatus verandert in 'Approved' in LedgerJournalTable, of uit de workflowgeschiedenistabel die de definitieve goedkeuring aangeeft. Vastleggen Bepaal de timestamp waarop de status van de journaalpost verandert in 'Approved'. Gebeurtenistype inferred
	Journaalpost ter goedkeuring ingediend	Dit is het formeel indienen van een voltooide journaalpost voor beoordeling en goedkeuring. Meestal wordt dit afgeleid uit een statuswijziging van de journaalkop, bijvoorbeeld van 'Concept' naar 'In beoordeling' of 'Ingediend'.
Waarom dit belangrijk is Dit belangrijke moment start de goedkeuringscyclus. Door de tijd tussen indiening en definitieve goedkeuring te meten, kun je bottlenecks in het beoordelingsproces opsporen en de naleving van SLA’s volgen. Waar vind je dit? Dit wordt afgeleid uit een wijziging van een statusveld, bijvoorbeeld wanneer ApprovalStatus verandert in 'InReview' in LedgerJournalTable, of uit de workflowgeschiedenis van de journaalpost. Vastleggen Bepaal de timestamp waarop de status van de journaalpost verandert in 'ingediend' of 'in beoordeling'. Gebeurtenistype inferred
	Beoordeling van journaalpost gestart	Deze activiteit markeert het moment waarop een beoordelaar actief aan een ingediende journaalpost begint te werken. Dit kan worden afgeleid uit de toewijzing van de journaalpost aan een beoordelaar of uit het moment waarop die de registratie voor het eerst opent.
Waarom dit belangrijk is Met deze activiteit meet je de overdrachtstijd naar de beoordelaar: de vertraging tussen indiening en de start van de beoordeling. Zo kunnen problemen met de verdeling van werk of meldingen aan het licht komen. Waar vind je dit? 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 de workflowtoewijzingen of gebruikersactiviteiten analyseren. Deze gegevens zijn mogelijk niet standaard beschikbaar. Gebeurtenistype inferred
	Boeking van journaalpost geprobeerd	Deze activiteit geeft aan dat een gebruiker het boeken van een goedgekeurde journaalpost heeft gestart. De gebeurtenis kan expliciet worden vastgelegd als het systeem het begin van de boekingstaak registreert.
Waarom dit belangrijk is Door een poging tot boeken te onderscheiden van een geslaagde boeking, kun je problemen met systeemprestaties of vertragingen in batchtaken opsporen die de financiële afsluiting beïnvloeden. Waar vind je dit? Dit kan een expliciete gebeurtenis zijn in een tabel met de geschiedenis van batchtaken, of worden afgeleid uit een statuswijziging naar 'Posting in progress' in LedgerJournalTable. Vastleggen Hiervoor moet je batchtaken of systeemlogboeken analyseren die betrekking hebben op de boekingsroutine van het grootboek. Gebeurtenistype explicit
	Journaalpost gecorrigeerd	Deze activiteit geeft aan dat een gebruiker een eerder afgewezen journaalpost heeft gewijzigd. Dit wordt meestal afgeleid uit een wijziging van de journaalkop of de regels nadat de status 'Rejected' is vastgelegd.
Waarom dit belangrijk is Deze activiteit maakt herstelwerk zichtbaar. Door te analyseren hoe vaak correctierondes voorkomen en hoelang ze duren, kun je het proces verbeteren en handmatig werk verminderen. Waar vind je dit? 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 de timestamps van latere wijzigingen door de maker. Gebeurtenistype inferred
	Journaalpost opnieuw ter goedkeuring ingediend	Een gecorrigeerde journaalpost wordt opnieuw ingediend voor een nieuwe beoordelingsronde. Dit wordt afgeleid uit een statuswijziging van 'Rejected' of 'Draft' 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 bepalen. Waar vind je dit? Dit wordt afgeleid uit de workflowgeschiedenis of door statuswijzigingen in LedgerJournalTable te volgen, waarbij de status van afgewezen teruggaat naar ingediend. Vastleggen Zoek naar een gebeurtenis met de status 'Submitted' die voor dezelfde journaalpost volgt op een gebeurtenis met de status 'Rejected'. Gebeurtenistype inferred
	Journaalpost teruggedraaid	Dit markeert de afronding van het terugdraaien van de journaalpost, waarbij een tegenboeking succesvol is geboekt. Dit is een alternatief eindpunt in de levenscyclus van een onjuiste journaalpost.
Waarom dit belangrijk is Deze activiteit sluit het proces voor gecorrigeerde journaalposten af en helpt de totale inspanning voor aanpassingen na het boeken te analyseren. Die inspanning beïnvloedt de efficiëntie van het hele proces. Waar vind je dit? Dit wordt vastgelegd wanneer de nieuwe tegenboeking zelf de status 'Posted' krijgt. De koppeling met de oorspronkelijke journaalpost blijft behouden via een referentieveld. Vastleggen Zoek naar de gebeurtenis met de status 'Posted' voor de bijbehorende tegenboeking. Gebeurtenistype inferred
	Journaalregel toegevoegd	Deze gebeurtenis geeft aan 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 regels te volgen, krijg je inzicht in de complexiteit en de benodigde invoer voor verschillende soorten journaalposten. Ook worden vertragingen tussen het aanmaken van de journaalkop en het afronden van de regels zichtbaar. Waar vind je dit? De gebeurtenis wordt vastgelegd aan de hand van de aanmaaktimestamp van records in de entiteit LedgerJournalTrans, gekoppeld aan de journaalkop. Elke aangemaakte regel is een afzonderlijke gebeurtenis. Vastleggen Gebruik voor elk record in de tabel LedgerJournalTrans het veld 'createdDateTime'. Gebeurtenistype explicit
	Terugdraaien van journaalpost gestart	Deze gebeurtenis markeert het begin van het terugdraaien van een eerder geboekte journaalpost. De gebeurtenis wordt vastgelegd wanneer een gebruiker de actie voor het terugdraaien in het systeem start.
Waarom dit belangrijk is Door terugboekingen te volgen, zie je hoe vaak geboekte journaalposten worden gecorrigeerd en waarom. Dit kan wijzen op onderliggende problemen bij de oorspronkelijke gegevensinvoer of goedkeuring. Waar vind je dit? Dit is meestal een expliciete gebruikersactie die kan worden vastgelegd in auditsporen of kan worden afgeleid uit het aanmaken van een nieuwe tegenboeking die aan de oorspronkelijke journaalpost is gekoppeld. Vastleggen Gebruik de gebeurtenis waarbij een nieuwe journaalpost wordt aangemaakt die is gemarkeerd als terugboeking van een geboekte journaalpost. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Microsoft Dynamics 365

Stappen

Open de Data Management-werkruimte: Meld je aan bij je Microsoft Dynamics 365-omgeving. Zoek via de hoofdzoekbalk naar de werkruimte 'Data management' en open deze.
Maak een nieuw exportproject: Selecteer in de Data Management-werkruimte de tegel 'Export' om een nieuw data-exportproject aan te maken. Geef het project een duidelijke naam, bijvoorbeeld 'ProcessMind_JournalEntry_Export'.
Kies de data-indeling: Geef bij de projectgegevens de gewenste indeling op. Kies 'CSV' of 'Excel', zodat je de data daarna eenvoudig kunt transformeren.
Voeg de benodigde data-entiteiten toe: Deze stap is het belangrijkst. Voeg meerdere entiteiten aan het project toe om alle benodigde activiteiten en attributen vast te leggen. Klik voor elke entiteit op 'Add entity' en zoek naar de volgende namen. Voeg ze bij voorkeur één voor één toe.
- Ledger journal headers: legt gebeurtenissen voor het aanmaken, boeken en terugdraaien vast.
- 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: Selecteer voor elke toegevoegde entiteit de optie 'Filter'. Beperk de export met filters. Filter minimaal op 'Legal entity' (Company) en op een datumbereik voor 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 velden van entiteiten: Controleer de veldkoppelingen voor elke entiteit. Zorg dat het exportbestand alle velden bevat die nodig zijn voor de uiteindelijke attributen. Standaard neemt het systeem meestal alle velden op.
Voer de exporttaak uit: Klik na het instellen van het project op 'Export' in het actievenster. Het systeem maakt een datapakket met een afzonderlijk bestand 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.
Zet de data om naar een event log: Voer deze stap buiten Dynamics 365 uit met een script, bijvoorbeeld in Python of PowerShell, of met een tool voor datavoorbereiding. Combineer en transformeer de data uit de verschillende geëxporteerde bestanden tot één CSV-bestand met een event log. Maak voor elk bronbestand rijen aan voor specifieke activiteiten. Bijvoorbeeld:
- Maak op basis van het bestand Ledger journal headers gebeurtenissen 'Journal Entry Created' aan met de aanmaaktimestamp en gebeurtenissen 'Journal Entry Posted' met de boektimestamp.
- Maak op basis van het bestand Ledger journal lines gebeurtenissen 'Journal Line Added' aan.
- Koppel het bestand Workflow tracking status table aan de kopgegevens en maak op basis van de workflowstatus en timestamps gebeurtenissen aan voor 'Journal Submitted For Approval', 'Journal Approved' en 'Journal Rejected'.
- Leid gebeurtenissen zoals 'Journal Entry Corrected' af door te zoeken naar een gewijzigde timestamp na een gebeurtenis 'Journal Rejected'.
Maak het uiteindelijke CSV-bestand op: Zorg dat het getransformeerde bestand de vereiste kolommen bevat: JournalEntryId, ActivityName en EventTime, plus eventuele aanbevolen attributen. Sorteer het bestand eerst op JournalEntryId en daarna op EventTime.
Upload naar ProcessMind: Het uiteindelijke CSV-bestand met het event log is klaar om naar ProcessMind te uploaden voor analyse.

Configuratie

Data-entiteiten: De configuratie staat of valt met de keuze van de juiste entiteiten. De belangrijkste zijn Ledger journal headers, Ledger journal lines en Workflow tracking status table. Afhankelijk van je workflowconfiguratie heb je mogelijk extra entiteiten nodig.
Exportindeling: CSV is aanbevolen. Dit is een universele indeling die je eenvoudig kunt verwerken met scripttalen en datatools voor de benodigde transformatie.
Filters: Filteren op Legal Entity (Company) is essentieel om te voorkomen dat je data uit irrelevante bedrijfseenheden exporteert. Een datumbereikfilter, 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 het exportproject voor doorlopende monitoring in op incrementele exports. Zo worden alleen records opgehaald die sinds de vorige uitvoering zijn gewijzigd. Dat is veel efficiënter dan elke keer een volledige export.
Machtigingen: Het gebruikersaccount waarmee je de exporttaak instelt en uitvoert, moet de rol 'Data management administrator' hebben of gelijkwaardige machtigingen om toegang te krijgen tot de Data Management-werkruimte en de onderliggende data-entiteiten.

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 ingebouwde 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. Wacht tot de eerste synchronisatie van de data is voltooid.
Open Azure Synapse Analytics: Ga naar Azure Portal en open de Synapse Analytics-werkruimte die is verbonden met 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 is aangemaakt op basis van de bestanden in je data lake. De D365-entiteiten zijn beschikbaar als tabellen of weergaven waarop je query’s kunt uitvoeren.
Maak een nieuw SQL-script: Open de hub 'Develop' en maak een leeg SQL-script aan. Hier bouw je de query voor het event log.
Kopieer de query en pas deze aan: Kopieer de volledige SQL-query uit het gedeelte 'query' van dit document naar de nieuwe scripteditor in Synapse Studio.
Vervang de tijdelijke waarden: Controleer de query zorgvuldig en vervang alle tijdelijke waarden. Werk de database- en schemanaam bij, bijvoorbeeld [YourD365DB].[dbo], en stel de gewenste parameters StartDate en EndDate in voor de analyseperiode.
Voer de query uit: Voer het script uit met de serverless SQL-pool. De uitvoeringstijd hangt af van het datumbereik 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 resultaten als CSV-bestand op te slaan. Klik met de rechtermuisknop op de resultaten en kies een optie zoals 'Save as CSV'.
Maak het bestand klaar om te uploaden: Zorg dat het geëxporteerde CSV-bestand UTF-8-gecodeerd is en dat de kolomkoppen overeenkomen met de vereisten van ProcessMind. Verdere datatransformatie is niet nodig.

Configuratie

Vereisten: Deze methode vereist een werkende koppeling tussen Microsoft Dynamics 365 Finance en een Azure Data Lake Storage Gen2-account. Je hebt ook een Azure Synapse Analytics-werkruimte nodig die is ingesteld om deze data op te vragen. Gebruikers moeten de juiste leesmachtigingen hebben voor zowel Azure Synapse als het data lake.
Data-entiteiten: Zorg dat de volgende D365-entiteiten zijn opgenomen in de export naar het data lake: LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry en UserInfo.
Filteren op datumbereik: De meegeleverde query bevat de parameters @StartDate en @EndDate. Begin bij voorkeur met een beperkt datumbereik, bijvoorbeeld 3 tot 6 maanden, om de queryprestaties en kosten beheersbaar te houden. Kies een periode die representatief is voor de 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 belangrijke filter voor de prestaties. Vervang de tijdelijke waarde [YourLegalEntity].
Workflowconfiguratie: De query gaat er bij goedkeurings- en afwijzingsgebeurtenissen van uit dat je de standaardworkflowengine van D365 gebruikt, die data vastlegt in WorkflowTrackingStatusTable. Gebruikt je organisatie een ander of aangepast goedkeuringsmechanisme, dan moet je de query aanpassen.

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 omgevingsinstellingen: Installeer Python 3.x op je computer. Installeer de benodigde Python-bibliotheken met pip: pip install pandas requests adal. De bibliotheek adal verzorgt de verificatie via Azure Active Directory, die nodig is voor Dynamics 365.
Registreer een toepassing in Azure AD: Registreer een toepassing in Azure Active Directory om toegang te krijgen tot de Dynamics 365 API. Noteer de Application (client) ID en Directory (tenant) ID en maak een client secret aan. Geef de toepassing gedelegeerde machtigingen voor toegang tot Dynamics 365 Finance & Operations, zoals Financials.Read.
Stel het Python-script in: Kopieer het meegeleverde Python-script naar een bestand, bijvoorbeeld extract_journals.py. Vul bovenaan het script de tijdelijke variabelen in met je Azure AD- en Dynamics 365-gegevens: TENANT_ID, CLIENT_ID, CLIENT_SECRET en D365_URL.
Stel de extractieparameters in: Pas de variabelen START_DATE en END_DATE in het script aan om de periode voor de data-extractie te bepalen. Je kunt ook de lijst LEGAL_ENTITIES aanpassen om specifieke bedrijfscodes te selecteren.
Voer het extractiescript uit: Voer het script uit vanaf de opdrachtregel met python extract_journals.py. Het script meldt zich aan bij Azure AD, haalt een toegangstoken op en vraagt vervolgens via de Dynamics 365 OData API de gegevens voor journaalkoppen en -regels op binnen het opgegeven datumbereik.
Houd de uitvoering van het script in de gaten: Tijdens het ophalen van datapagina’s via de API toont het script voortgangsberichten in de console. Afhankelijk van de hoeveelheid data kan dit geruime tijd duren. Het script verwerkt de paginering van de API automatisch en haalt zo alle relevante records op.
Controleer de ruwe data (optioneel): Het script slaat de ruwe opgevraagde data eerst op in raw_journal_headers.csv en raw_journal_lines.csv. Controleer deze bestanden om te zien of de eerste data-extractie is gelukt voordat de transformatie wordt uitgevoerd.
Bekijk hoe gebeurtenissen worden afgeleid: Het script verwerkt de ruwe data om de 12 vereiste procesactiviteiten af te leiden. Zo wordt 'Journal Submitted For Approval' afgeleid wanneer het veld WorkflowApprovalStatus verandert van 'Draft' in 'Submitted'. De timestamp van zo’n gebeurtenis komt uit het veld ModifiedDateTime van het record.
Genereer het uiteindelijke event log: Na de verwerking voegt het script alle afgeleide gebeurtenissen samen in één gestructureerd event log. Het maakt de vereiste kolommen aan: JournalEntryId, ActivityName, EventTime en andere aanbevolen attributen.
Exporteer en controleer het CSV-bestand: Het uiteindelijke event log wordt opgeslagen als journal_entry_event_log.csv. Open dit bestand en controleer de structuur en inhoud. Kijk of de verwachte kolommen aanwezig zijn en of er data voor verschillende activiteiten is gegenereerd.
Maak het bestand klaar voor upload naar ProcessMind: Het gegenereerde CSV-bestand heeft de juiste indeling om te uploaden. Sla het op met UTF-8-codering. Je kunt het nu als databron in ProcessMind gebruiken om het proces voor journaalposten van vastlegging tot rapportage te analyseren.

Configuratie

URL van het API-eindpunt: De basis-URL voor de 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: Voor het script is een toepassingsregistratie in Azure AD nodig. Geef de waarden TENANT_ID, CLIENT_ID en CLIENT_SECRET op voor de verificatie.
Vereiste API-machtigingen: De Azure AD-toepassing heeft gedelegeerde machtigingen nodig om data uit Dynamics 365 te lezen. De machtiging Financials.Read is doorgaans voldoende voor toegang tot journaalgegevens.
Datumbereik: Met de variabelen START_DATE en END_DATE in het script stel je de extractieperiode in. Voor een eerste analyse is een periode van 3 tot 6 maanden aanbevolen. Zo houd je de hoeveelheid data beheersbaar en krijg je inzicht in het proces.
Filter voor juridische entiteit: 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 vraagt vooral de OData-entiteiten LedgerJournalHeaders en LedgerJournalLines op. Dit zijn standaardentiteiten voor journaalpostgegevens in Dynamics 365.
Koppeling van statusvelden: De logica waarmee het script activiteiten afleidt, is gebaseerd op het standaardveld WorkflowApprovalStatus. Gebruikt je implementatie een aangepast veld om de status van journaalposten bij te houden, dan moet je de veldnaam in het script aanpassen.

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 benodigde Dynamics 365-data-entiteiten beschikbaar zijn in de doelomgeving. Zorg voor de machtigingen om journaalkoppen, journaalregels, workflow- of goedkeuringsgeschiedenis, statusgeschiedenis, gebruikersgegevens, gegevens over juridische entiteiten en gegevens over terugdraaiingen of boekingen te lezen. Welke entiteiten beschikbaar zijn, hangt af van de Dynamics 365-applicatie en configuratie. Gebruik [Your table name] of [Configure based on your system] als de connector de benodigde bron niet beschikbaar maakt.
Open in Power Apps de doelomgeving en maak een dataflow aan. Selecteer de standaardconnector voor Dynamics 365, voer de verbindingsgegevens van de omgeving in en meld je aan met een account dat de benodigde entiteiten mag lezen. Neem geen inloggegevens op in de transformatielogica.
Voeg de entiteit voor journaalkoppen, de entiteit voor journaalregels en alle geconfigureerde bronnen toe die workflow-, status-, toewijzings-, audit-, boekings- en terugdraaiingsgebeurtenissen vastleggen. Selecteer de velden die nodig zijn om het journaal, de timestamp van de gebeurtenis, de gebruiker, het journaaltype, de status, de afwijzingsreden, de juridische entiteit en het totaalbedrag te bepalen. Leg de werkelijke entiteiten en veldkoppelingen vast in de documentatie van de dataflow.
Pas in Power Query de ingestelde filters voor datumbereik en bedrijf of juridische entiteit toe. Behoud de timestamps uit de bron en zet ze om naar één gedocumenteerde tijdzone. Zet identificatiecodes om naar tekst, timestamps naar een consistent datum- en tijdtype, bedragen naar een numeriek type en statuswaarden naar consistente tekstwaarden. Verwijder records zonder bruikbare JournalEntryId of EventTime, tenzij je ze apart als uitzonderingen bewaart.
Maak voor elk van de twaalf vereiste activiteiten een eventquery. Elke query moet expliciet rijen opleveren met JournalEntryId, ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity en JournalTotalAmount. Laat ProcessMind geen activiteiten afleiden uit status- of veldwijzigingen.
Pas de regels voor gebeurtenissen toe op basis van de beschikbare brondata. Gebruik timestamps voor het aanmaken van journaalposten voor Journal Entry Created en timestamps voor het aanmaken van journaalregels voor Journal Line Added. Gebruik overgangen in de goedkeuringsworkflow of status voor indienen, beoordelen, goedkeuren en afwijzen. Gebruik wijzigingen na een afwijzing voor Journal Entry Corrected en latere overgangen naar indienen voor Journal Resubmitted For Approval. Gebruik registraties van het starten en voltooien van boekingen voor Journal Posting Attempted en Journal Entry Posted, en registraties van het starten en voltooien van terugdraaiingen voor Journal Entry Reversal Initiated en Journal Entry Reversed. Als een vereiste gebeurtenis niet expliciet beschikbaar is, stel dan een controleerbare afleiding op basis van de bronhistorie in en documenteer de regel.
Voeg de twaalf eventqueries samen tot één eventlogquery. 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 gebruik daarna een vaste sortering als de bron daarvoor een veld bevat.
Stel de bestemming van de dataflow in, bijvoorbeeld een ondersteund data lake, datawarehouse, database of bestandsbestemming die het ProcessMind-innameproces gebruikt. Sla het event log op als een platte tabel of een bestand met scheidingstekens, met één rij per gebeurtenis. Behoud UTF-8-codering, ISO-compatibele datum- en tijdwaarden en een stabiel schema.
Vernieuw de dataflow voor de gekozen periode, controleer fouten bij het vernieuwen en afgewezen rijen en vergelijk het aantal gebeurtenissen met de bronentiteiten en -geschiedenis. Corrigeer koppelingen of filters voordat je de uitvoer publiceert.
Exporteer het voltooide event log of maak het beschikbaar voor upload naar ProcessMind. Koppel JournalEntryId aan de case-ID, ActivityName aan de activiteit, EventTime aan de timestamp van de gebeurtenis en de overige kolommen aan gebeurtenis- of case-attributen. ProcessMind leest het event log zoals het is. Controleer dus 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. Stel de omgeving en verificatie in via de verbindingsinstellingen van het platform, niet in de querytekst.
Bronentiteiten: Selecteer de geconfigureerde entiteiten voor journaalkoppen, journaalregels, workflow- of goedkeuringsgeschiedenis, statusgeschiedenis, auditgeschiedenis, boekingsgeschiedenis, terugdraaiingsgeschiedenis, gebruikers en juridische entiteiten. De exacte namen verschillen per Dynamics 365-applicatie en aanpassing. Koppel ze 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 aan historie. Verleng de periode pas nadat je de vernieuwingsduur, de bewaartermijn van de brondata en de volledigheid van de gebeurtenissen hebt gecontroleerd. Neem een terugkijkperiode op als gebeurtenissen na de gekozen startdatum kunnen worden afgerond.
Filters: Pas filters voor bedrijfscode of juridische entiteit, journaaltype, documenttype, journaalstatus en EventTime alleen toe als ze passen bij de analyse. Filter geen afgewezen, gecorrigeerde, opnieuw ingediende, teruggedraaide of geboekte records weg die nodig zijn om de levenscyclus te reconstrueren.
Incrementeel vernieuwen: Gebruik waar mogelijk een betrouwbare timestamp voor bronwijzigingen. Behoud later binnengekomen workflow-, audit-, boekings- en terugdraaiingsrecords. Verwijder dubbele records op basis van een stabiele brongebeurtenis-ID 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 afstemming met de auditgegevens.
Prestaties: Pas waar mogelijk filters toe bij de bron, selecteer alleen benodigde kolommen, vermijd onnodige koppelingen, tel journaalregels op voordat je totalen koppelt en partitioneer grote historie of vernieuw die incrementeel.
Datakwaliteit: Wijs rijen zonder JournalEntryId of EventTime af of rapporteer ze apart. Maak statuslabels en gebruikers-ID’s consistent voordat je de eventqueries samenvoegt.
Vereisten: De mogelijkheid Power Platform Dataflows, een verbinding met de Dynamics 365-connector, leestoegang tot alle geselecteerde entiteiten, toegang tot workflow-, audit-, boekings- en terugdraaiingsgeschiedenis waar nodig, en een gelicentieerde of geautoriseerde ProcessMind-bestemming of uploadmethode.
Afhankelijk van de configuratie: Dynamics 365 biedt niet in elke applicatie of implementatie dezelfde entiteiten en historievelden. Vervang tijdelijke aanduidingen door de werkelijk ingestelde entiteiten en veldkoppelingen voordat je de oplossing in gebruik neemt.

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 kun je meteen aan de slag met het verbeteren van het proces voor journaalposten. Gebruik de data om efficiënter te werken en de financiële rapportagecycli te verkorten.

Terug naar de verbetergids

Template downloaden

Verbeter journaalposten in Dynamics 365 en rapporteer sneller

Verwijder bottlenecks en verkort de doorlooptijd van journaalposten in R2R met 30%.

Start je gratis proefperiode

Geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.

Datatemplate voor registratie tot rapportage van journaalposten

Datatemplate voor registratie tot rapportage van journaalposten

Attributen voor het proces van vastlegging tot rapportage voor journaalposten

Activiteiten in het proces van vastlegging tot rapportage voor journaalposten

Extractiegidsen

Export via het Data Management Framework van Microsoft Dynamics 365

Stappen

Configuratie

Voorbeeldquery sql

Data uit Azure Data Lake opvragen via Synapse voor Dynamics 365

Stappen

Configuratie

Voorbeeldquery sql

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

Stappen

Configuratie

Voorbeeldquery python

Data-extractie uit Dynamics 365 met Power Platform Dataflows

Stappen

Configuratie

Voorbeeldquery sql

Klaar om aan de slag te gaan?

Verbeter journaalposten in Dynamics 365 en rapporteer sneller