> Miglioramento Continuo dei Processi > Record to Report Registrazione contabile > Microsoft Dynamics 365 > Template Dati

Il suo template dati per le registrazioni contabili Record to Report

Microsoft Dynamics 365

← Torna alla Guida al Miglioramento

Attributi della registrazione contabile Record to Report (21) Attività della registrazione contabile Record to Report (12) Guide all'Estrazione (4)

Il suo template dati per le registrazioni contabili Record to Report

Questo template fornisce una guida completa ai punti dati essenziali richiesti per analizzare il suo processo Record to Report - Registrazioni contabili. Delinea gli attributi cruciali da raccogliere e le attività chiave da monitorare, assicurando di acquisire tutte le informazioni necessarie per un'iniziativa di Process Mining efficace. Inoltre, troverà indicazioni pratiche su come estrarre questi dati dal suo sistema sorgente.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione per Microsoft Dynamics 365

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

Attributi della registrazione contabile Record to Report

Questi sono i campi dati consigliati da includere nel suo event log per un'analisi completa delle registrazioni contabili Record to Report.

3 Obbligatorio 7 Consigliato 11 Facoltativo

	Nome	Descrizione
	ID registrazione prima nota JournalEntryId	L'identificatore univoco per una registrazione contabile, che funge da identificatore primario del caso.
Descrizione L'ID registrazione contabile collega in modo univoco tutte le attività e i punti dati relativi a una singola transazione. Consente il tracciamento completo end-to-end del ciclo di vita di una registrazione, dalla creazione e revisione fino alla contabilizzazione finale nel libro giornale. Nell'analisi di Process Mining, questo attributo è fondamentale per ricostruire il flusso del processo. Ogni ID registrazione contabile univoco rappresenta una singola istanza del processo, consentendo l'esame dettagliato delle varianti, dei tempi di ciclo e della conformità per le singole transazioni finanziarie. Perché è importante Questa è la chiave essenziale per tracciare una registrazione contabile dall'inizio alla fine, rendendo possibile l'analisi dell'intero flusso di processo per ogni caso. Dove trovare Questo identificatore si trova solitamente nella tabella di intestazione della registrazione, come LedgerJournalTable, spesso in un campo chiamato JournalNum. Esempi JRN-0012345JV-2023-08-156GENJ0000891
	Nome attività ActivityName	Il nome della fase specifica del processo aziendale o dell'`event` che si è verificato.
Descrizione Questo attributo descrive un singolo evento o compito all'interno del ciclo di vita della registrazione contabile, come "Registrazione creata", "Registrazione inviata per approvazione" o "Registrazione contabilizzata". Queste attività formano i nodi della mappa di processo scoperta. Analizzare la sequenza e la frequenza di queste attività è il cuore del Process Mining. Rivela il flusso reale del processo, aiuta a identificare le deviazioni dalla procedura standard ed evidenzia i colli di bottiglia dove le attività richiedono più tempo del previsto o vengono ripetute. Perché è importante Questo attributo definisce le fasi del processo, costituendo l'ossatura della mappa del processo e consentendo l'analisi del flusso e delle varianti. Dove trovare Si tratta di un attributo concettuale derivato da eventi di sistema, cambi di stato o log del workflow all'interno di Microsoft Dynamics 365. Esempi Registrazione Contabile CreataGiornale inviato per approvazioneGiornale approvatoRegistrazione prima nota contabilizzata
	Timestamp Evento EventTime	Il timestamp preciso che indica quando si è verificata un'attività o un evento.
Descrizione L'Ora dell'evento registra la data e l'ora in cui si è svolta una specifica attività nel processo di registrazione contabile. Questi dati cronologici sono essenziali per ordinare gli eventi e calcolare la durata tra di essi. In fase di analisi, questo timestamp viene utilizzato per costruire la timeline di ogni caso, operazione fondamentale per calcolare tutte le metriche basate sul tempo, come tempi di ciclo, tempi di elaborazione e tempi di attesa. Consente di identificare i ritardi tra i passaggi e supporta le dashboard relative ai colli di bottiglia e alla conformità degli SLA. Perché è importante Questo timestamp è essenziale per ordinare correttamente gli eventi e calcolare tutti i KPI basati sulla durata, come il tempo di ciclo e i ritardi di elaborazione. Dove trovare I timestamp degli eventi si trovano solitamente nei log della cronologia del workflow, nelle tabelle di audit trail (es. SysDatabaseLog) o come timestamp di creazione/modifica nei record correlati come LedgerJournalTable e LedgerJournalTrans. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	Entità Legale LegalEntity	L'entità legale o il codice azienda per cui viene registrata la voce contabile.
Descrizione L'Entità legale rappresenta la specifica azienda o unità di business all'interno di un'organizzazione per la quale viene registrata la transazione finanziaria. Si tratta di una dimensione organizzativa fondamentale nei sistemi finanziari. Nel Process Mining, questo attributo consente di confrontare il processo di registrazione contabile in diverse parti dell'organizzazione. Può rivelare se alcune entità legali hanno processi più efficienti, tassi di rifiuto più elevati o tempi di ciclo più lunghi, aiutando a identificare e condividere le best practice. Perché è importante Consente di confrontare le performance del processo tra diverse società o unità aziendali, evidenziando variazioni e opportunità di miglioramento. Dove trovare Si tratta di un campo principale in Dynamics 365, spesso disponibile nelle tabelle delle transazioni come LedgerJournalTable, tipicamente legato al DataAreaId. Esempi USMFDEMFGBSI
	Importo totale giornale JournalTotalAmount	Il valore monetario totale della registrazione contabile, solitamente la somma dei debiti.
Descrizione Questo attributo rappresenta il valore finanziario totale della registrazione contabile. Può essere utilizzato per categorizzare le voci in fasce di valore, come basso, medio e alto. Analizzare il processo in base al valore finanziario può rivelare schemi importanti. Ad esempio, le registrazioni di alto valore potrebbero seguire un processo di approvazione più rigoroso con più passaggi e tempi di ciclo più lunghi. Questo attributo è essenziale per l'analisi della materialità e per comprendere l'impatto economico delle inefficienze di processo. Perché è importante Consente di segmentare il processo per valore finanziario, che spesso è correlato alla complessità del processo, al rischio e ai workflow di approvazione. Dove trovare Questo valore potrebbe dover essere calcolato sommando gli importi in dare dalla tabella delle righe di registrazione, LedgerJournalTrans, per ogni voce contabile. Esempi 1500.75125000.0050.25
	Motivo del Rigetto RejectionReason	Il motivo fornito quando una registrazione contabile viene rifiutata durante il processo di approvazione.
Descrizione Quando una registrazione contabile viene rifiutata, l'approvatore spesso fornisce una motivazione. Questo attributo acquisisce tale informazione, che è preziosa per l'analisi delle cause radice. Questo è l'attributo principale per la dashboard "Analisi del tasso di rifiuto delle registrazioni contabili". Categorizzando e analizzando i motivi del rifiuto, le organizzazioni possono identificare problemi comuni, come documentazione errata, violazioni delle policy o errori di inserimento dati, per poi implementare formazione mirata o miglioramenti del processo. Perché è importante Spiega perché avvengono le rilavorazioni, fornendo gli insight necessari per ridurre i tassi di rifiuto e migliorare le approvazioni corrette al primo tentativo. Dove trovare Queste informazioni sono solitamente memorizzate nella cronologia del workflow o nella sezione commenti associata alla fase di rifiuto. Esempi Documentazione di supporto insufficienteConto errato utilizzatoSupera la soglia di approvazioneVoce duplicata
	Nome Utente UserName	Nome dell'utente che ha eseguito l'attività.
Descrizione Questo attributo identifica il dipendente o l'utente di sistema responsabile dell'esecuzione di una specifica attività, come la creazione, l'approvazione o la contabilizzazione di una registrazione. Collega le fasi del processo alle risorse umane. Analizzare le prestazioni per utente è una capacità chiave del Process Mining. Aiuta a costruire la dashboard "Prestazioni degli utenti per le registrazioni contabili" per confrontare le durate delle attività e la produttività tra diversi utenti o team. Ciò può evidenziare i profili migliori, identificare le esigenze di formazione e assistere nel bilanciamento del carico di lavoro. Perché è importante Collega le attività del processo a individui specifici, consentendo l'analisi delle prestazioni degli utenti, della distribuzione del carico di lavoro e dell'allocazione delle risorse. Dove trovare Le informazioni sull'utente si trovano solitamente nei campi createdBy o modifiedBy di tabelle come LedgerJournalTable o nei log associati alla cronologia del workflow. Esempi Alice SmithBob Johnsonsystem.batch
	Ora Fine Evento EventEndTime	Il `timestamp` che indica quando un'attività o un `event` è stato completato.
Descrizione L'Ora di fine evento segna il completamento di un'attività specifica. Mentre l'Ora di inizio indica quando un evento comincia, l'Ora di fine fornisce l'altro limite, consentendo il calcolo preciso della durata dei singoli compiti. Nel Process Mining, disporre sia di un'ora di inizio che di fine consente di calcolare il tempo di elaborazione dell'attività, che è distinto dal tempo di attesa. Questo è fondamentale per le dashboard che analizzano le prestazioni degli utenti e identificano quali compiti specifici, e non solo gli intervalli tra di essi, richiedono più tempo. Perché è importante Consente il calcolo preciso della durata di ogni attività, fondamentale per analizzare le performance degli utenti e identificare i compiti che richiedono più risorse. Dove trovare Questi dati possono essere memorizzati esplicitamente nei log del workflow o potrebbero dover essere derivati utilizzando l'Ora di inizio dell'attività successiva nella sequenza. Esempi 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Stato giornale JournalStatus	Lo stato attuale o finale della registrazione contabile.
Descrizione Questo attributo indica lo stato della registrazione contabile in un determinato momento, come "Bozza", "In revisione", "Approvato", "Rifiutato" o "Contabilizzato". Fornisce un'istantanea della fase in cui si trova la registrazione nel suo ciclo di vita. Analizzare lo stato è utile per comprendere gli esiti dei casi. Può essere utilizzato per filtrare tutte le registrazioni rifiutate o per monitorare il volume di registrazioni in una fase specifica. Questo attributo supporta diverse dashboard fornendo contesto all'analisi della produttività e dello stato. Perché è importante Fornisce un esito chiaro per ogni registrazione contabile, consentendo l'analisi dei tassi di successo, dei tassi di rifiuto e del volume di lavoro nelle diverse fasi. Dove trovare Lo stato si trova spesso nella tabella di intestazione della registrazione, LedgerJournalTable, o deriva dallo stato del workflow. Esempi BozzaInviatoApprovatoRegistratoRifiutato
	Tipo di Giornale JournalType	La classificazione della registrazione contabile, come Giornale generale o Rateo.
Descrizione Il Tipo di registrazione categorizza le voci in base alla loro finalità aziendale, ad esempio registrazioni giornaliere, ratei e risconti, ripartizioni o elisioni. Questa segmentazione è fondamentale per comprendere i diversi percorsi e comportamenti del processo. Questo attributo consente di filtrare e confrontare il processo tra diversi tipi di registrazioni. È essenziale per la dashboard "Volume di produzione delle registrazioni contabili per tipo", aiutando ad analizzare se determinati tipi di giornali sono più inclini a ritardi, rifiuti o rielaborazioni. Perché è importante Consente di segmentare l'analisi per confrontare processi con scopi aziendali diversi, che potrebbero avere percorsi, tempi di ciclo e requisiti di approvazione distinti. Dove trovare Solitamente viene memorizzato nella tabella di intestazione della registrazione, LedgerJournalTable, in un campo relativo ai nomi o ai tipi di registrazione (ad esempio, JournalName). Esempi Giornale generaleRettifica rateiTrasferimento infragruppoPaghe e contributi
	Codice Valuta CurrencyCode	La valuta dell'importo della registrazione contabile.
Descrizione Questo attributo specifica la valuta in cui è denominata la registrazione contabile, come EUR, USD o GBP. Fornisce il contesto essenziale per l'importo totale della registrazione. Sebbene non venga sempre utilizzata per analizzare il flusso del processo in sé, la valuta è vitale per qualsiasi reportistica o analisi finanziaria basata sugli importi. Consente la corretta aggregazione e il confronto dei valori, specialmente nelle organizzazioni multinazionali. Perché è importante Fornisce il contesto necessario per qualsiasi analisi finanziaria, garantendo che i valori monetari siano interpretati correttamente, specialmente in ambienti multi-valuta. Dove trovare Il codice valuta è solitamente disponibile nella tabella delle righe di registrazione, LedgerJournalTrans. Esempi USDEURGBPJPY
	Contabilizzazione automatica IsAutomatedPosting	Un flag che indica se la registrazione di prima nota è stata creata o contabilizzata automaticamente.
Descrizione Questo attributo booleano distingue tra le registrazioni contabili create manualmente da un utente e quelle generate automaticamente dal sistema o da un sottosistema, come un'integrazione di sistema o un processo di allocazione automatizzato. Analizzare questo attributo aiuta a confrontare l'efficienza e i tassi di errore dei processi automatizzati rispetto a quelli manuali. Può evidenziare opportunità per un'ulteriore automazione mostrando se le voci manuali sono più inclini a errori, rielaborazioni o ritardi. Perché è importante Separa i processi manuali da quelli automatizzati, consentendo un confronto della loro efficienza, accuratezza e conformità. Dove trovare Questo può essere indicato dall'utente "Creato da" (ad esempio, un utente di sistema o batch) o da un flag specifico nell'intestazione della registrazione o nella configurazione del tipo. Esempi truefalse
	Data di Registrazione PostingDate	La data in cui la registrazione contabile viene contabilizzata nel libro giornale.
Descrizione La Data di contabilizzazione è la data ufficiale in cui la transazione influisce sui saldi del libro giornale. Questa data è fondamentale per la reportistica finanziaria e i periodi di chiusura. Questo attributo viene utilizzato per analizzare il ritardo tra approvazione e contabilizzazione, che è il fulcro del KPI "Lead Time di contabilizzazione delle registrazioni". Ridurre questo ritardo è spesso un obiettivo chiave per accelerare il processo di chiusura finanziaria. Può anche essere utilizzato per analizzare i volumi di contabilizzazione nel tempo. Perché è importante Fondamentale per calcolare il KPI del tempo di contabilizzazione e comprendere i ritardi tra l'approvazione e il momento in cui la transazione diventa ufficiale nel libro giornale. Dove trovare Questa data è solitamente memorizzata nella tabella di intestazione della registrazione (LedgerJournalTable) o nelle tabelle delle transazioni contabilizzate correlate. Esempi 2023-10-282023-11-012023-10-31
	Dipartimento DepartmentName	Il reparto o il 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 dalla stessa. Si tratta di una dimensione chiave per la reportistica gestionale interna. Questo attributo consente di analizzare il processo di registrazione contabile per reparto. Può aiutare a rispondere a domande quali: Quali reparti inviano il maggior numero di registrazioni? Alcuni reparti presentano tassi di rifiuto più elevati o tempi di approvazione più lunghi? Queste informazioni sono utili per sforzi mirati di miglioramento dei processi. Perché è importante Offre un modo per analizzare le prestazioni del processo per funzione aziendale, aiutando a identificare colli di bottiglia specifici per reparto o necessità di formazione. Dove trovare Queste informazioni si trovano solitamente a livello di riga della registrazione (LedgerJournalTrans) come dimensione finanziaria. Esempi VenditeFinanzaMarketingOperazioni
	È Corretto la Prima Volta IsFirstTimeRight	Un flag che indica se il giornale è stato approvato senza alcun rifiuto precedente.
Descrizione Questo attributo booleano a livello di caso è vero se una registrazione contabile procede dall'invio all'approvazione senza alcuna attività intermedia di rifiuto o correzione. È una misura chiave della qualità del processo. Il KPI "Tasso di approvazione corretta al primo tentativo" (First-Time Right) è calcolato direttamente da questo attributo. Un tasso elevato indica un processo efficiente e di alta qualità, mentre un tasso basso segnala problemi sistemici con la qualità iniziale dei dati, la chiarezza dei requisiti o le procedure di sottomissione. Perché è importante Si tratta di una misura critica della qualità del processo, che evidenzia quante registrazioni fluiscono attraverso il processo di approvazione in modo lineare senza alcuna rielaborazione. Dove trovare Si tratta di un attributo calcolato derivato a livello di caso analizzando la sequenza delle attività per ogni ID registrazione contabile. Esempi truefalse
	È una Rilavorazione IsRework	Un flag che identifica le attività che fanno parte di un ciclo di rilavorazione o correzione.
Descrizione Questo attributo booleano calcolato è impostato su vero per le attività che si verificano dopo un rifiuto, come "Registrazione corretta" o un invio ripetuto per approvazione. Aiuta a isolare e quantificare la rielaborazione. Questo attributo è essenziale per la dashboard "Cicli di rielaborazione e correzione delle registrazioni contabili" e per il KPI "Tasso di rielaborazione". Contrassegnando la rielaborazione, diventa facile visualizzare e misurare la frequenza e l'impatto dei cicli di correzione, che sono una fonte primaria di inefficienza nel processo. Perché è importante Segnala direttamente i cicli di rilavorazione inefficienti, facilitando la quantificazione dell'impatto di rifiuti e correzioni sul tempo di ciclo e sul costo totale. Dove trovare Si tratta di un attributo calcolato derivato durante la trasformazione dei dati analizzando la sequenza delle attività all'interno di un caso. Esempi truefalse
	Livello di Approvazione ApprovalLevel	Indica la fase attuale o completata in un workflow di approvazione multilivello.
Descrizione Per le registrazioni che richiedono approvazioni multiple, questo attributo traccia quale livello gerarchico è stato raggiunto, ad esempio 'Approvazione Manager' o 'Approvazione Direttore'. È utile per analizzare i bottleneck di approvazione nel dettaglio. Può aiutare a individuare se i ritardi avvengono costantemente a un livello specifico della catena, suggerendo la necessità di ridisegnare il processo o riallocare le risorse in quella fase. Perché è importante Offre visibilità sui workflow di approvazione a più stadi, aiutando a identificare colli di bottiglia a specifici livelli di approvazione. Dove trovare Queste informazioni verrebbero derivate dal log della cronologia del workflow, tracciando il completamento delle diverse fasi di approvazione. Esempi Livello 1: ManagerLivello 2: DirectorLivello 3: VP Finance
	Sistema di Origine SourceSystem	Il sistema di origine da cui sono stati estratti i dati.
Descrizione Questo attributo identifica l'applicazione sorgente da cui provengono i dati delle registrazioni contabili. Per questo processo, il valore è solitamente una costante, come "Microsoft Dynamics 365". In un contesto di analisi più ampio, specialmente in ambienti con più ERP o sistemi integrati, questo campo aiuta a differenziare i processi e le fonti di dati. Garantisce chiarezza sulla provenienza dei dati ed è importante per la data governance e la validazione. Perché è importante Identifica l'origine dei dati, aspetto cruciale per la data governance e per le analisi che coinvolgono più sistemi aziendali. Dove trovare Si tratta di un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) per etichettare l'origine del dataset. Esempi Microsoft Dynamics 365D365 F&O
	Stato SLA approvazione ApprovalSlaState	Indica se l'approvazione della registrazione ha rispettato gli accordi sul livello di servizio (SLA).
Descrizione Questo attributo categorizza il ciclo di approvazione di ogni registrazione contabile in base al completamento entro il tempo target definito da un Service Level Agreement (SLA). I valori possibili sono solitamente "Rispettato" o "Violato". Questa è la metrica principale per la dashboard "Conformità SLA per l'approvazione delle registrazioni contabili". Fornisce una visione chiara e orientata al business delle prestazioni rispetto ai target, aiutando a monitorare e gestire la tempestività del processo di approvazione e a promuovere miglioramenti dove gli SLA vengono frequentemente mancati. Perché è importante Traduce i dati grezzi del tempo di ciclo in un esito aziendale chiaro (rispettato o violato), rendendo facile il monitoraggio delle prestazioni rispetto agli obiettivi chiave. Dove trovare Si tratta di un attributo calcolato. La logica richiede il confronto del KPI del tempo di ciclo di approvazione calcolato rispetto a un target SLA predefinito. Esempi RaggiuntoViolato
	Tempo di Elaborazione ProcessingTime	La durata del tempo trascorso lavorando attivamente su un'attività.
Descrizione Il Tempo di elaborazione misura l'intervallo tra l'inizio e la fine di un'attività, rappresentando la durata effettiva del lavoro. Si distingue dal tempo di ciclo, che include i tempi di attesa tra le attività. Questa metrica calcolata è fondamentale per la dashboard "Prestazioni degli utenti per le registrazioni contabili". Aiuta a capire quanto tempo impiegano gli utenti o i team per completare compiti specifici, eliminando l'influenza dei tempi di coda o di attesa. Ciò consente una valutazione più equa e accurata dell'efficienza delle risorse. Perché è importante Misura il tempo di lavoro attivo per un'attività, consentendo l'analisi dell'efficienza degli utenti e dei team senza l'interferenza dei periodi di attesa. Dove trovare Viene calcolato prendendo la differenza tra l'Ora di fine evento e l'Ora dell'evento (Ora di inizio) per ogni attività. Esempi PT5M15SPT1H15MP1DT2H
	Ultimo `Data Update` LastDataUpdate	Il `timestamp` di ultimo aggiornamento dei `dati` dal sistema sorgente.
Descrizione Questo attributo indica la data e l'ora dell'estrazione dati più recente dal sistema sorgente. Fornisce il contesto relativo all'aggiornamento dell'analisi e dei dati inclusi. Visualizzare queste informazioni nelle dashboard rassicura gli utenti sulla tempestività dei dati e li aiuta a comprendere il periodo temporale coperto dall'analisi attuale. È un metadato fondamentale per qualsiasi progetto di Process Mining. Perché è importante Fornisce un contesto critico sull'aggiornamento dei dati, assicurando che gli utenti comprendano quanto sia recente l'analisi del processo. Dove trovare Questo `timestamp` è generato e memorizzato durante il processo di estrazione, trasformazione e caricamento (`ETL`) dei `dati`. Esempi 2023-10-27T02:00:00Z

Obbligatorio Consigliato Facoltativo

Attività della registrazione contabile Record to Report

Questi sono i `passaggi chiave` del `processo` e le `pietre miliari` da acquisire nel tuo `event log` per un'`accurata scoperta` e `analisi dei processi`.

5 Consigliato 7 Facoltativo

	Activity	Descrizione
	Giornale approvato	La registrazione contabile è stata approvata dall'autorità designata, completando l'ultimo passaggio nel workflow di approvazione. Questo viene solitamente rilevato da un cambio di stato nell'intestazione della registrazione, come il passaggio ad "Approvato".
Perché è importante Si tratta di una pietra miliare critica che conclude il processo di approvazione e consente la contabilizzazione. È essenziale per calcolare il tempo del ciclo di approvazione, il lead time di contabilizzazione e il tasso di correttezza al primo tentativo. Dove trovare Dedotto da un cambio di stato (es. ApprovalStatus che passa ad 'Approved') nella LedgerJournalTable o dalla tabella della cronologia del workflow che indica uno stato di approvazione finale. Acquisisci Identifica il timestamp in cui lo stato del giornale passa ad 'Approved'. Tipo di evento inferred
	Giornale inviato per approvazione	Rappresenta l'invio formale di una registrazione contabile completata in un workflow di revisione e approvazione. Questo viene solitamente dedotto da un cambio di stato nell'intestazione della registrazione, ad esempio da "Bozza" a "In revisione" o "Inviato".
Perché è importante Si tratta di una pietra miliare chiave che avvia il ciclo di approvazione. Misurare il tempo dall'invio all'approvazione finale è fondamentale per identificare i colli di bottiglia nel processo di revisione e monitorare la conformità degli SLA. Dove trovare Dedotto da un cambio di stato (es. ApprovalStatus che passa a 'InReview') nella LedgerJournalTable o dai log della cronologia del workflow associati al giornale. Acquisisci Identifica il timestamp in cui lo stato del giornale passa a 'submitted' o 'in review'. Tipo di evento inferred
	Giornale rifiutato	La registrazione contabile è stata rifiutata da un revisore o approvatore e richiede correzioni. Questo evento viene rilevato da un cambio di stato della registrazione, come il passaggio a "Rifiutato" o "Richiede correzione".
Perché è importante Tracciare i rifiuti è fondamentale per calcolare il tasso di rifiuto e identificare le cause radice delle rielaborazioni. Evidenzia problemi di qualità dei dati, conformità o formazione degli utenti. Dove trovare Dedotto da un cambio di stato (es. ApprovalStatus che passa a 'Rejected') nella LedgerJournalTable o dal log della cronologia del workflow. Acquisisci Identifica il timestamp in cui lo stato del giornale passa a 'Rejected'. Tipo di evento inferred
	Registrazione Contabile Creata	Questa attività segna l'inizio di una nuova registrazione contabile. Viene rilevata quando un utente crea un nuovo record di intestazione della registrazione nel sistema, stabilendo un ID registrazione contabile univoco che funge da identificatore del caso per l'analisi del processo.
Perché è importante Questo è l'evento di inizio principale per il processo. Analizzare il tempo da questo punto alla contabilizzazione è fondamentale per misurare il tempo di ciclo end-to-end e identificare i ritardi iniziali nell'inserimento dei dati. Dove trovare Questo evento viene acquisito dal timestamp di creazione dell'intestazione della registrazione nell'entità GeneralJournalEntry o LedgerJournalTable. In genere si tratta di un evento esplicito di creazione record. Acquisisci Utilizzi il campo "createdDateTime" in GeneralJournalEntry o LedgerJournalTable. Tipo di evento explicit
	Registrazione prima nota contabilizzata	Questa attività segna la contabilizzazione riuscita della registrazione nel libro giornale, rendendola un record finanziario ufficiale. È un evento critico, rilevato quando lo stato dell'intestazione della registrazione viene aggiornato a "Contabilizzato".
Perché è importante Questo è l'evento finale di successo principale per il processo. Viene utilizzato per calcolare il tempo di ciclo end-to-end e il lead time di contabilizzazione, che sono indicatori chiave dell'efficienza della chiusura finanziaria. Dove trovare Rilevato da un cambio di stato (es. JournalStatus che passa a 'Posted') nella tabella LedgerJournalTable e dalla creazione delle relative voci nella tabella GeneralJournalAccountEntry. Acquisisci Identifica il timestamp in cui lo stato del giornale diventa 'Posted'. Tipo di evento inferred
	Giornale reinviato per approvazione	Una registrazione di prima nota corretta viene reinviata al workflow di approvazione per un nuovo ciclo di revisione. Questo evento si deduce dal cambio di stato da 'Rejected' o 'Draft' a 'In Review' o 'Submitted'.
Perché è importante Questa attività segna l'inizio di un ciclo di rielaborazione. Il conteggio di questi eventi aiuta a quantificare il tasso di rielaborazione e il numero medio di cicli di approvazione per registrazione. Dove trovare Dedotto dalla cronologia del workflow o tracciando i cambi di stato nella LedgerJournalTable dove lo stato passa da rifiutato a nuovamente inviato. Acquisisci Identifica un evento di stato 'Submitted' che avviene dopo un evento di stato 'Rejected' per lo stesso giornale. Tipo di evento inferred
	Registrazione prima nota corretta	Questa attività indica che una registrazione contabile precedentemente rifiutata è stata modificata da un utente. In genere viene dedotto rilevando una modifica all'intestazione o alle righe della registrazione dopo che è stato registrato uno stato "Rifiutato".
Perché è importante Questa attività identifica esplicitamente la rielaborazione. Analizzare la frequenza e la durata dei cicli di correzione aiuta a snellire il processo e a ridurre lo sforzo manuale. Dove trovare Dedotto tracciando i campi 'modifiedDateTime' e 'modifiedBy' nelle tabelle LedgerJournalTable o LedgerJournalTrans dopo che si è verificato un evento 'Journal Rejected'. Acquisisci Confronta il timestamp di uno stato 'Rejected' con i successivi timestamp di modifica effettuati dall'autore. Tipo di evento inferred
	Registrazione prima nota stornata	Contrassegna il completamento del processo di storno della registrazione contabile, in cui una voce di storno viene contabilizzata con successo. Questo funge da punto finale alternativo per il ciclo di vita di una registrazione errata.
Perché è importante Questa attività chiude le voci corrette e aiuta ad analizzare lo sforzo totale dedicato agli aggiustamenti post-contabilizzazione, il che influisce sull'efficienza complessiva del processo. Dove trovare Rilevato quando la nuova registrazione di storno passa allo stato 'Posted'. Il collegamento al giornale originale è mantenuto tramite un campo di riferimento. Acquisisci Identifica l'evento di stato 'Posted' per la registrazione di storno associata. Tipo di evento inferred
	Revisione giornale iniziata	Questa attività segna il momento in cui un revisore inizia a lavorare attivamente su una registrazione inviata. Può essere dedotta quando la registrazione viene assegnata a un revisore o quando il revisore apre per la prima volta il record per l'esame.
Perché è importante Questa attività aiuta a misurare il tempo di passaggio al revisore, ovvero il ritardo tra l'invio e l'inizio della revisione. Può esporre problemi di allocazione delle risorse o di notifica. Dove trovare Spesso non viene registrato esplicitamente. Può essere dedotto dai log di assegnazione del workflow o richiede il confronto tra il timestamp di invio e il timestamp della prima modifica da parte di un utente revisore. Acquisisci Richiede l'analisi dei log di assegnazione degli utenti del workflow o dei log di attività degli utenti, che potrebbero non essere standard. Tipo di evento inferred
	Riga giornale aggiunta	Questo evento indica che una riga di dare o avere è stata aggiunta alla registrazione contabile. Viene rilevato ogni volta che una nuova riga di transazione viene creata e associata all'intestazione della registrazione.
Perché è importante Monitorare la creazione delle voci di riga aiuta a comprendere la complessità e lo sforzo di inserimento dati per i diversi tipi di registrazioni. Può anche evidenziare ritardi tra la creazione dell'intestazione e il completamento delle righe. Dove trovare Rilevato dal timestamp di creazione dei record nell'entità LedgerJournalTrans, collegati alla testata del giornale. Ogni riga creata è un evento distinto. Acquisisci Utilizzi il campo "createdDateTime" per ogni record nella tabella LedgerJournalTrans. Tipo di evento explicit
	Storno registrazione prima nota avviato	Questo evento rappresenta l'inizio di un processo per stornare una registrazione contabile precedentemente contabilizzata. Viene rilevato quando un utente avvia l'azione di storno nel sistema.
Perché è importante Tracciare gli storni aiuta a identificare la frequenza e i motivi della correzione delle voci contabilizzate. Ciò può indicare problemi sottostanti nelle fasi iniziali di inserimento dati o di approvazione. Dove trovare In genere si tratta di un'azione esplicita dell'utente che può essere acquisita dagli audit trail o identificando la creazione di una nuova registrazione di storno collegata all'originale. Acquisisci Utilizzi l'evento di creazione di una nuova registrazione contabile contrassegnata come storno di una registrazione contabilizzata. Tipo di evento explicit
	Tentata contabilizzazione giornale	Questa attività indica che un utente ha avviato il processo di contabilizzazione per una registrazione approvata. Può essere rilevata esplicitamente se il sistema registra l'avvio del job di contabilizzazione.
Perché è importante Distinguere tra il tentativo di contabilizzazione e la contabilizzazione effettiva aiuta a diagnosticare problemi di performance del sistema o ritardi nei batch job che influenzano la chiusura finanziaria. Dove trovare Questo può essere un evento esplicito registrato in una tabella della cronologia dei batch job o dedotto da un cambio di stato in "Contabilizzazione in corso" su LedgerJournalTable. Acquisisci Richiede l'analisi dei batch job o dei log di sistema relativi alla routine di contabilizzazione della contabilità generale. Tipo di evento explicit

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i tuoi dati da Microsoft Dynamics 365

Fasi

Navigare nell'area di lavoro Gestione dati: effettui l'accesso all'ambiente Microsoft Dynamics 365. Utilizzi la barra di ricerca principale per trovare e aprire l'area di lavoro 'Gestione dati'.
Creare un nuovo progetto di esportazione: selezioni il riquadro 'Esporta' per creare un nuovo progetto. Assegni un nome descrittivo, ad esempio 'ProcessMind_JournalEntry_Export'.
Selezionare il formato dei dati: nei dettagli del progetto, specifichi il formato di destinazione. Si consiglia 'CSV' o 'Excel' per facilitare le fasi successive.
Aggiungere le entità dei dati richieste: questo è il passaggio fondamentale. Aggiunga le entità per catturare attività e attributi. Clicchi su 'Aggiungi entità' e cerchi i seguenti nomi (si consiglia di aggiungerli singolarmente):
- Ledger journal headers: per gli eventi di creazione, contabilizzazione e storno.
- Ledger journal lines: per l'aggiunta di singole righe di dare/avere.
- Workflow tracking status table: per tutti gli eventi del workflow (invio, approvazione, rifiuto).
Configurare i filtri delle entità: per ogni entità, selezioni l'opzione 'Filtro'. Applichi filtri per limitare l'esportazione: almeno per 'Società' (Legal entity) e per un intervallo temporale specifico (es. CREATEDDATETIME negli ultimi 3-6 mesi) per gestire il volume dei dati.
Mappare i campi delle entità: verifichi la mappatura dei campi. Si assicuri che tutti i campi necessari per gli attributi finali siano inclusi. Di norma, il sistema include tutti i campi per impostazione predefinita.
Eseguire il job di esportazione: una volta configurato il progetto, clicchi su 'Esporta' nel riquadro azioni. Il sistema creerà un pacchetto di dati contenente file separati per ogni entità.
Scaricare i dati esportati: al termine del job, acceda alla cronologia dei job e scarichi il pacchetto generato (un file zip).
Trasformare i dati in un Event Log: questa fase va eseguita esternamente a Dynamics 365 (es. con Python, PowerShell o strumenti di preparazione dati). L'obiettivo è unire i file in un unico CSV. Ad esempio:
- Dal file Ledger journal headers, crei gli eventi 'Journal Entry Created' e 'Journal Entry Posted' usando i relativi timestamp.
- Dal file Ledger journal lines, crei gli eventi 'Journal Line Added'.
- Dalla Workflow tracking status table, unisca i dati alle testate per creare eventi come 'Journal Submitted For Approval', 'Journal Approved' e 'Journal Rejected'.
- Deduca eventi come 'Journal Entry Corrected' cercando timestamp di modifica successivi a un evento 'Journal Rejected'.
Strutturare il file CSV finale: il file trasformato deve avere le colonne obbligatorie: JournalEntryId, ActivityName ed EventTime, oltre agli attributi consigliati. Ordini il file per JournalEntryId e poi per EventTime.
Caricare su ProcessMind: l'event log CSV è ora pronto per essere caricato sulla piattaforma ProcessMind per l'analisi.

Configurazione

Entità dei dati: il fulcro della configurazione è la selezione delle entità corrette. Le principali sono Ledger journal headers, Ledger journal lines e Workflow tracking status table. Potrebbero essere necessarie entità aggiuntive a seconda della configurazione specifica del vostro workflow.
Formato di esportazione: si consiglia il formato CSV, in quanto universale e facilmente gestibile da linguaggi di scripting e strumenti di analisi per la fase di trasformazione.
Filtraggio: filtrare per Legal Entity (Società) è essenziale per evitare di esportare dati da unità aziendali non pertinenti. L'applicazione di un filtro temporale (ad esempio su CREATEDDATETIME) è fondamentale per gestire le prestazioni e le dimensioni dei file. Per un'analisi iniziale, un intervallo di 3-6 mesi è lo standard.
Esportazioni incrementali: per un monitoraggio continuo, configurate il progetto di esportazione in modalità incrementale. Questo estrarrà solo i record modificati dall'ultima esecuzione, rendendo il processo molto più efficiente rispetto a un'esportazione completa.
Permessi: l'account utente che configura ed esegue il job di esportazione deve possedere il ruolo 'Data management administrator' o permessi equivalenti per accedere all'area di lavoro Gestione dati e alle relative entità.

a Query di Esempio config

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

Fasi

Configurare l'esportazione da D365 ad Azure Data Lake: prima di eseguire qualsiasi query, verifichi che la funzione nativa 'Export to Azure Data Lake' di Microsoft Dynamics 365 sia attiva. Selezioni le entità necessarie per il processo di prima nota, tra cui almeno: LedgerJournalTable, LedgerJournalTrans, GeneralJournalEntry, GeneralJournalAccountEntry e WorkflowTrackingStatusTable. Attenda il completamento della sincronizzazione iniziale.
Accedere ad Azure Synapse Analytics: apra il portale Azure e acceda all'area di lavoro Synapse Analytics collegata all'account Azure Data Lake Storage che contiene i dati di Dynamics 365.
Accedere al database SQL: all'interno di Synapse Studio, vada all'hub 'Data'. Individui il database SQL serverless creato sui file del data lake. Le entità D365 saranno disponibili come tabelle o viste interrogabili.
Creare un nuovo script SQL: apra l'hub 'Develop' e crei un nuovo script SQL vuoto. Qui verrà costruita la query per l'event log.
Copiare e adattare la query: copi la query SQL completa fornita nella sezione 'query' di questo documento e la incolli nell'editor di script di Synapse Studio.
Aggiornare i segnaposto: riveda la query e sostituisca tutti i valori segnaposto. Deve aggiornare il nome del database e dello schema, ad esempio [YourD365DB].[dbo], e impostare i parametri StartDate e EndDate per il periodo di analisi desiderato.
Eseguire la query: esegua lo script utilizzando il pool SQL serverless. Il tempo di esecuzione varierà in base all'intervallo di date e al volume di dati nel sistema.
Rivedere i risultati: al termine della query, il riquadro dei risultati mostrerà l'event log generato. Verifichi che le colonne (JournalEntryId, ActivityName, EventTime, ecc.) e i dati appaiano corretti.
Esportare l'Event Log: utilizzi la funzione di esportazione di Synapse Studio per salvare il set di risultati come file CSV. Clicchi con il tasto destro sui risultati e selezioni 'Salva come CSV'.
Preparare l'upload: si assicuri 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.

Configurazione

Prerequisiti: questo metodo richiede un'integrazione attiva tra Microsoft Dynamics 365 Finance e un account Azure Data Lake Storage Gen2. È necessario configurare un'area di lavoro Azure Synapse Analytics per interrogare i dati. Gli utenti devono disporre dei permessi di lettura sia in Azure Synapse che nel data lake.
Entità dei dati: verificate che le seguenti entità D365 siano incluse nell'esportazione verso il data lake: LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry e UserInfo.
Filtro per intervallo temporale: la query fornita include i parametri @StartDate e @EndDate. Si consiglia vivamente di iniziare con un intervallo limitato (3-6 mesi) per gestire le prestazioni e i costi della query, analizzando un periodo rappresentativo dell'attività aziendale.
Filtro per Società (Legal Entity): la query deve essere filtrata per DataAreaId per concentrare l'analisi su una specifica società. Questo filtro è cruciale per le performance in ambienti D365 di grandi dimensioni. Sostituire il segnaposto [YourLegalEntity] con il valore corretto.
Configurazione Workflow: la logica della query per gli eventi di approvazione e rifiuto presuppone l'uso del motore di workflow standard di D365, che registra i dati in WorkflowTrackingStatusTable. Se la vostra organizzazione utilizza un meccanismo di approvazione differente o personalizzato, la query dovrà essere adattata.

a 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;

Fasi

Prerequisiti e configurazione ambiente: installi Python 3.x sulla Sua macchina. Installi le librerie necessarie tramite pip: pip install pandas requests adal. La libreria adal è usata per l'autenticazione Azure Active Directory richiesta da Dynamics 365.
Registrare un'applicazione in Azure AD: per accedere alle API di Dynamics 365, deve registrare un'applicazione nel Suo Azure AD. Segni l'Application (client) ID, il Directory (tenant) ID e crei un client secret. Assegni all'applicazione i permessi delegati per accedere a Dynamics 365 Finance & Operations, come Financials.Read.
Configurare lo script Python: copi lo script fornito in un file, ad esempio extract_journals.py. Inserisca i valori nei segnaposto in cima allo script con le Sue informazioni Azure AD e Dynamics 365: TENANT_ID, CLIENT_ID, CLIENT_SECRET e D365_URL.
Impostare i parametri di estrazione: regoli le variabili START_DATE ed END_DATE nello script per definire l'intervallo temporale. Può anche personalizzare la lista LEGAL_ENTITIES per filtrare specifici codici società.
Eseguire lo script di estrazione: esegua lo script da riga di comando con python extract_journals.py. Lo script si autenticherà su Azure AD, otterrà un token di accesso e inizierà a interrogare l'API OData di Dynamics 365 per i dati di testata e riga.
Monitorare l'esecuzione: lo script stamperà messaggi di progresso in console mentre scarica le pagine di dati dall'API. Il tempo richiesto dipende dal volume dei dati; lo script gestisce automaticamente la paginazione.
Revisione dei dati grezzi (opzionale): lo script salva inizialmente i dati in raw_journal_headers.csv e raw_journal_lines.csv. Può ispezionare questi file per verificare che il download iniziale sia andato a buon fine.
Comprendere la deduzione degli eventi: lo script elabora i dati per dedurre le 12 attività richieste. Ad esempio, 'Journal Submitted For Approval' viene dedotto quando il campo WorkflowApprovalStatus passa da 'Draft' a 'Submitted', usando il timestamp di ModifiedDateTime.
Generare l'Event Log finale: dopo l'elaborazione, lo script unisce gli eventi in un unico Event Log strutturato con le colonne obbligatorie: JournalEntryId, ActivityName, EventTime e gli altri attributi.
Esportare e verificare il file CSV: l'Event Log finale viene salvato come journal_entry_event_log.csv. Lo apra per verificarne struttura e contenuto, assicurandosi che le attività siano state generate correttamente.
Preparare il caricamento su ProcessMind: il file CSV è pronto per l'upload. Verifichi che sia salvato con codifica UTF-8. Ora può usarlo come origine dati in ProcessMind per analizzare il Suo processo Record to Report.

Configurazione

URL dell'endpoint API: l'URL di base per le API OData di Dynamics 365 Finance & Operations. Deve essere impostato nella variabile D365_URL dello script, ad esempio: https://vostra-org.operations.dynamics.com.
Credenziali Azure AD: lo script richiede la registrazione di un'applicazione in Azure AD. È necessario fornire TENANT_ID, CLIENT_ID e CLIENT_SECRET per l'autenticazione.
Permessi API richiesti: l'applicazione Azure AD deve avere i permessi delegati per leggere i dati da Dynamics 365. Il permesso Financials.Read è solitamente sufficiente per accedere ai dati dei giornali contabili.
Intervallo temporale: le variabili START_DATE ed END_DATE nello script controllano il periodo di estrazione. Per un'analisi iniziale, si consiglia un periodo di 3-6 mesi per bilanciare volume dei dati e approfondimenti sul processo.
Filtro Società (Legal Entity): l'elenco LEGAL_ENTITIES nello script permette di specificare i codici azienda (dataAreaId) da includere. È fondamentale per concentrare l'analisi sulle aree di business rilevanti.
Entità dei dati: lo script interroga principalmente le entità OData LedgerJournalHeaders e LedgerJournalLines. Si tratta di entità standard per i dati delle registrazioni di prima nota in Dynamics 365.
Mappatura campi di stato: la logica dello script per dedurre le attività si basa sul campo standard WorkflowApprovalStatus. Se la vostra implementazione utilizza un campo personalizzato per tracciare lo stato del giornale, sarà necessario aggiornare il nome del campo nello script.

a 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")

Fasi

Navigare nell'area di lavoro Gestione dati: effettui l'accesso all'ambiente Microsoft Dynamics 365. Utilizzi la barra di ricerca principale per trovare e aprire l'area di lavoro 'Gestione dati'.
Creare un nuovo progetto di esportazione: selezioni il riquadro 'Esporta' per creare un nuovo progetto. Assegni un nome descrittivo, ad esempio 'ProcessMind_JournalEntry_Export'.
Selezionare il formato dei dati: nei dettagli del progetto, specifichi il formato di destinazione. Si consiglia 'CSV' o 'Excel' per facilitare le fasi successive.
Aggiungere le entità dei dati richieste: questo è il passaggio fondamentale. Aggiunga le entità per catturare attività e attributi. Clicchi su 'Aggiungi entità' e cerchi i seguenti nomi (si consiglia di aggiungerli singolarmente):
- Ledger journal headers: per gli eventi di creazione, contabilizzazione e storno.
- Ledger journal lines: per l'aggiunta di singole righe di dare/avere.
- Workflow tracking status table: per tutti gli eventi del workflow (invio, approvazione, rifiuto).
Configurare i filtri delle entità: per ogni entità, selezioni l'opzione 'Filtro'. Applichi filtri per limitare l'esportazione: almeno per 'Società' (Legal entity) e per un intervallo temporale specifico (es. CREATEDDATETIME negli ultimi 3-6 mesi) per gestire il volume dei dati.
Mappare i campi delle entità: verifichi la mappatura dei campi. Si assicuri che tutti i campi necessari per gli attributi finali siano inclusi. Di norma, il sistema include tutti i campi per impostazione predefinita.
Eseguire il job di esportazione: una volta configurato il progetto, clicchi su 'Esporta' nel riquadro azioni. Il sistema creerà un pacchetto di dati contenente file separati per ogni entità.
Scaricare i dati esportati: al termine del job, acceda alla cronologia dei job e scarichi il pacchetto generato (un file zip).
Trasformare i dati in un Event Log: questa fase va eseguita esternamente a Dynamics 365 (es. con Python, PowerShell o strumenti di preparazione dati). L'obiettivo è unire i file in un unico CSV. Ad esempio:
- Dal file Ledger journal headers, crei gli eventi 'Journal Entry Created' e 'Journal Entry Posted' usando i relativi timestamp.
- Dal file Ledger journal lines, crei gli eventi 'Journal Line Added'.
- Dalla Workflow tracking status table, unisca i dati alle testate per creare eventi come 'Journal Submitted For Approval', 'Journal Approved' e 'Journal Rejected'.
- Deduca eventi come 'Journal Entry Corrected' cercando timestamp di modifica successivi a un evento 'Journal Rejected'.
Strutturare il file CSV finale: il file trasformato deve avere le colonne obbligatorie: JournalEntryId, ActivityName ed EventTime, oltre agli attributi consigliati. Ordini il file per JournalEntryId e poi per EventTime.
Caricare su ProcessMind: l'event log CSV è ora pronto per essere caricato sulla piattaforma ProcessMind per l'analisi.

Configurazione

Entità dei dati: il fulcro della configurazione è la selezione delle entità corrette. Le principali sono Ledger journal headers, Ledger journal lines e Workflow tracking status table. Potrebbero essere necessarie entità aggiuntive a seconda della configurazione specifica del vostro workflow.
Formato di esportazione: si consiglia il formato CSV, in quanto universale e facilmente gestibile da linguaggi di scripting e strumenti di analisi per la fase di trasformazione.
Filtraggio: filtrare per Legal Entity (Società) è essenziale per evitare di esportare dati da unità aziendali non pertinenti. L'applicazione di un filtro temporale (ad esempio su CREATEDDATETIME) è fondamentale per gestire le prestazioni e le dimensioni dei file. Per un'analisi iniziale, un intervallo di 3-6 mesi è lo standard.
Esportazioni incrementali: per un monitoraggio continuo, configurate il progetto di esportazione in modalità incrementale. Questo estrarrà solo i record modificati dall'ultima esecuzione, rendendo il processo molto più efficiente rispetto a un'esportazione completa.
Permessi: l'account utente che configura ed esegue il job di esportazione deve possedere il ruolo 'Data management administrator' o permessi equivalenti per accedere all'area di lavoro Gestione dati e alle relative entità.

a Query di Esempio config

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

Il suo template dati per le registrazioni contabili Record to Report

Il suo template dati per le registrazioni contabili Record to Report

Attributi della registrazione contabile Record to Report

Attività della registrazione contabile Record to Report

Guide all'Estrazione

Esportazione Microsoft Dynamics 365 Data Management Framework

Fasi

Configurazione

a Query di Esempio config

Query Azure Data Lake via Synapse per Dynamics 365

Fasi

Configurazione

a Query di Esempio sql

Estrazione tramite Script Python via API OData di Dynamics 365

Fasi

Configurazione

a Query di Esempio python

Estrazione tramite Power Platform Dataflows da Dynamics 365

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Ottimizzi la prima nota in Dynamics 365, report più rapidi

Il suo template dati per le registrazioni contabili Record to Report

Il suo template dati per le registrazioni contabili Record to Report

Attributi della registrazione contabile Record to Report

Attività della registrazione contabile Record to Report

Guide all'Estrazione

Esportazione Microsoft Dynamics 365 Data Management Framework

Fasi

Configurazione

a Query di Esempio config

Query Azure Data Lake via Synapse per Dynamics 365

Fasi

Configurazione

a Query di Esempio sql

Estrazione tramite Script Python via API OData di Dynamics 365

Fasi

Configurazione

a Query di Esempio python

Estrazione tramite Power Platform Dataflows da Dynamics 365

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Ottimizzi la prima nota in Dynamics 365, report più rapidi