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 per la gestione di resi e rimborsi
| Nome | Descrizione | ||
|---|---|---|---|
| ID del caso di reso ReturnCaseId | Identificativo univoco della richiesta di reso di un cliente, che collega tutte le attività e i documenti correlati. | ||
| Descrizione L’ID del caso di reso è la chiave primaria per monitorare l’intero ciclo di vita del processo, dall’avvio alla chiusura. Ogni ID corrisponde a uno specifico reso del cliente e comprende tutti gli eventi associati, come la creazione dell’ordine, la consegna, l’ispezione e l’elaborazione della nota di credito. Nell’analisi dei processi, questo attributo è fondamentale per costruire la mappa del processo. Consente al sistema di raggruppare i singoli eventi in percorsi end-to-end del caso e di analizzare le varianti del processo, i tempi di ciclo e i colli di bottiglia per ogni singolo reso. Perché è importante È l’identificativo essenziale del caso che collega tutte le fasi del percorso di reso e permette di analizzare il flusso e le prestazioni del processo end-to-end. Dove reperirli In genere è il numero dell’ordine di reso del modulo Sales and Distribution (SD). Si trova nel campo VBELN della tabella VBAK (Sales Document Header Data), dove la categoria del documento (VBAK-VBTYP) è 'H' per i resi. Esempi 600001236000045660000789 | |||
| Nome dell’attività ActivityName | Nome di uno specifico evento o passaggio aziendale che si è verificato nel processo di reso. | ||
| Descrizione Questo attributo descrive una singola azione o modifica di stato nel ciclo di vita del reso, come 'Ordine di reso creato', 'Entrata merci contabilizzata' o 'Nota di credito creata'. Queste attività costituiscono gli elementi fondamentali della mappa del processo. Analizzare la sequenza e la frequenza delle attività aiuta a individuare i percorsi più comuni, le deviazioni e i cicli di rilavorazione. È fondamentale per capire cosa accade in un caso e in quale ordine, e costituisce la base di ogni analisi di Process Mining. Perché è importante Le attività definiscono le fasi del processo. Analizzarne la sequenza, la durata e la frequenza è il fulcro del Process Mining e mostra come viene svolto il lavoro nella pratica. Dove reperirli Ricavato dalle modifiche di stato in tabelle come VBUK/VBUP, dagli eventi di creazione dei documenti (ad esempio in VBAK, LIKP, VBRK) o dai registri delle modifiche nelle tabelle CDHDR/CDPOS. Esempi Ordine di reso creatoEntrata merci registrataNota di credito creataPosizione dell’ordine di reso completata | |||
| Ora dell’evento EventTime | Data e ora esatte in cui si è verificata l’attività. | ||
| Descrizione Questo timestamp indica il momento preciso in cui si è verificato un evento aziendale. Viene registrato per ogni attività del processo e fornisce la sequenza cronologica degli eventi all’interno di un caso. L’ora dell’evento è essenziale per tutte le analisi basate sul tempo, tra cui il calcolo dei tempi di ciclo tra le attività, l’individuazione dei colli di bottiglia in cui si accumulano le attese e la misurazione della durata complessiva del caso. Consente di analizzare le prestazioni e verificare il rispetto degli accordi sul livello di servizio (SLA). Perché è importante Questo timestamp è indispensabile per calcolare le durate, analizzare le prestazioni del processo, individuare i colli di bottiglia e ricostruire la cronologia di ogni caso di reso. Dove reperirli Ricavato da vari campi di data e ora delle tabelle SAP. Per gli eventi di creazione si utilizzano spesso i campi ERDAT ed ERZET (ad esempio in VBAK). Per gli eventi di modifica si usano UDATE e UTIME nella tabella CDHDR. Esempi 2023-04-15T10:22:05Z2023-04-16T14:01:30Z2023-04-18T09:15:00Z | |||
| Sistema di origine SourceSystem | Il sistema da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo identifica l’origine dei dati, un’informazione essenziale negli ambienti con più sistemi. Fornisce il contesto e aiuta a garantire la tracciabilità e l’integrità dei dati. Nell’analisi, viene utilizzato per segmentare o filtrare i dati quando si combinano processi provenienti da sistemi di origine diversi. Conferma che gli eventi provengono dall’applicazione prevista, in questo caso SAP ECC. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la governance dei dati e per le analisi che coinvolgono più sistemi aziendali. Dove reperirli È un valore statico definito durante l’estrazione dei dati per identificare la specifica istanza SAP ECC (ad esempio, 'ECC_PROD_100'). Esempi SAP_ECC_PRODSAPECC_FINANCE_200 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Timestamp che indica quando sono stati aggiornati l’ultima volta i dati di questo processo. | ||
| Descrizione Questo attributo registra la data e l’ora dell’estrazione o dell’aggiornamento più recente. Indica quanto sono aggiornati i dati analizzati. Nell’analisi, è importante per valutare l’attualità delle informazioni. Gli utenti possono verificare quanto siano recenti i dati, un aspetto che incide sulla rilevanza dei risultati, soprattutto nel monitoraggio delle attività in corso. Perché è importante Indica quanto sono aggiornati i dati, aiutando gli utenti a capire a quale momento si riferisce l’analisi del processo e quando è previsto il prossimo aggiornamento. Dove reperirli È un attributo di metadati valorizzato con il timestamp di esecuzione del processo di estrazione dei dati. Esempi 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| Canale di reso ReturnChannel | Canale attraverso cui è stato avviato il reso, ad esempio online, in negozio o tramite call center. | ||
| Descrizione Questo attributo specifica l’origine o la modalità di ricezione della richiesta di reso. Permette di distinguere le richieste avviate tramite un portale web, in un negozio fisico o con l’assistenza di un operatore del servizio clienti. Segmentare il processo per canale di reso è fondamentale per comprendere le differenze operative e distribuire le risorse. Ad esempio, i resi in negozio potrebbero richiedere meno tempo per l’ispezione, ma prevedere passaggi documentali diversi rispetto ai resi online. È una dimensione importante per la Dashboard 'Andamento dei volumi nel processo di reso'. Perché è importante Distingue le modalità di avvio dei resi, che spesso incidono sul flusso del processo, sulle risorse necessarie e sui tempi di ciclo dei diversi canali. Dove reperirli Spesso non è un campo standard in SAP ECC e potrebbe essere necessario ricavarlo da un campo personalizzato (ad esempio in VBAK) o dedurlo da altri dati, come l’organizzazione commerciale (VKORG) o il canale di distribuzione (VTWEG). Per i dettagli sull’implementazione, consultare la documentazione di SAP ECC. Esempi Portale onlineIn negozioCall center | |||
| Importo del rimborso richiesto RequestedRefundAmount | Importo previsto del rimborso, in genere calcolato sul valore netto degli articoli restituiti. | ||
| Descrizione Questo attributo rappresenta l’importo iniziale del reso, registrato nell’ordine di reso. Costituisce la base per l’analisi e la riconciliazione finanziaria. L’importo viene confrontato con l’'Importo effettivo del rimborso' per individuare eventuali differenze, una metrica importante per la Dashboard 'Monitoraggio delle differenze negli importi dei rimborsi'. Analizzarlo aiuta a monitorare l’impatto finanziario dei resi e a individuare possibili problemi di prezzo o di calcolo degli accrediti. Perché è importante Definisce il valore finanziario iniziale del reso, fondamentale per monitorare le differenze contabili e comprendere il valore complessivo della merce restituita. Dove reperirli In genere corrisponde al valore netto della posizione dell’ordine di reso. Si trova nel campo NETWR della tabella VBAP. Esempi 150.0049.991250.75 | |||
| Importo effettivo del rimborso ActualRefundAmount | Importo finale accreditato al cliente, come registrato nei documenti finanziari. | ||
| Descrizione Questo attributo indica l’importo finale del rimborso, confermato, elaborato e registrato nel sistema contabile. Può differire dall’importo richiesto a causa di spese di reintegro a magazzino, rettifiche basate sulle condizioni dell’articolo o altre disposizioni delle politiche aziendali. È un attributo fondamentale per la Dashboard 'Monitoraggio delle differenze negli importi dei rimborsi'. Il confronto con l’importo richiesto aiuta a individuare problemi sistematici nel calcolo e nell’approvazione dei rimborsi, garantendo la correttezza finanziaria. Perché è importante Rappresenta l’esito finanziario finale del reso. Confrontarlo con l’importo richiesto aiuta a verificare la correttezza dei dati e a individuare eventuali perdite finanziarie. Dove reperirli Ricavato dal documento finanziario associato alla nota di credito. In genere si trova nel campo WRBTR (importo nella valuta del documento) della tabella BSEG (Accounting Document Segment), per la relativa registrazione nel conto Co.Ge. Esempi 150.0045.001200.75 | |||
| Motivo del reso ReturnReason | Codice del motivo indicato dal cliente per la restituzione dell’articolo. | ||
| Descrizione Questo attributo indica il motivo del reso del prodotto tramite i codici predefiniti in SAP. Alcuni esempi sono 'Danneggiato durante il trasporto', 'Articolo errato spedito' o 'Taglia non adatta'. È una dimensione fondamentale per l’analisi delle cause profonde. Filtrando la mappa del processo o i KPI per motivo del reso, gli analisti possono verificare se determinati motivi sono associati a tempi di elaborazione più lunghi, a un maggior numero di ispezioni non superate o a specifiche deviazioni del processo. Queste informazioni possono guidare interventi sulla qualità dei prodotti, sulla logistica o sui processi di vendita. Perché è importante Spiega perché vengono effettuati i resi e consente di analizzarne le cause profonde per ridurne il numero intervenendo sulla qualità dei prodotti, sulle spedizioni o sulle descrizioni. Dove reperirli Si trova nel campo ABGRU della tabella VBAP, relativa alle posizioni dei documenti di vendita (motivo del rifiuto dei documenti di vendita). Esempi 001 - Prodotto danneggiato002 - Prodotto errato005 - Arrivato troppo tardi | |||
| Numero materiale MaterialNumber | Identificativo univoco del prodotto restituito. | ||
| Descrizione Il numero materiale, o SKU, identifica con precisione l’articolo oggetto del reso e consente un’analisi dettagliata a livello di prodotto. Analizzando i resi per numero materiale, le aziende possono individuare i prodotti con un tasso di reso elevato, che potrebbe indicare problemi di qualità, descrizioni inesatte o difetti di fabbricazione. È essenziale per Dashboard come 'Impatto dei resi sull’inventario' e per capire come i diversi prodotti attraversano il processo di reso. Perché è importante Identifica i prodotti restituiti e mette in evidenza possibili problemi di controllo della qualità o descrizioni inesatte. Dove reperirli Si trova nel campo MATNR della tabella VBAP, relativa alle posizioni dei documenti di vendita. Esempi RM-1025FG-2050-BACC-5591 | |||
| Operatore di elaborazione ProcessingAgent | ID utente del dipendente che ha svolto l’attività. | ||
| Descrizione Questo attributo registra il nome utente della persona responsabile di una specifica fase del processo, ad esempio la creazione dell’ordine di reso o la registrazione dell’entrata merci. Spesso corrisponde all’utente indicato come 'Modificato da' o 'Creato da'. Analizzare i dati per operatore di elaborazione è importante per gestire le prestazioni e analizzare le risorse. Aiuta a individuare chi ottiene i risultati migliori, chi potrebbe aver bisogno di ulteriore formazione e come viene distribuito il carico di lavoro nel team. Viene utilizzato in Dashboard come 'Prestazioni degli operatori nell’elaborazione dei resi' per confrontare i tempi di ciclo e i volumi elaborati. Perché è importante Tiene traccia del coinvolgimento degli utenti e consente di analizzare le prestazioni del team, la distribuzione del carico di lavoro e le esigenze di formazione, oltre a individuare le buone pratiche. Dove reperirli Si trova in genere in campi come ERNAM (Creato da) o AENAM (Modificato da) nelle tabelle di intestazione, ad esempio VBAK, LIKP e VBRK. Per gli eventi di modifica, il campo è USERNAME nella tabella CDHDR. Esempi CBURNSDSCRANTONJHALPERT | |||
| Data obiettivo SLA del rimborso RefundSLATargetDate | Data entro cui si prevede di elaborare il rimborso, secondo gli accordi sul livello di servizio. | ||
| Descrizione Questo attributo definisce la scadenza entro cui completare il processo di rimborso per un determinato caso di reso. In genere viene calcolato in base a regole aziendali, ad esempio '5 giorni lavorativi dalla ricezione della merce'. La data obiettivo è il valore di riferimento per misurare le prestazioni effettive. È l’elemento centrale della Dashboard 'Conformità SLA nell’elaborazione dei rimborsi', che consente all’azienda di monitorare il rispetto degli impegni presi con i clienti e individuare i casi a rischio di mancato rispetto dello SLA. Perché è importante Definisce l’obiettivo per l’elaborazione dei rimborsi e consente all’azienda di misurare e rendicontare il rispetto degli SLA, dando priorità ai casi in ritardo. Dove reperirli In genere non è un campo standard di SAP e deve essere ricavato applicando le regole aziendali. Può essere calcolato aggiungendo una durata configurata a una data di riferimento, ad esempio la data di entrata merci in MKPF. Consultare la documentazione di SAP ECC o i requisiti aziendali. Esempi 2023-04-25T23:59:59Z2023-04-28T23:59:59Z2023-05-02T23:59:59Z | |||
| Differenza nell’importo del rimborso RefundAmountDiscrepancy | Differenza calcolata tra l’importo effettivo e quello richiesto per il rimborso. | ||
| Descrizione Questa metrica calcolata quantifica la differenza tra l’importo inizialmente richiesto nell’ordine di reso e quello infine emesso nella nota di credito. Un valore positivo può indicare un rimborso parziale; un valore negativo è insolito, ma potrebbe segnalare un pagamento in eccesso. Questo attributo è la misura principale della Dashboard 'Monitoraggio delle differenze negli importi dei rimborsi'. Aiuta a individuare e analizzare rapidamente i casi con scostamenti finanziari, che potrebbero dipendere dalla valutazione delle condizioni dell’articolo, da spese di reintegro a magazzino o da errori. Monitorarlo contribuisce a garantire il controllo finanziario e il rispetto delle politiche aziendali. Perché è importante Misura direttamente gli scostamenti finanziari nel processo di rimborso e aiuta a individuare il mancato rispetto delle politiche, gli errori di elaborazione o le perdite finanziarie. Dove reperirli Campo calcolato: ActualRefundAmount - RequestedRefundAmount. Esempi 0.00-4.99-50.00 | |||
| Documento di vendita originale OriginalSalesDocument | Numero dell’ordine di vendita originale a cui si riferisce il reso. | ||
| Descrizione Questo attributo rimanda direttamente all’acquisto iniziale del cliente. È un documento di riferimento che collega il reso ai dettagli della transazione originale. Questo collegamento è molto utile per approfondire l’analisi. Consente agli analisti di verificare perché vengono restituiti gli articoli di determinati ordini, controllare prezzi e condizioni originali e ricostruire l’intero ciclo di vita dell’ordine del cliente, dall’acquisto al reso. Aiuta anche a capire se i prodotti venduti tramite specifiche campagne o canali presentano tassi di reso più elevati. Perché è importante Collega il reso alla vendita originale e offre una visione completa della transazione con il cliente, utile per approfondire l’analisi delle cause profonde. Dove reperirli Questo riferimento è memorizzato a livello di posizione dell’ordine di reso. Si trova nel campo VGBEL della tabella VBAP (numero del documento di riferimento). Esempi 100034561000987110012345 | |||
| ID cliente CustomerId | Identificativo univoco del cliente che avvia il reso. | ||
| Descrizione Questo attributo identifica il cliente specifico che restituisce il prodotto, indicato in SAP come 'Sold-to Party'. Collega la transazione di reso ai dati anagrafici del cliente. Analizzare i dati per ID cliente aiuta a individuare chi effettua resi frequenti, un possibile segnale di insoddisfazione o di uso improprio delle politiche di reso. Incrociando questo dato con la segmentazione dei clienti, è inoltre possibile capire se determinati gruppi adottano comportamenti diversi o vivono esperienze differenti durante il processo di reso. Perché è importante Collega i resi ai singoli clienti e consente di analizzarne i comportamenti, individuare chi effettua resi ripetuti e valutare l’impatto sulle relazioni con i clienti. Dove reperirli Si trova nel campo KUNNR (Sold-to party) della tabella VBAK, relativa alle intestazioni dei documenti di vendita. Esempi CUST-100432CUST-203991CUST-831102 | |||
| Numero della nota di credito CreditMemoNumber | Identificativo univoco del documento di nota di credito emesso per il rimborso. | ||
| Descrizione La nota di credito è il documento di fatturazione ufficiale in SAP che formalizza il rimborso da corrispondere al cliente. Il suo numero identifica in modo univoco il documento finanziario. Questo attributo è essenziale per la riconciliazione finanziaria e per monitorare il processo dal reso operativo alla liquidazione finanziaria. Segna una tappa importante del processo e consente di individuare i documenti contabili correlati ad attributi come 'Importo effettivo del rimborso'. Perché è importante Collega direttamente al documento finanziario che autorizza il rimborso al cliente, un riferimento essenziale per gli audit finanziari e la riconciliazione. Dove reperirli La nota di credito è un documento di fatturazione. Il relativo numero si trova nel campo VBELN della tabella VBRK (Billing Document: Header Data). Il collegamento si ricava dal flusso documentale dell’ordine di reso. Esempi 900011229000334490005566 | |||
| Rispetto della politica di reso ReturnPolicyAdherence | Indicatore che segnala se il reso rispetta tutte le regole e le politiche aziendali definite. | ||
| Descrizione Questo attributo booleano calcolato indica se il caso di reso ha seguito le politiche aziendali standard. La logica può prevedere la verifica di più condizioni, ad esempio se il reso è stato avviato entro i termini consentiti, se il codice del motivo è valido per il prodotto o se è stata ottenuta l’approvazione di un responsabile per un’eccezione. Questo attributo alimenta la Dashboard 'Conformità alle politiche di approvazione dei resi'. Consente di misurare direttamente il tasso di conformità e aiuta a individuare le politiche aggirate più spesso, così da pianificare interventi mirati di miglioramento del processo o di formazione. Perché è importante Misura il rispetto delle regole aziendali, aiutando ad applicare le politiche in modo coerente e a individuare i casi che richiedono una revisione o un’approvazione specifica. Dove reperirli È un attributo derivato da un insieme di regole aziendali. Ad esempio: (Data di avvio del reso - Data di acquisto originale) <= 30 giorni AND ReturnReason IS NOT NULL. Esempi truefalse | |||
| Rispetto dello SLA IsSLACompliant | Indicatore che segnala se il rimborso è stato elaborato entro i termini concordati nell’accordo sul livello di servizio (SLA). | ||
| Descrizione È un attributo booleano calcolato confrontando la data effettiva dell’attività 'Rimborso elaborato' con la 'Data obiettivo SLA del rimborso'. Il valore è true se il rimborso è stato completato entro i termini e false in caso contrario. Questo attributo semplifica l’analisi e la rendicontazione, fornendo un esito chiaro e binario per il rispetto dello SLA in ogni caso. Viene utilizzato per calcolare il tasso complessivo di 'Conformità SLA nell’elaborazione dei rimborsi' e permette di filtrare facilmente i casi non conformi per analizzarli. Perché è importante Fornisce un indicatore chiaro e binario delle prestazioni SLA per ogni caso, semplificando il monitoraggio della conformità e la rendicontazione. Dove reperirli È un attributo calcolato. La logica è: 'Rimborso elaborato' EventTime <= RefundSLATargetDate. Esempi truefalse | |||
| Società CompanyCode | Entità giuridica o società responsabile della transazione. | ||
| Descrizione In SAP, la società rappresenta un’unità contabile autonoma. Tutte le transazioni finanziarie, compresi i resi e i rimborsi, vengono registrate in una specifica società. Questo attributo è essenziale per la rendicontazione finanziaria e per segmentare il processo nelle organizzazioni multinazionali o con più entità. Analizzare i dati per società consente di confrontare le prestazioni del processo di reso tra le diverse entità giuridiche dell’azienda. Perché è importante Consente di filtrare e confrontare i processi di reso tra le diverse entità giuridiche di un’organizzazione, un aspetto fondamentale per l’analisi finanziaria. Dove reperirli Si trova nel campo BUKRS_VF (società per la fatturazione) della tabella VBAK, relativa alle intestazioni dei documenti di vendita. Esempi 10002000US01 | |||
| Stabilimento Plant | Luogo o struttura fisica in cui l’articolo restituito viene ricevuto ed elaborato. | ||
| Descrizione In SAP, lo stabilimento rappresenta un luogo fisico, come un magazzino o un centro di distribuzione, in cui vengono gestite le merci. Per i resi, di solito è il luogo in cui l’articolo viene ricevuto e ispezionato. Analizzare il processo per stabilimento aiuta a individuare differenze nelle prestazioni delle varie strutture. Può mettere in evidenza i magazzini più efficienti nell’ispezione degli articoli o con i volumi di elaborazione più elevati, fornendo indicazioni utili per la Dashboard 'Volumi ed efficienza delle ispezioni degli articoli'. Perché è importante Identifica il luogo fisico in cui viene elaborato il reso e consente di confrontare le prestazioni dei diversi magazzini o centri di distribuzione. Dove reperirli Si trova a livello di posizione dell’ordine di reso, nel campo WERKS della tabella VBAP. Esempi PL01WH02DC05 | |||
| Stato dell’ordine di reso ReturnOrderStatus | Stato complessivo di elaborazione del caso relativo all’ordine di reso. | ||
| Descrizione Questo attributo fornisce un quadro dello stato attuale del caso di reso, ad esempio 'Aperto', 'In elaborazione' o 'Completato'. Deriva dalla combinazione degli stati a livello di intestazione o di posizione del documento di vendita. Nell’analisi, è utile per filtrare i casi e concentrarsi sui resi attivi o completati. Aiuta a monitorare il carico di lavoro complessivo e l’avanzamento dei casi aperti e fornisce una panoramica dell’esito di ogni percorso di reso. Perché è importante Fornisce una visione d’insieme della fase del ciclo di vita in cui si trova un caso e consente di filtrare e analizzare i resi aperti, in corso o chiusi. Dove reperirli Ricavato dai campi di stato delle tabelle VBUK (stato dell’intestazione) e VBUP (stato della posizione). Ad esempio, VBUK-GBSTK indica lo stato complessivo di elaborazione del documento. Esempi ApertoIn elaborazioneCompletato | |||
Attività di gestione di resi e rimborsi
| Attività | Descrizione | ||
|---|---|---|---|
| Decisione d’uso presa | Dopo l’ispezione, un ingegnere della qualità o un ispettore prende una decisione formale sulle condizioni dell’articolo reso. La decisione determina la fase successiva, ad esempio il reinserimento in inventario, la rottamazione o la riparazione. | ||
| Perché è importante Questa attività è fondamentale per comprendere l’efficienza delle ispezioni e i relativi esiti. La decisione incide direttamente sull’importo del rimborso e sulla gestione dell’inventario. Dove reperirli Se viene utilizzato SAP QM, si tratta di un evento esplicito registrato nella tabella QAVE (decisione d’uso durante l’elaborazione dell’ispezione). La data della decisione è memorizzata in QAVE-VDATUM. Il collegamento alla consegna si trova nella tabella QALS. Acquisizione Utilizzi la data della decisione d’uso (VDATUM) della tabella QAVE, collegata tramite il lotto di ispezione (QALS-PRUEFLOS). Tipo di evento explicit | |||
| Entrata merci registrata | Questa attività si verifica quando l’articolo reso viene ricevuto fisicamente in magazzino o presso il centro di elaborazione. Viene registrata quando si contabilizza un documento di movimento merci relativo alla consegna di reso. | ||
| Perché è importante È una tappa fondamentale, che indica che l’azienda ha preso in carico l’articolo reso. Segna l’inizio dell’ispezione fisica e incide sulla precisione dell’inventario. Dove reperirli L’evento può essere dedotto dallo stato del movimento merci della posizione della consegna di reso nella tabella VBUP (ad esempio, WBSTA = 'C'). La data e l’ora esatte sono riportate nella testata del documento materiale (MKPF-BUDAT) corrispondente all’entrata merci. Acquisizione Individui la data di registrazione (BUDAT) nella tabella MKPF per il documento materiale collegato alla consegna di reso. Tipo di evento inferred | |||
| Nota di credito contabilizzata in FI | La nota di credito viene trasferita alla contabilità finanziaria e diventa una registrazione ufficiale dei crediti verso clienti. Questo passaggio avvia l’effettivo processo di rimborso al cliente. | ||
| Perché è importante Questa attività segna il momento in cui l’azienda riconosce contabilmente il rimborso. Eventuali ritardi tra la creazione e la contabilizzazione della nota di credito possono rallentare l’effettivo rimborso al cliente. Dove reperirli È un evento dedotto, rilevato quando lo stato di contabilizzazione nell’intestazione del documento di fatturazione (VBRK-RFBSK) viene aggiornato a 'C' (documento di contabilizzazione creato). La data di creazione effettiva del documento contabile è registrata nella tabella BKPF. Acquisizione Individuare il timestamp in cui VBRK-RFBSK viene impostato su 'C' oppure utilizzare la data di creazione (CPUDT) del documento contabile BKPF collegato. Tipo di evento inferred | |||
| Nota di credito creata | Viene generato un documento di fatturazione (nota di credito) per autorizzare l’accredito al cliente. È il documento finanziario ufficiale che formalizza l’importo del rimborso. | ||
| Perché è importante Si tratta di una tappa finanziaria importante del processo. Analizzare il tempo necessario per creare la nota di credito aiuta a individuare i ritardi nell’elaborazione dei documenti finanziari dopo la ricezione e l’ispezione della merce. Dove reperirli È un evento esplicito registrato nella tabella VBRK (Billing Document Header). La data di creazione è VBRK-ERDAT. Nel flusso documentale, la nota di credito è collegata all’ordine di reso o alla richiesta di nota di credito. Acquisizione Utilizzare il timestamp di creazione (ERDAT) dalla tabella VBRK per il documento di fatturazione pertinente. Tipo di evento explicit | |||
| Ordine di reso completato | Questa attività segna la conclusione del processo di reso dal punto di vista delle vendite e della distribuzione. Si verifica quando tutte le posizioni dell’ordine di reso sono state elaborate e chiuse. | ||
| Perché è importante È l’evento finale principale del processo. Misurando il tempo che intercorre tra 'Ordine di reso creato' e questa attività si ottiene il tempo di ciclo end-to-end del caso di reso. Dove reperirli È un evento dedotto dalle tabelle degli stati. Viene rilevato quando lo stato complessivo dell’intestazione del documento di vendita (VBUK-GBSTK) viene aggiornato a 'C' (elaborazione completata). Acquisizione Individuare nei documenti di modifica (CDHDR/CDPOS) il timestamp in cui il campo di stato dell’intestazione VBUK-GBSTK passa a 'C'. Tipo di evento inferred | |||
| Ordine di reso creato | Questa attività segna l’avvio del processo di reso, quando un cliente chiede di restituire un prodotto. Viene registrata quando in SAP ECC viene creato un nuovo documento di vendita di tipo «Reso» (ad esempio RE). | ||
| Perché è importante Questo è l’evento di inizio principale del processo di gestione dei resi. Analizzare il tempo che intercorre tra questa attività e le successive consente di misurare il tempo di ciclo totale e individuare i ritardi iniziali nell’elaborazione. Dove reperirli È un evento esplicito registrato nella tabella VBAK (testata del documento di vendita). La data e l’ora di creazione sono memorizzate nei campi VBAK-ERDAT e VBAK-ERZET per il numero del documento di vendita corrispondente (VBAK-VBELN), con tipo di ordine VBAK-AUART = 'RE'. Acquisizione Utilizzi la data e l’ora di creazione (ERDAT, ERZET) della tabella VBAK per i documenti di vendita di tipo 'RE'. Tipo di evento explicit | |||
| Blocco dell’ordine di reso rimosso | Indica l’approvazione della richiesta di reso, che può così passare alla fase successiva. In genere viene rilevata quando cambia lo stato del documento o viene rimosso un blocco di consegna o fatturazione. | ||
| Perché è importante Questa attività segna una tappa fondamentale nell’approvazione. Misurare il tempo necessario per raggiungerla aiuta a individuare i colli di bottiglia nel processo di autorizzazione e approvazione dei resi. Dove reperirli È un evento dedotto dai registri delle modifiche del documento di vendita. Verifichi le tabelle CDHDR e CDPOS per individuare le modifiche ai campi di blocco in VBAK o VBAP oppure ai campi di stato in VBUK/VBUP. Acquisizione Individui nelle tabelle dei documenti di modifica (CDHDR/CDPOS) la data e l’ora in cui viene rimosso uno stato di blocco pertinente. Tipo di evento inferred | |||
| Consegna di reso creata | Viene generato un documento di consegna per gestire la ricezione fisica della merce resa. Questo evento indica l’avvio del processo logistico del reso. | ||
| Perché è importante Segna il passaggio dall’elaborazione amministrativa alla gestione logistica fisica. Eventuali ritardi in questa fase possono incidere sulla pianificazione del magazzino e sul tempo di ciclo complessivo del reso. Dove reperirli È un evento esplicito registrato nella tabella LIKP (testata della consegna). La data di creazione è memorizzata in LIKP-ERDAT. Il collegamento all’ordine di reso di origine si trova nella tabella LIPS (LIPS-VGBEL). Acquisizione Utilizzi la data di creazione (ERDAT) della tabella LIKP per la consegna associata all’ordine di reso. Tipo di evento explicit | |||
| Nota di credito compensata | La partita aperta della nota di credito nei crediti verso clienti viene compensata, in genere tramite un pagamento in uscita al cliente. Questo evento segna la chiusura finanziaria definitiva del rimborso. | ||
| Perché è importante Questa attività conferma l’uscita di cassa e completa la parte finanziaria del processo. Dal punto di vista del cliente, segna la vera conclusione del percorso di rimborso. Dove reperirli È un evento esplicito del modulo FI. La data di compensazione del documento contabile è memorizzata nella tabella BSEG (BSEG-AUGDT) per la relativa posizione cliente. Acquisizione Utilizzare la data di compensazione (AUGDT) dalla tabella BSEG o BSAD per il documento contabile collegato alla nota di credito. Tipo di evento explicit | |||
| Posizione dell’ordine di reso completata | Una singola posizione dell’ordine di reso viene contrassegnata come completamente elaborata. In genere, ciò avviene dopo il completamento di tutti i documenti logistici e finanziari successivi relativi a quella posizione. | ||
| Perché è importante Il monitoraggio a livello di posizione aiuta a individuare i prodotti o i motivi di reso che causano i ritardi più lunghi. Offre una visione più dettagliata del completamento del processo. Dove reperirli È un evento dedotto dalle tabelle degli stati. Viene rilevato quando lo stato complessivo della posizione del documento di vendita (VBUP-GBSTK) viene aggiornato a 'C' (elaborazione completata). Acquisizione Individuare nei documenti di modifica (CDHDR/CDPOS) il timestamp in cui il campo di stato della posizione VBUP-GBSTK passa a 'C'. Tipo di evento inferred | |||
| Posizione dell’ordine di reso rifiutata | Una specifica posizione dell’ordine di reso viene rifiutata durante la revisione iniziale o dopo l’ispezione. Per quella posizione non verranno quindi effettuate ulteriori elaborazioni, come il rimborso. | ||
| Perché è importante Analizzare i rifiuti aiuta a individuare le richieste di reso non valide e a definire come comunicare le politiche ai clienti. È un percorso importante del processo che non porta a un rimborso. Dove reperirli È un evento dedotto. In genere viene rilevato quando alla posizione viene assegnato un codice univoco di 'Motivo del rifiuto' nella tabella VBAP (VBAP-ABGRU). Il timestamp deve essere ricavato dai registri delle modifiche. Acquisizione Individuare nei documenti di modifica (CDHDR/CDPOS) il timestamp in cui il campo VBAP-ABGRU viene compilato per una posizione di reso. Tipo di evento inferred | |||
| Richiesta di nota di credito creata | La richiesta di nota di credito viene creata per documentare formalmente la necessità di un rimborso. In molte configurazioni, l’ordine di reso stesso funge da richiesta di nota di credito. | ||
| Perché è importante Segna l’avvio formale della fase di liquidazione finanziaria del processo di gestione dei resi. Avvia le successive approvazioni finanziarie e la creazione dei documenti. Dove reperirli Può trattarsi di un evento esplicito nella tabella VBAK per un documento di vendita di tipo «Richiesta di nota di credito» (ad esempio CR), oppure può coincidere con l’evento «Ordine di reso creato» se il tipo di ordine è configurato per la fatturazione basata sull’ordine. Acquisizione Utilizzi la data e l’ora di creazione (ERDAT) della tabella VBAK per i documenti di tipo 'CR' oppure riutilizzi l’evento di creazione dell’ordine di reso. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
- Creare un programma ABAP: Utilizzi il codice transazione
SE38per creare un nuovo programma ABAP eseguibile, ad esempioZ_PM_RETURN_EXTRACTION. Assegni un titolo descrittivo e lo salvi come oggetto locale o all’interno di un pacchetto di sviluppo. - Definire la schermata di selezione: Nel programma, definisca una schermata di selezione che consenta agli utenti di filtrare i dati. I filtri principali includono l’intervallo di date di creazione degli ordini di reso (
S_ERDAT), il tipo di documento di vendita per i resi (S_AUART, ad esempio 'RE') e il codice società (P_BUKRS). - Definire le strutture dei dati: Crei un tipo di struttura locale conforme al formato richiesto per l’Event Log. La struttura deve includere i campi
ReturnCaseId,ActivityName,EventTime,SourceSystem,LastDataUpdate,ProcessingAgent,ReturnReasone gli altri attributi necessari. - Implementare la logica di selezione dei dati: Scriva la logica ABAP principale per selezionare i dati relativi a ciascuna delle 12 attività richieste. A tal fine, interroghi diverse tabelle SAP, tra cui VBAK, VBAP, LIKP, VBRK, BKPF, CDHDR e CDPOS. Utilizzi la tabella del flusso documentale (VBFA) per collegare i documenti correlati, come le consegne e le note di credito, all’ordine di reso originale.
- Estrarre 'Return Order Created': Selezioni i record dalle tabelle
VBAKeVBAPin base ai criteri della schermata di selezione. Il numero del documento di vendita (VBAK-VBELN) fungerà daReturnCaseId. - Estrarre le modifiche di stato e gli eventi principali: Per attività come 'Return Order Block Removed' o 'Return Order Item Rejected', interroghi le tabelle dei documenti di modifica (
CDHDR,CDPOS) o i campi di stato in tabelle comeVBAP(ABGRU). Per le attività logistiche e finanziarie successive, selezioni i dati da tabelle comeLIKP,MKPF,VBRKeBKPF, utilizzandoVBFAper verificare che siano collegate all’insieme iniziale di ordini di reso. - Popolare la tabella dell’Event Log: Per ogni attività recuperata, crei un nuovo record in una tabella interna definita con la struttura dell’Event Log. Mappi i dati delle tabelle SAP di origine nei campi corrispondenti, ad esempio associando
VBAK-ERNAMaProcessingAgenteVBAK-ERDATeVBAK-ERZETaEventTime. - Unire i dati delle attività: Verifichi che l’istruzione SELECT di ogni attività aggiunga i risultati alla stessa tabella interna principale. Si otterrà così un file semplice in cui ogni riga rappresenta un evento.
- Gestire le date e le informazioni di sistema: Utilizzi i campi di sistema
SY-DATUMeSY-UZEITper valorizzare la data e l’ora diLastDataUpdatein ogni riga. UtilizziSY-SYSIDper valorizzareSourceSystem. - Implementare la funzione di output: Aggiunga la possibilità di visualizzare i risultati in una griglia ALV (SAP List Viewer) per l’analisi online, utilizzando moduli funzione come
REUSE_ALV_GRID_DISPLAY. Preveda un’opzione per scaricare la tabella interna finale sul computer locale dell’utente come file CSV o di testo semplice. - Eseguire ed esportare: Esegua il programma tramite
SE38. Inserisca i criteri di selezione desiderati e avvii l’esecuzione. Una volta visualizzati o elaborati i dati, utilizzi la funzione di esportazione del programma per salvare il file dell’Event Log. Verifichi che il formato sia compatibile con ProcessMind, in genere CSV con una riga di intestazione.
Configurazione
- Intervallo di date: Nella schermata di selezione, specifichi un intervallo di date per la creazione degli ordini di reso. Per l’analisi iniziale si consiglia un periodo da 3 a 6 mesi, così da bilanciare il volume dei dati e la quantità di informazioni sul processo.
- Tipo di documento di reso: Filtri i dati in base al tipo di documento di vendita utilizzato nel sistema per i resi, ad esempio 'RE' per i resi o 'CR' per le richieste di nota di credito. È un filtro fondamentale per isolare il processo corretto. Inserisca questi valori nell’opzione di selezione
S_AUART. - Codice società: Specifichi il codice società pertinente (
P_BUKRS) per limitare i dati a una specifica entità giuridica. È essenziale negli ambienti con più società. - Prerequisiti: L’utente che esegue il programma deve disporre delle autorizzazioni per
SE38(esecuzione del programma) e dell’accesso alle tabelle sottostanti dei moduli SD, MM e FI (ad esempio VBAK, LIKP, VBRK, BKPF, CDHDR). Per lo sviluppo è necessario un ruolo di sviluppatore ABAP. - Prestazioni: Con insiemi di dati molto ampi, relativi a più anni, il programma potrebbe richiedere tempi di esecuzione lunghi. Valuti l’esecuzione come processo in background (
SM36) e il salvataggio dell’output nel file system del server applicativo anziché la visualizzazione online.
Query di esempio abap
REPORT Z_PM_RETURN_EXTRACTION.
" =======================================================================
" DATA DECLARATIONS
" =======================================================================
TYPES: BEGIN OF ty_event_log,
returncaseid TYPE vbeln_va,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE sysysid,
lastdataupdate TYPE timestamp,
processingagent TYPE ernam,
returnreason TYPE augru,
materialnumber TYPE matnr,
returnchannel TYPE string, " Placeholder, needs custom logic
requestedrefundamount TYPE netwr,
actualrefundamount TYPE netwr,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lv_timestamp TYPE timestamp,
lv_last_update TYPE timestamp.
" =======================================================================
" SELECTION SCREEN
" =======================================================================
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY,
s_auart FOR vbak-auart.
PARAMETERS: p_bukrs TYPE bukrs OBLIGATORY.
" =======================================================================
" MAIN LOGIC
" =======================================================================
START-OF-SELECTION.
" Set static values for the extraction run
GET TIME STAMP FIELD lv_last_update.
" 1. Return Order Created & 6. Credit Memo Request Created
" Note: In many SAP standard processes, the Return Order itself acts as the Credit Memo Request.
SELECT h~vbeln, h~erdat, h~erzet, h~ernam, h~augru, i~matnr, i~netwr
INTO TABLE @DATA(lt_return_orders)
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN @s_erdat
AND h~auart IN @s_auart
AND h~bukrs_vf = @p_bukrs.
LOOP AT lt_return_orders INTO DATA(ls_return_order).
" Activity: Return Order Created
ls_event_log-returncaseid = ls_return_order-vbeln.
ls_event_log-activityname = 'Return Order Created'.
CONVERT DATE ls_return_order-erdat TIME ls_return_order-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_return_order-ernam.
ls_event_log-returnreason = ls_return_order-augru.
ls_event_log-materialnumber = ls_return_order-matnr.
ls_event_log-requestedrefundamount = ls_return_order-netwr.
APPEND ls_event_log TO lt_event_log.
" Activity: Credit Memo Request Created
ls_event_log-activityname = 'Credit Memo Request Created'.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
IF lt_return_orders IS NOT INITIAL.
" 2. Return Order Block Removed (Example for Delivery Block)
SELECT objectid, udate, utime, username
FROM cdhdr
INTO TABLE @DATA(lt_block_changes)
FOR ALL ENTRIES IN @lt_return_orders
WHERE objectclas = 'VERKBELEG'
AND objectid = @lt_return_orders-vbeln
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT objectid, fname, value_new
INTO TABLE @DATA(lt_cdpos_block)
FROM cdpos
FOR ALL ENTRIES IN @lt_block_changes
WHERE objectclas = @lt_block_changes-objectclas
AND objectid = @lt_block_changes-objectid
AND changenr = @lt_block_changes-changenr
AND tabname = 'VBAK'
AND fname = 'LIFSK' " Delivery Block field
AND value_new = ''.
LOOP AT lt_cdpos_block INTO DATA(ls_cdpos_block).
READ TABLE lt_block_changes INTO DATA(ls_block_change) WITH KEY objectid = ls_cdpos_block-objectid.
IF sy-subrc = 0.
ls_event_log-returncaseid = ls_cdpos_block-objectid.
ls_event_log-activityname = 'Return Order Block Removed'.
CONVERT DATE ls_block_change-udate TIME ls_block_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_block_change-username.
CLEAR: ls_event_log-returnreason, ls_event_log-materialnumber, ls_event_log-requestedrefundamount, ls_event_log-actualrefundamount.
APPEND ls_event_log TO lt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" Get subsequent documents from flow
SELECT vbelv, vbtyp_n, vbeln, rfbsk
INTO TABLE @DATA(lt_doc_flow)
FROM vbfa
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbelv = @lt_return_orders-vbeln
AND vbtyp_n IN ('J', 'R', 'M'). " J=Delivery, R=Goods Mvmt, M=Invoice
" 3. Return Delivery Created
SELECT vbeln, erdat, erzet, ernam FROM likp
INTO TABLE @DATA(lt_deliveries)
FOR ALL ENTRIES IN @lt_doc_flow
WHERE vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'J'.
LOOP AT lt_deliveries INTO DATA(ls_delivery).
READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_del) WITH KEY vbeln = ls_delivery-vbeln.
ls_event_log-returncaseid = ls_doc_flow_del-vbelv.
ls_event_log-activityname = 'Return Delivery Created'.
CONVERT DATE ls_delivery-erdat TIME ls_delivery-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_delivery-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 4. Goods Receipt Posted
SELECT mblnr, mjahr, budat, cputm, usnam FROM mkpf
INTO TABLE @DATA(lt_goods_receipt)
FOR ALL ENTRIES IN @lt_doc_flow
WHERE xblnr = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'R'.
LOOP AT lt_goods_receipt INTO DATA(ls_goods_receipt).
READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_gr) WITH KEY vbeln = ls_goods_receipt-mblnr.
ls_event_log-returncaseid = ls_doc_flow_gr-vbelv.
ls_event_log-activityname = 'Goods Receipt Posted'.
CONVERT DATE ls_goods_receipt-budat TIME ls_goods_receipt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_goods_receipt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 5. Usage Decision Made (Requires QM Module implementation)
SELECT q~prueflos, q~vdatu, q~vzeit, q~vname
FROM qals AS q
INNER JOIN qave AS v ON q~prueflos = v~prueflos
INTO TABLE @DATA(lt_usage_decisions)
FOR ALL ENTRIES IN @lt_deliveries
WHERE q~kdauf = @lt_deliveries-vbeln.
LOOP AT lt_usage_decisions INTO DATA(ls_ud).
SELECT SINGLE vbelv FROM vbfa INTO @DATA(lv_vbelv_ud) WHERE vbeln = @ls_ud-prueflos.
ls_event_log-returncaseid = lv_vbelv_ud.
ls_event_log-activityname = 'Usage Decision Made'.
CONVERT DATE ls_ud-vdatu TIME ls_ud-vzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_ud-vname.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 7. Credit Memo Created
SELECT h~vbeln, h~erdat, h~erzet, h~ernam, i~netwr, i~vgbel
INTO TABLE @DATA(lt_cred_memos)
FROM vbrk AS h
INNER JOIN vbrp AS i ON h~vbeln = i~vbeln
FOR ALL ENTRIES IN @lt_doc_flow
WHERE h~vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'M'.
LOOP AT lt_cred_memos INTO DATA(ls_cred_memo).
ls_event_log-returncaseid = ls_cred_memo-vgbel.
ls_event_log-activityname = 'Credit Memo Created'.
CONVERT DATE ls_cred_memo-erdat TIME ls_cred_memo-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_cred_memo-ernam.
ls_event_log-actualrefundamount = ls_cred_memo-netwr.
APPEND ls_event_log TO lt_event_log.
" 8. Credit Memo Posted To FI
SELECT SINGLE budat, cputime, usnam FROM bkpf
INTO @DATA(ls_bkpf_post)
WHERE awkey = @ls_cred_memo-vbeln AND awtyp = 'VBRK'.
IF sy-subrc = 0.
ls_event_log-activityname = 'Credit Memo Posted To FI'.
CONVERT DATE ls_bkpf_post-budat TIME ls_bkpf_post-cputime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-processingagent = ls_bkpf_post-usnam.
APPEND ls_event_log TO lt_event_log.
ENDIF.
" 12. Credit Memo Cleared
SELECT SINGLE augdt FROM bseg
INTO @DATA(lv_augdt)
WHERE bukrs = @p_bukrs
AND belnr = @ls_cred_memo-vbeln
AND augdt IS NOT NULL.
IF sy-subrc = 0 AND lv_augdt IS NOT INITIAL.
ls_event_log-activityname = 'Credit Memo Cleared'.
CONVERT DATE lv_augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
CLEAR: ls_event_log-processingagent.
APPEND ls_event_log TO lt_event_log.
ENDIF.
ENDLOOP.
" 9. Return Order Item Completed
SELECT vbeln, erdat, erzet, ernam, abgru FROM vbap
INTO TABLE @DATA(lt_items_completed)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND gbsta = 'C'.
LOOP AT lt_items_completed INTO DATA(ls_item_completed).
ls_event_log-returncaseid = ls_item_completed-vbeln.
ls_event_log-activityname = 'Return Order Item Completed'.
CONVERT DATE ls_item_completed-erdat TIME ls_item_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_item_completed-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 10. Return Order Completed
SELECT vbeln, erdat, erzet, ernam FROM vbak
INTO TABLE @DATA(lt_orders_completed)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND gbsta = 'C'.
LOOP AT lt_orders_completed INTO DATA(ls_order_completed).
ls_event_log-returncaseid = ls_order_completed-vbeln.
ls_event_log-activityname = 'Return Order Completed'.
CONVERT DATE ls_order_completed-erdat TIME ls_order_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_order_completed-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 11. Return Order Item Rejected
SELECT vbeln, erdat, erzet, ernam FROM vbap
INTO TABLE @DATA(lt_items_rejected)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND abgru IS NOT NULL AND abgru <> ''.
LOOP AT lt_items_rejected INTO DATA(ls_item_rejected).
ls_event_log-returncaseid = ls_item_rejected-vbeln.
ls_event_log-activityname = 'Return Order Item Rejected'.
CONVERT DATE ls_item_rejected-erdat TIME ls_item_rejected-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_item_rejected-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
ENDIF.
" =======================================================================
" OUTPUT
" =======================================================================
cl_salv_table=>factory(
IMPORTING
r_salv_table = DATA(lo_alv)
CHANGING
t_table = lt_event_log ).
lo_alv->display( ).Passaggi
- Prerequisiti: Verifichi che l’utente del database disponga dell’accesso in lettura alle tabelle SAP ECC necessarie. Sono incluse le tabelle dei moduli Sales and Distribution (SD), Materials Management (MM) e Financial Accounting (FI). Per connettersi al database, occorre un client SQL adeguato, come DBeaver, SAP HANA Studio o Oracle SQL Developer.
- Identificare le specificità del sistema: Prima di eseguire la query, individui i tipi di documento specifici utilizzati dall’organizzazione per i resi. La query contiene il segnaposto
[YOUR_RETURN_ORDER_TYPES], da sostituire con i valori effettivi, ad esempio 'RE' per i resi standard. - Preparare la query: Copi nel client SQL la query completa fornita nella sezione 'query'.
- Configurare i parametri: Individui all’inizio della query l’espressione di tabella comune (CTE) denominata
BaseReturnOrders. Modifichi la clausolaWHEREper specificare l’intervallo di date desiderato, sostituendo[START_DATE]e[END_DATE]. Aggiorni l’elenco dei tipi di ordine di reso e, se necessario, applichi un filtro per uno specifico codice società (BUKRS_VF). - Eseguire la query: Esegua la query modificata sul database SAP ECC. Il tempo di esecuzione può variare in base all’intervallo di date selezionato e alle dimensioni del database.
- Rivedere i dati grezzi: Al termine della query, controlli rapidamente l’output. Verifichi che le colonne
ReturnCaseId,ActivityNameeEventTimesiano valorizzate e che siano presenti dati per più attività. - Esportare in CSV: Esporti l’intero risultato dal client SQL in un file CSV. Utilizzi la codifica UTF-8 per preservare correttamente tutti i caratteri.
- Preparare il caricamento: Apra il file CSV e verifichi che le intestazioni delle colonne corrispondano esattamente agli attributi richiesti:
ReturnCaseId,ActivityName,EventTime,SourceSysteme così via. Corregga le intestazioni se il client SQL le ha modificate durante l’esportazione. - Caricamento finale: Carichi il file CSV verificato sulla piattaforma ProcessMind per l’analisi.
Configurazione
- Tipi di documento di reso: La query deve essere configurata con i tipi di documento di vendita specifici che identificano gli ordini di reso nel sistema SAP. A tal fine, sostituisca il segnaposto
[YOUR_RETURN_ORDER_TYPES]. Tra gli esempi più comuni figurano 'RE' e i tipi personalizzati che iniziano con 'Z'. - Intervallo di date: È fondamentale definire un intervallo di date adeguato per l’estrazione. Per un’analisi iniziale si consiglia in genere un periodo da 3 a 6 mesi. Imposti l’intervallo utilizzando i segnaposto
[START_DATE]e[END_DATE]nel formato 'YYYYMMDD'. - Codice società: Nelle organizzazioni con più codici società, filtrare i dati è essenziale per circoscrivere l’analisi. Può aggiungere un filtro come
VBAK.BUKRS_VF = '[YOUR_COMPANY_CODE]'nella CTE iniziale per limitare l’ambito. - Dialetto del database: La query fornita utilizza funzioni SQL comuni. Tuttavia, le conversioni di data e ora, come
TO_TIMESTAMP, e la concatenazione di stringhe (CONCAT) potrebbero richiedere lievi modifiche alla sintassi in base al sistema di database sottostante, ad esempio Oracle, HANA o DB2. - Autorizzazioni necessarie: L’utente del database deve disporre dell’accesso in lettura alle seguenti tabelle principali: VBAK, VBAP, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG, BKPF, BSAD, QALS, QAVE, CDHDR e CDPOS.
Query di esempio sql
WITH BaseReturnOrders AS (
SELECT
VBAK.VBELN AS ReturnOrderNumber,
VBAP.POSNR AS ReturnOrderItemNumber
FROM VBAK
JOIN VBAP ON VBAK.VBELN = VBAP.VBELN
WHERE VBAK.AUART IN ('[YOUR_RETURN_ORDER_TYPES]') -- e.g., 'RE'
AND VBAK.ERDAT BETWEEN '[START_DATE]' AND '[END_DATE]' -- e.g., '20230101' and '20231231'
)
-- 1. Return Order Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(VBAK.ERDAT, VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
VBAK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
UNION ALL
-- 2. Return Order Block Removed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Block Removed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBAK'
AND CDPOS.FNAME IN ('LIFSK', 'FAKSK')
AND CDPOS.VALUE_NEW = ''
AND CDPOS.VALUE_OLD <> ''
UNION ALL
-- 3. Return Delivery Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(LIKP.ERDAT, LIKP.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
LIKP.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIKP ON VBFA.VBELN = LIKP.VBELN
UNION ALL
-- 4. Goods Receipt Posted
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Goods Receipt Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(MKPF.CPUDT, MKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
MKPF.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIPS ON VBFA.VBELN = LIPS.VBELN AND VBFA.POSNN = LIPS.POSNR
JOIN MSEG ON LIPS.VBELN = MSEG.LFBNR AND LIPS.POSNR = MSEG.LFPOS
JOIN MKPF ON MSEG.MBLNR = MKPF.MBLNR AND MSEG.MJAHR = MKPF.MJAHR
WHERE MSEG.BWART IN ('651', '653', '655') -- Standard returns movement types
UNION ALL
-- 5. Usage Decision Made
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Usage Decision Made' AS "ActivityName",
TO_TIMESTAMP(CONCAT(QAVE.ADAT, QAVE.ATIM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
QAVE.AENAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN QALS ON VBFA.VBELN = QALS.VBELN AND VBFA.POSNN = QALS.POSNR -- Linking inspection lot to delivery item
JOIN QAVE ON QALS.PRUEFLOS = QAVE.PRUEFLOS
UNION ALL
-- 6. Credit Memo Request Created (assumes a separate doc, or can be the return order itself)
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CMR_VBAK.ERDAT, CMR_VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CMR_VBAK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'K' -- 'K' is Credit Memo Request
JOIN VBAK AS CMR_VBAK ON VBFA.VBELN = CMR_VBAK.VBELN
UNION ALL
-- 7. Credit Memo Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(VBRK.ERDAT, VBRK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
VBRK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
WHERE VBRK.FKART IN ('[YOUR_CREDIT_MEMO_TYPES]') -- e.g., 'G2'
UNION ALL
-- 8. Credit Memo Posted To FI
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Posted To FI' AS "ActivityName",
TO_TIMESTAMP(CONCAT(BKPF.CPUDT, BKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
BKPF.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BKPF ON VBRK.VBELN = BKPF.AWKEY AND BKPF.AWTYP = 'VBRK'
UNION ALL
-- 9. Return Order Item Completed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Item Completed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBUP'
AND CDPOS.FNAME = 'GBSTA'
AND CDPOS.VALUE_NEW = 'C'
UNION ALL
-- 10. Return Order Completed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Completed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBUK'
AND CDPOS.FNAME = 'GBSTK'
AND CDPOS.VALUE_NEW = 'C'
UNION ALL
-- 11. Return Order Item Rejected
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Item Rejected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
CDPOS.VALUE_NEW AS "ReturnReason", -- Using rejection reason for this specific event
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBAP'
AND CDPOS.FNAME = 'ABGRU'
AND CDPOS.VALUE_NEW <> ''
UNION ALL
-- 12. Credit Memo Cleared
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Cleared' AS "ActivityName",
TO_TIMESTAMP(BSAD.AUGDT, 'YYYYMMDD') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CLEAR_DOC.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BSAD ON VBRK.VBELN = BSAD.VBELN
JOIN BKPF AS CLEAR_DOC ON BSAD.AUGBL = CLEAR_DOC.BELNR AND BSAD.BUKRS = CLEAR_DOC.BUKRS AND BSAD.GJAHR_AUGL = CLEAR_DOC.GJAHR;È pronto a iniziare?
Utilizzi subito questo template per semplificare la raccolta dei dati e ottenere informazioni utili sul processo di gestione di resi e rimborsi.
Ottimizzi subito la gestione di resi e rimborsi
Semplifichi la gestione dei resi in SAP ECC e riduca del 30% il tempo di ciclo. Inizi oggi.
Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.