Il template dei dati per la gestione di resi e rimborsi
Il template dei dati per la gestione di resi e rimborsi
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione
Attributi del processo di gestione dei resi e dei rimborsi
| Nome | Descrizione | ||
|---|---|---|---|
| ID del caso di reso ReturnCaseId | Identificativo univoco di un singolo processo di reso del cliente, che collega tutte le attività correlate dall’avvio alla chiusura. | ||
| Descrizione L’ID del caso di reso è l’identificativo principale che raggruppa tutti gli eventi e le attività relativi a un singolo reso. A ogni richiesta di reso del cliente viene assegnato un ID univoco, che consente di monitorare l’intero processo dall’inizio alla fine. Nel Process Mining, questo attributo è fondamentale per ricostruire il flusso del processo. Consente di analizzare la durata dei casi, le varianti del processo e i colli di bottiglia, collegando in una sequenza temporale coerente gli eventi distinti, come «Richiesta di reso avviata», «Merce ricevuta» e «Rimborso elaborato», per ciascun reso. Perché è importante È la chiave essenziale per monitorare un reso dall’inizio alla fine e consente tutte le analisi a livello di caso, compresi il tempo di ciclo e l’individuazione delle varianti del processo. Dove reperirli In genere è il numero del documento di vendita (VBELN) nell’intestazione dell’ordine di reso, nella tabella VBAK, dove la categoria del documento (VBTYP) indica un reso. Esempi 600001896000019060000191 | |||
| Nome dell’attività ActivityName | Nome di una specifica attività aziendale o di un evento che si è verificato nel processo di reso e rimborso. | ||
| Descrizione Questo attributo descrive una singola fase o tappa del ciclo di vita del reso. Le attività rappresentano il lavoro svolto, ad esempio «Ordine di reso approvato» o «Ispezione dell’articolo completata». Sono ricavate dalle modifiche di stato, dalla creazione di documenti o da specifiche azioni degli utenti registrate in SAP S/4HANA. L’analisi della sequenza e della frequenza di queste attività è alla base del Process Mining. Permette di visualizzare la mappa del processo, individuare i percorsi più comuni e quelli rari e identificare le attività ripetute di frequente, che possono indicare rilavorazioni o inefficienze. Perché è importante Le attività sono alla base della mappa del processo e ne consentono la visualizzazione e l’analisi, mettendo in evidenza il flusso, i colli di bottiglia e le variazioni. Dove reperirli I nomi delle attività derivano in genere da una combinazione di dati, come le modifiche di stato dei documenti nelle tabelle VBUK/VBUP, gli eventi di creazione nelle tabelle di intestazione come VBAK (documenti di vendita) e BKPF (documenti contabili) e gli stati dei movimenti merci in MSEG. Esempi Richiesta di reso avviataMerce ricevuta in magazzinoNota di credito creataRimborso elaborato | |||
| Ora dell’evento EventTime | Data e ora precise in cui si è verificata una specifica attività. | ||
| Descrizione L’ora dell’evento registra la data e l’ora in cui un evento aziendale è stato registrato nel sistema. Questo timestamp è fondamentale per ordinare cronologicamente le attività e per tutte le analisi basate sul tempo. Nel Process Mining, questo attributo serve a calcolare i tempi di ciclo tra le attività, determinare la durata di ogni fase e analizzare nel tempo le prestazioni del processo. È la base per individuare i colli di bottiglia, monitorare il rispetto degli SLA e comprendere le dinamiche temporali del processo di reso. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare durate e tempi di ciclo e individuare i ritardi nel processo. Dove reperirli In genere proviene dai campi di data e ora associati alla creazione di documenti o alle modifiche di stato, come ERDAT (data di creazione) ed ERZET (ora di creazione) nelle tabelle VBAK, LIKP e BKPF, oppure dalla data di registrazione (BUDAT) nei documenti contabili. Esempi 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID del sistema di origine SourceSystemId | Identificativo del sistema di origine da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo specifica il sistema di registrazione da cui provengono i dati degli eventi. Per questo processo, in genere si tratta dell’ID dell’istanza SAP S/4HANA. Negli ambienti con più sistemi, questo campo è fondamentale per la tracciabilità dei dati, la risoluzione dei problemi e la garanzia dell’integrità dei dati. Permette di distinguere i dati quando i resi vengono gestiti in diverse istanze ERP o integrati con sistemi esterni, come un sistema di gestione del magazzino. Perché è importante Fornisce un contesto essenziale sull’origine e sulla tracciabilità dei dati, soprattutto negli ambienti con più sistemi, garantendo che i dati siano rintracciabili e affidabili. Dove reperirli Questo valore è solitamente statico e viene configurato durante l’estrazione dei dati. Può essere recuperato dalle informazioni amministrative del sistema SAP, ad esempio dall’ID di sistema (SID). Esempi S4H_PROD_100S4Q_DEV_200 | |||
| Ultimo aggiornamento dei dati LastDataUpdateTimestamp | Timestamp che indica quando i dati di questo evento sono stati aggiornati o estratti l’ultima volta. | ||
| Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione o dell’ultimo aggiornamento dei dati. Fornisce metadati sull’aggiornamento del set di dati analizzato. È importante per valutare quanto siano aggiornate le analisi di Process Mining. Gli utenti possono verificare l’attualità dei dati, un aspetto particolarmente rilevante per il monitoraggio operativo e per le Dashboard che seguono i casi in corso. Perché è importante Indica quanto sono aggiornati i dati, un aspetto fondamentale per garantire che le analisi e le Dashboard si basino su informazioni attuali. Dove reperirli In genere viene generato e associato al set di dati al momento dell’estrazione dallo strumento ETL o dalla pipeline di dati. Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| ID cliente CustomerId | Identificativo univoco del cliente che avvia il reso. | ||
| Descrizione Questo attributo identifica il cliente che ha richiesto il reso. Collega l’istanza del processo a una specifica anagrafica cliente. Analizzare i resi per cliente aiuta a individuare schemi ricorrenti, ad esempio tassi di reso insolitamente elevati, che potrebbero indicare comportamenti fraudolenti o insoddisfazione. Consente inoltre di segmentare il processo di reso in base alla tipologia, al valore o allo storico del cliente, così da offrire livelli di servizio adeguati. Perché è importante Collega i resi a clienti specifici e consente di analizzarne il comportamento, creare segmenti e individuare chi effettua resi con frequenza. Dove reperirli Si trova nel campo del numero cliente (KUNNR) della tabella dell’intestazione dell’ordine di reso (VBAK). Esempi CUST-001234CUST-005678CUST-009012 | |||
| ID prodotto ProductId | Identificativo univoco dell’articolo reso. | ||
| Descrizione Questo attributo specifica il materiale o il prodotto oggetto del reso. Collega il processo di reso a un articolo specifico del catalogo prodotti. Analizzare i resi per prodotto è fondamentale per individuare gli articoli con tassi di reso elevati, che possono segnalare difetti di qualità, descrizioni poco chiare o problemi di produzione. Questi dati aiutano le aziende a prendere decisioni informate sulla progettazione dei prodotti, sulla gestione dei fornitori e sulle strategie di magazzino. Perché è importante Collega il processo di reso a prodotti specifici e consente di analizzare i tassi di reso per articolo e individuare problemi di qualità o di descrizione. Dove reperirli Si trova nel campo del numero materiale (MATNR) della tabella delle posizioni dell’ordine di reso (VBAP) o della tabella delle posizioni della consegna di reso (LIPS). Esempi FG-10023HW-45981SW-LICENSE-PREM | |||
| Importo del rimborso RefundAmount | Importo monetario finale del rimborso erogato al cliente. | ||
| Descrizione Questo attributo rappresenta l’importo effettivamente accreditato o rimborsato al cliente al termine del processo di reso. Il valore è registrato in documenti finanziari come le note di credito. È una metrica finanziaria fondamentale per diverse analisi. È essenziale per la Dashboard «Analisi degli scostamenti dell’importo del rimborso», che consente di confrontare l’importo effettivo con quello richiesto. Permette inoltre di segmentare i resi in base al valore e di verificare se quelli di importo elevato seguono un processo diverso o richiedono più tempo per essere risolti. Perché è importante Misura l’impatto finanziario dei resi ed è essenziale per analizzare l’accuratezza dei rimborsi, individuare i casi di importo elevato e comprendere i costi complessivi. Dove reperirli Proviene dal campo del valore netto (NETWR) del documento di nota di credito, presente in tabelle come VBRK (intestazione del documento di fatturazione) o BSEG (posizione del documento contabile). Esempi 125.50999.0049.99 | |||
| Motivo del reso ReturnReason | Motivo indicato dal cliente per la restituzione dell’articolo. | ||
| Descrizione Questo attributo registra il motivo del reso indicato dal cliente, ad esempio «Articolo difettoso», «Taglia errata» o «Non più necessario». In genere, durante l’avvio del reso, il motivo viene selezionato da un elenco predefinito di codici. Analizzare i motivi dei resi è fondamentale per individuare problemi di qualità dei prodotti, migliorare le descrizioni o perfezionare i processi di vendita. Fornisce indicazioni dirette sull’insoddisfazione dei clienti e aiuta a stabilire le priorità degli interventi per ridurre il tasso complessivo di reso. Perché è importante Fornisce indicazioni essenziali sui motivi dei resi e consente di analizzarne le cause profonde, intervenendo sulla qualità dei prodotti, sugli errori di evasione o sulle aspettative dei clienti. Dove reperirli In genere è memorizzato nel campo ABGRU (motivo di rifiuto dei documenti di vendita) della tabella delle posizioni dell’ordine di vendita per reso (VBAP). Esempi 001 - Qualità scadente002 - Danneggiato durante il trasporto005 - Articolo spedito errato | |||
| Nome utente UserName | ID utente del dipendente che ha eseguito l’attività. | ||
| Descrizione Questo attributo identifica l’utente specifico o l’agente di sistema responsabile del completamento di un’attività, come l’approvazione di un reso o la creazione di una nota di credito. In SAP, viene spesso registrato nei campi che indicano chi ha creato o modificato un documento. L’analisi per utente aiuta a individuare le persone o i team con i risultati migliori, le esigenze di formazione e la distribuzione dei carichi di lavoro. È inoltre essenziale per indagare sugli scostamenti, poiché collega le azioni del processo a persone specifiche e supporta le attività di conformità e audit. Perché è importante Associa le attività del processo a utenti specifici e consente di analizzare le prestazioni dei team, i carichi di lavoro e la conformità. Dove reperirli Si trova comunemente nelle tabelle di intestazione dei documenti, ad esempio nel campo ERNAM (Creato da) delle tabelle VBAK (ordini di vendita), LIKP (consegne) e BKPF (documenti contabili). I dettagli degli utenti possono essere arricchiti con i dati della tabella anagrafica utenti USR21. Esempi CBROWNASMITHWF_BATCH | |||
| Ora di fine dell’evento EventEndTime | Timestamp che indica il completamento di un’attività e serve a calcolarne la durata. | ||
| Descrizione Mentre StartTime (EventTime) indica l’inizio di un’attività, EventEndTime ne indica la conclusione. Per molti eventi generati dal sistema, l’ora di inizio e quella di fine coincidono, perché l’evento è istantaneo. Questo attributo è invece fondamentale per le attività di durata misurabile, come l’ispezione di un articolo. Consente di calcolare direttamente il tempo di elaborazione dell’attività. È un dato essenziale per analizzare le prestazioni e individuare le fasi specifiche che richiedono più tempo, non soltanto gli intervalli tra una fase e l’altra. Perché è importante Consente di calcolare con precisione la durata delle singole attività, un dato fondamentale per individuare le inefficienze nelle specifiche fasi del processo. Dove reperirli Spesso viene ricavato indirettamente. Per alcune attività può essere disponibile in un campo separato; più comunemente, corrisponde allo StartTime dell’attività successiva nel caso. Esempi 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Addetto alla gestione ProcessingAgent | L’addetto o il gruppo di risorse specifico responsabile della gestione di un’attività manuale. | ||
| Descrizione Questo attributo identifica la persona o il team che ha svolto una determinata attività. Può essere più specifico di «Nome utente», perché indica un ruolo o un team, soprattutto in un contesto di servizi condivisi. È utile nella Dashboard «Efficienza nell’approvazione dei rimborsi» per analizzare i risultati dei diversi addetti o team. Aiuta a comprendere come è distribuito il carico di lavoro, a individuare le esigenze di formazione e a riconoscere gli addetti o i team con i risultati migliori, che potrebbero condividere le proprie buone pratiche. Perché è importante Consente di analizzare i risultati a livello di addetto o di team, aiutando a gestire il carico di lavoro, individuare opportunità di formazione e migliorare l’efficienza. Dove reperirli Queste informazioni potrebbero essere disponibili tramite le funzioni SAP Business Partner, se agli addetti sono assegnati ruoli specifici, oppure si possono ricavare dal reparto o dal ruolo dell’utente nella struttura organizzativa delle risorse umane. Esempi Assistenza di primo livelloTeam di ispezione del magazzinoReparto Finanza - Contabilità fornitori | |||
| Data obiettivo SLA del rimborso RefundSlaTargetDate | La data entro cui il rimborso relativo al caso di reso dovrebbe essere elaborato. | ||
| Descrizione Questo attributo definisce la scadenza prevista dall’accordo sul livello di servizio (SLA) per l’elaborazione del rimborso. Di solito la data viene calcolata in base alle regole aziendali, ad esempio aggiungendo un determinato numero di giorni all’approvazione del reso o alla ricezione della merce. Questo campo è alla base della Dashboard «Monitoraggio del rispetto degli SLA sui rimborsi» e del relativo KPI. Consente di monitorare in modo proattivo i casi a rischio di mancato rispetto dello SLA e di analizzare le cause profonde dei ritardi, contribuendo così a migliorare la soddisfazione dei clienti. Perché è importante Fornisce il riferimento per misurare il rispetto degli SLA, aiutando a monitorare i risultati, dare priorità ai casi in attesa da più tempo e migliorare la soddisfazione dei clienti. Dove reperirli Quasi sempre è un campo derivato. La logica si basa su una data chiave, ad esempio la data di creazione della richiesta di reso, a cui si aggiunge una durata definita dalle regole aziendali, che può dipendere da fattori quali il tipo di cliente o il motivo del reso. Esempi 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| È automatizzata IsAutomated | Indicatore che specifica se un’attività è stata svolta da un sistema o da una persona. | ||
| Descrizione Questo attributo booleano distingue le attività eseguite automaticamente da un sistema, ad esempio tramite un flusso di lavoro o un processo in background, da quelle svolte manualmente da un utente. È essenziale per calcolare il KPI «Tasso di approvazione automatizzata dei rimborsi» e individuare opportunità di aumentare l’automazione. Filtrando le attività manuali, le aziende possono concentrare gli interventi di miglioramento sui punti in cui l’automazione può offrire i maggiori vantaggi in termini di velocità, costi e accuratezza. Perché è importante Distingue le attività manuali da quelle automatizzate, un aspetto fondamentale per individuare opportunità di automazione e misurare l’impatto della trasformazione digitale. Dove reperirli In genere si ricava dal nome utente. Ad esempio, se l’utente è «WF_BATCH» o un altro ID di sistema, l’attività viene contrassegnata come automatizzata. Esempi truefalse | |||
| È una rilavorazione IsRework | Indicatore che specifica se un’attività del caso ripete un’attività precedente. | ||
| Descrizione Questo attributo booleano calcolato individua le rilavorazioni, ossia i casi in cui un’attività viene svolta più di una volta nello stesso caso. Ad esempio, quando è necessario ripetere l’ispezione di un articolo oppure creare una nota di credito, annullarla e poi crearla di nuovo. Questo attributo è essenziale per la Dashboard «Analisi delle rilavorazioni nell’elaborazione dei rimborsi» e per il KPI «Tasso di rilavorazione dei rimborsi». Aiuta a quantificare le inefficienze del processo, evidenziando le attività soggette a errori o che richiedono più tentativi, e indica dove servono controlli o formazione migliori. Perché è importante Evidenzia le inefficienze e gli errori del processo segnalando le attività ripetute, così da intervenire in modo mirato per ridurre gli sprechi e i ritardi. Dove reperirli In genere questo indicatore viene calcolato direttamente dallo strumento di Process Mining oppure in anticipo durante la trasformazione dei dati. Verifica se lo stesso nome di attività è già comparso in precedenza nello stesso caso. Esempi truefalse | |||
| Esito dell’ispezione dell’articolo ItemInspectionOutcome | Esito dell’ispezione fisica dell’articolo reso. | ||
| Descrizione Questo attributo registra l’esito dell’ispezione effettuata dopo la ricezione della merce in magazzino. Tra gli esiti più comuni figurano «Accettato - Rivendibile», «Respinto - Danneggiato» e «Accettato - Da ricondizionare». Questi dati forniscono un contesto essenziale per le fasi successive del processo e determinano se viene emesso un rimborso totale, parziale o nessun rimborso. Analizzare l’esito aiuta a individuare i motivi dei rifiuti e può fornire indicazioni sull’imballaggio dei prodotti o sui partner di spedizione, se gli articoli risultano spesso danneggiati durante il trasporto. Perché è importante Chiarisce i criteri alla base dell’approvazione o del rifiuto dei rimborsi e fornisce dati utili sulle condizioni degli articoli e sui motivi delle rettifiche degli importi. Dove reperirli Queste informazioni possono essere registrate in un lotto di ispezione del modulo di gestione della qualità (QM), oppure come stato o codice motivo nella riga dell’articolo della consegna di reso (LIPS). Potrebbero anche trovarsi in un campo personalizzato. Esempi Accettato - RivendibileAccettato - Da ricondizionareRespinto - Danno causato dal clienteRespinto - Articolo restituito errato | |||
| ID della politica di reso ReturnPolicyId | Identificativo della politica di reso applicabile a questo specifico caso. | ||
| Descrizione Questo attributo indica quale politica di reso o insieme di regole si applica alla transazione. Le politiche possono variare in base al tipo di prodotto, al segmento di clientela o al tempo trascorso dall’acquisto. Questi dati sono essenziali per la Dashboard «Panoramica sulla conformità alle politiche di reso». Associando ogni caso a una politica, il sistema può verificare automaticamente il rispetto delle regole, ad esempio le scadenze per il reso o i requisiti relativi alle condizioni dell’articolo, e segnalare eventuali scostamenti da analizzare. Perché è importante Consente di verificare automaticamente il rispetto delle regole aziendali, contribuendo a garantire che i resi siano gestiti in modo coerente e secondo le politiche previste. Dove reperirli Spesso non è un campo standard di SAP e potrebbe essere necessario ricavarlo applicando la logica aziendale a dati quali il tipo di prodotto, il cliente e la data di vendita. Se implementato, può essere memorizzato in un campo personalizzato. Esempi STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Importo del rimborso richiesto RequestedRefundAmount | Importo del rimborso richiesto o previsto all’inizio del processo. | ||
| Descrizione Questo attributo registra il valore della merce resa indicato nella richiesta iniziale. Costituisce la base di riferimento per il confronto con l’importo finale rimborsato. Questo campo è necessario per la Dashboard «Analisi degli scostamenti dell’importo del rimborso». Confrontare l’importo richiesto con quello effettivamente rimborsato aiuta a individuare problemi come rimborsi parziali dovuti a danni agli articoli, spese di reintegro o altri adeguamenti, garantendo accuratezza e trasparenza finanziaria. Perché è importante Fornisce una base di riferimento per misurare l’accuratezza dei rimborsi e individuare e analizzare le differenze tra gli importi previsti e quelli effettivi. Dove reperirli In genere si ricava dal valore netto degli articoli nell’ordine di vendita iniziale per il reso. Corrisponde al valore netto (NETWR) delle relative righe nella tabella VBAP. Esempi 125.501050.0049.99 | |||
| Numero della consegna di reso ReturnDeliveryNumber | Identificativo univoco del documento di consegna di reso. | ||
| Descrizione Quando un cliente restituisce fisicamente la merce, in SAP viene creato un documento di consegna di reso per gestire la logistica in entrata. Questo attributo contiene il numero univoco del documento. L’ID è importante per monitorare il movimento fisico della merce resa. Collega gli aspetti finanziari e logistici del reso e consente un’analisi dettagliata delle fasi di ricezione e ispezione. Perché è importante Collega l’ordine di reso alla ricezione fisica della merce ed è fondamentale per analizzare la logistica e i tempi di elaborazione in magazzino. Dove reperirli È il numero del documento di consegna (VBELN) nella tabella dell’intestazione delle consegne (LIKP), dove la categoria del documento indica una consegna di reso. Esempi 840000128400001384000014 | |||
| Numero della nota di credito CreditMemoNumber | Identificativo univoco del documento di nota di credito che autorizza il rimborso. | ||
| Descrizione La nota di credito è il documento di fatturazione che accredita ufficialmente sul conto del cliente l’importo degli articoli resi. Questo attributo contiene il numero univoco del documento finanziario. Monitorare il numero della nota di credito è essenziale per analizzare la fase di liquidazione finanziaria del processo di reso. Segna una tappa fondamentale, spesso dà avvio al pagamento effettivo del rimborso ed è necessario per la riconciliazione finanziaria e gli audit. Perché è importante Rappresenta la transazione finanziaria ufficiale relativa al rimborso ed è fondamentale per monitorare le fasi finali del processo e svolgere gli audit finanziari. Dove reperirli È il numero del documento di fatturazione (VBELN) nella tabella dell’intestazione dei documenti di fatturazione (VBRK), dove la categoria del documento indica una nota di credito. Esempi 900003459000034690000347 | |||
| Organizzazione commerciale SalesOrganization | Unità organizzativa responsabile della vendita originale e del reso. | ||
| Descrizione In SAP, l’organizzazione commerciale è un elemento chiave della struttura organizzativa e rappresenta l’unità responsabile della vendita e della distribuzione di prodotti e servizi. Viene assegnata alla transazione di reso. Questo attributo consente di filtrare e confrontare il processo di reso tra diverse unità aziendali, aree geografiche o divisioni. Aiuta a individuare le organizzazioni commerciali con tassi di reso più elevati o processi di gestione meno efficienti e fornisce una base per analizzare le prestazioni organizzative. Perché è importante Consente di confrontare le prestazioni e i tassi del processo di reso tra diverse unità aziendali, aree geografiche o canali di vendita. Dove reperirli Si trova nel campo dell’organizzazione commerciale (VKORG) della tabella dell’intestazione dell’ordine di reso (VBAK). Esempi 10002100US01 | |||
| Rispetto della policy sui resi ReturnPolicyAdherence | Indicatore che specifica se il caso di reso è conforme alla politica di reso definita. | ||
| Descrizione Questo attributo booleano calcolato indica se un reso soddisfa i criteri stabiliti dalla politica applicabile. La logica può verificare, ad esempio, se il reso è stato avviato entro i termini consentiti o se il motivo è valido per il prodotto. Questo attributo supporta direttamente la Dashboard «Panoramica sulla conformità alle politiche di reso». Quantifica i livelli di conformità e consente di scendere di livello per analizzare i casi non conformi e comprenderne i motivi, contribuendo ad applicare le politiche in modo più efficace. Perché è importante Quantifica il rispetto delle regole aziendali e aiuta a individuare e ridurre le violazioni delle politiche che possono incidere sulla redditività o generare eccezioni nel processo. Dove reperirli Si calcola applicando le regole aziendali. Ad esempio: (data di avvio del reso - data di acquisto originale) <= [giorni consentiti per il reso]. Sono necessarie la data di acquisto originale e le regole della politica. Esempi truefalse | |||
| Rispetto dello SLA sui rimborsi RefundSlaAdherence | Indicatore che specifica se il rimborso è stato elaborato entro la scadenza prevista dall’accordo sul livello di servizio (SLA). | ||
| Descrizione Questo attributo calcolato verifica se l’attività «Rimborso elaborato» è avvenuta entro la «Data obiettivo SLA del rimborso». Per ogni caso indica semplicemente se lo SLA è stato rispettato oppure no. È la metrica principale della Dashboard «Monitoraggio del rispetto degli SLA sui rimborsi» e del KPI «Tasso di rispetto degli SLA sui rimborsi». Aiuta a misurare i risultati rispetto agli impegni presi con i clienti e a individuare i casi che non hanno soddisfatto le aspettative, consentendo di analizzare le cause profonde dei ritardi. Perché è importante Misura direttamente il rispetto degli impegni presi con i clienti ed è quindi un indicatore fondamentale della qualità del servizio e della soddisfazione dei clienti. Dove reperirli Si calcola confrontando l’EventTime dell’attività «Rimborso elaborato» con il valore «RefundSlaTargetDate» per ciascun caso. Esempi truefalse | |||
| Stato dell’ordine di reso ReturnOrderStatus | Stato complessivo corrente del caso di reso. | ||
| Descrizione Questo attributo indica lo stato generale del caso di reso in un determinato momento, ad esempio «Aperto», «In corso» o «Chiuso». Spesso si tratta di uno stato aggregato, ricavato dall’ultima tappa principale completata. È essenziale per la Dashboard «Stato attuale dei casi di reso», che offre una vista operativa del carico di lavoro e della distribuzione dei casi. Aiuta i responsabili a capire quanti casi si trovano in ciascuna fase del processo, così da distribuire meglio le risorse e gestire il carico di lavoro. Perché è importante Mostra a che punto del processo si trova ciascun caso, un’informazione essenziale per le Dashboard operative che monitorano il carico di lavoro e lo stato correnti. Dove reperirli Si ricava dai campi di stato dei documenti pertinenti. Ad esempio, dallo stato di testata (GBSTK) o di riga (LFSTK) dell’ordine di vendita correlato (VBUK/VBUP) o dei documenti di consegna. Esempi In attesa della ricezione della merceIn attesa di ispezioneIn attesa del rimborsoChiuso | |||
Attività di gestione dei resi e dei rimborsi
| Attività | Descrizione | ||
|---|---|---|---|
| Caso di reso chiuso | È l’attività finale, che indica il completamento del processo di reso e l’assenza di ulteriori azioni previste per il caso. In genere si deduce quando il documento dell’ordine di reso raggiunge nel sistema uno stato finale di chiusura. | ||
| Perché è importante Questo evento definisce la fine del ciclo di vita del processo e consente di calcolare il tempo di ciclo complessivo. Conferma che il caso è stato risolto completamente. Dove reperirli Si deduce quando lo stato complessivo dell’ordine di reso nella tabella VBAK, o delle relative posizioni nella tabella VBAP, raggiunge lo stato «Completato» o «Chiuso». La determinazione dipende dalla configurazione della gestione degli stati del sistema. Acquisizione Si deduce quando lo stato del documento dell’ordine di reso passa a «Completato». Tipo di evento inferred | |||
| Ispezione dell’articolo completata | Indica il completamento della valutazione della qualità e delle condizioni della merce resa. In Advanced Returns Management, spesso si tratta di una fase esplicita che registra l’esito dell’ispezione e determina l’azione successiva, ad esempio il rimborso o lo scarto. | ||
| Perché è importante La durata e l’esito dell’ispezione incidono direttamente sui tempi di elaborazione del rimborso e sulla gestione delle scorte. Questa attività è essenziale per analizzare l’efficienza delle ispezioni e le rilavorazioni. Dove reperirli In SAP Advanced Returns Management (ARM), può essere un evento esplicito registrato dalla transazione di ispezione. Può anche essere dedotto da una modifica dello stato della posizione dell’ordine di reso che indica l’esito dell’ispezione. Acquisizione Si rileva dai log delle transazioni o dalle modifiche di stato relative alle attività di follow-up logistico in ARM. Tipo di evento explicit | |||
| Merce ricevuta in magazzino | Questo evento segna la ricezione fisica dell’articolo reso in magazzino o presso il centro di elaborazione. Viene registrato esplicitamente quando si esegue la registrazione dell’entrata merci (PGR) per la consegna di reso, generando un documento materiale. | ||
| Perché è importante È una tappa fondamentale, che avvia il conteggio dei tempi per l’ispezione e la gestione dell’articolo. I ritardi precedenti dipendono dal cliente, mentre quelli successivi sono interni. Dove reperirli Si rileva dalle tabelle dei documenti materiali MSEG e MKPF per il tipo di movimento di entrata merci associato ai resi. La data di registrazione (MKPF-BUDAT) indica il momento dell’evento. Acquisizione L’evento corrisponde alla registrazione dell’entrata merci per la consegna di reso. Tipo di evento explicit | |||
| Nota di credito creata | È la creazione del documento di fatturazione ufficiale che accredita sul conto del cliente l’importo relativo all’articolo reso. L’evento viene registrato esplicitamente quando la nota di credito viene generata a partire dalla relativa richiesta. | ||
| Perché è importante La creazione della nota di credito è una tappa finanziaria fondamentale: conferma l’importo da rimborsare e autorizza l’avvio del pagamento. Dove reperirli Si rileva dalla creazione di un documento di fatturazione nella tabella VBRK, con una categoria documento che indica una nota di credito. Il documento è collegato alla richiesta di nota di credito nella tabella VBFA. Acquisizione L’evento viene registrato al salvataggio di un nuovo documento di fatturazione per nota di credito, ad esempio tramite la transazione VF01. Tipo di evento explicit | |||
| Richiesta di nota di credito creata | Dopo un’ispezione con esito positivo, questa attività segna la creazione di una richiesta di accredito a favore del cliente. Viene registrata come nuovo documento di vendita, ossia una richiesta di nota di credito, che fa riferimento all’ordine di reso originale. | ||
| Perché è importante È l’evento che avvia la fase di liquidazione finanziaria del processo di reso. Analizzare il tempo che intercorre tra l’ispezione e questa fase permette di valutare l’efficienza del passaggio dalla logistica all’amministrazione finanziaria. Dove reperirli Si rileva dalla creazione di un documento di vendita nella tabella VBAK con categoria documento Richiesta di nota di credito. Il collegamento al reso è mantenuto nella tabella del flusso documentale VBFA. Acquisizione L’evento viene registrato al salvataggio di un nuovo documento di richiesta di nota di credito. Tipo di evento explicit | |||
| Richiesta di reso avviata | È il punto di partenza del processo di reso, in cui viene creato formalmente nel sistema un ordine di reso. In SAP S/4HANA, l’evento viene registrato esplicitamente al salvataggio di un nuovo documento di vendita di tipo ordine di reso. | ||
| Perché è importante Questa attività segna l’avvio ufficiale del ciclo di vita del caso di reso. Analizzare il tempo che intercorre tra questo evento e la chiusura è fondamentale per misurare il tempo di ciclo complessivo del reso e valutare l’esperienza del cliente. Dove reperirli È un evento esplicito, registrato alla creazione di un documento di vendita nella tabella VBAK, quando la categoria del documento (VBAK-VBTYP) indica un ordine di reso. La data di creazione è registrata in VBAK-ERDAT. Acquisizione L’evento viene registrato al salvataggio di un nuovo ordine di vendita per reso, ad esempio tramite la transazione VA01. Tipo di evento explicit | |||
| Rimborso elaborato | Questa attività segna la fase finale del processo di rimborso: l’accredito viene compensato, a indicare che il pagamento è stato inviato al cliente. L’evento si deduce dalla creazione, nel modulo finanziario, di un documento di compensazione che salda l’accredito aperto sul conto del cliente. | ||
| Perché è importante È il momento in cui il cliente riceve effettivamente il pagamento. Il tempo necessario per arrivare a questa fase dall’avvio del reso incide notevolmente sulla soddisfazione del cliente ed è fondamentale per misurare il rispetto degli SLA. Dove reperirli Si deduce dalle informazioni sul documento di compensazione nella tabella delle posizioni contabili BSEG. La data di compensazione (BSEG-AUGDT) nella posizione cliente associata alla nota di credito indica quando è stato elaborato il rimborso. Acquisizione Si deduce dalla compilazione del campo della data di compensazione nel documento contabile associato alla nota di credito. Tipo di evento inferred | |||
| Documento contabile creato | L’evento si verifica quando la nota di credito viene registrata correttamente nel modulo di contabilità finanziaria. Vengono create le relative registrazioni nel libro mastro, rendendo ufficiale l’accredito dal punto di vista contabile. | ||
| Perché è importante Questa attività conferma che l’accredito è stato integrato nel sistema finanziario. Il tempo che intercorre tra la creazione della nota di credito e la registrazione contabile può evidenziare problemi nell’interfaccia tra fatturazione e contabilità. Dove reperirli Si rileva dalla creazione dell’intestazione di un documento nella tabella contabile BKPF, collegata alla nota di credito in VBRK (VBRK-BELNR). Acquisizione L’evento viene registrato quando il documento di fatturazione viene contabilizzato correttamente nella contabilità finanziaria. Tipo di evento explicit | |||
| Documento di consegna del reso creato | Questa attività indica la creazione di un documento di consegna in entrata, utilizzato per gestire la ricezione fisica della merce resa. Il sistema registra esplicitamente la creazione di un documento di consegna che fa riferimento all’ordine di reso. | ||
| Perché è importante È una tappa logistica fondamentale. Il tempo che intercorre tra l’approvazione del reso e la creazione della consegna evidenzia l’efficienza con cui le informazioni sul reso vengono comunicate al magazzino o al reparto ricevimento. Dove reperirli Si rileva dalla creazione di un’intestazione di consegna nella tabella LIKP, collegata all’ordine di reso precedente tramite la tabella del flusso documentale VBFA. Acquisizione L’evento viene registrato al salvataggio di un nuovo documento di consegna per reso, ad esempio tramite la transazione VL01N. Tipo di evento explicit | |||
| Ordine di reso approvato | Indica l’approvazione o il rilascio formale dell’ordine di reso, che può così passare alla fase successiva. In genere si deduce da una modifica dello stato nell’intestazione o nella posizione del documento di vendita, che segnala la rimozione di eventuali blocchi. | ||
| Perché è importante Le fasi di approvazione possono causare ritardi significativi. Monitorare questa attività aiuta a individuare i colli di bottiglia nella fase iniziale di autorizzazione del processo di reso. Dove reperirli Si deduce dalle tabelle di gestione degli stati o dai campi di stato direttamente nelle tabelle VBAK o VBAP. Una modifica dello stato di rilascio o la rimozione di un blocco alla consegna (VBAP-LIFSP) può indicare l’avvenuta approvazione. Acquisizione Si deduce da una modifica dei campi di stato dell’intestazione o della posizione dell’ordine di reso che ne indica il rilascio o l’approvazione. Tipo di evento inferred | |||
| Ordine di sostituzione creato | Questa attività rappresenta una soluzione alternativa: invece di un rimborso, viene creato un nuovo ordine di vendita per spedire al cliente un articolo sostitutivo. L’evento viene registrato alla creazione di un nuovo ordine di vendita collegato al reso originale. | ||
| Perché è importante Questa attività permette di distinguere i resi con rimborso da quelli con sostituzione, che seguono percorsi diversi e producono esiti diversi per il cliente. È fondamentale per analizzare le varianti del processo. Dove reperirli Si rileva dalla creazione di un nuovo documento di vendita in VBAK, collegato all’ordine di reso nella tabella del flusso documentale (VBFA). Acquisizione L’evento viene registrato al salvataggio di un nuovo documento di ordine di vendita identificato come sostituzione. Tipo di evento explicit | |||
| Reso rifiutato | Indica che l’articolo reso non soddisfa i criteri previsti dalla politica di reso e che la richiesta di rimborso o accredito è stata respinta. In genere viene registrato applicando alla posizione dell’ordine di reso, dopo l’ispezione, uno stato o un codice motivo specifico. | ||
| Perché è importante Monitorare i rifiuti aiuta ad analizzare la conformità alle politiche di reso e a individuare i motivi più frequenti dei dinieghi. Si tratta di un percorso di eccezione importante nel processo. Dove reperirli Si deduce dall’inserimento di un motivo di rifiuto (VBAP-ABGRU) nella posizione dell’ordine di reso o dall’assegnazione di uno stato specifico durante il processo di ispezione in Advanced Returns Management. Acquisizione Si deduce dall’inserimento di un motivo di rifiuto o di uno stato specifico di rifiuto nella posizione del documento di reso. Tipo di evento inferred | |||
Guide all’estrazione
Passaggi
- Verifica dei prerequisiti: Verifichi che l’account utente che esegue l’estrazione disponga delle autorizzazioni necessarie in SAP S/4HANA per accedere alle viste Core Data Services (CDS) richieste. Tra le viste principali figurano I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry e I_ClearedItem.
- Accesso allo strumento di interrogazione: Acceda al client SQL o allo strumento di integrazione dei dati che preferisce e che dispone di una connessione al database SAP S/4HANA. Può trattarsi di strumenti SAP, come SAP Analytics Cloud, o di una piattaforma ETL di terze parti.
- Impostazione dei parametri della query: Prima di eseguirla, modifichi la query SQL fornita. Individui i valori segnaposto e li sostituisca con i parametri corretti per il proprio ambiente. Dovrà impostare
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]e gli altri filtri relativi al tipo di documento o al codice società. - Esecuzione della query di estrazione: Copi la query SQL completa e la esegua nello strumento scelto. La query raccoglie tutte le attività specificate in un unico insieme di dati, unendo i risultati di più istruzioni select.
- Comprensione della logica della query: Ogni blocco
SELECTnella strutturaUNION ALLestrae una specifica attività. Unisce più viste CDS per raccogliere gli attributi necessari, assegna una stringa fissa aActivityNamee seleziona il timestamp pertinente perEventTime. - Revisione dei dati grezzi: Al termine della query, riveda brevemente i risultati. Verifichi che il numero di righe sia ragionevole e che le colonne principali, come
ReturnCaseId,ActivityNameedEventTime, contengano i valori previsti. - Trasformazione dei dati: La query produce un Event Log in formato tabellare. In genere non sono necessarie trasformazioni strutturali significative. Potrebbe tuttavia essere necessario adeguare i formati dei timestamp o i tipi di dati in base ai requisiti del sistema di destinazione.
- Esportazione dell’Event Log: Esporti i risultati della query in un file CSV. Verifichi che il file utilizzi la codifica UTF-8 per evitare problemi con i caratteri, in particolare nei nomi utente o nelle descrizioni dei prodotti.
- Caricamento nello strumento di Process Mining: Il file CSV ottenuto è pronto per essere caricato nella piattaforma di Process Mining, ad esempio ProcessMind. Mappi le colonne del file ai campi corrispondenti nello strumento, per esempio
ReturnCaseIdsu ID del caso,ActivityNamesu Attività edEventTimesu Timestamp.
Configurazione
- Prerequisiti: L’utente che esegue l’estrazione deve disporre delle autorizzazioni di visualizzazione per gli oggetti relativi ai documenti di vendita (VBAK), alle consegne (LIKP), alla fatturazione (VBRK) e alla contabilità (BSEG, BKPF). È indispensabile poter accedere alle viste CDS sottostanti.
- Filtri per l’ambito dei dati: È fondamentale filtrare la query per tipi di documento specifici, così da isolare il processo di gestione dei resi. Configuri i segnaposto per i tipi di ordine di reso (ad esempio, 'RE'), i tipi di richiesta di nota di credito (ad esempio, 'G2') e i tipi di ordine di sostituzione (ad esempio, 'SO'). Si consiglia inoltre di filtrare per
CompanyCodeoSalesOrganizationper limitare l’ambito dei dati. - Filtro per intervallo di date: Per gestire le prestazioni e il volume dei dati, applichi sempre un filtro per intervallo di date. Inizi con un periodo recente di 3-6 mesi. La query utilizza come condizione di filtro principale la data di creazione dell’ordine di reso iniziale (
I_SalesDocument.CreationDate). - Considerazioni sulle prestazioni: Questa query completa unisce più viste CDS di grandi dimensioni. L’esecuzione può richiedere molte risorse al sistema S/4HANA di origine. Pianifichi l’estrazione nelle fasce orarie di minore attività per ridurne l’impatto. Per insiemi di dati molto ampi, valuti strategie di caricamento incrementale.
Query di esempio sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Passaggi
- Verifichi che sia disponibile l’accesso diretto in lettura allo schema SAP HANA contenente i dati pertinenti relativi a vendite, consegne, fatturazione, documenti materiale, ispezioni, stati e contabilità. Lo schema, le viste e i nomi dei campi variano a seconda dell’implementazione di SAP S/4HANA; sostituisca quindi ogni segnaposto tra parentesi quadre con gli oggetti e i campi configurati nel sistema.
- Definisca l’ambito dell’estrazione usando [Start date], [End date], [Company Code filter] e [Return document type filter]. Per l’estrazione iniziale, utilizzi un periodo mobile di tre-sei mesi e lo estenda solo dopo aver verificato prestazioni e completezza.
- Individui gli ordini di reso in [Your sales document header table] e [Your sales document item table]. Limiti l’insieme ai tipi di documento degli ordini di reso configurati in [Your return order document type configuration]. Mantenga il numero dell’ordine di reso e il numero della posizione come riferimenti principali per collegare i documenti successivi.
- Ricostruisca il flusso documentale dagli ordini di reso alle consegne di reso in entrata, alle richieste di nota di credito, agli ordini di sostituzione e alle note di credito usando [Your document flow table or view]. Non presuma che il flusso documentale sia memorizzato in VBAK o VBAP. Configuri i campi di relazione in base al modello di flusso documentale utilizzato nel sistema.
- Estragga gli eventi di creazione espliciti dai record pertinenti delle intestazioni e delle posizioni dei documenti. Estragga gli eventi di approvazione, rifiuto, ispezione, chiusura, entrata merci, contabilizzazione e compensazione dalle fonti configurate per stati, ispezioni, documenti materiale, contabilità e compensazioni. Ogni attività deve essere registrata in una riga evento distinta, poiché ProcessMind non deduce gli eventi.
- Normalizzi i timestamp usando un tipo di dato timestamp del database e un fuso orario coerenti. Applichi a ogni attività la precedenza configurata per i timestamp degli eventi. Se sono disponibili solo la data e l’ora, le combini usando il fuso orario di sistema configurato in [Your system time zone].
- Compili ReturnCaseId per ogni evento. Utilizzi il numero dell’ordine di reso di origine oppure l’identificativo del caso di reso configurato, se Advanced Returns Management memorizza una chiave del caso distinta. Escluda gli eventi non collegabili a un caso di reso oppure li inserisca in un output di eccezione per la correzione.
- Compili le colonne obbligatorie ReturnCaseId, ActivityName, EventTime, SourceSystemId e LastDataUpdateTimestamp. Se disponibili, includa anche le colonne consigliate, tra cui EventEndTime, UserName, ReturnReason, RefundAmount, ProductId e CustomerId. Mantenga una riga per ogni occorrenza di attività e non aggreghi le attività in un’unica riga per caso.
- Convalidi i risultati applicando i controlli descritti in validationSteps. Verifichi che siano presenti tutti i dodici nomi di attività, che i timestamp seguano un ordine plausibile all’interno di ogni caso e che i riferimenti ai documenti corrispondano alle tabelle di origine.
- Esporti i risultati in un file CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Mantenga esattamente i nomi delle colonne, utilizzi una sola riga di intestazione, conservi i timestamp in un formato ISO non ambiguo e carichi l’Event Log configurando ReturnCaseId come identificativo del caso e ActivityName come colonna delle attività.
Configurazione
- Intervallo di date: Inizi con un periodo di tre-sei mesi. Utilizzi i parametri [Start date] e [End date] e includa una cronologia sufficiente a comprendere i casi avviati prima del periodo selezionato ma conclusi al suo interno.
- Insieme dei resi: Filtri in base ai tipi di documento degli ordini di reso configurati in [Your return order document type configuration]. Non codifichi un tipo di documento senza averlo prima verificato nel sistema di destinazione.
- Filtri organizzativi: Applichi i filtri [Company Code filter], organizzazione commerciale, canale di distribuzione, divisione, stabilimento o cliente solo quando necessario. Verifichi che i filtri non escludano documenti successivi tra società diverse o intercompany.
- Oggetti di origine: Sostituisca i segnaposto [Your table name] e [Your view name] con tabelle SAP S/4HANA o viste CDS approvate. Nell’implementazione potrebbero essere disponibili VBAK, VBAP, VBRK e VBRP, ma prima dell’esecuzione occorre verificarne l’utilizzo e le estensioni.
- Gestione dei timestamp: Configuri i campi timestamp di origine e il fuso orario per ogni attività. Memorizzi EventTime ed EventEndTime in modo coerente, preferibilmente in UTC o nel fuso orario concordato per ProcessMind.
- Interpretazione degli stati: Configuri i valori esatti degli stati, i codici motivo, gli esiti delle ispezioni e gli indicatori di chiusura che nel sistema rappresentano approvazione, rifiuto, completamento dell’ispezione e chiusura del caso.
- Identificativo del sistema di origine: Sostituisca [Source system identifier] con un valore stabile, ad esempio l’identificativo del sistema SAP utilizzato dalla piattaforma di estrazione.
- Timestamp di aggiornamento: Sostituisca [Extraction timestamp] con il timestamp di avvio dell’esecuzione della query o di creazione dell’istantanea di origine. Utilizzi lo stesso valore per tutte le righe di una singola estrazione, a meno che non siano necessari timestamp di aggiornamento a livello di riga.
- Prestazioni: Limiti l’insieme iniziale degli ordini di reso prima di unirlo alle fonti di grandi dimensioni relative a flusso documentale, contabilità, documenti materiale e stati. Utilizzi campi indicizzati o che consentono l’eliminazione delle partizioni, eviti scansioni senza restrizioni e materializzi i risultati intermedi solo previa approvazione dell’amministratore del database.
- Estrazione incrementale: Per le esecuzioni ricorrenti, utilizzi [Last successful extraction timestamp] e una finestra di sovrapposizione controllata per acquisire gli aggiornamenti tardivi. Rimuova i duplicati usando ReturnCaseId, ActivityName, la chiave del documento di origine ed EventTime.
- Autorizzazioni e prerequisiti: Ottenga le autorizzazioni di lettura per tutti gli oggetti e i campi di origine configurati, l’approvazione per l’accesso diretto al database e la conferma che i componenti SAP richiesti e le funzioni di Advanced Returns Management siano attivi, ove applicabile.
- Protezione dei dati: Limiti i campi relativi ai clienti e ai dati finanziari al minimo necessario, rispetti i controlli sulla privacy dell’organizzazione e protegga i file esportati.
Query di esempio sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; È pronto per iniziare?
Con questo template dispone delle conoscenze di base necessarie per estrarre e analizzare i dati relativi alla gestione dei resi e dei rimborsi. Inizi oggi il percorso verso l’eccellenza dei processi.
Ottimizzi subito la gestione dei resi e dei rimborsi in SAP S/4HANA
Individui le inefficienze, riduca del 30% il tempo di ciclo e migliori la soddisfazione.
Non è richiesta alcuna carta di credito. Inizi oggi a ottimizzare i processi.