> Průběžné zlepšování procesů > Od požadavku na nákup k platbě > Oracle Fusion Financials > Datová šablona

Šablona dat pro proces nákupu od požadavku po platbu

Oracle Fusion Financials

Atributy procesu nákupu od požadavku po platbu(22) Aktivity procesu nákupu od požadavku po platbu(12) Návody k extrakci dat(4)

Šablona dat pro proces nákupu od požadavku po platbu

Tato šablona vám pomůže shromáždit potřebná data pro analýzu procesu nákupu od požadavku po platbu. Uvádí důležité atributy, které je třeba získat, aktivity, které je vhodné sledovat, a praktický postup pro extrakci dat z Oracle Fusion Financials. Díky tomu připravíte záznam událostí pro smysluplný process mining.

Doporučené atributy ke shromáždění
Aktivity, které je vhodné sledovat
Postup extrakce dat z Oracle Fusion Financials

Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Stáhnout šablonu

Atributy procesu nákupu od požadavku po platbu

Toto jsou doporučená datová pole pro záznam událostí, který použijete k analýze procesu nákupu od požadavku po platbu.

5 Povinné 7 Doporučené 10 Volitelné

	Název	Popis
	Aktivita ActivityName	Název obchodní události, ke které došlo v určité fázi procesu nákupního požadavku.
Popis Činnost označuje konkrétní krok nebo milník v životním cyklu nákupního požadavku. Příkladem je „Vytvoření požadavku“, „Schválení kroku“ nebo „Vytvoření nákupní objednávky“. Činnosti se odvozují ze změn stavu, akcí uživatelů nebo systémových událostí zaznamenaných v auditních protokolech či transakčních tabulkách zdrojového systému. Tento atribut je nezbytný pro sestavení mapy procesu, která znázorňuje průběh požadavků. Analýza pořadí a četnosti činností pomáhá odhalit obvyklé cesty procesem, úzká místa, opakované zpracování a odchylky od standardního postupu. Proč je to důležité Tvoří základ mapy procesu a umožňuje zobrazit a analyzovat workflow nákupního požadavku. Kde data získat Odvozuje se ze záznamů o změnách stavu v tabulkách, jako je POR_REQUISITION_HEADERS_ALL, z historie transakcí nebo z auditních záznamů workflow, například FA_FUSION_SOAINFRA.WFTASK. Příklady Nákupní požadavek vytvořenSchvalovací krok schválenNákupní požadavek zamítnutNákupní objednávka vytvořena
	Čas události EventTime	Časové razítko určující, kdy k činnosti došlo.
Popis Čas události zaznamenává přesné datum a čas, kdy proběhla konkrétní činnost. Toto časové razítko je nezbytné pro chronologické seřazení událostí v rámci případu. Získává se z údajů o vytvoření, poslední aktualizaci nebo z časových razítek konkrétních akcí v systému. Při analýze se čas události používá k výpočtu všech časových ukazatelů, například doby mezi činnostmi, čekání a celkové doby trvání případu. Pomáhá odhalovat úzká místa, měřit výkonnost vůči SLA a porozumět časovému průběhu procesu nákupního požadavku. Proč je to důležité Tento atribut je nezbytný pro výpočet časových KPI, správné seřazení událostí a analýzu výkonnosti procesu i úzkých míst. Kde data získat Obvykle se přebírá ze sloupce LAST_UPDATE_DATE nebo CREATION_DATE, který souvisí s transakcí či změnou stavu. Tyto sloupce se často nacházejí v tabulkách, jako je POR_REQUISITION_HEADERS_ALL, nebo v tabulkách s historií workflow. Příklady 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID nákupního požadavku PurchaseRequisitionId	Jedinečný identifikátor nákupního požadavku, který slouží jako ID případu v procesu.
Popis ID nákupního požadavku je hlavní identifikátor, který propojuje všechny činnosti související s konkrétní žádostí o zboží nebo služby. Každý požadavek dostane při vytvoření jedinečné ID, které se po celou dobu jeho životního cyklu nemění. V process mining se tento atribut používá ke spojení všech souvisejících událostí, například vytvoření, odeslání, jednotlivých kroků schvalování a konečného uzavření, do jednoho případu. Díky tomu lze analyzovat celý průběh požadavku, zobrazit mapu procesu, vypočítat dobu průchodu a porovnat varianty jednotlivých požadavků. Proč je to důležité Tento základní atribut umožňuje sledovat životní cyklus požadavku od začátku do konce a provádět analýzy na úrovni případů i výpočty KPI. Kde data získat Obvykle jde o primární klíč v tabulce hlaviček požadavků, například POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID v Oracle Fusion Financials. Příklady 100234810023491002350
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat ze zdrojového systému.
Popis Tento atribut uvádí datum a čas poslední extrakce dat z Oracle Fusion Financials. Vztahuje se k celé datové sadě, nikoli k jednotlivým událostem. Analytici podle něj zjišťují, jak aktuální jsou data, a ověřují, kdy byly zahrnuty nejnovější transakce. Jde o důležitá metadata pro reporting v dashboardu a kontrolu, zda analýzy vycházejí z aktuálních informací. Proč je to důležité Informuje uživatele o aktuálnosti dat, aby analýzy vycházely z nejnovějších dostupných informací. Kde data získat Toto časové razítko se vytváří a ukládá při extrakci dat, obvykle pomocí nástroje ETL nebo datového pipeline. Příklady 2023-10-27T02:00:00Z
	Zdrojový systém SourceSystem	Informační systém, ze kterého byla data získána.
Popis Tento atribut určuje původ procesních dat. V tomto datovém modelu bude jeho hodnota vždy „Oracle Fusion Financials“. V prostředích s více ERP systémy nebo integrovanými systémy je toto pole důležité pro sledování původu dat, řešení problémů a kontrolu jejich kvality. Udává, z jakého zdroje pocházejí analyzované procesní události. Proč je to důležité Poskytuje důležitý kontext o původu dat, který je nezbytný pro správu dat a jejich integraci z více systémů. Kde data získat 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 Financials
	Celková částka požadavku RequisitionTotalAmount	Celková peněžní hodnota nákupního požadavku.
Popis Tento atribut představuje součet hodnot všech položek jednoho nákupního požadavku. Pomáhá určit finanční význam každé žádosti. V process mining se celková částka používá v řadě analýz. Lze podle ní například filtrovat požadavky s vysokou hodnotou, které často podléhají jinému schvalování nebo důkladnější kontrole. Dashboardy mohou ukázat, jak hodnota požadavku souvisí s ukazateli procesu, například dobou průchodu nebo mírou zamítnutí. Proč je to důležité Poskytuje finanční kontext pro analýzu podle hodnoty, pomáhá určit priority při zlepšování procesů a ukazuje, jak hodnota požadavku ovlivňuje průběh procesu. Kde data získat Nachází se v hlavičce požadavku, často v poli REQUISITION_TOTAL v POR_REQUISITION_HEADERS_ALL. Lze ji také vypočítat jako součet částek položek z POR_REQUISITION_LINES_ALL. Příklady 550.0012500.7599.99
	Důvod zamítnutí RejectionReason	Důvod, který schvalovatel uvedl při zamítnutí požadavku nebo kroku schvalování.
Popis Při zamítnutí požadavku schvalovatel obvykle uvede důvod, buď výběrem z předem připraveného seznamu, nebo volným textem. Tento atribut zachycuje vysvětlení zamítnutí. Je důležitý pro analýzu příčin problémů v procesu. Podporuje dashboard „Trendy změn a zamítnutí“ a ukazuje, proč jsou požadavky zamítány. Analýza důvodů pomáhá odhalit opakující se problémy, například nesprávné účtování, překročení rozpočtu nebo porušení pravidel. Tyto problémy pak lze řešit školením nebo systémovými kontrolami. Proč je to důležité Ukazuje, proč jsou požadavky zamítány, a umožňuje cíleně omezit opakované zpracování a zvýšit podíl požadavků zpracovaných bez zásahu. Kde data získat Získává se z komentářů ve workflow nebo z polí s kódem důvodu zamítnutí v auditních záznamech workflow. Může být uložen v tabulkách souvisejících s FA_FUSION_SOAINFRA.WFTASK nebo v přidruženém úložišti komentářů. Příklady Nesprávný účet hlavní knihyPřekročen rozpočet nákladového střediskaVybrán nepreferovaný dodavatelDuplicitní požadavek
	Jméno žadatele RequesterName	Jméno zaměstnance, který vytvořil a odeslal nákupní požadavek.
Popis Tento atribut určuje osobu, která zahájila žádost o zboží nebo služby. Údaj se obvykle zaznamenává na začátku procesu při vytvoření požadavku. Analýza výkonnosti procesu podle žadatele je důležitá pro dashboard „Ukazatele výkonnosti žadatelů“. Pomáhá určit, kteří uživatelé nebo skupiny mohou potřebovat další školení. Upozorní například na časté změny, zamítnutí nebo dlouhou dobu zpracování jejich požadavků. Nabízí pohled na proces z hlediska zapojených lidí. Proč je to důležité Umožňuje analyzovat výkonnost podle žadatele, určit potřeby školení a najít uživatele či oddělení, která pracují efektivně. Kde data získat Získává se z údajů v hlavičce požadavku, často propojením ID žadatele s tabulkou zaměstnanců nebo uživatelů. Hledejte pole související s PREPARER_ID v POR_REQUISITION_HEADERS_ALL a propojte je s PER_ALL_PEOPLE_F. Příklady Jan NovákJana NovákováEva Dvořáková
	Obchodní jednotka BusinessUnit	Konkrétní obchodní jednotka organizace, ke které požadavek patří.
Popis Obchodní jednotka představuje samostatnou právní nebo funkční část společnosti, pro kterou se požadavek podává. V organizační struktuře stojí výše než oddělení. Analýza podle obchodní jednotky umožňuje porovnávat výkonnost různých částí organizace na vyšší úrovni. Vedení tak může zjistit, zda se neefektivita týká jen některých oblastí, nebo celé organizace, a určit, kam zaměřit zlepšování. Jde o důležitý filtr pro většinu dashboardů a KPI. Proč je to důležité Poskytuje přehled o organizačním kontextu a umožňuje porovnávat výkonnost i strategicky analyzovat různé části organizace. Kde data získat Jde o základní organizační pole v Oracle Fusion. Obvykle je dostupné v hlavičce požadavku v tabulkách, jako je POR_REQUISITION_HEADERS_ALL. Příklady Obchodní jednotka Severní AmerikaObchodní jednotka EvropaÚstředí společnosti
	Oddělení DepartmentName	Obchodní oddělení, do kterého žadatel patří.
Popis Tento atribut označuje organizační jednotku osoby, která vytvořila požadavek, například „Finance“, „IT“ nebo „Marketing“. Obvykle se odvozuje z profilu žadatele v HR systému. Analýza podle oddělení je běžný způsob členění procesních dat. Pomáhá odhalit rozdíly mezi odděleními, například vyšší míru zamítnutí nebo delší dobu průchodu. Na základě těchto zjištění lze cíleně zlepšovat procesy. Jde o důležitý rozměr dashboardu „Ukazatele výkonnosti žadatelů“. Proč je to důležité Umožňuje analyzovat proces podle obchodní jednotky a odhalit rozdíly ve vzorcích, výkonnosti a dodržování pravidel mezi odděleními. Kde data získat Obvykle se odvozuje z profilu žadatele. Často je potřeba propojit tabulku požadavků s tabulkou HR nebo adresářem uživatelů, který obsahuje údaje o oddělení. Příklady Informační technologieFinanceProvozMarketing
	Požadované datum dodání RequiredByDate	Datum, do kterého žadatel potřebuje zboží nebo služby.
Popis Toto datum určuje žadatel jako termín, do kterého potřebuje obdržet požadované položky. V nákupním procesu slouží jako interní cíl SLA. Tento atribut je základem dashboardu „Plnění požadovaného data dodání“ a KPI „Míra dodržení požadovaného data“. Porovnáním tohoto data se skutečným datem vytvoření nákupní objednávky nebo přijetí zboží lze zjistit, jak dobře nákupní proces plní požadavky interních zákazníků a kde dochází k systémovým zpožděním. Proč je to důležité Je důležitý pro měření výkonnosti procesu vůči interním termínům a pro zjištění, zda nákupní proces včas plní potřeby firmy. Kde data získat Obvykle se ukládá na úrovni položky požadavku v tabulkách, jako je POR_REQUISITION_LINES_ALL, například v poli NEED_BY_DATE. Příklady 2023-11-012023-12-152024-01-31
	Stav požadavku RequisitionStatus	Aktuální nebo konečný stav nákupního požadavku.
Popis Tento atribut uvádí celkový stav požadavku v určitém okamžiku nebo jeho konečný výsledek, například „Schváleno“, „Zamítnuto“, „Probíhá“ nebo „Uzavřeno“. Často se z něj odvozují mnohé činnosti v záznamu událostí. Tento atribut je základem dashboardu „Přehled stavů požadavků“, který poskytuje přehled o aktuálním objemu práce a nevyřízených požadavcích. Používá se také k výpočtu KPI podle výsledku, například míry zamítnutí požadavků, a to filtrováním případů, které končí určitým stavem. Proč je to důležité Poskytuje přehled o aktuálním stavu požadavků a slouží k určení konečných výsledků pro výpočet KPI. Kde data získat Nachází se v tabulce hlaviček požadavků, obvykle v poli DOCUMENT_STATUS nebo APPROVAL_STATUS v POR_REQUISITION_HEADERS_ALL. Příklady SCHVÁLENOPROBÍHÁZAMÍTNUTOSTAŽENO
	Byl automatizován IsAutomated	Příznak určující, zda činnost provedl systém automaticky.
Popis Tento atribut označuje události, které provedl systémový uživatel nebo automatizovaný agent, nikoli člověk. Může jít například o systémové změny stavu nebo automatické schválení položek s nízkou hodnotou. Analýza tohoto atributu pomáhá měřit míru automatizace procesu. Lze porovnat rychlost a efektivitu automatických a ručních kroků a určit, které další činnosti by bylo možné automatizovat. Proč je to důležité Pomáhá měřit míru automatizace procesu a hledat příležitosti k automatizaci ručních úkolů. Kde data získat Určuje se podle toho, zda je uživatel přiřazený k činnosti systémový nebo servisní účet. K tomu je potřeba seznam známých ID systémových uživatelů. Příklady truefalse
	Byl změněn IsAmendedFlag	Logická hodnota, která je pravdivá, pokud byl požadavek alespoň jednou změněn.
Popis Tento vypočítaný atribut uvádí, zda byl požadavek po prvním odeslání změněn. Určuje se podle toho, zda historie případu obsahuje činnost „Změna požadavku“. Tento příznak zjednodušuje analýzu i výpočet KPI. Používá se přímo k výpočtu KPI „Míra změn požadavků“ a k vyhledání případů, které nebyly zpracovány bez zásahu. Umožňuje snadno filtrovat a porovnávat ukazatele změněných a nezměněných požadavků. Proč je to důležité Zjednodušuje výpočet míry změn a umožňuje snadno porovnat změněné a nezměněné požadavky. Kde data získat Tento atribut není ve zdrojovém systému. Vypočítává se při transformaci dat podle toho, zda záznam událostí obsahuje činnosti související se změnou požadavku. Příklady truefalse
	Byl zpracován bez zásahu IsStraightThrough	Příznak určující, zda byl požadavek schválen bez změn nebo zamítnutí.
Popis Tento vypočítaný příznak označuje požadavky, které prošly procesem od odeslání po schválení bez opakovaného zpracování, například změn nebo zamítnutí. Znamená, že daný případ proběhl bez odchylek. Tento atribut je základem KPI „Podíl požadavků zpracovaných bez zásahu“. Analýza jejich společných znaků, například oddělení, žadatelů nebo typů požadavků, může odhalit osvědčené postupy a příležitosti k automatizaci. Analýza ostatních požadavků naopak pomáhá určit hlavní příčiny neefektivity. Proč je to důležité Přímo měří efektivitu procesu a slouží jako základ KPI „Podíl požadavků zpracovaných bez zásahu“. Pomáhá také určit příčiny opakovaného zpracování. Kde data získat Tento atribut se vypočítává při transformaci dat. Případ dostane hodnotu true, pokud neobsahuje činnosti „Změna požadavku“ ani „Zamítnutí kroku schvalování“. Příklady truefalse
	Číslo nákupní objednávky PurchaseOrderNumber	Identifikátor nákupní objednávky vytvořené na základě schváleného požadavku.
Popis Tento atribut propojuje nákupní požadavek s navazující nákupní objednávkou. Po úplném schválení se požadavek obvykle převede na jednu nebo více objednávek, které se odešlou dodavateli. Při analýze toto ID umožňuje sledovat navazující kroky po podání požadavku. Slouží k výpočtu KPI „Doba od požadavku po nákupní objednávku“ a podporuje dashboard „Doba průchodu od požadavku po nákupní objednávku“. Umožňuje také spojit data o procesu požadavku s navazujícími procesy nákupní objednávky a fakturace a analyzovat celý proces od nákupu po platbu. Proč je to důležité Propojuje požadavek s navazující nákupní objednávkou, takže lze měřit dobu od požadavku po objednávku a analyzovat celý proces. Kde data získat Tento údaj se ukládá po vytvoření nákupní objednávky. Obvykle se získává z odkazů na původní požadavek v distribučních tabulkách objednávek, například PO_DISTRIBUTIONS_ALL, která odkazuje na položku požadavku. Příklady PO-2023-5832PO-2023-5833PO-2023-5834
	Jméno uživatele UserName	Jméno uživatele, který provedl konkrétní činnost, například schvalovatele nebo editora.
Popis Zatímco jméno žadatele označuje osobu, která požadavek zahájila, jméno uživatele určuje osobu, která provedla konkrétní událost, například schválení nebo zamítnutí. To je důležité zejména u vícestupňových schvalovacích workflow, do kterých se zapojuje více lidí. Tento atribut je důležitý pro analýzu úzkých míst při schvalování a měření výkonnosti jednotlivých schvalovatelů či týmů. Podporuje dashboard „Úzká místa ve schvalovacím workflow“, protože umožňuje analyzovat dobu zpracování u každého uživatele ve schvalovacím řetězci. Proč je to důležité Určuje, kdo provedl jednotlivé události. To je důležité při analýze předávání práce, výkonnosti schvalovatelů a rozdělení zdrojů. Kde data získat Získává se z historie workflow nebo z auditních tabulek, například FA_FUSION_SOAINFRA.WFTASK, která zaznamenává uživatele spojeného s dokončením každého úkolu. Příklady David LeeSusan ChenMichael Brown
	Měna CurrencyCode	Kód měny částky požadavku, například USD nebo EUR.
Popis Tento atribut určuje měnu, ve které je uvedena celková částka požadavku. V mezinárodních organizacích mohou být požadavky zadávány v různých měnách. Pro správnou interpretaci a agregaci finančních dat je tento údaj nezbytný. Při každé analýze peněžních hodnot je nutné zohlednit kód měny, aby bylo možné částky správně porovnat. Můžete filtrovat jednu měnu nebo všechny částky převést na společnou měnu. Proč je to důležité Zajišťuje přesnou finanční analýzu a reporting, zejména v mezinárodních organizacích, které pracují s více měnami. Kde data získat Obvykle se nachází v tabulce hlaviček požadavků vedle polí s částkami, například v POR_REQUISITION_HEADERS_ALL. Příklady USDEURGBPJPY
	Název dodavatele SupplierName	Název navrženého nebo předem vybraného dodavatele zboží či služeb.
Popis Tento atribut určuje dodavatele, od kterého se má zboží nebo služba nakoupit. Dodavatele může navrhnout žadatel nebo jej může systém vybrat podle katalogů či předchozích dohod. Analýza podle dodavatele může odhalit důležité vzorce v nákupu. Pomůže například zjistit, zda se požadavky na určitého dodavatele schvalují déle nebo se častěji zamítají. Tyto informace mohou být užitečné při řízení vztahů s dodavateli a při plánování nákupů. Proč je to důležité Umožňuje analyzovat výkonnost procesu podle dodavatele a podpořit rozhodování o nákupní strategii i řízení vztahů s dodavateli. Kde data získat Nachází se v tabulce položek požadavku POR_REQUISITION_LINES_ALL. Často se propojuje přes VENDOR_ID s hlavní tabulkou dodavatelů, například POZ_SUPPLIERS. Příklady Kancelářské potřeby, s. r. o.Globální technologická řešeníKreativní marketingová agentura
	Popis položky ItemDescription	Popis produktu nebo služby požadované v položce nákupního požadavku.
Popis Tento atribut obsahuje textový popis pořizované položky a uvádí podrobnosti o požadovaném zboží nebo službě. Popis položky bývá často nestrukturovaný, přesto poskytuje užitečný kontext pro analýzu. Pomocí filtrů lze vyhledat požadavky na konkrétní typy nákupu, které nemusí být zachyceny typem požadavku. Analytik může například vyhledat všechny požadavky obsahující výraz „softwarová licence“ a zjistit, jakým procesem procházejí a jak dlouho trvá jejich zpracování. Proč je to důležité Poskytuje podrobnější informace o pořizované položce a umožňuje přesněji filtrovat a analyzovat konkrétní zboží nebo služby. Kde data získat Nachází se v tabulce položek požadavku POR_REQUISITION_LINES_ALL, například v poli ITEM_DESCRIPTION. Příklady Notebook s úhlopříčkou 15 palců, 16 GB RAMKonzultační služby, projekt na 4. čtvrtletíRoční prodloužení údržby softwaru
	Schvalovací cesta workflow ApprovalWorkflowPath	Předem stanovené pořadí schvalovatelů nebo schvalovacích skupin, které musí požadavek projít.
Popis Tento atribut určuje očekávaný standardní postup schvalování požadavku podle firemních pravidel. Zohledňuje například částku požadavku, jeho typ a oddělení. Představuje model procesu „jak má být“. Schvalovací cesta workflow je důležitá pro kontrolu shody a dodržování pravidel. Podporuje dashboard „Analýza shody a odchylek“ a KPI „Index shody požadavků“, protože umožňuje přímo porovnat skutečné kroky schvalování s předepsanou cestou. Odchylky mohou ukazovat na porušení pravidel nebo neefektivní proces. Proč je to důležité Umožňuje ověřit shodu porovnáním skutečného průběhu procesu s požadovanou hierarchií schvalování a odhalit požadavky, které pravidla nedodržují. Kde data získat Tyto informace se nastavují v Oracle Fusion BPM Worklist nebo Approval Management Engine (AMX). Získání definované cesty pro každý požadavek může být složité a může vyžadovat dotazy do konfiguračních tabulek. Příklady Vedoucí > ředitel > viceprezident pro financeVlastník nákladového střediska > bezpečnost ITVedoucí > vedoucí oddělení
	Typ požadavku RequisitionType	Kategorie požadavku, například žádost o zboží nebo služby.
Popis Tento atribut klasifikuje požadavek podle toho, co se objednává. Mezi běžné typy patří zboží, služby nebo kapitálové výdaje. Typ může ovlivnit požadované schvalovací workflow i nákupní strategii. Při analýze slouží typ požadavku jako užitečné kritérium pro filtrování a porovnávání. Můžete například zjistit, zda se požadavky na služby schvalují déle než požadavky na zboží. Atribut pomáhá porozumět tomu, zda se různé typy požadavků liší průběhem nebo úzkými místy. Proč je to důležité Umožňuje rozdělit analýzu podle typu nákupu a zjistit, jak se proces liší například u zboží a služeb. Kde data získat Často se určuje podle typu nebo kategorie položky vybrané při vytvoření požadavku. Může být uložena v tabulce položek požadavku POR_REQUISITION_LINES_ALL. Příklady ZbožíSlužbyKapitálové výdaje

Povinné Doporučené Volitelné

Aktivity procesu nákupu od požadavku po platbu

Toto jsou důležité kroky a milníky procesu, které je třeba zaznamenat pro přesné zmapování procesu nákupních požadavků.

6 Doporučené 6 Volitelné

	Aktivita	Popis
	Nákupní objednávka vytvořena	K této události dojde, když se schválený řádek požadavku použije k vytvoření nákupní objednávky. Propojuje proces zpracování požadavku s navazujícím nákupním procesem.
Proč je to důležité Jde o důležitý milník pro měření doby od požadavku po nákupní objednávku. Prodlevy v této fázi ukazují na úzká místa při předání požadavku z procesu schvalování do nákupu. Kde data získat Jde o výslovně zaznamenanou událost. Vazba mezi požadavkem a nákupní objednávkou se ukládá například v tabulce PO_LINE_LOCATIONS_ALL, která obsahuje odkaz na ID zdrojového řádku požadavku. Zachycení Najděte datum vytvoření nákupní objednávky, která odkazuje na zadané ID požadavku. Typ události explicit
	Nákupní požadavek odeslán	Označuje, že uživatel odeslal vyplněný požadavek do schvalovacího workflow. Událost se zaznamená při změně stavu požadavku z „Incomplete“ nebo „Draft“ na stav označující čekání na schválení.
Proč je to důležité Tato činnost zahajuje schvalovací cyklus. Je důležitým milníkem pro měření doby schválení požadavku a celkové doby zpracování. Kde data získat Událost lze odvodit ze změny stavu v tabulce POR_REQUISITION_HEADERS_ALL, například při změně stavu na „PENDING APPROVAL“. Datum odeslání bývá uloženo také samostatně. Zachycení Určete časové razítko první změny pole stavu dokumentu na „Pending Approval“. Typ události inferred
	Nákupní požadavek schválen	Označuje konečné schválení nákupního požadavku po úspěšném dokončení všech kroků workflow. Událost lze odvodit ze změny celkového stavu požadavku na „Approved“.
Proč je to důležité Jde o důležitý milník, který potvrzuje, že požadavek je připraven k nákupu. Zároveň označuje konec období, za které se měří celková doba schválení požadavku. Kde data získat Událost lze odvodit ze změny pole stavu dokumentu v tabulce POR_REQUISITION_HEADERS_ALL na „APPROVED“. Čas události odpovídá datu této změny. Zachycení Určete časové razítko, kdy se stav dokumentu poprvé nastaví na „Approved“. Typ události inferred
	Nákupní požadavek uzavřen	Označuje konec životního cyklu požadavku. Všechny jeho řádky byly vyřízeny, například převedeny na nákupní objednávky, nebo zrušeny. Událost lze odvodit z konečné změny stavu.
Proč je to důležité Jde o hlavní událost úspěšného ukončení procesu. Potvrzuje, že požadavek byl zcela zpracován a není třeba podnikat další kroky. Kde data získat Událost lze odvodit ze změny stavu hlavičky požadavku v tabulce POR_REQUISITION_HEADERS_ALL na „CLOSED“. Zachycení Určete časové razítko změny stavu dokumentu požadavku na „Closed“. Typ události inferred
	Nákupní požadavek vytvořen	Označuje zahájení nákupního procesu, kdy uživatel poprvé uloží nový nákupní požadavek. Tato událost se v systému obvykle zaznamená jako vytvoření záznamu s odpovídajícím časovým razítkem.
Proč je to důležité Jde o hlavní počáteční událost procesu zpracování požadavku. Analýza doby od vytvoření po odeslání může odhalit prodlevy při přípravě a formalizaci požadavku. Kde data získat Tato událost se zaznamenává v tabulce POR_REQUISITION_HEADERS_ALL. Zachycuje se záznamem ve sloupci creation_date při vytvoření nového ID požadavku. Zachycení Použijte časové razítko vytvoření záznamu hlavičky požadavku. Typ události explicit
	Nákupní požadavek zamítnut	Označuje konečné zamítnutí požadavku, kterým se jeho zpracování ukončí. Událost lze odvodit ze změny celkového stavu požadavku na „Rejected“.
Proč je to důležité Tato činnost ukončuje neúspěšné případy. Jejich analýza je důležitá pro pochopení KPI míry zamítnutí nákupních požadavků a příčin neúspěchu. Kde data získat Událost lze odvodit ze změny stavu dokumentu v tabulce POR_REQUISITION_HEADERS_ALL na „REJECTED“. Zachycení Určete časové razítko, kdy se stav dokumentu poprvé nastaví na „Rejected“. Typ události inferred
	Nákupní požadavek stažen	K této události dojde, když žadatel zruší nebo stáhne odeslaný požadavek před jeho úplným schválením. Obvykle jde o výslovnou akci uživatele, která změní stav požadavku.
Proč je to důležité Sledování stažených požadavků pomáhá zjistit příčiny předčasného ukončení, například změnu obchodních potřeb nebo opravu chyb uživatelem po odeslání. Kde data získat Událost lze odvodit ze změny stavu na „WITHDRAWN“ v tabulce POR_REQUISITION_HEADERS_ALL. Akce se zaznamenává v historii činností požadavku. Zachycení Zaznamenejte časové razítko změny stavu požadavku na „Withdrawn“. Typ události inferred
	Nákupní požadavek změněn	Tato událost označuje, že uživatel po prvním odeslání požadavek upravil. Často je pak nutné znovu zahájit schvalování. Událost lze odvodit ze změn důležitých datových polí nebo z vytvoření nové verze požadavku.
Proč je to důležité Časté změny ukazují na problémy s kvalitou dat nebo měnící se požadavky. Vedou k opakované práci a prodlevám. Tato událost přímo slouží k výpočtu KPI míry změn nákupních požadavků. Kde data získat Událost lze odvodit sledováním čísel verzí požadavku nebo změnou stavu zpět na „Incomplete“ po odeslání. Úpravy mohou být zaznamenány také v protokolech změn nebo auditních tabulkách. Zachycení Určete časová razítka vytvoření nových verzí stejného ID požadavku po jeho odeslání. Typ události inferred
	Schvalovací krok schválen	Označuje, že konkrétní schvalovatel schválil požadavek v přiděleném kroku workflow. Událost se výslovně zaznamenává v historii schvalování.
Proč je to důležité Sledování jednotlivých schvalovacích kroků pomáhá zmapovat skutečný postup schvalování a změřit dobu zpracování v každé úrovni hierarchie. Kde data získat Údaj se získává z historie schvalovacích akcí požadavku. Ta se obvykle ukládá do tabulek workflow (WF) nebo Human Capital Management (HCM), které spravují schvalovací hierarchie. Zachycení Použijte časové razítko akce „APPROVE“ z protokolu historie akcí workflow. Typ události explicit
	Schvalovací krok vrácen	Schvalovatel vrátí požadavek zpracovateli kvůli doplnění informací nebo drobným opravám, aniž by jej formálně zamítl. Obvykle jde o výslovnou akci v systému workflow.
Proč je to důležité Tato událost ukazuje na potřebu upřesnění a vytváří cyklus opakované práce, který prodlužuje dobu zpracování. Rozlišení vrácení od zamítnutí poskytuje podrobnější přehled o překážkách v procesu. Kde data získat Údaj se získává z historie schvalovacích akcí požadavku. Systém workflow zaznamená akci „RETURN“ nebo podobnou akci s časovým razítkem. Zachycení Použijte časové razítko akce „RETURN“ nebo „Request for Information“ z historie workflow. Typ události explicit
	Schvalovací krok zamítnut	Schvalovatel požadavek zamítne. Obvykle jej tím vrátí zpracovateli k opravě nebo ukončí jeho vyřizování. Tato akce se výslovně zaznamenává v historii workflow.
Proč je to důležité Tato činnost je častou příčinou opakované práce a prodlev. Analýza zamítnutí pomáhá odhalit problémy s dodržováním pravidel, rozpočtem nebo nejasným zdůvodněním. Kde data získat Údaj se získává z historie schvalovacích akcí požadavku. Systém workflow zaznamená akci „REJECT“ s časovým razítkem. Zachycení Použijte časové razítko akce „REJECT“ z protokolu historie akcí workflow. Typ události explicit
	Zahájení schvalovacího kroku	Označuje okamžik, kdy je požadavek ve workflow přidělen konkrétnímu schvalovateli nebo schvalovací skupině. Údaj se získává z transakčního protokolu workflow enginu.
Proč je to důležité Tato činnost je důležitá pro výpočet čekací doby každého schvalovacího kroku. Pomáhá určit úzká místa způsobená konkrétními schvalovateli nebo úrovněmi schvalování. Kde data získat Údaj se získává z tabulek workflow v Oracle Fusion, které zaznamenávají úkoly přidělené uživatelům. Použije se časové razítko přidělení schvalovacího úkolu. Zachycení Použijte časové razítko vytvoření úkolu v historii workflow pro daný požadavek. Typ události explicit

Doporučené Volitelné

Návody k extrakci dat

Jak získat data z Oracle Fusion Financials

Kroky

Přejděte do části Reports and Analytics: Přihlaste se do Oracle Fusion Financials. V nabídce Navigator přejděte do Tools a vyberte Reports and Analytics. Zde najdete nástroje pro tvorbu reportů.
Vytvořte novou analýzu: V pracovním prostoru Reports and Analytics klikněte na tlačítko 'Create' a v rozbalovací nabídce vyberte 'Analysis'. V nové kartě se otevře editor analýz Oracle Transactional Business Intelligence (OTBI).
Vyberte oblast předmětu: Zobrazí se výzva k výběru oblasti předmětu. Do vyhledávacího pole zadejte 'Procurement - Requisitions Real Time' a vyberte ji ze seznamu. Tato oblast obsahuje potřebná data o událostech v průběhu životního cyklu požadavku.
Sestavte analýzu událostí požadavku: V tomto kroku je třeba spojit výsledky několika dotazů, aby se zachytily jednotlivé události. Uživatelské rozhraní OTBI nemá funkci UNION ALL pro různé typy událostí, proto vytvořte jeden report se všemi relevantními poli data a stavu. Na kartě 'Criteria' přetáhněte sloupce uvedené v části dotazu z panelu 'Subject Areas' vlevo do oblasti 'Selected Columns'. Zahrňte například sloupce s datem vytvoření, odeslání, schválení a vytvoření objednávky.
Přidejte historii akcí u požadavku: Chcete-li zachytit jednotlivé kroky schválení (schváleno, zamítnuto, vráceno, staženo), přidejte pole ze složky 'Requisition Action History' v oblasti předmětu. Do vybraných sloupců přetáhněte 'Action Date', 'Action' a 'Performer'.
Nastavte filtry: Přejděte na kartu 'Prompts' a vytvořte filtry pro analýzu. Pro omezení objemu dat je důležité nastavit časové období. Vytvořte filtr pro 'Requisition Header'.'Requisition Creation Date' a zadejte období, například posledních 6 měsíců. Data můžete dále omezit výběrem 'Business Unit' nebo 'Requester Name'.
Spusťte a zkontrolujte report: Přejděte na kartu 'Results', spusťte analýzu a zobrazte náhled dat. Výstupem bude široká tabulka s jedním řádkem na položku požadavku nebo schvalovací akci a několika sloupci s daty a stavy.
Exportujte nezpracovaná data: Až budete s náhledem spokojeni, klikněte na odkaz 'Export', který bývá ve spodní části stránky s výsledky. Jako formát vyberte 'Data' > 'CSV File'. Tím stáhnete nezpracovaná data z analýzy.
Převeďte data do formátu záznamu událostí: Exportovaný soubor CSV bude mít široký formát. Pomocí externího nástroje, například skriptu v Pythonu, Power Query v Excelu nebo jiného nástroje pro přípravu dat, jej převeďte. Sloupce s daty je třeba rozbalit do jednoho sloupce 'EventTime' a pro každý typ události vytvořit odpovídající sloupec 'ActivityName' (například 'Requisition Created' nebo 'Requisition Submitted').
Dokončete přípravu k nahrání: Po převodu ověřte, že soubor obsahuje požadované sloupce: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem a LastDataUpdate. Uložte výsledný záznam událostí jako soubor CSV a nahrajte jej do ProcessMind.

Konfigurace

Oblast předmětu: Použijte především oblast 'Procurement - Requisitions Real Time'. Obsahuje základní informace o hlavičkách a řádcích požadavků, rozúčtování a historii schvalování.
Časové období: Vždy nastavte povinný filtr data, abyste omezili objem dat a zrychlili zpracování. Dobrým začátkem je filtr 'Requisition Header'.'Requisition Creation Date' za poslední 3 až 6 měsíců.
Důležité filtry: Zvažte filtry 'Requisition Header'.'Business Unit' a 'Requisition Header'.'Requisition Status'. Zaměříte se tak na příslušné organizační jednotky a můžete vyloučit nepotřebné stavy, například 'Canceled'.
Výběr sloupců: Sloupce do analýzy přidávejte uvážlivě. Příliš mnoho sloupců, zejména z různých složek (dimenzí), může zpomalit zpracování. Zahrňte jen pole potřebná pro záznam událostí.
Oprávnění: Uživatel, který data extrahuje, musí mít roli s potřebnými oprávněními pro pracovní prostor Reports and Analytics a oblast 'Procurement - Requisitions Real Time'. Tato oprávnění obvykle mají role jako 'BI Author' nebo 'Procurement Analyst'.

Ukázkový dotaz sql

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

Kroky

Přihlaste se do Oracle Fusion Financials jako uživatel s oprávněními BI Author nebo podobnými.
Kliknutím na ikonu Navigator otevřete pracovní oblast Reports and Analytics a vyberte Tools > Reports and Analytics.
Kliknutím na tlačítko „Browse Catalog“ otevřete katalog Business Intelligence Publisher.
V rozhraní BI Publisher klikněte na „New“ a v rozevíracím seznamu vyberte „Data Model“.
Ve vlastnostech datového modelu můžete zadat název a popis. Kliknutím na ikonu „+“ přidejte novou sadu dat a vyberte „SQL Query“.
V dialogovém okně nové sady dat zadejte název, například Requisition_Event_Log, vyberte vhodný zdroj dat pro Financials, například ApplicationDB_FSCM, a jako typ SQL nastavte „Standard SQL“.
Zkopírujte celý SQL skript z části „query“ tohoto dokumentu a vložte ho do textového pole SQL Query.
Dotaz obsahuje parametry :p_start_date a :p_end_date. BI Publisher je rozpozná automaticky. Podle potřeby můžete nastavit výchozí hodnoty.
Uložte datový model do vhodné složky katalogu, například Shared Folders/Custom.
Chcete-li exportovat data, vraťte se do katalogu, klikněte na „New“ a vyberte „Report“. Propojte novou sestavu s právě vytvořeným datovým modelem.
Spusťte sestavu a zadejte počáteční a koncové datum. Jakmile se zobrazí data, stáhněte výsledky do souboru CSV pomocí funkce „Export“.
Ověřte, že je výsledný soubor CSV uložen v kódování UTF-8 a obsahuje požadované záhlaví pro načtení do nástroje pro process mining.

Konfigurace

Zdroj dat: Zdroj dat BI Publisher, obvykle pojmenovaný 'ApplicationDB_FSCM' nebo podobně, musí být nastaven pro uživatele s přístupem pro čtení ke všem tabulkám v dotazu, včetně tabulek z oblastí Procurement (POR, PO), Human Capital Management (PER, HR) a Financials (FUN).
Filtr časového období: Dotaz obsahuje povinné parametry data (:p_start_date a :p_end_date), které filtrují podle data vytvoření požadavku. Při první extrakci nebo u rozsáhlých systémů je důležité získávat data po zvládnutelných dávkách, například za 3 až 6 měsíců, aby nedošlo k vypršení časového limitu systému.
Filtr obchodní jednotky: V komentované části klauzule WHERE dotazu je připraven filtr podle názvu obchodní jednotky. Doporučujeme jej odkomentovat a nastavit tak, aby zahrnoval jen jednotky relevantní pro analýzu. Výrazně tím můžete zrychlit zpracování.
Předpoklady: Uživatel, který vytváří a spouští report, potřebuje roli s oprávněními BI Publisher, například 'BI Administrator Role' nebo 'BI Author Role'. Zároveň musí mít potřebná oprávnění pro přístup k datům o nákupu.

Ukázkový dotaz sql

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

Kroky

Předpoklady a nastavení prostředí: Ověřte, že máte v systému nainstalovaný Python 3. Knihovnu requests nainstalujete spuštěním příkazu pip install requests v terminálu. Budete také potřebovat přihlašovací údaje k API (uživatelské jméno a heslo) uživatele Oracle Fusion s dostatečnými oprávněními ke čtení nákupních požadavků a základní URL adresu instance Oracle Fusion.
Uložte skript v Pythonu: Uložte celý kód Pythonu z části 'query' do souboru, například extract_requisitions.py.
Nastavte parametry skriptu: Otevřete soubor skriptu v textovém editoru a upravte zástupné hodnoty na začátku. Nastavte FUSION_URL, USERNAME a PASSWORD podle svého prostředí Oracle Fusion. Pomocí START_DATE a END_DATE určete období extrakce.
Seznamte se s koncovými body a poli API: Skript používá zdroj REST API purchaseRequisitions. Parametrem fields vyžádá jen potřebná data, včetně vnořených kolekcí, jako jsou lines (informace o objednávkách) a actionHistory (události schvalování), což zrychluje zpracování.
Spusťte skript: V terminálu spusťte příkaz python extract_requisitions.py. Skript se ověří vůči API, začne získávat data a bude v konzoli zobrazovat průběh včetně počtu zpracovaných požadavků.
Zpracování stránkování: Skript stránkuje data automaticky. Oracle Fusion REST API vrací data po částech, tedy na jednotlivých stránkách. Skript kontroluje příznak hasMore v každé odpovědi a opakuje požadavky s aktualizovaným parametrem offset, dokud nezíská všechny požadavky z určeného období.
Převod dat: Pro každý požadavek získaný z API skript vytvoří několik řádků záznamu událostí. Z CreationDate vytvoří událost 'Requisition Created', z SubmittedDate událost 'Requisition Submitted' a z kolekce actionHistory vytvoří podrobné události pro jednotlivé kroky schválení (zahájeno, schváleno, zamítnuto, vráceno).
Odvození událostí konečného stavu: Skript zachytí výsledné události, například 'Requisition Approved' a 'Requisition Rejected', podle konečného DocumentStatus požadavku a jako čas události použije LastUpdateDate.
Vytvoření události objednávky: Skript zkontroluje každý řádek požadavku. Pokud řádek obsahuje PoHeaderId, znamená to, že byla vytvořena objednávka. Do záznamu událostí přidá odpovídající událost, která propojí požadavek s navazujícím nákupním procesem.
Zkontrolujte výstupní soubor: Po dokončení skript vytvoří ve stejné složce soubor CSV oracle_fusion_requisitions_event_log.csv. Soubor obsahuje extrahovaný záznam událostí.
Připravte soubor k nahrání: Otevřete vytvořený soubor CSV v tabulkovém procesoru a zkontrolujte jeho obsah. Ověřte, že sloupce a formáty dat odpovídají požadavkům nástroje process mining. Soubor je připraven k nahrání do ProcessMind.

Konfigurace

Přihlašovací údaje k API: Potřebujete vyhrazený účet pro integraci s rolí, která umožňuje přístup pouze pro čtení k REST API Purchase Requisitions. Příkladem jsou role Procurement Manager nebo vlastní role pro integraci.
Koncový bod REST API: Skript používá koncový bod .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Ověřte, že číslo verze v URL odpovídá vašemu prostředí Oracle Fusion.
Filtr časového období: Skript obsahuje proměnné START_DATE a END_DATE. Doporučujeme získávat data po zvládnutelných dávkách, například za 3 až 6 měsíců, abyste předešli vypršení časového limitu API a problémům s výkonem. Filtr se použije na CreationDate požadavků.
Výběr polí: Parametr fields je důležitý pro výkon. Omezuje odpověď API na atributy potřebné pro záznam událostí, čímž snižuje síťový provoz i dobu zpracování. Neodstraňujte povinná pole, jako jsou RequisitionId, CreationDate, actionHistory nebo lines.
Limit stránkování: Parametr limit je nastaven na 100, což je bezpečná hodnota pro většinu prostředí. Pro rychlejší extrakci můžete zkusit hodnotu 200 nebo 500. Příliš vysoká hodnota však může způsobit problémy s pamětí nebo narazit na limity API.

Ukázkový dotaz python

import requests
import csv
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

if __name__ == class="hl-string">"__main__":
    get_requisitions_data()

Kroky

Ověřte, že je ve vašem prostředí k dispozici Oracle BI Cloud Connector, potřebný obsah pro nákup v Oracle Fusion Financials a přístup k příslušným Public View Objects. Zkontrolujte, že uživatel BICC nebo účet pro integraci má oprávnění extrahovat data o požadavcích, historii schvalování a objednávkách. Přesné názvy rolí a položek nabídky se liší podle verze Oracle. Použijte odpovídající oblast správy BICC ve svém prostředí.
Určete a povolte PVO potřebné pro extrakci. Použijte RequisitionHeaderPVO nebo odpovídající PVO hlavičky požadavku ve svém prostředí spolu s PVO, které zpřístupňují řádky požadavků, historii stavů, historii schvalovacího workflow a odkazy na objednávky. Nepředpokládejte, že jedno PVO obsahuje historii workflow nebo vytvoření objednávky. Zaznamenejte přesné názvy PVO a dostupné atributy.
Nastavte úlohu BICC pro přírůstkovou nebo historickou hromadnou extrakci. Pomocí [Start date parameter] a [End date parameter] nastavte období extrakce a určete, aby se soubory CSV ukládaly do schváleného cloudového úložiště. Při prvním načtení zvolte dostatečně široké historické období. U opakovaných načtení použijte překrývající se období, abyste zachytili pozdější aktualizace. Pokud je k dispozici, odstraňte duplicity podle identifikátoru případu, aktivity, času události a identifikátoru zdrojové události.
Nastavte sloupce pro extrakci. Zahrňte identifikátor požadavku, identifikátory hlavičky a řádku, žadatele, oddělení, částku, stav, požadované datum, obchodní jednotku, důvod zamítnutí, časová razítka vytvoření a aktualizace, časová razítka změn stavu, přiřazení ke schválení a schvalovacích akcí, schvalovací akci, odkaz na objednávku a časové razítko obnovení dat BICC. Použijte přesné názvy atributů dostupné ve vybraných PVO. Pokud atribut není k dispozici, namapujte jej na [Configure based on your system] a omezení zdokumentujte. Nenahrazujte jej neověřeným polem.
Extrahujte zdrojové soubory CSV a uchovejte jejich původní podobu. Načtěte každý soubor do přípravné oblasti, zachovejte název zdrojového PVO a souboru, sjednoťte časová razítka podle dohodnutého časového pásma a jednotně zpracujte hodnoty data a času Oracle. Identifikátory považujte za řetězce, aby se neztratily úvodní nuly ani přesnost.
Převeďte zdrojová data do tabulky událostí s jedním řádkem pro každou konkrétní obchodní událost. Výstup musí obsahovat PurchaseRequisitionId, ActivityName, EventTime, SourceSystem a LastDataUpdate. Pokud jsou k dispozici, přidejte doporučené atributy. Nespoléhejte na to, že ProcessMind odvodí události ze stavů nebo změn polí. Při převodu výslovně vytvořte řádky pro všech dvanáct aktivit uvedených v dotazu.
Vytvářejte řádky událostí podle odpovídajících zdrojových údajů. Pro Requisition Created použijte záznam o vytvoření, pro Requisition Submitted výslovný přechod do stavu odesláno, pro Requisition Withdrawn výslovnou akci nebo přechod stažení, pro Requisition Amended zjištěnou změnu po odeslání nebo novou verzi, pro Approval Step Started přiřazení ve workflow a pro Approval Step Approved, Approval Step Rejected a Approval Step Returned výslovné akce v historii schvalování. Pro Requisition Approved, Requisition Rejected a Requisition Closed použijte výslovný přechod celkového stavu. Pro Purchase Order Created použijte výslovný záznam o vytvoření objednávky nebo její časové razítko propojené s požadavkem.
Odstraňujte duplicity deterministicky. Pokud stejnou událost představuje více zdrojových řádků, ponechte jeden řádek s nejpřesnějším časovým razítkem události a stabilním identifikátorem zdroje, pokud je k dispozici. Neslučujte různé kroky schválení jen proto, že mají stejný identifikátor požadavku. Zachovejte samostatné události pro jednotlivé schvalovatele nebo kroky workflow.
Ověřte výsledný záznam událostí. Zkontrolujte, že obsahuje všechny požadované aktivity, každá událost má identifikátor případu a časové razítko, časová razítka spadají do období extrakce nebo jsou vysvětlena pozdějšími aktualizacemi a doporučené atributy jsou vyplněny, pokud je zdroj obsahuje. Porovnejte počty požadavků a propojení na objednávky se zdrojovými extrakty.
Exportujte konečný záznam událostí jako soubor CSV v kódování UTF-8, s jedním řádkem záhlaví a jednou událostí na řádek. Použijte přesné názvy sloupců PurchaseRequisitionId, ActivityName, EventTime, SourceSystem a LastDataUpdate a přidejte doporučené atributy. Nahrajte soubor CSV do ProcessMind a nastavte PurchaseRequisitionId jako identifikátor případu, ActivityName jako aktivitu a EventTime jako časové razítko události.

Konfigurace

Metoda extrakce: hromadná extrakce dat pomocí Oracle BI Cloud Connector, soubory CSV se ukládají do nakonfigurovaného cloudového úložiště.
Zdrojové objekty: Použijte RequisitionHeaderPVO a odpovídající PVO pro řádky požadavků, historii stavů, historii schvalovacího workflow a odkazy na objednávky, které jsou v daném prostředí k dispozici. Přesné názvy PVO a atributy ověřte v prostředí.
Povinné výstupní sloupce: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem a LastDataUpdate.
Doporučené výstupní sloupce: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason a BusinessUnit.
Časové období: Pro běžnou analýzu použijte období tří až šesti měsíců. Při prvním historickém načtení použijte podle potřeby delší období. U opakovaných extrakcí použijte překrývající se období, abyste zachytili pozdější aktualizace, a následně odstraňte duplicity.
Filtry: Filtry [Company-specific filter], [Document Type filter], [Business Unit filter] a [Date range filter] použijte pouze tehdy, pokud jsou tyto atributy ve vybraných PVO dostupné. Ověřte, zda se filtr vztahuje k datu vytvoření, aktualizace, změny stavu nebo jinému zdrojovému datu.
Přírůstková extrakce: Upřednostněte časové razítko aktualizace nebo podporovaný mechanismus přírůstkové extrakce zpřístupněný v BICC. Uchovejte časový bod poslední úspěšné extrakce a při dalším spuštění zahrňte krátké překrývající se období.
Úplnost událostí: Pokud hlavičky požadavků neobsahují historii schvalování, změny stavů, úpravy ani vytvoření objednávky, nastavte samostatné zdrojové extrakce. Ze samotného aktuálního stavu hlavičky nelze spolehlivě rekonstruovat historické události.
Výkon: Omezte časové období a počet vybraných sloupců, u rozsáhlých extrakcí použijte dostupné dělení na části, vynechte nepotřebné popisné atributy a zpracovávejte soubory CSV po dávkách. Zdrojové soubory uchovejte pro následné porovnání.
Úložiště: Nastavte schválené cloudové úložiště s dostatečnou kapacitou, dobou uchovávání, šifrováním a řízením přístupu. Ověřte, že účet pro extrakci může zapisovat soubory a proces převodu je může číst.
Předpoklady: Dostupný BICC, přístup k příslušným datům o nákupu a schvalování v Oracle Fusion, potřebná oprávnění pro integraci, přístup k vybraným PVO a případné požadované předplatné nebo licence Oracle. Přesné názvy rolí, licencí a cesty v nabídce závisí na verzi Oracle a konfiguraci prostředí.
Práce s časem: Sjednoťte všechna zdrojová časová razítka podle zdokumentovaného časového pásma. Pokud je to nutné pro audit, uchovejte i původní časové razítko.
Identifikace případu: Jako identifikátor případu použijte PurchaseRequisitionId. Identifikátor řádku požadavku použijte pouze tehdy, pokud záměrně modelujete proces na úrovni řádků.

Ukázkový dotaz sql

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Chcete začít?

Pomocí této šablony můžete začít optimalizovat proces nákupu od požadavku po platbu a hledat možnosti, jak zvýšit jeho efektivitu. Připravte se na zlepšení nákupního provozu.

Zpět na průvodce zlepšováním

Stáhnout šablonu

Zrychlete proces nákupu od požadavku po platbu o 30 %

Zjednodušte zpracování nákupních požadavků v Oracle P2P a zkraťte dobu jejich vyřízení o 30 %.

Začněte se zkušební verzí

Platební kartu nepotřebujete, nastavení zabere jen několik minut.

Šablona dat pro proces nákupu od požadavku po platbu

Šablona dat pro proces nákupu od požadavku po platbu

Atributy procesu nákupu od požadavku po platbu

Aktivity procesu nákupu od požadavku po platbu

Návody k extrakci dat

Export z Oracle Transactional Business Intelligence (OTBI)

Kroky

Konfigurace

Ukázkový dotaz sql

Extrakce datového modelu SQL v Oracle BI Publisher

Kroky

Konfigurace

Ukázkový dotaz sql

Skript v Pythonu přes Oracle Fusion REST API

Kroky

Konfigurace

Ukázkový dotaz python

Hromadná extrakce dat pomocí Oracle BI Cloud Connector (BICC)

Kroky

Konfigurace

Ukázkový dotaz sql

Chcete začít?

Zrychlete proces nákupu od požadavku po platbu o 30 %