Il template dei dati per la gestione di resi e rimborsi
Il template dei dati per la gestione di resi e rimborsi
- Campi dati consigliati da raccogliere
- Fasi principali del processo da monitorare
- Istruzioni per l’estrazione dei dati
Attributi per la gestione di resi e rimborsi
| Nome | Descrizione | ||
|---|---|---|---|
| Data e ora dell’evento EventTime | Data e ora che indicano quando si è verificata una specifica attività o un evento. | ||
| Descrizione La data e ora dell’evento, o timestamp, registra il momento esatto in cui si è svolta un’attività. Ogni attività nell’Event Log ha un timestamp corrispondente, che stabilisce l’ordine cronologico degli eventi. Questo attributo è fondamentale per tutte le analisi dei processi basate sul tempo. Viene utilizzato per calcolare i tempi di ciclo tra le attività, individuare i tempi di attesa e i colli di bottiglia, misurare la durata complessiva dei casi e verificare il rispetto degli accordi sul livello del servizio (SLA). La precisione dei timestamp incide direttamente sull’affidabilità di qualsiasi analisi delle prestazioni. Perché è importante Questo timestamp è essenziale per calcolare tutte le metriche basate sulla durata, come i tempi di ciclo e di attesa, fondamentali per l’analisi delle prestazioni. Dove reperirli Corrisponde ai campi di data di creazione o modifica presenti in diverse tabelle, ad esempio 'SalesTable.createdDateTime' per la creazione degli ordini o 'WMSJournalTrans.createdDateTime' per i giornali di magazzino. Esempi 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| ID del caso di reso ReturnCaseId | Identificativo univoco del caso di reso e rimborso di un cliente, che collega tutte le attività correlate. | ||
| Descrizione L’ID del caso di reso è l’identificativo principale di ogni singola istanza del processo di reso. Collega tutte le attività associate a uno specifico reso o a una richiesta di rimborso, dalla creazione iniziale dell’ordine di reso fino alla chiusura. Nell’analisi dei processi, questo ID è fondamentale per ricostruire il percorso completo di ogni reso. Consente di monitorare l’intero ciclo di vita, misurare i tempi di ciclo complessivi e analizzare le differenze tra i vari casi. Tutti gli eventi, i dati e le metriche vengono aggregati e correlati utilizzando questo identificativo. Perché è importante È l’identificativo essenziale del caso, che collega tutti i passaggi del processo e permette di tracciare e analizzare ogni reso dall’inizio alla fine. Dove reperirli In genere, si tratta del numero di autorizzazione al reso (RMA) o del numero dell’ordine cliente di tipo 'Returned Order' nel modulo 'Sales and marketing'. Si trova in tabelle come 'SalesTable', dove 'SalesType' è 'Returned Order'. Esempi RMA-001234RMA-001235RMA-001236 | |||
| Nome dell’attività ActivityName | Nome dell’evento aziendale o dell’attività specifica che si è verificata nel processo di gestione dei resi e dei rimborsi. | ||
| Descrizione Questo attributo descrive un passaggio o un evento specifico nel ciclo di gestione dei resi e dei rimborsi, ad esempio 'Ordine di reso creato', 'Articolo ricevuto' o 'Nota di credito contabilizzata'. Ogni attività rappresenta un momento distinto del processo, registrato nel sistema. Analizzare la sequenza e la frequenza di queste attività è il fulcro del Process Mining. Consente di visualizzare le mappe del processo, individuare i colli di bottiglia tra i passaggi e scoprire le varianti di processo più e meno comuni. L’insieme delle attività definisce l’ambito del processo analizzato. Perché è importante Definisce i passaggi del processo e consente di visualizzarne il flusso e di individuare colli di bottiglia, rilavorazioni e deviazioni. Dove reperirli È un attributo concettuale ricavato dagli eventi del sistema. Può essere generato associando le modifiche di stato nelle tabelle come 'SalesTable' e 'WMSJournalTable' o eventi specifici a nomi di facile comprensione. Esempi Ordine di reso creatoArticolo ricevutoCodice di destinazione assegnatoNota di credito contabilizzata | |||
| Canale di reso ReturnChannel | Il metodo o il canale utilizzato dal cliente per avviare il reso. | ||
| Descrizione Questo attributo indica il canale utilizzato dal cliente per avviare la procedura di reso, ad esempio «Portale online», «In negozio», «Chiamata al servizio clienti» o «Posta». Suddividere l’analisi del processo per canale di reso consente di valutare le prestazioni e l’efficienza di ciascun canale. L’azienda può confrontare tempi di ciclo, costi e soddisfazione dei clienti per individuare le prassi più efficaci e le aree in cui investire o intervenire. Questo dato è essenziale per la Dashboard «Prestazioni di utilizzo del canale di reso». Perché è importante Consente di confrontare le prestazioni dei diversi canali di reso e di ottimizzare quelli più efficienti e convenienti. Dove reperirli Questa informazione può essere registrata nell’intestazione dell’ordine di reso ('SalesTable') oppure ricavata dall’utente che ha creato l’ordine. Potrebbe essere necessaria una logica personalizzata o un campo dedicato. Esempi Portale webChiosco in negozioAssistenza clienti | |||
| Codice di destinazione DispositionCode | Codice che indica l’esito dell’ispezione dell’articolo e l’azione successiva da intraprendere. | ||
| Descrizione Il codice di destinazione viene assegnato durante il controllo qualità di un articolo reso. Determina il passaggio successivo del processo, ad esempio 'Credit', 'Replace', 'Scrap' o 'Return to Customer'. Questo attributo rappresenta un momento decisionale fondamentale nel processo di gestione dei resi. Analizzare i dati per codice di destinazione consente alle aziende di comprendere gli esiti dei resi, monitorare l’impatto finanziario degli articoli scartati e valutare l’efficienza dei diversi percorsi di risoluzione, come la sostituzione rispetto al rimborso. Perché è importante Questo codice determina il percorso seguito da una pratica di reso dopo l’ispezione ed è quindi fondamentale per analizzare le varianti del processo e i relativi risultati aziendali. Dove reperirli È un campo chiave del modulo di gestione della qualità, associato all’elaborazione degli ordini di qualità o di ispezione. Esempi CRDTREPL-DSCRAPRTV | |||
| Codice motivo del reso ReturnReasonCode | Il motivo indicato dal cliente per la restituzione dell’articolo. | ||
| Descrizione Il codice motivo del reso registra la ragione indicata dal cliente, ad esempio «Articolo difettoso», «Taglia errata», «Non conforme alla descrizione» o «Non più necessario». In genere, questa informazione viene raccolta all’avvio della procedura di reso. Analizzare i motivi dei resi è fondamentale per individuarne le cause profonde. Aiuta le aziende a rilevare problemi di qualità dei prodotti, descrizioni inesatte o errori logistici. Le informazioni raccolte possono orientare interventi di miglioramento nella progettazione dei prodotti, nel marketing e nella gestione della catena di fornitura, riducendo così i resi futuri. Perché è importante Fornisce informazioni essenziali sui motivi dei resi e consente di individuarne le cause profonde, ridurre il tasso di reso e migliorare la soddisfazione dei clienti. Dove reperirli In genere, questo dato è registrato a livello di riga dell’ordine di reso. Per gli ordini di reso, cerchi i campi relativi al codice motivo nella tabella 'SalesLine'. Esempi DIFETTOARTICOLO_ERRATONON_PIÙ_DESIDERATODANNEGGIATO_DURANTE_IL_TRASPORTO | |||
| ID prodotto ProductId | L’identificativo univoco del prodotto restituito. | ||
| Descrizione L’ID prodotto, spesso corrispondente allo SKU (Stock Keeping Unit), identifica l’articolo specifico restituito dal cliente. A ogni riga dell’ordine di reso è associato un ID prodotto. Analizzare i resi per prodotto è essenziale per individuare gli articoli con un tasso di reso elevato. Questo può segnalare problemi di controllo qualità, descrizioni inesatte o difetti di fabbricazione. L’analisi aiuta a stabilire le priorità per le verifiche e gli interventi di miglioramento relativi ai prodotti. Perché è importante Consente di analizzare i resi per singolo prodotto e di individuare gli articoli con problemi di qualità o un volume elevato di resi. Dove reperirli Corrisponde al campo 'ItemId' della tabella 'SalesLine' relativo all’ordine di reso. Esempi SKU-A-123SKU-B-456SKU-C-789 | |||
| Utente responsabile ResponsibleUser | Utente o dipendente che ha svolto o è responsabile di una specifica attività. | ||
| Descrizione Questo attributo identifica la persona responsabile dell’esecuzione di un passaggio del processo. Può trattarsi dell’addetto di magazzino che ha ricevuto l’articolo, dell’ispettore della qualità o dell’impiegato amministrativo che ha contabilizzato la nota di credito. Analizzare il processo per utente aiuta a comprendere la distribuzione del carico di lavoro, individuare chi ottiene i risultati migliori e rilevare eventuali esigenze di formazione. Consente inoltre di esaminare i casi gestiti da singole persone o team e di garantire un’adeguata separazione delle mansioni. Perché è importante Consente di analizzare la distribuzione del carico di lavoro e i risultati di singole persone o team, nonché di individuare opportunità di formazione o di assegnazione delle risorse. Dove reperirli Si trova nei campi 'created by' o 'modified by' dei record delle transazioni, ad esempio 'SalesTable.createdBy' o negli ID utente collegati nelle tabelle dei giornali. Esempi Alice.WBob.JChris.P | |||
| Data obiettivo SLA del rimborso RefundSlaTargetDate | La data entro cui la pratica di reso e rimborso dovrebbe essere risolta completamente. | ||
| Descrizione Questo attributo definisce la scadenza prevista dall’accordo sul livello di servizio (SLA) per la risoluzione di una pratica di reso. Indica la data entro cui il cliente dovrebbe ricevere una soluzione definitiva, ad esempio un rimborso registrato o un articolo sostitutivo spedito. La data obiettivo è essenziale per monitorare le prestazioni rispetto agli impegni di servizio. Viene utilizzata per calcolare il KPI «Tasso di rispetto dello SLA di risoluzione» e alimentare la Dashboard «Prestazioni SLA per la risoluzione dei rimborsi». Confrontandola con la data effettiva di completamento del processo, l’azienda può individuare le violazioni degli SLA e gestire in modo proattivo le pratiche ancora aperte da più tempo. Perché è importante È il valore di riferimento per misurare le prestazioni del processo, monitorare il rispetto degli SLA e individuare le pratiche in ritardo. Dove reperirli Potrebbe non essere un campo standard. Spesso viene calcolata sommando un periodo SLA predefinito (ad esempio, 14 giorni) alla data di creazione del reso e può essere registrata in un campo personalizzato. Esempi 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| ID cliente CustomerId | L’identificativo univoco del cliente che ha avviato il reso. | ||
| Descrizione L’ID cliente identifica in modo univoco l’account associato al reso e collega la transazione a uno specifico cliente nel CRM o nel database clienti. L’analisi dei resi per cliente permette di individuare chi effettua resi con una frequenza insolitamente elevata, un possibile segnale di frode o di insoddisfazione persistente. Consente inoltre di segmentare la clientela, ad esempio offrendo servizi di reso premium ai clienti di maggior valore. Perché è importante Collega la procedura di reso a uno specifico cliente e consente di analizzare i dati a livello di cliente, individuando schemi ricorrenti nei resi o possibili frodi. Dove reperirli È il campo 'CustAccount' della tabella 'SalesTable' relativo all’ordine di reso. Esempi CUST-00045CUST-00192CUST-00315 | |||
| ID magazzino WarehouseId | L’identificativo del magazzino o della sede in cui viene ricevuto l’articolo restituito. | ||
| Descrizione Questo attributo identifica il magazzino fisico o il centro resi che gestisce l’articolo restituito. Le diverse sedi possono adottare processi diversi e disporre di risorse o livelli di prestazione differenti. Analizzare il processo per magazzino consente di confrontare le prestazioni delle diverse sedi. Aiuta a individuare i centri più efficienti nella gestione dei resi, a rilevare i colli di bottiglia a livello regionale e a orientare le decisioni sull’allocazione delle risorse e sulla standardizzazione dei processi nella rete logistica. Perché è importante Consente di confrontare le prestazioni dei diversi magazzini o centri resi e di individuare i colli di bottiglia regionali e le prassi più efficaci. Dove reperirli Questa informazione è registrata nel campo 'InventLocationId' delle transazioni relative alle scorte, ad esempio nel giornale di arrivo ('WMSJournalTable') o in 'SalesLine'. Esempi WH-EASTWH-WESTCENTRAL-DC | |||
| ID nota di credito CreditNoteId | L’identificativo univoco della nota di credito creata per un rimborso. | ||
| Descrizione Quando viene elaborato un rimborso, viene generato un documento finanziario denominato nota di credito. Questo attributo ne registra l’ID univoco. L’ID collega direttamente il processo operativo di reso alle registrazioni finanziarie nel sistema contabile. È utile ai fini della revisione e per approfondire gli scostamenti finanziari, poiché consente all’analista di seguire la pratica di reso fino alla specifica transazione finanziaria che l’ha chiusa. Perché è importante Collega il processo operativo di reso alla transazione finanziaria corrispondente, un passaggio fondamentale per le revisioni e la riconciliazione finanziaria. Dove reperirli Il numero della nota di credito si trova in genere nel campo 'InvoiceId' della tabella 'CustInvoiceJour', dove il tipo di transazione è 'Credit note'. È possibile collegarlo all’ordine di reso. Esempi CN-10056CN-10057CN-10058 | |||
| Importo del rimborso richiesto RequestedRefundAmount | Il valore monetario totale del rimborso richiesto dal cliente. | ||
| Descrizione Questo attributo rappresenta l’importo iniziale del rimborso richiesto o previsto all’avvio della procedura di reso. In genere, si basa sul prezzo di acquisto originale degli articoli restituiti. Il valore costituisce la base di riferimento per l’«Analisi degli scostamenti dell’importo del rimborso». Confrontando l’importo richiesto con quello effettivamente rimborsato, l’azienda può individuare differenze dovute a spese di riassortimento, rimborsi parziali per articoli danneggiati o altri adeguamenti. Questo confronto aiuta a monitorare l’accuratezza finanziaria e il rispetto delle politiche aziendali. Perché è importante Costituisce la base di riferimento per valutare l’accuratezza finanziaria, confrontandolo con l’importo effettivamente rimborsato. Dove reperirli In genere, corrisponde all’importo della riga o all’importo totale della riga dell’ordine di vendita originale relativa all’articolo restituito; si trova in 'SalesLine.LineAmount'. Esempi 99.99150.0024.50 | |||
| Importo effettivo del rimborso ActualRefundAmount | Il valore monetario finale del rimborso erogato al cliente. | ||
| Descrizione Questo attributo indica l’importo finale e confermato rimborsato al cliente. Il valore viene registrato al momento della creazione e della registrazione della nota di credito. È un attributo fondamentale per l’analisi finanziaria e viene utilizzato direttamente nella Dashboard «Analisi degli scostamenti dell’importo del rimborso» e nel KPI «Tasso di accuratezza dell’importo del rimborso». Analizzare questi dati aiuta a comprendere l’impatto finanziario dei resi e gli eventuali adeguamenti apportati durante il processo. Perché è importante Rappresenta l’impatto finanziario effettivo del reso ed è fondamentale per calcolare l’accuratezza dei rimborsi e comprenderne gli esiti finanziari. Dove reperirli Il valore è disponibile nei dettagli della transazione della nota di credito registrata. È associato alle tabelle 'CustTrans' e 'CustInvoiceJour' relative alla nota di credito. Esempi 99.99135.000.00 | |||
| Ora di fine EndTime | Data e ora che indicano quando è stata completata una specifica attività. | ||
| Descrizione L’ora di fine indica il timestamp di completamento di un’attività. Se StartTime ne segna l’inizio, EndTime ne indica la conclusione e consente di calcolare il tempo di elaborazione dell’attività specifica. Questo attributo è fondamentale per un’analisi dettagliata delle prestazioni, soprattutto per le attività di durata misurabile, come 'Ispezione dell’articolo'. Confrontando StartTime ed EndTime, gli analisti possono misurare con precisione il tempo di elaborazione effettivo delle attività e distinguerlo dal tempo di attesa tra un’attività e l’altra. In questo modo, è possibile individuare le inefficienze all’interno delle singole attività, non solo negli intervalli tra di esse. Perché è importante Consente di calcolare il tempo di elaborazione effettivo delle singole attività e di distinguere il tempo di attesa dal tempo di lavoro vero e proprio. Dove reperirli Spesso deve essere ricavata. Ad esempio, può corrispondere al campo 'modifiedDateTime' di una modifica di stato che conclude un’attività oppure allo StartTime dell’attività successiva. Esempi 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| Rispetta la politica aziendale IsPolicyAdherent | Un indicatore che segnala se l’approvazione del reso è conforme alle politiche aziendali stabilite. | ||
| Descrizione Questo attributo booleano calcolato indica se un reso soddisfa tutti i criteri definiti nella politica aziendale. Il calcolo può basarsi su fattori quali il periodo utile per il reso, le condizioni dell’articolo o il motivo della restituzione. L’attributo alimenta direttamente la Dashboard «Panoramica della conformità delle approvazioni dei resi» e il KPI «Tasso di approvazione conforme dei resi». Consente all’azienda di quantificare il rispetto delle politiche, individuare le pratiche approvate in via eccezionale e analizzare i motivi e la frequenza di tali eccezioni. È un dato essenziale per la governance e il controllo dei costi. Perché è importante Misura direttamente il rispetto delle regole aziendali e aiuta a individuare e ridurre le approvazioni di resi non conformi, che possono comportare perdite di ricavi. Dove reperirli È un attributo derivato. La logica va definita confrontando gli attributi del reso, ad esempio la data del reso rispetto alla data di acquisto e il motivo della restituzione, con regole aziendali predefinite. Esempi truefalse | |||
| Sistema di origine SourceSystem | Sistema informativo da cui sono stati estratti i dati degli eventi. | ||
| Descrizione Questo attributo identifica il sistema informativo di origine dei dati. In questo caso, si tratta principalmente di 'Microsoft Dynamics 365'. Nelle organizzazioni più grandi, un processo può coinvolgere più sistemi. Specificare il sistema di origine di ogni evento è fondamentale per la governance dei dati, la risoluzione dei problemi di estrazione e la comprensione dell’architettura tecnologica del processo. Conferma la provenienza dei dati analizzati. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, indispensabili per la governance e la convalida dei dati e per comprendere i sistemi coinvolti nel processo. Dove reperirli In genere, è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine del set di dati. Esempi Microsoft Dynamics 365 F&OD365-PROD | |||
| Stato dell’ordine di reso ReturnOrderStatus | Lo stato complessivo dell’ordine di reso al momento dell’evento. | ||
| Descrizione Questo attributo indica lo stato corrente dell’intestazione dell’ordine di reso, ad esempio «Aperto», «Fatturato» o «Annullato». Offre una panoramica della fase del ciclo di vita in cui si trova la pratica. Le attività descrivono le singole fasi del processo, mentre lo stato complessivo è utile per filtrare e segmentare le pratiche. Ad esempio, un analista può concentrarsi solo sulle pratiche «Aperte» per comprendere il carico di lavoro corrente oppure analizzare il flusso delle pratiche che vengono infine «Annullate». Perché è importante Riassume lo stato generale della pratica ed è utile per filtrare le pratiche e comprendere esiti come gli annullamenti. Dove reperirli Questa informazione si trova nel campo 'SalesStatus' o 'DocumentStatus' della tabella 'SalesTable'. Esempi Ordine apertoConsegnatoFatturatoAnnullato | |||
| Stato SLA SlaStatus | Indica se la pratica è stata risolta entro la scadenza prevista dall’accordo sul livello di servizio. | ||
| Descrizione Questo attributo calcolato fornisce un’indicazione semplice del rispetto dello SLA, in genere «Nei tempi» o «In ritardo». Il valore si ottiene confrontando la data e l’ora dell’ultima attività, ad esempio «Ordine di reso chiuso», con l’attributo 'RefundSlaTargetDate'. L’attributo semplifica la reportistica sulle prestazioni nelle Dashboard come «Prestazioni SLA per la risoluzione dei rimborsi». Invece di dover confrontare le date, gli utenti dispongono di uno stato diretto e facilmente comprensibile. Possono così filtrare e aggregare rapidamente i dati per calcolare il «Tasso di rispetto dello SLA di risoluzione» complessivo. Perché è importante Fornisce un’indicazione immediata e semplice del rispetto dello SLA, facilitando il filtro delle pratiche in ritardo e l’analisi delle cause profonde dei ritardi. Dove reperirli È un attributo derivato, calcolato confrontando la data e l’ora dell’attività di risoluzione finale con l’attributo 'RefundSlaTargetDate'. Esempi Nei tempiIn ritardo | |||
| Tipo di reso ReturnType | Classifica il reso in base all’esito previsto, ad esempio rimborso o sostituzione. | ||
| Descrizione Questo attributo classifica la pratica di reso in base al tipo di soluzione richiesto dal cliente o offerto dall’azienda. Tra le opzioni più comuni figurano il rimborso in denaro, la sostituzione con un altro articolo o la riparazione. Questa classificazione è utile per analizzare i diversi percorsi del processo. La procedura per emettere un rimborso è molto diversa da quella necessaria per spedire un articolo sostitutivo. Suddividere i dati per tipo di reso consente di analizzare con maggiore precisione i tempi di ciclo e i colli di bottiglia specifici di ciascun percorso di risoluzione. Perché è importante Consente di segmentare l’analisi in base all’esito previsto, poiché le procedure di rimborso e sostituzione prevedono fasi e tempi di ciclo diversi. Dove reperirli Potrebbe essere un campo personalizzato nell’intestazione dell’ordine di reso oppure essere ricavato dal codice di destinazione o da transazioni successive, come la creazione di un ordine di vendita sostitutivo. Esempi RimborsoSostituzioneCredito in negozio | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultimo aggiornamento dei dati del processo. | ||
| Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione dei dati dal sistema di origine e del loro aggiornamento nello strumento di Process Mining. Indica quanto sono aggiornati i dati analizzati. Conoscere la data e l’ora dell’ultimo aggiornamento è importante per valutare l’attualità dell’analisi. Aiuta a interpretare correttamente le Dashboard e i KPI, chiarendo se si tratta di dati in tempo reale o di un’istantanea riferita a un momento specifico. È un’informazione essenziale per il monitoraggio operativo. Perché è importante Indica quanto sono aggiornati i dati, così gli analisti possono valutare l’attualità delle informazioni sul processo. Dove reperirli È un attributo di metadati generato e memorizzato durante il flusso di acquisizione dei dati, che in genere corrisponde al timestamp di completamento del processo ETL. Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
Attività di gestione di resi e rimborsi
| Attività | Descrizione | ||
|---|---|---|---|
| Articolo ricevuto | Segna la ricezione fisica dell’articolo reso in magazzino o presso il centro resi designato. Viene registrata quando si contabilizza il giornale di arrivo associato all’ordine di reso. | ||
| Perché è importante È una tappa fondamentale, che segna il passaggio dalle attività del cliente alla gestione interna. Da questo momento si calcolano tutti i tempi di gestione interna, ad esempio quelli di ispezione e assegnazione della destinazione. Dove reperirli Data e ora di contabilizzazione del giornale WMS o del giornale di arrivo dell’articolo associato alla riga ReturnOrder. Le transazioni di magazzino vengono aggiornate allo stato 'Registered' o 'Received'. Acquisizione Evento di contabilizzazione del giornale di arrivo dell’articolo collegato alla riga dell’ordine di reso. Tipo di evento explicit | |||
| Codice di destinazione assegnato | Questa attività indica che l’ispezione è terminata e che è stata presa una decisione sull’articolo reso. Alla riga del reso viene assegnato un codice di destinazione, ad esempio 'Credit', 'Scrap' o 'Replace'. | ||
| Perché è importante È un momento decisionale fondamentale, che determina il percorso successivo del processo: rimborso, sostituzione o rifiuto. Eventuali ritardi in questa fase possono incidere sensibilmente sui tempi complessivi di risoluzione. Dove reperirli L’evento viene registrato quando il campo DispositionCode viene compilato nella transazione di magazzino della riga dell’ordine di reso o nel giornale correlato. Acquisizione Evento di aggiornamento in cui viene impostato DispositionCode per la riga dell’ordine di reso. Tipo di evento explicit | |||
| Nota di credito contabilizzata | La nota di credito viene contabilizzata nei registri finanziari e diventa disponibile per il cliente. Questo segna il completamento del rimborso dal punto di vista dell’azienda. | ||
| Perché è importante È una tappa finanziaria fondamentale, che conferma l’elaborazione del rimborso nel sistema. Spesso è un’attività chiave per misurare il rispetto degli SLA relativi ai rimborsi. Dove reperirli Data e ora di contabilizzazione del giornale fatture dell’ordine di reso, che finalizza la nota di credito. Lo stato dell’ordine di reso diventa 'Invoiced'. Acquisizione Contabilizzazione del giornale fatture dell’ordine di reso. Tipo di evento explicit | |||
| Ordine di reso chiuso | L’ordine di reso ha raggiunto lo stato finale: tutte le transazioni fisiche e finanziarie sono state completate. In genere, ciò avviene dopo la contabilizzazione della nota di credito o la spedizione dell’articolo sostitutivo. | ||
| Perché è importante È l’evento finale principale di un processo di reso completato correttamente. Il tempo che intercorre tra la creazione e questo momento rappresenta il tempo di ciclo complessivo del caso. Dove reperirli Si deduce dalla modifica del campo di stato ReturnOrder al valore finale, ad esempio 'Invoiced' o 'Closed'. Indica che non sono previste ulteriori attività. Acquisizione Modifica del campo SalesTable.Status o SalesTable.DocumentStatus a uno stato finale. Tipo di evento inferred | |||
| Ordine di reso creato | Questa attività segna l’avvio del processo di reso, con la creazione nel sistema di un’autorizzazione al reso (RMA) o di un ordine di reso. Si tratta di un evento esplicito, registrato quando viene creato un nuovo record ReturnOrder in Dynamics 365. | ||
| Perché è importante È l’evento di inizio principale dell’intero processo di reso. Analizzare il tempo che intercorre tra questa attività e le successive consente di calcolare il tempo di attraversamento complessivo e di individuare i colli di bottiglia nelle prime fasi. Dove reperirli L’evento viene registrato in base alla data e all’ora di creazione dell’intestazione ReturnOrder. In genere, si trova in SalesTable, dove SalesType è 'Returned Order'. Acquisizione Evento di creazione del record SalesTable con SalesType = 'Returned Order'. Tipo di evento explicit | |||
| Articolo sostitutivo spedito | La bolla di accompagnamento dell’articolo sostitutivo viene contabilizzata, a indicare che l’articolo è stato spedito al cliente. Questo segna il completamento della procedura di sostituzione. | ||
| Perché è importante È una tappa fondamentale nella variante di sostituzione e rappresenta l’adempimento dell’impegno dell’azienda nei confronti del cliente. È importante per monitorare i tempi di ciclo delle sostituzioni. Dove reperirli Data di contabilizzazione del giornale della bolla di accompagnamento per l’ordine cliente dell’articolo sostitutivo. Lo stato dell’ordine diventa 'Delivered'. Acquisizione Contabilizzazione della bolla di accompagnamento per l’ordine cliente dell’articolo sostitutivo. Tipo di evento explicit | |||
| Giornale di arrivo creato | Questa attività indica che il magazzino è in attesa dell’arrivo dell’articolo reso. Consiste nella creazione di un giornale di arrivo, che prepara il sistema alla ricezione fisica della merce. | ||
| Perché è importante Questo passaggio distingue la preparazione logistica dalla ricezione fisica vera e propria. Aiuta ad analizzare la preparazione del magazzino e a pianificare i resi in arrivo. Dove reperirli Creazione di un record in WMSJournalTable con JournalType 'Arrival'. Il giornale è collegato alla riga dell’ordine di reso. Acquisizione Data e ora di creazione del record WMSJournalTable relativo al reso. Tipo di evento explicit | |||
| Nota di credito creata | Quando la destinazione è 'Credit', viene generata una nota di credito che autorizza il rimborso al cliente. Questo segna l’avvio formale della fase di liquidazione finanziaria del processo. | ||
| Perché è importante Questa attività segna l’approvazione del rimborso. Il tempo che intercorre tra l’assegnazione della destinazione e la creazione della nota di credito mette in luce i ritardi amministrativi nell’avvio del rimborso. Dove reperirli È possibile dedurlo dalla creazione di un nuovo record SalesTable con valore negativo, collegato all’ordine di reso originale, oppure dall’esecuzione del processo batch 'Create credit note'. Acquisizione Creazione di una nota di credito, spesso tramite la contabilizzazione della fattura dell’ordine di reso. Tipo di evento explicit | |||
| Ordine di controllo qualità generato | Viene creato un ordine di controllo qualità, a indicare che l’articolo reso deve essere sottoposto a un’ispezione strutturata. È una procedura comune quando i resi richiedono test approfonditi o verifiche rispetto agli standard di qualità. | ||
| Perché è importante Questa attività segna l’inizio di un’ispezione formale. Monitorare il tempo a partire da questo momento aiuta a misurare l’efficienza e la durata del flusso di lavoro per il controllo qualità. Dove reperirli Data e ora di creazione di un record in InventQualityOrderTable collegato all’ordine di reso. Acquisizione Creazione di un record InventQualityOrderTable. Tipo di evento explicit | |||
| Ordine di reso annullato | L’ordine di reso viene annullato prima del completamento, ad esempio su richiesta del cliente o perché l’articolo non è mai stato restituito. | ||
| Perché è importante Rappresenta una conclusione alternativa e non riuscita del processo. Analizzare i motivi dell’annullamento dei resi può fornire informazioni sul comportamento dei clienti o sulle criticità del processo. Dove reperirli Si deduce dalla modifica del campo di stato ReturnOrder a 'Cancelled'. Questo stato finale è distinto dalla chiusura corretta dell’ordine. Acquisizione Modifica del campo SalesTable.Status a 'Cancelled'. Tipo di evento inferred | |||
| Ordine di reso confermato | Indica la conferma formale dell’ordine di reso nel sistema, che spesso attiva le operazioni successive. In genere, viene registrata come azione esplicita o modifica dello stato nell’intestazione ReturnOrder. | ||
| Perché è importante La conferma è un passaggio fondamentale prima dell’avvio della logistica. I ritardi tra la creazione e la conferma possono indicare arretrati amministrativi o legati al sistema. Dove reperirli È possibile individuarla dalla registrazione del giornale 'Confirmation' per l’ordine di reso o da una modifica del campo DocumentStatus in SalesTable. Acquisizione Esecuzione della funzione 'Confirm sales order' per l’ordine di reso. Tipo di evento explicit | |||
| Ordine di sostituzione creato | Viene creato un nuovo ordine cliente per inviare un articolo sostitutivo al cliente. Questa attività si verifica quando l’azione di destinazione è 'Replace and Credit' o 'Replace and Scrap'. | ||
| Perché è importante Questa attività avvia la variante del processo di sostituzione. Monitorare separatamente questo percorso rispetto a quello del rimborso è essenziale per comprendere la complessità e i costi delle sostituzioni. Dove reperirli Creazione di un nuovo record SalesTable per l’articolo sostitutivo, spesso generato automaticamente e collegato all’ordine di reso originale. Acquisizione Creazione di un nuovo ordine cliente collegato all’ordine di reso tramite l’azione di destinazione. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
- Prerequisiti: registrare un’applicazione in Azure Active Directory. Prima di connettersi all’API di Dynamics 365, è necessario registrare un’applicazione nel tenant di Azure AD. Conceda all’applicazione le autorizzazioni delegate per accedere a Dynamics 365 Finance & Operations, ad esempio
Financials.ReadWrite.Allo un’autorizzazione personalizzata. - Configurare l’ID applicazione in Dynamics 365. In Dynamics 365, acceda a System administration > Setup > Azure Active Directory applications. Aggiunga l’ID applicazione (client) della registrazione dell’app in Azure AD e lo associ a un account utente con i ruoli di sicurezza necessari per leggere le entità dati richieste.
- Ottenere un token di accesso OAuth 2.0. Scriva uno script, ad esempio in PowerShell o Python, per eseguire l’autenticazione tramite l’endpoint della piattaforma Microsoft Identity. Utilizzi le credenziali dell’applicazione (ID client e segreto) per richiedere un token di accesso per l’URL della risorsa Dynamics 365.
- Individuare l’URL dell’ambiente Dynamics 365. Recuperi l’URL di base dell’ambiente Dynamics 365. L’endpoint della Web API avrà in genere questo formato:
https://[YourD365FinanceAndOpsURL].dynamics.com/data. - Creare ed eseguire le richieste API OData. Per ciascuna delle 12 attività richieste, crei un URL specifico per una richiesta OData GET. Utilizzi
$selectper recuperare solo le colonne necessarie e$filterper specificare l’intervallo di date e le eventuali condizioni di stato. Il token di autenticazione ottenuto al passaggio 3 deve essere incluso nell’intestazione di autorizzazione di ogni richiesta come token Bearer. - Sviluppare uno script di estrazione. Crei uno script che scorra l’elenco delle richieste OData. Lo script dovrà gestire l’autenticazione, eseguire ogni richiesta GET e salvare i dati JSON restituiti. Tenga conto dei limiti dell’API e, se necessario, inserisca delle pause.
- Gestire la paginazione dell’API. Dynamics 365 suddivide i risultati più ampi in più pagine. Lo script deve verificare la presenza della proprietà
@odata.nextLinknella risposta. Se presente, dovrà inviare una richiesta successiva a quell’URL per recuperare la pagina seguente, continuando fino a quando non viene più fornitonextLink. - Trasformare e unire i dati. Elabori la risposta JSON di ciascuna delle 12 chiamate API. Per ogni attività, crei un record standardizzato con
ReturnCaseId,ActivityName,EventTimee gli altri attributi. Ad esempio, per l’evento 'Return Order Created', associReturnOrderNumberaReturnCaseId, impostiActivityNamesu 'Return Order Created' e associcreatedDateTimeaEventTime. Riunisca i record trasformati di tutte le chiamate in un unico elenco o tabella. - Pulire e standardizzare i timestamp. Verifichi che tutti i valori di
EventTimeseguano un formato coerente, preferibilmente UTC, ad esempioYYYY-MM-DDTHH:MM:SSZ. Gestisca come necessario i record con timestamp mancanti o non validi. - Esportare l’Event Log finale. Dopo aver raccolto e trasformato tutti i dati in un unico insieme coerente, lo esporti in un file CSV. Verifichi che le intestazioni delle colonne corrispondano ai requisiti di ProcessMind:
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCodee così via. Il file è pronto per il caricamento.
Configurazione
- URL dell’endpoint API: l’URL di base dell’istanza Dynamics 365 Finance & Operations. Il formato è
https://[YourEnvironmentName].dynamics.com/data. - Registrazione dell’app in Azure AD: è necessario registrare un’applicazione in Azure AD con un ID client e un segreto. L’app deve disporre delle autorizzazioni API per accedere alle entità dati di Dynamics 365.
- Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date a ogni chiamata API, utilizzando il parametro OData
$filtersu un campo data pertinente, comecreatedDateTimeomodifiedDateTime. Per contenere i volumi di estrazione, è consigliabile iniziare con gli ultimi 3-6 mesi di dati. - Filtro per società: per estrarre i dati di una specifica entità giuridica, includa il parametro di query
cross-company=true, quindi applichi$filteral campodataAreaId. Ad esempio:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'. - Impostazione della paginazione: utilizzi nelle richieste l’intestazione
Prefer: odata.maxpagesize=[value]per controllare il numero di record restituiti per pagina. Un valore compreso tra1000e5000è comune e aiuta a prevenire i timeout dell’API sulle entità di grandi dimensioni. - Limitazione delle richieste API: tenga presenti i limiti di protezione del servizio API di Dynamics 365. Lo script di estrazione dovrebbe gestire le risposte
429 (Too Many Requests), ad esempio applicando un’attesa esponenziale o una semplice procedura di pausa e nuovo tentativo.
Query di esempio graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser Passaggi
- Abilitare l’endpoint TDS: verifichi che l’endpoint Tabular Data Stream (TDS) sia abilitato nell’ambiente Dataverse di Dynamics 365. Un amministratore di sistema può attivarlo nel centro di amministrazione di Power Platform, in Environment > Settings > Features.
- Individuare l’URL dell’ambiente: recuperi l’URL dell’ambiente. In genere ha un formato simile a
yourorg.crm.dynamics.com. Il nome del server dell’endpoint TDS corrisponde a questo URL con la porta 5558, ad esempioyourorg.crm.dynamics.com,5558. - Connettersi con un client SQL: utilizzi un client SQL compatibile con TDS, come SQL Server Management Studio (SSMS) o Azure Data Studio.
- Autenticazione: si connetta al server con il proprio account Azure Active Directory, dotato delle autorizzazioni appropriate nell’ambiente Dataverse, in genere System Administrator o System Customizer.
- Preparare la query: copi la query SQL completa fornita nella sezione
querydi questo documento in una nuova finestra di query del client SQL. - Impostare i parametri: individui i segnaposto nella query. Sostituisca
'{StartDate}'e'{EndDate}'con l’intervallo di date desiderato per l’estrazione, ad esempio'2023-01-01'e'2023-12-31'. Aggiorni inoltre gli eventuali valori segnaposto per i codici di stato o di disposizione in base alla configurazione specifica di Dynamics 365. - Eseguire la query: esegua la query modificata sul database Dataverse. Il tempo di esecuzione varia in base al volume dei dati e all’intervallo di date selezionato.
- Rivedere i risultati: al termine della query, controlli che l’insieme di dati restituito contenga le colonne previste:
ReturnCaseId,ActivityName,EventTimee gli attributi consigliati. - Esportare l’Event Log: esporti i risultati della query in un file CSV. La maggior parte dei client SQL dispone di una funzione integrata per salvare direttamente i risultati in un file. Verifichi che il file sia salvato con codifica UTF-8.
- Caricare i dati in ProcessMind: il file CSV esportato è pronto per essere caricato in ProcessMind come nuovo Event Log per l’analisi di Process Mining.
Configurazione
- Prerequisiti: deve disporre di un account utente con almeno l’accesso in lettura alle tabelle Dataverse pertinenti, ad esempio SalesTable, SalesLine e CustInvoiceJour. Le autorizzazioni sono in genere gestite tramite ruoli di sicurezza come System Administrator o un ruolo personalizzato con autorizzazioni sufficienti sulle tabelle.
- Endpoint TDS: l’endpoint TDS di Dataverse deve essere abilitato nell’ambiente. Questa funzionalità consente di eseguire query SQL dirette e in sola lettura sul database Dataverse.
- Intervallo di date: la query contiene i segnaposto
'{StartDate}'e'{EndDate}'. Per l’analisi iniziale, si consiglia un intervallo di 3-6 mesi, che fornisce un insieme di dati rappresentativo senza causare problemi di prestazioni. - Filtro per società: così com’è, la query viene eseguita su tutte le entità giuridiche (società) a cui l’utente ha accesso. Per analizzare una singola società, rimuova il commento e aggiunga una clausola
WHEREche filtri il campoDATAAREAIDin ogni parte dell’istruzioneUNION ALL, ad esempioAND st.DATAAREAID = '[YourCompanyID]'. - Segnaposto per la logica personalizzata: la query contiene segnaposto come
[YourReplaceCode1]per i codici di disposizione e note sul collegamento degli ordini sostitutivi. Questi elementi devono essere configurati in base al processo aziendale e alla configurazione specifica di Dynamics 365. - Prestazioni: le query dirette su grandi insiemi di dati tramite l’endpoint TDS possono essere lente. La connessione è ottimizzata per le query analitiche, ma le unioni complesse di milioni di righe possono causare un timeout. Si consiglia di applicare filtri di data rigorosi.
Query di esempio sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'; È pronto per iniziare?
Utilizzi questo template per semplificare la raccolta dei dati e iniziare a individuare opportunità di miglioramento nella gestione di resi e rimborsi. Inizi oggi il percorso verso tempi di elaborazione più brevi e una maggiore soddisfazione dei clienti.
Riduca i ritardi nella gestione di resi e rimborsi: ottimizzi il processo oggi
Riduca del 30% il tempo di ciclo e migliori la soddisfazione dei clienti.
Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.