Šablona dat pro proces od objednávky k inkasu při zpracování prodejních objednávek
Šablona dat pro proces od objednávky k inkasu při zpracování prodejních objednávek
- Doporučené atributy ke sběru
- Důležité aktivity ke sledování
- Praktický návod k extrakci dat
Atributy procesu od objednávky k inkasu při zpracování prodejních objednávek
| Název | Popis | ||
|---|---|---|---|
| Prodejní objednávka SalesOrder | Jedinečný identifikátor prodejní objednávky, který slouží jako hlavní případ procesu od objednávky k inkasu. | ||
| Popis Číslo prodejní objednávky jednoznačně identifikuje každou zákaznickou objednávku po celou dobu jejího životního cyklu. Propojuje všechny související aktivity, od vytvoření a potvrzení objednávky přes její plnění a fakturaci až po konečnou úhradu. V process mining se tento atribut používá k seskupení souvisejících událostí do jednoho případu. Analýza podle prodejní objednávky poskytuje úplný přehled od začátku do konce. Umožňuje vypočítat celkovou dobu cyklu, určit varianty procesu u jednotlivých objednávek a sledovat jejich průchod různými odděleními a systémy. Proč je to důležité Jde o ID případu. Propojuje všechny události procesu a umožňuje sledovat průchod jedné zákaznické objednávky od začátku do konce. Kde data získat Tento identifikátor se obvykle nachází v tabulce hlaviček prodejních objednávek v Oracle Fusion, například DOO_HEADERS_ALL. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady SO-100567SO-100568SO-100569 | |||
| Čas události EventTime | Časové razítko určující, kdy u prodejní objednávky došlo ke konkrétní aktivitě nebo události. | ||
| Popis Tento atribut uvádí datum a čas každé aktivity v procesu a určuje chronologické pořadí událostí. Je časovým základem analýzy procesu a zaznamenává, kdy přesně k jednotlivým krokům došlo. V process mining je EventTime nezbytný pro výpočet doby cyklu, trvání mezi aktivitami a celkové doby průchodu případu. Umožňuje analyzovat výkonnost, odhalovat úzká místa podle čekacích dob a sledovat dodržování dohod o úrovni služeb (SLA) z hlediska včasnosti. Přesnost tohoto atributu ovlivňuje všechny časové KPI a dashboardy. Proč je to důležité Toto časové razítko je nezbytné pro chronologické seřazení událostí a výpočet všech časových ukazatelů, například doby cyklu a trvání. Kde data získat Jde o odvozený atribut, který čerpá údaje z různých polí časových razítek v tabulkách Oracle Fusion, například z data vytvoření objednávky, odeslání zásilky, vystavení faktury a přijetí platby. Příklady 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Název aktivity ActivityName | Název konkrétní obchodní události nebo úkolu, ke kterému došlo v procesu prodejní objednávky. | ||
| Popis Tento atribut popisuje krok, který byl v určitém okamžiku proveden v rámci prodejní objednávky, například „Prodejní objednávka vytvořena“, „Zboží odesláno“ nebo „Platba přijata“. Pořadí těchto aktivit tvoří tok procesu pro každý případ. Analýza atributu ActivityName je základem process mining. Umožňuje zobrazit mapu procesu, odhalit různé varianty procesu a určit úzká místa, kde se případy hromadí. Slouží také k výpočtu doby přechodu mezi kroky a k pochopení provozního sledu procesu od objednávky k inkasu. Proč je to důležité Tento atribut určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat tok procesu. Kde data získat Jde o odvozený atribut, který vzniká mapováním stavů transakcí nebo typů událostí z různých tabulek Oracle Fusion, například stavu objednávky, zásilky či faktury, na standardizovaný seznam názvů aktivit. Příklady Vytvoření prodejní objednávkyOdeslání zbožíVytvoření fakturyPlatba přijata | |||
| Celková hodnota prodejní objednávky SalesOrderTotalAmount | Celková peněžní hodnota prodejní objednávky. | ||
| Popis Tento atribut představuje celkovou částku účtovanou zákazníkovi za celou prodejní objednávku. Zahrnuje součet všech položek, daní a dalších poplatků před uplatněním slev. Při analýze procesu umožňuje process mining podle hodnoty objednávky. Objednávky lze rozdělit podle hodnoty, například na vysoké a nízké, a zjistit, zda procházejí různými cestami nebo mají odlišnou dobu cyklu. Pomáhá také zaměřit zlepšování procesů na případy s největším finančním dopadem. Proč je to důležité Umožňuje analyzovat finanční dopad, zaměřit zlepšování procesů na objednávky s vysokou hodnotou a porozumět faktorům ovlivňujícím náklady. Kde data získat Obvykle se nachází v tabulkách hlaviček prodejních objednávek v Oracle Fusion. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady 5250.00125000.75980.50 | |||
| Datum splatnosti platby PaymentDueDate | Datum, do kterého musí zákazník uhradit fakturu. | ||
| Popis Datum splatnosti platby se vypočítá podle data vystavení faktury a platebních podmínek dohodnutých se zákazníkem. Určuje termín včasné úhrady. Tento atribut je důležitý pro KPI „Podíl včas vybraných plateb“. Porovnáním PaymentDueDate se skutečným datem přijetí platby systém určí, zda byla platba uhrazena včas, nebo se zpožděním. To pomáhá sledovat výkonnost pohledávek a řídit peněžní tok. Proč je to důležité Slouží jako termín pro výpočet podílu včasných plateb, který je důležitým ukazatelem efektivity peněžního toku. Kde data získat Nachází se v tabulkách pohledávek nebo faktur v Oracle Fusion, například AR_PAYMENT_SCHEDULES_ALL. Příklady 2023-06-192023-07-012023-06-25 | |||
| Je automatizováno IsAutomated | Příznak určující, zda aktivitu provedl automaticky systém, nebo ručně uživatel. | ||
| Popis Tento booleovský atribut rozlišuje mezi událostmi řízenými systémem, například automatickou kontrolou úvěruschopnosti nebo systémem vytvořenou fakturou, a ručními úkony uživatele. Obvykle se odvozuje od uživatelského jména přiřazeného k aktivitě, přičemž obecné ID systému označuje automatizaci. Analýza tohoto atributu pomáhá měřit míru automatizace procesu a přímo slouží jako vstup pro KPI „Podíl objednávek přepracovaných ručně“. Může ukázat příležitosti k další automatizaci tím, že odhalí ruční kroky, které zaberou nejvíce času nebo u nichž nejčastěji dochází k chybám. Proč je to důležité Pomáhá měřit míru automatizace procesu a určit možnosti, jak omezit nákladné ruční zásahy. Kde data získat Jde o odvozené pole, které se často určuje podle pravidla aplikovaného na atribut UserName. Pokud je například uživatel „SYSTEM“ nebo „BATCH“, nastaví se příznak na true. Příklady truefalse | |||
| Název zákazníka CustomerName | Jméno zákazníka, který zadal prodejní objednávku. | ||
| Popis Tento atribut určuje oficiální název zákaznického účtu spojeného s prodejní objednávkou. Umožňuje členit a analyzovat proces z pohledu zákazníka. Analýza podle zákazníka pomáhá zjistit, zda mají někteří zákazníci delší dobu cyklu, častěji se u nich práce přepracovává nebo se u nich objevují konkrétní odchylky od procesu. Tato zjištění lze využít ke zlepšení zákaznického servisu, přizpůsobení procesů důležitým zákazníkům a prověření problémů, které ovlivňují jejich spokojenost. Proč je to důležité Umožňuje analyzovat proces z pohledu zákazníka, odhalit problémy týkající se konkrétních zákazníků a zlepšit jejich spokojenost. Kde data získat Získává se z hlavních tabulek zákazníků, například HZ_PARTIES, a propojuje se s prodejní objednávkou pomocí ID zákazníka. Příklady Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Požadované datum dodání RequestedDeliveryDate | Datum dodání, které zákazník požaduje. | ||
| Popis Tento atribut zaznamenává datum, kdy chce zákazník zboží obdržet. Slouží jako důležitý výkonnostní cíl pro část procesu od objednávky k inkasu, která se týká plnění objednávky. Datum je nezbytné pro výpočet KPI „Podíl včasných dodávek“ a pro dashboard „Dohoda o úrovni dodávek (SLA)“. Porovnáním tohoto data s atributem ActualDeliveryDate může organizace měřit, jak dobře plní očekávání zákazníků, a odhalovat příčiny zpoždění dodávek. Proč je to důležité Slouží jako základ pro měření včasnosti dodávek a dodržování dohod o úrovni služeb (SLA) se zákazníky. Kde data získat Obvykle se nachází v tabulkách položek řádků prodejních objednávek v Oracle Fusion. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady 2023-05-202023-06-012023-05-25 | |||
| Prodejní kanál SalesChannel | Kanál, kterým byla prodejní objednávka přijata. | ||
| Popis Tento atribut označuje původ prodejní objednávky, například „Web“, „Přímý prodej“, „Partner“ nebo „EDI“. Ukazuje, jak se objednávka dostala do organizace. Členění procesu podle prodejního kanálu je důležité pro dashboard „Přehled výkonnosti prodejních kanálů“. Umožňuje porovnat efektivitu, dobu cyklu a chybovost jednotlivých kanálů a zjistit, které fungují nejlépe a kde je vhodné zlepšit procesy nebo zavést další automatizaci. Proč je to důležité Podporuje analýzu výkonnosti podle kanálu a pomáhá určit, které kanály jsou při zpracování objednávek nejefektivnější a nejméně efektivní. Kde data získat Tyto informace mohou být uloženy ve vyhrazeném poli hlavičky prodejní objednávky. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady Přímý prodejWebový portálEDIProdejce | |||
| Skutečné datum dodání ActualDeliveryDate | Datum, kdy bylo zboží skutečně doručeno zákazníkovi. | ||
| Popis Tento atribut zaznamenává konečné datum dodání, které označuje dokončení části procesu týkající se plnění objednávky. Jde o skutečný výsledek, se kterým se porovnávají plánovaná nebo požadovaná data. Porovnáním s atributem RequestedDeliveryDate se vypočítá včasnost dodání. Datum je důležitým vstupem pro KPI „Podíl včasných dodávek“ a dashboard „SLA dodávek“. Poskytuje jasný ukazatel efektivity logistiky a dodavatelského řetězce. Proč je to důležité Jde o skutečné datum dodání, které se používá k výpočtu podílu včasných dodávek a hodnocení plnění objednávek podle požadavků zákazníků. Kde data získat Získává se z tabulek transakcí odeslání a doručení v Oracle Fusion. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady 2023-05-202023-06-032023-05-25 | |||
| Uživatelské jméno UserName | Jméno nebo ID uživatele, který aktivitu provedl. | ||
| Popis Tento atribut určuje zaměstnance nebo systémového uživatele odpovědného za provedení konkrétního kroku procesu. Lze jej využít k analýze výkonnosti uživatelů, rozložení pracovní zátěže a dodržování standardních postupů. Analýza podle uživatele pomáhá určit potřeby školení, rozpoznat výkonné jednotlivce či týmy a prověřit odchylky způsobené konkrétními uživateli. Hodí se také pro sledování toho, kdo provedl jednotlivé úkony, například při auditu nebo kontrole shody. Proč je to důležité Umožňuje analyzovat výkonnost podle uživatelů, rozložení pracovní zátěže a vzorce ručního přepracování spojené s konkrétními osobami. Kde data získat Obvykle se získává z polí jako CREATED_BY nebo LAST_UPDATED_BY v transakčních tabulkách Oracle Fusion a často se propojuje s hlavní tabulkou uživatelů, například FND_USER. Příklady john.smithjane.doesystem_batch_user | |||
| Byla faktura opravena IsInvoiceCorrected | Příznak označující, zda byla faktura po prvním vytvoření opravena nebo upravena. | ||
| Popis Tato logická hodnota je true, pokud faktura prošla cyklem oprav, což dokládá aktivita „Invoice Corrected“. Označuje případy, kdy bylo nutné fakturu znovu zpracovat. Jde o důležitý vstup pro dashboard „Invoice Accuracy & Rework Analysis“ a KPI „Invoice Rework Rate“. Pomáhá vyčíslit rozsah chyb při fakturaci a hledat jejich příčiny, aby bylo možné omezit ruční práci a zpoždění plateb. Proč je to důležité Odhaluje opakované zpracování faktur, které může ukazovat na neefektivní proces, problémy s kvalitou dat nebo možné zpoždění plateb. Kde data získat Jde o vypočítané pole, které má u případu obvykle hodnotu true, pokud jeho záznam událostí obsahuje aktivitu „Invoice Corrected“. Příklady falsetrue | |||
| Číslo faktury InvoiceNumber | Jedinečný identifikátor zákaznické faktury. | ||
| Popis Tento atribut je jedinečné číslo přidělené faktuře vystavené na základě prodejní objednávky. Propojuje prodejní a plnicí aktivity s finančním vypořádáním. Hlavním ID případu je prodejní objednávka, ale číslo faktury je důležité pro analýzu fakturace a plateb. Umožňuje sledovat opravy faktur, spory a stav plateb a podporuje dashboardy, jako je „Analýza správnosti a přepracování faktur“. Proč je to důležité Propojuje proces s pohledávkami a je nezbytné pro analýzu přepracování faktur a platebních cyklů. Kde data získat Je k dispozici v tabulkách transakcí pohledávek v Oracle Fusion, například RA_CUSTOMER_TRX_ALL. Příklady INV-93485INV-93486INV-93487 | |||
| Dodáno včas IsOnTimeDelivery | Vypočítaný příznak, který má hodnotu true, pokud bylo zboží doručeno v požadovaném termínu nebo dříve. | ||
| Popis Tento booleovský atribut se odvozuje porovnáním ActualDeliveryDate s RequestedDeliveryDate. Poskytuje jednoduchý ukazatel výkonnosti dodání na úrovni případu. Příznak slouží jako základ pro výpočet souhrnného KPI „Podíl včasných dodávek“. Usnadňuje filtrování a analýzu, takže uživatelé mohou rychle vybrat všechny opožděné objednávky a zjistit příčiny zpoždění. Proč je to důležité Přímo měří, jak plnění objednávek odpovídá očekáváním zákazníků, a usnadňuje analýzu opožděných objednávek. Kde data získat Jde o vypočítané pole. Logika: ActualDeliveryDate <= RequestedDeliveryDate. Příklady truefalse | |||
| Název produktu ProductName | Název prodávaného produktu nebo služby. | ||
| Popis Tento atribut určuje položku na řádku prodejní objednávky. Pokud má objednávka více řádků, lze případ analyzovat na úrovni položky nebo tento atribut agregovat na úrovni hlavičky. Analýza podle produktu pomáhá zjistit, zda jsou některé produkty spojeny se složitějšími nebo problematičtějšími průběhy procesu, například s častým zpožděním dodávek nebo problémy s platbami. Tato zjištění mohou být užitečná při řízení produktů a plánování dodavatelského řetězce. Proč je to důležité Umožňuje analyzovat výkonnost procesu u různých produktů a odhalit položky se složitým plněním nebo fakturací. Kde data získat Získává se z tabulek položek řádků prodejních objednávek a propojuje se s hlavní tabulkou produktů. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady Standardní produkt X1Balíček prémiových služebKomponenta Y2-B | |||
| Obchodní jednotka BusinessUnitName | Název interní obchodní jednotky odpovědné za prodejní objednávku. | ||
| Popis Tento atribut označuje konkrétní divizi nebo provozní jednotku společnosti, která za transakci odpovídá. Umožňuje porovnávat výkonnost různých částí organizace. Členění procesu podle obchodní jednotky pomáhá odhalit rozdíly v efektivitě, nákladech a dodržování pravidel napříč společností. Analýza může ukázat osvědčené postupy ve výkonných jednotkách, které lze sdílet, nebo upozornit na jednotky, kde je potřeba cíleně zlepšit procesy. Proč je to důležité Umožňuje porovnávat výkonnost a konzistentnost procesů mezi různými organizačními jednotkami. Kde data získat Obvykle je k dispozici v hlavičce prodejní objednávky a propojuje se s organizační strukturou definovanou v Oracle Fusion. Příklady BU-Severní AmerikaBU-EMEAGlobální služby | |||
| Platba po splatnosti IsLatePayment | Vypočítaný příznak, který má hodnotu true, pokud byla platba přijata po datu splatnosti. | ||
| Popis Tento booleovský atribut se odvozuje porovnáním skutečného data přijetí platby s PaymentDueDate. Jasně ukazuje, zda byla faktura uhrazena včas. Atribut se používá k výpočtu KPI „Podíl včas uhrazených plateb“. Umožňuje snadno rozdělit platby na včasné a opožděné a analyzovat charakteristiky zákazníků, kteří platí pozdě, běžné příčiny zpoždění i finanční dopad na provozní kapitál. Proč je to důležité Přímo měří efektivitu inkasa plateb a usnadňuje analýzu opožděných plateb. Kde data získat Jde o vypočítané pole. Logika: PaymentReceivedDate > PaymentDueDate. Příklady falsetrue | |||
| Platební podmínky PaymentTerms | Dohodnuté podmínky platby zákazníka. | ||
| Popis Tento atribut určuje podmínky, za kterých má zákazník uhradit fakturu, například „splatnost do 30 dnů“ nebo „splatnost do 60 dnů“. Podle těchto podmínek se vypočítává PaymentDueDate. Členění analýzy podle platebních podmínek pomáhá vysvětlit rozdíly v délce platebního cyklu. Poskytuje kontext pro KPI „Podíl včas uhrazených plateb“, protože různé podmínky přirozeně vedou k odlišnému chování při platbách. Tato zjištění mohou pomoci při nastavování úvěrové politiky a předpovídání peněžního toku. Proč je to důležité Poskytuje důležitý kontext pro analýzu platebního chování a pomáhá vysvětlit rozdíly v době od vystavení faktury do přijetí platby. Kde data získat Je k dispozici u prodejní objednávky nebo zákaznického účtu v Oracle Fusion. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady Splatnost do 30 dnůSplatnost do 60 dnůSplatné při přijetí | |||
| Poslední aktualizace dat LastUpdateDate | Časové razítko označující, kdy byla data této události naposledy obnovena ze zdrojového systému. | ||
| Popis Tento atribut zaznamenává, kdy byla data naposledy extrahována nebo aktualizována v datové sadě pro process mining. Informuje o aktuálnosti analyzovaných dat. Díky těmto informacím uživatelé vědí, jak aktuální je analýza procesu. Mohou lépe počítat s časovým zpožděním dat a nastavit i sledovat plán jejich obnovy. Proč je to důležité Informuje o aktuálnosti dat, takže uživatelé vědí, jak aktuální je jejich analýza procesu. Kde data získat Tato hodnota se vytvoří a zapíše do datové sady při každém cyklu extrakce a transformace dat. Příklady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Typ objednávky OrderType | Klasifikace prodejní objednávky, například „Standardní objednávka“ nebo „Vratka“. | ||
| Popis Typ objednávky slouží ke kategorizaci prodejních objednávek podle jejich obchodního účelu. Mezi běžné typy patří standardní prodej, servisní objednávky, povolení k vrácení zboží (RMA) a interní objednávky. Analýza procesu podle typu objednávky je důležitá, protože různé typy mají často odlišný průběh procesu a výkonnostní cíle. Toto členění pomáhá rozpoznat záměrné a očekávané rozdíly v procesu, aby nebyly mylně považovány za odchylky. Proč je to důležité Umožňuje oddělit různé legitimní průběhy procesu, například standardní objednávky a vratky, a zajistit tak spravedlivou a přesnou analýzu. Kde data získat Obvykle je k dispozici jako pole v tabulce hlaviček prodejních objednávek v Oracle Fusion. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady Standardní prodejní objednávkaPovolení k vrácení zbožíServisní objednávka | |||
| Zdrojový systém SourceSystemIdentifier | Určuje zdrojový systém, ze kterého byla data události získána. | ||
| Popis Tento atribut určuje původ dat. Hodí se zejména v prostředích, kde se na procesu od objednávky k inkasu podílí více systémů. Data o objednávkách mohou například pocházet z Oracle Fusion, zatímco údaje o přepravě z logistického systému třetí strany. Při analýze pomáhá sledovat původ dat a filtrovat zobrazení procesu podle událostí z konkrétních systémů. Je důležitý pro ověřování dat a odhalování roztříštěnosti procesu napříč různými IT systémy. Proč je to důležité Poskytuje informace o původu dat, které jsou důležité pro správu dat a řešení problémů v prostředí s více systémy. Kde data získat Obvykle jde o statickou hodnotu, která se přidává při extrakci a transformaci dat a označuje původ datové sady. Příklady Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Země zákazníka CustomerCountry | Země, ve které se zákazník nachází. | ||
| Popis Tento atribut uvádí zemi z dodací nebo fakturační adresy zákazníka. Slouží jako důležitý rozměr geografické analýzy. Členění procesu podle země může odhalit regionální rozdíly ve výkonnosti procesu, době cyklu nebo chování při platbách. Pomáhá pochopit, jak místní předpisy, logistické problémy a podmínky na trhu ovlivňují proces od objednávky k inkasu. Proč je to důležité Umožňuje geografickou analýzu a pomáhá odhalit regionální rozdíly v efektivitě procesu, dodržování pravidel a chování zákazníků. Kde data získat Získává se z hlavních tabulek zákazníků (HZ_LOCATIONS, HZ_PARTY_SITES) propojených s prodejní objednávkou. Příklady USANěmeckoJaponsko | |||
| Způsob přepravy ShippingMethod | Způsob přepravy nebo dopravce, který doručuje zboží zákazníkovi. | ||
| Popis Tento atribut uvádí dopravce nebo úroveň přepravní služby, například „Pozemní přeprava“, „Expresní letecká přeprava“ nebo „Místní kurýr“. Tyto informace jsou důležité pro dashboard „Dodržování termínů podle způsobu přepravy“. Umožňují porovnávat včasnost dodávek a náklady na přepravu u různých způsobů a dopravců, což pomáhá optimalizovat logistiku a výběr dodavatelů. Proč je to důležité Přímo podporuje analýzu logistiky a umožňuje porovnávat výkonnost různých dopravců a způsobů přepravy. Kde data získat Je k dispozici v tabulkách přepravy a plnění v Oracle Fusion. Podrobnosti najdete v dokumentaci Oracle Fusion Financials. Příklady FedEx GroundUPS Next Day AirDHL International | |||
Aktivity procesu od objednávky k inkasu při zpracování prodejních objednávek
| Aktivita | Popis | ||
|---|---|---|---|
| Objednávka uzavřena | Poslední aktivita v procesu. Znamená, že všechny řádky prodejní objednávky byly splněny, vyfakturovány a uzavřeny. Stav hlavičky objednávky se změní na „Closed“. | ||
| Proč je to důležité Tato aktivita označuje úspěšné dokončení životního cyklu prodejní objednávky. Je nezbytná pro výpočet celkové doby průchodu procesem a odhalení objednávek, které se nikdy neuzavřou. Kde data získat Událost se odvozuje ze změny stavu hlavičky prodejní objednávky na „Closed“ v tabulce DOO_HEADERS_ALL. Časové razítko této poslední změny stavu slouží jako čas události. Zachycení Odvozuje se z časového razítka změny stavu hlavičky prodejní objednávky na „Closed“. Typ události inferred | |||
| Odeslání zboží | Tato aktivita označuje okamžik, kdy zboží opustí sklad a je na cestě k zákazníkovi. Zaznamená se při zpracování transakce potvrzení odeslání v Oracle Shipping. | ||
| Proč je to důležité Jde o důležitý milník, který označuje dokončení části procesu spojené s vyřízením objednávky a spouští fakturaci. Je nezbytný pro měření včasnosti odeslání a doby doručení. Kde data získat Jde o výslovně zaznamenanou událost v Oracle Shipping Execution. Transakce potvrzení odeslání vytvoří záznam v tabulkách dopravy, například WSH_DELIVERY_DETAILS, s datem odeslání. Zachycení Údaj se získá z časového razítka „skutečné datum odeslání“ v záznamu podrobností o dodávce propojeném s řádkem objednávky. Typ události explicit | |||
| Platba přijata | Tato aktivita znamená, že platba zákazníka byla přijata a přiřazena k faktuře v pohledávkách. Zaznamená se zaúčtováním přiřazení přijaté platby. | ||
| Proč je to důležité Jde o důležitý milník pro měření „Celkové doby cyklu od objednávky k inkasu“ a „Podílu včas uhrazených plateb“. Zachycuje přeměnu prodeje na peněžní prostředky. Kde data získat V Oracle Accounts Receivable jde o explicitní událost. Zaznamenává se v tabulkách přijatých plateb, například AR_RECEIVABLE_APPLICATIONS_ALL, když se platba přiřadí k faktuře. Zachycení Zaznamenává se z časového razítka „apply date“ u záznamu o přiřazení přijaté platby v AR. Typ události explicit | |||
| Potvrzení objednávky | Tento důležitý milník znamená, že prodejní objednávka prošla všemi úvodními kontrolami včetně schválení úvěru a je připravena k vyřízení. Obvykle se odvozuje z přechodu stavu objednávky do stavu, jako je „Čeká na odeslání“ nebo „Naplánováno“. | ||
| Proč je to důležité Tato aktivita je důležitým milníkem pro výpočet KPI „Průměrná doba potvrzení objednávky“ a označuje předání objednávky od zadání k vyřízení. Kde data získat Událost se odvozuje ze změny stavu hlavičky nebo řádku prodejní objednávky na hodnotu označující připravenost k vyřízení, například „Čeká na odeslání“. Zkontrolujte sloupce stavu v tabulkách DOO_HEADERS_ALL nebo DOO_FULFILL_LINES_ALL. Zachycení Údaj se odvozuje z časového razítka změny stavu objednávky na potvrzený nebo naplánovaný. Typ události inferred | |||
| Vytvoření faktury | Tato aktivita představuje vytvoření zákaznické faktury v modulu Accounts Receivable, které obvykle spouští potvrzení odeslání. Vznikne záznam faktury s jedinečným číslem a datem vytvoření. | ||
| Proč je to důležité Označuje oficiální začátek cyklu inkasa plateb. Slouží jako základ pro měření KPI „Doba od faktury po platbu“ a celkové efektivity peněžního toku. Kde data získat Jde o výslovně zaznamenanou událost v Oracle Accounts Receivable (AR). Záznam faktury s datem transakce se vytvoří v tabulce RA_CUSTOMER_TRX_ALL. Zachycení Údaj se získá z data vytvoření fakturační transakce v modulu AR. Typ události explicit | |||
| Vytvoření prodejní objednávky | Tato aktivita označuje začátek procesu prodejní objednávky, tedy okamžik, kdy se v Oracle Fusion zadá nová objednávka. Událost se obvykle zaznamená ve chvíli, kdy uživatel uloží nový záznam objednávky v modulu Order Management. | ||
| Proč je to důležité Jako začátek procesu je tato aktivita nezbytná pro měření celkové doby cyklu Order to Cash a analýzu počtu přijatých objednávek. Kde data získat Událost se zaznamená při vytvoření záznamu prodejní objednávky v Order Management Cloud. Čas vytvoření hledejte v tabulce DOO_HEADERS_ALL. Zachycení Údaj se získá z časového razítka vytvoření hlavičky prodejní objednávky. Typ události explicit | |||
| Doručení zboží | Označuje, že zákazník zásilku převzal. Údaj často poskytuje externí dopravce a následně se aktualizuje v Oracle Fusion. Lze jej také odvodit ze standardní doby přepravy počítané od data odeslání. | ||
| Proč je to důležité Tato aktivita je důležitá pro přesný výpočet KPI „Podíl včas doručených objednávek“ a měření úrovně zákaznického servisu. Kde data získat Tato událost obvykle není v Oracle nativně dostupná. Lze ji zaznamenat, pokud je systém propojen s dopravcem, nebo vypočítat přičtením standardní doby přepravy k datu „Odeslání zboží“. Je nutné analyzovat systém. Zachycení Událost se odvozuje z datových přenosů od dopravce nebo se vypočítá jako datum odeslání plus průměrná doba přepravy. Typ události inferred | |||
| Objednávka zrušena | Označuje zrušení prodejní objednávky před úplným odesláním zboží. Může k němu dojít z různých důvodů a výsledným stavem je „Cancelled“. | ||
| Proč je to důležité Jde o důležitou výjimečnou větev procesu. Analýza zrušených objednávek pomáhá odhalit příčiny, například vyprodané zásoby, problémy s cenami nebo změnu rozhodnutí zákazníka, a využít tato zjištění ke zlepšení procesů. Kde data získat Událost se odvozuje ze změny stavu hlavičky nebo řádku prodejní objednávky na „Cancelled“. Časové razítko této změny se použije jako čas události. Zachycení Odvozuje se z časového razítka změny stavu hlavičky nebo řádku objednávky na „Cancelled“. Typ události inferred | |||
| Oprava faktury | Dochází k němu, když se již vystavená faktura upraví, znovu vystaví nebo dobropisuje kvůli chybám či sporu se zákazníkem. Obvykle se zaznamená vytvořením dobropisu nebo nové verze faktury. | ||
| Proč je to důležité Sledování oprav faktur je důležité pro KPI „Míra přepracování faktur“. Ukazuje problémy ve fakturaci, které mohou zpozdit platby a zvýšit administrativní náklady. Kde data získat Událost se odvozuje od vytvoření dobropisu navázaného na původní fakturu nebo následné verze téže faktury v tabulce RA_CUSTOMER_TRX_ALL. Zachycení Odvozuje se podle dobropisů nebo faktur, které odkazují na předchozí fakturační transakci. Typ události inferred | |||
| Provedení úvěrové kontroly | Tato aktivita představuje kontrolu úvěruschopnosti zákazníka. V rámci workflow zpracování objednávky může jít o automatický nebo ruční krok. Její dokončení se obvykle zaznamená změnou stavu nebo jako dokončená úloha. | ||
| Proč je to důležité Analýza doby úvěrové kontroly pomáhá odhalit úzká místa při schvalování objednávek. Je důležitá pro KPI „Doba od úvěrové kontroly po potvrzení“. Kde data získat Událost lze odvodit ze změn stavu prodejní objednávky, například z přechodu do stavu „Čeká na schválení úvěru“, nebo z výslovného záznamu události ve funkci správy úvěrů. Zachycení Událost se odvozuje ze změn stavu objednávky nebo z časových razítek úloh spojených s úvěrovou kontrolou. Typ události inferred | |||
| Řádek objednávky uzavřen | Označuje konečné uzavření jednotlivého řádku prodejní objednávky. Řádek byl kompletně dodán a vyfakturován a neočekávají se u něj další transakce. Systém změní jeho stav na „Closed“. | ||
| Proč je to důležité Uzavřením řádků objednávky jsou splněny všechny smluvní závazky týkající se dané položky. Analýza pomáhá odhalit objednávky, které zůstávají otevřené dlouho po dodání a zaplacení. Kde data získat Událost se odvozuje ze změny stavu řádku plnění na „Closed“ v tabulce DOO_FULFILL_LINES_ALL. Časové razítko změny stavu označuje čas události. Zachycení Odvozuje se z časového razítka změny stavu řádku plnění na „Closed“. Typ události inferred | |||
| Rezervace zásob | Tato aktivita představuje přidělení nebo rezervaci fyzických zásob pro vyřízení řádku prodejní objednávky. Systém vyhradí konkrétní skladové položky, aby byly k dispozici, až bude objednávka připravena k vychystání. | ||
| Proč je to důležité Sledování této aktivity pomáhá analyzovat KPI „Doba přidělení zásob“ a odhalit prodlevy mezi potvrzením objednávky a zajištěním zboží. Kde data získat Událost se často zaznamenává v modulech pro správu zásob nebo provádění dodavatelského řetězce. Lze ji odvodit ze změn stavu řádku objednávky, které ukazují, že zásoby byly podrobně určeny nebo rezervovány. Zachycení Událost se odvozuje ze změn stavu řádku objednávky souvisejících s rezervací zásob nebo plánováním. Typ události inferred | |||
| Vychystání zboží | Tato aktivita představuje fyzické vychystání zboží ze skladu pro vyřízení objednávky. Jde o důležitý krok logistiky, který se obvykle zaznamenává v modulu pro správu skladu nebo dopravy. | ||
| Proč je to důležité Tato aktivita poskytuje přehled o provozu skladu. Prodlevy mezi rezervací zásob a vychystáním mohou ukazovat na nedostatek zdrojů nebo úzká místa ve skladovém procesu. Kde data získat Událost se zaznamenává v modulech Oracle Fusion Cloud SCM (Supply Chain Management). Lze ji odvodit ze změny stavu vychystávací vlny nebo výdejky spojené s řádkem prodejní objednávky. Zachycení Událost se odvozuje z časového razítka dokončení transakce vychystání v modulech SCM. Typ události inferred | |||
| Zablokování objednávky kvůli úvěrové kontrole | K této aktivitě dochází, když je prodejní objednávka automaticky nebo ručně zablokována kvůli neúspěšné úvěrové kontrole nebo jinému problému souvisejícímu s úvěrem. Systém ji obvykle zaznamená změnou stavu blokace objednávky. | ||
| Proč je to důležité Sledování úvěrových blokací je důležité pro zjištění příčin prodlev při zpracování objednávek a měření efektivity jejich uvolňování. Kde data získat Událost se odvozuje od zablokování prodejní objednávky. Obvykle se zaznamenává v tabulkách souvisejících s blokacemi, například DOO_HOLDS_ALL, které jsou propojené s prodejní objednávkou. Zachycení Událost se odvozuje od vytvoření záznamu v tabulce blokací objednávek s typem blokace „Úvěr“. Typ události inferred | |||
Návody k extrakci dat
Kroky
- Otevřete Oracle BI Publisher: Přihlaste se do prostředí Oracle Fusion jako uživatel s oprávněním BI Administrator nebo BI Author. V nabídce Navigator přejděte na Tools > Reports and Analytics. Kliknutím na tlačítko „Browse Catalog“ otevřete katalog Business Intelligence.
- Vytvořte nový datový model: V katalogu BI přejděte do vhodné složky, například Shared Folders > Custom. Klikněte na rozbalovací nabídku „New“ a vyberte „Data Model“.
- Nastavte datovou sadu s SQL dotazem: V editoru datového modelu klikněte na ikonu „+“, vytvořte novou datovou sadu a vyberte „SQL Query“. Otevře se dialogové okno. Zadejte název datové sady, například „OrderToCash_EventLog“, jako zdroj dat vyberte „Oracle BI EE“ a jako typ SQL zvolte „Standard SQL“.
- Zadejte SQL dotaz: Zkopírujte celý SQL dotaz z části „query“ tohoto dokumentu a vložte ho do textového pole SQL Query. Dotaz obsahuje parametry počátečního a koncového data (:p_start_date a :p_end_date), které BI Publisher rozpozná automaticky.
- Nastavte vlastnosti datového modelu: Po vložení dotazu klikněte na „OK“. V levém panelu editoru datového modelu přejděte do části „Properties“. Zkontrolujte, že je zaškrtnutá možnost „Include Parameter Tags“. Podle potřeby můžete nastavit výchozí hodnoty parametrů data.
- Zobrazte a uložte datový model: Klikněte na kartu „Data“. Může se zobrazit výzva k zadání hodnot parametrů data. Pro test zadejte krátké období. Kliknutím na „View“ zobrazíte vzorek dat. Pokud se data zobrazují správně, uložte datový model kliknutím na ikonu uložení a zadejte výstižný název, například „OrderToCash_EventLog_DM“.
- Vytvořte sestavu z datového modelu: Po uložení datového modelu klikněte v pravém horním rohu na tlačítko „Create Report“. Otevře se průvodce vytvořením sestavy.
- Nastavte sestavu: V průvodci vyberte možnost „Use Data Model“. Průvodce vás provede nastavením rozvržení. Pro jednoduchý export do CSV můžete zvolit rozvržení „Table“. Přetáhněte do tabulky všechny sloupce. Klikněte na „Next“ a zrušte zaškrtnutí možnosti „Show Grand Totals Row“. Kliknutím na „Finish“ sestavu uložte. Pojmenujte ji například „OrderToCash_EventLog_Report“.
- Spusťte sestavu: Otevřete nově vytvořenou sestavu. Zobrazí se výzva k zadání počátečního a koncového data extrakce. Zadejte požadované období.
- Exportujte data: Po spuštění sestavy klikněte na rozbalovací nabídku „View“ a vyberte jinou možnost zobrazení, například „View Report“. Poté najděte odkaz nebo ikonu „Export“ a jako formát exportu zvolte „CSV“. Tím stáhnete soubor se záznamem událostí.
- Připravte data k nahrání: Otevřete stažený soubor CSV. Ověřte, že názvy sloupců odpovídají požadovaným atributům: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate a IsAutomated. Soubor je nyní připravený k nahrání do nástroje process mining.
Konfigurace
- Uživatelská oprávnění: Musíte mít roli s oprávněním vytvářet datové modely a sestavy v BI Publisher, například „BI Administrator“ nebo „BI Author“.
- Zdroj dat: Dotaz je určen pro standardní aplikační zdroj dat „Oracle BI EE“, který se připojuje k transakční databázi (Fusion Apps). Obvykle není potřeba žádná zvláštní konfigurace.
- Parametry časového období: Dotaz používá dva parametry, :p_start_date a :p_end_date, které filtrují data. Doporučujeme extrahovat data v přiměřeně velkých dávkách, například po 3 až 6 měsících, aby nedošlo k překročení časového limitu sestavy nebo problémům s výkonem.
- Filtrování podle obchodní jednotky: Rozsah extrakce můžete omezit přidáním klauzule WHERE do CTE BaseOrders v dotazu. Ta umožní filtrovat podle konkrétního ID obchodní jednotky, například AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtrování podle typu objednávky: V CTE BaseOrders můžete také filtrovat konkrétní typy prodejních objednávek přidáním podmínky pro dhead.SOURCE_ORDER_TYPE_CODE.
- Výkon: U velmi rozsáhlých datových sad pokrývajících několik let může být tento postup s jediným dotazem pomalý. Zvažte spuštění mimo špičku nebo rozdělení extrakce do menších měsíčních dávek. V datovém modelu nesmí být vybraná vlastnost „Enable SQL Pruning“, protože může narušit složité dotazy UNION.
Ukázkový dotaz 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' Kroky
- Otevřete konzoli BICC: Přihlaste se k instanci Oracle Fusion Applications jako uživatel s rolí BICC_ADMINISTRATOR. Přejděte do nabídky Tools a vyberte Business Intelligence Cloud Connector.
- Nastavte nové úložiště: V konzoli BICC klikněte na „Configure External Storage“ a nastavte cílové úložiště. Může jít o Oracle Universal Content Management (UCM) nebo úložiště objektů OCI. Zkontrolujte správnost údajů pro připojení a přihlašovacích údajů.
- Vytvořte úlohu extrakce: Přejděte do části „Manage Extract Jobs“. Kliknutím na ikonu „+“ vytvořte novou úlohu a zadejte výstižný název, například ProcessMind_O2C_SalesOrder_Extract.
- Vyberte úložiště dat (PVO): V nastavení úlohy vyhledejte a přidejte Public View Objects (PVO) potřebné k zachycení životního cyklu prodejní objednávky. Je třeba přidat několik PVO, včetně FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice a FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Nastavte sloupce pro jednotlivá PVO: U každého vybraného PVO klikněte na nabídku „Actions“ a zvolte „Select Columns“. Pečlivě vyberte sloupce potřebné k vytvoření záznamu událostí, například HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate a identifikátory uživatelů. Podrobný seznam požadovaných sloupců pro jednotlivá PVO najdete v manifestu dotazu.
- Nastavte filtry pro přírůstkové načítání: Chcete-li řídit objem dat, nastavte pro každé PVO filtr podle sloupce LastUpdateDate. Při prvním spuštění můžete zvolit širší časové období. U dalších plánovaných spuštění nastavte filtr tak, aby extrahoval pouze záznamy změněné od posledního spuštění úlohy.
- Naplánujte extrakci: Přejděte do části „Manage Schedule“ a vytvořte pro úlohu nový plán. Doporučujeme spouštět úlohu mimo špičku, například každý den v noci, aby se co nejméně zatížil systém.
- Odešlete úlohu a sledujte její průběh: Po dokončení nastavení úlohu odešlete. Její průběh můžete sledovat na obrazovce „Manage Extract Jobs“. Po úspěšném dokončení budou datové soubory dostupné v nastaveném cloudovém úložišti ve formátu komprimovaného CSV.
- Převeďte nezpracovaná data na záznam událostí: Stáhněte extrahované soubory CSV. BICC poskytuje nezpracovaná data tabulek, nikoli zformátovaný záznam událostí. K jejich zpracování musíte použít externí nástroj, například Python, databázový skript nebo platformu ETL. Postup zahrnuje:
- Spojení dat z různých souborů, například propojení údajů o fakturách s hlavičkou prodejní objednávky.
- Převod sloupců s daty na samostatné řádky aktivit. Například ze souboru FscmTopModelAM.DooTopAM.Header vytvořte jeden řádek pro aktivitu Sales Order Created s datem CreationDate a další pro aktivitu Order Closed s datem ClosedDate.
- Namapování stavových kódů nebo příznaků na konkrétní aktivity, například Order Confirmed nebo Order Cancelled.
- Sloučení všech převedených dat do jednoho souboru s požadovanými sloupci: SalesOrder, ActivityName a EventTime.
- Připravte soubor k nahrání: Výsledný soubor musí být jeden soubor CSV se sloupci odpovídajícími požadovaným a doporučeným atributům. Nyní ho můžete nahrát do ProcessMind.
Konfigurace
- Výběr PVO: Přesnost záznamu událostí závisí na výběru správných PVO. Mezi důležitá PVO patří FscmTopModelAM.DooTopAM.Header (vytvoření a uzavření objednávky), FscmTopModelAM.ScmTopAM.ShipmentLine (události expedice) a FscmTopModelAM.ArTopAM.ReceivableInvoice (fakturace).
- Přírůstková extrakce: Při opakované extrakci vždy použijte filtr LastUpdateDate. Je důležitý pro výkon a zabrání opakované extrakci stejné datové sady o velikosti několika gigabajtů. Prvním úplným načtením vytvoříte výchozí stav, další spuštění pak zachytí pouze změny.
- Časové období: Při prvním načtení historických dat vyberte reprezentativní období, například posledních 3 až 6 měsíců. Získáte tak dostatek dat, aniž by jejich objem byl příliš velký. Další spuštění budou přírůstková.
- Nastavení úložiště: BICC může exportovat data do Oracle UCM nebo OCI Object Storage. Pro hromadné zpracování dat a snadnější napojení na navazující nástroje ETL se obvykle doporučuje OCI Object Storage.
- Plánování úloh: Plánujte extrakci mimo pracovní dobu, abyste předešli možnému snížení výkonu transakčního systému Oracle Fusion Financials.
- Předpoklady: Uživatelé, kteří úlohu nastavují, potřebují roli BICC_ADMINISTRATOR. Musíte mít předem nastavené přihlašovací údaje ke cloudovému úložišti a vědět, jaká transformace dat bude po extrakci potřeba.
Ukázkový dotaz 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 Chcete začít?
Pomocí této šablony si usnadníte sběr dat a můžete začít s process mining. Začněte optimalizovat zpracování prodejních objednávek v procesu od objednávky k inkasu.
Optimalizujte zpracování prodejních objednávek v procesu od objednávky k inkasu
Snadno odhalte úzká místa a zkraťte dobu procesu od objednávky k inkasu o 30 %.
Zkušební verze na 14 dní, bez nutnosti zadávat platební kartu.