Adatsablon a beszerzéstől a fizetésig tartó számlafeldolgozáshoz
Adatsablon a beszerzéstől a fizetésig tartó számlafeldolgozáshoz
- Javasolt attribútumok
- Követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez SAP S/4HANA rendszerből
A beszerzéstől a fizetésig tartó számlafeldolgozás attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Számlaszám InvoiceNumber | A szállítói számlabizonylat egyedi azonosítója, amely a folyamat elsődleges esetazonosítójaként szolgál. | ||
| Leírás A számlaszám minden szállítói számlához egyedi azonosítót rendel az SAP S/4HANA rendszerben. Összekapcsolja a számlához tartozó tevékenységeket, például a létrehozást, az előzetes rögzítést, a jóváhagyást és a fizetést, így egyetlen folyamatpéldányként követhetők. A process mining során ez az attribútum alapvető a számlák teljes útjának követéséhez. Segítségével a beérkezéstől a végső kifizetésig rekonstruálható a teljes folyamat, így számlánként elemezhetők az átfutási idők, a szűk keresztmetszetek és a folyamat eltérései. Miért fontos? Ez az alapvető azonosító kapcsolja össze az összes kapcsolódó eseményt, így a számla teljes életútja végigkövethető a rendszerben. Hol szerezhető be? Ez a könyvelési bizonylat száma, amely a BKPF tábla BELNR mezőjében található. Példák 190000000119000000451900000132 | |||
| Esemény időpontja EventTime | Az esemény bekövetkezésének pontos dátuma és időpontja. | ||
| Leírás Az esemény időpontja az az időbélyeg, amely pontosan rögzíti, mikor történt egy adott tevékenység. Erre az adatra van szükség a folyamatlépések közötti időtartam, átfutási idő és várakozási idő kiszámításához. A process mining elemzés során a pontos időbélyegek alapján mérhetők a teljesítményre vonatkozó KPI-k, például az „Átlagos számla-átfutási idő” és a „Számlajóváhagyás átfutási ideje”. A tevékenységek között eltelt idő elemzésével a szervezet megállapíthatja, hol késnek a számlák, és hol gyorsítható a folyamat. Miért fontos? Ez az időbélyeg alapozza meg az időalapú elemzéseket, többek között a teljesítmény nyomon követését, a szűk keresztmetszetek azonosítását és az SLA-k követését. Hol szerezhető be? Az adat jellemzően a CDHDR (fejléc) és CDPOS (tétel) módosítási bizonylattáblák UDATE és UTIME mezőiből származik. Egyes eseményeknél a BKPF táblában szereplő létrehozási vagy rögzítési dátumok és időpontok (CPUDT, CPUTM) is használhatók. Példák 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Tevékenység neve ActivityName | A számlával egy adott időpontban történt üzleti tevékenység vagy esemény neve. | ||
| Leírás A tevékenység neve a számlafeldolgozás egy adott lépését vagy státuszváltozását írja le. Ilyen például a „Számlabizonylat létrehozva”, a „Számla jóváhagyásra elküldve”, a „Fizetési zárolás beállítva” és a „Fizetés végrehajtva”. Ez az attribútum a folyamattérkép elkészítésének alapja, amely vizuálisan mutatja be a tevékenységek menetét. A tevékenységek sorrendjének, gyakoriságának és időtartamának elemzésével azonosíthatók a szűk keresztmetszetek, az ismételt munkát okozó körök és a megfeleléstől eltérő folyamatváltozatok. A process mining elemzés erre épül. Miért fontos? Meghatározza a folyamat lépéseit, így megjeleníthetők a folyamattérképek, és elemezhetők a folyamatok menete és eltérései. Hol szerezhető be? Az SAP-tranzakciókódok (SY-TCODE), a módosítási bizonylatok objektumstátuszai (CDHDR/CDPOS), valamint a státuszváltozást jelző mezőértékek kombinációjából származik. Példák Számla parkolásaSzámla jóváhagyásaFizetés végrehajtva | |||
| Bizonylattípus DocumentType | A könyvelési bizonylatok típusát jelölő kód, például szállítói számla vagy jóváíró bizonylat. | ||
| Leírás Az SAP-ban a bizonylattípus különbözteti meg az egyes üzleti tranzakciókat. A „KR” például általában standard szállítói számlát jelöl, a „KG” pedig szállítói jóváíró bizonylatot. A bizonylattípus szerinti elemzéssel külön vizsgálhatók az eltérő tranzakciótípusok. A jóváíró bizonylatok folyamata például jelentősen eltérhet a standard számlákétól. Ez a bontás pontosabb és relevánsabb eredményeket ad. Miért fontos? Segít megkülönböztetni a különféle pénzügyi tranzakciókat, például a standard számlákat és a jóváíró bizonylatokat, amelyek gyakran eltérő folyamaton mennek végig. Hol szerezhető be? A BKPF bizonylatfejléc-tábla BLART mezőjében található. Példák KRREKG | |||
| Felhasználónév UserName | Annak a személynek vagy rendszernek az SAP-felhasználói azonosítója, amely a tevékenységet végrehajtotta. | ||
| Leírás Ez az attribútum azonosítja azt a felhasználót, aki végrehajtott egy tranzakciót vagy létrehozott egy bizonylatot. Lehet egy személy felhasználói azonosítója vagy automatizált kötegelt feladatok rendszerazonosítója. A felhasználók szerinti elemzés segít megérteni a munkaterhelés eloszlását, feltárni a képzési igényeket és észrevenni a szokatlan felhasználói viselkedést. Például megmutathatja, kik kezelik gyakran a kivételeket, illetve mely számlákat dolgozza fel automatikusan a rendszer, például a „BATCHUSER” felhasználó. Ez fontos az „Automatizált számlafeldolgozás aránya” KPI kiszámításához. Miért fontos? A folyamat tevékenységeit konkrét felhasználókhoz vagy rendszerfiókokhoz rendeli, így elemezhető a munkaterhelés, összehasonlítható a teljesítmény és felismerhető az automatizálás. Hol szerezhető be? Például a BKPF-USNAM (Rögzítette) vagy a CDHDR-USERNAME (Módosította) mezőből származik. Példák SMITHJMUELLERTWF-BATCH | |||
| Fizetési esedékesség dátuma PaymentDueDate | Az a dátum, ameddig a számlát ki kell fizetni, hogy ne legyen lejárt tartozás. | ||
| Leírás A fizetési esedékesség dátuma az a kiszámított dátum, ameddig a szállítónak fizetni kell. A számla dátuma és a megállapodott fizetési feltételek alapján határozzák meg, és fontos határidő a folyamatban. Ez az attribútum szükséges a „Határidőre történő fizetések aránya” KPI-hoz és a „Szállítói fizetési teljesítmény” dashboardhoz. A tényleges fizetési dátum és az esedékesség összehasonlításával a vállalat mérheti, mennyire teljesíti időben fizetési kötelezettségeit. Ez a szállítói kapcsolatokat és a pénzügyi megítélést is befolyásolja. Miért fontos? Ez a határidőre történő fizetés elsődleges mércéje, ami segít fenntartani a jó szállítói kapcsolatokat és elkerülni a késedelmi díjakat. Hol szerezhető be? Ez a dátum gyakran közvetlenül elérhető a BSEG tábla szállítói tételében, a ZFBDT mezőben (az esedékesség számításának alapdátuma). A nettó esedékességi dátumot ebből az alapdátumból és a fizetési feltételekből számítják. Példák 2023-05-302023-06-152023-07-01 | |||
| Fizetési zárolás oka PaymentBlockReason | A számla fizetésének zárolási okát jelölő kód. | ||
| Leírás Ha a számla fizetését zárolják, ez az attribútum megadja a zárolás konkrét okát, például „Mennyiségi eltérés” vagy „Áreltérés”. Az SAP-ban beállított okok egységesítik a kivételek kezelését. Ez az attribútum szükséges a „Fizetési zárolások előfordulása és időtartama” dashboardhoz. A különböző okok gyakoriságának elemzésével feltárhatók a fizetési késedelmek kiváltó okai, például egyes szállítókkal, anyagokkal vagy belső folyamatokkal kapcsolatos problémák. Így célzott korrekciós intézkedések hozhatók. Miért fontos? Megadja a fizetési zárolások konkrét kiváltó okát, így célzottan elemezhetők a késedelmek, és javítható az elsőre helyes feldolgozás aránya. Hol szerezhető be? A BSEG tábla szállítói tételében, a ZLSPR mezőben található (fizetési zárolás kulcsa). Példák RIA | |||
| Megrendelés PurchasingDocument | Annak a megrendelésnek a száma, amelyhez a számla kapcsolódik. | ||
| Leírás A beszerzési bizonylat száma összekapcsolja a szállítói számlát az eredeti megrendeléssel (PO). Ez a kapcsolat alapvető a háromutas egyeztetéshez, amely a számlát a megrendeléssel és az áruátvétellel veti össze. Az attribútum szerinti elemzés segít megérteni a megrendeléshez kapcsolódó és az ahhoz nem kapcsolódó számlák közötti eltéréseket. Fontos az egyeztetési problémák feltárásához és a folyamat beszerzési részének hatékonyságvizsgálatához. Miért fontos? Összekapcsolja a számlát a beszerzési folyamattal, ami segít az egyeztetési eltérések és a megrendelésekre vonatkozó megfelelés elemzésében. Hol szerezhető be? Ez az adat jellemzően a BSEG bizonylattétel-tábla EBELN mezőjében található (beszerzési bizonylat száma). Példák 450000123445000056784500009012 | |||
| Szállítói szám VendorNumber | A számlát benyújtó szállító egyedi azonosítója. | ||
| Leírás A szállítói szám azonosítja a számlához tartozó szállítót vagy hitelezőt. Összekapcsolja a számlatranzakciót a szállítói törzsadatokkal. Ez az attribútum alapvető a szállítók szerinti elemzéshez, például a „Szállítói fizetési teljesítmény” értékeléséhez vagy a gyakran problémás, kivételt vagy fizetési zárolást okozó számlákat benyújtó szállítók azonosításához. Segít a szállítói kapcsolatok kezelésében és a beszállítók megbízhatóságának felmérésében. Miért fontos? Lehetővé teszi a folyamat teljesítményének szállítók szerinti elemzését, így feltárhatók a mintázatok, kezelhetők a kapcsolatok és azonosíthatók a beszállítókkal kapcsolatos problémák. Hol szerezhető be? Jellemzően a BSEG könyvelési bizonylattétel-tábla LIFNR mezőjében található. Példák 100345700012V9832 | |||
| Számla összege AmountInCompanyCodeCurrency | A számla teljes bruttó összege a vállalatkód helyi pénznemében. | ||
| Leírás Ez az attribútum a számla teljes értékét mutatja. Segít felmérni a számlafeldolgozás pénzügyi hatását és volumenét. Az összegek elemzésével előre vehetők a nagy értékű számlák, feltárhatók a költési trendek, és összevethetők a folyamatproblémák a pénzügyi értékkel. Például megvizsgálható, hogy a nagy értékű számlákat gyakrabban zárolják-e, vagy tovább tart-e a jóváhagyásuk. Miért fontos? Pénzügyi szempontból is értelmezhetővé teszi a folyamatot, így az összegek alapján is elemezhető, például hogy a nagy értékű számlák feldolgozása eltér-e a többiétől. Hol szerezhető be? Az érték jellemzően a BSEG tábla megfelelő tételeinek összegéből származik, a WRBTR mezőből (összeg helyi pénznemben). Példák 1500.75125000.00850.20 | |||
| Vállalatkód CompanyCode | Az a szervezeti egység, amely önálló jogi személyt képvisel, és amelyről pénzügyi kimutatások készülnek. | ||
| Leírás A vállalatkód az SAP Finance egyik alapvető szervezeti egysége. Minden számlához egy vállalatkód tartozik, amely meghatározza az ügyletért felelős jogi személyt. A process mining során a vállalatkód szerinti szűrés és összehasonlítás segít elemezni a folyamatok teljesítményét az egyes üzleti egységekben, jogi személyeknél vagy országokban. Feltárja a hatékonyság, a megfelelés és az automatizáltság regionális eltéréseit, így célzott folyamatfejlesztési intézkedések hozhatók. Miért fontos? Lehetővé teszi a számlafeldolgozás teljesítményének bontását és összehasonlítását a szervezet különböző jogi személyei vagy földrajzi területei között. Hol szerezhető be? A BKPF bizonylatfejléc-tábla szabványos mezője, neve BUKRS. Példák 1000US01DE01 | |||
| Adatkinyerés időpontja ExtractionTimestamp | Az adat forrásrendszerből történő kinyerésének dátuma és időpontja. | ||
| Leírás Ez az attribútum rögzíti az adatkinyerés időpontját. Megmutatja, mennyire frissek a process mining eszközben elemzett adatok. Az elemzés során segít megállapítani, milyen frissek a létrehozott eredmények. A működés nyomon követésére szolgáló dashboardoknál fontos, hogy a döntések naprakész információkra épüljenek, és az adatfrissítési ciklusok is megfelelően kezelhetők legyenek. Miért fontos? Jelzi az adatok frissességét, így az elemzés és a jelentések a rendelkezésre álló legaktuálisabb információkra épülnek. Hol szerezhető be? Ez nem SAP-mező. Az adatkinyerő eszköz vagy az ETL-folyamat hozza létre és adja hozzá az adatok lekérésekor. Példák 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Automatizált? IsAutomated | Jelzi, hogy a tevékenységet automatizált rendszerfelhasználó hajtotta-e végre. | ||
| Leírás Ez a logikai attribútum akkor igaz, ha a tevékenységhez ismert rendszer- vagy kötegelt fiók tartozik, például „WF-BATCH” vagy „SAP_SYSTEM”. Segít megkülönböztetni a manuális és az automatizált folyamatlépéseket. Ez az attribútum szükséges az „Automatizált számlafeldolgozás aránya” KPI kiszámításához. Az automatizált folyamatlépések elemzésével a szervezet felmérheti az automatizálási kezdeményezések eredményét, és további lehetőségeket találhat a manuális munka csökkentésére és a hatékonyság javítására. Miért fontos? Megkülönbözteti a manuális és a rendszer által végzett tevékenységeket. Ez alapvető az automatizálás arányának méréséhez és a további automatizálási lehetőségek feltárásához. Hol szerezhető be? A UserName attribútumból származik. Leképezés vagy szabály alapján sorolják az egyes felhasználói azonosítókat az „automatizált” kategóriába. Példák truefalse | |||
| Fizetési feltételek PaymentTerms | A szállítóval egyeztetett fizetési feltételeket, például az esedékességet és a kedvezményes időszakot meghatározó kód. | ||
| Leírás A fizetési feltételek határozzák meg a számla kiegyenlítésének szabályait, beleértve az esetleges korai fizetési kedvezményeket. A „Z030” például azt jelentheti, hogy a számlát nettó 30 napon belül kell kifizetni. Ez az attribútum szükséges a pénzügyi tervezéshez és a forgótőke hatékony kezeléséhez. A process mining során a „Fizetési esedékesség dátuma” kiszámítására és a korai fizetési kedvezményekre való jogosultság meghatározására használják, így közvetlenül támogatja a „Korai fizetési kedvezmények igénybevételi aránya” KPI-t. Miért fontos? Meghatározza a fizetési esedékesség és a kedvezmények szabályait, így közvetlenül befolyásolja a határidőre történő fizetés KPI-jait és a forgótőke kezelését. Hol szerezhető be? A BSEG tábla szállítói tételében, a ZTERM mezőben található (fizetési feltételek kulcsa). Példák 0001Z030NT60 | |||
| Forrásrendszer-azonosító SourceSystemId | Annak az SAP S/4HANA forrásrendszernek az azonosítója, amelyből az adatokat kinyerték. | ||
| Leírás Ez az attribútum jelöli az adat forrásrendszerét, például „S4H_PROD” vagy „ERP_EU”. Különösen fontos, ha a szervezet több ERP-példányt vagy régi és modern rendszereket használ. Az elemzés során lehetővé teszi a folyamatok teljesítményének összehasonlítását a különböző rendszerekben vagy régiókban. Segít igazolni az adatok eredetét, és nélkülözhetetlen az adatirányításhoz, valamint a hibakereséshez, ha több forrás adatait egy központi process mining platformon egyesítik. Miért fontos? Megmutatja az adatok eredetét, ami nélkülözhetetlen az adatirányításhoz és a különböző rendszerekben vagy telephelyeken zajló folyamatok összehasonlításához. Hol szerezhető be? Az érték általában az SAP rendszerazonosítójából (sy-sysid) származik az adatkinyerés során, vagy statikus értékként állítják be az ETL-folyamatban. Példák S4PS4H_PROD_100ECC_EU | |||
| Határidőre fizetve? IsPaidOnTime | Akkor igaz, ha a számlát a fizetési esedékesség napján vagy korábban fizették ki. | ||
| Leírás Ez a logikai attribútum a tényleges fizetési dátum, vagyis a „Fizetés végrehajtva” tevékenység időbélyegének és a „Fizetési esedékesség dátumának” összehasonlításából adódik. Egyértelműen jelzi minden számla fizetési státuszát. Ez a „Határidőre történő fizetések aránya” KPI alapja. Segítségével egyszerűen szűrhetők és elemezhetők a késedelmes fizetések jellemzői, például a gyakran érintett szállítók, vállalatkódok vagy számlaösszegek. Miért fontos? Közvetlenül méri a fizetési feltételek betartását, ami fontos KPI a szállítói kapcsolatok kezelésében és a pénzügyi működésben. Hol szerezhető be? A „Fizetés végrehajtva” tevékenység EventTime értékének és a PaymentDueDate attribútumnak az összehasonlításával számítható ki. (Fizetés dátuma <= PaymentDueDate). Példák truefalse | |||
| Ismételt munka történt? IsRework | Jelzi, hogy a számlánál történt-e ismételt munkát igénylő tevékenység, például elutasították-e a jóváhagyást vagy feloldották-e a fizetési zárolást. | ||
| Leírás Ez az attribútum megjelöli azokat a számlákat, amelyeknél egy vagy több ismételt munkával járó folyamatkör fordult elő. Ilyen például, ha a „Számla jóváhagyva” eseményt megelőzte a „Számla elutasítva”, vagy ha a „Fizetési zárolás feloldva” eseményt a „Fizetési zárolás beállítva” előzte meg. Az attribútum egyszerűsíti a „Számlák ismételt feldolgozásának aránya” KPI kiszámítását. Az elemzők könnyen elkülöníthetik és megvizsgálhatják az ismételt munkát igénylő eseteket, hogy feltárják a hatékonyságvesztés és a többszöri manuális munka okait. Miért fontos? Azonosítja azokat a nem hatékony folyamatokat, amelyekben meg kell ismételni a munkát. Segít számszerűsíteni a veszteséget és feltárni a folyamatkivételek kiváltó okait. Hol szerezhető be? Az eseménynaplóban szereplő tevékenységek sorrendje alapján számítható ki. Ha például egy számla eseménysorában szerepel a „Számla elutasítva”, ez a jelző igaz értéket kap. Példák truefalse | |||
| Jóváhagyási ciklusok száma ApprovalCycleCount | Azt mutatja meg, hányszor küldték jóváhagyásra a számlát. | ||
| Leírás Ez a mutató megszámolja, hányszor fordul elő egy számlánál a „Számla jóváhagyásra elküldve” tevékenység. Az egynél nagyobb érték azt jelzi, hogy a számlát legalább egyszer elutasították vagy visszaküldték, ezért újabb jóváhagyási ciklusra volt szükség. Ez az attribútum közvetlenül támogatja az „Első körös jóváhagyás aránya” KPI-t. A sok jóváhagyási cikluson áteső számlák elemzésével feltárhatók az elutasítások okai, például a hiányos adatok vagy a hibás kódolás, és javítható a folyamat. Miért fontos? Számszerűsíti az ismételt munkát a jóváhagyási alfolyamatban, így mérhető az elsőre helyes feldolgozás aránya, és feltárhatók a jóváhagyás elutasításának okai. Hol szerezhető be? Az egyes egyedi InvoiceNumber értékekhez tartozó „Számla jóváhagyásra elküldve” tevékenységek előfordulásainak megszámolásával számítható ki. Példák 123 | |||
| Kiegyenlítési bizonylat száma. ClearingDocumentNumber | Annak a bizonylatnak a száma, amellyel a számlát kiegyenlítik, általában a fizetési bizonylat száma. | ||
| Leírás A kiegyenlítési bizonylat száma összekapcsolja a nyitott számlatételt az azt kiegyenlítő tranzakcióval, amely szinte mindig a fizetési bizonylat. Ez igazolja, hogy a számlát kifizették. Ez az attribútum teremti meg a közvetlen kapcsolatot a számla és a fizetése között. A „Fizetés végrehajtva” tevékenység és a hozzá tartozó időbélyeg azonosítására használható, ami szükséges a teljes átfutási idő és a határidőre történő fizetések arányának kiszámításához. Miért fontos? Igazolja, hogy a számlát kifizették, és összekapcsolja a konkrét fizetési tranzakcióval. Ez fontos az átfutási idő és a fizetési teljesítmény elemzéséhez. Hol szerezhető be? A BSEG bizonylattétel-tábla AUGBL mezőjében található (kiegyenlítési bizonylat száma). Példák 150000000115000000231500000088 | |||
| Számla dátuma InvoiceDate | A dátum, amikor a szállító kiállította a számlát. | ||
| Leírás A számla dátuma, más néven bizonylatdátum, a szállító által a számlán feltüntetett dátum. A megállapodott fizetési feltételek alapján ebből számítják ki a fizetési esedékesség dátumát. Az elemzésben ez a dátum alapvető a pénzügyi számításokhoz, például a számlák korának és a korai fizetési kedvezményre való jogosultságnak a meghatározásához. A „Korai fizetési kedvezmények igénybevételi aránya” KPI egyik fontos bemenő adata. Miért fontos? Ez az alapja a fizetési feltételek és az esedékességi dátumok számításának, ami segít a forgótőke kezelésében és a kedvezmények igénybevételében. Hol szerezhető be? A BKPF bizonylatfejléc-tábla BLDAT mezőjében található (bizonylat dátuma). Példák 2023-04-122023-05-152023-06-20 | |||
| Visszafordítás oka ReversalReason | A számlabizonylat visszafordításának okát jelölő kód. | ||
| Leírás Ha egy számlát hibásan könyvelnek, gyakran visszafordítják. A visszafordítás oka kód megadja, miért történt ez, például „Hibás könyvelési dátum” vagy „Adatrögzítési hiba”. A visszafordítási okok elemzésével feltárhatók a számlakönyvelés során ismétlődő hibák. Az eredmények alapján javítható a képzés, erősíthetők a rendszerellenőrzések, illetve kezelhetők a pénzügyi újramunkát és adminisztratív többletterhet okozó visszatérő problémák. Miért fontos? Megmutatja, miért érvénytelenítették a számlákat, így közvetlenül feltárhatók a könyvelési folyamat hibái és az ismételt munka okai. Hol szerezhető be? Az eredeti bizonylat BKPF táblabeli fejlécében, az STGRD mezőben található (visszafordítás oka). Példák 010205 | |||
A beszerzéstől a fizetésig tartó számlafeldolgozás tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Fizetés végrehajtva | Ez a standard folyamat utolsó tevékenysége: ekkor történik meg a fizetés, és ekkor vezetik ki a számlát. Ez jelzi, hogy az összeget átutalták a szállítónak. | ||
| Miért fontos? Ezzel lezárul a P2P-számla teljes életciklusa. Az esemény szükséges a teljes átfutási idő kiszámításához és a határidőre történő fizetés méréséhez. Hol szerezhető be? Az esemény a szállítói tétel kiegyenlítési bizonylatának adataiból állapítható meg. A kiegyenlítési dátum (BSEG-AUGDT) és a kiegyenlítési bizonylat (BSEG-AUGBL) jelzi, hogy a fizetés megtörtént. Rögzítés A kiegyenlített szállítói tétel kiegyenlítési dátumát (BSEG-AUGDT) használja. Eseménytípus explicit | |||
| Számla jóváhagyása | Ez a tevékenység azt jelzi, hogy az illetékes jóváhagyta a számlát. Akkor rögzíthető, amikor a jóváhagyási munkafolyamat sikeresen lezárul, vagy beállítják a felszabadítási jelzőt. | ||
| Miért fontos? Ez fontos mérföldkő, mert ezután a számla kifizethetővé válik. A jóváhagyási késések gyakori szűk keresztmetszetet jelentenek, ezért ennek a tevékenységnek a követése segít megtalálni a lassan dolgozó jóváhagyókat vagy a késést okozó lépéseket. Hol szerezhető be? Az esemény az SAP-munkafolyamat utolsó felszabadítási lépéséből következtethető ki, vagy a számlához, illetve a kapcsolódó beszerzési bizonylathoz tartozó táblák felszabadítási állapotmezőinek változásával követhető nyomon. Rögzítés Következtessen rá a munkafolyamat lezárását jelző eseményekből vagy a bizonylat felszabadítási állapotmezőjének változásából. Eseménytípus inferred | |||
| Számla könyvelése | Ez fontos pénzügyi esemény: a parkolt vagy jóváhagyott számlát hivatalosan lekönyvelik a főkönyvbe. Ezzel elismerik a szállítóval szembeni kötelezettséget. | ||
| Miért fontos? A könyvelés fontos mérföldkő: lezárja az adatrögzítést és a jóváhagyást, és elindítja a pénzügyi rendezést. A számla létrehozásától a könyvelésig eltelt idő jól mutatja a belső feldolgozás hatékonyságát. Hol szerezhető be? Az eseményt a bizonylat fejlécében szereplő könyvelési dátum (BKPF-BUDAT) azonosítja. Ha a bizonylatot először előzetesen rögzítik, az esemény időpontját az jelzi, amikor a státusza könyveltre változik. Rögzítés Az esemény időpontjaként a könyvelési dátumot (BKPF-BUDAT) használja. Eseménytípus explicit | |||
| Számla visszafordítva | Ez a tevékenység egy korábban könyvelt számlabizonylat visszafordítását jelöli. Hibás számla esetén ez lezáró esemény, amelyet gyakran a számla helyes újbóli rögzítése követ. | ||
| Miért fontos? A visszafordítás olyan súlyos hibára utal, amelyet a folyamat korábbi szakaszában nem vettek észre. Gyakoriságának és kiváltó okainak követése segíti a folyamatfejlesztést és a pénzügyi pontatlanságok csökkentését. Hol szerezhető be? Visszafordításról akkor beszélünk, ha létrejön egy visszafordító bizonylat. Az eredeti bizonylat fejlécében (BKPF) szerepel a visszafordító bizonylat száma (BKPF-STBLG), és fordítva. Az esemény időpontja a visszafordító bizonylat könyvelési dátuma. Rögzítés Keresse meg azokat a bizonylatokat, amelyeknél a BKPF-STBLG mező értéket tartalmaz, és használja a visszafordító bizonylat könyvelési dátumát. Eseménytípus explicit | |||
| Számlabizonylat létrehozása | Ez az első esemény, amely a számlabizonylat létrehozását jelzi az SAP rendszerben. Akkor rögzíthető, amikor a felhasználó elment egy új számlabizonylatot, amely lehet parkolt vagy még nem könyvelt állapotban. | ||
| Miért fontos? Ez a tevékenység jelöli a számlafeldolgozás kezdetét. Az esemény és a későbbi események közötti idő mérése alapvető a teljes feldolgozási átfutási idő meghatározásához. Hol szerezhető be? Az esemény a bizonylat fejlécét tartalmazó táblában szereplő létrehozási dátum és idő alapján rögzíthető: ezek a CPUDT és CPUTM mezők, jellemzően a BKPF vagy logisztikai számlák esetén az RBKP táblában. A tranzakciókód, például a BKPF-TCODE mezőben szereplő FB60, MIRO vagy MIR7, megmutatja a létrehozás módját. Rögzítés Használja a számlabizonylat BKPF-CPUDT és BKPF-CPUTM mezőiben szereplő létrehozási időbélyeget. Eseménytípus explicit | |||
| Fizetési javaslat létrehozva | A számlát kiválasztják, majd egy fizetési futás részeként felveszik a fizetési javaslatba. Ez az automatizált fizetési folyamat első lépése. | ||
| Miért fontos? Ez a tevékenység jelzi a fizetési szándékot. A lépés és a tényleges fizetés között eltelt időből kiderülhet, ha probléma van a fizetési futással, a jóváhagyásokkal vagy a banki kommunikációval. Hol szerezhető be? A fizetési futás tábláiban található meg, különösen a REGUP táblában, amely a fizetési javaslatba felvett tételeket tartalmazza. Az időbélyeget a kapcsolódó REGUH tábla futási dátuma adja. Rögzítés Azonosítsa, mikor jelenik meg a számla a fizetési javaslat futásához tartozó REGUP táblában. Eseménytípus explicit | |||
| Fizetési zárolás beállítása | A számlára szándékosan fizetési zárolást állítanak be, hogy megakadályozzák a kifizetését. Ennek oka gyakran ár- vagy mennyiségi eltérés, illetve egy függőben lévő jóváíró számla. | ||
| Miért fontos? A fizetési zárolások gyakran okoznak késedelmes kifizetést és szállítói vitát. A zárolások gyakoriságának, időtartamának és okainak elemzése fontos a határidőre történő kifizetések arányának javításához. Hol szerezhető be? Az esemény a számlatétel fizetési zárolási kulcsának, vagyis a BSEG-ZLSPR mezőnek a változásával rögzíthető. A CDHDR és CDPOS változásnaplók megadják a zárolás beállításának időpontját és a műveletet végző felhasználót. Rögzítés Azonosítsa, mikor kap értéket a BSEG-ZLSPR mező, a változásbizonylatok (CDHDR/CDPOS) alapján. Eseménytípus explicit | |||
| Fizetési zárolás feloldása | Egy probléma megoldását jelzi: a korábban beállított fizetési zárolást feloldják, így a számla ismét kifizethetővé válik. | ||
| Miért fontos? A zárolás beállítása és feloldása között eltelt idő a folyamatkivétel megoldási idejét mutatja. Ennek csökkentése javítja a hatékonyságot és a szállítói kapcsolatokat. Hol szerezhető be? Az esemény akkor rögzíthető, amikor törlik a fizetési zárolási kulcsot tartalmazó BSEG-ZLSPR mező értékét. A módosítást a CDHDR és CDPOS táblák naplózzák, így a feloldás időpontja is meghatározható. Rögzítés Azonosítsa, mikor törlik a BSEG-ZLSPR mező értékét, a változásbizonylatok (CDHDR/CDPOS) alapján. Eseménytípus explicit | |||
| Késedelmes fizetés végrehajtva | Ez egy számított esemény, amely akkor következik be, ha a számlát a kiszámított esedékességi dátum után fizetik ki. Két dátummező összehasonlításával állapítható meg. | ||
| Miért fontos? Ez a tevékenység közvetlenül támogatja a határidőre történő fizetés KPI-jainak mérését. Segít azonosítani azokat a szállítókat vagy üzleti egységeket, ahol gyakori a késedelmes fizetés, ami ronthatja a szállítói kapcsolatokat és kötbérhez vezethet. Hol szerezhető be? A kiegyenlítési dátum (BSEG-AUGDT) és a nettó esedékességi dátum összehasonlításával számítható ki. Az esedékességi dátum az alapdátumból (BSEG-ZFBDT) és a fizetési feltételekből (BSEG-ZTERM) számítható. Rögzítés A BSEG-AUGDT > (BSEG-ZFBDT + fizetési határidő napokban) feltétel összehasonlításával állapítható meg. Eseménytípus calculated | |||
| Számla elutasítása | A számla elutasítása a jóváhagyási folyamat során. Ez ismételt munkát tesz szükségessé: a számlát javítani, majd újra be kell nyújtani. | ||
| Miért fontos? A számlaelutasítás a folyamat hatékonysági problémáinak és az adatok minőségi hiányosságainak fontos jelzője. Az elutasítások gyakoriságának és okainak elemzése segít megtalálni a fejlesztési és képzési lehetőségeket. Hol szerezhető be? Az esemény az SAP-munkafolyamat megfelelő állapotváltozásából, például az „elutasítva” állapotból következtethető ki. Az is jelezheti, ha egy esemény megszakítja az aktuális jóváhagyási munkafolyamatot, és visszaküldi a számlát feldolgozásra. Rögzítés Következtessen rá az elutasítást jelző munkafolyamat-állapotváltozásokból. Eseménytípus inferred | |||
| Számla jóváhagyásra küldése | Ez a tevékenység jelzi a számla hivatalos jóváhagyási munkafolyamatának elindítását. Erre gyakran a számla „jóváhagyásra vár” állapotából vagy egy munkafolyamat-elem létrehozásából lehet következtetni. | ||
| Miért fontos? Ez a jóváhagyási ciklusidő mérésének kezdőpontja. A jóváhagyás kezdetének ismerete segít megtalálni magában a jóváhagyási munkafolyamatban lévő szűk keresztmetszeteket. Hol szerezhető be? Az esemény jellemzően a számlabizonylathoz kapcsolódó SAP Business Workflow elindulásából következtethető ki. Ez az SWW_WI2OBJ táblában, a számlabizonylat-objektumhoz, például a BUS2081 objektumhoz kapcsolódik. Az esemény a bizonylat fejlécének egyéni állapotmezőjében bekövetkező változásból is azonosítható. Rögzítés Következtessen rá a számlabizonylathoz kapcsolódó munkafolyamat-elem létrehozásából. Eseménytípus inferred | |||
| Számla parkolása | A számlát már rögzítették a rendszerben, de még nem könyvelték a főkönyvbe. A parkolás lehetővé teszi a hiányos számlák mentését, illetve azok későbbi ellenőrzését a könyvelés előtt. | ||
| Miért fontos? A parkolás a folyamat tudatos szüneteltetését jelzi. A parkolt számlák számának és parkolási idejének követése segít feltárni a késések okait, még a hivatalos könyvelési és jóváhagyási ciklus kezdete előtt. Hol szerezhető be? Az esemény azonosítható a parkolási tranzakciókkal, például a MIR7 vagy FV60 tranzakcióval létrehozott bizonylatok alapján, illetve a BKPF tábla megfelelő állapotmezőinek vagy a parkolt bizonylatok külön tábláinak, például a VBKPF táblának az ellenőrzésével. Rögzítés Azonosítsa a parkolási tranzakciókkal létrehozott bizonylatokat, vagy ellenőrizze, hogy a bizonylat parkolt állapotú-e. Eseménytípus explicit | |||
| Számlaadatok módosítása | Ez a tevékenység a számlabizonylat létrehozása után végrehajtott módosítást jelzi. Erre gyakran az elutasítást követő javítás során vagy hibák korrigálásakor kerül sor. | ||
| Miért fontos? A gyakori módosítások ismételt munkára és az adatrögzítéskor felmerülő minőségi problémákra utalhatnak. A változások követése segít számszerűsíteni a javításokra fordított munkát és feltárni a gyakori hibákat. Hol szerezhető be? A fontos mezők módosításait az SAP változásbizonylat-táblái rögzítik: a CDHDR a fejlécet, a CDPOS pedig a tételt tartalmazza. Az események a megfelelő számlabizonylat-objektum módosításainak szűrésével állíthatók elő. Rögzítés Nyerje ki a számlabizonylat-objektum változásait a CDHDR és CDPOS táblákból. Eseménytípus explicit | |||
Útmutatók az adatok kinyeréséhez
Lépések
- Előfeltételek és jogosultságok: Győződjön meg arról, hogy az adatkinyerést végző felhasználó rendelkezik a szükséges SAP S/4HANA-jogosultságokkal a Core Data Services (CDS) nézetek eléréséhez. A fontos nézetek:
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemésI_PaymentProposalItem. A felhasználónak a kiválasztott felületen, például OData szolgáltatáson vagy közvetlen SQL-kapcsolaton keresztül futtatott lekérdezésekhez is jogosultságra lesz szüksége. - A kapcsolódási mód kiválasztása: Határozza meg, hogyan csatlakozik az SAP S/4HANA rendszerhez az SQL-lekérdezés futtatásához. Gyakori megoldás az SAP Data Services, az SAP Data Intelligence, egy SAP-csatlakozóval rendelkező külső ETL-eszköz, illetve a közvetlen SQL-kapcsolat az SAP HANA-adatbázishoz, ha ezt a szervezet biztonsági szabályzata engedélyezi.
- A kinyerési paraméterek megadása: A lekérdezés futtatása előtt adja meg a fő paramétereket. Határozza meg a kinyerés dátumtartományát, például a
CreationDateértékét'YYYY-MM-DD'és'YYYY-MM-DD'között. Adja meg azokat aCompanyCodeértékeket is, amelyeket be szeretne vonni, így szűkítheti a kinyert adatok körét. - Az SQL-lekérdezés testreszabása: Másolja a megadott SQL-lekérdezést a kiválasztott SQL-kliensbe vagy adatkinyerő eszközbe. Gondosan ellenőrizze a helyőrzőket, például a
'{StartDate}','{EndDate}'és('{CompanyCode1}', '{CompanyCode2}')értékeket. Cserélje le őket az előző lépésben megadott tényleges értékekre. Előfordulhat, hogy a munkafolyamat állapotát jelző mezőneveket is módosítania kell az SAP-konfigurációnak megfelelően. - A lekérdezés futtatása: Futtassa a teljes SQL-lekérdezést az SAP S/4HANA-adatbázison vagy a megfelelő szolgáltatási rétegen keresztül. A lekérdezés sok adatot dolgoz fel, ezért a futási idő az adatmennyiségtől és a kiválasztott dátumtartománytól függően jelentős lehet. Figyelje a futást az esetleges hibák és időtúllépések miatt.
- Az első eredmények ellenőrzése: A lekérdezés befejezése után gyorsan ellenőrizze az eredményt. Nézze meg, hogy az
InvoiceNumber,ActivityNameésEventTimeoszlopok tartalmaznak-e adatot. AzActivityNameoszlopban többféle tevékenységnek kell szerepelnie, nem csak az „Invoice Document Created” értéknek. - Az adatok átalakítása: A lekérdezés megfelelő formátumú eseménynaplót állít elő. Ellenőrizze azonban, hogy az
EventTimeoszlop egységes időbélyeg-formátumot használ-e, példáulYYYY-MM-DDTHH:MM:SSformátumot. A lekérdezés szükség esetén egyetlen időbélyeggé egyesíti a dátum- és időmezőket. - Az adatok exportálása: Exportálja az eszközből a végleges eredményhalmazt CSV (vesszővel elválasztott értékeket tartalmazó) fájlba. Ez a formátum a process mining eszközökkel, köztük a ProcessMinddel is kompatibilis.
- Felkészülés a feltöltésre: Feltöltés előtt ellenőrizze, hogy a CSV-fájl UTF-8 kódolású-e, így elkerülhetők a karaktermegjelenítési problémák. Az oszlopfejlécek pontosan egyezzenek a szükséges attribútumokkal:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodestb. - Feltöltés a ProcessMindbe: Töltse fel az előkészített CSV-fájlt a process mining projektbe. Az eszköz adatmodelljének beállításakor rendelje hozzá a fájl oszlopait a megfelelő esetazonosító-, tevékenységnév- és időbélyegmezőkhöz.
Konfiguráció
- Felhasznált CDS-nézetek: Az elsődleges adatforrások a szabványos SAP CDS-nézetek. A fő nézetek: az
I_InvoiceDocumenta fejlécadatokhoz, azI_OperationalAcctgDocItema pénzügyi könyvelési és elszámolási részletekhez, valamint azI_ChangeDocumentés azI_ChangeDocumentItema számlaattribútumok, például a fizetési zárolások és a munkafolyamat állapotának korábbi változásaihoz. - Dátumtartomány szerinti szűrés: A teljesítmény érdekében elengedhetetlen az adatok meghatározott dátumtartományra szűrése. A megadott lekérdezés helyőrzőt használ az
I_InvoiceDocumentnézetCreationDatemezőjéhez. Kezdésként 3–6 hónapnyi adatot érdemes lekérni. - Vállalati kód szerinti szűrés: A releváns és kezelhető adatmennyiség érdekében mindig szűrjön egy vagy több
CompanyCodeértékre. A lekérdezésben erre a célra szerepel aWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')helyőrző. - Bizonylattípus szerinti szűrés: A kinyerést tovább szűkítheti az
InvoiceDocumentTypemező alapján. Például felveheti a normál beszállítói számlákat (RE), a jóváíró számlákat pedig kizárhatja. Ezt a kezdeti CTEWHEREfeltételéhez adhatja hozzá. - Előfeltételek: A lekérdezést futtató felhasználónak megfelelő megjelenítési jogosultságokkal kell rendelkeznie a megadott vállalati kódokhoz tartozó pénzügyi és beszerzési bizonylatokhoz. A mögöttes HANA-adatbázis SQL-kliensen keresztüli elérése nem alapértelmezett, ehhez külön jogosultság szükséges.
- Teljesítmény: A változásbizonylat-táblák (
I_ChangeDocument,I_ChangeDocumentItem) adatainak kinyerése jelentős erőforrást igényelhet. A hosszú futási idő elkerüléséhez szűrjön szigorúan dátum, vállalati kód és objektumosztály (INCOMINGINVOICE) szerint.
Példa-lekérdezés sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Lépések
- Ellenőrizze, hogy engedélyezett-e a közvetlen, csak olvasási hozzáférés az SAP HANA-bérlőhöz vagy adatbázissémához. Kérjen csak olvasásra jogosult adatbázis-felhasználót, aki hozzáfér a szükséges SAP-táblákhoz és az engedélyezett változáselőzmény- vagy munkafolyamat-táblákhoz. Használja az SAP HANA Database Explorert, az SAP HANA Studiót vagy egy jóváhagyott SQL-klienst. Éles rendszerben ne használjon írási jogosultságot.
- Ellenőrizze a fizikai táblák és oszlopok nevét a célként használt S/4HANA-rendszerben. Az ACDOCA, a BKPF és az RBKP jó kiindulópont, de a munkafolyamat, a parkolás, a fizetési javaslat, a fizetés végrehajtása, a változáselőzmények és a fizetési zárolások előzményei kiadásonként vagy ügyfelenként eltérő objektumokat használhatnak. A lekérdezés minden szögletes zárójelben szereplő helyőrzőjét cserélje le a rendszerkatalógusban ellenőrzött objektumra, amely megfelel az üzleti jelentésnek.
- Adja meg a kinyerési időszakot a [Kezdő időbélyeg] és a [Záró időbélyeg] használatával. Kérjen le megfelelően hosszú időszakot a bizonylatok és események adataiból, általában három-hat hónapot. Bővítse az időszakot, ha a fizetési határidők vagy a késedelmes fizetések kívül eshetnek a számla létrehozásának időszakán.
- A beállított számlakulcs alapján azonosítsa a számlaeseteket. A lekérdezés az
InvoiceNumbermezőt használja esetazonosítóként, és szükség esetén belsőleg vállalati kóddal és pénzügyi évvel egészíti ki az ütközések elkerüléséhez. Ellenőrizze, hogy az üzleti definíció szerint a ProcessMind esetazonosítójának tartalmaznia kell-e a pénzügyi évet vagy a vállalati kódot is. - Társítsa a könyvelt számlaadatokat az RBKP, a BKPF és az ACDOCA táblákból. Az RBKP-ből kérje le a számlafejléceket, a BKPF-ből a könyvelési bizonylatok időbélyegeit és felhasználóit, az ACDOCA-ból pedig a beszállítóra, összegre, beszerzési bizonylatra, elszámolásra és fizetésre vonatkozó könyvelési adatokat, ha rendelkezésre állnak. Ne feltételezze, hogy minden mező minden könyvelési esetben ki van töltve.
- A parkolási, jóváhagyási, elutasítási, módosítási, fizetési zárolási, visszafordítási, fizetési javaslati és fizetés-végrehajtási eseményeket ellenőrzött, rendszerfüggő forrásokból rendelje hozzá. Cserélje le a helyőrző forrásnézeteket jóváhagyott nézetekre vagy táblákra, amelyek tartalmazzák az esemény időbélyegét, a számlahivatkozásokat, a felhasználókat, az állapotokat, valamint a régi és új értékeket. Minden tevékenységet külön eseménysorként kell megadni, mert a ProcessMind nem következtet ki eseményeket.
- Futtassa a teljes SQL-lekérdezést nem éles vagy csak olvasási munkamenetben. Ellenőrizze a végrehajtási terveket, és ahol indokolt, szűrjön vállalati kód, bizonylattípus, pénzügyi év és esemény-időbélyeg szerint. Kerülje a nagy napló- és előzménytáblák korlátozás nélküli összekapcsolását.
- Az alábbi ellenőrzésekkel validálja az eredményt. Győződjön meg arról, hogy minden szükséges oszlop szerepel, minden eseménynél ki van töltve az EventTime, minden esetnél szerepel az InvoiceNumber, és mind a 13 tevékenységnév megjelenik, ha a megfelelő forrásadat rendelkezésre áll.
- Exportálja az eredményt a ProcessMind által támogatott, tagolt fájlba, lehetőleg UTF-8 kódolású CSV-be. Minden sor egy eseményt tartalmazzon, az oszlopok pedig a következők legyenek: InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason és PurchasingDocument. Használjon egységes időzónát az időbélyegekhez, és őrizze meg az azonosítók kezdő nulláit.
- Töltse fel az eseménynaplót a ProcessMindbe, és állítsa be az InvoiceNumber mezőt esetazonosítóként, az ActivityName mezőt tevékenységoszlopként, az EventTime mezőt pedig időbélyegoszlopként. Ha a ProcessMind beállításai további esetkulcsokat is támogatnak, alkalmazza ugyanazt az összetett kulcsra vonatkozó szabályt, mint az adatkinyerésnél.
Konfiguráció
- Dátumtartomány: Az első kinyeréshez válasszon gördülő, három-hat hónapos időszakot. Kérjen le további előzményeket is, ha a jóváhagyási, fizetési, elszámolási, visszafordítási vagy késedelmes fizetési események a számla létrehozásának időszaka után történhetnek.
- Vállalati kör: Szűrjön a [Vállalatikód-szűrő] alapján, és ellenőrizze, hogy a kiválasztott vállalati kódokhoz engedélyezett-e az adatkinyerés.
- Bizonylatok köre: Szűrjön a [Bizonylattípus-szűrő] alapján, és vegye fel a célfolyamatban szereplő beszállítói számlák, jóváíró számlák, parkolt számlák és sztornók bizonylattípusait.
- Esetazonosító: A folyamatdefiníció szerint használja az InvoiceNumber mezőt. Ha a számlaszámok nem egyediek, tartsa meg a vállalati kódot és a pénzügyi évet a forráseredményben, vagy állítson be összetett esetkulcsot a ProcessMind-modellnek megfelelően.
- Eseményforrások: Ellenőrizze a munkafolyamat-állapotok változásainak, a jóváhagyási döntéseknek, a parkolásnak, a változáselőzményeknek, a fizetési zárolásoknak, a fizetési javaslatoknak és a fizetés végrehajtásának fizikai adatforrásait. Ezek az S/4HANA-kiadástól, az aktivált funkcióktól, a munkafolyamat kialakításától és az ügyfélspecifikus bővítésektől függően eltérnek.
- Időbélyeg-szabály: Az üzleti esemény időpontját használja, ne az adatkinyerés időpontját. Dokumentálja az időzónát, és feltöltés előtt egységesen alakítsa át az események időbélyegeit.
- Összegkezelés: A vállalati kód pénznemében megadott összeget használja, és ellenőrizze, hogy a kiválasztott forrás következetesen tárolja-e a tartozás és a követelés előjelét. Ne összegezze a naplósorokat, amíg nem ellenőrizte az adott számlaesetre vonatkozó összesítési szabályt.
- Fizetési szabály: Határozza meg, hogy a Payment Executed az elszámolást, a fizetési bizonylat könyvelését, a banki teljesítést vagy más üzleti mérföldkövet jelenti-e. Az elfogadott folyamatdefiníciónak megfelelő forrást használja.
- Késedelmes fizetés: A Late Payment Executed eseményt csak akkor adja ki, ha a Payment Executed esemény a PaymentDueDate után történik. A lekérdezés ezt az eseményt külön számítja ki, a ProcessMind nem következteti ki.
- Teljesítmény: A forrásadatokat dátum, vállalati kód, bizonylattípus és szükség esetén pénzügyi év szerint szűrje. Csak a szükséges oszlopokat válassza ki, vizsgálja meg a lekérdezési terveket, és nagy forráselőzmények esetén hozzon létre jóváhagyott köztes nézeteket.
- Előfeltételek: Közvetlen SAP HANA-kapcsolat, olvasási jogosultság minden kiválasztott objektumhoz, metaadatok vizsgálatára vonatkozó engedély, valamint hozzáférés a szállítói kötelezettségek, főkönyv, beszerzés, munkafolyamat és fizetés adataihoz. Ellenőrizze, hogy rendelkezésre állnak-e a szükséges SAP-licencek, adatbázis-hozzáférési engedélyek és adatvédelmi jóváhagyások.
- Biztonság: Csak olvasásra jogosult technikai felhasználót alkalmazzon, védje a beszállítói és fizetési adatokat, és tartsa be a szervezet szállítási, naplózási, maszkolási és hitelesítőadat-kezelési szabályait.
Példa-lekérdezés sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Lépések
- Az ABAP-szerkesztő megnyitása: Jelentkezzen be az SAP S/4HANA-rendszerbe. Nyissa meg az
SE38tranzakciót (ABAP Editor). - A program létrehozása: Adjon nevet az új programnak a Program mezőben, például
Z_PM_INVOICE_EXTRACT, majd kattintson a „Create” gombra. Adjon meg egy címet, a Type mezőben válassza az „Executable Program” értéket, majd mentse a programot a megfelelő csomagba. - A program felépítésének és a kiválasztóképernyőnek a meghatározása: A szerkesztőben határozza meg a végleges eseménynapló adatszerkezeteit. Ezután hozzon létre egy kiválasztóképernyőt, ahol megadható például a számla rögzítési dátumának tartománya, a vállalati kódok és a bizonylattípusok. Így a program újra felhasználható és rugalmas lesz.
- Az adatlekérési logika megírása: Írja meg az alapvető ABAP SQL-utasításokat az adatok SAP-táblákból történő lekéréséhez. A program egymás után kérdezi le a 13 szükséges tevékenység adatait.
- Fejléc- és tételadatok kinyerése: Az olyan alapvető eseményekhez, mint az „Invoice Document Created” és az „Invoice Posted”, kérjen le adatokat az elsődleges táblákból, például az
RBKP(Logistics Invoice Header) és aBKPF(Accounting Document Header) táblából. - Változásbizonylatok adatainak kinyerése: A „Payment Block Set” és „Payment Block Removed” tevékenységekhez kérdezze le a
CDHDR(Change document header) ésCDPOS(Change document items) változásbizonylat-táblákat. Azonosítsa az adott mezők, például aBSEGtáblaZLSPRmezőjének változásait. - Fizetési adatok kinyerése: A fizetéssel kapcsolatos tevékenységek rögzítéséhez kérdezze le például a
REGUP(Processed items from payment program) táblát a fizetési javaslatokhoz, aBSAK(Cleared Vendor Items) táblát pedig a teljesített fizetésekhez. A „Late Payment Executed” esemény azonosításához hasonlítsa össze az elszámolás dátumát (AUGDT) a nettó esedékesség dátumával (ZFBDT). - Munkafolyamat-adatok kinyerése: A jóváhagyási tevékenységekhez kérdezze le az SAP Business Workflow tábláit, például az
SWW_WI2OBJtáblát, hogy összekapcsolja a munkafolyamat-elemeket a számlaobjektumokkal. Ez a lépés nagymértékben függ az adott munkafolyamat beállításától, ezért jelentős módosításra lehet szükség. - Adatok egységesítése eseménynapló-formátumba: Minden kiválasztott tevékenység adatait alakítsa közös belső táblaszerkezetté. A tábla minden sora egyetlen eseményt jelöljön, és tartalmazza az esetazonosítót (
InvoiceNumber), azActivityNameés azEventTimemezőt, valamint a többi javasolt attribútumot. - A kimeneti fájl létrehozása: Az
OPEN DATASET,TRANSFERésCLOSE DATASETABAP-utasításokkal írja ki a végleges belső tábla tartalmát egy egyszerű fájlba az SAP alkalmazáskiszolgálón. Javasolt a vesszővel elválasztott értékeket tartalmazó CSV-formátum. - Ütemezés és futtatás: Teszteléshez futtassa a programot előtérben az
F8billentyűvel. Éles futtatáshoz ütemezze háttérfeladatként azSM36tranzakcióval, csúcsidőn kívülre, hogy ne terhelje a rendszer működését. - A fájl lekérése és feltöltése: Az
AL11tranzakcióval keresse meg az alkalmazáskiszolgáló azon könyvtárát, ahová a fájlt mentette. Töltse le a fájlt a helyi rendszerére. Feltöltés előtt ellenőrizze, hogy UTF-8 kódolású és megfelelő formátumú-e.
Konfiguráció
- Dátumtartomány: Adjon meg egy konkrét dátumtartományt a számla rögzítési dátuma (
RBKP-CPUDT) vagy könyvelési dátuma (BKPF-BUDAT) alapján. Első elemzéshez 3–6 hónapos időszak javasolt, hogy az adatmennyiség kezelhető maradjon. - Vállalati kód (BUKRS): Elengedhetetlen, hogy egy vagy több vállalati kódra szűrjön. Nagy szervezetben az összes vállalati kód adatainak kinyerése rendkívül hosszú futási időt és nagy fájlokat eredményezhet.
- Bizonylattípus (BLART): Szűrjön a releváns bizonylattípusokra a beszállítói számlák elkülönítéséhez. Gyakori típus a „RE” (bruttó számla) és a „KR” (beszállítói számla). Ezzel kizárhatja az elemzésből a nem releváns bizonylatokat.
- Beszállítói számla (LIFNR): A programban opcionális szűrőt állíthat be adott beszállítói számokra, ami célzott elemzéshez vagy teszteléshez hasznos.
- Kimeneti fájl beállítása: A programban paraméterként megadható legyen az alkalmazáskiszolgálón használt kimeneti fájl elérési útja és a mezőelválasztó, például vessző vagy pontosvessző.
- Előfeltételek: A programot futtató felhasználónak vagy rendszerfióknak fejlesztői jogosultságra van szüksége ABAP-programok létrehozásához és futtatásához az
SE38tranzakcióban, valamint széles körű olvasási jogosultságra az FI-, MM- és Basis-táblákhoz, többek között aBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSés munkafolyamat-táblákhoz.
Példa-lekérdezés abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. Készen áll a kezdésre?
Kezdje el még ma optimalizálni a számlafeldolgozást. Ez a sablon az első lépés a működés jelentős fejlesztése és a hatékonyság növelése felé.
Optimalizálja most a P2P-számlafeldolgozást SAP S/4HANA rendszerben
Találja meg a szűk keresztmetszeteket, és csökkentse legalább 30%-kal a számlafeldolgozás átfutási idejét.
Nincs szükség bankkártyára. A beállítás percek alatt elvégezhető.