> Průběžné zlepšování procesů > Purchase to Pay, nákupní požadavek > Coupa > Datová šablona

Šablona dat pro proces nákupu a platby, od požadavku po úhradu

Coupa

Atributy procesu nákupu a platby, od požadavku po úhradu(21) Aktivity procesu nákupu a platby, od požadavku po úhradu(12) Návody k extrakci dat(3)

Šablona dat pro proces nákupu a platby, od požadavku po úhradu

Tato datová šablona nabízí strukturu pro sběr informací potřebných k analýze procesu nákupu a platby, konkrétně zpracování požadavků. Uvádí atributy a aktivity, které má obsahovat kvalitní záznam událostí. Najdete v ní také návod, jak data efektivně získat ze systému Coupa.

Doporučené atributy pro podrobnou analýzu
Hlavní aktivity procesu, které je vhodné sledovat
Praktický návod k extrakci dat

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 a platby, od požadavku po úhradu

Tato doporučená datová pole zahrňte do záznamu událostí, abyste mohli podrobně analyzovat proces nákupu a platby, konkrétně zpracování požadavků.

5 Povinné 5 Doporučené 11 Volitelné

	Název	Popis
	Čas události EventTime	Přesné datum a čas, kdy k aktivitě došlo.
Popis Čas události neboli časové razítko zachycuje přesný okamžik, kdy byla zaznamenána aktivita týkající se požadavku na nákup. Tyto údaje jsou nezbytné pro chronologické seřazení událostí a sestavení průběhu procesu. Slouží jako základ všech časových analýz, například výpočtu doby zpracování, hledání úzkých míst měřením doby mezi aktivitami a sledování výkonnosti procesu v různých obdobích. Pro smysluplnou analýzu procesu jsou důležitá přesná a podrobná časová razítka. Proč je to důležité Časové razítko je nezbytné pro správné seřazení událostí a výpočet všech časových ukazatelů, například doby zpracování a úzkých míst. Kde data získat Tyto údaje se zaznamenávají v auditním záznamu nebo historii každého požadavku v Coupa, často v poli „created_at“ nebo „updated_at“ u jednotlivých akcí. Příklady 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	ID požadavku na nákup PurchaseRequisitionId	Jedinečný identifikátor každého požadavku na nákup, který slouží jako hlavní ID případu v procesu.
Popis ID požadavku na nákup je hlavní identifikátor, který propojuje všechny aktivity související s jedním požadavkem na zboží nebo služby. Každý požadavek dostane při vytvoření jedinečné ID, které zůstává stejné po celou dobu jeho životního cyklu. Díky tomu lze požadavek sledovat od vytvoření a odeslání přes všechny kroky schválení či zamítnutí až po předání do výběrového řízení a uzavření. V process mining se k tomuto ID přiřazuje každá položka záznamu událostí, což umožňuje rekonstruovat celý průběh každého případu. Proč je to důležité Jde o hlavní ID případu, které propojuje všechny kroky procesu a umožňuje analyzovat celý životní cyklus požadavku od začátku do konce. Kde data získat Toto pole primárního klíče se nachází v modulu Requisitions systému Coupa a v souvisejících exportech dat. Příklady PR-102934PR-102935PR-102936
	Název aktivity ActivityName	Název konkrétní obchodní aktivity nebo události, která se v daném okamžiku týkala požadavku.
Popis Tento atribut zaznamenává jednotlivé kroky životního cyklu požadavku na nákup. Patří mezi ně například „Požadavek vytvořen“, „Schvalovací krok schválen“ nebo „Požadavek předán do výběrového řízení“. Každá aktivita představuje konkrétní milník nebo úkon týkající se požadavku. Analýza pořadí a četnosti těchto aktivit je základem process mining. Umožňuje zobrazit mapy procesů, určit obvyklé průběhy a odhalit odchylky od standardního postupu. Proč je to důležité Určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat průběh požadavků. Kde data získat Obvykle se získává ze záznamů událostí, záznamů změn stavu nebo auditních záznamů v systému Coupa. Může být nutné namapovat pole se stavem nebo kódy akcí. Příklady Vytvoření požadavkuOdeslání požadavkuSchválení schvalovacího krokuPožadavek zamítnutObjednávka vytvořena
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat ze zdrojového systému.
Popis Tento atribut zaznamenává datum a čas poslední extrakce dat ze systému Coupa. Ukazuje, jak aktuální jsou analyzovaná data. Uživatelé tak mohou posoudit, zda poznatky odpovídají současnému provozu, nebo zachycují dřívější stav. To je důležité zejména u dashboardů, které sledují probíhající provoz. Proč je to důležité Informuje uživatele o aktuálnosti dat, aby věděli, jakého období se analýza týká, a mohli se rozhodovat na základě aktuálních informací. Kde data získat Toto časové razítko vytvoří a přidá datový tok nebo nástroj ETL po úspěšném dokončení extrakce dat. Příklady 2024-05-21T02:00:00Z
	Zdrojový systém SourceSystem	Určuje zdrojový systém, ze kterého byla data získána.
Popis Tento atribut označuje systém, ve kterém původně vznikla procesní data. V této analýze bude jeho hodnota vždy „Coupa“. Zahrnutí tohoto pole je vhodným postupem zejména v prostředích, kde se slučují data z více systémů. Poskytuje důležitý kontext o původu dat a pomáhá spravovat pravidla pro správu a kvalitu dat. Proč je to důležité Zajišťuje přehled o původu dat, který je důležitý pro jejich správu i při slučování dat z více podnikových systémů. Kde data získat Obvykle jde o neměnnou hodnotu, která se přidává během extrakce a transformace dat, aby označila jejich původ. Příklady Coupa
	Celková částka TotalAmount	Celková peněžní hodnota požadavku na nákup.
Popis Tento atribut představuje celkové náklady na zboží a služby uvedené v požadavku. Částka je pro analýzu procesu důležitá, protože často ovlivňuje složitost schvalovacího workflow. U požadavků na vyšší částky bývá obvykle potřeba více schvalovacích kroků. Analýza ukazatelů podle výše částky, například <1 000 USD nebo 1 000 až 10 000 USD, může ukázat, jak se proces liší podle finanční hodnoty požadavku. Proč je to důležité Pomáhá analyzovat rozdíly v procesu podle hodnoty požadavku, protože vyšší částky často vyžadují složitější schvalovací workflow. Kde data získat Jde o standardní pole v hlavičce objektu Requisition v Coupa, obvykle pojmenované „total“ nebo „total_amount“. Příklady 500.0012550.7599.99
	Oddělení Department	Obchodní oddělení nebo nákladové středisko, na které se požadavek účtuje.
Popis Atribut Oddělení propojuje každý požadavek s konkrétní organizační jednotkou nebo nákladovým střediskem. Umožňuje srovnávat jednotlivé části organizace. Dashboardy a KPI lze filtrovat podle oddělení a porovnávat dobu schvalování, míru zamítnutí a shodu. Díky tomu lze odhalit problémy nebo osvědčené postupy v konkrétních odděleních. Proč je to důležité Umožňuje porovnávat KPI procesu, například dobu zpracování a míru zamítnutí, mezi různými obchodními jednotkami a odhalit oblasti pro zlepšení. Kde data získat Jde o standardní pole objektu Requisition v Coupa. Často je propojené s profilem žadatele nebo uvedené na řádcích požadavku. Příklady MarketingProvoz ITSpráva budovVýzkum a vývoj
	Schvalovatel Approver	Uživatel nebo skupina odpovědná za schvalovací aktivitu.
Popis Tento atribut označuje konkrétní osobu nebo schvalovací skupinu přiřazenou ke schvalovacímu kroku. Vyplňuje se u aktivit, jako jsou „Schvalovací krok zahájen“, „Schvalovací krok schválen“ a „Schvalovací krok zamítnut“. Analýza podle schvalovatele je důležitá pro vytvoření dashboardu „Výkonnost a vytížení schvalovatelů“. Pomáhá měřit dobu schvalování jednotlivců, odhalovat úzká místa způsobená konkrétními schvalovateli a vyhodnocovat rozložení práce. Proč je to důležité Pomáhá analyzovat výkonnost schvalovatelů a rozložení jejich práce a odhalit úzká místa spojená s konkrétními osobami nebo schvalovacími skupinami. Kde data získat Tyto údaje najdete v podrobnostech schvalovacího řetězce přiřazeného ke každému požadavku v Coupa. Může být nutné propojit je s údaji o uživatelích. Příklady David MillerSchvalovatelé z finančního oddělení, úroveň 2Susan Chen
	Stav požadavku RequisitionStatus	Aktuální nebo konečný stav požadavku na nákup.
Popis Tento atribut označuje celkový stav požadavku v okamžiku extrakce dat nebo jeho konečný výsledek. Mezi běžné stavy patří „Čeká na schválení“, „Schválen“, „Zamítnut“, „Stažen“ a „Uzavřen“. Jde o důležitý rozměr pro filtrování a analýzu. Používá se k výpočtu míry schválení a zamítnutí, sledování aktuálního počtu otevřených požadavků a zjištění konečného výsledku žádostí. Proč je to důležité Pomáhá porozumět výsledkům požadavků, vypočítat míru schválení a zamítnutí a sledovat aktuální stav požadavků, které se právě zpracovávají. Kde data získat Jde o standardní pole objektu Purchase Requisition v systému Coupa, obvykle pojmenované „status“ nebo „state“. Příklady Čeká na schváleníSchválenoZamítnutoStaženoUzavřeno
	Žadatel Requester	Zaměstnanec, který vytvořil a odeslal požadavek na nákup.
Popis Tento atribut označuje osobu, která požadavek zadala. Analýza podle žadatele pomáhá odhalit vzorce spojené s konkrétními uživateli, například časté úpravy nebo zamítnutí, které mohou ukazovat na potřebu dalšího školení. Umožňuje také analyzovat počet požadavků a chování v procesu u různých uživatelů nebo skupin uživatelů. Proč je to důležité Umožňuje analyzovat chování v procesu podle uživatele, určit potřebu školení a zjistit, jak s procesem pracují různí lidé. Kde data získat V Coupa je k dispozici jako standardní pole objektu Requisition. Často je propojené s objektem User a pojmenované „requester“ nebo „created_by“. Příklady Alice JohnsonBob SmithCharlie Brown
	Byl upraven IsAmended	Logická hodnota, která je pravdivá, pokud byl požadavek po prvním odeslání alespoň jednou upraven.
Popis Tento vypočítaný atribut je jednoduchý příznak (pravda/nepravda), který označuje, zda u daného případu došlo k aktivitě „Požadavek upraven“. Usnadňuje analýzu a filtrování, protože umožňuje snadno vybrat požadavky, které bylo nutné změnit. Používá se k výpočtu KPI míry úprav požadavků a k naplnění dashboardu „Počet upravených požadavků“. Pomáhá tak odhalit příčiny přepracování a zlepšit kvalitu napoprvé. Proč je to důležité Usnadňuje výpočet KPI míry změn a umožňuje snadno rozdělit případy podle toho, zda vyžadovaly přepracování. Kde data získat Tato hodnota se vypočítá v nástroji process mining tak, že se v záznamu událostí každého případu ověří, zda obsahuje aktivitu „Požadavek upraven“. Příklady truefalse
	Cesta schvalovacího workflow ApprovalWorkflowPath	Identifikátor konkrétního schvalovacího řetězce nebo šablony workflow použité pro požadavek.
Popis Tento atribut označuje předem určené pořadí schvalovatelů, kterým má požadavek projít. Určují ho obchodní pravidla, často podle částky, oddělení a typu požadavku. Analýza tohoto atributu je základem dashboardu „Shoda požadavků s pravidly“. Porovnáním skutečného pořadí schvalovatelů s přiřazenou cestou workflow lze odhalit odchylky, měřit míru shody a identifikovat výjimky, které nejsou pod kontrolou. Proč je to důležité Umožňuje analyzovat shodu porovnáním očekávaných a skutečných schvalovacích kroků a odhalit odchylky v procesu. Kde data získat Podrobnosti najdete v dokumentaci Coupa. Tento údaj lze odvodit z názvu schvalovacího řetězce nebo pravidla workflow, které se pro požadavek použilo. Příklady Standardní schválení do 5 000 USDSchválení hardwaru IT nad 10 000 USDKontrola kapitálových výdajů finančním ředitelem
	Doba trvání schvalovacího kroku ApprovalStepDuration	Doba, po kterou požadavek čekal v jednom schvalovacím kroku.
Popis Tato vypočítaná metrika měří dobu mezi aktivitami „Schvalovací krok zahájen“ a odpovídající aktivitou „Schvalovací krok schválen“ nebo „Schvalovací krok zamítnut“. Zachycuje dobu čekání v každé jednotlivé fázi schvalovacího řetězce. Je důležitá pro dashboard „Úzká místa ve schvalovacích krocích“, protože přesně ukazuje, kteří schvalovatelé nebo které fáze způsobují největší zpoždění v celém procesu. Proč je to důležité Odhalí konkrétní úzká místa ve schvalovacím workflow. Měří dobu čekání v každém kroku, nikoli pouze celkovou dobu průchodu. Kde data získat V nástroji process mining se vypočítá jako časový rozdíl mezi událostí „Zahájení schvalovacího kroku“ a následující závěrečnou schvalovací událostí („Schváleno“ nebo „Zamítnuto“). Příklady 1,2 dne4 hodiny3,8 dne
	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 uvede důvod svého rozhodnutí. Tento atribut zaznamenává jeho slovní vysvětlení. Analýza důvodů zamítnutí přímo ukazuje, proč požadavky neprošly. Pomáhá odhalit časté problémy, například nesprávné účtování, nedostatek rozpočtu nebo nedostatečné zdůvodnění. Tyto problémy pak lze řešit školením nebo úpravou procesu. Proč je to důležité Ukazuje příčiny neúspěchu v procesu a pomáhá určit, kde je potřeba proškolit uživatele nebo upřesnit proces. Kde data získat Tyto údaje se obvykle zaznamenávají do pole pro komentáře nebo poznámky u změny stavu na „Zamítnuto“ v historii schvalování požadavku. Příklady Nesprávné nákladové střediskoPřekročen rozpočet na toto čtvrtletíDuplicitní požadavekNedostatečné zdůvodnění
	ID objednávky PurchaseOrderId	Identifikátor objednávky vytvořené na základě schváleného požadavku.
Popis Po úplném schválení a předání požadavku do výběrového řízení se obvykle vytvoří objednávka. Tento atribut uchovává ID této objednávky. Propojuje proces zpracování požadavku s navazujícím procesem objednávky. Umožňuje vypočítat KPI „Doba od schválení požadavku po vytvoření objednávky“ a analyzovat celý cyklus Purchase-to-Pay od začátku do konce. Proč je to důležité Propojuje požadavek s navazující objednávkou, takže lze analyzovat dobu předání a získat širší přehled o celém procesu P2P. Kde data získat Jde o standardní pole objektu Requisition v Coupa, které se vyplní po vytvoření objednávky. Příklady PO-45000123PO-45000124PO-45000125
	Komodita Commodity	Obecná kategorie požadovaného zboží nebo služeb.
Popis Atribut Komodita poskytuje standardizovanou klasifikaci položek v požadavku, například „Kancelářské potřeby“, „Počítačový hardware“ nebo „Marketingové služby“. Umožňuje analyzovat nákupní vzorce a rozdíly v procesu podle toho, co se nakupuje. Některé komodity mohou vyžadovat zvláštní schvalování nebo strategii výběrového řízení. Analýza procesu podle komodity pomáhá zlepšovat nákup v různých výdajových kategoriích. Proč je to důležité Pomáhá analyzovat výdajové kategorie a zjistit, zda se průběh procesu, například doba schvalování, liší podle typu nakupovaného zboží nebo služeb. Kde data získat Jde o standardní pole v Coupa, které je obvykle dostupné na úrovni řádku požadavku. Může být nutné seskupit údaje na úrovni hlavičky. Příklady Kancelářské potřebyPočítačový hardwareMarketingové službyCestování
	Měna Currency	Kód měny celkové částky požadavku.
Popis Tento atribut určuje měnu, například USD, EUR nebo GBP, ve které je uvedena celková částka požadavku. Jde o nezbytný kontext pro finanční analýzu, zejména v nadnárodních organizacích, které pracují s více měnami. Pomáhá správně interpretovat peněžní hodnoty a umožňuje jejich převod a souhrnné vykazování ve finančních přehledech a dashboardech. Proč je to důležité Doplňuje kontext k atributu „Celková částka“ a umožňuje přesnou finanční analýzu v prostředí s více měnami. Kde data získat Jde o standardní pole objektu Requisition v Coupa, obvykle pojmenované „currency_code“ nebo podobně. Příklady USDEURGBP
	Název dodavatele SupplierName	Název dodavatele vybraného pro požadavek.
Popis Tento atribut označuje zamýšleného dodavatele požadovaného zboží nebo služeb. Dodavatele může určit žadatel nebo může být doplněn později během výběrového řízení. Analýza ukazatelů procesu podle dodavatele pomáhá vyhodnotit jeho výkonnost a zjistit, zda spolupráce s některými dodavateli prodlužuje dobu zpracování nebo způsobuje jiné neefektivity. Poskytuje také důležitý kontext pro nákupní strategii a řízení vztahů s dodavateli. Proč je to důležité Umožňuje analyzovat výkonnost procesu podle vybraného dodavatele a využít výsledky při plánování výběrových řízení a správě dodavatelů. Kde data získat Tyto údaje jsou v Coupa dostupné v objektu Requisition Line, často v poli „supplier“ nebo „vendor“. Příklady StaplesDell TechnologiesAccentureCDW
	Počet schvalovacích kroků ApprovalStepCount	Celkový počet schvalovacích kroků, kterými požadavek prošel.
Popis Tento vypočítaný atribut počítá počet různých aktivit „Schválení schvalovacího kroku“ u každého požadavku. Pomáhá vyčíslit složitost schvalovacího workflow jednotlivých případů. Slouží jako základ KPI „Průměrný počet schvalovacích kroků“ a pomáhá najít požadavky s neobvykle dlouhým nebo složitým schvalováním, u kterých může být vhodné workflow zjednodušit. Proč je to důležité Vyjadřuje složitost schvalovacího workflow každého požadavku a pomáhá odhalit zbytečně složité cesty, které je třeba zjednodušit. Kde data získat Tato metrika se v nástroji process mining vypočítá jako počet výskytů aktivity „Schválení schvalovacího kroku“ pro každé Case ID. Příklady 253
	Typ požadavku RequisitionType	Kategorie nebo typ požadavku, například „Kapitálové výdaje“, „Provozní výdaje“ nebo „Software“.
Popis Typ požadavku je klasifikace, která rozděluje požadavky podle jejich obchodního účelu nebo povahy nákupu. Tento atribut se hodí pro analýzu shody a pro zjištění, jak jednotlivé typy požadavků procházejí procesem. Například požadavky na kapitálové výdaje mohou mít přísnější a delší schvalovací postup než běžné provozní požadavky. Analýza procesu podle typu požadavku může odhalit možnosti jeho zlepšení. Proč je to důležité Umožňuje rozdělit analýzu podle obchodního účelu požadavku, protože různé typy mohou mít odlišný průběh procesu a pravidla. Kde data získat Pravděpodobně jde o vlastní nebo standardní klasifikační pole objektu Requisition v Coupa. Příklady Kapitálové výdajeProvozní výdajeHardware ITOdborné služby
	Úroveň naléhavosti UrgencyLevel	Klasifikace naléhavosti požadavku, například „Vysoká“, „Střední“ nebo „Nízká“.
Popis Úroveň naléhavosti, často namapovaná na pole priority, umožňuje žadatelům označit požadavky, které je třeba vyřídit přednostně. Tento atribut je důležitý pro dashboard „Doba zpracování naléhavých požadavků“. Porovnáním doby zpracování naléhavých a běžných požadavků mohou organizace posoudit, zda pravidla prioritizace fungují a zda jsou naléhavé obchodní potřeby vyřizovány včas. Proč je to důležité Umožňuje zjistit, zda se naléhavé požadavky vyřizují rychleji než běžné, a ověřit tak účinnost pravidel prioritizace. Kde data získat V Coupa může jít o standardní nebo vlastní pole objektu Requisition. Podrobnosti najdete v dokumentaci Coupa nebo v konfiguraci systému. Příklady VysokáStředníNízká

Povinné Doporučené Volitelné

Aktivity procesu nákupu a platby, od požadavku po úhradu

Tyto důležité kroky a milníky procesu zachyťte v záznamu událostí, abyste mohli přesně zmapovat workflow zpracování požadavků v procesu nákupu a platby.

6 Doporučené 6 Volitelné

	Aktivita	Popis
	Objednávka vytvořena	Na základě údajů ze schváleného požadavku se vytvoří objednávka (PO). Událost se odvozuje od vytvoření záznamu objednávky, který obsahuje ID zdrojového požadavku.
Proč je to důležité Jde o hlavní úspěšný výsledek procesu zpracování požadavku a předání do další fáze procesu Purchase-to-Pay. Analýza doby od aktivity „Požadavek schválen“ do této události odhalí případná zpoždění. Kde data získat Událost se odvozuje od vytvoření záznamu v tabulce „purchase_orders“, který odkazuje na původní ID z tabulky „requisition_headers“ nebo „requisition_lines“. Zachycení Použijte časové razítko „created-at“ záznamu objednávky propojeného s ID požadavku. Typ události inferred
	Odeslání požadavku	Žadatel odešle vyplněný požadavek do schvalovacího workflow. Událost lze odvodit ze změny stavu požadavku v systémových auditních záznamech nebo historických tabulkách z 'draft' na 'pending_approval'.
Proč je to důležité Odesláním se spustí schvalovací proces. Jde proto o důležitý milník při měření KPI „Průměrná doba schvalování požadavku“. Zpoždění před tímto bodem souvisejí s uživatelem, zpoždění po něm s procesem. Kde data získat Událost lze odvodit ze změny stavu v tabulce 'requisition_headers', konkrétně když se pole 'status' změní na 'pending_approval'. Časové razítko změny je uvedeno v příslušném auditním záznamu. Zachycení Určete časové razítko, kdy se stav požadavku poprvé změní na 'pending_approval'. Typ události inferred
	Požadavek schválen	Požadavek úspěšně prošel všemi povinnými kroky schvalovacího workflow. Událost se odvozuje ze změny celkového stavu hlavičky požadavku na „approved“.
Proč je to důležité Jde o důležitý milník, který označuje konec schvalovacího cyklu. Doba do této aktivity je jedním z hlavních KPI a její dosažení spouští navazující nákupní kroky. Kde data získat Událost se odvozuje ze změny stavu v tabulce „requisition_headers“, kdy se pole „status“ aktualizuje na „approved“. Časové razítko se zaznamenává v souvisejícím auditním záznamu. Zachycení Určete časové razítko, kdy se celkový stav požadavku změní na „approved“. Typ události inferred
	Požadavek uzavřen	Požadavek je formálně uzavřen a nebudou u něj provedeny žádné další kroky. Může k tomu dojít po vytvoření a vyřízení objednávky nebo po zrušení požadavku po schválení, ale ještě před objednáním.
Proč je to důležité Tato aktivita jednoznačně ukončuje životní cyklus požadavku. Zajišťuje, že jsou případy řádně uzavřené a při analýze procesu se nejeví jako neustále aktivní. Kde data získat Událost se odvozuje ze změny stavu v tabulce „requisition_headers“, kdy se pole „status“ aktualizuje na „closed“. Časové razítko se zaznamenává v souvisejícím auditním záznamu. Zachycení Určete časové razítko, kdy se celkový stav požadavku změní na „closed“. Typ události inferred
	Požadavek zamítnut	Požadavek je během schvalování definitivně zamítnut a nebude převeden na objednávku. Událost se odvozuje ze změny celkového stavu hlavičky požadavku na „rejected“.
Proč je to důležité Tato aktivita představuje neúspěšné ukončení procesu. Analýza těchto událostí pomáhá snížit „Míru zamítnutí požadavků“ a odhalit příčiny, například porušení pravidel nebo nedostatek rozpočtu. Kde data získat Událost se odvozuje ze změny stavu v tabulce „requisition_headers“, kdy se pole „status“ aktualizuje na „rejected“. Časové razítko se zaznamenává v souvisejícím auditním záznamu. Zachycení Určete časové razítko, kdy se celkový stav požadavku změní na „rejected“. Typ události inferred
	Vytvoření požadavku	Uživatel založí nový požadavek na nákup a uloží ho jako koncept. Tím začíná každý případ požadavku. Událost se obvykle odvozuje z časového razítka vytvoření záznamu požadavku.
Proč je to důležité Tato činnost označuje začátek životního cyklu požadavku. Analýza doby od vytvoření po odeslání může odhalit zpoždění způsobená nejistotou uživatele nebo složitostí systému. Kde data získat Událost se zaznamenává podle časového razítka 'created-at' v tabulce 'requisition_headers' pro dané ID Purchase Requisition. Zachycení Použijte časové razítko vytvoření záznamu hlavičky požadavku. Typ události inferred
	Požadavek předán do výběrového řízení	Schválený požadavek se místo přímého převodu na objednávku předá do výběrového řízení, například do poptávky nebo aukce. Událost se odvozuje z propojení požadavku s objektem výběrového řízení.
Proč je to důležité Tato aktivita zachycuje důležitou alternativní cestu v nákupním procesu. Odlišuje běžné nákupy od složitějších strategických výběrových řízení, takže lze dobu zpracování analyzovat podrobněji. Kde data získat Událost se odvozuje ze změny stavu na „sourcing“ nebo ze zjištění, že bylo vytvořeno propojení mezi tabulkou „requisition_lines“ a tabulkou výběrového řízení. Zachycení Zkontrolujte, zda se stav změnil na „sourcing“ nebo zda vzniklo propojení s ID výběrového řízení. Typ události inferred
	Požadavek stažen	Původní žadatel zruší požadavek dříve, než získá konečné schválení. Jde o výslovnou akci uživatele, která proces daného požadavku ukončí.
Proč je to důležité Stažení požadavku může souviset se změnou obchodních potřeb, duplicitní žádostí nebo obcházením procesu. Sledování těchto případů pomáhá porozumět kolísání poptávky a možným problémům s dodržováním procesu. Kde data získat Událost se odvozuje ze změny stavu v tabulce „requisition_headers“ na „withdrawn“ nebo na podobnou hodnotu. Změna vychází z výslovné akce uživatele zaznamenané v auditním záznamu. Zachycení Určete časové razítko, kdy se stav požadavku změní na „withdrawn“. Typ události inferred
	Schválení schvalovacího kroku	Jednotlivý schvalovatel ve workflow schválí požadavek. Systém tuto konkrétní akci zaznamená spolu s časovým razítkem a informací o uživateli.
Proč je to důležité Tato aktivita poskytuje podrobný přehled o průběhu schvalování. Souhrn těchto kroků umožňuje vypočítat „Průměrnou dobu čekání na jeden schvalovací krok“ a analyzovat výkonnost schvalovatelů. Kde data získat Zaznamenává se na základě výslovné akce „approve“ v tabulce „approvals“ nebo v jejím auditním záznamu. Akce je propojena s konkrétním požadavkem a schvalovatelem. Zachycení V historii schvalování požadavku vyfiltrujte události „approve“. Typ události explicit
	Schvalovací krok zamítnut	Schvalovatel v příslušném kroku workflow požadavek zamítne. Obvykle jej tím vrátí žadateli k úpravě. Coupa tuto akci zaznamená.
Proč je to důležité Zamítnutí v kterémkoli kroku vede k přepracování a prodlužuje dobu zpracování. Analýza toho, kde a proč k zamítnutím dochází, pomáhá zlepšovat procesy a určit potřebu školení uživatelů. Kde data získat Zaznamenává se na základě výslovné akce „reject“ v tabulce „approvals“ nebo v jejím auditním záznamu. Akce je propojena s konkrétním požadavkem a schvalovatelem. Zachycení V historii schvalování požadavku vyfiltrujte události „reject“. Typ události explicit
	Úprava požadavku	Požadavek po odeslání upraví žadatel nebo jiný oprávněný uživatel. Coupa tuto událost výslovně zaznamená jako novou verzi nebo auditní záznam. Často se tím znovu spustí část nebo celý schvalovací workflow.
Proč je to důležité Sledování úprav je důležité pro pochopení přepracování a neefektivity procesu. Vysoký počet úprav může ukazovat na nejasné původní zadání nebo složitá nákupní pravidla a ovlivňuje KPI „Míra úprav požadavků“. Kde data získat Událost se zaznamenává v auditních tabulkách souvisejících s tabulkou 'requisition_headers'. Tyto tabulky evidují změny verzí nebo konkrétní akce 'edit'. Zachycení Po odeslání hledejte v historii požadavku výslovné události 'edit' nebo 'update'. Typ události explicit
	Zahájení schvalovacího kroku	Schvalovací úkol je přiřazen konkrétnímu schvalovateli nebo skupině schvalovatelů a požadavek čeká na jejich rozhodnutí. Událost lze odvodit ze založení schvalovacího záznamu přiřazeného k požadavku se stavem 'pending'.
Proč je to důležité Tímto okamžikem začíná čekání na konkrétní schválení. Doba mezi touto událostí a odpovídajícím schválením nebo zamítnutím schvalovacího kroku pomáhá odhalit konkrétní úzká místa ve schvalovacím řetězci. Kde data získat Událost lze odvodit z časového razítka vytvoření záznamu v tabulce 'approvals' propojeného s požadavkem, pokud má stav rozhodnutí schvalovatele hodnotu 'pending' nebo odpovídající stav. Zachycení Použijte časové razítko vytvoření záznamu čekajícího schválení konkrétní osoby ve schvalovacím řetězci. Typ události inferred

Doporučené Volitelné

Návody k extrakci dat

Jak získat data ze systému Coupa

Kroky

Přihlaste se do Coupa: Přihlaste se ke své instanci Coupa pomocí uživatelského účtu, který má oprávnění vytvářet a plánovat reporty.
Otevřete modul reportů: Přejděte na kartu „Setup“ a najděte část „Reporting“. Výběrem možnosti „Reports“ otevřete dashboard reportů.
Vytvořte vlastní report: Kliknutím na tlačítko „Create“ začněte vytvářet nový report. Jako typ vyberte „Custom Report“.
Vyberte zdroje dat reportu: V nástroji pro tvorbu reportů vyberte a propojte několik zdrojů dat, abyste získali všechny potřebné informace. Jako hlavní zdroj zvolte „Requisition Headers“. Poté přidejte tyto související objekty:
- „Approvals“: Podrobnosti o jednotlivých schvalovacích krocích, včetně schvalovatele, stavu a časových údajů.
- „Requisition Lines“: Souhrn celkových částek a podrobnosti o jednotlivých položkách.
- „Purchase Order Headers“: Informace o tom, kdy se požadavek převede na objednávku.
- „Users“: Celá jména a údaje o oddělení žadatelů a schvalovatelů.
Nastavte sloupce reportu: Přetáhněte potřebná pole z dostupných zdrojů dat do rozvržení reportu. Tento krok je zásadní, protože z těchto sloupců vytvoříte záznam událostí. Zahrňte alespoň tato pole:
- Z „Requisition Headers“: Requisition #, Created At, Submitted At, Updated At, Status, Created by (Login ID), Total, Sourced Externally?
- Z „Users“ (žadatel): Full Name, Department Name.
- Z „Approvals“: Created At, Updated At, Status, Approver (Login ID).
- Z „Purchase Order Headers“: PO Number, Created At.
Nastavte filtry reportu: Omezte rozsah exportovaných dat pomocí filtrů. Běžnou a účinnou volbou je pole „Requisition Headers - Created At“ s dynamickým rozsahem dat, například „Last 90 days“. Podle potřeby můžete také filtrovat podle kódů společností.
Naplánujte report: V nástroji pro tvorbu reportů přejděte na kartu „Schedule“. Nastavte četnost spouštění, například denně nebo týdně, a zvolte dobu mimo špičku.
Nastavte doručování: Vyberte způsob doručení. Pro automatizaci zvolte „SFTP“ a zadejte přihlašovací údaje k serveru a cílovou složku. Report můžete také posílat e-mailem. Jako formát souboru vyberte „CSV“.
Uložte a aktivujte report: Uložte report a ověřte, že je plán aktivní. První report se spustí v nejbližším naplánovaném čase.
Transformujte data: Vygenerovaný soubor CSV obsahuje plochá data, nikoli záznam událostí. Zpracujte ho externím skriptem, například v Pythonu, nebo pomocí nástroje ETL. Skript musí data převést tak, aby vznikl samostatný řádek pro každou aktivitu. Například řádek „Vytvoření požadavku“ použije sloupec Created At, pro každý schvalovací krok vznikne další řádek ze sloupců „Approvals“ a řádek „Vytvoření objednávky“ použije sloupec Created At z PO.
Vytvořte výsledný záznam událostí: Transformace musí vytvořit výsledný soubor CSV s požadovanými sloupci: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate a dalšími doporučenými atributy. Soubor je pak připravený k nahrání.

Konfigurace

Hlavní zdroje dat: Report musí propojit několik objektů Coupa. Hlavními zdroji jsou „Requisition Headers“, „Approvals“, „Requisition Lines“ a „Purchase Order Headers“.
Filtr podle období: Omezení objemu dat pomocí časového filtru je zásadní. Doporučujeme začít klouzavým obdobím posledních 3 až 6 měsíců podle pole „Requisition Headers - Created At“.
Přírůstkové načítání: Pro průběžnou analýzu plánujte každodenní spuštění reportu a export dat za předchozí den, například „Yesterday“. Tím vytvoříte přírůstkové dávky.
Nastavení doručování: Pro spolehlivé automatické napojení na datový proces nastavte doručování na server SFTP. Zabezpečte cílové umístění a ověřte, že má dostatek místa.
Potřebná oprávnění: Účet uživatele, který report nastavuje, musí mít oprávnění správce nebo oprávnění pro tvorbu reportů. Musí umožňovat vytváření a plánování reportů i přístup ke všem potřebným objektům (požadavky, PO, schválení a uživatelé).

Ukázkový dotaz config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

Kroky

Předpoklady: Ověřte, že máte nainstalované prostředí Python 3. Nainstalujte potřebné knihovny pandas a requests příkazem pip install pandas requests v terminálu nebo příkazovém řádku.
Získejte API klíč Coupa: Přihlaste se do své instance Coupa jako správce. Přejděte na Setup > Company Setup > API Keys. Vytvořte nový API klíč s oprávněním alespoň pro čtení v těchto rozsazích: core.purchase_order.read, core.requisition.read a core.user.read.
Nastavte skript: Vytvořte nový soubor Python, například extract_coupa_reqs.py. Vložte do něj poskytnutý Python skript. Nahraďte zástupnou hodnotu COUPA_INSTANCE_URL adresou URL Coupa vaší společnosti, například https://yourcompany.coupahost.com, a hodnotu API_KEY klíčem získaným v předchozím kroku.
Nastavte parametry extrakce: V části main skriptu upravte proměnné START_DATE a END_DATE a určete období, za které chcete data získat. Filtr se řídí datem vytvoření požadavků.
Spusťte skript: Spusťte skript v terminálu příkazem python extract_coupa_reqs.py. Skript se připojí k Coupa API, načte data a bude v konzoli zobrazovat průběh.
Zpracujte stránkování API: Skript obsahuje funkci, která stránkování API zpracuje automaticky. Data načítá po dávkách po 50 záznamech a pokračuje, dokud nezíská všechny požadavky z vybraného období.
Zpracujte data požadavků: Pro každou načtenou hlavičku požadavku skript vytvoří události „Vytvoření požadavku“ a „Odeslání požadavku“. Poté provede další volání API a načte související údaje o schváleních a objednávkách.
Vytvořte události aktivit: Ze záznamů o schválení skript vytvoří události „Zahájení schvalovacího kroku“, „Schválení schvalovacího kroku“ a „Zamítnutí schvalovacího kroku“. Zkontroluje také konečný stav požadavku a související data a vytvoří události jako „Schválení požadavku“, „Vytvoření objednávky“ a „Stažení požadavku“.
Odhalte změny požadavků: Skript kontroluje atribut version každého požadavku. Hodnota vyšší než 1 znamená, že byl požadavek změněn. Událost „Změna požadavku“ se vytvoří s časovým údajem updated-at novější verze.
Sestavte záznam událostí: Všechny vytvořené události se shromáždí do strukturovaného seznamu. Každá událost obsahuje požadované atributy, například PurchaseRequisitionId, ActivityName a EventTime, i doporučené atributy, například Requester a TotalAmount.
Exportujte do CSV: Po zpracování všech požadavků skript převede seznam událostí na pandas DataFrame a uloží ho do souboru CSV coupa_requisition_event_log.csv ve stejné složce. Soubor je připravený k přímému nahrání do ProcessMind.

Konfigurace

Oprávnění API klíče: API klíč použitý k extrakci musí mít v Coupa přístup pro čtení objektů requisition_headers, requisition_lines, approvals, purchase_orders a users. Bez těchto oprávnění skript selže nebo vrátí neúplná data.
Časové období: Skript filtruje data podle data vytvoření požadavku (created-at). Doporučujeme načítat data po zvládnutelných dávkách, například za 3 až 6 měsíců, abyste předešli dlouhému běhu a případnému vypršení časového limitu API. Podle potřeby upravte proměnné START_DATE a END_DATE.
Filtr stavu: Poskytnutý skript načítá požadavky bez ohledu na jejich stav. Pokud chcete analýzu zúžit, můžete do slovníku params v prvním volání API přidat parametr status a vybrat konkrétní stavy, například approved, pending_approval nebo ordered.
Limit stránkování: Skript je nastavený na načítání 50 záznamů při každém volání API (limit=50). Jde o běžnou hodnotu, která s Coupa API dobře funguje. Vyšší limit nemusí zrychlit zpracování a u složitých dotazů může zvýšit riziko vypršení časového limitu.
Výkon: Skript pro každý požadavek provádí několik volání API: jedno pro hlavičku, jedno pro schválení a jedno pro objednávky. Extrakce tisíců požadavků může trvat dlouho a podléhá limitům četnosti volání API Coupa. Doporučujeme spouštět skript mimo špičku.

Ukázkový dotaz python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

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

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

Kroky

Ověřte, že vybraná platforma iPaaS nebo process mining nabízí ověřený konektor Coupa s přístupem k hlavičkám požadavků, historii požadavků nebo auditním datům, záznamům o schválení, vazbám na sourcing a objednávky a informacím o uzavření. Názvy konektorů a objektů i dostupná pole se liší podle poskytovatele. Nastavte je podle dokumentace konektoru a konfigurace vašeho prostředí Coupa.
V rozhraní platformy vytvořte připojení ke konektoru. Zadejte požadovanou URL prostředí Coupa, způsob ověření, přihlašovací údaje, údaje OAuth a případné požadované rozsahy oprávnění. Do nastavení můžete do připojení v cílovém prostředí použít zástupné hodnoty, například [Your Coupa tenant URL] a [Your connector credentials].
Nastavte rozsah extrakce. Nejprve vyberte klouzavé období tří až šesti měsíců a po ověření dat ho případně rozšiřte. Používejte pouze filtry platné pro vaše prostředí, například [Your company filter] nebo [Your document type filter]. Nevylučujte požadavky jen proto, že jejich aktuální stav je uzavřený, zamítnutý, stažený nebo schválený. Tyto případy jsou potřebné pro analýzu celého průběhu.
Namapujte zdrojové objekty konektoru. Vyberte objekt hlaviček požadavků, historii požadavků nebo auditní objekt, objekt schválení, objekt vazeb na sourcing, objekt vazeb na objednávky a případný objekt historie uzavření nebo stavu, který konektor zpřístupňuje. Pokud požadovaný objekt není dostupný, použijte podporovanou podobu historie nebo auditu, případně omezení zdokumentujte před zveřejněním extrakce.
Nastavte mapování případů a událostí. Identifikátor požadavku namapujte na PurchaseRequisitionId, označení události na ActivityName, zdrojový časový údaj na EventTime, konstantní hodnotu zdroje Coupa na SourceSystem a čas aktualizace konektoru na LastDataUpdate. Pokud jsou tato pole dostupná, namapujte také žadatele, oddělení, celkovou částku, stav požadavku a schvalovatele.
Nastavte pravidla událostí tak, aby výslovně vytvářela řádky pro všech dvanáct aktivit. Událost Requisition Created vytvořte z časového údaje vytvoření požadavku, Requisition Submitted z přechodu z draft do pending_approval, Requisition Amended z verze nebo auditního záznamu po odeslání, Approval Step Started ze záznamu čekajícího schválení, Approval Step Approved ze schvalovací akce, Approval Step Rejected z akce zamítnutí, Requisition Withdrawn z výslovné akce stažení nebo změny stavu, Requisition Approved z přechodu hlavičky do stavu approved, Requisition Rejected z přechodu hlavičky do stavu rejected, Requisition Sourced z vazby požadavku na sourcing, Purchase Order Created z objednávky odkazující na požadavek a Requisition Closed z akce uzavření nebo změny stavu.
Před sloučením toků událostí normalizujte extrahovaná data. Převeďte všechny časové údaje do jednoho časového pásma, nejlépe UTC, zachovejte přesnost zdrojových časových údajů, sjednoťte datový typ identifikátoru požadavku na text a ponechte zdrojové hodnoty stavu a uživatele. Odstraňujte pouze technicky totožné zdrojové záznamy. Při porovnání použijte identifikátor požadavku, název aktivity, čas události, ID zdrojového záznamu, pokud je dostupné, a schvalovatele.
Zveřejněte nebo naplánujte tok konektoru. Nejprve proveďte úplnou extrakci vybraného období a poté nastavte přírůstkové aktualizace podle časového údaje aktualizace zdroje nebo podporovaného mechanismu sledování změn konektoru. Nastavte období zpětného načítání, aby se zahrnuly pozdě doručené auditní záznamy a změněné záznamy o schválení.
Ověřte výsledný záznam událostí podle reportů Coupa nebo náhledu konektoru. Zkontrolujte, že každý požadavek má událost vytvoření, přechody stavů a schválení jsou ve správném časovém pořadí a související události jsou přítomné, pokud existuje sourcing nebo objednávka.
Exportujte výsledek jako plochý soubor CSV nebo v jiném formátu záznamu událostí, který ProcessMind podporuje. Každý řádek musí odpovídat jedné události. Jako identifikátor případu použijte PurchaseRequisitionId, jako aktivitu ActivityName a jako časové razítko události EventTime. Soubor nahrajte nebo zveřejněte datovou sadu konektoru v ProcessMind. Nespoléhejte na to, že ProcessMind odvodí chybějící události.

Konfigurace

Konektor a přístup: Použijte ověřený konektor Coupa od vybrané platformy iPaaS nebo process mining. Požadovaná oprávnění Coupa, rozsahy API, moduly a licence konektoru závisí na poskytovateli a konfiguraci prostředí. Před nasazením ověřte přístup k datům o požadavcích, historii nebo auditu, schváleních, sourcingu, objednávkách a uzavření.
Časové období: Začněte s daty za tři až šest měsíců. Pro plánované aktualizace použijte klouzavé období a zahrňte časovou rezervu pro pozdější změny, schvalovací akce a upravené požadavky.
Požadovaná mapování: Identifikátor požadavku namapujte na PurchaseRequisitionId, označení události na ActivityName, čas události na EventTime, zdrojovou hodnotu na SourceSystem a čas aktualizace na LastDataUpdate.
Doporučená mapování: Namapujte stav požadavku, žadatele, oddělení nebo nákladové středisko, celkovou částku a schvalovatele. Pokud konektor podporuje historické snímky, zachovejte aktuální i hodnoty platné v době události.
Pravidla událostí: Nastavte výslovné vytváření všech dvanácti požadovaných aktivit. ProcessMind načítá záznam událostí tak, jak je, a další události neodvozuje ani nedoplňuje.
Filtry: Používejte pouze filtry podporované konektorem a platné pro dané prostředí, například [Your company filter], [Your document type filter], [Your business unit filter] nebo [Your requisition date range]. Konečné stavy nevylučujte, pokud to analýza výslovně nevyžaduje.
Zpracování časových údajů: Převeďte časové údaje do společného časového pásma, zachovejte přesnost zdroje a určete jednoznačné pravidlo řazení událostí se stejným časovým údajem.
Přírůstkové aktualizace: Použijte podporované pole updated-at nebo mechanismus sledování změn konektoru. Nastavte období zpětného načítání, protože historie schválení, vazby na sourcing a objednávky i informace o uzavření mohou být doplněny až po vytvoření požadavku.
Výkon: Omezte počáteční extrakci podle data a platných obchodních filtrů, načítejte pouze potřebná pole, stránkujte velké objekty a vyhněte se opakovanému spojování celých historických datových sad. Pokud je to možné, extrahujte vazby a auditní data přírůstkově.
Kvalita dat: Vyžadujte neprázdné hodnoty PurchaseRequisitionId, ActivityName, EventTime, SourceSystem a LastDataUpdate. Pokud konektor zpřístupňuje zdrojové identifikátory, zachovejte je pro řešení problémů a odstranění duplicit.
Rozdíly v konfiguraci: Názvy objektů a polí, hodnoty stavů, podoba auditních dat i dostupné údaje o vazbách se liší podle prostředí Coupa a konektoru. Pokud konektor nenabízí zdokumentující ekvivalent, použijte [Configure based on your system].

Ukázkový dotaz config

WITH
requisition_created AS (
    SELECT
        CAST(r.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        CAST(r.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(r.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your requisition header object] r
    WHERE r.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND r.created_at < CAST('[Your end date]' AS TIMESTAMP)
      AND [Your company filter]
),
requisition_submitted AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Submitted' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.previous_status AS VARCHAR(255))) = 'draft'
      AND LOWER(CAST(h.new_status AS VARCHAR(255))) = 'pending_approval'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_amended AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('amended', 'updated', 'version_created')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_started AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        CAST(a.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.status AS VARCHAR(255))) = 'pending'
      AND a.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_approved AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'approved'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_rejected AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'rejected'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_withdrawn AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('withdrawn', 'withdrawal', 'cancelled_before_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_approved AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'approved'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_rejected AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'rejected'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_sourced AS (
    SELECT
        CAST(s.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Sourced' AS ActivityName,
        CAST(s.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(s.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your sourcing relationship object] s
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(s.requisition_id AS VARCHAR(255))
    WHERE s.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND s.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
purchase_order_created AS (
    SELECT
        CAST(p.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        CAST(p.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(p.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your purchase order relationship object] p
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(p.requisition_id AS VARCHAR(255))
    WHERE p.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND p.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_closed AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('closed', 'closure', 'cancelled_after_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_submitted
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_amended
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_started
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_withdrawn
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_sourced
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM purchase_order_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_closed
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Chcete začít?

Začněte zlepšovat proces nákupu a platby, konkrétně zpracování požadavků v Coupa, pomocí této šablony. Získejte přehled o procesu a najděte možnosti, jak zefektivnit nákup.

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

Stáhnout šablonu

Zlepšete zpracování požadavků P2P v Coupa a zkraťte dobu průchodu

Najděte neefektivní místa a zkraťte dobu průchodu požadavků P2P o 30 %.

Začněte zkušební verzi zdarma

Bez platební karty. Zlepšení procesu můžete začít během několika minut.

Šablona dat pro proces nákupu a platby, od požadavku po úhradu

Šablona dat pro proces nákupu a platby, od požadavku po úhradu

Atributy procesu nákupu a platby, od požadavku po úhradu

Aktivity procesu nákupu a platby, od požadavku po úhradu

Návody k extrakci dat

Plánované reporty Coupa pro export dat o požadavcích

Kroky

Konfigurace

Ukázkový dotaz config

Extrakce pomocí Python skriptu přes Coupa REST API

Kroky

Konfigurace

Ukázkový dotaz python

Extrakce pomocí konektoru iPaaS třetí strany

Kroky

Konfigurace

Ukázkový dotaz config

Chcete začít?

Zlepšete zpracování požadavků P2P v Coupa a zkraťte dobu průchodu