Šablona dat pro proces od záznamu po výkaznictví: účetní doklady
Šablona dat pro proces od záznamu po výkaznictví: účetní doklady
- Doporučené atributy pro podrobnou analýzu
- Důležité aktivity účetních dokladů ke sledování
- Praktický návod k získání dat ze SAP ECC
Atributy procesu od záznamu po výkaznictví: účetní doklady
| Název | Popis | ||
|---|---|---|---|
| Čas události EventTime | Časové razítko určující, kdy u účetního zápisu došlo ke konkrétní aktivitě nebo události. | ||
| Popis Čas události uvádí přesné datum a čas každé aktivity v procesu účetního zápisu. Tyto údaje jsou nezbytné pro výpočet časových ukazatelů, například doby zpracování, délky jednotlivých kroků a prodlev mezi nimi. Zdroj časového razítka závisí na aktivitě. Může jít o datum a čas vytvoření dokladu (CPUDT/CPUTM) nebo o časové údaje změn z protokolů (CDHDR-UDATE/UTIME). Při analýze se podle času události řadí chronologicky a vytváří se základ mapy procesu. Tento údaj je nezbytný pro výpočet časových KPI, například průměrné doby zpracování účetního zápisu, průměrné doby schvalování a doby od schválení po zaúčtování. Proč je to důležité Toto časové razítko je základem veškeré časové analýzy. Umožňuje vypočítat dobu zpracování, délku jednotlivých kroků a úzká místa. Kde data získat Zdroj závisí na aktivitě. Nejčastěji jde o časové razítko vytvoření (CPUDT, CPUTM) z BKPF nebo časové údaje změn (UDATE, UTIME) z CDHDR. Příklady 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| ID účetního zápisu JournalEntryId | Jedinečný identifikátor finančního účetního dokladu, který spojuje kód společnosti, číslo dokladu a fiskální rok. | ||
| Popis ID účetního zápisu je hlavní identifikátor případu pro sledování životního cyklu účetního zápisu. Jde o složený klíč, který se obvykle vytváří spojením kódu společnosti (BUKRS), čísla dokladu (BELNR) a fiskálního roku (GJAHR). Zajišťuje tak jedinečnost v celém systému SAP. Při analýze procesů toto ID propojuje všechny související aktivity, například vytvoření, odložení, odeslání, schválení, zamítnutí a zaúčtování. Sledováním identifikátoru lze sestavit průběh každého účetního zápisu od začátku do konce, měřit dobu zpracování a odhalit odchylky nebo úzká místa u konkrétních zápisů. Proč je to důležité Tento nezbytný klíč umožňuje sledovat účetní zápis od vytvoření až po konečné zaúčtování, analyzovat celý proces a porovnávat jeho varianty. Kde data získat Jde o odvozený atribut, který se obvykle vytváří spojením polí z tabulky BKPF: kódu společnosti (BUKRS), čísla dokladu (BELNR) a fiskálního roku (GJAHR). Příklady 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Název aktivity ActivityName | Název obchodní aktivity nebo události, ke které došlo v určitém okamžiku procesu účetního zápisu. | ||
| Popis Název aktivity popisuje konkrétní krok v životním cyklu účetního zápisu, například „Účetní zápis vytvořen“, „Účetní zápis schválen“ nebo „Účetní zápis zaúčtován“. Tento atribut se obvykle odvozuje z několika zdrojů v SAP, včetně transakčních kódů (TCODE), protokolů změn dokladů (tabulky CDHDR a CDPOS) a polí se stavem dokladu. Analýza aktivit je základem process mining. Umožňuje vizualizovat mapy procesů, vypočítat dobu mezi jednotlivými kroky a odhalit opakované opravy, například když po události „Účetní zápis zamítnut“ následuje „Účetní zápis opraven“. Tato data jsou základem dashboardů pro dobu zpracování, míru oprav a varianty procesu. Proč je to důležité Určuje kroky v mapě procesu a umožňuje vizualizovat, analyzovat a optimalizovat workflow účetních zápisů. Kde data získat Odvozuje se z různých zdrojů, například z transakčních kódů v BKPF (TCODE), stavu dokladu, protokolů workflow v tabulkách jako SWW_WI2OBJ nebo změnových dokladů v CDHDR a CDPOS. Příklady Účetní zápis vytvořenÚčetní zápis schválenÚčetní zápis zamítnutÚčetní zápis zaúčtován | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko určující, kdy byla data naposledy získána ze zdrojového systému nebo aktualizována. | ||
| Popis Tento atribut zaznamenává datum a čas posledního načtení dat ze SAP ECC. Jde o metadata důležitá pro posouzení aktuálnosti analyzovaných dat. V každém dashboardu nebo analýze process mining je čas poslední aktualizace důležitý pro důvěru uživatelů v data a jejich rozhodování. Pomáhá odpovědět na otázku: „Jak aktuální jsou tyto informace?“ Proč je to důležité Informuje uživatele o aktuálnosti dat. Díky tomu vědí, jaké období analýza pokrývá, a mohou výsledkům důvěřovat. Kde data získat Jde o metadata, která při aktualizaci dat vytváří a ukládá nástroj pro extrakci dat nebo proces ETL. Příklady 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Zdrojový systém SourceSystem | Systém, ze kterého byla data o procesu získána. | ||
| Popis Tento atribut určuje původ dat, v tomto případě konkrétní instanci SAP ECC. Obvykle jde o statickou hodnotu přidanou při extrakci dat. V prostředí s více systémy ERP nebo zdroji dat je tento atribut důležitý. Umožňuje sledovat původ dat a filtrovat či rozdělit analýzu podle zdrojového systému. Proč je to důležité Zajišťuje přehled o původu dat a pomáhá sledovat jejich kvalitu, zejména v prostředí s více zdrojovými systémy. Kde data získat Obvykle jde o statickou hodnotu přidanou při transformaci dat, která označuje konkrétní instanci SAP ECC, například 'ECC_PROD_100'. Příklady SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Datum zaúčtování PostingDate | Datum, kdy se transakce zaúčtuje do hlavní knihy a ovlivní účetní období. | ||
| Popis Datum zaúčtování určuje fiskální období, do kterého se účetní zápis zaúčtuje. Z finančního hlediska i z hlediska shody jde o důležitý údaj, který musí odpovídat harmonogramu uzávěrky účetního období a platným předpisům. V process mining se toto datum používá ke sledování shody. Dashboard „Sledování dodržování pravidel“ a KPI „Míra souladu s pravidly“ ověřují, zda byly zápisy zaúčtovány ve správném období. Atribut lze využít také k analýze vývoje objemu účetních zápisů v čase. Proč je to důležité Důležité pro finanční výkaznictví a analýzu shody. Pomáhá ověřit, zda jsou zápisy zaúčtovány ve správném účetním období. Kde data získat Nachází se v tabulce hlaviček dokladů BKPF, pole BUDAT. Příklady 2023-10-312023-11-302024-01-15 | |||
| Kód společnosti CompanyCode | Organizační jednotka představující samostatnou právnickou osobu, pro kterou se sestavují finanční výkazy. | ||
| Popis Kód společnosti je základní organizační jednotkou v SAP Financials. Představuje právně samostatnou společnost a je důležitým polem v hlavičce účetního dokladu. Tento atribut umožňuje rozdělit analýzu procesů podle právnických osob. Můžete porovnávat výkonnost procesů, míru shody a výsledky KPI v různých částech firmy. Snadno tak zjistíte například, zda se prodlevy při schvalování nebo vysoký počet storen týkají jen některých kódů společností. Proč je to důležité Umožňuje filtrovat a porovnávat výkonnost procesů napříč různými právnickými osobami nebo obchodními jednotkami. Kde data získat Nachází se v tabulce hlaviček dokladů BKPF, pole BUKRS. Příklady 10002000US01DE01 | |||
| Stornováno IsReversed | Logická hodnota určující, zda byl účetní zápis stornován. | ||
| Popis Tento příznak označuje účetní doklady, které byly následně stornovány jiným účetním dokladem. V SAPu je stornovaný doklad propojen se stornovacím dokladem, což zajišťuje přehlednou auditní stopu. Tento atribut je zásadní pro dashboard „Analýza stornování účetních dokladů“ a KPI „Míra stornování účetních dokladů“. Umožňuje vyfiltrovat stornované doklady a hledat příčiny, například chyby při zadávání dat nebo nesprávné účetní postupy, s cílem snížit počet storen. Proč je to důležité Příznak přímo podporuje analýzu stornování. Označuje doklady, které byly později stornovány, a pomáhá tak odhalit příčiny chyb a zlepšit integritu dat. Kde data získat Odvozuje se z pole čísla stornovacího dokladu (STBLG) v tabulce BKPF. Pokud pole STBLG není prázdné, příznak má hodnotu true. Příklady truefalse | |||
| Transakční kód TransactionCode | Kód transakce SAP použité k vytvoření nebo zpracování účetního zápisu. | ||
| Popis Transakční kód (T-Code) je jedinečný identifikátor konkrétní funkce nebo programu v SAP. U účetních zápisů ukazuje, jak byly vytvořeny, například ručně (FB01, F-02), odložením (FV50) nebo prostřednictvím automatizovaného rozhraní. Tento atribut je velmi užitečný pro dashboard „Optimalizace ručních aktivit“. Analýzou T-Code lze rozlišit ruční a automatizované aktivity, zjistit, které ruční procesy zabírají nejvíce času, a určit možnosti automatizace, která omezí ruční práci a zvýší efektivitu. Proč je to důležité Pomáhá rozlišit ruční a automatizované procesy a najít možnosti automatizace a standardizace procesů. Kde data získat Nachází se v tabulce hlaviček dokladů BKPF, pole TCODE. Příklady FB01F-02FV50FBD1 | |||
| Typ dokladu DocumentType | Klasifikace účetních dokladů, která určuje způsob jejich zpracování a ukládání. | ||
| Popis Typ dokladu rozlišuje různé druhy obchodních transakcí, například zápis do hlavní knihy (SA), fakturu dodavatele (KR) nebo zaúčtování majetku (AA). Nastavuje se při konfiguraci systému a přiřazuje každému účetnímu zápisu. Tento atribut je důležitý pro analýzu, protože umožňuje rozdělit proces podle povahy transakce. Dashboard „Objem účetních zápisů podle typu“ a KPI „Průměrná doba zpracování podle typu účetního zápisu“ přímo využívají toto pole. Pomáhá zjistit, zda se u některých typů zápisů častěji objevují prodlevy, opravy nebo storna. Proč je to důležité Umožňuje rozdělit analýzu podle typu transakce a zjistit, zda se problémy v procesu týkají jen některých typů účetních zápisů. Kde data získat Nachází se v tabulce hlaviček dokladů BKPF, pole BLART. Příklady SAKRREAA | |||
| Uživatel User | ID uživatele SAP, který účetní zápis vytvořil nebo změnil. | ||
| Popis Tento atribut zaznamenává uživatelské jméno SAP odpovědné za konkrétní aktivitu, například vytvoření, odložení nebo zaúčtování dokladu. Získává se přímo z hlavičky dokladu nebo z tabulek protokolů změn. Analýza atributu Uživatel pomáhá porozumět výkonu týmu i jednotlivců. Dashboard Produktivita uživatelů sleduje objem aktivit a dobu zpracování podle uživatele. Atribut také pomáhá zjistit, kdo se podílí na opakovaných opravách, stornech nebo odchylkách od pravidel, a cíleně plánovat školení či zlepšení procesů. Proč je to důležité Určuje uživatele odpovědného za každou aktivitu a umožňuje analyzovat jeho výkon, rozložení pracovní zátěže a opakované opravy. Kde data získat Obvykle pochází z tabulky BKPF (pole USNAM pro tvůrce) nebo z tabulky CDHDR (pole USERNAME pro uživatele, který provedl změnu). Příklady ABROWNCJONESDSMITH | |||
| Celková částka dokladu TotalDocumentAmount | Celková hodnota účetního zápisu v měně dokladu. | ||
| Popis Tento atribut představuje celkovou finanční hodnotu účetního zápisu. Obvykle se vypočítá jako součet absolutních hodnot všech debetních nebo kreditních položek souvisejících s dokladem. Analýza procesu podle finanční hodnoty může odhalit důležité souvislosti. Například zápisy s vysokou hodnotou mohou procházet jiným, přísnějším schvalováním. Pomocí tohoto atributu lze analýzu filtrovat nebo rozdělit a zjistit, zda částka zápisu souvisí s dobou zpracování, mírou zamítnutí nebo prodlevami při schvalování. Proč je to důležité Umožňuje analyzovat finanční dopad, například vztah mezi hodnotou účetních zápisů a dobou zpracování nebo mírou zamítnutí. Kde data získat Jde o vypočítané pole odvozené součtem hodnoty částek (WRBTR nebo DMBTR) ze všech položek v tabulce BSEG pro daný účetní zápis. Příklady 1500.0025000.75125.50 | |||
| Doba schválení ApprovalTime | Doba od odeslání účetního dokladu ke schválení do jeho schválení nebo zamítnutí. | ||
| Popis Tato metrika měří dobu trvání dílčího procesu schvalování, který často významně prodlužuje celkovou dobu zpracování. Vypočítá se jako rozdíl mezi aktivitou „Účetní doklad odeslán ke schválení“ a odpovídající aktivitou „Účetní doklad schválen“ nebo „Účetní doklad zamítnut“. Doba schválení je hlavní metrikou dashboardu „Výkonnost schvalování účetních dokladů“ a KPI „Průměrná doba schválení účetního dokladu“. Analýza této doby pomáhá odhalit úzká místa ve workflow schvalování, měřit výkonnost schvalovatelů a zdůvodnit změny procesu, například úpravu limitů pro schvalování. Proč je to důležité Měří dobu trvání schvalovací fáze a pomáhá odhalit a řešit zpoždění při kontrole a schvalování. Kde data získat Vypočítá se odečtením časového razítka aktivity „Účetní doklad odeslán ke schválení“ od časového razítka aktivity „Účetní doklad schválen“ nebo „Účetní doklad zamítnut“. Příklady P1DT2HPT4H15MP3D | |||
| Důvod storna ReversalReason | Kód označující důvod stornování účetního dokladu. | ||
| Popis Při stornování dokladu může uživatel v SAPu zadat kód důvodu. Ten strukturovaně popisuje, proč bylo storno nutné, například kvůli nesprávnému datu zaúčtování nebo chybě při zadávání dat. Tento atribut je důležitým vstupem pro dashboard „Analýza stornování účetních dokladů“. Analýza nejčastějších důvodů storen pomáhá organizacím odhalit systémové problémy v procesech nebo nedostatky ve školení a přijmout cílená opatření, která předejdou dalším chybám a sníží míru stornování. Proč je to důležité Ukazuje, proč ke stornům dochází, a umožňuje cíleně hledat jejich příčiny, aby se omezily budoucí chyby. Kde data získat Nachází se v tabulce záhlaví dokladů BKPF, v poli STGRD. Příklady 010205 | |||
| Je předběžně uložen IsParked | Logický příznak označující, zda byl účetní doklad před zaúčtováním uložen jako předběžně uložený doklad. | ||
| Popis Předběžné uložení umožňuje uložit neúplný účetní doklad, aniž by ovlivnil finanční zůstatky. Jiný uživatel ho pak může doplnit nebo zkontrolovat před zaúčtováním. Tento příznak označuje doklady, které prošly krokem předběžného uložení. Analýza tohoto atributu pomáhá pochopit, jak se funkce předběžného ukládání používá. Může ukázat, zda slouží jako neformální kontrolní krok, který způsobuje zpoždění. Pomáhá také analyzovat celkovou dobu zpracování a rozlišit doklady zaúčtované přímo od těch, které byly nejprve předběžně uloženy. Proč je to důležité Označuje doklady, u kterých se využilo předběžné uložení. To může způsobovat zpoždění nebo ukazovat na neformální kontrolní postup. Kde data získat Odvozuje se z pole stavu dokladu (BSTAT) v tabulce BKPF. Hodnota „V“ označuje předběžně uložený doklad. Příklady truefalse | |||
| Měnový klíč CurrencyKey | Kód měny částek uvedených v účetním dokladu. | ||
| Popis Tento atribut určuje měnu účetního dokladu, například USD, EUR nebo JPY. Poskytuje kontext pro finanční částky spojené s dokladem. Nejde vždy o hlavní dimenzi analýzy, ale pro správnou interpretaci peněžních hodnot je zásadní. V mezinárodních organizacích lze podle tohoto atributu také rozdělit analýzu a zjistit, zda se procesy u dokladů v zahraničních a místních měnách liší. Proč je to důležité Poskytuje potřebný kontext pro všechny peněžní hodnoty a umožňuje jejich správnou finanční analýzu a interpretaci. Kde data získat Nachází se v tabulce záhlaví dokladů BKPF, v poli WAERS. Příklady USDEURGBPJPY | |||
| Nákladové středisko CostCenter | Organizační jednotka v rámci controllingové oblasti, která představuje místo vzniku nákladů. | ||
| Popis Nákladové středisko je důležitý kmenový údaj z modulu Controlling (CO), který se často přiřazuje k jednotlivým položkám účetního dokladu. Slouží ke sledování nákladů konkrétního oddělení, funkce nebo místa. Zahrnutí nákladového střediska umožňuje podrobnější analýzu procesu zpracování účetních dokladů. Pomůže zjistit, zda některá oddělení častěji opravují doklady, mají delší dobu zpracování nebo vytvářejí více ručních zápisů. Díky tomu lze vyhodnotit efektivitu procesu podle oddělení. Proč je to důležité Umožňuje vyhodnotit výkonnost procesu podle oddělení nebo funkční oblasti a odhalit místní neefektivitu. Kde data získat Nachází se v tabulce položek dokladů BSEG, v poli KOSTL. Příklady 4100CC_FINANCE_US10010101 | |||
| Vyžaduje opravu IsRework | Logický příznak označující, zda účetní doklad prošel opakovaným zpracováním, například když byl zamítnut a následně opraven. | ||
| Popis Tento příznak označuje případy, které se odchýlily od běžného průběhu a vyžadovaly nápravný krok. Obvykle se nastaví na true, pokud se u daného účetního dokladu zaznamená posloupnost aktivit, například „Účetní doklad zamítnut“ a poté „Účetní doklad opraven“. Tento atribut je nezbytný pro výpočet KPI „Míra oprav účetních dokladů“ a analýzu na dashboardu „Míra oprav a zamítnutí“. Pomáhá vyčíslit neefektivitu procesu a hledat příčiny opakovaného zpracování, například nejasné požadavky nebo nedostatečnou dokumentaci. Proč je to důležité Označuje doklady, které bylo nutné opravit. Umožňuje vyčíslit opakované zpracování a hledat jeho příčiny, aby se zvýšil podíl správně zpracovaných dokladů napoprvé. Kde data získat Jde o vypočítaný atribut odvozený z analýzy posloupnosti aktivit případu. Opakované zpracování se zaznamená, pokud dojde k zamítnutí nebo opravě. Příklady truefalse | |||
Aktivity procesu od záznamu po výkaznictví: účetní doklady
| Aktivita | Popis | ||
|---|---|---|---|
| Storno účetního zápisu zpracováno | Tato aktivita označuje storno dříve zaúčtovaného účetního zápisu. Storno je nový účetní doklad, který ruší původní zápis. | ||
| Proč je to důležité Jde o důležitou událost při měření kvality dat a přesnosti procesu. Vysoký podíl storen ukazuje na systémové problémy při původním zadání dat nebo schvalování. Každé storno navíc znamená další práci. Kde data získat Událost se identifikuje v hlavičce původního dokladu (tabulka BKPF). Při stornu SAP vyplní číslo stornovacího dokladu (BKPF-STBLG) a důvod storna (BKPF-STGRD). Časem události je datum zaúčtování nového stornovacího dokladu. Zachycení Zjistěte, kdy se u původního dokladu vyplní BKPF-STBLG. Časem události je datum zaúčtování stornovacího dokladu. Typ události explicit | |||
| Účetní zápis odeslán | Tato aktivita označuje dokončení odloženého účetního zápisu jeho tvůrcem. Zápis je nyní připraven ke kontrole a schválení. Událost se obvykle zachytí při spuštění úlohy SAP Business Workflow propojené s odloženým dokladem. | ||
| Proč je to důležité V tomto okamžiku se zápis předává od tvůrce schvalovateli a začíná se měřit doba schvalování pro KPI. Jde o důležitý milník při hodnocení efektivity schvalovacího workflow. Kde data získat Událost se odvozuje z času zahájení instance schvalovacího workflow propojené s objektem finančního dokladu. Je třeba analyzovat tabulky protokolu workflow, například SWW_WI2OBJ, a najít workflow spuštěné pro konkrétní kód společnosti, číslo dokladu a fiskální rok. Zachycení Najděte událost zahájení workflow pro objekt odloženého dokladu. Typ události inferred | |||
| Účetní zápis odložen | Tato aktivita označuje prvotní vytvoření účetního zápisu v předběžném stavu, ještě před jeho oficiálním zaúčtováním do hlavní knihy. V SAP se zaznamená, když uživatel uloží doklad pomocí transakce pro odložení a nastaví jeho stav na „odložený“. | ||
| Proč je to důležité Jde o důležitou počáteční událost procesů, které zahrnují kontrolu a schválení. Analýza doby mezi odložením a zaúčtováním pomáhá odhalit prodlevy před zaúčtováním a ve schvalovací fázi. Kde data získat Událost se identifikuje v tabulce hlaviček dokladů BKPF. Doklad se považuje za odložený, pokud je vytvořen se stavem BKPF-BSTAT = 'V'. Čas události určují datum a čas vytvoření, BKPF-CPUDT a BKPF-CPUTM. Zachycení Najděte vytvoření dokladu v BKPF, kde BKPF-BSTAT má hodnotu 'V'. Typ události explicit | |||
| Účetní zápis schválen | Tato aktivita označuje konečné schválení účetního zápisu ve workflow, po kterém jej lze zaúčtovat. Událost se zachytí z protokolu workflow po dokončení posledního kroku „uvolnit“ nebo „schválit“. | ||
| Proč je to důležité Tento důležitý milník uzavírá schvalovací proces. Doba do této aktivity je zásadním KPI pro hodnocení efektivity schvalování. Doba od této události do zaúčtování měří prodlevu po schválení. Kde data získat Událost se odvozuje z časového razítka dokončení posledního schvalovacího kroku v protokolu SAP Business Workflow. Jde o poslední schválení před zaúčtováním dokladu nebo jeho přípravou k zaúčtování. Zachycení Najděte v protokolech workflow dokončení posledního kroku „uvolnit“ nebo „schválit“. Typ události inferred | |||
| Účetní zápis zaúčtován | Jde o hlavní aktivitu, při které se účetní zápis oficiálně zaúčtuje do hlavní knihy a ovlivní finanční výkazy. Událost se zaznamená přímo, když se stav dokladu změní na „zaúčtováno“ a přiřadí se datum zaúčtování. | ||
| Proč je to důležité Jde o nejdůležitější milník, který potvrzuje úspěšné zpracování účetního zápisu. Doba celého procesu se často měří až do tohoto okamžiku. Událost je důležitá také při analýze finanční uzávěrky. Kde data získat Událost se identifikuje, když má doklad v tabulce BKPF datum zaúčtování (BKPF-BUDAT). U odložených dokladů odpovídá okamžiku, kdy se stav BKPF-BSTAT změní z 'V' na prázdnou hodnotu. Časové razítko zaúčtování je datum zadání BKPF-CPUDT. Zachycení Zjistěte, kdy se BKPF-BSTAT změní z 'V' na prázdnou hodnotu, případně u přímých zaúčtování použijte událost vytvoření. Typ události explicit | |||
| Dokumentace přiložena | Tato aktivita označuje přiložení podpůrných dokumentů, například faktur nebo tabulek, k účetnímu zápisu. Nejde o standardní účetní událost, která by se zaznamenávala přímo. Obvykle se odvozuje z vytvoření příloh propojených s objektem účetního dokladu. | ||
| Proč je to důležité Sledování této aktivity pomáhá ověřit dodržování zásad, které vyžadují dokumentaci. Pozdní přiložení dokumentů může být jednou z příčin dlouhého schvalování. Kde data získat Tuto událost je obtížné spolehlivě zachytit jako událost s časovým razítkem. Lze ji případně odvodit analýzou tabulek příloh Generic Object Services (GOS), například SOOD, a propojením času vytvoření přílohy s klíčem objektu účetního zápisu. Zachycení Odvoďte událost z času vytvoření propojených objektů v tabulkách GOS, například SOOD. Typ události inferred | |||
| Odložený účetní zápis smazán | Označuje smazání odloženého účetního zápisu, který nebyl nikdy zaúčtován. Může k tomu dojít po zamítnutí nebo při chybném vytvoření zápisu. | ||
| Proč je to důležité Tato aktivita označuje neúspěšné ukončení procesu. Analýza důvodů mazání odložených dokladů může odhalit například duplicitní zápisy nebo nejasnosti v procesu. Kde data získat Událost se zachytí při změně stavu odloženého dokladu v tabulce BKPF. Pole stavu BKPF-BSTAT se aktualizuje na 'Z' (odložený doklad smazán). Čas změny lze zjistit v protokolech změn dokladů (CDHDR). Zachycení Zjistěte, kdy se BKPF-BSTAT aktualizuje na 'Z'. Typ události explicit | |||
| Položka účetního zápisu vyrovnána | Tato aktivita označuje vyrovnání položky účtu hlavní knihy spravovaného podle otevřených položek, například účtu bankovního zúčtování. Nastává, když se položka spáruje s jinou a uzavře. | ||
| Proč je to důležité U procesů, jako je bankovní odsouhlasení, je doba vyrovnání položek důležitým KPI. Tato aktivita pomáhá analyzovat efektivitu odsouhlasení a postupů při měsíční uzávěrce. Kde data získat Událost se zachytí z tabulky položek BSEG. Při vyrovnání položky se vyplní pole data vyrovnání (BSEG-AUGDT) a dokladu vyrovnání (BSEG-AUGBL). Časem události je datum vyrovnání. Zachycení Zjistěte, kdy se u položky vyplní datum vyrovnání (BSEG-AUGDT). Typ události explicit | |||
| Účetní zápis opraven | Tato aktivita označuje úpravu odloženého účetního zápisu jeho původním tvůrcem poté, co byl vrácen k opravě. Změna se odvodí z úprav dokladu po události „Vyžádána změna“. | ||
| Proč je to důležité Sledování oprav pomáhá vyčíslit práci spojenou s opakovaným zpracováním. Doba mezi žádostí o změnu a opravou ukazuje, jak dlouho trvá vyřešení problémů v odeslaných zápisech. Kde data získat Událost se odvozuje analýzou protokolů změn dokladů (tabulky CDHDR a CDPOS) pro odložený doklad. Změna zaznamenaná po zamítnutí ve workflow znamená, že byla provedena oprava. Časové razítko pochází z tabulky CDHDR. Zachycení Najděte záznam změny v CDHDR/CDPOS po události zamítnutí. Typ události inferred | |||
| Účetní zápis vytvořen | Označuje vytvoření účetního zápisu, který je zaúčtován přímo, bez předchozího odložení. Událost se zaznamená při vytvoření dokladu v SAP pomocí transakce pro přímé zaúčtování. | ||
| Proč je to důležité Tato aktivita představuje alternativní počáteční bod jednodušších procesů účetních zápisů, které nevyžadují schvalovací workflow. Pomáhá odlišit jednoduchá přímá zaúčtování od složitějších odložených zápisů. Kde data získat Událost odpovídá vytvoření dokladu v tabulce BKPF, kde je stav dokladu BKPF-BSTAT prázdný (zaúčtováno). Čas události určuje datum vytvoření BKPF-CPUDT. U těchto dokladů probíhají události „Vytvořen“ a „Zaúčtován“ současně. Zachycení Najděte vytvoření dokladu v BKPF, kde je BKPF-BSTAT prázdné. Typ události explicit | |||
| Účetní zápis zamítnut | Tato aktivita označuje konečné zamítnutí účetního zápisu, po kterém nebude zaúčtován. Ve schvalovacím workflow jde obvykle o konečný stav, po němž se odložený doklad nakonec smaže. | ||
| Proč je to důležité Sledování zamítnutí je důležité pro řízení kvality. Analýza důvodů a četnosti zamítnutí pomáhá zvýšit podíl účetních zápisů správných hned napoprvé. Kde data získat Tento výsledek se zachytí z protokolu SAP Business Workflow. Představuje konečné rozhodnutí uživatele „zamítnout“, které proces ukončí. Odložený doklad může být následně smazán. Zachycení Najděte v protokolu workflow konečný stav „zamítnuto“ pro daný doklad. Typ události inferred | |||
| Vyžádána změna účetního zápisu | Označuje okamžik ve workflow, kdy schvalovatel zkontroloval účetní zápis a vrátil jej tvůrci k opravě. Událost se zachytí z protokolů workflow, které zaznamenávají rozhodnutí uživatele „zamítnout“ nebo „vrátit“. | ||
| Proč je to důležité Tato aktivita je důležitá pro odhalení opakovaných oprav, které jsou častou příčinou neefektivity a odchylek od procesu. Častý výskyt může ukazovat na problémy s kvalitou zápisů nebo nejasné požadavky. Kde data získat Událost se odvozuje z časového razítka konkrétního rozhodnutí uživatele v protokolu SAP Business Workflow, které odpovídá akci „zamítnout“ nebo „vrátit k opravě“. Zachycení Najděte v protokolech workflow čas rozhodnutí „zamítnout“ nebo „vrátit k opravě“. Typ události inferred | |||
| Zjištěno ruční zadání | Tato aktivita určuje, zda byl účetní zápis vytvořen ručně v online transakci, nebo prostřednictvím automatizovaného rozhraní či dávkového procesu. Nejde o akci uživatele, ale o vypočítaný atribut odvozený ze systémových dat. | ||
| Proč je to důležité Rozlišení ručně a automatizovaně vytvořených zápisů je důležité pro cílené zlepšování procesů. Ruční procesy bývají často předmětem standardizace a automatizace. Kde data získat Hodnota se vypočítá analýzou polí v tabulce hlaviček dokladů BKPF. Transakční kódy (BKPF-TCODE), například 'FB01', 'FB50' nebo 'FV50', označují ruční zadání. Jiné T-kódy nebo konkrétní názvy dávkových vstupů (BKPF-AWKEY) mohou ukazovat na automatizaci. Zachycení Odvoďte hodnotu z BKPF-TCODE nebo jiných ukazatelů zdrojového systému v hlavičce dokladu. Typ události calculated | |||
| Zjištěno zaúčtování mezi společnostmi | Vypočítaná aktivita, která označuje účetní zápis ovlivňující více než jeden kód společnosti. Zjišťuje se analýzou položek jednoho finančního dokladu. | ||
| Proč je to důležité Transakce mezi společnostmi mohou mít složitější požadavky na zpracování a schvalování. Jejich samostatná analýza umožňuje porovnat dobu zpracování a průběh procesu a odhalit specifická úzká místa. Kde data získat Hodnota se vypočítá kontrolou tabulky položek BSEG pro dané číslo dokladu (BELNR). Pokud položky obsahují více než jeden jedinečný kód společnosti (BSEG-BUKRS), jde o zaúčtování mezi společnostmi. Zachycení Ověřte, zda se pro jednu hodnotu BKPF-BELNR vyskytuje více různých hodnot BSEG-BUKRS. Typ události calculated | |||
Návody k získání dat
Kroky
- Vytvořte program ABAP: V systému SAP otevřete transakci SE38 (editor ABAP). Zadejte název nového programu, například Z_PM_JE_EXTRACTION, a klikněte na Vytvořit. Zadejte vhodný název a jako typ programu nastavte „Spustitelný program“.
- Definujte výběrovou obrazovku: Ve zdrojovém kódu programu definujte výběrovou obrazovku. Uživatelé na ní mohou zadat parametry, například období vytvoření dokladu, kódy společností a typy dokladů, a omezit tak objem získávaných dat.
- Definujte datové struktury: Vytvořte strukturu interní tabulky, do které se uloží výsledná data záznamu událostí. Musí obsahovat všechna povinná pole: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate a doporučené atributy, například User, CompanyCode a PostingDate.
- Naprogramujte výběr dat: Napište hlavní dotazy ABAP SQL, které získají data pro všech 14 požadovaných aktivit. Budete vybírat data z hlavních tabulek, například BKPF (záhlaví) a BSEG (položky), tabulek protokolu změn CDHDR a CDPOS, tabulek workflow, například SWWLOGHIST, a tabulek vyrovnání, například BSAS a BSAK.
- Získejte předběžně uložené a zaúčtované doklady: Pro události „Účetní doklad předběžně uložen“ vyberte z tabulky BKPF doklady, u kterých má stav dokladu (BSTAT) hodnotu „V“. Pro události „Účetní doklad vytvořen“ a „Účetní doklad zaúčtován“ vyberte z tabulky BKPF doklady s prázdným stavem, který označuje běžný zaúčtovaný doklad.
- Získejte události změn a odstranění: Prohledejte tabulky změnových dokladů CDHDR a CDPOS pro třídu objektů „BELEG“. Podle klíče dokladu vyhledejte změny odpovídající aktivitám „Účetní doklad opraven“ nebo „Předběžně uložený účetní doklad odstraněn“.
- Získejte události workflow: Aktivity jako „Účetní doklad odeslán ke schválení“, „Schválen“, „Zamítnut“ a „Vyžádána změna“ získáte z tabulek workflow. Pomocí tabulky SWW_WI2OBJ propojte účetní doklad s instancí workflow a v tabulce SWWLOGHIST vyhledejte konkrétní rozhodnutí uživatelů nebo změny stavu.
- Určete vypočítané události: U aktivity „Zjištěn ruční zápis“ porovnejte kód transakce (BKPF-TCODE) se seznamem známých transakčních kódů pro ruční zápisy. U aktivity „Zjištěno zaúčtování mezi společnostmi“ zkontrolujte položky BSEG daného dokladu a ověřte, zda se týkají více kódů společností.
- Sloučte a transformujte data: Při výběru dat pro každou aktivitu je převádějte do výsledné struktury záznamu událostí. Spojením kódu společnosti, čísla dokladu a fiskálního roku vytvořte JournalEntryId. Převeďte data a časy SAP na jedno časové razítko EventTime. Výsledky jednotlivých dotazů přidejte do výsledné interní tabulky.
- Naprogramujte export souboru: Pomocí příkazů ABAP pro práci se soubory, například OPEN DATASET, LOOP AT, TRANSFER a CLOSE DATASET, zapište sloučenou interní tabulku do souboru CSV nebo textového souboru v adresáři aplikačního serveru SAP. Soubor lze zobrazit pomocí transakce AL11.
- Naplánujte úlohu na pozadí: Otevřete transakci SM36 (Definice úlohy na pozadí). Vytvořte úlohu, přidejte krok, který spustí váš program ABAP, a nastavte plán, například každou noc nebo každý týden mimo špičku. Tím automatizujete získávání dat.
- Stáhněte a připravte soubor: Pomocí transakce CG3Y nebo ve spolupráci se správcem systému stáhněte vygenerovaný soubor z aplikačního serveru do místního počítače. Ověřte, že kódování a formát souboru odpovídají požadavkům nástroje process mining.
Konfigurace
- Období: Pro zajištění výkonu je důležité nastavit období. Jako hlavní filtr použijte datum vytvoření dokladu (BKPF-CPUDT). Pro první analýzu doporučujeme období 3 až 6 měsíců. Při testování zvolte několikadenní období, o kterém víte, že obsahuje data.
- Filtr kódu společnosti: Vždy filtrujte podle kódu společnosti (BKPF-BUKRS). Získání dat pro všechny kódy společností najednou může výrazně zatížit zdroje. Začněte s jedním nebo několika relevantními kódy společností.
- Filtr typu dokladu: Pomocí filtru typu dokladu (BKPF-BLART) omezte výběr na konkrétní typy účetních dokladů, například „SA“ pro doklady hlavní knihy, pokud nepotřebujete analyzovat všechny typy.
- ID úloh workflow: Logika získávání událostí workflow závisí na konkrétních ID úloh používaných ve vašem systému pro schválení, zamítnutí a odeslání. Tato ID je nutné nastavit ve zdrojovém kódu programu podle definic workflow ve vaší společnosti.
- Výkon: Program spojuje několik rozsáhlých tabulek, zejména CDPOS a tabulky historie workflow. Spuštění v době největšího provozu může ovlivnit výkon systému. Vždy ho naplánujte jako úlohu na pozadí mimo špičku. Pokud se problémy s výkonem opakují, zvažte vytvoření sekundárních indexů databáze.
- Předpoklady: Tato metoda vyžaduje uživatele s oprávněním k vývoji v ABAP (pro SE38) a oprávněním vytvářet a spravovat úlohy na pozadí (pro SM36). Uživatel nebo úloha musí mít také oprávnění ke čtení všech relevantních finančních tabulek, tabulek workflow a systémových tabulek (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST atd.).
Ukázkový dotaz abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Kroky
- Připojte se k databázi: Získejte přihlašovací údaje s oprávněním pouze ke čtení do databáze SAP ECC. Připojte se pomocí běžného SQL klienta, například DBeaver, SAP HANA Studio nebo SQL Server Management Studio.
- Připravte SQL dotaz: Zkopírujte celý SQL dotaz z části „dotaz“ tohoto dokumentu do svého SQL klienta.
- Nastavte parametry získávání dat: Před spuštěním upravte zástupné hodnoty v dotazu. Nahraďte „[START_DATE]“ a „[END_DATE]“ požadovaným obdobím ve formátu „YYYYMMDD“. Hodnoty „[COMPANY_CODE_1]“ a „[COMPANY_CODE_2]“ nahraďte konkrétními kódy společností SAP, které chcete analyzovat.
- Určete zdrojový systém: V hlavním příkazu
SELECTnahraďte zástupnou hodnotu „[Your SAP System ID]“ skutečným ID systému SAP (SID), aby byl zdroj dat správně označen. - Spusťte dotaz: Spusťte upravený SQL dotaz nad databází SAP. Doba zpracování závisí na zvoleném období a velikosti databázových tabulek.
- Zkontrolujte první výsledky: Po dokončení dotazu krátce zkontrolujte vrácené řádky a ověřte, že se data načetla podle očekávání. Zkontrolujte, zda jsou zastoupeny různé aktivity a zda klíčová pole, například
JournalEntryIdaEventTime, nejsou prázdná. - Zpracujte časová razítka: Dotaz spojuje pole data a času do řetězce ve formátu
YYYYMMDDHHMMSS. Ověřte, že tento formát dokáže zpracovat následný krok nebo cílový systém. Pokud to databáze podporuje, můžete funkci SQLCONCATupravit tak, aby používala formát ISO 8601, napříkladYYYY-MM-DDTHH:MI:SS. - Exportujte data: Exportujte celou sadu výsledků z SQL klienta do souboru CSV. Použijte kódování UTF-8, abyste předešli problémům se speciálními znaky.
- Připravte data k nahrání: Před nahráním do nástroje process mining ověřte, že záhlaví sloupců odpovídají požadovanému schématu dat. Povinná jsou pole
JournalEntryId,ActivityNameaEventTime. Přidejte sloupecLastDataUpdatea vyplňte ho časovým razítkem získání dat. - Proveďte závěrečnou kontrolu: Před zahájením analýzy proveďte kroky uvedené v části „validationSteps“ a ověřte úplnost a správnost získaných dat.
Konfigurace
- Oprávnění k databázi: Uživatel databáze potřebuje oprávnění ke čtení následujících tabulek SAP: BKPF, BSEG, CDHDR, CDPOS, T001 a V_USERNAME. Pro aktivity související s workflow je nutný také přístup k tabulkám SWW_WI2OBJ a SWWLOGHIST. Tato úroveň přístupu se obvykle uděluje pouze specializovaným technickým týmům.
- Filtrování podle období: Pro zajištění výkonu dotazu je důležité filtrovat data podle konkrétního období. Dodaný dotaz obsahuje zástupné hodnoty pro počáteční a koncové datum, které se použijí na datum vytvoření dokladu (
BKPF.CPUDT). Pro první analýzu doporučujeme období 3 až 6 měsíců. - Filtrování podle entity: Kvůli objemu dat a zaměření analýzy vždy filtrujte podle kódu společnosti (
BKPF.BUKRS). Můžete také filtrovat podle typu dokladu (BKPF.BLART) a zahrnout pouze relevantní typy účetních dokladů, například „SA“ pro doklady hlavní knihy. Pokud provozní doklady, jako jsou faktury nebo platby, nespadají do rozsahu analýzy, můžete je vyloučit. - Výkon: Přímé dotazy do hlavních tabulek, jako jsou BSEG a CDPOS, mohou výrazně zatěžovat zdroje. Doporučujeme získávat data mimo špičku, aby nebyl ovlivněn výkon systému pro koncové uživatele. Při jednom spuštění nezískávejte data za období delší než jeden rok.
- ID úloh workflow: Dotaz obsahuje zástupné hodnoty, například „[WF_TASK_ID_SUBMIT]“ a „[WF_TASK_ID_APPROVE]“. Nahraďte je skutečnými ID úloh z konfigurace workflow účetních dokladů ve vašem systému. Zjistíte je ve spolupráci se specialistou na SAP Workflow nebo analýzou technické definice workflow v transakci PFTC.
Ukázkový dotaz sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Kroky
- Nastavte připojení k SAP: Ve svém externím ETL nástroji nakonfigurujte nové zdrojové připojení k systému SAP ECC. Obvykle budete potřebovat údaje o aplikačním serveru, klientovi, číslo systému a vyhrazeného uživatele SAP s potřebnými oprávněními RFC.
- Určete zdroje dat: V projektu extrakce přidejte požadované tabulky SAP jako zdroje dat. Mezi hlavní tabulky patří BKPF (hlavička účetního dokladu), BSEG (položka účetního dokladu), VBSEGK (hlavička předběžně zaúčtovaného dokladu), CDHDR (hlavička změnového dokladu), CDPOS (položky změnového dokladu), SWW_WI2OBJ (vazby workflow na objekty), SWWLOGHIST (protokol workflow) a SRGBTBREL (vazby příloh GOS).
- Extrahujte základní události (vytvoření a předběžné zaúčtování): Vytvořte první datový tok pro extrakci počátečních událostí. Pro událost „Účetní doklad předběžně zaúčtován“ použijte jako zdroj VBSEGK. Pro událost „Účetní doklad vytvořen“ použijte BKPF a odfiltrujte stornované doklady i doklady, které byly nejprve předběžně zaúčtovány. Toho lze dosáhnout pomocí anti-joinu s VBSEGK.
- Extrahujte události workflow: Vytvořte datový tok, který propojí BKPF a SWW_WI2OBJ pomocí klíče objektu (kód společnosti + číslo dokladu + fiskální rok) a vyhledá ID instance workflow. Výsledek propojte se SWWLOGHIST a extrahujte události jako „Odesláno“, „Schváleno“, „Zamítnuto“ a „Vyžádány změny“ podle výsledků úloh workflow a rozhodnutí uživatelů zaznamenaných v protokolu.
- Extrahujte události změn a mazání: Pomocí tabulek CDHDR a CDPOS určete změny. U události „Účetní doklad opraven“ vyfiltrujte změny provedené u předběžně zaúčtovaných dokladů (Object Class „FIPP“). Událost „Předběžně zaúčtovaný účetní doklad smazán“ vyhledejte podle značek smazání v protokolech změn předběžně zaúčtovaných dokladů.
- Extrahujte události příloh: Událost „Dokumentace připojena“ zachytíte propojením BKPF a SRGBTBREL, kde je typ objektu „BKPF“ a typ vazby „[Your attachment relationship type]“. Čas vytvoření vazby použijte jako čas události.
- Extrahujte události vyrovnání a storna: U události „Položka účetního dokladu vyrovnána“ vyhledejte v tabulce BSEG záznamy s vyplněným polem vyrovnávacího dokladu (AUGBL). Časem události je datum zaúčtování vyrovnávacího dokladu (AUGDT). Událost „Storno účetního dokladu zpracováno“ vyhledejte v BKPF mezi doklady, které jsou storny, tedy mají vyplněné pole stornovaného dokladu (STBLG).
- Odvoďte vypočítané události: Pro vypočítané události vytvořte samostatné bloky logiky. Událost „Ruční zadání identifikováno“ určete filtrováním BKPF podle seznamu kódů ručních transakcí (například FB01, FB50, F-02). U události „Mezipodnikové zaúčtování identifikováno“ seskupte tabulku BSEG podle ID dokladu a vyhledejte doklady s více než jedním odlišným kódem společnosti.
- Spojte všechny toky událostí: Pomocí transformace UNION v ETL nástroji sloučte výstupy jednotlivých toků událostí (vytvoření, předběžné zaúčtování, schválení atd.) do jedné tabulky záznamu událostí. Ve všech tocích sjednoťte názvy sloupců i datové typy.
- Namapujte výsledné schéma: Namapujte sloučená data do požadované struktury záznamu událostí a vytvořte atributy
JournalEntryId,ActivityName,EventTime,Usera další povinné či doporučené atributy. Přidejte statické sloupce, napříkladSourceSystem, a proLastDataUpdatepoužijte čas spuštění úlohy ETL. - Nastavte přírůstkové načítání: Pro pravidelnou extrakci nakonfigurujte strategii přírůstkového načítání. Jako značku průběžného načítání použijte datum posledního vytvoření nebo změny (například BKPF.CPUDT, CDHDR.UDATE), abyste načítali pouze nové nebo aktualizované záznamy od posledního spuštění.
- Exportujte data do ProcessMind: Naplánujte úlohu extrakce a nastavte závěrečný krok tak, aby se záznam událostí uložil jako soubor CSV nebo Parquet do umístění, odkud jej lze nahrát do ProcessMind.
Konfigurace
- Předpoklady: Licence k externímu ETL nástroji (například Theobald Xtract Universal, Informatica nebo Talend) s vyhrazeným konektorem SAP. Uživatelský účet SAP s přístupem RFC a oprávněním číst finanční tabulky (například S_TABU_DIS pro skupiny tabulek F_00 a F_WF), data workflow a protokoly změn.
- Parametry připojení: Budete potřebovat IP adresu nebo název hostitele aplikačního serveru SAP, číslo systému a ID klienta. Uživatelské jméno a heslo SAP spravujte bezpečným způsobem.
- Hlavní filtry: Na zdroji vždy filtrujte podle kódu společnosti (BKPF.BUKRS) a fiskálního roku (BKPF.GJAHR), abyste omezili objem dat. Doporučujeme také filtrovat podle data vytvoření dokladu (BKPF.CPUDT) a určit tak období extrakce, například posledních 6 měsíců.
- Výběr období: Pro počáteční načtení zvolte reprezentativní období, například 3 až 6 měsíců. Pro další přírůstková načtení použijte značku průběžného načítání založenou na časovém údaji, například
CPUDT, a načítejte pouze nové záznamy. - Výkon: Spojení tabulek BSEG, CDPOS a tabulek workflow mohou být velmi pomalá. Pokud to nástroj umožňuje, zajistěte, aby ETL nástroj předával filtry přímo do zdrojového systému SAP. Při extrakci rozdělte data na menší části nebo dávky, zejména při načítání rozsáhlých historických dat.
- Úpravy workflow: Způsob identifikace aktivit workflow, jako jsou „Schváleno“ nebo „Zamítnuto“, závisí na konkrétních šablonách workflow. Ve svém systému budete muset určit správná ID úloh workflow a klíče rozhodnutí uživatelů, které použijete ve filtrech.
Ukázkový dotaz sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Chcete začít?
Využijte tuto šablonu dat jako výchozí bod pro process mining procesu od záznamu po výkaznictví: účetní doklady. Získejte podrobnější přehled a zvyšte efektivitu finančního provozu.
Optimalizujte proces od záznamu po výkaznictví: účetní doklady
Zkraťte dobu zpracování účetních dokladů o 30 % a zajistěte bezchybné výkaznictví.
Platební kartu nepotřebujete, se zlepšováním můžete začít hned.