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 dell’elaborazione degli ordini di vendita da Order to Cash
| Nome | Descrizione | ||
|---|---|---|---|
| Ordine di vendita SalesOrder | L'identificativo univoco di un ordine di vendita, che funge da caso principale per il processo Order to Cash. | ||
| Descrizione Il numero dell'ordine di vendita identifica in modo univoco ogni ordine cliente durante l'intero ciclo di vita. Funge da filo conduttore 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. L'analisi per ordine di vendita offre una visione completa end-to-end, consentendo di calcolare i tempi di attraversamento totali, identificare le varianti di processo dei singoli ordini e monitorare il percorso di un ordine tra diversi reparti e sistemi. Perché è importante Questo è il Case ID. Collega tutti gli eventi del processo, rendendo possibile tracciare il percorso end-to-end di un singolo ordine cliente. Dove reperirlo Questo identificativo si trova generalmente 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 | Il nome dello specifico evento aziendale o della Task che si è verificata all'interno del processo relativo all'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 di processo di ogni caso. L'analisi di ActivityName è fondamentale nel Process Mining. Consente di visualizzare la mappa del processo, individuare diverse varianti di processo e identificare i colli di bottiglia in cui si accumulano i casi. Costituisce la base per calcolare i tempi di transizione tra i passaggi e comprendere la sequenza operativa del processo Order to Cash. Perché è importante Questo attributo definisce i passaggi nella mappa del processo, consentendo di visualizzare e analizzare il flusso di processo. Dove reperirlo Si tratta di un attributo derivato, creato mappando gli stati delle transazioni o i tipi di evento provenienti da diverse tabelle Oracle Fusion, ad esempio lo stato dell'ordine, della spedizione e della fattura, su un elenco standardizzato di nomi delle attività. Esempi Ordine di vendita creatoMerce speditaFattura creataPagamento ricevuto | |||
| Orario dell'evento EventTime | Il timestamp che indica quando si è verificata una specifica attività o un evento per un ordine di vendita. | ||
| Descrizione Questo attributo fornisce la data e l'ora di ogni attività del processo, stabilendo la sequenza cronologica degli eventi. Costituisce la struttura temporale dell'analisi del processo e registra con precisione quando si è verificato ogni passaggio. Nel Process Mining, EventTime è fondamentale per calcolare i tempi di attraversamento, le durate tra le attività e i tempi complessivi dei casi. Consente di analizzare le prestazioni, rilevare i colli di bottiglia sulla base dei tempi di attesa e monitorare la Conformità agli accordi sui livelli di servizio (SLA) relativi alla puntualità. Tutti i KPI e i Dashboard basati sul tempo dipendono dall'accuratezza di questo attributo. Perché è importante Questo timestamp è essenziale per ordinare cronologicamente gli eventi e calcolare tutte le metriche basate sul tempo, come i tempi di attraversamento e le durate. Dove reperirlo Si tratta di un attributo derivato, ricavato da diversi campi timestamp presenti in varie tabelle Oracle Fusion, come la data di creazione dell'ordine, la data di spedizione, la data della fattura e la data del pagamento. Esempi 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Canale di vendita SalesChannel | Il 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'. Fornisce il contesto su come l'ordine è entrato nell'organizzazione. La segmentazione del processo per canale di vendita è fondamentale per il Dashboard 'Panoramica delle prestazioni dei canali di vendita'. Aiuta a confrontare l'efficienza, i tempi di attraversamento e i tassi di errore dei diversi canali, per individuare quelli più efficaci e quelli che potrebbero richiedere miglioramenti del processo 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 reperirlo 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 | La data in cui la merce è stata effettivamente consegnata al cliente. | ||
| Descrizione Questo attributo registra la data finale di consegna, che segna il completamento della parte di evasione del processo. Rappresenta il risultato effettivo rispetto al quale vengono misurate le date pianificate o richieste. Questa data viene confrontata con RequestedDeliveryDate per calcolare le prestazioni delle consegne puntuali. È un input fondamentale per il KPI 'Tasso di consegna puntuale' e per il Dashboard 'SLA della consegna', poiché fornisce una misura chiara dell'efficacia della logistica e della supply chain. Perché è importante È la data del risultato effettivo utilizzata per calcolare i tassi di consegna puntuale e valutare le prestazioni di evasione rispetto alle richieste del cliente. Dove reperirlo 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 | La data di consegna dell'ordine richiesta dal cliente. | ||
| Descrizione Questo attributo acquisisce la data in cui il cliente desidera ricevere la merce. Costituisce un obiettivo prestazionale fondamentale per la parte di evasione del processo Order to Cash. Questa data è essenziale per calcolare il KPI 'Tasso di consegna puntuale' e supportare il Dashboard 'Accordo sul livello di servizio della consegna (SLA)'. Confrontando questa data con ActualDeliveryDate, l'organizzazione può misurare la propria capacità di soddisfare le aspettative dei clienti e individuare le cause principali dei ritardi di consegna. Perché è importante Costituisce il riferimento per misurare le prestazioni delle consegne puntuali e la Conformità agli accordi sul livello di servizio (SLA) con il cliente. Dove reperirlo In genere si trova 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 | La data entro la quale il cliente deve effettuare il pagamento della 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. Stabilisce il termine per la riscossione puntuale del pagamento. Questo attributo è fondamentale per il KPI 'Tasso di riscossione puntuale dei pagamenti'. Confrontando PaymentDueDate con la data effettiva di ricezione del pagamento, il sistema può determinare se un pagamento è stato effettuato puntualmente o in ritardo, contribuendo a monitorare le prestazioni della contabilità clienti e a gestire il flusso di cassa. Perché è importante Funge da termine per il calcolo dei tassi di pagamento puntuale, una misura fondamentale dell'efficienza del flusso di cassa. Dove reperirlo Si trova nelle tabelle della contabilità clienti o delle fatture in Oracle Fusion, come AR_PAYMENT_SCHEDULES_ALL. Esempi 2023-06-192023-07-012023-06-25 | |||
| È automatizzato IsAutomated | Un indicatore che specifica se un'attività è stata eseguita automaticamente dal sistema o manualmente da un utente. | ||
| Descrizione Questo attributo booleano distingue tra eventi gestiti dal sistema, come la verifica automatizzata del credito o la fattura generata dal sistema, e azioni manuali degli utenti. In genere viene derivato in base al nome utente associato a un'attività, quando un ID di sistema generico indica l'automazione. L'analisi di questo attributo aiuta a misurare il livello di automazione del processo ed è un input diretto per il KPI 'Percentuale di ordini rilavorati manualmente'. Può mettere in evidenza 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 reperirlo Si tratta di un campo derivato, spesso basato su una regola applicata all'attributo UserName. Ad esempio, se l'utente è 'SYSTEM' o 'BATCH', questo indicatore viene impostato su true. Esempi truefalse | |||
| Importo totale dell'ordine di vendita SalesOrderTotalAmount | Il valore monetario totale dell'ordine di vendita. | ||
| Descrizione Questo attributo rappresenta l'importo totale addebitato al cliente per l'intero ordine di vendita. Include la somma di tutte le righe dell'ordine, le imposte e gli altri addebiti, prima dell'applicazione degli sconti. Nell'analisi dei processi, questo attributo è fondamentale per il Process Mining basato sul valore. Consente di segmentare gli ordini in base al valore, ad esempio ordini di valore elevato e ridotto, per verificare se seguono percorsi di processo diversi o presentano tempi di attraversamento differenti. Aiuta inoltre a dare priorità agli interventi di miglioramento sui casi con maggiore rilevanza finanziaria. Perché è importante Consente di analizzare l'impatto finanziario, aiutando a dare priorità ai miglioramenti dei processi per gli ordini di valore elevato e a comprendere i fattori che determinano i costi. Dove reperirlo In genere si trova 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 | Il nome del cliente che ha effettuato l'ordine di vendita. | ||
| Descrizione Questo attributo identifica la denominazione legale dell'account cliente associato all'ordine di vendita. È una dimensione fondamentale per segmentare e analizzare il processo da una prospettiva incentrata sul cliente. L'analisi per cliente aiuta a individuare se determinati clienti sperimentano tempi di attraversamento più lunghi, più rilavorazioni o specifiche deviazioni dal processo. Queste informazioni possono essere utilizzate per migliorare il servizio clienti, adattare i processi per gli account strategici e analizzare i problemi che incidono sulla soddisfazione del cliente. Perché è importante Consente un'analisi incentrata sul cliente per individuare i problemi di processo che interessano clienti specifici e migliorare la soddisfazione del cliente. Dove reperirlo Proviene dalle tabelle dei dati anagrafici 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 | Il nome o l'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 a livello di utente, la distribuzione del carico di lavoro e il rispetto delle procedure standard. L'analisi per utente aiuta a individuare le esigenze formative, riconoscere le persone o i team con prestazioni elevate e analizzare le deviazioni causate da utenti specifici. È inoltre utile ai fini della Conformità e dell'audit, poiché consente di tracciare chi ha eseguito ciascuna azione. Perché è importante Consente di analizzare le prestazioni per utente, la distribuzione del carico di lavoro e i modelli di rilavorazione manuale associati a singole persone. Dove reperirlo In genere proviene da campi come CREATED_BY o LAST_UPDATED_BY nelle tabelle delle transazioni Oracle Fusion, spesso collegati a una tabella anagrafica degli utenti come FND_USER. Esempi john.smithjane.doesystem_batch_user | |||
| Condizioni di pagamento PaymentTerms | Le condizioni concordate per il pagamento da parte del cliente. | ||
| Descrizione Questo attributo specifica le condizioni entro le quali il cliente deve pagare la fattura, ad esempio "Net 30" o "Net 60". Tali condizioni costituiscono la base per il calcolo di PaymentDueDate. Nell'analisi, la segmentazione per condizioni di pagamento può aiutare a spiegare le variazioni nei tempi del ciclo di pagamento. Fornisce il contesto necessario per il KPI "On-Time Payment Rate", poiché condizioni diverse determinano naturalmente comportamenti di pagamento differenti. Queste informazioni possono orientare la politica creditizia e le previsioni dei flussi di cassa. Perché è importante Fornisce un contesto fondamentale per analizzare i comportamenti di pagamento e aiuta a spiegare le variazioni nei tempi del ciclo dalla fatturazione al pagamento. Dove reperirlo Disponibile a livello di ordine di vendita o di account cliente in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi 30 giorni fine mese60 giorni fine mesePagamento alla ricezione | |||
| Consegna puntuale IsOnTimeDelivery | Un flag calcolato che assume valore true se la consegna effettiva è avvenuta entro o prima della data di consegna richiesta. | ||
| Descrizione Questo attributo booleano viene ricavato confrontando ActualDeliveryDate con RequestedDeliveryDate. Fornisce un indicatore semplice, a livello di caso, delle prestazioni di consegna. Questo flag costituisce la base per il calcolo del KPI aggregato "On-Time Delivery Rate". Semplifica i filtri e l'analisi, consentendo di isolare rapidamente tutti gli ordini consegnati in ritardo e di svolgere un'analisi delle cause principali dei fattori che contribuiscono ai ritardi. Perché è importante Misura direttamente le prestazioni della gestione degli ordini rispetto alle aspettative del cliente e semplifica l'analisi degli ordini consegnati in ritardo. Dove reperirlo Si tratta di un campo calcolato. La logica è: ActualDeliveryDate <= RequestedDeliveryDate. Esempi truefalse | |||
| Fattura corretta IsInvoiceCorrected | Un flag che indica se una fattura è stata corretta o modificata dopo la sua creazione iniziale. | ||
| Descrizione Questo attributo booleano assume valore true se una fattura è passata attraverso un ciclo di correzione, indicato dalla presenza dell'attività "Invoice Corrected". Segnala i casi che hanno comportato una rilavorazione nella fase di fatturazione. È un input fondamentale per la Dashboard "Invoice Accuracy & Rework Analysis" e per il KPI "Invoice Rework Rate". Aiuta a quantificare l'entità degli errori di fatturazione e consente di analizzarne le cause principali, individuando i motivi per cui sono necessarie correzioni, con l'obiettivo di ridurre il lavoro manuale e i ritardi nei pagamenti. Perché è importante Individua le rilavorazioni delle fatture, un indicatore fondamentale di inefficienza del processo, problemi di qualità dei dati e potenziali ritardi nei pagamenti. Dove reperirlo Si tratta di un campo calcolato, generalmente impostato su true per un caso se nel relativo Event Log è presente un'attività "Invoice Corrected". Esempi falsetrue | |||
| Metodo di spedizione ShippingMethod | Il metodo o il vettore utilizzato per spedire la merce al cliente. | ||
| Descrizione Questo attributo descrive 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 il Dashboard 'Conformità delle consegne per metodo di spedizione'. Consentono di confrontare le prestazioni delle consegne puntuali e i costi di spedizione tra diversi metodi e vettori, contribuendo a ottimizzare la strategia logistica e la selezione dei fornitori. Perché è importante Supporta direttamente l'analisi logistica, consentendo di confrontare le prestazioni di diversi vettori e metodi di spedizione. Dove reperirlo Disponibile nelle tabelle di spedizione e gestione degli ordini di Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi FedEx GroundUPS Next Day AirDHL International | |||
| Nome del prodotto ProductName | Il nome del prodotto o del servizio venduto. | ||
| Descrizione Questo attributo specifica l'articolo presente nella riga dell'ordine di vendita. Se un ordine contiene più righe, il caso può essere analizzato a livello di riga dell'articolo oppure questo attributo può essere aggregato a livello di intestazione. L'analisi per prodotto aiuta a comprendere se determinati prodotti sono associati a flussi di processo più complessi o problematici, ad esempio a frequenti ritardi di consegna o problemi di pagamento. Queste informazioni possono orientare le strategie di gestione dei prodotti e della supply chain. Perché è importante Consente di analizzare le prestazioni del processo per diversi prodotti, mettendo in evidenza gli articoli che possono presentare percorsi di evasione o fatturazione complessi. Dove reperirlo 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 fattura InvoiceNumber | L'identificativo univoco della fattura del cliente. | ||
| Descrizione Questo attributo corrisponde al numero univoco assegnato alla fattura generata dall'ordine di vendita. Collega le attività di vendita e gestione dell'ordine alla fase di regolamento finanziario del processo. Sebbene il Sales Order sia il principale ID del caso, il numero fattura è essenziale per analizzare i sottoprocessi di fatturazione e pagamento. È indispensabile per monitorare le correzioni delle fatture, le contestazioni e lo stato dei pagamenti, supportando Dashboard come "Invoice Accuracy & Rework Analysis". Perché è importante Fornisce un collegamento fondamentale con il processo di gestione dei crediti commerciali ed è necessario per analizzare le rilavorazioni delle fatture e i cicli di pagamento. Dove reperirlo Disponibile nelle tabelle delle transazioni dei crediti commerciali di Oracle Fusion, ad esempio RA_CUSTOMER_TRX_ALL. Esempi INV-93485INV-93486INV-93487 | |||
| Paese del cliente CustomerCountry | Il Paese in cui si trova il cliente. | ||
| Descrizione Questo attributo indica il Paese ricavato dall'indirizzo di spedizione o di fatturazione del cliente. Rappresenta una dimensione fondamentale per l'analisi geografica. La segmentazione del processo per Paese può evidenziare differenze regionali nelle prestazioni del processo, nei tempi di attraversamento o nei comportamenti di pagamento. Si tratta di un'informazione preziosa per comprendere l'impatto delle normative locali, delle difficoltà logistiche e delle condizioni di mercato sul processo Order to Cash. Perché è importante Consente di effettuare analisi geografiche per individuare variazioni regionali nell'efficienza del processo, nella conformità e nei comportamenti dei clienti. Dove reperirlo Ricavato dalle tabelle dei dati anagrafici dei clienti (HZ_LOCATIONS, HZ_PARTY_SITES) collegate all'ordine di vendita. Esempi USAGermaniaGiappone | |||
| Pagamento in ritardo IsLatePayment | Un flag calcolato che assume valore true se il pagamento è stato ricevuto dopo la data di scadenza. | ||
| Descrizione Questo attributo booleano viene ricavato confrontando la data effettiva di ricezione del pagamento con PaymentDueDate. Fornisce un indicatore chiaro del fatto che una fattura sia stata pagata puntualmente. Questo attributo viene utilizzato per calcolare il KPI "On-Time Payment Rate". Consente di segmentare facilmente i pagamenti puntuali e quelli in ritardo, analizzando le caratteristiche dei clienti che pagano in ritardo, le cause più frequenti 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 insoluti. Dove reperirlo Si tratta di un campo calcolato. La logica è: PaymentReceivedDate > PaymentDueDate. Esempi falsetrue | |||
| Sistema di origine SourceSystemIdentifier | Identifica il sistema di origine dal quale sono stati estratti i dati dell'evento. | ||
| Descrizione Questo attributo specifica l'origine dei dati, risultando particolarmente utile negli ambienti in cui al processo Order to Cash partecipano più sistemi. Ad esempio, i dati degli ordini possono provenire da Oracle Fusion, mentre quelli delle spedizioni possono avere origine in un sistema logistico di terze parti. Nell'analisi, aiuta a comprendere la provenienza dei dati e può essere utilizzato per filtrare la vista del processo in base agli eventi provenienti da sistemi specifici. È fondamentale per la convalida dei dati e per individuare la frammentazione del processo tra diversi ambienti IT. Perché è importante Fornisce il contesto sull'origine dei dati, fondamentale per la governance dei dati e la risoluzione dei problemi negli ambienti con più sistemi. Dove reperirlo In genere è un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l'origine del dataset. Esempi Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Tipo di ordine OrderType | Una classificazione dell'ordine di vendita, ad esempio "Standard Order" o "Return Order". | ||
| Descrizione Order Type viene utilizzato per classificare gli ordini di vendita in base alla loro finalità aziendale. Tra i tipi più comuni rientrano le vendite standard, gli ordini di servizio, le autorizzazioni al reso dei materiali (RMA) e gli ordini interni. Analizzare il processo per tipo di ordine è importante perché tipi diversi presentano spesso flussi di processo e obiettivi prestazionali distinti. Questa segmentazione aiuta a comprendere le variazioni di processo intenzionali e previste, evitando che vengano interpretate erroneamente come deviazioni. Perché è importante Consente di segmentare i diversi flussi di processo legittimi, ad esempio ordini standard e resi, per garantire un'analisi corretta e accurata. Dove reperirlo Generalmente disponibile come campo nella tabella dell'intestazione dell'ordine di vendita in Oracle Fusion. Consultare la documentazione di Oracle Fusion Financials. Esempi Ordine di vendita standardAutorizzazione al resoOrdine di servizio | |||
| Ultimo aggiornamento dei dati LastUpdateDate | Il timestamp che indica l'ultima volta in cui i dati relativi a questo evento sono stati aggiornati dal sistema di origine. | ||
| Descrizione Questo attributo registra quando i dati sono stati estratti o aggiornati l'ultima volta nel dataset di Process Mining. Fornisce trasparenza sull'aggiornamento dei dati analizzati. Queste informazioni sono fondamentali per consentire agli utenti di comprendere quanto sia aggiornata l'analisi del processo. Aiutano a gestire le aspettative sulla tempestività dei dati e sono importanti per configurare e monitorare le pianificazioni di aggiornamento dei dati. Perché è importante Indica l'aggiornamento dei dati e garantisce che gli utenti sappiano quanto sia attuale l'analisi del processo. Dove reperirlo Questo valore viene generato e applicato al dataset durante ogni ciclo di estrazione e trasformazione dei dati. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Unità aziendale BusinessUnitName | Il nome dell'unità aziendale interna responsabile dell'ordine di vendita. | ||
| Descrizione Questo attributo rappresenta la divisione o l'unità operativa specifica dell'azienda proprietaria della transazione. Consente di confrontare le prestazioni tra diverse aree dell'organizzazione. La segmentazione del processo per unità aziendale aiuta a individuare variazioni di efficienza, costi e Conformità all'interno dell'azienda. L'analisi può rivelare le best practice delle unità più performanti, da condividere, oppure mettere in evidenza le unità con prestazioni inferiori che richiedono interventi di miglioramento mirati. Perché è importante Consente di effettuare benchmarking delle prestazioni e analizzare la coerenza dei processi tra diverse unità organizzative. Dove reperirlo In genere è disponibile nell'intestazione dell'ordine di vendita ed è collegato alla struttura organizzativa definita in Oracle Fusion. Esempi BU-North AmericaBU-EMEAGlobal Services | |||
Attività dell’elaborazione degli ordini di vendita da Order to Cash
| Attività | Descrizione | ||
|---|---|---|---|
| Fattura creata | Questa attività rappresenta la creazione della fattura cliente nel modulo Accounts Receivable, generalmente attivata dall'evento di conferma della spedizione. Viene generato un record di fattura con un numero univoco e una data di creazione. | ||
| Perché è importante Segna l'inizio ufficiale del ciclo di riscossione dei pagamenti. Costituisce la base per misurare il 'Tempo dalla fattura al pagamento' e l'efficienza complessiva del flusso di cassa. Dove reperirlo È un evento esplicito in Oracle Accounts Receivable (AR). Un record di fattura viene creato nella tabella RA_CUSTOMER_TRX_ALL con una data della transazione. Acquisizione Acquisito dalla data di creazione della transazione di fatturazione nel modulo AR. Tipo di evento explicit | |||
| Merce spedita | Questa attività indica il momento in cui la merce è stata spedita dal magazzino ed è in transito verso il cliente. Viene acquisita quando una transazione di conferma della spedizione viene elaborata in Oracle Shipping. | ||
| Perché è importante Si tratta di una tappa fondamentale, che indica il completamento della parte di evasione del processo e attiva la fatturazione. È essenziale per misurare la puntualità delle spedizioni e i tempi di attraversamento della consegna. Dove reperirlo È un evento esplicito registrato in Oracle Shipping Execution. La transazione di conferma della spedizione crea un record in tabelle di spedizione come WSH_DELIVERY_DETAILS, con una data di spedizione. Acquisizione Acquisito dal timestamp della 'data effettiva di spedizione' nel record dei dettagli di consegna associato alla riga dell'ordine. Tipo di evento explicit | |||
| Ordine chiuso | L'attività finale del processo indica che tutte le righe dell'ordine di vendita sono state evase, fatturate e chiuse. Lo stato dell'intestazione dell'ordine viene aggiornato a 'Chiuso'. | ||
| Perché è importante Questa attività segna la conclusione positiva del ciclo di vita dell'ordine di vendita. È essenziale per calcolare le durate end-to-end del processo e individuare gli ordini zombie che non vengono mai chiusi. Dove reperirlo Deducibile dalla variazione dello stato dell'intestazione dell'ordine di vendita a 'Chiuso' nella tabella DOO_HEADERS_ALL. Il timestamp di questa variazione di stato finale rappresenta l'orario dell'evento. Acquisizione Derivato dal timestamp della variazione dello stato a 'Chiuso' sull'intestazione dell'ordine di vendita. Tipo di evento inferred | |||
| Ordine confermato | Questa tappa fondamentale indica che l'ordine di vendita ha superato tutti i controlli iniziali, inclusa l'approvazione del credito, ed è ora impegnato per l'evasione. In genere viene dedotta quando lo stato dell'ordine passa a uno stato come 'In attesa di spedizione' o 'Pianificato'. | ||
| Perché è importante Questa attività rappresenta una tappa fondamentale per il calcolo del 'Tempo medio di conferma dell'ordine' e segna il passaggio dall'inserimento dell'ordine al processo di evasione. Dove reperirlo Deducibile dalla variazione dello stato dell'intestazione o della riga dell'ordine di vendita a un valore che indica la disponibilità per l'evasione, ad esempio 'In attesa di spedizione'. Verificare le colonne di stato in DOO_HEADERS_ALL o DOO_FULFILL_LINES_ALL. Acquisizione Derivato dal timestamp della variazione dello stato dell'ordine a uno stato confermato o pianificato. Tipo di evento inferred | |||
| Ordine di vendita creato | Questa attività segna l'inizio del processo relativo all'ordine di vendita e rappresenta il momento in cui un nuovo ordine viene inserito in Oracle Fusion. L'evento viene generalmente acquisito in modo esplicito quando un utente salva un nuovo record d'ordine nel modulo Order Management. | ||
| Perché è importante In quanto punto di avvio del processo, questa attività è essenziale per misurare il tempo complessivo del ciclo Order to Cash e analizzare i volumi degli ordini acquisiti. Dove reperirlo Registrato in modo esplicito al momento della creazione di un record relativo a un ordine di vendita in Order Management Cloud. Cercare i timestamp di creazione nella tabella DOO_HEADERS_ALL. Acquisizione Acquisito dal timestamp di creazione del record di intestazione dell'ordine di vendita. Tipo di evento explicit | |||
| Pagamento ricevuto | Questa attività indica che il pagamento del cliente è stato ricevuto e abbinato alla fattura in Accounts Receivable. Viene acquisita quando viene registrata l'applicazione di un incasso. | ||
| Perché è importante È una tappa fondamentale per misurare il 'Tempo complessivo del ciclo Order to Cash' e il 'Tasso di pagamento puntuale'. Rappresenta la conversione della vendita in liquidità. Dove reperirlo È un evento esplicito in Oracle Accounts Receivable. Viene registrato in tabelle degli incassi come AR_RECEIVABLE_APPLICATIONS_ALL quando un incasso viene applicato a una fattura. Acquisizione Acquisito dal timestamp della 'data di applicazione' del record di applicazione dell'incasso in AR. Tipo di evento explicit | |||
| Blocco per credito applicato | Questa attività si verifica quando un ordine di vendita viene bloccato automaticamente o manualmente a causa di una verifica del credito non superata o di un altro problema legato al credito. In genere viene acquisita tramite una variazione dello stato di blocco dell'ordine nel sistema. | ||
| Perché è importante Il monitoraggio dei blocchi per credito è fondamentale per individuare le cause dei ritardi nell'elaborazione degli ordini e misurare l'efficienza del processo di rimozione del blocco. Dove reperirlo Deducibile dall'applicazione di un blocco all'ordine di vendita. In genere viene registrato in tabelle relative ai blocchi, come DOO_HOLDS_ALL, collegate all'ordine di vendita. Acquisizione Deducibile dalla creazione di un record nella tabella dei blocchi dell'ordine con tipo di blocco 'Credito'. Tipo di evento inferred | |||
| Fattura corretta | Si verifica quando una fattura precedentemente creata viene modificata, riemessa o accreditata a causa di errori o contestazioni del cliente. In genere viene acquisita tramite la creazione di una nota di credito o di una nuova versione della fattura. | ||
| Perché è importante Il monitoraggio delle correzioni delle fatture è fondamentale per il KPI 'Tasso di rilavorazione delle fatture', poiché mette in evidenza i problemi nel processo di fatturazione che possono ritardare i pagamenti e aumentare i costi amministrativi. Dove reperirlo Deducibile 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 Derivato dall'identificazione di note di credito o fatture che fanno riferimento a una transazione di fatturazione precedente. Tipo di evento inferred | |||
| Inventario riservato | Questa attività rappresenta l'allocazione o la prenotazione dell'inventario fisico necessario per evadere la riga dell'ordine di vendita. Il sistema impegna scorte specifiche, garantendone la disponibilità quando l'ordine è pronto per il prelievo. | ||
| Perché è importante Il monitoraggio di questa attività aiuta ad analizzare il KPI 'Tempo di attraversamento dell'allocazione dell'inventario' e a individuare i ritardi tra la conferma dell'ordine e la messa a disposizione della merce. Dove reperirlo Questo evento viene spesso acquisito nei moduli di gestione dell'inventario o di esecuzione della supply chain. Può essere dedotto dagli aggiornamenti dello stato della riga di evasione che indicano che l'inventario è stato dettagliato o riservato. Acquisizione Deducibile dalle variazioni dello stato della riga di evasione relative alla prenotazione o alla pianificazione dell'inventario. Tipo di evento inferred | |||
| Merce consegnata | Indica che il cliente ha ricevuto la spedizione. Queste informazioni provengono spesso da un vettore esterno e vengono aggiornate in Oracle Fusion, oppure possono essere dedotte sulla base di un tempo di transito standard calcolato dalla data di spedizione. | ||
| Perché è importante Questa attività è fondamentale per calcolare il KPI 'Tasso di consegna puntuale' e misurare con precisione i livelli di servizio al cliente. Dove reperirlo Spesso non è un evento nativo di Oracle. Può essere acquisito se è disponibile un'integrazione con il vettore, oppure calcolato aggiungendo un tempo di transito standard alla data di 'Merce spedita'. Richiede un'analisi del sistema. Acquisizione Deducibile dai flussi di dati del vettore o calcolato sulla base della data di spedizione più un tempo medio di transito. Tipo di evento inferred | |||
| Merce prelevata | Rappresenta il prelievo fisico della merce dal magazzino per evadere l'ordine. È un passaggio fondamentale del processo logistico e viene generalmente registrato nel modulo di gestione del magazzino o delle spedizioni. | ||
| Perché è importante Questa attività offre visibilità sulle operazioni di magazzino. I ritardi tra la prenotazione dell'inventario e il prelievo possono indicare problemi di risorse o colli di bottiglia di processo nel magazzino. Dove reperirlo Acquisito nei moduli Oracle Fusion Cloud SCM (Supply Chain Management). Può essere dedotto dalla variazione dello stato di una pick wave o di una pick slip associata alla riga dell'ordine di vendita. Acquisizione Deducibile dal timestamp di completamento della transazione di prelievo nei moduli SCM. Tipo di evento inferred | |||
| Ordine annullato | Rappresenta l'annullamento di un ordine di vendita prima che sia stato completamente spedito. Può verificarsi per diversi motivi e determina lo stato terminale 'Annullato'. | ||
| Perché è importante Si tratta di un percorso di eccezione fondamentale. L'analisi degli ordini annullati aiuta a individuare le cause principali, come esaurimento delle scorte, problemi di prezzo o ripensamento del cliente, fornendo indicazioni per migliorare il processo. Dove reperirlo Deducibile dalla variazione dello stato dell'intestazione o della riga dell'ordine di vendita allo stato 'Annullato'. Il timestamp di questa variazione di stato viene utilizzato per registrare l'evento. Acquisizione Derivato dal timestamp della variazione dello stato a 'Annullato' sull'intestazione o sulla riga dell'ordine. Tipo di evento inferred | |||
| Riga dell'ordine chiusa | Rappresenta la chiusura definitiva di una singola riga dell'ordine di vendita e indica che è stata completamente spedita e fatturata, senza ulteriori transazioni previste. Il sistema aggiorna lo stato della riga a 'Chiuso'. | ||
| Perché è importante La chiusura delle righe dell'ordine indica il completamento di tutti gli obblighi contrattuali relativi a quell'articolo. L'analisi aiuta a individuare gli ordini che rimangono aperti a lungo dopo l'evasione e il pagamento. Dove reperirlo Deducibile dalla variazione dello stato della riga di evasione a 'Chiuso' nella tabella DOO_FULFILL_LINES_ALL. Il timestamp di questa variazione di stato identifica l'evento. Acquisizione Derivato dal timestamp della variazione dello stato a 'Chiuso' sulla riga di evasione. Tipo di evento inferred | |||
| Verifica del credito eseguita | Rappresenta l'esecuzione di una verifica del credito sull'account del cliente per valutarne l'affidabilità creditizia. Si tratta spesso di un passaggio automatizzato o manuale all'interno del Workflow di elaborazione degli ordini, il cui completamento viene generalmente registrato come aggiornamento dello stato o attività completata. | ||
| Perché è importante L'analisi del tempo necessario per le verifiche del credito aiuta a individuare i colli di bottiglia nell'approvazione degli ordini. È fondamentale per il KPI 'Tempo dalla verifica del credito alla conferma'. Dove reperirlo Può essere dedotta dalle variazioni di stato dell'ordine di vendita, ad esempio dal passaggio allo stato 'Approvazione del credito in sospeso', oppure da un Event Log esplicito nella funzionalità di gestione del credito. Acquisizione Deducibile dalle variazioni dello stato dell'ordine o dai timestamp associati alle attività di revisione del credito. Tipo di evento inferred | |||
Guide all'estrazione
Passaggi
- Acceda a Oracle BI Publisher: acceda al Suo ambiente Oracle Fusion con un utente che disponga dei privilegi BI Administrator o BI Author. Utilizzi il menu Navigator per accedere a Tools > Reports and Analytics. Faccia clic sul pulsante 'Browse Catalog' per aprire il Business Intelligence Catalog.
- Crei un nuovo Data Model: nel BI Catalog, acceda a una cartella appropriata, 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 Data Model, faccia clic sull'icona '+' per creare un nuovo dataset e selezioni 'SQL Query'. Verrà visualizzata una finestra di dialogo. Assegni un nome al dataset, ad esempio 'OrderToCash_EventLog', selezioni 'Oracle BI EE' come Data Source 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 di inizio e di fine (:p_start_date e :p_end_date), che BI Publisher riconoscerà automaticamente.
- Configuri le proprietà del Data Model: dopo aver incollato la query, faccia clic su 'OK'. Acceda alla sezione 'Properties' nel riquadro sinistro dell'editor del Data Model. Verifichi che 'Include Parameter Tags' sia selezionato. Se necessario, può anche impostare valori predefiniti per i parametri delle date.
- Visualizzi e salvi il Data Model: faccia clic sulla scheda 'Data'. Potrebbe essere richiesto di inserire i valori dei parametri delle date. Inserisca un intervallo breve per eseguire un test. Faccia clic su 'View' per visualizzare un campione dei dati. Se i dati vengono visualizzati correttamente, salvi il Data Model facendo clic sull'icona di salvataggio e assegnandogli un nome descrittivo, ad esempio 'OrderToCash_EventLog_DM'.
- Crei un report dal Data Model: dopo aver salvato il Data Model, faccia clic sul pulsante 'Create Report' nell'angolo superiore destro. Si aprirà la procedura guidata per la creazione del report.
- Configuri il report: nella procedura guidata, selezioni l'opzione 'Use Data Model'. La procedura guidata 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 come 'OrderToCash_EventLog_Report'.
- Esegua il report: apra il report appena creato. Le verrà richiesto di inserire le date di inizio e di fine dell'estrazione. Indichi l'intervallo di date desiderato.
- Esporti i dati: una volta eseguito il report, faccia clic sul menu a discesa 'View' e selezioni un'opzione di visualizzazione diversa, 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. 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 con privilegi per creare modelli dati e report in BI Publisher, come «BI Administrator» o «BI Author».
- Origine dei dati: la query è progettata per l’origine dati applicativa standard «Oracle BI EE», che si connette 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 batch gestibili, ad esempio 3-6 mesi alla volta, per evitare timeout dei report e problemi di prestazioni.
- Filtraggio per unità aziendale: per limitare l’ambito dell’estrazione, può aggiungere una clausola WHERE alla CTE BaseOrders nella query, filtrando per uno specifico ID dell’unità aziendale, ad esempio AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtraggio 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 set di dati molto grandi che coprono diversi anni, questo approccio basato su un’unica query può essere lento. Valuti l’esecuzione negli orari di minore attività oppure suddivida l’estrazione in batch mensili più piccoli. Si assicuri che la proprietà «Enable SQL Pruning» non sia selezionata nel Data Model, poiché potrebbe interferire con query UNION complesse.
a 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 alla Sua istanza Oracle Fusion Applications con un utente che disponga del ruolo BICC_ADMINISTRATOR. Acceda a Tools e selezioni Business Intelligence Cloud Connector dal menu.
- Crei una nuova Offering: nella console BICC, faccia clic su Configure External Storage per configurare la destinazione. Può scegliere Oracle Universal Content Management (UCM) oppure un bucket OCI Object Storage. Verifichi che i dettagli della connessione e le credenziali siano corretti.
- Avvii un nuovo job di estrazione: acceda alla sezione Manage Extract Jobs. Faccia clic sull'icona + per creare un nuovo job. Gli assegni un nome descrittivo, ad esempio ProcessMind_O2C_SalesOrder_Extract.
- Selezioni i Data Store (PVO): nella configurazione del job, cerchi e aggiunga i Public View Objects (PVO) necessari per acquisire il ciclo di vita dell'ordine di vendita. Dovrà aggiungere diversi 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 ogni PVO: per ciascun PVO selezionato, faccia clic sul menu Actions e scelga Select Columns. Selezioni con attenzione le colonne necessarie per generare l'Event Log, come HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate e gli identificativi degli utenti. Per l'elenco dettagliato delle colonne richieste per ciascun PVO, consulti il query manifest.
- Applichi i filtri per i caricamenti incrementali: per gestire il volume dei dati, applichi a ogni 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 job.
- Pianifichi il job di estrazione: acceda alla sezione Manage Schedule. Crei una nuova pianificazione per il job. È consigliabile eseguire il job negli orari di minore attività, ad esempio ogni notte, per ridurre al minimo l'impatto sulle prestazioni del sistema.
- Invii e monitori il job: dopo aver completato la configurazione, invii il job. Può monitorarne l'avanzamento dalla schermata Manage Extract Jobs. Al termine, 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 formattato. Dovrà utilizzare uno strumento esterno, come Python, uno script per database o una piattaforma ETL, per elaborare questi file. L'operazione comprende:
- 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 di attività distinte. Ad esempio, dal file FscmTopModelAM.DooTopAM.Header può creare una riga per Sales Order Created utilizzando CreationDate e un'altra per Order Closed utilizzando ClosedDate.
- Mappare i codici di stato o i flag su 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.
- Formatti il file per il caricamento: verifichi che il file trasformato finale sia un unico CSV, con colonne corrispondenti agli Attributi richiesti e consigliati. Il file è ora pronto per essere caricato in ProcessMind.
Configurazione
- Selezione dei PVO: l’accuratezza dell’Event Log dipende interamente dalla selezione 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 e impedisce di estrarre ripetutamente lo stesso set di dati di diversi gigabyte. Il caricamento completo iniziale deve stabilire una base di riferimento, mentre le esecuzioni successive devono acquisire 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 nell’UCM di Oracle o in OCI Object Storage. In genere OCI Object Storage è consigliato per gli scenari con estrazioni massive e per una più semplice integrazione con gli strumenti ETL a valle.
- Pianificazione dei processi: pianifichi i processi di estrazione negli orari non lavorativi, per evitare possibili peggioramenti delle prestazioni sul sistema transazionale Oracle Fusion Financials.
- Prerequisiti: gli utenti che configurano il processo devono disporre del ruolo BICC_ADMINISTRATOR. È inoltre necessario aver configurato in anticipo le credenziali per l’archiviazione cloud e conoscere chiaramente la logica di trasformazione dei dati richiesta dopo l’estrazione.
a 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 filteringPronto per iniziare?
Utilizzi questo Template per semplificare la raccolta dei dati e avviare il Suo percorso nel Process Mining. Inizi oggi stesso a ottimizzare l'elaborazione degli ordini di vendita nel processo Order to Cash.
Ottimizzi oggi l'elaborazione degli ordini di vendita nel processo Order to Cash
Individui i colli di bottiglia e riduca facilmente del 30% i tempi del ciclo Order to Cash.
Non è richiesta alcuna carta di credito. Prova gratuita di 14 giorni.