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

Il template dei dati per la gestione di resi e rimborsi

Oracle Fusion SCM

Attributi per la gestione di resi e rimborsi(21) Attività per la gestione di resi e rimborsi(15) Guide all’estrazione(3)

Il template dei dati per la gestione di resi e rimborsi

Questo template è pensato per aiutarLa ad analizzare la gestione di resi e rimborsi in Oracle Fusion SCM. Indica gli attributi essenziali da raccogliere e le attività principali da monitorare, oltre a fornire istruzioni chiare per estrarre questi dati. Lo utilizzi per ottenere indicazioni utili sul processo e individuare le aree da migliorare.

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

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

Scarica il template

Attributi per la gestione di resi e rimborsi

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo la gestione di resi e rimborsi in Oracle Fusion SCM.

5 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Nome di una specifica fase o di un evento aziendale che si è verificato durante il processo di reso e rimborso.
Descrizione Questo attributo descrive una singola fase o tappa del ciclo di vita del reso, ad esempio «RMA creato», «Articolo ispezionato» o «Rimborso elaborato». Ogni attività rappresenta un momento distinto del processo, registrato negli Event Log del sistema. Analizzare la sequenza e la durata di queste attività è il fulcro del Process Mining. Consente di visualizzare le mappe di processo, individuare 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 il rispetto delle procedure operative standard. Perché è importante Le attività costituiscono la struttura portante della mappa di processo e consentono di visualizzare e analizzare il flusso, le varianti e i colli di bottiglia. Dove reperirli Ricavato dagli Event Log, dalle modifiche di stato o da specifici record di transazione nei moduli di Oracle Fusion SCM, come Order Management e Inventory Management. Esempi RMA creatoArticolo ricevutoNota di credito creataRimborso elaborato
	ID del caso di reso ReturnCaseId	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 è l’identificativo univoco del caso per l’intero processo di reso e rimborso. Collega tutti gli eventi, dalla creazione iniziale dell’autorizzazione al reso della merce (RMA) fino all’elaborazione finale del rimborso e alla chiusura del caso. Nell’analisi di Process Mining, questo attributo è fondamentale per ricostruire il percorso completo di ogni reso. Consente agli analisti di seguire l’intero ciclo di vita, misurare i tempi di ciclo totali e comprendere le differenze nella gestione dei vari resi. Tutti gli altri dati relativi agli eventi vengono raggruppati in base a questo ID per ottenere una visione unitaria del processo. Perché è importante È la chiave essenziale per riunire tutti gli eventi correlati in una singola istanza di processo e rendere possibile l’analisi end-to-end. Dove reperirli In genere, questo identificativo viene generato in Oracle Order Management o nei moduli di assistenza all’avvio di una richiesta di reso. Esempi RMA-2023-00123RMA-2023-00456RMA-2023-00789
	Ora dell’evento EventTime	Data e ora che indicano quando si è verificata una specifica attività o un evento.
Descrizione L’ora dell’evento, o ora di inizio, indica la data e l’ora esatte in cui un’attività è stata registrata nel sistema di origine. Fornisce il contesto cronologico di ogni fase del processo. Questo dato è essenziale per tutte le analisi basate sul tempo. Serve a ordinare correttamente gli eventi, calcolare i tempi di ciclo tra le attività, misurare la durata totale di un caso e valutare le prestazioni rispetto agli accordi sui livelli di servizio (SLA). Senza date e orari accurati, non è possibile analizzare l’efficienza del processo, individuare i ritardi o comprenderne le dinamiche. Perché è importante Questo attributo definisce la sequenza cronologica degli eventi, fondamentale per calcolare tutte le metriche basate sulla durata e individuare i colli di bottiglia del processo. Dove reperirli In Oracle Fusion SCM, queste informazioni si trovano in genere in campi come «Data di creazione», «Data e ora» o «Data dell’ultimo aggiornamento», associati ai record di transazione o di stato. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati.
Descrizione Questo attributo identifica il sistema informativo di origine in cui sono stati registrati i dati dell’evento. Per questo processo, in genere si tratta di «Oracle Fusion SCM». Negli ambienti con più sistemi integrati, questo campo è fondamentale per ricostruire la provenienza dei dati e risolvere i problemi. Aiuta a verificarne l’origine e può essere usato per filtrare l’analisi in base al sistema di provenienza degli eventi, mantenendo la qualità e il contesto dei dati. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, indispensabili per convalidarli e analizzarli in ambienti con più sistemi. Dove reperirli Spesso è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine del set di dati. Esempi Oracle Fusion SCMOracle SCM Cloud
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo indica quando il set di dati è stato aggiornato l’ultima volta. Fornisce la data di aggiornamento dell’intero set di dati, non dei singoli eventi. Conoscere la data dell’ultimo aggiornamento è fondamentale per interpretare correttamente l’analisi. Aiuta a capire se le Dashboard e gli indicatori KPI mostrano informazioni in tempo reale oppure dati aggiornati diverse ore o giorni prima. È un metadato essenziale per qualsiasi progetto di Process Mining. Perché è importante Indica quanto sono aggiornati i dati, aiutando gli utenti a interpretare il contesto e l’attualità dell’analisi. Dove reperirli Questa data e ora vengono generate e aggiunte durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Data obiettivo SLA del rimborso RefundSlaTargetDate	La data entro cui si prevede di completare il rimborso, secondo l’accordo sul livello di servizio.
Descrizione Questo attributo definisce la scadenza entro cui completare il processo di rimborso per un determinato caso. L’obiettivo SLA è spesso stabilito in base alle politiche aziendali, alla categoria del cliente o al motivo del reso. Questa data è il valore di riferimento per misurare la puntualità e la conformità. Viene utilizzata direttamente nella Dashboard «Conformità SLA delle politiche di rimborso» ed è essenziale per calcolare il KPI «Tasso di conformità allo SLA dei rimborsi». Confrontando la data effettiva di completamento del rimborso con quella obiettivo è possibile individuare le violazioni dello SLA e dare priorità ai casi a rischio di ritardo. Perché è importante Fornisce il valore di riferimento per misurare la puntualità ed è essenziale per calcolare i KPI di conformità allo SLA. Dove reperirli Può trattarsi di un campo data specifico nel caso di reso oppure di una data da ricavare 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 che il cliente ha inizialmente richiesto per il reso.
Descrizione Questo attributo registra l’importo del rimborso richiesto dal cliente all’inizio del processo. Costituisce la base di riferimento per il confronto con il rimborso effettivo. Questo dato è essenziale per la Dashboard «Importi dei rimborsi richiesti ed effettivi» e per il KPI «Tasso di discrepanza degli importi dei rimborsi». Analizzando la differenza tra gli importi richiesti e quelli effettivi è possibile individuare problemi come resi di articoli errati, spese di reintegro o modifiche alle politiche aziendali, ottenendo indicazioni utili sulla precisione finanziaria e sulla soddisfazione dei clienti. Perché è importante Costituisce la base di riferimento per l’analisi finanziaria, consentendo di calcolare le discrepanze nei rimborsi e di individuare potenziali problemi. Dove reperirli Questo valore dovrebbe essere registrato nell’intestazione della richiesta RMA o di reso in Oracle Fusion SCM, probabilmente nel modulo Order Management. Esempi 129.9945.501200.00
	Importo effettivo del rimborso ActualRefundAmount	L’importo finale effettivamente elaborato e rimborsato al cliente.
Descrizione Questo attributo indica l’importo finale confermato, restituito al cliente dopo aver applicato tutte le verifiche, le rettifiche e le commissioni. Rappresenta l’esito finanziario effettivo del caso di reso. È un dato finanziario fondamentale per la Dashboard «Importi dei rimborsi richiesti ed effettivi». Il confronto con l’importo richiesto è essenziale per calcolare il KPI «Tasso di discrepanza degli importi dei rimborsi» e comprendere l’impatto finanziario delle politiche di reso, delle condizioni degli articoli e delle rettifiche applicate durante l’elaborazione. Perché è importante Rappresenta l’esito finanziario effettivo del reso e consente di analizzare le discrepanze e redigere rendicontazioni finanziarie. Dove reperirli Queste informazioni provengono probabilmente dalla nota di credito o dalle registrazioni delle transazioni di contabilità fornitori 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, in genere selezionato dal cliente da un elenco predefinito, ad esempio «Articolo difettoso», «Taglia errata» o «Non più necessario». L’analisi dei motivi di reso offre indicazioni utili sulla qualità dei prodotti, sulla precisione del processo di vendita e sul comportamento dei clienti. Questi dati permettono di individuare i prodotti con un’elevata percentuale di difetti, migliorare le descrizioni per ridurre gli ordini errati e comprendere le cause profonde dei resi. I risultati dell’analisi possono orientare interventi mirati per ridurre il volume complessivo dei resi. Perché è importante Fornisce indicazioni essenziali sui motivi dei resi e può orientare miglioramenti dei prodotti e dei processi di vendita. Dove reperirli In genere è memorizzato come codice o campo di testo nella riga dell’articolo RMA in Oracle Order Management. Esempi DifettosoArticolo spedito erratoArrivato troppo tardiPrezzo più conveniente disponibile
	Operatore che ha elaborato il reso ProcessingAgent	Utente o operatore responsabile dell’esecuzione di una specifica attività nel processo di reso.
Descrizione Questo attributo identifica il dipendente o l’utente di sistema che ha svolto una determinata attività, ad esempio approvare un RMA o elaborare un rimborso. Può anche indicare un team o un reparto, se non vengono registrate le assegnazioni individuali. Analizzare le prestazioni per operatore è fondamentale per la gestione operativa. Questo attributo alimenta la Dashboard «Prestazioni degli operatori addetti all’elaborazione dei resi», che consente di confrontare il carico di lavoro, la durata delle attività e i tassi di rilavorazione dei diversi operatori. Queste informazioni possono evidenziare esigenze di formazione, individuare le prestazioni migliori e orientare una distribuzione più efficace delle risorse. Perché è importante Consente di analizzare le prestazioni per utente o team, individuare chi ottiene i risultati migliori, le opportunità di formazione e gli squilibri nel carico di lavoro. Dove reperirli In genere, si trova in campi come «USER_ID», «PROCESSED_BY» o «AGENT_NAME» nei log delle transazioni di Oracle Fusion SCM. Esempi j.doea.smithm.jones
	Ora di fine EndTime	Data e ora che indicano quando un’attività è stata completata.
Descrizione L’ora di fine indica il completamento di un’attività. Mentre StartTime indica quando è iniziato un evento, l’ora di fine serve a calcolare il tempo effettivo di elaborazione di quell’evento. Per gli eventi istantanei, StartTime e l’ora di fine possono coincidere. In fase di analisi, la differenza tra l’ora di fine e StartTime corrisponde al «Tempo di elaborazione» di un’attività. Questo dato è fondamentale per individuare le fasi che richiedono più tempo, distinguendole dalle attese tra una fase e l’altra. È essenziale per un’analisi dettagliata dei colli di bottiglia e per calcolare l’efficienza delle risorse. Perché è importante Questo attributo è necessario per calcolare il tempo effettivo di elaborazione delle singole attività e distinguere il tempo di lavoro attivo dalle attese. Dove reperirli Può essere un campo separato nei log del sistema di origine oppure si può ricavare da StartTime dell’attività successiva. Esempi 2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
	Stato del reso ReturnStatus	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 «Chiuso - rimborsato», «Chiuso - rifiutato» o «In corso». Lo stato del reso è fondamentale per analizzare e monitorare gli esiti. Consente di filtrare i casi in base al risultato, confrontare i flussi dei resi approvati con quelli dei resi rifiutati e alimentare la Dashboard «Stato attuale dei casi di reso». Comprendere la distribuzione degli esiti è essenziale per misurare l’efficacia del processo. Perché è importante Indica l’esito di un caso, dato essenziale per filtrare i dati, effettuare confronti e comprendere il tasso di successo del processo. Dove reperirli Di solito è disponibile in un campo di stato del record principale dell’intestazione del reso o dell’RMA in Oracle Order Management. Esempi In attesa di ricezioneIspezione completataChiuso - rimborsatoChiuso - respinto
	Codice di destinazione DispositionCode	Un codice che indica la destinazione finale dell’articolo fisico restituito.
Descrizione Il codice di destinazione specifica cosa è accaduto al prodotto restituito dopo l’ispezione: ad esempio, se è stato reintegrato nelle scorte, rottamato, inviato per la ricondizionatura o restituito al fornitore. Queste informazioni sono utili 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. Il dato collega il processo di reso agli esiti di magazzino e finanziari. Perché è importante Collega il processo di reso all’esito fisico dell’articolo in magazzino e fornisce indicazioni sui tassi di recupero e sui costi. Dove reperirli Queste informazioni vengono registrate 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 indicatore booleano che specifica se il rimborso è stato elaborato entro l’obiettivo SLA definito.
Descrizione Questo attributo calcolato indica in modo semplice, con un valore vero o falso, la conformità allo SLA per ciascun caso di reso. Il valore si ottiene confrontando la data e l’ora effettive di completamento del rimborso con «RefundSlaTargetDate». L’indicatore è essenziale per misurare e visualizzare facilmente i tassi di conformità. Alimenta la Dashboard «Conformità SLA delle politiche di rimborso» e semplifica il calcolo del KPI «Tasso di conformità allo SLA dei rimborsi». Consente di filtrare rapidamente i casi e analizzare le cause profonde per capire perché alcuni non rispettano lo SLA. Perché è importante Semplifica il monitoraggio e la rendicontazione dello SLA trasformando il confronto tra date in una semplice metrica booleana. Dove reperirli Campo calcolato. Il valore è vero se la data e l’ora di «Refund Processed» sono uguali o precedenti a «RefundSlaTargetDate»; in caso contrario, è falso. Esempi truefalse
	Discrepanza dell’importo del rimborso RefundAmountDiscrepancy	La differenza calcolata tra l’importo del rimborso richiesto e quello effettivo.
Descrizione Questa metrica quantifica la differenza in denaro tra l’importo richiesto dal cliente e quello ricevuto. Si calcola sottraendo «ActualRefundAmount» da «RequestedRefundAmount». Questo valore calcolato costituisce la base del KPI «Tasso di discrepanza degli importi dei rimborsi». Un valore diverso da zero indica che durante il processo è stata applicata una rettifica. Analizzare i motivi di queste discrepanze, come le spese di reintegro o le trattenute per danni, può fornire indicazioni sull’efficacia delle politiche e sulla comunicazione con i clienti. Perché è importante Quantifica le rettifiche finanziarie applicate durante il processo di rimborso e aiuta ad analizzare l’impatto delle politiche e degli esiti delle ispezioni. Dove reperirli Campo calcolato: «RequestedRefundAmount» - «ActualRefundAmount». Esempi 0.005.50-10.00
	È una rilavorazione IsRework	Un indicatore booleano che specifica se un’attività fa parte di un ciclo di rilavorazione.
Descrizione Questo indicatore identifica le attività che ripetono passaggi precedenti dello stesso caso, segnalando un ciclo del processo o una rilavorazione. Ad esempio, se un articolo non supera l’ispezione e deve essere controllato di nuovo, il secondo evento di ispezione viene contrassegnato come rilavorazione. Questo attributo è fondamentale per quantificare le inefficienze 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 delle rilavorazioni è uno degli obiettivi principali del Process Mining, perché permette di rilevare direttamente sprechi di lavoro, ritardi e costi aggiuntivi. Perché è importante Segnala direttamente le inefficienze e i cicli del processo, facilitando la quantificazione e l’analisi delle cause delle rilavorazioni. Dove reperirli È un attributo calcolato, individuato dagli algoritmi del software di Process Mining che rilevano le attività ripetute all’interno di un singolo caso. Esempi truefalse
	ID cliente CustomerId	L’identificativo univoco del cliente che ha avviato il reso.
Descrizione Questo attributo è l’ID univoco del cliente associato al caso di reso. Collega il processo di reso al database dei clienti. L’analisi dei resi dal punto di vista del cliente può rivelare tendenze importanti. Ad esempio, può aiutare a individuare clienti che effettuano resi con frequenza insolitamente elevata, un possibile segnale di insoddisfazione o di frode. Consente inoltre di analizzare i dati per segmento di clientela e capire se determinati gruppi presentano comportamenti diversi. Perché è importante Consente di analizzare i resi dal punto di vista del cliente, individuare chi restituisce spesso gli articoli, segmentare i comportamenti e rilevare potenziali frodi. Dove reperirli Si trova come ID cliente o ID parte 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 il luogo fisico specifico, 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 di prestazioni specifici di una sede. Consente di confrontare i tempi di ispezione, gli esiti di destinazione e i tempi di ciclo complessivi tra strutture diverse. Può mettere in luce inefficienze operative, problemi di organico o necessità di formazione in determinate sedi. Perché è importante Consente di analizzare le prestazioni per sede e individuare colli di bottiglia e inefficienze specifici di una regione o di una struttura. Dove reperirli 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 è l’identificativo univoco, ad esempio un codice SKU o un numero articolo, del prodotto specifico oggetto del reso. Collega il processo di reso al catalogo dei prodotti. L’analisi a livello di prodotto è fondamentale per individuare gli articoli problematici. Filtrando o suddividendo l’analisi del processo in base all’ID prodotto, le aziende possono identificare i prodotti con un’elevata percentuale di resi, tempi di ispezione lunghi o specifici tipi di difetti. Queste informazioni sono importanti per il controllo qualità, la gestione della catena di approvvigionamento e lo sviluppo dei prodotti. Perché è importante Collega il processo di reso a prodotti specifici e consente di analizzare la qualità dei prodotti e le tendenze dei resi. Dove reperirli Potrebbe corrispondere al campo «INVENTORY_ITEM_ID» o a un campo simile nella riga dell’articolo 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 autorizzazione al reso della merce.
Descrizione Il numero RMA è un’autorizzazione formale che consente al cliente di restituire un prodotto. Spesso coincide con l’ID del caso di reso, ma in alcuni sistemi può essere un identificativo distinto, assegnato in precedenza. 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 nelle comunicazioni relative al reso. Perché è importante Funge da numero di riferimento aziendale principale, essenziale per il monitoraggio operativo e le comunicazioni con i clienti. Dove reperirli È l’identificativo principale dell’oggetto Return Merchandise Authorization in Oracle Order Management. Esempi 789001789002789003
	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 corso. Il flusso del processo e i passaggi richiesti possono variare notevolmente a seconda che il cliente riceva un rimborso in denaro, un prodotto sostitutivo o un articolo riparato. L’analisi del processo per tipo di reso è essenziale per comprenderne le varianti. Consente di creare mappe di processo distinte per rimborsi e sostituzioni, individuando i colli di bottiglia e le caratteristiche prestazionali specifiche di ciascun percorso. Questa segmentazione è fondamentale per interventi mirati di miglioramento dei processi. Perché è importante Consente di suddividere l’analisi in base ai diversi percorsi del processo, poiché sostituzioni e rimborsi seguono spesso passaggi differenti. Dove reperirli In genere è un campo categoria o tipo nell’intestazione o nella riga RMA in Oracle Order Management. Esempi RimborsoSostituzioneRiparazione

Obbligatorio Consigliato Facoltativo

Attività per la gestione di resi e rimborsi

Questi sono i passaggi e i traguardi principali da registrare nell’Event Log per individuare con precisione il processo e i colli di bottiglia.

7 Consigliato 8 Facoltativo

	Attività	Descrizione
	Articolo ispezionato	Questa attività indica il completamento dell’ispezione dell’articolo e la registrazione della valutazione della qualità. In genere, è una transazione esplicita in Oracle Inventory Management o Quality Management che aggiorna lo stato dell’RMA.
Perché è importante L’esito dell’ispezione determina direttamente le fasi successive, come l’approvazione o il rifiuto del rimborso. La durata dell’ispezione è un indicatore chiave dell’efficienza del magazzino. Dove reperirli Si ricava dalla data e ora della transazione registrata quando l’ispettore completa l’attività di ispezione sulla ricezione dell’RMA in Oracle Inventory o Quality Management. Acquisizione Utilizzare la data e l’ora di completamento della transazione di ispezione. Tipo di evento explicit
	Articolo ricevuto	Questa attività segna la ricezione fisica dell’articolo reso presso il magazzino o il centro di elaborazione. È un evento esplicito registrato 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 avvia le successive fasi di ispezione ed elaborazione. Misurare il tempo tra «RMA approvato» e «Articolo ricevuto» aiuta ad analizzare le prestazioni logistiche e di spedizione. Dove reperirli È una transazione esplicita registrata in Oracle Inventory Management. L’evento corrisponde alla data della transazione di ricezione dell’RMA. Acquisizione Utilizzare la data e l’ora della transazione di ricezione dell’RMA in Inventory. Tipo di evento explicit
	Caso di reso chiuso	È l’attività finale, che indica il completamento di tutte le operazioni relative all’RMA, comprese la ricezione, la definizione della destinazione e la liquidazione finanziaria. Si deduce dallo stato finale «Chiuso» dell’ordine RMA.
Perché è importante Questo evento segna la conclusione definitiva del processo ed è fondamentale per calcolare il tempo di ciclo end-to-end e verificare che non rimangano casi aperti a tempo indeterminato. Dove reperirli Si deduce dalla data e ora in cui l’intestazione dell’ordine RMA e tutte le relative righe raggiungono lo stato finale «Chiuso» in Oracle Order Management. Acquisizione Registrare l’ultima data e ora in cui lo stato dell’intestazione o della riga dell’RMA passa a «Chiuso». Tipo di evento inferred
	Nota di credito creata	Questa attività finanziaria consiste nella creazione di una nota di credito in Accounts Receivable per autorizzare il rimborso al cliente. È un evento esplicito avviato dal processo di reso in Order Management.
Perché è importante La creazione di una nota di credito è una tappa decisiva, che indica l’impegno dell’azienda a rimborsare il cliente. Avvia l’intera fase di liquidazione finanziaria del processo. Dove reperirli È una transazione esplicita in Oracle Accounts Receivable. L’evento può essere collegato all’RMA originale tramite il riferimento all’ordine di vendita riportato nella 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à segna il completamento del pagamento del rimborso al cliente. È un evento esplicito registrato quando la transazione di compensazione del pagamento viene contabilizzata in Oracle Financials.
Perché è importante È un punto di arrivo fondamentale per misurare il tempo totale del ciclo di rimborso dal punto di vista del cliente. Conferma che l’obbligo finanziario nei confronti del cliente è stato assolto. Dove reperirli L’evento si ricava dalla data contabile o di compensazione della transazione di pagamento in Oracle Accounts Payable o Treasury, che salda la nota di credito. Acquisizione Utilizzare la data di compensazione della transazione di pagamento che salda la nota di credito. Tipo di evento explicit
	RMA approvato	Questa tappa fondamentale indica che la richiesta di reso è stata convalidata e approvata secondo le regole aziendali. In genere, si deduce da una modifica dello stato dell’RMA che consente di avviare le fasi successive, come la spedizione da parte del cliente.
Perché è importante L’approvazione è un passaggio decisivo del processo. Eventuali ritardi incidono direttamente sul tempo totale del ciclo di reso e sulla soddisfazione dei clienti. Questa attività è essenziale per analizzare i colli di bottiglia nell’approvazione. Dove reperirli Si deduce dalla data e ora in cui lo stato dell’intestazione o della riga dell’ordine RMA passa ad «Approvato» o «In attesa di ricezione». Acquisizione Registrare la data e l’ora in cui lo stato dell’RMA viene aggiornato a uno stato di approvazione. Tipo di evento inferred
	RMA creato	Questa attività segna l’avvio ufficiale del processo di reso, con la creazione di un’autorizzazione al reso della merce (RMA) in Oracle Fusion SCM. In genere, l’evento viene registrato esplicitamente quando un utente o un processo automatizzato crea un nuovo record di ordine di vendita RMA.
Perché è importante È l’evento di inizio principale dell’intero processo di reso. Analizzare il tempo che intercorre tra questa attività e le successive permette di calcolare la durata complessiva del processo e individuare eventuali ritardi iniziali. Dove reperirli L’evento si ricava dalla data e ora 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
	Articolo spedito dal cliente	Indica che il cliente ha rispedito l’articolo all’azienda. Spesso questo evento non viene registrato direttamente in Oracle SCM, ma può essere dedotto dai dati di integrazione con il corriere o da un aggiornamento manuale.
Perché è importante Questa attività fornisce informazioni sul comportamento dei clienti e sul tempo di transito della merce. Aiuta a distinguere i ritardi di elaborazione interni da quelli dovuti alla spedizione. Dove reperirli L’evento può essere dedotto dai dati di spedizione del corriere collegati all’RMA oppure da un aggiornamento manuale dello stato in Oracle SCM. Se non è disponibile un’integrazione, l’evento potrebbe non essere rilevabile. Acquisizione Data e ora provenienti dall’API del corriere integrata o da un campo compilato manualmente. Tipo di evento inferred
	Cliente informato	Indica la comunicazione inviata al cliente per confermare l’esito del caso di reso, ad esempio il rimborso elaborato o la spedizione di un articolo sostitutivo. Spesso viene registrata in un registro delle comunicazioni o tramite un aggiornamento dello stato del caso.
Perché è importante Comunicare tempestivamente con i clienti è fondamentale per la loro soddisfazione. L’analisi di questa attività aiuta a verificare il rispetto degli SLA di comunicazione. Dove reperirli È necessaria un’analisi del sistema. L’evento può essere registrato da un CRM integrato o da una piattaforma di comunicazione, oppure tramite un aggiornamento manuale dello stato dell’RMA o di una richiesta di assistenza correlata. Acquisizione Data e ora provenienti da un sistema di comunicazione esterno o da un aggiornamento manuale. Tipo di evento inferred
	Destinazione del reso determinata	Dopo l’ispezione, questa attività registra la decisione sulla destinazione dell’articolo reso, ad esempio «Rimesso a magazzino» o «Scartato». La decisione viene registrata tramite una transazione di inventario esplicita che sposta l’articolo alla destinazione finale.
Perché è importante Questo passaggio è fondamentale per l’accuratezza dell’inventario e la riconciliazione finanziaria. Analizzare le destinazioni degli articoli aiuta a comprendere i motivi dei resi e i problemi di qualità dei prodotti. Dove reperirli Dopo l’ispezione, viene registrato come transazione in Oracle Inventory Management, ad esempio un trasferimento tra sottoinventari o un aggiornamento dello stato dell’articolo. Acquisizione Rilevare la data e l’ora della transazione di inventario che registra la destinazione dell’articolo. Tipo di evento explicit
	Ispezione dell’articolo avviata	Indica l’inizio dell’ispezione fisica dell’articolo reso per valutarne le condizioni. L’evento può essere dedotto da una modifica della posizione o dello stato dell’articolo nel modulo di gestione del magazzino oppure registrato tramite una scansione esplicita.
Perché è importante Misurare il tempo tra la ricezione dell’articolo e l’inizio dell’ispezione permette di individuare le attese in coda presso la postazione di ispezione, un collo di bottiglia frequente. Dove reperirli L’evento può essere registrato tramite una modifica dello stato della riga di ricezione o una transazione che sposta l’articolo in un’area di ispezione in Oracle Inventory Management. Potrebbe essere necessaria una configurazione personalizzata per registrarlo esplicitamente. Acquisizione Data e ora della modifica dello stato o del trasferimento dell’articolo nell’area di ispezione. Tipo di evento inferred
	Ordine di sostituzione creato	Questa attività si verifica quando il cliente richiede una sostituzione anziché un rimborso. È un evento esplicito, corrispondente alla creazione di un nuovo ordine di vendita, spesso collegato all’RMA originale.
Perché è importante Questa attività identifica una variante importante del processo. Distinguere i processi di sostituzione da quelli di rimborso è essenziale per analizzare correttamente il tempo di ciclo di ciascun percorso. Dove reperirli È un evento esplicito: la 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
	Richiesta di approvazione RMA inviata	Indica il momento in cui l’RMA creato viene inviato per la revisione e l’approvazione interne. Spesso si deduce da una modifica dello stato dell’RMA, che passa da bozza o inserimento a in attesa di approvazione.
Perché è importante Monitorare questo passaggio consente di misurare la durata della fase precedente all’approvazione. Distingue il tempo di inserimento dei dati da quello effettivamente trascorso in attesa dell’intervento di un approvatore. Dove reperirli Si deduce dalla data e ora in cui lo stato dell’intestazione o della riga dell’ordine RMA passa a «In attesa di approvazione» o a uno stato equivalente nel flusso di lavoro di approvazione di Order Management. Acquisizione Individuare la data e l’ora della modifica dello stato a «In attesa di approvazione». Tipo di evento inferred
	Rimborso avviato	Questa attività indica l’avvio del pagamento del rimborso. Spesso si deduce da una modifica dello stato della nota di credito, che passa da aperta a uno stato che indica l’elaborazione del pagamento.
Perché è importante Questa attività permette di distinguere l’approvazione e la creazione della nota di credito dall’elaborazione effettiva del pagamento, che potrebbe essere gestita da un altro team o sistema e causare ritardi. Dove reperirli Si deduce da una modifica dello stato della nota di credito in Accounts Receivable oppure dalla creazione in Accounts Payable di un record di pagamento che fa riferimento alla nota di credito. Acquisizione Individuare la data e l’ora in cui lo stato della nota di credito passa a «In attesa di pagamento» o a uno stato simile. Tipo di evento inferred
	RMA rifiutato	Indica la decisione definitiva di rifiutare la richiesta di reso del cliente. In genere, si deduce da una modifica dello stato dell’RMA a «Rifiutato» o «Annullato» durante la fase di approvazione.
Perché è importante È un percorso di eccezione fondamentale. Analizzare la frequenza e i motivi dei rifiuti può far emergere problemi nelle politiche di reso, nelle aspettative dei clienti o tentativi di frode. Dove reperirli Si deduce dalla data e ora in cui lo stato dell’intestazione o della riga dell’ordine RMA passa a «Rifiutato» o a uno stato finale equivalente. Acquisizione Individuare la data e l’ora della modifica dello stato a «Rifiutato» o «Annullato». Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Oracle Fusion SCM

Passaggi

Acceda all’editor di analisi OTBI: acceda alla Sua istanza Oracle Fusion Cloud SCM. Dal menu Navigator, apra Tools, quindi selezioni Reports and Analytics. Faccia clic sul pulsante 'Create' e scelga 'Analysis' dal menu a discesa.
Selezioni le aree tematiche: nella finestra 'Select Subject Area', scelga le aree tematiche principali che contengono i dati relativi a resi e rimborsi. Selezioni "Sales - CRM All Lines" e "Receivables - Transactions Real Time". Le combinerà per ottenere una visione completa del processo.
Passi alla modalità avanzata: dopo aver selezionato le aree tematiche, si aprirà l’editor di analisi. Passi subito alla scheda 'Advanced' per accedere all’editor SQL logico, necessario per creare la struttura richiesta per l’event log.
Crei 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 contiene più clausole UNION ALL per estrarre 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 relativi a specifiche unità aziendali o tipologie di ordine di reso 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 e la struttura delle colonne rispetto alle aree tematiche selezionate.
Riveda i risultati: apra la scheda 'Results' per visualizzare un’anteprima dell’output. I dati dovrebbero essere presentati nel formato di un event log, con una riga per ogni singola attività del processo di reso. Verifichi che colonne come ReturnCaseId, ActivityName ed EventTime contengano i valori previsti.
Salvi l’analisi: quando i risultati La soddisfano, 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 di 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 processo di esportazione: nelle opzioni di pianificazione, definisca la frequenza, ad esempio giornaliera o settimanale. Nella sezione 'Delivery', imposti CSV come formato di output. Configuri la destinazione, ad esempio il server dei contenuti o un indirizzo e-mail, a cui inviare il file. Attivi la pianificazione per avviare le estrazioni automatiche.

Configurazione

Aree tematiche: le aree tematiche 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 note di credito e dei pagamenti dei rimborsi. Potrebbero essere necessarie altre aree tematiche, come "Inventory - Inventory Transactions Real Time", se servono informazioni più dettagliate su ispezioni e decisioni relative ai resi.
Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date, così da limitare il volume dei dati e garantire il completamento corretto dell’analisi. Si consiglia di estrarre i dati relativi a periodi di 3-6 mesi per volta. La query fornita filtra in base alla data di creazione dell’RMA.
Filtri principali: oltre all’intervallo di date, è opportuno filtrare per tipo di ordine, selezionando specificamente gli ordini di autorizzazione al reso (RMA). Si consiglia inoltre di filtrare per una specifica unità aziendale o entità giuridica, così da circoscrivere i dati in modo adeguato.
Modalità SQL logico: questo metodo di estrazione richiede l’uso della scheda 'Advanced' e la scrittura di una query SQL logica personalizzata con istruzioni UNION ALL. Questo approccio consente di 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 indispensabile poter accedere alle aree tematiche Sales, Receivables e, se necessario, Inventory.

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 aree tematiche o gli oggetti di visualizzazione SCM necessari, la distribuzione su cloud storage e le origini dati richieste per Oracle Fusion SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, pagamenti e comunicazioni. Verifichi le autorizzazioni con l’amministratore Oracle.
Individui gli oggetti di visualizzazione BICC configurati che contengono le informazioni su intestazioni dei resi, cronologia delle approvazioni, transazioni di ricevimento, record di ispezione, transazioni relative alla decisione sul reso, note di credito, rimborsi, ordini di sostituzione, notifiche e chiusure. RmaHeaderAll è un esempio di oggetto di visualizzazione per le intestazioni dei resi. Sostituisca ogni riferimento alla sorgente tra parentesi quadre nello script di estrazione con l’oggetto di visualizzazione corrispondente o con l’estrazione disponibile nel Suo ambiente.
Configuri un processo di estrazione BICC per gli oggetti di visualizzazione richiesti. Scelga un’estrazione incrementale o completa in base ai campi di rilevamento delle modifiche disponibili, configuri la distribuzione su cloud storage e imposti le date di inizio e fine richieste per l’intervallo di estrazione. Utilizzi [Configure based on your system] se il nome del processo BICC, la posizione di archiviazione o la configurazione degli oggetti di visualizzazione variano.
Estragga i dati sorgente nel cloud storage. Mantenga gli identificativi originali, i timestamp degli eventi, i valori di stato, gli identificativi di utenti o agenti, gli importi, i motivi del reso, le date SLA e il timestamp di aggiornamento BICC. Non sovrascriva i timestamp sorgente durante il consolidamento dei file.
Carichi i file ricevuti in un’area di staging. Uniformi i nomi delle colonne sorgente utilizzando ReturnCaseId, ActivityName, EventTime, SourceSystem, LastDataUpdate, EndTime, ProcessingAgent, ReturnStatus, RequestedRefundAmount, ActualRefundAmount, ReturnReason e RefundSlaTargetDate. Converta i timestamp in un unico fuso orario concordato e, se necessario, conservi separatamente quello originale.
Applichi le regole sugli eventi definite nello script di estrazione. Ogni regola deve generare una riga di evento distinta. Le variazioni di stato utilizzate per dedurre le attività devono basarsi sulla cronologia degli stati pertinente o su un timestamp di ultimo aggiornamento affidabile. Quando è necessario ricostruire le variazioni storiche, non si basi soltanto sullo stato attuale, perché in questo modo gli eventi precedenti verrebbero omessi.
Unisca tutte le righe di evento specifiche per attività, rimuova solo i record esattamente duplicati a causa di consegne ripetute dalla sorgente e conservi gli eventi ripetuti legittimi quando corrispondono a 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, mantenendo i valori specifici dell’evento quando presenti. Valorizzi SourceSystem con Oracle Fusion SCM o con il nome della sorgente configurata e LastDataUpdate con il timestamp di estrazione BICC o di aggiornamento della sorgente.
Esegua i controlli di convalida descritti di seguito. Verifichi la presenza di tutti i 15 nomi di attività richiesti, che i timestamp rientrino nell’intervallo di estrazione o in una finestra operativa documentata esplicitamente e 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 distribuire in blocco su cloud storage gli oggetti di visualizzazione SCM e correlati richiesti. Il processo BICC, il percorso di archiviazione e la disponibilità degli oggetti di visualizzazione dipendono dall’ambiente Oracle Fusion.
Oggetti sorgente: RmaHeaderAll può fornire informazioni sulle intestazioni dei resi. Per i dati relativi alla cronologia delle approvazioni, ai ricevimenti, alle ispezioni, alle decisioni sui resi, alle note di credito, ai rimborsi, alle sostituzioni, alle notifiche e alle chiusure potrebbero servire altri oggetti di visualizzazione o estrazioni disponibili. Utilizzi [Your view object name] se la sorgente corrispondente non è stata confermata.
Intervallo di date: inizi con 3-6 mesi di dati. Estenda l’intervallo solo dopo aver verificato il volume, la disponibilità della cronologia degli stati e la capacità del cloud storage. Per i caricamenti incrementali, utilizzi una finestra di sovrapposizione per acquisire gli aggiornamenti tardivi.
Estrazione incrementale: preferisca un timestamp di modifica documentato o un meccanismo incrementale supportato da BICC. Se sono disponibili solo dati sullo stato attuale, non è possibile ricostruire in modo affidabile gli eventi storici dedotti.
Filtri: applichi filtri per società, unità aziendale, organizzazione di inventario, tipo di documento, tipo di reso, tipo di ordine, unità operativa e stato solo dopo aver confermato i relativi campi sorgente e il loro significato aziendale. Utilizzi [Company-specific filter] e [Document type filter] per i criteri specifici dell’ambiente.
Timestamp degli eventi: utilizzi il timestamp dell’evento aziendale quando disponibile. Ricorra al timestamp di aggiornamento dello stato o del record solo per gli eventi dedotti documentati esplicitamente e registri la regola di derivazione nel dizionario dei dati.
Rimozione dei duplicati: rimuova i duplicati in base a ReturnCaseId, ActivityName, EventTime, identificativo dell’evento sorgente e sistema sorgente, quando disponibili. Non accorpi eventi distinti di ricevimento, ispezione o pagamento solo perché condividono lo stesso identificativo del caso.
Prestazioni: suddivida l’estrazione per intervallo di date, unità aziendale, organizzazione di inventario o un’altra partizione supportata dalla sorgente. Negli ambienti con volumi elevati, eviti estrazioni complete senza restrizioni durante l’orario lavorativo. Monitori la durata dei processi BICC, le dimensioni dei file, la capacità del cloud storage e le prestazioni dell’area di staging a valle.
Prerequisiti: verifichi l’accesso a BICC e al cloud storage, i ruoli Oracle Fusion necessari, l’accesso ai dati pertinenti di SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, pagamenti e comunicazioni, nonché le eventuali licenze di reporting o integrazione richieste.
Sicurezza: utilizzi credenziali approvate e cloud storage crittografato. Limiti le estrazioni agli attributi strettamente necessari e applichi le politiche aziendali di conservazione e accesso.
Disponibilità delle sorgenti: 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 provenienti da corrieri, magazzini, sistemi di pagamento o comunicazione. Utilizzi [Configure based on your system] quando BICC non fornisce queste sorgenti.

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

Configuri l’ambiente Python: verifichi di avere installato Python 3.6 o una versione successiva. Installi le librerie necessarie con pip: pip install requests pandas.
Configuri 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 dei crediti commerciali.
Individui 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.
Personalizzi lo script Python: apra lo script Python fornito e aggiorni le variabili segnaposto all’inizio del file: ORACLE_BASE_URL, ORACLE_USERNAME e ORACLE_PASSWORD. Modifichi la variabile RMA_ORDER_TYPE in modo che corrisponda al codice del tipo di ordine RMA utilizzato nel Suo sistema.
Definisca il periodo di estrazione: modifichi le variabili START_DATE e END_DATE nello script per definire l’intervallo temporale dei dati da estrarre. Per provare lo script, si consiglia di iniziare con un periodo più breve, ad esempio un mese.
Esegua lo script: avvii lo script dalla riga di comando: python extract_oracle_returns.py. Lo script si collegherà alle API Oracle, recupererà i dati, li elaborerà e mostrerà gli aggiornamenti sullo stato nella console.
Recuperi l’event log: al termine dell’esecuzione, verrà creato nella stessa cartella il file returns_event_log.csv, che contiene l’event log estratto.
Riveda i dati e li prepari per 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 ed EventTime. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti dello strumento di Process Mining utilizzato.
Carichi i dati in ProcessMind: carichi direttamente in ProcessMind il file CSV generato. Associ le colonne del file CSV agli attributi corrispondenti in ProcessMind (ReturnCaseId a ID del caso, ActivityName ad Attività, EventTime a 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 sui rimborsi.
Autenticazione: lo script utilizza l’autenticazione di base. Il nome utente e la password forniti devono appartenere a un account con accesso alle API e privilegi sufficienti per leggere i dati degli ordini e dei crediti commerciali.
Intervallo di date: l’estrazione filtra gli ordini RMA in base a CreationDate. Configuri nello script le variabili START_DATE e END_DATE. Per il caricamento iniziale si consiglia un periodo di 3-6 mesi; per gli aggiornamenti successivi, utilizzi una finestra mobile.
Filtro per tipo di ordine RMA: è fondamentale configurare nello script la variabile RMA_ORDER_TYPE, così da estrarre solo gli ordini di reso e non gli ordini di vendita standard. Può trovare il codice specifico del tipo di ordine RMA 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 Oracle SCM in uso.
Prerequisiti: è necessario accedere a un ambiente Oracle Fusion SCM. L’account utente utilizzato per l’estrazione deve disporre di ruoli quali Order Manager (ORA_DOO_ORDER_MANAGER_JOB) e Accounts Receivable Manager (ORA_AR_ACCOUNTS_RECEIVABLE_MANAGER_JOB), oppure di ruoli personalizzati equivalenti che consentano l’accesso alle API REST richieste.

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 utili sulla gestione di resi e rimborsi. Inizi oggi a ottimizzare il processo.

Torna alla guida al miglioramento

Scarica il template

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

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

Inizi la prova gratuita

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

Il template dei dati per la gestione di resi e rimborsi

Il template dei dati per la gestione di resi e rimborsi

Attributi per la gestione di resi e rimborsi

Attività per la gestione di resi e rimborsi

Guide all’estrazione

Esportazione da Oracle Transactional Business Intelligence (OTBI)

Passaggi

Configurazione

Query di esempio sql

Estrazione degli oggetti di visualizzazione con Oracle BI Cloud Connector (BICC)

Passaggi

Configurazione

Query di esempio sql

Script Python che utilizza le API REST di Oracle Fusion SCM

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

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