Il Suo template dei dati per Order to Cash - Elaborazione degli ordini di vendita
Il Suo template dei dati per Order to Cash - Elaborazione degli ordini di vendita
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni pratiche per l’estrazione dei dati
Attributi di Order to Cash - Elaborazione degli ordini di vendita
| Nome | Descrizione | ||
|---|---|---|---|
| Ordine di vendita SalesOrder | Identificativo univoco dell’ordine di vendita, utilizzato come caso principale per il processo dall’ordine all’incasso. | ||
| Descrizione Il numero dell’ordine di vendita identifica in modo univoco ogni ordine del cliente durante tutto il suo ciclo di vita. È il riferimento centrale che collega tutte le attività correlate, dalla creazione e conferma iniziali fino all’evasione, alla fatturazione e al pagamento finale. Nel Process Mining, questo attributo è essenziale per raggruppare tutti gli eventi correlati in un unico caso. Analizzare il processo per ordine di vendita offre una visione completa dall’inizio alla fine e consente di calcolare i tempi di ciclo complessivi, individuare le varianti di processo dei singoli ordini e seguirne il percorso tra reparti e sistemi diversi. Perché è importante È l’ID del caso. Collega tutti gli eventi del processo e consente di ricostruire il percorso completo di un singolo ordine del cliente. Dove reperirli Questo identificativo si trova in genere nella tabella di intestazione degli ordini di vendita in Oracle Fusion, ad esempio DOO_HEADERS_ALL. Consultare la documentazione di Oracle Fusion Financials. Esempi SO-100567SO-100568SO-100569 | |||
| Nome dell’attività ActivityName | Nome dello specifico evento aziendale o task che si è verificato nel processo dell’ordine di vendita. | ||
| Descrizione Questo attributo descrive il passaggio eseguito in un determinato momento per un ordine di vendita, ad esempio «Ordine di vendita creato», «Merce spedita» o «Pagamento ricevuto». La sequenza di queste attività costituisce il flusso del processo per ciascun caso. L’analisi di ActivityName è fondamentale nel Process Mining: consente di visualizzare la mappa del processo, individuare le diverse varianti e rilevare i colli di bottiglia in cui si accumulano i casi. È inoltre la base per calcolare i tempi di transizione tra i passaggi e comprendere la sequenza operativa del processo dall’ordine all’incasso. Perché è importante Questo attributo definisce i passaggi della mappa del processo e consente di visualizzare e analizzare il flusso del processo. Dove reperirli È un attributo derivato, ottenuto associando gli stati delle transazioni o i tipi di evento di diverse tabelle Oracle Fusion, ad esempio lo stato dell’ordine, della spedizione o della fattura, a un elenco standardizzato di nomi di attività. Esempi Ordine di vendita creatoMerce speditaFattura creataPagamento ricevuto | |||
| Ora dell’evento EventTime | Timestamp che indica quando si è verificata una specifica attività o un evento relativo a un ordine di vendita. | ||
| Descrizione Questo attributo fornisce la data e l’ora di ogni attività del processo, definendo la sequenza cronologica degli eventi. Costituisce il riferimento temporale dell’analisi e registra con precisione quando si è verificato ogni passaggio. Nel Process Mining, EventTime è fondamentale per calcolare i tempi di ciclo, la durata tra le attività e i tempi di attraversamento complessivi dei casi. Consente di analizzare le prestazioni, individuare i colli di bottiglia in base ai tempi di attesa e monitorare il rispetto degli accordi sui livelli di servizio (SLA) relativi alla puntualità. Tutti i KPI e le Dashboard basati sul tempo dipendono dalla precisione di questo attributo. Perché è importante Questo timestamp è essenziale per ordinare cronologicamente gli eventi e calcolare tutte le metriche temporali, come i tempi di ciclo e le durate. Dove reperirli È un attributo derivato, ricavato da diversi campi timestamp nelle tabelle Oracle Fusion, come la data di creazione dell’ordine, la data di spedizione, la data della fattura e quella del pagamento. Esempi 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Canale di vendita SalesChannel | Canale attraverso il quale è stato ricevuto l’ordine di vendita. | ||
| Descrizione Questo attributo classifica l’origine dell’ordine di vendita, ad esempio «Web», «Vendita diretta», «Partner» o «EDI», e indica come l’ordine è entrato nell’organizzazione. Segmentare il processo per canale di vendita è fondamentale per la Dashboard «Panoramica delle prestazioni dei canali di vendita». Consente di confrontare l’efficienza, i tempi di ciclo e i tassi di errore dei diversi canali, per individuare quelli più efficaci e quelli che potrebbero richiedere miglioramenti o ulteriore automazione. Perché è importante Supporta l’analisi delle prestazioni per canale e aiuta a individuare i canali più e meno efficienti nell’elaborazione degli ordini. Dove reperirli Queste informazioni possono essere memorizzate in un campo dedicato nell’intestazione dell’ordine di vendita. Consultare la documentazione di Oracle Fusion Financials. Esempi Vendita direttaPortale webEDIRivenditore | |||
| Data di consegna effettiva ActualDeliveryDate | Data in cui la merce è stata effettivamente consegnata al cliente. | ||
| Descrizione Questo attributo registra la data di consegna effettiva, che segna il completamento della fase di evasione del processo. Rappresenta il risultato concreto rispetto al quale vengono misurate le date pianificate o richieste. La data viene confrontata con RequestedDeliveryDate per calcolare le prestazioni delle consegne puntuali. È un dato fondamentale per il KPI «Tasso di consegne puntuali» e la Dashboard «SLA delle consegne», perché fornisce una misura chiara dell’efficacia della logistica e della catena di approvvigionamento. Perché è importante È la data effettiva utilizzata per calcolare il tasso di consegne puntuali e valutare le prestazioni di evasione rispetto alle richieste dei clienti. Dove reperirli Proviene dalle tabelle delle transazioni di spedizione e consegna in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi 2023-05-202023-06-032023-05-25 | |||
| Data di consegna richiesta RequestedDeliveryDate | Data di consegna dell’ordine richiesta dal cliente. | ||
| Descrizione Questo attributo registra la data in cui il cliente desidera ricevere la merce. È un obiettivo di prestazione fondamentale per la fase di evasione del processo dall’ordine all’incasso. La data è essenziale per calcolare il KPI «Tasso di consegne puntuali» e supportare la Dashboard «Accordo sul livello di servizio delle consegne (SLA)». Confrontandola con ActualDeliveryDate, l’organizzazione può misurare la propria capacità di soddisfare le aspettative dei clienti e individuare le cause profonde dei ritardi. Perché è importante Costituisce la base di riferimento per misurare le prestazioni delle consegne puntuali e il rispetto degli accordi sul livello di servizio (SLA) con i clienti. Dove reperirli Si trova in genere nelle tabelle delle righe degli ordini di vendita in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi 2023-05-202023-06-012023-05-25 | |||
| Data di scadenza del pagamento PaymentDueDate | Data entro cui il cliente deve pagare la fattura. | ||
| Descrizione La data di scadenza del pagamento viene calcolata in base alla data della fattura e ai termini di pagamento concordati con il cliente. Definisce il termine entro cui il pagamento deve essere riscosso. Questo attributo è fondamentale per il KPI «Tasso di riscossione puntuale dei pagamenti». Confrontando PaymentDueDate con la data effettiva di ricezione del pagamento, il sistema determina se il pagamento è avvenuto entro la scadenza o in ritardo, aiutando a monitorare le prestazioni della contabilità clienti e a gestire il flusso di cassa. Perché è importante Definisce la scadenza per calcolare il tasso di pagamenti puntuali, un indicatore importante dell’efficienza del flusso di cassa. Dove reperirli Si trova nelle tabelle della contabilità clienti o delle fatture in Oracle Fusion, ad esempio AR_PAYMENT_SCHEDULES_ALL. Esempi 2023-06-192023-07-012023-06-25 | |||
| È automatizzata IsAutomated | Indicatore che specifica se un’attività è stata eseguita automaticamente dal sistema o manualmente da un utente. | ||
| Descrizione Questo attributo booleano distingue gli eventi generati dal sistema, come un controllo automatico del credito o una fattura generata dal sistema, dalle azioni manuali degli utenti. In genere viene ricavato dal nome utente associato all’attività: un ID di sistema generico indica un’operazione automatizzata. L’analisi di questo attributo aiuta a misurare il livello di automazione del processo ed è un dato diretto per il KPI «Percentuale di ordini rielaborati manualmente». Può mettere in evidenza le opportunità di ulteriore automazione, mostrando quali passaggi manuali richiedono più tempo o sono più soggetti a errori. Perché è importante Aiuta a quantificare il livello di automazione del processo e a individuare opportunità per ridurre gli interventi manuali costosi. Dove reperirli È un campo derivato, spesso basato su una regola applicata all’attributo UserName. Ad esempio, se l’utente è «SYSTEM» o «BATCH», l’indicatore viene impostato su true. Esempi truefalse | |||
| Importo totale dell’ordine di vendita SalesOrderTotalAmount | Valore monetario complessivo dell’ordine di vendita. | ||
| Descrizione Questo attributo rappresenta l’importo totale addebitato al cliente per l’intero ordine di vendita. Comprende la somma di tutte le righe, le imposte e gli altri addebiti, prima dell’applicazione degli sconti. Nell’analisi del processo, è fondamentale per il Process Mining basato sul valore. Consente di suddividere gli ordini per importo, ad esempio tra ordini di valore alto e basso, e verificare se seguono percorsi diversi o hanno tempi di ciclo differenti. Aiuta inoltre a dare priorità agli interventi di miglioramento sui casi di maggiore rilevanza finanziaria. Perché è importante Consente di analizzare l’impatto finanziario, dando priorità ai miglioramenti dei processi relativi agli ordini di valore elevato e aiutando a comprendere i fattori che determinano i costi. Dove reperirli Si trova in genere nelle tabelle di intestazione degli ordini di vendita in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi 5250.00125000.75980.50 | |||
| Nome del cliente CustomerName | Nome del cliente che ha effettuato l’ordine di vendita. | ||
| Descrizione Questo attributo identifica la ragione sociale del conto cliente associato all’ordine di vendita. È una dimensione importante per segmentare e analizzare il processo dal punto di vista del cliente. L’analisi per cliente aiuta a individuare eventuali tempi di ciclo più lunghi, maggiori rilavorazioni o specifiche deviazioni del processo per determinati clienti. Queste informazioni possono contribuire a migliorare il servizio, adattare i processi per i clienti strategici e indagare sui problemi che incidono sulla soddisfazione. Perché è importante Consente un’analisi incentrata sul cliente per individuare i problemi di processo che lo riguardano e migliorare la sua soddisfazione. Dove reperirli Proviene dalle tabelle anagrafiche dei clienti, ad esempio HZ_PARTIES, ed è collegato all’ordine di vendita tramite un ID cliente. Esempi Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Nome utente UserName | Nome o ID dell’utente che ha eseguito l’attività. | ||
| Descrizione Questo attributo identifica il dipendente o l’utente di sistema responsabile dell’esecuzione di uno specifico passaggio del processo. Può essere utilizzato per analizzare le prestazioni dei singoli utenti, la distribuzione del carico di lavoro e il rispetto delle procedure standard. L’analisi per utente aiuta a individuare le esigenze di formazione, riconoscere le persone o i team con i risultati migliori e indagare sulle deviazioni riconducibili a utenti specifici. È utile anche ai fini della conformità e degli audit, perché permette di verificare chi ha eseguito ciascuna azione. Perché è importante Consente di analizzare le prestazioni per utente, la distribuzione del carico di lavoro e gli schemi di rilavorazione manuale riconducibili a singole persone. Dove reperirli In genere proviene da campi come CREATED_BY o LAST_UPDATED_BY nelle tabelle delle transazioni di Oracle Fusion, spesso collegati a una tabella anagrafica degli utenti come FND_USER. Esempi john.smithjane.doesystem_batch_user | |||
| Consegna puntuale IsOnTimeDelivery | Indicatore calcolato, impostato su true se la consegna effettiva è avvenuta entro la data richiesta. | ||
| Descrizione Questo attributo booleano si ricava confrontando ActualDeliveryDate con RequestedDeliveryDate. Fornisce un indicatore semplice delle prestazioni di consegna per ciascun caso. È la base per calcolare il KPI aggregato «Tasso di consegne puntuali». Semplifica i filtri e l’analisi, consentendo di isolare rapidamente tutti gli ordini in ritardo e analizzare le cause profonde dei ritardi. Perché è importante Misura direttamente le prestazioni di evasione rispetto alle aspettative dei clienti e semplifica l’analisi degli ordini in ritardo. Dove reperirli È un campo calcolato. La logica è: ActualDeliveryDate <= RequestedDeliveryDate. Esempi truefalse | |||
| Fattura corretta IsInvoiceCorrected | Indicatore che segnala se una fattura è stata corretta o modificata dopo la creazione iniziale. | ||
| Descrizione Questo attributo booleano è true se la fattura ha seguito un ciclo di correzione, segnalato dalla presenza dell’attività 'Fattura corretta'. Indica i casi in cui è stato necessario rilavorare la fatturazione. È un dato fondamentale per la Dashboard 'Analisi dell’accuratezza e della rilavorazione delle fatture' e per il KPI 'Tasso di rilavorazione delle fatture'. Aiuta a quantificare gli errori di fatturazione e ad analizzarne le cause profonde, così da capire perché sono necessarie le correzioni e ridurre il lavoro manuale e i ritardi nei pagamenti. Perché è importante Individua le rilavorazioni delle fatture, un indicatore importante di inefficienze di processo, problemi di qualità dei dati e possibili ritardi nei pagamenti. Dove reperirli È un campo calcolato, in genere impostato su true per un caso se nel relativo event log è presente l’attività 'Fattura corretta'. Esempi falsetrue | |||
| Metodo di spedizione ShippingMethod | Metodo o vettore utilizzato per spedire la merce al cliente. | ||
| Descrizione Questo attributo specifica il vettore logistico o il livello di servizio utilizzato per la consegna, ad esempio «Trasporto terrestre», «Espresso aereo» o «Corriere locale». Queste informazioni sono essenziali per la Dashboard «Conformità delle consegne per metodo di spedizione». Consentono di confrontare la puntualità delle consegne e i costi di spedizione tra metodi e vettori diversi, aiutando a ottimizzare la strategia logistica e la scelta dei fornitori. Perché è importante Supporta direttamente l’analisi logistica, consentendo di confrontare le prestazioni dei diversi vettori e metodi di spedizione. Dove reperirli È disponibile nelle tabelle di spedizione ed evasione in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi FedEx GroundUPS Next Day AirDHL International | |||
| Nome del prodotto ProductName | Nome del prodotto o servizio venduto. | ||
| Descrizione Questo attributo specifica l’articolo presente nella riga dell’ordine di vendita. Se l’ordine contiene più righe, il caso può essere analizzato a livello di singolo articolo oppure l’attributo può essere aggregato a livello di intestazione. L’analisi per prodotto aiuta a capire se alcuni prodotti sono associati a flussi di processo più complessi o problematici, ad esempio per frequenti ritardi nelle consegne o problemi di pagamento. Queste informazioni possono orientare le strategie di gestione dei prodotti e della catena di approvvigionamento. Perché è importante Consente di analizzare le prestazioni del processo per prodotto e di individuare gli articoli con percorsi di evasione o fatturazione potenzialmente complessi. Dove reperirli Proviene dalle tabelle delle righe degli ordini di vendita ed è collegato a una tabella anagrafica dei prodotti. Consultare la documentazione di Oracle Fusion Financials. Esempi Widget standard X1Pacchetto di servizi premiumComponente Y2-B | |||
| Numero della fattura InvoiceNumber | Identificativo univoco della fattura del cliente. | ||
| Descrizione Questo attributo è il numero univoco assegnato alla fattura generata dall’ordine di vendita. Collega le attività di vendita ed evasione alla fase di regolamento finanziario del processo. L’ordine di vendita è l’ID del caso principale, mentre il numero della fattura è fondamentale per analizzare i sottoprocessi di fatturazione e pagamento. È essenziale per monitorare le correzioni delle fatture, le contestazioni e lo stato dei pagamenti e supporta Dashboard come «Precisione delle fatture e analisi della rilavorazione». Perché è importante Fornisce un collegamento essenziale con il processo di contabilità clienti ed è necessario per analizzare la rilavorazione delle fatture e i cicli di pagamento. Dove reperirli È disponibile nelle tabelle delle transazioni della contabilità clienti in Oracle Fusion, ad esempio RA_CUSTOMER_TRX_ALL. Esempi INV-93485INV-93486INV-93487 | |||
| Paese del cliente CustomerCountry | Paese in cui si trova il cliente. | ||
| Descrizione Questo attributo indica il paese ricavato dall’indirizzo di spedizione o di fatturazione del cliente. È una dimensione importante per l’analisi geografica. Segmentare il processo per paese può rivelare differenze regionali nelle prestazioni, nei tempi di ciclo o nei comportamenti di pagamento. Queste informazioni aiutano a comprendere l’impatto delle normative locali, delle difficoltà logistiche e delle condizioni di mercato sul processo dall’ordine all’incasso. Perché è importante Consente di individuare differenze regionali nell’efficienza del processo, nella conformità e nei comportamenti dei clienti attraverso l’analisi geografica. Dove reperirli Proviene dalle tabelle anagrafiche dei clienti, come HZ_LOCATIONS e HZ_PARTY_SITES, collegate all’ordine di vendita. Esempi USAGermaniaGiappone | |||
| Pagamento in ritardo IsLatePayment | Indicatore calcolato, impostato su true se il pagamento è stato ricevuto dopo la data di scadenza. | ||
| Descrizione Questo attributo booleano si ricava confrontando la data effettiva di ricezione del pagamento con PaymentDueDate. Indica chiaramente se una fattura è stata pagata entro la scadenza. L’attributo viene utilizzato per calcolare il KPI «Tasso di pagamenti puntuali». Consente di distinguere facilmente i pagamenti puntuali da quelli in ritardo e di analizzare le caratteristiche dei clienti che pagano in ritardo, le cause ricorrenti dei ritardi e l’impatto finanziario sul capitale circolante. Perché è importante Misura direttamente l’efficacia della riscossione dei pagamenti e semplifica l’analisi dei pagamenti scaduti. Dove reperirli È un campo calcolato. La logica è: PaymentReceivedDate > PaymentDueDate. Esempi falsetrue | |||
| Sistema di origine SourceSystemIdentifier | Identifica il sistema di origine da cui sono stati estratti i dati degli eventi. | ||
| Descrizione Questo attributo specifica l’origine dei dati ed è particolarmente utile quando al processo dall’ordine all’incasso partecipano più sistemi. Ad esempio, i dati degli ordini possono provenire da Oracle Fusion, mentre quelli delle spedizioni possono arrivare da un sistema logistico di terze parti. Nell’analisi, aiuta a comprendere la provenienza dei dati e consente di filtrare la vista del processo in base agli eventi provenienti da sistemi specifici. È fondamentale per convalidare i dati e individuare la frammentazione del processo tra ambienti IT diversi. Perché è importante Fornisce informazioni sull’origine dei dati, essenziali per la governance dei dati e la risoluzione dei problemi negli ambienti con più sistemi. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati. Esempi Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Termini di pagamento PaymentTerms | Condizioni di pagamento concordate con il cliente. | ||
| Descrizione Questo attributo specifica le condizioni entro cui il cliente deve pagare la fattura, ad esempio «30 giorni data fattura» o «60 giorni data fattura». Queste condizioni costituiscono la base per calcolare PaymentDueDate. Nell’analisi, segmentare i dati per termini di pagamento aiuta a spiegare le differenze nei tempi di ciclo dei pagamenti. Fornisce un contesto utile per il KPI «Tasso di pagamenti puntuali», poiché condizioni diverse determinano naturalmente comportamenti di pagamento diversi. Queste informazioni possono orientare la politica del credito e le previsioni del flusso di cassa. Perché è importante Fornisce un contesto essenziale per analizzare i comportamenti di pagamento e aiuta a spiegare le differenze nei tempi di ciclo tra fatturazione e pagamento. Dove reperirli È disponibile a livello di ordine di vendita o di conto cliente in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi 30 giorni data fattura60 giorni data fatturaPagamento alla ricezione | |||
| Tipo di ordine OrderType | Classificazione dell’ordine di vendita, ad esempio «Ordine standard» o «Ordine di reso». | ||
| Descrizione Il tipo di ordine serve a classificare gli ordini di vendita in base alla loro finalità aziendale. Tra i tipi più comuni rientrano gli ordini di vendita standard, gli ordini di assistenza, le autorizzazioni al reso della merce (RMA) e gli ordini interni. Analizzare il processo per tipo di ordine è importante perché tipi diversi seguono spesso flussi di processo e obiettivi di prestazione distinti. Questa segmentazione aiuta a comprendere le variazioni previste e intenzionali, evitando che vengano interpretate erroneamente come deviazioni. Perché è importante Consente di distinguere flussi di processo diversi e legittimi, ad esempio ordini standard e resi, per garantire un’analisi corretta ed equilibrata. Dove reperirli In genere è disponibile come campo nella tabella di intestazione degli ordini di vendita in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi Ordine di vendita standardAutorizzazione al resoOrdine di assistenza | |||
| Ultimo aggiornamento dei dati LastUpdateDate | Timestamp che indica l’ultimo aggiornamento dei dati relativi a questo evento dal sistema di origine. | ||
| Descrizione Questo attributo registra quando i dati sono stati estratti o aggiornati l’ultima volta nel set di dati per il Process Mining. Indica quanto sono aggiornati i dati analizzati. Questa informazione è essenziale per capire quanto sia attuale l’analisi del processo. Aiuta a definire le aspettative sulla tempestività dei dati ed è importante per pianificare e monitorare gli aggiornamenti. Perché è importante Indica quanto sono aggiornati i dati, così chi li utilizza può sapere quanto è attuale l’analisi del processo. Dove reperirli Questo valore viene generato e aggiunto al set di dati durante ogni ciclo di estrazione e trasformazione. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Unità aziendale BusinessUnitName | Nome dell’unità aziendale interna responsabile dell’ordine di vendita. | ||
| Descrizione Questo attributo rappresenta la divisione o l’unità operativa specifica dell’azienda a cui fa capo la transazione. Consente di confrontare le prestazioni delle diverse aree dell’organizzazione. Segmentare il processo per unità aziendale aiuta a individuare differenze di efficienza, costi e conformità all’interno dell’azienda. L’analisi può far emergere le buone pratiche delle unità con i risultati migliori, da condividere con le altre, oppure evidenziare quelle che necessitano di interventi mirati. Perché è importante Consente di confrontare le prestazioni e analizzare la coerenza dei processi tra diverse unità organizzative. Dove reperirli In genere è disponibile nell’intestazione dell’ordine di vendita ed è collegato alla struttura organizzativa definita in Oracle Fusion. Esempi Unità aziendale - Nord AmericaUnità aziendale - EMEAServizi globali | |||
Attività di Order to Cash - Elaborazione degli ordini di vendita
| Attività | Descrizione | ||
|---|---|---|---|
| Fattura creata | Questa attività rappresenta la creazione della fattura per il cliente nel modulo Accounts Receivable, in genere avviata dall’evento di conferma della spedizione. Viene generato un record della fattura con un numero univoco e una data di creazione. | ||
| Perché è importante Segna l’inizio ufficiale del ciclo di riscossione dei pagamenti. È il riferimento per misurare il «Invoice to Payment Time» e l’efficienza complessiva del flusso di cassa. Dove reperirli È un evento esplicito in Oracle Accounts Receivable (AR). Il record della fattura viene creato nella tabella RA_CUSTOMER_TRX_ALL con una data di transazione. Acquisizione Ricavato dalla data di creazione della transazione della fattura nel modulo AR. Tipo di evento explicit | |||
| Merce spedita | Questa attività segna il momento in cui la merce lascia il magazzino e inizia il trasporto verso il cliente. Viene registrata quando in Oracle Shipping viene elaborata una transazione di conferma della spedizione. | ||
| Perché è importante È una tappa fondamentale, che segna il completamento della fase di evasione e avvia la fatturazione. È essenziale per misurare la puntualità delle spedizioni e i tempi di consegna. Dove reperirli È un evento esplicito registrato in Oracle Shipping Execution. La transazione di conferma della spedizione crea un record nelle tabelle delle spedizioni, come WSH_DELIVERY_DETAILS, con la data di spedizione. Acquisizione Ricavato dalla data e dall’ora effettive di spedizione nel record dei dettagli della consegna associato alla riga dell’ordine. Tipo di evento explicit | |||
| Ordine chiuso | È l’attività conclusiva del processo e indica che tutte le righe dell’ordine di vendita sono state evase, fatturate e chiuse. Lo stato dell’intestazione dell’ordine viene aggiornato a «Closed». | ||
| Perché è importante Questa attività segna la conclusione corretta del ciclo di vita dell’ordine di vendita. È essenziale per calcolare la durata complessiva del processo e individuare gli ordini che restano aperti senza mai essere chiusi. Dove reperirli Si deduce dal passaggio dello stato dell’intestazione dell’ordine di vendita a «Closed» nella tabella DOO_HEADERS_ALL. Il timestamp di questa modifica finale identifica il momento dell’evento. Acquisizione Si ricava dal timestamp della modifica dello stato dell’intestazione dell’ordine di vendita a «Closed». Tipo di evento inferred | |||
| Ordine confermato | Questa tappa fondamentale indica che l’ordine di vendita ha superato tutti i controlli iniziali, compresa l’approvazione del credito, ed è pronto per l’evasione. In genere, si deduce dal passaggio dell’ordine a uno stato come «Awaiting Shipping» o «Scheduled». | ||
| Perché è importante Questa attività è una tappa fondamentale per calcolare il «Average Order Confirmation Time» e segna il passaggio dall’inserimento dell’ordine al processo di evasione. Dove reperirli Dedotto dalla variazione dello stato dell’intestazione o della riga dell’ordine di vendita a un valore che indica che l’ordine è pronto per l’evasione, ad esempio «Awaiting Shipping». Verifichi le colonne di stato in DOO_HEADERS_ALL o DOO_FULFILL_LINES_ALL. Acquisizione Ricavato dalla data e dall’ora in cui lo stato dell’ordine passa a confermato o programmato. Tipo di evento inferred | |||
| Ordine di vendita creato | Questa attività segna l’inizio del processo dell’ordine di vendita e corrisponde al momento in cui un nuovo ordine viene inserito in Oracle Fusion. In genere, l’evento viene registrato esplicitamente quando un utente salva un nuovo ordine nel modulo Order Management. | ||
| Perché è importante Essendo l’attività iniziale del processo, è essenziale per misurare il tempo di ciclo complessivo di Order to Cash e analizzare i volumi degli ordini ricevuti. Dove reperirli Registrato esplicitamente al momento della creazione di un ordine di vendita in Order Management Cloud. Cerchi le date e gli orari di creazione nella tabella DOO_HEADERS_ALL. Acquisizione Ricavato dalla data e dall’ora di creazione dell’intestazione dell’ordine di vendita. Tipo di evento explicit | |||
| Pagamento ricevuto | Questa attività indica che il pagamento del cliente è stato ricevuto e registrato a fronte della fattura nella contabilità clienti. L’evento viene rilevato quando viene contabilizzata l’applicazione di un incasso. | ||
| Perché è importante È una tappa fondamentale per misurare il «Tempo di ciclo complessivo dall’ordine all’incasso» e il «Tasso di pagamenti puntuali», poiché rappresenta la conversione della vendita in denaro incassato. Dove reperirli È un evento esplicito in Oracle Accounts Receivable. Viene registrato nelle tabelle degli incassi, come AR_RECEIVABLE_APPLICATIONS_ALL, quando un incasso viene applicato a una fattura. Acquisizione Si rileva dal timestamp del campo «apply date» nel record di applicazione dell’incasso in AR. Tipo di evento explicit | |||
| Controllo del credito eseguito | Indica l’esecuzione di un controllo sul conto del cliente per valutarne l’affidabilità creditizia. Nell’ambito del flusso di lavoro di elaborazione degli ordini, questa fase è spesso automatica o manuale; il completamento viene in genere registrato come aggiornamento di stato o attività completata. | ||
| Perché è importante Analizzare il tempo necessario per i controlli del credito aiuta a individuare i colli di bottiglia nell’approvazione degli ordini. È un dato essenziale per il KPI «Credit Check to Confirmed Time». Dove reperirli Può essere dedotto dalle variazioni di stato dell’ordine di vendita, ad esempio dal passaggio allo stato «Pending Credit Approval», oppure da un Event Log esplicito nella funzionalità di gestione del credito. Acquisizione Dedotto dalle variazioni di stato dell’ordine o dalle date e dagli orari associati alle attività di revisione del credito. Tipo di evento inferred | |||
| Fattura corretta | Si verifica quando una fattura creata in precedenza viene modificata, riemessa o stornata a causa di errori o contestazioni del cliente. In genere, l’operazione viene registrata creando una nota di credito o una nuova versione della fattura. | ||
| Perché è importante Monitorare le correzioni delle fatture è fondamentale per il KPI «Tasso di rilavorazione delle fatture», che mette in evidenza i problemi nel processo di fatturazione che possono ritardare i pagamenti e aumentare i costi amministrativi. Dove reperirli Si deduce dalla creazione di una nota di credito collegata alla fattura originale o di una versione successiva della stessa fattura nella tabella RA_CUSTOMER_TRX_ALL. Acquisizione Si ricava individuando le note di credito o le fatture che fanno riferimento a una transazione di fatturazione precedente. Tipo di evento inferred | |||
| Merce consegnata | Indica che il cliente ha ricevuto la spedizione. L’informazione proviene spesso da un vettore esterno e viene aggiornata in Oracle Fusion; in alternativa, può essere dedotta applicando un tempo di transito standard alla data di spedizione. | ||
| Perché è importante Questa attività è fondamentale per calcolare il KPI «On-Time Delivery Rate» e misurare con precisione i livelli del servizio clienti. Dove reperirli Spesso non è un evento nativo di Oracle. Può essere registrato se è attiva l’integrazione con il vettore oppure calcolato aggiungendo un tempo di transito standard alla data «Goods Shipped». È necessaria un’analisi del sistema. Acquisizione Dedotto dai dati forniti dai vettori oppure calcolato in base alla data di spedizione e al tempo medio di transito. Tipo di evento inferred | |||
| Merce prelevata | Indica il prelievo fisico della merce dal magazzino per evadere l’ordine. È una fase fondamentale del processo logistico e viene in genere registrata nel modulo di gestione del magazzino o delle spedizioni. | ||
| Perché è importante Questa attività offre visibilità sulle operazioni di magazzino. I ritardi tra la prenotazione delle scorte e il prelievo possono indicare colli di bottiglia legati alle risorse o al processo. Dove reperirli Registrato nei moduli Oracle Fusion Cloud SCM (Supply Chain Management). Può essere dedotto dalla variazione di stato di un’ondata di prelievo o di una distinta di prelievo associata alla riga dell’ordine di vendita. Acquisizione Dedotto dalla data e dall’ora di completamento della transazione di prelievo nei moduli SCM. Tipo di evento inferred | |||
| Ordine annullato | Indica l’annullamento di un ordine di vendita prima che la spedizione sia stata completata. Può verificarsi per diversi motivi e porta allo stato finale «Cancelled». | ||
| Perché è importante È un percorso di eccezione importante. Analizzare gli ordini annullati aiuta a individuare le cause profonde, come l’esaurimento delle scorte, problemi di prezzo o un ripensamento del cliente, e a definire interventi di miglioramento del processo. Dove reperirli Si deduce dal passaggio dello stato dell’intestazione o della riga dell’ordine di vendita a «Cancelled». Il timestamp della modifica viene utilizzato per registrare l’evento. Acquisizione Si ricava dal timestamp della modifica dello stato dell’intestazione o della riga dell’ordine a «Cancelled». Tipo di evento inferred | |||
| Ordine bloccato per motivi di credito | Questa attività si verifica quando un ordine di vendita viene bloccato automaticamente o manualmente a causa di un controllo del credito non superato o di un altro problema legato al credito. In genere, viene registrata nel sistema come variazione dello stato di blocco dell’ordine. | ||
| Perché è importante Monitorare gli ordini bloccati per motivi di credito è fondamentale per individuare le cause dei ritardi nell’elaborazione e misurare l’efficienza del processo di rilascio. Dove reperirli Dedotto dall’applicazione di un blocco all’ordine di vendita. In genere, l’evento viene registrato in tabelle relative ai blocchi, come DOO_HOLDS_ALL, collegate all’ordine di vendita. Acquisizione Dedotto dalla creazione di un record nella tabella dei blocchi degli ordini con tipo di blocco «Credit». Tipo di evento inferred | |||
| Riga dell’ordine chiusa | Indica la chiusura definitiva di una singola riga dell’ordine di vendita: la merce è stata spedita integralmente, la fattura è stata emessa e non sono previste altre transazioni. Il sistema aggiorna lo stato della riga a «Closed». | ||
| Perché è importante La chiusura delle righe dell’ordine indica che tutti gli obblighi contrattuali relativi all’articolo sono stati assolti. L’analisi consente di individuare gli ordini che restano aperti a lungo dopo l’evasione e il pagamento. Dove reperirli Si deduce dal passaggio dello stato della riga di evasione a «Closed» nella tabella DOO_FULFILL_LINES_ALL. Il timestamp della modifica dello stato identifica il momento dell’evento. Acquisizione Si ricava dal timestamp della modifica dello stato della riga di evasione a «Closed». Tipo di evento inferred | |||
| Scorte riservate | Questa attività rappresenta l’allocazione o la prenotazione delle scorte fisiche necessarie per evadere la riga dell’ordine di vendita. Il sistema riserva quantità specifiche, assicurandone la disponibilità quando l’ordine è pronto per il prelievo. | ||
| Perché è importante Monitorare questa attività aiuta ad analizzare il KPI «Inventory Allocation Lead Time» e a individuare i ritardi tra la conferma dell’ordine e la disponibilità della merce. Dove reperirli L’evento viene spesso registrato nei moduli di gestione delle scorte o di esecuzione della catena di fornitura. Può essere dedotto dagli aggiornamenti di stato della riga di evasione che indicano che le scorte sono state specificate o riservate. Acquisizione Dedotto dalle variazioni di stato della riga di evasione relative alla prenotazione o alla programmazione delle scorte. Tipo di evento inferred | |||
Guide all’estrazione
Passaggi
- Acceda a Oracle BI Publisher: acceda all’ambiente Oracle Fusion con un utente che disponga dei privilegi BI Administrator o BI Author. Dal menu Navigator, selezioni Tools > Reports and Analytics. Faccia clic sul pulsante 'Browse Catalog' per aprire il catalogo Business Intelligence.
- Crei un nuovo modello di dati: nel catalogo BI, raggiunga una cartella adatta, ad esempio Shared Folders > Custom. Faccia clic sul menu a discesa 'New' e selezioni 'Data Model'.
- Definisca il dataset della query SQL: nell’editor del modello di dati, faccia clic sull’icona '+' per creare un nuovo dataset e selezioni 'SQL Query'. Si aprirà una finestra di dialogo. Assegni un nome al dataset, ad esempio 'OrderToCash_EventLog', selezioni 'Oracle BI EE' come origine dei dati e scelga 'Standard SQL' come tipo di SQL.
- Inserisca la query SQL: copi la query SQL completa fornita nella sezione 'query' di questo documento e la incolli nell’area di testo SQL Query. La query include i parametri per la data iniziale e finale (:p_start_date e :p_end_date), che BI Publisher riconoscerà automaticamente.
- Configuri le proprietà del modello di dati: dopo aver incollato la query, faccia clic su 'OK'. Nel riquadro a sinistra dell’editor del modello di dati, apra la sezione 'Properties'. Verifichi che sia selezionata l’opzione 'Include Parameter Tags'. Se lo desidera, può anche impostare valori predefiniti per i parametri delle date.
- Visualizzi e salvi il modello di dati: faccia clic sulla scheda 'Data'. Potrebbe essere richiesto di inserire i valori dei parametri delle date. Inserisca un intervallo breve per eseguire una prova. Faccia clic su 'View' per visualizzare un campione dei dati. Se i dati sono corretti, salvi il modello facendo clic sull’icona di salvataggio e assegnandogli un nome descrittivo, ad esempio 'OrderToCash_EventLog_DM'.
- Crei un report dal modello di dati: dopo aver salvato il modello di dati, faccia clic sul pulsante 'Create Report' nell’angolo in alto a destra. Si aprirà la procedura guidata per la creazione del report.
- Configuri il report: nella procedura guidata, selezioni l’opzione 'Use Data Model'. La procedura La guiderà nella configurazione del layout. Per una semplice esportazione CSV, può scegliere il layout 'Table'. Trascini tutte le colonne nella tabella. Faccia clic su 'Next', quindi deselezioni 'Show Grand Totals Row'. Faccia clic su 'Finish' per salvare il report. Gli assegni un nome, ad esempio 'OrderToCash_EventLog_Report'.
- Esegua il report: apra il report appena creato. Le verrà richiesto di inserire le date iniziale e finale dell’estrazione. Indichi l’intervallo desiderato.
- Esporti i dati: una volta eseguito il report, faccia clic sul menu a discesa 'View' e selezioni un’altra opzione di visualizzazione, ad esempio 'View Report'. Individui quindi il collegamento o l’icona 'Export' e scelga 'CSV' come formato di esportazione. Verrà scaricato il file dell’event log.
- Prepari il caricamento: apra il file CSV scaricato e verifichi che le intestazioni delle colonne corrispondano agli attributi richiesti: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate e IsAutomated. Il file è ora pronto per essere caricato nello strumento di Process Mining.
Configurazione
- Privilegi utente: deve disporre di un ruolo che consenta di creare modelli di dati e report in BI Publisher, ad esempio 'BI Administrator' o 'BI Author'.
- Origine dei dati: la query è progettata per l’origine dati applicativa standard 'Oracle BI EE', che si collega al database transazionale (Fusion Apps). In genere non è necessaria alcuna configurazione speciale.
- Parametri dell’intervallo di date: la query utilizza due parametri, :p_start_date e :p_end_date, per filtrare i dati. Si consiglia vivamente di estrarre i dati in blocchi gestibili, ad esempio da 3 a 6 mesi per volta, per evitare timeout dei report e problemi di prestazioni.
- Filtro per unità aziendale: per limitare l’ambito dell’estrazione, può aggiungere una clausola WHERE alla CTE BaseOrders della query, filtrando per uno specifico ID dell’unità aziendale, ad esempio AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtro per tipo di ordine: può anche filtrare specifici tipi di ordini di vendita aggiungendo una condizione su dhead.SOURCE_ORDER_TYPE_CODE nella CTE BaseOrders.
- Prestazioni: per dataset molto grandi che coprono diversi anni, questo approccio basato su un’unica query può essere lento. Valuti di eseguirlo nelle ore di minore attività oppure di suddividere l’estrazione in blocchi mensili più piccoli. Verifichi che la proprietà 'Enable SQL Pruning' non sia selezionata nel modello di dati, perché potrebbe interferire con query UNION complesse.
Query di esempio sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED'Passaggi
- Acceda alla console BICC: acceda all’istanza Oracle Fusion Applications con un utente che disponga del ruolo BICC_ADMINISTRATOR. Dal menu Tools, selezioni Business Intelligence Cloud Connector.
- Crei una nuova offerta: nella console BICC, faccia clic su Configure External Storage per configurare la destinazione, che può essere Oracle Universal Content Management (UCM) oppure un bucket OCI Object Storage. Verifichi che i dettagli di connessione e le credenziali siano corretti.
- Avvii un nuovo processo di estrazione: apra la sezione Manage Extract Jobs e faccia clic sull’icona + per creare un nuovo processo. Gli assegni un nome descrittivo, ad esempio ProcessMind_O2C_SalesOrder_Extract.
- Selezioni i Data Store (PVO): nella configurazione del processo, cerchi e aggiunga i Public View Objects (PVO) necessari per acquisire il ciclo di vita degli ordini di vendita. Dovrà aggiungere più PVO, tra cui FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice e FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configuri le colonne per ciascun PVO: per ogni PVO selezionato, faccia clic sul menu Actions e scelga Select Columns. Selezioni con attenzione le colonne necessarie per generare l’event log, ad esempio HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate e gli identificativi degli utenti. Per l’elenco dettagliato delle colonne richieste per ciascun PVO, consulti il manifesto della query.
- Applichi i filtri per i caricamenti incrementali: per gestire il volume dei dati, applichi a ciascun PVO un filtro basato sulla colonna LastUpdateDate. Per la prima esecuzione, può selezionare un intervallo di date ampio. Per le esecuzioni pianificate successive, configuri il filtro in modo da estrarre solo i record aggiornati dall’ultima esecuzione del processo.
- Pianifichi il processo di estrazione: apra la sezione Manage Schedule e crei una nuova pianificazione per il processo. Si consiglia di eseguirlo nelle ore di minore attività, ad esempio ogni notte, per ridurre al minimo l’impatto sulle prestazioni del sistema.
- Invii e monitori il processo: una volta completata la configurazione, invii il processo. Può monitorarne l’avanzamento dalla schermata Manage Extract Jobs. Al termine dell’esecuzione, i file di dati saranno disponibili nella posizione di archiviazione cloud configurata, in formato CSV compresso.
- Trasformi i dati grezzi in un event log: scarichi i file CSV estratti. BICC fornisce dati grezzi delle tabelle, non un event log già formattato. Dovrà elaborare i file con uno strumento esterno, ad esempio Python, uno script per database o una piattaforma ETL. L’elaborazione prevede di:
- unire i dati provenienti da file diversi, ad esempio collegando i dati delle fatture all’intestazione dell’ordine di vendita;
- trasformare le colonne delle date in righe distinte per ciascuna attività. Ad esempio, dal file FscmTopModelAM.DooTopAM.Header può creare una riga per l’attività Sales Order Created usando CreationDate e un’altra per Order Closed usando ClosedDate;
- associare i codici di stato o gli indicatori ad attività specifiche, come Order Confirmed o Order Cancelled;
- riunire tutti i dati trasformati in un unico file con le colonne richieste: SalesOrder, ActivityName ed EventTime.
- Prepari il file per il caricamento: verifichi che il file trasformato finale sia un unico CSV e contenga le colonne corrispondenti agli attributi richiesti e consigliati. Il file è ora pronto per essere caricato in ProcessMind.
Configurazione
- Selezione dei PVO: la precisione dell’event log dipende interamente dalla scelta dei PVO corretti. Tra i PVO principali figurano FscmTopModelAM.DooTopAM.Header (per la creazione e la chiusura degli ordini), FscmTopModelAM.ScmTopAM.ShipmentLine (per gli eventi di spedizione) e FscmTopModelAM.ArTopAM.ReceivableInvoice (per la fatturazione).
- Estrazione incrementale: utilizzi sempre il filtro LastUpdateDate per le estrazioni ricorrenti. È fondamentale per le prestazioni ed evita di estrarre ripetutamente lo stesso dataset di diversi gigabyte. Il primo caricamento completo stabilisce una base di riferimento; le esecuzioni successive acquisiscono solo le modifiche.
- Intervallo di date: per il primo caricamento storico, estragga un periodo rappresentativo, ad esempio gli ultimi 3-6 mesi di dati, così da bilanciare completezza e volume gestibile. Le esecuzioni successive saranno incrementali.
- Configurazione dell’archiviazione: BICC può esportare i dati in Oracle UCM o OCI Object Storage. Per i casi che prevedono grandi volumi di dati e una più semplice integrazione con gli strumenti ETL a valle, in genere è consigliabile OCI Object Storage.
- Pianificazione dei processi: pianifichi le estrazioni fuori dall’orario lavorativo per evitare possibili cali di prestazioni nel sistema transazionale Oracle Fusion Financials.
- Prerequisiti: gli utenti che configurano il processo devono disporre del ruolo BICC_ADMINISTRATOR. È necessario aver configurato in precedenza le credenziali di archiviazione cloud e conoscere chiaramente la logica di trasformazione dei dati da applicare dopo l’estrazione.
Query di esempio config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filteringÈ pronto a iniziare?
Utilizzi questo template per semplificare la raccolta dei dati e avviare il percorso di Process Mining. Inizi oggi a ottimizzare il processo Order to Cash - Elaborazione degli ordini di vendita.
Ottimizzi oggi il processo Order to Cash - Elaborazione degli ordini di vendita
Individui i colli di bottiglia e riduca facilmente del 30% il tempo di ciclo Order to Cash.
Non è richiesta la carta di credito. Prova gratuita di 14 giorni.