> Miglioramento continuo dei processi > Elaborazione delle fatture nel processo dall’acquisto al pagamento > Microsoft Dynamics 365 > Template dei dati

Il Suo template di dati per Procure-to-Pay - Elaborazione delle fatture

Microsoft Dynamics 365

← Torna alla guida al miglioramento

Attributi del processo Procure-to-Pay - Elaborazione delle fatture(22) Attività del processo Procure-to-Pay - Elaborazione delle fatture(14) Guide all’estrazione(4)

Il Suo template di dati per Procure-to-Pay - Elaborazione delle fatture

Questo template fornisce indicazioni chiare per estrarre i dati essenziali necessari ad analizzare il processo Procure-to-Pay - Elaborazione delle fatture in Microsoft Dynamics 365. Illustra gli attributi fondamentali da raccogliere, le attività principali da monitorare e le modalità pratiche per estrarre i dati. Utilizzi queste indicazioni per raccogliere tutte le informazioni necessarie a un’analisi e a un’ottimizzazione complete del processo.

Attributi consigliati da raccogliere per un’analisi approfondita
Attività principali da monitorare durante l’intero ciclo di elaborazione delle fatture
Indicazioni per estrarre i dati 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 Procure-to-Pay - Elaborazione delle fatture

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo Procure-to-Pay - Elaborazione delle fatture.

5 Obbligatorio 7 Consigliato 10 Facoltativo

	Nome	Descrizione
	Nome dell’attività ActivityName	Nome dello specifico evento aziendale o dell’attività che si è verificata in un determinato momento del ciclo di elaborazione della fattura.
Descrizione Il nome dell’attività descrive una fase specifica o una modifica di stato nel processo di elaborazione della fattura, ad esempio «Fattura registrata», «Fattura inviata per l’approvazione» o «Pagamento eseguito». Questi dati sono essenziali per creare la mappa del processo e comprenderne la sequenza degli eventi. L’analisi di questo attributo mostra il flusso del processo, individua i percorsi più frequenti e mette in evidenza deviazioni e colli di bottiglia. Serve a calcolare i tempi di ciclo tra le attività, ad esempio il tempo tra approvazione e registrazione contabile, e a misurare la frequenza di eventi specifici come i rifiuti o i blocchi dei pagamenti. Perché è importante Definisce le fasi della mappa del processo, consentendo di visualizzare il flusso e analizzare le transizioni tra le diverse attività. Dove reperirli Questo attributo deriva in genere dalla combinazione di campi di stato, tipi di transazione o voci del registro delle modifiche presenti nelle diverse tabelle di Dynamics 365 relative all’elaborazione delle fatture. Esempi Fattura inviata per l’approvazioneRilevata discrepanza nella riconciliazionePagamento eseguito
	Numero della fattura InvoiceNumber	Identificativo univoco di ogni fattura fornitore, utilizzato come ID del caso principale per monitorarne il ciclo di elaborazione.
Descrizione Il numero della fattura è la chiave univoca che collega tutte le attività associate a una singola fattura fornitore. Consente di ricostruire l’intero percorso della fattura, dalla ricezione e registrazione fino alla riconciliazione, all’approvazione e al pagamento finale. Nell’analisi di Process Mining, questo attributo è fondamentale: identifica il caso e permette di ricostruire il flusso di elaborazione di ogni fattura. Consente così di calcolare i tempi di ciclo complessivi, individuare le varianti del processo e analizzare le caratteristiche e gli esiti delle singole fatture. Perché è importante È l’ID del caso essenziale che collega tutti gli eventi correlati e permette di analizzare l’intero ciclo di elaborazione di ogni singola fattura. Dove reperirli Si trova in genere nella tabella principale delle fatture fornitore, ad esempio nel campo Num di VendInvoiceInfoTable. Esempi INV-10056773245-AUS-001-98432
	Ora dell’evento EventTime	Data e ora esatte in cui si è verificata una specifica attività o un evento.
Descrizione L’ora dell’evento, ovvero la data e l’ora registrate, indica il momento esatto in cui si è svolta un’attività. È un elemento fondamentale dell’Event Log, perché fornisce la sequenza temporale necessaria per ordinare correttamente le attività e calcolarne la durata. Nell’analisi, questo dato è alla base di tutte le metriche temporali. Serve a calcolare la durata delle attività, il tempo di ciclo tra le diverse fasi, ad esempio il tempo di approvazione, e il tempo complessivo di elaborazione di ogni fattura. Consente inoltre di analizzare l’andamento nel tempo. Perché è importante Questa data e ora sono essenziali per ordinare gli eventi, calcolare tutti i tempi di ciclo e le durate e individuare i colli di bottiglia del processo. Dove reperirli Il dato proviene da diversi campi di data e ora presenti in più tabelle, come createdDateTime o modifiedDateTime nelle tabelle VendInvoiceInfoTable, VendTrans o nelle tabelle della cronologia dei flussi di lavoro. Esempi 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Sistema di origine SourceSystem	Sistema di registrazione da cui sono stati estratti i dati degli eventi.
Descrizione Questo attributo identifica l’applicazione di origine dei dati delle attività. Per questo processo, si tratta in genere di «Microsoft Dynamics 365». Negli ambienti con più sistemi, ad esempio una soluzione esterna di OCR o acquisizione, questo campo permette di distinguere il sistema in cui si svolge ogni fase del processo. Garantisce la tracciabilità dei dati e aiuta a risolvere i problemi di estrazione. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, utili per convalidarli e comprendere i sistemi coinvolti nel processo. Dove reperirli È un valore statico, «Microsoft Dynamics 365», aggiunto durante la trasformazione dei dati per indicare l’origine del set di dati. Esempi Microsoft Dynamics 365
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati del processo dal sistema di origine.
Descrizione Questo attributo registra la data dell’ultima estrazione e dell’ultimo aggiornamento del set di dati da Microsoft Dynamics 365. In genere, il valore è uguale per tutti i record di un singolo caricamento. Questa informazione aiuta a capire quanto sono aggiornati i dati analizzati. Indica quanto sono recenti le informazioni sul processo ed è essenziale per gestire le pianificazioni degli aggiornamenti e convalidare le pipeline di dati. Perché è importante Indica quanto sono aggiornati i dati, così gli utenti possono sapere a quando risale l’analisi e quando è previsto il prossimo aggiornamento. Dove reperirli Questa data e ora vengono generate e aggiunte al set di dati dal processo di estrazione o ETL al momento dell’esecuzione. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Data di scadenza del pagamento PaymentDueDate	Data entro cui la fattura deve essere pagata in base ai termini di pagamento concordati.
Descrizione La data di scadenza del pagamento viene calcolata in base alla data della fattura e ai termini di pagamento del fornitore. Rappresenta la scadenza contrattuale del pagamento. Questa data è fondamentale per misurare le prestazioni finanziarie e gestire i rapporti con i fornitori. È la base di riferimento per calcolare il KPI «Percentuale di pagamenti puntuali», confrontandola con la data effettiva di «Pagamento eseguito». L’analisi aiuta a individuare problemi sistemici che causano ritardi nei pagamenti, con possibili ripercussioni sui rapporti con i fornitori o sulla possibilità di usufruire degli sconti per pagamento anticipato. Perché è importante È il valore di riferimento per misurare la puntualità dei pagamenti, un KPI fondamentale per la salute finanziaria e i rapporti con i fornitori. Dove reperirli Spesso il sistema calcola questa data e la memorizza nella tabella delle transazioni del fornitore, ad esempio VendTrans, in base alla data della fattura e ai termini di pagamento. Esempi 2023-05-152023-06-302023-07-20
	Importo della fattura InvoiceAmount	Valore monetario totale della fattura.
Descrizione Questo attributo rappresenta l’importo totale dovuto indicato nella fattura del fornitore. È un dato finanziario fondamentale per ogni caso. L’importo della fattura è ampiamente utilizzato per la segmentazione e l’analisi. Può rivelare se le fatture di importo elevato seguono un processo di approvazione diverso e più rigoroso o richiedono tempi di elaborazione più lunghi. Viene inoltre utilizzato nelle Dashboard per analizzare i volumi delle fatture in base al valore e può essere aggregato per calcolare la spesa totale oggetto di analisi. Perché è importante Consente di analizzare i dati in base al valore finanziario, aiutando a dare priorità agli interventi di miglioramento sulle fatture di importo elevato e a comprendere i fattori che determinano i costi. Dove reperirli Si trova nella tabella dell’intestazione della fattura, ad esempio VendInvoiceInfoTable, in un campo come InvoiceAmount o Amount. Esempi 1500.00250.7512500.50
	Numero del fornitore VendorNumber	Identificativo univoco del venditore o fornitore che ha presentato la fattura.
Descrizione Il numero del fornitore è il codice che identifica in modo univoco un fornitore nei dati anagrafici. Collega la transazione della fattura a un fornitore specifico e consente di analizzare il processo dal punto di vista del fornitore. Questo attributo è essenziale per segmentare i dati del processo per fornitore. Aiuta a rispondere a domande come «Quali fornitori hanno i tempi di approvazione più lunghi?» o «Le discrepanze di riconciliazione sono più frequenti con alcuni fornitori?». Analizzare le prestazioni per fornitore può far emergere opportunità di collaborazione con i fornitori e di miglioramento del processo. Perché è importante Consente di filtrare i dati e analizzare le cause profonde per fornitore, aiutando a individuare problemi di prestazioni o schemi ricorrenti legati a fornitori specifici. Dove reperirli Si trova in genere nell’intestazione della tabella delle fatture dei fornitori, ad esempio VendInvoiceInfoTable, collegata ai dati anagrafici principali dei fornitori in VendTable. Esempi V-1001V-2050V-8342
	Numero dell’ordine di acquisto PurchaseOrderNumber	Identificativo dell’ordine di acquisto (PO) a cui è associata la fattura.
Descrizione Il numero dell’ordine di acquisto collega una fattura al documento di acquisto originale. È fondamentale nei processi che prevedono la riconciliazione a due o tre vie tra fattura, PO e ricevimento della merce. Questo attributo consente di analizzare le fatture associate a un PO e quelle che ne sono prive, che spesso seguono percorsi di processo diversi. È essenziale per comprendere l’efficacia della riconciliazione, indagare le discrepanze e misurare la percentuale di elaborazione senza interventi manuali delle fatture associate a un PO. Perché è importante Distingue le fatture associate a un PO da quelle che ne sono prive, una delle principali cause di variazione del processo e un elemento essenziale per l’analisi della riconciliazione. Dove reperirli Si trova nella tabella dell’intestazione della fattura, ad esempio VendInvoiceInfoTable, spesso in un campo come PurchId. Esempi PO-001234PO-005678PO-009101
	Ora di fine EndTime	Data e ora precise in cui è stata completata una specifica attività o un evento.
Descrizione L’ora di fine registra il momento in cui si conclude un’attività. Se combinata con l’ora di inizio (EventTime), consente di calcolare con precisione la durata di ogni singola fase. Questo attributo è essenziale per calcolare il «ProcessingTime» di ogni attività, una metrica chiave per l’analisi delle prestazioni. Aiuta a individuare con precisione le fasi del processo che richiedono più tempo e a pianificare interventi mirati. Ad esempio, consente di misurare la durata esatta di una fase manuale di codifica o approvazione. Perché è importante Consente di calcolare direttamente i tempi di elaborazione delle attività, un dato fondamentale per individuare le fasi del processo che richiedono più tempo. Dove reperirli Come StartTime, proviene da diversi campi di data e ora. Per alcune attività può corrispondere allo StartTime dell’attività successiva; in altri casi può essere un timestamp specifico di completamento. Esempi 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Stato della fattura InvoiceStatus	Stato corrente della fattura al momento dell’estrazione dei dati.
Descrizione Lo stato della fattura indica la fase corrente del suo ciclo di vita, ad esempio «In attesa di approvazione», «Approvato», «Registrato» o «Pagato». Fornisce un quadro aggiornato dell’avanzamento della fattura. Questo attributo viene utilizzato soprattutto per creare Dashboard operative che mostrano il carico di lavoro e le attività arretrate. Aiuta i responsabili a capire quante fatture si trovano in ciascuna fase del processo, supportando l’allocazione delle risorse e il monitoraggio operativo. È essenziale per la Dashboard «Elaborazione delle fatture: volumi e stato». Perché è importante Fornisce una visione aggiornata di tutte le fatture, essenziale per il monitoraggio operativo, la gestione del carico di lavoro e l’individuazione dei colli di bottiglia correnti. Dove reperirli In genere si ricava dai campi di stato della tabella principale delle fatture, come VendInvoiceInfoTable. Esempi In attesa di approvazioneRegistratoPagato
	Utente User	ID utente o nome della persona che ha eseguito l’attività.
Descrizione Questo attributo identifica il dipendente o l’utente di sistema responsabile dell’esecuzione di una specifica fase del processo. Per le fasi automatizzate, può trattarsi di un account di sistema o di servizio. Analizzare il processo per utente aiuta a comprendere la distribuzione del carico di lavoro, individuare esigenze di formazione e confrontare le prestazioni di singole persone o team. È fondamentale per analizzare i cicli di rilavorazione, in cui il lavoro passa da un utente all’altro, e capire perché utenti diversi completano la stessa attività in modi differenti. Perché è importante Consente di analizzare le prestazioni e il carico di lavoro per utente o team e aiuta a individuare il livello di automazione e le cause della rilavorazione. Dove reperirli Proviene dai campi ID utente nelle tabelle delle transazioni o della cronologia del flusso di lavoro, ad esempio createdby o modifiedby. Queste informazioni possono trovarsi nelle tabelle di tracciamento del flusso di lavoro. Esempi j.doea.smithAX_Admin
	Codice società CompanyCode	Identificativo della persona giuridica o società dell’organizzazione che elabora la fattura.
Descrizione Il codice società identifica la persona giuridica specifica responsabile finanziariamente della fattura. Nelle organizzazioni composte da più società, è un dato fondamentale per la segmentazione finanziaria. Questo attributo consente di filtrare o confrontare l’analisi del processo tra diverse persone giuridiche. Può rivelare se le prestazioni, le politiche o i colli di bottiglia del processo riguardano società specifiche del gruppo, supportando iniziative di miglioramento mirate alle singole realtà. Perché è importante Consente di segmentare l’analisi del processo per persona giuridica, un aspetto fondamentale per le organizzazioni grandi e articolate in più società. Dove reperirli È un campo standard nella maggior parte delle tabelle finanziarie di Dynamics 365, spesso denominato DataAreaId. Esempi USMFDEMFGBSI
	È automatizzata IsAutomated	Indicatore che specifica se un’attività è stata eseguita automaticamente dal sistema o da un utente.
Descrizione Questo attributo booleano (true/false) distingue gli eventi eseguiti dal sistema dalle attività manuali degli utenti. Ad esempio, la riconciliazione di una fattura può essere automatizzata, mentre la gestione delle discrepanze può richiedere un intervento manuale. Analizzare questo attributo è fondamentale per comprendere il livello di automazione del processo. Aiuta a misurare i risultati delle iniziative di automazione, individua i colli di bottiglia che richiedono ancora interventi manuali e mette in evidenza ulteriori opportunità per migliorare l’efficienza e ridurre gli errori. Perché è importante Aiuta a misurare il livello di automazione del processo, individuando i colli di bottiglia manuali e le opportunità per aumentare l’efficienza. Dove reperirli In genere si ricava dall’attributo «Utente». Se l’utente è un account di sistema o di servizio noto, l’indicatore viene impostato su true. Esempi truefalse
	Motivo del blocco del pagamento PaymentBlockReason	Codice che spiega perché è stato applicato un blocco al pagamento di una fattura.
Descrizione Il blocco del pagamento impedisce che una fattura venga pagata. Questo attributo registra il motivo del blocco, in genere un codice standard selezionato da un utente, ad esempio «Addebiti contestati» o «In attesa del ricevimento della merce». Questo attributo è essenziale per la Dashboard «Frequenza e durata dei blocchi dei pagamenti». Analizzare i motivi più comuni dei blocchi aiuta a individuare i problemi alla base del processo P2P. Risolvere queste cause profonde può ridurre sensibilmente i ritardi nei pagamenti e migliorare i rapporti con i fornitori. Perché è importante Spiega perché i pagamenti vengono ritardati intenzionalmente e aiuta a individuare e risolvere i problemi nelle fasi precedenti che causano i blocchi. Dove reperirli In genere è un campo della registrazione della fattura o della transazione del fornitore, spesso associato allo stato del blocco del pagamento. Si trova in tabelle come VendTrans. Esempi Contestazione sulla qualitàIn attesa di nota di creditoBlocco manuale
	Motivo del rifiuto RejectionReason	Motivo indicato da un approvatore per rifiutare una fattura.
Descrizione Quando una fattura viene rifiutata durante il flusso di lavoro di approvazione, l’approvatore indica in genere un motivo. Questo attributo registra la spiegazione, che può essere un codice predefinito o un testo libero. È un attributo fondamentale per la Dashboard «Analisi dei rifiuti delle fatture». Fornisce le informazioni qualitative necessarie per comprendere le cause profonde dei rifiuti, ad esempio «Numero PO errato», «Fattura duplicata» o «Prezzo non corrispondente». Analizzare questi motivi aiuta a dare priorità alle azioni per ridurre il tasso di rifiuto. Perché è importante Fornisce informazioni dirette sui motivi per cui le fatture vengono rifiutate e consente di intervenire in modo mirato per ridurre le rilavorazioni e aumentare la percentuale di pratiche corrette al primo tentativo. Dove reperirli In genere si trova nei commenti o nei registri della cronologia delle tabelle di elaborazione del flusso di lavoro. Esempi Quantità errataFattura duplicataLimite di approvazione superato
	Pagamento puntuale IsOnTimePayment	Indicatore calcolato che specifica se una fattura è stata pagata entro la data di scadenza.
Descrizione Questo attributo booleano si ricava confrontando il timestamp dell’attività «Pagamento eseguito» con la «Data di scadenza del pagamento». Se la data del pagamento è uguale o precedente alla scadenza, il valore è true; altrimenti è false. Questo attributo supporta direttamente il KPI «Percentuale di pagamenti puntuali» e la Dashboard «Conformità ai termini di pagamento». Semplifica l’analisi fornendo un esito binario chiaro per ogni fattura, così è facile filtrare i pagamenti in ritardo e indagarne le cause profonde per fornitore, reparto o paese. Perché è importante Misura direttamente la conformità ai termini di pagamento, semplificando il calcolo del KPI «Percentuale di pagamenti puntuali» e le analisi correlate. Dove reperirli Questo attributo viene calcolato nel livello di trasformazione dei dati. La logica è: (timestamp dell’attività «Pagamento eseguito») <= (data di scadenza del pagamento). Esempi truefalse
	Reparto Department	Centro di costo o reparto a cui vengono imputati i costi della fattura.
Descrizione Il reparto identifica l’unità aziendale o il centro di costo responsabile della spesa riportata in fattura. In genere viene determinato durante l’attività di codifica della fattura. Analizzare il processo per reparto è fondamentale per comprendere le differenze tra reparti in termini di spesa, tempi di approvazione e conformità. Aiuta a individuare i reparti con il maggior numero di eccezioni nelle fatture o i cicli di approvazione più lunghi, fornendo una base per comunicazioni e formazione mirate. Perché è importante Consente di analizzare costi e processi per reparto, mettendo in evidenza le differenze nelle prestazioni e nella conformità all’interno dell’organizzazione. Dove reperirli Proviene dalle dimensioni finanziarie associate alle righe o all’intestazione della fattura. Per recuperare questi dati è necessario interrogare le strutture dati relative alle dimensioni. Esempi VenditeMarketingOperazioni IT
	Tempo di ciclo totale TotalCycleTime	Durata complessiva dell’elaborazione di una singola fattura, dalla ricezione al pagamento.
Descrizione Il tempo di ciclo totale misura l’intera durata del processo di una fattura. Si calcola come differenza tra la prima attività, ad esempio «Fattura registrata», e l’ultima, ad esempio «Pagamento eseguito», per un determinato numero di fattura. È un KPI primario per misurare l’efficienza complessiva del processo. Fornisce una visione d’insieme delle prestazioni ed è utilizzato nella Dashboard «Tempo di ciclo end-to-end delle fatture». Analizzare l’andamento di questa metrica e segmentare i dati per attributi come il fornitore o l’importo aiuta a individuare opportunità di miglioramento più ampie. Perché è importante È il KPI di riferimento per misurare la velocità e l’efficienza complessive del processo e riassume le prestazioni per ogni fattura. Dove reperirli Si calcola a livello di caso nello strumento di Process Mining o durante la preparazione dei dati. Corrisponde alla differenza tra i timestamp del primo e dell’ultimo evento per ciascun CaseId. Esempi P15DP22DT5H30MP7D
	Termini di pagamento PaymentTerms	Termini di pagamento concordati con il fornitore, ad esempio «30 giorni» o «2% entro 10 giorni, netto 30».
Descrizione I termini di pagamento definiscono le condizioni concordate per pagare il fornitore, compresi i tempi e gli eventuali sconti. Queste informazioni provengono in genere dai dati anagrafici del fornitore o dall’ordine di acquisto. Questo attributo fornisce un contesto essenziale per la data di scadenza del pagamento e per il KPI «Percentuale di pagamenti puntuali». Analizzare l’eventuale correlazione tra determinati termini di pagamento e i ritardi può far emergere difficoltà operative. Aiuta inoltre a pianificare le finanze e a gestire efficacemente il capitale circolante. Perché è importante Fornisce il contesto per le date di scadenza dei pagamenti e aiuta ad analizzare l’impatto finanziario delle tempistiche di pagamento e la percentuale di sconti ottenuti. Dove reperirli Queste informazioni sono memorizzate nei dati anagrafici del fornitore (VendTable) e copiate nelle tabelle delle transazioni, come VendInvoiceInfoTable. Esempi 30 giorni60 giorni2% entro 10 giorni, netto 30
	Tipo di discrepanza MatchingDiscrepancyType	Classifica il tipo di mancata corrispondenza rilevata durante la riconciliazione tra fattura e PO.
Descrizione Quando si verifica una discrepanza durante la riconciliazione a due o tre vie, questo attributo ne specifica la natura, ad esempio «Prezzo non corrispondente», «Quantità non corrispondente» o «Ricevimento della merce mancante». Questi dati sono fondamentali per la Dashboard «Tempo di risoluzione delle discrepanze di riconciliazione». Analizzando la frequenza dei diversi tipi di discrepanza, l’azienda può individuare le cause profonde degli errori di riconciliazione. Ad esempio, frequenti discrepanze di prezzo possono indicare dati anagrafici non aggiornati, mentre quelle relative alle quantità possono segnalare problemi di spedizione. Perché è importante Classifica gli errori di riconciliazione e consente di analizzarne le cause profonde, ridurre le discrepanze e migliorare la percentuale di elaborazione senza interventi manuali. Dove reperirli Può essere memorizzato in una tabella dedicata alla riconciliazione o alle eccezioni, oppure può essere necessario ricavarlo dai messaggi di stato o dai commenti del flusso di lavoro. Esempi Prezzo non corrispondenteQuantità non corrispondenteRicevimento della merce mancante
	Valuta della fattura InvoiceCurrency	Codice della valuta in cui è espresso l’importo della fattura, ad esempio USD o EUR.
Descrizione La valuta della fattura specifica la valuta in cui è espresso l’importo. È un dato importante per le organizzazioni multinazionali che lavorano con fornitori di paesi diversi. Questo attributo fornisce il contesto necessario per interpretare l’importo della fattura e viene utilizzato per filtrare i dati e creare report, soprattutto nelle attività globali. Consente di interpretare correttamente i valori finanziari e di effettuare analisi per valuta o conversioni in una valuta di rendicontazione standard. Perché è importante Fornisce il contesto essenziale per interpretare e analizzare correttamente gli importi delle fatture nelle diverse aree geografiche. Dove reperirli Si trova nella tabella dell’intestazione della fattura, accanto all’importo, ad esempio nel campo CurrencyCode di VendInvoiceInfoTable. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività del processo Procure-to-Pay - Elaborazione delle fatture

Questi sono i passaggi e le tappe fondamentali del processo da registrare nell’Event Log per individuare e analizzare con precisione il flusso di lavoro di elaborazione delle fatture.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Fattura approvata	Indica l’approvazione definitiva della fattura nel flusso di lavoro, che ne autorizza la registrazione contabile e il pagamento. Al completamento, il motore dei flussi di lavoro registra esplicitamente l’evento.
Perché è importante È una tappa fondamentale che conclude il processo di approvazione. Il tempo tra «Fattura inviata per l’approvazione» e questo evento è un indicatore importante dell’efficienza delle approvazioni e aiuta a individuare i colli di bottiglia. Dove reperirli È un evento esplicito registrato nelle tabelle della cronologia dei flussi di lavoro, ad esempio WorkflowTrackingStatusTable, quando lo stato del flusso di lavoro passa a «Approvato». Acquisizione Data e ora della registrazione dello stato «Approvato» nella cronologia dei flussi di lavoro. Tipo di evento explicit
	Fattura inviata per l’approvazione	Questa attività segna l’invio formale della fattura a un flusso di lavoro per la revisione e l’approvazione. Il motore dei flussi di lavoro di Dynamics 365 registra esplicitamente l’invio.
Perché è importante È il punto di partenza per misurare l’intero ciclo di approvazione. Aiuta a capire quanto tempo le fatture restano in attesa prima ancora che inizi l’approvazione ed è il riferimento per i KPI relativi all’approvazione. Dove reperirli È un evento esplicito registrato nelle tabelle della cronologia dei flussi di lavoro, ad esempio WorkflowTrackingStatusTable, quando una fattura viene inviata a un flusso di lavoro. Acquisizione Data e ora di creazione del record di invio nella cronologia dei flussi di lavoro. Tipo di evento explicit
	Fattura registrata	È il primo inserimento della fattura nel sistema, che crea un record provvisorio prima che vengano elaborati tutti i dettagli. L’attività viene rilevata quando si crea un nuovo record nel giornale di registrazione delle fatture fornitore.
Perché è importante Questa attività segna l’inizio ufficiale del ciclo di elaborazione della fattura. Analizzare il tempo a partire da questo momento aiuta a misurare la durata complessiva dell’elaborazione e a individuare i ritardi nelle prime fasi. Dove reperirli È un evento esplicito, rilevato quando viene creato un record nel registro delle fatture fornitore, in genere nella tabella VendInvoiceRegisterJournalTable o in una tabella analoga delle fatture in sospeso. Acquisizione Data e ora di creazione del record nel giornale di registrazione delle fatture fornitore. Tipo di evento explicit
	Fattura registrata contabilmente	È l’evento contabile formale con cui la fattura approvata viene registrata nella contabilità generale e genera una passività. Si tratta di un evento transazionale esplicito nel sistema.
Perché è importante La registrazione contabile è l’ultimo passaggio prima del pagamento e un importante punto di controllo finanziario. Il tempo tra «Fattura approvata» e «Fattura registrata contabilmente» misura l’efficienza delle fasi contabili finali. Dove reperirli È un evento esplicito, rilevato quando viene creata la transazione del fornitore registrata in tabelle come VendTrans e nei record associati GeneralJournalEntry e LedgerEntry. Acquisizione Data e ora di creazione del record nella tabella delle transazioni del fornitore (VendTrans). Tipo di evento explicit
	Fattura riconciliata con l’ordine di acquisto	Indica il completamento corretto della riconciliazione, quando i dettagli della fattura corrispondono a quelli dell’ordine di acquisto e della ricevuta merci. L’evento si deduce quando lo stato di riconciliazione della fattura viene aggiornato a «Superato».
Perché è importante Per le fatture associate a un ordine di acquisto, una riconciliazione corretta è una tappa fondamentale, perché conferma la validità dell’addebito prima del pagamento. È essenziale per monitorare l’efficienza della riconciliazione e il livello di automazione. Dove reperirli Si deduce quando il campo dello stato di riconciliazione nell’intestazione o nelle righe della fattura fornitore, ad esempio VendInvoiceInfoTable, viene aggiornato a «Superato» o «Riconciliato correttamente». Acquisizione Data e ora della modifica dello stato a «Superato» nei dettagli di convalida della riconciliazione della fattura. Tipo di evento inferred
	Pagamento eseguito	È l’attività finale: la registrazione del giornale di pagamento genera il pagamento e salda la fattura. Si tratta di un evento transazionale esplicito che conclude il ciclo di elaborazione della fattura.
Perché è importante Questa attività segna la conclusione corretta del processo dalla fattura al pagamento. È il riferimento per misurare il «Tasso di pagamenti puntuali» e il tempo di ciclo complessivo. Dove reperirli È un evento esplicito, rilevato al momento della registrazione del giornale di pagamento. Le informazioni sul saldo vengono registrate in tabelle come VendSettlement, che collegano il pagamento alla fattura. Acquisizione Data e ora di registrazione del giornale di pagamento che salda la transazione del fornitore. Tipo di evento explicit
	Blocco del pagamento impostato	Questa attività si verifica quando viene applicato un blocco alla fattura che ne impedisce il pagamento. Viene rilevata quando cambia il campo relativo al blocco o alla sospensione del pagamento nel record della fattura registrata.
Perché è importante I blocchi dei pagamenti sono una delle cause principali dei ritardi. Analizzare quando e perché vengono impostati è fondamentale per migliorare la puntualità dei pagamenti e i rapporti con i fornitori. Dove reperirli Si deduce da una modifica del campo relativo alla sospensione o al blocco del pagamento nella transazione del fornitore registrata (VendTrans). Il registro delle modifiche può fornire la data e l’ora. Acquisizione Data e ora dell’aggiornamento che imposta il campo di blocco del pagamento nella transazione del fornitore. Tipo di evento inferred
	Blocco del pagamento rimosso	Indica la rimozione del blocco del pagamento, che consente alla fattura di passare alla pianificazione del pagamento. Viene rilevata quando il campo di blocco del pagamento viene cancellato o impostato su uno stato non bloccato.
Perché è importante Misura il tempo necessario per risolvere i problemi che causano il blocco dei pagamenti. Un intervallo lungo tra l’impostazione e la rimozione del blocco indica inefficienze nella risoluzione dei problemi. Dove reperirli Si deduce da una modifica che cancella il campo relativo alla sospensione o al blocco del pagamento nella transazione del fornitore registrata (VendTrans). Il registro delle modifiche può fornire la data e l’ora. Acquisizione Data e ora dell’aggiornamento che cancella il campo di blocco del pagamento nella transazione del fornitore. Tipo di evento inferred
	Contabilizzazione della fattura completata	Questa attività indica che alle righe della fattura sono state assegnate le distribuzioni dei conti di contabilità generale. In genere si deduce dalla creazione o dal completamento delle distribuzioni contabili collegate alla fattura.
Perché è importante La codifica è un passaggio fondamentale per garantire l’accuratezza finanziaria. Misurare il tempo necessario per codificare le fatture aiuta a individuare i colli di bottiglia nella revisione contabile e supporta il KPI «Tempo medio dall’acquisizione dei dati alla codifica». Dove reperirli Si deduce dalla creazione e dalla convalida dei record nelle tabelle delle distribuzioni contabili, ad esempio AccountingDistribution, associate alla fattura fornitore in sospeso. Acquisizione Data e ora in cui le distribuzioni contabili della fattura vengono salvate e convalidate. Tipo di evento inferred
	Dati della fattura acquisiti	Indica che è stato completato l’inserimento dei dati della fattura, compresi i dettagli di intestazione e delle righe, prima dell’invio alla riconciliazione o all’approvazione. Spesso si deduce quando lo stato del record della fattura passa da «nuovo» o «registrato» a «pronto per l’elaborazione».
Perché è importante Monitorare questa attività aiuta a misurare l’efficienza dell’inserimento dei dati, manuale o automatizzato tramite OCR. I ritardi in questa fase possono ripercuotersi sull’intero processo. Dove reperirli Si deduce dalle modifiche di stato del record della fattura fornitore in sospeso, ad esempio VendInvoiceInfoTable. L’evento si verifica quando tutti i campi obbligatori sono compilati e la fattura è pronta per la fase successiva. Acquisizione Rilevare la modifica di stato nella tabella delle fatture in sospeso che indica il completamento dell’inserimento dei dati. Tipo di evento inferred
	Discrepanza nella riconciliazione gestita	Segna la risoluzione di una discrepanza di riconciliazione già individuata e consente alla fattura di proseguire. Si deduce quando una fattura con stato di riconciliazione «Non superato» viene riconciliata correttamente oppure sbloccata manualmente.
Perché è importante Questa attività conclude il sottoprocesso di risoluzione della discrepanza. Il tempo tra «Rilevata discrepanza nella riconciliazione» e questo evento è un KPI importante per misurare l’efficienza della risoluzione. Dove reperirli Si deduce da un evento di riconciliazione corretta («Fattura riconciliata con l’ordine di acquisto») che si verifica dopo un evento «Rilevata discrepanza nella riconciliazione» per la stessa fattura. Acquisizione Individuare una data e ora dello stato di riconciliazione «Superato» successiva a una data e ora dello stato «Non superato». Tipo di evento inferred
	Fattura respinta	Indica che un approvatore ha respinto la fattura, interrompendo il processo e rinviandola in genere per una correzione. Il motore dei flussi di lavoro registra esplicitamente l’evento di rifiuto.
Perché è importante Monitorare i rifiuti aiuta a quantificare le rilavorazioni e a individuare le cause ricorrenti, come una codifica errata o la violazione delle policy. Questo dato supporta direttamente il KPI «Tasso di rifiuto delle fatture». Dove reperirli È un evento esplicito registrato nelle tabelle della cronologia dei flussi di lavoro, ad esempio WorkflowTrackingStatusTable, quando lo stato del flusso di lavoro passa a «Respinto» o «Annullato». Acquisizione Data e ora della registrazione dello stato «Respinto» nella cronologia dei flussi di lavoro. Tipo di evento explicit
	Pagamento pianificato	Questa attività si verifica quando una fattura registrata viene inclusa in una proposta di pagamento o in un giornale di pagamento, prima che il pagamento venga eseguito. È un’azione esplicita che crea una riga nel giornale di pagamento.
Perché è importante Segna il passaggio dalla contabilità fornitori alle attività di tesoreria. Analizzare questa fase può far emergere ritardi tra la registrazione della fattura e l’avvio del pagamento. Dove reperirli È un evento esplicito, rilevato quando viene creata una riga nel giornale di pagamento (LedgerJournalTrans) che salda la transazione del fornitore registrata. Acquisizione Data e ora di creazione della riga del giornale di pagamento che fa riferimento alla fattura. Tipo di evento explicit
	Rilevata discrepanza nella riconciliazione	Questa attività si verifica quando la riconciliazione della fattura non riesce a causa di differenze tra la fattura, l’ordine di acquisto o la ricevuta merci. Viene rilevata quando lo stato di riconciliazione della fattura è impostato su «Non superato» o «Discrepanza».
Perché è importante Individuare quando e perché si verificano discrepanze è fondamentale per il KPI «Tasso di discrepanze nella riconciliazione». Questa attività segna l’inizio del processo di risoluzione, che spesso è fonte di ritardi significativi. Dove reperirli Si deduce quando il campo dello stato di riconciliazione della fattura fornitore, ad esempio VendInvoiceInfoTable, viene aggiornato a «Non superato». Spesso viene registrato anche il motivo dell’esito negativo. Acquisizione Data e ora della modifica dello stato a «Non superato» o «Discrepanza» durante la riconciliazione. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Microsoft Dynamics 365

Passaggi

Acceda all’area di lavoro Gestione dati: acceda a Microsoft Dynamics 365 Finance. Utilizzi la barra di ricerca per trovare e aprire l’area di lavoro Data management.
Crei un nuovo progetto di esportazione: nell’area di lavoro, selezioni il riquadro Export per creare un progetto di esportazione dei dati. Assegni al progetto un nome significativo, ad esempio ProcessMind_Invoice_Processing_Export.
Definisca il progetto dati: nella scheda Generale del nuovo progetto, specifichi il Data format. CSV è un formato comunemente utilizzato e consigliato. Imposti gli altri parametri secondo necessità.
Aggiunga le entità dati necessarie: acceda alla sezione Selected entities e selezioni Add entity. Cerchi e aggiunga, una alla volta, le seguenti entità principali. Per ciascuna dovrà specificare il formato dei dati di destinazione.
- VendInvoiceInfoTableEntity (intestazione fattura fornitore)
- VendInvoiceTransEntity (righe fattura fornitore)
- VendInvoiceRegisterHeaderEntity (intestazione registro fatture)
- WorkflowTrackingStatusTableEntity (cronologia del flusso di lavoro)
- AccountingDistributionEntity (distribuzioni contabili)
- VendInvoiceJour (fatture fornitore registrate)
- VendTrans (transazioni fornitore, per i blocchi di pagamento)
- LedgerJournalTransVendPaymEntity (righe del giornale pagamenti fornitori)
- VendSettlement (transazioni di liquidazione fornitori)
Applichi i filtri: per ogni entità è fondamentale applicare filtri che limitino l’ambito dei dati. Selezioni un’entità e faccia clic su Filtro. Come minimo, filtri per Company (entità giuridica) e per un intervallo di date specifico, usando un campo data pertinente come CREATEDDATETIME o INVOICEDATE. Per un’analisi iniziale, è tipico considerare gli ultimi 3-6 mesi.
Configuri le mappature delle entità: per ogni entità, riveda la mappatura dall’origine alla destinazione. Verifichi che l’esportazione includa tutti i campi necessari per l’Event Log finale. In genere, in questa fase non sono necessarie modifiche complesse alla mappatura.
Esegua il processo di esportazione: dopo aver aggiunto e filtrato tutte le entità, selezioni Export nel riquadro delle azioni per avviare il processo. Può eseguirlo subito oppure programmarlo nelle ore di minore attività, così da ridurre al minimo il carico sul sistema.
Scarichi i dati esportati: al termine del processo di esportazione, acceda alla cronologia dei processi. Da qui potrà scaricare il pacchetto di dati esportato, che conterrà file separati per ciascuna entità dati.
Trasformi i dati in un Event Log: i file esportati sono istantanee delle singole entità, non un Event Log consolidato. Dovrà usare uno strumento esterno, ad esempio un database, uno script Python o Power Query, per elaborare e combinare i file. La query concettuale nella sezione query contiene la logica completa per questa trasformazione.
Esegua la logica di trasformazione: carichi i file CSV esportati nell’ambiente di trasformazione scelto. Esegua la query di trasformazione fornita, che unisce i dati di tutti i file di origine per creare un’unica tabella Event Log, con una riga per ogni attività aziendale.
Completi e carichi i dati: esporti i dati trasformati finali in un unico file CSV. Verifichi che le intestazioni delle colonne corrispondano ai requisiti, ad esempio InvoiceNumber, ActivityName, EventTime. Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Entità dati: la configurazione si basa sulla selezione delle entità necessarie a coprire l’intero ciclo di vita delle fatture. Tra le entità principali figurano VendInvoiceInfoTableEntity, VendInvoiceJour e WorkflowTrackingStatusTableEntity.
Formato di esportazione dei dati: selezioni CSV come formato di destinazione per semplificare le successive fasi di trasformazione.
Filtro per società: è fondamentale filtrare ogni entità dati in base alla specifica entità giuridica (Company) analizzata, per evitare di estrarre dati non pertinenti.
Filtro per intervallo di date: applichi un filtro coerente per intervallo di date a tutte le entità pertinenti, ad esempio VendInvoiceInfoTableEntity e VendInvoiceJour, basandosi sulle date di creazione o registrazione. Inizi da un periodo recente, ad esempio gli ultimi 6 mesi, per gestire il volume dei dati.
Caricamento completo o incrementale: per l’estrazione iniziale, esegua un caricamento completo. Per gli aggiornamenti successivi, può configurare un’esportazione incrementale che recuperi solo i dati modificati dall’ultima esecuzione, riducendo i tempi di elaborazione.
Prerequisiti: l’utente che esegue l’esportazione deve disporre dei ruoli di sicurezza appropriati in Dynamics 365, in genere Data management administrator o un ruolo equivalente con autorizzazioni per accedere alle entità dati necessarie.

Query di esempio sql

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Passaggi

Prerequisito: configurare BYOD: verifichi che la funzionalità Bring Your Own Database sia configurata per l’ambiente Microsoft Dynamics 365 Finance and Operations. È necessario predisporre un database Azure SQL e configurare D365 affinché vi esporti i dati.
Individuare le entità dati: in D365, acceda all’area di lavoro Data management. L’estrazione si basa sull’esportazione di specifiche entità dati. Verifichi che un processo di esportazione diretto al database BYOD includa le seguenti entità: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements e Accounting distributions.
Creare e pianificare il processo di esportazione: nell’area di lavoro Data management, crei un nuovo progetto di esportazione. Aggiunga al progetto le entità elencate sopra e imposti il database BYOD come formato dati di destinazione. Pianifichi l’esecuzione ricorrente del processo, ad esempio ogni giorno o ogni ora, per mantenere aggiornati i dati nel database BYOD.
Verificare i dati in Azure SQL: si connetta al database Azure SQL con uno strumento come SQL Server Management Studio (SSMS) o Azure Data Studio. Verifichi che le tabelle corrispondenti alle entità D365 siano state create e contengano dati.
Preparare la query SQL: copi la query SQL fornita. È progettata per essere eseguita direttamente sulle tabelle create dal processo di esportazione BYOD nel database Azure SQL.
Connettersi ed eseguire la query: apra una nuova finestra di query nel client SQL connesso a BYOD. Incolli la query SQL copiata nella finestra.
Impostare i parametri della query: individui le variabili segnaposto all’inizio dello script. Sostituisca {StartDate}, {EndDate} e {CompanyCode} rispettivamente con la data di inizio, la data di fine e l’identificativo dell’entità giuridica desiderati. Ad esempio: SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Eseguire la query: esegua l’intero script SQL. La query raccoglie e unisce i dati di più tabelle per creare un Event Log cronologico per ogni fattura.
Rivedere i risultati: l’output sarà un’unica tabella contenente l’Event Log, con colonne quali InvoiceNumber, ActivityName, EventTime e gli altri attributi specificati. Riveda i risultati per verificare che siano corretti e completi.
Esportare l’Event Log: esporti i risultati della query in un file CSV. La maggior parte dei client SQL include una funzione per salvare i risultati in un file. Verifichi che il file venga salvato con codifica UTF-8.
Preparare il caricamento: prima di caricare i dati in uno strumento di Process Mining, verifichi che il file CSV contenga esattamente le intestazioni indicate nella query (InvoiceNumber, ActivityName e così via). Non sono necessarie altre trasformazioni della struttura del file.

Configurazione

Entità dati principali: l’estrazione richiede che diverse entità dati D365 vengano esportate nel database BYOD. Tra quelle fondamentali figurano VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution e VendTrans.
Filtro per intervallo di date: la query fornita include i parametri @StartDate e @EndDate. Si consiglia di iniziare con un intervallo limitato, ad esempio 3-6 mesi di dati, per verificare le prestazioni. Il filtro viene applicato alla data di registrazione o di creazione della fattura.
Filtro per codice società: il parametro @DataAreaId è fondamentale negli ambienti con più società. Filtri sempre per una specifica entità giuridica (codice società) per mantenere corretto il contesto dei dati.
Frequenza di aggiornamento BYOD: l’aggiornamento dei dati dipende interamente dalla pianificazione del processo di esportazione D365. Per un’analisi quasi in tempo reale è necessaria una frequenza elevata, ad esempio oraria, che può incidere sulle prestazioni e sui costi sia di D365 sia di Azure.
Prerequisiti: questo metodo richiede un abbonamento Azure attivo, un database Azure SQL predisposto e l’accesso con privilegi di amministratore in D365 per configurare l’area di lavoro Data management.

Query di esempio sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

Passaggi

Preparare i prerequisiti: verifichi che sul sistema sia installato Python 3.6 o versione successiva. Installi le librerie necessarie con pip: pip install pandas requests msal. Queste librerie servono rispettivamente a manipolare i dati, inviare richieste HTTP all’API e gestire l’autenticazione tramite la piattaforma Microsoft Identity.
Registrare un’applicazione in Azure Active Directory: per autenticarsi all’API di Dynamics 365, dovrà registrare un’applicazione nel tenant Azure AD dell’organizzazione. Crei una nuova registrazione app, generi un segreto client e annoti l’ID applicazione (client), l’ID directory (tenant) e il valore del segreto client.
Concedere le autorizzazioni API: nella registrazione app appena creata in Azure AD, acceda alle autorizzazioni API. Aggiunga un’autorizzazione per Dynamics ERP o Dynamics 365 Business Central, in base alla licenza, e conceda l’autorizzazione delegata user_impersonation. Un amministratore deve concedere il consenso amministrativo per queste autorizzazioni.
Creare un utente applicazione in Dynamics 365: nell’ambiente Dynamics 365, acceda a System administration > Users > Users. Crei un nuovo utente e inserisca nel campo Application ID l’ID applicazione (client) della registrazione app Azure. Assegni all’utente i ruoli di sicurezza appropriati, ad esempio System administrator o un ruolo più limitato che consenta l’accesso in lettura a tutte le entità dati necessarie.
Configurare lo script Python: copi lo script Python fornito in un file, ad esempio extract_invoices.py. Apra il file e aggiorni le variabili segnaposto all’inizio con l’URL specifico dell’ambiente Dynamics 365, l’ID tenant, l’ID client, il segreto client e il codice società (dataAreaId) da cui desidera estrarre i dati.
Impostare l’intervallo di date: modifichi le variabili START_DATE e END_DATE nello script per definire il periodo di estrazione dei dati. Si consiglia di iniziare con un intervallo più breve, ad esempio un mese, per provare lo script e verificare i risultati.
Eseguire lo script: avvii lo script dalla riga di comando o dal terminale con il comando python extract_invoices.py. Lo script eseguirà l’autenticazione, interrogherà i diversi endpoint OData per ogni attività ed elaborerà i dati.
Controllare l’esecuzione: durante il recupero dei dati per ciascuna attività, lo script mostrerà messaggi di avanzamento nella console. L’operazione può richiedere molto tempo, a seconda dell’intervallo di date e del volume dei dati. Verifichi la presenza di messaggi di errore che potrebbero indicare problemi di autenticazione o di accesso all’API.
Rivedere il file di output: al termine dell’esecuzione, lo script genererà nella stessa directory un file CSV denominato d365_invoice_event_log.csv. Il file contiene l’Event Log consolidato.
Preparare il caricamento: apra il file CSV e ne verifichi la formattazione. Controlli che siano presenti e compilate tutte le colonne necessarie (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate). Il file è pronto per essere caricato in ProcessMind.

Configurazione

Autenticazione: lo script utilizza il flusso delle credenziali client OAuth 2.0. Dovrà configurare una registrazione app Azure AD e concederle le autorizzazioni API per Dynamics 365. È inoltre necessario creare in Dynamics 365 un utente applicazione con i ruoli di sicurezza appropriati.
Endpoint API: URL di base dell’API OData di Dynamics 365 Finance and Operations. Il formato è in genere https://[your-d365-environment-name].operations.dynamics.com.
Intervallo di date: lo script include le variabili START_DATE e END_DATE, utilizzate per filtrare i record in base alle date di creazione o modifica e gestire il volume dei dati. Per le prime estrazioni si consiglia un periodo di 3-6 mesi.
Filtro per società: i dati devono essere filtrati per una specifica società o entità giuridica. A questo scopo, nello script è obbligatorio specificare dataAreaId nel filtro della query API.
Entità dati principali: lo script interroga diverse entità OData standard di Dynamics 365, tra cui VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines e VendSettlements. Se il processo standard è stato modificato in modo sostanziale, potrebbero essere necessarie entità personalizzate.
Paginazione: lo script gestisce automaticamente le risposte paginate dell’API tramite la proprietà @odata.nextLink, così da recuperare tutti i record del periodo specificato.

Query di esempio python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"
COMPANY_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

    if not all_events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Passaggi

Verifichi di avere accesso a Microsoft Power Platform, Power Query, all’ambiente Dynamics 365 di destinazione e alle entità o tabelle di origine che contengono i dati relativi a fatture fornitore, righe fattura, distribuzioni contabili, ordini di acquisto, ricezioni, flussi di lavoro, blocchi di pagamento, registrazioni contabili e pagamenti. Poiché le implementazioni di Dynamics 365 variano, documenti gli oggetti di origine effettivi in una cartella di lavoro di mappatura. Finché non avrà confermato gli oggetti specifici dell’ambiente, utilizzi segnaposto come [Your invoice register table] e [Your workflow event table].
In Power Platform, crei un flusso di dati nell’area di lavoro o nell’ambiente utilizzato per l’estrazione di ProcessMind. Selezioni il connettore adatto alla distribuzione di Dynamics 365 e configuri la connessione con [Your connection string or environment reference] e [Your credentials]. Non inserisca le credenziali nel testo della query.
In Power Query, aggiunga le entità di origine necessarie per l’estrazione. Come minimo, mappi le fonti relative a registro fatture, intestazione fattura, righe fattura, distribuzioni contabili, abbinamento a ordini di acquisto o ricezioni, cronologia del flusso di lavoro, cronologia dei blocchi di pagamento, transazioni di registrazione contabile, proposte di pagamento o righe del giornale pagamenti e liquidazioni dei pagamenti. Prima di pubblicare il flusso di dati, annoti nella cartella di lavoro di mappatura i nomi effettivi delle entità e delle colonne.
Applichi a ciascuna fonte l’intervallo di estrazione concordato, usando [Start date] e [End date]. Filtri per [Your company or legal entity filter], per i tipi di documento pertinenti e per i record delle fatture fornitore. Mantenga i timestamp di origine con precisione sufficiente a ordinare gli eventi. Per EventTime, utilizzi i timestamp del sistema di origine, non quelli di aggiornamento.
Crei una query normalizzata con una riga per ogni evento aziendale registrato esplicitamente o derivato in modo esplicito. La query deve produrre i seguenti valori ActivityName: Invoice Registered, Invoice Data Captured, Invoice Coded, Invoice Matched To Purchase Order, Matching Discrepancy Found, Matching Discrepancy Handled, Invoice Sent For Approval, Invoice Approved, Invoice Rejected, Payment Block Set, Payment Block Released, Invoice Posted, Payment Scheduled e Payment Executed. ProcessMind legge l’Event Log così come viene fornito, quindi non faccia affidamento su ProcessMind per dedurre le attività mancanti.
Colleghi ogni fonte di eventi alla fattura usando InvoiceNumber. Se una fonte utilizza una chiave interna della fattura, colleghi prima tale chiave all’intestazione o al registro fatture e riporti poi il valore aziendale InvoiceNumber. Mantenga, quando disponibili, VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate e EndTime. Documenti la mappatura specifica dell’ambiente per ogni colonna di origine.
Applichi condizioni specifiche per ciascun evento. La registrazione richiede la creazione di un record nel registro fatture fornitore. L’acquisizione dei dati richiede la transizione configurata da uno stato nuovo o registrato a uno stato pronto per l’elaborazione. La codifica richiede la creazione o la finalizzazione delle distribuzioni contabili. Un abbinamento riuscito richiede un risultato Passed. Un abbinamento non riuscito richiede Failed o Discrepancy. La gestione di una discrepanza richiede un successivo nuovo abbinamento riuscito o una sostituzione manuale documentata. L’invio, l’approvazione e il rifiuto nel flusso di lavoro richiedono eventi espliciti del flusso di lavoro. Gli eventi di blocco dei pagamenti richiedono una modifica dello stato del blocco. La registrazione contabile, la pianificazione e l’esecuzione richiedono record espliciti di registrazione, del giornale pagamenti o di liquidazione.
Uniformi i tipi e i valori dei dati. Imposti InvoiceNumber e ActivityName come testo, EventTime e EndTime come data e ora, InvoiceAmount come valore numerico e PaymentDueDate come data o data e ora, in base alla fonte. Imposti SourceSystem su Microsoft Dynamics 365. Imposti LastDataUpdate sul timestamp di aggiornamento del flusso di dati o sul timestamp di estrazione dalla fonte, applicando lo stesso criterio a tutte le righe di ogni aggiornamento.
Rimuova le righe prive di InvoiceNumber o EventTime, salvo che una procedura di eccezione approvata assegni un identificativo stabile al caso. Elimini i duplicati solo quando i record duplicati rappresentano lo stesso evento, utilizzando, se disponibile, l’identificativo dell’evento di origine. Non accorpi approvazioni, tentativi di abbinamento, blocchi o azioni di pagamento ripetuti ma distinti.
Carichi l’output normalizzato nella destinazione configurata, ad esempio una destinazione dati di Power Platform, un lakehouse, un data warehouse o una destinazione file supportata dall’implementazione. Esporti o renda disponibile il risultato come tabella piatta, con un evento per riga e le colonne obbligatorie InvoiceNumber, ActivityName, EventTime, SourceSystem e LastDataUpdate, oltre agli attributi consigliati, se disponibili.
Aggiorni il flusso di dati, controlli l’output e completi le verifiche di convalida. Verifichi che siano presenti tutti i 14 valori ActivityName quando esistono i record di origine corrispondenti, che i timestamp siano ordinati correttamente e che l’identificativo del caso sia InvoiceNumber. Esporti la tabella convalidata in un formato supportato da ProcessMind, ad esempio CSV o il formato di output del connettore configurato, quindi la carichi o la colleghi a ProcessMind, impostando InvoiceNumber come identificativo del caso, ActivityName come attività e EventTime come timestamp dell’evento.

Configurazione

Mappatura delle fonti: sostituisca ogni segnaposto specifico dell’ambiente con le entità, le tabelle, le viste e le colonne effettive di Dynamics 365. Non presuma che i nomi coincidano tra Finance, Supply Chain Management, Dataverse, personalizzazioni o integrazioni.
Colonne di output obbligatorie: per ogni riga evento accettata, InvoiceNumber, ActivityName, EventTime, SourceSystem e LastDataUpdate devono essere valorizzati.
Colonne di output consigliate: includa VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate e EndTime quando disponibili nella fonte.
Intervallo di date: inizi con 3-6 mesi di cronologia. Estenda l’intervallo solo dopo aver verificato le prestazioni della query e la completezza degli eventi. Se supportati, utilizzi un limite iniziale inclusivo e uno finale esclusivo per evitare duplicati tra gli aggiornamenti.
Filtro per società o entità giuridica: applichi [Your company or legal entity filter] in modo coerente a tutte le entità di origine. Verifichi che le unioni non combinino fatture di entità giuridiche diverse quando InvoiceNumber non è univoco a livello globale.
Filtro per tipo di documento: limiti l’estrazione alle fatture fornitore e ai tipi di documento utilizzati dal processo. Configuri il filtro in base al sistema, senza presupporre uno specifico valore di Dynamics 365.
Filtri di stato: utilizzi i valori configurati per nuovo, registrato, pronto per l’elaborazione, Passed, Failed, Discrepancy, approvato, rifiutato, bloccato e sbloccato. Le etichette di stato possono variare in base alla versione, alla lingua, alle personalizzazioni o all’integrazione.
Semantica degli eventi: estragga una riga esplicita per ogni attività richiesta. Le attività derivate sono ammesse solo quando la transizione o il record di origine indicato fornisce prove attendibili. ProcessMind non deduce gli eventi dalle altre righe.
Scelta dei timestamp: privilegi il timestamp dell’evento di origine. Utilizzi i timestamp di creazione, modifica, azione del flusso di lavoro, registrazione contabile, giornale o liquidazione in base alla definizione dell’evento. Non utilizzi LastDataUpdate come EventTime.
Metadati di aggiornamento: valorizzi LastDataUpdate con un unico timestamp coerente per ogni esecuzione del flusso di dati. Se la destinazione supporta l’aggiornamento incrementale, mantenga separatamente il punto di ripresa dell’aggiornamento rispetto a EventTime.
Aggiornamento incrementale: utilizzi un indicatore di avanzamento stabile della fonte, ad esempio un timestamp di modifica o un identificativo dell’evento, e includa un periodo di riesame per acquisire gli eventi tardivi relativi a flussi di lavoro, abbinamenti e pagamenti. Se disponibili, elimini i duplicati usando gli identificativi degli eventi di origine.
Prestazioni: applichi i filtri alle entità di origine prima delle unioni, selezioni solo le colonne necessarie, eviti di espandere senza limiti le righe delle fatture e prepari separatamente le fonti di grandi dimensioni. Utilizzi il query folding quando supportato dal connettore. Partizioni gli intervalli di date ampi o aggiorni i dati in modo incrementale.
Chiavi di unione: utilizzi InvoiceNumber solo se è univoco nell’ambito della società o dell’entità giuridica selezionata. In caso contrario, utilizzi la chiave composta specifica dell’ambiente e riporti InvoiceNumber nell’output finale.
Prerequisiti: sono necessarie autorizzazioni per accedere ai dati di Dynamics 365, alla cronologia dei flussi di lavoro, ai dati di registrazione contabile e di pagamento, nonché al flusso di dati e alla destinazione di Power Platform. Le licenze necessarie e la disponibilità dei connettori dipendono dal tenant, dalla distribuzione di Dynamics 365 e dalla destinazione selezionata.
Sicurezza: utilizzi connessioni gestite o credenziali approvate, applichi il principio del privilegio minimo ed eviti di incorporare segreti nelle espressioni di Power Query o nei file esportati.
Valuta e importi: mantenga la valuta di origine oppure aggiunga la colonna valuta specifica dell’ambiente se necessaria per l’analisi finanziaria. Non converta gli importi, a meno che non sia stata definita una regola approvata per i tassi di cambio.

Query di esempio sql

let
    StartDate = #datetime(2025, 1, 1, 0, 0, 0),
    EndDate = #datetime(2025, 7, 1, 0, 0, 0),
    CompanyFilter = "[Your company or legal entity filter]",
    SourceSystemValue = "Microsoft Dynamics 365",
    RefreshTime = DateTimeZone.RemoveZone(DateTimeZone.UtcNow()),

    InvoiceRegister = Table.SelectRows(#"[Your invoice register table]", each [Company] = CompanyFilter and [CreatedDateTime] >= StartDate and [CreatedDateTime] < EndDate),
    InvoiceHeader = Table.SelectRows(#"[Your invoice header table]", each [Company] = CompanyFilter),
    InvoiceLines = Table.SelectRows(#"[Your invoice line table]", each [Company] = CompanyFilter),
    LedgerDistributions = Table.SelectRows(#"[Your ledger distribution table]", each [Company] = CompanyFilter and [CreatedDateTime] >= StartDate and [CreatedDateTime] < EndDate),
    MatchingResults = Table.SelectRows(#"[Your invoice matching result table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    WorkflowEvents = Table.SelectRows(#"[Your workflow event table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PaymentHoldHistory = Table.SelectRows(#"[Your payment hold history table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PostingEvents = Table.SelectRows(#"[Your invoice posting table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PaymentScheduleEvents = Table.SelectRows(#"[Your payment proposal or payment journal line table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),
    PaymentExecutionEvents = Table.SelectRows(#"[Your payment settlement table]", each [Company] = CompanyFilter and [EventDateTime] >= StartDate and [EventDateTime] < EndDate),

    HeaderColumns = Table.SelectColumns(InvoiceHeader, {"InvoiceNumber", "VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "InvoiceStatus", "PaymentDueDate"}),
    HeaderDistinct = Table.Distinct(HeaderColumns, {"InvoiceNumber"}),

    RegisterEvents = Table.RenameColumns(Table.SelectColumns(InvoiceRegister, {"InvoiceNumber", "CreatedDateTime", "User"}), {{"CreatedDateTime", "EventTime"}}),
    RegisterWithActivity = Table.AddColumn(RegisterEvents, "ActivityName", each "Invoice Registered", type text),

    DataCapturedBase = Table.SelectRows(InvoiceHeader, each ([PreviousStatus] = "new" or [PreviousStatus] = "registered") and [InvoiceStatus] = "ready for processing"),
    DataCapturedEvents = Table.RenameColumns(Table.SelectColumns(DataCapturedBase, {"InvoiceNumber", "StatusChangedDateTime", "User"}), {{"StatusChangedDateTime", "EventTime"}}),
    DataCapturedWithActivity = Table.AddColumn(DataCapturedEvents, "ActivityName", each "Invoice Data Captured", type text),

    CodedBase = Table.SelectRows(LedgerDistributions, each [DistributionStatus] = "Finalized" or [DistributionStatus] = "Created"),
    CodedEvents = Table.RenameColumns(Table.SelectColumns(CodedBase, {"InvoiceNumber", "EventDateTime", "User"}), {}),
    CodedWithActivity = Table.AddColumn(CodedEvents, "ActivityName", each "Invoice Coded", type text),

    MatchedBase = Table.SelectRows(MatchingResults, each [MatchingStatus] = "Passed"),
    MatchedEvents = Table.SelectColumns(MatchedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    MatchedWithActivity = Table.AddColumn(MatchedEvents, "ActivityName", each "Invoice Matched To Purchase Order", type text),

    DiscrepancyBase = Table.SelectRows(MatchingResults, each [MatchingStatus] = "Failed" or [MatchingStatus] = "Discrepancy"),
    DiscrepancyEvents = Table.SelectColumns(DiscrepancyBase, {"InvoiceNumber", "EventDateTime", "User"}),
    DiscrepancyWithActivity = Table.AddColumn(DiscrepancyEvents, "ActivityName", each "Matching Discrepancy Found", type text),

    HandledBase = Table.SelectRows(MatchingResults, each ([MatchingStatus] = "Passed" and ([PreviousMatchingStatus] = "Failed" or [PreviousMatchingStatus] = "Discrepancy")) or [ManualOverride] = true),
    HandledEvents = Table.SelectColumns(HandledBase, {"InvoiceNumber", "EventDateTime", "User"}),
    HandledWithActivity = Table.AddColumn(HandledEvents, "ActivityName", each "Matching Discrepancy Handled", type text),

    SubmittedBase = Table.SelectRows(WorkflowEvents, each [WorkflowEventType] = "Submitted"),
    SubmittedEvents = Table.SelectColumns(SubmittedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    SubmittedWithActivity = Table.AddColumn(SubmittedEvents, "ActivityName", each "Invoice Sent For Approval", type text),

    ApprovedBase = Table.SelectRows(WorkflowEvents, each [WorkflowEventType] = "Approved"),
    ApprovedEvents = Table.SelectColumns(ApprovedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    ApprovedWithActivity = Table.AddColumn(ApprovedEvents, "ActivityName", each "Invoice Approved", type text),

    RejectedBase = Table.SelectRows(WorkflowEvents, each [WorkflowEventType] = "Rejected"),
    RejectedEvents = Table.SelectColumns(RejectedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    RejectedWithActivity = Table.AddColumn(RejectedEvents, "ActivityName", each "Invoice Rejected", type text),

    BlockSetBase = Table.SelectRows(PaymentHoldHistory, each [HoldStatus] = "Blocked" and ([PreviousHoldStatus] <> "Blocked" or [PreviousHoldStatus] = null)),
    BlockSetEvents = Table.SelectColumns(BlockSetBase, {"InvoiceNumber", "EventDateTime", "User"}),
    BlockSetWithActivity = Table.AddColumn(BlockSetEvents, "ActivityName", each "Payment Block Set", type text),

    BlockReleasedBase = Table.SelectRows(PaymentHoldHistory, each ([HoldStatus] = "Unblocked" or [HoldStatus] = "") and [PreviousHoldStatus] = "Blocked"),
    BlockReleasedEvents = Table.SelectColumns(BlockReleasedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    BlockReleasedWithActivity = Table.AddColumn(BlockReleasedEvents, "ActivityName", each "Payment Block Released", type text),

    PostedBase = Table.SelectRows(PostingEvents, each [PostingStatus] = "Posted"),
    PostedEvents = Table.SelectColumns(PostedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    PostedWithActivity = Table.AddColumn(PostedEvents, "ActivityName", each "Invoice Posted", type text),

    ScheduledBase = Table.SelectRows(PaymentScheduleEvents, each [PaymentJournalLineStatus] = "Created" or [PaymentJournalLineStatus] = "Included"),
    ScheduledEvents = Table.SelectColumns(ScheduledBase, {"InvoiceNumber", "EventDateTime", "User"}),
    ScheduledWithActivity = Table.AddColumn(ScheduledEvents, "ActivityName", each "Payment Scheduled", type text),

    ExecutedBase = Table.SelectRows(PaymentExecutionEvents, each [SettlementStatus] = "Posted" or [PaymentStatus] = "Executed"),
    ExecutedEvents = Table.SelectColumns(ExecutedBase, {"InvoiceNumber", "EventDateTime", "User"}),
    ExecutedWithActivity = Table.AddColumn(ExecutedEvents, "ActivityName", each "Payment Executed", type text),

    AllEvents = Table.Combine({RegisterWithActivity, DataCapturedWithActivity, CodedWithActivity, MatchedWithActivity, DiscrepancyWithActivity, HandledWithActivity, SubmittedWithActivity, ApprovedWithActivity, RejectedWithActivity, BlockSetWithActivity, BlockReleasedWithActivity, PostedWithActivity, ScheduledWithActivity, ExecutedWithActivity}),
    EventsWithHeader = Table.NestedJoin(AllEvents, {"InvoiceNumber"}, HeaderDistinct, {"InvoiceNumber"}, "Header", JoinKind.LeftOuter),
    ExpandedHeader = Table.ExpandTableColumn(EventsWithHeader, "Header", {"VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "InvoiceStatus", "PaymentDueDate"}, {"VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "InvoiceStatus", "PaymentDueDate"}),
    WithSourceSystem = Table.AddColumn(ExpandedHeader, "SourceSystem", each SourceSystemValue, type text),
    WithLastDataUpdate = Table.AddColumn(WithSourceSystem, "LastDataUpdate", each RefreshTime, type datetime),
    WithEndTime = Table.AddColumn(WithLastDataUpdate, "EndTime", each [EventTime], type datetime),
    SelectedColumns = Table.SelectColumns(WithEndTime, {"InvoiceNumber", "ActivityName", "EventTime", "SourceSystem", "LastDataUpdate", "VendorNumber", "PurchaseOrderNumber", "InvoiceAmount", "User", "InvoiceStatus", "PaymentDueDate", "EndTime"}),
    TypedColumns = Table.TransformColumnTypes(SelectedColumns, {{"InvoiceNumber", type text}, {"ActivityName", type text}, {"EventTime", type datetime}, {"SourceSystem", type text}, {"LastDataUpdate", type datetime}, {"VendorNumber", type text}, {"PurchaseOrderNumber", type text}, {"InvoiceAmount", type number}, {"User", type text}, {"InvoiceStatus", type text}, {"PaymentDueDate", type date}, {"EndTime", type datetime}}),
    ValidEvents = Table.SelectRows(TypedColumns, each [InvoiceNumber] <> null and [InvoiceNumber] <> "" and [EventTime] <> null),
    SortedEvents = Table.Sort(ValidEvents, {{"InvoiceNumber", Order.Ascending}, {"EventTime", Order.Ascending}, {"ActivityName", Order.Ascending}})
in
    SortedEvents

È pronto a iniziare?

Utilizzi questo template per avviare il Suo percorso di Process Mining e ottenere informazioni utili a elaborare le fatture più rapidamente e con maggiore precisione. Inizi oggi a trasformare le Sue attività.

Torna alla guida al miglioramento

Scarica il template

Inizi oggi a ottimizzare il processo Procure-to-Pay - Elaborazione delle fatture

Individui le inefficienze e riduca del 30% o più il tempo di attraversamento delle fatture.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Può iniziare in pochi minuti.

Il Suo template di dati per Procure-to-Pay - Elaborazione delle fatture

Il Suo template di dati per Procure-to-Pay - Elaborazione delle fatture

Attributi del processo Procure-to-Pay - Elaborazione delle fatture

Attività del processo Procure-to-Pay - Elaborazione delle fatture

Guide all’estrazione

Esportazione tramite Data Management Framework di Dynamics 365

Passaggi

Configurazione

Query di esempio sql

Query SQL diretta tramite Bring Your Own Database (BYOD)

Passaggi

Configurazione

Query di esempio sql

Script Python con API REST OData di Dynamics 365

Passaggi

Configurazione

Query di esempio python

Estrazione tramite flusso di dati di Microsoft Power Platform

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Inizi oggi a ottimizzare il processo Procure-to-Pay - Elaborazione delle fatture