Šablona dat pro zpracování plateb závazků
Šablona dat pro zpracování plateb závazků
- Základní atributy pro analýzu dodavatelů a plateb
- Důležité milníky platebního cyklu
- Specifická logika extrakce pro systémy SAP S/4HANA
Atributy zpracování plateb závazků
| Název | Popis | ||
|---|---|---|---|
| Aktivita Activity | Konkrétní úkol nebo změna stavu události zaznamenaná u faktury. | ||
| Popis Tento atribut zachycuje jednotlivé kroky procesu během životního cyklu faktury. Zahrnuje například vytvoření a zaúčtování faktury, její blokaci a schválení i vyrovnání platby. Názvy aktivit se odvozují z transakčních kódů, záznamů změn nebo aktualizací stavu workflow ve zdrojovém systému. Při analýze toto pole slouží k mapování variant průběhu procesu. Nástroj process mining podle něj zobrazí posloupnost kroků, odhalí opakovanou práci a ukáže, kde se proces odchyluje od obvyklého průběhu. Jde o základní součást záznamu událostí. Proč je to důležité Určuje uzly v mapě procesu a umožňuje zobrazit workflow i úzká místa. Kde data získat Odvozeno z transakčních kódů (TCODE) nebo z hlavičky změnového dokladu (CDHDR) a jeho položky (CDPOS) Příklady Faktura zaúčtovánaNastavena blokace platbyProvedení platebního běhuFaktura vyrovnána | |||
| Čas události EventTime | Přesné časové razítko okamžiku, kdy k aktivitě došlo. | ||
| Popis Čas události zaznamenává přesné datum a čas, kdy byla aktivita zapsána do databáze SAP. Umožňuje chronologicky seřadit události v rámci případu. Časové razítko se obvykle sestavuje z polí CPU Date a CPU Time v systémových protokolech nebo hlavičkách dokladů. Při analýze je tento atribut nezbytný pro výpočet doby průchodu, trvání a propustnosti. Umožňuje měřit časové rozestupy mezi kroky, například dobu od přijetí faktury po její konečné schválení. To je důležité pro odhalování úzkých míst a vyhodnocení KPI, jako je průměrná doba schválení faktury. Proč je to důležité Určuje chronologické pořadí událostí a slouží jako základ všech výpočtů výkonu založených na čase. Kde data získat Tabulka SAP BKPF, pole CPUDT (datum zadání) a CPUTM (čas zadání), nebo pole UDATE a UTIME v CDHDR Příklady 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Číslo faktury InvoiceNumber | Jedinečný identifikátor zpracovávané faktury dodavatele. | ||
| Popis Číslo faktury je hlavním identifikátorem pro sledování životního cyklu závazku v systému SAP S/4HANA. Jde konkrétně o číslo účetního dokladu vytvořené při zaúčtování faktury do hlavní knihy. Ve standardní terminologii SAP odpovídá číslu dokladu (BELNR) v rámci konkrétního kódu společnosti a fiskálního roku. Při analýze procesů tento atribut slouží jako Case ID. Propojuje jednotlivé činnosti od přijetí a předběžného zaúčtování faktury přes různé blokace a změny až po závěrečné vyrovnání platby. Seskupením událostí podle tohoto identifikátoru mohou analytici rekonstruovat úplnou historii každého platebního závazku. Proč je to důležité Slouží jako jednoznačné Case ID, podle kterého lze zrekonstruovat celý průběh platebního procesu. Kde data získat Tabulka SAP BKPF (hlavička účetního dokladu), pole BELNR, nebo tabulka ACDOCA, pole BELNR Příklady 1900000523510000289119000006015100003002 | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko posledního načtení nebo obnovení záznamu. | ||
| Popis Poslední aktualizace dat označuje okamžik, kdy byla data úspěšně načtena do platformy process mining. Nejde o čas obchodní události, ale o aktuálnost samotné datové sady. Tento údaj je důležitý pro důvěryhodnost analytických dashboardů. Při analýze uživatelům pomáhá zjistit, jak aktuální jsou zobrazené informace. Je zvlášť důležitý při sledování dashboardů s téměř aktuálními daty, například Analýzy blokací plateb. Uživatelé tak mohou rozhodovat podle nejnovějšího stavu systému SAP S/4HANA. Proč je to důležité Informuje uživatele o aktuálnosti dat, což je důležité pro provozní dashboardy. Kde data získat Vygenerováno procesem ETL / extrakce Příklady 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Zdrojový systém SourceSystem | Identifikátor instance SAP S/4HANA, ze které data pocházejí. | ||
| Popis Tento atribut určuje konkrétní instalaci ERP nebo klienta, ze kterého byla data procesu získána. Pokud souběžně používáte více instancí SAP nebo starší systémy, pole pomáhá zachovat původ dat a porovnávat výsledky napříč systémy. Při analýze slouží jako filtr nejvyšší úrovně. Analytici díky němu oddělí data při porovnávání výkonu různých regionálních instalací nebo při ověřování konzistence dat během migrace systému. Umožňuje také správně zohlednit odchylky procesu způsobené konfigurací systému. Proč je to důležité Rozlišuje zdroje dat v prostředí s více systémy a umožňuje přesné členění. Kde data získat ID systému (SY-SYSID) z prostředí instalace SAP Příklady SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Bez ručního zásahu IsTouchless | Příznak určující, zda byla faktura zpracována bez ručního zásahu. | ||
| Popis Tento atribut se vypočítá analýzou posloupnosti událostí v případu. Případ je označen jako zpracovaný bez ručního zásahu, pokud obsahuje pouze automatizované činnosti (například uživatele „system“ nebo konkrétní transakční kódy TCODES na pozadí) a žádné ruční změny ani blokace. Při analýze jde o hlavní metriku KPI podílu faktur zpracovaných bez ručního zásahu. Organizace díky ní může sledovat výsledky automatizace a zjistit, které typy případů, například podle dodavatele nebo regionu, systém zpracuje bez zásahu člověka. Proč je to důležité Jde o hlavní ukazatel automatizace a efektivity procesu. Kde data získat Vypočítá se podle posloupnosti činností a typů uživatelů. Příklady truefalse | |||
| Částka faktury InvoiceAmount | Celková hrubá částka faktury v měně dokladu. | ||
| Popis Tento atribut vyjadřuje finanční hodnotu faktury zaznamenanou ve zdrojovém dokladu. Jde o závazek, který je třeba uhradit dodavateli. V SAP S/4HANA se obvykle ukládá do pole Částka v měně dokladu. Při analýze se částka faktury používá k určování priorit. Dashboardy, jako je Rozložení ručních zásahů, pomocí tohoto pole ukazují, zda se časově náročné ruční činnosti nevěnují fakturám s nízkou hodnotou. Organizace tak může zaměřit zlepšování procesů na transakce s vysokou hodnotou, u nichž mají selhání procesu větší finanční dopad. Proč je to důležité Vyjadřuje finanční význam případu a pomáhá určit priority při řešení neefektivit u transakcí s vysokou hodnotou. Kde data získat Tabulka SAP BKPF nebo BSEG, pole WRBTR Příklady 1500.00250.5010000.00 | |||
| Číslo dodavatele VendorNumber | Jedinečný identifikátor dodavatele spojeného s fakturou. | ||
| Popis Číslo dodavatele odpovídá konkrétnímu účtu věřitele v pomocné účetní knize SAP. Propojuje fakturu s kmenovými daty obsahujícími platební podmínky, bankovní údaje a kontaktní informace. V S/4HANA bývá často propojeno s konceptem obchodního partnera, v mnoha tabulkách se však stále používá starší název pole LIFNR. Při analýze je tento atribut základem dashboardu Shoda s platebními podmínkami dodavatelů. Analytici mohou podle něj agregovat výsledky procesu za jednotlivé dodavatele a zjistit, kteří z nich opakovaně způsobují blokace, cenové odchylky nebo zpoždění. Údaje podporují strategická rozhodnutí v oblasti nákupu i řízení vztahů s dodavateli. Proč je to důležité Umožňuje agregovat výsledky podle dodavatele a pomáhá odhalit příčiny zpoždění. Kde data získat Tabulka SAP BKPF, pole LIFNR, nebo tabulka ACDOCA, pole LIFNR Příklady 100050VEND-US-99200400 | |||
| Čisté datum splatnosti NetDueDate | Vypočtené datum, do kterého je třeba fakturu uhradit, aby se předešlo sankcím. | ||
| Popis Čisté datum splatnosti je konečný termín úhrady. Vypočítá se přičtením maximální délky platební lhůty k základnímu datu. Někdy se ukládá přímo, často se však počítá v analytických pohledech. Při analýze slouží jako hlavní referenční bod pro sledování pozdních plateb a sankcí. Porovnáním skutečného data vyrovnání s čistým datem splatnosti se vypočítá ukazatel „Počet dní po splatnosti“. Ten pomáhá vyhodnotit efektivitu týmu závazků i riziko zhoršení vztahů s dodavateli. Proč je to důležité Jde o cílový termín procesu. Jeho nedodržení může ovlivnit úvěrový rating a způsobit dodatečné náklady. Kde data získat Výpočet: základní datum + maximální počet dní splatnosti (ZBD1T/ZBD2T/ZBD3T) Příklady 2023-11-302023-12-01 | |||
| Datum vyrovnání ClearingDate | Datum, kdy byla faktura vyrovnána platbou. | ||
| Popis Datum vyrovnání zaznamenává, kdy byla otevřená položka v knize závazků vyrovnána, obvykle platebním během nebo ručním zaúčtováním platby. Tím se závazek považuje za uzavřený. Při analýze se tento atribut používá k výpočtu celkové doby průchodu procesem. Jde o časové razítko aktivity „Vyrovnání platby“, které se porovnává s čistým datem splatnosti při vyhodnocení včasnosti plateb. Údaj se přímo využívá v dashboardu Efektivita vyrovnávání plateb. Proč je to důležité Označuje dokončení platebního procesu a slouží k vyhodnocení včasnosti platby. Kde data získat Tabulka SAP BSEG nebo AUGDT, pole AUGDT Příklady 2023-11-012023-11-15 | |||
| Důvod blokace platby PaymentBlockReason | Kód označující důvod, proč je faktura zablokována pro platbu. | ||
| Popis Tento atribut obsahuje konkrétní kód důvodu, který brání automatickému platebnímu běhu v zařazení faktury. Příkladem je A pro blokaci platby, R pro kontrolu faktury nebo ruční blokace nastavená uživatelem. Při analýze je toto pole hlavním zdrojem údajů pro dashboard Analýza ručních blokací plateb. Agregace četnosti jednotlivých důvodů blokace pomáhá odhalit systémové problémy, například opakované cenové odchylky nebo chybějící příjem zboží, které zdržují platební proces. Proč je to důležité Určuje konkrétní příčinu zastavení procesu a umožňuje cíleně hledat její původ. Kde data získat Tabulka SAP BSEG, pole ZLSPR Příklady ABR* | |||
| Kód společnosti CompanyCode | Organizační jednotka, pro kterou se sestavuje rozvaha a výkaz zisku a ztráty. | ||
| Popis Kód společnosti označuje samostatnou účetní jednotku v rámci podniku. Jde o základní organizační jednotku externího účetnictví, podle které se člení finanční data. Každá faktura je přiřazena právě k jednomu kódu společnosti. Při analýze tento atribut umožňuje členit KPI podle právního subjektu nebo regionu. V dashboardech slouží k porovnání efektivity týmů závazků v různých dceřiných společnostech. Pomáhá například zjistit, zda některá pobočka používá ruční blokace plateb častěji než společnost jako celek. Proč je to důležité Člení proces podle právního subjektu a usnadňuje interní srovnávání. Kde data získat Tabulka SAP BKPF, pole BUKRS Příklady US01DE1010002000 | |||
| Platba po splatnosti IsLatePayment | Příznak určující, zda byla platba provedena po datu splatnosti bez odpočtu. | ||
| Popis Tento vypočítaný atribut má hodnotu true, pokud je datum vyrovnání pozdější než datum splatnosti bez odpočtu. Slouží jako binární ukazatel výkonnosti procesu. Při analýze se podle tohoto příznaku počítá počet případů, které nesplňují požadavky, pro KPI četnosti sankcí za pozdní platbu. Tvorbu dashboardu usnadňuje tím, že stačí spočítat hodnoty „True“, místo aby se ve vizualizaci složitě počítaly rozdíly mezi daty. Proč je to důležité Usnadňuje výpočet KPI včasnosti plateb. Kde data získat Vypočítá se takto: Clearing Date > Net Due Date Příklady truefalse | |||
| Platební podmínky PaymentTerms | Kód sjednaných podmínek platby a skonta. | ||
| Popis Platební podmínky určují, kdy je faktura splatná a zda lze při dřívější úhradě využít skonto. Tento kód, například Z001, odpovídá pravidlům jako „splatnost 30 dní“ nebo „skonto 2 % při platbě do 10 dnů, jinak splatnost 30 dní“. Přebírá se z kmenových dat dodavatele do faktury, ale lze jej změnit ručně. Při analýze je tento atribut základem dashboardů Optimalizace skonta za včasnou platbu a Shoda s platebními podmínkami dodavatelů. Systém podle něj vypočítá základní datum splatnosti a určí, zda byla platba provedena včas pro využití skonta. Proč je to důležité Určuje očekávané termíny a finanční pobídky, které jsou důležité při analýze skonta. Kde data získat Tabulka SAP BSEG, pole ZTERM Příklady Z001NT300001 | |||
| Typ dokladu DocumentType | Určuje kategorii účetního dokladu, například fakturu dodavatele, platbu nebo dobropis. | ||
| Popis Typ dokladu je v SAP dvoumístný kód, který klasifikuje účetní transakci. Mezi běžné typy patří KR pro faktury dodavatelů, KZ pro platby dodavatelům a RE pro příjem faktury brutto. Typ určuje číselnou řadu a stav polí dokladu. Při analýze se tento atribut používá k vymezení rozsahu procesu. Analytik může například vyloučit dobropisy a zaměřit se pouze na efektivitu odchozích plateb. Atribut také pomáhá zjistit skladbu zpracovávaných transakcí a podporuje dashboard Složitost variant procesu. Proč je to důležité Rozlišuje případy, například faktury a dobropisy, a umožňuje filtrovat analýzu. Kde data získat Tabulka SAP BKPF, pole BLART Příklady KRREKZKG | |||
| Uživatelské jméno UserName | ID uživatele, který provedl danou aktivitu. | ||
| Popis Uživatelské jméno zachycuje přihlašovací ID osoby nebo systémového účtu odpovědného za provedení kroku procesu. Může jít o uživatele, který ručně zadává data, nebo o ID úlohy na pozadí, například BATCH_USER, která provádí automatizované úlohy. Při analýze tento atribut umožňuje vypočítat míru automatizace aktivit. Rozlišením lidských uživatelů a systémových účtů mohou analytici měřit míru automatizace procesu. Údaj se používá také v dashboardu Rozložení ručních zásahů k posouzení pracovního vytížení týmů. Proč je to důležité Rozlišuje ruční a automatizovanou práci a umožňuje vypočítat míru automatizace. Kde data získat Tabulka SAP BKPF, pole USNAM, nebo tabulka CDHDR, pole USERNAME Příklady BSMITHWF-BATCHRJONES | |||
| Fiskální rok FiscalYear | Fiskální rok, do kterého faktura spadá. | ||
| Popis Fiskální rok je období používané pro finanční výkaznictví. Spolu s kódem společnosti a číslem dokladu tvoří složený primární klíč finančního dokladu v SAP. Při analýze je nezbytný pro jednoznačnou identifikaci případů a zároveň umožňuje meziroční srovnání. Zajišťuje, že Case ID „Číslo faktury“ zůstane jedinečné i při práci s daty za mnoho let. Proč je to důležité Technický předpoklad pro jednoznačnou identifikaci případů v SAP FI. Kde data získat Tabulka SAP BKPF, pole GJAHR Příklady 20232024 | |||
| Měna Currency | Kód měny, ve které je uvedena částka faktury. | ||
| Popis Atribut Měna určuje, v jaké měně je uvedena částka faktury, například USD, EUR nebo GBP. Umožňuje správně interpretovat finanční hodnoty a je nezbytný při agregaci dat napříč kódy společností v různých zemích. Při analýze zajišťuje správný výpočet finančních KPI. Často se používá k přepočtu hodnot na vykazovací měnu pro globální dashboardy. Bez tohoto atributu by souhrnné ukazatele, jako jsou celkové výdaje nebo průměrná hodnota faktury, v prostředí s více měnami nedávaly smysl. Proč je to důležité Doplňuje kontext finančních částek a umožňuje přesné vykazování napříč zeměmi. Kde data získat Tabulka SAP BKPF, pole WAERS Příklady USDEURGBPJPY | |||
| Nákupní doklad PurchasingDocument | Číslo objednávky spojené s fakturou. | ||
| Popis Tento atribut propojuje fakturu s předcházejícím nákupním procesem. Obsahuje číslo objednávky (PO), ke které se faktura páruje. Některé faktury, například za různé provozní výdaje, odkaz na objednávku nemají. Při analýze je toto pole důležité pro analýzu míry třístranného párování. Analytici díky němu oddělí faktury s objednávkou od faktur bez objednávky, které obvykle procházejí výrazně odlišným schvalovacím workflow. Pole také umožňuje propojit data závazků s daty nákupu a provádět process mining napříč celým procesem. Proč je to důležité Propojuje závazky s nákupem, umožňuje analyzovat třístranné párování a rozšířit analýzu procesu. Kde data získat Tabulka SAP BSEG, pole EBELN Příklady 45000012344500009876 | |||
| Nevyužitá sleva DiscountLostAmount | Peněžní hodnota dostupných, ale nevyužitých skont. | ||
| Popis Tento vypočítaný atribut vyjadřuje hodnotu nevyužité úspory. Zjišťuje se, zda byla platba provedena až po termínu pro uplatnění skonta. Pokud ano, vypočítá se hodnota nevyužité slevy jako procento z částky faktury. Při analýze jde o důležitou finanční metriku pro optimalizaci skont za včasnou platbu. Vyjadřuje náklady na neefektivitu v penězích a pomáhá doložit přínos zlepšení procesu. Proč je to důležité Vyčísluje přímou finanční ztrátu způsobenou prodlevami v procesu. Kde data získat Vypočítá se takto: Pokud Clearing Date > Discount Date, pak Invoice Amount * Discount % Příklady 30.000.00150.00 | |||
| Počet dní pro první skonto CashDiscountDays1 | Počet dní od základního data, po které lze využít první skonto. | ||
| Popis Tento atribut určuje období s nejvýhodnějšími platebními podmínkami, například „10“ v podmínce „skonto 2 % při platbě do 10 dnů, jinak splatnost 30 dní“. Hodnota pochází z podmínek uložených u položky faktury. Při analýze pomáhá určit cílové datum pro optimalizaci skonta za včasnou platbu. Pokud je faktura vyrovnána v tomto období, skonto se uplatní. Pole umožňuje vyčíslit náklady na nevyužitou příležitost způsobené pomalým zpracováním. Proč je to důležité Určuje období, během kterého lze dosáhnout finanční úspory. Kde data získat Tabulka SAP BSEG, pole ZBD1T Příklady 10140 | |||
| Procento prvního skonta CashDiscountPercentage1 | Výše skonta v procentech při úhradě během prvního období pro skonto. | ||
| Popis Tento atribut vyjadřuje finanční pobídku, kterou dodavatel nabízí za včasnou platbu, například „2“ v podmínce „skonto 2 % při platbě do 10 dnů“. Při analýze se používá k výpočtu hodnoty potenciálního skonta. Vynásobením tohoto procenta částkou faktury mohou dashboardy zobrazit celkovou částku, o kterou organizace přichází kvůli neefektivitě procesu. Údaj tak pomáhá doložit přínos automatizace. Proč je to důležité Vyčísluje potenciální úsporu v procentech a je důležitý pro výpočet návratnosti investice. Kde data získat Tabulka SAP BSEG, pole ZBD1P Příklady 2.03.00.0 | |||
| Základní datum BaselineDate | Datum, od kterého se uplatňují platební podmínky a počítá splatnost. | ||
| Popis Základní datum je výchozím bodem pro výpočet čisté splatnosti a období pro skonto. Obvykle jde o datum faktury nebo datum zaúčtování, podle konfigurace a kmenových dat dodavatele. Při analýze je toto datum technickým předpokladem pro určení stavu „Po splatnosti“. Chybné základní datum může vést k předčasným platbám s dopadem na cash flow nebo k pozdním platbám a souvisejícím sankcím. Ověření správnosti data je součástí analýzy shody s platebními podmínkami dodavatelů. Proč je to důležité Slouží jako výchozí bod pro všechny výpočty data splatnosti. Kde data získat Tabulka SAP BSEG, pole ZFBDT Příklady 2023-10-012023-10-15 | |||
Činnosti při zpracování plateb závazků
| Aktivita | Popis | ||
|---|---|---|---|
| Faktura zaúčtována | Označuje oficiální zaevidování závazku v hlavní účetní knize. Tato činnost se určuje podle časového razítka vytvoření v tabulce BKPF nebo data zápisu v tabulce ACDOCA. | ||
| Proč je to důležité Jde o hlavní výchozí bod finanční časové osy, který slouží jako základ pro analýzu splatnosti a stáří pohledávek. Kde data získat Tabulka BKPF, pole CPUDT (datum zadání) a CPUTM (čas zadání). Zachycení Zaznamená se při vytvoření záznamu v BKPF Typ události explicit | |||
| Nastavena blokace platby | Označuje, že na položce faktury byla nastavena blokace platby, která brání jejímu zařazení do platebního běhu. Změny se zjišťují sledováním pole ZLSPR v tabulce BSEG prostřednictvím změnových dokladů. | ||
| Proč je to důležité Blokace jsou hlavní příčinou pozdních plateb a komplikací v procesu. Přímo ovlivňují dashboard analýzy ručních blokací plateb. Kde data získat Tabulky CDPOS a CDHDR (změnové doklady), ve kterých se hledají změny pole BSEG-ZLSPR. Zachycení Zaznamená se při změně ZLSPR v záznamech CDPOS Typ události explicit | |||
| Provedení platebního běhu | Označuje provedení platebního běhu, při kterém se generují pokyny k převodu peněz. Sleduje se prostřednictvím aktualizace stavu v tabulkách REGUH nebo REGUP. | ||
| Proč je to důležité Závazek provést platbu, který je důležitý pro analýzu efektivity dávkového zpracování plateb. Kde data získat Tabulka REGUH, obvykle ve spojení s datem a identifikací běhu. Zachycení Zaznamenáno při aktualizaci stavu platebního běhu Typ události explicit | |||
| Vyrovnání platby | Označuje závěrečné vyrovnání otevřené položky na účtu dodavatele proti platbě. Zaznamenává se z pole AUGDT (datum vyrovnání) v tabulce BSEG. | ||
| Proč je to důležité Konečný stav procesu, který značí jeho dokončení a vyrovnané účetnictví. Vysoký podíl ručního vyrovnávání ukazuje na neefektivní odsouhlasování. Kde data získat Tabulka BSEG, pole AUGDT (datum vyrovnání). Zachycení Zaznamenáno po vyplnění pole AUGDT Typ události explicit | |||
| Vytvoření platebního dokladu | Vytvoření účetního dokladu, který připíše částku na bankovní účet a zaúčtuje ji na vrub dodavatele. Údaj najdete v tabulce BKPF u dokladů typu platba (např. ZP, KZ). | ||
| Proč je to důležité Finanční vypořádání platby, které se používá k výpočtu doby splatnosti závazků (DPO). Kde data získat Tabulka BKPF, filtrovaná podle typu dokladu (BLART) používaného pro platby. Zachycení Zaznamenáno při vytvoření platebního dokladu BKPF Typ události explicit | |||
| Zrušena blokace platby | Označuje zrušení dříve nastavené blokace platby, díky kterému lze fakturu uhradit. Zjišťuje se, když se pole ZLSPR v tabulce BSEG změní z hodnoty na prázdnou nebo nulovou. | ||
| Proč je to důležité V systémech bez výslovných záznamů workflow často slouží jako náhrada za událost „Faktura schválena“ a označuje konec období, kdy proces vázl. Kde data získat Tabulky CDPOS a CDHDR, ve kterých se hledá vymazání hodnoty BSEG-ZLSPR. Zachycení Zaznamená se při odstranění ZLSPR v záznamech CDPOS Typ události explicit | |||
| Faktura odložena | Faktura byla zadána do SAP, ale ještě nebyla zaúčtována do hlavní účetní knihy. Tento stav se často používá při předběžném zadávání dat. Lze jej zjistit přímo z tabulky VBKPF nebo podle dokladů v BKPF se stavovým kódem odloženého dokladu, než dojde k jejich zaúčtování. | ||
| Proč je to důležité Odložení faktury označuje začátek zadávání dat a pomáhá měřit dobu od přijetí faktury po vznik finančního závazku. Kde data získat Tabulka VBKPF s hlavičkovými údaji odložených dokladů nebo tabulka BKPF s konkrétním stavem dokladu (BSTAT = V). Zachycení Zaznamená se při vytvoření záznamu ve VBKPF Typ události explicit | |||
| Faktura po splatnosti | Vypočítané časové razítko označující okamžik, kdy nastalo datum čisté splatnosti faktury. Vypočítá se přičtením počtu dnů podle platebních podmínek k výchozímu datu v tabulce BSEG. | ||
| Proč je to důležité Slouží jako referenční bod pro sledování včasnosti plateb a sankcí za pozdní platby. Kde data získat Výpočet: BSEG-ZFBDT (výchozí datum) + BSEG-ZBD1T/ZBD2T/ZBD3T (počet dnů). Zachycení Odvodit porovnáním aktuálního data s datem čisté splatnosti Typ události calculated | |||
| Propadla sleva za včasnou platbu | Vypočítaná událost označující datum, kdy vypršel nárok na hotovostní slevu. Určuje se porovnáním data splatnosti slevy s aktuálním datem nebo datem platby. | ||
| Proč je to důležité Nezbytné pro vizualizaci promarněných finančních příležitostí v nástroji pro optimalizaci slev za včasnou platbu. Kde data získat Výpočet: BSEG-ZFBDT + BSEG-ZBD1T (počet dnů pro slevu 1). Zachycení Odvodit porovnáním data s datem splatnosti slevy Typ události calculated | |||
| Storno faktury | Označuje, že účetní doklad faktury byl stornován nebo zrušen. Zjišťuje se kontrolou pole STBLG (stornovací doklad) v tabulce BKPF. | ||
| Proč je to důležité Označuje opakovanou práci a selhání procesu, pomáhá odhalit plýtvání a zbytečně duplicitní úsilí. Kde data získat Tabulka BKPF, pole STBLG není prázdné. Zachycení Zaznamenáno po vyplnění pole STBLG Typ události explicit | |||
| Vytvořen návrh platby | Označuje, že faktura byla zahrnuta do běhu návrhu plateb (F110), což je první krok automatizovaného platebního programu. Údaje se získávají z tabulky REGUH, která obsahuje data o vyrovnání. | ||
| Proč je to důležité Označuje, že faktura byla vybrána k platbě a prošla kontrolami platnosti v platebním programu. Kde data získat Čas vytvoření tabulky REGUH (klíče LAUFD a LAUFI). Zachycení Zaznamenáno při vytvoření záznamu REGUH Typ události explicit | |||
| Zjištěna cenová odchylka | Odvozená činnost označující nesoulad mezi cenou na faktuře a cenou v objednávce. Zjišťuje se podle konkrétního klíče blokace platby, obvykle „R“ pro kontrolu faktury, který se automaticky nastaví při zaúčtování. | ||
| Proč je to důležité Odhaluje příčiny ručních oprav a podporuje analýzu míry třístranného párování. Kde data získat Odvozuje se z hodnoty BSEG-ZLSPR „R“ (nebo z nastavení systému pro cenové blokace) v okamžiku zaúčtování. Zachycení Porovnat hodnotu ZLSPR s „R“ Typ události inferred | |||
| Zjištěna odchylka v množství | Odvozená činnost označující nesoulad mezi množstvím na faktuře a množstvím na příjemce. Zjišťuje se podle konkrétního klíče blokace platby, obvykle „M“ pro odchylku v množství, nastaveného u položky dokladu. | ||
| Proč je to důležité Důležité pro analýzu efektivity párování a kvality dat v dodavatelském řetězci. Kde data získat Odvozuje se z hodnoty BSEG-ZLSPR „M“ (nebo z nastavení systému pro blokace kvůli odchylce v množství). Zachycení Porovnat hodnotu ZLSPR s „M“ Typ události inferred | |||
| Změněny platební podmínky | Zaznamenává změnu platebních podmínek u otevřené faktury, která ovlivňuje datum splatnosti nebo nárok na slevu. Změny se sledují v protokolech změn pole ZTERM v tabulce BSEG. | ||
| Proč je to důležité Časté změny mohou ukazovat na chyby v kmenových datech nebo ruční úpravy, které ovlivňují prognózy peněžních toků a dodržování platebních podmínek dodavatelů. Kde data získat Tabulky CDPOS a CDHDR, ve kterých se hledají změny pole BSEG-ZTERM. Zachycení Zaznamená se při změně ZTERM v záznamech CDPOS Typ události explicit | |||
Návody k extrakci
Kroky
Určete potřebná CDS View: Ověřte, zda jsou k dispozici standardní CDS View pro SAP S/4HANA. Potřebujete především I_JournalEntry (záhlaví), I_OperationalAcctgDocItem (položky, ekvivalent BSEG), I_SupplierInvoice (logistika), I_PaymentProposalItem (F110) a I_ChangeDocument (pro záznamy změn).
Nastavte oprávnění uživatele: Ověřte, že databázový nebo technický servisní uživatel má oprávnění SELECT k pohledům DDL SQL přidruženým k entitám CDS. Obvykle se to nastavuje v SAP HANA Studio nebo ABAP Eclipse Development Tools (ADT).
Připravte prostředí SQL: Otevřete rozhraní SQL, například SAP HANA Studio, DBeaver připojený k HANA nebo konektor pro process mining, který podporuje SQL. Tento postup předpokládá přímý přístup SQL k vrstvě HANA, kde jsou CDS View zpřístupněna jako pohledy.
Vymezte rozsah: Určete kód společnosti (CompanyCode) a rozsah účetních roků, abyste omezili objem dat. To je důležité kvůli výkonu při dotazování pohledu položek provozních účetních dokladů.
Nastavte logiku činností: Zkopírujte níže uvedený SQL dotaz. Pomocí UNION ALL spojuje 14 samostatných bloků logiky do jedné struktury event logu. Každý blok se týká konkrétní činnosti, například zaúčtování faktury nebo vyrovnání platby.
Zpracujte doklady změn: Dotaz obsahuje části pro změny platebních podmínek a blokací. Využívají pohled I_ChangeDocument. Pokud tento pohled ve vaší verzi S/4 není aktivní, možná budete muset vytvořit vlastní CDS View nad podkladovými tabulkami CDHDR/CDPOS.
Zkontrolujte vypočítané události: Prověřte logiku pro splatnost faktury a nevyužité skonto. Jde o vypočítané události, které vznikají přičtením počtu dnů k základnímu datu v pohledu provozních položek.
Spusťte extrakci: Proveďte dotaz. U velkých datových sad doporučujeme rozdělit extrakci podle účetního roku nebo kódu společnosti, aby nedošlo k přeplnění paměti.
Ověřte formát data: Zkontrolujte, že sloupec EventTime má formát YYYY-MM-DD HH:MM:SS. SAP HANA SQL vrací časová razítka, která může být nutné převést podle cílové aplikace.
Exportujte data: Uložte výsledek jako soubor CSV nebo Parquet. Záhlaví musí odpovídat sloupcům uvedeným v závěrečném příkazu SELECT.
Připravte data k nahrání: Pokud váš nástroj pro process mining vyžaduje konkrétní formát CSV, například určitý formát data, proveďte úpravy v následném skriptu nebo pomocí funkcí TO_VARCHAR v SQL.
Proveďte závěrečnou kontrolu: Načtěte vzorek do ProcessMind a ověřte, že ID případu (číslo faktury) správně sdružuje všechny činnosti od zaúčtování po vyrovnání.
Konfigurace
- Filtr kódu společnosti: Omezte dotaz na konkrétní organizační jednotky (CompanyCode = '1000'), abyste zachovali kontext a výkon.
- Rozsah dat: Omezte objem dat filtrem podle PostingDate nebo CreationDate, například na posledních 12 měsíců.
- Typ účtu: Ve I_OperationalAcctgDocItem nastavte filtr FinancialAccountType = 'K' (dodavatel), abyste vyloučili řádky hlavní knihy a odběratelů.
- Aktivace CDS View: Ověřte, že pohledy I_JournalEntry, I_OperationalAcctgDocItem a I_PaymentProposalItem jsou aktivní a zpřístupněné pro SQL.
- Výkon záznamu změn: Dotazování I_ChangeDocument může vyžadovat značné systémové zdroje. Omezte poddotazy podle ObjectClass 'BELEG' a konkrétních názvů polí, například ZLSPR a ZTERM.
Ukázkový dotaz sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Kroky
- Ověřte, že máte přímý přístup SQL ke schématu SAP HANA obsahujícímu ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP a příslušné tabulky změnových dokumentů. Nahraďte [Your SAP HANA schema] a údaje o připojení hodnotami schválenými pro váš systém.
- Potvrďte rozsah faktur a období sestavy. Nastavte [Start date] a [End date] ve formátu YYYYMMDD a [Company code filter] zadejte jako platnou podmínku SQL, například BUKRS IN ('1000','2000').
- Ověřte verzi SAP a místní konfiguraci odložených dokladů, polí stavu platebního programu, typů platebních dokladů a ukládání změnových dokumentů. Dotaz používá zdokumentované zdrojové objekty a konzervativní mapování polí. Před nasazením do produkčního prostředí je ale nutné zkontrolovat místní rozšíření a rozdíly mezi verzemi.
- Spusťte dotaz v SAP HANA pomocí schváleného SQL klienta nebo služby pro extrakci. Dotaz vytvoří jeden řádek události pro každou výslovně extrahovanou aktivitu. ProcessMind nedoplní aktivity, které ve výsledku chybí.
- Zkontrolujte zdrojová data a upravte označené podmínky konfigurace pro stav odložených dokladů, typy platebních dokladů, stav návrhů a běhů plateb a třídy objektů změnových dokumentů. Podmínky nerozšiřujte, dokud neověříte, že výsledky neobsahují duplicitní ani nesouvisející účetní doklady.
- Ověřte propojení pomocí polí InvoiceNumber, CompanyCode, fiskální rok, číslo účetního dokladu, číslo dodavatele a položka dokladu, pokud jsou relevantní. Zkontrolujte, že jsou čísla faktur v cílovém systému konzistentně uvedena v BKPF, BSEG, ACDOCA, REGUH a REGUP.
- Ověřte vypočítané události. Událost Invoice Due se vytvoří k vypočtenému čistému datu splatnosti. Událost Cash Discount Lost se vytvoří k nejbližšímu příslušnému termínu skonta, pokud před ním neproběhla platba. Jde o odvozené řádky, které je třeba jasně odlišit od událostí pocházejících ze zdrojových záznamů.
- Výsledek exportujte do plochého souboru CSV v kódování UTF-8 nebo do jiného tabulkového formátu podporovaného ProcessMind. Zachovejte přesné názvy sloupců InvoiceNumber, Activity, EventTime, SourceSystem a LastDataUpdate. Pro každou událost ponechte jeden řádek a neslučujte aktivity podle faktury.
- Nahrajte záznam událostí do ProcessMind a namapujte InvoiceNumber jako identifikátor případu, Activity jako název aktivity a EventTime jako čas události. Zbývající sloupce namapujte jako atributy události nebo případu podle nastavení importu ProcessMind.
Konfigurace
- Rozsah dat: Při první extrakci použijte průběžné období 3 až 6 měsíců. Filtry podle data zaúčtování, data změny a data platebního programu nastavte konzistentně. Při ověřování dlouhých platebních podmínek období prodlužte.
- Schéma: Nahraďte [Your SAP HANA schema] schématem, které obsahuje objekty SAP. Ověřte, zda prostředí zpřístupňuje objekty závislé na klientovi prostřednictvím vybraného schématu, nebo zda je nutné zadat výslovný filtr klienta.
- Filtr společnosti: Nastavte [Company code filter] tak, aby omezoval BUKRS na požadované kódy společností. Stejný rozsah použijte pro BKPF, BSEG, ACDOCA, REGUH, REGUP a zdroje dokladů změn, pokud tato pole obsahují.
- Filtr dokladů: Zkontrolujte podmínku pro typ dokladu faktury i typ platebního dokladu. Dotaz obsahuje běžné příklady, typy dokladů jsou však nastavitelné a je nutné je přizpůsobit cílovému systému.
- Předběžně zadané faktury: Ověřte, jak je stav předběžného zadání vyjádřen v VBKPF nebo BKPF. Dotaz používá nastavitelnou podmínku, protože kódování tohoto stavu se může lišit podle verze a implementace.
- Změny platebních údajů: Ověřte třídu objektu, název tabulky, názvy polí a reprezentaci hodnot pro BSEG-ZLSPR a BSEG-ZTERM v dokladech změn. Způsob ukládání dokladů změn a názvy polí je třeba ověřit v cílovém systému.
- Platební program: Ověřte pole REGUH a REGUP používaná pro stav návrhu a provedení platby, datum běhu, jeho identifikaci a vazbu na účetní doklad. Místní nastavení platebního programu může ovlivnit dostupné hodnoty stavu.
- Výkon: Omezte rozsah dat a kódy společností, vybírejte pouze potřebné sloupce a použijte filtry pro jednotlivé zdroje ještě před spojením tabulek. U velkých datových sad vytvořte filtrované podmnožiny zdrojů nebo použijte schválený výpočetní pohled HANA či extrakční schéma.
- Oprávnění: Potřebujete oprávnění ke čtení příslušných objektů schématu SAP HANA a všech pohledů, které zpřístupňují účetní data, data platebního programu a doklady změn. Postup koordinujte s týmy SAP security a správy dat.
- Funkční předpoklady: Musí být aktivní a naplněné příslušné funkce finančního účetnictví, závazků, platebního programu a dokladů změn. Pokud se některá zdrojová tabulka v implementaci nepoužívá, nastavte schválenou náhradu podle návrhu systému.
- Zpracování časových razítek: BKPF a BSEG obvykle obsahují datum a čas v samostatných polích. Dotaz je spojí do časového razítka. Ověřte časové pásmo zdrojového systému a před nahráním do ProcessMind proveďte potřebný převod.
- Ochrana dat: Omezte údaje o dodavatelích a účetnictví na schválený rozsah a dodržujte pravidla organizace pro uchovávání, maskování a přístup k datům.
Ukázkový dotaz sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Chcete začít?
Proměňte finanční data v užitečné poznatky a začněte optimalizovat platební cykly. Náš tým vám pomůže v každé fázi práce s process mining.
Zlepšete zpracování plateb dodavatelům v SAP S/4HANA
Odstraňte úzká místa a zkraťte dobu průchodu procesem o 30 %.
Platební kartu nepotřebujete. Nastavení zabere 5 minut.