> Miglioramento Continuo dei Processi > Acquisto al Pagamento Elaborazione Fatture > Microsoft Dynamics 365 > Template Dati

Il Suo Template Dati per il Processo Dal Ciclo Acquisto al Pagamento - Gestione Fatture

Microsoft Dynamics 365

← Torna alla Guida al Miglioramento

Acquisto al Pagamento - Attributi di Elaborazione Fatture (23) Acquisto al Pagamento - Attività di Elaborazione Fatture (14) Guide all'Estrazione (4)

Il Suo Template Dati per il Processo Dal Ciclo Acquisto al Pagamento - Gestione Fatture

Questo `template` fornisce una guida chiara per l'estrazione dei `data` essenziali necessari per analizzare il Suo processo di Acquisto al Pagamento - Elaborazione Fatture in Microsoft Dynamics 365. Delinea gli attributi cruciali da raccogliere, le attività chiave da monitorare e una guida pratica per l'estrazione dei `data`. Utilizzi questa risorsa per assicurarsi di raccogliere tutte le informazioni necessarie per un'analisi e un'ottimizzazione complete del processo.

Attributi consigliati da raccogliere per un'analisi approfondita
Attività chiave da monitorare durante il ciclo di vita dell'elaborazione delle fatture
Guida all'estrazione dei dati da Microsoft Dynamics 365

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

Scarica Template

Acquisto al Pagamento - Attributi di Elaborazione Fatture

Questi sono i campi `data` consigliati da includere nel Suo `event log` per un'analisi completa del Suo processo di Acquisto al Pagamento - Elaborazione Fatture.

5 Obbligatorio 7 Consigliato 11 Facoltativo

	Nome	Descrizione
	Nome attività ActivityName	Il nome dello specifico `event` aziendale o attività che si è verificato in un determinato momento all'interno del ciclo di vita dell'elaborazione delle fatture.
Descrizione Il Nome Attività descrive un passaggio specifico o un cambiamento di stato nel processo di fatturazione, come 'Fattura Registrata', 'Fattura Inviata per Approvazione' o 'Pagamento Eseguito'. Questo `data` è cruciale per costruire la mappa di processo e comprendere la sequenza degli `event`. Analizzare questo attributo rivela il flusso di processo, identifica i percorsi comuni ed evidenzia deviazioni o `bottleneck`. Viene utilizzato per calcolare i tempi di ciclo tra le attività, come la durata dall'approvazione alla registrazione, e per misurare la frequenza di `event` specifici come rifiuti o blocchi di pagamento. Perché è importante Definisce i passaggi nella mappa di processo, consentendo la visualizzazione del flusso di processo e l'analisi delle transizioni tra le diverse attività. Dove trovare Questo attributo è tipicamente derivato da una combinazione di campi di stato, tipi di transazione o voci di `change log` all'interno di varie tabelle di Dynamics 365 relative all'elaborazione delle fatture. Esempi Fattura Inviata per ApprovazioneDiscrepanza Matching TrovataPagamento Eseguito
	Numero fattura InvoiceNumber	L'identificatore unico per ogni fattura fornitore, che serve come ID del `case` primario per tracciarne il ciclo di vita.
Descrizione Il Numero Fattura è la chiave unica che collega tutte le attività associate a una singola fattura fornitore. Consente la tracciatura end-to-end del percorso della fattura, dal ricevimento e registrazione attraverso il matching, l'approvazione e il pagamento finale. Nell'analisi di `Process Mining`, questo attributo è fondamentale. Definisce il `case`, consentendo la ricostruzione del flusso di processo di ogni fattura. Ciò permette il calcolo dei tempi di ciclo totali, l'identificazione delle varianti di processo e l'analisi delle caratteristiche e degli esiti specifici della fattura. Perché è importante Questo è l'ID del `Case` essenziale che collega tutti gli `event` correlati, rendendo possibile analizzare l'intero ciclo di vita di ogni singola fattura. Dove trovare Questo si trova tipicamente nella tabella principale delle fatture fornitore, come VendInvoiceInfoTable, campo Num. Esempi INV-10056773245-AUS-001-98432
	Timestamp Evento EventTime	Il timestamp preciso che indica quando si è verificata un'attività o un evento specifico.
Descrizione Event Time, o il timestamp, registra la data e l'ora esatte in cui un'attività ha avuto luogo. Questo è un componente critico dell'event log, fornendo la sequenza temporale necessaria per ordinare correttamente le attività e calcolare le durate. Nell'analisi, questo timestamp è la base per tutte le metriche relative al tempo. Viene utilizzato per calcolare la durata delle attività, il tempo di ciclo tra diversi passaggi (ad esempio, il tempo di approvazione) e il tempo totale di elaborazione end-to-end per ogni fattura. Permette anche l'analisi delle tendenze nel tempo. Perché è importante Questo `timestamp` è essenziale per ordinare gli `event`, calcolare tutti i tempi di ciclo e le durate, e identificare i `bottleneck` di processo. Dove trovare Questo proviene da vari campi `data`/ora attraverso più tabelle, come i campi createdDateTime o modifiedDateTime in tabelle come VendInvoiceInfoTable, VendTrans o tabelle di cronologia del `workflow`. Esempi 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Sistema di Origine SourceSystem	Il sistema sorgente da cui sono stati estratti i dati degli eventi.
Descrizione Questo attributo identifica l'applicazione sorgente da cui hanno avuto origine i `data` dell'attività. Per questo processo, sarà tipicamente 'Microsoft Dynamics 365'. In ambienti con sistemi multipli, come una soluzione OCR esterna o di acquisizione, questo campo aiuta a differenziare dove si verifica ogni passaggio del processo. Assicura che la `data lineage` sia chiara e aiuta nella risoluzione dei problemi di estrazione dei `data`. Perché è importante Fornisce un contesto cruciale sull'origine dei `data`, importante per la convalida dei `data` e per comprendere il panorama dei sistemi del processo. Dove trovare Questo è un valore statico, 'Microsoft Dynamics 365', aggiunto durante la trasformazione dei `data` per etichettare l'origine del `dataset`. Esempi Microsoft Dynamics 365
	Ultimo `Data Update` LastDataUpdate	Il `timestamp` che indica l'ultima volta che i `data` per questo processo sono stati aggiornati dal sistema sorgente.
Descrizione Questo attributo registra quando il `dataset` è stato estratto e aggiornato l'ultima volta da Microsoft Dynamics 365. È tipicamente lo stesso per tutti i record all'interno di un singolo caricamento di `data`. Questa informazione è vitale per gli utenti al fine di comprendere l'attualità dei `data` che stanno analizzando. Fornisce contesto su quanto siano attuali gli `insight` di processo ed è essenziale per gestire i programmi di aggiornamento dei `data` e convalidare le `data pipeline`. Perché è importante Informa gli utenti sulla tempestività dei dati, assicurando che sappiano quanto sia recente l'analisi e quando è previsto il prossimo aggiornamento dei dati. Dove trovare Questo `timestamp` è generato e impresso sul `dataset` dal processo di estrazione `data` o ETL al momento dell'esecuzione. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Data Scadenza Pagamento PaymentDueDate	La data entro la quale la fattura dovrebbe essere pagata secondo i termini di pagamento concordati.
Descrizione La Data di Scadenza Pagamento è calcolata in base alla data della fattura e ai termini di pagamento del fornitore. Rappresenta la scadenza contrattuale per il pagamento. Questa data è critica per misurare le performance finanziarie e la gestione delle relazioni con i fornitori. È la linea di base utilizzata per calcolare il KPI 'Tasso di Pagamento Puntuale' confrontandola con la data effettiva di 'Pagamento Eseguito'. Analizzare questo aiuta a identificare problemi sistemici che causano ritardi nei pagamenti, che possono portare a relazioni danneggiate con i fornitori o a sconti per pagamenti anticipati persi. Perché è importante Questo è il `benchmark` per misurare le performance di pagamento puntuale, un KPI chiave per la salute finanziaria e le relazioni con i fornitori. Dove trovare Questa `data` è spesso calcolata dal sistema e memorizzata nella tabella delle transazioni del fornitore, come VendTrans, in base alla `data` della fattura e ai termini di pagamento. Esempi 2023-05-152023-06-302023-07-20
	Importo Fattura InvoiceAmount	Il valore monetario totale della fattura.
Descrizione Questo attributo rappresenta l'importo totale dovuto come indicato sulla fattura del fornitore. È un punto `data` finanziario fondamentale per ogni `case`. L'Importo Fattura è ampiamente utilizzato per la segmentazione e l'analisi. Può rivelare se le fatture di alto valore seguono un processo di approvazione diverso e più rigoroso o se richiedono più tempo per essere elaborate. Viene anche utilizzato nelle `dashboard` per analizzare i volumi delle fatture per valore e può essere aggregato per comprendere la spesa totale sotto analisi. Perché è importante Consente analisi basate sul valore finanziario, aiutando a prioritizzare gli sforzi di miglioramento dei processi sulle fatture di alto valore e a comprendere i driver di costo. Dove trovare Trovato nella tabella dell'intestazione fattura, ad esempio, VendInvoiceInfoTable, in un campo come InvoiceAmount o Amount. Esempi 1500.00250.7512500.50
	Numero del fornitore VendorNumber	L'identificatore unico per il fornitore che ha inviato la fattura.
Descrizione Il Numero Fornitore è il codice che identifica in modo univoco un fornitore nei `master data`. Collega la transazione della fattura a un fornitore specifico, consentendo un'analisi incentrata sul fornitore. Questo attributo è essenziale per segmentare i `data` di processo per fornitore. Aiuta a rispondere a domande come 'Quali fornitori hanno i tempi di approvazione più lunghi?' o 'Le discrepanze di matching sono più comuni con alcuni fornitori?'. L'analisi delle performance per fornitore può rivelare opportunità di collaborazione con i fornitori e di miglioramento del processo. Perché è importante Consente il filtraggio e l'analisi delle cause profonde per fornitore, aiutando a identificare problemi di performance o modelli legati a fornitori specifici. Dove trovare Questo si trova tipicamente nell'intestazione della tabella delle fatture fornitore, come VendInvoiceInfoTable, collegato ai `master data` principali del fornitore in VendTable. Esempi V-1001V-2050V-8342
	Numero Ordine d'Acquisto PurchaseOrderNumber	L'identificatore dell'Ordine di Acquisto (PO) a cui la fattura è correlata.
Descrizione Il Numero Ordine di Acquisto collega una fattura al documento di approvvigionamento originale. Questo è critico per i processi che coinvolgono il matching a 2 o 3 vie tra la fattura, il PO e il ricevimento merce. Questo attributo consente l'analisi delle fatture con PO rispetto a quelle senza PO, che spesso seguono percorsi di processo diversi. È fondamentale per comprendere l'efficacia del processo di matching, investigare le discrepanze di matching e misurare il tasso di elaborazione straight-through per le fatture con PO. Perché è importante Distingue le fatture con ordine di acquisto (PO) da quelle senza PO, che è un fattore chiave di variazione del processo ed è cruciale per l'analisi del matching. Dove trovare Situato nella tabella di 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 `event` è stato completato.
Descrizione L'End Time registra quando un'attività è stata conclusa. Se combinato con lo Start Time (`EventTime`), consente il calcolo preciso di quanto tempo ha richiesto ogni singolo passaggio per essere completato. Questo attributo è essenziale per calcolare il 'ProcessingTime' per ogni attività, una metrica chiave per l'analisi delle performance. Aiuta a individuare esattamente quali passaggi nel processo stanno consumando più tempo, consentendo sforzi di miglioramento mirati. Ad esempio, può misurare la durata esatta di un passaggio di codifica manuale o di approvazione. Perché è importante Consente il calcolo diretto dei tempi di elaborazione delle attività, fondamentale per identificare i passaggi più dispendiosi in termini di tempo nel processo. Dove trovare Come StartTime, questo `data` proviene da vari campi `data`/ora. Per alcune attività, potrebbe essere lo StartTime dell'attività successiva. In altri casi, potrebbe essere un `timestamp` specifico di 'completamento'. Esempi 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Stato Fattura InvoiceStatus	Lo stato attuale della fattura al momento dell'estrazione dei `data`.
Descrizione Lo Stato Fattura indica lo stato attuale di una fattura all'interno del suo ciclo di vita, come 'In attesa di Approvazione', 'Approvata', 'Registrata' o 'Pagata'. Questo fornisce un'istantanea dell'avanzamento della fattura. Questo attributo è utilizzato principalmente per creare `dashboard` operativi che mostrano il carico di lavoro attuale e l'arretrato. Aiuta i manager a capire quante fatture si trovano in ogni fase del processo, supportando l'allocazione delle risorse e il monitoraggio operativo. È fondamentale per la `dashboard` 'Invoice Processing Throughput & Status'. Perché è importante Fornisce una visione dello stato attuale di tutte le fatture, essenziale per il monitoraggio operativo, la gestione del carico di lavoro e l'identificazione degli attuali `bottleneck`. Dove trovare Questo è tipicamente derivato dai campi di stato sulla 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 un passaggio di processo specifico. Per i passaggi automatizzati, questo potrebbe essere un account di sistema o di servizio. Analizzare il processo per utente aiuta a comprendere la distribuzione del carico di lavoro, a identificare le esigenze di formazione e a confrontare le performance tra individui o team. È cruciale per analizzare i cicli di rilavorazione, dove il lavoro viene passato avanti e indietro tra gli utenti, e per comprendere le variazioni nel modo in cui diversi utenti completano la stessa attività. Perché è importante Permette l'analisi delle performance e del carico di lavoro per utente o team, e aiuta a identificare i livelli di automazione e le fonti di rilavorazione. Dove trovare Proveniente dai campi ID utente nelle tabelle di transazione o di cronologia del `workflow`, come i campi createdby o modifiedby. Queste informazioni potrebbero trovarsi nelle tabelle di tracciamento del `workflow`. Esempi j.doea.smithAX_Admin
	Codice Società CompanyCode	L'identificatore per l'entità legale o l'azienda all'interno dell'organizzazione che elabora la fattura.
Descrizione Il Codice Società rappresenta l'entità legale specifica finanziariamente responsabile della fattura. In un'organizzazione multi-società, questo è un punto `data` critico per la segmentazione finanziaria. Questo attributo consente di filtrare o confrontare l'analisi di processo tra diverse entità legali. Può rivelare se le performance del processo, le `policy` o i `bottleneck` sono specifici di determinate società all'interno del gruppo, supportando iniziative di miglioramento del processo localizzate. Perché è importante Consente di segmentare l'analisi del processo per entità legale, aspetto cruciale per le grandi organizzazioni multi-aziendali. Dove trovare Questo è un campo standard nella maggior parte delle tabelle finanziarie di Dynamics 365, spesso chiamato DataAreaId. Esempi USMFDEMFGBSI
	Dipartimento Department	Il centro di costo o reparto a cui sono allocati i costi della fattura.
Descrizione Il Reparto identifica l'unità di business o il centro di costo responsabile della spesa sulla fattura. Questo viene solitamente determinato durante l'attività di codifica della fattura. Analizzare il processo per reparto è fondamentale per comprendere le differenze dipartimentali in termini di spesa, tempi di approvazione e conformità. Aiuta a identificare quali reparti presentano il maggior numero di eccezioni di fattura o i cicli di approvazione più lunghi, fornendo una base per comunicazioni e formazione mirate. Perché è importante Consente l'analisi dei costi e dei processi per dipartimento, evidenziando le variazioni di prestazioni e conformità all'interno dell'organizzazione. Dove trovare Proveniente dalle dimensioni finanziarie collegate alle righe o all'intestazione della fattura. Ciò richiede l'interrogazione delle strutture `data` relative alle dimensioni. Esempi VenditeMarketingOperazioni IT
	È Automatizzato IsAutomated	Un flag che indica se un'attività è stata eseguita automaticamente dal sistema o da un utente umano.
Descrizione Questo attributo booleano (`true`/`false`) distingue tra `event` eseguiti dal sistema e attività utente manuali. Ad esempio, un passaggio di matching della fattura potrebbe essere automatizzato, mentre la gestione delle discrepanze è manuale. Analizzare questo attributo è fondamentale per comprendere il livello di automazione nel processo. Aiuta a misurare il successo delle iniziative di automazione, identifica i `bottleneck` manuali rimanenti ed evidenzia le opportunità per ulteriore automazione per migliorare l'efficienza e ridurre gli errori. Perché è importante Aiuta a misurare il livello di automazione nel processo, identificando i colli di bottiglia manuali e le opportunità di guadagni in efficienza. Dove trovare Questo è tipicamente derivato in base all'attributo 'Utente'. Se l'utente è un account di sistema o di servizio noto, questo flag è impostato su `true`. Esempi truefalse
	È Pagamento Puntuale IsOnTimePayment	Un flag calcolato che indica se una fattura è stata pagata alla data di scadenza o prima.
Descrizione Questo attributo booleano è derivato confrontando il `timestamp` dell'attività 'Pagamento Eseguito' con la 'Data di Scadenza Pagamento'. Se la `data` di pagamento è inferiore o uguale alla `data` di scadenza, il valore è `true`, altrimenti è `false`. Questo attributo supporta direttamente il KPI 'Tasso di Pagamento Puntuale' e la `dashboard` 'Conformità Termini di Pagamento'. Semplifica l'analisi fornendo un chiaro risultato binario per ogni fattura, rendendo facile filtrare i pagamenti in ritardo e indagarne le cause principali per fornitore, reparto o paese. Perché è importante Misura direttamente la conformità ai termini di pagamento, semplificando il calcolo del KPI del tasso di pagamento puntuale e le analisi correlate. Dove trovare Questo attributo è calcolato nel livello di trasformazione dei `data`. La logica è: (`Timestamp` dell'attività 'Pagamento Eseguito') <= (Data di Scadenza Pagamento). Esempi truefalse
	Motivo Blocco Pagamento PaymentBlockReason	Il codice motivo che spiega perché è stato applicato un blocco di pagamento a una fattura.
Descrizione Un blocco di pagamento impedisce il pagamento di una fattura. Questo attributo cattura il motivo del blocco, che di solito è un codice standardizzato selezionato da un utente, come 'Spese contestate' o 'In attesa di ricezione merce'. Questo attributo è essenziale per la dashboard 'Frequenza e Durata dei Blocchi di Pagamento'. L'analisi delle ragioni più comuni dei blocchi di pagamento aiuta a identificare i problemi sottostanti nel processo P2P. La risoluzione di queste cause profonde può ridurre significativamente i ritardi nei pagamenti e migliorare le relazioni con i fornitori. Perché è importante Spiega perché i pagamenti vengono intenzionalmente ritardati, aiutando a identificare e risolvere i problemi a monte che causano i blocchi di pagamento. Dove trovare Questo è tipicamente un campo sul record della transazione o della fattura del fornitore, spesso correlato allo stato di blocco del pagamento. Cerchi in tabelle come VendTrans. Esempi Contestazione di qualitàIn attesa di nota di creditoBlocco manuale
	Motivo del Rigetto RejectionReason	Il motivo fornito da un approvatore per il rifiuto di una fattura.
Descrizione Quando una fattura viene rifiutata durante il processo di approvazione, il responsabile solitamente indica una motivazione. Questo attributo registra tale spiegazione, che può essere un codice predefinito o un testo libero. È un attributo fondamentale per la dashboard 'Analisi Rifiuti Fatture'. Fornisce le informazioni qualitative necessarie per comprendere le cause profonde dei rifiuti, come 'Numero Ordine Errato', 'Fattura Duplicata' o 'Disallineamento Prezzi'. Analizzare queste ragioni aiuta a dare priorità alle azioni per ridurre il tasso di rifiuto. Perché è importante Fornisce un `insight` diretto sul motivo per cui le fatture vengono rifiutate, consentendo azioni mirate per ridurre le rilavorazioni e migliorare i tassi di 'first-time-right'. Dove trovare Tipicamente trovato nei commenti o nei `log` di cronologia delle tabelle di elaborazione del `workflow`. Esempi Quantità errataFattura duplicataLimite di approvazione superato
	Tempo di ciclo totale TotalCycleTime	La durata totale end-to-end per l'elaborazione di una singola fattura, dal ricevimento al pagamento.
Descrizione Il Tempo di Ciclo Totale misura l'intera durata che una fattura trascorre nel processo. Viene calcolato come la differenza di tempo tra la primissima attività (ad es., 'Fattura Registrata') e l'ultimissima attività (ad es., 'Pagamento Eseguito') per un dato numero di fattura. Questo è un KPI primario per misurare l'efficienza complessiva del processo. Fornisce una visione di alto livello delle performance ed è utilizzato nella `dashboard` 'Tempo di Ciclo End-to-End della Fattura'. Analizzare le tendenze di questa metrica e segmentarla per attributi come fornitore o importo aiuta a identificare ampie opportunità di miglioramento. Perché è importante Rappresenta il KPI chiave di alto livello per la velocità e l'efficienza complessiva del processo, riassumendo le performance per ogni fattura. Dove trovare Questo è calcolato a livello di `case` all'interno dello strumento di `Process Mining` o durante la preparazione dei `data`. È la differenza di tempo tra il `timestamp` del primo e dell'ultimo `event` per ogni CaseId. Esempi P15DP22DT5H30MP7D
	Tempo di Elaborazione ProcessingTime	La durata di una singola attività, calcolata come la differenza tra il suo tempo di fine e il suo tempo di inizio.
Descrizione Il Tempo di Elaborazione misura il tempo attivo dedicato a una specifica attività. Viene calcolato sottraendo lo StartTime di un `event` dal suo EndTime. Questo è anche definito come durata dell'attività. Questa metrica è fondamentale per l'analisi delle performance. Aiuta a identificare quali attività specifiche sono le più dispendiose in termini di tempo, a differenza dei tempi di attesa tra le attività. Ciò consente miglioramenti mirati, come fornire una migliore formazione per accelerare la codifica manuale o ottimizzare un passaggio di sistema che sta rallentando. Perché è importante Misura la durata effettiva del lavoro delle attività, aiutando a individuare le attività inefficienti mature per l'ottimizzazione o l'automazione. Dove trovare Questo non è un campo nel sistema sorgente. Viene calcolato durante la trasformazione dei `data` utilizzando la formula: EndTime - StartTime. Esempi PT1H30MP2DT4HPT5M15S
	Termini di Pagamento PaymentTerms	L'accordo sui termini di pagamento con il fornitore, come 'Net 30' o '2% 10, Net 30'.
Descrizione I Termini di Pagamento definiscono le condizioni concordate per il pagamento al fornitore, inclusi i tempi e gli eventuali sconti. Queste informazioni provengono solitamente dai `master data` del fornitore o dall'ordine di acquisto. Questo attributo fornisce un contesto cruciale per la Data di Scadenza del Pagamento e il KPI del Tasso di Pagamento Puntuale. Analizzare se determinati termini di pagamento sono correlati a pagamenti in ritardo può rivelare sfide operative. Aiuta anche nella pianificazione finanziaria e nella gestione efficace del capitale circolante. Perché è importante Fornisce contesto per le date di scadenza dei pagamenti e aiuta ad analizzare l'impatto finanziario delle tempistiche di pagamento e dei tassi di cattura degli sconti. Dove trovare Queste informazioni sono memorizzate nei `master data` del fornitore (VendTable) e copiate in tabelle di transazione come VendInvoiceInfoTable. Esempi Netto 30Netto 602% 10, Netto 30
	Tipo di Discrepanza MatchingDiscrepancyType	Categorizza il tipo di non corrispondenza rilevato durante il processo di associazione fattura e ordine di acquisto.
Descrizione Quando si verifica una discrepanza durante il matching a 2 o 3 vie, questo attributo specifica la natura del problema, ad esempio, 'Discrepanza di Prezzo', 'Discrepanza di Quantità' o 'Ricevimento Merce Mancante'. Questi `data` sono centrali per la `dashboard` 'Tempo di Risoluzione delle Discrepanze di Matching'. Analizzando la frequenza dei diversi tipi di discrepanza, l'azienda può identificare le cause radice dei fallimenti di matching. Ad esempio, frequenti discrepanze di prezzo possono indicare problemi con i `master data` obsoleti, mentre le discrepanze di quantità potrebbero indicare problemi di spedizione. Perché è importante Categorizza i fallimenti di matching, permettendo un'analisi delle cause radice per ridurre il tasso di discrepanze e migliorare l'elaborazione straight-through. Dove trovare Questo può essere memorizzato in una tabella dedicata di `log` di matching o eccezione, oppure potrebbe dover essere derivato da messaggi di stato o commenti del `workflow`. Esempi Discrepanza PrezzoDiscrepanza QuantitàMancato Ricevimento Merce
	Valuta Fattura InvoiceCurrency	Il codice valuta per l'importo della fattura (es. USD, EUR).
Descrizione La Valuta della Fattura specifica la valuta in cui è denominato l'importo della fattura. Questo è importante per le organizzazioni multinazionali che operano con fornitori di diversi paesi. Questo attributo fornisce il contesto necessario per l'Importo della Fattura ed è utilizzato per il filtraggio e il reporting, specialmente nelle operazioni globali. Assicura che i valori finanziari siano interpretati correttamente e consente analisi specifiche per valuta o la conversione a una valuta di reporting standard. Perché è importante Fornisce un contesto essenziale per gli importi finanziari, consentendo un'interpretazione e un'analisi accurate dei valori delle fatture in diverse regioni. Dove trovare Situato nella tabella di intestazione della fattura, accanto all'importo della fattura, ad esempio, nel campo CurrencyCode della tabella VendInvoiceInfoTable. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Acquisto al Pagamento - Attività di Elaborazione Fatture

Questi sono i passaggi chiave del processo e le tappe fondamentali da acquisire nel tuo log eventi per una scoperta e un'analisi accurate del tuo workflow di elaborazione delle fatture.

6 Consigliato 8 Facoltativo

	Activity	Descrizione
	Fattura Approvata	Rappresenta l'approvazione finale e riuscita della fattura all'interno del `workflow`, autorizzandola per la registrazione e il pagamento. Questo è un `event` esplicito registrato dal `workflow engine` al completamento.
Perché è importante Questa è una pietra miliare critica che conclude il processo di approvazione. Il tempo da 'Fattura Inviata per Approvazione' a questo `event` è una misura chiave dell'efficienza dell'approvazione e aiuta a identificare i `bottleneck`. Dove trovare Questo è un `event` esplicito registrato nelle tabelle di cronologia del `workflow` (ad es., WorkflowTrackingStatusTable) quando lo stato del `workflow` cambia in 'Approvato'. Acquisisci `Timestamp` della voce di stato 'Approvato' nella cronologia del `workflow`. Tipo di evento explicit
	Fattura Corrispondente all'Ordine di Acquisto	Rappresenta il completamento riuscito del processo di matching, dove i dettagli della fattura si allineano con l'ordine di acquisto e le informazioni di ricevimento merce. Questo `event` si inferisce quando lo stato di matching della fattura viene aggiornato a 'Superato'.
Perché è importante Il matching riuscito è una pietra miliare chiave per le fatture con PO, confermando la validità dell'addebito prima del pagamento. È essenziale per il monitoraggio dell'efficienza del matching e dei tassi di automazione. Dove trovare Deducibile dall'aggiornamento del campo dello stato di corrispondenza sull'intestazione o sulle righe della fattura fornitore (ad es., VendInvoiceInfoTable) a un valore 'Superato' o 'Corrispondente con successo'. Acquisisci `Timestamp` del cambio di stato a 'Superato' nei dettagli di convalida del matching della fattura. Tipo di evento inferred
	Fattura Inviata per Approvazione	Questa attività segna l'invio formale di una fattura in un `workflow` per revisione e approvazione. Il `workflow engine` di Dynamics 365 registra esplicitamente questo `event` di invio.
Perché è importante Questo è il punto di partenza per misurare l'intero ciclo di approvazione. Aiuta a identificare quanto tempo le fatture attendono prima che il processo di approvazione inizi e funge da trigger per i KPI relativi all'approvazione. Dove trovare Questo è un `event` esplicito registrato nelle tabelle di cronologia del `workflow` (ad es., WorkflowTrackingStatusTable) quando una fattura viene inviata a un `workflow`. Acquisisci Timestamp di creazione del record di invio del workflow nella cronologia del workflow. Tipo di evento explicit
	Fattura Registrata	Questa è la registrazione iniziale di una fattura nel sistema, creando un record segnaposto prima che i dettagli completi vengano elaborati. Questa attività viene catturata quando viene creato un nuovo record nel giornale del registro fatture fornitore.
Perché è importante Questa attività segna l'inizio ufficiale del ciclo di vita dell'elaborazione delle fatture. Analizzare il tempo da questo punto aiuta a misurare la durata totale dell'elaborazione e a identificare i ritardi iniziali. Dove trovare Questo è un `event` esplicito catturato dalla creazione di un record nel registro fatture fornitori, tipicamente nella tabella VendInvoiceRegisterJournalTable o in una tabella simile per fatture in sospeso. Acquisisci Timestamp di creazione del record nel giornale registro fatture fornitori. Tipo di evento explicit
	Fattura Registrata	Questo è l'`event` contabile formale in cui la fattura approvata viene registrata nel Conto Economico, creando una passività. Questo è un `event` transazionale esplicito nel sistema.
Perché è importante La registrazione è il passaggio finale prima del pagamento ed è un punto di controllo finanziario chiave. Il tempo da 'Fattura Approvata' a 'Fattura Registrata' misura l'efficienza dei passaggi contabili finali. Dove trovare Questo è un `event` esplicito catturato dalla creazione della transazione fornitore registrata in tabelle come VendTrans e nei record associati GeneralJournalEntry e LedgerEntry. Acquisisci Timestamp di creazione del record nella tabella delle transazioni fornitore (VendTrans). Tipo di evento explicit
	Pagamento Eseguito	Questa è l'attività finale, che rappresenta la registrazione del giornale di pagamento che crea il pagamento e salda la fattura. Questo è un `event` transazionale esplicito che chiude il ciclo di vita della fattura.
Perché è importante Questa attività segna la conclusione riuscita del processo da fattura a pagamento. È la base per misurare il 'Tasso di Pagamento Puntuale' e il tempo di ciclo totale end-to-end. Dove trovare Questo è un `event` esplicito catturato dalla registrazione del giornale di pagamento. Le informazioni di liquidazione sono registrate in tabelle come VendSettlement, collegando il pagamento alla fattura. Acquisisci `Timestamp` di registrazione del giornale di pagamento che salda la transazione del fornitore. Tipo di evento explicit
	Blocco Pagamento Impostato	Questa attività si verifica quando viene applicato un blocco a una fattura, impedendone il pagamento. Questo viene catturato da una modifica nel campo dello stato di blocco o di sospensione del pagamento nel record della fattura registrata.
Perché è importante I blocchi di pagamento sono una causa primaria di ritardi nei pagamenti. Analizzare quando e perché vengono impostati è cruciale per migliorare le performance di pagamento puntuale e le relazioni con i fornitori. Dove trovare Deducibile da una modifica al campo di sospensione o blocco del pagamento sulla transazione fornitore registrata (VendTrans). Il log delle modifiche può essere utilizzato per catturare il timestamp. Acquisisci `Timestamp` dell'aggiornamento che imposta il campo di blocco del pagamento sulla transazione del fornitore. Tipo di evento inferred
	Blocco Pagamento Rilasciato	Rappresenta la rimozione di un blocco di pagamento, consentendo alla fattura di procedere alla pianificazione del pagamento. Questo viene catturato quando il campo del blocco di pagamento viene azzerato o modificato a uno stato sbloccato.
Perché è importante Misura il tempo necessario per risolvere i problemi che causano i blocchi di pagamento. Lunghe durate tra l'impostazione e il rilascio di un blocco indicano processi di risoluzione dei problemi inefficienti. Dove trovare Deducibile da una modifica che annulla il campo di sospensione o blocco del pagamento sulla transazione fornitore registrata (VendTrans). Il log delle modifiche può fornire il timestamp. Acquisisci `Timestamp` dell'aggiornamento che cancella il campo di blocco del pagamento sulla transazione del fornitore. Tipo di evento inferred
	Dati Fattura Acquisiti	Rappresenta il completamento dell'inserimento `data` per la fattura, inclusi i dettagli di intestazione e riga, prima che venga inviata per matching o approvazione. Questo si inferisce spesso quando il record della fattura passa da uno stato 'nuovo' o 'registrato' a uno stato 'pronto per l'elaborazione'.
Perché è importante Il tracciamento di questa attività aiuta a misurare l'efficienza del processo di inserimento `data`, sia manuale che automatizzato (OCR). Ritardi qui possono propagarsi attraverso l'intero processo. Dove trovare Deducibile dalle modifiche di stato sul record della fattura fornitore in sospeso (ad es., VendInvoiceInfoTable). L'evento si verifica quando tutti i campi richiesti sono popolati e la fattura è pronta per il passaggio successivo. Acquisisci Rileva il cambiamento di stato sulla tabella delle fatture in sospeso che indica il completamento dell'inserimento dati. Tipo di evento inferred
	Discrepanza Matching Gestita	Segna la risoluzione di una discrepanza di matching precedentemente identificata, consentendo alla fattura di procedere. Questo si inferisce quando una fattura con stato di matching 'Fallito' viene ri-abbinata con successo o superata manualmente.
Perché è importante Questa attività conclude il sub-processo di risoluzione delle discrepanze. Il tempo tra 'Discrepanza Matching Trovata' e questo `event` è un KPI chiave per misurare l'efficienza della risoluzione. Dove trovare Deducibile da un evento di corrispondenza riuscito ('Fattura Corrispondente all'Ordine di Acquisto') che si verifica dopo un evento 'Discrepanza di Corrispondenza Trovata' per la stessa fattura. Acquisisci Identifichi un timestamp di stato di corrispondenza 'Superato' che segue un timestamp di stato 'Fallito'. Tipo di evento inferred
	Discrepanza Matching Trovata	Questa attività si verifica quando il processo di matching delle fatture fallisce a causa di disallineamenti tra la fattura, l'ordine di acquisto o il ricevimento merce. Viene catturata quando lo stato di matching della fattura viene impostato su 'Fallito' o 'Discrepanza'.
Perché è importante Identificare quando e perché si verificano le discrepanze è cruciale per il KPI 'Tasso di discrepanza di corrispondenza'. Questa attività segna l'inizio del processo di risoluzione, che è spesso una fonte di ritardi significativi. Dove trovare Deducibile dall'aggiornamento del campo dello stato di corrispondenza sulla fattura fornitore (ad es., VendInvoiceInfoTable) a un valore 'Fallito'. La ragione del fallimento è spesso anch'essa registrata. Acquisisci `Timestamp` del cambio di stato a 'Fallito' o 'Discrepanza' durante il matching. Tipo di evento inferred
	Fattura Codificata	Questa attività significa che le distribuzioni contabili del Conto Economico sono state assegnate alle righe della fattura. Viene tipicamente inferita dalla creazione o finalizzazione delle distribuzioni contabili collegate alla fattura.
Perché è importante La codifica è un passaggio critico per l'accuratezza finanziaria. Misurare il tempo impiegato per codificare le fatture aiuta a identificare i colli di bottiglia nel processo di revisione contabile e supporta il KPI 'Tempo medio da acquisizione dati a codifica'. Dove trovare Deducibile dalla creazione e validazione dei record nelle tabelle di distribuzione contabile (ad es., AccountingDistribution) associate alla fattura fornitore in sospeso. Acquisisci `Timestamp` di quando le distribuzioni contabili per la fattura vengono salvate e validate. Tipo di evento inferred
	Fattura Rifiutata	Indica che un approvatore ha rifiutato la fattura, interrompendo il processo e tipicamente rimandandola indietro per la correzione. Il workflow engine registra esplicitamente questo evento di rifiuto.
Perché è importante Il tracciamento dei rifiuti aiuta a quantificare le rilavorazioni e a identificare le ragioni comuni di fallimento, come codifiche errate o violazioni delle `policy`. Questo supporta direttamente il KPI 'Tasso di Rifiuto delle Fatture'. Dove trovare Questo è un `event` esplicito registrato nelle tabelle di cronologia del `workflow` (ad es., WorkflowTrackingStatusTable) quando lo stato del `workflow` cambia in 'Rifiutato' o 'Annullato'. Acquisisci `Timestamp` della voce di stato 'Rifiutato' nella cronologia del `workflow`. Tipo di evento explicit
	Pagamento Programmato	Questa attività si verifica quando una fattura registrata viene inclusa in una proposta di pagamento o in un giornale di pagamento, ma prima che il pagamento venga eseguito. È un'azione esplicita che crea una riga nel giornale di pagamento.
Perché è importante Questo segna il passaggio dalle operazioni di Contabilità Fornitori a quelle di Tesoreria. Analizzare questo passaggio può rivelare ritardi tra la registrazione della fattura e l'avvio del pagamento. Dove trovare Questo è un `event` esplicito catturato dalla creazione di una riga in un giornale di pagamento (LedgerJournalTrans) che salda la transazione del fornitore. Acquisisci Timestamp di creazione della riga del giornale di pagamento che fa riferimento alla fattura. Tipo di evento explicit

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i tuoi dati da Microsoft Dynamics 365

Fasi

Navigare all'Area di Lavoro Gestione Dati: Acceda a Microsoft Dynamics 365 Finance. Utilizzi la barra di ricerca per trovare e navigare all'area di lavoro Gestione dati.
Creare un Nuovo Progetto di Esportazione: All'interno dell'area di lavoro, selezioni il riquadro Esporta per creare un nuovo progetto di esportazione dati. Assegni un nome significativo al progetto, ad esempio ProcessMind_Invoice_Processing_Export.
Definire il Progetto Dati: Nella scheda Generale del nuovo progetto, specifichi il Formato dati. CSV è un formato comunemente usato e consigliato. Imposti altri parametri secondo necessità.
Aggiungere le Entità Dati Richieste: Vada alla sezione Entità selezionate e clicchi Aggiungi entità. Cerchi e aggiunga le seguenti entità principali una per una. Dovrà specificare il formato dati di destinazione per ciascuna.
- VendInvoiceInfoTableEntity (Intestazione fattura fornitore)
- VendInvoiceTransEntity (Righe fattura fornitore)
- VendInvoiceRegisterHeaderEntity (Intestazione registro fatture)
- WorkflowTrackingStatusTableEntity (Cronologia workflow)
- AccountingDistributionEntity (Distribuzioni GL)
- VendInvoiceJour (Fatture fornitore registrate)
- VendTrans (Transazioni fornitore, per blocchi di pagamento)
- LedgerJournalTransVendPaymEntity (Righe giornale pagamenti fornitore)
- VendSettlement (Transazioni di saldo fornitore)
Applicare i Filtri: Per ogni entità, è fondamentale applicare filtri per limitare l'ambito dei dati. Selezioni un'entità e clicchi Filtra. Al minimo, filtri per Company (Entità legale) e un intervallo di date specifico su un campo data rilevante come CREATEDDATETIME o INVOICEDATE. Un intervallo tipico per l'analisi iniziale è gli ultimi 3-6 mesi.
Configurare le Mappature delle Entità: Per ogni entità, esamini la mappatura sorgente-destinazione. Si assicuri che tutti i campi richiesti per l'event log finale siano inclusi nell'esportazione. Di solito non sono necessarie modifiche complesse alla mappatura in questa fase.
Eseguire il Job di Esportazione: Una volta aggiunte e filtrate tutte le entità, clicchi Esporta nel riquadro Azioni per avviare il job. Può eseguirlo immediatamente o pianificarlo per le ore non di punta per minimizzare il carico del sistema.
Scaricare i Dati Esportati: Dopo che il job di esportazione è stato completato con successo, navighi alla cronologia dei job. Da lì, può scaricare il pacchetto di dati esportato, che conterrà file separati per ogni entità dati.
Trasformare i Dati in un Event Log: I file esportati sono snapshot di entità, non un event log consolidato. Deve 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.
Eseguire la Logica di Trasformazione: Carichi i file CSV esportati nell'ambiente di trasformazione scelto. Esegua la query di trasformazione fornita, che unisce i dati di tutti i file sorgente per creare una singola tabella di event log con una riga per attività aziendale.
Finalizzare e Caricare: Esporti i dati trasformati finali in un singolo file CSV. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti, ad esempio InvoiceNumber, ActivityName, EventTime. Questo file è ora pronto per essere caricato su ProcessMind.

Configurazione

Entità Dati: Il fulcro della configurazione è la selezione del set corretto di entità per coprire il ciclo di vita delle fatture. Le entità chiave includono VendInvoiceInfoTableEntity, VendInvoiceJour e WorkflowTrackingStatusTableEntity.
Formato di Esportazione Dati: Selezioni CSV come formato dati di destinazione per una facile elaborazione nei passaggi di trasformazione successivi.
Filtro per Azienda: È fondamentale filtrare ogni entità dati per la specifica entità legale (Azienda) che sta analizzando, al fine di evitare di estrarre dati irrilevanti.
Filtro Intervallo di Date: Applichi un filtro di intervallo di date coerente a tutte le entità rilevanti, come VendInvoiceInfoTableEntity e VendInvoiceJour, basato sulle date di creazione o di registrazione. Inizi con un periodo recente, ad esempio gli ultimi 6 mesi, per gestire il volume dei dati.
Push Completo vs. Incrementale: Per l'estrazione iniziale, esegua un push completo. Per i successivi aggiornamenti, può configurare un'esportazione incrementale per recuperare solo i dati modificati dall'ultima esecuzione, riducendo il tempo di elaborazione.
Prerequisiti: L'utente che esegue l'esportazione deve avere i ruoli di sicurezza appropriati in Dynamics 365, tipicamente inclusi Data management administrator o un ruolo simile con permessi di accesso alle entità dati richieste.

a Query di Esempio config

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

Fasi

Prerequisito: Configurare BYOD: Si assicuri che la funzionalità Bring Your Own Database sia configurata per il Suo ambiente Microsoft Dynamics 365 Finance and Operations. Ciò implica l'impostazione di un database SQL di Azure e la configurazione di D365 per esportarvi i dati.
Identificare le Entità Dati: In D365, navighi all'area di lavoro Gestione dati. Il cuore di questa estrazione si basa sull'esportazione di specifiche entità dati. Si assicuri che le seguenti entità siano incluse in un job di esportazione mirato al Suo database BYOD: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements e Accounting distributions.
Creare e Pianificare il Job di Esportazione: Nell'area di lavoro Gestione dati, crei un nuovo progetto di esportazione. Aggiunga le entità sopra elencate al progetto. Configuri il formato dati di destinazione in modo che sia il Suo database BYOD. Imposti una pianificazione ricorrente per il job di esportazione, ad esempio giornaliera o oraria, per mantenere i dati nel Suo BYOD aggiornati.
Verificare i Dati in Azure SQL: Si connetta al Suo database SQL di Azure 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 siano popolate con i dati.
Preparare la Query SQL: Copi la query SQL fornita. Questa query è progettata per essere eseguita direttamente sulle tabelle create dal processo di esportazione BYOD nel Suo database SQL di Azure.
Connettersi ed Eseguire: Apra una nuova finestra di query nel Suo client SQL connesso al BYOD. Incolli la query SQL copiata nella finestra.
Impostare i Parametri della Query: Individui le variabili segnaposto nella parte superiore dello script. Sostituisca {StartDate}, {EndDate} e {CompanyCode} con la data di inizio, la data di fine e l'identificatore dell'entità legale desiderati, rispettivamente. Ad esempio, SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Eseguire la Query: Esegua lo script SQL completo. La query raccoglierà e unirà i dati da più tabelle per costruire un event log cronologico per ogni fattura.
Esaminare i Risultati: L'output sarà una singola tabella contenente l'event log con colonne per InvoiceNumber, ActivityName, EventTime e altri attributi specificati. Esamini i risultati per assicurarsi che appaiano corretti e completi.
Esportare l'Event Log: Esporti i risultati della query in un file CSV. La maggior parte dei client SQL ha una funzione integrata per salvare i risultati in un file. Si assicuri che il file sia salvato con codifica UTF-8.
Preparare per il Caricamento: Prima di caricare su uno strumento di Process Mining, confermi che il file CSV abbia le intestazioni esatte come specificato nella query (InvoiceNumber, ActivityName, ecc.). Non è necessaria alcuna ulteriore trasformazione della struttura del file.

Configurazione

Entità Dati Chiave: L'estrazione si basa su diverse entità dati di D365 che vengono esportate nel BYOD. Le entità critiche includono: VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution e VendTrans.
Filtro Intervallo di Date: La query fornita include i parametri @StartDate e @EndDate. Si consiglia di iniziare con un intervallo di date limitato, ad esempio 3-6 mesi di dati, per garantire le prestazioni. Il filtro viene applicato alla data di registrazione o di creazione della fattura.
Filtro Codice Azienda: Il parametro @DataAreaId è cruciale per ambienti multi-azienda. Filtri sempre per una specifica entità legale (Codice Azienda) per garantire che il contesto dei dati sia corretto.
Frequenza di Aggiornamento BYOD: La tempestività dei dati dipende interamente dalla pianificazione del job di esportazione di D365. Per un'analisi quasi in tempo reale, è richiesta un'alta frequenza (ad esempio, oraria), il che potrebbe avere implicazioni in termini di prestazioni e costi sia su D365 che su Azure.
Prerequisiti: Questo metodo richiede una sottoscrizione Azure attiva, un database SQL di Azure provisionato e un accesso a livello di amministratore in D365 per configurare l'area di lavoro Gestione dati.

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;

Fasi

Configurazione dei Prerequisiti: Si assicuri di avere Python 3.6 o versioni successive installato sul Suo sistema. Installi le librerie necessarie utilizzando pip: pip install pandas requests msal. Queste librerie servono per la manipolazione dei dati, l'effettuazione di richieste HTTP all'API e la gestione dell'autenticazione della piattaforma di identità Microsoft.
Registrare un'Applicazione in Azure Active Directory: Per autenticarsi con l'API di Dynamics 365, deve registrare un'applicazione nel tenant Azure AD della Sua organizzazione. Crei una nuova App Registration, generi un client secret e prenda nota dell'ID applicazione (client), dell'ID directory (tenant) e del valore del client secret.
Concedere Autorizzazioni API: All'interno della nuova App Registration creata in Azure AD, navighi su Autorizzazioni API. Aggiunga un'autorizzazione per 'Dynamics ERP' o 'Dynamics 365 Business Central' (a seconda della Sua licenza), e conceda l'autorizzazione delegata user_impersonation. Un amministratore deve concedere il consenso amministrativo per queste autorizzazioni.
Creare un Utente Applicazione in Dynamics 365: Nel Suo ambiente Dynamics 365, navighi in Amministrazione sistema > Utenti > Utenti. Crei un nuovo utente e inserisca l'ID applicazione (client) dall'Azure App Registration nel campo ID applicazione. Assegni i ruoli di sicurezza appropriati a questo utente, come 'Amministratore di sistema' o un ruolo più ristretto che abbia accesso in lettura a tutte le entità dati richieste.
Configurare lo Script Python: Copi lo script Python fornito in un file, ad esempio extract_invoices.py. Apra il file e aggiorni le variabili segnaposto nella parte superiore con l'URL specifico del Suo ambiente Dynamics 365, l'ID tenant, l'ID client, il client secret e il codice azienda (dataAreaId) da cui desidera estrarre i dati.
Impostare l'Intervallo di Date: Regoli le variabili START_DATE e END_DATE nello script per definire la finestra temporale per l'estrazione dei dati. Si consiglia di iniziare con un intervallo più piccolo, ad esempio un mese, per testare lo script e verificare i risultati.
Eseguire lo Script: Esegua lo script dalla riga di comando o dal terminale utilizzando il comando: python extract_invoices.py. Lo script si autenticherà, interrogherà i diversi endpoint OData per ogni attività ed elaborerà i dati.
Monitorare l'Esecuzione: Lo script stamperà messaggi di progresso sulla console mentre recupera i dati per ogni attività. Ciò potrebbe richiedere una quantità di tempo significativa a seconda dell'intervallo di date e del volume dei dati. Cerchi eventuali messaggi di errore che potrebbero indicare problemi con l'autenticazione o l'accesso API.
Esaminare il File di Output: Una volta che lo script è stato completato con successo, genererà un file CSV chiamato d365_invoice_event_log.csv nella stessa directory. Questo file contiene l'event log consolidato.
Preparare per il Caricamento: Apra il file CSV per assicurarsi che sia formattato correttamente. Verifichi che tutte le colonne richieste (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) siano presenti e popolate. Il file è ora pronto per essere caricato su ProcessMind.

Configurazione

Autenticazione: Lo script utilizza il flusso di credenziali client OAuth 2.0. Deve configurare una registrazione di app Azure AD e concedere le autorizzazioni API a Dynamics 365. Un utente applicazione con ruoli di sicurezza appropriati deve essere creato in Dynamics 365 stesso.
Endpoint API: L'URL di base per l'API OData di Dynamics 365 Finance and Operations. Il formato è tipicamente https://[nome-ambiente-d365].operations.dynamics.com.
Intervallo di Date: Lo script include le variabili START_DATE e END_DATE. Queste vengono utilizzate per filtrare i record in base alle loro date di creazione o modifica per gestire il volume dei dati. Per le estrazioni iniziali, si consiglia un periodo da 3 a 6 mesi.
Filtro Azienda: I dati devono essere filtrati da una specifica entità legale o azienda. Questo viene fatto specificando il dataAreaId nel filtro della query API, che è una configurazione obbligatoria nello script.
Entità Dati Chiave: Lo script interroga diverse entità OData standard di Dynamics 365, incluse VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines e VendSettlements. Potrebbero essere richieste entità personalizzate se il processo standard è pesantemente modificato.
Paginazione: Lo script gestisce automaticamente le risposte paginate dall'API utilizzando la proprietà @odata.nextLink per garantire che tutti i record per il periodo specificato vengano recuperati.

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()

Fasi

Navigare all'Area di Lavoro Gestione Dati: Acceda a Microsoft Dynamics 365 Finance. Utilizzi la barra di ricerca per trovare e navigare all'area di lavoro Gestione dati.
Creare un Nuovo Progetto di Esportazione: All'interno dell'area di lavoro, selezioni il riquadro Esporta per creare un nuovo progetto di esportazione dati. Assegni un nome significativo al progetto, ad esempio ProcessMind_Invoice_Processing_Export.
Definire il Progetto Dati: Nella scheda Generale del nuovo progetto, specifichi il Formato dati. CSV è un formato comunemente usato e consigliato. Imposti altri parametri secondo necessità.
Aggiungere le Entità Dati Richieste: Vada alla sezione Entità selezionate e clicchi Aggiungi entità. Cerchi e aggiunga le seguenti entità principali una per una. Dovrà specificare il formato dati di destinazione per ciascuna.
- VendInvoiceInfoTableEntity (Intestazione fattura fornitore)
- VendInvoiceTransEntity (Righe fattura fornitore)
- VendInvoiceRegisterHeaderEntity (Intestazione registro fatture)
- WorkflowTrackingStatusTableEntity (Cronologia workflow)
- AccountingDistributionEntity (Distribuzioni GL)
- VendInvoiceJour (Fatture fornitore registrate)
- VendTrans (Transazioni fornitore, per blocchi di pagamento)
- LedgerJournalTransVendPaymEntity (Righe giornale pagamenti fornitore)
- VendSettlement (Transazioni di saldo fornitore)
Applicare i Filtri: Per ogni entità, è fondamentale applicare filtri per limitare l'ambito dei dati. Selezioni un'entità e clicchi Filtra. Al minimo, filtri per Company (Entità legale) e un intervallo di date specifico su un campo data rilevante come CREATEDDATETIME o INVOICEDATE. Un intervallo tipico per l'analisi iniziale è gli ultimi 3-6 mesi.
Configurare le Mappature delle Entità: Per ogni entità, esamini la mappatura sorgente-destinazione. Si assicuri che tutti i campi richiesti per l'event log finale siano inclusi nell'esportazione. Di solito non sono necessarie modifiche complesse alla mappatura in questa fase.
Eseguire il Job di Esportazione: Una volta aggiunte e filtrate tutte le entità, clicchi Esporta nel riquadro Azioni per avviare il job. Può eseguirlo immediatamente o pianificarlo per le ore non di punta per minimizzare il carico del sistema.
Scaricare i Dati Esportati: Dopo che il job di esportazione è stato completato con successo, navighi alla cronologia dei job. Da lì, può scaricare il pacchetto di dati esportato, che conterrà file separati per ogni entità dati.
Trasformare i Dati in un Event Log: I file esportati sono snapshot di entità, non un event log consolidato. Deve 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.
Eseguire la Logica di Trasformazione: Carichi i file CSV esportati nell'ambiente di trasformazione scelto. Esegua la query di trasformazione fornita, che unisce i dati di tutti i file sorgente per creare una singola tabella di event log con una riga per attività aziendale.
Finalizzare e Caricare: Esporti i dati trasformati finali in un singolo file CSV. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti, ad esempio InvoiceNumber, ActivityName, EventTime. Questo file è ora pronto per essere caricato su ProcessMind.

Configurazione

Entità Dati: Il fulcro della configurazione è la selezione del set corretto di entità per coprire il ciclo di vita delle fatture. Le entità chiave includono VendInvoiceInfoTableEntity, VendInvoiceJour e WorkflowTrackingStatusTableEntity.
Formato di Esportazione Dati: Selezioni CSV come formato dati di destinazione per una facile elaborazione nei passaggi di trasformazione successivi.
Filtro per Azienda: È fondamentale filtrare ogni entità dati per la specifica entità legale (Azienda) che sta analizzando, al fine di evitare di estrarre dati irrilevanti.
Filtro Intervallo di Date: Applichi un filtro di intervallo di date coerente a tutte le entità rilevanti, come VendInvoiceInfoTableEntity e VendInvoiceJour, basato sulle date di creazione o di registrazione. Inizi con un periodo recente, ad esempio gli ultimi 6 mesi, per gestire il volume dei dati.
Push Completo vs. Incrementale: Per l'estrazione iniziale, esegua un push completo. Per i successivi aggiornamenti, può configurare un'esportazione incrementale per recuperare solo i dati modificati dall'ultima esecuzione, riducendo il tempo di elaborazione.
Prerequisiti: L'utente che esegue l'esportazione deve avere i ruoli di sicurezza appropriati in Dynamics 365, tipicamente inclusi Data management administrator o un ruolo simile con permessi di accesso alle entità dati richieste.

a Query di Esempio config

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

Il Suo Template Dati per il Processo Dal Ciclo Acquisto al Pagamento - Gestione Fatture

Il Suo Template Dati per il Processo Dal Ciclo Acquisto al Pagamento - Gestione Fatture

Acquisto al Pagamento - Attributi di Elaborazione Fatture

Acquisto al Pagamento - Attività di Elaborazione Fatture

Guide all'Estrazione

Esportazione dal Framework di Gestione Dati di Dynamics 365

Fasi

Configurazione

a Query di Esempio config

Query SQL Diretta tramite Bring Your Own Database (BYOD)

Fasi

Configurazione

a Query di Esempio sql

Script Python che utilizza l'API REST OData di Dynamics 365

Fasi

Configurazione

a Query di Esempio python

Estrazione del Dataflow di Microsoft Power Platform

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Inizi a Ottimizzare il Suo Processo di Acquisto al Pagamento - Elaborazione Fatture Oggi Stesso

Il Suo Template Dati per il Processo Dal Ciclo Acquisto al Pagamento - Gestione Fatture

Il Suo Template Dati per il Processo Dal Ciclo Acquisto al Pagamento - Gestione Fatture

Acquisto al Pagamento - Attributi di Elaborazione Fatture

Acquisto al Pagamento - Attività di Elaborazione Fatture

Guide all'Estrazione

Esportazione dal Framework di Gestione Dati di Dynamics 365

Fasi

Configurazione

a Query di Esempio config

Query SQL Diretta tramite Bring Your Own Database (BYOD)

Fasi

Configurazione

a Query di Esempio sql

Script Python che utilizza l'API REST OData di Dynamics 365

Fasi

Configurazione

a Query di Esempio python

Estrazione del Dataflow di Microsoft Power Platform

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Inizi a Ottimizzare il Suo Processo di Acquisto al Pagamento - Elaborazione Fatture Oggi Stesso