> Miglioramento continuo dei processi > Registrazione contabile > Microsoft Dynamics 365 > Template dei dati

Il Suo template dei dati per Record to Report - Registrazione contabile

Microsoft Dynamics 365

Attributi del processo Record to Report - Registrazione delle scritture contabili(20) Attività del processo Record to Report - Registrazione delle scritture contabili(12) Guide all’estrazione(4)

Il Suo template dei dati per Record to Report - Registrazione contabile

Questo template offre una guida completa ai dati essenziali necessari per analizzare il processo Record to Report - Registrazione delle scritture contabili. Illustra gli attributi fondamentali da raccogliere e le attività principali da monitorare, così da acquisire tutte le informazioni necessarie per un’iniziativa di Process Mining efficace. Include inoltre indicazioni pratiche su come estrarre questi dati dal sistema di origine.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione da Microsoft Dynamics 365

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi del processo Record to Report - Registrazione delle scritture contabili

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo Record to Report - Registrazione delle scritture contabili.

3 Obbligatorio 7 Consigliato 10 Facoltativo

	Nome	Descrizione
	Data e ora dell’evento EventTime	Data e ora precise in cui si è verificata un’attività o un evento.
Descrizione La data e ora dell’evento indicano quando si è svolta una specifica attività del processo di registrazione contabile. Questi dati cronologici sono essenziali per ordinare gli eventi e calcolare il tempo che intercorre tra l’uno e l’altro. Nell’analisi, questo valore consente di ricostruire la cronologia di ogni caso, indispensabile per calcolare tutte le metriche temporali, come i tempi di ciclo, i tempi di elaborazione e i tempi di attesa. Permette di individuare i ritardi tra le fasi e alimenta le Dashboard dedicate ai colli di bottiglia e al rispetto degli SLA. Perché è importante Questa data e ora sono essenziali per ordinare correttamente gli eventi e calcolare tutti i KPI basati sulla durata, come il tempo di ciclo e i ritardi di elaborazione. Dove reperirli Le date e le ore degli eventi si trovano in genere nei log della cronologia del flusso di lavoro, nelle tabelle delle tracce di audit, ad esempio SysDatabaseLog, oppure nei campi di creazione e modifica dei record correlati, come LedgerJournalTable e LedgerJournalTrans. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	ID della registrazione contabile JournalEntryId	Identificativo univoco di una registrazione contabile, utilizzato come identificativo principale del caso.
Descrizione L’ID della registrazione contabile collega in modo univoco tutte le attività e i dati relativi a una singola transazione contabile. Consente di monitorare l’intero ciclo di vita della registrazione, dalla creazione e revisione fino alla contabilizzazione finale nella contabilità generale. Nell’analisi di Process Mining, questo attributo è fondamentale per ricostruire il flusso del processo. Ogni ID univoco rappresenta una singola istanza del processo e consente di esaminare nel dettaglio le varianti, i tempi di ciclo e la conformità delle singole transazioni finanziarie. Perché è importante È la chiave essenziale per monitorare una registrazione contabile dall’inizio alla fine e analizzare l’intero flusso del processo per ogni caso. Dove reperirli Questo identificativo si trova in genere nella tabella dell’intestazione della registrazione, ad esempio LedgerJournalTable, spesso in un campo denominato JournalNum. Esempi JRN-0012345JV-2023-08-156GENJ0000891
	Nome dell’attività ActivityName	Nome della specifica fase o dell’evento del processo aziendale che si è verificato.
Descrizione Questo attributo descrive un singolo evento o un’attività nel ciclo di vita della registrazione contabile, ad esempio 'Registrazione contabile creata', 'Registrazione contabile inviata per l’approvazione' o 'Registrazione contabile contabilizzata'. Queste attività costituiscono i nodi della mappa del processo individuata. Analizzare la sequenza e la frequenza delle attività è fondamentale nel Process Mining. L’analisi mostra il flusso effettivo del processo, aiuta a individuare le deviazioni dalla procedura standard e mette in evidenza i colli di bottiglia, dove le attività richiedono più tempo del previsto o vengono ripetute. Perché è importante Questo attributo definisce le fasi del processo, costituisce la struttura portante della mappa e consente di analizzare il flusso e le varianti del processo. Dove reperirli È un attributo concettuale ricavato dagli eventi di sistema, dalle modifiche di stato o dai log del flusso di lavoro in Microsoft Dynamics 365. Esempi Registrazione contabile creataRegistrazione contabile inviata per l’approvazioneRegistrazione contabile approvataRegistrazione contabile contabilizzata
	Data e ora di fine dell’evento EventEndTime	Data e ora che indicano il completamento di un’attività o di un evento.
Descrizione La data e ora di fine dell’evento indicano il completamento di una specifica attività. Mentre StartTime indica quando inizia un evento, EndTime ne definisce il limite finale e consente di calcolare con precisione la durata delle singole attività. Nel Process Mining, disporre sia dell’ora di inizio sia di quella di fine permette di calcolare il tempo di elaborazione dell’attività, distinto dal tempo di attesa. È un dato essenziale per le Dashboard che analizzano le prestazioni degli utenti e individuano le attività specifiche che richiedono più tempo, non soltanto gli intervalli tra un’attività e l’altra. Perché è importante Consente di calcolare con precisione la durata di ogni attività, un dato essenziale per analizzare le prestazioni degli utenti e individuare le attività che assorbono più risorse. Dove reperirli Questi dati possono essere memorizzati esplicitamente nei log del flusso di lavoro oppure ricavati utilizzando StartTime dell’attività successiva nella sequenza. Esempi 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Entità giuridica LegalEntity	L’entità giuridica o il codice società per cui viene registrata la registrazione contabile.
Descrizione L’entità giuridica identifica la società o l’unità aziendale specifica all’interno di un’organizzazione a cui è riferita la transazione finanziaria. Nei sistemi finanziari rappresenta una dimensione organizzativa fondamentale. Nel Process Mining, questo attributo consente di confrontare il processo di registrazione contabile tra le diverse aree dell’organizzazione. Può evidenziare entità giuridiche con processi più efficienti, tassi di rifiuto più elevati o tempi di ciclo più lunghi, aiutando a individuare e condividere le buone pratiche. Perché è importante Consente di confrontare le prestazioni del processo tra società o unità aziendali diverse, mettendo in luce variazioni e opportunità di miglioramento. Dove reperirli È un campo fondamentale di Dynamics 365, spesso disponibile nelle tabelle delle transazioni come LedgerJournalTable e generalmente associato a DataAreaId. Esempi USMFDEMFGBSI
	Importo totale del giornale JournalTotalAmount	Valore monetario complessivo della registrazione contabile, generalmente pari alla somma degli addebiti.
Descrizione Questo attributo rappresenta il valore finanziario complessivo della registrazione contabile. Può essere utilizzato per suddividere le registrazioni in fasce di valore, ad esempio basso, medio e alto. L’analisi del processo in base al valore finanziario può rivelare schemi importanti. Per esempio, le registrazioni di importo elevato potrebbero seguire un processo di approvazione più rigoroso, con più passaggi e tempi di ciclo più lunghi. Questo attributo è essenziale per l’analisi della rilevanza e per comprendere l’impatto finanziario delle inefficienze del processo. Perché è importante Consente di segmentare il processo in base al valore finanziario, spesso correlato alla complessità del processo, al rischio e ai flussi di lavoro di approvazione. Dove reperirli Potrebbe essere necessario calcolare questo valore sommando gli importi degli addebiti nella tabella delle righe del giornale, LedgerJournalTrans, per ciascuna registrazione contabile. Esempi 1500.75125000.0050.25
	Motivo del rifiuto RejectionReason	Il motivo indicato quando una registrazione contabile viene rifiutata durante il processo di approvazione.
Descrizione Quando una registrazione contabile viene rifiutata, chi la approva spesso ne indica il motivo. Questo attributo raccoglie tale informazione, preziosa per individuare le cause profonde. È l’attributo principale della Dashboard «Analisi del tasso di rifiuto delle registrazioni contabili». Classificando e analizzando i motivi dei rifiuti, le organizzazioni possono individuare problemi ricorrenti, come documentazione incompleta, violazioni delle policy o errori di inserimento dei dati, e intervenire con formazione mirata o miglioramenti del processo. Perché è importante Spiega perché si verificano rilavorazioni e fornisce indicazioni concrete per ridurre i rifiuti e aumentare le approvazioni corrette al primo tentativo. Dove reperirli Queste informazioni sono in genere archiviate nella cronologia del flusso di lavoro o nella sezione dei commenti associata alla fase di rifiuto. Esempi Documentazione giustificativa insufficienteConto erratoSuperamento della soglia di approvazioneRegistrazione duplicata
	Nome utente UserName	Nome dell’utente che ha svolto l’attività.
Descrizione Questo attributo identifica il dipendente o l’utente di sistema responsabile di una specifica attività, ad esempio la creazione, l’approvazione o la registrazione di una scrittura contabile. Collega le fasi del processo alle persone che le svolgono. Analizzare i risultati per utente è una funzione importante del Process Mining. Consente di creare la Dashboard 'Prestazioni degli utenti nelle registrazioni contabili', per confrontare la durata delle attività e il volume di lavoro dei diversi utenti o team. Può mettere in evidenza chi ottiene i risultati migliori, individuare esigenze di formazione e aiutare a bilanciare i carichi di lavoro. Perché è importante Collega le attività del processo a persone specifiche e consente di analizzare le prestazioni degli utenti, la distribuzione del carico di lavoro e l’assegnazione delle risorse. Dove reperirli Le informazioni sugli utenti si trovano in genere nei campi createdBy o modifiedBy di tabelle come LedgerJournalTable oppure nei log associati alla cronologia del flusso di lavoro. Esempi Alice SmithBob Johnsonsystem.batch
	Stato del giornale JournalStatus	Stato attuale o finale della registrazione contabile.
Descrizione Questo attributo indica lo stato della registrazione contabile in un determinato momento, ad esempio «Bozza», «In revisione», «Approvato», «Rifiutato» o «Registrato». Fornisce un quadro della fase del ciclo di vita in cui si trova la registrazione. L’analisi dello stato aiuta a comprendere gli esiti dei casi. Può essere utilizzata per filtrare tutte le registrazioni rifiutate o per monitorare il volume di quelle che si trovano in una determinata fase. Questo attributo fornisce il contesto necessario per analizzare i volumi elaborati e gli stati in più Dashboard. Perché è importante Indica chiaramente l’esito di ogni registrazione contabile e consente di analizzare i tassi di successo e di rifiuto, nonché il volume di lavoro nelle diverse fasi. Dove reperirli Lo stato si trova spesso nella tabella di intestazione del giornale, LedgerJournalTable, oppure si ricava dallo stato del flusso di lavoro. Esempi BozzaInviatoApprovatoRegistratoRifiutato
	Tipo di registrazione contabile JournalType	Classificazione della registrazione contabile, ad esempio registrazione generale o rateo.
Descrizione Il tipo di registrazione contabile classifica le scritture in base alla loro finalità aziendale, ad esempio registrazioni giornaliere, ratei, allocazioni o eliminazioni. Questa segmentazione è essenziale per comprendere i diversi percorsi e comportamenti del processo. Questo attributo consente di filtrare e confrontare il processo in base ai diversi tipi di registrazione. È fondamentale per la Dashboard 'Volume delle registrazioni contabili per tipo', che aiuta a verificare se alcuni tipi di registrazione sono più soggetti a ritardi, rifiuti o rilavorazioni. Perché è importante Consente di segmentare l’analisi e confrontare i processi in base alle diverse finalità aziendali, che possono comportare percorsi, tempi di ciclo e requisiti di approvazione distinti. Dove reperirli In genere è memorizzato nella tabella dell’intestazione della registrazione, LedgerJournalTable, in un campo relativo ai nomi o ai tipi di registrazione, ad esempio JournalName. Esempi Libro giornale generaleRettifica per competenzaTrasferimento intersocietarioRetribuzioni
	Codice valuta CurrencyCode	La valuta dell’importo della registrazione contabile.
Descrizione Questo attributo specifica la valuta in cui è espresso l’importo della registrazione contabile, ad esempio USD, EUR o GBP. Fornisce un contesto essenziale per l’importo totale del giornale. Anche se non viene sempre utilizzata per analizzare il flusso del processo, la valuta è fondamentale per la rendicontazione e le analisi finanziarie basate sugli importi del giornale. Consente di aggregare e confrontare correttamente i valori, soprattutto nelle organizzazioni multinazionali. Perché è importante Fornisce il contesto necessario per le analisi finanziarie e assicura che i valori monetari siano interpretati correttamente, soprattutto in ambienti con più valute. Dove reperirli Il codice valuta è in genere disponibile nella tabella delle righe del giornale, LedgerJournalTrans. Esempi USDEURGBPJPY
	Corretto al primo tentativo IsFirstTimeRight	Indicatore che specifica se il giornale è stato approvato senza rifiuti precedenti.
Descrizione Questo attributo booleano a livello di caso assume il valore true se una registrazione contabile passa dall’invio all’approvazione senza attività intermedie di «Registrazione contabile rifiutata» o «Registrazione contabile corretta». È una misura fondamentale della qualità del processo. Il KPI «Tasso di approvazione corretta al primo tentativo» viene calcolato direttamente a partire da questo attributo. Un tasso elevato indica un processo efficiente e di qualità, mentre un tasso basso segnala problemi sistemici nella qualità iniziale dei dati, nella chiarezza dei requisiti o nelle procedure di invio. Perché è importante È una misura fondamentale della qualità del processo e mostra quante registrazioni contabili completano senza intoppi l’approvazione, senza necessità di rilavorazioni. Dove reperirli È un attributo calcolato a livello di caso, analizzando la sequenza delle attività per ciascun ID della registrazione contabile. Esempi truefalse
	Data di registrazione PostingDate	La data in cui la registrazione contabile viene registrata nella contabilità generale.
Descrizione La data di registrazione è la data ufficiale in cui la transazione incide sui saldi della contabilità generale. È fondamentale per la rendicontazione finanziaria e la chiusura dei periodi contabili. Questo attributo serve ad analizzare il ritardo tra approvazione e registrazione ed è alla base del KPI «Tempo di attraversamento della registrazione contabile». Ridurre questo intervallo è spesso un obiettivo importante per accelerare la chiusura finanziaria. L’attributo può inoltre essere utilizzato per analizzare i volumi di registrazione nel tempo. Perché è importante È essenziale per calcolare il KPI relativo al tempo di attraversamento della registrazione e comprendere i ritardi tra l’approvazione e il momento in cui una transazione diventa ufficiale nel libro mastro. Dove reperirli Questa data è in genere archiviata nella tabella di intestazione del giornale (LedgerJournalTable) o nelle tabelle correlate delle transazioni registrate. Esempi 2023-10-282023-11-012023-10-31
	Livello di approvazione ApprovalLevel	Indica la fase attuale o completata di un flusso di lavoro di approvazione articolato su più livelli.
Descrizione Per le registrazioni contabili che richiedono più approvazioni, questo attributo indica il livello gerarchico raggiunto, ad esempio «Approvazione del responsabile» o «Approvazione del direttore». L’attributo è utile per analizzare più nel dettaglio i colli di bottiglia nell’approvazione. Può aiutare a individuare eventuali ritardi ricorrenti in un livello specifico della catena di approvazione, segnalando la necessità di riprogettare il processo o riallocare le risorse in quella fase. Perché è importante Offre visibilità sui flussi di lavoro di approvazione articolati in più fasi e aiuta a individuare i colli di bottiglia nei singoli livelli. Dove reperirli Queste informazioni si ricavano dalla cronologia del flusso di lavoro, che registra il completamento delle diverse fasi di approvazione. Esempi Livello 1: responsabileLivello 2: direttoreLivello 3: vicepresidente Finanza
	Registrazione automatica IsAutomatedPosting	Indicatore che specifica se la registrazione contabile è stata creata o registrata automaticamente.
Descrizione Questo attributo booleano distingue le registrazioni contabili create manualmente da un utente da quelle generate automaticamente dal sistema o da un sottosistema, ad esempio tramite un’integrazione di sistema o un processo di allocazione automatizzato. L’analisi di questo attributo consente di confrontare l’efficienza e i tassi di errore dei processi automatizzati e manuali. Può evidenziare opportunità per ampliare l’automazione, mostrando se le registrazioni manuali sono più soggette a errori, rilavorazioni o ritardi. Perché è importante Distingue i processi manuali da quelli automatizzati e consente di confrontarne efficienza, accuratezza e conformità. Dove reperirli L’indicazione può provenire dall’utente riportato nel campo «Creato da» (ad esempio un utente di sistema o batch) oppure da un indicatore specifico nell’intestazione del giornale o nella configurazione del tipo. Esempi truefalse
	Reparto DepartmentName	Il reparto o centro di costo associato alla registrazione contabile.
Descrizione Il reparto o centro di costo identifica l’unità aziendale interna responsabile della transazione finanziaria o interessata da essa. È una dimensione importante per la rendicontazione gestionale interna. Questo attributo consente di analizzare il processo di registrazione contabile per reparto e di rispondere a domande come: quali reparti inviano il maggior numero di registrazioni? Alcuni reparti hanno tassi di rifiuto più elevati o tempi di approvazione più lunghi? Queste informazioni sono utili per definire interventi mirati di miglioramento del processo. Perché è importante Consente di analizzare le prestazioni del processo per funzione aziendale e di individuare colli di bottiglia specifici dei reparti o necessità di formazione. Dove reperirli Queste informazioni si trovano in genere a livello di riga del giornale (LedgerJournalTrans), come dimensione finanziaria. Esempi VenditeFinanzaMarketingOperazioni
	Rilavorazione IsRework	Indicatore che identifica le attività appartenenti a un ciclo di rilavorazione o correzione.
Descrizione Questo attributo booleano calcolato assume il valore true per le attività che si verificano dopo un rifiuto, come «Registrazione contabile corretta» o un nuovo «Invio della registrazione contabile per l’approvazione». Consente di isolare e quantificare le rilavorazioni. L’attributo è essenziale per la Dashboard «Cicli di rilavorazione e correzione delle registrazioni contabili» e per il KPI «Tasso di rilavorazione». Segnalando le rilavorazioni, è possibile visualizzare e misurare facilmente la frequenza e l’impatto dei cicli di correzione, tra le principali cause di inefficienza del processo. Perché è importante Segnala direttamente i cicli di rilavorazione inefficienti e consente di quantificare facilmente l’impatto di rifiuti e correzioni sul tempo di ciclo e sui costi complessivi. Dove reperirli È un attributo calcolato durante la trasformazione dei dati, analizzando la sequenza delle attività all’interno di un caso. Esempi truefalse
	Sistema di origine SourceSystem	Sistema di registrazione da cui sono stati estratti i dati.
Descrizione Questo attributo identifica l’applicazione di origine dei dati delle registrazioni contabili. Per questo processo, il valore è in genere costante, ad esempio 'Microsoft Dynamics 365'. In un’analisi più ampia, soprattutto negli ambienti con più sistemi ERP o sistemi integrati, questo campo aiuta a distinguere i processi e le origini dei dati. Chiarisce la provenienza dei dati ed è importante per la governance e la convalida dei dati. Perché è importante Identifica la provenienza dei dati, un’informazione essenziale per la governance dei dati e per le analisi che possono coinvolgere più sistemi aziendali. Dove reperirli È un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine del set di dati. Esempi Microsoft Dynamics 365D365 F&O
	Stato dello SLA di approvazione ApprovalSlaState	Indica se l’approvazione della registrazione contabile ha rispettato il livello di servizio concordato.
Descrizione Questo attributo classifica il ciclo di approvazione di ogni registrazione contabile in base al rispetto o meno del tempo obiettivo definito da un accordo sul livello di servizio (SLA). I valori possibili sono in genere «Rispettato» o «Non rispettato». È la metrica principale della Dashboard «Conformità allo SLA di approvazione delle registrazioni contabili». Offre una visione chiara delle prestazioni rispetto agli obiettivi e aiuta a monitorare e gestire la puntualità del processo di approvazione, favorendo interventi di miglioramento nei casi in cui gli SLA non vengano rispettati con frequenza. Perché è importante Traduce i dati grezzi sul tempo di ciclo in un esito aziendale chiaro (rispettato o non rispettato), facilitando il monitoraggio delle prestazioni rispetto agli obiettivi principali. Dove reperirli È un attributo calcolato. La logica confronta il KPI del tempo di ciclo di approvazione calcolato con un obiettivo SLA predefinito. Esempi RispettatoNon rispettato
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo indica la data e l’ora dell’estrazione più recente dei dati dal sistema di origine. Fornisce un riferimento sull’aggiornamento dell’analisi e dei dati inclusi. Mostrare questa informazione nelle Dashboard permette agli utenti di sapere quanto sono aggiornati i dati e di comprendere il periodo coperto dall’analisi del processo. È un metadato fondamentale per qualsiasi progetto di Process Mining. Perché è importante Fornisce un riferimento essenziale sull’aggiornamento dei dati, così che gli utenti possano capire quanto è attuale l’analisi del processo. Dove reperirli Questa data e ora vengono generate e memorizzate durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2023-10-27T02:00:00Z

Obbligatorio Consigliato Facoltativo

Attività del processo Record to Report - Registrazione delle scritture contabili

Queste sono le fasi e le tappe fondamentali del processo da registrare nell’Event Log per individuare e analizzare il processo con precisione.

5 Consigliato 7 Facoltativo

	Attività	Descrizione
	Registrazione contabile approvata	La registrazione contabile è stata approvata dall’autorità designata, completando l’ultima fase del flusso di lavoro di approvazione. In genere l’evento viene rilevato da una modifica dello stato dell’intestazione, ad esempio il passaggio ad 'Approvato'.
Perché è importante È una tappa fondamentale che conclude il processo di approvazione e consente la registrazione nel libro mastro. È essenziale per calcolare il tempo di ciclo di approvazione, il tempo di attraversamento fino alla registrazione e il tasso di completamento corretto al primo tentativo. Dove reperirli Si deduce dalla modifica di un campo di stato, ad esempio quando ApprovalStatus passa a 'Approved' in LedgerJournalTable, oppure dalla tabella della cronologia del flusso di lavoro, che indica l’approvazione finale. Acquisizione Individuare la data e l’ora in cui lo stato della registrazione passa ad 'Approvato'. Tipo di evento inferred
	Registrazione contabile contabilizzata	Questa attività segna la corretta registrazione della scrittura nella contabilità generale, che diventa così un documento finanziario ufficiale. È un evento fondamentale, rilevato quando lo stato dell’intestazione passa a 'Registrata'.
Perché è importante È l’evento finale che indica il completamento corretto del processo. Serve a calcolare il tempo di ciclo complessivo e il tempo di attraversamento fino alla registrazione, indicatori fondamentali dell’efficienza della chiusura finanziaria. Dove reperirli L’evento viene rilevato dalla modifica di un campo di stato, ad esempio quando JournalStatus passa a 'Posted' in LedgerJournalTable, e dalla creazione delle voci corrispondenti nella tabella GeneralJournalAccountEntry. Acquisizione Individuare la data e l’ora in cui lo stato della registrazione passa a 'Registrata'. Tipo di evento inferred
	Registrazione contabile creata	Questa attività segna l’avvio di una nuova registrazione contabile. Viene rilevata quando un utente crea nel sistema un nuovo record di intestazione, al quale viene assegnato un ID univoco che funge da identificativo del caso per l’analisi del processo.
Perché è importante È l’evento iniziale principale del processo. Analizzare il tempo che intercorre da questo momento alla registrazione è essenziale per misurare il tempo di ciclo complessivo e individuare eventuali ritardi iniziali nell’inserimento dei dati. Dove reperirli L’evento viene rilevato dalla data e ora di creazione dell’intestazione della registrazione nell’entità GeneralJournalEntry o LedgerJournalTable. In genere corrisponde a un evento esplicito di creazione del record. Acquisizione Utilizzare il campo 'createdDateTime' in GeneralJournalEntry o LedgerJournalTable. Tipo di evento explicit
	Registrazione contabile inviata per l’approvazione	Indica l’invio formale di una registrazione contabile completata al flusso di lavoro di revisione e approvazione. In genere si deduce da una modifica dello stato dell’intestazione, ad esempio da 'Bozza' a 'In revisione' o 'Inviata'.
Perché è importante È una tappa fondamentale che avvia il ciclo di approvazione. Misurare il tempo che intercorre tra l’invio e l’approvazione finale è essenziale per individuare i colli di bottiglia nella revisione e monitorare il rispetto degli SLA. Dove reperirli Si deduce dalla modifica di un campo di stato, ad esempio quando ApprovalStatus passa a 'InReview' in LedgerJournalTable, oppure dai log della cronologia del flusso di lavoro associato alla registrazione. Acquisizione Individuare la data e l’ora in cui lo stato della registrazione passa a 'Inviata' o 'In revisione'. Tipo di evento inferred
	Registrazione contabile rifiutata	La registrazione contabile è stata rifiutata da un revisore o da un approvatore e deve essere corretta. L’evento viene rilevato da una modifica dello stato della registrazione, ad esempio il passaggio a 'Rifiutata' o 'Da correggere'.
Perché è importante Monitorare i rifiuti è fondamentale per calcolare il tasso di rifiuto e individuare le cause profonde delle rilavorazioni. In questo modo emergono problemi relativi alla qualità dei dati, alla conformità o alla formazione degli utenti. Dove reperirli Si deduce dalla modifica di un campo di stato, ad esempio quando ApprovalStatus passa a 'Rejected' in LedgerJournalTable, oppure dal log della cronologia del flusso di lavoro. Acquisizione Individuare la data e l’ora in cui lo stato della registrazione passa a 'Rifiutata'. Tipo di evento inferred
	Registrazione contabile corretta	Questa attività indica che un utente ha modificato una registrazione contabile precedentemente rifiutata. In genere si deduce rilevando una modifica all’intestazione o alle righe della registrazione dopo la registrazione dello stato 'Rifiutata'.
Perché è importante Questa attività identifica esplicitamente una rilavorazione. Analizzare la frequenza e la durata dei cicli di correzione aiuta a semplificare il processo e a ridurre il lavoro manuale. Dove reperirli Si deduce monitorando i campi 'modifiedDateTime' e 'modifiedBy' nelle tabelle LedgerJournalTable o LedgerJournalTrans dopo un evento 'Registrazione contabile rifiutata'. Acquisizione Confrontare la data e l’ora dello stato 'Rifiutata' con quelle delle successive modifiche effettuate dall’autore della registrazione. Tipo di evento inferred
	Registrazione contabile inviata nuovamente per l’approvazione	Una registrazione contabile corretta viene reinserita nel flusso di lavoro di approvazione per un nuovo ciclo di revisione. L’evento si deduce dal passaggio dello stato da 'Rifiutata' o 'Bozza' a 'In revisione' o 'Inviata'.
Perché è importante Questa attività segna l’inizio di un ciclo di rilavorazione. Contare questi eventi permette di quantificare il tasso di rilavorazione e il numero medio di cicli di approvazione per registrazione contabile. Dove reperirli Si deduce dalla cronologia del flusso di lavoro o monitorando le modifiche di stato in LedgerJournalTable, quando lo stato passa da rifiutato a inviato. Acquisizione Individuare un evento con stato 'Inviata' che si verifica dopo un evento con stato 'Rifiutata' per la stessa registrazione. Tipo di evento inferred
	Registrazione contabile stornata	Segna il completamento della procedura di storno della registrazione contabile, con la corretta contabilizzazione della registrazione di storno. Costituisce un punto finale alternativo nel ciclo di vita di una registrazione errata.
Perché è importante Questa attività conclude il processo di correzione delle registrazioni e aiuta ad analizzare il lavoro complessivo dedicato alle rettifiche successive alla contabilizzazione, che incidono sull’efficienza generale del processo. Dove reperirli L’evento viene rilevato quando la nuova registrazione di storno passa allo stato 'Registrata'. Il collegamento alla registrazione originale è mantenuto tramite un campo di riferimento. Acquisizione Individuare l’evento con stato 'Registrata' per la registrazione di storno associata. Tipo di evento inferred
	Revisione della registrazione contabile avviata	Questa attività indica quando un revisore inizia a lavorare attivamente su una registrazione inviata. Può essere dedotta dall’assegnazione della registrazione a un revisore o dalla prima apertura del record da parte del revisore.
Perché è importante Questa attività consente di misurare il tempo di passaggio al revisore, ovvero il ritardo tra l’invio e l’inizio della revisione. Può far emergere problemi nell’assegnazione delle risorse o nelle notifiche. Dove reperirli Spesso questa attività non viene registrata in modo esplicito. Può essere dedotta dai log di assegnazione del flusso di lavoro oppure confrontando la data e ora di invio con quella della prima modifica effettuata da un utente con ruolo di revisore. Acquisizione Richiede l’analisi dei log di assegnazione degli utenti nel flusso di lavoro o dei log delle attività degli utenti, che potrebbero non essere disponibili di serie. Tipo di evento inferred
	Riga della registrazione contabile aggiunta	Questo evento indica che è stata aggiunta una riga di debito o di credito alla registrazione contabile. Viene rilevato ogni volta che si crea una nuova riga di transazione associata all’intestazione della registrazione.
Perché è importante Monitorare la creazione delle righe aiuta a comprendere la complessità e il lavoro di inserimento dei dati richiesti dai diversi tipi di registrazione. Può inoltre mettere in evidenza i ritardi tra la creazione dell’intestazione e il completamento delle righe. Dove reperirli L’evento viene rilevato dalla data e ora di creazione dei record nell’entità LedgerJournalTrans, collegati all’intestazione della registrazione. Ogni riga creata costituisce un evento distinto. Acquisizione Utilizzare il campo 'createdDateTime' per ogni record della tabella LedgerJournalTrans. Tipo di evento explicit
	Storno della registrazione contabile avviato	Questo evento indica l’avvio della procedura di storno di una registrazione contabile già contabilizzata. Viene rilevato quando un utente avvia l’azione di storno nel sistema.
Perché è importante Monitorare gli storni aiuta a individuare con quale frequenza e per quali motivi vengono corrette le registrazioni contabilizzate. Può far emergere problemi alla base dell’inserimento iniziale dei dati o delle fasi di approvazione. Dove reperirli In genere si tratta di un’azione esplicita dell’utente, rilevabile dalle tracce di audit o individuando la creazione di una nuova registrazione di storno collegata a quella originale. Acquisizione Utilizzare l’evento di creazione di una nuova registrazione contabile contrassegnata come storno di una registrazione contabilizzata. Tipo di evento explicit
	Tentativo di registrazione contabile	Questa attività indica che un utente ha avviato la registrazione nel libro mastro di una registrazione contabile approvata. Può essere rilevata in modo esplicito se il sistema registra l’avvio del processo di registrazione.
Perché è importante Distinguere il tentativo di registrazione dalla registrazione completata aiuta a diagnosticare problemi di prestazioni del sistema o ritardi nei processi batch che incidono sulla chiusura finanziaria. Dove reperirli Può trattarsi di un evento esplicito registrato in una tabella della cronologia dei processi batch oppure può essere dedotto dal passaggio dello stato di LedgerJournalTable a 'Registrazione in corso'. Acquisizione Richiede l’analisi dei log dei processi batch o di sistema relativi alla procedura di registrazione nella contabilità generale. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Microsoft Dynamics 365

Passaggi

Acceda all’area di lavoro Data Management: acceda al Suo ambiente Microsoft Dynamics 365. Utilizzi la barra di ricerca principale per trovare e aprire l’area di lavoro 'Data management'.
Crei un nuovo progetto di esportazione: nell’area di lavoro Data Management, selezioni il riquadro 'Export' per creare un progetto di esportazione dei dati. Assegni al progetto un nome descrittivo, ad esempio 'ProcessMind_JournalEntry_Export'.
Selezioni il formato dei dati: nei dettagli del progetto, specifichi il formato di destinazione. Per semplificare le successive operazioni di trasformazione, selezioni 'CSV' o 'Excel'.
Aggiunga le entità dati necessarie: questo è il passaggio più importante. Aggiunga al progetto diverse entità per acquisire tutte le attività e gli attributi richiesti. Per ciascuna entità, faccia clic su 'Add entity' e cerchi i nomi seguenti. È consigliabile aggiungerle una alla volta.
- Ledger journal headers: registra gli eventi di creazione, contabilizzazione e storno.
- Ledger journal lines: registra l’aggiunta delle singole righe dare/avere.
- Workflow tracking status table: registra tutti gli eventi relativi al flusso di lavoro, come invio, approvazione e rifiuto.
Configuri i filtri delle entità: per ogni entità aggiunta, selezioni l’opzione 'Filter'. Applichi i filtri per limitare l’ambito dell’esportazione. Come minimo, filtri per 'Legal entity' (Company) e per un intervallo di date specifico su un campo pertinente, ad esempio CREATEDDATETIME in Ledger journal headers, così da mantenere gestibile il volume dei dati. Per esempio, esporti i dati degli ultimi 3-6 mesi.
Mappi i campi delle entità: riveda la mappatura dei campi per ogni entità. Verifichi che il file esportato includa tutti i campi necessari per gli attributi finali. In genere, il sistema include tutti i campi per impostazione predefinita.
Esegua il processo di esportazione: dopo aver configurato il progetto, faccia clic su 'Export' nel riquadro delle azioni. Il sistema creerà un pacchetto di dati con file separati per ciascuna entità.
Scarichi i dati esportati: al termine dell’esportazione, apra la cronologia dei processi e scarichi il pacchetto generato, che sarà un file zip.
Trasformi i dati in un Event Log: questa operazione deve essere eseguita al di fuori di Dynamics 365, utilizzando uno script, ad esempio in Python o PowerShell, oppure uno strumento di preparazione dei dati. L’obiettivo è combinare e trasformare i dati dei diversi file esportati in un unico file CSV Event Log. Per ogni file di origine, crei righe corrispondenti ad attività specifiche. Per esempio:
- Dal file Ledger journal headers, crei gli eventi 'Journal Entry Created' usando la data e l’ora di creazione e gli eventi 'Journal Entry Posted' usando la data e l’ora di contabilizzazione.
- Dal file Ledger journal lines, crei gli eventi 'Journal Line Added'.
- Dal file Workflow tracking status table, unisca i dati alle informazioni delle intestazioni e crei gli eventi 'Journal Submitted For Approval', 'Journal Approved' e 'Journal Rejected' in base allo stato del flusso di lavoro e alle relative date e ore.
- Rilevi eventi come 'Journal Entry Corrected' cercando una data e ora di modifica successive a un evento 'Journal Rejected'.
Strutturi il file CSV finale: verifichi che il file trasformato contenga le colonne richieste: JournalEntryId, ActivityName e EventTime, oltre agli attributi consigliati. Ordini il file per JournalEntryId e poi per EventTime.
Carichi i dati in ProcessMind: il file CSV Event Log finale, unico, è pronto per essere caricato sulla piattaforma ProcessMind e analizzato.

Configurazione

Entità dati: la configurazione dipende soprattutto dalla selezione delle entità corrette. Le principali sono Ledger journal headers, Ledger journal lines e Workflow tracking status table. In base alla configurazione specifica del flusso di lavoro, potrebbero essere necessarie altre entità.
Formato di esportazione: si consiglia CSV, un formato universale facilmente gestibile con linguaggi di scripting e strumenti per i dati durante la trasformazione richiesta.
Filtri: filtrare per Legal Entity (Company) è essenziale per evitare di esportare dati di unità aziendali non pertinenti. Applicare un filtro per intervallo di date, ad esempio su CREATEDDATETIME, è fondamentale per contenere le dimensioni dei file e il carico di elaborazione. Per un’analisi iniziale, è comune utilizzare un intervallo di 3-6 mesi.
Esportazioni incrementali: per il monitoraggio continuativo, configuri il progetto in modo da eseguire esportazioni incrementali. Verranno estratti solo i record modificati dall’ultima esecuzione, con un notevole risparmio rispetto a un’esportazione completa ogni volta.
Autorizzazioni: l’account utente che configura ed esegue il processo di esportazione deve disporre del ruolo 'Data management administrator' o di autorizzazioni equivalenti per accedere all’area di lavoro Data Management e alle entità dati sottostanti.

Query di esempio 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.

Passaggi

Configuri l’esportazione da D365 ad Azure Data Lake: prima di eseguire query, verifichi che la funzionalità nativa di Microsoft Dynamics 365 'Export to Azure Data Lake' sia configurata e attiva. Selezioni le entità dati necessarie per il processo di registrazione delle scritture contabili, includendo almeno LedgerJournalTable, LedgerJournalTrans, GeneralJournalEntry, GeneralJournalAccountEntry e WorkflowTrackingStatusTable. Attenda il completamento della sincronizzazione iniziale dei dati.
Acceda ad Azure Synapse Analytics: apra Azure Portal e acceda all’area di lavoro Synapse Analytics collegata all’account Azure Data Lake Storage che contiene i dati di Dynamics 365.
Acceda al database SQL: in Synapse Studio, apra l’hub 'Data'. Individui il database SQL serverless creato sui file del data lake. Le entità D365 saranno disponibili come tabelle o viste interrogabili.
Crei un nuovo script SQL: apra l’hub 'Develop' e crei uno script SQL vuoto. Qui preparerà la query per l’Event Log.
Copi e adatti la query: copi la query SQL completa riportata nella sezione 'query' di questo documento e la incolli nel nuovo editor di script di Synapse Studio.
Aggiorni i segnaposto: riveda attentamente la query e sostituisca tutti i valori segnaposto. Aggiorni il nome del database e dello schema, ad esempio [YourD365DB].[dbo], e imposti i parametri StartDate e EndDate per il periodo da analizzare.
Esegua la query: esegua lo script usando il pool SQL serverless. Il tempo di esecuzione dipenderà dall’intervallo di date e dal volume dei dati presenti nel sistema.
Riveda i risultati: al termine dell’esecuzione, il riquadro dei risultati mostrerà l’Event Log generato. Controlli rapidamente che le colonne (JournalEntryId, ActivityName, EventTime ecc.) e i dati siano corretti.
Esporti l’Event Log: utilizzi la funzione di esportazione disponibile nello strumento di query o in Synapse Studio per salvare i risultati in un file CSV. Faccia clic con il pulsante destro del mouse sui risultati e selezioni un’opzione come 'Save as CSV'.
Prepari il file per il caricamento: verifichi che il file CSV esportato sia codificato in UTF-8 e che le intestazioni delle colonne corrispondano ai requisiti di ProcessMind. Non dovrebbero essere necessarie ulteriori trasformazioni dei dati.

Configurazione

Prerequisiti: questo metodo richiede un’integrazione funzionante tra Microsoft Dynamics 365 Finance e un account Azure Data Lake Storage Gen2. È necessario configurare un’area di lavoro Azure Synapse Analytics per interrogare questi dati. Gli utenti devono disporre delle autorizzazioni di lettura appropriate sia in Azure Synapse sia nel data lake.
Entità dati: verifichi che nell’esportazione verso il data lake siano incluse le seguenti entità D365: LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry e UserInfo.
Filtro per intervallo di date: la query fornita include i parametri @StartDate e @EndDate. Per gestire i tempi e i costi delle query, si consiglia vivamente di iniziare con un intervallo limitato, ad esempio 3-6 mesi. Analizzi un periodo rappresentativo dell’attività aziendale.
Filtro per entità giuridica: la query dovrebbe essere filtrata per DataAreaId (Legal Entity), così da concentrare l’analisi su una specifica società. Negli ambienti D365 di grandi dimensioni, questo filtro è fondamentale per le prestazioni. Sostituisca il segnaposto [YourLegalEntity].
Configurazione del flusso di lavoro: la logica della query per gli eventi di approvazione e rifiuto presuppone l’uso del motore standard dei flussi di lavoro D365, che registra i dati in WorkflowTrackingStatusTable. Se la Sua organizzazione utilizza un meccanismo di approvazione diverso o personalizzato, sarà necessario adattare la query.

Query di esempio 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;

Passaggi

Prerequisiti e configurazione dell’ambiente: installi Python 3.x sul computer. Installi con pip le librerie Python necessarie: pip install pandas requests adal. La libreria adal serve per l’autenticazione tramite Azure Active Directory, necessaria per Dynamics 365.
Registri un’applicazione in Azure AD: per accedere all’API di Dynamics 365, registri un’applicazione in Azure Active Directory. Prenda nota dell’ID applicazione (client), dell’ID directory (tenant) e crei un segreto client. Conceda all’applicazione le autorizzazioni delegate per accedere a Dynamics 365 Finance & Operations, ad esempio Financials.Read.
Configuri lo script Python: copi lo script Python fornito in un file, ad esempio extract_journals.py. Inserisca nelle variabili segnaposto all’inizio dello script i dati di Azure AD e Dynamics 365: TENANT_ID, CLIENT_ID, CLIENT_SECRET e D365_URL.
Imposti i parametri di estrazione: modifichi nello script le variabili START_DATE e END_DATE per definire l’intervallo temporale dei dati da estrarre. Può anche personalizzare l’elenco LEGAL_ENTITIES per filtrare codici società specifici.
Esegua lo script di estrazione: avvii lo script dalla riga di comando con python extract_journals.py. Lo script eseguirà l’autenticazione con Azure AD, recupererà un token di accesso e interrogherà l’API OData di Dynamics 365 per ottenere i dati delle intestazioni e delle righe delle scritture contabili nell’intervallo di date specificato.
Controlli l’esecuzione dello script: durante il recupero delle pagine di dati dall’API, lo script mostrerà messaggi di avanzamento nella console. L’operazione può richiedere molto tempo, a seconda del volume dei dati. Lo script gestisce automaticamente la paginazione dell’API per recuperare tutti i record pertinenti.
Riveda i dati grezzi (facoltativo): inizialmente, lo script salva i dati grezzi recuperati nei file raw_journal_headers.csv e raw_journal_lines.csv. Può controllarli per verificare che l’estrazione iniziale sia riuscita prima di applicare la logica di trasformazione.
Comprenda la derivazione degli eventi: lo script elabora i dati grezzi per derivare le 12 attività di processo richieste. Per esempio, deduce l’evento 'Journal Submitted For Approval' quando il campo WorkflowApprovalStatus passa da 'Draft' a 'Submitted'. La data e l’ora dell’evento vengono ricavate dal campo ModifiedDateTime del record.
Generi l’Event Log finale: al termine dell’elaborazione, lo script combina tutti gli eventi derivati in un Event Log strutturato. Crea le colonne richieste: JournalEntryId, ActivityName, EventTime e gli altri attributi consigliati.
Esporti e verifichi il file CSV: l’Event Log finale viene salvato come journal_entry_event_log.csv. Apra il file per verificarne struttura e contenuto. Controlli che siano presenti le colonne previste e che siano stati generati i dati per le diverse attività.
Prepari il caricamento in ProcessMind: il file CSV generato è in un formato adatto al caricamento. Verifichi che sia salvato con codifica UTF-8. Può quindi utilizzarlo come origine dati in ProcessMind per analizzare il processo Record to Report relativo alle scritture contabili.

Configurazione

URL dell’endpoint API: l’URL di base dell’API OData di Dynamics 365 Finance & Operations. Va impostato nella variabile D365_URL dello script, ad esempio https://your-org.operations.dynamics.com.
Credenziali Azure AD: lo script richiede la registrazione di un’applicazione Azure AD. Per l’autenticazione, deve fornire TENANT_ID, CLIENT_ID e CLIENT_SECRET.
Autorizzazioni API necessarie: l’applicazione Azure AD deve disporre delle autorizzazioni delegate per leggere i dati di Dynamics 365. In genere, l’autorizzazione Financials.Read è sufficiente per accedere ai dati delle scritture contabili.
Intervallo di date: le variabili START_DATE e END_DATE dello script definiscono il periodo di estrazione. Per l’analisi iniziale, si consiglia un periodo di 3-6 mesi, così da bilanciare il volume dei dati e le informazioni sul processo.
Filtro per entità giuridica: l’elenco LEGAL_ENTITIES dello script consente di specificare i codici società (dataAreaId) da includere nell’estrazione. È fondamentale per concentrare l’analisi sulle aree aziendali pertinenti.
Entità dati: lo script interroga principalmente le entità OData LedgerJournalHeaders e LedgerJournalLines, standard per i dati delle scritture contabili in Dynamics 365.
Mappatura del campo di stato: la logica con cui lo script deriva le attività si basa sul campo standard WorkflowApprovalStatus. Se l’implementazione utilizza un campo personalizzato per monitorare lo stato delle scritture contabili, dovrà aggiornare nello script il nome del campo.

Query di esempio 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")

Passaggi

Verifichi che nell’ambiente di destinazione siano disponibili Power Platform Dataflows, il connettore standard di Dynamics 365 e le entità dati Dynamics 365 necessarie. Ottenga le autorizzazioni per leggere le intestazioni e le righe delle scritture contabili, la cronologia dei flussi di lavoro o delle approvazioni, la cronologia degli stati, le informazioni sugli utenti e sulle entità giuridiche, nonché la cronologia degli storni e delle contabilizzazioni. La disponibilità esatta delle entità dipende dall’applicazione e dalla configurazione di Dynamics 365. Se il connettore non espone una fonte necessaria, utilizzi [Your table name] o [Configure based on your system].
In Power Apps, apra l’ambiente di destinazione e crei un flusso di dati. Selezioni il connettore standard di Dynamics 365, inserisca i dettagli di connessione dell’ambiente e si autentichi con un account autorizzato a leggere le entità richieste. Non inserisca le credenziali nella logica di trasformazione.
Aggiunga l’entità delle intestazioni delle scritture contabili, quella delle righe e tutte le fonti configurate che registrano eventi relativi a flussi di lavoro, stati, assegnazioni, audit, contabilizzazioni e storni. Selezioni i campi necessari per identificare la scrittura contabile, la data e l’ora dell’evento, l’utente, il tipo di scrittura, lo stato, il motivo del rifiuto, l’entità giuridica e l’importo totale. Registri la mappatura effettiva di entità e campi nella documentazione del flusso di dati.
In Power Query, applichi l’intervallo di date configurato e i filtri per società o entità giuridica. Mantenga le date e le ore originali delle fonti e le uniformi a un unico fuso orario documentato. Converta gli identificativi in testo, le date e le ore in un tipo datetime coerente, gli importi in valori numerici e gli stati in valori testuali uniformi. Rimuova i record privi di un JournalEntryId o EventTime utilizzabile, a meno che non vengano conservati in un output separato per le eccezioni.
Crei una query di eventi per ciascuna delle dodici attività richieste. Ogni query deve produrre esplicitamente righe con JournalEntryId, ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity e JournalTotalAmount. Non si affidi a ProcessMind per dedurre le attività dalle variazioni di stato o di campo.
Definisca le regole degli eventi utilizzando i dati disponibili nelle fonti. Utilizzi le date e le ore di creazione delle scritture per Journal Entry Created, quelle di creazione delle righe per Journal Line Added, le transizioni dei flussi di lavoro o degli stati di approvazione per invio, revisione, approvazione e rifiuto, le modifiche successive al rifiuto per Journal Entry Corrected, le successive transizioni di invio per Journal Resubmitted For Approval, i record di avvio e completamento della contabilizzazione per Journal Posting Attempted e Journal Entry Posted e i record di avvio e completamento dello storno per Journal Entry Reversal Initiated e Journal Entry Reversed. Se un evento richiesto non è disponibile in modo esplicito, configuri una derivazione verificabile dalla cronologia delle fonti e documenti la regola.
Accodi tutte e dodici le query di eventi in un’unica query Event Log. Verifichi che ogni riga di output contenga i nomi esatti delle colonne richieste, che ActivityName includa solo le etichette delle attività documentate e che EventTime sia valorizzato. Ordini per JournalEntryId e EventTime, quindi applichi un criterio deterministico per risolvere eventuali parità, se la fonte ne fornisce uno.
Configuri la destinazione del flusso di dati, ad esempio un data lake, un data warehouse, un database o una destinazione file supportata e utilizzata dal processo di acquisizione di ProcessMind. Salvi l’Event Log come tabella piatta o file delimitato, con una riga per evento. Mantenga la codifica UTF-8, date e ore compatibili con ISO e uno schema stabile.
Aggiorni il flusso di dati per il periodo selezionato, riveda gli errori di aggiornamento e le righe rifiutate e verifichi la coerenza del numero di eventi con le entità e le cronologie di origine. Corregga le mappature o i filtri prima di pubblicare l’output.
Esporti o renda disponibile l’Event Log completato per il caricamento in ProcessMind. Mappi JournalEntryId come identificativo del caso, ActivityName come attività, EventTime come data e ora dell’evento e le colonne rimanenti come attributi dell’evento o del caso. ProcessMind legge l’Event Log così com’è: verifichi quindi che tutte le attività richieste nella visualizzazione del processo siano già presenti come righe.

Configurazione

Connessione: utilizzi il connettore standard di Dynamics 365 tramite Power Platform Dataflows. Configuri l’ambiente e l’autenticazione nelle impostazioni di connessione della piattaforma, non nel testo della query.
Entità di origine: selezioni le entità configurate per intestazioni e righe delle scritture contabili, cronologia dei flussi di lavoro o delle approvazioni, cronologia degli stati, audit, contabilizzazioni e storni, utenti ed entità giuridiche. I nomi esatti variano in base all’applicazione e alle personalizzazioni di Dynamics 365; le mappi utilizzando [Your table name].
Colonne di output obbligatorie: JournalEntryId, ActivityName e EventTime devono essere valorizzate per ogni riga di evento.
Colonne di output consigliate: EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity e JournalTotalAmount.
Intervallo di date: inizi con tre-sei mesi di cronologia. Estenda l’intervallo solo dopo aver verificato la durata degli aggiornamenti, la conservazione dei dati nelle fonti e la completezza degli eventi. Includa un periodo di osservazione precedente quando gli eventi possono essere completati dopo la data iniziale selezionata.
Filtri: applichi i filtri per Company Code o Legal Entity, tipo di scrittura, tipo di documento, stato della scrittura ed EventTime solo se corrispondono all’ambito dell’analisi. Eviti di escludere record rifiutati, corretti, inviati nuovamente, stornati o contabilizzati, necessari per ricostruire il ciclo di vita.
Aggiornamento incrementale: utilizzi, se disponibile, una data e ora affidabile di modifica nella fonte. Conservi i record tardivi relativi a flussi di lavoro, audit, contabilizzazioni e storni e rimuova i duplicati utilizzando un identificativo stabile dell’evento di origine o una chiave composta documentata.
Fusi orari: converta tutte le date e le ore delle fonti in un unico fuso orario documentato. Se necessario per la riconciliazione ai fini dell’audit, conservi anche la data e l’ora originali.
Prestazioni: applichi i filtri all’origine quando supportato, selezioni solo le colonne necessarie, eviti unioni superflue, aggreghi le righe delle scritture prima di unire i totali e suddivida in partizioni o aggiorni in modo incrementale le cronologie di grandi dimensioni.
Qualità dei dati: rifiuti o segnali separatamente le righe prive di JournalEntryId o EventTime. Uniformi le etichette degli stati e gli identificativi degli utenti prima di accodare le query di eventi.
Prerequisiti: disponibilità di Power Platform Dataflows, connessione al connettore Dynamics 365, accesso in lettura a tutte le entità selezionate, accesso alla cronologia dei flussi di lavoro, degli audit, delle contabilizzazioni e degli storni ove necessario e una destinazione o un percorso di caricamento ProcessMind autorizzato e coperto da licenza.
Dipendenze dalla configurazione: Dynamics 365 non espone le stesse entità e gli stessi campi cronologici in tutte le applicazioni e implementazioni. Prima della distribuzione, sostituisca i segnaposto con le mappature effettive delle entità e dei campi configurati.

Query di esempio 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;

È pronto a iniziare?

Questo template contiene tutto ciò che Le serve per iniziare a ottimizzare il processo Record to Report - Registrazione delle scritture contabili. Inizi subito a utilizzare i dati per migliorare l’efficienza e accelerare i cicli di rendicontazione finanziaria.

Torna alla guida al miglioramento

Scarica il template

Migliori la gestione delle scritture contabili in Dynamics 365 e acceleri la rendicontazione

Elimini i colli di bottiglia e riduca del 30% il tempo di ciclo delle scritture contabili R2R.

Inizi la prova gratuita

Non è necessaria una carta di credito. Può iniziare in pochi minuti.

Il Suo template dei dati per Record to Report - Registrazione contabile

Il Suo template dei dati per Record to Report - Registrazione contabile

Attributi del processo Record to Report - Registrazione delle scritture contabili

Attività del processo Record to Report - Registrazione delle scritture contabili

Guide all’estrazione

Esportazione tramite Data Management Framework di Microsoft Dynamics 365

Passaggi

Configurazione

Query di esempio sql

Query su Azure Data Lake tramite Synapse per Dynamics 365

Passaggi

Configurazione

Query di esempio sql

Estrazione con script Python tramite API OData di Dynamics 365

Passaggi

Configurazione

Query di esempio python

Estrazione con Power Platform Dataflows da Dynamics 365

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Migliori la gestione delle scritture contabili in Dynamics 365 e acceleri la rendicontazione