> Miglioramento Continuo dei Processi > Order to Cash Fatturazione e Contabilità > Microsoft Dynamics 365 > Template Dati

Il Suo Template Dati Order to Cash - Fatturazione e Contabilità

Microsoft Dynamics 365

← Torna alla Guida al Miglioramento

Attributi di Order to Cash - Fatturazione e Contabilità (18) Attività di Order to Cash - Fatturazione e Contabilità (12) Guide all'Estrazione (2)

Il Suo Template Dati Order to Cash - Fatturazione e Contabilità

Questo template fornisce una chiara roadmap per la raccolta dei punti dati essenziali necessari per analizzare il Suo processo Order to Cash - Fatturazione e Contabilità. Troverà gli attributi raccomandati da includere nel Suo event log, le attività chiave da tracciare e una guida pratica sull'estrazione di queste informazioni. È progettato per aiutarLa a impostare rapidamente i Suoi dati per un Process Mining approfondito.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione per Microsoft Dynamics 365

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

Scarica Template

Attributi di Order to Cash - Fatturazione e Contabilità

Questi sono i campi dati raccomandati da includere nel Suo event log per un'analisi completa di Order to Cash - Fatturazione e Contabilità.

3 Obbligatorio 6 Consigliato 9 Facoltativo

	Nome	Descrizione
	Numero fattura InvoiceNumber	L'identificatore unico per ogni fattura cliente, che funge da identificatore primario del caso per il processo di fatturazione.
Descrizione Il Numero Fattura è la chiave centrale che raggruppa tutte le attività relative a un singolo documento di fatturazione. Consente un'analisi completa e end-to-end del ciclo di vita della fattura, dalla generazione e approvazione al pagamento del cliente e alla chiusura finale. Utilizzando questo come Case ID, ogni voce dell'event log corrisponde a una fattura specifica, consentendo 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 tracciare l'intero ciclo di vita di una fattura, consentendo l'analisi dell'efficienza del processo, dei bottleneck e delle deviazioni per ogni singolo documento di fatturazione. Dove trovare Questo si trova tipicamente nel modulo Vendite e marketing, all'interno di tabelle come CustInvoiceJour (campo InvoiceId) o esposto tramite entità dati come SalesInvoiceHeaderV2. Esempi CIV-001254INV-2023-9876US-004321
	Nome attività ActivityName	Il nome dell'attività commerciale o dell'evento che si è verificato in un punto specifico del ciclo di vita della fattura.
Descrizione Questo attributo descrive un passo o una milestone specifica all'interno del processo di fatturazione, come 'Invoice Generated', 'Invoice Approved' o 'Customer Payment Received'. La sequenza di queste attività forma il flusso di processo. L'analisi delle attività è fondamentale per il Process Mining, poiché consente la scoperta di modelli di processo, l'identificazione di varianti e la misurazione delle prestazioni tra i diversi passi. Perché è importante Definisce i passi del processo, consentendo la visualizzazione delle mappe di processo, l'analisi delle varianti di processo e l'identificazione di bottleneck o deviazioni dalla procedura standard. Dove trovare Questo attributo è tipicamente derivato da più fonti, come campi di cambio stato (es. DocumentState), campi data specifici popolati o log di cronologia del workflow all'interno di Microsoft Dynamics 365. Esempi Fattura generataFattura ApprovataPagamento cliente ricevutoNota di credito emessa
	Timestamp Evento EventTime	Il timestamp preciso che indica quando si è verificata un'attività o un evento specifico.
Descrizione `Event Time`, noto anche come `timestamp`, registra la data e l'ora esatte per ogni attività nel processo. Questo `dato` è critico per tutte le analisi di `Process Mining` basate sul tempo. Viene utilizzato per calcolare i tempi di ciclo tra le attività, misurare la durata totale di un `case` e comprendere le prestazioni del processo nel tempo. `Timestamp` accurati e affidabili sono la base per KPI come i Giorni di Incasso Clienti e il Tempo di Generazione della Fattura. Perché è importante Questo è l'attributo fondamentale per tutte le analisi di performance e relative al tempo, consentendo il calcolo dei tempi di ciclo, delle durate e del throughput per misurare l'efficienza del processo. Dove trovare I timestamp sono ricavati da vari campi data e ora su diverse tabelle in Dynamics 365, come CreatedDateTime sulla tabella CustInvoiceJour per la generazione della fattura, o specifici timestamp di cronologia del workflow. Esempi 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Data Scadenza Pagamento PaymentDueDate	La data entro cui il cliente è tenuto a pagare la fattura.
Descrizione La Data di Scadenza del Pagamento è un campo data critico calcolato in base alla data della fattura e ai termini di pagamento del cliente. Serve come base per misurare la tempestività del pagamento. Questo attributo è essenziale per la dashboard 'Payment Terms Adherence Analysis' e per il calcolo di KPI come il 'Tasso di Pagamento Puntuale' e il 'Days Sales Outstanding'. Confrontare questa data con la data di pagamento effettiva rivela il comportamento di pagamento del cliente e l'efficacia del processo di riscossione. Perché è importante Questo è il benchmark per misurare le prestazioni di pagamento. È essenziale per calcolare i tassi di pagamento puntuale e analizzare l'aderenza ai termini di pagamento del cliente. Dove trovare Questo si trova tipicamente nella tabella CustInvoiceJour in un campo come DueDate. Esempi 2023-05-152023-06-302023-07-01
	Dipartimento Department	Il dipartimento aziendale associato all'utente o all'attività.
Descrizione Questo attributo assegna un'attività o un utente a uno specifico dipartimento organizzativo, come 'Contabilità Clienti' o 'Vendite'. Consente una visione di livello superiore delle prestazioni del processo rispetto al livello utente individuale. L'analisi per dipartimento aiuta a comprendere i passaggi di consegne interfunzionali, a confrontare l'efficienza tra i team e a identificare i bottleneck a livello di dipartimento, come richiesto dalla dashboard 'Billing Department Activity Load'. Perché è importante Consente l'analisi delle prestazioni a livello organizzativo, confrontando l'efficienza tra i diversi team e comprendendo come i passaggi tra i reparti influenzano il processo. Dove trovare Questo non è tipicamente un campo diretto sulla transazione della fattura. È derivato unendo l'ID UserResponsible con la directory dei dipendenti o utenti che contiene le informazioni del dipartimento. Esempi Crediti InsolutiFinanzaOperazioni di Fatturazione
	Importo Fattura InvoiceAmount	Il valore monetario totale della fattura.
Descrizione Questo attributo rappresenta l'importo totale dovuto sulla fattura. È una metrica critica per l'analisi finanziaria, consentendo la segmentazione delle fatture per valore. Ad esempio, gli analisti possono concentrarsi su fatture di alto valore per comprendere i loro comportamenti di pagamento o identificare se fatture più grandi richiedono tempi di approvazione più lunghi. È anche fondamentale per calcolare il valore totale delle fatture in sospeso e per i calcoli del DSO. Perché è importante Consente l'analisi dell'impatto finanziario, permettendole di filtrare e segmentare i processi per valore monetario al fine di dare priorità alle fatture di alto valore e comprenderne i comportamenti specifici di processo. Dove trovare Trovato nella tabella `CustInvoiceJour`, tipicamente in un campo come `InvoiceAmount`. Disponibile anche nelle tabelle delle transazioni correlate. Esempi 5430.5012500.00750.25
	Nome cliente CustomerName	Il nome del cliente a cui è stata emessa la fattura.
Descrizione Il nome del cliente fornisce un identificatore leggibile per l'azienda o l'individuo a cui è stata emessa la fattura. Nell'analisi di Process Mining, questo permette di segmentare il processo di fatturazione per cliente. Questo può rivelare quali clienti pagano costantemente in tempo, quali sono frequentemente in ritardo, o se certi gruppi di clienti sperimentano variazioni o ritardi unici nel processo. È fondamentale per le dashboard relative al comportamento di pagamento dei clienti e all'analisi del Days Sales Outstanding. Perché è importante Ciò consente di segmentare l'analisi del processo per cliente, contribuendo a identificare comportamenti specifici del cliente, modelli di pagamento o problemi di processo. Dove trovare Questa informazione è recuperata unendo i dati della fattura con la tabella dei dati anagrafici del cliente, tipicamente CustTable, in base al numero di conto cliente. Esempi Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Stato Fattura InvoiceStatus	Lo stato attuale della fattura nel suo ciclo di vita (es. Aperta, Pagata, Annullata).
Descrizione Questo attributo fornisce un'istantanea della situazione attuale della fattura. Indica se una fattura è ancora in attesa di pagamento, è stata completamente pagata, è scaduta o è stata annullata tramite una nota di credito. Questo è utile per filtrare i casi per analizzare solo le fatture aperte o per confermare l'esito finale di una fattura chiusa. Aiuta a comprendere il carico di lavoro attuale e lo stato finanziario dei crediti. Perché è importante Fornisce un'istantanea rapida dello stato attuale della fattura, utile per filtrare i casi e comprendere gli esiti delle diverse varianti di processo. Dove trovare Questo può essere derivato dallo stato di pagamento della fattura, spesso controllando se il saldo sul record CustTrans correlato è zero. Non esiste sempre un singolo campo 'stato'. Esempi ApertoPagatoScadutoAnnullato
	Utente Responsabile UserResponsible	L'utente o il dipendente responsabile dell'esecuzione di una specifica attività.
Descrizione Questo attributo identifica l'individuo che ha eseguito un particolare compito nel processo di fatturazione, come l'approvazione di una fattura o l'applicazione del contante. È cruciale per l'analisi del carico di lavoro, il confronto delle prestazioni e l'identificazione delle esigenze di formazione. Ad esempio, la dashboard 'Billing Department Activity Load' si basa su questo attributo per vedere se il lavoro è distribuito in modo uniforme o se certi utenti sono bottleneck. Aiuta anche a comprendere l'allocazione e l'efficienza delle risorse. Perché è importante Consente l'analisi a livello di risorsa, aiutando a identificare i bottleneck, a misurare le prestazioni individuali o del team e ad analizzare la distribuzione del carico di lavoro all'interno del dipartimento di fatturazione. Dove trovare Questo può essere ricavato dai log di cronologia del workflow (es. WorkflowTrackingStatusTable) o da campi di proprietà come Owner o ModifiedBy su tabelle pertinenti. Esempi John SmithAlicia BakerAmministratore di sistema
	Days Sales Outstanding DaysSalesOutstanding	Il numero di giorni tra la generazione della fattura e la ricezione del pagamento dal cliente.
Descrizione I Giorni di Incasso Clienti (DSO) sono una metrica finanziaria chiave che misura il numero medio di giorni necessari a un'azienda per riscuotere un pagamento dopo che una vendita è stata effettuata. Questo `attributo` calcolato computa questa durata per ogni singola fattura. È la metrica primaria per la `dashboard` 'Analisi del `Trend` dei Giorni di Incasso Clienti' e il KPI 'DSO'. L'analisi del DSO aiuta a gestire il flusso di cassa e a valutare l'efficienza della funzione crediti e incassi. Perché è importante Questo è un KPI critico per misurare la salute del cash flow di un'azienda e l'efficienza del suo processo di riscossione. Quantifica la velocità con cui i ricavi vengono convertiti in contante. Dove trovare Questo attributo non è presente nel sistema di origine. Viene calcolato come la durata tra l'attività 'Invoice Generated' e l'attività 'Customer Payment Received'. Esempi 284592
	È Pagamento Puntuale IsOnTimePayment	Un `flag` che indica se il pagamento del cliente è stato ricevuto entro o prima della data di scadenza.
Descrizione Questo attributo booleano calcolato confronta il timestamp 'Customer Payment Received' con la 'Payment Due Date'. Contrassegna ogni fattura come pagata in tempo o in ritardo. Questo è il componente principale per il calcolo del KPI 'On-Time Payment Rate' ed è ampiamente utilizzato nella dashboard 'Payment Terms Adherence Analysis'. Fornisce un esito chiaro e binario per le prestazioni di pagamento, semplificando l'analisi e la rendicontazione. Perché è importante Misura direttamente l'aderenza del cliente ai termini di pagamento ed è la base per il KPI "Tasso di Pagamento Puntuale", semplificando l'analisi dell'efficacia della riscossione. Dove trovare Questo attributo non è presente nel sistema di origine. Viene calcolato durante la trasformazione dei dati confrontando la data del pagamento con la PaymentDueDate. Esempi truefalse
	È una Rilavorazione IsRework	Un `flag` che indica se il processo di fatturazione ha coinvolto attività di rilavorazione, come approvazioni multiple.
Descrizione Questo è un attributo booleano calcolato che contrassegna le fatture che hanno subito rilavorazioni. La rilavorazione può essere definita come il fatto di avere più eventi 'Invoice Approved' o storni di pagamenti. Questo attributo è specificamente progettato per supportare la dashboard 'Invoice Rework Analysis' e il KPI 'Invoice Rework Rate'. Isolando questi casi, gli analisti possono indagare le cause profonde delle rilavorazioni, che spesso indicano inefficienze di processo, problemi di qualità dei dati o lacune nella formazione. Perché è importante Questo flag quantifica direttamente l'inefficienza del processo identificando i casi con azioni ripetitive o correttive, contribuendo a individuare le cause profonde di spreco e ritardo. Dove trovare Questo attributo non è disponibile nel sistema di origine. Viene calcolato nel livello di trasformazione dei dati verificando attività ripetute o specifici schemi di rilavorazione all'interno di un caso. Esempi truefalse
	Numero ordine di vendita SalesOrderNumber	L'identificatore dell'ordine di vendita che ha originato la fattura.
Descrizione Il Numero Ordine di Vendita collega il processo di fatturazione al precedente processo di vendita. Questa connessione è inestimabile per un'analisi Order-to-Cash più ampia e end-to-end. Permette agli analisti di indagare come i problemi nel processo di vendita e di evasione, come modifiche dell'ordine o ritardi di spedizione, possano influenzare il ciclo di fatturazione. Ad esempio, può aiutare a rispondere a domande come 'Le fatture derivanti da ordini di vendita complessi impiegano 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 profonde dei problemi di fatturazione. Dove trovare Trovato nell'intestazione della fattura o nei dettagli della riga, con collegamento all'ordine di vendita. Cercare un campo come `SalesId` nella tabella `CustInvoiceJour`. Esempi SO-009876SO-010234US-SO-00543
	Richiede Intervento Manuale RequiresManualIntervention	Un `flag` che indica se un pagamento ha richiesto una rettifica manuale durante l'applicazione degli incassi.
Descrizione Questo attributo booleano contrassegna i pagamenti che hanno richiesto intervento manuale o correzione durante il processo di applicazione del contante. Questo è fondamentale per il KPI 'Cash Application Discrepancy Rate', poiché aiuta a quantificare l'accuratezza e il livello di automazione della registrazione dei pagamenti. Identificare le ragioni dell'intervento manuale, come informazioni di rimessa mancanti o discrepanze di pagamento, può portare a miglioramenti di processo che aumentano i tassi di straight-through processing. Perché è importante Questo attributo aiuta a identificare l'attrito del processo e le imprecisioni nel passo di applicazione del contante, che è cruciale per migliorare l'automazione e ridurre lo sforzo manuale. Dove trovare Questa informazione potrebbe essere inferita dall'utente che ha registrato il pagamento (se non è un utente di sistema) o da codici di motivo specifici utilizzati durante la riconciliazione del pagamento. Consulti la documentazione di Microsoft Dynamics 365. Esempi truefalse
	Sistema di Origine SourceSystem	Il sistema da cui i dati sono stati estratti.
Descrizione Questo attributo identifica l'origine dei dati di processo. In questo contesto, specifica che i dati provengono da Microsoft Dynamics 365. Questo è importante negli ambienti multi-sistema per differenziare le fonti di dati e garantire che la lineage dei dati sia chiara, il che aiuta nella validazione dei dati e nella risoluzione dei problemi. Perché è importante Fornisce un contesto cruciale sull'origine dei dati, essenziale per la governance dei dati, la validazione e la fusione di dati provenienti da più sistemi aziendali. Dove trovare Questo è un valore statico aggiunto durante il processo di estrazione e trasformazione dei `dati` per etichettare l'origine del `dataset`. Esempi Microsoft Dynamics 365 FinanceD365 F&O
	Termini di Pagamento PaymentTerms	Le condizioni concordate per il pagamento delle fatture (es. Net 30, Net 60).
Descrizione I Termini di Pagamento definiscono le regole per quando un cliente è tenuto a pagare una fattura. Questo attributo è usato per calcolare la Data di Scadenza del Pagamento ed è una dimensione chiave per analizzare il comportamento di pagamento. La dashboard 'Payment Terms Adherence Analysis' utilizza questo attributo per raggruppare clienti e fatture al fine di vedere se certi termini di pagamento sono più o meno efficaci o sono associati a tassi più elevati di pagamenti in ritardo. Perché è importante Fornisce il contesto del perché una fattura è dovuta in una certa data e permette di segmentare l'analisi per vedere se determinati termini di pagamento correlano con pagamenti in ritardo. Dove trovare Questo è tipicamente memorizzato sul record anagrafico del cliente ma copiato nell'intestazione della fattura. Cerchi un campo Payment o PaymTermId sulla tabella CustInvoiceJour. Esempi Netto 30Netto 60Pagamento alla ricezione
	Ultimo `Data Update` LastDataUpdate	Il `timestamp` che indica l'ultima volta che i `dati` per questo `evento` sono stati aggiornati dal sistema sorgente.
Descrizione Questo attributo registra l'ultima estrazione o aggiornamento dei dati da Microsoft Dynamics 365. È un campo metadata cruciale per comprendere la freschezza dei dati analizzati. Aiuta gli analisti e gli utenti aziendali a sapere se stanno visualizzando le informazioni più attuali ed è vitale per la gestione degli orari di aggiornamento dei dati e per garantire l'affidabilità dell'analisi. Perché è importante Assicura che gli utenti comprendano la freschezza dei dati, fattore critico per la governance dei dati, la gestione dell'aggiornamento della dashboard e l'affidabilità della tempestività degli insight. Dove trovare Questo attributo è generato e impresso sul 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 per l'importo della fattura (es. USD, EUR).
Descrizione Questo attributo specifica la valuta in cui è denominato l'importo della fattura. È essenziale per le organizzazioni multinazionali che operano con diverse valute. Senza questo contesto, aggregare o confrontare gli importi delle fatture sarebbe privo di significato. Permette una corretta conversione di valuta e una rendicontazione e analisi finanziaria accurate in diverse regioni. Perché è importante Fornisce un contesto essenziale per qualsiasi metrica finanziaria come l'Importo Fattura, prevenendo aggregazioni errate e consentendo un'analisi accurata in ambienti multi-valuta. Dove trovare Trovato nella tabella `CustInvoiceJour`, tipicamente in un campo come `CurrencyCode`. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività di Order to Cash - Fatturazione e Contabilità

Questi sono i `passaggi chiave` del `processo` e le `pietre miliari` da acquisire nel tuo `event log` per un'`accurata scoperta` e `analisi dei processi`.

7 Consigliato 5 Facoltativo

	Activity	Descrizione
	Contante Applicato alla Fattura	Rappresenta il regolamento di un pagamento cliente rispetto a una fattura specifica, riducendo il saldo in sospeso della fattura. Questo è un passo distinto in Dynamics 365 che collega la transazione di pagamento alla transazione di fattura.
Perché è importante Questa è una milestone critica per calcolare accuratamente il DSO e comprendere l'efficienza del team di applicazione del contante. Segna il punto in cui il pagamento è completamente riconciliato con quanto fatturato. Dove trovare Registrato nella tabella CustSettlement. Il campo della data di regolamento in questa tabella fornisce il timestamp per quando un pagamento specifico è stato applicato a una specifica transazione di fattura. Acquisisci Utilizzi il TransDate o CreatedDateTime dalla tabella CustSettlement. Tipo di evento explicit
	Data Scadenza Pagamento Raggiunta	Un `event` calcolato che si verifica quando la data di scadenza della fattura viene raggiunta senza che un pagamento sia stato completamente applicato. Questa attività non corrisponde a una transazione nel sistema ma è derivata da `dati` esistenti.
Perché è importante Questo evento è cruciale per analizzare i tassi di pagamento puntuale e identificare le fatture che stanno diventando scadute. Funge da punto di innesco per le attività di riscossione e intimazione. Dove trovare Questo non è registrato come un evento. Viene calcolato utilizzando il campo DueDate dalla tabella CustInvoiceJour. Il timestamp dell'evento è la data di scadenza stessa. Acquisisci Creare un `event` in cui il `timestamp` è il valore del campo `CustInvoiceJour.DueDate`. Tipo di evento calculated
	Fattura Approvata	Segna il completamento del processo di revisione interno, dove la fattura è formalmente approvata. Questo evento è registrato dal sistema di workflow di Dynamics 365 e indica che la fattura è pronta per essere inviata al cliente.
Perché è importante Questa è una milestone chiave per misurare il tempo del ciclo di approvazione. Ritardi in questa fase possono aumentare direttamente il tempo complessivo per ricevere il pagamento dal cliente. Dove trovare Registrato nelle tabelle di cronologia del workflow, come WorkflowTrackingStatusTable, come passo di completamento o approvazione per la specifica istanza del workflow della fattura. Acquisisci Estraia gli `event log` del `workflow` dove lo stato è 'Approvato' o 'Completato'. Tipo di evento explicit
	Fattura Chiusa	Questa attività segna lo stato finale di una fattura, dove il suo saldo è zero in quanto è stata completamente pagata o regolata con note di credito. Questa non è una transazione diretta ma uno stato inferito basato sullo stato finanziario della fattura.
Perché è importante Questo evento significa il completamento riuscito del ciclo Order to Cash per una singola fattura. Il tempo impiegato per raggiungere questo stato è una misura primaria dell'efficienza complessiva del processo. Dove trovare Desunto verificando se la transazione della fattura nella tabella CustTrans ha un saldo residuo pari a zero. Ciò è determinato confrontando l'importo della fattura con l'importo totale saldato ad essa. Acquisisci Derivare dai record `CustTrans` dove `AmountCur` è uguale a `SettleAmountCur`. Il `timestamp` è la data dell'ultimo regolamento. Tipo di evento inferred
	Fattura generata	Rappresenta la creazione e la registrazione del documento della fattura di vendita nel sistema. Questa è una transazione esplicita in Dynamics 365 che crea un documento legale e voci finanziarie nel sottoconto clienti.
Perché è importante Questo è l'inizio ufficiale del ciclo di vita di fatturazione per una fattura. È un evento critico per il tracciamento del Days Sales Outstanding (DSO) e della durata complessiva del processo. Dove trovare Catturato dal `timestamp` di creazione del record della fattura di vendita registrata nella tabella `CustInvoiceJour`. Le corrispondenti transazioni finanziarie vengono create nelle tabelle `GeneralJournalEntry` e `LedgerEntry` al momento della registrazione. Acquisisci Utilizzi il campo CreatedDateTime dalla tabella CustInvoiceJour per la fattura registrata. Tipo di evento explicit
	Fattura inviata al cliente	Questa attività rappresenta il momento in cui la fattura è stata trasmessa al cliente, sia elettronicamente che fisicamente. In Dynamics 365, questo può essere un evento esplicito se inviato tramite email di sistema, o inferito che si verifichi al momento della registrazione se non è abilitato un tracciamento specifico.
Perché è importante Misura l'efficienza del processo di consegna delle fatture. Un ritardo tra l'approvazione e l'invio della fattura estende inutilmente il ciclo di pagamento. Dove trovare Può essere esplicitamente catturato dai `log` delle email come `SysOutgoingEmailTable` se si utilizzano le funzionalità email di D365. Altrimenti, è spesso dedotto essere lo stesso del tempo di registrazione della fattura da `CustInvoiceJour`. Acquisisci Utilizzi il timestamp del log email se disponibile; altrimenti, utilizzi il timestamp di registrazione della fattura. Tipo di evento inferred
	Pagamento cliente ricevuto	Questa attività segna la creazione di una voce di giornale per registrare un pagamento ricevuto da un cliente. Significa che il contante è stato ricevuto, ma non è ancora stato applicato a una fattura specifica.
Perché è importante Questo è il punto di partenza per misurare il lead time dell'applicazione del contante. Differenzia tra la ricezione del denaro e la sua effettiva riconciliazione con le fatture in sospeso. Dove trovare Catturato dalla creazione o registrazione di un giornale dei pagamenti clienti. Questo viene registrato in tabelle come `LedgerJournalTrans`, che poi crea una transazione cliente in `CustTrans` al momento della registrazione. Acquisisci Utilizzi il timestamp di registrazione del giornale pagamenti cliente dalla tabella LedgerJournalTable. Tipo di evento explicit
	Fattura Sottoposta ad Approvazione	Questa attività indica che una fattura generata è stata sottoposta a un workflow di approvazione formale. Ciò è comune nelle organizzazioni con controlli che richiedono una revisione da parte della direzione prima che una fattura venga inviata a un cliente. Questo è registrato come un passo specifico nel motore di workflow di D365.
Perché è importante Il tracciamento della sottomissione per l'approvazione aiuta a separare il tempo di creazione della fattura dal tempo di attesa per l'approvazione. È il primo passo nell'analisi dell'efficienza dei processi interni di revisione e controllo. Dove trovare Catturato dalle tabelle della cronologia del `workflow`, come `WorkflowTrackingStatusTable`, filtrando per l'`event` di invio relativo al documento di fattura. Acquisisci Estraia gli `event log` del `workflow` dove lo stato è 'Inviato'. Tipo di evento explicit
	Nota di credito emessa	Rappresenta la creazione di una nota di credito o di un memo di credito, tipicamente per correggere un errore di fatturazione, concedere un adeguamento del prezzo o contabilizzare merci restituite. Una nota di credito è essenzialmente una fattura negativa.
Perché è importante Le note di credito frequenti possono indicare problemi sistemici nel processo di evasione degli ordini o di fatturazione. Analizzare il motivo per cui vengono emesse le note di credito è fondamentale per il miglioramento del processo e la riduzione della perdita di entrate. Dove trovare Questa è una transazione esplicita, registrata come una nuova fattura registrata con un importo negativo nella tabella CustInvoiceJour. È spesso collegata alla fattura originale tramite un campo di riferimento. Acquisisci 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à segna il punto in cui le merci sono state spedite o i servizi erogati per un ordine di vendita, innescando il processo di fatturazione. È tipicamente inferita dalla registrazione di una bolla di accompagnamento o nota di consegna in Microsoft Dynamics 365, che modifica lo stato delle linee dell'ordine di vendita correlate.
Perché è importante Questo evento serve come punto di partenza per misurare il tempo di ciclo di generazione della fattura. Comprendere il ritardo tra l'evasione dell'ordine e la fatturazione aiuta a identificare i bottleneck amministrativi che possono influenzare il cash flow. Dove trovare Desunto dalla data di creazione di una voce di giornale della bolla di accompagnamento collegata all'ordine di vendita. Ciò implica tabelle come CustPackingSlipJour e CustPackingSlipTrans, che sono correlate all'ordine di vendita su cui si basa la fattura. Acquisisci Identificare la data di registrazione più recente della bolla di accompagnamento per l'ordine di vendita associato alla fattura. Tipo di evento inferred
	Pagamento Stornato	Questa attività significa lo storno di un pagamento cliente precedentemente registrato. Questo si verifica a causa di errori come una registrazione errata, fondi insufficienti o altri fallimenti di pagamento.
Perché è importante Gli storni di pagamento evidenziano errori operativi o problemi con i pagamenti dei clienti. Analizzare la loro frequenza aiuta a identificare le cause profonde e a migliorare l'accuratezza del processo di applicazione del contante. Dove trovare Catturato come storno di transazione nel libro mastro generale. Una registrazione stornata può essere identificata in `GeneralJournalEntry`, spesso con un `flag` specifico o dalla sua relazione con la transazione originale. Acquisisci Identificare le voci di giornale con un `flag` di storno o un riferimento a una transazione stornata. Tipo di evento explicit
	Sollecito di Pagamento Emesso	Rappresenta l'invio di una lettera di intimazione o di un avviso di riscossione a un cliente riguardo a una fattura scaduta. Dynamics 365 dispone di un processo formale di intimazione che genera e registra queste comunicazioni.
Perché è importante Tracciare i solleciti aiuta a valutare l'efficacia del processo di intimazione. Consente l'analisi di quanti solleciti sono necessari prima che un pagamento venga ricevuto. Dove trovare Questo è un evento esplicito catturato dalla data di creazione del giornale delle lettere di sollecito nella tabella CustCollectionLetterJour, che è collegata alla transazione della fattura scaduta. Acquisisci Utilizzi il timestamp di creazione dalla tabella CustCollectionLetterJour. Tipo di evento explicit

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i tuoi dati da Microsoft Dynamics 365

Fasi

Navigare allo spazio di lavoro Data management: Acceda a Microsoft Dynamics 365 Finance and Operations. Utilizzi la barra di ricerca per trovare e navigare allo spazio di lavoro Data management. Questo è l'hub centrale per tutte le operazioni di importazione ed esportazione dei dati.
Creare un nuovo progetto di esportazione: All'interno dello spazio di lavoro Data management, clicchi sul riquadro Export per creare un nuovo progetto di esportazione dei dati. Assegni al progetto un nome significativo, come ProcessMind_O2C_Billing_Export, e una descrizione.
Selezionare il formato dei dati di destinazione: Nella configurazione del progetto, specifichi il Target data format. Per la compatibilità con la maggior parte degli strumenti di trasformazione dei dati, selezioni CSV. Configuri le opzioni di formato come necessario, assicurando un delimitatore comune e un qualificatore di testo.
Aggiungere le entità di dati richieste: Questo è il passaggio più critico. Aggiungerà più entità di dati standard al Suo progetto per acquisire tutte le attività richieste. Per ogni entità, clicchi su Add entity e cerchi il nome dell'entità elencato nella sezione Query/Script. Aggiunga ciascuna delle seguenti entità al Suo progetto: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement e Dunning history letters.
Applicare i filtri di entità: Per limitare i dati a un ambito pertinente, applichi filtri alle Sue entità. Al minimo, filtri Sales invoice headers V2 per InvoiceDate per un periodo specifico, ad esempio gli ultimi 6 mesi. Inoltre, filtri per le specifiche entità giuridiche (aziende) che desidera analizzare.
Eseguire il lavoro di esportazione: Una volta aggiunte tutte le entità e applicati i filtri, clicchi sul pulsante Export nel riquadro delle azioni. Il sistema creerà un pacchetto di lavoro e inizierà l'elaborazione dell'estrazione dei dati in background.
Monitorare e scaricare i dati: Può monitorare l'avanzamento del lavoro nella sezione Job history. Una volta che il lavoro è completato con successo, può scaricare il pacchetto di dati esportato. Il pacchetto sarà un file ZIP contenente file CSV separati per ogni entità di dati.
Decomprimere il pacchetto: Estraiga il contenuto del file ZIP scaricato in una cartella locale. Avrà ora più file CSV, uno per ogni entità.
Trasformare e combinare 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 sorgente, crei le colonne richieste: InvoiceNumber (Case ID), ActivityName (un valore fisso che rappresenta l'event, come 'Fattura Generata') e EventTime (il campo data rilevante dal file sorgente). Mappi altri attributi come InvoiceAmount e CustomerName.
Unire tutti i dati trasformati: Combini i dati trasformati da tutti i file sorgente in un'unica tabella utilizzando un'operazione di unione o aggiunta. Questo crea l'event log finale e unificato in cui ogni riga rappresenta un'activity nel ciclo di vita della fattura.
Formattazione finale per il caricamento: Si assicuri che il file CSV finale abbia le intestazioni di colonna corrette (InvoiceNumber, ActivityName, EventTime, ecc.) e che la colonna EventTime sia in un formato timestamp coerente (ad esempio, AAAA-MM-GG HH:MI:SS). Questo file è ora pronto per il caricamento in ProcessMind.

Configurazione

Entità di dati: L'estrazione si basa su un set di entità di dati D365 standard. Le entità chiave includono 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 l'applicazione incassi) e Workflow tracking status table (per le approvazioni).
Formato di esportazione: Il formato di dati target raccomandato è CSV per la sua ampia compatibilità con gli strumenti di trasformazione dei dati.
Filtro per intervallo di date: È fondamentale applicare un filtro per intervallo di date alle entità primarie, in particolare a Sales invoice headers V2 sul campo InvoiceDate. Si consiglia un intervallo da 3 a 6 mesi per mantenere l'esportazione gestibile, fornendo al contempo dati sufficienti per l'analisi.
Filtro per azienda: L'esportazione dovrebbe essere filtrata dall'entità giuridica o dal codice azienda specifico che sta analizzando per garantire la pertinenza dei dati e ridurre le dimensioni dell'esportazione.
Staging e trasformazione dei dati: È richiesto un passaggio di post-elaborazione al di fuori di Dynamics 365. I file esportati devono essere combinati e riformattati in un unico formato di event log. Questo di solito implica l'uso di strumenti come Power BI (Power Query), Python o SQL.
Prerequisiti: L'utente che esegue l'esportazione deve avere ruoli di sicurezza appropriati assegnati in Dynamics 365, tipicamente inclusi un ruolo con permessi per lo spazio di lavoro Data management e accesso alle entità di 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.

Fasi

Prerequisiti: Si assicuri di avere Python 3.6+ installato con le librerie requests e pandas. Avrà anche bisogno delle credenziali per un service principal (Registrazione App) in Azure Active Directory a cui è stato concesso l'accesso all'ambiente Dynamics 365 Finance & Operations.
Registrazione Applicazione: In Azure AD, registri una nuova applicazione. Crei un segreto client e annoti l'ID dell'applicazione (client), l'ID della directory (tenant) e il segreto client. In Dynamics 365, aggiunga questo ID applicazione in Amministrazione sistema > Configurazione > Applicazioni Azure Active Directory e gli assegni i diritti utente appropriati per leggere le entità dati richieste.
Configurare lo Script: Apra lo script Python fornito. Compili le variabili di configurazione all'inizio dello script, inclusi d365_url, tenant_id, client_id, client_secret, company, start_date e end_date. Il d365_url dovrebbe essere l'URL base del Suo 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 access token OAuth2 dalla piattaforma di identità di Microsoft. Questo token è richiesto per autorizzare le successive chiamate API.
Estrazione dei dati: Esegua lo script dal Suo terminale usando python your_script_name.py. Lo script inizierà a recuperare tutte le fatture di vendita registrate (CustInvoiceJour) all'interno dell'intervallo di date specificato. Per ogni fattura, effettuerà quindi chiamate API aggiuntive per recuperare i dati correlati per attività come pagamenti, regolamenti, note di credito e cronologia del workflow.
Generazione Attività: Lo script elabora i dati grezzi da più endpoint API. Genera esplicitamente una riga per ciascuna delle 12 attività richieste. Ad esempio, utilizza l'entità CustInvoiceJour per l'event 'Fattura Generata' e interroga l'entità CustSettlement per creare eventi 'Incasso Applicato a Fattura'.
Eventi Calcolati: Si noti che eventi come 'Data Scadenza Pagamento Raggiunta' e 'Fattura Chiusa' non sono transazioni dirette in Dynamics 365. Lo script deriva questi eventi in base alla data di scadenza, allo stato e alla cronologia di regolamento di una fattura, creando voci corrispondenti nell'event log.
Gestione della Paginazione: La funzione helper fetch_all_data è progettata per gestire automaticamente la paginazione. Le API OData di Dynamics 365 restituiscono un numero limitato di record per pagina, quindi questa funzione segue l'@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 compila in un'unica lista, li converte in un DataFrame pandas e standardizza i nomi delle colonne in InvoiceNumber, ActivityName, EventTime e altri attributi richiesti.
Esportazione in CSV: Infine, lo script salva il DataFrame risultante in un file CSV chiamato d365_billing_event_log.csv. Questo file è formattato e pronto per il caricamento in ProcessMind o in un altro strumento di Process Mining.

Configurazione

D365 URL: L'URL base della Sua istanza Dynamics 365 Finance & Operations. Questo è l'endpoint primario per tutte le chiamate API.
Credenziali Azure AD: Sono richiesti client_id, client_secret e tenant_id per l'autenticazione. Questi dovrebbero appartenere a un'applicazione con accesso in lettura alle entità D365 pertinenti.
Azienda: Specifichi il DataAreaId, che corrisponde all'entità giuridica in Dynamics 365 da cui desidera estrarre i dati (ad es. 'USMF').
Intervallo di date: Definisca una start_date e una end_date per limitare l'ambito dell'estrazione. Per un'analisi iniziale, si consiglia un periodo da 3 a 6 mesi per garantire una dimensione gestibile del set di dati, pur catturando sufficienti variazioni di processo.
Entità OData chiave: Lo script interroga principalmente le seguenti entità: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours e WorkflowTrackingStatusTables. Si assicuri che l'utente configurato abbia i permessi per leggere da tutte queste entità.
Prestazioni: L'estrazione dei dati per un lungo periodo o da un'azienda molto grande può essere lenta a causa della natura di effettuare più chiamate API sequenziali. Si consiglia di eseguire lo script durante le ore non di punta e di iniziare con un intervallo di date più piccolo per stimare il tempo di esecuzione totale.

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

Il Suo Template Dati Order to Cash - Fatturazione e Contabilità

Il Suo Template Dati Order to Cash - Fatturazione e Contabilità

Attributi di Order to Cash - Fatturazione e Contabilità

Attività di Order to Cash - Fatturazione e Contabilità

Guide all'Estrazione

Esportazione di Entità Dati di Microsoft Dynamics 365

Fasi

Configurazione

a Query di Esempio config

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

Fasi

Configurazione

a Query di Esempio python

Pronto per iniziare?

Fine dei Ritardi di Fatturazione: Ottimizzi Ordine al Contante & Contabilità Oggi

Il Suo Template Dati Order to Cash - Fatturazione e Contabilità

Il Suo Template Dati Order to Cash - Fatturazione e Contabilità

Attributi di Order to Cash - Fatturazione e Contabilità

Attività di Order to Cash - Fatturazione e Contabilità

Guide all'Estrazione

Esportazione di Entità Dati di Microsoft Dynamics 365

Fasi

Configurazione

a Query di Esempio config

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

Fasi

Configurazione

a Query di Esempio python

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Fine dei Ritardi di Fatturazione: Ottimizzi Ordine al Contante & Contabilità Oggi