Datová šablona pro proces od nákupu k platbě: zpracování faktur
Datová šablona pro proces od nákupu k platbě: zpracování faktur
- Doporučené atributy ke shromáždění
- Důležité aktivity ke sledování
- Doporučení k extrakci dat ze SAP S/4HANA
Atributy procesu od nákupu k platbě: zpracování faktur
| Název | Popis | ||
|---|---|---|---|
| Číslo faktury InvoiceNumber | Jedinečný identifikátor fakturačního dokladu dodavatele, který slouží jako hlavní identifikátor případu v procesu. | ||
| Popis Číslo faktury je jedinečný identifikátor přidělený každé faktuře dodavatele v SAP S/4HANA. Propojuje všechny související činnosti, například vytvoření, předběžné zaúčtování, schválení a platbu, do jednoho uceleného případu. V process mining je tento atribut zásadní pro sledování průchodu každé faktury procesem od začátku do konce. Umožňuje rekonstruovat celý tok procesu od přijetí až po konečnou platbu a analyzovat dobu průchodu, úzká místa i odchylky u jednotlivých faktur. Proč je to důležité Jde o nezbytný identifikátor, který propojuje všechny související události a umožňuje sledovat celý životní cyklus faktury v systému. Kde data získat Jde o číslo účetního dokladu. Najdete ho v tabulce BKPF v poli BELNR. Příklady 190000000119000000451900000132 | |||
| Čas události EventTime | Přesné datum a čas, kdy k činnosti došlo. | ||
| Popis Čas události je časové razítko, které přesně zaznamenává, kdy k určité činnosti došlo. Tyto údaje jsou nezbytné pro výpočet délky trvání, doby průchodu procesem a čekání mezi jednotlivými kroky. Při analýze process mining se přesná časová razítka používají k měření výkonnostních KPI, například „Průměrná doba zpracování faktury“ a „Doba schválení faktury“. Analýza času mezi činnostmi pomáhá organizacím odhalit úzká místa, kde se faktury zdržují, a najít příležitosti ke zrychlení procesu. Proč je to důležité Toto časové razítko je základem všech časových analýz, včetně sledování výkonnosti, odhalování úzkých míst a monitorování SLA. Kde data získat Obvykle se získává z tabulek změnových dokladů CDHDR (hlavička) a CDPOS (položka), a to z polí UDATE a UTIME. U některých událostí může pocházet z dat vytvoření nebo zadání v tabulkách, jako je BKPF (CPUDT, CPUTM). Příklady 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Název činnosti ActivityName | Název obchodní činnosti nebo události, ke které u faktury došlo v určitém okamžiku. | ||
| Popis Název činnosti popisuje konkrétní krok nebo změnu stavu v průběhu zpracování faktury. Příklady: „Vytvoření fakturačního dokladu“, „Odeslání faktury ke schválení“, „Nastavení blokace platby“ a „Provedení platby“. Tento atribut je důležitý pro sestavení mapy procesu, která znázorňuje tok jednotlivých činností. Analýza jejich pořadí, četnosti a délky trvání pomáhá odhalit úzká místa, opakované zpracování a odchylky od stanoveného procesu. Tvoří základ analýzy process mining. Proč je to důležité Určuje jednotlivé kroky procesu. Díky tomu lze zobrazit mapy procesů a analyzovat jejich průběh a odchylky. Kde data získat Odvozuje se z kombinace kódů transakcí SAP (SY-TCODE), stavů objektů změnových dokladů (CDHDR/CDPOS) a konkrétních hodnot polí, které signalizují změnu stavu. Příklady Zaparkování fakturySchválení fakturyProvedení platby | |||
| Částka faktury AmountInCompanyCodeCurrency | Celková hrubá částka faktury v místní měně účetního okruhu. | ||
| Popis Tento atribut udává celkovou hodnotu faktury. Pomáhá pochopit finanční dopad a rozsah provozu spojeného se zpracováním faktur. Analýza částek faktur pomáhá upřednostnit rychlejší zpracování faktur s vysokou hodnotou, odhalit vývoj výdajů a spojit problémy v procesu s jejich finančním dopadem. Můžete například zjistit, zda se faktury s vysokou hodnotou častěji blokují nebo schvalují déle. Proč je to důležité Dodává procesu finanční kontext a umožňuje analyzovat peněžní hodnoty, například zjistit, zda se faktury s vysokou hodnotou zpracovávají jinak. Kde data získat Tato hodnota se obvykle vypočítá jako součet příslušných položek v poli WRBTR tabulky BSEG (částka v místní měně). Příklady 1500.75125000.00850.20 | |||
| Číslo dodavatele VendorNumber | Jedinečný identifikátor dodavatele, který fakturu vystavil. | ||
| Popis Číslo dodavatele identifikuje dodavatele nebo věřitele spojeného s fakturou. Propojuje fakturu s kmenovými daty dodavatele. Tento atribut je důležitý pro analýzu podle dodavatelů, například při hodnocení „Výkonnosti plateb dodavatelům“ nebo při hledání dodavatelů, jejichž faktury často obsahují problémy vedoucí k výjimkám či blokaci platby. Pomáhá řídit vztahy s dodavateli a hodnotit jejich spolehlivost. Proč je to důležité Umožňuje analyzovat výkonnost procesu podle dodavatele, odhalovat vzorce, řídit vztahy a posuzovat problémy související s dodavateli. Kde data získat Obvykle se nachází v poli LIFNR tabulky položek účetního dokladu BSEG. Příklady 100345700012V9832 | |||
| Datum splatnosti platby PaymentDueDate | Datum, do kterého musí být faktura zaplacena, aby nebyla po splatnosti. | ||
| Popis Datum splatnosti platby je vypočítané datum, do kterého je třeba zaplatit dodavateli podle data faktury a dohodnutých platebních podmínek. Jde o důležitý termín v procesu. Tento atribut je nezbytný pro KPI „Míra včasných plateb“ a dashboard „Výkonnost plateb dodavatelům“. Porovnáním skutečného data platby s datem splatnosti může společnost měřit, jak plní své platební závazky. To ovlivňuje vztahy s dodavateli i finanční pověst společnosti. Proč je to důležité Jde o hlavní měřítko včasnosti plateb, která je důležitá pro udržení dobrých vztahů s dodavateli a předcházení poplatkům z prodlení. Kde data získat Toto datum bývá přímo dostupné v položce dodavatele v poli ZFBDT tabulky BSEG (základní datum pro výpočet splatnosti). Čisté datum splatnosti se vypočítá z tohoto základního data a platebních podmínek. Příklady 2023-05-302023-06-152023-07-01 | |||
| Důvod blokace platby PaymentBlockReason | Kód označující důvod, proč je faktura blokována pro platbu. | ||
| Popis Pokud je faktura blokována pro platbu, tento atribut uvádí konkrétní důvod blokace, například „Nesoulad v množství“ nebo „Nesprávná cena“. Důvody se nastavují v SAP, aby se výjimky řešily jednotně. Tento atribut je důležitý pro dashboard „Výskyt a délka blokace platby“. Analýza četnosti jednotlivých důvodů blokace pomáhá odhalit příčiny zpoždění plateb, například problémy s konkrétními dodavateli, materiály nebo interními procesy. Na základě toho lze přijmout cílená nápravná opatření. Proč je to důležité Uvádí konkrétní příčinu blokace platby a umožňuje cílenou analýzu, která pomáhá omezit prodlevy a zvýšit podíl správného zpracování napoprvé. Kde data získat Nachází se v položce dodavatele v poli ZLSPR (klíč blokace platby) tabulky BSEG. Příklady RIA | |||
| Objednávka PurchasingDocument | Číslo objednávky, ke které se faktura vztahuje. | ||
| Popis Číslo nákupního dokladu propojuje fakturu dodavatele s původní objednávkou (PO). Toto propojení je základem třístranného párování, při kterém se faktura ověřuje proti objednávce a příjemce zboží. Analýza podle tohoto atributu pomáhá odhalit rozdíly mezi fakturami s objednávkou a bez ní. Je důležitá při hledání nesrovnalostí v párování a hodnocení efektivity nákupní části procesu. Proč je to důležité Propojuje fakturu s nákupním procesem, což je důležité pro analýzu nesrovnalostí při párování a dodržování objednávek. Kde data získat Tyto údaje se obvykle nacházejí v poli EBELN (číslo nákupního dokladu) tabulky položek dokladu BSEG. Příklady 450000123445000056784500009012 | |||
| Typ dokladu DocumentType | Kód, který rozlišuje různé typy účetních dokladů, například faktury dodavatele nebo dobropisy. | ||
| Popis Typ dokladu se v SAP používá k rozlišení různých obchodních transakcí. Například „KR“ obvykle označuje standardní fakturu dodavatele, zatímco „KG“ může označovat dobropis od dodavatele. Analýza podle typu dokladu umožňuje rozdělit proces a zjistit, jak se zpracovávají různé typy transakcí. Proces u dobropisu se například může výrazně lišit od procesu u standardní faktury. Takové rozdělení přináší přesnější a relevantnější poznatky o procesu. Proč je to důležité Pomáhá rozlišit různé typy finančních transakcí, například standardní faktury a dobropisy, které často procházejí odlišnými procesy. Kde data získat Nachází se v poli BLART tabulky hlavičky dokladu BKPF. Příklady KRREKG | |||
| Účetní okruh CompanyCode | Organizační jednotka představující právně samostatnou společnost, pro kterou se sestavuje účetní závěrka. | ||
| Popis Účetní okruh je základní organizační jednotkou v SAP Finance. Každá faktura je přiřazena ke konkrétnímu účetnímu okruhu, který určuje právní subjekt odpovědný za transakci. V process mining je filtrování nebo porovnávání podle účetního okruhu důležité pro analýzu výkonnosti procesů v různých organizačních jednotkách, právních subjektech nebo zemích. Pomáhá odhalit regionální rozdíly v efektivitě, shodě a míře automatizace a podpořit cílené zlepšování procesů. Proč je to důležité Umožňuje rozdělit a porovnat výkonnost zpracování faktur v různých právních subjektech nebo zeměpisných oblastech organizace. Kde data získat Jde o standardní pole BUKRS v tabulce hlavičky dokladu BKPF. Příklady 1000US01DE01 | |||
| Uživatelské jméno UserName | ID uživatele SAP, který činnost provedl. Může jít o osobu nebo systém. | ||
| Popis Tento atribut určuje uživatele, který provedl konkrétní transakci nebo vytvořil doklad. Může jít o ID konkrétní osoby nebo o ID systému, který spustil automatizovanou dávkovou úlohu. Analýza podle uživatelů pomáhá porozumět rozložení pracovní zátěže, určit potřeby školení a odhalit neobvyklé chování. Může například ukázat, kteří uživatelé často řeší výjimky nebo které faktury se zpracovávají automaticky, například uživatelem „BATCHUSER“. To je důležité pro výpočet KPI „Míra automatizace faktur“. Proč je to důležité Přiřazuje činnosti v procesu konkrétním uživatelům nebo systémovým účtům. Umožňuje analyzovat pracovní zátěž, porovnávat výkonnost a odhalovat automatizaci. Kde data získat Získává se například z polí BKPF-USNAM (zadáno uživatelem) nebo CDHDR-USERNAME (změnil uživatel). Příklady SMITHJMUELLERTWF-BATCH | |||
| Čas extrakce ExtractionTimestamp | Datum a čas extrakce dat ze zdrojového systému. | ||
| Popis Tento atribut zaznamenává časové razítko extrakce dat. Udává, jak aktuální jsou data analyzovaná v nástroji process mining. Při analýze pomáhá určit, jak čerstvé jsou získané poznatky. U dashboardů pro sledování provozu je důležitý, protože umožňuje ověřit, že rozhodnutí vycházejí z aktuálních informací, a účinně řídit obnovování dat. Proč je to důležité Udává aktuálnost dat a pomáhá zajistit, aby analýzy a reporty vycházely z nejnovějších dostupných informací. Kde data získat Nejde o pole SAP. Vytváří ho a přidává nástroj pro extrakci dat nebo proces ETL při načítání dat. Příklady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Číslo vyrovnávacího dokladu. ClearingDocumentNumber | Číslo dokladu, kterým se faktura vyrovná. Obvykle jde o platební doklad. | ||
| Popis Číslo vyrovnávacího dokladu propojuje otevřenou položku faktury s transakcí, která ji vyrovnala. Téměř vždy jde o platební doklad. Potvrzuje tak, že faktura byla zaplacena. Tento atribut jednoznačně propojuje fakturu s její platbou. Používá se k určení činnosti „Provedení platby“ a odpovídajícího časového razítka. To je nezbytné pro výpočet celkové doby průchodu procesem a míry včasných plateb. Proč je to důležité Potvrzuje, že faktura byla zaplacena, a propojuje ji s konkrétní platební transakcí. To je důležité pro analýzu doby průchodu procesem a výkonnosti plateb. Kde data získat Nachází se v poli AUGBL (číslo vyrovnávacího dokladu) tabulky položek dokladu BSEG. Příklady 150000000115000000231500000088 | |||
| Datum faktury InvoiceDate | Datum, kdy dodavatel vystavil fakturu. | ||
| Popis Datum faktury, označované také jako datum dokladu, je datum uvedené dodavatelem na faktuře. Podle něj a dohodnutých platebních podmínek se vypočítává datum splatnosti. Toto datum je důležité pro finanční výpočty, například pro určení stáří faktury a nároku na slevu při dřívější platbě. Je také jedním ze vstupů pro KPI „Míra využití slev za včasnou platbu“. Proč je to důležité Slouží jako základ pro výpočet platebních podmínek a data splatnosti. To je důležité pro řízení pracovního kapitálu a využití slev. Kde data získat Nachází se v poli BLDAT (datum dokladu) tabulky hlavičky dokladu BKPF. Příklady 2023-04-122023-05-152023-06-20 | |||
| Důvod storna ReversalReason | Kód označující důvod stornování fakturačního dokladu. | ||
| Popis Pokud je faktura zaúčtována chybně, často se stornuje. Kód důvodu storna vysvětluje, proč k tomu došlo, například „Nesprávné datum zaúčtování“ nebo „Chyba při zadávání údajů“. Analýza důvodů storna pomáhá odhalit opakující se chyby při zaúčtování faktur. Tyto poznatky lze využít ke zlepšení školení, posílení kontrol v systému nebo řešení opakujících se problémů, které vedou k přepracování a zbytečné administrativě. Proč je to důležité Vysvětluje, proč byly faktury stornovány, a přímo tak ukazuje zdroje chyb a opakované práce při zaúčtování. Kde data získat Nachází se v poli STGRD (důvod storna) hlavičky původního dokladu v tabulce BKPF. Příklady 010205 | |||
| ID zdrojového systému SourceSystemId | Identifikátor zdrojového systému SAP S/4HANA, ze kterého byla data extrahována. | ||
| Popis Tento atribut určuje zdrojový systém, například „S4H_PROD“ nebo „ERP_EU“. Je důležitý zejména v prostředích s více instancemi ERP nebo s kombinací starších a moderních systémů. Při analýze umožňuje porovnávat výkonnost procesů napříč systémy nebo regiony. Zajišťuje dohledatelnost původu dat a je důležitý pro správu dat i řešení problémů, pokud se data z více zdrojů spojují v jedné platformě process mining. Proč je to důležité Udává původ dat, což je důležité pro jejich správu i pro porovnávání procesů napříč systémy a pobočkami společnosti. Kde data získat Tato hodnota se obvykle získává z ID systému SAP (sy-sysid) při extrakci dat nebo se nastavuje jako statická hodnota v ETL workflow. Příklady S4PS4H_PROD_100ECC_EU | |||
| Je automatizovaná IsAutomated | Příznak označující, zda činnost provedl automatizovaný systémový uživatel. | ||
| Popis Tento booleovský atribut má hodnotu true, pokud je uživatel přiřazený k činnosti známý systémový nebo dávkový účet, například „WF-BATCH“ nebo „SAP_SYSTEM“. Pomáhá rozlišit ruční a automatizované kroky procesu. Tento atribut je nezbytný pro výpočet KPI „Míra automatizace faktur“. Analýza automatizovaných částí procesu umožňuje měřit výsledky automatizačních iniciativ, určit další příležitosti k omezení ruční práce a zvýšit efektivitu. Proč je to důležité Rozlišuje ruční činnosti od činností prováděných systémem. To je základem pro měření míry automatizace a hledání dalších příležitostí k automatizaci. Kde data získat Odvozuje se z atributu UserName. Pomocí mapování nebo pravidla se konkrétní ID uživatelů označí jako „automatizovaná“. Příklady truefalse | |||
| Platební podmínky PaymentTerms | Kód, který určuje dohodnuté podmínky platby dodavateli, například data splatnosti a období pro získání slevy. | ||
| Popis Platební podmínky stanovují pravidla úhrady faktury včetně případných slev za včasnou platbu. Například „Z030“ může znamenat „Splatnost do 30 dnů bez srážky“. Tento atribut je důležitý pro finanční plánování a optimalizaci pracovního kapitálu. V process mining se používá k výpočtu „Data splatnosti platby“ a k určení nároku na slevu za včasnou platbu. Přímo tak podporuje KPI „Míra využití slev za včasnou platbu“. Proč je to důležité Určuje pravidla pro data splatnosti a slevy, a přímo tak ovlivňuje KPI včasnosti plateb i řízení pracovního kapitálu. Kde data získat Nachází se v položce dodavatele v poli ZTERM (klíč platebních podmínek) tabulky BSEG. Příklady 0001Z030NT60 | |||
| Počet schvalovacích cyklů ApprovalCycleCount | Počet případů, kdy byla faktura odeslána ke schválení. | ||
| Popis Tato metrika počítá, kolikrát se u jedné faktury vyskytla činnost „Odeslání faktury ke schválení“. Počet vyšší než jedna znamená, že faktura byla alespoň jednou zamítnuta nebo vrácena a musela projít dalším schvalovacím cyklem. Tento atribut přímo podporuje KPI „Míra schválení napoprvé“. Analýza faktur s vysokým počtem schvalovacích cyklů pomáhá zjistit příčiny neúspěšného schválení, například chybějící údaje nebo nesprávné účtování, a najít způsoby, jak proces zlepšit. Proč je to důležité Vyčísluje opakované zpracování ve schvalovací části procesu. Pomáhá měřit podíl správného zpracování napoprvé a odhalit příčiny zamítnutí schválení. Kde data získat Vypočítá se tak, že se pro každé jedinečné InvoiceNumber spočítají výskyty činnosti „Odeslání faktury ke schválení“. Příklady 123 | |||
| Vyžaduje opakované zpracování IsRework | Příznak označující, zda se u faktury opakovaly činnosti, například zamítnutí schválení nebo zrušení blokace platby. | ||
| Popis Tento atribut označí faktury, u kterých se vyskytl jeden nebo více cyklů opakovaného zpracování. Opakované zpracování lze určit podle konkrétní posloupnosti činností, například když po „Schválení faktury“ následuje „Zamítnutí faktury“ nebo po „Nastavení blokace platby“ následuje „Odstranění blokace platby“. Atribut zjednodušuje výpočet KPI „Míra opakovaného zpracování faktur“. Analytici mohou snadno vybrat a prozkoumat případy s opakovaným zpracováním, zjistit příčiny neefektivity a omezit opakovanou ruční práci. Proč je to důležité Odhaluje neefektivní průběh procesu, při kterém se práce musí opakovat. Pomáhá vyčíslit plýtvání a určit příčiny výjimek v procesu. Kde data získat Vypočítá se podle pořadí činností v záznamu událostí. Pokud se například v průběhu zpracování faktury objeví „Zamítnutí faktury“, příznak se nastaví na true. Příklady truefalse | |||
| Zaplaceno včas IsPaidOnTime | Příznak má hodnotu true, pokud byla faktura zaplacena v den splatnosti nebo dříve. | ||
| Popis Tento booleovský atribut vzniká porovnáním skutečného data platby, tedy časového razítka činnosti „Provedení platby“, s „Datem splatnosti platby“. Pro každou fakturu tak jednoznačně určuje, zda byla zaplacena včas. Tento výpočet je základem KPI „Míra včasných plateb“. Umožňuje snadno filtrovat a analyzovat pozdní platby, například podle dodavatele, účetního okruhu nebo částky faktury. Proč je to důležité Přímo měří dodržování platebních podmínek. Jde o důležitý KPI pro řízení vztahů s dodavateli a finančního provozu. Kde data získat Vypočítá se porovnáním času události u činnosti „Provedení platby“ s atributem PaymentDueDate. (Datum platby <= PaymentDueDate). Příklady truefalse | |||
Aktivity procesu od nákupu k platbě: zpracování faktur
| Aktivita | Popis | ||
|---|---|---|---|
| Provedení platby | Jde o poslední činnost standardního procesu. Platba se provede a faktura se vyrovná. To znamená, že peníze byly odeslány dodavateli. | ||
| Proč je to důležité Tím končí životní cyklus faktury v procesu P2P. Tento údaj je nezbytný pro výpočet celkové doby průchodu procesem a měření včasnosti plateb vůči datu splatnosti. Kde data získat Událost se zaznamenává z údajů o vyrovnání položky dodavatele. Datum vyrovnání (BSEG-AUGDT) a číslo vyrovnávacího dokladu (BSEG-AUGBL) potvrzují, že platba proběhla. Zachycení Použijte datum vyrovnání (BSEG-AUGDT) z vyrovnané položky dodavatele. Typ události explicit | |||
| Schválení faktury | Tato činnost označuje schválení faktury určeným schvalovatelem. Zaznamená se po úspěšném dokončení workflow schvalování nebo po nastavení příznaku uvolnění. | ||
| Proč je to důležité Jde o důležitý milník, po kterém lze fakturu zaplatit. Zpoždění při schvalování jsou častým úzkým místem. Sledováním této činnosti můžete určit pomalé schvalovatele nebo kroky procesu. Kde data získat Událost lze odvodit z posledního kroku uvolnění v SAP workflow nebo sledováním změn stavových polí uvolnění v tabulkách souvisejících s fakturou či nákupním dokladem. Zachycení Odvoďte událost z dokončení workflow nebo ze změny stavového pole uvolnění v dokladu. Typ události inferred | |||
| Stornování faktury | Činnost představuje storno dříve zaúčtovaného fakturačního dokladu. U chybné faktury jde o koncovou událost, po které se faktura často znovu zadá správně. | ||
| Proč je to důležité Storna upozorňují na závažné chyby, které nebyly zachyceny v dřívějších fázích procesu. Sledování jejich četnosti a příčin je důležité pro zlepšování procesů a omezení finančních nepřesností. Kde data získat Storno poznáte podle vytvoření stornovacího dokladu. V hlavičce původního dokladu (BKPF) je uvedeno číslo stornovacího dokladu (BKPF-STBLG) a naopak. Časem události je datum zaúčtování stornovacího dokladu. Zachycení Vyhledejte doklady, u kterých je vyplněno pole BKPF-STBLG, a použijte datum zaúčtování stornovacího dokladu. Typ události explicit | |||
| Vytvoření faktury | Jde o první událost, která označuje vytvoření faktury v SAP. Zachytit ji lze při uložení nové faktury uživatelem, ať už je faktura zaparkovaná, nebo dosud nezaúčtovaná. | ||
| Proč je to důležité Tato činnost označuje začátek životního cyklu zpracování faktury. Doba od této události k dalším krokům je důležitá pro měření celkové doby zpracování. Kde data získat Událost se zaznamenává podle data a času vytvoření (CPUDT, CPUTM) v tabulce hlavičky dokladu, obvykle BKPF nebo RBKP u logistických faktur. Způsob vytvoření dokládá kód transakce (BKPF-TCODE), například FB60, MIRO nebo MIR7. Zachycení U faktury použijte časové razítko vytvoření z polí BKPF-CPUDT a BKPF-CPUTM. Typ události explicit | |||
| Zaúčtování faktury | Jde o důležitou finanční událost, při které se zaparkovaná nebo schválená faktura formálně zaúčtuje do hlavní knihy. Tím se zaúčtuje závazek vůči dodavateli. | ||
| Proč je to důležité Zaúčtování je důležitým milníkem, který odděluje zadávání a schvalování údajů od finančního vypořádání. Doba od vytvoření faktury do jejího zaúčtování je důležitým ukazatelem efektivity interního zpracování. Kde data získat Tuto událost určíte podle data zaúčtování (BKPF-BUDAT) v hlavičce dokladu. U dokladů, které se nejprve předběžně zaúčtují, je časem události okamžik změny jejich stavu na zaúčtovaný. Zachycení Jako čas události použijte datum zaúčtování (BKPF-BUDAT). Typ události explicit | |||
| Aktualizace údajů faktury | Tato činnost označuje změnu faktury po jejím prvním vytvoření. K úpravám často dochází při opravách po zamítnutí nebo při odstraňování chyb. | ||
| Proč je to důležité Časté aktualizace ukazují na opakované opravy a možné problémy s kvalitou dat při zadávání. Sledováním změn můžete vyčíslit čas věnovaný opravám a odhalit nejčastější chyby. Kde data získat Změny důležitých polí se v SAP zaznamenávají do tabulek změnových dokladů CDHDR (hlavička) a CDPOS (položka). Události lze vytvořit filtrováním změn příslušného objektu faktury. Zachycení Z tabulek CDHDR a CDPOS extrahujte události změn objektu faktury. Typ události explicit | |||
| Nastavení blokace platby | Blokace se nastaví na faktuře, aby ji nebylo možné zaplatit. Důvodem bývá například nesoulad v ceně nebo množství či čekající dobropis. | ||
| Proč je to důležité Blokace plateb jsou častou příčinou pozdních úhrad a sporů s dodavateli. Pro zlepšení včasnosti plateb je důležité analyzovat četnost, dobu trvání a důvody blokací. Kde data získat Událost se zaznamenává sledováním změn pole klíče blokace platby (BSEG-ZLSPR) v položce faktury. Záznamy změn v tabulkách CDHDR a CDPOS uvádějí čas a uživatele, který blokaci nastavil. Zachycení Pomocí změnových dokladů (CDHDR/CDPOS) zjistěte, kdy bylo vyplněno pole BSEG-ZLSPR. Typ události explicit | |||
| Odeslání faktury ke schválení | Tato činnost označuje zahájení formálního workflow schvalování faktury. Obvykle ji lze odvodit ze změny stavu faktury na „čeká na schválení“ nebo z vytvoření položky workflow. | ||
| Proč je to důležité Tento okamžik slouží jako začátek měření doby schvalování. Znalost toho, kdy schvalování začíná, je nezbytná pro odhalení úzkých míst v samotném workflow. Kde data získat Obvykle ji lze odvodit ze zahájení SAP Business Workflow (tabulka SWW_WI2OBJ) propojeného s objektem faktury, například BUS2081, nebo ze změny vlastního stavového pole v hlavičce dokladu. Zachycení Odvoďte událost z vytvoření položky workflow související s fakturou. Typ události inferred | |||
| Pozdní provedení platby | Jde o vypočítanou událost, ke které dojde, když se platba faktury provede po vypočteném datu splatnosti. Určuje se porovnáním dvou datových polí. | ||
| Proč je to důležité Tato aktivita přímo slouží k výpočtu KPI včasnosti plateb a pomáhá odhalit dodavatele nebo organizační jednotky, u kterých se platby často zpožďují. Zpoždění mohou poškodit vztahy s dodavateli a vést k sankcím. Kde data získat Vypočítá se porovnáním data vyrovnání (BSEG-AUGDT) s čistým datem splatnosti. Datum splatnosti se vypočítá ze základního data (BSEG-ZFBDT) a platebních podmínek (BSEG-ZTERM). Zachycení Určete porovnáním BSEG-AUGDT > (BSEG-ZFBDT + počet dní podle platebních podmínek). Typ události calculated | |||
| Vytvoření návrhu platby | Faktura se vybere a zařadí do návrhu platby v rámci platebního běhu. Jde o první krok automatizovaného procesu platby. | ||
| Proč je to důležité Tato činnost vyjadřuje záměr provést platbu. Prodleva mezi tímto krokem a samotným provedením platby může upozornit na problémy s platebním během, schvalováním nebo komunikací s bankou. Kde data získat Údaj najdete v tabulkách platebního běhu, konkrétně v REGUP, která obsahuje položky zařazené do návrhu platby. Časové razítko poskytuje datum běhu v odpovídající tabulce REGUH. Zachycení Určete, kdy se faktura objeví v tabulce REGUP v rámci běhu návrhu platby. Typ události explicit | |||
| Zamítnutí faktury | Označuje zamítnutí faktury během schvalování. Po zamítnutí je nutné fakturu opravit a znovu odeslat ke schválení. | ||
| Proč je to důležité Zamítnutí faktur ukazuje na neefektivitu procesu a problémy s kvalitou dat. Analýza četnosti a důvodů zamítnutí pomáhá určit možnosti zlepšení a potřebu školení. Kde data získat Událost lze odvodit z konkrétních změn stavu v SAP workflow, například na „zamítnuto“, nebo z událostí, které zruší aktuální workflow schvalování a vrátí fakturu ke zpracování. Zachycení Odvoďte událost ze změn stavu workflow, které označují zamítnutí. Typ události inferred | |||
| Zaparkování faktury | Faktura byla zadána do systému, ale ještě nebyla zaúčtována do hlavní knihy. Zaparkování umožňuje uložit neúplnou fakturu nebo ji před zaúčtováním předložit ke kontrole. | ||
| Proč je to důležité Zaparkování označuje záměrné přerušení procesu. Sledováním doby a četnosti zaparkovaných faktur můžete zjistit příčiny zpoždění před zahájením zaúčtování a schvalování. Kde data získat Událost lze určit podle dokladů vytvořených parkovacími transakcemi, například MIR7 nebo FV60, případně kontrolou konkrétních stavových polí v tabulce BKPF nebo ve specializovaných tabulkách zaparkovaných dokladů, například VBKPF. Zachycení Vyhledejte doklady vytvořené parkovacími transakcemi nebo zkontrolujte, zda mají stav zaparkovaného dokladu. Typ události explicit | |||
| Zrušení blokace platby | Označuje vyřešení problému a zrušení dříve nastavené blokace platby. Fakturu lze znovu zaplatit. | ||
| Proč je to důležité Doba mezi nastavením a zrušením blokace odpovídá době řešení výjimky v procesu. Její zkrácení pomáhá zvýšit efektivitu a zlepšit vztahy s dodavateli. Kde data získat Událost se zaznamenává při vymazání pole klíče blokace platby (BSEG-ZLSPR). Změna se ukládá do tabulek CDHDR a CDPOS, které uvádějí čas zrušení blokace. Zachycení Pomocí změnových dokladů (CDHDR/CDPOS) zjistěte, kdy bylo pole BSEG-ZLSPR vymazáno. Typ události explicit | |||
Návody k extrakci dat
Kroky
- Předpoklady a oprávnění: Ověřte, že uživatel provádějící extrakci má v SAP S/4HANA potřebná oprávnění k přístupu k požadovaným CDS View (Core Data Services). Mezi důležitá zobrazení patří
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemaI_PaymentProposalItem. Uživatel musí mít také oprávnění spouštět dotazy přes zvolené rozhraní, například službu OData nebo přímé připojení SQL. - Zvolte způsob připojení: Určete, jak se připojíte k systému SAP S/4HANA a spustíte SQL dotaz. Běžné možnosti zahrnují SAP Data Services, SAP Data Intelligence, nástroj ETL třetí strany s konektorem SAP nebo přímé připojení SQL k databázi SAP HANA, pokud to bezpečnostní pravidla vaší organizace dovolují.
- Nastavte parametry extrakce: Před spuštěním dotazu určete hlavní parametry. Zadejte období extrakce, například
CreationDatemezi'YYYY-MM-DD'a'YYYY-MM-DD'. Určete také hodnotyCompanyCode, které chcete zahrnout, aby byl rozsah extrahovaných dat omezený. - Upravte SQL dotaz: Zkopírujte dodaný SQL dotaz do zvoleného SQL klienta nebo nástroje pro extrakci dat. Pečlivě zkontrolujte zástupné hodnoty, například
'{StartDate}','{EndDate}'a('{CompanyCode1}', '{CompanyCode2}'). Nahraďte je skutečnými hodnotami z předchozího kroku. Podle konfigurace SAP může být nutné upravit také názvy polí pro stav workflow. - Spusťte dotaz: Spusťte celý SQL dotaz nad databází SAP S/4HANA nebo prostřednictvím příslušné servisní vrstvy. Dotaz zahrnuje více dat a jeho spuštění může podle objemu dat a zvoleného období trvat delší dobu. Sledujte případné chyby a překročení časového limitu.
- Zkontrolujte první výsledky: Po dokončení dotazu rychle zkontrolujte výstup. Ověřte, že jsou vyplněné sloupce
InvoiceNumber,ActivityNameaEventTime. Ve sloupciActivityNameby měly být různé aktivity, nejen „Invoice Document Created“. - Zkontrolujte transformaci dat: Dotaz je sestaven tak, aby vytvořil přehledný záznam událostí. Ověřte však, že sloupec
EventTimepoužívá jednotný formát časového razítka, napříkladYYYY-MM-DDTHH:MM:SS. Dodaný dotaz podle potřeby spojuje pole data a času do jednoho časového razítka. - Exportujte data: Exportujte konečnou sadu výsledků z nástroje do souboru CSV (hodnoty oddělené čárkami). Tento formát podporují nástroje process mining, včetně ProcessMind.
- Připravte soubor k nahrání: Před nahráním ověřte, že soubor CSV používá kódování UTF-8, aby nedošlo k problémům se znaky. Zkontrolujte, že názvy sloupců přesně odpovídají požadovaným atributům:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodeatd. - Nahrajte data do ProcessMind: Nahrajte připravený soubor CSV do projektu process mining. V nastavení datového modelu namapujte sloupce souboru na odpovídající pole ID případu, názvu aktivity a časového razítka.
Konfigurace
- Použitá CDS View: Hlavními zdroji dat jsou standardní CDS View SAP. Mezi důležitá zobrazení patří
I_InvoiceDocumentpro data hlavičky,I_OperationalAcctgDocItempro finanční účtování a vyrovnání aI_ChangeDocumentspolu sI_ChangeDocumentItempro sledování historických změn atributů faktury, například blokace platby a stavu workflow. - Filtrování podle období: Kvůli výkonu je důležité filtrovat data podle konkrétního období. Dodaný dotaz obsahuje zástupnou hodnotu pro
CreationDatev zobrazeníI_InvoiceDocument. Doporučujeme začít s daty za období 3 až 6 měsíců. - Filtr podle kódu společnosti: Aby extrakce obsahovala relevantní a zvládnutelné množství dat, vždy filtrujte podle jednoho či více
CompanyCode. Dotaz pro tento účel obsahuje zástupnou podmínkuWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Filtr podle typu dokladu: Extrakci můžete dále zúžit filtrováním podle
InvoiceDocumentType. Můžete například zahrnout běžné faktury dodavatelů (RE) a vyloučit dobropisy. Filtr lze přidat do klauzuleWHEREv úvodním CTE. - Předpoklady: Uživatel spouštějící dotaz potřebuje příslušná oprávnění k zobrazení finančních a nákupních dokladů pro zadané kódy společností. Přístup k podkladové databázi HANA přes SQL klienta není standardní a vyžaduje zvláštní oprávnění.
- Dopad na výkon: Extrakce dat z tabulek změnových dokladů (
I_ChangeDocument,I_ChangeDocumentItem) může být náročná na výkon. Abyste předešli dlouhému běhu dotazu, použijte přísné filtry podle data, kódu společnosti a třídy objektu (INCOMINGINVOICE).
Ukázkový dotaz sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Kroky
- Ověřte, že máte schválený přímý přístup pro čtení k tenantovi SAP HANA nebo databázovému schématu. Získejte databázového uživatele pouze pro čtení s oprávněním k požadovaným tabulkám SAP a případným schváleným tabulkám historie změn nebo workflow. Použijte SAP HANA Database Explorer, SAP HANA Studio nebo schváleného SQL klienta. Nepoužívejte přístup pro zápis do produkčního prostředí.
- Ověřte fyzické názvy tabulek a sloupců v cílovém systému S/4HANA. ACDOCA, BKPF a RBKP jsou běžným výchozím bodem, ale workflow, odložené doklady, návrhy plateb, provedení plateb, historie změn a historie blokací plateb mohou využívat objekty závislé na verzi nebo konkrétním zákazníkovi. Každou položku v hranatých závorkách v dotazu nahraďte objekty ověřenými v katalogu systému a odpovídajícími danému obchodnímu významu.
- Určete období extrakce pomocí [Start timestamp] a [End timestamp]. Zahrňte dostatečně široké období dokladů a událostí, obvykle tři až šest měsíců. Rozšiřte je, pokud datum splatnosti nebo pozdní platby mohou spadat mimo období vytvoření faktury.
- Určete případy faktur pomocí nakonfigurovaného klíče faktury. Dotaz používá
InvoiceNumberjako identifikátor případu a v případě potřeby jej interně kombinuje s kódem společnosti a fiskálním rokem, aby nedocházelo ke kolizím. Ověřte, zda definice procesu vyžaduje zahrnout fiskální rok nebo kód společnosti také do identifikátoru případu v ProcessMind. - Namapujte zaúčtovaná data faktur z RBKP, BKPF a ACDOCA. RBKP použijte pro informace v hlavičce faktury, BKPF pro časová razítka a uživatele účetních dokladů a ACDOCA pro dodavatele, částku, nákupní doklad, vyrovnání a související účetní údaje o platbě, pokud jsou k dispozici. Nepředpokládejte, že jsou všechna pole vyplněna při každém způsobu zaúčtování.
- Namapujte události odložení, schválení, zamítnutí, aktualizace, blokace platby, storna, návrhu platby a provedení platby z ověřených zdrojů konkrétního systému. Zástupné zdrojové pohledy nahraďte schválenými pohledy nebo tabulkami, které obsahují časová razítka událostí, odkazy na faktury, uživatele, stavy a původní i nové hodnoty. Každou aktivitu je nutné zaznamenat jako samostatný řádek události, protože ProcessMind události neodvozuje.
- Spusťte celý SQL dotaz v neprodukční relaci nebo relaci pouze pro čtení. Zkontrolujte plány provádění a podle potřeby omezte dotaz podle kódu společnosti, typu dokladu, fiskálního roku a času události. Vyhněte se neomezenému spojování rozsáhlých účetních a historických tabulek.
- Ověřte výsledek podle níže uvedených kontrol. Zkontrolujte, že jsou přítomny všechny požadované sloupce,
EventTimeje vyplněný u každé události,InvoiceNumberu každého případu a všech 13 názvů aktivit se vyskytuje, pokud pro ně existují zdrojová data. - Exportujte výsledek do odděleného souboru podporovaného ProcessMind, nejlépe do CSV v kódování UTF-8. Každý řádek musí odpovídat jedné události a obsahovat sloupce
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReasonaPurchasingDocument. Zachovejte jednotné časové pásmo časových razítek a úvodní nuly v identifikátorech. - Nahrajte záznam událostí do ProcessMind a nastavte
InvoiceNumberjako identifikátor případu,ActivityNamejako sloupec aktivity aEventTimejako sloupec časového razítka. Pokud konfigurace ProcessMind podporuje další klíče případu, použijte stejné pravidlo pro složený klíč jako při extrakci.
Konfigurace
- Období: Při první extrakci použijte průběžné období tří až šesti měsíců. Zahrňte další historii, pokud ke schválení, platbě, vyrovnání, stornu nebo pozdní platbě může dojít až po období vytvoření faktury.
- Rozsah společností: Filtrujte podle [Company code filter] a ověřte, že máte oprávnění extrahovat data pro vybrané kódy společností.
- Rozsah dokladů: Filtrujte podle [Document type filter] a zahrňte typy dokladů odpovídající fakturám dodavatelů, dobropisům, odloženým fakturám a stornům v cílovém procesu.
- Identifikátor případu: Podle definice procesu použijte
InvoiceNumber. Pokud čísla faktur nejsou jedinečná napříč systémem, ponechte ve výsledku kód společnosti a fiskální rok nebo v modelu ProcessMind nastavte složený klíč případu. - Zdroje událostí: Ověřte fyzické zdroje změn stavu workflow, rozhodnutí o schválení, odložení, historie změn, blokací plateb, návrhů plateb a provedení plateb. Zdroje se liší podle verze S/4HANA, aktivovaných funkcí, návrhu workflow a zákaznických rozšíření.
- Pravidla pro časová razítka: Použijte čas obchodní události, nikoli čas extrakce. Zdokumentujte časové pásmo a před nahráním sjednoťte časová razítka všech událostí.
- Pravidla pro částky: Použijte částku v měně kódu společnosti a ověřte, zda vybraný zdroj jednotně ukládá znaménka debetních a kreditních částek. Nesčítejte řádky účetního deníku, dokud neověříte pravidlo agregace pro daný případ faktury.
- Pravidla pro platby: Určete, zda „Payment Executed“ znamená vyrovnání, zaúčtování platebního dokladu, provedení bankovní platby nebo jiný obchodní milník. Použijte zdroj odpovídající dohodnuté definici procesu.
- Pozdní platba: Událost „Late Payment Executed“ zaznamenejte pouze tehdy, pokud k události „Payment Executed“ dojde po
PaymentDueDate. Dotaz tuto událost vypočítává výslovně a nespoléhá na odvozování v ProcessMind. - Výkon: Omezte čtení zdrojů podle data, kódu společnosti, typu dokladu a příslušného fiskálního roku. Načítejte jen potřebné sloupce, kontrolujte plány dotazů a u rozsáhlé historie podle potřeby vytvořte schválené mezilehlé pohledy.
- Předpoklady: Přímé připojení k SAP HANA, oprávnění ke čtení všech vybraných objektů, oprávnění kontrolovat metadata a přístup k příslušným datům závazků, hlavní knihy, nákupu, workflow a plateb. Ověřte, že jsou zajištěny potřebné licence SAP, pravidla přístupu k databázi a schválení ochrany dat.
- Zabezpečení: Používejte technického uživatele pouze pro čtení, chraňte údaje o dodavatelích a platbách a dodržujte pravidla organizace pro transporty, audit, maskování a správu přihlašovacích údajů.
Ukázkový dotaz sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Kroky
- Otevřete editor ABAP: Přihlaste se do systému SAP S/4HANA. Otevřete transakci
SE38(editor ABAP). - Vytvořte program: Do pole Program zadejte název nového programu, například
Z_PM_INVOICE_EXTRACT, a klikněte na tlačítko „Vytvořit“. Zadejte název, nastavte typ na „Spustitelný program“ a uložte jej do vhodného balíčku. - Definujte strukturu programu a výběrovou obrazovku: V editoru definujte datové struktury pro výstupní záznam událostí. Poté vytvořte výběrovou obrazovku, na které uživatelé zadají parametry, například období data zadání faktury, kódy společností a typy dokladů. Program tak bude možné opakovaně používat a snadno upravovat.
- Naprogramujte výběr dat: Napište základní příkazy ABAP SQL pro výběr dat z různých tabulek SAP. Program postupně načte data pro každou z 13 požadovaných aktivit.
- Extrahujte data hlaviček a položek: U základních událostí, jako jsou „Vytvoření faktury“ a „Zaúčtování faktury“, načtěte data z hlavních tabulek, například
RBKP(hlavička logistické faktury) aBKPF(hlavička účetního dokladu). - Extrahujte data změnových dokladů: U aktivit, jako jsou „Nastavení blokace platby“ a „Odebrání blokace platby“, načtěte data z tabulek změnových dokladů
CDHDR(hlavička změnového dokladu) aCDPOS(položky změnového dokladu). Bude třeba určit změny konkrétních polí, napříkladZLSPRv tabulceBSEG. - Extrahujte údaje o platbách: Pro zachycení platebních aktivit načtěte například tabulku
REGUP(zpracované položky platebního programu) pro návrhy plateb aBSAK(vyrovnané položky dodavatelů) pro provedené platby. Pozdní platbu určete porovnáním data vyrovnání (AUGDT) s datem čisté splatnosti (ZFBDT). - Extrahujte data workflow: Pro schvalovací aktivity načtěte tabulky SAP Business Workflow, například
SWW_WI2OBJ, které propojují položky workflow s objekty faktur. Tato část závisí na konkrétní konfiguraci workflow a může vyžadovat rozsáhlé úpravy. - Sjednoťte data do formátu záznamu událostí: Data každé vybrané aktivity převeďte do společné struktury interní tabulky. Každý řádek této tabulky představuje jednu událost a musí obsahovat identifikátor případu (
InvoiceNumber),ActivityNameaEventTimespolu s dalšími doporučenými atributy. - Vytvořte výstupní soubor: Pomocí příkazů ABAP
OPEN DATASET,TRANSFERaCLOSE DATASETzapište obsah výsledné interní tabulky do textového souboru na aplikačním serveru SAP. Doporučujeme formát CSV, tedy hodnoty oddělené čárkami. - Naplánujte a spusťte program: Při testování spusťte program v popředí pomocí
F8. V produkčním prostředí jej naplánujte jako úlohu na pozadí pomocí transakceSM36, ideálně mimo špičku, abyste omezili dopad na výkon systému. - Stáhněte soubor a nahrajte data: Pomocí transakce
AL11přejděte do adresáře aplikačního serveru, kam byl soubor uložen. Stáhněte jej do místního systému. Před nahráním ověřte kódování UTF-8 a správný formát souboru.
Konfigurace
- Období: Určete období extrakce podle data zadání faktury (
RBKP-CPUDT) nebo data zaúčtování (BKPF-BUDAT). Při první analýze doporučujeme období 3 až 6 měsíců, aby objem dat zůstal zvládnutelný. - Kód společnosti (BUKRS): Filtrujte podle jednoho či více kódů společností. Extrakce dat ze všech společností ve velké organizaci může trvat velmi dlouho a vytvořit rozsáhlé soubory.
- Typ dokladu (BLART): Vyfiltrujte příslušné typy dokladů, abyste oddělili faktury dodavatelů. Mezi běžné typy patří „RE“ (faktura, hrubá částka) a „KR“ (faktura dodavatele). Tím z analýzy vyloučíte nesouvisející doklady.
- Účet dodavatele (LIFNR): Program může obsahovat volitelný filtr konkrétních čísel dodavatelů, který se hodí pro cílenou analýzu nebo testování.
- Nastavení výstupního souboru: Program by měl umožnit zadat cestu k výstupnímu souboru na aplikačním serveru a oddělovač polí, například čárku nebo středník.
- Předpoklady: Uživatel nebo systémový účet spouštějící program potřebuje vývojářský přístup k vytváření a spouštění programů ABAP (přes
SE38) a rozsáhlá oprávnění ke čtení tabulek FI, MM a Basis, včetněBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSa tabulek workflow.
Ukázkový dotaz abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. Chcete začít?
Začněte optimalizovat zpracování faktur ještě dnes. Tato šablona je prvním krokem ke zlepšení provozu a vyšší efektivitě.
Optimalizujte zpracování faktur P2P v SAP S/4HANA
Najděte úzká místa a zkraťte dobu zpracování faktur o 30 % nebo více.
Platební kartu nepotřebujete. Nastavení zabere jen několik minut.