> Průběžné zlepšování procesů > Nákup od požadavku po platbu: nákupní požadavek > SAP Ariba > Datová šablona

Šablona dat pro Purchase to Pay: nákupní požadavek

SAP Ariba

Atributy procesu Purchase to Pay: nákupní požadavek(19) Činnosti procesu Purchase to Pay: nákupní požadavek(13) Návody na extrakci dat(2)

Šablona dat pro Purchase to Pay: nákupní požadavek

Tato datová šablona vám pomůže efektivně shromáždit a uspořádat informace potřebné k analýze procesu Purchase to Pay: nákupní požadavek. Obsahuje základní atributy a činnosti pro sestavení kvalitního záznamu událostí, který umožní podrobně analyzovat výkonnost procesu. Najdete v ní také praktický návod, jak data získat ze zdrojového systému a začít s process mining.

Doporučené atributy pro podrobnou analýzu
Hlavní činnosti a milníky procesu, které je třeba sledovat
Podrobný návod na extrakci dat ze systému

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 Purchase to Pay: nákupní požadavek

Doporučená datová pole pro záznam událostí, který umožní podrobně analyzovat proces Purchase to Pay: nákupní požadavek a zachytit všechny důležité informace.

3 Povinné 8 Doporučené 8 Volitelné

	Název	Popis
	Časové razítko události EventTimestamp	Přesné datum a čas, kdy činnost nastala. Slouží jako hlavní časový údaj pro řazení událostí.
Popis Časové razítko události zaznamenává přesný okamžik, kdy činnost proběhla. Tento přesný údaj je nezbytný pro správné seřazení událostí v každém případu a výpočet doby mezi jednotlivými kroky procesu. V analýze tvoří základ všech časových výpočtů, včetně doby zpracování, čekání a trvání jednotlivých kroků. Používá se v dashboardech pro analýzu výkonnosti, například v ukazatelích Doba schválení požadavku a Analýza úzkých míst ve schvalovací cestě. Přesnost tohoto pole přímo ovlivňuje spolehlivost všech ukazatelů výkonnosti. Proč je to důležité Tento atribut určuje chronologické pořadí událostí a slouží jako základ pro výpočty výkonnosti a doby trvání, například doby zpracování a úzkých míst. Kde data získat Obvykle se nachází u záznamů činností nebo změn stavu v auditních záznamech či tabulkách transakčních protokolů SAP Ariba. Příklady 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Název činnosti ActivityName	Název konkrétní obchodní události, která nastala v určitém okamžiku životního cyklu požadavku.
Popis Název činnosti popisuje jednotlivý krok nebo milník v procesu zpracování požadavku, například „Požadavek vytvořen“, „Krok schválen“ nebo „Požadavek uzavřen“. Údaj se obvykle odvozuje ze záznamů událostí, změn stavu nebo konkrétních akcí uživatelů zaznamenaných v SAP Ariba. Tento atribut je nezbytný pro vytvoření mapy procesu, která znázorňuje průběh činností. Analýza jejich pořadí a četnosti pomáhá odhalit obvyklé cesty procesem, úzká místa, odchylky od standardního postupu a místa, kde se práce přepracovává. Tvoří základ každé analýzy process mining. Proč je to důležité Určuje jednotlivé kroky procesu a umožňuje vizualizovat a analyzovat workflow požadavku včetně úzkých míst a odchylek. Kde data získat Odvozuje se ze záznamů událostí, auditních záznamů nebo záznamů o změnách stavu v SAP Ariba. Často souvisí s tabulkami hlaviček požadavků a jejich položek. Příklady Požadavek odeslánKrok schválenPožadavek upravenObjednávka vytvořena
	Purchase Requisition ID PurchaseRequisitionId	Jedinečný identifikátor dokumentu požadavku na nákup, který slouží jako hlavní identifikátor případu v procesu.
Popis Purchase Requisition ID je hlavní identifikátor, který propojuje všechny činnosti související s jedním požadavkem na zboží nebo služby. Každý požadavek vytvořený v SAP Ariba dostane jedinečné ID, které zůstává stejné po celý jeho životní cyklus, od vytvoření a odeslání až po konečné schválení, zamítnutí nebo uzavření. Při analýze process mining je tento atribut základem pro propojení událostí do případů. Umožňuje rekonstruovat celý průběh každého požadavku od začátku do konce, přesně počítat dobu zpracování, identifikovat varianty procesu a analyzovat opakované cykly přepracování. Bez tohoto identifikátoru by nebylo možné rozlišit události patřící k různým požadavkům. Proč je to důležité Jde o základní identifikátor případu, který propojuje všechny související činnosti. Díky němu lze analyzovat celý proces zpracování každého jedinečného požadavku. Kde data získat V datové struktuře SAP Ariba jde o pole primárního klíče v hlavních tabulkách hlaviček požadavků. Příklady PR-102345PR-102346PR-102347
	Celková částka požadavku TotalRequisitionAmount	Celková peněžní hodnota požadavku na nákup.
Popis Tento atribut zachycuje finanční hodnotu celého požadavku. Poskytuje důležitý obchodní kontext pro kategorizaci a stanovení priority požadavků. Porovnání ukazatelů procesu s touto hodnotou může odhalit důležité souvislosti. Požadavky s vysokou hodnotou mohou například procházet přísnějším schvalováním nebo se zpracovávat déle. Atribut pomáhá pochopit finanční dopad neefektivit a rozdělit požadavky do hodnotových pásem pro srovnávací analýzu. Proč je to důležité Poskytuje finanční kontext pro analýzu toho, jak hodnota požadavku ovlivňuje průběh procesu, například dobu schvalování a složitost workflow. Kde data získat Informace najdete v dokumentaci SAP Ariba. Jde o standardní pole v hlavičce požadavku na nákup. Příklady 1500.0025000.5099.95
	Důvod zamítnutí RejectionReason	Důvod, který schvalovatel uvedl při zamítnutí požadavku nebo schvalovacího kroku.
Popis Při zamítnutí požadavku schvalovatelé často uvedou důvod, ať už volným textem, nebo výběrem z předem připraveného seznamu. Tento atribut zachycuje jejich důležitou zpětnou vazbu. Údaj je základem dashboardu „Analýza míry zamítnutí požadavků“. Analýza nejčastějších důvodů zamítnutí pomáhá odhalit příčiny selhání procesu, například nesprávné účtování, nedostatečné zdůvodnění nebo problémy s rozpočtem. Na základě těchto poznatků lze lépe školit žadatele a zvýšit kvalitu prvního podání, čímž se omezí přepracování. Proč je to důležité Ukazuje, proč požadavky neprojdou schválením. Analýza příčin pomáhá omezit přepracování a zvýšit podíl požadavků schválených napoprvé. Kde data získat Informace najdete v dokumentaci SAP Ariba. Obvykle se zaznamenávají v komentářích nebo v historii spojené s událostí zamítnutí. Příklady Nesprávný účet hlavní knihyPřekročen rozpočetNedostatečné zdůvodněníDuplicitní požadavek
	Kategorie položky ItemCategory	Zařazení požadovaného zboží nebo služeb, například „IT hardware“, „Kancelářské potřeby“ nebo „Odborné služby“.
Popis Kategorie položky upřesňuje, co se nakupuje. Toto zařazení pomáhá porozumět výdajům a uplatňovat strategie a pravidla nákupu pro jednotlivé kategorie. V process mining je tento atribut důležitý pro dashboard „Analýza změn požadavků“. Může ukázat, zda se některé kategorie položek mění častěji, což může signalizovat nejasné specifikace nebo kolísání cen. Umožňuje také porovnat výkonnost procesu, například dobu schvalování, u různých typů nákupů a zjistit, zda některé kategorie narážejí na větší překážky. Proč je to důležité Umožňuje analyzovat proces podle typu nakupovaného zboží nebo služeb a odhalit úzká místa či problémy s dodržováním pravidel v konkrétních kategoriích. Kde data získat Informace najdete v dokumentaci SAP Ariba. Obvykle jsou uvedené na úrovni položky požadavku. Příklady IT hardwareKonzultační službyKancelářské potřebyMarketingové materiály
	Oddělení žadatele RequesterDepartment	Obchodní oddělení nebo nákladové středisko zaměstnance, který vytvořil požadavek na nákup.
Popis Tento atribut doplňuje organizační kontext a určuje, která část firmy požadavek zadala. Obvykle se odvozuje z profilu žadatele nebo se uvádí přímo ve formuláři požadavku. Při analýze slouží jako důležitý filtr pro porovnávání. Používá se téměř ve všech dashboardech, například v přehledu Doba schválení požadavku nebo Analýza míry zamítnutí požadavků, kde umožňuje rozdělit ukazatele podle oddělení. Díky tomu lze zjistit, která oddělení mají nejdelší dobu zpracování, nejvíce změn nebo nejvíce požadavků v rozporu s pravidly, a cíleně zlepšovat proces. Proč je to důležité Umožňuje rozdělit a porovnat výkonnost procesu v různých částech organizace a odhalit problémy nebo osvědčené postupy specifické pro jednotlivá oddělení. Kde data získat Informace najdete v dokumentaci SAP Ariba. Obvykle jsou v datech hlavičky požadavku a často odkazují na profil žadatele. Příklady MarketingProvoz ITFinanceVýzkum a vývoj
	Schvalovací cesta ApprovalWorkflowPath	Předem stanovené pořadí schvalovacích kroků, kterými má požadavek projít.
Popis Tento atribut určuje standardní variantu procesu nebo schvalovací matici, kterou má požadavek dodržet podle svých vlastností, například hodnoty, kategorie položky a oddělení. Představuje cílový proces neboli očekávaný průběh. Je základem kontroly shody a používá se v dashboardu „Přehled dodržování pravidel u požadavků“. Porovnáním skutečného pořadí činností s očekávanou schvalovací cestou mohou analytici automaticky odhalit porušení pravidel, neoprávněné schvalovací kroky nebo vynechané kontroly. To je důležité pro interní audit a řízení rizik. Proč je to důležité Určuje standardní postup a umožňuje automaticky odhalovat odchylky a porušení pravidel při kontrole shody. Kde data získat Informace najdete v dokumentaci SAP Ariba. Lze je odvodit z konfigurace schvalovací matice nebo z konkrétního pole požadavku. Příklady Standardní IT > 10 000 USDMarketingové služby < 5 000 USDKapitálové výdaje > 100 000 USD
	Stav požadavku RequisitionStatus	Aktuální stav nákupního požadavku v průběhu jeho životního cyklu.
Popis Tento atribut zachycuje aktuální stav požadavku, například „Rozpracovaný“, „Odeslaný“, „Schválený“, „Zamítnutý“ nebo „Uzavřený“. Ukazuje, v jaké fázi procesu se jednotlivé případy nacházely v okamžiku extrakce dat. Process mining rekonstruuje historický průběh procesu, tento atribut je však důležitý pro provozní sledování. Je hlavním zdrojem dat pro dashboard „Sledování aktuálního stavu požadavků“, který manažerům ukazuje aktuální objem práce a pomáhá odhalit požadavky, které se zdržely nebo čekají příliš dlouho. Poskytuje okamžitý přehled o právě zpracovávaných požadavcích, na jehož základě lze jednat. Proč je to důležité Umožňuje průběžně sledovat zpracování požadavků a včas odhalit a řešit případy, které se zdržely nebo čekají příliš dlouho. Kde data získat Podívejte se do dokumentace SAP Ariba. Jde o standardní stavové pole v hlavičce požadavku. Příklady SchválenýOdeslanýZamítnutýČeká na schválení
	Úroveň naléhavosti UrgencyLevel	Ukazatel priority požadavku, například „Běžná“, „Naléhavá“ nebo „Kritická“.
Popis Úroveň naléhavosti, často vyjádřená příznakem priority, označuje potřebu rychlejšího zpracování. Obvykle ji nastavuje žadatel, aby se naléhavým požadavkům věnovala pozornost včas. Tento atribut je základem dashboardu „Sledování naléhavých požadavků“ a KPI „Doba zpracování naléhavého požadavku“. Umožňuje přímo porovnat dobu zpracování naléhavých a běžných požadavků a ověřit, zda prioritní zpracování funguje. Analýza odchylek a zpoždění u naléhavých požadavků pomáhá zajistit kontinuitu provozu. Proč je to důležité Umožňuje zaměřit analýzu na prioritní požadavky a sledovat, zda se zpracovávají rychleji, aby byly naléhavé potřeby firmy vyřízeny včas. Kde data získat Informace najdete v dokumentaci SAP Ariba. Často jde o pole, které lze vybrat při vytváření požadavku. Příklady VysokáStředníNízká
	Uživatel, který provedl událost EventUser	ID nebo jméno uživatele, který provedl činnost, například žadatele nebo schvalovatele.
Popis Atribut Uživatel, který provedl událost, určuje osobu odpovědnou za konkrétní krok procesu. Může jít o zaměstnance, který odeslal požadavek, vedoucího, který ho schválil, nebo pracovníka nákupu, který ho zpracoval. Tento atribut je důležitý pro analýzu vytížení, porovnání výkonnosti a hledání příležitostí ke školení. Umožňuje analyzovat dobu schvalování podle uživatele a poskytuje data pro dashboard „Vytížení a výkonnost schvalovatelů“. Pomáhá také hledat příčiny zpoždění nebo odchylek tím, že je propojí s konkrétními osobami či týmy. Proč je to důležité Umožňuje analyzovat rozložení práce, výkonnost uživatelů a přidělování zdrojů. Pomáhá tak odhalit úzká místa způsobená konkrétními uživateli nebo týmy. Kde data získat Informace najdete v dokumentaci SAP Ariba. Často jsou uložené v auditních záznamech nebo tabulkách historie a propojené s kmenovými daty uživatelů. Příklady john.doejane.smithmanager123
	Byl změněn IsAmended	Logická hodnota určující, zda byl nákupní požadavek po prvním odeslání alespoň jednou změněn.
Popis Tento vypočítaný atribut označuje případy, ve kterých proběhla alespoň jedna činnost „Změna nákupního požadavku“. Usnadňuje tak označení požadavků, které bylo během jejich životního cyklu nutné upravit. Pomocí tohoto příznaku se počítá KPI „Míra změn nákupních požadavků“. Analytici mohou snadno změřit četnost opakované práce a hledat její příčiny ve vztahu k dalším atributům, například „Jméno žadatele“ nebo „Kategorie položky“. Proč je to důležité Usnadňuje výpočet KPI míry změn, pomáhá vyčíslit opakovanou práci a odhalit oblasti, kde je třeba přesněji specifikovat požadavky hned na začátku. Kde data získat Nastaví se na true, pokud případ obsahuje jednu nebo více činností „Změna nákupního požadavku“, jinak na false. Příklady truefalse
	Byla nutná opakovaná práce IsRework	Logická hodnota určující, zda se u nákupního požadavku opakovala práce, například kvůli zamítnutí nebo několika změnám.
Popis Tento vypočítaný atribut zachycuje širší okruh neefektivity než atribut „Byl změněn“. Označuje případy s výrazným opakováním práce, které se obvykle definuje jako jedna nebo více událostí „Krok schválení zamítnut“ nebo několik událostí „Změna nákupního požadavku“. Příznak slouží k výpočtu KPI „Míra opakované práce u nákupních požadavků“. Pomáhá vyčíslit skryté náklady a prodlevy spojené se selháním procesu. Analýza takto označených případů může odhalit souvislosti s konkrétními schvalovateli, odděleními nebo typy požadavků, které průběh procesu komplikují. Proč je to důležité Označuje případy, u kterých proces provázely výrazné komplikace, například zamítnutí. Můžete se tak zaměřit na příčiny neefektivity a prodlev. Kde data získat Nastaví se na true, pokud případ obsahuje zamítnutí nebo více než jednu změnu požadavku. Příklady truefalse
	ID nákupní objednávky PurchaseOrderId	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ím dokumentem, nákupní objednávkou (PO). Jeho přítomnost potvrzuje, že se požadavek úspěšně změnil v objednávku. Je nezbytný pro analýzu celého procesu, která pokračuje i po fázi požadavku. Pomocí tohoto atributu se vypočítává KPI „Doba od požadavku k nákupní objednávce“, který propojuje událost vytvoření požadavku s událostí vytvoření nákupní objednávky. Díky tomu získáte ucelený přehled o počáteční fázi nákupního cyklu. Proč je to důležité Propojuje požadavek s navazující nákupní objednávkou a umožňuje měřit dobu celého cyklu od požadavku po objednávku. Kde data získat Podívejte se do dokumentace SAP Ariba. Tyto údaje se obvykle ukládají do datových položek požadavku po vytvoření nákupní objednávky. Příklady PO-4500012345PO-4500012346PO-4500012347
	Je automatizovaná IsAutomated	Logická hodnota určující, zda činnost provedl systém, nebo uživatel.
Popis Tento atribut rozlišuje automatické systémové události, například automatická schválení nebo systémové změny stavu, od ručních činností provedených uživateli. Pomáhá tak určit míru automatizace procesu. Při analýze umožňuje přesněji měřit práci uživatelů a hledat další možnosti automatizace. Filtrováním ručních činností například získáte přesnější dobu zpracování z pohledu uživatele. Atribut také pomáhá ověřit, zda automatická pravidla v procesu fungují podle očekávání. Proč je to důležité Rozlišuje činnosti uživatelů od činností systému. To je důležité pro měření míry automatizace i hledání dalších příležitostí k automatizaci. Kde data získat Obvykle se určuje podle toho, zda ID uživatele v poli „Uživatel události“ odpovídá systémovému nebo dávkovému účtu. Příklady truefalse
	Jméno schvalovatele ApproverName	Jméno uživatele, který má ve workflow schválit konkrétní krok.
Popis Tento atribut označuje konkrétního manažera nebo jiného pracovníka odpovědného za schválení. Na rozdíl od obecného atributu „Uživatel události“ se vztahuje přímo ke schvalovacím úkolům. Je důležitý pro dashboard „Vytížení a výkonnost schvalovatelů“. Umožňuje sledovat počet požadavků zpracovaných jednotlivými schvalovateli i jejich průměrnou dobu schválení. Díky tomu můžete odhalit úzká místa u jednotlivých schvalovatelů, vyrovnat jejich pracovní vytížení a porovnat výsledky se stanovenými cíli. Proč je to důležité Určuje osobu odpovědnou za schválení a umožňuje podrobně analyzovat její vytížení a výkonnost i lépe rozdělit práci mezi schvalovatele. Kde data získat Podívejte se do dokumentace SAP Ariba. Tyto údaje jsou uložené v datech schvalovacího workflow propojených s požadavkem. Příklady Sarah JonesDavid ChenMaria Garcia
	Jméno žadatele RequesterName	Jméno zaměstnance, který zadal nákupní požadavek.
Popis Tento atribut na úrovni případu označuje osobu, která nákupní požadavek vytvořila. Poskytuje kontext o původu požadavku a o konkrétním žadateli. Při analýze můžete podle tohoto atributu filtrovat proces a sledovat chování jednotlivých žadatelů. Dashboardy „Analýza změn nákupních požadavků“ a „Analýza míry zamítnutí nákupních požadavků“ jej například využívají k odhalení osob, které mohou potřebovat další školení kvůli častým změnám nebo zamítnutím požadavků. Pomáhá také lépe zacílit zpětnou vazbu a opatření ke zlepšení. Proč je to důležité Označuje osobu, která požadavek vytvořila, a umožňuje analyzovat průběh a kvalitu procesu podle jednotlivých žadatelů. Kde data získat Podívejte se do dokumentace SAP Ariba. Jde o standardní pole v hlavičce požadavku, obvykle označené jako „Vytvořil“ nebo „Žadatel“. Příklady Alice WilliamsBob MillerCharles Brown
	Poslední aktualizace dat LastDataUpdate	Časové razítko označující, kdy byla data tohoto záznamu naposledy obnovena ze zdrojového systému.
Popis Tento atribut uvádí datum a čas poslední extrakce nebo aktualizace dat pro danou událost. Ukazuje, jak aktuální jsou analyzovaná data, což je důležité zejména při sledování probíhajících procesů. Analytici podle něj zjišťují, jak aktuální jsou získané poznatky. U dashboardů, jako je „Sledování aktuálního stavu požadavků“, je tento údaj zásadní, protože uživatelům ukazuje, jak čerstvé jsou zobrazené informace. Pomáhá tak nastavit realistická očekávání ohledně aktuálnosti dat. Proč je to důležité Ukazuje aktuálnost dat, která je důležitá pro posouzení včasnosti a relevance poznatků z process mining. Kde data získat Toto časové razítko se obvykle vytvoří a přidá ke každému záznamu při načítání dat. Příklady 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého byla data získána.
Popis Tento atribut určuje původ procesních dat. V tomto přehledu bude jeho hodnota vždy „SAP Ariba“. Pokud se však data slučují z více systémů, je pole důležité pro sledování původu dat a řešení problémů. Při analýze pomáhá ověřit původ dat a filtrovat nebo porovnávat procesy probíhající v různých systémech. Zajišťuje přehled o zdroji dat a důvěru v něj, což je důležité pro podporu ze strany zainteresovaných osob. Proč je to důležité Určuje původ dat, což je důležité pro správu dat, řešení problémů a správné pochopení kontextu analýzy. Kde data získat Obvykle jde o neměnnou hodnotu, která se přidává při extrakci a transformaci dat a označuje jejich původ. Příklady SAP AribaSAP_ARIBA_P2PAribaCloud

Povinné Doporučené Volitelné

Činnosti procesu Purchase to Pay: nákupní požadavek

Důležité kroky a milníky, které je třeba zaznamenat pro přesné odhalení průběhu procesu a jeho úzkých míst.

6 Doporučené 7 Volitelné

	Aktivita	Popis
	Objednávka vytvořena	Označuje úspěšné převedení schváleného požadavku na nákup na objednávku. Událost se zaznamená vytvořením dokumentu objednávky, který odkazuje na požadavek.
Proč je to důležité Jde o hlavní úspěšný výsledek procesu zadávání požadavku. Událost je nezbytná pro měření KPI „Doba od požadavku po objednávku“ od začátku do konce. Kde data získat Jde o konkrétní událost. Použije se časové razítko vytvoření dokumentu objednávky, který obsahuje přímý odkaz nebo referenci na zdrojové Purchase Requisition ID. Zachycení V tabulce hlaviček objednávek vyhledejte objednávku propojenou s požadavkem a použijte její časové razítko vytvoření. Typ události explicit
	Požadavek odeslán	Zaznamenává, že žadatel formálně odeslal požadavek na nákup do schvalovacího workflow. Událost odpovídá změně stavu z „Composing“ na „Submitted“.
Proč je to důležité Tento důležitý milník spouští schvalovací proces. Je nezbytný pro výpočet ukazatelů „Doba schválení požadavku“ a „Doba od vytvoření do odeslání požadavku“. Kde data získat Událost lze odvodit z historie dokumentu nebo auditního protokolu Ariba, kde je zaznamenána změna stavu požadavku na „Submitted“ i její časové razítko. Zachycení Zjistěte časové razítko první změny pole stavu požadavku na „Submitted“. Typ události inferred
	Požadavek schválen	Označuje konečné schválení požadavku na nákup po úspěšném dokončení všech kroků workflow. Zaznamená se změnou stavu na „Approved“.
Proč je to důležité Tento důležitý milník označuje konec schvalovací fáze. Slouží jako koncový bod pro měření „Průměrné doby schválení požadavku“ a signalizuje, že lze vytvořit objednávku. Kde data získat Událost lze odvodit z historie dokumentu Ariba, kde je zaznamenána konečná změna stavu požadavku na „Approved“. Zachycení Zjistěte časové razítko změny pole stavu požadavku na „Approved“. Typ události inferred
	Požadavek uzavřen	Zaznamenává konečné administrativní uzavření požadavku na nákup po dokončení všech souvisejících úkonů, například objednání a převzetí. Událost se zachytí konečnou změnou stavu na „Closed“.
Proč je to důležité Označuje definitivní konec celého životního cyklu požadavku. Analýza doby od vytvoření objednávky do uzavření může odhalit úzká místa při následném příjmu zboží nebo fakturaci. Kde data získat Událost lze odvodit z historie dokumentu Ariba, kde je zaznamenána změna stavu požadavku na „Closed“. Zachycení Zjistěte časové razítko změny pole stavu požadavku na „Closed“. Typ události inferred
	Požadavek vytvořen	Zaznamenává okamžik, kdy uživatel vytvoří dokument požadavku na nákup. Událost nastane při prvním uložení požadavku ve stavu „Composing“ nebo jako koncept.
Proč je to důležité Tímto krokem začíná životní cyklus požadavku. Analýza doby od vytvoření do odeslání pomáhá měřit efektivitu uživatelů a odhalit potřebu školení. Kde data získat Vychází z časového razítka vytvoření objektu požadavku na nákup v SAP Ariba. Najdete ho v hlavičce dokumentu požadavku a označuje konkrétní událost vytvoření. Zachycení Použijte časové razítko „CreateTime“ nebo odpovídající údaj z tabulky hlavičky dokumentu požadavku. Typ události explicit
	Požadavek zamítnut	Označuje konečné zamítnutí požadavku na nákup po posouzení. Jde o koncový stav procesu, který se zaznamená změnou stavu na „Denied“.
Proč je to důležité Jde o důležitý neúspěšný konec procesu. Analýza zamítnutých požadavků je nezbytná pro KPI „Míra zamítnutí požadavků“, protože pomáhá odhalit opakující se příčiny a zlepšit kvalitu žádostí. Kde data získat Událost lze odvodit z historie dokumentu Ariba, kde je zaznamenána konečná změna stavu požadavku na „Denied“. Zachycení Zjistěte časové razítko změny pole stavu požadavku na „Denied“. Typ události inferred
	Krok schválen	Označuje kladný výsledek schvalovacího kroku, kdy schvalovatel schválil svou část požadavku. Událost se zaznamenává jako schvalovací akce.
Proč je to důležité Měří dobu zpracování u jednotlivých schvalovatelů. Tyto údaje jsou důležité pro výpočet „Průměrné doby schvalovacího kroku“ a posouzení vytížení schvalovatelů. Kde data získat Vychází z tabulek schvalovacího workflow v Ariba. Událost se zaznamená s časovým razítkem, když schvalovatel u přiřazené úlohy zvolí akci „Approve“. Zachycení Použijte časové razítko akce „Approve“ zaznamenané v historii konkrétního schvalovacího kroku. Typ události explicit
	Krok zamítnut	Označuje záporný výsledek schvalovacího kroku, kdy schvalovatel požadavek zamítne, obvykle s požadavkem na úpravu. Událost se zaznamenává jako akce „Deny“.
Proč je to důležité Událost upozorňuje na významný zdroj přepracování a zpoždění. Její analýza pomáhá porozumět „Míře přepracování požadavků“ a důvodům zamítnutí. Kde data získat Vychází z tabulek schvalovacího workflow v Ariba. Událost se zaznamená s časovým razítkem, když schvalovatel u přiřazené úlohy zvolí akci „Deny“ nebo „Reject“. Zachycení Použijte časové razítko akce „Deny“ zaznamenané v historii konkrétního schvalovacího kroku. Typ události explicit
	Položka požadavku objednána	Označuje změnu stavu jednotlivé položky požadavku na „Ordered“ poté, co byla zařazena do objednávky. Umožňuje podrobnější sledování než samotné vytvoření objednávky na úrovni hlavičky.
Proč je to důležité Umožňuje analyzovat částečné objednání nebo zpoždění na úrovni položek, které při pohledu pouze na hlavičku nejsou vidět. Hodí se u požadavků s mnoha položkami, které se plní prostřednictvím různých objednávek. Kde data získat Událost lze odvodit ze změny stavu objektu položky požadavku. Jakmile je pro položku vytvořena objednávka, její stav se změní na „Ordered“. Zachycení Zjistěte časové razítko změny pole stavu položky požadavku na „Ordered“. Typ události inferred
	Požadavek předán do výběrového řízení	K této události dochází, když je schválený požadavek předán oddělení nákupu k zahájení výběrového řízení, například RFQ, před vytvořením objednávky. Zaznamená se změnou stavu, například na „Sourcing“.
Proč je to důležité Označuje důležitou větev procesu u položek s vysokou hodnotou nebo nestandardních položek. Pomáhá analyzovat, jak dlouho výběrové řízení přispívá k celkové době zpracování. Kde data získat Událost lze odvodit ze změny stavu požadavku na hodnotu, která označuje předání do výběrového řízení. Běžné je to v Ariba Buying integrovaném s Ariba Sourcing. Zachycení Zjistěte časové razítko změny pole stavu požadavku na „Sourcing“ nebo na podobný vlastní stav. Typ události inferred
	Požadavek stažen	K této události dochází, když původní žadatel zruší odeslaný požadavek na nákup dříve, než je plně schválen. Zaznamená se změnou stavu na „Withdrawn“ nebo „Canceled“.
Proč je to důležité Označuje ukončení procesu z podnětu uživatele. Analýza důvodů stažení požadavků může odhalit změny obchodních potřeb nebo příliš dlouhé schvalování. Kde data získat Událost lze odvodit z historie dokumentu nebo auditního protokolu Ariba, kde je zaznamenána změna stavu požadavku na „Withdrawn“. Zachycení Zjistěte časové razítko změny pole stavu požadavku na „Withdrawn“. Typ události inferred
	Požadavek upraven	K této události dochází, když uživatel po odeslání změní požadavek na nákup, často v reakci na zamítnutí nebo dotaz. Zaznamená se při úpravě a opětovném odeslání dokumentu.
Proč je to důležité Událost zachycuje přepracování a neefektivitu procesu. Časté změny mohou ukazovat na nejasné původní požadavky nebo pravidla a ovlivňují KPI „Míra změn požadavků“. Kde data získat Událost lze odvodit z údajů o verzích v Ariba. Každá změna vytvoří novou verzi dokumentu požadavku. Verze vyšší než 1 označuje změnu. Zachycení Vyhledejte nové verze požadavku vytvořené po prvním stavu „Submitted“. Časové razítko nové verze představuje čas události. Typ události inferred
	Zahájeno schvalování	Označuje, že požadavek na nákup byl předán schvalovateli nebo do schvalovací fronty a čeká na vyřízení. Událost nastane při vytvoření a přiřazení žádosti o schválení.
Proč je to důležité Poskytuje podrobný přehled o schvalovacím workflow. Je nezbytná pro výpočet čekání ve frontě a určení konkrétních kroků, které představují úzká místa při analýze úzkých míst ve schvalovací cestě. Kde data získat Vychází z tabulek schvalovacího workflow v Ariba, které zaznamenávají vytvoření a přiřazení jednotlivých schvalovacích úloh propojených s požadavkem. Zachycení Použijte časové razítko vytvoření záznamu žádosti o schválení, který je propojen s požadavkem a konkrétním schvalovacím krokem. Typ události explicit

Doporučené Volitelné

Návody na extrakci dat

Jak získat data ze SAP Ariba

Kroky

Přihlaste se do SAP Ariba: Přihlaste se do svého prostředí SAP Ariba pomocí účtu s oprávněním vytvářet a spouštět analytické reporty, například s rolí „Reporting Analyst“.
Přejděte do analytických reportů: V hlavním dashboardu otevřete část určenou pro reportování. Obvykle ji najdete v nabídce „Reporting“, „Analytics“ nebo „Manage“ > „Analytical Reports“.
Vytvořte nový report: Spusťte vytvoření analytického reportu. Zobrazí se výzva k výběru hlavní datové oblasti, často označované jako „Fact“. Vyberte oblast týkající se nákupních požadavků, například „[Requisition]“ nebo podobnou možnost dostupnou ve vaší konfiguraci Ariba.
Přidejte datová pole: V nástroji pro tvorbu reportů přidejte sloupce. Pro získání všech potřebných informací bude nutné spojit více zdrojů dat (Facts). Typický report propojí „[Requisition Fact]“, „[Approval History Fact]“ a „[Purchase Order Fact]“ pomocí ID požadavku. Přidejte všechna pole uvedená v konfiguraci dotazu, včetně příslušných časových údajů, například Created Date, Submitted Date, Approved Date a Action Date z historie schvalování.
Nastavte filtry: Omezte rozsah dat pomocí filtrů. Nejdůležitější je časové období. Nastavte filtr „Requisition Created Date“ na požadované období, například poslední 3 až 6 měsíců. Podle potřeby přidejte další filtry, například pro konkrétní kódy společností nebo prostředí.
Spusťte report a exportujte nezpracovaná data: Spusťte report. Po dokončení exportujte výsledky do souboru CSV nebo Excel. První export bude v širokém formátu, kde každý řádek představuje jeden požadavek nebo schvalovací záznam a mnoho sloupců obsahuje různá data a činnosti uživatelů.
Převeďte data do formátu záznamu událostí: Tento krok proveďte mimo SAP Ariba. Pomocí nástroje, jako je Microsoft Excel s Power Query, skriptu v Pythonu nebo jiného nástroje pro přípravu dat, převeďte široký formát na dlouhý. Pro každý exportovaný sloupec s časovým údajem, například „Created Date“, „Submitted Date“ nebo „Approved Date“, vytvořte v konečném záznamu událostí samostatný řádek. Tento postup se označuje jako „unpivoting“ nebo „melting“.
Přiřaďte činnosti a atributy: Během transformace vytvořte sloupce ActivityName a EventTimestamp. Při zpracování sloupce „Submitted Date“ například vytvořte řádky, ve kterých bude ActivityName obsahovat „Odeslání nákupního požadavku“ a EventTimestamp hodnotu ze sloupce „Submitted Date“.
Spojte a vyčistěte data: Spojte data převedená ze všech sloupců s časovými údaji do jednoho souboru. Ověřte, že jsou ve všech řádcích správně vyplněné sloupce PurchaseRequisitionId, ActivityName a EventTimestamp. Odstraňte prázdné řádky a opravte případné problémy s formátováním.
Uložte výsledný soubor CSV: Uložte konečný záznam událostí jako soubor CSV s kódováním UTF-8. Soubor je nyní připravený k nahrání do nástroje process mining.

Konfigurace

Typ reportu: analytický report vytvořený ve standardním rozhraní pro reportování Ariba.
Základní datové oblasti: Budete muset spojit data z více oblastí, obvykle „[Requisition Fact]“, „[Approval History Fact]“ a „[Purchase Order Fact]“. Přesné názvy se mohou lišit podle datového modelu Ariba.
Časové období: Doporučujeme filtrovat podle „Requisition Created Date“ a zvolit přiměřené období, například 3 až 6 měsíců. Při prvním testu použijte kratší období, třeba jeden týden.
Důležité filtry: Vždy nastavte konkrétní časové období. Zvažte také filtr podle „Company Code“ nebo „Purchasing Organization“, abyste omezili data na příslušnou část provozu a zrychlili zpracování reportu.
Předpoklady: Uživatel spouštějící report musí mít roli s oprávněním k modulu Analytical Reporting a k podkladovým datovým oblastem pro požadavky, schválení a nákupní objednávky.

Ukázkový dotaz config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

Kroky

Připravte prostředí Python: Nainstalujte Python verze 3.6 nebo novější. Potřebné knihovny nainstalujte pomocí pip: pip install requests pandas.
Nastavte přístup k API: Na portálu SAP Ariba Developer Portal zaregistrujte novou aplikaci. Přihlaste se k odběru služby Operational Reporting API for Requisitions a získejte přihlašovací údaje OAuth: Application Key (API Key), OAuth Client Secret a řetězec zakódovaný v Base64 ve formátu [your_api_key]:[your_client_secret].
Upravte skript Python: Otevřete dodaný skript Python. Vyplňte zástupné proměnné v horní části, včetně ARIBA_REALM, BASE_URL, API_KEY a BASE64_CREDS. Nastavte také START_DATE a END_DATE pro období, ze kterého chcete data získat.
Definujte obsah sestavy: Zkontrolujte objekt JSON report_payload ve skriptu. Určuje sestavu, která se spustí. Skript je přednastavený na použití RequisitionFactSystemView a výběr polí potřebných pro požadované aktivity a atributy. Podle potřeby můžete přidat další pole nebo filtry.
Spusťte skript: Spusťte skript v terminálu příkazem python your_script_name.py. Nejprve se skript ověří v systému Ariba a získá přístupový token.
Odešlete požadavek na sestavu a sledujte jeho stav: Skript automaticky odešle požadavek na sestavu do API Ariba. Protože úloha probíhá asynchronně, skript bude každých 60 sekund kontrolovat její stav prostřednictvím API Ariba.
Stáhněte data sestavy: Jakmile API Ariba oznámí stav úlohy COMPLETED, skript stáhne výsledná data. Obvykle jde o soubor ZIP obsahující jeden soubor CSV.
Zpracujte a transformujte data: Skript rozbalí soubor a načte surová data do objektu pandas DataFrame. Poté převede data ze širokého formátu, kde je jeden řádek pro každou žádanku a mnoho sloupců s daty, do dlouhého formátu záznamu událostí. Ten obsahuje více řádků pro každou žádanku, jeden pro každou aktivitu.
Vytvořte záznam událostí: Transformovaný DataFrame má nyní podobu záznamu událostí se sloupci, jako jsou PurchaseRequisitionId, ActivityName a EventTimestamp. Uložte jej jako ariba_requisition_event_log.csv do stejné složky, ve které je skript.
Připravte data k nahrání: Vytvořený soubor CSV je připravený k nahrání do ProcessMind. Zkontrolujte, zda názvy sloupců odpovídají mapování nastavenému v projektu ProcessMind.

Konfigurace

URL koncového bodu API: Skript potřebuje základní URL API vaší instance Ariba. Obvykle má formát https://[your-realm].api.ariba.com/api/operationalreporting/v2/. Nahraďte [your-realm] názvem prostředí Ariba vaší společnosti.
Ověření přístupu: Extrakce používá ověřování OAuth 2.0. Z aplikace zaregistrované na portálu Ariba Developer Portal musíte získat platné apiKey, clientSecret a řetězec base64EncodedCredentials.
Šablona pohledu: Skript používá RequisitionFactSystemView. Jde o standardní pohled Ariba. Ověřte, že je ve vašem prostředí povolený a že k němu má uživatel API potřebná oprávnění.
Filtr časového období: Filtr creationDate v obsahu reportu určuje objem dat. Při první extrakci doporučujeme zvolit období 3 až 6 měsíců. Ve velkých organizacích zvažte extrakci po menších měsíčních dávkách.
Přírůstkové načítání: Při dalších extrakcích upravte START_DATE a END_DATE tak, aby se načetly pouze nové nebo změněné záznamy. Skript přírůstkové načítání neřídí automaticky, proto je třeba nastavit časové období před každým spuštěním.
Předpoklady: K vytvoření aplikace a přihlašovacích údajů potřebujete uživatelský účet SAP Ariba s oprávněním „Developer Portal Access“. Samotná aplikace API musí mít roli „Operational Reporting API User“, aby mohla spouštět úlohy reportů.

Ukázkový dotaz python

import requests
import json
import pandas as pd
import time
import zipfile
import io

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

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

Chcete začít?

Použijte tuto šablonu k přípravě dat a získejte přehled o procesu Purchase to Pay: nákupní požadavek. Začněte zlepšovat provoz ještě dnes.

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

Stáhnout šablonu

Zkraťte prodlevy a zlepšete proces nákupních požadavků v Purchase to Pay

Odhalte neefektivní místa v SAP Ariba a zkraťte dobu cyklu o 30 %.

Začněte používat zkušební verzi

Platební kartu nepotřebujete. Nastavení je rychlé a snadné.

Šablona dat pro Purchase to Pay: nákupní požadavek

Šablona dat pro Purchase to Pay: nákupní požadavek

Atributy procesu Purchase to Pay: nákupní požadavek

Činnosti procesu Purchase to Pay: nákupní požadavek

Návody na extrakci dat

Export CSV/Excel z analytických reportů SAP Ariba

Kroky

Konfigurace

Ukázkový dotaz config

Extrakce pomocí skriptu v Pythonu přes Operational Reporting API

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Zkraťte prodlevy a zlepšete proces nákupních požadavků v Purchase to Pay