Šablona dat pro zpracování faktur dodavatelů
Šablona dat pro zpracování faktur dodavatelů
- Doporučené atributy pro důkladnou analýzu
- Důležité aktivity procesu, které je třeba sledovat
- Postup získání dat krok za krokem
Atributy zpracování faktur dodavatelů
| Název | Popis | ||
|---|---|---|---|
| Aktivita ActivityName | Název konkrétní obchodní události nebo kroku, ke kterému došlo během zpracování faktury. | ||
| Popis Aktivita představuje samostatnou fázi nebo úkon v procesu závazků, například „Přijetí faktury“, „Faktura zaúčtována“ nebo „Platba provedena“. Tyto aktivity tvoří základ procesní mapy. Analýza aktivit je základem process mining. Pomáhá znázornit průběh procesu, odhalit obvyklé postupy, zjistit odchylky od standardního procesu a měřit četnost a dobu trvání jednotlivých kroků. Pořadí aktivit u konkrétní faktury zachycuje její průchod procesem. Proč je to důležité Určuje jednotlivé kroky procesu, umožňuje znázornit a analyzovat jeho průběh, odhalit úzká místa a zjistit opakované cykly oprav. Kde data získat Odvozuje se z různých zdrojů, například ze změn stavu dokladu (např. BKPF-BSTAT), změnových dokladů (tabulky CDHDR/CDPOS) nebo protokolů workflow. Obvykle je potřeba připravit vlastní logiku extrakce. Příklady Přijetí fakturyFaktura schválenaPlatba provedenaFaktura zablokována k platbě | |||
| Čas události EventTime | Přesné datum a čas, kdy k aktivitě došlo. | ||
| Popis Čas události je časové razítko přiřazené ke každé aktivitě a určuje chronologické pořadí událostí u faktury. Tato data jsou nezbytná pro pochopení průběhu procesu a časovou analýzu. Při analýze se čas události používá ke správnému seřazení aktivit, výpočtu doby mezi jednotlivými kroky, určení čekání a sledování výkonnosti procesu v různých obdobích, například po jednotlivých měsících. Je základem všech KPI založených na době trvání. Proč je to důležité Toto časové razítko je nezbytné pro chronologické řazení událostí a výpočet časových ukazatelů, například doby zpracování a trvání jednotlivých kroků, které jsou základem process mining. Kde data získat Získává se z různých polí data a času v tabulkách SAP, například z data vytvoření (BKPF-CPUDT), data účtování (BKPF-BUDAT), data vyrovnání (BSAK-AUGDT) nebo časových razítek protokolu změn (CDHDR-UDATE/UTIME). Příklady 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Faktura Invoice | Jedinečný identifikátor dokladu faktury, který slouží jako hlavní ID případu v procesu závazků. | ||
| Popis Faktura je ústředním objektem, který propojuje všechny související aktivity od přijetí po úhradu. V SAP S/4HANA jde obvykle o složený klíč tvořený kódem společnosti (BUKRS), jedinečným číslem dokladu (BELNR) a fiskálním rokem (GJAHR). Analýza podle faktury poskytuje úplný přehled o jejím průběhu od začátku do konce. Je základem pro výpočet důležitých ukazatelů, například celkové doby zpracování, odhalení úzkých míst u jednotlivých faktur a pochopení různých cest, kterými může faktura procesem projít. Proč je to důležité Jednoznačně identifikuje průběh každé faktury, takže lze sledovat její celý životní cyklus a analyzovat výkonnost procesu pro každý případ zvlášť. Kde data získat Jde o složený klíč odvozený z tabulek BKPF (hlavička účetního dokladu) nebo RBKP (hlavička dokladu: příjem faktury) pomocí polí BUKRS, BELNR a GJAHR. Příklady 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data tohoto záznamu naposledy aktualizována ze zdrojového systému. | ||
| Popis Tento atribut uvádí datum a čas poslední extrakce nebo aktualizace dat ze SAP S/4HANA. Jde o metadata důležitá pro posouzení aktuálnosti analyzovaných dat. Díky této informaci uživatelé vědí, jak aktuální je analýza procesu. Pomáhá nastavit očekávání ohledně zpoždění dat, plánovat jejich aktualizaci a udržovat jejich integritu. Proč je to důležité Ukazuje aktuálnost dat, takže uživatelé vědí, jak čerstvá jsou data použitá v analýze procesu. Kde data získat Tato hodnota se vygeneruje a zapíše do každého záznamu při extrakci dat ze zdrojového systému. Příklady 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Zdrojový systém SourceSystem | Systém, ze kterého byla data načtena. | ||
| Popis Tento atribut označuje původ procesních dat. V tomto přehledu bude jeho hodnota obvykle „SAP S/4HANA“. V prostředí s více ERP nebo propojenými systémy je toto pole důležité pro sledování původu dat a jejich oddělení. Zajišťuje analýzu správné datové sady a pomáhá při řešení problémů s kvalitou dat tím, že umožňuje dohledat jejich zdroj. Proč je to důležité Označuje původ dat, což je důležité pro správu dat, řešení problémů a prostředí s více systémy. Kde data získat Obvykle jde o statickou hodnotu přidanou při extrakci dat, která označuje původ datové sady. Příklady SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Částka faktury InvoiceAmount | Celková hrubá částka faktury v původní měně dokladu. | ||
| Popis Jde o celkovou částku faktury vystavené dodavatelem. Zahrnuje cenu zboží nebo služeb, daně a další poplatky před odečtením srážek nebo slev. Částka faktury je důležitý finanční atribut pro řadu analýz. Pomáhá určit prioritu faktur s vysokou hodnotou, pochopit finanční dopad prodlev v procesu, například poplatky z prodlení u vysokých částek, a rozdělit proces do skupin, například zjistit, zda faktury s vysokou hodnotou procházejí jiným schvalováním. Je také nezbytná pro odhalování možných duplicitních plateb. Proč je to důležité Doplňuje finanční kontext procesu a umožňuje analýzu podle hodnoty, stanovení priority faktur s vysokou částkou a vyčíslení finančních dopadů. Kde data získat U faktur MM se nachází například v tabulce RBKP-RMWWR (hrubá částka faktury). U faktur FI se vypočítává z položek v BSEG (pole WRBTR). Příklady 1500.00250.7512345.50 | |||
| Číslo objednávky PurchaseOrderNumber | Jedinečný identifikátor objednávky spojené s fakturou, pokud se na ni vztahuje. | ||
| Popis Tento atribut propojuje fakturu s předem schválenou objednávkou (PO). Číslo objednávky je základem třístranného párování (objednávka, faktura, příjemka). Je důležitý pro analýzu shody a efektivity. Používá se k výpočtu KPI „Podíl faktur bez objednávky“, který měří dodržování pravidel nákupu. Je také základem dashboardu „Výkonnost třístranného párování“, který umožňuje analyzovat párování faktur s objednávkou. Proč je to důležité Důležitý údaj pro analýzu efektivity třístranného párování a dodržování pravidel nákupu. Pomáhá odhalit faktury zpracované bez objednávky. Kde data získat Nachází se v tabulkách položek faktury, například RSEG-EBELN u faktur MM nebo BSEG-EBELN u faktur FI. Příklady 45000012344500005678 | |||
| Datum splatnosti faktury InvoiceDueDate | Datum, do kterého je třeba fakturu uhradit dodavateli. | ||
| Popis Datum splatnosti faktury je lhůta pro úhradu dodavateli. Jeho dodržení pomáhá vyhnout se poplatkům za pozdní platbu a udržovat dobré vztahy s dodavatelem. Datum se vypočítává ze základního data faktury a platebních podmínek dohodnutých s dodavatelem. Tento údaj je nezbytný pro dashboard „Shoda plateb a doba po splatnosti“ a KPI „Podíl včasných plateb“. Porovnáním data splatnosti se skutečným datem platby lze zjistit, zda byly faktury uhrazeny včas, předčasně nebo pozdě. To má přímé finanční dopady a ovlivňuje vztahy s dodavateli. Proč je to důležité Jde o hlavní údaj pro analýzu včasnosti plateb. Umožňuje měřit jejich průběh a dopad na vztahy s dodavateli i poplatky za pozdní úhradu. Kde data získat Toto datum se často vypočítává. Čisté datum splatnosti je v poli BSEG-NETDT. Lze ho také odvodit ze základního data platby (BSEG-ZFBDT) a platebních podmínek (BSEG-ZTERM). Příklady 2023-10-312023-11-152024-01-10 | |||
| Kód společnosti CompanyCode | Organizační jednotka, pro kterou se faktura zpracovává. | ||
| Popis Kód společnosti označuje nejmenší organizační jednotku, pro kterou lze sestavit úplnou a samostatnou účetní závěrku pro externí výkaznictví. V procesu závazků představuje právnickou osobu, která dluží peníze dodavateli. Analýza podle kódu společnosti umožňuje porovnat výkonnost procesu mezi různými právnickými osobami v organizaci. Pomáhá určit, které části firmy dodržují standardní postupy a kde je vyšší efektivita, delší doba zpracování nebo více opakované práce. Proč je to důležité Umožňuje porovnat výkonnost procesu mezi různými právnickými osobami a odhalit problémy i osvědčené postupy v jednotlivých regionech nebo organizačních jednotkách. Kde data získat Nachází se v hlavičkách dokladů, především v BKPF-BUKRS u faktur FI a RBKP-BUKRS u faktur MM. Příklady 10001710US01DE01 | |||
| Název dodavatele VendorName | Název dodavatele, který fakturu vystavil. | ||
| Popis Tento atribut obsahuje oficiální název dodavatele. Propojuje se prostřednictvím čísla dodavatele uloženého v dokladu faktury. Analýza dodavatelů je důležitá pro řízení vztahů s dodavateli a odhalení problémů v procesu, které se týkají konkrétních dodavatelů. Pomáhá odpovědět například na otázky: „Kteří dodavatelé nejčastěji posílají faktury s nesrovnalostmi?“ nebo „Platíme vybraným strategickým dodavatelům pravidelně včas?“ Spolu s číslem a částkou faktury je důležitá také pro odhalování možných duplicitních plateb. Proč je to důležité Umožňuje analyzovat výkonnost procesu podle dodavatele, odhalit problematické dodavatele a účinně řídit vztahy se strategickými dodavateli. Kde data získat Získává se z tabulky kmenových dat dodavatelů LFA1 (pole NAME1) propojením přes číslo dodavatele (LIFNR) uvedené v BKPF nebo RBKP. Příklady Kancelářské potřeby, s. r. o.Skupina globálního poradenstvíStrojní součástky GmbH | |||
| Uživatelské jméno UserName | ID uživatele, který aktivitu provedl. | ||
| Popis Tento atribut zaznamenává ID uživatele SAP odpovědného za konkrétní aktivitu, například zaúčtování, schválení nebo vyrovnání faktury. Propojuje jednotlivé kroky procesu s konkrétními uživateli. Analýza podle uživatelského jména pomáhá pochopit rozložení pracovní zátěže, určit nejvýkonnější uživatele a odhalit, kdo může potřebovat další školení. Je důležitá také pro analýzu úzkých míst při schvalování v dashboardech, protože ukazuje, kteří schvalovatelé způsobují prodlevy. Proč je to důležité Přiřazuje aktivity konkrétním osobám a umožňuje analyzovat jejich výkon, pracovní zátěž a dodržování pravidel oddělení pravomocí. Kde data získat Obvykle se nachází v tabulkách hlaviček, například BKPF-USNAM (zadáno uživatelem), nebo v tabulkách změnových dokladů CDHDR-USERNAME (změněno uživatelem). Příklady ABROWNJSMITHAP_AUTOMATION | |||
| Číslo faktury dodavatele VendorInvoiceNumber | Číslo faktury, které dodavatel uvedl na svém dokladu. | ||
| Popis Jde o referenční číslo z účetního systému dodavatele, uvedené na papírové nebo elektronické faktuře. Při přijetí faktury se zadává ručně nebo se načítá pomocí OCR. Toto pole je důležité pro provoz i analýzu, zejména pro dashboard „Možné duplicitní úhrady faktur“. Duplicitní faktury lze často odhalit vyhledáním více interních dokladů se stejným názvem dodavatele, číslem faktury dodavatele a částkou faktury. Jde o hlavní externí referenci faktury. Proč je to důležité Toto pole pomáhá odhalit možné duplicitní úhrady a slouží jako hlavní externí reference při komunikaci s dodavateli. Kde data získat Ukládá se do pole „Reference“ v záhlaví dokladu, obvykle BKPF-XBLNR. Příklady INV-2023-9876733401120231015-001 | |||
| Datum vyrovnání ClearingDate | Datum úhrady, kdy byla faktura vyrovnána a odstraněna z otevřených položek. | ||
| Popis Datum vyrovnání označuje finanční vypořádání faktury. Jde o datum aktivity „Úhrada provedena“, která u většiny úspěšně zpracovaných faktur představuje poslední krok. Toto datum slouží k výpočtu skutečného data úhrady a jeho porovnání s datem splatnosti faktury. Je proto nezbytné pro výpočet KPI „Míra včasných úhrad“ i pro analýzu výkonnosti plateb. Zároveň označuje konec období, za které se počítá celková doba zpracování faktury. Proč je to důležité Označuje konečné vypořádání faktury. Slouží jako konečný bod pro výpočet doby zpracování a jako základ pro analýzu včasných úhrad. Kde data získat Najdete jej v tabulkách vyrovnaných položek, například u dodavatelů v BSAK-AUGDT. Příklady 2023-10-282023-11-142024-01-09 | |||
| Důvod blokace BlockingReason | Důvod, proč je faktura zablokována k úhradě. Obvykle upozorňuje na nesrovnalost. | ||
| Popis Pokud faktura neprojde kontrolou při třístranném párování nebo jiném ověřovacím kroku, zablokuje se její úhrada. Důvod blokace popisuje problém, například nesoulad v množství, rozdíl v ceně nebo chybějící příjem zboží. Tento atribut je zásadní pro dashboard „Analýza oprav nesrovnalostí ve fakturách“. Četnost jednotlivých důvodů blokace pomáhá odhalit příčiny neefektivity procesu. Pokud je například častým důvodem „Rozdíl v ceně“, může to ukazovat na problémy s kmenovými daty v nákupním systému. Proč je to důležité Přímo ukazuje příčiny nesrovnalostí ve fakturách a opakovaného zpracování, takže můžete cíleně zlepšovat proces. Kde data získat Ukládá se do tabulek položek faktury, například RSEG, do polí začínajících na SPGR* (například SPGRP, SPGRQ, SPGRT). Najdete jej také v RBKP_BLOCKED. Příklady Nesoulad v ceněNesoulad v množstvíChybějící příjem zboží | |||
| Měna faktury InvoiceCurrency | Kód měny, ve které je uvedena částka faktury (například USD nebo EUR). | ||
| Popis Tento atribut určuje měnu, ve které je vyjádřena částka faktury. Poskytuje nezbytný kontext pro všechny finanční údaje. V mezinárodní organizaci může být analýza faktur bez zohlednění měny zavádějící. Toto pole umožňuje správně pracovat s finančními údaji: částky můžete převést na jednu vykazovací měnu nebo analýzu rozdělit podle měny a porovnat finanční aktivity v jednotlivých regionech. Proč je to důležité Poskytuje potřebný kontext k částce faktury a umožňuje přesnou finanční analýzu a vykazování, zejména v mezinárodním prostředí. Kde data získat Najdete ji v tabulkách záhlaví dokladu, především v BKPF-WAERS nebo RBKP-WAERS. Příklady USDEURGBPJPY | |||
| Platební podmínky PaymentTerms | Podmínky dohodnuté s dodavatelem pro úhradu faktury, často včetně možnosti získat slevu. | ||
| Popis Platební podmínky určují termín splatnosti a případné slevy za včasnou platbu. Například podmínka „Z001“ může znamenat „Splatnost do 30 dnů, při úhradě do 10 dnů sleva 2 %“. Tento atribut je základem dashboardu „Míra využití slev za včasnou platbu“. Analýza platebních podmínek umožňuje určit všechny faktury, u kterých bylo možné slevu uplatnit. Porovnáním slev s těmi, které byly skutečně využity, odhalíte nevyužité možnosti úspor a změříte efektivitu procesu plateb. Proč je to důležité Je nezbytný pro analýzu možností získat slevu za včasnou platbu, měření finanční výkonnosti procesu plateb a odhalování nevyužitých úspor. Kde data získat Najdete jej v položkách dodavatele v tabulce BSEG-ZTERM nebo v záhlaví faktury v RBKP-ZTERM. Příklady Z0010001NT30 | |||
| Pozdní úhrada IsLatePayment | Logická hodnota určující, zda byla faktura uhrazena po datu splatnosti. | ||
| Popis Tento vypočítaný atribut má hodnotu true nebo false a určuje, zda byla faktura uhrazena po oficiálním datu splatnosti. Vypočítá se porovnáním „Data vyrovnání“ a „Data splatnosti faktury“. Tento příznak zjednodušuje analýzu v dashboardu „Shoda plateb a stáří pohledávek“ i výpočet KPI „Míra včasných úhrad“. Umožňuje snadno filtrovat a sčítat pozdní úhrady, vypočítat podíl včasných úhrad a určit dodavatele nebo kódy společností s vysokým podílem pozdních úhrad. Proč je to důležité Přímo měří dodržování platebních podmínek, zjednodušuje výpočet KPI včasných úhrad a pomáhá odhalit oblasti se slabou platební výkonností. Kde data získat Vypočítaný atribut. Logika: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Příklady truefalse | |||
| Provedeno automaticky IsAutomated | Příznak označující, zda aktivitu provedl automaticky systém, nebo uživatel. | ||
| Popis Tento logický atribut rozlišuje mezi aktivitami zahájenými člověkem a aktivitami provedenými systémovými úlohami, workflow nebo boty. Jako automatické se označí například automatizovaný platební běh nebo zaúčtování faktury vytvořené systémem. Analýza tohoto atributu pomáhá zjistit míru automatizace procesu závazků. Lze s ní měřit výsledky automatizačních iniciativ, porovnávat efektivitu automatických a ručních kroků a hledat další možnosti automatizace. Proč je to důležité Pomáhá měřit míru automatizace procesu, vyhodnocovat její účinnost a hledat další možnosti zlepšení. Kde data získat Odvozuje se podle uživatelského jména, například systémových ID jako 'SAP_SYSTEM' nebo 'BATCHUSER', případně podle konkrétních transakčních kódů spojených s automatizovanými úlohami. Příklady truefalse | |||
| Typ dokladu faktury InvoiceDocumentType | Klasifikace dokladu faktury, která určuje způsob jeho zpracování v SAP. | ||
| Popis Typ dokladu je konfigurační prvek SAP, který kategorizuje účetní doklady. Například „KR“ se obvykle používá pro dodavatelské faktury, „RE“ pro faktury MM a „KG“ pro dobropisy dodavatelů. Typ určuje například číselnou řadu a povinná pole. Filtrování podle typu dokladu umožňuje porovnat průběh zpracování různých druhů faktur. Schvalování dobropisu může například probíhat jinak než schvalování běžné faktury. To se hodí pro dashboard „Varianty schvalování faktur“. Proč je to důležité Umožňuje rozdělit proces podle způsobu zpracování různých typů faktur a odhalit rozdíly v postupech i době zpracování. Kde data získat Přímo z pole BKPF-BLART v tabulce hlavičky dokladu. Příklady KRREKG | |||
| Uplatněná sleva DiscountTaken | Logická hodnota určující, zda byla úspěšně uplatněna sleva za včasnou platbu. | ||
| Popis Tento atribut určuje, zda byla při úhradě faktury skutečně uplatněna skonta. Je důležitý pro měření finanční efektivity procesu závazků. Tento příznak je základem KPI „Míra využití slev za včasnou platbu“. Vyfiltrujte faktury, u kterých bylo možné slevu získat podle platebních podmínek, a analyzujte tento příznak. Zjistíte tak přesnou výši dosažených úspor i počet nevyužitých příležitostí. Získáte jasné a měřitelné vyhodnocení výkonnosti procesu závazků. Proč je to důležité Přímo měří, jak úspěšně využíváte dostupné slevy za včasnou platbu, které mají přímý dopad na hospodářský výsledek společnosti. Kde data získat Odvozuje se z toho, zda je částka slevy v poli BSEG-SKNTO na platebním dokladu vyšší než nula. Příklady truefalse | |||
Aktivity při zpracování faktur dodavatelů
| Aktivita | Popis | ||
|---|---|---|---|
| Faktura schválena | Faktura získala všechna potřebná schválení v systému workflow. Často jde o poslední krok před zaúčtováním faktury nebo zrušením blokace platby. | ||
| Proč je to důležité Tento důležitý milník označuje konec schvalovacího cyklu. Doba mezi předáním ke schválení a schválením je důležitým ukazatelem efektivity. Kde data získat Zaznamenává se v protokolech SAP Business Workflow jako dokončení nebo závěrečné uvolnění. Lze ji také odvodit z odstranění blokace platby po předání faktury ke schválení. Zachycení Z protokolů SAP workflow načtěte události dokončení workflow nebo vyhledejte závěrečnou událost „release“. Typ události explicit | |||
| Faktura stornována | Doklad faktury byl stornován, čímž se zrušil jeho finanční dopad. Jde o alternativní konec procesu, často způsobený chybným zadáním nebo sporem s dodavatelem. | ||
| Proč je to důležité Sledování storen pomáhá odhalit příčiny selhání procesu, například duplicitní podání nebo nesprávné údaje na faktuře, a může upozornit na problémy v předchozích krocích. Kde data získat Událost se výslovně zaznamená při vytvoření stornovacího dokladu. V hlavičce původního dokladu (BKPF) se vyplní číslo stornovacího dokladu (STBLG) a důvod storna. Zachycení Zjistěte datum účtování stornovacího dokladu, na který odkazuje hlavička původního dokladu (BKPF-STBLG). Typ události explicit | |||
| Faktura zablokována k platbě | Systém fakturu zablokoval automaticky nebo ručně, a tím zabránil její úhradě. Důvodem bývají nesrovnalosti v ceně či množství nebo chybějící schválení. | ||
| Proč je to důležité Jde o důležitý ukazatel problémů a opakované práce. Analýza důvodů a délky blokace pomáhá odhalit příčiny prodlev při platbách a neefektivní postupy. Kde data získat Tento stav je výslovně zaznamenán v poli klíče blokace platby (ZLSPR) na položce dodavatele v účetním dokladu (tabulka BSEG). Zachycení Zaznamenává se prostřednictvím změnových dokladů, když je v poli BSEG-ZLSPR uveden důvod blokace. Typ události explicit | |||
| Faktura zaúčtována | Faktura je formálně zaúčtována do hlavní knihy a vzniká finanční závazek. Odložený doklad se změní na zaúčtovaný nebo se doklad zaúčtuje přímo. | ||
| Proč je to důležité Jde o důležitý finanční milník. Potvrzuje závazek společnosti zaplatit a často je podmínkou pro naplánování platby. Kde data získat Událost se určuje podle data účtování (BUDAT) v hlavičce dokladu (BKPF). Zaúčtovaný doklad má pole stavu dokladu (BKPF-BSTAT) prázdné. Zachycení U dokladů, které nejsou odložené (BKPF-BSTAT je prázdné), použijte datum účtování (BKPF-BUDAT). Typ události explicit | |||
| Platba provedena | Faktura byla uhrazena. Událost se zaznamená po dokončení platebního běhu a vytvoření a zaúčtování platebního dokladu. | ||
| Proč je to důležité Tato aktivita je důležitá pro analýzu peněžních toků a měření KPI „Podíl včasných plateb“ porovnáním data platby s datem splatnosti faktury. Kde data získat Zaznamenává se podle data účtování platebního dokladu, kterým se faktura vyrovná. Číslo platebního dokladu je propojeno s fakturou v poli vyrovnávacího dokladu (AUGBL) na její položce (BSEG). Zachycení Zjistěte datum účtování (BUDAT) platebního dokladu, kterým se vyrovná položka faktury. Typ události explicit | |||
| Platba vyrovnána | Tato aktivita označuje konečné uzavření faktury. Platba a faktura se vzájemně vyrovnají v pomocné knize. Proces je tím dokončen. | ||
| Proč je to důležité Jako jednoznačný konec procesu je tato aktivita nezbytná pro přesný výpočet celkové doby zpracování. Potvrzuje, že závazek byl uhrazen. Kde data získat Jde o výslovně zaznamenanou událost. Nastane, když je na položce dodavatele v dokladu faktury (tabulka BSEG) vyplněno pole data vyrovnání (AUGDT). Zachycení Na položce faktury použijte datum vyrovnání (BSEG-AUGDT). Typ události explicit | |||
| Přijetí faktury | Tato aktivita označuje vytvoření dokladu faktury v SAP, ručně nebo prostřednictvím automatizovaného rozhraní, například OCR/VIM. Událost se obvykle zaznamenává podle data a času vytvoření hlavičky účetního dokladu. | ||
| Proč je to důležité Jako počáteční bod procesu je tato aktivita nezbytná pro výpočet celkové doby zpracování faktury a měření průchodnosti celého procesu závazků. Kde data získat Událost se zaznamenává z tabulky hlaviček účetních dokladů (BKPF) pomocí data vytvoření dokladu (CPUDT) a času vytvoření (CPUTM). Zachycení U dokladu faktury použijte časové razítko vytvoření (BKPF-CPUDT, BKPF-CPUTM). Typ události explicit | |||
| Faktura předána ke schválení | Faktura byla podle obchodních pravidel předána do workflow ke schválení. Tím začíná dílčí proces schvalování. | ||
| Proč je to důležité Tato aktivita je výchozím bodem pro měření KPI „Průměrná doba schválení faktury“ a analýzu úzkých míst při schvalování. Kde data získat Lze ji zaznamenat z protokolů SAP Business Workflow (tabulky SWW*), které evidují zahájení instance workflow propojené s objektem faktury, například BUS2081. Zachycení Z protokolů SAP workflow, například z tabulky SWW_WIHEAD, načtěte události zahájení workflow propojené s dokladem faktury. Typ události explicit | |||
| Faktura spárována s objednávkou | Tato aktivita označuje úspěšné spárování faktury s příslušnou objednávkou. Jde o důležitý krok třístranného párování faktur souvisejících s nákupem. | ||
| Proč je to důležité Analýza této aktivity pomáhá měřit efektivitu párování a je základem KPI „Výkonnost třístranného párování“ a „Podíl faktur bez objednávky“. Kde data získat Událost se odvozuje z platného čísla objednávky (EBELN) a položky (EBELP) na položce faktury v tabulce BSEG nebo ACDOCA. Zachycení Odvozuje se z přítomnosti odkazu na objednávku (BSEG-EBELN) v dokladu faktury při jeho vytvoření. Typ události inferred | |||
| Faktura spárována s příjemkou | Tato aktivita označuje úspěšné spárování množství a hodnot na faktuře s příslušným dokladem o příjmu zboží. Jde o závěrečnou kontrolu při třístranném párování. | ||
| Proč je to důležité Sledování této aktivity pomáhá odhalit neefektivní místa v třístranném párování a nesrovnalosti mezi přijatým zbožím a fakturou dodavatele. Kde data získat Událost se odvozuje z odkazu na materiálový doklad (příjem zboží) na položce faktury, často propojeného prostřednictvím historie položky objednávky. Zachycení Odvozuje se z odkazu na doklad o příjmu zboží na položce faktury, například v RSEG u faktur MIRO. Typ události inferred | |||
| Faktura zamítnuta | Schvalovatel zamítl fakturu během schvalovacího workflow. Faktura se obvykle vrátí zpracovateli k opravě nebo doplnění informací. | ||
| Proč je to důležité Sledování zamítnutí odhaluje opakovanou práci ve schvalovacím procesu a může upozornit na nedodržování pravidel nebo nesprávné zaúčtování faktury. Kde data získat Zaznamenává se jako konkrétní výsledek v protokolech SAP Business Workflow propojených s fakturou. Zachycení Z protokolů SAP workflow načtěte události se stavem „rejected“. Typ události explicit | |||
| Nesrovnalost vyřešena | Tato aktivita označuje, že dříve zjištěný problém, který pravděpodobně vedl k blokaci platby, byl prošetřen a vyřešen. Zaznamená se při odstranění blokace platby z faktury. | ||
| Proč je to důležité Sledování tohoto cyklu oprav je důležité pro dashboard „Analýza oprav nesrovnalostí na fakturách“. Pomáhá vyčíslit čas a úsilí vynaložené na opravy chyb. Kde data získat Událost se odvozuje ze změnových dokladů, které ukazují odstranění blokace platby. Hlavním zdrojem je protokol změn pole BSEG-ZLSPR. Zachycení Vyhledejte změnové doklady pro tabulku BSEG, ve kterých se hodnota pole ZLSPR změnila na prázdnou. Typ události inferred | |||
| Odložení faktury | Faktura byla zadána do systému, ale dosud nebyla zaúčtována do hlavní knihy. Tento krok se často používá k uložení neúplného dokladu, který se později doplní nebo schválí. | ||
| Proč je to důležité Sledování odložených faktur pomáhá odhalit prodlevy před zahájením formálního účtování a upozornit na neúplná data nebo problémy při počáteční kontrole. Kde data získat Tento stav se odvozuje z pole stavu dokladu v hlavičce účetního dokladu (BKPF-BSTAT = 'V' pro odložený doklad). Událost nastane při nastavení tohoto stavu. Zachycení Vyhledejte změnové doklady pro tabulku BKPF, ve kterých je pole BSTAT nastaveno na 'V' (Vor-erfasst/Pre-entered). Typ události inferred | |||
| Uplynulo datum splatnosti faktury | Vypočítaná událost označuje, že uplynulo čisté datum splatnosti faktury a platba dosud nebyla vyrovnána. Znamená to, že platba je opožděná nebo po splatnosti. | ||
| Proč je to důležité Tato aktivita je důležitá pro dashboard „Shoda plateb a doba po splatnosti“. Pomáhá včas odhalit a řešit faktury po splatnosti a analyzovat příčiny opožděných plateb. Kde data získat V SAP nejde o výslovně zaznamenanou událost. Vypočítá se porovnáním aktuálního systémového data s čistým datem splatnosti, které se určuje z BSEG-ZFBDT nebo základního data a platebních podmínek. Zachycení Vypočítaná událost nastane, když je časové razítko události pozdější než čisté datum splatnosti faktury. Typ události calculated | |||
| Vytvořen návrh platby | Faktura byla zařazena do návrhu platby v rámci platebního běhu, například F110. Je připravena k úhradě po závěrečném spuštění běhu. | ||
| Proč je to důležité Tato aktivita zachycuje přechod od otevřeného závazku k položce připravované k úhradě a pomáhá analyzovat efektivitu platebního provozu. Kde data získat Událost se výslovně zaznamenává v tabulkách dat platebního běhu, zejména REGUP (zpracované položky platebního programu) a REGUH (hlavička). Zachycení Zjistěte, kdy se faktura objeví v tabulce REGUP v rámci platebního běhu uvedeného v REGUH. Typ události explicit | |||
Návody k extrakci dat
Kroky
- Předpoklady a přístup: Zajistěte si uživatele s přístupem pro čtení ke schématu databáze SAP S/4HANA (obvykle SAPABAP1 nebo podobnému), ve kterém jsou uloženy CDS View. Budete potřebovat SQL klienta, který se připojí k databázi SAP HANA, například SAP HANA Studio, DBeaver nebo jiný nástroj pro práci s databázemi.
- Určete hlavní CDS View: Pro extrakci se používají především tato CDS View: I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails a I_PaymentProposalItem. Seznamte se s jejich hlavními poli.
- Vymezte rozsah dotazu: Otevřete SQL klienta a připojte se k databázi SAP HANA. Než spustíte celý dotaz, určete rozsah extrakce. Nastavte správný identifikátor zdrojového systému, období faktur podle CreationDateTime a příslušné kódy společností.
- Připravte hlavní dotaz: Zkopírujte celý SQL dotaz z příslušné části do SQL klienta. Dotaz nejprve pomocí Common Table Expressions (CTE) vybere základní soubor faktur a poté sestaví záznam událostí spojením dat pro 15 různých aktivit.
- Nastavte parametry dotazu: V zkopírovaném SQL dotazu najděte zástupné proměnné. Nahraďte '[YYYY-MM-DD]' počátečním a koncovým datem analyzovaného období. Hodnoty '[Your Company Code 1]' a '[Your Company Code 2]' nahraďte seznamem kódů společností SAP, které chcete analyzovat.
- Spusťte extrakční dotaz: Spusťte celý SQL dotaz. V závislosti na objemu dat a zvoleném období může zpracování trvat několik minut až několik hodin.
- Zkontrolujte předběžné výsledky: Po dokončení dotazu zkontrolujte prvních několik set řádků. Ověřte konzistenci dat, očekávané hodnoty ve všech sloupcích a přítomnost různých hodnot ActivityName.
- Exportujte záznam událostí: Exportujte celou sadu výsledků z SQL klienta do souboru CSV. Použijte kódování UTF-8, aby se předešlo problémům se znaky. Soubor pojmenujte výstižně, například sap_s4hana_ap_event_log.csv.
- Připravte data k nahrání: Před nahráním do nástroje process mining ověřte, že názvy sloupců v souboru CSV přesně odpovídají požadovaným názvům atributů: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName atd.
- Nahrajte data do nástroje process mining: Nahrajte vytvořený soubor CSV do platformy process mining a namapujte sloupce na odpovídající pole identifikátoru případu, aktivity a časového razítka.
Konfigurace
- Hlavní CDS View: Extrakce využívá kombinaci standardních CDS View v S/4HANA. Hlavní pohledy jsou:
- I_JournalEntry a I_JournalEntryItem: Záhlaví a položky finančních dokladů, údaje o zaúčtování a informace o vyrovnání.
- I_SupplierInvoiceAPI01: Podrobnosti o fakturách MM (logistika), včetně odkazů na objednávky a blokací plateb.
- I_ChangeDocument: Přesné časové údaje o změnách, například nastavení nebo zrušení blokace platby.
- I_WorkflowStatusDetails: Události související se schvalovacím workflow faktur.
- I_PaymentProposalItem: Informace o zařazení faktury do návrhu platebního běhu.
- I_Supplier: Údaje o dodavateli, například VendorName.
- Filtrování podle období: Omezení objemu dat pomocí filtru období je zásadní. Uvedený dotaz filtruje podle CreationDateTime v CTE Invoices_Base. Pro první analýzu doporučujeme období 3 až 6 měsíců, aby byl objem dat zvládnutelný.
- Povinné filtry: Vždy filtrujte podle CompanyCode. Analýza všech kódů společností najednou může být velmi pomalá a nemusí přinést užitečné výsledky. Filtrujte také podle JournalEntryType a vyberte pouze doklady související s dodavateli, například 'KR' nebo 'RE'.
- Předpoklady: Databázový uživatel spouštějící dotaz musí mít oprávnění SELECT pro všechna použitá CDS View i pro podkladové schéma HANA. Přístup v SAP GUI na úrovni aplikace nestačí.
- Výkon: Přímé dotazy na I_ChangeDocument mohou výrazně zatěžovat zdroje. Uvedený dotaz omezuje zátěž tím, že nejprve předfiltruje faktury. U velmi rozsáhlých datových sad zvažte spuštění extrakce mimo špičku nebo po menších časových úsecích.
Ukázkový dotaz sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X'; Kroky
- Ověřte, že máte přímý přístup pro čtení ke schématu SAP HANA s příslušnými tabulkami SAP S/4HANA. Získejte připojovací řetězec, přihlašovací údaje, název schématu a oprávnění ke čtení tabulek BKPF, ACDOCA a dalších tabulek používaných pro odložené doklady, workflow, nákup, příjem zboží, návrhy plateb, vyrovnání a storna.
- Před spuštěním ověřte technický datový model cílového systému. Zkontrolujte fyzické názvy, klíčová pole, časová pole, vazby na storna a platby i způsob ukládání workflow. Každý zástupný údaj v hranatých závorkách nahraďte odpovídajícím objektem nebo polem ze systému. Nepředpokládejte, že workflow nebo data odložených dokladů jsou uložena v jediné univerzální tabulce.
- Nastavte parametry extrakce: [Start date], [End date], [Company code filter], [Document type filter] a [Schema name]. Začněte obdobím tří až šesti měsíců a prodlužte ho až po ověření výkonu a úplnosti dat.
- Spusťte SQL dotaz v autorizovaném SQL klientovi pro SAP HANA, například SAP HANA Database Explorer nebo jiném schváleném nástroji. Dotaz vytvoří jeden řádek pro každou výslovně extrahovanou aktivitu. ProcessMind události nedopočítává.
- Ověřte výslednou sadu dat. Zkontrolujte, že Invoice slouží jako identifikátor případu, ActivityName obsahuje všech 15 požadovaných názvů aktivit, EventTime je vyplněné a časově věrohodné, SourceSystem označuje SAP S/4HANA a LastDataUpdate obsahuje čas aktualizace extrakce. Před načtením zkontrolujte duplicitní události, vazby na storna a spojení dokladů.
- Proveďte případná mapování specifická pro systém. Namapujte například nakonfigurovaný zdroj odložených dokladů na Invoice Parked, zdroj workflow na Invoice Routed For Approval, Invoice Approved a Invoice Rejected a zdroj plateb na Payment Proposal Created a Payment Executed. Pokud potřebujete auditní stopu, ponechte identifikátory zdrojů v dalších sloupcích.
- Exportujte výsledek jako soubor s oddělovači nebo sadu výsledků databázového dotazu, vždy s jednou událostí na řádek. Použijte kódování UTF-8, sjednoťte časové pásmo časových údajů a zachovejte přesné názvy sloupců Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber a InvoiceDueDate. Neslučujte aktivity podle faktury.
- Nahrajte záznam událostí do ProcessMind a nastavte Invoice jako identifikátor případu, ActivityName jako sloupec aktivity a EventTime jako sloupec času události. Ověřte mapování volitelných atributů na odpovídající pole. ProcessMind načítá záznam událostí beze změn, proto před nahráním zajistěte, aby každý zobrazovaný typ aktivity měl vlastní řádek.
Konfigurace
- Období: Začněte třemi až šesti měsíci. Podle extrahované aktivity použijte datum zaúčtování, datum vytvoření dokladu nebo datum příslušné události ve zdroji. Období prodlužte až po ověření doby běhu dotazu a doby uchovávání dat ve zdroji.
- Filtr společností: Nastavte [Company code filter] tak, aby extrakce zahrnovala požadované kódy společností. Pokud omezení není potřeba, použijte řízený výběr všech společností, nikoli neomezený dotaz v produkčním prostředí.
- Filtr dokladů: [Document type filter] nastavte až po ověření typů dokladů používaných v cílovém systému pro faktury dodavatelů, dobropisy, odložené doklady, platební doklady a storna.
- Mapování schématu a objektů: Nahraďte [Schema name] a všechny zástupné názvy zdrojových objektů a polí hodnotami ověřenými v cílovém systému SAP S/4HANA. Přímý dotaz HANA je nutné přizpůsobit aktivovaným aplikacím, rozšířením, návrhu workflow a datovému modelu systému.
- Práce s časovými údaji: Převeďte všechna zdrojová časová razítka do jednoho časového pásma. Pokud je k dispozici pouze datum, použijte zdokumentovaný výchozí čas a toto omezení uveďte v datovém slovníku.
- Význam událostí: Každou aktivitu extrahujte jako samostatný řádek. Neslučujte více aktivit do jednoho záznamu faktury a neočekávejte, že ProcessMind odvodí události párování, schválení, splatnosti nebo vyrovnání.
- Událost splatnosti: Událost Invoice Due Date Passed vytvořte pouze u faktur, jejichž datum splatnosti předchází nastavenému času vyhodnocení a u kterých do tohoto času nedošlo k vyrovnání. Pro výpočet dotaz používá [Evaluation timestamp].
- Výkon: Omezte počáteční období a rozsah společností, filtrujte podle indexovaných polí nebo polí relevantních pro dělení tabulek, nevybírejte zbytečně mnoho sloupců a dotaz spouštějte ve schváleném čase pro reporting. Pokud dotaz v produkčním prostředí překročí dohodnutou dobu běhu, zvažte přípravu podmnožin zdrojových dat.
- Aktualizace dat: LastDataUpdate nastavte na čas spuštění extrakce. Při přírůstkovém načítání uchovávejte časovou značku poslední změny v příslušném zdroji a zahrňte i předchozí období, aby se zachytily pozdější aktualizace a storna.
- Předpoklady: Potřebujete požadovaná databázová oprávnění, schválený přístup do produkčního prostředí, znalost konfigurace Universal Journal v systému, přístup ke konfigurovaným zdrojům odložených dokladů, nákupu, příjmu zboží, workflow, plateb, vyrovnání a storen a případná potřebná schválení licencí SAP nebo správy systému.
Ukázkový dotaz sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Kroky
- Specifikace a návrh: Před programováním se s obchodními analytiky dohodněte na přesných podmínkách spuštění a datových polích pro všech 15 požadovaných aktivit. Určete příslušné tabulky SAP, typy dokladů (například 'KR' a 'RE') a kódy společností, které zahrnete do rozsahu.
- Vytvořte program ABAP: Otevřete editor ABAP pomocí transakčního kódu SE38. Vytvořte nový spustitelný program, například Z_PM_AP_INVOICE_EXTRACT. Zadejte výstižný název a nastavte oblast aplikace na 'Financial Accounting'.
- Definujte výběrovou obrazovku: V programu pomocí klíčových slov PARAMETERS a SELECT-OPTIONS vytvořte výběrovou obrazovku. Uživatelé na ní zadají období extrakce podle data vytvoření faktury, cílové kódy společností (BUKRS) a příslušné typy dokladů faktur (BLART). Přidejte také parametr pro cestu k výstupnímu souboru na aplikačním serveru.
- Deklarujte data: Definujte strukturu interní tabulky odpovídající konečnému formátu záznamu událostí (například TY_EVENT_LOG) včetně všech požadovaných a doporučených atributů. Deklarujte interní tabulky pro data z různých zdrojových tabulek SAP, například BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS a REGUH.
- Vyberte hlavní data: Začněte extrakci výběrem hlavní sady faktur z RBKP (logistické faktury) a BKPF (finanční faktury) podle kritérií zadaných na výběrové obrazovce. Klíče těchto faktur uložte do interní tabulky, která poslouží pro další vyhledávání.
- Postupně extrahujte aktivity: U každé faktury z hlavní sady vyhledejte časové údaje a podrobnosti jednotlivých obchodních aktivit. Například v CDHDR a CDPOS vyhledejte změny blokace platby, v REGUH a REGUP data platebního běhu a v BKPF podrobnosti o stornovacím dokladu. Každou nalezenou aktivitu přidejte jako nový záznam do výsledné tabulky událostí.
- Vypočítejte odvozené události: V ABAP implementujte logiku pro aktivity, které nejsou přímo uložené v poli tabulky. U události 'Invoice Due Date Passed' použijte datum splatnosti faktury (BSEG-ZFBDT + platební podmínky) a datum vyrovnání (BSEG-AUGDT). Pokud k vyrovnání dojde po datu splatnosti, vytvořte nový záznam události s časovým údajem nastaveným na datum splatnosti.
- Transformujte a doplňte data: Při shromažďování dat pro jednotlivé aktivity vyplňte všechny požadované atributy. Vyhledejte například názvy dodavatelů v LFA1, spojte datum a čas do jednoho řetězce časového razítka (CONCATENATE...INTO...) a nastavte hodnotu SourceSystem.
- Vytvořte výstupní soubor: Po zpracování všech faktur a souvisejících aktivit použijte příkazy OPEN DATASET, LOOP AT ... TRANSFER a CLOSE DATASET k zápisu dat do souboru na cestě aplikačního serveru zadané na výběrové obrazovce.
- Stáhněte soubor a připravte ho k nahrání: Pomocí transakčního kódu CG3Y stáhněte vytvořený soubor z aplikačního serveru do místního počítače. Uložte ho jako soubor CSV v kódování UTF-8. Před nahráním do nástroje process mining ověřte, že názvy sloupců odpovídají požadovaným atributům (Invoice, ActivityName, EventTime atd.).
Konfigurace
- Období: Definujte výběrovou volbu P_CPUDT pro datum vytvoření faktury (BKPF-CPUDT nebo RBKP-CPUDT). Pro první analýzu doporučujeme data za 6 až 12 měsíců.
- Kód společnosti (P_BUKRS): Povinný parametr SELECT-OPTIONS pro filtrování konkrétních kódů společností. Zpracování všech společností najednou nedoporučujeme, pokud to není nezbytné.
- Typ dokladu faktury (P_BLART): Parametr SELECT-OPTIONS pro filtrování příslušných typů dokladů faktur. Mezi běžné typy patří 'KR' (faktura dodavatele), 'KG' (dobropis dodavatele) a 'RE' (ověření logistické faktury).
- Režim spuštění: Při zpracování velkého objemu dat spouštějte program jako úlohu na pozadí (SM36/SM37), abyste předešli vypršení časového limitu v dialogovém režimu. Naplánujte spuštění mimo špičku.
- Cesta k výstupnímu souboru: Parametr určuje cestu a název souboru na aplikačním serveru SAP, například ve složce /tmp/. Soubor se sem uloží před stažením.
- Předpoklady: Uživatel spouštějící report musí mít oprávnění ke čtení tabulek FI, CO a MM (BKPF, BSEG, RBKP, RSEG, LFA1), tabulek změnových dokladů (CDHDR, CDPOS) a tabulek workflow. K zápisu souborů na aplikační server je navíc potřeba objekt oprávnění S_DATASET.
Ukázkový dotaz abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM. Chcete začít?
Využijte tuto šablonu jako výchozí bod pro process mining a hledejte možnosti, jak zefektivnit provoz závazků vůči dodavatelům. Začněte analyzovat a zlepšovat proces ještě dnes.
Omezte poplatky z prodlení: zlepšete zpracování faktur dodavatelů
Snižte náklady na zpracování až o 60 % a snadno odhalte duplicitní platby.
Platební kartu nepotřebujete. Začít můžete během několika minut.