> Miglioramento continuo dei processi > Procure to Pay Elaborazione delle fatture > Microsoft Dynamics 365 > Template dei dati

Il Suo Template dei dati per Purchase to Pay - Elaborazione delle fatture

Microsoft Dynamics 365

← Torna alla guida al miglioramento

Purchase to Pay - Attributi dell’elaborazione delle fatture (22) Purchase to Pay - Attività di elaborazione delle fatture (14) Guide all'estrazione (4)

Il Suo Template dei dati per Purchase to Pay - Elaborazione delle fatture

Questo Template fornisce una guida chiara per estrarre i dati essenziali necessari ad analizzare il processo Purchase to Pay - Elaborazione delle fatture in Microsoft Dynamics 365. Illustra gli attributi fondamentali da raccogliere, le attività principali da monitorare e indicazioni pratiche per l’estrazione dei dati. Utilizzi questa risorsa per assicurarsi di 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 vita dell’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

Purchase to Pay - Attributi dell’elaborazione delle fatture

Questi sono i campi dati consigliati da includere nel Suo Event Log per un’analisi completa del processo Purchase to Pay - Elaborazione delle fatture.

5 Obbligatorio 7 Consigliato 10 Facoltativo

	Nome	Descrizione
	Nome dell’attività ActivityName	Il nome dello specifico evento aziendale o Task che si è verificato in un determinato momento del ciclo di vita dell’elaborazione della fattura.
Descrizione Il nome dell’attività descrive una fase specifica o una variazione di stato nel processo della fattura, come «Fattura registrata», «Fattura inviata per l’approvazione» o «Pagamento eseguito». Questi dati sono fondamentali per costruire la mappa del processo e comprendere la sequenza degli eventi. L’analisi di questo Attributo rivela il flusso del processo, identifica i percorsi più comuni ed evidenzia deviazioni o colli di bottiglia. Viene utilizzato per calcolare i tempi di ciclo tra le attività, ad esempio la durata tra approvazione e contabilizzazione, e per misurare la frequenza di eventi specifici come rifiuti o blocchi dei pagamenti. Perché è importante Definisce le fasi della mappa del processo, consentendo di visualizzare il flusso del processo e analizzare le transizioni tra attività diverse. Dove reperirlo Questo Attributo deriva in genere da una combinazione di campi di stato, tipi di transazione o voci del registro delle modifiche presenti in diverse tabelle di Dynamics 365 relative all’elaborazione delle fatture. Esempi Fattura inviata per l’approvazioneDiscrepanza nel matching rilevataPagamento eseguito
	Numero della fattura InvoiceNumber	L’identificativo univoco di ogni fattura fornitore, che funge da ID principale del caso per monitorarne il ciclo di vita.
Descrizione Il numero della fattura è la chiave univoca che collega tutte le attività associate a una singola fattura fornitore. Consente di tracciare la fattura end-to-end, dalla ricezione e registrazione fino al matching, all’approvazione e al pagamento finale. Nell’analisi di Process Mining, questo Attributo è fondamentale. Definisce il caso e consente di ricostruire il flusso di processo di ogni fattura. In questo modo è possibile calcolare i tempi complessivi del ciclo, identificare le varianti di processo e analizzare le caratteristiche e gli esiti specifici di ciascuna fattura. Perché è importante È l’ID del caso essenziale che collega tutti gli eventi correlati, rendendo possibile analizzare l’intero ciclo di vita di ogni singola fattura. Dove reperirlo Si trova in genere nella tabella principale delle fatture fornitore, come VendInvoiceInfoTable, nel campo Num. Esempi INV-10056773245-AUS-001-98432
	Ora dell’evento EventTime	Il timestamp preciso che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione L’ora dell’evento, ovvero il timestamp, registra la data e l’ora esatte in cui si è svolta un’attività. È un componente fondamentale dell’Event Log, poiché fornisce la sequenza temporale necessaria per ordinare correttamente le attività e calcolare le durate. Nell’analisi, questo timestamp costituisce la base per tutte le metriche temporali. Viene utilizzato per calcolare la durata delle attività, il tempo di ciclo tra fasi diverse, ad esempio il tempo di approvazione, e il tempo totale di elaborazione end-to-end di ogni fattura. Consente inoltre di analizzare le tendenze nel tempo. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare tutti i tempi di ciclo e le durate e individuare i colli di bottiglia del processo. Dove reperirlo Proviene da diversi campi di data e ora presenti in più tabelle, come i campi createdDateTime o modifiedDateTime nelle tabelle VendInvoiceInfoTable, VendTrans o nelle tabelle della cronologia del Workflow. Esempi 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Sistema di origine SourceSystem	Il sistema di riferimento dal quale sono stati estratti i dati degli eventi.
Descrizione Questo Attributo identifica l’applicazione di origine da cui provengono i dati dell’attività. Per questo processo sarà in genere «Microsoft Dynamics 365». Negli ambienti con più sistemi, ad esempio una soluzione OCR o di acquisizione esterna, questo campo aiuta a distinguere il sistema in cui si svolge ogni fase del processo. Garantisce la tracciabilità dell’origine dei dati e facilita la risoluzione dei problemi di estrazione. Perché è importante Fornisce un contesto fondamentale sull’origine dei dati, importante per convalidare i dati e comprendere l’architettura dei sistemi coinvolti nel processo. Dove reperirlo È un valore statico, «Microsoft Dynamics 365», aggiunto durante la trasformazione dei dati per indicare l’origine del dataset. Esempi Microsoft Dynamics 365
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l’ultima volta in cui i dati relativi a questo processo sono stati aggiornati dal sistema di origine.
Descrizione Questo Attributo registra quando il dataset è stato estratto e aggiornato l’ultima volta da Microsoft Dynamics 365. In genere è uguale per tutti i record inclusi in un singolo caricamento dei dati. Queste informazioni sono fondamentali per comprendere l’attualità dei dati analizzati. Forniscono il contesto necessario per valutare quanto siano aggiornati gli insight sul processo e sono essenziali per gestire la pianificazione degli aggiornamenti dei dati e convalidare le pipeline di dati. Perché è importante Informa gli utenti sull’aggiornamento dei dati, assicurando che sappiano quanto è recente l’analisi e quando è previsto il prossimo aggiornamento. Dove reperirlo Questo timestamp viene generato e applicato al dataset dal processo di estrazione dei dati o ETL al momento dell’esecuzione. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Data di scadenza del pagamento PaymentDueDate	La data entro la quale la fattura deve essere pagata in base ai termini di pagamento concordati.
Descrizione La data di scadenza del pagamento viene calcolata sulla base della data della fattura e dei termini di pagamento del fornitore. Rappresenta il termine contrattuale per il pagamento. Questa data è fondamentale per misurare le prestazioni finanziarie e gestire i rapporti con i fornitori. Costituisce il riferimento utilizzato per calcolare il KPI «Tasso di pagamenti puntuali», confrontandola con la data effettiva di «Pagamento eseguito». L’analisi consente di individuare i 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 riferimento per misurare la puntualità dei pagamenti, un KPI fondamentale per la solidità finanziaria e i rapporti con i fornitori. Dove reperirlo Questa data viene spesso calcolata dal sistema e memorizzata nella tabella delle transazioni del fornitore, come VendTrans, sulla base della data della fattura e dei termini di pagamento. Esempi 2023-05-152023-06-302023-07-20
	Importo della fattura InvoiceAmount	Il valore monetario totale della fattura.
Descrizione Questo Attributo rappresenta l’importo totale dovuto indicato nella fattura fornitore. È un dato finanziario fondamentale per ogni caso. L’importo della fattura viene ampiamente utilizzato per la segmentazione e l’analisi. Può mostrare se le fatture di importo elevato seguono un processo di approvazione diverso e più rigoroso o se richiedono più tempo per essere elaborate. Viene inoltre utilizzato nelle Dashboard per analizzare i volumi delle fatture in base al valore e può essere aggregato per comprendere la spesa totale inclusa nell’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 reperirlo 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	L’identificativo univoco del fornitore che ha emesso la fattura.
Descrizione Il numero del fornitore è il codice che identifica univocamente un fornitore nei dati master. Collega la transazione della fattura a uno specifico fornitore, consentendo un’analisi incentrata sui fornitori. 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 nel matching sono più frequenti con determinati fornitori?». L’analisi delle 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 principali per fornitore, aiutando a individuare problemi di prestazioni o schemi ricorrenti legati a specifici fornitori. Dove reperirlo Si trova in genere nell’intestazione della tabella delle fatture fornitore, come VendInvoiceInfoTable, collegata ai dati master principali dei fornitori in VendTable. Esempi V-1001V-2050V-8342
	Numero dell’ordine di acquisto PurchaseOrderNumber	L’identificativo dell’ordine di acquisto (PO) a cui è associata la fattura.
Descrizione Il numero dell’ordine di acquisto collega la fattura al documento di approvvigionamento originale. È fondamentale per i processi che prevedono il matching a 2 o 3 vie tra fattura, ordine di acquisto e ricezione della merce. Questo Attributo consente di analizzare le fatture associate a un ordine di acquisto rispetto a quelle non associate, che spesso seguono percorsi di processo diversi. È essenziale per comprendere l’efficacia del matching, analizzare le discrepanze e misurare il tasso di elaborazione straight-through delle fatture associate a un ordine di acquisto. Perché è importante Distingue le fatture associate a un ordine di acquisto da quelle non associate, una delle principali cause di variazione del processo e un elemento fondamentale per l’analisi del matching. Dove reperirlo Si trova nella tabella dell’intestazione della fattura, come VendInvoiceInfoTable, spesso in un campo come PurchId. Esempi PO-001234PO-005678PO-009101
	Ora di fine EndTime	Il timestamp preciso che indica quando una specifica attività o un evento è stato completato.
Descrizione L’ora di fine registra il momento in cui un’attività si è conclusa. Se combinata con l’ora di inizio (EventTime), consente di calcolare con precisione quanto tempo è stato necessario per completare ogni singola fase. Questo attributo è essenziale per calcolare il «ProcessingTime» di ciascuna attività, una metrica fondamentale per l’analisi delle prestazioni. Aiuta a individuare con precisione le fasi del processo che richiedono più tempo, consentendo di definire interventi di miglioramento mirati. Ad esempio, può 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 elemento fondamentale per individuare le fasi del processo che richiedono più tempo. Dove reperirlo Come StartTime, proviene da diversi campi di data e ora. Per alcune attività può corrispondere allo StartTime dell’attività successiva; in altri casi può trattarsi di uno specifico timestamp di completamento. Esempi 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Stato della fattura InvoiceStatus	Lo stato corrente della fattura al momento dell’estrazione dei dati.
Descrizione Lo stato della fattura indica la situazione corrente di una fattura nel corso del suo ciclo di vita, ad esempio «In attesa di approvazione», «Approvata», «Registrata» o «Pagata». Fornisce una fotografia dell’avanzamento della fattura. Questo attributo viene utilizzato principalmente per creare Dashboard operative che mostrano il carico di lavoro e l’arretrato correnti. Aiuta i responsabili a comprendere quante fatture si trovano in ciascuna fase del processo, supportando l’allocazione delle risorse e il monitoraggio operativo. È fondamentale per la Dashboard «Throughput e stato dell’elaborazione delle fatture». Perché è importante Fornisce una visione aggiornata dello stato di tutte le fatture, essenziale per il monitoraggio operativo, la gestione del carico di lavoro e l’identificazione dei colli di bottiglia presenti. Dove reperirlo In genere deriva dai campi di stato della tabella principale delle fatture, come VendInvoiceInfoTable. Esempi In attesa di approvazioneRegistratoPagato
	Utente User	L’ID utente o il 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 le esigenze formative e confrontare le prestazioni di singoli utenti o team. È fondamentale per analizzare i cicli di rilavorazione, in cui il lavoro passa avanti e indietro tra diversi utenti, e per comprendere le variazioni nel modo in cui utenti diversi completano la stessa attività. Perché è importante Consente di analizzare prestazioni e carico di lavoro per utente o team e aiuta a individuare il livello di automazione e le fonti di rilavorazione. Dove reperirlo Proviene dai campi degli ID utente nelle tabelle delle transazioni o della cronologia del Workflow, come i campi createdby o modifiedby. Queste informazioni possono trovarsi nelle tabelle di monitoraggio del Workflow. Esempi j.doea.smithAX_Admin
	Codice società CompanyCode	L’identificativo dell’entità giuridica o della società dell’organizzazione che elabora la fattura.
Descrizione Il codice società rappresenta l’entità giuridica specifica finanziariamente responsabile della fattura. In un’organizzazione composta da più società, costituisce un dato fondamentale per la segmentazione finanziaria. Questo attributo consente di filtrare o confrontare l’analisi del processo tra diverse entità giuridiche. Può evidenziare se le prestazioni del processo, le policy o i colli di bottiglia sono specifici di determinate società del gruppo, supportando iniziative di miglioramento dei processi a livello locale. Perché è importante Consente di segmentare l’analisi del processo per entità giuridica, un aspetto fondamentale per le organizzazioni di grandi dimensioni composte da più società. Dove reperirlo È un campo standard presente nella maggior parte delle tabelle finanziarie di Dynamics 365, spesso denominato DataAreaId. Esempi USMFDEMFGBSI
	È automatizzato IsAutomated	Un 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 fase di abbinamento di una fattura può essere automatizzata, mentre la gestione delle discrepanze può richiedere un intervento manuale. L’analisi di questo attributo è fondamentale per comprendere il livello di automazione del processo. Aiuta a misurare il successo delle iniziative di automazione, a individuare i colli di bottiglia manuali ancora presenti e a evidenziare ulteriori opportunità di automazione 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à di miglioramento dell’efficienza. Dove reperirlo In genere viene derivato dall’attributo «User». Se l’utente è un account di sistema o di servizio noto, questo indicatore viene impostato su true. Esempi truefalse
	Motivo del blocco del pagamento PaymentBlockReason	Il codice motivo che spiega perché è stato applicato un blocco al pagamento di una fattura.
Descrizione Un blocco del pagamento impedisce il pagamento di una fattura. Questo attributo registra il motivo del blocco, generalmente un codice standard selezionato dall’utente, come «Addebiti contestati» o «In attesa della ricezione della merce». Questo attributo è essenziale per la Dashboard «Frequenza e durata dei blocchi di pagamento». Analizzare i motivi più frequenti dei blocchi aiuta a individuare i problemi alla base del processo P2P. Risolvere queste cause principali può ridurre significativamente i ritardi nei pagamenti e migliorare i rapporti con i fornitori. Perché è importante Spiega perché i pagamenti vengono intenzionalmente posticipati, aiutando a individuare e risolvere i problemi a monte che causano i blocchi di pagamento. Dove reperirlo In genere è un campo della transazione del fornitore o del record della fattura, spesso collegato allo stato del blocco del pagamento. Verificare tabelle come VendTrans. Esempi Contestazione sulla qualitàIn attesa della nota di creditoBlocco manuale
	Motivo del rifiuto RejectionReason	Il motivo indicato dall’approvatore per il rifiuto di una fattura.
Descrizione Quando una fattura viene rifiutata durante il Workflow di approvazione, l’approvatore indica generalmente un motivo. Questo attributo acquisisce tale spiegazione, che può essere un codice predefinito o un testo libero. È un attributo fondamentale per la Dashboard «Analisi dei rifiuti delle fatture». Fornisce gli elementi qualitativi necessari per comprendere le cause principali dei rifiuti, come «Numero dell’ordine di acquisto errato», «Fattura duplicata» o «Discrepanza di prezzo». L’analisi di questi motivi aiuta a definire le priorità degli interventi per ridurre il tasso di rifiuto. Perché è importante Fornisce una visione diretta delle ragioni per cui le fatture vengono rifiutate, consentendo interventi mirati per ridurre le rilavorazioni e migliorare il tasso di correttezza al primo passaggio. Dove reperirlo In genere si trova nei commenti o nei log della cronologia delle tabelle che gestiscono il Workflow. Esempi Quantità errataFattura duplicataLimite di approvazione superato
	Pagamento puntuale IsOnTimePayment	Un indicatore calcolato che specifica se una fattura è stata pagata entro la data di scadenza o prima di essa.
Descrizione Questo attributo booleano deriva dal confronto tra il timestamp dell’attività «Pagamento eseguito» e la «Data di scadenza del pagamento». Se la data del pagamento è precedente o uguale alla data di scadenza, il valore è true; in caso contrario è false. Questo attributo supporta direttamente il KPI «Tasso di pagamenti puntuali» e la Dashboard «Conformità ai termini di pagamento». Semplifica l’analisi fornendo un risultato binario chiaro per ogni fattura, rendendo semplice filtrare i pagamenti in ritardo e analizzarne le cause principali per fornitore, reparto o Paese. Perché è importante Misura direttamente la conformità ai termini di pagamento, semplificando il calcolo del KPI «Tasso di pagamenti puntuali» e le analisi correlate. Dove reperirlo 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	Il centro di costo o il 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 nella fattura. Di norma viene determinato durante l’attività di codifica della fattura. Analizzare il processo per reparto è fondamentale per comprendere le differenze tra le unità in termini di spesa, tempi di approvazione e conformità. Aiuta a individuare i reparti con il maggior numero di eccezioni sulle fatture o con i cicli di approvazione più lunghi, fornendo una base per attività mirate di comunicazione e formazione. 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 reperirlo Proviene dalle dimensioni finanziarie collegate alle righe o all’intestazione della fattura. È necessario interrogare le strutture dati correlate alle dimensioni. Esempi VenditeMarketingOperazioni IT
	Tempo totale di ciclo TotalCycleTime	La durata complessiva end-to-end dell’elaborazione di una singola fattura, dalla ricezione al pagamento.
Descrizione Il tempo totale di ciclo misura l’intera durata della permanenza di una fattura nel processo. Viene calcolato come differenza temporale tra la prima attività, ad esempio «Fattura registrata», e l’ultima attività, ad esempio «Pagamento eseguito», per un determinato numero di fattura. È un KPI primario per misurare l’efficienza complessiva del processo. Fornisce una visione di alto livello delle prestazioni e viene utilizzato nella Dashboard «Tempo di ciclo end-to-end delle fatture». Analizzare l’andamento di questa metrica e segmentarlo per attributi come fornitore o importo aiuta a individuare ampie opportunità di miglioramento. Perché è importante Rappresenta il KPI di alto livello principale per la velocità e l’efficienza complessive del processo, sintetizzando le prestazioni di ciascuna fattura. Dove reperirlo Viene calcolato a livello di caso all’interno dello strumento di Process Mining o durante la preparazione dei dati. Corrisponde alla differenza temporale tra i timestamp del primo e dell’ultimo evento per ogni CaseId. Esempi P15DP22DT5H30MP7D
	Termini di pagamento PaymentTerms	L’accordo sui termini di pagamento con il fornitore, ad esempio «Net 30» o «2% 10, Net 30».
Descrizione I termini di pagamento definiscono le condizioni concordate per pagare il fornitore, inclusi il periodo previsto e gli eventuali sconti. Queste informazioni provengono generalmente dai dati anagrafici del fornitore o dall’ordine di acquisto. Questo attributo fornisce un contesto fondamentale per la data di scadenza del pagamento e per il KPI «Tasso di pagamenti puntuali». Analizzare l’eventuale correlazione tra determinati termini di pagamento e i ritardi può far emergere criticità operative. Inoltre, aiuta a pianificare le attività finanziarie 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 dei tassi di acquisizione degli sconti. Dove reperirlo Queste informazioni sono memorizzate nell’anagrafica del fornitore (VendTable) e copiate in tabelle delle transazioni come VendInvoiceInfoTable. Esempi 30 giorni netti60 giorni netti2% 10, 30 giorni netti
	Tipo di discrepanza MatchingDiscrepancyType	Classifica il tipo di mancata corrispondenza rilevata durante il processo di abbinamento tra fattura e ordine di acquisto.
Descrizione Quando si verifica una discrepanza durante l’abbinamento a due o tre vie, questo attributo specifica la natura del problema, ad esempio «Discrepanza di prezzo», «Discrepanza di quantità» o «Ricezione della merce mancante». Questi dati sono fondamentali per la Dashboard «Tempo di risoluzione delle discrepanze di abbinamento». Analizzando la frequenza dei diversi tipi di discrepanza, l’azienda può individuare le cause principali degli errori di abbinamento. Ad esempio, frequenti discrepanze di prezzo possono indicare problemi nei dati anagrafici obsoleti, mentre le discrepanze di quantità possono segnalare problemi di spedizione. Perché è importante Classifica gli errori di abbinamento, consentendo l’analisi delle cause principali per ridurre il tasso di discrepanze e migliorare l’elaborazione automatica senza interventi. Dove reperirlo Può essere memorizzato in una tabella dedicata ai log di abbinamento o delle eccezioni, oppure può essere necessario derivarlo dai messaggi di stato o dai commenti del Workflow. Esempi Discrepanza di prezzoDiscrepanza di quantitàRicezione della merce mancante
	Valuta della fattura InvoiceCurrency	Il codice della valuta dell’importo della fattura, ad esempio USD o EUR.
Descrizione La valuta della fattura specifica la valuta in cui è espresso l’importo della fattura. È 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 filtri e report, soprattutto nelle attività globali. Garantisce che i valori finanziari siano interpretati correttamente e consente analisi specifiche per valuta o la conversione in una valuta standard di reporting. Perché è importante Fornisce il contesto essenziale per gli importi finanziari, consentendo un’interpretazione e un’analisi accurate dei valori delle fatture nelle diverse aree geografiche. Dove reperirlo Si trova nella tabella dell’intestazione della fattura, accanto all’importo della fattura, ad esempio nel campo CurrencyCode di VendInvoiceInfoTable. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Purchase to Pay - Attività di elaborazione delle fatture

Questi sono i passaggi chiave e le tappe fondamentali del processo da acquisire nel Suo Event Log per individuare e analizzare con precisione il Workflow di elaborazione delle fatture.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Fattura abbinata all’ordine di acquisto	Rappresenta il completamento corretto del processo di matching, in cui i dettagli della fattura corrispondono alle informazioni dell’ordine di acquisto e della ricezione della merce. L’evento viene dedotto quando lo stato del matching della fattura viene aggiornato a «Passed».
Perché è importante Il matching completato correttamente è una tappa fondamentale per le fatture associate a un ordine di acquisto, poiché conferma la validità dell’addebito prima del pagamento. È essenziale per monitorare l’efficienza del matching e i tassi di automazione. Dove reperirlo Viene dedotto dall’aggiornamento del campo relativo allo stato del matching nell’intestazione o nelle righe della fattura fornitore, ad esempio VendInvoiceInfoTable, al valore «Passed» o «Successfully Matched». Acquisizione Timestamp della variazione di stato a «Passed» nei dettagli di convalida del matching della fattura. Tipo di evento inferred
	Fattura approvata	Rappresenta l’approvazione finale e corretta della fattura all’interno del Workflow, che ne autorizza la contabilizzazione e il pagamento. È un evento esplicito registrato dal motore Workflow al completamento.
Perché è importante È una tappa fondamentale che conclude il processo di approvazione. Il tempo tra «Fattura inviata per l’approvazione» e questo evento è una misura importante dell’efficienza dell’approvazione e aiuta a individuare i colli di bottiglia. Dove reperirlo È un evento esplicito registrato nelle tabelle della cronologia del Workflow, ad esempio WorkflowTrackingStatusTable, quando lo stato del Workflow cambia in «Approved». Acquisizione Timestamp dell’inserimento dello stato «Approved» nella cronologia del Workflow. Tipo di evento explicit
	Fattura contabilizzata	È l’evento contabile formale con cui la fattura approvata viene registrata nel General Ledger, creando una passività. Si tratta di un evento transazionale esplicito nel sistema.
Perché è importante La contabilizzazione è l’ultima fase prima del pagamento e rappresenta un punto di controllo finanziario fondamentale. Il tempo tra «Fattura approvata» e «Fattura contabilizzata» misura l’efficienza delle fasi contabili finali. Dove reperirlo È un evento esplicito acquisito dalla creazione della transazione fornitore contabilizzata in tabelle come VendTrans e nei record associati GeneralJournalEntry e LedgerEntry. Acquisizione Timestamp di creazione del record nella tabella delle transazioni fornitore, VendTrans. Tipo di evento explicit
	Fattura inviata per l’approvazione	Questa attività segna l’invio formale di una fattura in un Workflow per la revisione e l’approvazione. Il motore Workflow di Dynamics 365 registra esplicitamente questo evento di invio.
Perché è importante Questo è il punto di partenza per misurare l’intero ciclo di approvazione. Aiuta a individuare per quanto tempo le fatture restano in attesa prima ancora che inizi il processo di approvazione ed è il riferimento per i KPI relativi all’approvazione. Dove reperirlo È un evento esplicito registrato nelle tabelle della cronologia del Workflow, ad esempio WorkflowTrackingStatusTable, quando una fattura viene inviata a un Workflow. Acquisizione Timestamp di creazione del record di invio al Workflow nella cronologia del Workflow. Tipo di evento explicit
	Fattura registrata	È il primo inserimento di una fattura nel sistema, con la creazione di un record provvisorio prima dell’elaborazione dei dettagli completi. L’attività viene acquisita quando viene creato un nuovo record nel giornale del registro delle fatture fornitore.
Perché è importante Questa attività segna l’inizio ufficiale del ciclo di vita dell’elaborazione della fattura. Analizzare il tempo trascorso da questo momento consente di misurare la durata complessiva dell’elaborazione e di individuare i ritardi nelle fasi iniziali. Dove reperirlo È un evento esplicito acquisito dalla creazione di un record nel registro delle fatture fornitore, in genere nella VendInvoiceRegisterJournalTable o in una tabella simile delle fatture in sospeso. Acquisizione Timestamp di creazione del record nel giornale del registro delle fatture fornitore. Tipo di evento explicit
	Pagamento eseguito	È l’attività finale e rappresenta la contabilizzazione del giornale dei pagamenti, che crea il pagamento e regola la fattura. Si tratta di un evento transazionale esplicito che chiude il ciclo di vita della fattura.
Perché è importante Questa attività segna la conclusione corretta del processo dalla fattura al pagamento. Costituisce la base per misurare il «Tasso di pagamenti puntuali» e il tempo totale del ciclo end-to-end. Dove reperirlo È un evento esplicito acquisito dalla contabilizzazione del giornale dei pagamenti. Le informazioni di regolazione vengono registrate in tabelle come VendSettlement, che collegano il pagamento alla fattura. Acquisizione Timestamp di contabilizzazione del giornale dei pagamenti che regola la transazione fornitore. Tipo di evento explicit
	Blocco del pagamento impostato	Questa attività si verifica quando viene applicato un blocco a una fattura, impedendone il pagamento. Viene acquisita tramite una variazione del campo relativo al blocco o alla sospensione del pagamento nel record della fattura contabilizzata.
Perché è importante I blocchi dei pagamenti sono una delle principali cause dei pagamenti tardivi. Analizzare quando e perché vengono impostati è fondamentale per migliorare la puntualità dei pagamenti e i rapporti con i fornitori. Dove reperirlo Viene dedotta da una variazione del campo relativo alla sospensione o al blocco del pagamento nella transazione fornitore contabilizzata, VendTrans. Il registro delle modifiche può essere utilizzato per acquisire il timestamp. Acquisizione Timestamp dell’aggiornamento che imposta il campo del blocco del pagamento nella transazione fornitore. Tipo di evento inferred
	Blocco del pagamento rimosso	Rappresenta la rimozione di una sospensione del pagamento, consentendo alla fattura di passare alla pianificazione del pagamento. Viene acquisita quando il campo del blocco del pagamento viene svuotato o modificato in uno stato non bloccato.
Perché è importante Misura il tempo necessario per risolvere i problemi che causano le sospensioni dei pagamenti. Durate elevate tra l’impostazione e la rimozione di un blocco indicano processi di risoluzione dei problemi inefficienti. Dove reperirlo Viene dedotta da una variazione che cancella il campo relativo alla sospensione o al blocco del pagamento nella transazione fornitore contabilizzata, VendTrans. Il registro delle modifiche può fornire il timestamp. Acquisizione Timestamp dell’aggiornamento che cancella il campo del blocco del pagamento nella transazione fornitore. Tipo di evento inferred
	Dati della fattura acquisiti	Rappresenta il completamento dell’inserimento dei dati della fattura, inclusi i dettagli dell’intestazione e delle righe, prima dell’invio al matching o all’approvazione. Spesso viene dedotto quando il record della fattura passa dallo stato «nuovo» o «registrato» allo stato «pronto per l’elaborazione».
Perché è importante Il monitoraggio di questa attività consente di misurare l’efficienza del processo di inserimento dei dati, sia manuale sia automatizzato tramite OCR. Eventuali ritardi in questa fase possono ripercuotersi sull’intero processo. Dove reperirlo Viene dedotto dalle variazioni 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 variazione di stato nella tabella delle fatture in sospeso che indica il completamento dell’inserimento dei dati. Tipo di evento inferred
	Discrepanza nel matching gestita	Segna la risoluzione di una discrepanza di matching precedentemente identificata, consentendo alla fattura di proseguire. Viene dedotta quando una fattura con stato di matching «Failed» viene nuovamente abbinata correttamente o viene sottoposta a override manuale.
Perché è importante Questa attività conclude il sottoprocesso di risoluzione della discrepanza. Il tempo tra «Discrepanza nel matching rilevata» e questo evento è un KPI fondamentale per misurare l’efficienza della risoluzione. Dove reperirlo Viene dedotta da un evento di matching completato correttamente («Fattura abbinata all’ordine di acquisto») che si verifica dopo un evento «Discrepanza nel matching rilevata» per la stessa fattura. Acquisizione Identificare un timestamp dello stato di matching «Passed» successivo a un timestamp dello stato «Failed». Tipo di evento inferred
	Discrepanza nel matching rilevata	Questa attività si verifica quando il processo di matching della fattura non va a buon fine a causa di disallineamenti tra la fattura, l’ordine di acquisto o la ricezione della merce. Viene acquisita quando lo stato del matching della fattura è impostato su «Failed» o «Discrepancy».
Perché è importante Individuare quando e perché si verificano le discrepanze è fondamentale per il KPI «Tasso di discrepanze nel matching». Questa attività segna l’inizio del processo di risoluzione, che spesso è all’origine di ritardi significativi. Dove reperirlo Viene dedotto dall’aggiornamento del campo relativo allo stato del matching nella fattura fornitore, ad esempio VendInvoiceInfoTable, al valore «Failed». Spesso viene registrato anche il motivo dell’errore. Acquisizione Timestamp della variazione di stato a «Failed» o «Discrepancy» durante il matching. Tipo di evento inferred
	Fattura codificata	Questa attività indica che alle righe della fattura sono state assegnate le distribuzioni dei conti di General Ledger. In genere viene dedotta dalla creazione o dalla finalizzazione delle distribuzioni dei conti contabili collegate alla fattura.
Perché è importante La codifica è una fase fondamentale per garantire l’accuratezza finanziaria. Misurare il tempo necessario per codificare le fatture aiuta a individuare i colli di bottiglia nel processo di revisione contabile e supporta il KPI «Tempo medio da acquisizione dati a codifica». Dove reperirlo Viene dedotto dalla creazione e dalla convalida dei record nelle tabelle delle distribuzioni contabili, ad esempio AccountingDistribution, associate alla fattura fornitore in sospeso. Acquisizione Timestamp in cui le distribuzioni contabili della fattura vengono salvate e convalidate. Tipo di evento inferred
	Fattura rifiutata	Indica che un approvatore ha rifiutato la fattura, interrompendo il processo e rinviandola generalmente per la correzione. Il motore Workflow registra esplicitamente questo evento di rifiuto.
Perché è importante Il monitoraggio dei rifiuti aiuta a quantificare le rilavorazioni e a individuare le cause più frequenti degli errori, come una codifica errata o violazioni delle policy. Supporta direttamente il KPI «Tasso di rifiuto delle fatture». Dove reperirlo È un evento esplicito registrato nelle tabelle della cronologia del Workflow, ad esempio WorkflowTrackingStatusTable, quando lo stato del Workflow cambia in «Rejected» o «Canceled». Acquisizione Timestamp dell’inserimento dello stato «Rejected» nella cronologia del Workflow. Tipo di evento explicit
	Pagamento pianificato	Questa attività si verifica quando una fattura contabilizzata viene inclusa in una proposta di pagamento o in un giornale dei pagamenti, ma prima dell’esecuzione del pagamento. È un’azione esplicita che crea una riga nel giornale dei pagamenti.
Perché è importante Segna il passaggio dalla contabilità fornitori alle attività di tesoreria. Analizzare questa fase può evidenziare i ritardi tra la contabilizzazione della fattura e l’avvio del pagamento. Dove reperirlo È un evento esplicito acquisito dalla creazione di una riga in un giornale dei pagamenti, LedgerJournalTrans, che regola la transazione fornitore contabilizzata. Acquisizione Timestamp di creazione della riga del giornale dei pagamenti che fa riferimento alla fattura. Tipo di evento explicit

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i dati da Microsoft Dynamics 365

Passaggi

Accesso all’area di lavoro Data Management: acceda a Microsoft Dynamics 365 Finance. Utilizzi la barra di ricerca per trovare e aprire l’area di lavoro Data management.
Creazione di un nuovo progetto di esportazione: nell’area di lavoro, selezioni il riquadro Export per creare un nuovo progetto di esportazione dei dati. Assegni al progetto un nome significativo, ad esempio ProcessMind_Invoice_Processing_Export.
Definizione del 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à.
Aggiunta delle entità dati richieste: acceda alla sezione Selected entities e faccia clic su Add entity. Cerchi e aggiunga una alla volta le seguenti entità principali. Dovrà specificare il formato dati di destinazione per ciascuna.
- VendInvoiceInfoTableEntity (intestazione della fattura fornitore)
- VendInvoiceTransEntity (righe della fattura fornitore)
- VendInvoiceRegisterHeaderEntity (intestazione del giornale del registro fatture)
- WorkflowTrackingStatusTableEntity (cronologia del flusso di lavoro)
- AccountingDistributionEntity (distribuzioni di contabilità generale)
- VendInvoiceJour (fatture fornitore registrate)
- VendTrans (transazioni fornitore, per i blocchi dei pagamenti)
- LedgerJournalTransVendPaymEntity (righe del giornale dei pagamenti al fornitore)
- VendSettlement (transazioni di regolamento del fornitore)
Applicazione dei filtri: per ogni entità è fondamentale applicare filtri per limitare l’ambito dei dati. Selezioni un’entità e faccia clic su Filtro. Come minimo, applichi il filtro Company (entità giuridica) e un intervallo di date specifico su un campo pertinente, come CREATEDDATETIME o INVOICEDATE. Per l’analisi iniziale è tipico utilizzare gli ultimi 3-6 mesi.
Configurazione delle mappature delle entità: per ogni entità, riveda la mappatura dall’origine alla destinazione. Verifichi che nell’esportazione siano inclusi tutti i campi richiesti per l’Event Log finale. In genere, in questa fase non sono necessarie modifiche complesse alle mappature.
Esecuzione del processo di esportazione: dopo aver aggiunto e filtrato tutte le entità, faccia clic su Export nel riquadro delle azioni per avviare il processo. Può eseguirlo immediatamente oppure pianificarlo negli orari di minore utilizzo per ridurre il carico sul sistema.
Download dei dati esportati: dopo il completamento corretto del processo, apra la cronologia dei processi. Da qui potrà scaricare il pacchetto di dati esportati, che conterrà file separati per ciascuna entità dati.
Trasformazione dei dati in un Event Log: i file esportati sono istantanee delle entità, non un Event Log consolidato. Dovrà utilizzare uno strumento esterno, come un database, uno script Python o Power Query, per elaborare e combinare questi file. La query concettuale nella sezione query fornisce la logica completa per questa trasformazione.
Esecuzione della 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 attività aziendale.
Finalizzazione e caricamento: 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: il cuore della configurazione consiste nel selezionare l'insieme corretto di entità per coprire l'intero ciclo di vita della fattura. Tra le entità principali figurano VendInvoiceInfoTableEntity, VendInvoiceJour e WorkflowTrackingStatusTableEntity.
Formato dei dati esportati: selezioni CSV come formato dati di destinazione, così da semplificare le successive fasi di elaborazione.
Filtro per azienda: è fondamentale filtrare ogni entità dati in base alla specifica entità giuridica (Company) analizzata, per evitare di acquisire dati non pertinenti.
Filtro per intervallo di date: applichi un intervallo di date coerente a tutte le entità pertinenti, come VendInvoiceInfoTableEntity e VendInvoiceJour, sulla base delle date di creazione o registrazione. Inizi con un periodo recente, ad esempio gli ultimi 6 mesi, per gestire il volume dei dati.
Caricamento completo o incrementale: per la prima estrazione esegua un caricamento completo. Per gli aggiornamenti successivi, potrà configurare un'esportazione incrementale che acquisisca 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 analogo con autorizzazioni per accedere alle entità dati richieste.

a 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: configuri BYOD: verifichi che la funzionalità Bring Your Own Database sia configurata per il Suo ambiente Microsoft Dynamics 365 Finance and Operations. Ciò richiede la configurazione di un database Azure SQL e di D365 per esportarvi i dati.
Identifichi le entità dati: in D365, apra il Workspace Data management. Questa estrazione si basa sull'esportazione di entità dati specifiche. Verifichi che in un processo di esportazione destinato al database BYOD siano incluse 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.
Crei e pianifichi il processo di esportazione: nel Workspace Data management, crei un nuovo progetto di esportazione. Aggiunga al progetto le entità elencate sopra. Configuri come formato dati di destinazione il database BYOD. Imposti una pianificazione ricorrente, ad esempio giornaliera o oraria, per mantenere aggiornati i dati nel database BYOD.
Verifichi i dati in Azure SQL: si connetta al database Azure SQL utilizzando 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.
Prepari la query SQL: copi la query SQL fornita. La query è progettata per essere eseguita direttamente sulle tabelle create dal processo di esportazione BYOD nel database Azure SQL.
Si connetta ed esegua la query: apra una nuova finestra di query nel client SQL connesso a BYOD. Incolli nella finestra la query SQL copiata.
Imposti i parametri della query: individui le variabili segnaposto all'inizio dello script. Sostituisca {StartDate}, {EndDate} e {CompanyCode} 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';.
Esegua la query: esegua lo script SQL completo. La query raccoglierà e unirà i dati provenienti da più tabelle per creare un Event Log cronologico per ogni fattura.
Esamini i risultati: l'output sarà costituito da un'unica tabella contenente l'Event Log, con colonne per InvoiceNumber, ActivityName, EventTime e altri Attributi specificati. Esamini i risultati per verificare che siano corretti e completi.
Esporti l'Event Log: esporti i risultati della query in un file CSV. La maggior parte dei client SQL dispone di una funzione integrata per salvare i risultati in un file. Verifichi che il file sia salvato con codifica UTF-8.
Prepari il caricamento: prima di caricare il file in uno strumento di Process Mining, verifichi che il file CSV contenga esattamente le intestazioni specificate nella query (InvoiceNumber, ActivityName e così via). Non sono necessarie ulteriori trasformazioni della struttura del file.

Configurazione

Entità dati principali: l'estrazione si basa sull'esportazione in BYOD di diverse entità dati D365. Tra le entità 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. È consigliabile iniziare con un intervallo limitato, ad esempio 3-6 mesi di dati, per garantire prestazioni adeguate. Il filtro viene applicato alla data di registrazione o di creazione della fattura.
Filtro per codice azienda: il parametro @DataAreaId è fondamentale negli ambienti con più aziende. Applichi sempre il filtro a una specifica entità giuridica (Company Code), così da garantire il corretto contesto dei dati.
Frequenza di aggiornamento BYOD: la tempestività 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ò avere implicazioni sulle prestazioni e sui costi sia in D365 sia in Azure.
Prerequisiti: questo metodo richiede un abbonamento Azure attivo, un database Azure SQL predisposto e accesso di livello amministratore in D365 per configurare il Workspace Data management.

a 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

Configuri i prerequisiti: verifichi di avere Python 3.6 o una versione successiva installata nel sistema. Installi le librerie necessarie utilizzando pip: pip install pandas requests msal. Queste librerie servono rispettivamente per la manipolazione dei dati, l'invio di richieste HTTP all'API e la gestione dell'autenticazione tramite la piattaforma Microsoft Identity.
Registri un'applicazione in Azure Active Directory: per autenticarsi all'API Dynamics 365, dovrà registrare un'applicazione nel tenant Azure AD della Sua organizzazione. Crei una nuova App Registration, generi un client secret e annoti l'Application (client) ID, il Directory (tenant) ID e il valore del client secret.
Conceda le autorizzazioni API: nella nuova App Registration in Azure AD, apra API permissions. Aggiunga un'autorizzazione per 'Dynamics ERP' o 'Dynamics 365 Business Central', a seconda della licenza, e conceda l'autorizzazione delegata user_impersonation. Un amministratore dovrà concedere il consenso amministrativo per queste autorizzazioni.
Crei un utente applicativo in Dynamics 365: nell'ambiente Dynamics 365, apra System administration > Users > Users. Crei un nuovo utente e inserisca l'Application (client) ID dell'App Registration Azure nel campo Application ID. Assegni a questo utente i ruoli di sicurezza appropriati, ad esempio 'System administrator', oppure un ruolo più limitato che disponga dell'accesso in lettura a tutte le entità dati richieste.
Configuri 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, il tenant ID, il client ID, il client secret e il codice azienda (dataAreaId) da cui desidera estrarre i dati.
Imposti l'intervallo di date: modifichi le variabili START_DATE e END_DATE nello script per definire l'intervallo temporale dell'estrazione. È consigliabile iniziare con un intervallo più breve, ad esempio un mese, per testare lo script e verificare i risultati.
Esegua lo script: esegua lo script dalla riga di comando o dal terminale utilizzando il comando python extract_invoices.py. Lo script eseguirà l'autenticazione, interrogherà i diversi endpoint OData per ogni attività ed elaborerà i dati.
Monitori l'esecuzione: durante l'acquisizione dei dati per ciascuna attività, lo script visualizzerà messaggi di avanzamento nella console. L'operazione può richiedere tempo, a seconda dell'intervallo di date e del volume dei dati. Verifichi la presenza di eventuali messaggi di errore che possano indicare problemi di autenticazione o di accesso all'API.
Esamini il file di output: al termine dell'esecuzione, lo script genererà un file CSV denominato d365_invoice_event_log.csv nella stessa directory. Il file contiene l'Event Log consolidato.
Prepari il caricamento: apra il file CSV per verificarne la corretta formattazione. Controlli che tutte le colonne richieste (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) siano presenti e valorizzate. Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Autenticazione: lo script utilizza il flusso OAuth 2.0 client credentials. Dovrà configurare un'App Registration Azure AD e concederle le autorizzazioni API per Dynamics 365. In Dynamics 365 dovrà inoltre essere creato un utente applicativo con ruoli di sicurezza appropriati.
Endpoint API: l'URL di base dell'API OData di Dynamics 365 Finance and Operations. Il formato è generalmente 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 è consigliato un periodo di 3-6 mesi.
Filtro azienda: i dati devono essere filtrati in base a una specifica entità giuridica o azienda. A questo scopo, nello script si specifica dataAreaId nel filtro della query API; si tratta di una configurazione obbligatoria.
Principali entità dati: 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 significativo, potrebbero essere necessarie entità personalizzate.
Paginazione: lo script gestisce automaticamente le risposte paginate dell'API utilizzando la proprietà @odata.nextLink, così da recuperare tutti i record del periodo specificato.

a 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 dati relativi a fatture fornitore, righe delle fatture, distribuzioni contabili, ordini di acquisto, ricevute, Workflow, blocchi di pagamento, registrazioni contabili e giornali dei pagamenti. Poiché le implementazioni di Dynamics 365 possono differire, documenti gli oggetti di origine effettivi in un workbook di mappatura. Utilizzi segnaposto come [Your invoice register table] e [Your workflow event table] finché non saranno confermati gli oggetti specifici dell'ambiente.
In Power Platform, crei un Dataflow nel Workspace o nell'ambiente utilizzato per l'estrazione verso ProcessMind. Selezioni il connettore appropriato per la distribuzione Dynamics 365 e configuri la connessione utilizzando [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 origini relative a registro delle fatture, intestazione della fattura, righe della fattura, distribuzione contabile, risultato dell'abbinamento con l'ordine di acquisto o la ricevuta, cronologia del Workflow, cronologia dei blocchi di pagamento, transazione di registrazione, proposta di pagamento o riga del giornale dei pagamenti e liquidazione del pagamento. Prima di pubblicare il Dataflow, registri i nomi effettivi delle entità e delle colonne nel workbook di mappatura.
Applichi a ogni origine la finestra di estrazione concordata, utilizzando [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 una precisione sufficiente a ordinare gli eventi. Per EventTime utilizzi i timestamp del sistema di origine, non quelli di aggiornamento.
Crei una query di eventi 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ì com'è, pertanto non faccia affidamento su ProcessMind per dedurre le attività mancanti.
Colleghi ogni origine degli eventi al caso della fattura utilizzando InvoiceNumber. Quando un'origine utilizza una chiave interna della fattura, colleghi prima tale chiave all'intestazione o al registro della fattura e riporti InvoiceNumber come identificativo aziendale. Mantenga VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate ed EndTime quando disponibili. Utilizzi una mappatura documentata e specifica dell'ambiente per ogni colonna di origine.
Applichi condizioni specifiche per evento. La registrazione richiede la creazione di un record nel registro delle 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 il completamento delle distribuzioni contabili. Un abbinamento riuscito richiede un risultato Passed. Un abbinamento non riuscito richiede Failed o Discrepancy. La gestione della discrepanza richiede un successivo nuovo abbinamento riuscito o una sostituzione manuale documentata. L'invio al Workflow, l'approvazione e il rifiuto richiedono eventi espliciti del Workflow. Gli eventi di blocco del pagamento richiedono una modifica dello stato di blocco. La registrazione contabile, la pianificazione e l'esecuzione richiedono record espliciti di registrazione, giornale dei pagamenti o liquidazione.
Standardizzi i tipi e i valori dei dati. Imposti InvoiceNumber e ActivityName come testo, EventTime ed EndTime come datetime, InvoiceAmount come tipo numerico e PaymentDueDate come data o datetime secondo l'origine. Imposti SourceSystem su Microsoft Dynamics 365. Imposti LastDataUpdate sul timestamp di aggiornamento del Dataflow o sul timestamp di estrazione dell'origine, mantenendo lo stesso criterio per tutte le righe di un aggiornamento.
Rimuova le righe prive di InvoiceNumber o EventTime, salvo che un processo di eccezione approvato assegni un identificativo di caso stabile. Elimini i duplicati solo quando i record duplicati dell'origine rappresentano lo stesso evento, utilizzando ove disponibile l'identificativo dell'evento di origine. Non accorpi approvazioni, tentativi di abbinamento, blocchi o azioni di pagamento distinti e ripetuti.
Carichi l'output normalizzato nella destinazione configurata, ad esempio una destinazione dati 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 quando disponibili.
Aggiorni il Dataflow, esamini l'output e completi i controlli di convalida. Verifichi che tutti i 14 valori ActivityName siano presenti 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, come CSV o l'output del connettore configurato, quindi la carichi in ProcessMind o stabilisca la connessione utilizzando InvoiceNumber come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell'evento.

Configurazione

Mappatura delle origini: 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 siano identici tra Finance, Supply Chain Management, Dataverse, personalizzazioni o integrazioni.
Colonne di output obbligatorie: InvoiceNumber, ActivityName, EventTime, SourceSystem e LastDataUpdate devono essere valorizzate per ogni riga di evento accettata.
Colonne di output consigliate: VendorNumber, PurchaseOrderNumber, InvoiceAmount, User, InvoiceStatus, PaymentDueDate ed EndTime dovrebbero essere incluse quando l'origine le fornisce.
Intervallo di date: inizi con 3-6 mesi di cronologia. Estenda l'intervallo solo dopo aver convalidato le prestazioni della query e la completezza degli eventi. Utilizzi, ove supportati, limiti inclusivi per l'inizio ed esclusivi per la fine, così da evitare eventi duplicati tra un aggiornamento e l'altro.
Filtro per azienda o entità giuridica: applichi [Your company or legal entity filter] in modo coerente a tutte le entità di origine. Verifichi che le join non combinino fatture appartenenti a 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 questo filtro in base al sistema, senza presumere un valore specifico di Dynamics 365.
Filtri per stato: utilizzi i valori configurati per nuovo, registrato, pronto per l'elaborazione, Passed, Failed, Discrepancy, approvato, rifiutato, bloccato e sbloccato. Le etichette degli stati 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 indicata o il record di origine fornisce una prova affidabile. ProcessMind non deduce gli eventi dalle altre righe.
Selezione del timestamp: privilegi il timestamp dell'evento di origine. Utilizzi i timestamp di creazione, modifica, azione del Workflow, registrazione, 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 l'aggiornamento del Dataflow. Se la destinazione supporta l'aggiornamento incrementale, conservi separatamente il watermark di aggiornamento rispetto a EventTime.
Aggiornamento incrementale: utilizzi un watermark stabile dell'origine, come un timestamp di modifica o un identificativo dell'evento, e includa un periodo di sovrapposizione per acquisire gli eventi di Workflow, abbinamento e pagamento arrivati in ritardo. Elimini i duplicati utilizzando, ove disponibili, gli identificativi degli eventi di origine.
Prestazioni: filtri le entità di origine prima delle join, selezioni solo le colonne necessarie, eviti l'espansione senza restrizioni delle righe delle fatture e prepari separatamente le origini di grandi dimensioni. Utilizzi il query folding quando è supportato dal connettore. Partizioni gli intervalli di date estesi o utilizzi l'aggiornamento incrementale.
Chiavi di join: utilizzi InvoiceNumber solo quando è univoco all'interno dell'azienda o dell'entità giuridica selezionata. In caso contrario, utilizzi la chiave composita specifica dell'ambiente e riporti InvoiceNumber nell'output finale.
Prerequisiti: le autorizzazioni necessarie includono l'accesso ai dati Dynamics 365, alla cronologia del Workflow, ai dati di registrazione e pagamento e al Dataflow e alla destinazione Power Platform. Le licenze richieste e la disponibilità dei connettori dipendono dal tenant, dalla distribuzione 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 Power Query o nei file esportati.
Valute e importi: conservi la valuta dell'origine oppure aggiunga la colonna valuta specifica dell'ambiente se l'analisi finanziaria lo richiede. Non converta gli importi salvo che sia stata definita una regola di cambio approvata.

a 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 nel Process Mining e ottenere insight utili a elaborare le fatture in modo più rapido e accurato. Inizi oggi stesso a trasformare le Sue operazioni.

Torna alla guida al miglioramento Scarica il Template

Inizi oggi a ottimizzare Purchase to Pay - Elaborazione delle fatture

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

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Inizi in pochi minuti.

Il Suo Template dei dati per Purchase to Pay - Elaborazione delle fatture

Il Suo Template dei dati per Purchase to Pay - Elaborazione delle fatture

Purchase to Pay - Attributi dell’elaborazione delle fatture

Purchase to Pay - Attività di elaborazione delle fatture

Guide all'estrazione

Esportazione tramite il Data Management Framework di Dynamics 365

Passaggi

Configurazione

a Query di esempio sql

Query SQL diretta tramite Bring Your Own Database (BYOD)

Passaggi

Configurazione

a Query di esempio sql

Script Python tramite API REST OData di Dynamics 365

Passaggi

Configurazione

a Query di esempio python

Estrazione tramite Dataflow di Microsoft Power Platform

Passaggi

Configurazione

a Query di esempio sql

Pronto a iniziare?

Inizi oggi a ottimizzare Purchase to Pay - Elaborazione delle fatture

Il Suo Template dei dati per Purchase to Pay - Elaborazione delle fatture

Il Suo Template dei dati per Purchase to Pay - Elaborazione delle fatture

Purchase to Pay - Attributi dell’elaborazione delle fatture

Purchase to Pay - Attività di elaborazione delle fatture

Guide all'estrazione

Esportazione tramite il Data Management Framework di Dynamics 365

Passaggi

Configurazione

a Query di esempio sql

Query SQL diretta tramite Bring Your Own Database (BYOD)

Passaggi

Configurazione

a Query di esempio sql

Script Python tramite API REST OData di Dynamics 365

Passaggi

Configurazione

a Query di esempio python

Estrazione tramite Dataflow di Microsoft Power Platform

Passaggi

Configurazione

a Query di esempio sql

Pronto a iniziare?

Inizi oggi a ottimizzare Purchase to Pay - Elaborazione delle fatture

La Sua privacy è importante