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

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

Microsoft Dynamics 365

← Torna alla guida al miglioramento

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

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

Questo template fornisce indicazioni complete per raccogliere i dati necessari ad analizzare il processo di gestione del credito e recupero crediti. Descrive gli attributi essenziali, le attività principali da monitorare e le modalità pratiche per estrarre i dati. Utilizzi questa risorsa per semplificare la preparazione dei dati e avviare più rapidamente il Process Mining.

Attributi consigliati per un’analisi completa
Attività chiave del processo da monitorare per una ricostruzione accurata
Indicazioni pratiche per estrarre i dati dal sistema

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

Scarica il template

Attributi per la gestione del credito e il recupero crediti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il 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 una fase del ciclo di vita della fattura.
Descrizione Il nome attività descrive una fase o un evento specifico del processo di gestione del credito e del recupero, come «Fattura generata», «Lettera di sollecito inviata» o «Pagamento ricevuto». Questo attributo è fondamentale per il Process Mining, perché definisce i nodi della mappa del processo. Analizzare la sequenza e la frequenza delle attività rivela il flusso effettivo del processo e consente di individuare cicli di rilavorazione, inefficienze e percorsi non conformi. È alla base di tutte le visualizzazioni del flusso di processo e viene utilizzato per calcolare i tempi di ciclo tra le diverse fasi. Perché è importante Questo attributo definisce le fasi della mappa del processo e permette di visualizzare e analizzare il ciclo di vita della fattura. Dove reperirli In genere, questo attributo si ricava associando eventi di sistema specifici, modifiche di stato o date di creazione dei record presenti in 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	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 in modo univoco ogni transazione finanziaria con un cliente. Collega tutte le attività correlate, dalla generazione e registrazione della fattura al recupero del pagamento e al saldo finale. Nel Process Mining, questo numero consente di ricostruire il percorso completo di ogni fattura e di analizzarne nel dettaglio il ciclo di vita. Considerando ogni fattura come un caso distinto, le organizzazioni possono individuare i percorsi ricorrenti, i colli di bottiglia e gli scostamenti dalla procedura standard. È inoltre la base per calcolare indicatori chiave come i giorni medi di incasso e analizzare le varianti di processo. Perché è importante È l’ID del caso essenziale che collega tutti gli eventi del processo e consente di ricostruire e analizzare l’intero ciclo dalla fattura all’incasso. Dove reperirli In genere corrisponde al campo «Invoice» della tabella «CustInvoiceJour» in Microsoft Dynamics 365 Finance. Esempi INV-0012345CIV-2023-8876SI-9510034
	Ora dell’evento EventTime	Data e ora che indicano quando si è verificata una specifica attività o un evento.
Descrizione L’ora dell’evento indica la data e l’ora esatte in cui un’attività è stata registrata nel sistema. È un elemento fondamentale del Process Mining, perché fornisce l’ordine cronologico necessario per ricostruire il flusso del processo e calcolare tutti gli indicatori basati sul tempo. Questo attributo è indispensabile per analizzare le durate, individuare i colli di bottiglia e monitorare gli SLA. Per esempio, la differenza tra l’evento «Fattura generata» e «Pagamento ricevuto» viene utilizzata per calcolare i giorni medi di incasso (DSO), un KPI aziendale fondamentale. Senza date e orari precisi, non è possibile analizzare le prestazioni né individuare i colli di bottiglia. Perché è importante Questo riferimento temporale è indispensabile per ordinare gli eventi, ricostruire la mappa del processo e calcolare tutti gli indicatori di prestazione, come i tempi di ciclo e le durate. Dove reperirli Questo attributo proviene da diversi campi di data e ora delle 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
	Data di scadenza del pagamento PaymentDueDate	Data entro cui il pagamento della fattura deve essere effettuato secondo gli accordi contrattuali.
Descrizione La data di scadenza del pagamento è un attributo temporale fondamentale, definito dalle condizioni di pagamento concordate con il cliente. Serve come base di riferimento per stabilire se una fattura è scaduta ed è il principale fattore che avvia le attività di recupero, come l’invio di promemoria o l’avvio di una procedura formale di sollecito. Nel Process Mining, viene utilizzata per calcolare i giorni di ritardo e verificare il rispetto delle politiche di sollecito, per esempio controllando che un promemoria sia stato inviato entro X giorni dalla scadenza. Perché è importante Questa data è il riferimento per misurare la puntualità dei pagamenti e avvia tutte le attività relative alle fatture scadute e al recupero crediti. Dove reperirli In genere, si trova nel campo «DueDate» delle tabelle «CustTrans» o «CustInvoiceJour». Esempi 2023-02-142023-03-312023-04-30
	Giorni di ritardo DaysOverdue	Numero di giorni trascorsi dalla data di scadenza del pagamento di una fattura.
Descrizione I giorni di ritardo sono un indicatore calcolato che misura il tempo trascorso dalla data di scadenza del pagamento di una fattura non pagata. Si calcolano sottraendo la data di scadenza del pagamento dalla data corrente. Sono un indicatore chiave per il team di recupero crediti, perché aiutano a stabilire a quali fatture dare priorità. Costituiscono l’indicatore principale della Dashboard «Fatture scadute per segmento» e sono fondamentali per valutare lo stato dei crediti verso clienti e l’efficacia delle attività di recupero. Perché è importante È un indicatore operativo fondamentale per stabilire le priorità delle attività di recupero e misurare la gravità dei ritardi di pagamento. Dove reperirli È un campo calcolato. La logica è: IF Invoice is unpaid THEN (Today() - PaymentDueDate) ELSE 0. Esempi 1532910
	Importo fattura InvoiceAmount	Valore monetario totale della fattura.
Descrizione L’importo della fattura rappresenta il valore finanziario totale dei beni o servizi fatturati. È un attributo fondamentale per l’analisi finanziaria del processo. Consente di suddividere i casi per valore e verificare se le fatture di importo elevato seguono percorsi diversi o subiscono ritardi maggiori. Questo attributo è essenziale per le Dashboard «Stralci di fatture inesigibili» e «Analisi della gestione dei limiti di credito», che aiutano a quantificare l’impatto finanziario e a valutare il rischio. Perché è importante Consente di analizzare l’impatto finanziario, dare priorità alle fatture di importo elevato e comprendere come il valore della fattura influisca sul processo. Dove reperirli 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à raggiunto dalla procedura di sollecito e recupero di una fattura scaduta.
Descrizione Il livello di sollecito rappresenta la fase di una procedura strutturata, per esempio «Livello 1: promemoria cortese», «Livello 2: avviso formale» o «Livello 3: ultimo avvertimento». Monitorare questo attributo è essenziale per valutare l’efficacia della strategia di recupero. La Dashboard «Efficacia della strategia di sollecito» lo utilizza per mostrare la percentuale di fatture pagate dopo aver raggiunto ciascun livello. Queste informazioni aiutano le aziende a perfezionare i flussi di lavoro di sollecito, rendendoli più efficaci nel favorire i pagamenti e nel preservare i rapporti con i clienti. Perché è importante È fondamentale per misurare l’efficacia della strategia di sollecito e capire in quale fase i clienti sono più propensi a pagare. Dove reperirli Queste informazioni si trovano nelle tabelle relative al recupero crediti e alle lettere di sollecito, come «CustCollectionLetterJour». Esempi 123 - FinaleAzione legale
	Nome cliente CustomerName	Denominazione legale del cliente a cui è stata emessa la fattura.
Descrizione Il nome del cliente identifica il cliente specifico associato a una fattura. È una dimensione primaria per filtrare e segmentare i dati. Analizzare il processo per cliente aiuta a individuare quelli che pagano regolarmente in ritardo, presentano contestazioni o richiedono un’attività di recupero particolarmente intensa. È un attributo chiave per la Dashboard «Tempo di ciclo della risoluzione delle contestazioni» e per le analisi approfondite dei singoli account cliente. Perché è importante Consente di analizzare il processo per singolo cliente, individuare schemi ricorrenti e gestire i rapporti con gli account strategici o problematici. Dove reperirli In genere, queste informazioni vengono unite a quelle della tabella «CustTable» utilizzando il numero di conto cliente presente in «CustInvoiceJour». Esempi Contoso Ltd.Adventure WorksFabrikam Inc.
	Responsabile del recupero assegnato CollectorAssigned	Nome dell’addetto al recupero crediti o del membro del team responsabile della gestione della fattura scaduta.
Descrizione Questo attributo identifica il dipendente responsabile delle attività di recupero relative a una specifica fattura. È fondamentale per analizzare le prestazioni e il carico di lavoro. Filtrando la mappa del processo o le Dashboard per addetto al recupero, i responsabili possono valutare la produttività individuale, confrontare le strategie di recupero e individuare opportunità di formazione. Questo attributo è una dimensione chiave per le Dashboard «Produttività del team di recupero crediti» e «Tempo di ciclo della risoluzione delle contestazioni», perché consente di associare gli esiti del processo a singole persone o team. Perché è importante Consente di analizzare le prestazioni del team di recupero crediti, aiuta a bilanciare i carichi di lavoro e permette di individuare le prassi migliori confrontando l’efficacia dei singoli addetti. Dove reperirli Consultare la documentazione di Microsoft Dynamics 365. Il dato potrebbe essere collegato a un modulo di gestione del recupero crediti o ai campi relativi alle responsabilità degli utenti nei record dei clienti o delle transazioni. Esempi John SmithEmily JonesTeam di recupero crediti A
	Segmento cliente CustomerSegment	Classificazione del cliente, per esempio in base alle dimensioni, al settore o all’importanza strategica.
Descrizione Il segmento cliente è un attributo categoriale che raggruppa i clienti in gruppi significativi, per esempio «Account strategici», «PMI» o «Pubblica amministrazione». Questa segmentazione è fondamentale per l’analisi strategica e aiuta a rispondere a domande come «I clienti strategici hanno giorni medi di incasso inferiori?» o «Gli stralci sono più frequenti in un determinato settore?». Viene utilizzato direttamente nelle Dashboard «Andamento dei giorni medi di incasso», «Stralci di fatture inesigibili» e «Fatture scadute per segmento» per ottenere una visione d’insieme che va oltre i singoli clienti. Perché è importante Consente di aggregare l’analisi per gruppi di clienti, individuare tendenze strategiche e adattare le strategie di recupero ai diversi segmenti. Dove reperirli Spesso si tratta di un campo personalizzato o di un dato ricavato dagli attributi della tabella «CustTable» (tabella anagrafica dei clienti). Esempi EnterpriseMercato intermedioSettore pubblicoPartner
	Stato fattura InvoiceStatus	Stato attuale della fattura nel suo ciclo di vita.
Descrizione Lo stato della fattura offre una fotografia della sua posizione nel processo, per esempio «Aperta», «Pagata», «Contestata» o «Stralciata». Il registro delle attività fornisce una cronologia dettagliata, mentre lo stato attuale è un attributo utile a livello di caso per filtrare i dati e creare report di sintesi. Consente agli analisti di segmentare rapidamente i dati, concentrandosi solo sulle fatture scadute ancora aperte o analizzando le caratteristiche di tutte le fatture stralciate. È un modo semplice per comprendere lo stato attuale dei crediti verso clienti. Perché è importante Consente di filtrare e analizzare rapidamente le fatture in base allo stato attuale, per esempio concentrandosi su tutti i casi aperti o contestati. Dove reperirli Si ricava dallo stato di saldo delle transazioni nella tabella «CustTrans». Una transazione aperta non è stata pagata, mentre una chiusa è stata saldata. Esempi ApertaPagataPagata parzialmenteStralciata
	Codice valuta CurrencyCode	Valuta della fattura, per esempio USD o EUR.
Descrizione Il codice valuta specifica la valuta dell’importo della fattura. È un attributo contestuale importante, soprattutto per le organizzazioni multinazionali. È necessario per interpretare correttamente i valori finanziari e può aiutare a verificare se i cicli o i problemi di pagamento sono correlati a valute specifiche, per esempio a causa della complessità dei cambi o dei pagamenti internazionali. Perché è importante Fornisce il contesto necessario per interpretare tutti i valori monetari e consente di analizzare processi che coinvolgono più valute. Dove reperirli In genere, si trova nel campo «CurrencyCode» della tabella «CustInvoiceJour». Esempi USDEURGBPCAD
	Contestazione presente IsDisputed	Indicatore booleano che segnala se una fattura è stata contestata almeno una volta.
Descrizione Questo indicatore calcolato viene impostato su true se il caso della fattura contiene un’attività «Contestazione registrata». Semplifica l’analisi, perché consente di filtrare o confrontare facilmente i flussi di processo delle fatture contestate e non contestate. Per esempio, è possibile confrontare la media dei giorni di incasso delle fatture contestate con quella delle fatture non contestate e quantificare l’impatto delle contestazioni sui flussi di cassa. È un attributo utile per le Dashboard di sintesi e per le analisi comparative. Perché è importante Semplifica l’analisi e il filtraggio, consentendo di confrontare facilmente le fatture contestate con quelle non contestate. Dove reperirli È un campo calcolato. La logica è: IF the case contains a 'Dispute Registered' activity THEN true ELSE false. Esempi truefalse
	Limite di credito CreditLimit	Importo massimo di credito approvato per il cliente.
Descrizione Il limite di credito è l’importo massimo di debito che un cliente è autorizzato ad accumulare. Questo attributo è fondamentale per la gestione del rischio. La Dashboard «Analisi della gestione dei limiti di credito» confronta questo valore con gli importi delle fatture relative a clienti insolventi o con fatture stralciate. L’analisi aiuta a stabilire se i limiti di credito sono adeguati e vengono applicati, e se i clienti inadempienti hanno ricevuto di recente un aumento del limite, mettendo così in luce eventuali debolezze nel processo di approvazione del credito. Perché è importante È essenziale per la valutazione del rischio e aiuta a capire se gli stralci sono legati a limiti di credito inadeguati o gestiti male. Dove reperirli In genere, questo valore è memorizzato nell’anagrafica cliente della tabella «CustTable». Esempi 10000.0050000.000.00
	Motivo della contestazione DisputeReason	Motivo indicato dal cliente per contestare una fattura.
Descrizione Quando contesta una fattura, il cliente in genere ne indica il motivo, per esempio «Prezzo errato», «Merce danneggiata» o «Fatturazione duplicata». Questo attributo registra il motivo della contestazione. Analizzarlo è fondamentale per individuare le cause profonde dei problemi. Aiuta a rilevare criticità ricorrenti nel processo dall’ordine all’incasso, per esempio nei reparti vendite, spedizioni o fatturazione. Ridurre le contestazioni alla fonte è uno degli obiettivi principali di questa analisi e incide direttamente sui giorni medi di incasso, perché evita ritardi nei pagamenti. Perché è importante Fornisce dati fondamentali per individuare le cause profonde dei ritardi di pagamento e risolvere i problemi nelle fasi precedenti che portano alle contestazioni delle fatture. Dove reperirli Consultare la documentazione di Microsoft Dynamics 365. Queste informazioni fanno parte delle funzionalità di gestione delle contestazioni o dei casi. Esempi Errore di prezzoQuantità insufficienteProdotto non ricevutoServizio non conforme alla descrizione
	Paese Country	Paese dell’indirizzo di fatturazione del cliente.
Descrizione Questo attributo specifica il paese associato all’account cliente. È una dimensione comune per le analisi geografiche. Segmentare per paese KPI di processo come i giorni medi di incasso o il tasso di stralcio può rivelare differenze regionali nelle abitudini di pagamento dei clienti, nell’efficacia del recupero crediti o nelle condizioni economiche. Queste informazioni possono portare a strategie di recupero adattate alle diverse aree geografiche o a condizioni di pagamento specifiche per alcune regioni. Perché è importante Consente di svolgere analisi geografiche per individuare tendenze regionali nelle abitudini di pagamento e nelle prestazioni del processo di recupero crediti. Dove reperirli Si ricava collegando l’anagrafica cliente («CustTable») al relativo record dell’indirizzo principale, spesso presente 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 degli eventi. In questo caso, si tratta di «Microsoft Dynamics 365». Anche se nell’analisi di un singolo sistema può sembrare un dato statico, è fondamentale per la governance dei dati, la risoluzione dei problemi e le future integrazioni. Se si includessero dati provenienti da altri sistemi, come un CRM separato o un portale di un’agenzia di recupero crediti, questo campo sarebbe essenziale per distinguerli e comprendere il processo completo tra i diversi sistemi. Perché è importante Garantisce la tracciabilità dei dati ed è fondamentale per mantenerne la qualità e consentire analisi su più sistemi integrati. Dove reperirli In genere, si tratta di un valore statico aggiunto durante l’estrazione dei dati per indicare l’origine dei record. Esempi Microsoft Dynamics 365D365 F&O
	Tempo di risoluzione della contestazione DisputeResolutionTime	Tempo necessario per risolvere una contestazione del cliente, a partire dalla sua registrazione.
Descrizione Il tempo di risoluzione della contestazione misura l’efficienza del processo di gestione delle contestazioni. Si calcola come durata tra le attività «Contestazione registrata» e «Contestazione risolta». Tempi di risoluzione lunghi possono ritardare i pagamenti e ridurre la soddisfazione dei clienti. Analizzare questo indicatore per addetto al recupero o per motivo della contestazione aiuta a individuare i colli di bottiglia e le aree di miglioramento nel flusso di lavoro di gestione delle contestazioni. Perché è importante Misura l’efficienza del processo di gestione delle contestazioni, una causa frequente di ritardi significativi nei pagamenti. Dove reperirli Si calcola come durata tra le date e le ore delle attività «Contestazione registrata» e «Contestazione risolta». Esempi 7.215.83.5
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento o ricaricamento dei dati.
Descrizione Questo attributo indica l’ultima volta in cui il set di dati è stato aggiornato dal sistema di origine. È un metadato fondamentale per chi utilizza l’analisi di Process Mining, perché fornisce informazioni sull’attualità dei dati. Sapere fino a quale momento i dati sono aggiornati aiuta gli analisti a prendere decisioni informate e a comprendere la portata dei risultati. In genere, viene applicato all’intero set di dati durante il processo di acquisizione. Perché è importante Informa gli utenti sull’attualità dei dati, così che le analisi si basino su un intervallo temporale noto e le decisioni non vengano prese sulla base di informazioni obsolete. Dove reperirli Questo valore viene generato e aggiunto al set di dati dalla pipeline ETL o di elaborazione 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 fasi e le tappe principali da registrare nell’Event Log per ricostruire con precisione il flusso di lavoro 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, l’evento viene registrato quando un utente modifica lo stato della fattura in «Contestata» nel modulo di gestione del recupero crediti.
Perché è importante Questo è il punto di partenza del processo di gestione delle contestazioni. Monitorarlo consente di misurare la frequenza delle contestazioni e il tempo necessario per risolverle, con effetti sulla soddisfazione dei clienti e sui flussi di cassa. Dove reperirli Si deduce da una modifica dello stato della transazione cliente (CustTrans) o di una tabella correlata alla gestione delle contestazioni (smmCaseDetail). È necessario disporre di un registro delle modifiche di stato con data e ora. Acquisizione Individuare quando il campo dello stato della contestazione relativo a una transazione di fattura viene compilato o modificato in «Contestata». Tipo di evento inferred
	Data di scadenza del pagamento superata	Evento calcolato che si verifica quando la data corrente supera la data di scadenza della fattura. Non corrisponde a un’azione diretta dell’utente, ma viene ricavato confrontando la data di sistema con il campo della data di scadenza della fattura.
Perché è importante Questo evento dà avvio a tutte le attività di recupero crediti. Consente di analizzare il volume delle fatture scadute e la tempestività dei solleciti, supportando indicatori come il rispetto delle politiche di sollecito. Dove reperirli Calcolato confrontando l’ora corrente con il campo «DueDate» nella tabella delle transazioni cliente (CustTrans). L’ora dell’evento corrisponde alla data di scadenza stessa. Acquisizione Crei un evento quando «NOW()» è successivo alla data di scadenza della fattura. Tipo di evento calculated
	Fattura generata	Indica la creazione nel sistema di una fattura di vendita, prima della registrazione ufficiale. In genere, questa attività è rilevata come evento esplicito quando un utente finalizza un ordine di vendita e genera il relativo documento di fatturazione.
Perché è importante È l’evento di inizio principale del ciclo di vita della fattura. Analizzare il tempo che intercorre da questo momento al pagamento è fondamentale per misurare i giorni medi di incasso. Dove reperirli Registrato nella tabella Sales Invoice Header (SalesInvoiceHeader) o Sales Table (SalesTable) al momento della creazione della fattura. L’ora di creazione del record costituisce l’ora dell’evento. Acquisizione Acquisisca l’ora di creazione del record della fattura di vendita. Tipo di evento explicit
	Fattura registrata e inviata	Indica la registrazione ufficiale della fattura nella contabilità generale, che la rende un credito verso clienti formalmente rilevato. Questo evento coincide di solito con l’invio della fattura al cliente e viene acquisito al completamento della procedura di registrazione in Dynamics 365.
Perché è importante È una tappa fondamentale, che avvia ufficialmente il conteggio dei termini di pagamento e dell’anzianità del credito. I ritardi tra la generazione e la registrazione possono nascondere inefficienze nel processo di fatturazione. Dove reperirli Dedotto dalla data di registrazione nel giornale delle fatture cliente (CustInvoiceJour) o da una modifica dello stato a «Registrata». Il dato fondamentale è l’ora di registrazione. Acquisizione Utilizzi l’ora di registrazione del giornale delle fatture cliente (CustInvoiceJour). Tipo di evento inferred
	Fattura saldata	La fattura è stata pagata interamente e il saldo è pari a zero: il processo si è concluso con successo. Questo stato si deduce quando la somma dei pagamenti assegnati corrisponde all’importo totale della fattura.
Perché è importante È il principale esito positivo del processo dal credito all’incasso. Analizzare i percorsi che portano a questo esito aiuta a individuare le prassi migliori e le varianti di processo più efficienti. Dove reperirli Si deduce dalla data di saldo nella tabella dei saldi cliente (CustSettlement). Il saldo è pari a zero quando i campi «AmountCur» e «SettleAmountCur» della fattura in CustTrans, sommati, danno zero. Acquisizione Individuare 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 stralciata formalmente come credito inesigibile. Si tratta di un’azione esplicita eseguita da un utente autorizzato, che azzera il credito e registra la perdita.
Perché è importante È il principale esito negativo del processo. Monitorare gli stralci è fondamentale per comprendere il rischio di credito, le difficoltà di recupero e le perdite finanziarie. Dove reperirli Rilevato da una specifica transazione del giornale generale usata per stralciare crediti inesigibili e collegata alla fattura originale. La data di registrazione del giornale di stralcio funge da riferimento temporale. Acquisizione Individuare le registrazioni del giornale con uno specifico profilo di registrazione per gli stralci 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. L’evento viene acquisito quando in Dynamics 365 viene eseguito il processo periodico di sollecito, che 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 il rispetto delle politiche interne di recupero crediti. Dove reperirli Nella tabella della cronologia dei solleciti (CustCollectionLetterJour) viene creato un record esplicito. L’ora corrisponde alla data di creazione del giornale delle lettere di sollecito. Acquisizione Estragga gli eventi di creazione dalla tabella CustCollectionLetterJour e li colleghi alla fattura. Tipo di evento explicit
	Pagamento registrato	Rappresenta la registrazione ufficiale del pagamento del cliente nella contabilità generale e la sua assegnazione a saldo di una fattura. L’evento viene rilevato dalla data di registrazione del giornale dei pagamenti cliente.
Perché è importante Conclude la fase del processo relativa al pagamento. Il tempo tra la ricezione e la registrazione del pagamento, ovvero il ritardo nell’assegnazione dell’incasso, è un indicatore chiave di efficienza per l’ufficio finanziario. Dove reperirli Rilevato dalla data e ora di registrazione del giornale dei pagamenti cliente (LedgerJournalTrans). Conferma che il pagamento è stato elaborato completamente 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 di pagamento. L’evento precede la registrazione definitiva e l’assegnazione dell’incasso alla fattura specifica.
Perché è importante È una tappa fondamentale per calcolare i giorni medi di incasso e comprendere i flussi di cassa. Il tempo che intercorre tra questo evento e la registrazione del pagamento evidenzia i colli di bottiglia nel processo di assegnazione degli incassi. Dove reperirli Evento esplicito, rilevato 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 riportata nelle righe del giornale dei pagamenti cliente. Tipo di evento explicit
	Attività di recupero registrata	Indica un’azione manuale di recupero, come una telefonata o un’e-mail, registrata a carico del cliente o della fattura. L’evento viene acquisito quando un addetto utilizza la funzione Attività nell’area di lavoro dedicata al recupero crediti per registrare le proprie interazioni.
Perché è importante Offre visibilità sul lavoro manuale svolto dal team di recupero crediti. Analizzare queste attività in relazione ai pagamenti ricevuti aiuta a misurare la produttività del team e l’efficacia dei diversi metodi di contatto. Dove reperirli Registrato nelle tabelle Attività (smmActivities) o nelle tabelle correlate alla gestione dei casi associate al conto cliente. Se possibile, occorre collegare l’attività a una fattura specifica. Acquisizione Acquisisca la creazione dei record Attività di tipo «Telefonata» o «E-mail» relativi al recupero crediti. Tipo di evento explicit
	Contestazione risolta	Segna la conclusione della contestazione, quando è stata raggiunta e documentata una soluzione. L’evento viene registrato quando un utente aggiorna lo stato della contestazione della fattura impostandolo su «Risolta» oppure chiude il caso di contestazione associato.
Perché è importante Questa attività conclude il sottoprocesso di gestione delle contestazioni. La durata tra la registrazione e la risoluzione della contestazione è un KPI fondamentale per misurare l’efficienza del team che se ne occupa. Dove reperirli Si deduce da una modifica dello stato della transazione cliente (CustTrans) o dalla chiusura del caso di contestazione correlato (smmCaseDetail). L’ora della modifica di stato corrisponde all’ora dell’evento. Acquisizione Individuare quando il campo dello stato della contestazione relativo a una fattura viene cancellato o modificato in «Risolta». Tipo di evento inferred
	Promessa di pagamento creata	Il cliente si è impegnato a effettuare un pagamento in una data futura specifica e la promessa è stata registrata nel sistema. L’evento viene registrato esplicitamente quando un addetto al recupero crediti inserisce i dettagli della promessa di pagamento nel modulo dedicato.
Perché è importante Tiene traccia degli accordi informali di pagamento e della percentuale di promesse mantenute. Confrontare le promesse con i pagamenti effettivi può aiutare a prevedere i flussi di cassa e a valutare l’affidabilità dei clienti. Dove reperirli Probabilmente registrato nelle tabelle relative all’area di lavoro per il recupero crediti o alla gestione dei casi, in particolare in quelle dedicate alle promesse di pagamento. L’ora dell’evento corrisponde alla data di creazione del record della promessa. Acquisizione Acquisire gli eventi di creazione da una tabella di dettaglio dei casi di promessa di pagamento o di recupero crediti. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Microsoft Dynamics 365

Passaggi

Verifica dei prerequisiti: verifichi che la Sua organizzazione utilizzi Microsoft Dynamics 365 Finance e che la funzionalità Bring Your Own Database (BYOD) sia configurata per esportare attivamente le entità dati in un database Azure SQL. Dovrà disporre delle credenziali per l’accesso in lettura al database.
Individuazione delle entità dati: verifichi che le entità dati necessarie siano esportate da Dynamics 365 nel database BYOD. Le entità principali per questo processo sono: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment e CustDispute. Se ne manca qualcuna, ne configuri l’esportazione nell’area di lavoro Gestione dati di Dynamics 365.
Connessione al database BYOD: utilizzi un client SQL, ad esempio SQL Server Management Studio (SSMS) o Azure Data Studio, per connettersi al database Azure SQL configurato come destinazione BYOD.
Preparazione della query SQL: copi nel client SQL la query T-SQL completa riportata nella sezione query di questo documento. La query raccoglie in un unico Event Log tutte le attività e gli attributi richiesti.
Impostazione dei parametri della query: individui i segnaposto all’inizio della query. Sostituisca '{CompanyCode}' con l’ID dell’entità giuridica Dynamics 365 da analizzare, ad esempio «USMF». Sostituisca '{StartDate}' e '{EndDate}' con l’intervallo di date desiderato, nel formato «YYYY-MM-DD».
Esecuzione della query: esegua la query modificata sul database BYOD. Il tempo di esecuzione dipende dal volume di dati nell’intervallo selezionato.
Revisione dei risultati: al termine dell’esecuzione, il riquadro dei risultati mostrerà l’Event Log. Ogni riga rappresenta un’attività specifica nel ciclo di gestione del credito e recupero crediti relativo a una fattura. Verifichi che i dati siano completi e corretti.
Esportazione dell’Event Log: esporti i risultati della query in un file CSV. La maggior parte dei client SQL include una funzione per esportare i risultati. Faccia clic con il pulsante destro del mouse sulla griglia dei risultati e cerchi un’opzione come «Salva risultati con nome» o «Esporta».
Preparazione del caricamento: verifichi che il file CSV esportato utilizzi la codifica UTF-8 e che le intestazioni delle colonne corrispondano agli attributi richiesti: InvoiceNumber, ActivityName, EventTime e gli 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 richiede che diverse entità dati standard siano esportate nel database BYOD. Verifichi che il processo di esportazione includa almeno CustInvoiceJour, CustTrans, CustTable e CustSettlement. Per alcune attività sono necessarie anche entità aggiuntive, come CustCollectionLetterJour.
Intervallo di date: per gestire le prestazioni, è fondamentale filtrare la query in base a un intervallo di date specifico. 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 società: per garantire la coerenza dei dati, la query deve essere filtrata in base a una specifica entità giuridica (codice società). Utilizzi il segnaposto '{CompanyCode}' per indicare la società da analizzare.
Considerazioni sulle prestazioni: con insiemi di dati molto ampi, relativi a più anni o società, l’esecuzione della query può richiedere molto tempo. Valuti di eseguirla nelle ore di minore attività o di applicare filtri aggiuntivi per limitare i dati. Verifichi che le tabelle BYOD dispongano di 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

Prerequisiti e configurazione dell’ambiente: verifichi di avere installato Python 3.8 o versioni successive. Installi le librerie necessarie con pip: pip install pandas requests msal. Le serviranno anche le credenziali di un’entità servizio autorizzata ad accedere all’ambiente Dynamics 365.
Registrazione dell’applicazione in Azure AD: acceda al portale Azure Active Directory e registri una nuova applicazione per ottenere un ID client e un ID Tenant. Nella sezione «Certificati e segreti» dell’applicazione, crei un nuovo segreto client. Conservi in modo sicuro l’ID client, l’ID Tenant e il segreto client.
Concessione delle autorizzazioni API: nelle impostazioni «Autorizzazioni API» 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 amministrativo per l’organizzazione.
Creazione di un utente Dynamics 365: crei un utente applicazione dedicato in Dynamics 365 Finance and Operations e lo associ all’ID client dell’applicazione Azure AD. Assegni all’utente un ruolo di sicurezza con autorizzazioni di lettura per tutte le entità dati richieste, ad esempio CustInvoiceJour, CustCollectionLetterJour, CustSettlements e smmActivities.
Configurazione dello script Python: copi lo script Python fornito in un file, ad esempio extract_d365_collections.py. Inserisca nelle variabili segnaposto all’inizio dello script l’URL dell’ambiente D365, l’ID Tenant, l’ID client, il segreto client e la società predefinita (dataAreaId).
Impostazione dei parametri di estrazione: modifichi le variabili start_date e end_date nello script per definire l’intervallo temporale dei dati da estrarre. Per l’analisi iniziale si consiglia un periodo compreso tra 3 e 6 mesi.
Esecuzione dello script: esegua lo script dal terminale con 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.
Recupero dei dati per ogni attività: lo script effettua chiamate API in sequenza per recuperare i dati relativi alla creazione delle fatture, alla registrazione, ai solleciti, ai pagamenti e ad altri eventi chiave. Ogni query si rivolge a un’entità dati specifica e seleziona solo i campi necessari per ottimizzare le prestazioni.
Trasformazione e unione dei dati: lo script utilizza la libreria pandas per elaborare la risposta JSON di ogni chiamata API. Trasforma i dati in una tabella strutturata, uniforma i nomi delle colonne e unisce i dati di tutte le attività in un unico Event Log.
Calcolo degli eventi derivati: l’attività «Data di scadenza del pagamento superata» non corrisponde a un record diretto nel sistema. Lo script calcola l’evento esaminando tutte le fatture scadute nell’intervallo specificato e generando una riga corrispondente per ciascuna.
Esportazione dell’Event Log: una volta elaborati e uniti tutti i dati, lo script salva l’Event Log finale in un 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, nel formato https://[your-environment-name].operations.dynamics.com.
Credenziali di autenticazione: lo script richiede l’ID Tenant, l’ID client e il segreto client di un’applicazione registrata in Azure Active Directory. L’applicazione deve disporre delle autorizzazioni per accedere all’API Dynamics 365.
Filtro società (dataAreaId): Dynamics 365 è un sistema multi-società. Lo script è configurato per interrogare una società specifica utilizzando il filtro dataAreaId. Verifichi che la variabile default_company indichi l’entità giuridica corretta, ad esempio «USMF».
Intervallo di date: i parametri start_date e end_date definiscono l’intervallo di estrazione. Per gestire il volume dei dati e completare l’estrazione in tempi ragionevoli, si consiglia di iniziare con un periodo recente compreso tra 3 e 6 mesi. Il filtro viene applicato principalmente alla data di creazione della fattura.
Considerazioni sulle prestazioni: l’estrazione di insiemi di dati molto ampi tramite l’API OData può richiedere molto tempo ed essere soggetta a limitazioni delle richieste da parte di Microsoft. In caso di problemi, valuti di utilizzare intervalli di date più brevi o di eseguire l’estrazione nelle ore di minore attività.
Prerequisiti: è necessario un ambiente Python 3.8 o successivo 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 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 a iniziare?

Utilizzi questo template per preparare i dati in modo efficace e ottenere informazioni utili sulle attività di gestione del credito e recupero crediti. Inizi oggi 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 crediti per accelerare gli incassi

Migliori il flusso di cassa rendendo più efficiente il ciclo dal credito all’incasso e riducendo del 30% il tempo di ciclo.

Inizi la prova gratuita

Non è richiesta la carta di credito. La configurazione richiede pochi minuti.

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

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

Attributi per la gestione del credito e il 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 con API REST OData di Dynamics 365

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi oggi la gestione del credito e il recupero crediti per accelerare gli incassi

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

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

Attributi per la gestione del credito e il 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 con API REST OData di Dynamics 365

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi oggi la gestione del credito e il recupero crediti per accelerare gli incassi

La Sua privacy è importante