> Miglioramento continuo dei processi > Gestione dei resi e dei rimborsi > Oracle Fusion SCM > Template dei dati

Il Suo Template dati per la gestione dei resi e dei rimborsi

Oracle Fusion SCM

Attributi della gestione dei resi e dei rimborsi (21) Attività della gestione dei resi e dei rimborsi (15) Guide all'estrazione (3)

Il Suo Template dati per la gestione dei resi e dei rimborsi

Questo Template è stato progettato per aiutarLa ad analizzare la gestione dei resi e dei rimborsi in Oracle Fusion SCM. Indica gli attributi essenziali da raccogliere, le attività principali da monitorare e fornisce istruzioni chiare per estrarre questi dati. Lo utilizzi per ottenere indicazioni preziose sul processo e individuare le aree di miglioramento.

Attributi consigliati da raccogliere
Attività principali da monitorare per l'analisi del processo
Istruzioni dettagliate per l'estrazione da Oracle Fusion SCM

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il Template

Attributi della gestione dei resi e dei rimborsi

Questi sono i campi dati consigliati da includere nel Suo Event Log per un’analisi completa della gestione di resi e rimborsi in Oracle Fusion SCM.

5 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome di una specifica fase o di uno specifico evento aziendale verificatosi nel processo di reso e rimborso.
Descrizione Questo attributo descrive una singola fase o tappa del ciclo di vita del reso, come 'RMA Created', 'Item Inspected' o 'Refund Processed'. Ogni attività rappresenta un punto distinto del processo acquisito negli Event Log del sistema. L'analisi della sequenza e della durata di queste attività costituisce il nucleo del Process Mining. Consente di visualizzare le mappe di processo, identificare i colli di bottiglia tra le fasi e calcolare i tempi di attraversamento specifici delle attività. Questi dati sono fondamentali per comprendere il flusso del processo, i cicli di rilavorazione e la conformità alle procedure operative standard. Perché è importante Le attività costituiscono la struttura portante della mappa di processo e consentono di visualizzare e analizzare il flusso, le variazioni e i colli di bottiglia del processo. Dove reperirlo Derivata dagli Event Log, dalle variazioni di stato o da specifici record di transazione nei moduli Oracle Fusion SCM, come Order Management e Inventory Management. Esempi RMA creatoArticolo ricevutoNota di credito creataRimborso elaborato
	ID del caso di reso ReturnCaseId	L'identificativo principale che collega tutte le attività associate a una specifica richiesta di reso o rimborso del cliente.
Descrizione L'ID del caso di reso funge da identificativo univoco del caso per l'intero processo di reso e rimborso. Collega ogni evento, dalla creazione iniziale della Return Material Authorization (RMA) fino all'elaborazione finale del rimborso e alla chiusura del caso. Nell'analisi di Process Mining, questo attributo è fondamentale per ricostruire il percorso end-to-end di ogni reso. Consente agli analisti di seguire l'intero ciclo di vita, misurare i tempi di ciclo complessivi e comprendere le variazioni nella gestione dei diversi resi. Tutti gli altri dati a livello di evento vengono raggruppati in base a questo ID per creare una visione coerente del processo. Perché è importante È la chiave essenziale per riunire tutti gli eventi correlati in una singola istanza di processo, rendendo possibile l'analisi end-to-end. Dove reperirlo Questo identificativo viene generalmente generato nei moduli Oracle Order Management o Service quando viene avviata una richiesta di reso. Esempi RMA-2023-00123RMA-2023-00456RMA-2023-00789
	Ora dell'evento EventTime	Il timestamp che indica quando si è verificata una specifica attività o un evento.
Descrizione Event Time, o ora di inizio, è la data e l'ora precise in cui un'attività è stata registrata nel sistema di origine. Fornisce il contesto cronologico di ogni fase del processo. Questo timestamp è essenziale per tutte le analisi basate sul tempo. Viene utilizzato per ordinare correttamente gli eventi, calcolare i tempi di ciclo tra le attività, misurare la durata complessiva di un caso e valutare le prestazioni rispetto agli accordi sui livelli di servizio (SLA). Senza timestamp accurati è impossibile analizzare l'efficienza del processo, identificare i ritardi o comprendere le dinamiche del processo. Perché è importante Questo attributo fornisce la sequenza cronologica degli eventi, fondamentale per calcolare tutte le metriche basate sulla durata e individuare i colli di bottiglia del processo. Dove reperirlo Questa informazione si trova generalmente in un campo 'Creation Date', 'Timestamp' o 'Last Update Date' associato ai record di transazione o di stato in Oracle Fusion SCM. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	Sistema di origine SourceSystem	Il sistema dal quale sono stati estratti i dati.
Descrizione Questo attributo identifica il sistema informativo di origine in cui sono stati registrati i dati degli eventi. Per questo processo, si tratterebbe generalmente di 'Oracle Fusion SCM'. Negli ambienti con più sistemi integrati, questo campo è fondamentale per la tracciabilità dei dati e la risoluzione dei problemi. Aiuta a confermare l'origine dei dati e può essere utilizzato per filtrare l'analisi degli eventi provenienti da sistemi specifici, assicurando il mantenimento della qualità e del contesto dei dati. Perché è importante Fornisce un contesto essenziale sull'origine dei dati, indispensabile per la convalida e l'analisi dei dati negli ambienti con più sistemi. Dove reperirlo Spesso si tratta di un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati per indicare l'origine del dataset. Esempi Oracle Fusion SCMOracle SCM Cloud
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell'ultimo aggiornamento o dell'ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo indica il momento più recente in cui il dataset è stato aggiornato. Fornisce la data di 'aggiornamento' dell'intero dataset, non dei singoli eventi. Conoscere l'ora dell'ultimo aggiornamento dei dati è fondamentale per comprendere l'attualità dell'analisi. Aiuta a interpretare correttamente Dashboard e KPI, chiarendo se si stanno esaminando informazioni in tempo reale o dati risalenti a qualche ora o giorno prima. È un elemento di metadati essenziale per qualsiasi progetto di Process Mining. Perché è importante Informa gli utenti sull'attualità dei dati, assicurando che comprendano il contesto e la tempestività della propria analisi. Dove reperirlo Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Agente di elaborazione ProcessingAgent	L'utente o l'agente responsabile dell'esecuzione di una specifica attività nel processo di reso.
Descrizione Questo attributo identifica il dipendente o l'utente di sistema che ha eseguito una determinata attività, come l'approvazione di un RMA o l'elaborazione di un rimborso. Può riferirsi anche a un team o a un reparto, se non viene registrata l'assegnazione individuale. Analizzare le prestazioni per agente è fondamentale per la gestione operativa. Questo attributo abilita la Dashboard 'Return Processing Agent Performance', consentendo di confrontare il carico di lavoro, la durata delle attività e i tassi di rilavorazione dei diversi agenti. Queste informazioni possono evidenziare le esigenze formative, individuare i migliori risultati e orientare una migliore allocazione delle risorse. Perché è importante Consente di analizzare le prestazioni per utente o team, aiutando a individuare le persone più performanti, le opportunità formative e gli squilibri nel carico di lavoro. Dove reperirlo Si trova generalmente in campi come 'USER_ID', 'PROCESSED_BY' o 'AGENT_NAME' nei log delle transazioni di Oracle Fusion SCM. Esempi j.doea.smithm.jones
	Data obiettivo SLA del rimborso RefundSlaTargetDate	La data entro la quale si prevede di completare il rimborso in base allo SLA.
Descrizione Questo attributo definisce la scadenza entro cui completare il processo di rimborso per un determinato caso. L'obiettivo SLA è spesso determinato dalle policy aziendali, dal livello del cliente o dal motivo del reso. Questa data costituisce il riferimento per misurare la puntualità e la conformità. Viene utilizzata direttamente nella Dashboard «Conformità allo SLA della policy sui rimborsi» ed è essenziale per calcolare il KPI «Tasso di conformità allo SLA dei rimborsi». Il confronto tra la data effettiva di completamento del rimborso e questa data obiettivo consente di individuare le violazioni dello SLA e di dare priorità ai casi a rischio di ritardo. Perché è importante Fornisce il riferimento per misurare le prestazioni puntuali ed è fondamentale per calcolare i KPI di conformità allo SLA. Dove reperirlo Può trattarsi di un campo data specifico del caso di reso oppure di una data derivata aggiungendo un periodo predefinito, ad esempio 14 giorni, alla data di avvio del reso. Esempi 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
	Importo del rimborso richiesto RequestedRefundAmount	L'importo monetario inizialmente richiesto dal cliente per il reso.
Descrizione Questo attributo acquisisce il valore del rimborso richiesto dal cliente all'inizio del processo. Costituisce l'importo di riferimento rispetto al quale viene confrontato il rimborso finale. Questo dato è essenziale per la Dashboard 'Requested vs Actual Refund Amounts' e per il KPI 'Refund Amount Discrepancy Rate'. Analizzare la differenza tra gli importi richiesti ed effettivi può far emergere problemi come resi di articoli errati, costi di reintegro a magazzino o adeguamenti alle politiche, offrendo informazioni preziose sull'accuratezza finanziaria e sulla soddisfazione dei clienti. Perché è importante Costituisce il riferimento per l'analisi finanziaria, consentendo di calcolare le discrepanze nei rimborsi e di evidenziare potenziali problemi. Dove reperirlo Questo valore dovrebbe essere memorizzato nell'intestazione dell'RMA o della richiesta di reso in Oracle Fusion SCM, probabilmente nel modulo Order Management. Esempi 129.9945.501200.00
	Importo effettivo del rimborso ActualRefundAmount	L'importo monetario finale effettivamente elaborato e rimborsato al cliente.
Descrizione Questo attributo rappresenta l'importo finale confermato restituito al cliente dopo l'applicazione di tutte le ispezioni, gli adeguamenti e le commissioni. Riflette l'esito finanziario effettivo del caso di reso. È un dato finanziario fondamentale utilizzato nella Dashboard 'Requested vs Actual Refund Amounts'. Il confronto con l'importo richiesto è essenziale per calcolare il KPI 'Refund Amount Discrepancy Rate' e comprendere l'impatto finanziario delle politiche di reso, delle condizioni degli articoli e degli adeguamenti applicati durante l'elaborazione. Perché è importante Rappresenta l'esito finanziario effettivo del reso, consentendo di analizzare le discrepanze e produrre report finanziari. Dove reperirlo Queste informazioni proverrebbero probabilmente dalle registrazioni delle Credit Memo o delle transazioni di Accounts Payable collegate al caso di reso in Oracle Fusion Financials. Esempi 129.9940.000.00
	Motivo del reso ReturnReason	Il motivo indicato dal cliente per la restituzione dell'articolo.
Descrizione Questo attributo contiene il motivo del reso, generalmente selezionato dal cliente da un elenco predefinito, ad esempio «Articolo difettoso», «Taglia errata» o «Non più necessario». L'analisi dei motivi dei resi offre indicazioni preziose sulla qualità dei prodotti, sull'accuratezza del processo di vendita e sul comportamento dei clienti. Questi dati possono essere utilizzati per individuare i prodotti con tassi di difettosità elevati, migliorare le descrizioni dei prodotti e ridurre gli ordini errati, nonché comprendere le cause alla radice dei resi. Questa analisi può guidare interventi strategici volti a ridurre il volume complessivo dei resi. Perché è importante Fornisce indicazioni fondamentali sulle cause dei resi e può essere utilizzato per migliorare i prodotti e i processi di vendita. Dove reperirlo Generalmente memorizzato come codice o campo di testo sulla riga RMA in Oracle Order Management. Esempi DifettosoArticolo errato speditoArrivato troppo tardiPrezzo migliore disponibile
	Ora di fine EndTime	Il timestamp che indica quando un'attività è stata completata.
Descrizione End Time indica il completamento di un'attività. Mentre StartTime indica quando è iniziato un evento, End Time è necessario per calcolare il tempo effettivo di elaborazione di quello specifico evento. Per gli eventi istantanei, StartTime ed End Time possono coincidere. Nell'analisi, la differenza tra End Time e Start Time fornisce il 'Processing Time' di un'attività. Questo è fondamentale per identificare le fasi specifiche che richiedono più tempo, distinguendole dal tempo di attesa tra una fase e l'altra. È essenziale per un'analisi dettagliata dei colli di bottiglia e per il calcolo dell'efficienza delle risorse. Perché è importante Questo attributo è necessario per calcolare il tempo effettivo di elaborazione delle singole attività e aiuta a distinguere il tempo di lavoro attivo dal tempo di attesa. Dove reperirlo Può essere un campo separato nei log del sistema di origine oppure può essere derivato dallo StartTime dell'attività successiva. Esempi 2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
	Stato del reso ReturnStatus	Lo stato attuale o finale del caso di reso.
Descrizione Questo attributo indica lo stato complessivo del caso di reso in un determinato momento o il suo esito finale, ad esempio 'Closed - Refunded', 'Closed - Rejected' o 'In Progress'. Return Status è fondamentale per l'analisi e il monitoraggio degli esiti. Consente di filtrare i casi in base al risultato, confrontare i flussi di processo dei resi approvati e rifiutati e alimentare la Dashboard 'Current Return Case Status Dashboard'. Comprendere la distribuzione degli esiti è essenziale per misurare l'efficacia del processo. Perché è importante Fornisce l'esito di un caso, indispensabile per il filtraggio, l'analisi comparativa e la comprensione dei tassi di successo del processo. Dove reperirlo È generalmente disponibile come campo di stato nel record principale dell'intestazione del reso o dell'RMA in Oracle Order Management. Esempi In attesa di ricezioneIspezione completataChiuso, rimborsatoChiuso, rifiutato
	Codice di destinazione DispositionCode	Un codice che indica la gestione finale dell'articolo fisico restituito.
Descrizione Il Disposition Code specifica cosa è accaduto al prodotto restituito dopo l'ispezione, ad esempio se è stato reintegrato nell'inventario, rottamato, inviato alla ricondizionatura o restituito al fornitore. Queste informazioni sono preziose per analizzare l'impatto finanziario e operativo dei resi. Analizzando i codici di destinazione, un'azienda può comprendere i costi associati ai prodotti non rivendibili e individuare opportunità per migliorare i processi di ricondizionatura. In questo modo, il processo di reso viene collegato agli esiti di inventario e finanziari. Perché è importante Collega il processo di reso al relativo esito fisico nell'inventario, offrendo indicazioni sui tassi e sui costi di recupero. Dove reperirlo Queste informazioni vengono acquisite nei moduli Oracle Inventory Management o Warehouse Management al termine dell'attività di ispezione. Esempi RETURN_TO_STOCKSCRAPREFURBISHRETURN_TO_VENDOR
	Conforme allo SLA IsSlaCompliant	Un flag booleano che indica se il rimborso è stato elaborato entro l'obiettivo SLA definito.
Descrizione Questo attributo calcolato fornisce un semplice indicatore vero o falso della conformità allo SLA per ciascun caso di reso. Viene determinato confrontando il timestamp effettivo di completamento del rimborso con «RefundSlaTargetDate». Questo flag è essenziale per misurare e visualizzare facilmente i tassi di conformità. Alimenta la Dashboard «Conformità allo SLA della policy sui rimborsi» e semplifica il calcolo del KPI «Tasso di conformità allo SLA dei rimborsi». Consente di filtrare rapidamente i casi e analizzare le cause alla radice per comprendere perché determinati casi non rispettano lo SLA. Perché è importante Semplifica il monitoraggio e la reportistica dello SLA trasformando il confronto tra date in una semplice metrica booleana. Dove reperirlo Campo calcolato. È true se il timestamp «Refund Processed» è uguale o precedente a «RefundSlaTargetDate»; in caso contrario è false. Esempi truefalse
	Discrepanza sull'importo del rimborso RefundAmountDiscrepancy	La differenza calcolata tra l'importo del rimborso richiesto e l'importo effettivamente rimborsato.
Descrizione Questa metrica quantifica la differenza monetaria tra l'importo richiesto dal cliente e quello ricevuto. Viene calcolata sottraendo «ActualRefundAmount» da «RequestedRefundAmount». Questo valore calcolato costituisce la base del KPI «Tasso di discrepanza dell'importo del rimborso». Un valore diverso da zero indica che durante il processo è stata applicata una rettifica. L'analisi delle cause di queste discrepanze, come le spese di reintegro a magazzino o le detrazioni per danni, può offrire indicazioni sull'efficacia delle policy e sulla comunicazione con i clienti. Perché è importante Quantifica le rettifiche finanziarie nel processo di rimborso, aiutando ad analizzare l'impatto delle policy e degli esiti delle ispezioni. Dove reperirlo Campo calcolato: «RequestedRefundAmount» - «ActualRefundAmount». Esempi 0.005.50-10.00
	ID cliente CustomerId	L'identificativo univoco del cliente che ha avviato il reso.
Descrizione Questo attributo è l'ID univoco che identifica il cliente associato al caso di reso. Collega il processo di reso al database dei clienti. L'analisi dei resi in un'ottica incentrata sul cliente può rivelare schemi importanti. Ad esempio, può aiutare a individuare i clienti con una frequenza di reso insolitamente elevata, che potrebbe indicare problemi di soddisfazione o potenziali frodi. Consente inoltre di analizzare i dati per segmento di clientela e comprendere se determinati gruppi presentano comportamenti diversi rispetto ai resi. Perché è importante Consente un'analisi incentrata sul cliente, aiutando a individuare i clienti che effettuano resi ripetuti, segmentare i comportamenti e rilevare potenziali frodi. Dove reperirlo È disponibile come ID cliente o ID party nell'intestazione dell'ordine di vendita originale o della richiesta di reso in Oracle Order Management. Esempi CUST-100589743ACC-54321
	ID magazzino WarehouseId	L'identificativo del magazzino o della struttura che ha ricevuto l'articolo restituito.
Descrizione Questo attributo indica la specifica ubicazione fisica, ad esempio un centro di distribuzione o un magazzino, in cui l'articolo restituito dal cliente è stato ricevuto ed elaborato. L'analisi del processo per magazzino è importante per individuare problemi prestazionali specifici di una sede. Consente di confrontare i tempi di ispezione, gli esiti di destinazione e i tempi di attraversamento complessivi tra strutture diverse. In questo modo è possibile evidenziare inefficienze operative, problemi di organico o necessità di formazione in determinati siti. Perché è importante Consente di analizzare le prestazioni per ubicazione, aiutando a individuare colli di bottiglia e inefficienze specifici di una regione o di una struttura. Dove reperirlo Questo campo, spesso denominato «ORGANIZATION_ID», è associato alla transazione di ricezione in Oracle Inventory Management. Esempi WH-US-WESTWH-EU-CENTRALDC-01
	ID prodotto ProductId	L'identificativo univoco del prodotto restituito.
Descrizione Questo attributo rappresenta l'identificativo univoco, ad esempio uno SKU o un codice articolo, del prodotto specifico coinvolto nel reso. Collega il processo di reso al catalogo prodotti. L'analisi a livello di prodotto è fondamentale per individuare gli articoli problematici. Filtrando o segmentando l'analisi del processo per Product ID, le aziende possono identificare i prodotti con tassi di reso elevati, tempi di ispezione lunghi o specifici schemi di difettosità. Queste informazioni sono essenziali per il controllo qualità, la gestione della supply chain e lo sviluppo dei prodotti. Perché è importante Collega il processo di reso a prodotti specifici, consentendo di analizzare la qualità dei prodotti e gli schemi dei resi. Dove reperirlo Corrisponde al campo «INVENTORY_ITEM_ID» o a un campo analogo sulla riga RMA in Oracle Order Management o nei moduli Inventory. Esempi PROD-5540-ASKU-98765ITEM-001-B
	Numero RMA RmaNumber	L'identificativo univoco della transazione di Return Merchandise Authorization.
Descrizione Il numero RMA rappresenta l'autorizzazione formale concessa al cliente per restituire un prodotto. Sebbene spesso coincida con il Return Case ID, in alcuni sistemi può essere un identificativo distinto e precedente. Questo attributo funge da numero di riferimento aziendale, riconoscibile sia dagli utenti interni sia dai clienti. Può essere utilizzato per cercare e filtrare i casi ed è spesso il numero principale impiegato nelle comunicazioni relative al reso. Perché è importante Funge da principale numero di riferimento aziendale, essenziale per il monitoraggio operativo e le comunicazioni con i clienti. Dove reperirlo È l'identificativo principale dell'oggetto Return Merchandise Authorization in Oracle Order Management. Esempi 789001789002789003
	Rilavorazione IsRework	Un flag booleano che indica se un'attività fa parte di un ciclo di rilavorazione.
Descrizione Questo flag identifica le attività che costituiscono la ripetizione di fasi precedenti nello stesso caso e indicano un ciclo del processo o una rilavorazione. Ad esempio, se un articolo non supera l'ispezione e deve essere ispezionato nuovamente, il secondo evento di ispezione viene contrassegnato come rilavorazione. Questo attributo è fondamentale per quantificare l'inefficienza del processo. Viene utilizzato nella Dashboard «Tassi di rilavorazione nell'elaborazione dei resi» e per calcolare il KPI «Frequenza degli eventi di rilavorazione dei resi». Individuare la quantità e le cause della rilavorazione è uno degli obiettivi principali del Process Mining, poiché evidenzia direttamente attività sprecate, ritardi e costi aggiuntivi. Perché è importante Segnala direttamente le inefficienze e i cicli del processo, rendendo semplice quantificare e analizzare le cause della rilavorazione. Dove reperirlo È un attributo calcolato, individuato dagli algoritmi del software di Process Mining che rilevano le attività ripetute all'interno di un singolo caso. Esempi truefalse
	Tipo di reso ReturnType	Classifica il reso in base all'esito previsto, ad esempio rimborso, sostituzione o riparazione.
Descrizione Questo attributo classifica il tipo di reso in elaborazione. Il flusso del processo e le attività richieste possono variare significativamente a seconda che il cliente riceva un rimborso monetario, un prodotto sostitutivo o un articolo riparato. L'analisi del processo per Return Type è essenziale per comprendere le varianti del processo. Consente di creare mappe di processo separate per rimborsi e sostituzioni, aiutando a individuare i colli di bottiglia e le caratteristiche prestazionali specifici di ciascun percorso. Questa segmentazione è fondamentale per interventi mirati di miglioramento del processo. Perché è importante Consente di segmentare l'analisi in base ai diversi percorsi del processo, poiché sostituzioni e rimborsi seguono spesso fasi differenti. Dove reperirlo Generalmente è un campo categoria o tipo nell'intestazione o nella riga RMA in Oracle Order Management. Esempi RimborsoCambioRiparazione

Obbligatorio Consigliato Facoltativo

Attività della gestione dei resi e dei rimborsi

Questi sono i passaggi e i traguardi chiave del processo da acquisire nel Suo Event Log per un’individuazione accurata del processo e dei colli di bottiglia.

7 Consigliato 8 Facoltativo

	Attività	Descrizione
	Articolo ispezionato	Questa attività indica il completamento dell'ispezione dell'articolo, durante la quale viene registrata una valutazione della qualità. Generalmente corrisponde a una transazione esplicita in Oracle Inventory Management o Quality Management che aggiorna lo stato dell'RMA.
Perché è importante L'esito dell'ispezione influenza direttamente le fasi successive, come l'approvazione o il rifiuto del rimborso. La durata dell'attività di ispezione è un indicatore chiave delle prestazioni del magazzino. Dove reperirlo Acquisito dal timestamp della transazione registrato quando l'ispettore completa l'attività di ispezione a fronte della ricezione dell'RMA in Oracle Inventory o Quality Management. Acquisizione Utilizzare il timestamp di completamento della transazione di ispezione. Tipo di evento explicit
	Articolo ricevuto	Questa attività indica la ricezione fisica dell'articolo restituito presso il magazzino o il centro di elaborazione. È un evento esplicito acquisito in Oracle Fusion Inventory Management quando la merce viene scansionata e registrata come ricevuta a fronte dell'RMA.
Perché è importante La ricezione dell'articolo è una tappa fondamentale che attiva le successive fasi di ispezione ed elaborazione. Misurare il tempo tra 'RMA Approved' e 'Item Received' aiuta ad analizzare le prestazioni logistiche e di spedizione. Dove reperirlo Si tratta di una transazione esplicita registrata in Oracle Inventory Management. L'evento corrisponde alla data della transazione di ricezione dell'RMA. Acquisizione Utilizzare il timestamp della transazione di ricezione dell'RMA in Inventory. Tipo di evento explicit
	Caso di reso chiuso	Questa è l'attività finale, che indica il completamento di tutte le azioni relative all'RMA, inclusi la ricezione, la definizione della destinazione e il regolamento finanziario. Viene dedotta dallo stato finale 'Closed' dell'ordine RMA.
Perché è importante Questo evento rappresenta la conclusione definitiva del processo, fondamentale per calcolare il tempo di ciclo end-to-end e assicurare che nessun caso rimanga aperto indefinitamente. Dove reperirlo Deducibile dal timestamp in cui l'intestazione dell'ordine RMA e tutte le relative righe raggiungono lo stato finale 'Closed' in Oracle Order Management. Acquisizione Acquisire l'ultimo timestamp della variazione dello stato dell'intestazione o della riga RMA a 'Closed'. Tipo di evento inferred
	Nota di credito creata	Questa è l'attività finanziaria con cui viene generata una nota di credito in Accounts Receivable per autorizzare il rimborso al cliente. È un evento esplicito attivato dal processo di reso in Order Management.
Perché è importante La creazione di una nota di credito è una tappa definitiva che indica l'impegno dell'azienda a rimborsare il cliente. Costituisce l'evento che avvia l'intera fase di regolamento finanziario del processo. Dove reperirlo Si tratta di una transazione esplicita in Oracle Accounts Receivable. L'evento può essere ricondotto all'RMA originale tramite il riferimento all'ordine di vendita riportato sulla nota di credito. Acquisizione Utilizzare la data di creazione della transazione della nota di credito in AR. Tipo di evento explicit
	Rimborso elaborato	Questa attività indica il completamento del pagamento del rimborso al cliente. È un evento esplicito acquisito quando la transazione di compensazione del pagamento viene registrata in Oracle Financials.
Perché è importante È il punto finale fondamentale per misurare il tempo complessivo del ciclo di rimborso dal punto di vista del cliente. Conferma che l'obbligazione finanziaria nei confronti del cliente è stata adempiuta. Dove reperirlo L'evento viene acquisito dalla data contabile o di compensazione della transazione di pagamento in Oracle Accounts Payable o Treasury che regola la nota di credito. Acquisizione Utilizzare la data di compensazione della transazione di pagamento che regola la nota di credito. Tipo di evento explicit
	RMA approvato	Questa tappa fondamentale indica che la richiesta di reso è stata convalidata e approvata in base alle regole aziendali. Generalmente viene dedotta da una variazione dello stato dell'RMA, che abilita le fasi successive del processo, come la spedizione da parte del cliente.
Perché è importante L'approvazione è un passaggio decisivo del processo. I ritardi in questa fase incidono direttamente sulla durata complessiva del ciclo di reso e sulla soddisfazione dei clienti. Questa attività è essenziale per analizzare i colli di bottiglia nelle approvazioni. Dove reperirlo Deducibile dal timestamp della variazione dello stato dell'intestazione o della riga dell'ordine RMA a uno stato 'Approved' o 'Awaiting Receiving'. Acquisizione Acquisire il timestamp dell'aggiornamento dello stato dell'RMA a uno stato approvato. Tipo di evento inferred
	RMA creato	Questa attività segna l'avvio ufficiale del processo di reso, con la creazione di una Return Material Authorization (RMA) in Oracle Fusion SCM. L'evento viene generalmente acquisito in modo esplicito quando un utente o un processo automatizzato genera un nuovo record di ordine di vendita RMA.
Perché è importante Questo è l'evento iniziale principale dell'intero processo di reso. Analizzare il tempo che intercorre tra questa attività e le successive consente di determinare la durata complessiva del processo e di individuare i ritardi iniziali. Dove reperirlo L'evento viene acquisito dal timestamp di creazione dell'intestazione dell'ordine di reso in Oracle Fusion Order Management. Corrisponde al salvataggio iniziale del documento RMA. Acquisizione Rilevare la data di creazione del record dell'intestazione dell'ordine di reso. Tipo di evento explicit
	Approvazione RMA inviata	Indica il momento in cui l'RMA creato viene inviato per la revisione e l'approvazione interne. Spesso viene dedotto da una variazione dello stato dell'RMA, che segnala il passaggio dallo stato di bozza o inserimento a uno stato di approvazione in sospeso.
Perché è importante Il monitoraggio di questa attività consente di misurare la durata della fase precedente all'approvazione, distinguendo il tempo di inserimento dei dati dal tempo effettivamente trascorso in attesa dell'intervento dell'approvatore. Dove reperirlo Deducibile dal timestamp della variazione dello stato dell'intestazione o della riga dell'ordine RMA a 'Pending Approval' o a uno stato equivalente all'interno del Workflow di approvazione di Order Management. Acquisizione Identificare il timestamp della variazione di stato a 'Pending Approval'. Tipo di evento inferred
	Articolo spedito dal cliente	Rappresenta l'azione del cliente che rispedisce l'articolo all'azienda. Questo evento spesso non viene acquisito direttamente in Oracle SCM, ma può essere dedotto dai dati di integrazione del corriere o da un aggiornamento manuale.
Perché è importante Questa attività offre informazioni sul comportamento dei clienti e sul tempo di transito delle merci. Aiuta a distinguere i ritardi nell'elaborazione interna da quelli causati dalla spedizione. Dove reperirlo Può trattarsi di un evento dedotto dai dati di spedizione del corriere collegati all'RMA oppure di un aggiornamento manuale dello stato in Oracle SCM. In assenza di un'integrazione, l'evento potrebbe non essere disponibile. Acquisizione Timestamp proveniente da un'API integrata del corriere o da un campo di inserimento manuale dei dati. Tipo di evento inferred
	Cliente informato	Rappresenta la comunicazione inviata al cliente per confermare l'esito del caso di reso, ad esempio il rimborso elaborato o la spedizione di un prodotto sostitutivo. Spesso viene acquisita da un registro delle comunicazioni o da un aggiornamento dello stato del caso.
Perché è importante Una comunicazione tempestiva con il cliente è fondamentale per la soddisfazione. Analizzarla aiuta ad assicurare il rispetto degli accordi sui livelli di servizio relativi alle comunicazioni. Dove reperirlo Richiede un'analisi dei sistemi. Può essere registrata da un CRM integrato o da una piattaforma di comunicazione, oppure corrispondere a un aggiornamento manuale dello stato dell'RMA o di una richiesta di assistenza correlata. Acquisizione Timestamp proveniente da un sistema di comunicazione esterno o da un aggiornamento manuale. Tipo di evento inferred
	Destinazione del reso determinata	Dopo l'ispezione, questa attività rappresenta la decisione relativa alla destinazione dell'articolo restituito, ad esempio 'Return to Stock' o 'Scrap'. Viene acquisita tramite una transazione di inventario esplicita che trasferisce l'articolo alla destinazione finale.
Perché è importante Questo passaggio è fondamentale per l'accuratezza dell'inventario e la riconciliazione finanziaria. Analizzare le destinazioni aiuta a comprendere le motivazioni dei resi e i problemi di qualità dei prodotti. Dove reperirlo Registrato come transazione in Oracle Inventory Management, ad esempio un trasferimento tra subinventari o un aggiornamento dello stato dell'articolo, dopo l'ispezione. Acquisizione Rilevare il timestamp della transazione di inventario che rende effettiva la destinazione. Tipo di evento explicit
	Ispezione dell'articolo avviata	Indica l'inizio dell'ispezione fisica dell'articolo restituito per valutarne le condizioni. Può essere dedotto dalla variazione della posizione o dello stato dell'articolo all'interno del modulo di gestione del magazzino oppure può corrispondere a una scansione esplicita.
Perché è importante Misurare il tempo tra la ricezione dell'articolo e l'inizio dell'ispezione evidenzia i ritardi di attesa presso la stazione di ispezione, un collo di bottiglia frequente. Dove reperirlo Può essere acquisito da una variazione dello stato della riga di ricezione o da una transazione che trasferisce l'articolo in un'area di ispezione in Oracle Inventory Management. Potrebbe essere necessaria una configurazione personalizzata per acquisirlo in modo esplicito. Acquisizione Timestamp della variazione di stato o del trasferimento dell'inventario in un'area di ispezione. Tipo di evento inferred
	Ordine di sostituzione creato	Questa attività si verifica nei casi in cui il cliente richieda una sostituzione anziché un rimborso. È un evento esplicito in cui viene generato un nuovo ordine di vendita, spesso collegato all'RMA originale.
Perché è importante Questa attività identifica una variante importante del processo. Separare i processi di sostituzione da quelli di rimborso è essenziale per analizzare correttamente il tempo di ciclo di ciascun percorso. Dove reperirlo È un evento esplicito, corrispondente alla creazione di un nuovo documento di ordine di vendita in Order Management. Deve essere collegato all'RMA tramite un campo di riferimento. Acquisizione Utilizzare la data di creazione del nuovo ordine di vendita collegato all'RMA. Tipo di evento explicit
	Rimborso avviato	Questa attività indica l'avvio del processo di pagamento del rimborso. Spesso viene dedotta da una variazione dello stato della nota di credito, che passa da uno stato aperto a uno stato indicante che il pagamento è in elaborazione.
Perché è importante Questa attività consente di distinguere l'approvazione e la creazione della nota di credito dall'effettiva elaborazione del pagamento, che potrebbe essere gestita da un team o da un sistema diverso e costituire una fonte di ritardi. Dove reperirlo Deducibile da una variazione dello stato della nota di credito in Accounts Receivable oppure dalla creazione di un record di pagamento in Accounts Payable che fa riferimento alla nota di credito. Acquisizione Identificare il timestamp della variazione dello stato della nota di credito a 'Pending Payment' o a uno stato simile. Tipo di evento inferred
	RMA rifiutato	Rappresenta la decisione definitiva di rifiutare la richiesta di reso del cliente. Generalmente viene dedotta da una variazione dello stato dell'RMA a 'Rejected' o 'Cancelled' durante la fase di approvazione.
Perché è importante È un percorso di eccezione fondamentale. Analizzare la frequenza e le motivazioni dei rifiuti può far emergere problemi relativi alle politiche di reso, alle aspettative dei clienti o a tentativi di frode. Dove reperirlo Deducibile dal timestamp della variazione dello stato dell'intestazione o della riga dell'ordine RMA a uno stato terminale 'Rejected' o equivalente. Acquisizione Identificare il timestamp della variazione di stato a 'Rejected' o 'Cancelled'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i dati da Oracle Fusion SCM

Passaggi

Acceda all'editor OTBI Analysis: acceda alla Sua istanza Oracle Fusion Cloud SCM. Utilizzi il menu Navigator per andare a Tools, quindi selezioni Reports and Analytics. Faccia clic sul pulsante «Create» e scelga «Analysis» dal menu a discesa.
Selezioni le Subject Areas: nella finestra «Select Subject Area», scelga le Subject Areas principali che contengono i dati relativi a resi e rimborsi. Selezioni «Sales - CRM All Lines» e «Receivables - Transactions Real Time». Le combinerà per creare una vista completa del processo.
Passi alla modalità Advanced: dopo aver selezionato le Subject Areas, si aprirà l'editor dell'analisi. Passi immediatamente alla scheda «Advanced» per accedere all'editor SQL logico, necessario per creare la struttura richiesta dell'Event Log.
Costruisca la query dell'Event Log: copi l'intero SQL logico fornito nella sezione «Query» di questo documento e lo incolli nell'area di testo «SQL Query» della scheda Advanced. La query è strutturata con più clausole UNION ALL per recuperare ciascuna delle 15 attività richieste come riga separata.
Imposti i parametri della query: modifichi i valori segnaposto nella query. In particolare, aggiorni i segnaposto [START_DATE] e [END_DATE] per definire l'intervallo di date dell'estrazione. Potrebbe inoltre essere necessario modificare i filtri per specifiche Business Unit o Return Order Type in base alla configurazione della Sua organizzazione.
Convalidi la query: faccia clic sul pulsante «Validate SQL» per verificare che la sintassi sia corretta. Il sistema controllerà i nomi delle colonne e la struttura rispetto alle Subject Areas selezionate.
Esamini i risultati: acceda alla scheda «Results» per visualizzare un'anteprima dell'output. I dati dovrebbero apparire nel formato di un Event Log, con ogni riga corrispondente a un'attività distinta del processo di reso. Verifichi che colonne come ReturnCaseId, ActivityName ed EventTime siano valorizzate come previsto.
Salvi l'analisi: quando è soddisfatto dei risultati, faccia clic sull'icona «Save Analysis». Assegni un nome descrittivo, ad esempio «ProcessMind Returns and Refund Extraction», e salvi l'analisi in una cartella condivisa.
Crei una pianificazione dell'esportazione: per automatizzare l'estrazione, può pianificare l'esecuzione periodica dell'analisi. Dalla home page di Oracle BI, individui l'analisi salvata, faccia clic su «More» e selezioni «Schedule».
Configuri il job di esportazione: nelle opzioni di pianificazione, definisca la frequenza, ad esempio giornaliera o settimanale. Nella sezione «Delivery», imposti il formato di output su CSV. Configuri la destinazione, ad esempio content server o e-mail, a cui inviare il file di output. Attivi la pianificazione per avviare le estrazioni automatiche.

Configurazione

Subject Areas: le Subject Areas principali per questa analisi sono «Sales - CRM All Lines» per le intestazioni e le righe degli ordini RMA e la cronologia degli stati, e «Receivables - Transactions Real Time» per i dettagli delle Credit Memo e dei pagamenti dei rimborsi. Potrebbero essere necessarie Subject Areas aggiuntive, come «Inventory - Inventory Transactions Real Time», se occorrono dettagli più granulari su ispezione e destinazione.
Filtro dell'intervallo di date: è fondamentale applicare un filtro sull'intervallo di date per limitare il volume dei dati e garantire il completamento corretto dell'analisi. Si consiglia di estrarre i dati relativi a un periodo di 3-6 mesi alla volta. La query fornita filtra in base alla data di creazione dell'RMA.
Filtri principali: oltre all'intervallo di date, applichi un filtro su Order Type per selezionare specificamente gli ordini Return Material Authorization (RMA). È inoltre consigliabile filtrare per una specifica Business Unit o Legal Entity, così da circoscrivere correttamente i dati.
Modalità Logical SQL: questo metodo di estrazione richiede l'utilizzo della scheda «Advanced» e la scrittura di una query SQL logica personalizzata con istruzioni UNION ALL. Questo approccio è necessario per riorganizzare i dati transazionali nel formato di Event Log richiesto da ProcessMind.
Prerequisiti: l'utente che esegue l'estrazione deve disporre di un ruolo con le autorizzazioni necessarie per creare ed eseguire analisi OTBI, ad esempio il ruolo «BI Author». È inoltre obbligatorio avere accesso alle Subject Areas Sales, Receivables ed eventualmente Inventory specificate.

a Query di esempio sql

SELECT
    "Sales - CRM All Lines"."Order"."Order Number" AS "ReturnCaseId",
    'RMA Created' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Order"."Creation Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Order"."Created By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Order"."Header Status" AS "ReturnStatus",
    "Sales - CRM All Lines"."Order"."Order Amount" AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    "Sales - CRM All Lines"."Order"."Return Reason" AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Order Type" = 'Return'
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Approval Submitted' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Pending Approval' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Approved' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Awaiting Receiving' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Shipped By Customer' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: This event is not standard. Adapt if custom fields exist.
UNION ALL
SELECT
    "Sales - CRM All Lines"."Order"."Order Number" AS "ReturnCaseId",
    'Item Received' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Fulfillment Line"."Actual Arrival Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Fulfillment Line"."Last Updated By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Fulfillment Line"."Fulfillment Line Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Order Type" = 'Return' AND "Sales - CRM All Lines"."Fulfillment Line"."Actual Arrival Date" IS NOT NULL
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Inspection Started' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area or custom fields.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Inspected' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area or custom fields.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Return Disposition Determined' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area.
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Credit Memo Created' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Transaction Details"."Created By" AS "ProcessingAgent",
    "Receivables - Transactions Real Time"."Transaction Details"."Transaction Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Transaction Details"."Transaction Amount" AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo'
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Refund Initiated' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Receipt Application Details"."Application Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Created By" AS "ProcessingAgent",
    'Refund Initiated' AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Amount Applied" * -1 AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo'
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Refund Processed' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Receipt Application Details"."GL Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Created By" AS "ProcessingAgent",
    'Refund Processed' AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Amount Applied" * -1 AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo' AND "Receivables - Transactions Real Time"."Receipt Application Details"."GL Date" IS NOT NULL
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Customer Notified' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires integration with a notification or CRM system.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Return Case Closed' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Closed' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Rejected' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" IN ('Canceled', 'Rejected') AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Sales - CRM All Lines"."Order"."Return Reference Order Number" AS "ReturnCaseId",
    'Exchange Order Created' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Order"."Creation Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Order"."Created By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Order"."Header Status" AS "ReturnStatus",
    "Sales - CRM All Lines"."Order"."Order Amount" AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    "Sales - CRM All Lines"."Order"."Return Reason" AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Return Reference Order Number" IS NOT NULL
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'

Passaggi

Verifichi che nel Suo ambiente siano disponibili Oracle BI Cloud Connector, le Subject Areas o i View Object SCM richiesti, la distribuzione verso il cloud storage e le origini dati necessarie di Oracle Fusion SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, pagamenti e comunicazioni. Confermi le autorizzazioni con l'amministratore Oracle.
Individui i View Object BICC configurati che contengono le informazioni relative all'intestazione del reso, alla cronologia delle approvazioni, alle transazioni di ricezione, ai record di ispezione, alle transazioni di destinazione, alle Credit Memo, ai rimborsi, agli ordini di sostituzione, alle notifiche e alla chiusura. RmaHeaderAll è un esempio di View Object per l'intestazione del reso. Sostituisca ogni riferimento all'origine tra parentesi quadre nello script di estrazione con il View Object corrispondente o con l'estrazione disponibile nel Suo ambiente.
Configuri un job di estrazione BICC per i View Object richiesti. Selezioni un'estrazione incrementale o completa in base ai campi di tracciamento delle modifiche disponibili, configuri la distribuzione verso il cloud storage e imposti la finestra di estrazione con le date di inizio e fine richieste. Utilizzi [Configure based on your system] quando il nome del job BICC, la posizione di archiviazione o la configurazione del View Object differiscono.
Estragga i dati di origine nel cloud storage. Conservi gli identificativi di origine, i timestamp degli eventi, i valori degli stati, gli identificativi degli utenti o degli agenti, gli importi monetari, i motivi dei resi, le date SLA e il timestamp di aggiornamento BICC. Non sovrascriva i timestamp di origine durante il consolidamento dei file.
Carichi i file distribuiti in un'area di staging. Standardizzi i nomi delle colonne di origine in ReturnCaseId, ActivityName, EventTime, SourceSystem, LastDataUpdate, EndTime, ProcessingAgent, ReturnStatus, RequestedRefundAmount, ActualRefundAmount, ReturnReason e RefundSlaTargetDate. Converta i timestamp in un unico fuso orario concordato e conservi separatamente il fuso orario originale, se necessario.
Applichi le regole degli eventi definite nello script di estrazione. Ogni regola deve generare una riga di evento separata. Le modifiche di stato utilizzate per le attività dedotte devono basarsi sulla cronologia degli stati pertinente o su un timestamp affidabile dell'ultimo aggiornamento. Non si affidi esclusivamente allo stato corrente quando sono necessarie modifiche storiche, poiché in tal modo ometterebbe gli eventi precedenti.
Unisca tutte le righe di evento specifiche delle attività, rimuova esclusivamente i record duplicati esatti creati da consegne ripetute dell'origine e conservi gli eventi ripetuti legittimi quando i record di origine rappresentano occorrenze aziendali distinte. Verifichi che ReturnCaseId sia valorizzato per ogni riga di evento.
Arricchisca ogni evento con gli attributi a livello di caso più recenti disponibili, preservando i valori specifici dell'evento quando presenti. Valorizzi SourceSystem con Oracle Fusion SCM o con il nome dell'origine configurata e LastDataUpdate con il timestamp di estrazione BICC o di aggiornamento dell'origine.
Esegua i controlli di convalida descritti di seguito. Confermi la presenza di tutti i 15 nomi di attività richiesti, verifichi che i timestamp rientrino nella finestra di estrazione o in una finestra operativa esplicitamente documentata e controlli che le attività terminali siano coerenti con lo stato finale del reso.
Esporti l'Event Log risultante in formato CSV o in un altro formato supportato da ProcessMind. Includa una riga per evento e le colonne esatte ReturnCaseId, ActivityName, EventTime, SourceSystem e LastDataUpdate, insieme agli attributi consigliati quando disponibili. Carichi il file in ProcessMind e associ ReturnCaseId all'identificativo del caso, ActivityName all'attività ed EventTime al timestamp dell'evento.

Configurazione

Metodo di estrazione: configuri Oracle BI Cloud Connector per la distribuzione massiva dei View Object SCM e correlati richiesti verso il cloud storage. Il job BICC esatto, il percorso di archiviazione e la disponibilità dei View Object dipendono dall'ambiente Oracle Fusion.
Oggetti di origine: RmaHeaderAll può fornire le informazioni sull'intestazione del reso. I dati relativi a cronologia delle approvazioni, ricezione, ispezione, destinazione, Credit Memo, rimborso, sostituzione, notifica e chiusura potrebbero richiedere View Object aggiuntivi o estrazioni distribuite. Utilizzi [Your view object name] quando l'origine corrispondente non è stata confermata.
Intervallo di date: inizi con un periodo di 3-6 mesi. Ampli l'intervallo solo dopo aver convalidato il volume, la disponibilità degli stati storici e la capacità del cloud storage. Utilizzi una finestra di sovrapposizione per i caricamenti incrementali, così da acquisire gli aggiornamenti ricevuti in ritardo.
Estrazione incrementale: preferisca un timestamp documentato delle modifiche o un meccanismo incrementale supportato da BICC. Se sono disponibili solo dati sullo stato corrente, non è possibile ricostruire in modo affidabile gli eventi storici dedotti.
Filtri: applichi filtri per azienda, Business Unit, organizzazione di inventario, tipo di documento, tipo di reso, tipo di ordine, unità operativa e stato solo quando i relativi campi e significati aziendali sono stati confermati. Utilizzi [Company-specific filter] e [Document type filter] per i predicati specifici dell'ambiente.
Timestamp degli eventi: utilizzi il timestamp dell'evento aziendale quando disponibile. Utilizzi un timestamp di aggiornamento dello stato o del record solo per gli eventi dedotti esplicitamente documentati e registri la regola di derivazione nel dizionario dati.
Deduplicazione: deduplichi per ReturnCaseId, ActivityName, EventTime, identificativo dell'evento di origine e sistema di origine, quando disponibili. Non accorpi eventi distinti di ricezione, ispezione o pagamento solo perché condividono lo stesso identificativo del caso.
Prestazioni: suddivida l'estrazione per intervallo di date, Business Unit, organizzazione di inventario o un'altra partizione supportata dall'origine. Eviti estrazioni complete senza restrizioni durante l'orario lavorativo negli ambienti ad alto volume. Monitori la durata dei job BICC, le dimensioni dei file, la capacità del cloud storage e le prestazioni dello staging a valle.
Prerequisiti: confermi l'accesso a BICC, l'accesso al cloud storage, i ruoli Oracle Fusion richiesti, l'accesso ai dati pertinenti di SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, pagamenti e comunicazioni, nonché le eventuali licenze necessarie per la reportistica o l'integrazione.
Sicurezza: utilizzi credenziali approvate e cloud storage cifrato. Limiti le estrazioni agli attributi minimi necessari e applichi le policy aziendali di conservazione e accesso.
Disponibilità delle origini: alcune attività, in particolare la spedizione al cliente, l'avvio dell'ispezione, l'avvio del rimborso e la notifica al cliente, potrebbero richiedere dati esterni relativi a corrieri, magazzino, pagamenti o comunicazioni. Utilizzi [Configure based on your system] quando tali origini non vengono distribuite da BICC.

a Query di esempio sql

WITH
source_data AS (
    SELECT
        r.return_case_id,
        r.created_timestamp,
        r.approval_submitted_timestamp,
        r.approved_timestamp,
        r.customer_shipped_timestamp,
        r.item_received_timestamp,
        r.inspection_started_timestamp,
        r.inspected_timestamp,
        r.disposition_determined_timestamp,
        r.credit_memo_created_timestamp,
        r.refund_initiated_timestamp,
        r.refund_processed_timestamp,
        r.customer_notified_timestamp,
        r.closed_timestamp,
        r.rejected_timestamp,
        r.exchange_order_created_timestamp,
        r.end_timestamp,
        r.processing_agent,
        r.return_status,
        r.requested_refund_amount,
        r.actual_refund_amount,
        r.return_reason,
        r.refund_sla_target_date,
        r.last_data_update
    FROM [Your configured return event source] r
    WHERE r.last_data_update >= [Start date parameter]
      AND r.last_data_update < [End date parameter]
      AND ([Company-specific filter])
),
events AS (
    SELECT return_case_id AS ReturnCaseId, 'RMA Created' AS ActivityName, created_timestamp AS EventTime, 'Oracle Fusion SCM' AS SourceSystem, last_data_update AS LastDataUpdate, end_timestamp AS EndTime, processing_agent AS ProcessingAgent, return_status AS ReturnStatus, requested_refund_amount AS RequestedRefundAmount, actual_refund_amount AS ActualRefundAmount, return_reason AS ReturnReason, refund_sla_target_date AS RefundSlaTargetDate FROM source_data WHERE created_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Approval Submitted', approval_submitted_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE approval_submitted_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Approved', approved_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE approved_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Shipped By Customer', customer_shipped_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE customer_shipped_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Received', item_received_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE item_received_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Inspection Started', inspection_started_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE inspection_started_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Inspected', inspected_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE inspected_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Return Disposition Determined', disposition_determined_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE disposition_determined_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Credit Memo Created', credit_memo_created_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE credit_memo_created_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Refund Initiated', refund_initiated_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE refund_initiated_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Refund Processed', refund_processed_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE refund_processed_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Customer Notified', customer_notified_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE customer_notified_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Return Case Closed', closed_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE closed_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Rejected', rejected_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE rejected_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Exchange Order Created', exchange_order_created_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE exchange_order_created_timestamp IS NOT NULL
)
SELECT
    ReturnCaseId,
    ActivityName,
    EventTime,
    SourceSystem,
    LastDataUpdate,
    EndTime,
    ProcessingAgent,
    ReturnStatus,
    RequestedRefundAmount,
    ActualRefundAmount,
    ReturnReason,
    RefundSlaTargetDate
FROM events
WHERE ReturnCaseId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY ReturnCaseId, EventTime, ActivityName;

Passaggi

Configurare l'ambiente Python: verifichi che Python 3.6 o una versione successiva sia installato. Installi le librerie necessarie utilizzando pip: pip install requests pandas.
Configurare l'accesso a Oracle Fusion SCM: ottenga le credenziali di un utente Oracle Fusion con i ruoli necessari per accedere alle API REST. In genere sono richiesti i ruoli Order Manager e Accounts Receivable Manager. L'utente deve disporre delle autorizzazioni per visualizzare gli ordini di vendita (RMA) e le note di credito clienti.
Identificare gli endpoint API: verifichi l'URL di base della Sua istanza Oracle Fusion SCM. Lo script utilizza le risorse REST salesOrdersForOrderHub e receivablesCreditMemos. Potrebbe essere necessario modificare la versione 11.13.18.05 in base al Suo ambiente.
Personalizzare lo script Python: apra lo script Python fornito. Aggiorni le variabili segnaposto all'inizio dello script: ORACLE_BASE_URL, ORACLE_USERNAME e ORACLE_PASSWORD. Modifichi la variabile RMA_ORDER_TYPE in modo che corrisponda al codice del tipo di ordine utilizzato per gli RMA nel Suo sistema.
Definire il periodo di estrazione: modifichi nello script le variabili START_DATE e END_DATE per definire l'intervallo temporale dell'estrazione dati. È consigliabile iniziare con un periodo più breve, ad esempio un mese, per testare lo script.
Eseguire lo script: esegua lo script dalla riga di comando: python extract_oracle_returns.py. Lo script si connetterà alle API Oracle, recupererà i dati, li elaborerà e visualizzerà gli aggiornamenti di stato nella console.
Recuperare l'Event Log: al termine dell'esecuzione, se completata correttamente, lo script genererà nella stessa directory un file denominato returns_event_log.csv. Il file contiene l'Event Log estratto.
Verificare e preparare il caricamento: apra il file returns_event_log.csv con un'applicazione per fogli di calcolo. Verifichi che i dati siano completi e corretti, prestando particolare attenzione alle colonne ActivityName e EventTime. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti del Suo strumento di Process Mining.
Caricare i dati in ProcessMind: carichi direttamente in ProcessMind il file CSV generato. Mappi le colonne del file CSV sui relativi attributi in ProcessMind (ReturnCaseId su Case ID, ActivityName su Activity, EventTime su Timestamp).

Configurazione

Endpoint API: lo script utilizza principalmente due endpoint API REST: /fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub per i dati degli ordini RMA e /fscmRestApi/resources/11.13.18.05/receivablesCreditMemos per i dati finanziari relativi ai rimborsi.
Autenticazione: lo script utilizza l'autenticazione di base. Il nome utente e la password forniti devono appartenere a un account utente con accesso alle API e privilegi sufficienti per leggere i dati relativi agli ordini e ai crediti clienti.
Intervallo di date: l'estrazione viene filtrata in base alla CreationDate degli ordini RMA. Configuri nello script le variabili START_DATE e END_DATE. Per i caricamenti iniziali è consigliato un periodo di 3-6 mesi. Per gli aggiornamenti ricorrenti, utilizzi una finestra temporale mobile.
Filtro del tipo di ordine RMA: è fondamentale configurare nello script la variabile RMA_ORDER_TYPE. In questo modo verranno estratti esclusivamente gli ordini di reso, escludendo gli ordini di vendita standard. Il codice specifico del tipo di ordine RMA è disponibile nell'attività di configurazione 'Manage Order Types' di Oracle Fusion.
Mappatura dei codici di stato: lo script associa i codici di stato interni di Oracle, ad esempio DOO_AWAITING_RECEIVING e DOO_CLOSED, ai valori di ActivityName comprensibili per l'azienda. Potrebbe essere necessario personalizzare questa mappatura in base alla configurazione specifica di Oracle SCM.
Prerequisiti: è necessario disporre dell'accesso a un ambiente Oracle Fusion SCM. L'account utente utilizzato per l'estrazione deve avere ruoli come Order Manager (ORA_DOO_ORDER_MANAGER_JOB) e Accounts Receivable Manager (ORA_AR_ACCOUNTS_RECEIVABLE_MANAGER_JOB), oppure ruoli personalizzati equivalenti che garantiscano l'accesso alle API REST richieste.

a Query di esempio python

import requests
import pandas as pd
from datetime import datetime
import json

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
ORACLE_BASE_URL = class="hl-string">"https://[your_oracle_fusion_instance].fa.ocs.oraclecloud.com"
ORACLE_USERNAME = class="hl-string">"[your_api_user]"
ORACLE_PASSWORD = class="hl-string">"[your_api_password]"
RMA_ORDER_TYPE = class="hl-string">"ORA_RETURN_ORDER"  class=class="hl-string">"hl-comment"># IMPORTANT: Configure with your specific RMA Order Type Code
START_DATE = class="hl-string">"2023-01-01T00:00:00.000Z" class=class="hl-string">"hl-comment"># Format: YYYY-MM-DDTHH:MM:SS.sssZ
END_DATE = class="hl-string">"2023-06-30T23:59:59.000Z"

class=class="hl-string">"hl-comment"># --- Helper Functions --- #
def get_paginated_data(endpoint, params):
    class="hl-string">"""Fetches all data from a paginated Oracle REST API endpoint."""
    all_items = []
    url = fclass="hl-string">"{ORACLE_BASE_URL}{endpoint}"
    params[class="hl-string">'limit'] = 200 class=class="hl-string">"hl-comment"># Max limit can be up to 500
    params[class="hl-string">'offset'] = 0

    while True:
        print(fclass="hl-string">"Fetching data from {url} with offset {params['offset']}...")
        try:
            response = requests.get(url, auth=(ORACLE_USERNAME, ORACLE_PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            items = data.get(class="hl-string">'items', [])
            if not items:
                break
            all_items.extend(items)
            if data.get(class="hl-string">'hasMore', False):
                params[class="hl-string">'offset'] += len(items)
            else:
                break
        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
        except json.JSONDecodeError as e:
            print(fclass="hl-string">"JSON Decode Error: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
    return all_items

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #
if __name__ == class="hl-string">"__main__":
    event_log_records = []
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch all RMA Orders
    print(class="hl-string">"Fetching RMA orders...")
    rma_params = {
        class="hl-string">'finder': class="hl-string">'findOrders',
        class="hl-string">'q': fclass="hl-string">"OrderTypeCode='{RMA_ORDER_TYPE}' and CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">'fields': class="hl-string">'OrderNumber,CreationDate,CreatedBy,LastUpdateDate,LastUpdatedBy,OrderStatus,ReturnReasonCode,CrossReference,lines',
        class="hl-string">'expand': class="hl-string">'lines.fulfillmentLines'
    }
    rma_orders = get_paginated_data(class="hl-string">"/fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub", rma_params)

    class=class="hl-string">"hl-comment"># 2. Fetch all related Credit Memos (can be optimized by filtering on creation date)
    print(class="hl-string">"Fetching Credit Memos...")
    cm_params = {
        class="hl-string">'fields': class="hl-string">'TransactionNumber,TransactionDate,Amount,CustomerTransactionId,SalesOrderNumber'
    }
    credit_memos = get_paginated_data(class="hl-string">"/fscmRestApi/resources/11.13.18.05/receivablesCreditMemos", cm_params)
    cm_map = {cm[class="hl-string">'SalesOrderNumber']: cm for cm in credit_memos if class="hl-string">'SalesOrderNumber' in cm}

    print(fclass="hl-string">"Processing {len(rma_orders)} RMA orders...")
    for rma in rma_orders:
        case_id = rma.get(class="hl-string">'OrderNumber')
        if not case_id:
            continue

        class=class="hl-string">"hl-comment"># Helper to add events
        def add_event(activity, timestamp, agent, status, reason=None, end_time=None):
            if timestamp:
                event_log_records.append({
                    class="hl-string">'ReturnCaseId': case_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': timestamp,
                    class="hl-string">'EndTime': end_time if end_time else timestamp,
                    class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion SCM',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'ProcessingAgent': agent,
                    class="hl-string">'ReturnStatus': status,
                    class="hl-string">'ReturnReason': reason,
                    class="hl-string">'RequestedRefundAmount': None, class=class="hl-string">"hl-comment"># Placeholder
                    class="hl-string">'ActualRefundAmount': None, class=class="hl-string">"hl-comment"># Placeholder
                    class="hl-string">'RefundSlaTargetDate': None class=class="hl-string">"hl-comment"># Placeholder
                })

        class=class="hl-string">"hl-comment"># Activity: RMA Created
        add_event(class="hl-string">'RMA Created', rma.get(class="hl-string">'CreationDate'), rma.get(class="hl-string">'CreatedBy'), class="hl-string">'Draft', rma.get(class="hl-string">'ReturnReasonCode'))

        class=class="hl-string">"hl-comment"># Activities from Fulfillment Lines
        if class="hl-string">'lines' in rma and rma[class="hl-string">'lines']:
            for line in rma[class="hl-string">'lines'][class="hl-string">'items']:
                if class="hl-string">'fulfillmentLines' in line and line[class="hl-string">'fulfillmentLines']:
                    for ff_line in line[class="hl-string">'fulfillmentLines'][class="hl-string">'items']:
                        ff_status = ff_line.get(class="hl-string">'StatusCode')
                        last_update = ff_line.get(class="hl-string">'LastUpdateDate', rma.get(class="hl-string">'LastUpdateDate'))
                        agent = ff_line.get(class="hl-string">'LastUpdatedBy', rma.get(class="hl-string">'LastUpdatedBy'))

                        class=class="hl-string">"hl-comment"># The following is an inference based on typical status flows.
                        class=class="hl-string">"hl-comment"># Your specific statuses may vary.
                        if ff_status in [class="hl-string">'DOO_AWAIT_APPROVAL', class="hl-string">'DOO_SUBMITTED']:
                            add_event(class="hl-string">'RMA Approval Submitted', last_update, agent, ff_status)
                        elif ff_status == class="hl-string">'DOO_AWAIT_RECEIVING':
                            add_event(class="hl-string">'RMA Approved', last_update, agent, ff_status)
                        elif ff_status in [class="hl-string">'DOO_PARTIALLY_FULFILLED', class="hl-string">'DOO_SHIPMENT_CONFIRMED']:
                             add_event(class="hl-string">'Item Received', ff_line.get(class="hl-string">'ActualShipDate', last_update), agent, ff_status)
                             class=class="hl-string">"hl-comment"># Infer inspection events based on receipt
                             add_event(class="hl-string">'Item Inspection Started', ff_line.get(class="hl-string">'ActualShipDate', last_update), agent, class="hl-string">'Awaiting Inspection')
                             add_event(class="hl-string">'Item Inspected', last_update, agent, class="hl-string">'Inspection Complete')
                        elif ff_status == class="hl-string">'DOO_AWAIT_BILLING':
                            add_event(class="hl-string">'Return Disposition Determined', last_update, agent, ff_status)
                        elif ff_status == class="hl-string">'DOO_CLOSED':
                            add_event(class="hl-string">'Return Case Closed', last_update, agent, ff_status)
                        elif ff_status in [class="hl-string">'DOO_CANCELED', class="hl-string">'DOO_REJECTED']:
                            add_event(class="hl-string">'RMA Rejected', last_update, agent, ff_status)
                        
                        class=class="hl-string">"hl-comment"># Placeholder activities not directly available
                        add_event(class="hl-string">'Item Shipped By Customer', None, class="hl-string">'Customer', class="hl-string">'In Transit')
                        add_event(class="hl-string">'Customer Notified', None, class="hl-string">'System', class="hl-string">'Notification Sent')

        class=class="hl-string">"hl-comment"># Activity: Exchange Order Created
        if rma.get(class="hl-string">'CrossReference'):
             add_event(class="hl-string">'Exchange Order Created', rma.get(class="hl-string">'LastUpdateDate'), rma.get(class="hl-string">'LastUpdatedBy'), rma.get(class="hl-string">'OrderStatus'))

        class=class="hl-string">"hl-comment"># Activities from Credit Memos
        if case_id in cm_map:
            cm = cm_map[case_id]
            cm_date = cm.get(class="hl-string">'TransactionDate')
            cm_amount = cm.get(class="hl-string">'Amount')
            add_event(class="hl-string">'Credit Memo Created', cm_date, class="hl-string">'System', class="hl-string">'Credit Memo Issued')
            add_event(class="hl-string">'Refund Initiated', cm_date, class="hl-string">'System', class="hl-string">'Refund In Progress')
            class=class="hl-string">"hl-comment"># Assuming refund is processed shortly after creation for this example
            add_event(class="hl-string">'Refund Processed', cm_date, class="hl-string">'System', class="hl-string">'Refund Complete')

            class=class="hl-string">"hl-comment"># Update refund amounts on all events for this case
            for rec in event_log_records:
                if rec[class="hl-string">'ReturnCaseId'] == case_id:
                    rec[class="hl-string">'ActualRefundAmount'] = cm_amount
                    rec[class="hl-string">'RequestedRefundAmount'] = cm_amount class=class="hl-string">"hl-comment"># Assuming requested equals actual

    class=class="hl-string">"hl-comment"># 4. Create and Save DataFrame
    if not event_log_records:
        print(class="hl-string">"No events were generated. Check your configuration and date range.")
    else:
        df = pd.DataFrame(event_log_records)
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'], errors=class="hl-string">'coerce')
        df = df.dropna(subset=[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ReturnCaseId', class="hl-string">'EventTime'])

        class=class="hl-string">"hl-comment"># Reorder columns
        column_order = [
            class="hl-string">'ReturnCaseId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
            class="hl-string">'ProcessingAgent', class="hl-string">'ReturnStatus', class="hl-string">'ReturnReason', class="hl-string">'RequestedRefundAmount', 
            class="hl-string">'ActualRefundAmount', class="hl-string">'RefundSlaTargetDate'
        ]
        df = df[column_order]

        df.to_csv(class="hl-string">'returns_event_log.csv', index=False)
        print(class="hl-string">"Successfully created returns_event_log.csv")

Pronto a iniziare?

Utilizzi questo Template per semplificare la raccolta dei dati e ottenere indicazioni preziose sulla gestione dei resi e dei rimborsi. Inizi oggi stesso a ottimizzare il processo.

Torna alla guida al miglioramento Scarica il Template

Elimini i colli di bottiglia e ottimizzi subito la gestione dei resi e dei rimborsi

Individui le inefficienze e riduca del 30% il tempo di attraversamento in Oracle Fusion SCM.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione in meno di 5 minuti.

Il Suo Template dati per la gestione dei resi e dei rimborsi

Il Suo Template dati per la gestione dei resi e dei rimborsi

Attributi della gestione dei resi e dei rimborsi

Attività della gestione dei resi e dei rimborsi

Guide all'estrazione

Esportazione da Oracle Transactional Business Intelligence (OTBI)

Passaggi

Configurazione

a Query di esempio sql

Estrazione di View Object tramite Oracle BI Cloud Connector (BICC)

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza le API REST di Oracle Fusion SCM

Passaggi

Configurazione

a Query di esempio python

Pronto a iniziare?

Elimini i colli di bottiglia e ottimizzi subito la gestione dei resi e dei rimborsi

Il Suo Template dati per la gestione dei resi e dei rimborsi

Il Suo Template dati per la gestione dei resi e dei rimborsi

Attributi della gestione dei resi e dei rimborsi

Attività della gestione dei resi e dei rimborsi

Guide all'estrazione

Esportazione da Oracle Transactional Business Intelligence (OTBI)

Passaggi

Configurazione

a Query di esempio sql

Estrazione di View Object tramite Oracle BI Cloud Connector (BICC)

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza le API REST di Oracle Fusion SCM

Passaggi

Configurazione

a Query di esempio python

Pronto a iniziare?

Elimini i colli di bottiglia e ottimizzi subito la gestione dei resi e dei rimborsi

La Sua privacy è importante