Il Suo Template dati per la gestione di resi e rimborsi
Il Suo Template dati per la gestione di resi e rimborsi
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l'estrazione da NetSuite
Attributi della gestione dei resi e dei rimborsi
| Nome | Descrizione | ||
|---|---|---|---|
| ID del caso di reso ReturnCaseId | L'identificativo univoco di un singolo caso di reso o rimborso del cliente, che collega tutte le attività correlate dall'avvio alla chiusura. | ||
| Descrizione Il Return Case ID funge da identificativo principale per monitorare il percorso end-to-end di un reso. Ogni ID univoco corrisponde a una singola autorizzazione al reso e consente di analizzare in modo completo tutti gli eventi associati, come la ricezione dell'articolo, l'ispezione e l'elaborazione del rimborso. Nel Process Mining, questo ID è essenziale per ricostruire il flusso completo del processo per ogni reso, calcolare i tempi di ciclo e individuare le deviazioni a livello di caso. Perché è importante Questo è l'attributo fondamentale per il Process Mining, poiché collega tutti i singoli eventi in istanze di processo end-to-end coerenti, rendendo possibile l'analisi dei flussi e delle prestazioni del processo. Dove reperirlo In genere corrisponde all'Internal ID o al Transaction ID del record Return Authorization in NetSuite. Esempi RMA-0012345RMA-0012346RMA-0012347 | |||
| Nome dell'attività ActivityName | Il nome dello specifico evento o passaggio aziendale che si è verificato nel processo di reso, come 'Item Inspected' o 'Refund Processed'. | ||
| Descrizione L'Activity Name descrive un passaggio o una tappa distinta nel ciclo di vita di resi e rimborsi. Gli eventi vengono ordinati in base ai relativi timestamp per costruire il flusso del processo. L'analisi della sequenza e della frequenza delle attività aiuta a individuare i percorsi più comuni, i colli di bottiglia tra le fasi e le eventuali rilavorazioni o attività ripetute. Tra gli esempi figurano 'Return Authorization Created', 'Item Received' e 'Credit Memo Approved'. Perché è importante Questo attributo definisce le fasi del processo. È essenziale per visualizzare la mappa del processo, analizzare le variazioni del flusso e individuare colli di bottiglia o cicli di rilavorazione. Dove reperirlo Questo attributo viene in genere ricavato dalle modifiche di stato dei record delle transazioni, come Return Authorization e Credit Memo, oppure da specifiche azioni degli utenti registrate nelle note di sistema o in log degli eventi personalizzati. Esempi Return Authorization creataArticolo ricevutoArticolo ispezionatoRimborso elaboratoReturn Authorization chiusa | |||
| Timestamp dell'evento EventTimestamp | La data e l'ora precise in cui si è verificata l'attività, che costituiscono la base cronologica del processo. | ||
| Descrizione L'Event Timestamp registra il momento esatto in cui si è svolta un'attività. Questi dati sono fondamentali per ordinare correttamente gli eventi e per tutte le analisi basate sul tempo. Vengono utilizzati per calcolare le durate tra le attività, i tempi di ciclo totali dei casi e i tempi di attesa, elementi essenziali per il monitoraggio delle prestazioni, l'analisi dei colli di bottiglia e i controlli di conformità agli SLA. I timestamp devono essere accurati per garantire l'affidabilità degli insight di Process Mining. Perché è importante Questo attributo fornisce l'ordine cronologico degli eventi, necessario per individuare il flusso del processo e calcolare tutte le metriche di prestazione, come i tempi di ciclo e i tempi di attesa. Dove reperirlo Queste informazioni provengono in genere dai campi 'Date Created' o 'Last Modified Date' dei record NetSuite oppure dai timestamp presenti nella sottolista System Notes associata alle transazioni. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:12:05Z | |||
| Sistema di origine SourceSystem | Il sistema da cui sono stati estratti i dati, utilizzato per monitorarne la provenienza. | ||
| Descrizione Questo attributo identifica l'origine dei dati di processo. In questo contesto, il valore sarà in genere 'NetSuite'. Specificare il sistema di origine è importante negli ambienti in cui i dati possono essere uniti da più sistemi, poiché garantisce una chiara tracciabilità e una corretta lineage dei dati. Perché è importante Identifica l'origine dei dati, un elemento fondamentale per la governance dei dati, la risoluzione dei problemi e gli scenari in cui i dati provenienti da più sistemi vengono combinati per ottenere una visione completa del processo. Dove reperirlo Si tratta di un valore statico ('NetSuite'), normalmente aggiunto durante il processo di estrazione e trasformazione dei dati. Esempi NetSuiteNetSuite ERP | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp che indica l'ultima volta in cui i dati relativi a questo processo sono stati aggiornati o ricaricati. | ||
| Descrizione Questo attributo registra quando il dataset è stato aggiornato l'ultima volta dal sistema di origine. È un metadato fondamentale, poiché informa gli utenti sull'aggiornamento dell'analisi. Visualizzare queste informazioni nei Dashboard aiuta a gestire le aspettative e garantisce che le decisioni vengano prese tenendo conto dell'attualità dei dati. Perché è importante Fornisce trasparenza sull'aggiornamento dei dati, un elemento essenziale affinché gli utenti possano fidarsi dell'analisi e comprenderne la rilevanza rispetto allo stato attuale delle operazioni. Dove reperirlo Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Importo effettivo del rimborso ActualRefundAmount | L'importo monetario finale effettivamente rimborsato al cliente. | ||
| Descrizione Questo attributo rappresenta il valore effettivamente accreditato o rimborsato al cliente, come registrato nel Credit Memo o nella transazione di rimborso. L'importo può differire da quello richiesto a causa di adeguamenti quali costi di reintegro, spese di spedizione o rimborsi parziali per merci danneggiate. Questo attributo è fondamentale per la reportistica finanziaria e per il calcolo del KPI 'Refund Amount Discrepancy Rate'. Perché è importante Rappresenta l'effettivo impatto finanziario del reso ed è essenziale per la riconciliazione finanziaria e l'analisi dell'accuratezza dei rimborsi. Dove reperirlo Questo valore proviene dal campo 'Total' della transazione Credit Memo generata dalla Return Authorization. Esempi 99.99140.000.00 | |||
| Operatore incaricato ProcessingAgent | Il dipendente o l'utente che ha eseguito una specifica attività nel processo di reso. | ||
| Descrizione Il Processing Agent identifica la persona responsabile dell'esecuzione di una determinata attività, come l'approvazione di un reso o l'ispezione di un articolo. Questo attributo è fondamentale per analizzare le prestazioni a livello di utente. Aiuta a individuare i dipendenti con le migliori prestazioni, le aree in cui può essere necessaria ulteriore formazione e gli squilibri nella distribuzione del carico di lavoro all'interno del team. Analizzare le attività per operatore è essenziale per il Dashboard 'Departmental Return Process Performance'. Perché è importante Consente di analizzare le prestazioni individuali e del team, bilanciare i carichi di lavoro e individuare le esigenze formative, con un impatto diretto sull'efficienza operativa. Dove reperirlo Può essere ricavato da campi come 'Created By', 'Approved By' o dai campi utente della sottolista System Notes nelle transazioni NetSuite. Esempi Alice JohnsonBob WilliamsCharlie Brown | |||
| Reparto Department | Il reparto o il team aziendale responsabile della gestione del caso di reso in una determinata fase. | ||
| Descrizione Questo attributo assegna le attività del processo a uno specifico reparto, come 'Customer Service', 'Warehouse' o 'Finance'. È essenziale per comprendere i passaggi di consegne tra i team e individuare i colli di bottiglia a livello di reparto. Analizzando il tempo che i casi trascorrono all'interno di un reparto o in attesa di essere presi in carico, le organizzazioni possono individuare le fonti dei ritardi e ottimizzare l'allocazione delle risorse. È una dimensione primaria per il Dashboard 'Departmental Return Process Performance'. Perché è importante Consente di analizzare le prestazioni del processo per area funzionale, evidenziando i ritardi nei passaggi di consegne tra reparti e i colli di bottiglia dipartimentali. Dove reperirlo Può essere ricavato dal record dell'utente o del dipendente associato a un'attività oppure da un campo 'Department' della transazione stessa. In NetSuite viene spesso configurato nei record dei dipendenti. Esempi MagazzinoAssistenza clientiFinanzaAssicurazione qualità | |||
| Stato del reso ReturnAuthorizationStatus | Lo stato attuale della Return Authorization, ad esempio 'Pending Approval', 'Approved' o 'Closed'. | ||
| Descrizione Questo attributo indica lo stato attuale del caso di reso nel relativo ciclo di vita. È fondamentale per comprendere l'avanzamento dei resi e segmentare i casi. Ad esempio, analizzare il tempo trascorso nello stato 'Pending Receipt' può evidenziare ritardi nella spedizione, mentre una lunga permanenza in 'Pending Approval' può indicare un collo di bottiglia interno. Viene inoltre utilizzato per determinare l'esito finale di un reso, come 'Closed' o 'Rejected'. Perché è importante Fornisce una fotografia della posizione di ciascun reso nel processo, consentendo di analizzare la distribuzione dei casi, la durata degli stati e gli esiti del processo. Dove reperirlo Corrisponde al campo 'Status' o a un campo analogo del record Return Authorization in NetSuite. Esempi In attesa di approvazioneIn attesa di ricezioneApprovatoRifiutatoChiuso | |||
| Tipo di reso ReturnType | La classificazione del reso in base al motivo indicato dal cliente. | ||
| Descrizione Return Type classifica i resi in base al motivo sottostante, ad esempio 'Defective Item', 'Wrong Size', 'Changed Mind' o 'Not as Described'. Questa classificazione è fondamentale per l'analisi delle cause principali. Analizzando le metriche di processo per i diversi tipi di reso, un'azienda può individuare problemi di qualità dei prodotti, imprecisioni nelle descrizioni o errori di evasione. Questo attributo è essenziale per il Dashboard 'Returns Performance By Type And Channel'. Perché è importante Aiuta a individuare le cause principali dei resi, consentendo interventi mirati su prodotti, descrizioni di marketing o processo di evasione per ridurne il volume. Dove reperirlo In genere si tratta di un campo personalizzato o di un campo standard di tipo elenco/record nel modulo Return Authorization, in cui viene registrato il motivo del reso. Esempi Prodotto difettosoArticolo errato speditoInsoddisfazione del clienteTaglia/colore errati | |||
| Canale del reso ReturnChannel | Il canale attraverso il quale è stato effettuato l'acquisto originale o avviato il reso. | ||
| Descrizione Return Channel indica l'origine del reso, ad esempio 'Online', 'In-Store' o 'Marketplace'. Canali diversi possono avere processi di reso, costi e aspettative dei clienti differenti. Analizzare le prestazioni per canale aiuta le aziende a ottimizzare ciascun processo, allocare efficacemente le risorse e comprendere i problemi specifici del canale. È un attributo fondamentale per il Dashboard 'Returns Performance By Type And Channel'. Perché è importante Consente di confrontare le prestazioni tra diversi canali aziendali, evidenziando inefficienze o best practice specifiche delle modalità con cui i resi vengono avviati e gestiti. Dove reperirlo Queste informazioni provengono spesso dal record Sales Order originale associato al reso. Possono essere memorizzate in un campo 'Channel' o 'Location'. Esempi Negozio onlineNegozio al dettaglioMarketplace AmazonOrdine telefonico | |||
| Condizione del reso ReturnCondition | La condizione valutata dell'articolo restituito al momento dell'ispezione, ad esempio 'New', 'Damaged' o 'Used'. | ||
| Descrizione Questo attributo registra l'esito dell'ispezione fisica dell'articolo restituito. La condizione determina le fasi successive, ad esempio se emettere un rimborso completo, rimettere l'articolo a magazzino o scartarlo. Analizzare la coerenza e i tempi di elaborazione di questa valutazione è l'obiettivo del Dashboard 'Return Condition Assessment Quality' ed è fondamentale per la riconciliazione finanziaria e la gestione dell'inventario. Perché è importante Incide direttamente sull'esito finanziario del reso e sulle successive attività di inventario. Valutazioni incoerenti possono causare perdite finanziarie e rilavorazioni del processo. Dove reperirlo È probabilmente un campo personalizzato del record Item Receipt o Return Authorization, compilato dal personale di magazzino durante l'ispezione. Esempi RivendibileDanneggiato nella confezioneUsato, in buone condizioniParti mancanti | |||
| Data obiettivo dello SLA del rimborso RefundSlaTargetDate | La data entro la quale il rimborso dovrebbe essere elaborato in base agli accordi sui livelli di servizio. | ||
| Descrizione La Data obiettivo SLA del rimborso è un timestamp calcolato che rappresenta l'impegno assunto nei confronti del cliente per l'elaborazione del rimborso. In genere viene calcolata aggiungendo un periodo predefinito, ad esempio 5 giorni lavorativi, a un evento chiave come 'Articolo ricevuto' o 'Rimborso approvato'. Questo attributo è essenziale per la Dashboard 'Monitoraggio della Conformità SLA del rimborso' e per il KPI 'Tasso di raggiungimento dello SLA del rimborso', poiché consente all'azienda di misurare le prestazioni rispetto agli impegni assunti. Perché è importante Consente di misurare quantitativamente le prestazioni rispetto agli impegni assunti nei confronti dei clienti, un aspetto fondamentale per mantenere elevati i livelli di soddisfazione e fiducia. Dove reperirlo Questa data non è generalmente un campo standard. Deve essere derivata aggiungendo un periodo SLA predefinito, ad esempio 5 giorni, a un timestamp chiave, come la data di 'Articolo ricevuto'. Esempi 2023-11-01T23:59:59Z2023-11-05T23:59:59Z2023-11-10T23:59:59Z | |||
| Differenza sull'importo del rimborso RefundAmountDiscrepancy | La differenza calcolata tra l'importo del rimborso richiesto e l'importo effettivamente rimborsato. | ||
| Descrizione Questa metrica viene calcolata sottraendo l' 'Importo effettivo del rimborso' dall' 'Importo del rimborso richiesto'. Un valore diverso da zero indica che durante il processo è stato effettuato un adeguamento, ad esempio per costi di ricondizionamento o merce danneggiata. Questo attributo alimenta l'analisi del KPI 'Tasso di differenza sull'importo del rimborso' e aiuta a segnalare i casi con adeguamenti finanziari significativi che richiedono un'ulteriore verifica. Perché è importante Evidenzia gli adeguamenti finanziari effettuati durante il processo di reso, consentendo di analizzare perché si verificano le differenze e se risultano coerenti e giustificate. Dove reperirlo Si tratta di un attributo calcolato. La formula è: Esempi 0.0010.00-5.00 | |||
| È automatizzato IsAutomated | Flag booleano che indica se un'attività è stata eseguita automaticamente dal sistema. | ||
| Descrizione Questo attributo indica se un'attività è stata eseguita da un utente oppure da un sistema, uno script o un Workflow automatizzato. Ad esempio, un evento iniziale 'Autorizzazione al reso creata' potrebbe essere automatizzato tramite un portale clienti, mentre 'Articolo ispezionato' è un'attività manuale. Il monitoraggio dell'automazione aiuta a individuare le opportunità per automatizzare le fasi manuali e a misurare i miglioramenti di efficienza derivanti dalle automazioni già esistenti. Perché è importante Aiuta a distinguere tra attività manuali e automatizzate, un elemento fondamentale per individuare le opportunità di automazione e misurare l'impatto delle iniziative di trasformazione digitale. Dove reperirlo Può essere dedotto dall'utente associato a un evento. Gli eventi generati dal sistema in NetSuite sono spesso associati a uno specifico utente di sistema o a uno script ID. Esempi truefalse | |||
| È conforme allo SLA IsSlaCompliant | Flag calcolato che indica se il rimborso è stato elaborato entro l'obiettivo SLA definito. | ||
| Descrizione Questo attributo booleano viene derivato confrontando il timestamp 'Rimborso elaborato' con la 'Data obiettivo SLA del rimborso'. Se il rimborso è stato elaborato entro la data obiettivo, il valore è true; in caso contrario, è false. Questo flag semplifica la creazione di report e Dashboard sulla Conformità, come la Dashboard 'Monitoraggio della Conformità SLA del rimborso', e viene utilizzato per calcolare il KPI 'Tasso di raggiungimento dello SLA del rimborso'. Perché è importante Fornisce un risultato chiaro e binario sulle prestazioni SLA per ogni singolo caso, rendendo semplice monitorare, rendicontare e analizzare nel tempo i tassi di Conformità. Dove reperirlo Questo attributo viene calcolato durante la trasformazione dei dati o all'interno dello strumento di Process Mining. La logica è: Esempi truefalse | |||
| ID cliente CustomerId | L'identificativo univoco del cliente che avvia il reso. | ||
| Descrizione Il Customer ID collega una transazione di reso a uno specifico cliente. Consente analisi incentrate sul cliente, come l'individuazione dei clienti che effettuano resi frequenti, un comportamento che può indicare insoddisfazione o frode. Permette inoltre di segmentare le prestazioni del processo in base al tipo o al valore del cliente, così da dare priorità al servizio per gli account strategici. Perché è importante Facilita l'analisi dei comportamenti di reso a livello di cliente e consente di segmentare il processo in base ad attributi del cliente, come il segmento o il valore nel corso del ciclo di vita. Dove reperirlo È il campo 'Customer' o 'Entity' nell'intestazione del record Return Authorization in NetSuite. Esempi CUST-001CUST-002CUST-003 | |||
| Identificativo del prodotto ProductIdentifier | L'identificativo univoco del prodotto restituito, ad esempio SKU o Item Number. | ||
| Descrizione Questo attributo identifica lo specifico articolo coinvolto nel reso. Analizzare i resi a livello di prodotto è fondamentale per individuare gli articoli con tassi di reso elevati, che possono indicare difetti di qualità, descrizioni inadeguate o altri problemi. Questi dati consentono un'analisi approfondita delle prestazioni del prodotto e possono orientare le decisioni relative a sviluppo, approvvigionamento e marketing. Perché è importante Collega i dati del processo di reso a prodotti specifici, consentendo l'analisi delle cause principali dei problemi legati ai prodotti e contribuendo a ridurre il tasso complessivo dei resi. Dove reperirlo Si trova nella sottolista 'Items' del record Return Authorization e corrisponde al campo 'Item'. Esempi SKU-TEE-BL-LPROD-00543ITEM-987123 | |||
| Importo del rimborso richiesto RequestedRefundAmount | L'importo monetario del rimborso inizialmente richiesto o previsto per il reso. | ||
| Descrizione Questo attributo memorizza il valore del rimborso previsto all'inizio del processo. In genere si basa sul prezzo di acquisto originale degli articoli restituiti. L'importo costituisce il riferimento per il confronto con l'importo rimborsato finale. Il KPI 'Refund Amount Discrepancy Rate' confronta direttamente questo valore con l'Actual Refund Amount per individuare le variazioni dovute a costi di reintegro, rimborsi parziali o altri adeguamenti. Perché è importante Fornisce un riferimento per l'analisi finanziaria, aiutando a monitorare le discrepanze tra i valori dei rimborsi previsti ed effettivi e a individuarne le cause. Dove reperirlo Questo valore deriva dai campi 'Amount' o 'Rate' delle righe articolo della transazione Return Authorization. Esempi 99.99150.0025.50 | |||
| Rispetto delle policy ReturnPolicyAdherence | Indica se il reso è conforme alle policy aziendali stabilite. | ||
| Descrizione Questo attributo booleano o categoriale segnala se un reso soddisfa tutti i criteri predefiniti, come il periodo utile per la restituzione, le condizioni dell'articolo e la prova d'acquisto. Viene utilizzato per monitorare la conformità e gestire le eccezioni. Il Dashboard 'Return Policy Adherence Exceptions' utilizza questo attributo per evidenziare i casi che richiedono una gestione o una revisione speciale, contribuendo a ridurre i rischi e garantire un'applicazione coerente delle regole. Perché è importante Aiuta a monitorare e applicare le policy sui resi, riducendo il rischio finanziario derivante dai resi non conformi e garantendo equità e coerenza. Dove reperirlo Si tratterebbe quasi certamente di un campo personalizzato, probabilmente una casella di controllo o un elenco, nel record Return Authorization, gestito tramite un Workflow. Esempi ConformeNon conforme, fuori termineEccezione approvata | |||
Attività della gestione dei resi e dei rimborsi
| Attività | Descrizione | ||
|---|---|---|---|
| Articolo ricevuto | Questa attività segna la ricezione fisica dell'articolo restituito presso il magazzino o il centro di elaborazione. In NetSuite viene registrata esplicitamente tramite la creazione di una transazione Item Receipt collegata alla Return Authorization originale. | ||
| Perché è importante Si tratta di una tappa fondamentale, che trasferisce il processo dall'azione del cliente all'elaborazione interna. Il tempo tra 'Return Approved' e 'Item Received' misura la rapidità del reso da parte del cliente, mentre il tempo successivo a questo evento misura l'efficienza interna. Dove reperirlo Questo evento corrisponde al timestamp di creazione della transazione ItemReceipt. Il record è collegato direttamente alla ReturnAuthorization di origine. Acquisizione Data di creazione del record della transazione ItemReceipt in NetSuite collegata alla RA. Tipo di evento explicit | |||
| Credit Memo creato | Questa attività indica l'avvio della parte finanziaria del reso tramite la creazione di un Credit Memo. Il documento specifica l'importo da rimborsare al cliente e viene creato dalla Return Authorization dopo la ricezione e l'approvazione dell'articolo. | ||
| Perché è importante La creazione del Credit Memo è una tappa finanziaria fondamentale. Il tempo tra la ricezione dell'articolo e la creazione del Credit Memo evidenzia l'efficienza del processo che va dall'ispezione all'emissione del credito. Dove reperirlo Questo evento corrisponde al timestamp di creazione della transazione CreditMemo. Il campo 'Created From' del Credit Memo lo collega alla ReturnAuthorization. Acquisizione Data di creazione del record della transazione CreditMemo in NetSuite. Tipo di evento explicit | |||
| Return Authorization approvata | Questa attività rappresenta l'approvazione formale della richiesta di reso del cliente da parte di un dipendente e consente al processo di proseguire. In genere viene acquisita deducendo una modifica del campo di stato del record Return Authorization, ad esempio da 'Pending Approval' a 'Pending Receipt'. | ||
| Perché è importante Monitorare questa fase di approvazione è fondamentale per individuare i colli di bottiglia nella fase di revisione iniziale. I ritardi in questa fase incidono direttamente sul tempo necessario per informare il cliente e ricevere l'articolo restituito. Dove reperirlo Deducibile dalle note di sistema o dalla cronologia del Workflow del record ReturnAuthorization, in particolare quando il campo 'Status' viene aggiornato a uno stato approvato, ad esempio 'Pending Receipt'. Acquisizione Rilevare la modifica dello stato del record ReturnAuthorization a uno stato 'Approved'. Tipo di evento inferred | |||
| Return Authorization chiusa | Questa è l'attività finale, che segna la chiusura amministrativa del caso di reso dopo il completamento di tutte le elaborazioni. L'evento viene dedotto dalla modifica finale dello stato del record Return Authorization a 'Closed'. | ||
| Perché è importante In quanto punto conclusivo del processo, questa attività è essenziale per calcolare i tempi di ciclo end-to-end e individuare i casi che rimangono aperti a lungo dopo l'elaborazione del rimborso. Dove reperirlo Deducibile dalle note di sistema o dalla cronologia del Workflow del record ReturnAuthorization, quando il campo 'Status' viene aggiornato allo stato terminale finale, ad esempio 'Closed'. Acquisizione Rilevare la modifica dello stato del record ReturnAuthorization a uno stato 'Closed'. Tipo di evento inferred | |||
| Return Authorization creata | Questa attività segna l'avvio del processo di reso, quando un cliente richiede la restituzione di un articolo. In NetSuite viene registrata esplicitamente tramite la creazione di un nuovo record Return Authorization (RA), che funge da identificativo principale del caso di reso. | ||
| Perché è importante In quanto punto di partenza del processo, questa attività è essenziale per misurare il tempo totale del ciclo di reso e analizzare nel tempo il volume delle richieste di reso ricevute. Dove reperirlo Questo evento corrisponde al timestamp di creazione del record ReturnAuthorization in NetSuite. In genere, nel record vengono acquisiti l'utente, la data e lo stato iniziale, ad esempio 'Pending Approval'. Acquisizione Data di creazione del record della transazione ReturnAuthorization in NetSuite. Tipo di evento explicit | |||
| Rimborso elaborato | Si tratta del regolamento finanziario finale, con cui i fondi vengono restituiti al cliente. L'evento viene acquisito esplicitamente tramite la creazione di una transazione Customer Refund generata dal Credit Memo. | ||
| Perché è importante Questa attività è fondamentale per misurare la conformità agli SLA e la soddisfazione dei clienti. La durata tra 'Credit Memo Approved' e 'Refund Processed' riflette direttamente la rapidità del reparto tesoreria o finanza. Dove reperirlo Questo evento corrisponde al timestamp di creazione della transazione CustomerRefund. Il campo 'Created From' della transazione la collega al CreditMemo. Acquisizione Data di creazione del record della transazione CustomerRefund in NetSuite. Tipo di evento explicit | |||
| Articolo ispezionato | Questa attività concettuale rappresenta il completamento dell'ispezione fisica dell'articolo restituito per valutarne le condizioni. Poiché NetSuite non dispone di un oggetto standard 'Inspection', l'attività viene in genere dedotta da un campo personalizzato o da un aggiornamento dello stato sulla Return Authorization o sull'Item Receipt. | ||
| Perché è importante L'ispezione costituisce spesso un importante collo di bottiglia. Monitorarne il completamento è essenziale per analizzare le prestazioni degli operatori, la coerenza delle decisioni e l'impatto sulla successiva approvazione del rimborso. Dove reperirlo Richiede un'analisi del sistema. L'evento può essere dedotto da una modifica al campo personalizzato 'Inspection Status' del record ReturnAuthorization oppure può corrispondere a un processo offline non registrato. Acquisizione Deducibile dalla modifica di un campo di stato personalizzato sulla Return Authorization o sull'Item Receipt. Tipo di evento inferred | |||
| Cliente informato | Rappresenta l'invio al cliente di una notifica relativa a un aggiornamento di stato importante, come l'approvazione, la ricezione dell'articolo o l'elaborazione del rimborso. In genere viene dedotto dal timestamp di un'e-mail generata dal sistema e registrata nella scheda delle comunicazioni del record. | ||
| Perché è importante Una comunicazione tempestiva è fondamentale per la soddisfazione dei clienti. Misurare il ritardo tra una tappa e la notifica al cliente aiuta a individuare le lacune nell'esperienza del cliente. Dove reperirlo Richiede un'analisi del sistema. L'evento viene acquisito dal timestamp di un'e-mail in uscita o di una nota utente nella sottoscheda Communication della ReturnAuthorization o del CreditMemo. Acquisizione Timestamp di un'e-mail o di una voce del log delle comunicazioni collegata al caso. Tipo di evento inferred | |||
| Credit Memo applicato | Questa attività rappresenta un'alternativa al rimborso in denaro, in cui il Credit Memo viene applicato a una fattura cliente aperta. L'evento viene dedotto dal collegamento 'Applied To' del Credit Memo, che indica che il credito è stato utilizzato. | ||
| Perché è importante Distinguere tra rimborsi in denaro e applicazioni di crediti è importante per l'analisi finanziaria. Questo percorso rappresenta una modalità di chiusura del processo diversa dal rimborso diretto. Dove reperirlo Deducibile dalle note di sistema o dai record correlati del CreditMemo, in particolare quando viene collegato a una transazione Invoice per compensare il saldo del cliente. Acquisizione Rilevare l'applicazione di un CreditMemo a una transazione Invoice. Tipo di evento inferred | |||
| Credit Memo approvato | Rappresenta l'approvazione formale del Credit Memo, spesso richiesta per rimborsi di importo elevato o nell'ambito dei controlli finanziari. L'evento viene dedotto da una modifica dello stato del record Credit Memo, che indica che il documento è pronto per l'applicazione o il pagamento. | ||
| Perché è importante Quando sono necessarie approvazioni finanziarie, questa fase può costituire un collo di bottiglia significativo. Analizzarne la durata aiuta a rendere più efficienti i controlli finanziari senza ritardare i rimborsi ai clienti. Dove reperirlo Deducibile dalle note di sistema del record CreditMemo, in particolare quando un campo relativo allo stato di approvazione viene aggiornato da 'Pending Approval' a 'Approved' o 'Open'. Acquisizione Rilevare la modifica dello stato della transazione CreditMemo a uno stato 'Approved'. Tipo di evento inferred | |||
| Ordine di sostituzione creato | Questa attività rappresenta uno scenario di sostituzione in cui viene creato un nuovo ordine di vendita per il cliente anziché procedere con un rimborso. L'evento viene in genere acquisito tramite la creazione di un Sales Order collegato alla Return Authorization originale. | ||
| Perché è importante Monitorare le sostituzioni come percorso distinto aiuta ad analizzare le preferenze dei clienti e l'efficienza del processo di sostituzione rispetto a quello di rimborso. Si tratta di una variante comune e importante. Dove reperirlo Questo evento corrisponde al timestamp di creazione di una nuova transazione SalesOrder. Il collegamento alla ReturnAuthorization può trovarsi in un campo standard o personalizzato e richiede un'analisi del sistema. Acquisizione Data di creazione del record SalesOrder collegato alla ReturnAuthorization. Tipo di evento explicit | |||
| Return Authorization rifiutata | Rappresenta la decisione di negare la richiesta di reso di un cliente, spesso a causa di violazioni delle policy. L'evento viene acquisito deducendo una modifica dello stato del record Return Authorization a 'Rejected' o 'Closed', senza ulteriori elaborazioni. | ||
| Perché è importante L'analisi dei rifiuti aiuta a individuare le ragioni più comuni delle richieste di reso non conformi, fornendo indicazioni utili per la comunicazione con i clienti e il chiarimento delle policy. Si tratta di una deviazione importante dal percorso standard. Dove reperirlo Deducibile dalle note di sistema o dalla cronologia del Workflow del record ReturnAuthorization, quando il campo 'Status' viene aggiornato a uno stato terminale 'Rejected'. Acquisizione Rilevare la modifica dello stato del record ReturnAuthorization a uno stato 'Rejected'. Tipo di evento inferred | |||
Guide all'estrazione
Passaggi
- Acceda alla creazione di una Saved Search: acceda a NetSuite. Selezioni Reports > New Search. Nella pagina New Saved Search faccia clic su 'Transaction'.
- Definisca i criteri principali: nella pagina di configurazione della Saved Search, nella scheda 'Criteria' e nella sottoscheda 'Standard', imposti i seguenti filtri per isolare i record delle autorizzazioni al reso:
TypeèReturn AuthorizationMain LineèYes- Aggiunga un filtro
Date Createde imposti l'intervallo desiderato, ad esempio 'within last 3 months'. Questo passaggio è fondamentale per gestire il volume dei dati.
- Configuri le colonne dei risultati per gli attributi: acceda alla scheda 'Results'. Aggiunga i seguenti campi, che diventeranno gli attributi dell'Event Log. Utilizzi 'Custom Label' per rinominarli secondo necessità e renderli più chiari.
- ID caso:
Document NumberoTranID(Custom Label: ReturnCaseId) - Stato del reso:
Status(Custom Label: ReturnAuthorizationStatus) - Addetto all'elaborazione:
Created Byo un campo personalizzato, se applicabile (Custom Label: ProcessingAgent) - Reparto:
Department(Custom Label: Department) - Tipo di reso: un campo personalizzato come
[Your Return Reason Field](Custom Label: ReturnType) - Importo del rimborso:
Amount(Custom Label: ActualRefundAmount)
- ID caso:
- Aggiunga colonne formula per i timestamp degli eventi: questo è il passaggio più importante. Per ciascuna delle 12 attività, aggiunga una colonna 'Formula (Date/Time)'. Ogni formula utilizza un'istruzione CASE per restituire un timestamp solo quando si è verificato l'evento specifico. Consulti la sezione 'query' per le formule esatte da utilizzare per ogni attività.
- Aggiunga colonne statiche: aggiunga due colonne 'Formula (Text)' ai risultati:
- Per
SourceSystem, utilizzi la formula:'NetSuite'. - Per
LastDataUpdate, utilizzi una formula che rappresenti la data di esecuzione, come{today}. Per un timestamp preciso, questo corrisponderà all'ora di esportazione.
- Per
- Salvi ed esporti la ricerca: assegni alla ricerca un nome descrittivo, ad esempio 'ProcessMind Returns Extraction'. Faccia clic su 'Save & Run'. Quando vengono visualizzati i risultati, faccia clic sull'icona di esportazione e scelga 'CSV'.
- Trasformi i dati in un Event Log: il CSV esportato sarà in formato 'wide', con una riga per ogni caso di reso e numerose colonne contenenti i timestamp dei diversi eventi. Dovrà trasformarlo in un Event Log in formato 'long'. Utilizzi uno strumento come Microsoft Excel Power Query (Unpivot Columns), Python o un altro strumento di scripting per eseguire questa trasformazione.
- Per ogni riga del CSV, crei più righe nuove, una per ciascuna colonna con timestamp dell'evento non vuota.
- La nuova tabella trasformata dovrebbe contenere colonne come
ReturnCaseId,ActivityNameeEventTimestamp.ActivityNamederiva dall'intestazione della colonna timestamp originale, ad esempio 'Return Authorization Created', mentreEventTimestampè il valore contenuto in quella colonna.
- Completi il file per il caricamento: verifichi che il file CSV finale contenga le intestazioni richieste:
ReturnCaseId,ActivityName,EventTimestamp,SourceSystem,LastDataUpdate, oltre agli attributi consigliati. Il file è ora pronto per essere caricato in ProcessMind.
Configurazione
- Tipo di ricerca: La ricerca salvata deve essere una ricerca
Transazione. - Intervallo di date: È fondamentale applicare un filtro per intervallo di date al campo
Date Createddell’autorizzazione al reso. Si consiglia un intervallo di 3-6 mesi, per bilanciare completezza dei dati e prestazioni. - Filtro principale: La ricerca deve essere filtrata con
Tipouguale aReturn AuthorizationeMain Lineuguale aSì, così da garantire un record iniziale per ogni caso di reso. - Campi personalizzati: L’accuratezza di questa estrazione, soprattutto per eventi concettuali come 'Articolo ispezionato' o attributi come 'Tipo di reso', dipende in larga misura dall’utilizzo di campi personalizzati nei record delle transazioni della Sua organizzazione. Le formule fornite includono segnaposto come
{custbody_...}, che devono essere adattati alla configurazione NetSuite. - Autorizzazioni utente: L’utente che esegue la ricerca deve disporre delle autorizzazioni di visualizzazione per tutti i tipi di transazione coinvolti: Return Authorization, Item Receipt, Credit Memo, Customer Refund e Sales Order.
- Prestazioni: Per gli account con un volume molto elevato di resi, questa ricerca completa potrebbe risultare lenta. Valuti di eseguirla nelle ore di minore attività oppure di pianificarne l’esportazione automatica nel file cabinet.
a Query di esempio config
This configuration represents the settings in the NetSuite Saved Search UI. The 'Results' tab should be configured with the following columns and formulas.
**Criteria Tab:**
* `Type` = `Return Authorization`
* `Main Line` = `true`
* `Date Created` = `[Specify Desired Date Range]`
**Results Tab (Columns):**
| Custom Label | Field / Formula Type | Formula / Field ID |
|---|---|---|
| `ReturnCaseId` | Formula (Text) | `{tranid}` |
| `SourceSystem` | Formula (Text) | `'NetSuite'` |
| `LastDataUpdate` | Formula (Date/Time) | `{today}` |
| `ReturnAuthorizationStatus` | Field | `Status` |
| `ProcessingAgent` | Field | `Created By` |
| `Department` | Field | `Department` |
| `ReturnType` | Field | `{custbody_return_reason}` |
| `ActualRefundAmount` | Field | `Amount` |
| `CycleTime` | Formula (Numeric) | `CASE WHEN {status} = 'Closed' THEN {lastmodifieddate} - {datecreated} ELSE NULL END` |
| `Activity_ReturnAuthorizationCreated` | Field | `Date Created` |
| `Activity_ReturnAuthorizationApproved` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Pending Receipt' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ReturnAuthorizationRejected` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Rejected' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ItemReceived` | Formula (Date/Time) | `{applyingtransaction.trandate}` |
| `Activity_ItemInspected` | Formula (Date/Time) | `CASE WHEN {custbody_inspection_status} = 'Complete' THEN {custbody_inspection_date} ELSE NULL END` |
| `Activity_CreditMemoCreated` | Formula (Date/Time) | `{createdfrom.trandate}` |
| `Activity_CreditMemoApproved` | Formula (Date/Time) | `MIN(CASE WHEN {createdfrom.systemnotes.newvalue} = 'Open' AND {createdfrom.systemnotes.field} = 'Status' THEN {createdfrom.systemnotes.date} ELSE NULL END)` |
| `Activity_RefundProcessed` | Formula (Date/Time) | `{createdfrom.appliedtotransaction.trandate}` |
| `Activity_CreditMemoApplied` | Formula (Date/Time) | `CASE WHEN {createdfrom.status} = 'Fully Applied' AND {createdfrom.appliedtotransaction.type} = 'Invoice' THEN {createdfrom.appliedtotransaction.date} ELSE NULL END` |
| `Activity_ExchangeOrderCreated` | Formula (Date/Time) | `{custbody_exchange_order.trandate}` |
| `Activity_CustomerNotified` | Formula (Date/Time) | `MAX({messages.messagedate})` |
| `Activity_ReturnAuthorizationClosed` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Closed' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` | Passaggi
- Abiliti SuiteAnalytics Connect: verifichi di disporre di una licenza SuiteAnalytics Connect per il Suo account NetSuite. Un amministratore deve abilitare la funzionalità in Setup > Company > Enable Features > Analytics.
- Assegni le autorizzazioni utente: assegni al ruolo dell'utente che effettua la connessione l'autorizzazione 'SuiteAnalytics Connect'. L'utente dovrà inoltre disporre delle autorizzazioni di visualizzazione per tutti i record oggetto della query, come Transactions, Employees e Customers.
- Installi il driver ODBC: scarichi e installi il driver ODBC NetSuite appropriato per il Suo sistema operativo dalla pagina di download di SuiteAnalytics Connect in NetSuite.
- Configuri il DSN: configuri un Data Source Name (DSN) sul computer dal quale eseguirà la query. Inserisca Service Data Source, Server Hostname, Port, Role ID, Account ID e le credenziali.
- Connetta il client SQL: utilizzi un client SQL, come DBeaver o Microsoft SQL Server Management Studio, per connettersi a NetSuite tramite il DSN configurato.
- Prepari la query SQL: copi la query SQL fornita nel client. La query è progettata per estrarre tutti gli eventi chiave del processo di resi e rimborsi.
- Personalizzi la query: modifichi i valori segnaposto nella query. Come minimo, dovrà aggiornare l'intervallo di date nella Common Table Expression (CTE)
ReturnAuthorizationsper filtrare il periodo desiderato. Potrebbe inoltre dover modificare i nomi dei campi personalizzati, comeCUSTBODY_RETURN_TYPE, o specifici valori di stato in base alla configurazione NetSuite. - Esegua la query: esegua la query SQL personalizzata sulla replica del database NetSuite. Il tempo di esecuzione può variare in base all'intervallo di date e al volume dei dati.
- Verifichi ed esporti i dati: al termine della query, controlli che i risultati siano corretti. Esporti l'intero set di risultati in un file CSV.
- Completi il file per il caricamento: verifichi che le intestazioni del file CSV corrispondano agli attributi richiesti:
ReturnCaseId,ActivityName,EventTimestamp,SourceSystem,LastDataUpdate, ecc. Verifichi che la colonnaEventTimestamputilizzi un formato coerente per data e ora. Il file è ora pronto per essere caricato in ProcessMind.
Configurazione
- Prerequisiti: è necessaria una licenza NetSuite con il modulo aggiuntivo SuiteAnalytics Connect. L'utente che esegue la connessione deve disporre di un ruolo con l'autorizzazione 'SuiteAnalytics Connect' e dell'accesso in lettura ai record di transazioni, entità e dipendenti.
- Configurazione dell'origine dati: deve configurare un DSN (Data Source Name) utilizzando il driver ODBC NetSuite. Sono necessari Account ID, Role ID e credenziali. L'host del servizio è generalmente
odbcserver.netsuite.comnegli ambienti di produzione. - Filtro sull'intervallo di date: è fondamentale applicare un filtro sull'intervallo di date alla CTE iniziale che seleziona le autorizzazioni al reso. Senza un filtro, la query tenterà di recuperare tutti i dati sui resi e sarà probabilmente molto lenta o andrà in timeout. Per l'analisi iniziale si consiglia un intervallo da 3 a 6 mesi.
- Tipi di transazione principali: la query interessa diversi tipi di transazione fondamentali: ReturnAuthorization, ItemReceipt, CreditMemo, CustomerRefund e SalesOrd, per gli scambi. Verifichi che il Suo processo utilizzi questi oggetti standard.
- Dipendenze dai campi personalizzati: attività come 'Articolo ispezionato' e attributi come 'Tipo di reso' vengono spesso acquisiti in campi personalizzati. La query fornita utilizza segnaposto come
CUSTBODY_INSPECTION_STATUSeCUSTBODY_RETURN_TYPE. Dovrà individuare gli ID corretti dei campi personalizzati nel Suo sistema e aggiornare la query di conseguenza. - Considerazioni sulle prestazioni: si tratta di una query complessa, con numerosi join e una struttura
UNION ALLdi grandi dimensioni. La esegua negli orari di minore attività per ridurre al minimo l'impatto sulle prestazioni del sistema. Per dataset molto grandi, valuti di eseguire la query su intervalli temporali più brevi e di accodare i risultati.
a Query di esempio sql
WITH ReturnAuthorizations AS (
SELECT
T.TRANSACTION_ID AS ReturnCaseId,
T.TRANDATE
FROM
TRANSACTION T
WHERE
T.TYPE = 'ReturnAuthorization'
AND T.TRANDATE BETWEEN TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD') AND TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD')
)
SELECT
RA.ReturnCaseId AS "ReturnCaseId",
'Return Authorization Created' AS "ActivityName",
T.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION T
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON T.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Pending Receipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Rejected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE IN ('Rejected', 'Closed')
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Received' AS "ActivityName",
IR.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION IR
INNER JOIN TRANSACTION T_RA ON IR.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON IR.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE IR.TYPE = 'ItemReceipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Inspected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.CUSTBODY_INSPECTION_STATUS' AND SN.NEW_VALUE = 'Completed'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Created' AS "ActivityName",
CM.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION CM
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON CM.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.APPROVAL_STATUS' AND SN.NEW_VALUE = 'Approved'
UNION ALL
SELECT
RA.ReturnCaseId,
'Refund Processed' AS "ActivityName",
REF.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
ABS(REF.TOTAL) AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION REF
INNER JOIN TRANSACTION CM ON REF.APPLIED_TO_TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON REF.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE REF.TYPE = 'CustomerRefund'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Applied' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Fully Applied'
UNION ALL
SELECT
RA.ReturnCaseId,
'Exchange Order Created' AS "ActivityName",
SO.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION SO
INNER JOIN TRANSACTION T_RA ON SO.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SO.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SO.TYPE = 'SalesOrd'
UNION ALL
SELECT
RA.ReturnCaseId,
'Customer Notified' AS "ActivityName",
MSG.MESSAGE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM MESSAGES MSG
INNER JOIN TRANSACTION T ON MSG.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON MSG.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE MSG.INCOMING = 'F'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Closed' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE T.TYPE = 'ReturnAuthorization' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE LIKE '%Closed%'; È pronto per iniziare?
Inizi a trasformare la gestione di resi e rimborsi utilizzando questo Template dati. Cominci oggi stesso a ottimizzare i Workflow NetSuite per migliorare l'efficienza e la soddisfazione dei clienti.
Ottimizzi subito resi e rimborsi e aumenti l'efficienza di NetSuite
Riduca del 30% il tempo di ciclo dei resi in NetSuite. Inizi oggi stesso a migliorare le operazioni.
Nessuna carta di credito richiesta • Configurazione in pochi minuti