> Miglioramento continuo dei processi > Gestione del credito e recupero crediti > Microsoft Dynamics 365 > Template dei dati

Il Suo Template dati per la gestione del credito e il recupero dei crediti

Microsoft Dynamics 365

← Torna alla guida al miglioramento

Attributi della gestione del credito e recupero crediti (19) Attività di gestione del credito e recupero crediti (12) Guide all’estrazione (2)

Il Suo Template dati per la gestione del credito e il recupero dei crediti

Questo Template offre una guida completa alla raccolta dei dati necessari per analizzare il processo di gestione del credito e recupero dei crediti. Illustra gli attributi essenziali, le attività principali da monitorare e indicazioni pratiche per l’estrazione dei dati. Utilizzi questa risorsa per semplificare la preparazione dei dati e accelerare il percorso verso il Process Mining.

Attributi consigliati da raccogliere per un’analisi completa
Attività principali del processo da monitorare per una discovery accurata
Indicazioni pratiche per estrarre i dati dal Suo sistema

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

Scarica il Template

Attributi della gestione del credito e recupero crediti

Questi sono i campi dati consigliati da includere nel Suo Event Log per un’analisi completa del processo di gestione del credito e recupero crediti.

3 Obbligatorio 8 Consigliato 8 Facoltativo

	Nome	Descrizione
	Nome attività ActivityName	Il nome dell'evento o dell'attività specifica che si è verificata in un determinato momento del ciclo di vita della fattura.
Descrizione Il nome attività descrive un passaggio o un evento specifico all'interno del processo di gestione del credito e della riscossione, come «Invoice Generated», «Dunning Letter Sent» o «Payment Received». Questo attributo è fondamentale nel Process Mining, poiché definisce i nodi della mappa di processo. L'analisi della sequenza e della frequenza di queste attività rivela il flusso di processo effettivo e consente di identificare cicli di rilavorazione, inefficienze e percorsi di processo non conformi. Supporta direttamente la creazione di tutte le visualizzazioni del flusso di processo e viene utilizzato per segmentare il calcolo dei tempi di ciclo tra le diverse fasi del processo. Perché è importante Questo attributo definisce i passaggi della mappa di processo, rendendo possibile visualizzare e analizzare il ciclo di vita della fattura. Dove reperirlo In genere viene ricavato associando specifici eventi di sistema, modifiche di stato o date di creazione dei record provenienti da diverse tabelle, come «CustInvoiceJour», «CustTrans», «CustCollectionLetterJour» e «CustPaymPromise», a nomi di attività standardizzati. Esempi Fattura registrata e inviataLettera di sollecito generataContestazione registrataPagamento ricevuto
	Numero fattura InvoiceNumber	L'identificativo univoco di ogni fattura cliente, utilizzato come identificativo principale del caso nel processo di gestione del credito.
Descrizione Il numero fattura è un attributo fondamentale che identifica univocamente ogni transazione finanziaria con un cliente. Collega tutte le attività correlate, dalla generazione e registrazione della fattura alla riscossione del pagamento e al saldo finale. Nel Process Mining, questo numero viene utilizzato per ricostruire il percorso end-to-end di ogni fattura e analizzarne in dettaglio il ciclo di vita. Trattando ogni fattura come un caso separato, le organizzazioni possono identificare i percorsi di processo più comuni, i colli di bottiglia e le deviazioni dalla procedura standard. Costituisce la base per calcolare metriche chiave come i Days Sales Outstanding e analizzare le varianti di processo. Perché è importante È il Case ID essenziale che collega tutti gli eventi di processo, consentendo di ricostruire e analizzare l'intero ciclo di vita invoice-to-cash. Dove reperirlo In genere corrisponde al campo «Invoice» della tabella «CustInvoiceJour» in Microsoft Dynamics 365 Finance. Esempi INV-0012345CIV-2023-8876SI-9510034
	Ora dell'evento EventTime	Il timestamp che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione L'ora dell'evento è la data e l'ora precise in cui un'attività è stata registrata nel sistema. Costituisce un elemento fondamentale del Process Mining, poiché fornisce l'ordine cronologico necessario per costruire il flusso di processo e calcolare tutte le metriche basate sul tempo. Questo attributo è essenziale per analizzare le durate, identificare i colli di bottiglia e monitorare gli SLA. Ad esempio, la differenza temporale tra gli eventi «Invoice Generated» e «Payment Received» viene utilizzata per calcolare i Days Sales Outstanding (DSO), un KPI aziendale fondamentale. Senza timestamp accurati, l'analisi delle prestazioni e l'identificazione dei colli di bottiglia non sono possibili. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, individuare la mappa di processo e calcolare tutte le metriche delle prestazioni, come tempi di ciclo e durate. Dove reperirlo Questo attributo proviene da diversi campi di data e ora nelle tabelle D365, come «CreatedDateTime» in «CustInvoiceJour» o «TransDate» in «CustTrans», a seconda dell'attività specifica. Esempi 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Addetto alla riscossione assegnato CollectorAssigned	Il nome dell'addetto alla riscossione o del membro del team responsabile della gestione della fattura scaduta.
Descrizione Questo attributo identifica il dipendente responsabile delle attività di riscossione relative a una specifica fattura. È fondamentale per analizzare prestazioni e carichi di lavoro. Filtrando la mappa di processo o i Dashboard per addetto alla riscossione, i responsabili possono valutare la produttività individuale, confrontare le strategie di riscossione e individuare opportunità di coaching. Questo attributo è una dimensione chiave per i Dashboard «Collection Team Productivity» e «Dispute Resolution Cycle Time», poiché consente di attribuire gli esiti del processo a singole persone o team. Perché è importante Consente di analizzare le prestazioni del team di riscossione, contribuisce a bilanciare i carichi di lavoro e permette di individuare le best practice confrontando l'efficacia dei diversi addetti. Dove reperirlo Consultare la documentazione di Microsoft Dynamics 365. Potrebbe essere collegato a un modulo di gestione della riscossione o ai campi relativi alle responsabilità degli utenti nelle anagrafiche dei clienti o nei record delle transazioni. Esempi John SmithEmily JonesTeam A del recupero crediti
	Data di scadenza pagamento PaymentDueDate	La data entro la quale, secondo gli accordi contrattuali, deve essere effettuato il pagamento della fattura.
Descrizione La data di scadenza del pagamento è un attributo temporale fondamentale, definito dalle condizioni di pagamento concordate con il cliente. Questa data costituisce il riferimento per determinare se una fattura è scaduta. È il principale fattore che attiva le attività di riscossione, come l'invio di solleciti o l'avvio di una procedura formale di sollecito. Nel Process Mining viene utilizzata per calcolare la metrica «Days Overdue» e verificare la conformità alle policy di sollecito, ad esempio controllando che un sollecito sia stato inviato entro X giorni dal superamento della scadenza. Perché è importante Questa data è il riferimento per misurare la puntualità dei pagamenti e attiva tutte le attività relative a scadenze e riscossione. Dove reperirlo In genere si trova nel campo «DueDate» delle tabelle «CustTrans» o «CustInvoiceJour». Esempi 2023-02-142023-03-312023-04-30
	Giorni di ritardo DaysOverdue	Il numero di giorni trascorsi dalla data di scadenza del pagamento della fattura.
Descrizione I giorni di ritardo sono una metrica calcolata che misura il tempo trascorso dalla data di scadenza del pagamento per una fattura non pagata. Si calcolano sottraendo la data di scadenza del pagamento dalla data corrente. Sono un indicatore chiave delle prestazioni del team di riscossione, poiché aiutano a stabilire quali fatture debbano essere gestite con priorità. Costituiscono la metrica principale del Dashboard «Overdue Invoices By Segment» e sono fondamentali per valutare lo stato dei crediti verso clienti e l'efficacia delle attività di riscossione. Perché è importante È una metrica operativa fondamentale, utilizzata per stabilire la priorità delle attività di riscossione e misurare la gravità dei ritardi nei pagamenti. Dove reperirlo È un campo calcolato. La logica è: IF la fattura non è pagata THEN (Today() - PaymentDueDate) ELSE 0. Esempi 1532910
	Importo fattura InvoiceAmount	Il valore monetario complessivo della fattura.
Descrizione L'importo fattura rappresenta il valore finanziario totale dei beni o dei servizi fatturati. È un attributo fondamentale per l'analisi finanziaria del processo. Consente di segmentare i casi in base al valore per verificare se le fatture di importo elevato seguono un processo diverso o subiscono ritardi maggiori. Questo attributo è essenziale per i Dashboard «Uncollectible Invoice Write-Offs» e «Credit Limit Management Analysis», poiché aiuta a quantificare l'impatto finanziario e valutare il rischio. Perché è importante Consente di analizzare l'impatto finanziario, stabilire la priorità delle fatture di importo elevato e comprendere in che modo il valore della fattura influisce sul comportamento del processo. Dove reperirlo Probabilmente corrisponde al campo «InvoiceAmount» della tabella «CustInvoiceJour». Esempi 1500.7525000.00549.99
	Livello di sollecito DunningLevel	Indica la fase o il livello di gravità attuale del processo di sollecito per una fattura scaduta.
Descrizione Il livello di sollecito rappresenta la fase di una procedura strutturata di sollecito, ad esempio «Livello 1: sollecito bonario», «Livello 2: avviso formale» o «Livello 3: ultimo avvertimento». Monitorare questo attributo è essenziale per valutare il successo della strategia di riscossione. Il Dashboard «Dunning Strategy Effectiveness» utilizza questo attributo per mostrare la percentuale di fatture pagate dopo il raggiungimento di ciascun livello. Ciò aiuta le aziende a perfezionare i propri Workflow di sollecito, rendendoli più efficaci nel garantire il pagamento e nel preservare al contempo i rapporti con i clienti. Perché è importante È fondamentale per misurare l'efficacia della strategia di sollecito e comprendere in quale fase i clienti hanno maggiore probabilità di pagare. Dove reperirlo Queste informazioni si trovano nelle tabelle relative alla riscossione e alle lettere di sollecito, come «CustCollectionLetterJour». Esempi 123 - FinaleAzione legale
	Nome cliente CustomerName	La denominazione legale del cliente a cui è stata emessa la fattura.
Descrizione Il nome cliente identifica lo specifico cliente associato a una fattura. Questo attributo è una dimensione primaria per filtri e segmentazioni. Analizzare il processo per cliente aiuta a individuare quelli che pagano sistematicamente in ritardo, presentano contestazioni o richiedono attività di riscossione particolarmente impegnative. È un attributo chiave per il Dashboard «Dispute Resolution Cycle Time» e per qualsiasi analisi approfondita di specifici account cliente. Perché è importante Consente di analizzare il processo per singolo cliente, aiutando a individuare schemi ricorrenti e a gestire i rapporti con gli account strategici o problematici. Dove reperirlo Queste informazioni vengono in genere unite alla tabella «CustTable» utilizzando il numero di conto cliente presente in «CustInvoiceJour». Esempi Contoso Ltd.Adventure WorksFabrikam Inc.
	Segmento cliente CustomerSegment	Una classificazione del cliente, ad esempio in base a dimensioni, settore o importanza strategica.
Descrizione Il segmento cliente è un attributo categoriale utilizzato per raggruppare i clienti in coorti significative, ad esempio «Strategic Accounts», «SMB» o «Government». Questa segmentazione è fondamentale per l'analisi strategica. Aiuta a rispondere a domande come «Gli account strategici hanno un DSO inferiore?» o «Gli stralci sono più frequenti in un determinato segmento di settore?». Viene utilizzata direttamente nei Dashboard «Days Sales Outstanding Trend», «Uncollectible Invoice Write-Offs» e «Overdue Invoices By Segment» per fornire insight di livello più elevato rispetto all'analisi dei singoli clienti. Perché è importante Consente un'analisi aggregata dei gruppi di clienti per individuare tendenze strategiche e adattare le strategie di riscossione ai diversi segmenti. Dove reperirlo Spesso si tratta di un campo personalizzato o di un valore derivato dagli attributi di «CustTable», la tabella dell'anagrafica clienti. Esempi EnterpriseMid-MarketSettore pubblicoPartner
	Stato fattura InvoiceStatus	Lo stato attuale della fattura nel suo ciclo di vita.
Descrizione Lo stato fattura fornisce una fotografia della posizione della fattura nel processo, ad esempio «Aperta», «Pagata», «Contestata» o «Stralciata». Mentre il registro delle attività offre una cronologia dettagliata, lo stato attuale è un attributo utile a livello di caso per filtri e report di sintesi. Consente agli analisti di segmentare rapidamente i dati, concentrandosi solo sulle fatture aperte e scadute oppure analizzando le caratteristiche di tutte le fatture stralciate. È un modo semplice ma efficace per comprendere lo stato attuale dei crediti verso clienti. Perché è importante Fornisce un modo rapido e semplice per filtrare e analizzare le fatture in base al loro stato attuale, ad esempio concentrandosi su tutti i casi aperti o contestati. Dove reperirlo Derivato dallo stato di saldo delle transazioni nella tabella «CustTrans». Una transazione aperta non è pagata, mentre una chiusa è stata saldata. Esempi ApertoPagatoParzialmente pagatoStralciato
	Codice valuta CurrencyCode	La valuta della fattura, ad esempio USD o EUR.
Descrizione Il codice valuta specifica la valuta della transazione relativa all'importo fattura. È un attributo contestuale importante, soprattutto per le organizzazioni multinazionali. È necessario per interpretare correttamente i valori finanziari e può essere utilizzato per analizzare se i cicli o i problemi di pagamento siano correlati a valute specifiche, eventualmente a causa della complessità dei cambi o dei pagamenti internazionali. Perché è importante Fornisce il contesto essenziale per tutti i valori monetari e consente di analizzare processi che coinvolgono più valute. Dove reperirlo In genere si trova nel campo «CurrencyCode» della tabella «CustInvoiceJour». Esempi USDEURGBPCAD
	È contestata IsDisputed	Un flag booleano che indica se una fattura è mai stata contestata.
Descrizione È un flag calcolato impostato su true se il caso della fattura contiene un'attività «Dispute Registered». Semplifica l'analisi consentendo agli utenti di filtrare o confrontare facilmente i flussi di processo delle fatture contestate e non contestate. Ad esempio, è possibile confrontare la media del DSO delle fatture contestate con quella delle fatture non contestate per quantificare l'impatto delle contestazioni sul flusso di cassa. È un attributo utile per i Dashboard di sintesi e per le analisi comparative. Perché è importante Semplifica l'analisi e il filtraggio, consentendo di confrontare facilmente le popolazioni di fatture contestate e non contestate. Dove reperirlo È un campo calcolato. La logica è: IF il caso contiene un'attività «Dispute Registered» THEN true ELSE false. Esempi truefalse
	Limite di credito CreditLimit	L'importo massimo di credito approvato per il cliente.
Descrizione Il limite di credito è l'importo totale del debito che un cliente è autorizzato ad accumulare. Questo attributo è fondamentale per la gestione del rischio. Il Dashboard «Credit Limit Management Analysis» confronta questo valore con gli importi delle fatture relative agli account insoluti o stralciati. L'analisi aiuta a determinare se i limiti di credito sono impostati correttamente e vengono rispettati e se i clienti insolventi hanno ricevuto di recente aumenti del limite, evidenziando potenziali debolezze nel processo di approvazione del credito. Perché è importante Essenziale per la valutazione del rischio, questo attributo aiuta ad analizzare se gli stralci siano legati a limiti di credito cliente gestiti in modo inadeguato o insufficienti. Dove reperirlo Questo valore è in genere memorizzato nell'anagrafica cliente, nella tabella «CustTable». Esempi 10000.0050000.000.00
	Motivo della contestazione DisputeReason	Il motivo indicato dal cliente per contestare una fattura.
Descrizione Quando un cliente contesta una fattura, in genere indica un motivo, come «Prezzo errato», «Merce danneggiata» o «Fatturazione duplicata». Questo attributo registra tale motivo. Analizzare le motivazioni delle contestazioni è fondamentale per l'analisi delle cause principali. Aiuta a individuare problemi ricorrenti nel processo order-to-cash, ad esempio nelle funzioni vendite, spedizioni o fatturazione. Ridurre le contestazioni alla fonte è un risultato chiave di questa analisi e incide direttamente sul DSO, evitando ritardi nei pagamenti. Perché è importante Fornisce dati fondamentali per l'analisi delle cause principali dei ritardi nei pagamenti, aiutando a individuare e risolvere i problemi a monte che portano alle contestazioni delle fatture. Dove reperirlo Consultare la documentazione di Microsoft Dynamics 365. Questo elemento farebbe parte delle funzionalità di gestione delle contestazioni o dei casi. Esempi Errore di prezzoQuantità insufficienteProdotto non ricevutoServizio non conforme alla descrizione
	Paese Country	Il Paese dell'indirizzo di fatturazione del cliente.
Descrizione Questo attributo specifica il Paese associato all'account cliente. È una dimensione comune per l'analisi geografica. Segmentare KPI di processo come DSO o tassi di stralcio per Paese può rivelare differenze regionali nel comportamento di pagamento dei clienti, nell'efficacia della riscossione o nelle condizioni economiche. Ciò può portare a strategie di riscossione adattate alle diverse aree geografiche o a condizioni di pagamento differenti per determinate regioni. Perché è importante Consente un'analisi geografica per individuare tendenze regionali nel comportamento di pagamento e nelle prestazioni del processo di riscossione. Dove reperirlo Deriva dall'associazione dell'anagrafica cliente («CustTable») al relativo record dell'indirizzo principale, spesso in «LogisticsPostalAddress». Esempi USADEUGBRCAN
	Sistema di origine SourceSystem	Identifica il sistema da cui provengono i dati.
Descrizione Questo attributo specifica l'applicazione di origine in cui sono stati registrati i dati dell'evento. In questo contesto, il valore sarebbe «Microsoft Dynamics 365». Sebbene in un'analisi basata su un unico sistema possa sembrare statico, è fondamentale per la governance dei dati, la risoluzione dei problemi e le future integrazioni. Se venissero inclusi dati provenienti da altri sistemi, come un CRM separato o il portale di un'agenzia di recupero crediti, questo campo sarebbe essenziale per distinguerli e comprendere il processo completo tra più sistemi. Perché è importante Fornisce una chiara tracciabilità dei dati ed è essenziale per mantenere la qualità dei dati e consentire analisi su più sistemi integrati. Dove reperirlo In genere è un valore statico aggiunto durante il processo di estrazione dei dati per indicare l'origine dei record. Esempi Microsoft Dynamics 365D365 F&O
	Tempo di risoluzione della contestazione DisputeResolutionTime	Il tempo necessario per risolvere una contestazione del cliente a partire dalla sua prima registrazione.
Descrizione Il tempo di risoluzione della contestazione misura l'efficienza del processo di gestione delle contestazioni. Si calcola come durata tra le attività «Dispute Registered» e «Dispute Resolved». Tempi di risoluzione elevati possono ritardare il pagamento e incidere negativamente sulla soddisfazione del cliente. Analizzare questa metrica per addetto alla riscossione o motivo della contestazione aiuta a individuare colli di bottiglia e aree di miglioramento nel Workflow di gestione delle contestazioni. Perché è importante Misura l'efficienza del processo di gestione delle contestazioni, una causa frequente di ritardi significativi nei pagamenti. Dove reperirlo Calcolato come durata tra i timestamp delle attività «Dispute Registered» e «Dispute Resolved». Esempi 7.215.83.5
	Ultimo aggiornamento dati LastDataUpdate	Il timestamp dell'ultimo aggiornamento o refresh dei dati.
Descrizione Questo attributo indica l'ultima volta in cui il dataset è stato aggiornato dal sistema di origine. È un elemento di metadati fondamentale per gli utenti dell'analisi di Process Mining, poiché fornisce il contesto relativo all'aggiornamento dei dati. Sapere che i dati sono aggiornati fino a un determinato momento aiuta gli analisti a prendere decisioni informate e a comprendere l'ambito dei risultati. In genere viene applicato all'intero dataset durante la pipeline di acquisizione dei dati. Perché è importante Informa gli utenti sull'attualità dei dati, assicurando che le analisi si basino su un intervallo temporale noto ed evitando decisioni fondate su informazioni obsolete. Dove reperirlo Questo valore viene generato e applicato al dataset dalla pipeline ETL/dei dati al momento dell'esecuzione. Esempi 2023-04-01T02:00:00Z2023-04-02T02:00:00Z

Obbligatorio Consigliato Facoltativo

Attività di gestione del credito e recupero crediti

Queste sono le principali fasi del processo e le tappe fondamentali da acquisire nel Suo Event Log per un’individuazione accurata del Workflow di gestione del credito e recupero crediti.

9 Consigliato 3 Facoltativo

	Attività	Descrizione
	Contestazione registrata	Indica che il cliente ha contestato formalmente la fattura e che il relativo stato è stato aggiornato. In genere viene acquisito quando un utente modifica lo stato della fattura in «Disputed» nel modulo di gestione del recupero crediti.
Perché è importante Questo è il punto di partenza del processo di risoluzione della contestazione. Il monitoraggio consente di misurare la frequenza delle contestazioni e il tempo necessario per risolverle, con un impatto sulla soddisfazione dei clienti e sui flussi di cassa. Dove reperirlo Dedotto da un cambiamento di stato nella transazione cliente (CustTrans) o in una tabella correlata di gestione delle contestazioni (smmCaseDetail). È necessario un registro con timestamp del cambiamento di stato. Acquisizione Identificare il momento in cui il campo dello stato della contestazione di una transazione di fattura viene valorizzato o modificato in «Disputed». Tipo di evento inferred
	Data di scadenza del pagamento superata	Un evento calcolato che si verifica quando la data corrente supera la data di scadenza della fattura. Questa attività non corrisponde a un'azione diretta dell'utente, ma viene ricavata confrontando la data di sistema con il campo della data di scadenza della fattura.
Perché è importante Questo evento attiva tutte le attività di recupero. Consente di analizzare il volume delle fatture scadute e la tempestività delle azioni di sollecito, supportando KPI come il rispetto delle politiche di sollecito. Dove reperirlo Calcolato confrontando il timestamp corrente con il campo «DueDate» nella tabella Customer Transactions (CustTrans). Il timestamp dell'evento corrisponde alla DueDate. Acquisizione Creare un evento quando «NOW()» è maggiore della DueDate della fattura. Tipo di evento calculated
	Fattura generata	Indica la creazione nel sistema di un record di fattura di vendita, prima della sua registrazione ufficiale. Questa attività corrisponde generalmente a un evento esplicito acquisito quando un utente finalizza un ordine di vendita e genera il relativo documento di fattura.
Perché è importante Questo è l'evento iniziale principale del ciclo di vita della fattura. Analizzare il tempo che intercorre da questo momento al pagamento è fondamentale per misurare i giorni di esposizione commerciale (DSO). Dove reperirlo Registrato nella tabella Sales Invoice Header (SalesInvoiceHeader) o nella tabella Sales (SalesTable) al momento della creazione della fattura. Il timestamp di creazione del record funge da orario dell'evento. Acquisizione Acquisire il timestamp di creazione del record della fattura di vendita. Tipo di evento explicit
	Fattura registrata e inviata	Rappresenta la registrazione ufficiale della fattura nella contabilità generale, che la rende un credito commerciale formale. Questo evento coincide generalmente con l'invio della fattura al cliente e viene acquisito al completamento della routine di registrazione in Dynamics 365.
Perché è importante Si tratta di una tappa fondamentale che avvia ufficialmente il conteggio delle condizioni di pagamento e dell'anzianità. I ritardi tra generazione e registrazione possono nascondere inefficienze nel processo di fatturazione. Dove reperirlo Dedotto dalla data di registrazione nel Customer Invoice Journal (CustInvoiceJour) o da un cambiamento di stato a «Posted». Il timestamp di registrazione è il dato chiave. Acquisizione Utilizzare il timestamp di registrazione del Customer Invoice Journal (CustInvoiceJour). Tipo di evento inferred
	Fattura saldata	La fattura è stata pagata integralmente e il saldo è pari a zero, a conferma del completamento positivo del processo. Questo stato viene dedotto quando la somma dei pagamenti applicati è uguale all'importo totale della fattura.
Perché è importante È il principale punto di arrivo positivo del processo credit-to-cash. L'analisi dei percorsi che conducono a questo esito mette in evidenza le best practice e le varianti di processo più efficienti. Dove reperirlo Inferito dalla data di saldo nella tabella dei saldi cliente (CustSettlement). Si verifica quando i campi «AmountCur» e «SettleAmountCur» della fattura in CustTrans hanno somma pari a zero. Acquisizione Identificare la data di saldo più recente associata alla transazione della fattura che porta il saldo a zero. Tipo di evento inferred
	Fattura stralciata	La fattura è stata considerata inesigibile e viene formalmente stralciata come perdita su crediti. Si tratta di un'azione esplicita eseguita da un utente autorizzato, che azzera il credito e registra la perdita.
Perché è importante È il principale punto di arrivo negativo del processo. Monitorare gli stralci è fondamentale per comprendere il rischio di credito, gli insuccessi nella riscossione e le perdite finanziarie. Dove reperirlo Acquisito da una specifica transazione del giornale generale utilizzata per stralciare una perdita su crediti e collegata alla fattura originale. Il timestamp corrisponde alla data di registrazione del giornale di stralcio. Acquisizione Identificare le registrazioni contabili con uno specifico profilo di registrazione per lo stralcio che fanno riferimento alla fattura. Tipo di evento explicit
	Lettera di sollecito generata	Indica che è stata creata una lettera formale di sollecito o recupero per la fattura scaduta. Viene acquisito quando il processo periodico di sollecito viene eseguito in Dynamics 365 e genera i record delle lettere per le fatture pertinenti.
Perché è importante Tiene traccia dell'avvio e della frequenza delle attività formali di recupero. È essenziale per misurare l'efficacia dei solleciti e la conformità alle politiche interne di recupero. Dove reperirlo Viene creato un record esplicito nella tabella Dunning History (CustCollectionLetterJour). La data di creazione del giornale della lettera di sollecito costituisce il timestamp. Acquisizione Estrarre gli eventi di creazione dalla tabella CustCollectionLetterJour, collegandoli alla fattura. Tipo di evento explicit
	Pagamento registrato	Rappresenta la registrazione ufficiale del pagamento cliente nella contabilità generale e la sua applicazione per saldare una fattura. Viene acquisito dalla data di registrazione del giornale dei pagamenti cliente.
Perché è importante Completa la parte del processo relativa al pagamento. L'intervallo tra la ricezione e la registrazione del pagamento, ovvero il ritardo nell'applicazione dell'incasso, è un indicatore chiave dell'efficienza del reparto Finance. Dove reperirlo Acquisito dal timestamp di registrazione del giornale dei pagamenti cliente (LedgerJournalTrans). Conferma che il pagamento è stato completamente elaborato nella contabilità. Acquisizione Utilizzare la data di registrazione del giornale dei pagamenti cliente registrato. Tipo di evento explicit
	Pagamento ricevuto	Indica che un pagamento del cliente è stato ricevuto e registrato nel sistema, in genere tramite un giornale dei pagamenti. Questo evento precede la registrazione definitiva e l'applicazione dell'incasso alla fattura specifica.
Perché è importante Si tratta di una tappa fondamentale per calcolare il DSO e comprendere il flusso di cassa. L'intervallo tra questo evento e Payment Posted evidenzia i colli di bottiglia nel processo di applicazione degli incassi. Dove reperirlo Evento esplicito acquisito dalla data di creazione di una riga del giornale dei pagamenti cliente (LedgerJournalTrans), prima della registrazione. Rappresenta la data in cui il pagamento è stato registrato come ricevuto. Acquisizione Utilizzare la data della transazione nelle righe del giornale dei pagamenti cliente. Tipo di evento explicit
	Attività di recupero registrata	Rappresenta un'azione manuale di recupero, come una telefonata o un'e-mail, registrata a carico del cliente o della fattura. Viene acquisita quando un addetto al recupero utilizza la funzionalità Activities nell'area di lavoro del recupero crediti per registrare le proprie interazioni.
Perché è importante Offre visibilità sull'impegno manuale del team di recupero. Analizzare queste attività rispetto all'esito dei pagamenti aiuta a misurare la produttività del team e l'efficacia dei diversi metodi di contatto. Dove reperirlo Registrata nelle tabelle Activities (smmActivities) o nelle tabelle correlate di gestione dei casi associate all'account cliente. Se possibile, è necessario collegare l'attività a una fattura specifica. Acquisizione Acquisire la creazione dei record Activity in cui il tipo è «Phone Call» o «Email» e l'attività è correlata al recupero crediti. Tipo di evento explicit
	Contestazione risolta	Indica la conclusione del processo di contestazione, quando è stata raggiunta e documentata una risoluzione. L'evento viene acquisito quando un utente aggiorna lo stato della contestazione di una fattura in «Resolved» o chiude il caso di contestazione associato.
Perché è importante Questa attività conclude il sottoprocesso di risoluzione della contestazione. La durata tra la registrazione e la risoluzione della contestazione è un KPI fondamentale per misurare l'efficienza del team di risoluzione. Dove reperirlo Inferito da una modifica dello stato della transazione cliente (CustTrans) o dalla chiusura del caso di contestazione correlato (smmCaseDetail). Il timestamp di questa modifica dello stato corrisponde all'ora dell'evento. Acquisizione Identificare quando il campo dello stato della contestazione di una fattura viene cancellato o modificato in «Risolto». Tipo di evento inferred
	Promessa di pagamento creata	Il cliente si è impegnato a effettuare un pagamento in una specifica data futura e tale promessa è stata registrata nel sistema. L'evento viene registrato esplicitamente quando un addetto al recupero inserisce i dettagli della promessa di pagamento nel modulo di recupero crediti.
Perché è importante Tiene traccia degli accordi informali di pagamento e dei relativi tassi di adempimento. Confrontare le promesse con i pagamenti effettivi può aiutare a prevedere i flussi di cassa e a valutare l'affidabilità dei clienti. Dove reperirlo Probabilmente registrato nelle tabelle relative all'area di lavoro del recupero crediti o alla gestione dei casi, in particolare quelle dedicate alla funzionalità delle promesse di pagamento. La data di creazione del record della promessa costituisce l'orario dell'evento. Acquisizione Acquisire gli eventi di creazione da una tabella dei dettagli della promessa di pagamento o del caso di recupero. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Microsoft Dynamics 365

Passaggi

Verifichi i prerequisiti: si assicuri che la Sua organizzazione disponga di Microsoft Dynamics 365 Finance e che la funzionalità Bring Your Own Database (BYOD) sia configurata ed esporti attivamente le entità dati in un database Azure SQL. Dovrà disporre delle credenziali di accesso in lettura a questo database Azure SQL.
Identifichi le entità dati: verifichi che le entità dati necessarie vengano esportate da Dynamics 365 nel Suo BYOD. Le entità principali per questo processo includono: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment e CustDispute. Se qualcuna è assente, la configuri per l’esportazione nel Workspace Data Management di Dynamics 365.
Si connetta al database BYOD: utilizzi un client SQL, come SQL Server Management Studio (SSMS) o Azure Data Studio, per connettersi al database Azure SQL che funge da destinazione BYOD.
Prepari la query SQL: copi nel client SQL la query T-SQL completa fornita nella sezione query di questo documento. La query è progettata per raccogliere tutte le attività e gli attributi richiesti in un unico formato Event Log.
Imposti i parametri della query: individui i segnaposto all’inizio della query. Sostituisca '{CompanyCode}' con l’ID dell’entità giuridica Dynamics 365 di destinazione, ad esempio «USMF». Sostituisca '{StartDate}' e '{EndDate}' con l’intervallo di date desiderato per l’analisi, nel formato «YYYY-MM-DD».
Esegua la query: esegua la query modificata sul database BYOD. Il tempo di esecuzione varierà in base al volume di dati nell’intervallo selezionato.
Esamini i risultati: al termine dell’esecuzione, il riquadro dei risultati mostrerà l’Event Log. Ogni riga rappresenta un’attività specifica nel ciclo di vita della gestione del credito e del recupero dei crediti per una fattura. Verifichi la completezza e la correttezza dei dati.
Esporti l’Event Log: esporti i risultati della query in un file CSV. La maggior parte dei client SQL dispone di una funzione integrata per esportare i risultati. Faccia clic con il pulsante destro del mouse sulla griglia dei risultati e cerchi un’opzione come «Save Results As» o «Export».
Prepari il caricamento: si assicuri che il file CSV esportato utilizzi la codifica UTF-8 e che le intestazioni delle colonne corrispondano agli attributi richiesti: InvoiceNumber, ActivityName, EventTime e agli eventuali attributi consigliati inclusi. Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Prerequisiti: accesso a un’istanza di Microsoft Dynamics 365 for Finance con la funzionalità Bring Your Own Database (BYOD) configurata e operativa. Sono necessarie autorizzazioni di lettura per il database Azure SQL di destinazione.
Entità dati: l’estrazione si basa su diverse entità dati standard esportate nel BYOD. Si assicuri che almeno CustInvoiceJour, CustTrans, CustTable e CustSettlement siano inclusi nel processo di esportazione BYOD. Sono necessarie entità aggiuntive come CustCollectionLetterJour per attività specifiche.
Intervallo di date: è fondamentale filtrare la query in base a un intervallo di date specifico per gestire le prestazioni. Per l’analisi iniziale si consiglia un periodo compreso tra 3 e 6 mesi. La query fornita utilizza i segnaposto '{StartDate}' e '{EndDate}' a questo scopo.
Filtro azienda: la query deve essere filtrata in base a una specifica entità giuridica, ovvero il Company Code, per garantire la coerenza dei dati. Utilizzi il segnaposto '{CompanyCode}' per specificare l’azienda da analizzare.
Considerazioni sulle prestazioni: per dataset molto estesi, distribuiti su più anni o aziende, il tempo di esecuzione della query può essere significativo. Valuti l’esecuzione nelle ore di minore attività o l’applicazione di filtri aggiuntivi per limitare l’ambito dei dati. Si assicuri che nelle tabelle BYOD siano presenti indici adeguati sulle colonne data e sulle colonne chiave.

a Query di esempio sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

Passaggi

Verifichi i prerequisiti e configuri l’ambiente: si assicuri di avere installato Python 3.8 o una versione successiva. Installi le librerie necessarie tramite pip: pip install pandas requests msal. Avrà inoltre bisogno delle credenziali di un service principal con accesso all’ambiente Dynamics 365.
Registri l’applicazione in Azure AD: acceda al portale Azure Active Directory. Registri una nuova applicazione per ottenere un Client ID e un Tenant ID. Crei un nuovo client secret nella sezione «Certificates & secrets» dell’applicazione. Conservi in modo sicuro il Client ID, il Tenant ID e il Client Secret.
Conceda le autorizzazioni API: nelle impostazioni «API permissions» dell’applicazione registrata in Azure AD, aggiunga un’autorizzazione. Selezioni «Dynamics ERP» o una voce equivalente per Dynamics 365, quindi conceda l’autorizzazione delegata «user_impersonation». Conceda il consenso dell’amministratore per la Sua organizzazione.
Crei un utente Dynamics 365: crei un utente applicazione dedicato in Dynamics 365 Finance and Operations. Associ questo utente al Client ID dell’applicazione Azure AD. Assegni all’utente un ruolo di sicurezza con autorizzazioni di lettura per tutte le entità dati richieste, come CustInvoiceJour, CustCollectionLetterJour, CustSettlements e smmActivities.
Configuri lo script Python: copi lo script Python fornito in un file, ad esempio extract_d365_collections.py. Compili le variabili segnaposto all’inizio dello script con l’URL dell’ambiente D365, il Tenant ID, il Client ID, il Client Secret e l’azienda predefinita (dataAreaId).
Imposti i parametri di estrazione: modifichi le variabili start_date e end_date nello script per definire l’intervallo temporale dei dati. Per l’analisi iniziale si consiglia un periodo compreso tra 3 e 6 mesi.
Esegua lo script: esegua lo script dal terminale utilizzando il comando python extract_d365_collections.py. Lo script eseguirà l’autenticazione, interrogherà gli endpoint OData per ciascuna delle 12 attività e gestirà automaticamente la paginazione dell’API.
Recuperi i dati per ogni attività: lo script effettua chiamate API sequenziali per recuperare i dati relativi alla generazione e alla registrazione delle fatture, ai solleciti, ai pagamenti e ad altri eventi principali. Ogni query si rivolge a una specifica entità dati e seleziona solo i campi necessari per ottimizzare le prestazioni.
Trasformi e combini i dati: lo script utilizza la libreria pandas per elaborare la risposta JSON di ogni chiamata API. Trasforma i dati in una tabella strutturata, standardizza i nomi delle colonne e unisce quindi i dati di tutte le attività in un unico Event Log.
Calcoli gli eventi derivati: l’attività «Payment Due Date Passed» non corrisponde a un record diretto nel sistema. Lo script calcola questo evento scorrendo tutte le fatture scadute nell’intervallo specificato e generando una riga corrispondente per ciascuna.
Esporti l’Event Log: dopo aver elaborato e combinato tutti i dati, lo script salva l’Event Log finale come file CSV denominato d365_collections_event_log.csv nella stessa directory. Il file è formattato e pronto per essere caricato in uno strumento di Process Mining.

Configurazione

URL dell’endpoint API: l’URL di base dell’ambiente Dynamics 365 Finance and Operations. Deve essere fornito nel formato https://[your-environment-name].operations.dynamics.com.
Credenziali di autenticazione: lo script richiede un Tenant ID, un Client ID e un Client Secret ottenuti dalla registrazione di un’applicazione Azure Active Directory. L’applicazione deve disporre delle autorizzazioni per accedere all’API Dynamics 365.
Filtro azienda (dataAreaId): Dynamics 365 è un sistema multi-azienda. Lo script è configurato per interrogare una specifica azienda utilizzando il filtro dataAreaId. Si assicuri di impostare la variabile default_company sull’entità giuridica corretta, ad esempio «USMF».
Intervallo di date: i parametri start_date e end_date controllano l’intervallo di estrazione. Si consiglia di iniziare con un periodo recente di 3-6 mesi per gestire il volume dei dati e garantire un’estrazione tempestiva. Il filtro viene applicato principalmente alla data di creazione della fattura.
Considerazioni sulle prestazioni: l’estrazione tramite API OData di dataset molto estesi può richiedere tempo e può essere soggetta a limitazioni di frequenza imposte da Microsoft. In caso di problemi di prestazioni, valuti di eseguire l’estrazione su intervalli più brevi o nelle ore di minore attività.
Prerequisiti: è necessario un ambiente Python 3.8 o superiore con le librerie pandas, requests e msal. L’utente Dynamics 365 associato deve disporre dell’accesso in lettura ai moduli di gestione finanziaria, vendite e recupero dei crediti, in particolare alle entità indicate nello script.

a Query di esempio python

import requests
import pandas as pd
import msal
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

È pronto per iniziare?

Utilizzi questo Template per preparare i dati in modo efficace e ottenere informazioni preziose sulle operazioni di gestione del credito e recupero dei crediti. Inizi oggi stesso a ottimizzare il processo per accelerare il flusso di cassa.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi oggi la gestione del credito e il recupero dei crediti per incassare più rapidamente

Migliori il flusso di cassa semplificando il ciclo dal credito all’incasso e riducendo del 30% il tempo di ciclo.

Inizi la prova gratuita

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

Il Suo Template dati per la gestione del credito e il recupero dei crediti

Il Suo Template dati per la gestione del credito e il recupero dei crediti

Attributi della gestione del credito e recupero crediti

Attività di gestione del credito e recupero crediti

Guide all’estrazione

Query SQL diretta tramite Bring Your Own Database (BYOD)

Passaggi

Configurazione

a Query di esempio sql

Script Python tramite API REST OData di Dynamics 365

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Ottimizzi oggi la gestione del credito e il recupero dei crediti per incassare più rapidamente

Il Suo Template dati per la gestione del credito e il recupero dei crediti

Il Suo Template dati per la gestione del credito e il recupero dei crediti

Attributi della gestione del credito e recupero crediti

Attività di gestione del credito e recupero crediti

Guide all’estrazione

Query SQL diretta tramite Bring Your Own Database (BYOD)

Passaggi

Configurazione

a Query di esempio sql

Script Python tramite API REST OData di Dynamics 365

Passaggi

Configurazione

a Query di esempio python

È pronto per iniziare?

Ottimizzi oggi la gestione del credito e il recupero dei crediti per incassare più rapidamente

La Sua privacy è importante