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à chiave da monitorare
- Indicazioni per l’estrazione
Attributi dell’elaborazione di resi e rimborsi
| Nome | Descrizione | ||
|---|---|---|---|
| ID del caso di reso ReturnCaseId | L’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 funge da chiave primaria per monitorare l’intero ciclo di vita di un processo di reso, dall’avvio alla chiusura. Ogni ID corrisponde a uno specifico reso 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 di processo. Consente al sistema di raggruppare i singoli eventi in percorsi end-to-end dei casi, permettendo di analizzare varianti di processo, tempi di ciclo e colli di bottiglia per ogni singolo reso. Perché è importante È l’identificativo essenziale del caso che collega tutte le fasi del percorso di un reso, rendendo possibile analizzare il flusso e le performance del processo end-to-end. Dove reperirlo In genere corrisponde al numero dell’ordine di reso del modulo Sales and Distribution (SD). Si trova nella tabella VBAK (dati della testata del documento di vendita), nel campo VBELN, dove la categoria del documento (VBAK-VBTYP) è «H» per i resi. Esempi 600001236000045660000789 | |||
| Nome dell’attività ActivityName | Il nome di uno specifico evento o passaggio aziendale verificatosi nel processo di gestione dei resi. | ||
| Descrizione Questo Attributo descrive una singola azione distinta o una modifica di stato nel ciclo di vita del reso, come «Return Order Created», «Goods Receipt Posted» o «Credit Memo Created». Queste attività costituiscono gli elementi fondamentali della mappa di processo. Analizzare la sequenza e la frequenza di queste attività aiuta a individuare i percorsi di processo più comuni, le deviazioni e i cicli di rilavorazione. È essenziale per comprendere cosa accade all’interno di un caso e in quale ordine, costituendo la base di ogni analisi di Process Mining. Perché è importante Le attività definiscono le fasi del processo. Analizzarne sequenza, durata e frequenza è il cuore del Process Mining e rivela come viene svolto realmente il lavoro. Dove reperirlo Derivato dalle modifiche di stato in tabelle come VBUK/VBUP, dagli eventi di creazione dei documenti, ad esempio in VBAK, LIKP e VBRK, o dai log 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 | La data e l’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 è fondamentale per tutte le analisi basate sul tempo, inclusi il calcolo dei tempi di ciclo tra le attività, l’identificazione dei colli di bottiglia in cui si accumulano le attese e la misurazione della durata complessiva del caso. Consente di analizzare le performance e verificare la conformità rispetto agli accordi sui livelli di servizio (SLA). Perché è importante Questo timestamp è essenziale per calcolare tutte le durate, analizzare le performance del processo, individuare i colli di bottiglia e comprendere la sequenza temporale di ogni caso di reso. Dove reperirlo Proviene da diversi campi di data e ora nelle tabelle SAP. Per gli eventi di creazione, si tratta spesso dei campi ERDAT ed ERZET, ad esempio in VBAK. Per gli eventi di modifica, sono 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 dal quale 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 contribuisce 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 diversi sistemi di origine. Conferma che gli eventi provengono dall’applicazione prevista, in questo caso SAP ECC. Perché è importante Identifica l’origine dei dati, un elemento fondamentale per la governance dei dati e per le analisi che coinvolgono più sistemi aziendali. Dove reperirlo È 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 | Il timestamp che indica quando i dati relativi a questo processo sono stati aggiornati l’ultima volta. | ||
| Descrizione Questo Attributo registra la data e l’ora dell’estrazione o dell’aggiornamento dei dati più recente. Fornisce trasparenza sul livello di aggiornamento dei dati analizzati. Nell’analisi è importante per comprendere la tempestività degli insight. Gli utenti possono verificare quanto siano aggiornati i dati, un elemento che incide sulla rilevanza dei risultati, soprattutto nel monitoraggio delle attività in corso. Perché è importante Indica l’aggiornamento dei dati, aiutando gli utenti a comprendere quanto sia attuale l’analisi del processo e quando sia previsto il prossimo aggiornamento. Dove reperirlo È un Attributo di metadati valorizzato con il timestamp di esecuzione del job di estrazione dei dati. Esempi 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| Agente di elaborazione ProcessingAgent | L’ID utente del dipendente che ha eseguito l’attività. | ||
| Descrizione Questo Attributo acquisisce il nome utente della persona responsabile dell’esecuzione di una specifica fase del processo, come la creazione dell’ordine di reso o la registrazione dell’entrata merci. Viene spesso indicato come utente «Changed By» o «Created By». Analizzare i dati per agente di elaborazione è fondamentale per la gestione delle performance e l’analisi delle risorse. Aiuta a individuare gli agenti con le performance migliori, quelli che potrebbero necessitare di ulteriore formazione e la distribuzione del carico di lavoro all’interno del team. Viene utilizzato in Dashboard come «Agent Return Processing Performance» per confrontare tempi di ciclo e produttività. Perché è importante Tiene traccia del coinvolgimento degli utenti, consentendo di analizzare le performance del team, distribuire il carico di lavoro e individuare esigenze formative o best practice. Dove reperirlo Si trova generalmente in campi come ERNAM (Created by) o AENAM (Changed by) nelle tabelle di testata, come VBAK, LIKP e VBRK. Per gli eventi di modifica, corrisponde a USERNAME nella tabella CDHDR. Esempi CBURNSDSCRANTONJHALPERT | |||
| Canale di reso ReturnChannel | Il canale attraverso il quale è stato avviato il reso, ad esempio online, in negozio o tramite call center. | ||
| Descrizione Questo attributo specifica l’origine o il metodo di acquisizione della richiesta di reso. Consente di distinguere tra resi avviati tramite un portale web, un punto vendita fisico o un operatore del servizio clienti. Segmentare il processo per Canale di reso è fondamentale per comprendere le differenze operative e allocare le risorse in modo adeguato. Ad esempio, i resi in negozio potrebbero prevedere tempi di ispezione più brevi, ma fasi di documentazione diverse rispetto ai resi online. Si tratta di una dimensione chiave per il Dashboard «Returns Process Throughput Trends». Perché è importante Distingue le modalità di avvio dei resi, che spesso incidono sul flusso di processo, sul fabbisogno di risorse e sui tempi di ciclo dei diversi canali. Dove reperirlo Spesso non è un campo standard in SAP ECC e potrebbe dover essere ricavato da un campo personalizzato, ad esempio in VBAK, oppure dedotto da altri dati, come l’Organizzazione commerciale (VKORG) o il Canale di distribuzione (VTWEG). Consulti la documentazione SAP ECC per l’implementazione specifica. Esempi Portale onlineIn negozioCall center | |||
| Importo del rimborso richiesto RequestedRefundAmount | Il valore previsto del rimborso, generalmente basato sul valore netto degli articoli restituiti. | ||
| Descrizione Questo attributo rappresenta il valore monetario iniziale del reso, registrato nell’ordine di reso. Costituisce la base per l’analisi finanziaria e la riconciliazione. L’importo viene confrontato con l’«Actual Refund Amount» per monitorare le discrepanze, una metrica chiave per il Dashboard «Refund Amount Discrepancy Tracking». L’analisi di questo valore aiuta a monitorare l’impatto finanziario dei resi e a identificare potenziali problemi di determinazione dei prezzi o di calcolo del credito. Perché è importante Stabilisce il valore finanziario iniziale del reso, fondamentale per monitorare le discrepanze finanziarie e comprendere il valore complessivo delle merci restituite. Dove reperirlo Questo valore corrisponde generalmente al valore netto a livello di riga dell’ordine di reso. Si trova nella tabella VBAP, campo NETWR. Esempi 150.0049.991250.75 | |||
| Importo effettivo del rimborso ActualRefundAmount | L’importo finale accreditato al cliente, come registrato nei documenti finanziari. | ||
| Descrizione Questo attributo rappresenta il valore finale e confermato del rimborso, elaborato e registrato nel sistema contabile. L’importo può differire da quello richiesto a causa di costi di ricondizionamento, rettifiche basate sulle condizioni dell’articolo o dell’applicazione di altre politiche. È un attributo fondamentale per il Dashboard «Refund Amount Discrepancy Tracking». Il confronto con l’importo richiesto aiuta a identificare problemi sistemici nel calcolo e nell’approvazione dei rimborsi, garantendo l’accuratezza finanziaria. Perché è importante Rappresenta l’esito finanziario finale del reso. Il confronto con l’importo richiesto aiuta a garantire l’accuratezza e a identificare eventuali perdite finanziarie. Dove reperirlo Proviene dal documento finanziario associato alla nota di credito. Si trova generalmente nella tabella BSEG (Accounting Document Segment), campo WRBTR (Amount in document currency), per la registrazione sul conto Co.Ge. pertinente. Esempi 150.0045.001200.75 | |||
| Motivo del reso ReturnReason | Il codice motivo fornito dal cliente per la restituzione dell’articolo. | ||
| Descrizione Questo Attributo indica il motivo per cui un prodotto è stato restituito, utilizzando codici motivo predefiniti in SAP. Tra gli esempi figurano «Danneggiato durante il trasporto», «Articolo errato spedito» o «Taglia non adatta». È una dimensione fondamentale per l’analisi delle cause alla radice. Filtrando la mappa di processo o i KPI per motivo del reso, gli analisti possono verificare se determinati motivi sono associati a tempi di elaborazione più lunghi, tassi più elevati di esito negativo dell’ispezione o specifiche deviazioni dal processo. Queste informazioni possono guidare miglioramenti nella qualità dei prodotti, nella logistica o nei processi di vendita. Perché è importante Spiega perché si verificano i resi e consente di analizzarne le cause alla radice per ridurne il numero, intervenendo sui problemi di qualità del prodotto, spedizione o descrizione. Dove reperirlo Si trova nella tabella delle posizioni del documento di vendita VBAP, nel campo ABGRU (motivo del rifiuto dei documenti di vendita). Esempi 001 - Prodotto danneggiato002 - Prodotto errato005 - Arrivato troppo tardi | |||
| Numero materiale MaterialNumber | L’identificativo univoco del prodotto restituito. | ||
| Descrizione Il numero materiale, o SKU, specifica l’articolo esatto coinvolto nel reso. Ciò consente un’analisi dettagliata a livello di prodotto. Analizzando i resi per numero materiale, le aziende possono individuare i prodotti con tassi di restituzione elevati, che potrebbero indicare problemi di qualità, descrizioni inesatte o difetti di produzione. È essenziale per Dashboard come «Inventory Impact of Returns» e per comprendere come i diversi prodotti attraversano il processo di gestione dei resi. Perché è importante Identifica i prodotti restituiti, evidenziando potenziali problemi di controllo qualità o descrizioni dei prodotti non accurate. Dove reperirlo Si trova nella tabella delle posizioni del documento di vendita VBAP, nel campo MATNR. Esempi RM-1025FG-2050-BACC-5591 | |||
| Conforme allo SLA IsSLACompliant | Un indicatore che segnala se il rimborso è stato elaborato entro il livello di servizio concordato (SLA). | ||
| Descrizione Si tratta di un attributo booleano calcolato che confronta la data effettiva dell’attività «Refund Processed» con la «Refund SLA Target Date». Restituisce true se il rimborso è stato completato nei tempi previsti e false in caso contrario. Questo attributo semplifica l’analisi e la reportistica fornendo un esito chiaro e binario per la conformità allo SLA di ogni pratica. Viene utilizzato per calcolare il tasso complessivo di «Refund Processing SLA Compliance» e consente di filtrare facilmente le pratiche non conformi per analizzarle. Perché è importante Fornisce un indicatore binario chiaro delle prestazioni SLA per ogni pratica, semplificando il monitoraggio e la reportistica sulla conformità. Dove reperirlo Si tratta di un attributo calcolato. La logica è: «Refund Processed» EventTime <= RefundSLATargetDate. Esempi truefalse | |||
| Data obiettivo SLA del rimborso RefundSLATargetDate | La data entro la quale si prevede che il rimborso venga elaborato in base agli accordi sul livello di servizio. | ||
| Descrizione Questo attributo definisce la scadenza entro la quale completare il processo di rimborso per una determinata pratica di reso. Viene generalmente calcolato sulla base di regole aziendali, ad esempio «5 giorni lavorativi dal ricevimento della merce». Questa data obiettivo costituisce il riferimento per misurare le prestazioni effettive. È il componente centrale del Dashboard «Refund Processing SLA Compliance», che consente all’azienda di monitorare il rispetto degli impegni verso i clienti e identificare le pratiche a rischio di violazione dello SLA. Perché è importante Stabilisce l’obiettivo di prestazione per l’elaborazione dei rimborsi, consentendo all’azienda di misurare e rendicontare la conformità agli SLA e di dare priorità alle pratiche scadute. Dove reperirlo In genere non è un campo SAP standard e deve essere ricavato sulla base di regole aziendali. Potrebbe essere calcolato a partire da un campo data chiave, ad esempio la data di ricevimento della merce da MKPF, a cui si aggiunge una durata configurata. Consulti la documentazione SAP ECC o i requisiti aziendali. Esempi 2023-04-25T23:59:59Z2023-04-28T23:59:59Z2023-05-02T23:59:59Z | |||
| Discrepanza dell’importo del rimborso RefundAmountDiscrepancy | La differenza calcolata tra l’importo effettivo e quello richiesto del rimborso. | ||
| Descrizione Questa metrica calcolata quantifica la differenza monetaria tra l’importo inizialmente richiesto nell’ordine di reso e quello infine emesso nella nota di credito. Un valore positivo potrebbe indicare un rimborso parziale, mentre un valore negativo è insolito, ma potrebbe indicare un pagamento in eccesso. Questo attributo è la misura principale per il Dashboard «Refund Amount Discrepancy Tracking». Aiuta a identificare e analizzare rapidamente le pratiche con scostamenti finanziari, che potrebbero dipendere dalla valutazione delle condizioni dell’articolo, da costi di ricondizionamento o da errori. Il monitoraggio contribuisce a garantire il controllo finanziario e il rispetto delle politiche. Perché è importante Misura direttamente gli scostamenti finanziari nel processo di rimborso, aiutando a identificare violazioni delle politiche, errori di elaborazione o perdite finanziarie. Dove reperirlo Campo calcolato: ActualRefundAmount - RequestedRefundAmount. Esempi 0.00-4.99-50.00 | |||
| Documento di vendita originale OriginalSalesDocument | Il numero dell’ordine di vendita originale a fronte del quale viene effettuato il reso. | ||
| Descrizione Questo attributo fornisce un collegamento diretto all’acquisto iniziale del cliente. È un documento di riferimento che collega il reso ai dettagli della transazione originale. Disporre di questo collegamento è estremamente utile per un’analisi approfondita. Consente agli analisti di verificare perché le vendite associate a determinati ordini vengono restituite, controllare prezzi e condizioni originali e comprendere l’intero ciclo di vita dall’ordine del cliente al reso. Può inoltre aiutare a determinare se i prodotti venduti attraverso campagne o canali specifici presentano tassi di reso più elevati. Perché è importante Collega il reso alla vendita originale, consentendo una visione completa della transazione del cliente e un’analisi più approfondita delle cause principali. Dove reperirlo Questo riferimento è memorizzato a livello di riga dell’ordine di reso. Si trova nella tabella VBAP, campo VGBEL (Document number of the reference document). Esempi 100034561000987110012345 | |||
| ID cliente CustomerId | L’identificativo univoco del cliente che avvia il reso. | ||
| Descrizione Questo attributo identifica il cliente specifico, il «Sold-to Party» nella terminologia SAP, che sta restituendo il prodotto. Collega la transazione di reso ai dati anagrafici del cliente. L’analisi per Customer ID aiuta a identificare i clienti che effettuano resi frequenti, un possibile segnale di insoddisfazione o di uso improprio delle politiche di reso. Può inoltre essere utilizzata insieme ai dati di segmentazione della clientela per comprendere se determinati gruppi di clienti presentano comportamenti di reso o esperienze di processo differenti. Perché è importante Collega i resi a clienti specifici, consentendo di analizzare il comportamento della clientela, identificare chi effettua resi ripetuti e valutarne l’impatto sulle relazioni con i clienti. Dove reperirlo Si trova nella tabella Sales Document Header VBAK, campo KUNNR (Sold-to Party). Esempi CUST-100432CUST-203991CUST-831102 | |||
| Numero della nota di credito CreditMemoNumber | L’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. Questo numero identifica univocamente il documento finanziario. Questo attributo è essenziale per la riconciliazione finanziaria e per monitorare il processo dal reso operativo alla liquidazione finanziaria. Rappresenta una tappa fondamentale del processo e viene utilizzato per individuare i documenti contabili correlati ad attributi come «Actual Refund Amount». Perché è importante Fornisce un collegamento diretto al documento finanziario che autorizza il rimborso al cliente, essenziale per l’audit finanziario e la riconciliazione. Dove reperirlo La nota di credito è un documento di fatturazione. Il relativo numero si trova nella tabella VBRK (Billing Document: Header Data), campo VBELN. Il collegamento viene individuato tramite il flusso documentale dell’ordine di reso. Esempi 900011229000334490005566 | |||
| Rispetto della politica di reso ReturnPolicyAdherence | Un indicatore che segnala se il reso è conforme a tutte le regole e politiche aziendali definite. | ||
| Descrizione Questo attributo booleano calcolato segnala se una pratica di reso ha seguito le politiche aziendali standard e prescritte. La logica potrebbe prevedere il controllo di più condizioni, ad esempio se il reso è stato avviato entro il periodo consentito, se il codice causale è valido per il prodotto o se è stata ottenuta l’approvazione del responsabile per un’eccezione. Questo attributo alimenta il Dashboard «Return Approval Policy Compliance». Consente di misurare direttamente il tasso di conformità e di identificare le politiche aggirate più frequentemente, favorendo interventi mirati di miglioramento del processo o formazione. Perché è importante Misura la conformità alle regole aziendali, contribuendo ad applicare le politiche in modo coerente e a identificare le pratiche che richiedono una revisione o un’approvazione speciale. Dove reperirlo Si tratta di un attributo derivato sulla base di un insieme di regole aziendali. Ad esempio: (Return Initiation Date - Original Purchase Date) <= 30 days AND ReturnReason IS NOT NULL. Esempi truefalse | |||
| Società CompanyCode | L’entità giuridica o la società responsabile della transazione. | ||
| Descrizione La Società rappresenta un’unità contabile autonoma all’interno di SAP. Tutte le transazioni finanziarie, inclusi resi e rimborsi, vengono registrate su una specifica società. Questo attributo è essenziale per la reportistica finanziaria e per segmentare il processo nelle organizzazioni multinazionali o composte da più entità. L’analisi per Società consente di confrontare le prestazioni del processo di reso tra diverse entità giuridiche della stessa organizzazione. Perché è importante Consente di filtrare e confrontare i processi di reso tra diverse entità giuridiche di un’organizzazione, un aspetto fondamentale per l’analisi finanziaria. Dove reperirlo Si trova nella tabella Sales Document Header VBAK, campo BUKRS_VF (Company code for billing). Esempi 10002000US01 | |||
| Stabilimento Plant | La sede fisica o l’impianto in cui l’articolo restituito viene ricevuto ed elaborato. | ||
| Descrizione In SAP, lo Stabilimento rappresenta una sede fisica, come un magazzino o un centro di distribuzione, in cui vengono movimentate le merci. Per i resi, corrisponde generalmente al luogo in cui l’articolo viene ricevuto e sottoposto a ispezione. L’analisi del processo per Stabilimento aiuta a identificare le differenze di prestazione tra le diverse strutture. Può evidenziare quali magazzini sono più efficienti nell’ispezione degli articoli o presentano una maggiore capacità di elaborazione, supportando il Dashboard «Item Inspection Throughput & Efficiency». Perché è importante Identifica la sede fisica che elabora il reso, consentendo di confrontare le prestazioni tra diversi magazzini o centri di distribuzione. Dove reperirlo Si trova a livello di riga nell’ordine di reso, nella tabella VBAP, campo WERKS. Esempi PL01WH02DC05 | |||
| Stato dell’ordine di reso ReturnOrderStatus | Lo stato complessivo di elaborazione della pratica relativa all’ordine di reso. | ||
| Descrizione Questo attributo fornisce una fotografia dello stato attuale della pratica di reso, ad esempio «Open», «In Process» o «Completed». Deriva dalla combinazione degli stati a livello di testata o di riga del documento di vendita. Nell’analisi, questo attributo è utile per filtrare le pratiche e concentrarsi sui resi attivi o completati. Aiuta a monitorare il carico di lavoro complessivo e l’avanzamento delle pratiche aperte, fornendo un esito di alto livello per ogni percorso di reso. Perché è importante Fornisce una visione di alto livello della posizione della pratica nel suo ciclo di vita, consentendo di filtrare e analizzare i resi aperti, in corso o chiusi. Dove reperirlo Deriva dai campi di stato delle tabelle VBUK (Header Status) e VBUP (Item Status). Ad esempio, VBUK-GBSTK rappresenta lo stato complessivo di elaborazione del documento. Esempi ApertoIn lavorazioneCompletato | |||
Attività di elaborazione di resi e rimborsi
| Attività | Descrizione | ||
|---|---|---|---|
| Decisione di utilizzo presa | Dopo l’ispezione, un tecnico o un ispettore della qualità prende una decisione formale sulle condizioni dell’articolo restituito. Questa decisione determina la fase successiva del processo, ad esempio il reinserimento a magazzino, la rottamazione o la riparazione. | ||
| Perché è importante Questa attività è fondamentale per comprendere l’efficienza dell’ispezione e i relativi risultati. La decisione incide direttamente sull’importo del rimborso e sulla gestione dell’inventario. Dove reperirlo Se viene utilizzato SAP QM, questo è un evento esplicito registrato nella tabella QAVE (decisione di utilizzo nell’elaborazione dell’ispezione). L’ora della decisione è memorizzata in QAVE-VDATUM. Il collegamento alla consegna si trova nella tabella QALS. Acquisizione Utilizzi la data della decisione di utilizzo (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 fisico restituito viene ricevuto presso il magazzino o il centro di elaborazione. Viene registrata tramite la contabilizzazione di un documento di movimento merci associato alla consegna di reso. | ||
| Perché è importante È una milestone fondamentale, che indica che l’azienda ha preso possesso dell’articolo restituito. Rappresenta il punto di partenza per l’ispezione fisica e incide sull’accuratezza dell’inventario. Dove reperirlo Questo evento può essere dedotto dallo stato del movimento merci della posizione della consegna di reso nella tabella VBUP, ad esempio WBSTA = «C». Il timestamp esatto si trova nella testata del documento materiale (MKPF-BUDAT) relativa alla registrazione dell’entrata merci. Acquisizione Individui la data di contabilizzazione (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 rilasciata alla contabilità finanziaria, diventando una registrazione ufficiale nei crediti verso clienti. Questo passaggio avvia il processo effettivo di pagamento del rimborso al cliente. | ||
| Perché è importante Questa attività indica il momento in cui il rimborso viene riconosciuto finanziariamente dall’azienda. I ritardi tra la creazione e la contabilizzazione della nota di credito possono rallentare l’effettivo rimborso al cliente. Dove reperirlo Si tratta di un evento dedotto, identificato quando lo stato di contabilizzazione nella testata del documento di fatturazione (VBRK-RFBSK) viene aggiornato a «C» (documento contabile creato). La data effettiva di creazione del documento contabile si trova nella tabella BKPF. Acquisizione Individui il timestamp in cui VBRK-RFBSK viene impostato su «C», oppure utilizzi la data di creazione (CPUDT) del documento contabile collegato in BKPF. Tipo di evento inferred | |||
| Nota di credito creata | Viene generato un documento di fatturazione, ovvero una nota di credito, per autorizzare l’accredito finanziario al cliente. Questo è il documento finanziario ufficiale che formalizza l’importo del rimborso. | ||
| Perché è importante Questa è una milestone 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 della merce e l’ispezione. Dove reperirlo Si tratta di un evento esplicito registrato nella tabella VBRK (testata del documento di fatturazione). La data di creazione è VBRK-ERDAT. La nota di credito è collegata all’ordine di reso o alla richiesta di nota di credito nel flusso documentale. Acquisizione Utilizzi il timestamp di creazione (ERDAT) della tabella VBRK per il documento di fatturazione pertinente. Tipo di evento explicit | |||
| Ordine di reso completato | Questa attività segna la conclusione del processo di gestione dei resi dal punto di vista delle vendite e della distribuzione. Si verifica quando tutte le posizioni dell’ordine di reso sono state completamente elaborate e chiuse. | ||
| Perché è importante Questo è il principale evento di fine del processo. Misurare il tempo trascorso da «Return Order Created» a questa attività fornisce il tempo di ciclo end-to-end del caso di reso. Dove reperirlo Si tratta di un evento dedotto dalle tabelle degli stati. Viene registrato quando lo stato complessivo della testata del documento di vendita (VBUK-GBSTK) viene aggiornato a «C» (completamente elaborato). Acquisizione Individui il timestamp nei documenti di modifica (CDHDR/CDPOS) relativo al passaggio a «C» del campo di stato della testata VBUK-GBSTK. Tipo di evento inferred | |||
| Ordine di reso creato | Questa attività segna l’avvio del processo di reso, quando un cliente richiede la restituzione di un prodotto. Viene registrata quando in SAP ECC viene creato un nuovo documento di vendita di tipo «Return», ad esempio RE. | ||
| Perché è importante Questo è il principale evento di avvio del processo di gestione dei resi. Analizzare il tempo trascorso da questa attività alle successive aiuta a misurare il tempo di ciclo complessivo e a individuare i ritardi iniziali di elaborazione. Dove reperirlo Si tratta di un evento esplicito registrato nella tabella VBAK (testata del documento di vendita). Il timestamp di creazione è memorizzato nei campi VBAK-ERDAT e VBAK-ERZET per il numero di documento di vendita corrispondente (VBAK-VBELN), con tipo di ordine VBAK-AUART = «RE». Acquisizione Utilizzi il timestamp di creazione (ERDAT, ERZET) della tabella VBAK per il tipo di documento di vendita «RE». Tipo di evento explicit | |||
| Blocco dell’ordine di reso rimosso | Rappresenta l’approvazione della richiesta di reso, che consente al processo di passare alla fase successiva. Viene generalmente rilevato attraverso una modifica dello stato del documento o la rimozione di un blocco di consegna o fatturazione. | ||
| Perché è importante Questa attività rappresenta una milestone di approvazione fondamentale. Misurare il tempo necessario per raggiungerla aiuta a individuare i colli di bottiglia nel processo di autorizzazione e approvazione del reso. Dove reperirlo Si tratta di un evento dedotto dai log delle modifiche del documento di vendita. Verifichi le tabelle CDHDR e CDPOS per le modifiche ai campi di blocco in VBAK o VBAP oppure ai campi di stato in VBUK/VBUP. Acquisizione Individui il timestamp nelle tabelle dei documenti di modifica (CDHDR/CDPOS) relativo alla rimozione dello 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 restituita. Questo evento indica l’avvio del processo logistico relativo al reso. | ||
| Perché è importante Tiene traccia del passaggio dall’elaborazione amministrativa alla logistica fisica. I ritardi in questa fase possono incidere sulla pianificazione del magazzino e sul tempo di ciclo complessivo del reso. Dove reperirlo Si tratta di un evento esplicito registrato nella tabella LIKP (testata della consegna). Il timestamp di creazione si trova in LIKP-ERDAT. Il collegamento all’ordine di reso di origine è disponibile nella tabella LIPS (LIPS-VGBEL). Acquisizione Utilizzi il timestamp 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 relativa alla nota di credito nei crediti verso clienti viene compensata, generalmente 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, rappresenta la vera conclusione del percorso di rimborso. Dove reperirlo Si tratta di un evento esplicito del modulo FI. La data di compensazione del documento contabile è memorizzata nella tabella BSEG (BSEG-AUGDT) per la posizione cliente corrispondente. Acquisizione Utilizzi la data di compensazione (AUGDT) della 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. Ciò avviene generalmente 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 quali prodotti o motivi di reso causano i ritardi più lunghi. Fornisce una visione più granulare del completamento del processo. Dove reperirlo Si tratta di un evento dedotto dalle tabelle degli stati. Viene registrato quando lo stato complessivo della posizione del documento di vendita (VBUP-GBSTK) viene aggiornato a «C» (completamente elaborato). Acquisizione Individui il timestamp nei documenti di modifica (CDHDR/CDPOS) relativo al passaggio a «C» del campo di stato della posizione VBUP-GBSTK. Tipo di evento inferred | |||
| Posizione dell’ordine di reso rifiutata | Una specifica posizione dell’ordine di reso viene rifiutata, durante la verifica iniziale o dopo l’ispezione. Ciò significa che per tale posizione non verranno eseguite ulteriori attività, come il rimborso. | ||
| Perché è importante Analizzare i rifiuti aiuta a individuare le richieste di reso non valide e può orientare la comunicazione delle policy ai clienti. Si tratta di un percorso importante del processo che non conduce a un rimborso. Dove reperirlo Si tratta di un evento dedotto. Viene generalmente registrato quando nella tabella VBAP viene impostato per la posizione del reso un codice univoco di «Motivo del rifiuto» (VBAP-ABGRU). Il timestamp deve essere ricavato dai log delle modifiche. Acquisizione Individui il timestamp nei documenti di modifica (CDHDR/CDPOS) relativo alla valorizzazione del campo VBAP-ABGRU per una posizione di reso. Tipo di evento inferred | |||
| Richiesta di nota di credito creata | Viene creata una richiesta di nota di credito 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 Questo rappresenta l’avvio formale della fase di regolazione finanziaria del processo di gestione dei resi. Fornisce l’innesco per le successive approvazioni finanziarie e la creazione dei documenti. Dove reperirlo Può trattarsi di un evento esplicito in VBAK per un documento di vendita di tipo «Credit Memo Request», ad esempio CR, oppure dello stesso evento di «Return Order Created» se il tipo di ordine è configurato per la fatturazione correlata all’ordine. Acquisizione Utilizzi il timestamp di creazione (ERDAT) della tabella VBAK per il tipo di documento «CR», oppure riutilizzi l’evento di creazione dell’ordine di reso. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
- Crei il programma ABAP: utilizzi il codice transazione
SE38per creare un nuovo programma ABAP eseguibile, ad esempioZ_PM_RETURN_EXTRACTION. Inserisca un titolo descrittivo e lo salvi come oggetto locale oppure all’interno di un pacchetto di sviluppo. - Definisca 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). - Definisca le strutture dati: crei un tipo di struttura locale che corrisponda al formato richiesto per l’event log. La struttura deve includere i campi
ReturnCaseId,ActivityName,EventTime,SourceSystem,LastDataUpdate,ProcessingAgent,ReturnReasone gli altri attributi richiesti. - Implementi la logica di selezione dei dati: scriva la logica ABAP principale per selezionare i dati relativi alle 12 attività richieste. Ciò comporta l’interrogazione di 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 consegne e note di credito, all’ordine di reso originale.
- Estragga «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. - Estragga 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) oppure 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 il collegamento con l’insieme iniziale degli ordini di reso. - Compili 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, associ
VBAK-ERNAMaProcessingAgenteVBAK-ERDATeVBAK-ERZETaEventTime. - Combini i dati delle attività: verifichi che ogni istruzione SELECT relativa a un’attività aggiunga i risultati alla stessa tabella interna principale. In questo modo creerà la struttura finale del file piatto, in cui ogni riga rappresenta un evento.
- Gestisca timestamp e informazioni di sistema: utilizzi i campi di sistema
SY-DATUMeSY-UZEITper compilare il timestampLastDataUpdatedi ogni riga. UtilizziSY-SYSIDper compilareSourceSystem. - Implementi la funzionalità di output: aggiunga una funzione per visualizzare i risultati in una griglia ALV (SAP List Viewer) e consentire l’analisi online, utilizzando moduli funzione come
REUSE_ALV_GRID_DISPLAY. Preveda inoltre un’opzione per scaricare la tabella interna finale come file CSV o file di testo piatto sul computer locale dell’utente. - Esegua ed esporti: 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 file sia salvato in un formato compatibile con ProcessMind, generalmente un CSV con 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 compreso tra 3 e 6 mesi, così da bilanciare il volume dei dati e la qualità degli insight sul processo.
- Tipo di documento di reso: filtri in base al tipo di documento di vendita utilizzato nel Suo sistema per i resi, ad esempio 'RE' per i resi o 'CR' per le richieste di nota di credito. Si tratta di un filtro essenziale 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 determinata entità giuridica. Questo è fondamentale negli ambienti con più società. - Prerequisiti: l’utente che esegue il programma deve disporre delle autorizzazioni per
SE38(esecuzione dei programmi) e dell’accesso alle tabelle sottostanti di SD, MM e FI, ad esempio VBAK, LIKP, VBRK, BKPF e CDHDR. Per lo sviluppo è necessario un ruolo di sviluppatore ABAP. - Prestazioni: con dataset molto estesi, distribuiti su più anni, il programma potrebbe richiedere tempi di esecuzione elevati. Valuti l’esecuzione come job in background (
SM36) e la scrittura dell’output nel file system del server applicativo anziché la visualizzazione online.
a 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 di disporre di un utente database con accesso in lettura alle tabelle SAP richieste. Sono incluse le tabelle dei moduli Sales and Distribution (SD), Materials Management (MM) e Financial Accounting (FI). Per connettersi al database, Le servirà uno strumento client SQL adatto, come DBeaver, SAP HANA Studio o Oracle SQL Developer.
- Identifichi le caratteristiche del sistema: prima di eseguire la query, individui i tipi di documento specifici utilizzati dalla Sua organizzazione per i resi. La query utilizza il segnaposto
[YOUR_RETURN_ORDER_TYPES], che dovrà sostituire con i valori effettivi, ad esempio 'RE' per i resi standard. - Prepari la query: copi la query SQL completa fornita nella sezione 'query' nel Suo client SQL.
- Configuri i parametri: individui la Common Table Expression (CTE) denominata
BaseReturnOrdersall’inizio della query. 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). - Esegua 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.
- Esamini i dati grezzi: al termine della query, esegua una rapida verifica dell’output. Controlli che le colonne
ReturnCaseId,ActivityNameeEventTimesiano valorizzate e che siano presenti dati per più attività. - Esporti in CSV: esporti l’intero set di risultati dal client SQL in un file CSV. Utilizzi la codifica UTF-8 per garantire la corretta conservazione di tutti i caratteri.
- Prepari 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. - Esegua il 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 rappresentano gli ordini di reso nel Suo sistema SAP. A questo scopo, sostituisca il segnaposto
[YOUR_RETURN_ORDER_TYPES]. Tra gli esempi comuni figurano 'RE' o tipi personalizzati 'Z'. - Intervallo di date: è fondamentale definire un intervallo di date adeguato per l’estrazione. Per un’analisi iniziale si consiglia generalmente un periodo compreso tra 3 e 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 ottenere un’analisi mirata. 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 sintattiche in base al sistema di database sottostante, ad esempio Oracle, HANA o DB2. - Autorizzazioni richieste: l’utente 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.
a 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 per iniziare?
Inizi oggi stesso a utilizzare questo Template per semplificare la raccolta dei dati e ottenere informazioni preziose sul processo di resi e rimborsi.
Ottimizzi subito la gestione di resi e rimborsi
Semplifichi la gestione dei resi in SAP ECC e riduca del 30% i tempi di ciclo: inizi oggi.
Non è richiesta alcuna carta di credito; configurazione in pochi minuti