Il Suo Template dei dati per l'elaborazione di resi e rimborsi
Il Suo Template dei dati per l'elaborazione di resi e rimborsi
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l'estrazione
Attributi dell’elaborazione di resi e rimborsi
| Nome | Descrizione | ||
|---|---|---|---|
| ID del caso di reso ReturnCaseId | L'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à appartenenti a una singola istanza di reso. A ogni richiesta di reso del cliente viene assegnato un ID univoco, che consente di monitorare l'intero processo end-to-end. Nel Process Mining, questo attributo è fondamentale per ricostruire il flusso del processo. Consente di analizzare la durata dei casi e le varianti di processo, nonché di individuare i colli di bottiglia, collegando eventi distinti come «Richiesta di reso avviata», «Merce ricevuta» e «Rimborso elaborato» in una sequenza temporale coerente per ogni singolo reso. Perché è importante È la chiave essenziale per monitorare un reso dall'inizio alla fine e consente tutte le analisi a livello di caso, inclusi il tempo di attraversamento e l'individuazione delle varianti di processo. Dove reperirlo In genere corrisponde al numero del documento di vendita (VBELN) dell'intestazione dell'ordine di reso nella tabella VBAK, dove la categoria documento (VBTYP) indica un reso. Esempi 600001896000019060000191 | |||
| Nome dell'attività ActivityName | Il 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 milestone nel ciclo di vita dei resi. Le attività rappresentano il lavoro eseguito, ad esempio «Ordine di reso approvato» o «Ispezione dell'articolo completata». Sono derivate da modifiche di stato, creazione di documenti o specifiche azioni dell'utente registrate in SAP S/4HANA. L'analisi della sequenza e della frequenza di queste attività costituisce il nucleo del Process Mining. Aiuta a visualizzare la mappa del processo, a identificare i percorsi comuni e rari e a individuare le attività ripetute di frequente, che possono indicare rilavorazioni o inefficienze. Perché è importante Le attività costituiscono la struttura portante della mappa del processo e consentono di visualizzare e analizzare il flusso del processo, i colli di bottiglia e le variazioni. Dove reperirlo I nomi delle attività derivano in genere da una combinazione di dati, tra cui le modifiche di stato dei documenti nelle tabelle VBUK/VBUP, gli eventi di creazione nelle tabelle di intestazione come VBAK, per i documenti di vendita, e BKPF, per i documenti contabili, nonché gli stati dei movimenti merci in MSEG. Esempi Richiesta di reso avviataMerci ricevute in magazzinoNota di credito creataRimborso elaborato | |||
| Ora dell'evento EventTime | Il timestamp preciso che indica quando si è verificata una specifica attività. | ||
| Descrizione Event Time registra la data e l'ora in cui un evento aziendale è stato acquisito nel sistema. Questo timestamp è fondamentale per ordinare cronologicamente le attività e per tutte le analisi basate sul tempo. Nel Process Mining, questo attributo viene utilizzato per calcolare i tempi di attraversamento tra le attività, determinare la durata di ogni fase e analizzare le prestazioni del processo nel tempo. Costituisce 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 tutte le durate e i tempi di attraversamento e individuare i ritardi del processo. Dove reperirlo In genere proviene dai campi di data e ora associati alla creazione dei 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 dal quale sono stati estratti i dati. | ||
| Descrizione Questo attributo specifica il sistema di riferimento da cui hanno origine i dati degli eventi. Per questo processo, in genere corrisponde all'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 verifica dell'integrità dei dati. Aiuta a distinguere i dati quando i resi vengono elaborati su istanze ERP diverse 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 la rintracciabilità e l'affidabilità dei dati. Dove reperirlo Questo valore è generalmente statico e viene configurato durante l'estrazione dei dati. Può essere recuperato dalle informazioni amministrative del sistema SAP, ad esempio dal System ID (SID). Esempi S4H_PROD_100S4Q_DEV_200 | |||
| Ultimo aggiornamento dei dati LastDataUpdateTimestamp | Il timestamp che indica quando i dati relativi a 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 dataset analizzato. È importante per comprendere l'attualità dell'analisi di Process Mining. Gli utenti possono verificare quanto siano aggiornati i dati, un aspetto particolarmente rilevante per il monitoraggio operativo e per i Dashboard che tengono sotto controllo i casi in corso. Perché è importante Indica l'aggiornamento dei dati, un elemento fondamentale per garantire che analisi e Dashboard si basino su informazioni aggiornate. Dove reperirlo In genere viene generato e registrato nel dataset al momento dell'estrazione dei dati dallo strumento ETL o dalla pipeline dei dati. Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| ID cliente CustomerId | L'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 controparte presente nei dati anagrafici dei clienti. L'analisi dei resi per cliente aiuta a individuare schemi ricorrenti, come tassi di reso insolitamente elevati, che potrebbero indicare comportamenti fraudolenti o insoddisfazione. Consente inoltre di segmentare il processo di reso in base al tipo, al valore o alla storia del cliente, permettendo di definire livelli di servizio mirati. Perché è importante Collega i resi a clienti specifici e consente di analizzare il comportamento dei clienti, creare segmentazioni e individuare quelli che effettuano resi con maggiore frequenza. Dove reperirlo Si trova nel campo del numero cliente (KUNNR) nella tabella dell'intestazione dell'ordine di reso (VBAK). Esempi CUST-001234CUST-005678CUST-009012 | |||
| ID prodotto ProductId | L'identificativo univoco dell'articolo restituito. | ||
| Descrizione Questo attributo specifica il materiale o prodotto oggetto del reso. Collega il processo di reso a un articolo specifico del catalogo prodotti. L'analisi dei resi per prodotto è fondamentale per individuare gli articoli con tassi di reso elevati, che possono indicare difetti di qualità, descrizioni inadeguate o problemi di produzione. Questi dati aiutano l'azienda a prendere decisioni informate sulla progettazione dei prodotti, sulla gestione dei fornitori e sulle strategie di inventario. Perché è importante Collega il processo di reso a prodotti specifici e consente di analizzare i tassi di reso a livello di articolo e di individuare problemi di qualità o di descrizione. Dove reperirlo Si trova nel campo del numero materiale (MATNR) nella tabella delle posizioni dell'ordine di reso (VBAP) o nella tabella delle posizioni della consegna di reso (LIPS). Esempi FG-10023HW-45981SW-LICENSE-PREM | |||
| Importo del rimborso RefundAmount | Il valore 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 nei documenti finanziari, come le note di credito. È una metrica finanziaria fondamentale per diverse analisi. È essenziale per il Dashboard «Analisi delle discrepanze dell'importo del rimborso», che lo confronta con l'importo richiesto. Consente inoltre di segmentare i resi in base al valore, per verificare se quelli di importo elevato seguono un percorso 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 reperirlo 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, segmento del documento contabile. Esempi 125.50999.0049.99 | |||
| Motivo del reso ReturnReason | Il motivo indicato dal cliente per la restituzione dell'articolo. | ||
| Descrizione Questo attributo acquisisce il motivo dichiarato dal cliente per il reso, ad esempio «Articolo difettoso», «Taglia errata» o «Non più necessario». In genere viene selezionato da un elenco predefinito di codici motivo durante l'avvio del processo di reso. L'analisi dei motivi dei resi è fondamentale per individuare problemi di qualità dei prodotti, migliorare le descrizioni o perfezionare i processi di vendita. Fornisce una visione diretta dell'insoddisfazione dei clienti e aiuta a stabilire le priorità per gli interventi di miglioramento, riducendo il tasso complessivo di reso. Perché è importante Fornisce informazioni essenziali sulle cause dei resi e consente l'analisi delle cause principali per intervenire sulla qualità dei prodotti, sugli errori di evasione o sul divario tra aspettative e realtà del cliente. Dove reperirlo In genere è memorizzato nella tabella delle posizioni degli ordini di vendita di reso (VBAP), nel campo ABGRU (Motivo del rifiuto dei documenti di vendita). Esempi 001 - Qualità scadente002 - Danneggiato durante il trasporto005 - Articolo spedito errato | |||
| Nome utente UserName | L'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 acquisito nei campi che registrano l'utente che ha creato o modificato un documento. L'analisi per utente aiuta a individuare persone o team con prestazioni elevate, esigenze formative e distribuzione dei carichi di lavoro. È inoltre essenziale per analizzare le deviazioni, poiché collega le azioni di processo a persone specifiche, supportando la conformità e le attività di audit. Perché è importante Attribuisce le attività di processo a utenti specifici e consente di analizzare le prestazioni dei team, i carichi di lavoro e la conformità. Dove reperirlo Si trova comunemente nelle tabelle di intestazione dei documenti, ad esempio in ERNAM (Creato da) nelle tabelle VBAK, per gli ordini di vendita, LIKP, per le consegne, e BKPF, per i documenti contabili. I dati degli utenti possono essere arricchiti tramite la tabella anagrafica utenti USR21. Esempi CBROWNASMITHWF_BATCH | |||
| Ora di fine dell'evento EventEndTime | Il timestamp che indica il completamento di un'attività e viene utilizzato per 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, poiché si tratta di occorrenze istantanee. Tuttavia, per le attività con una durata misurabile, come «Ispezione dell'articolo», questo attributo è fondamentale. Consente di calcolare direttamente il tempo di elaborazione dell'attività. È quindi essenziale per l'analisi delle prestazioni, perché aiuta a individuare quali fasi specifiche, e non soltanto gli intervalli tra una fase e l'altra, richiedono più tempo. Perché è importante Consente di calcolare con precisione la durata delle singole attività, un elemento fondamentale per individuare le inefficienze all'interno di specifiche fasi del processo. Dove reperirlo Spesso è un valore derivato. Per alcune attività può corrispondere a un campo separato; più comunemente, coincide con lo StartTime dell'attività successiva nel caso. Esempi 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Agente responsabile dell'elaborazione ProcessingAgent | L'agente specifico o il gruppo di risorse responsabile della gestione di un'attività manuale. | ||
| Descrizione Questo attributo identifica la persona o il team che ha eseguito una determinata attività. Può essere più specifico del «Nome utente», poiché fa riferimento a un ruolo o a un team, soprattutto in un ambiente di servizi condivisi. È utile per il Dashboard «Efficienza dell'approvazione dei rimborsi», che consente di analizzare le prestazioni di diversi agenti o team. Aiuta a comprendere la distribuzione dei carichi di lavoro, a individuare le esigenze formative e a riconoscere le persone o i team con le prestazioni migliori, che potrebbero condividere best practice. Perché è importante Consente di analizzare le prestazioni a livello di agente o team, aiutando a gestire i carichi di lavoro, individuare opportunità formative e migliorare l'efficienza. Dove reperirlo Queste informazioni potrebbero essere disponibili tramite le funzioni del SAP Business Partner, se agli agenti sono assegnate specifiche funzioni, oppure potrebbero essere derivate dal reparto o dal ruolo dell'utente nella struttura organizzativa HR. Esempi Supporto di livello 1Team di ispezione del magazzinoUfficio Finanza - Contabilità fornitori | |||
| Data obiettivo SLA del rimborso RefundSlaTargetDate | La data entro la quale il rimborso relativo al caso di reso dovrebbe essere elaborato. | ||
| Descrizione Questo attributo definisce la scadenza dello Service Level Agreement (SLA) per l'elaborazione del rimborso. La data viene generalmente calcolata in base a regole aziendali, ad esempio aggiungendo un determinato numero di giorni all'approvazione del reso o alla ricezione della merce. Questo campo costituisce la base del Dashboard «Monitoraggio del rispetto dello SLA dei rimborsi» e del relativo KPI. Consente di monitorare in modo proattivo i casi a rischio di violazione dello SLA e di analizzare le cause principali dei ritardi, contribuendo in ultima analisi a migliorare la soddisfazione del cliente. Perché è importante Fornisce il riferimento per misurare la conformità allo SLA, monitorare le prestazioni, stabilire le priorità dei casi in attesa da più tempo e migliorare la soddisfazione del cliente. Dove reperirlo È 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 viene aggiunta una durata definita dalle regole aziendali, che può dipendere da fattori come il tipo di cliente o il motivo del reso. Esempi 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| È automatizzato IsAutomated | Un indicatore che specifica se un'attività è stata eseguita da un sistema o da una persona. | ||
| Descrizione Questo attributo booleano distingue tra le attività eseguite automaticamente dal sistema, come un Workflow o un job in background, e quelle svolte manualmente da un utente. È essenziale per calcolare il KPI «Tasso di approvazione automatizzata dei rimborsi» e individuare opportunità di incremento dell'automazione. Filtrando le attività manuali, l'azienda può concentrare gli interventi di miglioramento sulle aree in cui l'automazione potrebbe generare i maggiori benefici in termini di velocità, costi e accuratezza. Perché è importante Distingue tra attività manuali e automatizzate, un elemento fondamentale per individuare opportunità di automazione e misurare l'impatto della trasformazione digitale. Dove reperirlo In genere viene derivato in base al 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 | Un indicatore che segnala se un'attività di un caso è la ripetizione di un'attività precedente. | ||
| Descrizione Questo attributo booleano calcolato identifica i casi di rilavorazione, nei quali un'attività viene eseguita più di una volta all'interno dello stesso caso. Ad esempio, quando è necessario ripetere l'ispezione di un articolo oppure quando una nota di credito viene creata, annullata e quindi ricreata. 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 l'inefficienza del processo evidenziando le attività soggette a errori o che richiedono più tentativi, indicando le aree in cui sono necessari controlli o formazione migliori. Perché è importante Evidenzia le inefficienze e gli errori del processo segnalando le attività ripetute, così da consentire interventi mirati per ridurre gli sprechi e i ritardi. Dove reperirlo Questo indicatore viene in genere calcolato direttamente dallo strumento di Process Mining oppure può essere precalcolato 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 | Il risultato dell'ispezione fisica dell'articolo restituito. | ||
| Descrizione Questo attributo registra l'esito del processo di ispezione eseguito dopo la ricezione della merce in magazzino. Gli esiti più comuni includono «Accettato», «Rifiutato, danneggiato» o «Accettato, rivendibile». Questi dati forniscono un contesto essenziale per le fasi successive del processo. Determinano se viene emesso un rimborso completo, parziale o nessun rimborso. L'analisi dell'esito aiuta a individuare le cause dei rifiuti e può fornire indicazioni sul confezionamento dei prodotti o sui partner di spedizione, qualora gli articoli risultino danneggiati frequentemente durante il trasporto. Perché è importante Spiega il processo decisionale alla base dell'approvazione o del rifiuto dei rimborsi e fornisce dati preziosi sulle condizioni degli articoli e sulle cause degli adeguamenti degli importi rimborsati. Dove reperirlo Queste informazioni possono essere registrate in un lotto di ispezione del modulo di gestione della qualità (QM), oppure come stato o codice motivo sulla posizione della consegna di reso (LIPS). Potrebbero inoltre trovarsi in un campo personalizzato. Esempi Accettato - RivendibileAccettato - Da ricondizionareRifiutato - Danno causato dal clienteRifiutato - Articolo restituito errato | |||
| ID della politica sui resi ReturnPolicyId | L'identificativo della politica sui resi applicabile a questo specifico caso di reso. | ||
| Descrizione Questo attributo indica quale specifica politica sui resi o insieme di regole si applica alla transazione. Le politiche possono variare in base al tipo di prodotto, al segmento cliente o al tempo trascorso dall'acquisto. Questi dati sono essenziali per il Dashboard «Panoramica della conformità alle politiche sui resi». Associando ogni caso a una politica, il sistema può verificare automaticamente il rispetto di regole come i termini per la restituzione o i requisiti relativi alle condizioni dell'articolo e segnalare le deviazioni per l'analisi. Perché è importante Consente di verificare automaticamente la conformità alle regole aziendali e aiuta a garantire che i resi vengano elaborati in modo coerente e conforme alla politica applicabile. Dove reperirlo Spesso non è un campo SAP standard e potrebbe dover essere derivato in base alla logica aziendale, utilizzando dati come tipo di prodotto, cliente e data di vendita. Se implementato, potrebbe essere memorizzato in un campo personalizzato. Esempi STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Importo del rimborso richiesto RequestedRefundAmount | L'importo del rimborso richiesto o previsto inizialmente all'avvio del processo. | ||
| Descrizione Questo attributo acquisisce il valore della merce restituita secondo la richiesta di reso iniziale. Costituisce il riferimento rispetto al quale confrontare l'importo finale rimborsato. Questo campo è richiesto specificamente dal Dashboard «Analisi delle discrepanze dell'importo del rimborso». Il confronto tra l'importo richiesto e quello effettivamente rimborsato aiuta a individuare problemi come rimborsi parziali dovuti a danni all'articolo, costi di reintegro o altri adeguamenti, garantendo accuratezza e trasparenza finanziarie. Perché è importante Costituisce il riferimento per misurare l'accuratezza dei rimborsi e aiuta a individuare e analizzare le discrepanze tra i valori previsti e quelli effettivamente rimborsati. Dove reperirlo In genere proviene dal valore netto degli articoli nell'ordine di vendita di reso iniziale. Corrisponde al valore netto (NETWR) delle relative posizioni nella tabella VBAP. Esempi 125.501050.0049.99 | |||
| Numero della consegna di reso ReturnDeliveryNumber | L'identificativo univoco del documento di consegna di reso. | ||
| Descrizione Quando il cliente restituisce fisicamente la merce, in SAP viene creato un documento di consegna di reso per gestire la logistica in entrata. Questo attributo corrisponde al numero univoco di tale documento. Questo ID è importante per monitorare il movimento fisico della merce restituita. Collega gli aspetti finanziari e logistici del reso e consente un'analisi dettagliata delle fasi di ricezione e ispezione della merce. Perché è importante Fornisce un collegamento essenziale tra l'ordine di reso e la ricezione fisica della merce, fondamentale per analizzare i tempi di elaborazione della logistica e del magazzino. Dove reperirlo È il numero del documento di consegna (VBELN) della tabella dell'intestazione della consegna (LIKP), dove la categoria documento indica una consegna di reso. Esempi 840000128400001384000014 | |||
| Numero della nota di credito CreditMemoNumber | L'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 relativo agli articoli restituiti. Questo attributo corrisponde al numero univoco di tale documento finanziario. Il monitoraggio del numero della nota di credito è essenziale per analizzare la fase di regolazione finanziaria del processo di reso. Segna una milestone critica, spesso all'origine dell'effettivo pagamento del rimborso, ed è necessario per la riconciliazione finanziaria e le attività di audit. Perché è importante Rappresenta la transazione finanziaria ufficiale relativa al rimborso ed è fondamentale per monitorare le fasi finali del processo e per l'audit finanziario. Dove reperirlo È il numero del documento di fatturazione (VBELN) della tabella dell'intestazione del documento di fatturazione (VBRK), dove la categoria documento indica una nota di credito. Esempi 900003459000034690000347 | |||
| Organizzazione commerciale SalesOrganization | L'unità organizzativa responsabile della vendita originale e del reso. | ||
| Descrizione L'organizzazione commerciale è un elemento chiave della struttura organizzativa di SAP 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 se alcune organizzazioni commerciali presentano tassi di reso più elevati o processi di gestione dei resi meno efficienti, fornendo una base per l'analisi delle 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 reperirlo Si trova nel campo dell'organizzazione commerciale (VKORG) nella tabella dell'intestazione dell'ordine di reso (VBAK). Esempi 10002100US01 | |||
| Rispetto della policy sui resi ReturnPolicyAdherence | Un indicatore che specifica se il caso di reso è conforme alla politica sui resi definita. | ||
| Descrizione Questo attributo booleano calcolato indica se un reso soddisfa i criteri stabiliti dalla politica sui resi applicabile. La logica può verificare, ad esempio, se il reso è stato avviato entro il termine consentito o se il motivo del reso è valido per il prodotto. Questo attributo supporta direttamente il Dashboard «Panoramica della conformità alle politiche sui resi». Quantifica i tassi di conformità e consente di analizzare in dettaglio i casi non conformi per comprenderne le cause, contribuendo a far rispettare le politiche in modo più efficace. Perché è importante Quantifica la conformità alle regole aziendali e aiuta a individuare e ridurre le violazioni delle politiche che possono incidere sulla redditività o generare eccezioni di processo. Dove reperirlo Calcolato in base alle 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 policy. Esempi truefalse | |||
| Rispetto dello SLA per i rimborsi RefundSlaAdherence | Un indicatore che segnala se il rimborso è stato elaborato entro l'obiettivo dello Service Level Agreement (SLA). | ||
| Descrizione Questo attributo calcolato verifica se l'attività 'Rimborso elaborato' si è verificata entro la 'Data obiettivo SLA del rimborso'. Fornisce un semplice indicatore vero o falso del rispetto dello SLA per ogni caso. È la metrica principale della Dashboard 'Monitoraggio del rispetto dello SLA per i rimborsi' e del KPI 'Tasso di rispetto dello SLA per i rimborsi'. Aiuta a misurare le prestazioni rispetto agli impegni assunti con i clienti e a identificare i casi che non hanno soddisfatto le aspettative, consentendo l'analisi delle cause alla radice dei ritardi. Perché è importante Misura direttamente le prestazioni rispetto agli impegni assunti con i clienti, diventando così un indicatore fondamentale della qualità del servizio e della soddisfazione dei clienti. Dove reperirlo Calcolato confrontando l'EventTime dell'attività 'Rimborso elaborato' con il 'RefundSlaTargetDate' per ogni caso. Esempi truefalse | |||
| Stato dell'ordine di reso ReturnOrderStatus | Lo stato complessivo corrente del caso di reso. | ||
| Descrizione Questo attributo fornisce lo stato generale del caso di reso in un determinato momento, ad esempio «Aperto», «In elaborazione» o «Chiuso». Spesso si tratta di uno stato aggregato, derivato dall'ultima milestone principale completata. È essenziale per il Dashboard «Stato corrente dei casi di reso», che offre una visione operativa del carico di lavoro e della distribuzione dei casi. Aiuta i responsabili a comprendere quanti casi si trovano in ciascuna fase del processo, consentendo una migliore allocazione delle risorse e gestione dei carichi di lavoro. Perché è importante Fornisce una fotografia della posizione di ogni caso nel processo, un elemento essenziale per i Dashboard operativi che monitorano il carico di lavoro e lo stato corrente. Dove reperirlo Deriva dai campi di stato dei documenti pertinenti. Ad esempio, dallo stato dell'intestazione (GBSTK) o delle posizioni (LFSTK) nell'ordine di vendita correlato (VBUK/VBUP) o nei documenti di consegna. Esempi In attesa della ricezione della merceIn attesa di ispezioneIn attesa di rimborsoChiuso | |||
Attività di elaborazione di resi e rimborsi
| Attività | Descrizione | ||
|---|---|---|---|
| Caso di reso chiuso | Questa è l'attività finale e indica che il processo di reso è completato e che per il caso non sono previste ulteriori azioni. In genere l'evento viene dedotto 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 totale di attraversamento end-to-end. Conferma che il caso è stato completamente risolto. Dove reperirlo Deducibile dallo stato complessivo dell'ordine di reso nella tabella VBAK o dallo stato delle relative posizioni in VBAP, quando raggiunge lo stato «Completato» o «Chiuso». La determinazione dipende dalla configurazione della gestione degli stati del sistema. Acquisizione Deducibile dal passaggio dello stato del documento dell'ordine di reso a «Completato». Tipo di evento inferred | |||
| Ispezione dell'articolo completata | Rappresenta il completamento della valutazione della qualità e delle condizioni delle merci restituite. In Advanced Returns Management, spesso si tratta di una fase esplicita che registra l'esito dell'ispezione e determina l'azione successiva, come il rimborso o la rottamazione. | ||
| Perché è importante La durata e l'esito dell'ispezione incidono direttamente sui tempi di gestione dei rimborsi e sulla gestione dell'inventario. Questa attività è fondamentale per analizzare l'efficienza dell'ispezione e le rilavorazioni. Dove reperirlo In SAP Advanced Returns Management (ARM), può trattarsi di un evento esplicito proveniente 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 Viene acquisito dai log delle transazioni o dalle modifiche di stato relative alle attività di follow-up logistico in ARM. Tipo di evento explicit | |||
| Merci ricevute in magazzino | Questo evento segna la ricezione fisica dell'articolo restituito presso il magazzino o il centro di gestione. Viene acquisito esplicitamente quando viene eseguito un Post Goods Receipt (PGR) sulla consegna di reso, con la creazione di un documento materiale. | ||
| Perché è importante Si tratta di una tappa fondamentale, che avvia il conteggio del tempo per l'ispezione e la definizione della destinazione. I ritardi precedenti a questo punto dipendono dal cliente, mentre quelli successivi sono interni. Dove reperirlo Viene acquisito dalle tabelle dei documenti materiali MSEG e MKPF per il tipo di movimento di ricezione merci associato ai resi. La data di registrazione (MKPF-BUDAT) indica il momento dell'evento. Acquisizione L'evento corrisponde alla registrazione di una ricezione merci per la consegna di reso. Tipo di evento explicit | |||
| Nota di credito creata | Indica la creazione del documento di fatturazione ufficiale che accredita sul conto del cliente l'importo relativo all'articolo restituito. Si tratta di un evento esplicito, acquisito quando la nota di credito viene generata a partire dalla richiesta di nota di credito. | ||
| Perché è importante La creazione della nota di credito rappresenta una milestone finanziaria critica. Conferma l'importo da rimborsare e autorizza l'avvio del processo di pagamento. Dove reperirlo Acquisito 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 completata con esito positivo, questa attività indica la creazione di una richiesta di accredito a favore del cliente. L'evento viene registrato come un nuovo documento di vendita, una richiesta di nota di credito che fa riferimento all'ordine di reso originale. | ||
| Perché è importante Questo evento avvia la fase di regolazione finanziaria del processo di reso. Analizzando il tempo trascorso dall'ispezione a questo passaggio è possibile valutare l'efficienza del trasferimento di responsabilità dalla logistica alla finanza. Dove reperirlo Acquisito dalla creazione di un documento di vendita nella tabella VBAK, con una categoria documento corrispondente a una 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 | Questo è il punto di partenza del processo dei resi, in cui nel sistema viene creato formalmente un ordine di reso. L'evento viene acquisito esplicitamente quando in SAP S/4HANA viene salvato un nuovo documento di vendita del 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 complessivo del ciclo dei resi e l'esperienza del cliente. Dove reperirlo Si tratta di un evento esplicito acquisito durante la creazione di un documento di vendita nella tabella VBAK, in cui la categoria del documento (VBAK-VBTYP) indica un ordine di reso. Il timestamp di creazione è 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à indica la fase finale del processo di rimborso, in cui l'accredito finanziario viene compensato, a conferma dell'invio del pagamento al cliente. L'evento è dedotto dalla creazione di un documento di compensazione nel modulo finanziario, che chiude l'accredito aperto sul conto del cliente. | ||
| Perché è importante È il momento in cui il cliente riceve effettivamente il pagamento. Il tempo necessario per raggiungere questo passaggio dall'avvio del reso incide in modo significativo sulla soddisfazione del cliente ed è fondamentale per misurare il rispetto dello SLA. Dove reperirlo Deducibile dalle informazioni sul documento di compensazione nella tabella delle posizioni contabili BSEG. La data di compensazione (BSEG-AUGDT) sulla posizione cliente associata alla nota di credito indica quando il rimborso è stato elaborato. Acquisizione Deducibile dalla compilazione del campo della data di compensazione nel documento contabile associato alla nota di credito. Tipo di evento inferred | |||
| Consegna di reso creata | Questa attività indica la creazione di un documento di consegna in entrata, utilizzato per gestire la ricezione fisica delle merci restituite. Il sistema acquisisce l'evento esplicito di creazione di un documento di consegna che fa riferimento all'ordine di reso. | ||
| Perché è importante Questa fase rappresenta una tappa logistica fondamentale. Il tempo 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 reperirlo Viene acquisito 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 di reso, ad esempio tramite la transazione VL01N. Tipo di evento explicit | |||
| Documento contabile creato | Questo evento si verifica quando la nota di credito viene registrata correttamente nel modulo di contabilità finanziaria. Vengono create le relative registrazioni nella contabilità generale, rendendo ufficiale l'accredito dal punto di vista contabile. | ||
| Perché è importante Questa attività conferma che l'accredito è stato integrato nel sistema finanziario. Il tempo trascorso tra la creazione della nota di credito e la registrazione contabile può evidenziare problemi nell'interfaccia tra fatturazione e finanza. Dove reperirlo Acquisito 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 al completamento della registrazione del documento di fatturazione in Financial Accounting. Tipo di evento explicit | |||
| Ordine di reso approvato | Rappresenta l'approvazione o il rilascio formale dell'ordine di reso, che può così passare alla fase successiva. In genere viene dedotto da una modifica dello stato nell'intestazione o nella posizione del documento di vendita, a indicare che sono stati rimossi eventuali blocchi. | ||
| Perché è importante Le fasi di approvazione possono rappresentare una fonte significativa di ritardi. Monitorare questa attività aiuta a individuare i colli di bottiglia nella fase iniziale di autorizzazione del processo dei resi. Dove reperirlo Viene dedotto 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 di consegna (VBAP-LIFSP) può indicare l'approvazione. Acquisizione Viene dedotto da una modifica nei campi di stato dell'intestazione o della posizione dell'ordine di reso, che 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 acquisito quando viene creato un nuovo ordine di vendita con un riferimento al reso originale. | ||
| Perché è importante Questa attività consente di distinguere i resi con rimborso dai resi con sostituzione, che seguono percorsi di processo diversi e producono risultati differenti per il cliente. È fondamentale per l'analisi delle varianti. Dove reperirlo Acquisito 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 d'ordine di vendita designato come sostituzione. Tipo di evento explicit | |||
| Reso rifiutato | Indica che l'articolo restituito non soddisfa i criteri della politica di reso e che la richiesta di rimborso o accredito è stata respinta. In genere viene acquisito tramite l'applicazione di uno specifico stato o codice causale alla posizione dell'ordine di reso dopo l'ispezione. | ||
| Perché è importante Il monitoraggio dei rifiuti aiuta ad analizzare la conformità alle politiche sui resi e a identificare le cause più frequenti dei dinieghi. Si tratta di un percorso di eccezione fondamentale nel processo. Dove reperirlo Deducibile dall'impostazione di una motivazione di rifiuto (VBAP-ABGRU) sulla posizione dell'ordine di reso o dall'assegnazione di uno stato specifico durante il processo di ispezione in Advanced Returns Management. Acquisizione Deducibile dall'impostazione di una motivazione di rifiuto o di uno specifico stato «rifiutato» sulla 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 CDS View richieste. Tra le viste principali rientrano I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry e I_ClearedItem.
- Accesso allo strumento di query: acceda al client SQL o allo strumento di integrazione dei dati di Sua scelta, con una connessione già configurata al database SAP S/4HANA. Può trattarsi di strumenti SAP, come SAP Analytics Cloud, oppure di una piattaforma ETL di terze parti.
- Impostazione dei parametri della query: prima dell'esecuzione, modifichi la query SQL fornita. Individui i valori segnaposto e li sostituisca con i parametri corretti per il Suo ambiente. È necessario impostare
[Data di inizio],[Data di fine],[ID del sistema di origine],[Tipo di ordine di reso]e gli altri filtri relativi al tipo di documento o al codice azienda. - Esecuzione della query di estrazione: copi la query SQL completa ed esegua la query nello strumento. La query è progettata per raccogliere tutte le attività specificate in un unico dataset, unendo i risultati di più istruzioni select.
- Comprensione della logica della query: ogni blocco
SELECTnella strutturaUNION ALLè responsabile dell'estrazione di una specifica attività. Unisce più CDS View per raccogliere gli Attributi necessari, assegna una stringa fissa comeActivityNamee seleziona il timestamp pertinente perEventTime. - Revisione dei dati grezzi: al termine della query, esegua una breve revisione dell'output. Verifichi che il numero di righe sia ragionevole e che le colonne chiave, come
ReturnCaseId,ActivityNameedEventTime, siano valorizzate come previsto. - Trasformazione dei dati: la query è strutturata per produrre un Event Log piatto. In genere non sono necessarie trasformazioni strutturali significative. Tuttavia, potrebbe 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 il risultato della query come file CSV. Verifichi che il file utilizzi la codifica UTF-8 per evitare problemi con i caratteri, soprattutto nei nomi utente o nelle descrizioni dei prodotti.
- Caricamento nello strumento di Process Mining: il file CSV risultante è ora pronto per essere caricato nella piattaforma di Process Mining, come ProcessMind. Mappi le colonne del file nei campi corrispondenti dello strumento, ad esempio
ReturnCaseIdin Case ID,ActivityNamein Activity edEventTimein Timestamp.
Configurazione
- Prerequisiti: l'utente che esegue l'operazione deve disporre delle autorizzazioni di visualizzazione per gli oggetti relativi a documenti di vendita (VBAK), consegne (LIKP), fatturazione (VBRK) e contabilità (BSEG, BKPF). L'accesso alle CDS View sottostanti è essenziale.
- Filtri dell'ambito dei dati: è fondamentale filtrare la query per tipi di documento specifici, così da isolare il processo dei resi. Configuri i segnaposto per i tipi di ordine di reso, ad esempio 'RE', per i tipi di richiesta di nota di credito, ad esempio 'G2', e per i tipi di ordine di sostituzione, ad esempio 'SO'. È inoltre fortemente consigliato filtrare per
CompanyCodeoSalesOrganizationper limitare l'ambito dei dati. - Filtro dell'intervallo di date: per gestire le prestazioni e il volume dei dati, applichi sempre un filtro sull'intervallo di date. Inizi con un periodo recente di 3-6 mesi. La query utilizza la data di creazione dell'ordine di reso iniziale (
I_SalesDocument.CreationDate) come condizione di filtro principale. - Considerazioni sulle prestazioni: si tratta di una query completa che unisce più CDS View di grandi dimensioni. L'esecuzione può richiedere molte risorse nel sistema S/4HANA di origine. Pianifichi l'estrazione negli orari di minore attività per ridurre al minimo l'impatto. Per dataset molto grandi, valuti strategie di caricamento incrementale.
a 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 di vendite, consegne, fatturazione, documenti materiali, ispezioni, stati e contabilità. Lo schema, le viste e i nomi dei campi esatti variano in base alla distribuzione SAP S/4HANA; sostituisca quindi ogni segnaposto tra parentesi quadre con gli oggetti e i campi configurati nel Suo sistema.
- Definisca l'ambito dell'estrazione utilizzando [Data di inizio], [Data di fine], [Filtro codice azienda] e [Filtro tipo di documento di reso]. Per l'estrazione iniziale utilizzi un periodo mobile di tre-sei mesi e lo estenda solo dopo aver convalidato prestazioni e completezza.
- Identifichi la popolazione degli ordini di reso da [Tabella di testata dei documenti di vendita] e [Tabella delle posizioni dei documenti di vendita]. Limiti la popolazione ai tipi di documento degli ordini di reso configurati in [Configurazione del tipo di documento degli ordini di reso]. Mantenga il numero dell'ordine di reso e il numero della posizione come collegamento principale ai documenti successivi.
- Risolva 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 utilizzando [Tabella o vista del flusso documentale]. 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 espliciti di creazione dai record pertinenti di testata e posizione dei documenti. Estragga gli eventi di approvazione, rifiuto, ispezione, chiusura, ricezione merci, contabilizzazione e compensazione dalle fonti configurate relative a stati, ispezioni, documenti materiali, contabilità e compensazione. Ogni attività deve essere emessa come riga di evento separata, poiché ProcessMind non deduce gli eventi.
- Normalizzi i timestamp in un tipo di timestamp e in un fuso orario coerenti a livello di database. Utilizzi la precedenza dei timestamp degli eventi configurata per ogni attività. Se sono disponibili solo data e ora, le combini utilizzando il fuso orario di sistema configurato in [Fuso orario del sistema].
- Valorizzi 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 separata. Gli eventi che non possono essere collegati a un caso di reso devono essere esclusi oppure inseriti in un output delle eccezioni per la correzione.
- Valorizzi le colonne obbligatorie ReturnCaseId, ActivityName, EventTime, SourceSystemId e LastDataUpdateTimestamp. Valorizzi, quando disponibili, 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 il risultato utilizzando i controlli indicati in validationSteps. Verifichi che siano presenti tutti i dodici nomi delle attività, che i timestamp siano plausibilmente ordinati all'interno di ogni caso e che i riferimenti ai documenti siano riconciliati con le tabelle di origine.
- Esporti il risultato come CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Mantenga i nomi esatti 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 tre-sei mesi. Utilizzi i parametri [Data di inizio] e [Data di fine] e includa una cronologia sufficiente a catturare i casi avviati prima del periodo selezionato ma completati al suo interno.
- Popolazione dei resi: filtri in base ai tipi di documento degli ordini di reso configurati in [Configurazione del tipo di documento degli ordini di reso]. Non codifichi direttamente un tipo di documento, a meno che non sia stato verificato nel sistema di destinazione.
- Filtri organizzativi: applichi [Filtro codice azienda], organizzazione commerciale, canale di distribuzione, divisione, stabilimento o filtri cliente solo quando necessario. Verifichi che i filtri non escludano i documenti successivi interaziendali o tra società.
- Oggetti di origine: sostituisca i segnaposto [Nome della tabella] e [Nome della vista] con tabelle SAP S/4HANA o CDS View approvate. VBAK, VBAP, VBRK e VBRP potrebbero essere disponibili nella distribuzione, ma il loro utilizzo e le relative estensioni devono essere verificati prima dell'esecuzione.
- 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 ProcessMind concordato.
- 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 [Identificativo del sistema di origine] con un valore stabile, come l'identificativo del sistema SAP utilizzato dalla piattaforma di estrazione.
- Timestamp di aggiornamento: sostituisca [Timestamp di estrazione] con il timestamp di avvio dell'esecuzione della query o di creazione dello snapshot di origine. Utilizzi lo stesso valore per tutte le righe di una singola esecuzione, salvo che siano necessari timestamp di aggiornamento a livello di riga.
- Prestazioni: limiti la popolazione iniziale dei resi prima di eseguire join con fonti di grandi dimensioni relative a flusso documentale, contabilità, documenti materiali e stati. Utilizzi campi indicizzati o che consentano il partizionamento, eviti scansioni senza restrizioni e materializzi risultati intermedi solo previa approvazione dell'amministratore del database.
- Estrazione incrementale: per le esecuzioni ricorrenti, utilizzi [Timestamp dell'ultima estrazione completata] e una finestra di sovrapposizione controllata per acquisire gli aggiornamenti tardivi. Elimini i duplicati utilizzando ReturnCaseId, ActivityName, la chiave del documento di origine ed EventTime.
- Autorizzazioni e prerequisiti: ottenga l'autorizzazione in 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 e le funzioni Advanced Returns Management richiesti siano attivi, ove applicabile.
- Protezione dei dati: limiti i campi relativi ai clienti e alle informazioni finanziarie al minimo necessario, segua i controlli organizzativi sulla privacy e protegga i file esportati.
a 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 all'elaborazione di resi e rimborsi. Inizi oggi il Suo percorso verso l'eccellenza dei processi.
Ottimizzi ora l'elaborazione di resi e rimborsi in SAP S/4HANA
Identifichi le inefficienze, riduca del 30% il tempo di ciclo e aumenti la soddisfazione.
Non è richiesta alcuna carta di credito. Inizi oggi a ottimizzare i processi.