Adatsablon a Record to Report - Journal Entry folyamathoz
Adatsablon a Record to Report - Journal Entry folyamathoz
- Javasolt attribútumok a részletes elemzéshez
- A nyomon követendő fő naplóbejegyzési tevékenységek
- Gyakorlati útmutató az adatok kinyeréséhez SAP ECC-ből
A Record to Report - Journal Entry attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | Az időbélyeg, amely megmutatja, mikor történt egy adott tevékenység vagy esemény a naplóbejegyzés folyamatában. | ||
| Leírás Az esemény időpontja minden naplóbejegyzési tevékenység pontos dátumát és időpontját adja meg. Ez az adat elengedhetetlen az időalapú mutatók, például a ciklusidők, a feldolgozási idők és a lépések közötti késések kiszámításához. Az időbélyeg forrása a tevékenységtől függ: lehet a bizonylat létrehozásának dátuma és időpontja (CPUDT/CPUTM), vagy a naplók módosítási időbélyege (CDHDR-UDATE/UTIME). Az elemzés az esemény időpontja alapján rendezi időrendbe az eseményeket, így ez adja a folyamattérkép alapját. Az időalapú KPI-k, például az átlagos naplóbejegyzési ciklusidő, az átlagos jóváhagyási idő és a jóváhagyástól a könyvelésig eltelt idő kiszámításához is szükség van rá. Miért fontos? Ez az időbélyeg alapozza meg az időalapú elemzéseket, és lehetővé teszi a ciklusidők, az időtartamok és a szűk keresztmetszetek kiszámítását. Hol szerezhető be? A tevékenységtől függően különböző mezőkből származik. Elsősorban a BKPF létrehozási időbélyegéből (CPUDT, CPUTM) vagy a CDHDR módosítási dokumentumainak időbélyegéből (UDATE, UTIME). Példák 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Naplóbejegyzés-azonosító JournalEntryId | A pénzügyi bizonylat egyedi azonosítója, amely a vállalatkódot, a bizonylatszámot és a pénzügyi évet egyesíti. | ||
| Leírás A naplóbejegyzés-azonosító a naplóbejegyzés életútjának követésére szolgáló elsődleges esetazonosító. Összetett kulcs, amelyet általában a vállalatkód (BUKRS), a bizonylatszám (BELNR) és a pénzügyi év (GJAHR) összefűzésével állítanak elő. Így az SAP-rendszeren belül egyedi azonosítót kap. A folyamatelemzésben ez az azonosító kapcsolja össze az összes kapcsolódó tevékenységet, például a létrehozást, az előzetes rögzítést, a benyújtást, a jóváhagyást, az elutasítást és a könyvelést. Az azonosító alapján összeállítható minden naplóbejegyzés teljes útja, mérhetők a ciklusidők, és feltárhatók az egyes bejegyzések folyamateltérései és szűk keresztmetszetei. Miért fontos? Ez az alapvető azonosító követi a naplóbejegyzést a létrehozástól a végső könyvelésig, így lehetővé teszi a teljes folyamat elemzését és a változatok összehasonlítását. Hol szerezhető be? Származtatott attribútum, amelyet általában a BKPF tábla mezőinek összefűzésével állítanak elő: vállalatkód (BUKRS), bizonylatszám (BELNR) és pénzügyi év (GJAHR). Példák 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Tevékenység neve ActivityName | A naplóbejegyzési folyamat adott pontján végrehajtott üzleti tevékenység vagy bekövetkezett esemény neve. | ||
| Leírás A tevékenység neve a naplóbejegyzés életútjának egy adott lépését írja le, például: „Naplóbejegyzés létrehozva”, „Naplóbejegyzés jóváhagyva” vagy „Naplóbejegyzés lekönyvelve”. Ez az attribútum általában több SAP-adatforrásból származik, például tranzakciókódokból (TCODE), módosítási naplókból (CDHDR és CDPOS táblák), valamint a bizonylat állapotát jelző mezőkből. A tevékenységek elemzése a process mining alapja. Segítségével megjeleníthető a folyamattérkép, kiszámítható az egyes lépések közötti idő, és azonosíthatók az átdolgozási körök, például amikor az „Elutasított naplóbejegyzés” után a „Naplóbejegyzés javítva” következik. Ezek az adatok alapozzák meg a ciklusidőket, az átdolgozási arányokat és a folyamatváltozatokat bemutató dashboardokat. Miért fontos? Meghatározza a folyamattérkép lépéseit, így a naplóbejegyzési munkafolyamat megjeleníthető, elemezhető és fejleszthető. Hol szerezhető be? Többféle forrásból származik, például a BKPF tranzakciókódjaiból (TCODE), a bizonylat állapotából, a SWW_WI2OBJ-hez hasonló táblák munkafolyamatnaplóiból, illetve a CDHDR és CDPOS táblák módosítási dokumentumaiból. Példák Naplóbejegyzés létrehozvaNaplóbejegyzés jóváhagyvaNaplóbejegyzés véglegesen elutasítvaNaplóbejegyzés lekönyvelve | |||
| Forrásrendszer SourceSystem | A rendszer, amelyből a folyamatadatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja az adatok forrását, ebben az esetben az adott SAP ECC-példányt. Általában az adatok kinyerésekor hozzáadott, állandó érték. Több ERP-rendszert vagy adatforrást használó környezetben ez az attribútum segít egyértelműen nyomon követni az adatok eredetét, és lehetővé teszi az elemzés forrásrendszer szerinti szűrését vagy bontását. Miért fontos? Egyértelműen nyomon követhetővé teszi az adatok eredetét, és segít ellenőrizni az adatminőséget, különösen több forrásrendszer használatakor. Hol szerezhető be? Általában az adatátalakítás során hozzáadott, állandó érték, amely az adott SAP ECC-példányt azonosítja, például „ECC_PROD_100”. Példák SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg, amely megmutatja, mikor nyerték ki vagy frissítették utoljára az adatokat a forrásrendszerből. | ||
| Leírás Ez az attribútum rögzíti az SAP ECC-ből történő legutóbbi adatkinyerés dátumát és időpontját. Olyan metaadatmező, amely segít megállapítani, mennyire frissek az elemzett adatok. A process mining dashboardokon és elemzésekben az utolsó frissítés időpontja segít a felhasználóknak eldönteni, mennyire naprakészek az adatok, és megbízhatnak-e bennük. Választ ad arra a kérdésre is, hogy „Mennyire frissek ezek az információk?”. Miért fontos? Megmutatja, mennyire frissek az adatok, így a felhasználók tisztában vannak az elemzés időszakával, és megbízhatnak az eredményekben. Hol szerezhető be? Az adatkinyerő eszköz vagy az ETL-folyamat által az adatfrissítéskor létrehozott és tárolt metaadatmező. Példák 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Bizonylattípus DocumentType | A könyvelési bizonylatok besorolása, amely meghatározza azok feldolgozását és tárolását. | ||
| Leírás A bizonylattípus különbözteti meg az üzleti tranzakciókat, például a főkönyvi könyvelést (SA), a szállítói számlát (KR) vagy az eszközkönyvelést (AA). A rendszer beállításakor határozzák meg, és minden naplóbejegzéshez hozzárendelik. Az elemzésben ez az attribútum lehetővé teszi a folyamat tranzakciótípus szerinti bontását. A „Naplóbejegyzések száma típusonként” dashboard és az „Átlagos ciklusidő naplóbejegyzés-típusonként” KPI közvetlenül erre a mezőre támaszkodik. Segít feltárni, hogy bizonyos bejegyzéstípusoknál gyakoribbak-e a késések, az átdolgozások vagy a visszafordítások. Miért fontos? A tranzakciótípus szerinti bontással megmutatja, hogy a folyamatproblémák csak bizonyos naplóbejegyzés-típusokat érintenek-e. Hol szerezhető be? A BKPF bizonylatfejléc-táblában, a BLART mezőben található. Példák SAKRREAA | |||
| Felhasználó User | A naplóbejegyzést létrehozó vagy módosító személy SAP-felhasználói azonosítója. | ||
| Leírás Ez az attribútum rögzíti az adott tevékenységért, például egy bizonylat létrehozásáért, előzetes rögzítéséért vagy könyveléséért felelős SAP-felhasználó nevét. Közvetlenül a bizonylatfejléc- vagy módosításinapló-táblákból származik. A felhasználó attribútum elemzése segít megérteni a csapatok és az egyes felhasználók teljesítményét. A felhasználói produktivitást bemutató dashboardon felhasználónként követhetők a tevékenységek mennyiségei és feldolgozási ideje. Az attribútum azt is megmutatja, kik vesznek részt az átdolgozási körökben, a visszafordításokban vagy a megfelelési eltérésekben, így célzott képzés és folyamatfejlesztés tervezhető. Miért fontos? Megmutatja, ki felel az egyes tevékenységekért, így elemezhető a felhasználói teljesítmény, a munkaterhelés eloszlása és az átdolgozások mintázata. Hol szerezhető be? Általában a BKPF táblából származik (a létrehozó USNAM mezője), vagy a CDHDR táblából (a módosító USERNAME mezője). Példák ABROWNCJONESDSMITH | |||
| Könyvelési dátum PostingDate | Az a dátum, amikor a tranzakció bekerül a főkönyvbe, és ezzel meghatározza az érintett pénzügyi időszakot. | ||
| Leírás A könyvelési dátum határozza meg, melyik pénzügyi időszakban számolják el a naplóbejegyzést. Pénzügyi és megfelelési szempontból fontos dátummező, amelynek igazodnia kell a számviteli időszak zárási ütemezéséhez és az előírásokhoz. A process miningban ezzel a dátummal ellenőrizhető a megfelelés. A „Megfelelés nyomon követése” dashboard és a „Megfelelési arány” KPI segítségével ellenőrizhető, hogy a bejegyzéseket a megfelelő időszakban könyvelték-e le. A dátum a naplóbejegyzések mennyiségének időbeli alakulását is megmutatja. Miért fontos? A pénzügyi beszámolók és a megfelelés elemzéséhez szükséges, és segít ellenőrizni, hogy a bejegyzések a megfelelő számviteli időszakban kerültek-e könyvelésre. Hol szerezhető be? A BKPF bizonylatfejléc-táblában, a BUDAT mezőben található. Példák 2023-10-312023-11-302024-01-15 | |||
| Tranzakciókód TransactionCode | A naplóbejegyzés létrehozásához vagy feldolgozásához használt SAP-tranzakciókód. | ||
| Leírás A tranzakciókód (T-Code) egy adott SAP-funkció vagy -program egyedi azonosítója. Naplóbejegyzéseknél megmutatja, hogyan jött létre a bejegyzés: például kézi rögzítéssel (FB01, F-02), előzetes rögzítéssel (FV50) vagy automatizált interfészen keresztül. Ez az attribútum különösen hasznos a „Kézi tevékenységek optimalizálása” dashboardhoz. A T-Code elemzésével megkülönböztethetők a kézi és automatizált tevékenységek, azonosíthatók a legtöbb időt igénylő kézi folyamatok, és feltárhatók az automatizálási lehetőségek. Így csökkenthető a kézi munka és javítható a hatékonyság. Miért fontos? Segít megkülönböztetni a kézi és automatizált folyamatokat, valamint feltárni az automatizálási és folyamat-szabványosítási lehetőségeket. Hol szerezhető be? A BKPF bizonylatfejléc-táblában, a TCODE mezőben található. Példák FB01F-02FV50FBD1 | |||
| Vállalatkód CompanyCode | Az önálló jogi személyt képviselő szervezeti egység, amelyre pénzügyi kimutatások készülnek. | ||
| Leírás A vállalatkód az SAP Financials egyik alapvető szervezeti egysége. Önálló jogi személyt jelöl, és a naplóbejegyzés bizonylatfejlécének egyik fontos mezője. Ez az attribútum lehetővé teszi a folyamatelemzés jogi személyenkénti bontását. Összehasonlítható vele a folyamatok teljesítménye, a megfelelési arány és a KPI-k eredménye az üzlet különböző részei között. Például kideríthető, hogy a jóváhagyási késések vagy a gyakori visszafordítások csak bizonyos vállalatkódoknál jelentkeznek-e. Miért fontos? Lehetővé teszi a folyamatok teljesítményének szűrését és összehasonlítását a szervezet különböző jogi személyei vagy üzleti egységei között. Hol szerezhető be? A BKPF bizonylatfejléc-táblában, a BUKRS mezőben található. Példák 10002000US01DE01 | |||
| Visszafordítva IsReversed | Logikai jelző, amely megmutatja, hogy visszafordították-e a naplóbejegyzést. | ||
| Leírás Ez a jelző azokat a naplóbejegyzéseket azonosítja, amelyeket később egy másik könyvelési bizonylattal visszafordítottak. Az SAP-ban a visszafordított bizonylat hivatkozik a sztornóbizonylatra, így egyértelmű auditnyomvonalat biztosít. Ez az attribútum alapvető a „Naplóbejegyzések sztornóelemzése” dashboardhoz és a „Naplóbejegyzések sztornóaránya” KPI-hoz. Segítségével elkülöníthetők a visszafordított tételek, így feltárhatók a kiváltó okok, például az adatrögzítési hibák vagy a helytelen könyvelési kezelés. Ezzel csökkenthető a sztornók gyakorisága. Miért fontos? Közvetlenül támogatja a sztornóelemzést: megjelöli a később visszavont tételeket, így segít feltárni a hibák okait és javítani az adatok megbízhatóságát. Hol szerezhető be? A BKPF tábla Reversal Document number mezőjéből (STBLG) származik. Ha az STBLG mező nem üres, a jelző értéke igaz. Példák truefalse | |||
| Bizonylat teljes összege TotalDocumentAmount | A naplóbejegyzés teljes értéke a bizonylat pénznemében. | ||
| Leírás Ez az attribútum a naplóbejegyzés teljes pénzügyi értékét mutatja. Általában a bizonylathoz tartozó összes tartozik- vagy követel tétel abszolút értékének összegeként számítják ki. A folyamat pénzügyi érték szerinti elemzése fontos mintázatokat tárhat fel. A nagy összegű bejegyzések például eltérő, szigorúbb jóváhagyási folyamatot követhetnek. Az attribútummal szűrhető vagy bontható az elemzés, így ellenőrizhető, hogy az összeg összefügg-e a ciklusidővel, az elutasítások arányával vagy a jóváhagyási késésekkel. Miért fontos? Lehetővé teszi a pénzügyi hatás elemzését, például a feldolgozási idő vagy az elutasítási arány összevetését a naplóbejegyzések pénzösszegével. Hol szerezhető be? Számított mező, amelyet az adott naplóbejegyzéshez tartozó BSEG-tábla összes tételének összegmezőiből (WRBTR vagy DMBTR) állítanak elő. Példák 1500.0025000.75125.50 | |||
| Jóváhagyási idő ApprovalTime | A naplóbejegyzés 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 mutató a jóváhagyási részfolyamat időtartamát méri, amely gyakran jelentősen növeli a teljes átfutási időt. A „Naplóbejegyzés beküldve” tevékenység és a hozzá tartozó „Naplóbejegyzés jóváhagyva” vagy „Naplóbejegyzés elutasítva” tevékenység időpontja közötti különbségből számítható ki. A jóváhagyási idő a „Naplóbejegyzések jóváhagyási teljesítménye” dashboard és az „Átlagos naplóbejegyzés-jóváhagyási idő” KPI alapmutatója. Elemzésével azonosíthatók a jóváhagyási munkafolyamat szűk keresztmetszetei, mérhető a jóváhagyók teljesítménye, és alátámaszthatók a folyamatmódosítások, például a jóváhagyási értékhatárok módosítása. Miért fontos? Méri a jóváhagyási szakasz időtartamát, így feltárhatók és kezelhetők az ellenőrzési és jóváhagyási munkafolyamat késedelmei. Hol szerezhető be? A „Naplóbejegyzés beküldve” esemény időbélyegét kivonjuk a „Naplóbejegyzés jóváhagyva” vagy „Naplóbejegyzés elutasítva” esemény időbélyegéből. Példák P1DT2HPT4H15MP3D | |||
| Költséghely CostCenter | Az irányítási területen belüli szervezeti egység, amely egy költségek felmerülésével járó helyet jelöl. | ||
| Leírás A költséghely a Controlling (CO) modul egyik fontos törzsadat-eleme, amelyet gyakran a naplóbejegyzés tételsorához rendelnek. Egy adott részleg, funkció vagy hely költségeinek nyomon követésére szolgál. A költséghely bevonásával részletesebben elemezhető a naplóbejegyzések folyamata. Kiderülhet például, hogy egyes részlegeknél több az újramunka, hosszabb az átfutási idő, vagy több kézi rögzítésre van szükség. Így a folyamat hatékonysága részlegenként is vizsgálható. Miért fontos? Lehetővé teszi a folyamat teljesítményének részleg vagy funkcionális terület szerinti elemzését, és segít feltárni a helyi hatékonysági problémákat. Hol szerezhető be? A BSEG bizonylattétel-táblában található, a KOSTL mezőben. Példák 4100CC_FINANCE_US10010101 | |||
| Parkolt-e IsParked | Logikai jelző, amely megmutatja, hogy a naplóbejegyzést könyvelés előtt parkolt bizonylatként mentették-e. | ||
| Leírás A bizonylat parkolásával a felhasználó úgy menthet el egy hiányos naplóbejegyzést, hogy az ne módosítsa a pénzügyi egyenlegeket. Egy másik felhasználó később kiegészítheti vagy ellenőrizheti, mielőtt könyvelik. Ez a jelző azokat a tételeket azonosítja, amelyeknél sor került parkolásra. Az attribútum elemzésével megérthető, hogyan használják a parkolási funkciót. Kiderülhet, hogy informális ellenőrzési lépésként alkalmazzák, ami késedelmet okozhat. Az elejétől a végéig tartó átfutási idő elemzését is támogatja, megkülönböztetve a közvetlenül könyvelt és az előbb parkolt tételeket. Miért fontos? Azonosítja a parkolási funkcióval kezelt tételeket. Ezek késedelmet okozhatnak, vagy informális ellenőrzési folyamatra utalhatnak. Hol szerezhető be? A BKPF tábla bizonylatállapot-mezőjéből (BSTAT) származik. A „V” érték parkolt bizonylatot jelöl. Példák truefalse | |||
| Pénznemkulcs CurrencyKey | A naplóbejegyzésben rögzített összegek pénznemkódja. | ||
| Leírás Ez az attribútum adja meg a naplóbejegyzés pénznemét, például USD, EUR vagy JPY. Segít értelmezni a bizonylathoz tartozó pénzügyi összegeket. Bár nem mindig elsődleges elemzési szempont, a pénzösszegek helyes értelmezéséhez elengedhetetlen. Nemzetközi szervezeteknél az elemzés pénznem szerinti bontására is használható, így összehasonlíthatók a külföldi és a helyi pénznemben rögzített tételek folyamatai. Miért fontos? Megadja a pénzügyi összegek helyes elemzéséhez és értelmezéséhez szükséges pénznemadatokat. Hol szerezhető be? A BKPF bizonylatfejléc-táblában található, a WAERS mezőben. Példák USDEURGBPJPY | |||
| Sztornó oka ReversalReason | A naplóbejegyzés sztornózásának okát jelölő kód. | ||
| Leírás Bizonylat sztornózásakor az SAP-ban a felhasználó megadhat egy okkódot. Ez strukturáltan rögzíti, miért volt szükség a sztornóra, például hibás könyvelési dátum vagy adatrögzítési hiba miatt. Ez az attribútum a „Naplóbejegyzések sztornóelemzése” dashboard egyik fontos bemenő adata. A leggyakoribb sztornóokok elemzésével feltárhatók a folyamatok rendszerszintű problémái és a képzési hiányosságok. Ezek alapján célzott intézkedésekkel megelőzhetők a jövőbeli hibák és csökkenthető a sztornóarány. Miért fontos? Közvetlenül megmutatja, miért történnek sztornók, így célzottan feltárhatók a kiváltó okok és megelőzhetők a későbbi hibák. Hol szerezhető be? A BKPF bizonylatfejléc-táblában található, az STGRD mezőben. Példák 010205 | |||
| Újramunka történt-e IsRework | Logikai jelző, amely megmutatja, hogy a naplóbejegyzésnél történt-e újramunka, például elutasítás utáni javítás. | ||
| Leírás Ez a jelző azokat az eseteket azonosítja, amelyek eltértek a szokásos folyamattól, és korrekcióra volt szükség. Értéke jellemzően akkor igaz, ha az adott naplóbejegyzésnél olyan tevékenységsorozat figyelhető meg, mint a „Naplóbejegyzés elutasítva”, majd a „Naplóbejegyzés javítva”. Ez az attribútum elengedhetetlen a „Naplóbejegyzések újramunkálási aránya” KPI kiszámításához és az „Újramunka és elutasítási arány” dashboard elemzéséhez. Segít számszerűsíteni a folyamat hatékonyságvesztését, és alapot ad az újramunka okainak, például a nem egyértelmű követelményeknek vagy a hiányos dokumentációnak a feltárásához. Miért fontos? Megjelöli a javítást igénylő tételeket. Így mérhető az újramunka mértéke, feltárhatók az okai, és javítható az elsőre helyes teljesítés aránya. Hol szerezhető be? Számított attribútum, amely az eset tevékenységsorozatának elemzéséből származik. Újramunkálási ciklust jelez, ha elutasítási vagy javítási tevékenység történik. Példák truefalse | |||
A Record to Report - Journal Entry tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Naplóbejegyzés előzetesen rögzítve | Ez a tevékenység a naplóbejegyzés kezdeti, előzetes állapotú létrehozását jelöli, mielőtt hivatalosan bekerülne a főkönyvbe. Az SAP ezt kifejezetten rögzíti, amikor a felhasználó egy előzetes rögzítésre szolgáló tranzakcióval menti a bizonylatot, és annak állapota „parked” lesz. | ||
| Miért fontos? Ez fontos kezdő esemény azoknál a folyamatoknál, amelyek felülvizsgálatot és jóváhagyást igényelnek. Az előzetes rögzítés és a könyvelés közötti idő elemzésével feltárhatók a könyvelés előtti és a jóváhagyási szakasz késései. Hol szerezhető be? Az esemény a BKPF bizonylatfejléc-táblából azonosítható. A bizonylat akkor számít előzetesen rögzítettnek, ha létrehozásakor a BKPF-BSTAT értéke „V”. Az esemény időbélyege a létrehozás dátuma és időpontja: BKPF-CPUDT és BKPF-CPUTM. Rögzítés A BKPF táblában azonosítsa azokat a bizonylatokat, amelyeknél a BKPF-BSTAT értéke „V”. Eseménytípus explicit | |||
| Naplóbejegyzés jóváhagyásra benyújtva | Ez a tevékenység azt jelzi, hogy az előzetesen rögzített naplóbejegyzést a létrehozója véglegesítette, és az készen áll a felülvizsgálatra és jóváhagyásra. Ezt általában az előzetesen rögzített bizonylathoz kapcsolódó SAP Business Workflow-feladat indítása rögzíti. | ||
| Miért fontos? Ez jelöli az átadást a létrehozótól a jóváhagyónak, és ezzel elindítja a jóváhagyási ciklusidő KPI-jainak mérését. Fontos mérföldkő a jóváhagyási munkafolyamat hatékonyságának mérésében. Hol szerezhető be? A pénzügyi bizonylat objektumához kapcsolt jóváhagyási munkafolyamat-példány kezdési időpontjából következtethető ki. Ehhez olyan munkafolyamatnapló-táblákat kell elemezni, mint a SWW_WI2OBJ, hogy megtalálható legyen az adott vállalatkódhoz, bizonylatszámhoz és pénzügyi évhez tartozó munkafolyamat. Rögzítés Azonosítsa az előzetesen rögzített bizonylat objektumához tartozó munkafolyamat indítását. Eseménytípus inferred | |||
| Naplóbejegyzés jóváhagyva | Ez a tevékenység a naplóbejegyzés munkafolyamaton belüli végső jóváhagyását jelöli, amely után a bejegyzés könyvelhetővé válik. Az eseményt a munkafolyamatnapló rögzíti a végső „feloldás” vagy „jóváhagyás” lépés befejezésekor. | ||
| Miért fontos? Ez a jóváhagyási folyamatot lezáró fontos mérföldkő. Az eseményig eltelt idő a jóváhagyás hatékonyságának fontos KPI-ja, az esemény és a könyvelés közötti idő pedig a jóváhagyás utáni késést mutatja. Hol szerezhető be? Az SAP Business Workflow naplójában szereplő végső jóváhagyási lépés befejezési időbélyegéből következtethető ki. Ez az utolsó jóváhagyási művelet, mielőtt a bizonylatot lekönyvelik vagy könyvelésre előkészítik. Rögzítés Azonosítsa a végső „feloldás” vagy „jóváhagyás” lépés befejezését a munkafolyamatnaplókban. Eseménytípus inferred | |||
| Naplóbejegyzés lekönyvelve | Ez a központi tevékenység: a naplóbejegyzés hivatalosan bekerül a főkönyvbe, és hatással van a pénzügyi kimutatásokra. Az SAP kifejezetten rögzíti ezt az eseményt, amikor a bizonylat állapota „könyvelt” lesz, és megkapja a könyvelési dátumot. | ||
| Miért fontos? Ez a legfontosabb mérföldkő, amely a naplóbejegyzés sikeres feldolgozását jelzi. A teljes ciklusidőt gyakran eddig a pontig mérik. Ez az esemény a pénzügyi zárás elemzésében is fontos. Hol szerezhető be? A BKPF táblában szereplő bizonylat akkor azonosítható, ha van könyvelési dátuma (BKPF-BUDAT). Előzetesen rögzített bizonylatnál ez annak a pillanatnak felel meg, amikor a BKPF-BSTAT értéke „V”-ről üresre változik. A könyvelés időbélyege a rögzítés dátuma, BKPF-CPUDT. Rögzítés Azonosítsa, amikor a BKPF-BSTAT értéke „V”-ről üresre változik. Közvetlen könyvelésnél a létrehozási eseményt vegye alapul. Eseménytípus explicit | |||
| Naplóbejegyzés visszafordítva | Ez a tevékenység egy korábban lekönyvelt naplóbejegyzés visszafordítását jelöli. A visszafordítás egy új könyvelési bizonylat, amely érvényteleníti az eredeti bejegyzést. | ||
| Miért fontos? Ez az esemény fontos az adatminőség és a folyamat pontosságának méréséhez. A gyakori visszafordítások a kezdeti adatrögzítés vagy a jóváhagyás rendszerszintű problémáira utalnak, és minden visszafordítás többletmunkát jelent. Hol szerezhető be? Az esemény az eredeti bizonylat fejlécéből (BKPF tábla) azonosítható. Visszafordításkor az SAP kitölti a visszafordító bizonylat számát (BKPF-STBLG) és a visszafordítás okát (BKPF-STGRD). Az esemény időbélyege az új, visszafordító bizonylat könyvelési dátuma. Rögzítés Azonosítsa, amikor a BKPF-STBLG mező értéket kap az eredeti bizonylaton. Az időbélyeg a visszafordító bizonylat könyvelési dátuma. Eseménytípus explicit | |||
| Dokumentáció csatolva | Ez a tevékenység azt jelöli, amikor a felhasználó alátámasztó dokumentumokat, például számlákat vagy táblázatokat csatol a naplóbejegyzéshez. Ez nem szerepel külön, szabványos könyvelési eseményként a naplóban. Általában úgy következtetnek rá, hogy ellenőrzik a könyvelési bizonylathoz kapcsolt mellékletek létrehozását. | ||
| Miért fontos? A tevékenység követésével ellenőrizhető, hogy betartják-e a dokumentációt előíró szabályokat. A mellékletek késedelmes csatolása elnyújthatja a jóváhagyási ciklust. Hol szerezhető be? Ezt nehéz megbízhatóan, időbélyeggel ellátott eseményként rögzíteni. A Generic Object Services (GOS) mellékleteket tároló tábláinak, például a SOOD-nak az elemzésével következtetni lehet rá, ha a melléklet létrehozási időbélyegét összekapcsolják a naplóbejegyzés objektumkulcsával. Rögzítés Következtessen rá a GOS-táblákban (például SOOD) szereplő kapcsolt objektumok létrehozási időbélyegéből. Eseménytípus inferred | |||
| Előzetesen rögzített naplóbejegyzés törölve | Olyan előzetesen rögzített naplóbejegyzés törlését jelöli, amelyet soha nem könyveltek le. Ez elutasítás után vagy téves létrehozás esetén történhet meg. | ||
| Miért fontos? Ez a tevékenység a folyamat sikertelen lezárását jelzi. A törölt, előzetesen rögzített bizonylatok okainak elemzése feltárhatja például a duplikált bejegyzéseket vagy a folyamat félreértését. Hol szerezhető be? Az eseményt akkor rögzítik, amikor módosul a BKPF táblában szereplő, előzetesen rögzített bizonylat állapota. A BKPF-BSTAT mező értéke „Z”-re változik (előzetesen rögzített bizonylat törölve). A módosítás időbélyege a bizonylat módosítási naplóiban (CDHDR) található. Rögzítés Azonosítsa, amikor a BKPF-BSTAT értéke „Z”-re változik. Eseménytípus explicit | |||
| Kézi rögzítés azonosítva | Ez a tevékenység azt állapítja meg, hogy a naplóbejegyzés kézi online tranzakcióval vagy automatizált interfészen, illetve kötegelt folyamaton keresztül jött-e létre. Nem felhasználói művelet, hanem a rendszeradatokból számított attribútum. | ||
| Miért fontos? A kézi és automatizált bejegyzések megkülönböztetése segít célzottan fejleszteni a folyamatot. A kézi folyamatok gyakran a szabványosítási és automatizálási kezdeményezések elsődleges céljai. Hol szerezhető be? A BKPF bizonylatfejléc-tábla mezőinek elemzésével számítható ki. Az olyan tranzakciókódok, mint az „FB01”, az „FB50” vagy az „FV50” (BKPF-TCODE), kézi rögzítésre utalnak. Más T-kódok vagy bizonyos kötegelt adatbeviteli nevek (BKPF-AWKEY) automatizálást jelezhetnek. Rögzítés A BKPF-TCODE vagy a bizonylatfejléc más, forrásrendszerből származó jelzői alapján határozza meg. Eseménytípus calculated | |||
| Naplóbejegyzés javításra visszaküldve | A munkafolyamatnak azt a pontját jelöli, amikor a jóváhagyó felülvizsgálta a naplóbejegyzést, majd javításra visszaküldte a létrehozónak. Az esemény a munkafolyamatnaplóból azonosítható, amely „elutasítás” vagy „visszaküldés” felhasználói döntést rögzít. | ||
| Miért fontos? Ez a tevékenység elengedhetetlen az átdolgozási körök feltárásához, amelyek a hatékonyságromlás és a folyamateltérések fő okai közé tartoznak. Ha gyakran fordul elő, az a bejegyzések minőségével vagy a követelmények egyértelműségével kapcsolatos problémákra utal. Hol szerezhető be? Az esemény időpontja az SAP Business Workflow naplójának egy olyan felhasználói döntési lépéséből következtethető ki, amely „elutasításnak” vagy „javításra küldésnek” felel meg. Rögzítés Azonosítsa az „elutasítás” vagy „átdolgozás” döntésének időbélyegét a munkafolyamatnaplókban. Eseménytípus inferred | |||
| Naplóbejegyzés javítva | Ez a tevékenység azt jelzi, hogy az eredeti létrehozó módosította az előzetesen rögzített naplóbejegyzést, miután azt javításra visszaküldték. Az esemény a bizonylaton a „Javítás kérése” esemény után végrehajtott módosítások alapján azonosítható. | ||
| Miért fontos? A javítások követésével mérhető az átdolgozásra fordított munka. A javítás kérése és a módosítás elvégzése közötti idő megmutatja, mennyi időbe telik a benyújtott bejegyzésekkel kapcsolatos problémák megoldása. Hol szerezhető be? Az előzetesen rögzített bizonylathoz tartozó módosítási naplók (CDHDR és CDPOS táblák) elemzésével következtethető ki. Ha a munkafolyamatban rögzített elutasítás után módosítás történik, az javításra utal. Az időbélyeg a CDHDR táblából származik. Rögzítés Azonosítsa a CDHDR/CDPOS táblákban szereplő módosítási naplóbejegyzést az elutasítás után. Eseménytípus inferred | |||
| Naplóbejegyzés létrehozva | Olyan naplóbejegyzés létrehozását jelöli, amelyet közvetlenül könyvelnek, előzetes rögzítés nélkül. Az SAP ezt akkor rögzíti, amikor a bizonylat közvetlen könyvelési tranzakcióval jön létre. | ||
| Miért fontos? Ez a tevékenység alternatív kezdőpont az egyszerűbb, jóváhagyási munkafolyamatot nem igénylő naplóbejegyzési folyamatoknál. Segít megkülönböztetni az egyszerű, közvetlen könyveléseket az összetettebb, előzetesen rögzített bejegyzésektől. Hol szerezhető be? Ez az esemény a BKPF táblában szereplő bizonylat létrehozásának felel meg, amikor a bizonylat állapota, vagyis a BKPF-BSTAT mező üres (könyvelt). Az esemény időbélyege a létrehozás dátuma, BKPF-CPUDT. Ezeknél a bizonylatoknál a „Létrehozva” és a „Könyvelve” esemény egy időben történik. Rögzítés A BKPF táblában azonosítsa azokat a bizonylatokat, amelyeknél a BKPF-BSTAT mező üres. Eseménytípus explicit | |||
| Naplóbejegyzés tétele kiegyenlítve | Ez a tevékenység egy nyitott tételes főkönyvi számla, például egy banki elszámolószámla tételének egyeztetését jelöli. Akkor történik meg, amikor egy tételt egy másik tétellel párosítanak, és ezzel lezárják. | ||
| Miért fontos? A banki egyeztetéshez hasonló folyamatoknál a tételek kiegyenlítéséhez szükséges idő fontos KPI. Ez a tevékenység segít elemezni az egyeztetés és a hónap végi zárás hatékonyságát. Hol szerezhető be? Az eseményt a BSEG tételtábla rögzíti. Egy tétel kiegyenlítésekor kitöltik a kiegyenlítés dátumát (BSEG-AUGDT) és a kiegyenlítési bizonylatot (BSEG-AUGBL). Az esemény időbélyege a kiegyenlítés dátuma. Rögzítés Azonosítsa, amikor egy tételnél kitöltik a kiegyenlítés dátumát (BSEG-AUGDT). Eseménytípus explicit | |||
| Naplóbejegyzés véglegesen elutasítva | Ez a tevékenység a naplóbejegyzés végleges elutasítását jelöli, amely után a bejegyzést már nem könyvelik le. A jóváhagyási munkafolyamatban ez általában végállapot, amelyet az előzetesen rögzített bizonylat későbbi törlése követ. | ||
| Miért fontos? Az elutasítások követése fontos a minőségirányításhoz. Az elutasítások okainak és gyakoriságának elemzése segít javítani a naplóbejegyzések elsőre helyes feldolgozásának arányát. Hol szerezhető be? Az SAP Business Workflow naplója rögzíti ezt az eredményt: a végleges „elutasítás” felhasználói döntés lezárja a folyamatot. Az előzetesen rögzített bizonylatot ezt követően törölhetik. Rögzítés Azonosítsa a bizonylathoz tartozó munkafolyamatnapló végleges „elutasított” állapotát. Eseménytípus inferred | |||
| Vállalatközi könyvelés azonosítva | Számított tevékenység, amely jelzi, ha egy naplóbejegyzés egynél több vállalatkódot érint. Ezt egyetlen pénzügyi bizonylat tételeinek elemzésével lehet megállapítani. | ||
| Miért fontos? A vállalatközi tranzakciók feldolgozása és jóváhagyása összetettebb lehet. Azonosításukkal külön elemezhetők a ciklusidők és a folyamatútvonalak, így feltárhatók az egyedi szűk keresztmetszetek. Hol szerezhető be? A BSEG tételtábla adott bizonylatszámhoz (BELNR) tartozó sorainak vizsgálatával számítható ki. Ha a tételekben egynél több különböző vállalatkód (BSEG-BUKRS) szerepel, a könyvelés vállalatközi. Rögzítés Ellenőrizze, hogy egyetlen BKPF-BELNR-hez több különböző BSEG-BUKRS-érték tartozik-e. Eseménytípus calculated | |||
Adatkinyerési útmutatók
Lépések
- Az ABAP-program létrehozása: Az SAP-rendszerben nyissa meg az SE38 tranzakciót (ABAP Editor). Adjon nevet az új programnak, például Z_PM_JE_EXTRACTION, majd kattintson a Create gombra. Adjon meg egy megfelelő címet, és válassza az „Executable Program” programtípust.
- A kiválasztóképernyő meghatározása: A program forráskódjában határozza meg a kiválasztóképernyőt. Ezen a felhasználók megadhatják például a bizonylatok létrehozási dátumának tartományát, a vállalatkódokat és a bizonylattípusokat, így korlátozható a kinyerendő adatok mennyisége.
- Adatszerkezetek deklarálása: Határozzon meg egy belső táblastruktúrát a végleges eseménynapló adatainak tárolására. Ennek tartalmaznia kell az összes kötelező mezőt: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, valamint az ajánlott attribútumokat, például User, CompanyCode és PostingDate.
- Az adatkinyerési logika megírása: Írja meg az alapvető ABAP SQL-lekérdezéseket mind a 14 szükséges tevékenység adatainak kinyeréséhez. Ehhez a fő táblákból, például a BKPF-ből (fejléc) és a BSEG-ből (tételsor), a változásnapló-táblákból (CDHDR és CDPOS), a munkafolyamat-táblákból (például SWWLOGHIST), valamint a kiegyenlítési táblákból (például BSAS és BSAK) kell adatokat kiválasztani.
- Parkolt és könyvelt bizonylatok kinyerése: A „Naplóbejegyzés parkolva” eseményhez válassza ki a BKPF azon sorait, amelyeknél a bizonylatállapot (BSTAT) értéke „V”. A „Naplóbejegyzés létrehozva” és „Naplóbejegyzés könyvelve” eseményhez a BKPF üres állapotú sorait válassza ki, amelyek normál, könyvelt bizonylatot jelölnek.
- Módosítási és törlési események kinyerése: Kérdezze le a CDHDR és CDPOS változásbizonylat-táblákat a „BELEG” objektumosztályhoz. A bizonylatkulcs alapján keresse meg a „Naplóbejegyzés javítva” vagy „Parkolt naplóbejegyzés törölve” tevékenységnek megfelelő módosításokat.
- Munkafolyamat-események kinyerése: A „Naplóbejegyzés beküldve”, „Jóváhagyva”, „Elutasítva” és „Módosítás kérése” tevékenységek rögzítéséhez kérdezze le a munkafolyamat-táblákat. Az SWW_WI2OBJ táblával kapcsolja össze a könyvelési bizonylatot a munkafolyamat-példánnyal, majd az SWWLOGHIST táblából olvassa ki a felhasználói döntéseket és az állapotváltozásokat.
- Számított események azonosítása: A „Kézi rögzítés azonosítva” eseményhez vesse össze a tranzakciókódot (BKPF-TCODE) az ismert kézi rögzítési tranzakciók listájával. A „Vállalatközi könyvelés azonosítva” eseményhez vizsgálja meg az adott bizonylat BSEG-tételsorait, és ellenőrizze, hogy több vállalatkód érintett-e.
- Adatok összevonása és átalakítása: Az egyes tevékenységek adatainak kiválasztásakor alakítsa át őket a végleges eseménynapló struktúrájába. A JournalEntryId létrehozásához fűzze össze a vállalatkódot, a bizonylatszámot és az üzleti évet. Alakítsa át az SAP dátum- és időadatokat egyetlen EventTime időbélyeggé. Az egyes lekérdezések eredményeit fűzze hozzá a végleges belső táblához.
- Fájl exportálása: Az összevont belső tábla SAP alkalmazáskiszolgáló-könyvtárba történő CSV- vagy egyszerű szöveges fájlba írásához használja az ABAP fájlkezelő utasításait, például az OPEN DATASET, LOOP AT, TRANSFER és CLOSE DATASET utasításokat. A fájl az AL11 tranzakcióval tekinthető meg.
- Háttérfeladat ütemezése: Nyissa meg az SM36 tranzakciót (Define Background Job). Hozzon létre új feladatot, adjon meg egy lépést az ABAP-program futtatására, majd ütemezze például éjszakára vagy hétvégére, csúcsidőn kívülre az adatkinyerés automatizálásához.
- Fájl letöltése és formázása: A létrehozott fájl alkalmazáskiszolgálóról a helyi gépre történő letöltéséhez használja a CG3Y tranzakciót, vagy kérje a rendszergazda segítségét. Ellenőrizze, hogy a fájl kódolása és formátuma megfelel-e a process mining eszközbe történő feltöltéshez.
Konfiguráció
- Dátumtartomány: A teljesítmény megőrzése érdekében feltétlenül adjon meg dátumtartományt. Elsődleges szűrőként használja a bizonylat létrehozási dátumát (BKPF-CPUDT). Első elemzéshez 3–6 hónapos időszak javasolt. Teszteléshez válasszon néhány napot, amelyről tudja, hogy tartalmaz adatokat.
- Vállalatkód szerinti szűrés: Mindig szűrjön vállalatkódra (BKPF-BUKRS). Az összes vállalatkód adatainak egyidejű kinyerése jelentős erőforrásokat igényelhet. Kezdje egy vagy néhány releváns vállalatkóddal.
- Bizonylattípus szerinti szűrés: A bizonylattípus-szűrővel (BKPF-BLART) szűkítse a kört bizonyos naplóbejegyzés-típusokra, például az „SA” főkönyvi bizonylatokra, ha nem kell minden bizonylattípust elemeznie.
- Munkafolyamat-feladatazonosítók: A munkafolyamat-események kinyerésének logikája a rendszerben a jóváhagyáshoz, elutasításhoz és beküldéshez használt feladatazonosítóktól függ. Ezeket a vállalat munkafolyamat-definíciói alapján kell beállítani a program forráskódjában.
- Teljesítménnyel kapcsolatos szempontok: A program több nagy táblát kapcsol össze, különösen a CDPOS-t és a munkafolyamat-előzményeket tartalmazó táblákat. Csúcsidőben történő futtatása ronthatja a rendszer teljesítményét. Mindig háttérfeladatként, csúcsidőn kívülre ütemezze. Ha rendszeresen lassú a futás, fontolja meg másodlagos adatbázis-indexek létrehozását.
- Előfeltételek: Ehhez a módszerhez ABAP-fejlesztési jogosultságokkal (SE38) rendelkező felhasználó, valamint háttérfeladatok létrehozására és kezelésére jogosult felhasználó szükséges (SM36). A felhasználónak vagy a feladatnak olvasási hozzáféréssel kell rendelkeznie az összes érintett pénzügyi, munkafolyamat- és rendszertáblához (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST stb.).
Példa-lekérdezés abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Lépések
- Adatbázis-kapcsolat létrehozása: Kérjen csak olvasási jogosultságot biztosító hitelesítő adatokat az SAP ECC adatbázishoz. A csatlakozáshoz használjon szabványos SQL-klienst, például DBeavert, SAP HANA Studiót vagy SQL Server Management Studiót.
- Az SQL-lekérdezés előkészítése: Másolja be a dokumentum „query” szakaszában megadott teljes SQL-lekérdezést az SQL-kliensbe.
- Adatkinyerési paraméterek beállítása: Futtatás előtt állítsa be a lekérdezésben szereplő helyőrzőket. Cserélje le a „[START_DATE]” és „[END_DATE]” értékeket a kívánt dátumtartományra „YYYYMMDD” formátumban. A „[COMPANY_CODE_1]” és „[COMPANY_CODE_2]” helyére írja be az elemezni kívánt SAP-vállalatkódokat.
- Forrásrendszer megadása: A fő
SELECTutasításban cserélje le a „[Your SAP System ID]” helyőrzőt a tényleges SAP-rendszerazonosítóra (SID), hogy az adatforrás azonosítása helyes legyen. - A lekérdezés futtatása: Futtassa a beállított SQL-lekérdezést az SAP-adatbázison. A futási idő a dátumtartománytól és az adatbázistáblák méretétől függ.
- Az első eredmények ellenőrzése: A lekérdezés lefutása után gyorsan ellenőrizze a visszaadott sorokat, hogy az adatok a vártnak megfelelően szerepelnek-e. Nézze meg, hogy többféle tevékenység is megjelenik-e, és hogy a fontos mezők, például a
JournalEntryIdés azEventTime, ki vannak-e töltve. - Időbélyegek kezelése: A lekérdezés a dátum- és időmezőket „YYYYMMDDHHMMSS” formátumú karakterlánccá fűzi össze. Ellenőrizze, hogy az utófeldolgozás vagy a célrendszer fel tudja-e dolgozni ezt a formátumot. Ha az adatbázis támogatja, módosítsa az SQL
CONCATfüggvényt ISO 8601 formátumra, például „YYYY-MM-DDTHH:MI:SS” alakra. - Adatok exportálása: Exportálja az SQL-kliens teljes eredményhalmazát CSV-fájlba. A speciális karakterek megőrzése érdekében UTF-8 kódolást használjon.
- Feltöltés előkészítése: Process mining eszközbe történő feltöltés előtt ellenőrizze, hogy az oszlopfejlécek megfelelnek-e az előírt adatsémának. A
JournalEntryId, azActivityNameés azEventTimekötelező mező. Adja hozzá aLastDataUpdateoszlopot, és töltse ki az adatkinyerés időpontjával. - Végső ellenőrzés: Az elemzés megkezdése előtt végezze el a „validationSteps” szakaszban leírt lépéseket, hogy meggyőződjön a kinyert adatok teljességéről és pontosságáról.
Konfiguráció
- Adatbázis-jogosultságok: Az adatbázis-felhasználónak olvasási hozzáférésre van szüksége a következő SAP-táblákhoz: BKPF, BSEG, CDHDR, CDPOS, T001 és V_USERNAME. A munkafolyamathoz kapcsolódó tevékenységekhez az SWW_WI2OBJ és az SWWLOGHIST táblákhoz is hozzáférés kell. Ilyen jogosultságot jellemzően csak a speciális technikai csapatok kapnak.
- Dátumtartomány szerinti szűrés: A lekérdezés megfelelő teljesítményéhez feltétlenül szűrjön megadott dátumtartományra. A lekérdezésben szereplő kezdő- és záródátum-helyőrzők a bizonylat létrehozási dátumára (
BKPF.CPUDT) vonatkoznak. Első elemzéshez 3–6 hónapos időszak javasolt. - Szervezet szerinti szűrés: Az adatmennyiség kezelése és az elemzés fókuszálása érdekében mindig szűrjön vállalatkódra (
BKPF.BUKRS). A bizonylattípusra (BKPF.BLART) is szűrhet, hogy csak a releváns naplóbejegyzés-típusokat vegye figyelembe, például az „SA” főkönyvi bizonylatokat. Ha nem tartoznak az elemzés körébe, zárja ki az olyan operatív bizonylatokat, mint a számlák és a kifizetések. - Teljesítménnyel kapcsolatos szempontok: A központi táblák, például a BSEG és a CDPOS közvetlen lekérdezése jelentős erőforrásokat igényelhet. Az adatkinyerést csúcsidőn kívülre ütemezze, hogy ne rontsa a rendszer teljesítményét a végfelhasználók számára. Egy futtatás során ne nyerjen ki egy évnél hosszabb időszakot.
- Munkafolyamat-feladatazonosítók: A lekérdezés olyan helyőrzőket tartalmaz, mint a „[WF_TASK_ID_SUBMIT]” és a „[WF_TASK_ID_APPROVE]”. Ezeket a rendszer naplóbejegyzési munkafolyamatának tényleges feladatazonosítóira kell cserélni. Az azonosítókat SAP Workflow-szakértő segítségével vagy a PFTC tranzakcióban elérhető technikai munkafolyamat-definíció elemzésével állapíthatja meg.
Példa-lekérdezés sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Lépések
- Kapcsolódás az SAP rendszerhez: A külső ETL-eszközben állítson be új forráskapcsolatot az SAP ECC rendszerhez. Ehhez általában szükség van az alkalmazáskiszolgáló adataira, a kliensre, a rendszerszámra, valamint a szükséges RFC-jogosultságokkal rendelkező, erre a célra létrehozott SAP-felhasználóra.
- Adatforrások megadása: Az adatkinyerési projektben adja hozzá adatforrásként a szükséges SAP-táblákat. A fő táblák: BKPF (számviteli bizonylat fejadatai), BSEG (számviteli bizonylat tételei), VBSEGK (parkolt bizonylat fejadatai), CDHDR (módosítási bizonylat fejadatai), CDPOS (módosítási bizonylat tételei), SWW_WI2OBJ (workflow- és objektumkapcsolatok), SWWLOGHIST (workflow-napló) és SRGBTBREL (GOS-mellékletek kapcsolatai).
- Alapesemények kinyerése (létrehozás és parkolás): Hozzon létre egy adatfolyamot a kezdeti események kinyeréséhez. A „Naplótétel parkolva” eseményhez használja a VBSEGK táblát forrásként. A „Naplótétel létrehozva” eseményhez használja a BKPF táblát, és szűrje ki a sztornóbizonylatokat, valamint azokat, amelyeket először parkoltak. Ehhez végezzen anti-join műveletet a VBSEGK táblával.
- Workflow-események kinyerése: Hozzon létre adatfolyamot, amely a BKPF táblát a SWW_WI2OBJ táblával kapcsolja össze az objektumkulcs alapján (vállalatkód + bizonylatszám + üzleti év), így megkapja a workflow-példány azonosítóját. Kapcsolja össze az eredményt a SWWLOGHIST táblával, és nyerje ki az olyan eseményeket, mint a „Beküldve”, „Jóváhagyva”, „Elutasítva” és „Módosítás kérése”. Ezeket a naplóban rögzített workflow-feladatok eredményei és felhasználói döntések alapján azonosítsa.
- Módosítási és törlési események kinyerése: A módosítások azonosításához használja a CDHDR és CDPOS táblákat. A „Naplótétel javítva” eseményhez szűrje a parkolt bizonylatokon végzett módosításokat (Object Class: 'FIPP'). A „Parkolt naplótétel törölve” eseményhez keresse a parkolt bizonylatok módosítási naplóiban a törlési jelöléseket.
- Mellékletek eseményeinek kinyerése: A „Dokumentáció csatolva” esemény rögzítéséhez kapcsolja össze a BKPF táblát az SRGBTBREL táblával, ahol az objektumtípus 'BKPF', a kapcsolat pedig '[Your attachment relationship type]'. A kapcsolat létrehozásának dátuma lesz az esemény időpontja.
- Kiegyenlítési és sztornóesemények kinyerése: A „Naplótétel kiegyenlítve” eseményhez kérdezze le a BSEG táblát, és keresse azokat a sorokat, amelyekben a kiegyenlítő bizonylat mezője (AUGBL) ki van töltve. Az esemény időpontja a kiegyenlítő bizonylat könyvelési dátuma (AUGDT). A „Naplótétel sztornózva” eseményhez kérdezze le a BKPF táblát, és a sztornóbizonylatokat a sztornózott bizonylat mezőjének (STBLG) kitöltött értéke alapján azonosítsa.
- Számított események meghatározása: Hozzon létre külön logikai blokkokat a számított eseményekhez. A „Kézi könyvelés azonosítva” eseményhez szűrje a BKPF táblát a kézi tranzakciók listája alapján, például FB01, FB50, F-02. A „Vállalatközi könyvelés azonosítva” eseményhez csoportosítsa a BSEG táblát bizonylatazonosító szerint, és keresse azokat a bizonylatokat, amelyeknél egynél több különböző vállalatkód szerepel.
- Eseményfolyamok egyesítése: Az ETL-eszköz UNION átalakításával egyesítse az egyes eseményfolyamok (létrehozás, parkolás, jóváhagyás stb.) eredményét egyetlen eseménynapló-táblába. Minden adatfolyamban egyezzenek az oszlopnevek és az adattípusok.
- Leképezés a végleges sémára: A kombinált adatokat képezze le a szükséges eseménynapló-struktúrára. Hozza létre a
JournalEntryId,ActivityName,EventTime,Felhasználóés a többi szükséges, illetve ajánlott attribútum mezőit. Adjon hozzá statikus oszlopokat, példáulSourceSystemmezőt, aLastDataUpdateértékéhez pedig használja az ETL-feladat futtatási idejét. - Növekményes betöltés beállítása: A rendszeres adatkinyeréshez állítson be növekményes betöltést. Vízjelként használja az utolsó létrehozási vagy módosítási dátumot, például a BKPF.CPUDT vagy a CDHDR.UDATE mezőt, így csak az utolsó futás óta létrehozott vagy módosított rekordokat tölti le.
- Exportálás a ProcessMind számára: Ütemezze az adatkinyerési feladatot, és állítsa be a végső kimeneti lépést úgy, hogy az eseménynaplót CSV- vagy Parquet-fájlként mentse a ProcessMind számára elérhető helyre, ahonnan feltöltheti.
Konfiguráció
- Előfeltételek: Licenccel rendelkező külső ETL-eszköz (például Theobald Xtract Universal, Informatica vagy Talend), dedikált SAP-csatlakozóval. Szükség van továbbá RFC-hozzáféréssel rendelkező SAP-felhasználói fiókra, amely jogosult a pénzügyi táblák (például az F_00 és F_WF táblacsoportok az S_TABU_DIS jogosultsággal), a workflow-adatok és a módosítási naplók olvasására.
- Kapcsolati paraméterek: Szüksége lesz az SAP Application Server IP-címére vagy állomásnevére, a rendszerszámra és a kliensazonosítóra. Az SAP-felhasználónév és -jelszó tárolásához használjon biztonságos hitelesítőadat-kezelést.
- Fő szűrők: A forrásnál mindig szűrjön a vállalatkódra (BKPF.BUKRS) és az üzleti évre (BKPF.GJAHR), hogy korlátozza az adatmennyiséget. Erősen ajánlott a bizonylat létrehozási dátumára (BKPF.CPUDT) is szűrni, és így megadni az adatkinyerés időszakát, például az utolsó 6 hónapot.
- Dátumtartomány kiválasztása: A kezdeti betöltéshez válasszon reprezentatív időszakot, például 3–6 hónapot. A későbbi delta betöltéseknél használjon vízjelet egy időbélyegmezőn, például a
CPUDTmezőn, hogy csak az új rekordokat kérje le. - Teljesítménnyel kapcsolatos szempontok: A BSEG, CDPOS és workflow-táblák összekapcsolása nagyon lassú lehet. Ha lehetséges, állítsa be az ETL-eszközt úgy, hogy a szűrőket az SAP-forrásnál hajtsa végre. Ha az eszköz támogatja, kisebb csomagokban nyerje ki az adatokat, különösen nagy mennyiségű előzményadat betöltésekor.
- Workflow testreszabása: Az olyan tevékenységek azonosításához szükséges logika, mint az „Approved” vagy a „Rejected”, nagymértékben függ az Önök workflow-sablonjaitól. A szűréshez meg kell keresnie a rendszerben a megfelelő workflow-feladatazonosítókat és a felhasználói döntések kulcsait.
Példa-lekérdezés sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Kezdje el most?
Ezzel az adatsablonnal gyorsan elindíthatja a Record to Report - Journal Entry folyamat process mining elemzését. Szerezzen részletesebb képet, és javítsa a pénzügyi működés hatékonyságát.
Fejlessze most a Record to Report - Journal Entry folyamatot
Csökkentse 30%-kal a naplóbejegyzések átfutási idejét, és gondoskodjon a pontos beszámolásról.
Nincs szükség bankkártyára, kezdje el még ma a fejlesztést.