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

Il Suo Template dei dati Order to Cash - Billing & Invoicing

Microsoft Dynamics 365

← Torna alla guida al miglioramento

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

Il Suo Template dei dati Order to Cash - Billing & Invoicing

Questo Template fornisce una guida chiara per raccogliere i dati essenziali necessari ad analizzare il processo Order to Cash - Billing & Invoicing. Include gli attributi consigliati da inserire nell'Event Log, le attività principali da monitorare e indicazioni pratiche per estrarre queste informazioni. È progettato per aiutarLa a preparare rapidamente i dati necessari a un'analisi di Process Mining efficace.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l'estrazione 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 delle fatture

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

3 Obbligatorio 6 Consigliato 9 Facoltativo

	Nome	Descrizione
	Numero fattura InvoiceNumber	L’identificativo univoco di ogni fattura cliente, che funge da identificativo principale del caso per il processo di fatturazione.
Descrizione L’Invoice Number è la chiave centrale che raggruppa tutte le attività relative a un singolo documento di fatturazione. Consente un’analisi completa, dall’inizio alla fine, del ciclo di vita della fattura, dalla generazione e approvazione fino al pagamento del cliente e alla chiusura definitiva. Utilizzandolo come Case ID, ogni voce dell’Event Log corrisponde a una fattura specifica, permettendo un’analisi dettagliata delle varianti, il calcolo dei tempi di ciclo e il monitoraggio delle prestazioni per ogni transazione di fatturazione. Perché è importante Questo Attributo è essenziale per monitorare l’intero ciclo di vita di una fattura e consente di analizzare l’efficienza del processo, i colli di bottiglia e le deviazioni per ogni singolo documento di fatturazione. Dove reperirlo Si trova generalmente nel modulo Sales and marketing, in tabelle come CustInvoiceJour, nel campo InvoiceId, oppure è esposto tramite entità dati come SalesInvoiceHeaderV2. Esempi CIV-001254INV-2023-9876US-004321
	Nome dell’attività ActivityName	Il nome dell’attività aziendale o dell’evento verificatosi in uno specifico momento del ciclo di vita della fattura.
Descrizione Questo Attributo descrive una fase o una tappa specifica del processo di fatturazione, come 'Invoice Generated', 'Invoice Approved' o 'Customer Payment Received'. La sequenza di queste attività forma il flusso del processo. L’analisi delle attività è fondamentale per il process mining, poiché consente di scoprire i modelli di processo, identificare le varianti e misurare le prestazioni tra le diverse fasi. Perché è importante Definisce le fasi del processo, consentendo di visualizzare le mappe di processo, analizzare le varianti e identificare i colli di bottiglia o le deviazioni dalla procedura standard. Dove reperirlo Questo Attributo deriva generalmente da più fonti, come i campi di modifica dello stato, ad esempio DocumentState, specifici campi data valorizzati o i log della cronologia del Workflow in Microsoft Dynamics 365. Esempi Fattura generataFattura approvataPagamento del cliente ricevutoNota di credito emessa
	Ora dell’evento EventTime	Il timestamp preciso che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione Event Time, noto anche come timestamp, 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. Vengono utilizzati per calcolare i tempi di ciclo tra le attività, misurare la durata complessiva di un caso e comprendere l’andamento delle prestazioni nel tempo. Timestamp accurati e affidabili sono alla base di KPI come Days Sales Outstanding e Invoice Generation Time. Perché è importante È l’Attributo fondamentale per tutte le analisi delle prestazioni e degli aspetti temporali, poiché consente di calcolare tempi di ciclo, durate e throughput per misurare l’efficienza del processo. Dove reperirlo I timestamp provengono da diversi campi di data e ora presenti nelle varie tabelle di Dynamics 365, come CreatedDateTime nella tabella CustInvoiceJour per la generazione della fattura o specifici timestamp della cronologia del Workflow. 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 Payment Due Date è un campo data fondamentale, calcolato sulla base della data della fattura e delle condizioni di pagamento del cliente. Costituisce il riferimento per misurare la puntualità dei pagamenti. Questo attributo è essenziale per il Dashboard "Payment Terms Adherence Analysis" e per il calcolo di KPI come "On-Time Payment Rate" e "Days Sales Outstanding". Il confronto tra questa data e la data effettiva del pagamento consente di comprendere il comportamento di pagamento dei clienti e l'efficacia del processo di recupero crediti. Perché è importante Costituisce il riferimento per misurare le prestazioni dei pagamenti. È essenziale per calcolare la percentuale di pagamenti puntuali e analizzare il rispetto delle condizioni di pagamento concordate con i clienti. Dove reperirlo 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 sulla fattura. È una metrica fondamentale per l’analisi finanziaria, poiché consente di segmentare le fatture in base al valore. Ad esempio, gli analisti possono concentrarsi sulle fatture di importo elevato per comprenderne i comportamenti di pagamento o verificare se richiedono tempi di approvazione più lunghi. È inoltre essenziale per calcolare il valore totale delle fatture aperte e il DSO. Perché è importante Consente di analizzare l’impatto finanziario, filtrando e segmentando i processi in base al valore monetario per dare priorità alle fatture di importo elevato e comprenderne i comportamenti specifici nel processo. Dove reperirlo Si trova nella tabella CustInvoiceJour, generalmente 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 al quale è stata emessa la fattura.
Descrizione Il nome del cliente fornisce un identificativo leggibile per l'azienda o la persona a cui viene emessa la fattura. Nell'analisi di Process Mining, consente di segmentare il processo di fatturazione per cliente. In questo modo è possibile individuare quali clienti pagano regolarmente nei tempi previsti, quali sono spesso in ritardo o se determinati gruppi di clienti presentano variazioni o ritardi specifici nel processo. È fondamentale per i Dashboard relativi al comportamento di pagamento dei clienti e per l'analisi dei Days Sales Outstanding. Perché è importante Consente di segmentare l'analisi del processo per cliente, aiutando a identificare comportamenti specifici dei clienti, modelli di pagamento o problemi di processo. Dove reperirlo Queste informazioni vengono recuperate unendo i dati delle fatture alla tabella dei dati anagrafici dei clienti, in genere CustTable, sulla base del numero di conto 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 organizzativo, ad esempio "Accounts Receivable" o "Sales". Consente di ottenere una visione delle prestazioni del processo a un livello più ampio rispetto al singolo utente. L'analisi per reparto aiuta a comprendere i passaggi di consegna tra funzioni, confrontare l'efficienza dei diversi team e identificare i colli di bottiglia a livello di reparto, come richiesto dal Dashboard "Billing Department Activity Load". Perché è importante Consente di analizzare le prestazioni a livello organizzativo, confrontando l'efficienza dei diversi team e comprendendo in che modo i passaggi di consegna tra reparti incidono sul processo. Dove reperirlo In genere non si tratta di un campo diretto della transazione della fattura. Viene ricavato 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 attuale della fattura nel suo ciclo di vita, ad esempio Open, Paid o Canceled.
Descrizione Questo attributo fornisce una fotografia dello stato attuale della fattura. Indica se la fattura è ancora in attesa di pagamento, è stata pagata integralmente, è scaduta o è stata annullata tramite una nota di credito. È utile per filtrare i casi e analizzare soltanto le fatture aperte oppure per confermare 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 fotografia dello stato attuale della fattura, utile per filtrare i casi e comprendere gli esiti delle diverse varianti di processo. Dove reperirlo Può essere ricavato dallo stato del pagamento della fattura, verificando spesso se il saldo del record CustTrans associato è pari a zero. Non è sempre disponibile un unico campo "status". Esempi ApertaPagataScadutaAnnullata
	Utente responsabile UserResponsible	L'utente o il dipendente responsabile dell'esecuzione di una determinata attività.
Descrizione Questo attributo identifica la persona che ha eseguito una determinata attività nel processo di fatturazione, ad esempio l'approvazione di una fattura o la registrazione di un incasso. È fondamentale per analizzare i carichi di lavoro, confrontare le prestazioni e individuare le esigenze formative. Ad esempio, il Dashboard "Billing Department Activity Load" utilizza questo attributo per verificare se il lavoro è distribuito in modo equilibrato o se determinati utenti rappresentano colli di bottiglia. Inoltre, aiuta a comprendere l'allocazione delle risorse e l'efficienza operativa. Perché è importante Consente di analizzare il processo a livello di risorsa, aiutando a identificare i colli di bottiglia, misurare le prestazioni individuali o del team e analizzare la distribuzione del carico di lavoro all'interno del reparto fatturazione. Dove reperirlo Può essere ricavato dai log della cronologia del Workflow, ad esempio WorkflowTrackingStatusTable, oppure da campi di proprietà come Owner o ModifiedBy presenti nelle tabelle pertinenti. Esempi John SmithAlicia BakerAmministratore di sistema
	Condizioni di pagamento PaymentTerms	Le condizioni concordate per il pagamento della fattura, ad esempio Net 30 o Net 60.
Descrizione Le Payment Terms definiscono le regole che stabiliscono entro quando il cliente dovrebbe pagare una fattura. Questo attributo viene utilizzato per calcolare la Payment Due Date ed è una dimensione fondamentale per analizzare il comportamento di pagamento. Il Dashboard "Payment Terms Adherence Analysis" utilizza questo attributo per raggruppare clienti e fatture e verificare se determinate condizioni di pagamento siano più o meno efficaci o siano associate a percentuali più elevate di pagamenti in ritardo. Perché è importante Fornisce il contesto per comprendere perché una fattura scade in una determinata data e consente di segmentare l'analisi per verificare se alcune condizioni di pagamento siano correlate ai pagamenti in ritardo. Dove reperirlo In genere viene memorizzato nell'anagrafica del cliente, ma copiato nell'intestazione della fattura. Nella tabella CustInvoiceJour, cerchi un campo come Payment o PaymTermId. Esempi 30 giorni netti60 giorni nettiPagamento alla ricezione
	È soggetta a rilavorazione IsRework	Un indicatore che segnala se il processo della fattura ha incluso attività di rilavorazione, come approvazioni multiple.
Descrizione Si tratta di un attributo booleano calcolato che segnala le fatture sottoposte a rilavorazione. La rilavorazione può essere definita dalla presenza di più eventi "Invoice Approved" o da storni di pagamento. Questo attributo è progettato specificamente per supportare il Dashboard "Invoice Rework Analysis" e il KPI "Invoice Rework Rate". Isolando questi casi, gli analisti possono indagare le cause alla radice della rilavorazione, che spesso indicano inefficienze di processo, problemi di qualità dei dati o lacune formative. Perché è importante Questo indicatore quantifica direttamente l'inefficienza del processo identificando i casi caratterizzati da azioni ripetitive o correttive e aiutando a individuare le cause alla radice degli sprechi e dei ritardi. Dove reperirlo 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 dei crediti commerciali DaysSalesOutstanding	Il numero di giorni compreso tra la generazione della fattura e la ricezione del pagamento del cliente.
Descrizione I Days Sales Outstanding (DSO) sono un indicatore finanziario fondamentale che misura il numero medio di giorni necessari a un'azienda per incassare un pagamento dopo una vendita. Questo attributo calcolato determina tale durata per ogni singola fattura. È la metrica principale del Dashboard "Days Sales Outstanding Trend Analysis" e del KPI "DSO". L'analisi del DSO aiuta a gestire il flusso di cassa e a valutare l'efficienza delle funzioni di credito e recupero crediti. Perché è importante È un KPI fondamentale per misurare la solidità del flusso di cassa di un'azienda e l'efficienza del processo di recupero crediti. Quantifica la rapidità con cui i ricavi vengono convertiti in disponibilità liquide. Dove reperirlo Questo attributo non è presente nel sistema di origine. Viene calcolato come durata compresa tra l'attività "Invoice Generated" e l'attività "Customer Payment Received". Esempi 284592
	Numero dell'ordine di vendita SalesOrderNumber	L'identificativo dell'ordine di vendita da cui ha avuto origine la fattura.
Descrizione Il Sales Order Number collega il processo di fatturazione al processo di vendita precedente. Questo collegamento è prezioso per un'analisi Order-to-Cash completa e end-to-end. Consente agli analisti di verificare in che modo i problemi del processo di vendita e di evasione, come modifiche all'ordine o ritardi nella spedizione, possano influire 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 end-to-end più completa per identificare le cause alla radice dei problemi di fatturazione. Dove reperirlo 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 o prima di essa.
Descrizione Questo attributo booleano calcolato confronta il timestamp "Customer Payment Received" con la "Payment Due Date". Classifica ogni fattura come pagata puntualmente o in ritardo. È il componente principale per il calcolo del KPI "On-Time Payment Rate" e viene utilizzato ampiamente nel Dashboard "Payment Terms Adherence Analysis". Fornisce un esito chiaro e binario sulle prestazioni dei pagamenti, semplificando l'analisi e la reportistica. Perché è importante Misura direttamente il rispetto delle condizioni di pagamento da parte del cliente e costituisce la base del KPI On-Time Payment Rate, semplificando l'analisi dell'efficacia del processo di recupero crediti. Dove reperirlo 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 un pagamento ha richiesto una rettifica manuale durante la registrazione dell'incasso.
Descrizione Questo attributo booleano segnala i pagamenti che hanno richiesto un intervento manuale o una correzione durante il processo di registrazione degli incassi. È fondamentale per il KPI "Cash Application Discrepancy Rate", poiché 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 i tassi di elaborazione straight-through. Perché è importante Questo attributo aiuta a identificare gli attriti e le imprecisioni nel passaggio di registrazione degli incassi, un aspetto essenziale per migliorare l'automazione e ridurre il lavoro manuale. Dove reperirlo 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 causale utilizzati durante la riconciliazione dei pagamenti. Consulti la documentazione di Microsoft Dynamics 365. Esempi truefalse
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati.
Descrizione Questo Attributo identifica l’origine dei dati di processo. In questo contesto specifica che i dati provengono da Microsoft Dynamics 365. È importante negli ambienti multisistema per distinguere le fonti dei dati e garantire la chiarezza della loro provenienza, facilitando la convalida dei dati e la risoluzione dei problemi. Perché è importante Fornisce un contesto essenziale sull’origine dei dati, indispensabile per la governance dei dati, la convalida e l’unione di dati provenienti da più sistemi aziendali. Dove reperirlo È un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l’origine del dataset. Esempi Microsoft Dynamics 365 FinanceD365 F&O
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l’ultima volta in cui i dati relativi a questo evento sono stati aggiornati dal sistema di origine.
Descrizione Questo Attributo registra il momento dell’ultima estrazione o dell’ultimo aggiornamento dei dati da Microsoft Dynamics 365. È un campo di metadati fondamentale per comprendere l’aggiornamento dei dati analizzati. Aiuta analisti e utenti aziendali a sapere se stanno consultando le informazioni più recenti ed è essenziale per gestire le pianificazioni di aggiornamento dei dati e garantire l’affidabilità dell’analisi. Perché è importante Garantisce che gli utenti comprendano quanto siano recenti i dati, un aspetto fondamentale per la governance dei dati, la gestione dell’aggiornamento dei Dashboard e l’affidabilità della tempestività degli insight. Dove reperirlo Questo Attributo viene generato e applicato al dataset durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Esempi 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Valuta Currency	Il codice valuta dell’importo della fattura, ad esempio USD o 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 questo contesto, aggregare o confrontare gli importi delle fatture sarebbe privo di significato. Consente di effettuare conversioni valutarie corrette e di produrre report e analisi finanziarie accurate tra regioni diverse. Perché è importante Fornisce il contesto essenziale per qualsiasi metrica finanziaria, come Invoice Amount, evitando aggregazioni errate e consentendo analisi accurate negli ambienti multivaluta. Dove reperirlo Si trova nella tabella CustInvoiceJour, generalmente in un campo come CurrencyCode. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività di Order to Cash - Fatturazione ed emissione delle fatture

Queste sono le fasi e le tappe fondamentali del processo da acquisire nell’Event Log per una corretta individuazione e analisi del processo.

7 Consigliato 5 Facoltativo

	Attività	Descrizione
	Fattura approvata	Indica il completamento del processo di revisione interna, durante il quale la fattura viene approvata formalmente. Questo evento viene registrato dal sistema Workflow di Dynamics 365 e segnala che la fattura è pronta per essere inviata al cliente.
Perché è importante È una tappa fondamentale per misurare il tempo del ciclo di approvazione. I ritardi in questa fase possono aumentare direttamente il tempo complessivo necessario per ricevere il pagamento dal cliente. Dove reperirlo Viene registrato nelle tabelle della cronologia del Workflow, come WorkflowTrackingStatusTable, come fase di completamento o approvazione della specifica istanza del Workflow della fattura. Acquisizione Estrarre gli Event Log del Workflow in cui lo stato è 'Approved' o 'Completed'. Tipo di evento explicit
	Fattura chiusa	Questa attività indica lo stato finale di una fattura, il cui saldo è pari a zero perché è stata pagata integralmente o compensata con note di credito. Non si tratta di una transazione diretta, ma di uno stato dedotto in base alla situazione finanziaria della fattura.
Perché è importante Questo evento indica il completamento con successo del ciclo Order to Cash per una singola fattura. Il tempo necessario per raggiungere questo stato è una misura primaria dell’efficienza complessiva del processo. Dove reperirlo Viene dedotto verificando se la transazione della fattura nella tabella CustTrans presenta un saldo residuo pari a zero. Ciò viene determinato confrontando l’importo della fattura con l’importo totale compensato a suo fronte. Acquisizione Derivare dai record CustTrans in cui AmountCur è uguale a SettleAmountCur. Il timestamp corrisponde alla data dell’ultima compensazione. Tipo di evento inferred
	Fattura generata	Rappresenta la creazione e la registrazione del documento di fattura di vendita nel sistema. Si tratta di una transazione esplicita in Dynamics 365 che crea un documento legale e le registrazioni finanziarie nel sottolibro dei crediti verso clienti.
Perché è importante Questo è l’inizio ufficiale del ciclo di fatturazione di una fattura. È un evento fondamentale per monitorare i Days Sales Outstanding (DSO) e la durata complessiva del processo. Dove reperirlo Viene acquisito dal timestamp di creazione della registrazione della fattura di vendita registrata nella tabella CustInvoiceJour. Al momento della registrazione, le transazioni finanziarie corrispondenti vengono create nelle tabelle GeneralJournalEntry e LedgerEntry. Acquisizione Utilizzare il campo CreatedDateTime della tabella CustInvoiceJour per la fattura registrata. Tipo di evento explicit
	Fattura inviata al cliente	Questa attività rappresenta il momento in cui la fattura viene trasmessa al cliente, per via elettronica o fisica. In Dynamics 365 può essere un evento esplicito se l’invio avviene tramite l’e-mail del sistema oppure può essere dedotta come coincidente con il momento della registrazione, se non è attivo alcun tracciamento specifico.
Perché è importante Misura l’efficienza del processo di consegna della fattura. Un ritardo tra l’approvazione e l’invio prolunga inutilmente il ciclo di pagamento. Dove reperirlo Può essere acquisito esplicitamente dai log delle e-mail, come SysOutgoingEmailTable, se si utilizzano le funzionalità e-mail di D365. In caso contrario, spesso viene dedotto come coincidente con l’orario di registrazione della fattura nella tabella CustInvoiceJour. Acquisizione Utilizzare il timestamp del log e-mail, se disponibile; in caso contrario, utilizzare il timestamp di registrazione della fattura. Tipo di evento inferred
	Incasso applicato alla fattura	Rappresenta la compensazione di un pagamento cliente con una fattura specifica, riducendo il saldo residuo della fattura. Si tratta di una fase distinta in Dynamics 365, che collega la transazione del pagamento alla transazione della fattura.
Perché è importante È una tappa fondamentale per calcolare con precisione il DSO e comprendere l’efficienza del team che gestisce l’applicazione degli incassi. Indica il momento in cui il pagamento viene completamente riconciliato con quanto fatturato. Dove reperirlo Viene registrato nella tabella CustSettlement. Il campo della data di compensazione in questa tabella fornisce il timestamp del momento in cui uno specifico pagamento è stato applicato a una specifica transazione di fattura. Acquisizione Utilizzare TransDate o CreatedDateTime dalla tabella CustSettlement. Tipo di evento explicit
	Pagamento del cliente ricevuto	Questa attività indica la creazione di una registrazione contabile per registrare un pagamento ricevuto da un cliente. Segnala che il denaro è stato ricevuto, ma non è ancora stato applicato a una fattura specifica.
Perché è importante Questo è il punto di partenza per misurare il tempo di attraversamento dell’applicazione dell’incasso. Consente di distinguere tra la ricezione del denaro e la sua effettiva riconciliazione con le fatture aperte. Dove reperirlo Viene acquisito dalla creazione o dalla registrazione di un giornale dei pagamenti del cliente. È registrato in tabelle come LedgerJournalTrans, che al momento della registrazione crea una transazione cliente in CustTrans. Acquisizione Utilizzare il timestamp di registrazione del giornale dei pagamenti del cliente proveniente da LedgerJournalTable. Tipo di evento explicit
	Raggiunta la data di scadenza del pagamento	Un evento calcolato che si verifica quando viene raggiunta la data di scadenza della fattura senza che il pagamento sia stato applicato integralmente. Questa attività non corrisponde a una transazione nel sistema, ma viene derivata dai dati esistenti.
Perché è importante Questo evento è fondamentale per analizzare i tassi di pagamento puntuale e identificare le fatture che stanno diventando scadute. Costituisce il punto di attivazione delle attività di incasso e sollecito. Dove reperirlo Non viene registrato come evento. Viene calcolato utilizzando il campo DueDate della tabella CustInvoiceJour. Il timestamp dell’evento corrisponde alla data di scadenza stessa. Acquisizione Creare un evento il cui timestamp corrisponda al valore del campo CustInvoiceJour.DueDate. Tipo di evento calculated
	Fattura inviata per l’approvazione	Questa attività indica che una fattura generata è stata inserita in un Workflow formale di approvazione. È una prassi comune nelle organizzazioni che prevedono controlli e una revisione manageriale prima dell’invio della fattura al cliente. In D365 viene registrata come fase specifica nel motore Workflow.
Perché è importante Monitorare l’invio per l’approvazione aiuta a separare il tempo di creazione della fattura dal tempo di attesa dell’approvazione. È il primo passaggio per analizzare l’efficienza dei processi interni di revisione e controllo. Dove reperirlo Viene acquisito dalle tabelle della cronologia del Workflow, come WorkflowTrackingStatusTable, filtrando l’evento di invio associato al documento della fattura. Acquisizione Estrarre gli Event Log del Workflow in cui lo stato è 'Submitted'. Tipo di evento explicit
	Nota di credito emessa	Rappresenta la creazione di una nota di credito o di un credit memo, generalmente per correggere un errore di fatturazione, applicare una rettifica di prezzo o contabilizzare merci restituite. Una nota di credito è essenzialmente una fattura negativa.
Perché è importante La frequente emissione di note di credito può indicare problemi sistemici nel processo di evasione degli ordini o di fatturazione. Analizzare le ragioni dell’emissione delle note di credito è fondamentale per migliorare il processo e ridurre le perdite di ricavi. Dove reperirlo Si tratta di una transazione esplicita, registrata come una nuova fattura contabilizzata con un importo negativo nella tabella CustInvoiceJour. Spesso è collegata alla fattura originale tramite un campo di riferimento. Acquisizione Identificare i record in CustInvoiceJour con un importo totale negativo e collegarli alla fattura originale. Tipo di evento explicit
	Ordine di vendita evaso	Questa attività indica il momento in cui le merci sono state spedite o i servizi sono stati erogati per un ordine di vendita, dando avvio al processo di fatturazione. In genere viene dedotta dalla registrazione di un packing slip o di una nota di consegna in Microsoft Dynamics 365, che modifica lo stato delle righe dell’ordine di vendita correlate.
Perché è importante Questo evento costituisce il punto di partenza per misurare il tempo del ciclo di generazione della fattura. Comprendere il ritardo tra evasione e fatturazione aiuta a individuare i colli di bottiglia amministrativi che possono incidere sul flusso di cassa. Dove reperirlo Viene dedotto dalla data di creazione della registrazione del packing slip collegata all’ordine di vendita. Sono coinvolte tabelle come CustPackingSlipJour e CustPackingSlipTrans, correlate all’ordine di vendita su cui si basa la fattura. Acquisizione Identificare la data più recente di registrazione del packing slip per l’ordine di vendita associato alla fattura. Tipo di evento inferred
	Pagamento stornato	Questa attività indica lo storno di un pagamento cliente registrato in precedenza. Può verificarsi a causa di errori come una registrazione errata, fondi insufficienti o altri problemi di pagamento.
Perché è importante Gli storni dei pagamenti evidenziano errori operativi o problemi relativi ai pagamenti dei clienti. Analizzarne la frequenza aiuta a individuarne le cause alla radice e a migliorare l’accuratezza del processo di applicazione degli incassi. Dove reperirlo Viene acquisito come storno di una transazione nella contabilità generale. Un giornale stornato può essere identificato in GeneralJournalEntry, spesso tramite un flag specifico o attraverso la relazione con la transazione originale. Acquisizione Identificare le registrazioni contabili con un flag di storno o con un riferimento a una transazione stornata. Tipo di evento explicit
	Promemoria di pagamento emesso	Rappresenta l’invio di una lettera di sollecito o di una comunicazione di incasso al cliente in merito a una fattura scaduta. Dynamics 365 dispone di un processo formale di sollecito che genera e registra queste comunicazioni.
Perché è importante Monitorare i promemoria aiuta a valutare l’efficacia del processo di sollecito e consente di analizzare quanti promemoria sono necessari prima di ricevere un pagamento. Dove reperirlo È un evento esplicito acquisito dalla data di creazione della registrazione della lettera di sollecito nella tabella CustCollectionLetterJour, collegata alla transazione della fattura scaduta. Acquisizione Utilizzare il timestamp di creazione della tabella CustCollectionLetterJour. Tipo di evento explicit

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Microsoft Dynamics 365

Passaggi

Acceda al Data Management Workspace: acceda a Microsoft Dynamics 365 Finance and Operations. Utilizzi la barra di ricerca per trovare e aprire il Workspace Data management. Questo è il centro operativo per tutte le attività di importazione ed esportazione dei dati.
Crei un nuovo progetto di esportazione: nel Workspace Data management, faccia clic sul riquadro Export per creare un nuovo progetto di esportazione dei dati. Assegni al progetto un nome significativo, ad esempio ProcessMind_O2C_Billing_Export, e una descrizione.
Selezioni il formato 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à, assicurandosi di utilizzare un delimitatore e un qualificatore di testo comuni.
Aggiunga le entità dati richieste: questo è il passaggio più importante. Aggiunga al progetto diverse entità dati standard per acquisire tutte le attività necessarie. Per ogni entità, faccia clic su Add entity e cerchi il nome dell'entità 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 i filtri alle entità: per limitare i dati a un ambito pertinente, applichi i filtri alle entità. Come minimo, filtri Sales invoice headers V2 per InvoiceDate in relazione a un periodo specifico, ad esempio gli ultimi 6 mesi. Filtri inoltre i dati in base alle specifiche entità giuridiche, ovvero alle società, che desidera analizzare.
Esegua il processo di esportazione: dopo aver aggiunto tutte le entità e applicato i filtri, faccia clic sul pulsante Export nel riquadro delle azioni. Il sistema creerà un pacchetto di processo e avvierà in background l'estrazione dei dati.
Monitori e scarichi i dati: può monitorare l'avanzamento del processo nella sezione Job history. Al termine dell'esecuzione, se il processo è stato completato correttamente, potrà scaricare il pacchetto di dati esportato. Il pacchetto sarà un file ZIP contenente file CSV separati per ciascuna entità dati.
Decomprima il pacchetto: estragga il contenuto del file ZIP scaricato in una cartella locale. Ora disporrà di più file CSV, uno per ogni entità.
Trasformi e combini i dati: i file grezzi devono essere trasformati in un unico Event Log. Utilizzi uno strumento di preparazione dei dati come Power Query, Python o un'area di staging del database. Per ogni file di origine, crei le colonne richieste: InvoiceNumber (Case ID), ActivityName (un valore codificato che rappresenta l'evento, come 'Invoice Generated') ed EventTime (il campo data pertinente del file di origine). Mappi gli altri attributi, come InvoiceAmount e CustomerName.
Unisca tutti i dati trasformati: combini i dati trasformati di tutti i file di origine in un'unica tabella utilizzando un'operazione di unione o accodamento. In questo modo creerà l'Event Log unificato finale, in cui ogni riga rappresenta un'attività del ciclo di vita della fattura.
Applichi la formattazione finale per il caricamento: verifichi che il file CSV finale contenga le intestazioni di colonna corrette (InvoiceNumber, ActivityName, EventTime ecc.) e che la colonna EventTime utilizzi un formato timestamp coerente, 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 entità principali figurano Sales invoice headers V2 (per fatture e note di credito), Sales packing slip headers (per l'evasione degli ordini), CustPaymentJournalLineEntity (per i pagamenti), Customer settlement (per la registrazione degli incassi) e Workflow tracking status table (per le approvazioni).
Formato di esportazione: il formato dati di destinazione consigliato è CSV, grazie alla sua ampia compatibilità con gli strumenti di trasformazione dei dati.
Filtro dell'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, così da mantenere gestibile l'esportazione e disporre al contempo di dati sufficienti per l'analisi.
Filtro per società: l'esportazione deve essere filtrata in base alla specifica entità giuridica o al codice società analizzato, per garantire la pertinenza dei dati e ridurre le dimensioni dell'esportazione.
Staging e trasformazione dei dati: è necessario eseguire una fase di post-elaborazione esterna a Dynamics 365. I file esportati devono essere combinati e ristrutturati in un unico formato di 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, in genere un ruolo con autorizzazioni per il Workspace Data management e accesso alle entità dati richieste.

a 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, insieme alle librerie requests e pandas. Avrà inoltre bisogno delle credenziali di un service principal (App Registration) 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 client secret e annoti l'ID applicazione (client), l'ID directory (tenant) e il client secret. In Dynamics 365, aggiunga l'ID dell'applicazione in System administration > Setup > Azure Active Directory applications e assegni i diritti utente appropriati per leggere le entità dati richieste.
Configuri lo script: apra lo script Python fornito. Compili le variabili di configurazione nella parte iniziale dello script, tra cui d365_url, tenant_id, client_id, client_secret, company, start_date ed end_date. d365_url deve corrispondere all'URL di base dell'ambiente Dynamics 365, ad esempio https://your-d365-instance.operations.dynamics.com.
Autenticazione: lo script contiene una funzione get_access_token che utilizza automaticamente le Sue credenziali per richiedere un token di accesso OAuth2 alla piattaforma di identità Microsoft. Questo token è necessario per autorizzare le successive chiamate API.
Estrazione dei dati: esegua lo script dal terminale utilizzando 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à come pagamenti, registrazioni degli incassi, note di credito e cronologia del Workflow.
Generazione delle attività: lo script elabora i dati grezzi provenienti da più endpoint API. 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 ricava questi eventi sulla base della data di scadenza, dello stato e della cronologia delle registrazioni degli incassi della fattura, creando le voci corrispondenti nell'Event Log.
Gestione della paginazione: la funzione di supporto fetch_all_data è progettata per gestire automaticamente la paginazione. Le API OData di Dynamics 365 restituiscono un numero limitato di record per pagina; per questo la funzione segue @odata.nextLink fornito nella risposta API per recuperare l'intero set 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 standardizza 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 è formattato e pronto per essere caricato in ProcessMind o in un altro strumento di Process Mining.

Configurazione

URL D365: l’URL di base della Sua istanza di Dynamics 365 Finance & Operations. Questo è l’endpoint principale per tutte le chiamate API.
Credenziali Azure AD: per l’autenticazione sono necessari un client_id, un client_secret e un tenant_id. Devono appartenere a un’applicazione con accesso in lettura alle entità D365 pertinenti.
Società: specifichi il DataAreaId, che corrisponde all’entità giuridica in Dynamics 365 dalla quale desidera estrarre i dati, ad esempio «USMF».
Intervallo di date: definisca start_date e end_date per limitare l’ambito dell’estrazione. Per un’analisi iniziale, è consigliabile utilizzare un periodo compreso tra 3 e 6 mesi, così da mantenere gestibili le dimensioni del dataset e includere al contempo un numero sufficiente di varianti di 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 relativa a un periodo esteso o a una società di grandi dimensioni può richiedere tempo, poiché prevede numerose chiamate API sequenziali. È consigliabile eseguire lo script negli orari di minore utilizzo e iniziare con un intervallo di date più breve, per stimare la durata complessiva dell’esecuzione.

a 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 il percorso verso una fatturazione ottimizzata utilizzando questo Template. Offra al Suo team gli insight necessari per aumentare l'efficienza e migliorare il flusso di cassa.

Torna alla guida al miglioramento Scarica il Template

Elimini i ritardi nella fatturazione: ottimizzi oggi Order to Cash e la fatturazione

Riduca del 30% la durata del ciclo di fatturazione e raggiunga più rapidamente una visione chiara della situazione finanziaria.

Inizi la prova gratuita

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

Il Suo Template dei dati Order to Cash - Billing & Invoicing

Il Suo Template dei dati Order to Cash - Billing & Invoicing

Attributi di Order to Cash - Fatturazione ed emissione delle fatture

Attività di Order to Cash - Fatturazione ed emissione delle fatture

Guide all'estrazione

Esportazione delle entità dati di Microsoft Dynamics 365

Passaggi

Configurazione

a Query di esempio config

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

Passaggi

Configurazione

a Query di esempio python

Pronto a iniziare?

Elimini i ritardi nella fatturazione: ottimizzi oggi Order to Cash e la fatturazione

Il Suo Template dei dati Order to Cash - Billing & Invoicing

Il Suo Template dei dati Order to Cash - Billing & Invoicing

Attributi di Order to Cash - Fatturazione ed emissione delle fatture

Attività di Order to Cash - Fatturazione ed emissione delle fatture

Guide all'estrazione

Esportazione delle entità dati di Microsoft Dynamics 365

Passaggi

Configurazione

a Query di esempio config

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

Passaggi

Configurazione

a Query di esempio python

Pronto a iniziare?

Elimini i ritardi nella fatturazione: ottimizzi oggi Order to Cash e la fatturazione

La Sua privacy è importante