Šablona dat pro proces od záznamu po výkaznictví: účtování zápisů
Šablona dat pro proces od záznamu po výkaznictví: účtování zápisů
- Doporučené atributy ke shromáždění
- Aktivity, které je vhodné sledovat
- Praktický návod k extrakci dat
Atributy procesu od záznamu po výkaznictví: účtování zápisů
| Název | Popis | ||
|---|---|---|---|
| Aktivita ActivityName | Název obchodní činnosti, která proběhla v konkrétním okamžiku procesu účetního zápisu. | ||
| Popis Činnost označuje konkrétní krok nebo událost v životním cyklu účetního zápisu, například „Účetní zápis vytvořen“, „Účetní zápis odeslán ke kontrole“ nebo „Účetní zápis zaúčtován“. Tyto činnosti se obvykle odvozují z protokolů změn, aktualizací stavu nebo transakčních kódů zaznamenaných v systému. Analýza činností umožňuje vizualizovat průběh procesu, určit běžné postupy a odhalit odchylky od standardního postupu. Je základem pro výpočet ukazatelů, jako je četnost činností, čekání mezi kroky a míra shody. Proč je to důležité Určuje jednotlivé kroky procesu, takže lze zobrazit mapy procesů a analyzovat vzorce ve workflow. Kde data získat Odvozuje se z různých zdrojů, například z polí stavu v hlavičkových tabulkách a tabulkách položek (např. BKPF-BSTAT), protokolů změn dokladů (CDHDR/CDPOS) a protokolů workflow. Příklady Účetní zápis vytvořenÚčetní zápis zaparkovánÚčetní zápis odeslán ke kontroleÚčetní zápis schválenÚčetní zápis zaúčtován | |||
| Čas události EventTime | Časové razítko udávající, kdy v procesu účetního zápisu proběhla konkrétní činnost. | ||
| Popis Čas události je přesné datum a čas, kdy byla obchodní činnost provedena a zaznamenána v systému. Každá činnost v případu má vlastní časové razítko, které společně tvoří chronologickou posloupnost událostí. Tento atribut je nezbytný pro veškerou časovou analýzu procesu. Používá se k výpočtu doby zpracování, délky jednotlivých činností, čekání mezi kroky i časového rozložení práce. Přesná časová razítka jsou nutná pro vytvoření spolehlivého modelu procesu a výpočet ukazatelů výkonnosti, jako je doba schvalování. Proč je to důležité Určuje chronologické pořadí událostí. To je nezbytné pro výpočet všech časových ukazatelů a pochopení průběhu procesu. Kde data získat Údaje pocházejí z protokolů změn dokladů (CDHDR-UDATE, CDHDR-UTIME), protokolů workflow nebo časových razítek vytvoření či zadání v tabulkách, jako je BKPF (CPUDT, CPUTM). Příklady 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| ID účetního zápisu JournalEntryId | Jedinečný identifikátor účetního zápisu, který slouží jako hlavní identifikátor případu v procesu. | ||
| Popis ID účetního zápisu je jedinečné číslo přidělené každému účetnímu dokladu při jeho vytvoření v SAP S/4HANA. Umožňuje sledovat celý životní cyklus zápisu od vytvoření nebo zaparkování přes schvalovací workflow až po konečné zaúčtování, případné storno nebo vyrovnání. Při analýze process mining se toto ID používá k propojení všech souvisejících činností do jednoho případu. Seskupením událostí pod společným ID účetního zápisu mohou analytici sestavit průběh procesu od začátku do konce, měřit dobu zpracování a hledat odchylky nebo úzká místa u jednotlivých finančních transakcí. Tento atribut je základem celkového pohledu na proces. Proč je to důležité Tento identifikátor propojuje všechny související kroky procesu a umožňuje analyzovat celý průběh každého účetního zápisu. Kde data získat Jde o složený klíč, který se obvykle vytváří spojením kódu společnosti (BKPF-BUKRS), čísla dokladu (BKPF-BELNR) a fiskálního roku (BKPF-GJAHR). Příklady 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Částka v místní měně AmountInLocalCurrency | Celková hodnota účetního zápisu vyjádřená v místní měně kódu společnosti. | ||
| Popis Tento atribut vyjadřuje finanční hodnotu účetního zápisu. Obvykle jde o součet absolutních hodnot všech debetních nebo kreditních položek dokladu převedených do místní měny kódu společnosti. Analýza podle částky umožňuje rozdělit proces podle finančního dopadu. U zápisů s vysokou hodnotou může být například schvalování přísnější než u zápisů s nízkou hodnotou. Díky tomu lze při zlepšování procesů upřednostnit transakce s nejvyšším finančním rizikem. Proč je to důležité Udává finanční hodnotu zápisu a umožňuje sledovat, jak se průběh procesu mění podle výše částky. Kde data získat Vypočítá se jako součet částek z tabulky položek BSEG (pole DMBTR) pro daný účetní zápis (BELNR), převedený na kladnou hodnotu. Příklady 1500.75125000.0050.20 | |||
| Datum zaúčtování PostingDate | Datum, kdy je účetní zápis zaznamenán v hlavní knize a přiřazen k účetnímu období. | ||
| Popis Datum zaúčtování určuje účetní období, ve kterém se transakce objeví ve finančních výkazech. Pro účetnictví je zásadní a může se lišit od data vytvoření dokladu nebo jeho zadání do systému. V process mining se datum zaúčtování používá k analýze časových skupin, například při porovnávání uzávěrek na konci měsíce nebo sledování vývoje výkonnosti v různých účetních obdobích. Pomáhá také měřit prodlevu mezi vytvořením zápisu a jeho skutečným zaúčtováním. Proč je to důležité Poskytuje finanční kontext a umožňuje analyzovat výkonnost procesu v konkrétních účetních obdobích, například při měsíční nebo roční uzávěrce. Kde data získat Tabulka SAP S/4HANA BKPF, pole BUDAT (Posting Date in the Document). Příklady 2023-10-312023-11-012024-02-29 | |||
| Kód společnosti CompanyCode | Jedinečný identifikátor společnosti nebo právnické osoby, pro kterou se účetní zápis účtuje. | ||
| Popis Kód společnosti je základní organizační jednotkou v SAP Financials. Představuje samostatnou právnickou osobu, pro kterou se sestavují účetní výkazy. Každý účetní zápis je přiřazen ke konkrétnímu kódu společnosti. Tento atribut je důležitý pro rozdělení a porovnání výkonnosti procesů v různých částech organizace. Analytici mohou filtrovat proces podle konkrétní právnické osoby, porovnávat míru zamítnutí mezi kódy společností nebo hledat rozdíly v procesech podle regionu. Proč je to důležité Umožňuje filtrovat a porovnávat proces účetních zápisů mezi různými právnickými osobami nebo obchodními jednotkami organizace. Kde data získat Tabulka SAP S/4HANA BKPF, pole BUKRS (Company Code). Příklady 10001710US01 | |||
| Typ účetního zápisu JournalEntryType | Rozděluje účetní zápisy podle jejich účelu, například na zaúčtování majetku, fakturu dodavatele nebo zápis do hlavní knihy. | ||
| Popis Typ účetního zápisu, v terminologii SAP typ dokladu, je kód, který určuje kategorii účetního dokladu. Ovlivňuje například číselnou řadu dokladu a typy účtů, na které lze účtovat. Analýza podle typu účetního zápisu pomáhá pochopit rozdíly v průběhu procesu. Schvalování jednoduchého časového rozlišení (typ SA) může být například výrazně jednodušší než schvalování složitého pořízení majetku (typ AA). Tento atribut je důležitý pro dashboard „Shoda podle typu zápisu“. Proč je to důležité Rozděluje zápisy podle obchodního kontextu a umožňuje analyzovat rozdíly v průběhu a výkonnosti procesu u různých typů finančních transakcí. Kde data získat Tabulka SAP S/4HANA BKPF, pole BLART (Document Type). Příklady SAKRAA | |||
| Uživatel, který záznam vytvořil CreatedByUser | ID uživatele, který vytvořil účetní zápis. | ||
| Popis Tento atribut uchovává jedinečný identifikátor uživatele, který zahájil proces vytvořením původního dokladu. Může jít o účetního, pracovníka firmy nebo ID systému pro automaticky vytvářené zápisy. Analýza podle autora pomáhá odhalit vzorce spojené s konkrétními uživateli nebo týmy. Může ukázat potřebu školení, pokud někteří uživatelé častěji čelí zamítnutí, nebo upozornit na uživatele s dobrými výsledky. Tento atribut je nezbytný pro dashboard „Aktivita a výkonnost uživatelů“. Proč je to důležité Přiřazuje aktivity v procesu konkrétním uživatelům. Umožňuje analyzovat výkonnost, vyvažovat pracovní zátěž a hledat příležitosti ke školení. Kde data získat Tabulka SAP S/4HANA BKPF, pole USNAM (User Name). Příklady ABROWNCJONESBATCH_USER | |||
| Čas ukončení EndTime | Časové razítko označující, kdy byla aktivita dokončena. | ||
| Popis Čas ukončení označuje dokončení aktivity. V mnoha záznamech událostí jsou čas zahájení a čas ukončení aktivity stejné, protože jde o okamžitou událost. U aktivit s měřitelnou dobou trvání, například při aktivní kontrole dokumentu uživatelem, může tento atribut zachytit skutečnou délku. Samostatný čas ukončení umožňuje přesněji vypočítat dobu zpracování aktivity a odlišit ji od čekání. Pomáhá rozlišit dobu, kdy se na úkolu skutečně pracovalo, od doby, kdy čekal ve frontě. Proč je to důležité Umožňuje přesně vypočítat dobu zpracování aktivity a oddělit aktivní práci od čekání. Kde data získat U okamžitých událostí bývá stejný jako StartTime. U aktivit s dobou trvání může pocházet z protokolů workflow nebo se vypočítat podle následujících událostí. Příklady 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Doba schvalování ApprovalCycleTime | Doba od odeslání účetního zápisu ke schválení do jeho schválení nebo zamítnutí. | ||
| Popis Tato vypočítaná metrika měří dobu trvání samotného schvalování. Jde o čas mezi aktivitou „Účetní zápis odeslán ke kontrole“ a následující aktivitou „Účetní zápis schválen“ nebo „Účetní zápis zamítnut“. Tento KPI pomáhá odhalit úzká místa ve schvalovacím workflow. Dlouhá doba schvalování může výrazně prodloužit celý proces. Analýza podle schvalujícího, kódu společnosti nebo typu účetního zápisu může ukázat konkrétní oblasti ke zlepšení. Proč je to důležité Odděluje dobu schvalování od ostatních částí procesu a pomáhá určit a řešit úzká místa při kontrole a schvalování. Kde data získat Vypočítá se jako časový rozdíl mezi událostí „Účetní zápis odeslán ke kontrole“ a událostí „Účetní zápis schválen“ nebo „Účetní zápis zamítnut“. Příklady 1 den 2 hodiny4 hodiny 25 minut5 dní 0 hodin | |||
| Důvod storna ReversalReason | Kód označující důvod, proč byl zaúčtovaný účetní zápis stornován. | ||
| Popis Pokud je zaúčtovaný účetní zápis chybný, nelze ho smazat. Je třeba ho stornovat novým dokladem. Kód důvodu storna vysvětluje, proč k tomu došlo, například kvůli nesprávnému datu nebo částce zaúčtování. Analýza důvodů storna pomáhá hledat příčiny chyb v procesu Record to Report. Častý výskyt určitého důvodu může ukazovat na systémový problém, například nedostatečné školení nebo selhání kontrol. Jeho řešení pomáhá zvýšit kvalitu hned napoprvé. Proč je to důležité Pomáhá hledat příčiny chyb vedoucích ke stornu a poskytuje podklady pro omezení opakované práce a zlepšení kvality procesu. Kde data získat Tabulka SAP S/4HANA BKPF, pole STGRD (Reason for reversal). Příklady 010205 | |||
| Kód transakce TransactionCode | Kód transakce SAP použitý k vytvoření nebo změně účetního zápisu. | ||
| Popis Kód transakce (T-Code) je zkratka označující konkrétní funkci nebo program v SAP. U účetních zápisů mohou různé kódy T-Code ukazovat, jak zápis vznikl. Například FB01 označuje ruční zaúčtování do hlavní knihy, FV50 předběžné uložení a automatický kód zápis vytvořený systémem. Tento atribut dobře ukazuje, zda aktivitu provedl uživatel ručně, nebo systém automaticky. Je důležitý pro výpočet KPI míry ručního zaúčtování a pro hledání příležitostí k automatizaci. Proč je to důležité Ukazuje, jak byl zápis zpracován, například ručně nebo automaticky. Pomáhá analyzovat automatizaci a rozdíly v průběhu procesu. Kde data získat Tabulka SAP S/4HANA BKPF, pole TCODE (Transaction Code). Příklady FB01FV50F-02 | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data tohoto záznamu naposledy obnovena ze zdrojového systému. | ||
| Popis Tento atribut zaznamenává datum a čas poslední extrakce nebo aktualizace dat ze zdrojového systému. Ukazuje, jak aktuální jsou analyzovaná data. Čas poslední aktualizace pomáhá posoudit aktuálnost analýzy procesu. Uživatelé díky němu mohou správně interpretovat dashboardy a KPI a vědí, zda pracují s téměř aktuálními daty, nebo se snímkem z předchozího období. Proč je to důležité Ukazuje aktuálnost dat, takže uživatelé vědí, jak aktuální je analýza procesu. Kde data získat Jde o atribut metadat, který se obvykle generuje a zapisuje do každého záznamu při načítání dat. Příklady 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Ruční zaúčtování IsManualPosting | Logická hodnota označující, zda uživatel zaúčtoval účetní zápis ručně. | ||
| Popis Tento atribut označuje účetní zápisy zaúčtované ručním zásahem uživatele, nikoli automaticky systémovou úlohou nebo rozhraním. Obvykle se odvozuje z kódu transakce použitého při zaúčtování dokladu. Příznak slouží k výpočtu KPI míry ručního zaúčtování a pomáhá organizacím sledovat pokrok v automatizaci procesu Record to Report. Filtrováním ručně zaúčtovaných položek mohou analytici určit, které situace stále vyžadují zásah člověka, a posoudit jejich potenciál pro automatizaci. Proč je to důležité Rozlišuje ruční a systémové zaúčtování. Je důležitý pro měření míry automatizace a hledání dalších příležitostí k automatizaci. Kde data získat Jde o vypočítaný atribut odvozený z TransactionCode. Příznak se nastaví na „true“, pokud kód transakce odpovídá předem určenému seznamu ručních kódů, například „FB01“ nebo „F-02“. Příklady truefalse | |||
| Schvalující uživatel ApproverUser | ID uživatele, který účetní zápis schválil nebo zamítl. | ||
| Popis Tento atribut označuje uživatele, který kontroluje odeslaný účetní zápis a rozhoduje o jeho schválení. Ve workflow s více úrovněmi schvalování může mít jeden účetní zápis několik schvalujících. Tyto informace jsou nezbytné pro podrobnou analýzu schvalování. Pomáhají měřit pracovní zátěž jednotlivých schvalujících, počítat dobu schvalování a odhalovat úzká místa ve schvalovacím řetězci. Přímo podporují dashboard „Aktivita a výkonnost uživatelů“. Proč je to důležité Určuje osobu odpovědnou za schválení a umožňuje analyzovat její pracovní zátěž, výkonnost a úzká místa. Kde data získat Získává se z protokolů workflow, například SWW_WI2OBJ nebo SWWLOG, případně z tabulek změnových dokladů CDHDR/CDPOS, podle uživatele, který provedl schvalovací krok. Příklady DMILLERFWHITEKCHEN | |||
| Stav dokladu DocumentStatus | Aktuální stav zpracování účetního zápisu, například předběžně uložený, zaúčtovaný nebo vyrovnaný. | ||
| Popis Stav dokladu označuje, v jaké fázi životního cyklu se účetní zápis nachází. Předběžně uložený doklad je například uložený, ale ještě není zaúčtovaný do hlavní knihy. Zaúčtovaný doklad je naproti tomu dokončený. Analýza stavu pomáhá pochopit průběh práce a odhalit úzká místa. Velký počet dokladů, které dlouho zůstávají ve stavu „předběžně uložený“ nebo „čeká na schválení“, může ukazovat na neefektivní proces. Tento atribut je také důležitým zdrojem pro odvození aktivit procesu. Proč je to důležité Ukazuje, v jaké fázi životního cyklu se účetní zápis nachází, a pomáhá odhalit fronty a úzká místa. Kde data získat Tabulka SAP S/4HANA BKPF, pole BSTAT (Document status). Příklady VAB | |||
| Účetní rok FiscalYear | Účetní rok, do kterého účetní zápis patří. | ||
| Popis Účetní rok je spolu s kódem společnosti a číslem dokladu součástí jedinečného klíče účetního zápisu. Označuje finanční rok, ke kterému se doklad vztahuje. Při analýze se účetní rok používá ke sledování dlouhodobých trendů a k zajištění jedinečnosti identifikátoru případu. Porovnání metrik procesu mezi účetními roky může ukázat, jak se jeho výkonnost v čase zlepšuje nebo zhoršuje. Proč je to důležité Pomáhá jednoznačně identifikovat doklady a umožňuje porovnávat výkonnost procesu mezi jednotlivými roky. Kde data získat Tabulka SAP S/4HANA BKPF, pole GJAHR (Fiscal Year). Příklady 202320242022 | |||
| Vyžadoval opravu IsRework | Logická hodnota označující, zda účetní zápis vyžadoval opakované zpracování, například opravu po zamítnutí. | ||
| Popis Tento vypočítaný atribut označuje účetní zápisy, které se odchýlily od ideálního průběhu procesu. Obvykle se nastaví na true, pokud případ obsahuje aktivitu, jako je „Účetní zápis zamítnut“ nebo „Účetní zápis opraven“. Příznak usnadňuje analýzu efektivity procesu. Umožňuje rychle vypočítat KPI míry opakovaného zpracování a přímo porovnat dobu průchodu a náklady u případů s opravami a bez nich. Hledání příčin opakovaného zpracování je častým cílem zlepšování procesů. Proč je to důležité Označuje případy, které vyžadovaly opravu nebo další průchod procesem. Usnadňuje vyčíslení neefektivity a hledání jejích příčin. Kde data získat Jde o vypočítaný atribut odvozený z posloupnosti aktivit v případu. Nastaví se na „true“, pokud případ obsahuje například aktivitu „Účetní zápis zamítnut“. Příklady truefalse | |||
| Zdrojový systém SourceSystem | Určuje zdrojový systém, ze kterého byla data o účetních zápisech extrahována. | ||
| Popis Tento atribut určuje zdrojový systém, ve kterém vznikla data účetního zápisu. Ve firmách s více instancemi ERP nebo kombinací starších a moderních systémů pomáhá rozlišit jednotlivé zdroje dat. Při analýze lze podle něj porovnávat výkonnost procesů v různých systémech nebo filtrovat data podle konkrétního zdroje. Je důležitý pro správu dat a pro pochopení jejich kontextu. Proč je to důležité Poskytuje kontext o původu dat. V prostředí s více systémy je důležitý pro přesnou analýzu a porovnání procesů. Kde data získat Obvykle jde o statickou hodnotu doplněnou při extrakci dat, která označuje konkrétní instanci SAP S/4HANA, například SID nebo název logického systému. Příklady S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
Aktivity procesu od záznamu po výkaznictví: účtování zápisů
| Aktivita | Popis | ||
|---|---|---|---|
| Storno účetního zápisu zpracováno | Dříve zaúčtovaný účetní zápis se stornuje vytvořením nového dokladu s opačnými zápisy. Tato výslovná a auditovatelná transakce slouží k opravě chyb v zaúčtovaných dokladech. | ||
| Proč je to důležité Storno znamená, že v zaúčtovaném dokladu došlo k chybě. Vysoký počet storen může poukazovat na problémy ve schvalování nebo kvalitě zadávání dat. Jejich sledování pomáhá zvýšit přesnost zpracování hned napoprvé. Kde data získat Storno je výslovná událost. Hlavička nového stornovacího dokladu (BKPF) obsahuje odkaz na původní doklad v poli čísla stornovaného dokladu (STBLG). Časem události je datum zaúčtování nového dokladu. Zachycení Vyhledejte doklady s vyplněným polem BKPF-STBLG. Časovou značkou události je datum zaúčtování stornovacího dokladu. Typ události explicit | |||
| Účetní zápis odeslán ke kontrole | Autor účetního zápisu formálně odešle doklad ke kontrole a schválení ve workflow. Tím se předává práce od zadávání dat do formálního kontrolního procesu a začíná schvalovací cyklus. | ||
| Proč je to důležité Tímto okamžikem začíná běžet doba schvalování. Měření času od tohoto bodu do konečného schválení nebo zamítnutí pomáhá určit úzká místa přímo ve fázi kontroly a schvalování. Kde data získat Tato událost se často zaznamenává v protokolech workflow (tabulky SWW_WIHEAD, SWWLOG) propojených s obchodním objektem. Lze ji také odvodit ze změny stavu ve vlastním poli hlavičky dokladu (BKPF). Zachycení Časové razítko vytvoření položky workflow nebo změna pole stavu na „Odesláno“ či „Probíhá kontrola“. Typ události inferred | |||
| Účetní zápis schválen | Oprávněný vedoucí pracovník udělí účetnímu zápisu konečné schválení a potvrdí jeho platnost a správnost. Jde o poslední kontrolní krok před zaúčtováním dokladu do hlavní knihy. | ||
| Proč je to důležité Tento důležitý milník uzavírá schvalovací cyklus. Doba do jeho dosažení tvoří významnou část celkové doby procesu a ukazuje, jak efektivně schvalovatelé pracují. Kde data získat Událost lze odvodit z protokolu workflow, který zaznamenává poslední krok schválení, nebo ze změny stavu dokladu. ID uživatele, který zápis schválil, a časové razítko lze získat z dat workflow nebo protokolů změn. Zachycení V protokolech workflow vyhledejte časové razítko posledního kroku schválení nebo v protokolech změn změnu stavu na „Schváleno“. Typ události inferred | |||
| Účetní zápis vyrovnán | Otevřená položka účetního zápisu se vyrovná jiným zaúčtováním, například když platba vyrovná fakturu. Tato činnost označuje odsouhlasení konkrétních položek a jejich uzavření. | ||
| Proč je to důležité U mnoha účetních zápisů, zejména u zápisů na účtech s otevřenými položkami nebo na přechodných účtech, jde o závěrečný krok odsouhlasení. Doba od zaúčtování do vyrovnání ukazuje efektivitu odsouhlasování. Kde data získat Událost lze odvodit z tabulky položek (BSEG nebo pohledu ACDOCA). Po vyrovnání položky se vyplní pole data vyrovnání (AUGDT) a čísla vyrovnávacího dokladu (AUGBL). Zachycení Jako časové razítko události použijte datum vyrovnání položky (BSEG-AUGDT). Typ události inferred | |||
| Účetní zápis vytvořen | Tato činnost označuje vytvoření účetního dokladu v systému. Záznam se uloží do hlavičkové tabulky (BKPF), ale zatím není zaúčtován do hlavní knihy. Tím začíná životní cyklus účetního zápisu. | ||
| Proč je to důležité Jde o hlavní počáteční událost procesu. Doba od této události do zaúčtování je důležitá pro měření celkové doby zpracování a odhalení počátečních prodlev při zadávání dat. Kde data získat Tuto událost lze přímo zjistit z tabulky SAP BKPF pomocí polí data vytvoření (CPUDT) a času vytvoření (CPUTM) pro dané číslo dokladu (BELNR). Zachycení Časové razítko události určete pomocí BKPF-CPUDT a BKPF-CPUTM. Typ události explicit | |||
| Účetní zápis zaúčtován | Účetní zápis je oficiálně zaevidován v hlavní knize a ovlivňuje finanční výkazy společnosti. V tomto okamžiku se z dokladu stává trvalý finanční záznam. | ||
| Proč je to důležité Jde o hlavní milník úspěšného dokončení a konec základního cyklu zpracování. Průchodnost zaúčtovaných zápisů a doba potřebná k dosažení této fáze patří mezi základní ukazatele process miningu. Kde data získat Jde o výslovnou událost označenou datem zaúčtování (BUDAT) v tabulce BKPF. U zaúčtovaného dokladu je pole stavu dokladu (BSTAT) prázdné, na rozdíl od zaparkovaných dokladů („V“) nebo podržených dokladů („D“). Zachycení Pro časové razítko události použijte datum zaúčtování (BKPF-BUDAT) a datum zadání (BKPF-CPUDT). Prázdná hodnota BKPF-BSTAT označuje zaúčtovaný doklad. Typ události explicit | |||
| Připojen podpůrný dokument | Uživatel připojí k účetnímu zápisu jeden nebo více podpůrných dokumentů, například faktury nebo tabulky. Tyto dokumenty obvykle dokládají finanční transakci a poskytují k ní kontext při kontrole a auditu. | ||
| Proč je to důležité Přiložení dokumentace před kontrolou je důležité pro dodržení požadavků i efektivní schvalování. Tato činnost pomáhá měřit, zda se dodržují pravidla pro dokumentaci a jak dokumentace ovlivňuje dobu schvalování. Kde data získat Tato událost se obvykle odvozuje z časového razítka vytvoření příloh propojených prostřednictvím Generic Object Services (GOS). Tabulka SRGBTBREL propojuje obchodní objekt, například doklad BKPF, s přílohou. Zachycení Vyhledejte v tabulkách příloh GOS, například SRGBTBREL, odkazy na objekt BKPF a použijte časové razítko vytvoření přílohy. Typ události inferred | |||
| Účetní zápis opraven | Uživatel upraví účetní zápis poté, co byl zamítnut nebo vrácen k opravě. Tato činnost představuje práci navíc potřebnou k odstranění problémů zjištěných při kontrole před opětovným odesláním. | ||
| Proč je to důležité Tato činnost umožňuje vyčíslit opakované opravy. Analýza jejich četnosti a délky pomáhá najít zdroje neefektivity a příležitosti ke školení nebo zpřesnění procesu. Kde data získat Událost lze odvodit sledováním data poslední změny (AEDAT) v tabulce BKPF u dokladu, který byl dříve ve stavu „Zamítnuto“. Protokoly změn poskytují podrobnější informace o provedených úpravách. Zachycení Pro změny provedené po zamítnutí použijte časové razítko z hlaviček protokolu změn (CDHDR-UDATE). Typ události inferred | |||
| Účetní zápis zamítnut | Kontrolor nebo schvalovatel účetní zápis zamítne, takže jej nelze zaúčtovat. Doklad se obvykle vrací autorovi k opravě a proces se opakuje. | ||
| Proč je to důležité Sledování zamítnutí je důležité pro pochopení kvality procesu a odhalení častých chyb. Vysoký počet zamítnutí poukazuje na problémy s přesností dat, znalostí pravidel nebo úplností podpůrné dokumentace. Kde data získat Tuto událost lze odvodit ze změny stavu v protokolu workflow nebo ve vlastním poli stavu účetního dokladu. Časové razítko může poskytnout protokol změn dokumentu (CDHDR/CDPOS) pro příslušné pole stavu. Zachycení Vyhledejte změnu pole stavu na „Zamítnuto“ v protokolech změn (CDHDR/CDPOS) nebo v protokolech workflow. Typ události inferred | |||
| Účetní zápis zaparkován | Uživatel uloží neúplný účetní zápis, aniž by ho zaúčtoval. Zápis tak lze později doplnit nebo zkontrolovat. Tato výslovná akce vytvoří hlavičkový záznam dokladu se stavem „zaparkováno“, který zatím není zaúčtován. | ||
| Proč je to důležité Zaparkování je běžným krokem před odesláním ke schválení. Sledování doby, po kterou doklad zůstává zaparkovaný, pomáhá odhalit prodlevy při doplňování a přípravě dat před zahájením formální kontroly a schvalování. Kde data získat V tabulce BKPF je zaparkovaný doklad označen hodnotou „V“ v poli stavu dokladu (BSTAT). Časovou značkou události je datum vytvoření (CPUDT). Zachycení Vyfiltrujte doklady, u kterých má BKPF-BSTAT v době vytvoření hodnotu „V“. Typ události explicit | |||
| Účetní zápis změněn po zaúčtování | Uživatel po zaúčtování do hlavní knihy upraví omezenou sadu polí účetního zápisu. Většina finančních údajů je po zaúčtování neměnná, některá pole, například text nebo přiřazení, však upravit lze. | ||
| Proč je to důležité Tato činnost je důležitým ukazatelem pro kontrolu shody. Změny po zaúčtování mohou znamenat pokus o úpravu záznamů. Je proto třeba je pečlivě sledovat, aby se předešlo podvodům a zachovala integrita dat. Kde data získat Událost lze spolehlivě odvodit z tabulek protokolu změn (CDHDR a CDPOS). Záznam v CDHDR pro číslo dokladu s datem změny po datu zaúčtování označuje změnu provedenou po zaúčtování. Zachycení V CDHDR vyhledejte záznamy, u kterých je čas změny (UDATE/UTIME) pozdější než datum zaúčtování dokladu (BKPF-BUDAT). Typ události inferred | |||
| Zjištěno ruční zaúčtování | Účetní zápis byl zaúčtován pomocí ručního transakčního kódu, nikoli přes automatizované rozhraní nebo dávkovou úlohu. Nejde o událost v čase, ale o klasifikaci činnosti při zaúčtování. | ||
| Proč je to důležité Rozpoznání ručně zaúčtovaných zápisů je důležité pro iniciativy zaměřené na automatizaci. Vysoký podíl ručního zaúčtování může ukazovat na příležitosti ke zjednodušení procesů propojením subsystémů nebo využitím automatizovaných programů pro zaúčtování. Kde data získat Klasifikace vychází z pole transakčního kódu (TCODE) v hlavičkové tabulce dokladu (BKPF). Zápis se zařadí podle seznamu známých ručních transakčních kódů, například FB01, F-02 nebo FB50. Zachycení Při zaúčtování klasifikujte událost podle BKPF-TCODE a předem stanoveného seznamu ručních transakčních kódů. Typ události calculated | |||
Návody k extrakci dat
Kroky
- Předpoklady a přístup: Zajistěte, aby měl uživatel potřebná oprávnění k dotazování podkladové databáze SAP S/4HANA nebo ke spouštění reportů ABAP. Budete potřebovat přístup pro čtení k CDS views I_JournalEntry a I_JournalEntryItem a k tabulkám CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ a SWWLOGHIST. Přístup se obvykle zajišťuje přes databázového klienta, například SAP HANA Studio nebo DBeaver, případně pomocí SAP ABAP Development Tools (ADT) pro Eclipse.
- Zjistěte nastavení konkrétního systému: Před spuštěním dotazu zjistěte kódy úkolů používané ve workflow schvalování účetních zápisů. Požádejte správce workflow SAP o ID úkolů, například TS12345678, která odpovídají událostem odeslání, zamítnutí a schválení. Tato ID budete potřebovat místo zástupných hodnot v závěrečném dotazu.
- Připravte dotaz SQL: Zkopírujte celý dotaz SQL uvedený v části
querydo vybraného klienta SQL nebo vývojového nástroje. - Nastavte parametry dotazu: Vyhledejte v dotazu zástupné hodnoty a nahraďte je konkrétními údaji. Patří sem
[YourCompanyCode],[StartDate]a[EndDate]. Nahraďte také zástupná ID úkolů workflow ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) hodnotami zjištěnými v předchozím kroku. - Spusťte extrakční dotaz: Spusťte upravený dotaz SQL nad databází SAP S/4HANA. V závislosti na časovém období a objemu dat může jeho dokončení trvat dlouho. Doporučujeme spouštět ho mimo špičku.
- Zkontrolujte první výsledky: Po dokončení dotazu zkontrolujte několik prvních řádků výstupu a ověřte, že jsou očekávaným způsobem vyplněné všechny sloupce, například JournalEntryId, ActivityName a EventTime. Výsledek by měl obsahovat jeden řádek pro každou jedinečnou obchodní událost v životním cyklu účetního zápisu.
- Exportujte data do CSV: Exportujte celou sadu výsledků z nástroje SQL do jednoho souboru CSV. Použijte kódování UTF-8, aby nedocházelo k problémům se speciálními znaky.
- Připravte soubor k nahrání: Před nahráním do nástroje process mining ověřte, že soubor CSV obsahuje požadovaná záhlaví. Data už mají podobu záznamu událostí, takže není potřeba je dále transformovat ani převádět do jiného formátu.
Konfigurace
- CDS views (Core Data Services): Extrakce používá především
I_JournalEntrypro data hlaviček aI_JournalEntryItempro položky a částky. Tato views poskytují zjednodušený a sémanticky bohatý přístup k univerzálnímu deníku (ACDOCA). - Podpůrné tabulky: Pro úplný přehled procesu dotaz propojuje také několik standardních tabulek SAP:
CDHDRaCDPOSpro sledování změn dokumentů.SRGBRELaSOODpro zjištění, kdy jsou přílohy propojeny prostřednictvím Generic Object Services (GOS).SWW_WI2OBJaSWWLOGHISTpro extrakci důležitých událostí ze schvalovacího workflow.
- Filtrování podle období: Kvůli výkonu je nutné filtrovat data podle konkrétního časového období. V klauzuli
WHEREpoužijte poleI_JournalEntry.CreationDateTime. Pro úvodní analýzu doporučujeme období 3 až 6 měsíců. - Filtrování podle organizace: Vždy omezte extrakci filtrem
CompanyCode. Dotazování všech kódů společností najednou může ve velkém systému trvat velmi dlouho. - ID úkolů workflow: Dotaz obsahuje zástupné hodnoty pro ID úkolů workflow, například
[Workflow Approved Task ID]. Tato ID se v každé instalaci SAP liší a je nutné je správně nastavit, aby se extrahovaly aktivity workflow. Bez nich se nezachytí události odeslání, schválení ani zamítnutí. - Předpoklady: Uživatel spouštějící dotaz potřebuje rozsáhlá oprávnění pro čtení finančních, systémových a workflow tabulek. Tato oprávnění nejsou standardní a je nutné je přidělit zvlášť.
Ukázkový dotaz sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Kroky
- Ověřte, že je schválen přímý přístup SQL k databázi SAP HANA a že uživatel provádějící extrakci má oprávnění ke čtení tabulek BKPF a ACDOCA. Ověřte také přístup ke všem nakonfigurovaným zdrojům workflow, příloh, historie změn, vyrovnání nebo storen, které váš systém vyžaduje. Přímý přístup k databázi se obvykle zajišťuje pomocí SAP HANA Database Explorer, SAP HANA Studio nebo schváleného SQL klienta. Nespouštějte extrakční dotazy v transakci aplikace SAP, pokud váš systém takový přístup výslovně nepodporuje.
- Ověřte fyzické schéma tabulek BKPF a ACDOCA včetně polí klienta, kódu společnosti, fiskálního roku, čísla dokladu, typu dokladu, data účtování, data vytvoření, času vytvoření, uživatele, částky v lokální měně a případných polí pro storno nebo vyrovnání. Nasazení SAP S/4HANA se mohou lišit schématem i dostupností polí. Nahraďte proto zástupné hodnoty v hranatých závorkách v dotazu poli ověřenými ve vašem systému.
- Určete důvěryhodné zdroje událostí workflow a příloh. BKPF a ACDOCA obsahují údaje o účetních dokladech a položkách, samy však spolehlivě nezachycují všechny události odložení, odeslání, zamítnutí, opravy, schválení ani přiložení souboru. Nahraďte zástupné hodnoty zdrojů workflow a příloh schválenými View nebo tabulkami z vaší implementace. Pokud zdroj není k dispozici, události nevymýšlejte. Nakonfigurujte odpovídající zdroj, nebo danou aktivitu po zdokumentovaném schválení vynechte.
- Nastavte parametry extrakce pro požadované období, kódy společností, typy dokladů a klienta. Pro úvodní ověření doporučujeme období tří až šesti měsíců. Podle dohodnutého rozsahu procesu použijte pro provozní události časové razítko události a pro účetní události datum účtování.
- Spusťte celý SQL dotaz ve schváleném SQL klientovi HANA. Dotaz vytvoří jeden řádek události pro každou výslovně extrahovanou aktivitu. Pro účetní události používá BKPF a ACDOCA, pro události workflow, příloh, změn, vyrovnání a storen pak nakonfigurované zdrojové View. Aktivity neodvozuje pouze z existence dokladu.
- Zkontrolujte strukturu výstupu. JournalEntryId je identifikátor případu, ActivityName označuje aktivitu a EventTime obsahuje časové razítko události. Doporučené obchodní atributy se vracejí, pokud jsou k dispozici. Ověřte, že EventTime obsahuje časové razítko a že JournalEntryId ani ActivityName nejsou u žádného řádku prázdné.
- Porovnejte účetní data s očekávanou populací BKPF pro vybraného klienta, kódy společností, fiskální roky a období. Porovnání proveďte podle jedinečných hodnot JournalEntryId. Počty událostí workflow a příloh ověřte samostatně, protože pravidla uchovávání a časová razítka se mohou od účetních dat lišit.
- Ověřte pořadí událostí a způsob zpracování duplicit. Více položek v ACDOCA nesmí vytvářet duplicitní účetní události, pokud návrh procesu výslovně nevyžaduje události na úrovni položek. Použijte agregační logiku v dotazu, která vytvoří jednu účetní událost pro každý účetní zápis a typ události. Pokud jsou k dispozici, zachovejte přitom identifikátory událostí ze zdrojů.
- Exportujte výsledek jako CSV v kódování UTF-8 nebo v jiném tabulkovém formátu podporovaném ProcessMind. Zachovejte přesné názvy sloupců JournalEntryId, ActivityName a EventTime. Seřaďte soubor podle JournalEntryId a EventTime a další atributy ponechte jako sloupce. Nahrajte soubor do ProcessMind a nastavte JournalEntryId jako identifikátor případu, ActivityName jako aktivitu a EventTime jako časové razítko události.
Konfigurace
- Období: Začněte třemi až šesti měsíci. Pro testování výkonu zvolte kratší období a rozšiřte ho až po ověření počtu řádků a pokrytí událostí.
- Rozsah klientů a společností: Nastavte [Client parameter] a omezte CompanyCode na požadované právní subjekty. V systému s více klienty filtr klienta nevynechávejte.
- Rozsah účetních dat: Nastavte [Document type filter] a případně také filtry fiskálního roku a data účtování. Zahrňte zaúčtované i nezaúčtované doklady pouze tehdy, pokud je vybraný zdroj spolehlivě zachycuje.
- Rozsah workflow: Nastavte [Workflow event source] a mapování typů událostí na aktivity odeslání, zamítnutí, opravy a schválení. Ověřte, zda časová razítka označují vytvoření, provedení, nebo dokončení akce workflow.
- Rozsah příloh: Nastavte [Attachment event source] a pole vztahu, které propojuje přílohu s účetním zápisem. Ověřte, zda zdroj zaznamenává vytvoření, nahrazení, nebo odstranění přílohy.
- Rozsah změn: Pro změny po zaúčtování nastavte [Change history source]. Ověřte, že zdroj identifikuje účetní zápis a poskytuje spolehlivé časové razítko změny.
- Rozsah vyrovnání: Nastavte [Clearing source] a vztah mezi vyrovnávaným účetním dokladem a dokladem o vyrovnání. Rozhodněte, zda má být událost přiřazena původnímu účetnímu zápisu, dokladu o vyrovnání, nebo oběma.
- Rozsah storen: Nastavte [Reversal source] a vztah mezi původním dokladem a stornem. Pokud je tento vztah k dispozici, dotaz přiřadí aktivitu storna k původnímu JournalEntryId.
- Klasifikace ručního účtování: Nastavte [Manual posting source] nebo ověřené pole původu účtování. Aktivita Manual Posting Identified slouží ke klasifikaci a měla by konzistentně používat časové razítko účtování nebo jiné schválené časové razítko.
- Částka v měně: ACDOCA obsahuje data na úrovni položek. Dotaz agreguje částky v lokální měně podle účetního zápisu. Ověřte znaménkovou konvenci a rozhodněte, zda zahrnout statistické řádky, řádky konkrétní účetní knihy nebo rozšiřující účetní knihy.
- Výkon: Vybírejte pouze potřebné sloupce, filtrujte co nejdříve, vyhněte se neomezenému prohledávání ACDOCA a dotaz spouštějte ve schváleném čase pro reporting. Pokud to systém podporuje, využijte omezení oddílů pomocí filtrů klienta, fiskálního roku, kódu společnosti a data účtování.
- Zpracování duplicit: Pokud jsou k dispozici, používejte identifikátory událostí ze zdroje. Pokud zdroj obsahuje opakované technické záznamy, použijte zdokumentované pravidlo pro odstranění duplicit, ale neslučujte skutečně samostatné akce workflow.
- Předpoklady: Potřebujete databázová oprávnění, schválené připojení k SAP HANA, přístup ke nakonfigurovaným zdrojům workflow a příloh, odpovídající konfiguraci SAP Financial Accounting a workflow a exportní formát podporovaný ProcessMind.
Ukázkový dotaz sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Kroky
- Vytvořte program ABAP: Otevřete editor ABAP pomocí transakčního kódu
SE38. Zadejte název nového programu, napříkladZ_PM_JE_EXTRACT, a klikněte na „Vytvořit“. Zadejte vhodný název, jako typ nastavte „Spustitelný program“ a uložte jej jako lokální objekt nebo do balíčku. - Definujte výběrovou obrazovku: V programu definujte parametry a výběrové možnosti, které uživatelům umožní filtrovat data. Zahrňte období pro datum vytvoření účetního zápisu (
P_CPUDT_FR,P_CPUDT_TO), výběrovou možnost pro kód společnosti (SO_BUKRS) a cestu k výstupnímu souboru na aplikačním serveru (P_FPATH). - Deklarujte datové struktury: Definujte strukturu interní tabulky odpovídající požadovanému formátu záznamu událostí. Bude obsahovat konečný výstup. Deklarujte také interní tabulky a pracovní oblasti pro tabulky SAP, ze kterých budete vybírat data, například BKPF, ACDOCA, CDHDR, CDPOS a různé tabulky workflow.
- Implementujte logiku výběru dat: Napište hlavní logiku ABAP pro získání dat ke všem 12 požadovaným aktivitám. Pro přehlednost vytvořte samostatné podprogramy (FORM) pro každou aktivitu. Můžete například vytvořit FORM pro
get_created_events,get_parked_events,get_workflow_eventsa další. - Vyberte události „Vytvořeno“ a „Zaúčtováno“: Načtěte data z tabulky BKPF podle kritérií zadaných na výběrové obrazovce. Záznam v BKPF označuje vytvoření. Doklad se stavem
BSTAT = ' 'se považuje za zaúčtovaný. Jako čas události použijte časové razítko vytvoření (CPUDT,CPUTM). - Vyberte události „Odloženo“: Načtěte data z tabulky VBKPF, která obsahuje záhlaví odložených dokladů. Časové razítko vytvoření v této tabulce označuje událost odložení.
- Vyberte události workflow (Odesláno, Schváleno, Zamítnuto): Dotazujte tabulky workflow, například SWW_WI2OBJ (pro propojení objektu účetního zápisu s instancí workflow) a SWWLOGHIST nebo SWWIHEAD (pro získání podrobností a časů konkrétních kroků). Zjistěte ID úloh workflow pro odeslání, schválení a zamítnutí používaná ve vašem systému.
- Vyberte události „Změněno“ a „Opraveno“: Dotazujte tabulky dokumentace změn CDHDR (záhlaví) a CDPOS (položky) pro
OBJECTCLAS = 'BELEG'. U události „Změněno po zaúčtování“ filtrujte změny, jejichž časové razítko je pozdější než datum zaúčtování dokladu. U události „Opraveno“ filtrujte změny odložených nebo zamítnutých dokladů. - Vyberte události „Stornováno“ a „Vyrovnáno“: Storna určete podle dokladů, u nichž je vyplněno pole
STBLG(číslo stornovaného dokladu) v BKPF. Časem události storna je čas vytvoření stornovacího dokladu. Události vyrovnání určete výběrem nejnovějšího data vyrovnání (AUGDT) z tabulky ACDOCA pro položky daného účetního zápisu. - Spojte a seřaďte data: Po výběru dat pro každou aktivitu přidejte výsledky do hlavní interní tabulky. Po dokončení všech výběrů ji seřaďte podle
JournalEntryIdaEventTime, aby byly události každého případu v chronologickém pořadí. - Vytvořte výstupní soubor: Pomocí příkazů
OPEN DATASET,LOOP AT... TRANSFERaCLOSE DATASETzapište obsah seřazené konečné interní tabulky do zadané cesty na aplikačním serveru SAP. Soubor musí být ve formátu CSV a obsahovat řádek záhlaví. - Naplánujte spouštění: Pro pravidelnou extrakci vytvořte pomocí transakčního kódu
SM36úlohu na pozadí, která bude programZ_PM_JE_EXTRACTspouštět podle plánu, například týdně nebo měsíčně. Tím se export dat automatizuje.
Konfigurace
- Období: Výběrová obrazovka musí obsahovat povinné období pro datum vytvoření účetního zápisu (
CPUDT). Doporučujeme extrahovat data po zvládnutelných částech, například po 3 až 6 měsících, aby byl zachován dobrý výkon. - Kód společnosti (
BUKRS): Tento filtr omezuje extrakci na konkrétní právní subjekty relevantní pro analýzu pomocí process mining. Nedoporučujeme extrahovat data pro všechny kódy společností najednou. - Typ dokladu (
BLART): Tento volitelný filtr můžete použít k výběru konkrétních typů účetních zápisů, například „SA“ pro účtování na hlavní knihu nebo „KR“ pro faktury dodavatelů. Pomůže snížit objem dat a zvýšit relevanci datové sady. - Cesta k souboru: Program potřebuje logickou cestu na aplikačním serveru SAP, kam zapíše výstupní soubor. Ověřte, že je cesta platná a uživatel systému SAP má potřebná oprávnění k zápisu do daného adresáře. Adresáře serveru můžete spravovat a zobrazit pomocí transakce
AL11. - ID úloh workflow: Logiku extrakce událostí workflow (Odesláno, Schváleno, Zamítnuto) je nutné nakonfigurovat podle konkrétních ID úloh používaných ve workflow schvalování účetních zápisů vaší organizace. Tato ID bývají vlastní a musí je zjistit konzultant nebo vývojář workflow.
- Předpoklady: Uživatel nebo systémový účet spouštějící program potřebuje vývojářská oprávnění k vytváření a spouštění programů ABAP (
S_DEVELOP) a rozsáhlý přístup pro čtení finančních tabulek (BKPF, ACDOCA), tabulek protokolu změn (CDHDR, CDPOS) a tabulek workflow (SWW*).
Ukázkový dotaz abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Chcete začít?
Pomocí této šablony připravíte data a získáte důležité poznatky o procesu od záznamu po výkaznictví: účtování zápisů. Začněte zlepšovat svůj proces ještě dnes.
Zefektivněte účtování zápisů v procesu od záznamu po výkaznictví
Zlepšete proces a zkraťte dobu účtování zápisů v procesu od záznamu po výkaznictví o 30 %.
Platební kartu nepotřebujete. Nastavení zabere jen několik minut.