> Miglioramento continuo dei processi > Order to Cash Fatturazione ed emissione delle fatture > Microsoft Dynamics 365 > Template dei dati

Il Suo template dei dati per Order to Cash - Fatturazione ed emissione fatture

Microsoft Dynamics 365

← Torna alla guida al miglioramento

Attributi di Order to Cash - Fatturazione ed emissione fatture(18) Attività di Order to Cash - Fatturazione ed emissione fatture(12) Guide all’estrazione(2)

Il Suo template dei dati per Order to Cash - Fatturazione ed emissione fatture

Questo template offre indicazioni chiare per raccogliere i dati essenziali necessari ad analizzare il processo Order to Cash - Fatturazione ed emissione fatture. Include gli attributi consigliati per l’Event Log, le attività principali da monitorare e indicazioni pratiche su come estrarre queste informazioni. È pensato per aiutarLa a preparare rapidamente i dati per un’analisi di Process Mining.

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

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

Scarica il template

Attributi di Order to Cash - Fatturazione ed emissione fatture

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo Order to Cash - Fatturazione ed emissione fatture.

3 Obbligatorio 6 Consigliato 9 Facoltativo

	Nome	Descrizione
	Numero di fattura InvoiceNumber	Identificativo univoco di ogni fattura cliente, utilizzato come identificativo principale del caso nel processo di fatturazione.
Descrizione Il numero di fattura è la chiave centrale che raggruppa tutte le attività relative a un singolo documento di fatturazione. Consente di analizzare l’intero ciclo di vita della fattura, dalla creazione e approvazione fino al pagamento del cliente e alla chiusura. Utilizzandolo come ID del caso, ogni voce dell’event log corrisponde a una fattura specifica, consentendo un’analisi dettagliata delle varianti, il calcolo del tempo di ciclo e il monitoraggio delle prestazioni di ogni transazione di fatturazione. Perché è importante Questo attributo è essenziale per tracciare l’intero ciclo di vita di una fattura e analizzare l’efficienza del processo, i colli di bottiglia e le deviazioni per ogni singolo documento di fatturazione. Dove reperirli Si trova in genere nel modulo Vendite e marketing, in tabelle come CustInvoiceJour (campo InvoiceId) o tramite entità dati come SalesInvoiceHeaderV2. Esempi CIV-001254INV-2023-9876US-004321
	Nome dell’attività ActivityName	Nome dell’attività aziendale o dell’evento che si è verificato in un determinato momento del ciclo di vita della fattura.
Descrizione Questo attributo descrive un passaggio o una tappa specifica del processo di fatturazione, ad esempio «Fattura generata», «Fattura approvata» o «Pagamento del cliente ricevuto». La sequenza di queste attività costituisce il flusso del processo. Analizzarle è fondamentale per il Process Mining, perché consente di individuare i modelli di processo e le varianti e di misurare le prestazioni tra le diverse fasi. Perché è importante Definisce le fasi del processo e consente di visualizzare le mappe dei processi, analizzare le varianti e individuare i colli di bottiglia o le deviazioni dalla procedura standard. Dove reperirli Questo attributo deriva in genere da più fonti, come i campi di modifica dello stato (ad esempio DocumentState), la compilazione di specifici campi data o i log della cronologia del flusso di lavoro in Microsoft Dynamics 365. Esempi Fattura generataFattura approvataPagamento del cliente ricevutoNota di credito emessa
	Ora dell’evento EventTime	Marca temporale precisa che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione L’ora dell’evento, detta anche marca temporale, registra la data e l’ora esatte di ogni attività del processo. Questi dati sono fondamentali per tutte le analisi di Process Mining basate sul tempo. Servono a calcolare i tempi di ciclo tra le attività, misurare la durata complessiva di un caso e comprendere l’andamento del processo nel tempo. Marche temporali accurate e affidabili sono alla base di KPI come i giorni medi di incasso e il tempo di creazione della fattura. Perché è importante È l’attributo fondamentale per tutte le analisi delle prestazioni e dei tempi, perché consente di calcolare i tempi di ciclo, le durate e la produttività e di misurare l’efficienza del processo. Dove reperirli I timestamp provengono da diversi campi di data e ora presenti nelle tabelle di Dynamics 365, ad esempio CreatedDateTime nella tabella CustInvoiceJour per la generazione delle fatture oppure timestamp specifici della cronologia del flusso di lavoro. Esempi 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Data di scadenza del pagamento PaymentDueDate	La data entro la quale il cliente dovrebbe pagare la fattura.
Descrizione La data di scadenza del pagamento è un campo data fondamentale, calcolato in base alla data della fattura e alle condizioni di pagamento del cliente. Costituisce il riferimento per misurare la puntualità dei pagamenti. Questo attributo è essenziale per la Dashboard «Analisi del rispetto delle condizioni di pagamento» e per calcolare KPI come «Tasso di pagamenti puntuali» e «Giorni medi di incasso». Il confronto con la data effettiva del pagamento rivela il comportamento di pagamento dei clienti e l’efficacia del processo di recupero crediti. Perché è importante È il riferimento per misurare la puntualità dei pagamenti. È essenziale per calcolare il tasso di pagamenti puntuali e analizzare il rispetto delle condizioni di pagamento concordate con i clienti. Dove reperirli In genere si trova nella tabella CustInvoiceJour, in un campo come DueDate. Esempi 2023-05-152023-06-302023-07-01
	Importo della fattura InvoiceAmount	Il valore monetario totale della fattura.
Descrizione Questo attributo rappresenta l’importo totale dovuto per la fattura. È una metrica fondamentale per l’analisi finanziaria, perché consente di suddividere le fatture in base al valore. Ad esempio, gli analisti possono concentrarsi sulle fatture di importo elevato per capire come vengono pagate o verificare se richiedono tempi di approvazione più lunghi. È inoltre essenziale per calcolare il valore totale delle fatture insolute e il DSO. Perché è importante Consente di analizzare l’impatto finanziario, filtrando e segmentando i processi in base al valore monetario, così da dare priorità alle fatture di importo elevato e comprenderne le specificità di processo. Dove reperirli Si trova nella tabella CustInvoiceJour, in genere in un campo come InvoiceAmount. È disponibile anche nelle tabelle delle transazioni correlate. Esempi 5430.5012500.00750.25
	Nome del cliente CustomerName	Il nome del cliente a cui è stata emessa la fattura.
Descrizione Il nome del cliente identifica in modo leggibile l’azienda o la persona a cui viene addebitato l’importo. Nell’analisi di Process Mining, consente di segmentare il processo di fatturazione per cliente. In questo modo è possibile individuare i clienti che pagano regolarmente puntuali, quelli che accumulano spesso ritardi e gli eventuali ritardi o variazioni di processo specifici di determinati gruppi di clienti. È un dato essenziale per le Dashboard sul comportamento di pagamento dei clienti e per l’analisi dei Giorni medi di incasso. Perché è importante Consente di segmentare l’analisi del processo per cliente, aiutando a individuare comportamenti specifici, pattern di pagamento e problemi di processo. Dove reperirli Queste informazioni si ottengono unendo i dati delle fatture con la tabella anagrafica dei clienti, in genere CustTable, utilizzando il numero di conto del cliente. Esempi Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Reparto Department	Il reparto aziendale associato all’utente o all’attività.
Descrizione Questo attributo associa un’attività o un utente a uno specifico reparto aziendale, ad esempio «Crediti verso clienti» o «Vendite». Consente di valutare le prestazioni del processo a un livello più ampio rispetto al singolo utente. L’analisi per reparto aiuta a comprendere i passaggi di consegne tra funzioni, confrontare l’efficienza dei team e individuare i colli di bottiglia a livello di reparto, come richiesto dalla Dashboard «Carico di lavoro delle attività del reparto fatturazione». Perché è importante Consente di analizzare le prestazioni a livello organizzativo, confrontando l’efficienza dei diversi team e valutando l’impatto dei passaggi di consegne tra reparti sul processo. Dove reperirli In genere non è un campo diretto della transazione della fattura. Si ricava unendo l’ID UserResponsible alla directory dei dipendenti o degli utenti, che contiene le informazioni sul reparto. Esempi Crediti verso clientiFinanzaOperazioni di fatturazione
	Stato della fattura InvoiceStatus	Lo stato corrente della fattura nel suo ciclo di vita (ad esempio, aperta, pagata, annullata).
Descrizione Questo attributo mostra la situazione corrente della fattura. Indica se il pagamento è ancora in attesa, se la fattura è stata saldata interamente, è scaduta o è stata annullata tramite una nota di credito. È utile per filtrare i casi e analizzare solo le fatture aperte oppure verificare l’esito finale di una fattura chiusa. Aiuta a comprendere il carico di lavoro corrente e la situazione finanziaria dei crediti. Perché è importante Fornisce una rapida panoramica dello stato corrente della fattura, utile per filtrare i casi e comprendere gli esiti delle diverse varianti di processo. Dove reperirli Si può ricavare dallo stato del pagamento della fattura, verificando spesso se il saldo del record CustTrans correlato è pari a zero. Non sempre esiste un unico campo «stato». Esempi ApertaPagataScadutaAnnullata
	Utente responsabile UserResponsible	L’utente o il dipendente responsabile dell’esecuzione di una specifica attività.
Descrizione Questo attributo identifica la persona che ha svolto una determinata attività nel processo di fatturazione, ad esempio approvare una fattura o registrare un incasso. È fondamentale per analizzare i carichi di lavoro, confrontare le prestazioni e individuare le esigenze di formazione. Ad esempio, la Dashboard «Carico di lavoro delle attività del reparto fatturazione» utilizza questo attributo per verificare se il lavoro è distribuito in modo uniforme o se alcuni utenti costituiscono colli di bottiglia. Aiuta inoltre a comprendere l’allocazione delle risorse e l’efficienza. Perché è importante Consente l’analisi a livello di risorsa, aiutando a individuare i colli di bottiglia, misurare le prestazioni individuali o di gruppo e analizzare la distribuzione del carico di lavoro nel reparto fatturazione. Dove reperirli Può provenire dai log della cronologia del flusso di lavoro, ad esempio WorkflowTrackingStatusTable, oppure da campi di assegnazione come Owner o ModifiedBy nelle tabelle pertinenti. Esempi John SmithAlicia BakerAmministratore di sistema
	Condizioni di pagamento PaymentTerms	Le condizioni concordate per il pagamento della fattura (ad esempio, 30 o 60 giorni).
Descrizione Le condizioni di pagamento definiscono entro quando il cliente dovrebbe saldare una fattura. Questo attributo viene utilizzato per calcolare la data di scadenza del pagamento ed è una dimensione importante per analizzare i comportamenti di pagamento. La Dashboard «Analisi del rispetto delle condizioni di pagamento» utilizza questo attributo per raggruppare clienti e fatture e verificare se determinate condizioni sono più o meno efficaci o sono associate a una maggiore frequenza di ritardi. Perché è importante Spiega perché una fattura scade in una determinata data e consente di segmentare l’analisi per verificare se alcune condizioni di pagamento sono associate a ritardi. Dove reperirli In genere è memorizzato nell’anagrafica del cliente e copiato nell’intestazione della fattura. Nella tabella CustInvoiceJour, cerchi un campo Payment o PaymTermId. Esempi 30 giorni60 giorniPagamento alla ricezione
	È una rilavorazione IsRework	Un indicatore che segnala se il processo della fattura ha comportato attività di rilavorazione, ad esempio più approvazioni.
Descrizione È un attributo booleano calcolato che segnala le fatture sottoposte a rilavorazione. La rilavorazione può essere definita dalla presenza di più eventi «Fattura approvata» o da storni di pagamento. Questo attributo è pensato per supportare la Dashboard «Analisi della rilavorazione delle fatture» e il KPI «Tasso di rilavorazione delle fatture». Isolando questi casi, gli analisti possono indagare le cause profonde della rilavorazione, spesso riconducibili a inefficienze di processo, problemi di qualità dei dati o lacune nella formazione. Perché è importante Questo indicatore quantifica direttamente le inefficienze del processo, individuando i casi con azioni ripetute o correttive e aiutando a risalire alle cause profonde degli sprechi e dei ritardi. Dove reperirli Questo attributo non è disponibile nel sistema di origine. Viene calcolato nel livello di trasformazione dei dati, verificando la presenza di attività ripetute o di specifici schemi di rilavorazione all’interno di un caso. Esempi truefalse
	Giorni medi di incasso DaysSalesOutstanding	Il numero di giorni tra la generazione della fattura e la ricezione del pagamento del cliente.
Descrizione I Giorni medi di incasso (DSO) sono una metrica finanziaria fondamentale che misura il numero medio di giorni necessari a un’azienda per incassare un pagamento dopo una vendita. Questo attributo calcolato determina la durata per ogni singola fattura. È la metrica principale della Dashboard «Analisi dell’andamento dei giorni medi di incasso» e del KPI «DSO». Analizzare il DSO aiuta a gestire il flusso di cassa e a valutare l’efficienza delle attività di gestione del credito e recupero crediti. Perché è importante È un KPI fondamentale per misurare la salute del flusso di cassa di un’azienda e l’efficienza del processo di recupero crediti. Quantifica la rapidità con cui i ricavi si trasformano in liquidità. Dove reperirli Questo attributo non è presente nel sistema di origine. Si calcola come intervallo tra l’attività «Fattura generata» e l’attività «Pagamento del cliente ricevuto». Esempi 284592
	Numero dell’ordine di vendita SalesOrderNumber	L’identificativo dell’ordine di vendita da cui ha origine la fattura.
Descrizione Il numero dell’ordine di vendita collega il processo di fatturazione al processo di vendita che lo precede. Questo collegamento è prezioso per un’analisi completa del processo Order-to-Cash. Consente agli analisti di verificare in che modo eventuali problemi nelle fasi di vendita ed evasione, come modifiche agli ordini o ritardi nelle spedizioni, possano incidere sul ciclo di fatturazione. Ad esempio, aiuta a rispondere a domande come «Le fatture relative a ordini di vendita complessi richiedono più tempo per essere pagate?». Perché è importante Questo attributo collega il processo di fatturazione al processo di vendita a monte, consentendo un’analisi Order-to-Cash più completa e end-to-end per individuare le cause profonde dei problemi di fatturazione. Dove reperirli Si trova nell’intestazione della fattura o nei dettagli delle righe e rimanda all’ordine di vendita. Nella tabella CustInvoiceJour, cerchi un campo come SalesId. Esempi SO-009876SO-010234US-SO-00543
	Pagamento puntuale IsOnTimePayment	Un indicatore che segnala se il pagamento del cliente è stato ricevuto entro la data di scadenza.
Descrizione Questo attributo booleano calcolato confronta il timestamp «Pagamento del cliente ricevuto» con la «Data di scadenza del pagamento». Indica se ogni fattura è stata pagata puntualmente o in ritardo. È alla base del KPI «Tasso di pagamenti puntuali» ed è ampiamente utilizzato nella Dashboard «Analisi del rispetto delle condizioni di pagamento». Fornisce un esito chiaro e binario delle prestazioni di pagamento, semplificando l’analisi e la rendicontazione. Perché è importante Misura direttamente il rispetto delle condizioni di pagamento da parte dei clienti ed è alla base del KPI sul tasso di pagamenti puntuali, semplificando l’analisi dell’efficacia del recupero crediti. Dove reperirli Questo attributo non è presente nel sistema di origine. Viene calcolato durante la trasformazione dei dati confrontando la data del pagamento con PaymentDueDate. Esempi truefalse
	Richiede un intervento manuale RequiresManualIntervention	Un indicatore che segnala se il pagamento ha richiesto una rettifica manuale durante la registrazione dell’incasso.
Descrizione Questo attributo booleano segnala i pagamenti che hanno richiesto un intervento o una correzione manuale durante la registrazione dell’incasso. È fondamentale per il KPI «Tasso di discrepanze nella registrazione degli incassi», perché aiuta a quantificare l’accuratezza e il livello di automazione della registrazione dei pagamenti. Individuare le cause dell’intervento manuale, come informazioni di rimessa mancanti o discrepanze nei pagamenti, può portare a miglioramenti del processo e aumentare la percentuale di elaborazioni senza intervento manuale. Perché è importante Questo attributo aiuta a individuare gli ostacoli e le imprecisioni nella fase di registrazione degli incassi, un aspetto cruciale per migliorare l’automazione e ridurre il lavoro manuale. Dove reperirli Queste informazioni possono essere dedotte dall’utente che ha registrato il pagamento, se non si tratta di un utente di sistema, oppure da specifici codici causali utilizzati durante la riconciliazione dei pagamenti. Consulti la documentazione di Microsoft Dynamics 365. Esempi truefalse
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati.
Descrizione Questo attributo identifica l’origine dei dati del processo. In questo caso, indica che i dati provengono da Microsoft Dynamics 365. È un’informazione importante negli ambienti con più sistemi, perché consente di distinguere le origini dei dati e di tracciarne con chiarezza la provenienza, agevolando la convalida dei dati e la risoluzione dei problemi. Perché è importante Fornisce un contesto essenziale sull’origine dei dati, indispensabile per la governance e la convalida dei dati e per unire dati provenienti da più sistemi aziendali. Dove reperirli È un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati. Esempi Microsoft Dynamics 365 FinanceD365 F&O
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l’ultimo aggiornamento dei dati relativi a questo evento dal sistema di origine.
Descrizione Questo attributo registra la data dell’ultima estrazione o dell’ultimo aggiornamento dei dati da Microsoft Dynamics 365. È un campo di metadati fondamentale per capire quanto siano aggiornati i dati analizzati. Consente ad analisti e utenti aziendali di verificare se stanno consultando le informazioni più recenti ed è essenziale per gestire la pianificazione degli aggiornamenti e garantire l’affidabilità dell’analisi. Perché è importante Consente agli utenti di sapere quanto sono recenti i dati, un aspetto fondamentale per la governance dei dati, la gestione degli aggiornamenti delle Dashboard e la fiducia nella tempestività degli insight. Dove reperirli Questo attributo viene generato e aggiunto al set di dati durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Valuta Currency	Il codice della valuta dell’importo della fattura (ad esempio, USD, EUR).
Descrizione Questo attributo specifica la valuta in cui è espresso l’importo della fattura. È essenziale per le organizzazioni multinazionali che operano con valute diverse. Senza questa informazione, aggregare o confrontare gli importi delle fatture non avrebbe senso. Consente di convertire correttamente le valute e di produrre analisi e rendicontazioni finanziarie accurate per le diverse aree geografiche. Perché è importante Fornisce il contesto necessario per interpretare le metriche finanziarie, come l’importo della fattura, evitando aggregazioni errate e consentendo analisi accurate in ambienti con più valute. Dove reperirli Si trova nella tabella CustInvoiceJour, in genere in un campo come CurrencyCode. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività di Order to Cash - Fatturazione ed emissione fatture

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

7 Consigliato 5 Facoltativo

	Attività	Descrizione
	Data di scadenza del pagamento raggiunta	Evento calcolato che si verifica quando arriva la data di scadenza della fattura senza che il pagamento sia stato interamente abbinato. Questa attività non corrisponde a una transazione nel sistema, ma viene ricavata dai dati esistenti.
Perché è importante Questo evento è fondamentale per analizzare la puntualità dei pagamenti e individuare le fatture che stanno diventando scadute. Segna il momento in cui avviare le attività di recupero crediti e di sollecito. Dove reperirli Non viene registrato come evento. Si calcola utilizzando il campo DueDate della tabella CustInvoiceJour. La marca temporale dell’evento corrisponde alla data di scadenza. Acquisizione Crei un evento la cui marca temporale corrisponde al valore del campo CustInvoiceJour.DueDate. Tipo di evento calculated
	Fattura approvata	Segna la conclusione della revisione interna e l’approvazione formale della fattura. Il sistema del flusso di lavoro di Dynamics 365 registra questo evento, che indica che la fattura è pronta per essere inviata al cliente.
Perché è importante È una tappa fondamentale per misurare il tempo di ciclo dell’approvazione. I ritardi in questa fase possono allungare direttamente il tempo necessario per ricevere il pagamento dal cliente. Dove reperirli Viene registrato nelle tabelle della cronologia del flusso di lavoro, come WorkflowTrackingStatusTable, come passaggio di completamento o approvazione della specifica istanza del flusso di lavoro della fattura. Acquisizione Estragga gli event log del flusso di lavoro in cui lo stato è «Approvato» o «Completato». Tipo di evento explicit
	Fattura chiusa	Questa attività indica lo stato finale di una fattura, il cui saldo è pari a zero perché è stata pagata interamente o compensata con note di credito. Non corrisponde a una transazione diretta, ma a uno stato dedotto dalla situazione finanziaria della fattura.
Perché è importante Questo evento indica il completamento del ciclo Order to Cash per una singola fattura. Il tempo necessario per raggiungere questo stato è una misura fondamentale dell’efficienza complessiva del processo. Dove reperirli Si deduce verificando che il saldo residuo della transazione della fattura nella tabella CustTrans sia pari a zero. Il dato si ottiene confrontando l’importo della fattura con l’importo totale compensato. Acquisizione Lo deduca dai record CustTrans in cui AmountCur è uguale a SettleAmountCur. La marca temporale corrisponde alla data dell’ultima compensazione. Tipo di evento inferred
	Fattura generata	Indica la creazione e la registrazione nel sistema del documento di fattura di vendita. In Dynamics 365 si tratta di una transazione esplicita che genera un documento legale e le registrazioni finanziarie nel sottoconto clienti.
Perché è importante Questo evento segna l’inizio ufficiale del ciclo di fatturazione. È fondamentale per monitorare i giorni medi di incasso (DSO) e la durata complessiva del processo. Dove reperirli Si rileva dalla marca temporale di creazione della fattura di vendita registrata nella tabella CustInvoiceJour. Al momento della registrazione, le relative transazioni finanziarie vengono create nelle tabelle GeneralJournalEntry e LedgerEntry. Acquisizione Per la fattura registrata, utilizzi il campo CreatedDateTime della tabella CustInvoiceJour. Tipo di evento explicit
	Fattura inviata al cliente	Questa attività indica il momento in cui la fattura viene trasmessa al cliente, per via elettronica o cartacea. In Dynamics 365 può essere registrata come evento esplicito se viene inviata tramite l’e-mail del sistema; in assenza di una funzione di tracciamento specifica, si può dedurre che coincida con il momento della registrazione.
Perché è importante Misura l’efficienza del processo di invio delle fatture. Un ritardo tra l’approvazione e l’invio prolunga inutilmente il ciclo di pagamento. Dove reperirli Se si utilizzano le funzioni e-mail di D365, l’evento può essere rilevato direttamente dai log delle e-mail, ad esempio SysOutgoingEmailTable. In caso contrario, spesso si deduce che coincida con l’ora di registrazione della fattura in CustInvoiceJour. Acquisizione Utilizzi la marca temporale del log e-mail, se disponibile; in caso contrario, utilizzi quella di registrazione della fattura. Tipo di evento inferred
	Incasso abbinato alla fattura	Indica la compensazione di un pagamento del cliente con una fattura specifica, che riduce il saldo residuo della fattura. In Dynamics 365 è un passaggio distinto che collega la transazione di pagamento a quella della fattura.
Perché è importante È una tappa fondamentale per calcolare con precisione il DSO e comprendere l’efficienza del team che registra gli incassi. Segna il momento in cui il pagamento viene riconciliato interamente con l’importo fatturato. Dove reperirli Viene registrato nella tabella CustSettlement. Il campo della data di regolamento in questa tabella fornisce la marca temporale del momento in cui un pagamento specifico è stato abbinato a una determinata transazione di fattura. Acquisizione Utilizzi TransDate o CreatedDateTime dalla tabella CustSettlement. Tipo di evento explicit
	Pagamento del cliente ricevuto	Questa attività indica la creazione di una registrazione contabile per un pagamento ricevuto da un cliente. Segnala che il denaro è stato incassato, ma non ancora abbinato a una fattura specifica.
Perché è importante È il punto di partenza per misurare il tempo di attraversamento della registrazione dell’incasso. Consente di distinguere tra la ricezione del denaro e la sua effettiva riconciliazione con le fatture aperte. Dove reperirli Si rileva dalla creazione o dalla registrazione di un giornale di pagamento del cliente. Il dato è registrato in tabelle come LedgerJournalTrans e, al momento della registrazione, genera una transazione cliente in CustTrans. Acquisizione Utilizzi la marca temporale di registrazione del giornale di pagamento del cliente in LedgerJournalTable. Tipo di evento explicit
	Fattura inviata per l’approvazione	Questa attività indica che una fattura generata è stata inviata al flusso di lavoro formale di approvazione. È una prassi comune nelle organizzazioni che richiedono una revisione da parte della direzione prima di inviare la fattura al cliente. Il motore del flusso di lavoro di D365 registra questo passaggio specifico.
Perché è importante Monitorare l’invio per l’approvazione consente di distinguere il tempo necessario per creare la fattura da quello trascorso in attesa di approvazione. È il primo passo per analizzare l’efficienza dei processi interni di revisione e controllo. Dove reperirli Si rileva dalle tabelle della cronologia del flusso di lavoro, come WorkflowTrackingStatusTable, filtrando l’evento di invio relativo al documento della fattura. Acquisizione Estragga gli event log del flusso di lavoro in cui lo stato è «Inviato». Tipo di evento explicit
	Nota di credito emessa	Indica la creazione di una nota di credito, in genere per correggere un errore di fatturazione, applicare una rettifica di prezzo o contabilizzare merci restituite. In sostanza, una nota di credito equivale a una fattura negativa.
Perché è importante Un numero elevato di note di credito può segnalare problemi sistemici nel processo di evasione degli ordini o di fatturazione. Analizzare i motivi della loro emissione è essenziale per migliorare il processo e ridurre le perdite di ricavi. Dove reperirli È una transazione esplicita, registrata come una nuova fattura con importo negativo nella tabella CustInvoiceJour. Spesso è collegata alla fattura originale tramite un campo di riferimento. Acquisizione Individui nella tabella CustInvoiceJour i record con un importo totale negativo e li colleghi alla fattura originale. Tipo di evento explicit
	Ordine di vendita evaso	Questa attività indica che le merci sono state spedite o i servizi erogati per un ordine di vendita, dando avvio al processo di fatturazione. In Microsoft Dynamics 365, viene in genere dedotta dalla registrazione di un documento di trasporto o di consegna, che modifica lo stato delle righe dell’ordine di vendita corrispondente.
Perché è importante Questo evento segna l’inizio della misurazione del tempo di ciclo per la creazione della fattura. Capire quanto tempo intercorre tra l’evasione dell’ordine e la fatturazione aiuta a individuare i colli di bottiglia amministrativi che possono incidere sul flusso di cassa. Dove reperirli Si deduce dalla data di creazione della registrazione del documento di trasporto collegato all’ordine di vendita. A questo scopo si utilizzano tabelle come CustPackingSlipJour e CustPackingSlipTrans, correlate all’ordine di vendita su cui si basa la fattura. Acquisizione Individuare la data di registrazione più recente del documento di trasporto per l’ordine di vendita associato alla fattura. Tipo di evento inferred
	Pagamento stornato	Questa attività indica lo storno di un pagamento del cliente registrato in precedenza. Può verificarsi a causa di errori di registrazione, fondi insufficienti o altri problemi con il pagamento.
Perché è importante Gli storni dei pagamenti possono segnalare errori operativi o problemi nei pagamenti dei clienti. Analizzarne la frequenza aiuta a individuare le cause profonde e a migliorare l’accuratezza della registrazione degli incassi. Dove reperirli Viene rilevato come storno di una transazione nella contabilità generale. Una registrazione stornata si può individuare in GeneralJournalEntry, spesso tramite un contrassegno specifico o il collegamento alla transazione originale. Acquisizione Individui le registrazioni contabili con un contrassegno di storno o un riferimento a una transazione stornata. Tipo di evento explicit
	Promemoria di pagamento inviato	Indica l’invio al cliente di una lettera di sollecito o di un avviso di recupero crediti per una fattura scaduta. Dynamics 365 dispone di un processo formale di sollecito che genera e registra queste comunicazioni.
Perché è importante Monitorare i promemoria consente di valutare l’efficacia del processo di sollecito e di analizzare quanti invii sono necessari prima di ricevere il pagamento. Dove reperirli È un evento esplicito, rilevato dalla data di creazione della registrazione della lettera di sollecito nella tabella CustCollectionLetterJour, collegata alla transazione della fattura scaduta. Acquisizione Utilizzi la marca temporale di creazione della tabella CustCollectionLetterJour. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Microsoft Dynamics 365

Passaggi

Acceda all’area di lavoro Data Management: acceda a Microsoft Dynamics 365 Finance and Operations. Utilizzi la barra di ricerca per trovare e aprire l’area di lavoro Data management, il punto centrale per tutte le operazioni di importazione ed esportazione dei dati.
Crei un nuovo progetto di esportazione: nell’area di lavoro Data management, selezioni il riquadro Export per creare un progetto di esportazione dei dati. Assegni al progetto un nome significativo, ad esempio ProcessMind_O2C_Billing_Export, e una descrizione.
Selezioni il formato dei dati di destinazione: nella configurazione del progetto, specifichi il Target data format. Per garantire la compatibilità con la maggior parte degli strumenti di trasformazione dei dati, selezioni CSV. Configuri le opzioni del formato secondo necessità, scegliendo un delimitatore e un qualificatore di testo comuni.
Aggiunga le entità dati necessarie: questo è il passaggio più importante. Aggiunga al progetto diverse entità dati standard per acquisire tutte le attività necessarie. Per ogni entità, selezioni Add entity e cerchi il nome indicato nella sezione Query/Script. Aggiunga al progetto le seguenti entità: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement e Dunning history letters.
Applichi filtri alle entità: per limitare i dati a un ambito pertinente, applichi filtri alle entità. Come minimo, filtri Sales invoice headers V2 in base a InvoiceDate per un periodo specifico, ad esempio gli ultimi 6 mesi. Filtri inoltre in base alle entità giuridiche (società) che desidera analizzare.
Avvii l’esportazione: dopo aver aggiunto tutte le entità e applicato i filtri, selezioni il pulsante Export nel riquadro delle azioni. Il sistema creerà un pacchetto di lavoro e avvierà in background l’estrazione dei dati.
Controlli l’esportazione e scarichi i dati: può controllare l’avanzamento del lavoro nella sezione Job history. Al termine dell’elaborazione, potrà scaricare il pacchetto di dati esportati, un file ZIP contenente un file CSV separato per ogni entità.
Decomprima il pacchetto: estragga i contenuti del file ZIP scaricato in una cartella locale. Otterrà così diversi file CSV, uno per ogni entità.
Trasformi e combini i dati: i file originali devono essere trasformati in un unico Event Log. Utilizzi uno strumento di preparazione dei dati come Power Query, Python o un’area di staging di un database. Per ogni file sorgente, crei le colonne necessarie: InvoiceNumber (ID caso), ActivityName (un valore fisso che rappresenta l’evento, ad esempio 'Invoice Generated') e EventTime (il campo data pertinente del file sorgente). Mappi anche altri attributi, come InvoiceAmount e CustomerName.
Unisca tutti i dati trasformati: combini i dati trasformati di tutti i file sorgente in un’unica tabella utilizzando un’operazione di unione o accodamento. Otterrà così l’Event Log finale, in cui ogni riga rappresenta un’attività nel ciclo di vita della fattura.
Prepari il formato finale per il caricamento: verifichi che il file CSV finale abbia le intestazioni di colonna corrette (InvoiceNumber, ActivityName, EventTime e così via) e che la colonna EventTime utilizzi un formato data e ora uniforme (ad esempio, YYYY-MM-DD HH:MI:SS). Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Entità dati: l’estrazione si basa su un insieme di entità dati standard di D365. Tra le principali figurano Sales invoice headers V2 (fatture e note di credito), Sales packing slip headers (evasione degli ordini), CustPaymentJournalLineEntity (pagamenti), Customer settlement (registrazione degli incassi) e Workflow tracking status table (approvazioni).
Formato di esportazione: il formato dati di destinazione consigliato è CSV, compatibile con un’ampia gamma di strumenti di trasformazione dei dati.
Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date alle entità principali, in particolare a Sales invoice headers V2 sul campo InvoiceDate. Si consiglia un intervallo da 3 a 6 mesi, per mantenere gestibile l’esportazione e disporre al tempo stesso di dati sufficienti per l’analisi.
Filtro per società: l’esportazione deve essere filtrata in base alla specifica entità giuridica o al codice società da analizzare, così da garantire la pertinenza dei dati e ridurre le dimensioni dell’esportazione.
Preparazione e trasformazione dei dati: è necessario eseguire una fase di post-elaborazione al di fuori di Dynamics 365. I file esportati devono essere combinati e riorganizzati in un unico Event Log. In genere si utilizzano strumenti come Power BI (Power Query), Python o SQL.
Prerequisiti: l’utente che esegue l’esportazione deve disporre dei ruoli di sicurezza appropriati in Dynamics 365, tra cui in genere un ruolo con autorizzazioni per l’area di lavoro Data management e accesso alle entità dati necessarie.

Query di esempio config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Passaggi

Prerequisiti: verifichi di avere installato Python 3.6 o versione successiva, con le librerie requests e pandas. Le serviranno anche le credenziali di un’entità servizio (registrazione dell’applicazione) in Azure Active Directory, a cui sia stato concesso l’accesso all’ambiente Dynamics 365 Finance & Operations.
Registrazione dell’applicazione: in Azure AD, registri una nuova applicazione. Crei un segreto client e annoti l’ID applicazione (client), l’ID directory (tenant) e il segreto client. In Dynamics 365, aggiunga l’ID dell’applicazione in System administration > Setup > Azure Active Directory applications e le assegni i diritti utente necessari per leggere le entità dati richieste.
Configuri lo script: apra lo script Python fornito e compili le variabili di configurazione all’inizio, tra cui d365_url, tenant_id, client_id, client_secret, company, start_date ed end_date. d365_url deve essere l’URL di base dell’ambiente Dynamics 365, ad esempio https://your-d365-instance.operations.dynamics.com.
Autenticazione: lo script include la funzione get_access_token, che utilizza automaticamente le credenziali per richiedere un token di accesso OAuth2 alla piattaforma di identità Microsoft. Questo token autorizza le successive chiamate API.
Estrazione dei dati: esegua lo script dal terminale con il comando python your_script_name.py. Lo script inizierà recuperando tutte le fatture di vendita registrate (CustInvoiceJour) nell’intervallo di date specificato. Per ogni fattura, effettuerà ulteriori chiamate API per recuperare i dati correlati ad attività quali pagamenti, liquidazioni, note di credito e cronologia del Workflow.
Generazione delle attività: lo script elabora i dati grezzi provenienti da diversi endpoint API e genera esplicitamente una riga per ciascuna delle 12 attività richieste. Ad esempio, utilizza l’entità CustInvoiceJour per l’evento 'Invoice Generated' e interroga l’entità CustSettlement per creare gli eventi 'Cash Applied to Invoice'.
Eventi calcolati: tenga presente che eventi come 'Payment Due Date Reached' e 'Invoice Closed' non corrispondono a transazioni dirette in Dynamics 365. Lo script li ricava dalla data di scadenza, dallo stato e dalla cronologia delle liquidazioni della fattura, aggiungendo le voci corrispondenti all’Event Log.
Gestione della paginazione: la funzione di supporto fetch_all_data gestisce automaticamente la paginazione. Le API OData di Dynamics 365 restituiscono un numero limitato di record per pagina; questa funzione segue quindi il valore @odata.nextLink nella risposta API per recuperare l’intero insieme di dati.
Trasformazione e output dei dati: dopo aver raccolto tutti gli eventi, lo script li riunisce in un unico elenco, lo converte in un DataFrame pandas e uniforma i nomi delle colonne in InvoiceNumber, ActivityName, EventTime e negli altri attributi richiesti.
Esportazione in CSV: infine, lo script salva il DataFrame risultante in un file CSV denominato d365_billing_event_log.csv. Il file è già formattato e pronto per essere caricato in ProcessMind o in un altro strumento di Process Mining.

Configurazione

URL D365: l’URL di base dell’istanza Dynamics 365 Finance & Operations, ovvero l’endpoint principale per tutte le chiamate API.
Credenziali Azure AD: per l’autenticazione sono necessari client_id, client_secret e tenant_id. Devono appartenere a un’applicazione con accesso in lettura alle entità D365 pertinenti.
Società: specifichi DataAreaId, che corrisponde all’entità giuridica di Dynamics 365 da cui desidera estrarre i dati, ad esempio 'USMF'.
Intervallo di date: definisca start_date ed end_date per limitare l’ambito dell’estrazione. Per un’analisi iniziale si consiglia un periodo da 3 a 6 mesi, così da ottenere un insieme di dati gestibile ma sufficiente a rappresentare le variazioni del processo.
Entità OData principali: lo script interroga principalmente le seguenti entità: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours e WorkflowTrackingStatusTables. Verifichi che l’utente configurato disponga delle autorizzazioni di lettura per tutte queste entità.
Prestazioni: l’estrazione dei dati relativi a un periodo lungo o a una società molto grande può richiedere tempo, poiché comporta numerose chiamate API sequenziali. Si consiglia di eseguire lo script nelle ore di minore attività e di iniziare con un intervallo di date più breve per stimare la durata complessiva.

Query di esempio python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
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 = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

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

È pronto a iniziare?

Inizi a ottimizzare la fatturazione e l’emissione delle fatture utilizzando questo template. Offra al Suo team gli approfondimenti necessari per migliorare l’efficienza e i flussi di cassa.

Torna alla guida al miglioramento

Scarica il template

Elimini i ritardi di fatturazione: ottimizzi subito Order to Cash e l’emissione delle fatture

Riduca del 30% il tempo di ciclo della fatturazione e ottenga più rapidamente una visione chiara della situazione finanziaria.

Inizi la prova gratuita

Non è richiesta la carta di credito. Prova gratuita di 14 giorni.

Il Suo template dei dati per Order to Cash - Fatturazione ed emissione fatture

Il Suo template dei dati per Order to Cash - Fatturazione ed emissione fatture

Attributi di Order to Cash - Fatturazione ed emissione fatture

Attività di Order to Cash - Fatturazione ed emissione fatture

Guide all’estrazione

Esportazione delle entità dati di Microsoft Dynamics 365

Passaggi

Configurazione

Query di esempio config

Script Python con l’API Web OData di Dynamics 365

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Elimini i ritardi di fatturazione: ottimizzi subito Order to Cash e l’emissione delle fatture