Adatsablon a Record to Report naplókönyvelési folyamatához
Adatsablon a Record to Report naplókönyvelési folyamatához
- Javasolt attribútumok
- Követendő tevékenységek
- Gyakorlati útmutató az adatok kinyeréséhez
A Record to Report naplókönyvelési folyamat attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | Az az időbélyeg, amely megadja, mikor történt egy adott tevékenység a naplóbejegyzés esetében. | ||
| Leírás Az esemény időpontja az a pontos dátum és idő, amikor egy üzleti tevékenységet végrehajtottak és rögzítettek a rendszerben. Egy eset minden tevékenységéhez saját időbélyeg tartozik, így az események időrendi sorrendbe rendezhetők. Ez az attribútum minden időalapú folyamatelemzéshez nélkülözhetetlen. Segítségével számíthatók ki a ciklusidők, a tevékenységek közötti időtartamok és a várakozási idők, valamint megérthető a munka időbeli eloszlása. A megbízható folyamatmodell és az olyan teljesítménymutatók, mint a jóváhagyási ciklusidő, pontos időbélyegekre épülnek. Miért fontos? Megadja az események időrendi sorrendjét, ami nélkülözhetetlen az időtartam-alapú mutatók kiszámításához és a folyamat időbeli menetének megértéséhez. Hol szerezhető be? A módosítási bizonylatok naplóiból (CDHDR-UDATE, CDHDR-UTIME), a munkafolyamat-naplókból vagy az olyan táblák létrehozási és rögzítési időbélyegeiből származik, mint a BKPF (CPUDT, CPUTM). Példák 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Naplóbejegyzés-azonosító JournalEntryId | A pénzügyi naplóbejegyzés egyedi azonosítója, amely a folyamat elsődleges esetazonosítójaként szolgál. | ||
| Leírás Az SAP S/4HANA rendszerben minden számviteli bizonylat létrehozásakor egyedi naplóbejegyzés-azonosítót kap. Ezzel az azonosítóval követhető nyomon a naplóbejegyzés teljes életútja a kezdeti létrehozástól vagy függőben tartástól a jóváhagyási munkafolyamatokon át a végleges könyvelésig, illetve az esetleges sztornózásig vagy kiegyenlítésig. A process mining elemzésben ez az azonosító kapcsolja össze az összes kapcsolódó tevékenységet egyetlen esetté. Ha az elemzők a közös naplóbejegyzés-azonosító alapján csoportosítják az eseményeket, rekonstruálhatják a teljes folyamat menetét, mérhetik a ciklusidőket, és feltárhatják az egyes pénzügyi tranzakciók eltéréseit vagy szűk keresztmetszeteit. Ez az alapja a teljes folyamatnézet felépítésének. Miért fontos? Ez az azonosító kapcsolja össze a folyamat összes kapcsolódó lépését, így elemezhetővé válik minden naplóbejegyzés teljes útja. Hol szerezhető be? Ez összetett kulcs, amely jellemzően a vállalatkód (BKPF-BUKRS), a bizonylatszám (BKPF-BELNR) és az üzleti év (BKPF-GJAHR) összefűzésével jön létre. Példák 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Tevékenység ActivityName | A naplóbejegyzési folyamat egy adott pontján végrehajtott üzleti tevékenység neve. | ||
| Leírás A tevékenység a naplóbejegyzés életútjának egy konkrét lépése vagy eseménye, például „Naplóbejegyzés létrehozva”, „Naplóbejegyzés benyújtva ellenőrzésre” vagy „Naplóbejegyzés könyvelve”. A tevékenységek általában a rendszerben rögzített módosítási naplókból, státuszfrissítésekből vagy tranzakciókódokból származnak. A tevékenységek elemzésével megjeleníthető a folyamat menete, feltárhatók a gyakori útvonalak és azonosíthatók a szabványos eljárástól való eltérések. Ezek alapján számíthatók ki többek között a tevékenységek gyakoriságát, a lépések közötti várakozási időt és a megfelelési arányt mérő mutatók. Miért fontos? Meghatározza a folyamat lépéseit, így megjeleníthetők a folyamattérképek és elemezhetők a munkafolyamatok mintázatai. Hol szerezhető be? Többféle forrásból származhat, például a fejléc- és tételsorokat tartalmazó táblák státuszmezőiből (pl. BKPF-BSTAT), a módosítási bizonylatok naplóiból (CDHDR/CDPOS) és a munkafolyamat-naplókból. Példák Naplóbejegyzés létrehozvaNaplóbejegyzés függőbenNaplóbejegyzés benyújtva ellenőrzésreNaplóbejegyzés jóváhagyvaNaplóbejegyzés könyvelve | |||
| Könyvelés dátuma PostingDate | Az a dátum, amikor a könyvelési tétel bekerül a főkönyvbe, és amely meghatározza a pénzügyi időszakot. | ||
| Leírás A könyvelés dátuma határozza meg, hogy a tranzakció melyik pénzügyi időszakban jelenik meg a kimutatásokban. A számvitelben meghatározó dátum, amely eltérhet a dokumentum létrehozásának vagy rendszerbe rögzítésének dátumától. A process mining során a könyvelés dátuma időszak szerinti csoportosításra használható, például a hónapzárási folyamatok összehasonlítására vagy a teljesítmény alakulásának elemzésére különböző pénzügyi időszakokban. A tétel létrehozása és tényleges könyvelése közötti késedelem mérésére is alkalmas. Miért fontos? Pénzügyi szempontból fontos dátum: segítségével elemezhető a folyamat teljesítménye egy adott számviteli időszakban, például hónap- vagy évzáráskor. Hol szerezhető be? SAP S/4HANA BKPF tábla, BUDAT mező (a bizonylat könyvelési dátuma). Példák 2023-10-312023-11-012024-02-29 | |||
| Könyvelési tétel típusa JournalEntryType | Az üzleti célja szerint sorolja kategóriába a könyvelési tételt, például eszközbeszerzés, szállítói számla vagy főkönyvi tétel alapján. | ||
| Leírás A könyvelési tétel típusa, az SAP szóhasználatában dokumentumtípus, a számviteli bizonylatokat kategorizáló kulcs. Többek között meghatározza a bizonylathoz rendelt számtartományt és azt, hogy milyen számlatípusokra lehet könyvelni. A folyamat könyvelésitétel-típus szerinti elemzése segít megérteni az egyes esetek sajátosságait. Például egy egyszerű időbeli elhatárolás (SA típus) jóváhagyása jóval egyszerűbb lehet, mint egy összetett eszközbeszerzésé (AA típus). Ez a dimenzió a „Megfelelés könyvelésitétel-típusonként” dashboard alapja. Miért fontos? Üzleti háttér szerint kategorizálja a tételeket, így elemezhetők a folyamat eltérései és teljesítménye a különböző pénzügyi tranzakciótípusok esetén. Hol szerezhető be? SAP S/4HANA BKPF tábla, BLART mező (dokumentumtípus). Példák SAKRAA | |||
| Létrehozó felhasználó CreatedByUser | A könyvelési tételt létrehozó személy felhasználói azonosítója. | ||
| Leírás Ez az attribútum tárolja annak a felhasználónak az egyedi azonosítóját, aki az első dokumentum létrehozásával elindította a könyvelési tétel folyamatát. Lehet könyvelő, üzleti felhasználó vagy automatizált tétel esetén rendszerazonosító. A létrehozó szerinti elemzés feltárhatja az egyes felhasználókhoz vagy csapatokhoz kötődő mintákat. Megmutathatja például, ha egyes felhasználóknak képzésre van szükségük a magasabb elutasítási arány miatt, vagy kiemelheti a jól teljesítő munkatársakat. Ez az attribútum elengedhetetlen a „Felhasználói tevékenység és átbocsátás” dashboardhoz. Miért fontos? Az attribútum az egyes tevékenységeket konkrét felhasználókhoz rendeli, így elemezhető a teljesítmény és a munkaterhelés, valamint azonosíthatók a képzési igények. Hol szerezhető be? SAP S/4HANA BKPF tábla, USNAM mező (felhasználónév). Példák ABROWNCJONESBATCH_USER | |||
| Összeg helyi pénznemben AmountInLocalCurrency | A könyvelési tétel teljes értéke a vállalati kód helyi pénznemében. | ||
| Leírás Ez az attribútum a könyvelési tétel pénzügyi értékét mutatja. Általában a bizonylat összes tartozik- vagy követeléstételének abszolút értékéből számítják ki, a vállalati kód helyi pénznemére átváltva. Az összeg szerinti elemzéssel a tranzakciók pénzügyi hatása alapján csoportosítható a folyamat. A nagy értékű tételek például szigorúbb jóváhagyást igényelhetnek, mint a kisebbek. Így a folyamatfejlesztés azokra a tranzakciókra összpontosítható, amelyek a legnagyobb pénzügyi kockázatot jelentik. Miért fontos? Megmutatja a tétel pénzügyi értékét, így elemezhető, hogyan változik a folyamat az érintett összeg függvényében. Hol szerezhető be? A könyvelési tételhez tartozó BSEG tábla DMBTR mezőjének összegeiből számítják ki, majd pozitív értékként adják meg. A tételt a BELNR azonosítja. Példák 1500.75125000.0050.20 | |||
| Vállalati kód CompanyCode | Azt a vállalatot vagy jogi személyt egyedileg azonosító kód, amelynek könyvelésébe a tétel kerül. | ||
| Leírás A vállalati kód az SAP Financials alapvető szervezeti egysége. Egy önálló jogi személyt jelöl, amelyhez külön pénzügyi kimutatások készülnek. Minden könyvelési tétel egy adott vállalati kódhoz tartozik. Ez az attribútum lehetővé teszi a folyamat teljesítményének összehasonlítását a szervezet különböző részei között. Az elemzők egy adott jogi személyre szűrhetik a folyamat nézetét, összevethetik az elutasítási arányokat a vállalati kódok között, vagy feltárhatják a régiónként eltérő folyamatokat. Miért fontos? Lehetővé teszi a könyvelési tételek folyamatának szűrését és összehasonlítását a szervezet különböző jogi személyei vagy üzleti egységei szerint. Hol szerezhető be? SAP S/4HANA BKPF tábla, BUKRS mező (vállalati kód). Példák 10001710US01 | |||
| Befejezés időpontja EndTime | Az időbélyeg azt mutatja, mikor fejeződött be a tevékenység. | ||
| Leírás A befejezési időpont jelöli a tevékenység végét. Sok eseménynaplóban egy tevékenység kezdési és befejezési időpontja megegyezik, mert az esemény azonnal lezajlik. Ha azonban a tevékenységnek mérhető időtartama van, például egy felhasználó aktívan átnéz egy dokumentumot, ez az attribútum rögzítheti annak hosszát. A külön befejezési időponttal pontosabban számítható ki a tevékenység feldolgozási ideje és a várakozási idő. Így elkülöníthető, mennyi ideig dolgoztak ténylegesen egy feladaton, és mennyi ideig állt az egy sorban. Miért fontos? Lehetővé teszi a tevékenységek feldolgozási idejének pontos kiszámítását, az aktív munkavégzés és a tétlen várakozás elkülönítésével. Hol szerezhető be? Az azonnali eseményeknél általában megegyezik a StartTime értékével. Időtartammal rendelkező tevékenységeknél workflow-naplókból származhat, vagy a következő események alapján számítható ki. Példák 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Dokumentum állapota DocumentStatus | A könyvelési tétel aktuális feldolgozási állapota, például előzetesen rögzített, könyvelt vagy kiegyenlített. | ||
| Leírás A dokumentum állapota megmutatja, hol tart a könyvelési tétel az életciklusa során. Az előzetesen rögzített dokumentumot például már elmentették, de még nem könyvelték a főkönyvbe, míg a könyvelt dokumentum végleges. Az állapot elemzésével megérthető a munka menete és azonosíthatók a szűk keresztmetszetek. Ha sok dokumentum hosszú ideig előzetesen rögzített vagy jóváhagyásra váró állapotban marad, az a folyamat hiányosságaira utalhat. Az állapot a folyamattevékenységek meghatározásának is fontos forrása. Miért fontos? Megmutatja, hol tart a könyvelési tétel az életciklusa során, így azonosíthatók a várakozási sorok és a szűk keresztmetszetek. Hol szerezhető be? SAP S/4HANA BKPF tábla, BSTAT mező (dokumentumállapot). Példák VAB | |||
| Forrásrendszer SourceSystem | Megadja, melyik forrásrendszerből nyerték ki a naplóbejegyzési adatokat. | ||
| Leírás Ez az attribútum jelöli, hogy melyik rendszerből származnak a könyvelési tétel adatai. Több ERP-rendszert vagy régi és modern rendszereket párhuzamosan használó vállalatoknál segít megkülönböztetni az adatforrásokat. Az elemzés során összehasonlítható vele a folyamat teljesítménye az egyes rendszerekben, illetve az adatok egy adott forrásra szűrhetők. Az adatirányítás szempontjából is fontos, mert segít megérteni az adatok hátterét. Miért fontos? Megmutatja az adatok eredetét. Ez több rendszer használata esetén elengedhetetlen a folyamatok pontos elemzéséhez és összehasonlításához. Hol szerezhető be? Ez általában az adatkinyerés során hozzáadott, statikus érték, amely az adott SAP S/4HANA-példányt azonosítja, például SID vagy logikai rendszernév alapján. Példák S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Jóváhagyási ciklusidő ApprovalCycleTime | A könyvelési tétel jóváhagyásra küldése és jóváhagyása vagy elutasítása között eltelt idő. | ||
| Leírás Ez a számított mutató kifejezetten a jóváhagyási szakasz időtartamát méri. A „Könyvelési tétel ellenőrzésre beküldve” tevékenység és az azt követő „Könyvelési tétel jóváhagyva” vagy „Könyvelési tétel elutasítva” tevékenység közötti időt számítja ki. Ez a KPI segít azonosítani a jóváhagyási munkafolyamat szűk keresztmetszeteit. A hosszú jóváhagyási ciklusidő jelentősen késleltetheti a teljes folyamatot. A mutató jóváhagyó, vállalati kód vagy könyvelésitétel-típus szerinti elemzése megmutathatja, hol érdemes fejleszteni. Miért fontos? Külön méri a jóváhagyási lépés időtartamát, így könnyebben azonosíthatók és kezelhetők az ellenőrzési és jóváhagyási munkafolyamat szűk keresztmetszetei. Hol szerezhető be? A „Könyvelési tétel ellenőrzésre beküldve” esemény és a „Könyvelési tétel jóváhagyva” vagy „Könyvelési tétel elutasítva” esemény közötti idő különbségeként számítják ki. Példák 1 nap 2 óra4 óra 25 perc5 nap 0 óra | |||
| Jóváhagyó felhasználó ApproverUser | A könyvelési tételt jóváhagyó vagy elutasító személy felhasználói azonosítója. | ||
| Leírás Ez az attribútum azonosítja azt a felhasználót, aki átnézi a beküldött könyvelési tételt, és dönt róla. Többszintű jóváhagyási munkafolyamat esetén egy tételhez több jóváhagyó is tartozhat. Az adat részletes elemzést tesz lehetővé a jóváhagyási folyamatról. Segít felmérni a jóváhagyók munkaterhelését, kiszámítani az egyéni jóváhagyási időket, és azonosítani a jóváhagyási lánc szűk keresztmetszeteit. Közvetlenül támogatja a „Felhasználói tevékenység és átbocsátás” dashboardot. Miért fontos? Azonosítja a jóváhagyásért felelős személyt, így elemezhető a jóváhagyók munkaterhelése és teljesítménye, valamint feltárhatók a szűk keresztmetszetek. Hol szerezhető be? A workflow-naplókból (például SWW_WI2OBJ, SWWLOG) vagy a módosítási bizonylatok tábláiból (CDHDR/CDPOS) származik. A jóváhagyási lépést végrehajtó felhasználó követésével határozható meg. Példák DMILLERFWHITEKCHEN | |||
| Kézi könyvelés IsManualPosting | Logikai jelző, amely megmutatja, hogy a felhasználó kézzel könyvelte-e a tételt. | ||
| Leírás Ez az attribútum azonosítja azokat a könyvelési tételeket, amelyeket felhasználói beavatkozással könyveltek, nem pedig automatikusan, rendszerfeladat vagy interfész segítségével. Az értéket általában a dokumentum könyveléséhez használt tranzakciókódból határozzák meg. A jelzővel kiszámítható a kézi könyvelések arányát mérő KPI, és nyomon követhető a Record to Report folyamat automatizálása. A kézzel könyvelt tételekre szűrve az elemzők azonosíthatják azokat az eseteket, amelyek még emberi beavatkozást igényelnek, és felmérhetik az automatizálás lehetőségét. Miért fontos? Megkülönbözteti a felhasználó által végzett és a rendszer által automatikusan végrehajtott könyveléseket. Ez elengedhetetlen az automatizálás mértékének méréséhez és az új lehetőségek feltárásához. Hol szerezhető be? Ez a számított attribútum a TransactionCode értékéből származik. Az előre meghatározott kézi tranzakciókódok listája, például „FB01” és „F-02”, alapján állítja a jelzőt „true” értékre. Példák truefalse | |||
| Pénzügyi év FiscalYear | Az a pénzügyi év, amelyhez a könyvelési tétel tartozik. | ||
| Leírás A pénzügyi év a könyvelési tétel egyedi kulcsának része a vállalati kóddal és a bizonylatszámmal együtt. Azt a pénzügyi évet jelöli, amelyben a dokumentum releváns. Az elemzésben a pénzügyi év hosszú távú trendek vizsgálatára és az esetazonosító egyediségének biztosítására használható. A folyamatmutatók pénzügyi évek közötti összehasonlítása megmutathatja, hogyan javult vagy romlott a teljesítmény az idő múlásával. Miért fontos? Segít egyedileg azonosítani a dokumentumokat, és lehetővé teszi a folyamat teljesítményének évek közötti összehasonlítását. Hol szerezhető be? SAP S/4HANA BKPF tábla, GJAHR mező (pénzügyi év). Példák 202320242022 | |||
| Sztornó oka ReversalReason | Azt jelölő kód, hogy miért sztornózták a már könyvelt könyvelési tételt. | ||
| Leírás Ha egy könyvelt könyvelési tétel hibás, nem lehet törölni, hanem új bizonylattal kell sztornózni. A sztornó oka kód jelzi, miért volt erre szükség, például hibás könyvelési dátum vagy összeg miatt. A sztornóokok elemzése segít feltárni a Record to Report folyamat hibáinak kiváltó okait. Ha egy adott ok gyakran ismétlődik, az rendszerszintű problémára, például hiányos képzésre vagy nem megfelelő kontrollokra utalhat. Ezek kezelése javíthatja az elsőre helyes feldolgozás arányát. Miért fontos? Segít feltárni a sztornóhoz vezető hibák kiváltó okait, és olyan információt ad, amellyel csökkenthető az utómunka és javítható a folyamat minősége. Hol szerezhető be? SAP S/4HANA BKPF tábla, STGRD mező (sztornó oka). Példák 010205 | |||
| Történt utómunka IsRework | Logikai jelző, amely megmutatja, hogy kellett-e utómunkát végezni a könyvelési tételen, például elutasítás utáni javítás miatt. | ||
| Leírás Ez a számított attribútum megjelöli azokat a könyvelési tételeket, amelyek eltértek az ideális folyamattól. Értéke általában akkor igaz, ha az eset során olyan tevékenység történt, mint a „Könyvelési tétel elutasítva” vagy a „Könyvelési tétel javítva”. A jelző egyszerűbbé teszi a folyamat hatékonyságának elemzését. Segítségével gyorsan kiszámítható az utómunka arányát mérő KPI, és közvetlenül összehasonlítható az utómunkával járó és az attól mentes esetek átfutási ideje és költsége. Az utómunka kiváltó okainak feltárása sok folyamatfejlesztési kezdeményezés egyik fő célja. Miért fontos? Megjelöli a javítást vagy ismételt feldolgozási kört igénylő eseteket, így könnyen mérhető és elemezhető a folyamat hiányosságainak oka. Hol szerezhető be? Ez a számított attribútum az eset tevékenységeinek sorrendjéből származik. Értéke „true”, ha szerepel benne például a „Könyvelési tétel elutasítva” tevékenység. Példák truefalse | |||
| Tranzakciókód TransactionCode | A könyvelési tétel létrehozásához vagy módosításához használt SAP-tranzakciókód. | ||
| Leírás A tranzakciókód (T-Code) az SAP egy adott funkcióját vagy programját azonosító parancsikon. A könyvelési tételeknél a különböző T-Code-ok jelzik, hogyan jött létre a tétel. Az FB01 például kézi főkönyvi könyvelést, az FV50 előzetes rögzítést, egy automatizált kód pedig rendszer által létrehozott tételt jelezhet. Ez az attribútum jól mutatja, hogy a tevékenységet felhasználó végezte-e, vagy a rendszer hajtotta végre automatikusan. Alapul szolgál a kézi könyvelések arányát mérő KPI kiszámításához, és segít feltárni az automatizálási lehetőségeket. Miért fontos? Jelzi, hogyan dolgozták fel a tételt, például kézzel vagy automatikusan. Ez fontos az automatizálás elemzéséhez és a folyamat eltéréseinek megértéséhez. Hol szerezhető be? SAP S/4HANA BKPF tábla, TCODE mező (tranzakciókód). Példák FB01FV50F-02 | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg azt mutatja, mikor frissítették utoljára a rekord adatait a forrásrendszerből. | ||
| Leírás Ez az attribútum rögzíti a forrásrendszerből végzett legutóbbi adatkinyerés vagy frissítés dátumát és időpontját. Így látható, mennyire frissek az elemzett adatok. Az utolsó frissítés időpontja segít megítélni, mennyire aktuális a folyamatelemzés. A felhasználók ennek ismeretében helyesen értelmezhetik a dashboardokat és a KPI-kat: láthatják, hogy közel valós idejű adatokat vagy egy korábbi időszak pillanatképét nézik. Miért fontos? Jelzi az adatok frissességét, így a felhasználók tudják, mennyire aktuális a folyamatelemzés. Hol szerezhető be? Ez egy metaadat-attribútum, amelyet általában az adatbetöltési folyamat során hoznak létre, és minden rekordhoz hozzárendelnek. Példák 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
A Record to Report naplókönyvelési folyamat tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Naplóbejegyzés benyújtva ellenőrzésre | A naplóbejegyzés készítője hivatalosan benyújtja a bizonylatot az ellenőrzési és jóváhagyási munkafolyamatba. Ezzel az adatrögzítés átadódik a hivatalos kontrollfolyamatnak, és megkezdődik a jóváhagyási ciklus. | ||
| Miért fontos? Ez jelzi a jóváhagyási ciklus kezdetét. Ha ettől az időponttól a végleges jóváhagyásig vagy elutasításig mérjük az időt, külön vizsgálhatók az ellenőrzési és jóváhagyási szakaszok szűk keresztmetszetei. Hol szerezhető be? Az esemény gyakran az üzleti objektumhoz kapcsolódó munkafolyamat-naplókból (SWW_WIHEAD, SWWLOG) rögzíthető. A bizonylat fejlécének egy egyéni mezőjében (BKPF) bekövetkező státuszváltozásból is megállapítható. Rögzítés A munkafolyamat-elem létrehozásának időbélyege, vagy egy státuszmező „Submitted” vagy „In Review” értékre váltása. Eseménytípus inferred | |||
| Naplóbejegyzés jóváhagyva | A naplóbejegyzést egy arra jogosult vezető véglegesen jóváhagyja, megerősítve annak érvényességét és pontosságát. Ez az utolsó ellenőrzési pont, mielőtt a bizonylat a főkönyvbe könyvelhető. | ||
| Miért fontos? Ez fontos mérföldkő, amely lezárja a jóváhagyási ciklust. Az ehhez a lépéshez szükséges idő jelentősen befolyásolja a teljes folyamat időtartamát, és jól mutatja a jóváhagyás hatékonyságát. Hol szerezhető be? Az esemény a munkafolyamat-napló végső jóváhagyási lépéséből vagy a bizonylat státuszváltozásából állapítható meg. A jóváhagyó felhasználói azonosítója és az időbélyeg a munkafolyamat adataiból vagy a módosítási naplókból nyerhető ki. Rögzítés Keresse meg a végső jóváhagyási lépés időbélyegét a munkafolyamat-naplókban, vagy a „Approved” státuszra váltást a módosítási bizonylatokban. Eseménytípus inferred | |||
| Naplóbejegyzés kiegyenlítve | A naplóbejegyzés egyik nyitott tételsorát egy másik könyvelés kiegyenlíti, például egy fizetés egy számlát. Ezzel a tevékenységgel az adott tételsorok egyeztetése és lezárása történik meg. | ||
| Miért fontos? Sok naplóbejegyzésnél ez jelenti a végső egyeztetési lépést, különösen a függő számlákhoz vagy nyitott tételek kezelésére szolgáló számlákhoz kapcsolódó esetekben. A könyvelés és a kiegyenlítés közötti idő elemzésével mérhető az egyeztetés hatékonysága. Hol szerezhető be? Az esemény a tételsorokat tartalmazó táblából (BSEG vagy az ACDOCA-nézet) állapítható meg. Kiegyenlítéskor az adott tételsor kiegyenlítési dátuma (AUGDT) és kiegyenlítési bizonylata (AUGBL) mezője kitöltődik. Rögzítés Az esemény időbélyegéhez használja a tételsor kiegyenlítési dátumát (BSEG-AUGDT). Eseménytípus inferred | |||
| Naplóbejegyzés könyvelve | A naplóbejegyzést hivatalosan rögzítik a főkönyvben, így az hatással van a vállalat pénzügyi kimutatásaira. Ettől a ponttól kezdve a bizonylat végleges pénzügyi nyilvántartásnak számít. | ||
| Miért fontos? Ez a folyamat elsődleges sikeres mérföldköve, amely a fő feldolgozási ciklus végét jelzi. A könyvelt bejegyzések áteresztőképességének és a könyvelésig eltelt időnek az elemzése a process mining alapvető mérőszámai közé tartozik. Hol szerezhető be? Ez a BKPF táblában szereplő könyvelési dátummal (BUDAT) rögzített, egyértelmű esemény. A könyvelt bizonylat bizonylatstátusza (BSTAT) üres, így megkülönböztethető a függőben lévő („V”) vagy visszatartott („D”) bizonylatoktól. Rögzítés Az esemény időbélyegéhez használja a könyvelési dátumot (BKPF-BUDAT) és a rögzítés dátumát (BKPF-CPUDT). Az üres BKPF-BSTAT mező jelzi, hogy a bizonylatot könyvelték. Eseménytípus explicit | |||
| Naplóbejegyzés létrehozva | Ez a tevékenység jelzi a naplóbejegyzési bizonylat első létrehozását a rendszerben. A rekord létrejön a fejlécadatokat tartalmazó BKPF táblában, de még nem könyvelték a főkönyvbe. Ezzel kezdődik a naplóbejegyzés életútja. | ||
| Miért fontos? Ez a folyamat elsődleges kezdő eseménye. Az eseménytől a könyvelésig eltelt idő elemzése elengedhetetlen a teljes ciklusidő méréséhez és a kezdeti adatrögzítési késések feltárásához. Hol szerezhető be? Az esemény a BKPF SAP-táblából rögzíthető a létrehozás dátuma (CPUDT) és időpontja (CPUTM) alapján, az adott bizonylatszámhoz (BELNR) kapcsolva. Rögzítés Az esemény időbélyegéhez használja a BKPF-CPUDT és a BKPF-CPUTM mezőt. Eseménytípus explicit | |||
| Naplóbejegyzés sztornózva | Egy korábban könyvelt naplóbejegyzést ellentétes előjelű tételeket tartalmazó új bizonylattal sztornóznak. Ezzel a kifejezetten rögzített, auditálható tranzakcióval a könyvelt bizonylat hibáit javítják. | ||
| Miért fontos? A sztornó arra utal, hogy hiba történt egy könyvelt bizonylatban. A magas sztornózási arány a jóváhagyási folyamat vagy az adatrögzítés minőségének problémáit jelezheti. A sztornók nyomon követése segít javítani az elsőre helyes feldolgozás arányát. Hol szerezhető be? A sztornó egyértelműen rögzített esemény. Az új, sztornózó bizonylat fejléce (BKPF) az eredeti bizonylatra hivatkozik a sztornózott bizonylat számát tartalmazó mezőben (STBLG). Az esemény időpontja az új bizonylat könyvelési dátuma. Rögzítés Keresse meg azokat a bizonylatokat, amelyeknél a BKPF-STBLG mező ki van töltve. Az esemény időbélyege a sztornózó bizonylat könyvelési dátuma. Eseménytípus explicit | |||
| Alátámasztó dokumentáció csatolva | A felhasználó egy vagy több alátámasztó dokumentumot, például számlát vagy táblázatot csatol a naplóbejegyzéshez. Ezek a dokumentumok bizonyítékot és háttér-információt nyújtanak a pénzügyi tranzakció ellenőrzéséhez és auditjához. | ||
| Miért fontos? A megfelelés és a hatékony jóváhagyás érdekében fontos, hogy a dokumentáció már az ellenőrzés előtt rendelkezésre álljon. Ezzel a tevékenységgel mérhető, mennyire tartják be a dokumentációs előírásokat, és hogyan hat ez a jóváhagyási ciklus idejére. Hol szerezhető be? Ez az esemény jellemzően a Generic Object Services (GOS) szolgáltatáson keresztül csatolt dokumentumok létrehozási időbélyegéből állapítható meg. Az SRGBTBREL tábla kapcsolja össze az üzleti objektumot, például a BKPF-bizonylatot a melléklettel. Rögzítés Keresse meg a BKPF-objektumhoz kapcsolódó hivatkozásokat a GOS mellékleteket tároló tábláiban, például az SRGBTBREL táblában, és használja a melléklet létrehozási időbélyegét. Eseménytípus inferred | |||
| Kézi könyvelés azonosítva | A naplóbejegyzést kézi tranzakciókóddal könyvelték, nem automatizált interfészen vagy kötegelt feladaton keresztül. Ez nem időbeli esemény, hanem a könyvelési tevékenység besorolása. | ||
| Miért fontos? A kézi könyvelések azonosítása fontos az automatizálási kezdeményezésekhez. A kézi könyvelések magas aránya arra utalhat, hogy alrendszerek összekapcsolásával vagy automatizált könyvelőprogramokkal egyszerűsíthető a folyamat. Hol szerezhető be? A besorolás a bizonylat fejlécét tartalmazó BKPF tábla tranzakciókód (TCODE) mezőjének elemzésével történik. A bejegyzést az ismert kézi tranzakciókódok listája alapján sorolja be, például FB01, F-02 vagy FB50. Rögzítés A könyvelés időpontjában sorolja be az eseményt a BKPF-TCODE mező alapján, egy előre meghatározott kézi tranzakciókód-listával összevetve. Eseménytípus calculated | |||
| Könyvelt naplóbejegyzés módosítva | A felhasználó a naplóbejegyzés korlátozott számú mezőjét módosítja, miután azt már lekönyvelték a főkönyvbe. Bár a legtöbb pénzügyi adat könyvelés után nem módosítható, egyes mezők, például a szöveg vagy a hozzárendelések változhatnak. | ||
| Miért fontos? Ez a tevékenység fontos megfelelési jelzés. A könyvelés utáni módosítások a nyilvántartás megváltoztatására tett kísérletre utalhatnak, ezért a csalás megelőzése és az adatok integritásának biztosítása érdekében szorosan nyomon kell követni őket. Hol szerezhető be? Ez megbízhatóan megállapítható a módosítási bizonylatok tábláiból (CDHDR és CDPOS). Ha a CDHDR a bizonylatszámhoz a könyvelési dátum utáni módosítási dátumot tartalmaz, az könyvelés utáni módosítást jelez. Rögzítés Keresse meg a CDHDR azon rekordjait, amelyek módosítási időbélyege (UDATE/UTIME) későbbi, mint a bizonylat könyvelési dátuma (BKPF-BUDAT). Eseménytípus inferred | |||
| Naplóbejegyzés elutasítva | Az ellenőrző vagy jóváhagyó elutasítja a naplóbejegyzést, ezért az nem könyvelhető. A bizonylatot általában visszaküldik a készítőnek javításra, így újramunkát igénylő folyamat indul. | ||
| Miért fontos? Az elutasítások nyomon követése segít megérteni a folyamat minőségét és feltárni a gyakori hibákat. A magas elutasítási arány pontatlan adatokra, az előírások hiányos ismeretére vagy elégtelen alátámasztó dokumentációra utalhat. Hol szerezhető be? Az esemény a munkafolyamat-naplóban vagy a naplóbejegyzés egyéni státuszmezőjében rögzített státuszváltozásból állapítható meg. A megfelelő státuszmező változásait tartalmazó módosítási naplók (CDHDR/CDPOS) megadják az időbélyeget. Rögzítés Keresse meg a „Rejected” státuszra váltást a módosítási bizonylatokban (CDHDR/CDPOS) vagy a munkafolyamat-naplókban. Eseménytípus inferred | |||
| Naplóbejegyzés függőben | A felhasználó könyvelés nélkül menti el a hiányos naplóbejegyzést, hogy később kiegészíthesse vagy ellenőrizhesse. Ez a művelet létrehozza a bizonylat fejlécét, és „függőben” állapotba helyezi a bizonylatot, amely így még nincs könyvelve. | ||
| Miért fontos? A függőben tartás gyakori lépés a benyújtás előtt. A függőben töltött idő nyomon követésével feltárhatók az adatok kiegészítésének és előkészítésének késedelmei, még a hivatalos ellenőrzési és jóváhagyási folyamat megkezdése előtt. Hol szerezhető be? A BKPF táblában a függőben lévő bizonylatot a bizonylatstátusz mező (BSTAT) „V” értéke jelzi. Az esemény időbélyege a létrehozás dátuma (CPUDT). Rögzítés A létrehozás időpontjában szűrjön azokra a bizonylatokra, amelyeknél BKPF-BSTAT = 'V'. Eseménytípus explicit | |||
| Naplóbejegyzés javítva | A felhasználó módosítja a naplóbejegyzést, miután azt elutasították vagy javításra visszaküldték. Ez jelzi az ellenőrzés során feltárt problémák megoldásához szükséges újramunkát, mielőtt a bejegyzést ismét benyújtanák. | ||
| Miért fontos? Ezzel a tevékenységgel mérhető az újramunkát igénylő körök száma. A javítások gyakoriságának és időtartamának elemzése feltárja a hatékonysági problémák forrásait, és rámutat a képzés, illetve a folyamat pontosításának lehetőségeire. Hol szerezhető be? Ez a BKPF tábla „Last Changed On” dátumának (AEDAT) nyomon követésével állapítható meg, ha a bizonylat korábban „Rejected” állapotban volt. A módosítási bizonylatok részletesebben megmutatják, mi változott. Rögzítés Az elutasítás után végzett módosítások időbélyegéhez használja a módosítási bizonylat fejlécének időpontját (CDHDR-UDATE). Eseménytípus inferred | |||
Adatkinyerési útmutatók
Lépések
- Előfeltételek és hozzáférés: Gondoskodjon róla, hogy rendelkezzen olyan felhasználói fiókkal, amelynek jogosultságai lehetővé teszik az SAP S/4HANA adatbázisának lekérdezését vagy ABAP-jelentések futtatását. Olvasási hozzáférésre lesz szüksége az I_JournalEntry és I_JournalEntryItem CDS-nézetekhez, valamint a CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ és SWWLOGHIST táblákhoz. A hozzáférést általában olyan adatbázis-kliensen keresztül biztosítják, mint az SAP HANA Studio vagy a DBeaver, illetve az Eclipse-hez készült SAP ABAP Development Tools (ADT) használatával.
- Rendszerspecifikus beállítások azonosítása: A lekérdezés futtatása előtt azonosítsa a naplóbejegyzések jóváhagyási munkafolyamatában használt feladatkódokat. Kérje az SAP-munkafolyamat rendszergazdájának segítségét a beküldéshez, elutasításhoz és jóváhagyáshoz tartozó feladatazonosítók (például TS12345678) megkereséséhez. Ezekre az azonosítókra szükség lesz a végleges lekérdezés helyőrzőinek kitöltéséhez.
- Az SQL-lekérdezés előkészítése: Másolja be a
queryszakaszban található teljes SQL-lekérdezést a választott SQL-kliensbe vagy fejlesztőeszközbe. - A lekérdezési paraméterek beállítása: Keresse meg a lekérdezésben a helyőrzőket, és cserélje le őket a megfelelő értékekre. Adja meg a
[YourCompanyCode],[StartDate]és[EndDate]paramétereket. A munkafolyamat feladatazonosítóinak helyőrzőit ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) is cserélje le az előző lépésben azonosított értékekre. - Az adatkinyerő lekérdezés futtatása: Futtassa a módosított SQL-lekérdezést az SAP S/4HANA adatbázisán. A lekérdezés a dátumtartománytól és az adatmennyiségtől függően sokáig futhat. Érdemes csúcsidőn kívül futtatni.
- Az első eredmények ellenőrzése: A lekérdezés lefutása után ellenőrizze az eredmény első néhány sorát. Győződjön meg róla, hogy minden oszlop, például a JournalEntryId, az ActivityName és az EventTime a várt módon van kitöltve. Az eredményhalmazban a naplóbejegyzés életciklusának minden egyes különálló üzleti eseményéhez egy sornak kell tartoznia.
- Adatok exportálása CSV-fájlba: Exportálja az SQL-eszközből a teljes eredményhalmazt egyetlen CSV-fájlba. A speciális karakterek kezeléséhez UTF-8 kódolást használjon.
- Feltöltés előkészítése: Mielőtt feltöltené a fájlt egy process mining eszközbe, ellenőrizze, hogy a CSV-fájl tartalmazza-e a szükséges fejléceket. Az adatok már eseménynaplóként vannak rendezve, ezért további átalakításra vagy kimutatás készítésére nincs szükség.
Konfiguráció
- Core Data Services (CDS) nézetek: Az adatkinyerés elsősorban az
I_JournalEntrynézetet használja a fejlécadatokhoz, azI_JournalEntryItemnézetet pedig a tétel- és összegadatokhoz. Ezek a nézetek egyszerűsített, szemantikailag gazdag hozzáférést biztosítanak az univerzális naplóhoz (ACDOCA). - Kapcsolódó táblák: A teljes folyamat áttekintéséhez a lekérdezés több szabványos SAP-táblát is összekapcsol:
- A
CDHDRés aCDPOSa dokumentumok módosításainak követésére szolgál. - Az
SRGBRELés aSOODsegítségével azonosítható, mikor kapcsoltak mellékleteket a Generic Object Services (GOS) használatával. - A
SWW_WI2OBJés aSWWLOGHISTa jóváhagyási munkafolyamat fontos eseményeinek kinyerésére szolgál.
- A
- Dátumtartomány szerinti szűrés: A teljesítmény megőrzése érdekében szűrje az adatokat meghatározott dátumtartományra. Használja az
I_JournalEntry.CreationDateTimemezőt aWHEREfeltételben. Első elemzéshez 3–6 hónapos időszak javasolt. - Szervezeti szűrés: Mindig szűrjön a
CompanyCodemezőre, hogy csak a releváns jogi személyek adatai kerüljenek be. Nagy rendszerben az összes vállalatkód egyidejű lekérdezése rendkívül hosszú futási időt eredményezhet. - Munkafolyamat-feladatazonosítók: A lekérdezés helyőrzőket tartalmaz a munkafolyamat feladatazonosítóihoz (például
[Workflow Approved Task ID]). Ezek minden SAP-telepítésnél egyediek, ezért azonosítsa és állítsa be őket helyesen, hogy a munkafolyamat tevékenységei kinyerhetők legyenek. Nélkülük a beküldési, jóváhagyási és elutasítási események nem kerülnek be az eredménybe. - Előfeltételek: A lekérdezést futtató felhasználónak széles körű olvasási jogosultságra van szüksége a pénzügyi, rendszer- és munkafolyamat-táblákhoz. Ezek a jogosultságok nem alapértelmezettek, külön kell hozzárendelni őket.
Példa-lekérdezés 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; Lépések
- Ellenőrizze, hogy engedélyezett-e a közvetlen SQL-hozzáférés az SAP HANA-adatbázishoz, és hogy az adatkinyerést végző felhasználó rendelkezik-e olvasási jogosultsággal a BKPF és ACDOCA táblákhoz, valamint a rendszerben szükséges workflow-, melléklet-, módosítási előzmény-, kiegyenlítési vagy sztornózási adatforrásokhoz. A közvetlen adatbázis-hozzáférés általában az SAP HANA Database Explorer, az SAP HANA Studio vagy egy jóváhagyott SQL-kliens használatával történik. Ne futtasson adatkinyerési lekérdezést SAP-alkalmazás tranzakciójában, kivéve, ha a rendszer kifejezetten támogatja ezt a hozzáférést.
- Ellenőrizze a BKPF és ACDOCA fizikai sémáját, beleértve a kliens, a vállalatkód, a pénzügyi év, a dokumentumszám, a dokumentumtípus, a könyvelési dátum, a létrehozás dátuma és időpontja, a felhasználó, a helyi pénznemben megadott összeg, valamint az esetleges sztornózási vagy kiegyenlítési mezőket. Az SAP S/4HANA-rendszerek sémája és mezőinek elérhetősége eltérhet, ezért a lekérdezés szögletes zárójelben megadott helyőrzőit cserélje le a saját rendszerében ellenőrzött mezőkre.
- Azonosítsa a workflow- és mellékletesemények hiteles adatforrásait. A BKPF és az ACDOCA könyvelési dokumentum- és tételsoradatokat tartalmaz, de önmagukban nem feltétlenül teszik megbízhatóan láthatóvá az összes parkoltatási, beküldési, elutasítási, javítási, jóváhagyási vagy mellékleteseményt. Cserélje le a workflow- és mellékletforrások helyőrzőit a rendszerében jóváhagyott nézetekre vagy táblákra. Ha valamelyik adatforrás nem érhető el, ne hozzon létre eseményeket feltételezés alapján. Állítsa be a megfelelő adatforrást, vagy dokumentált jóváhagyással hagyja ki az adott tevékenységet.
- Állítsa be a szükséges dátumtartomány, vállalatkódok, dokumentumtípusok és kliens adatkinyerési paramétereit. Az első ellenőrzéshez 3–6 hónapos időszak javasolt. A megállapodott folyamati hatókörnek megfelelően a működési eseményeknél az esemény időbélyegét, a könyvelési eseményeknél pedig a könyvelési dátumot használja.
- Futtassa a teljes SQL-lekérdezést a jóváhagyott HANA SQL-kliensben. A lekérdezés minden kifejezetten kinyert tevékenységhez egy eseménysort hoz létre. A könyvelési eseményekhez a BKPF és az ACDOCA, a workflow-, melléklet-, módosítási, kiegyenlítési és sztornózási eseményekhez pedig a beállított forrásnézetek adatait használja. Nem következtet tevékenységekre pusztán abból, hogy létezik egy dokumentum.
- Ellenőrizze a kimeneti sémát. A JournalEntryId az esetazonosító, az ActivityName a tevékenység neve, az EventTime pedig az esemény időbélyege. Az ajánlott üzleti attribútumok is megjelennek, ha rendelkezésre állnak. Ellenőrizze, hogy az EventTime időbélyeg-e, és minden sorban szerepel-e a JournalEntryId és az ActivityName.
- Egyeztesse a könyvelési adatállományt úgy, hogy összeveti a különböző JournalEntryId értékeket a kiválasztott kliens, vállalatkódok, pénzügyi évek és dátumtartomány BKPF-adataival. A workflow- és mellékletadatokat külön egyeztesse, mert megőrzési és időbélyeg-szabályaik eltérhetnek a könyvelési adatokétól.
- Ellenőrizze az események sorrendjét és a duplikátumok kezelését. Az ACDOCA több tételsora nem hozhat létre duplikált könyvelési eseményeket, kivéve, ha a folyamatterv kifejezetten tételszintű eseményeket kíván meg. A lekérdezés összesítési logikájával hozzon létre egy könyvelési eseményt naplókönyvelésenként és eseménytípusonként, miközben lehetőség szerint őrizze meg a beállított forrásesemény-azonosítókat.
- Exportálja az eredményt UTF-8 kódolású CSV-fájlba vagy más, a ProcessMind által támogatott táblázatos formátumba. Őrizze meg pontosan a JournalEntryId, ActivityName és EventTime oszlopneveket. Rendezze a fájlt JournalEntryId, majd EventTime szerint, a további attribútumokat pedig tartsa meg oszlopként. Töltse fel a fájlt a ProcessMindbe, és állítsa be a JournalEntryId mezőt esetazonosítóként, az ActivityName mezőt tevékenységként, az EventTime mezőt pedig esemény-időbélyegként.
Konfiguráció
- Dátumtartomány: Kezdje 3–6 hónappal. Teljesítményteszthez használjon rövidebb időszakot, és csak a sorszámok és az események lefedettségének ellenőrzése után bővítse.
- Kliens és vállalati hatókör: Állítsa be a [Client parameter] értékét, és korlátozza a CompanyCode mezőt az érintett jogi személyekre. Többklieneses rendszerben ne hagyja ki a kliensre vonatkozó feltételt.
- Könyvelési hatókör: Állítsa be a [Document type filter] értékét, és szükség esetén szűrjön pénzügyi évre és könyvelési dátumra is. Csak akkor vegye fel a könyvelt és nem könyvelt dokumentumokat is, ha a kiválasztott adatforrás mindkettőt megbízhatóan tartalmazza.
- Workflow-hatókör: Állítsa be a [Workflow event source] értékét, valamint a beküldött, elutasított, javított és jóváhagyott tevékenységek eseménytípus-hozzárendeléseit. Ellenőrizze, hogy az időbélyegek a workflow-művelet létrehozását, végrehajtását vagy befejezését jelölik-e.
- Mellékletek hatóköre: Állítsa be a [Attachment event source] értékét és a mellékletet a naplókönyveléshez kapcsoló mezőt. Ellenőrizze, hogy a forrás a melléklet létrehozását, cseréjét vagy törlését rögzíti-e.
- Módosítások hatóköre: A könyvelés utáni módosításokhoz állítsa be a [Change history source] értékét. Ellenőrizze, hogy a forrás azonosítja-e a naplókönyvelést, és megbízható módosítási időbélyeget ad-e.
- Kiegyenlítések hatóköre: Állítsa be a [Clearing source] értékét, valamint a kiegyenlített könyvelési dokumentum és a kiegyenlítő dokumentum közötti kapcsolatot. Döntse el, hogy az eseményt az eredeti naplókönyveléshez, a kiegyenlítő dokumentumhoz vagy mindkettőhöz rendeli.
- Sztornózások hatóköre: Állítsa be a [Reversal source] értékét, valamint az eredeti és a sztornódokumentum közötti kapcsolatot. Ha ez a kapcsolat rendelkezésre áll, a lekérdezés a sztornózási tevékenységet az eredeti JournalEntryId értékhez rendeli.
- Kézi könyvelés besorolása: Állítsa be a [Manual posting source] értékét, vagy használjon ellenőrzött könyvelésieredet-mezőt. A Manual Posting Identified besorolási esemény, ezért következetesen a könyvelés időbélyegét vagy más jóváhagyott időbélyeget használjon hozzá.
- Pénznemben megadott összeg: Az ACDOCA tételsor-alapú. A lekérdezés naplókönyvelésenként összesíti a helyi pénznemben megadott összegeket. Ellenőrizze az előjel-konvenciót, valamint azt, hogy szerepeljenek-e a statisztikai, főkönyvspecifikus vagy kiterjesztett főkönyvi sorok.
- Teljesítmény: Csak a szükséges oszlopokat válassza ki, korán alkalmazza a szűrőket, kerülje az ACDOCA korlátozás nélküli beolvasását, és jóváhagyott jelentési időszakban futtassa a lekérdezést. Ha a rendszer támogatja, használja a kliensre, pénzügyi évre, vállalatkódra és könyvelési dátumra vonatkozó feltételeket a partíciók szűkítésére.
- Duplikátumok kezelése: Lehetőség szerint használja a forrásesemény-azonosítókat. Ha egy forrás ismétlődő technikai rekordokat tartalmazhat, alkalmazza a dokumentált duplikátumkezelési szabályt, de ne vonja össze a valóban különálló workflow-műveleteket.
- Előfeltételek: Szükséges adatbázis-jogosultságok, jóváhagyott SAP HANA-kapcsolat, hozzáférés a beállított workflow- és mellékletforrásokhoz, megfelelő SAP Financial Accounting- és workflow-beállítások, valamint a ProcessMind által támogatott exportformátum.
Példa-lekérdezés 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; Lépések
- Az ABAP-program létrehozása: Nyissa meg az ABAP Editort az
SE38tranzakciókóddal. Adjon nevet az új programnak, példáulZ_PM_JE_EXTRACT, majd kattintson a „Create” gombra. Adjon meg egy megfelelő címet, a „Type” mezőben válassza az „Executable Program” lehetőséget, majd mentse helyi objektumként vagy egy csomagba. - A kiválasztóképernyő meghatározása: A programban határozza meg az adatokat szűrő paramétereket és kiválasztási opciókat. Ezek között szerepeljen a naplókönyvelés létrehozási dátumának tartománya (
P_CPUDT_FR,P_CPUDT_TO), a vállalatkód kiválasztási opciója (SO_BUKRS), valamint az alkalmazáskiszolgálón létrehozandó kimeneti fájl elérési útja (P_FPATH). - Adatszerkezetek deklarálása: Határozzon meg egy belső táblastruktúrát, amely megfelel a szükséges eseménynapló-formátumnak. Ez tárolja a végleges kimenetet. Deklaráljon belső táblákat és munkaterületeket azokhoz az SAP-táblákhoz is, amelyekből adatokat olvas be, például a BKPF, ACDOCA, CDHDR, CDPOS és a különböző workflow-táblákhoz.
- Az adatlekérdezési logika megvalósítása: Írja meg a 12 szükséges tevékenység adatainak lekéréséhez szükséges ABAP-logikát. A kód áttekinthetősége érdekében minden tevékenységhez hozzon létre külön alprogramot (FORM). Ilyen lehet például a
get_created_events, aget_parked_eventsés aget_workflow_events. - A „Created” és „Posted” események lekérdezése: Olvassa be a BKPF táblát a felhasználó által a kiválasztóképernyőn megadott feltételek alapján. A BKPF-ben szereplő bejegyzés létrehozott dokumentumot jelez. A
BSTAT = ' 'állapotú dokumentum könyveltnek számít. Eseményidőként a létrehozás időbélyegét (CPUDT,CPUTM) használja. - A „Parked” események lekérdezése: Olvassa be a parkoltatott dokumentumok fejléceit tároló VBKPF táblát. A táblában szereplő létrehozási időbélyeg jelöli a parkoltatás eseményét.
- A „Workflow” események lekérdezése (beküldés, jóváhagyás, elutasítás): Kérdezze le az olyan workflow-táblákat, mint a SWW_WI2OBJ, amely összekapcsolja a naplókönyvelési objektumot a workflow-példánnyal, valamint a SWWLOGHIST vagy SWWIHEAD táblát, amely a lépések részleteit és időpontjait tartalmazza. Azonosítsa a rendszerében a beküldéshez, jóváhagyáshoz és elutasításhoz tartozó konkrét workflow-feladatazonosítókat.
- A „Change” és „Correction” események lekérdezése: Kérdezze le a CDHDR (fejléc) és CDPOS (tétel) módosítási dokumentumtáblákat az
OBJECTCLAS = 'BELEG'feltétellel. A „Changed After Posting” eseménynél szűrjön azokra a módosításokra, amelyek időbélyege későbbi a dokumentum könyvelési dátumánál. A „Corrected” eseménynél a parkoltatott vagy elutasított dokumentumok módosításait keresse. - A „Reversal” és „Cleared” események lekérdezése: A sztornózott dokumentumokat a BKPF
STBLG(sztornózott dokumentum száma) mezőjének kitöltöttsége alapján azonosítsa. A sztornózási esemény időpontja a sztornódokumentum létrehozási ideje. A kiegyenlítési események azonosításához kérdezze le az adott naplókönyvelés tételsoraihoz tartozó legkésőbbi kiegyenlítési dátumot (AUGDT) az ACDOCA táblából. - Adatok egyesítése és rendezése: Minden tevékenység adatainak lekérdezésekor fűzze az eredményeket a végleges belső főtáblához. Az összes lekérdezés után rendezze a főtáblát
JournalEntryId, majdEventTimeszerint, hogy az egyes esetek eseményei időrendben jelenjenek meg. - A kimeneti fájl létrehozása: Az
OPEN DATASET,LOOP AT... TRANSFERésCLOSE DATASETutasításokkal írja ki a rendezett végleges belső tábla tartalmát az SAP-alkalmazáskiszolgálón megadott fájlba. A fájl CSV-formátumú legyen, fejlécsorral. - Futtatás ütemezése: Rendszeres adatkinyeréshez az
SM36tranzakciókóddal hozzon létre háttérfeladatot, amely meghatározott ütemezés szerint, például hetente vagy havonta futtatja aZ_PM_JE_EXTRACTprogramot. Így automatizálhatja az adatok exportálását.
Konfiguráció
- Dátumtartomány: A kiválasztóképernyőn kötelezően meg kell adni a naplókönyvelés létrehozási dátumának (
CPUDT) tartományát. A jó teljesítmény érdekében kezelhető méretű részekben, például egyszerre 3–6 hónap adatait javasolt kinyerni. - Vállalatkód (
BUKRS): Ezzel a szűrővel az adatkinyerés az elemzés szempontjából érintett jogi személyekre korlátozható. Nem javasoljuk az összes vállalatkód egyidejű kinyerését. - Dokumentumtípus (
BLART): Opcionális szűrőként megadhatja a naplókönyvelések típusát, például az „SA” főkönyvi könyvelést vagy a „KR” szállítói számlákat. Ezzel csökkentheti az adatmennyiséget, és relevánsabb adatállományt kaphat. - Fájl elérési útja: A programnak szüksége van az SAP-alkalmazáskiszolgálón egy logikai elérési útra, ahová a kimeneti fájlt írja. Ellenőrizze, hogy az útvonal érvényes-e, és az SAP-rendszer felhasználójának van-e írási jogosultsága a könyvtárhoz. A kiszolgáló könyvtárait az
AL11tranzakcióval kezelheti és tekintheti meg. - Workflow-feladatazonosítók: A workflow-események (beküldés, jóváhagyás, elutasítás) kinyeréséhez a szervezet naplókönyvelési jóváhagyási munkafolyamatában használt konkrét feladatazonosítókat kell beállítani. Ezek gyakran egyediek, ezért workflow-tanácsadó vagy fejlesztő segítségével kell azonosítani őket.
- Előfeltételek: A programot futtató felhasználónak vagy rendszerfióknak fejlesztői jogosultságokra van szüksége ABAP-programok létrehozásához és futtatásához (
S_DEVELOP), valamint széles körű olvasási hozzáférésre a pénzügyi táblákhoz (BKPF, ACDOCA), a módosítási naplók tábláihoz (CDHDR, CDPOS) és a workflow-táblákhoz (SWW*).
Példa-lekérdezés 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. Készen áll a kezdésre?
A sablon segítségével magabiztosan előkészítheti az adatokat, és értékes betekintést nyerhet a Record to Report naplókönyvelési folyamatába. Kezdje el még ma a folyamat fejlesztését.
Tegye hatékonyabbá a Record to Report naplókönyvelési folyamatát
Fejlessze a folyamatot, és csökkentse 30%-kal a Record to Report naplókönyveléseinek átfutási idejét.
Nincs szükség bankkártyára. Beállítás néhány perc alatt.