Adatsablon a szállítói számlák feldolgozásához
Adatsablon a szállítói számlák feldolgozásához
- Javasolt attribútumok a részletes elemzéshez
- A hatékony nyomon követéshez szükséges fő folyamattevékenységek
- Útmutató az adatok kinyeréséhez, lépésről lépésre
A szállítói számlák feldolgozásának attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | A tevékenység pontos dátuma és időpontja. | ||
| Leírás Az esemény időpontja az egyes tevékenységekhez tartozó időbélyeg, amely megadja a számlával kapcsolatos események időrendi sorrendjét. Ez az adat szükséges a folyamat menetének megértéséhez és minden időalapú elemzéshez. Az elemzés során az esemény időpontja alapján állíthatók helyes sorrendbe a tevékenységek, számítható ki a lépések közötti átfutási idő, azonosítható a várakozás, és vizsgálható a folyamat teljesítménye különböző időszakokban, például hónapról hónapra. Minden időtartam-alapú KPI erre épül. Miért fontos? Ez az időbélyeg szükséges az események időrendi sorrendjének meghatározásához és az időalapú mutatók, például az átfutási idők és időtartamok kiszámításához. Ezek a process mining alapjai. Hol szerezhető be? Az SAP-táblák különböző dátum- és időmezőiből származik, például a létrehozás dátumából (BKPF-CPUDT), a könyvelési dátumból (BKPF-BUDAT), a kiegyenlítés dátumából (BSAK-AUGDT) vagy a módosítási napló időbélyegeiből (CDHDR-UDATE/UTIME). Példák 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Számla Invoice | A számladokumentum egyedi azonosítója, amely a szállítói számlafolyamat elsődleges esetazonosítója. | ||
| Leírás A számla az a központi objektum, amely összekapcsolja a kapcsolódó tevékenységeket a beérkezéstől a kifizetésig. SAP S/4HANA rendszerben ezt általában a vállalatkód (BUKRS), az egyedi bizonylatszám (BELNR) és az üzleti év (GJAHR) együttese azonosítja. A számlák elemzésével a teljes életciklus végigkövethető. Ez szükséges az olyan mutatók kiszámításához, mint a teljes átfutási idő, az egyes számlákat érintő szűk keresztmetszetek feltárásához, valamint annak megértéséhez, hogy milyen útvonalakon haladhat végig egy számla a folyamatban. Miért fontos? Egyedileg azonosítja az egyes számlák útját, így végigkövethető a teljes életciklusuk, és esetről esetre elemezhető a folyamat teljesítménye. Hol szerezhető be? Összetett kulcs, amely a BKPF (könyvelési bizonylat fejléce) vagy az RBKP (számlabeérkezési bizonylat fejléce) táblából, a BUKRS, BELNR és GJAHR mezők alapján állítható elő. Példák 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Tevékenység ActivityName | A számlafeldolgozás során bekövetkezett konkrét üzleti esemény vagy lépés neve. | ||
| Leírás A tevékenység a szállítói számlafolyamat egy-egy jól elkülöníthető szakaszát vagy műveletét jelöli, például: „Számla beérkezett”, „Számla könyvelve” vagy „Fizetés végrehajtva”. Ezekből épül fel a folyamattérkép. A tevékenységek elemzése a process mining alapja. Segítségével megjeleníthető a folyamat menete, feltárhatók a gyakori útvonalak, azonosíthatók a standard folyamattól való eltérések, és mérhető az egyes lépések gyakorisága, illetve időtartama. Az egyes számlák tevékenységeinek sorrendje mutatja meg a számla útját a folyamatban. Miért fontos? Meghatározza a folyamat lépéseit, így megjeleníthető és elemezhető a folyamat menete, feltárhatók a szűk keresztmetszetek és az utómunka-körök. Hol szerezhető be? Többféle forrásból származhat, például a bizonylatállapot változásaiból (BKPF-BSTAT), a módosítási bizonylatokból (CDHDR/CDPOS táblák) vagy a workflow-naplókból. Kinyeréséhez általában egyedi logikára van szükség. Példák Számla beérkezettSzámla jóváhagyvaFizetés végrehajtvaSzámla fizetési zárolása | |||
| Forrásrendszer SourceSystem | A rendszer, amelyből az adatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja a folyamatadatok forrását. Ebben a nézetben az értéke jellemzően „SAP S/4HANA”. Több ERP-rendszer vagy integrált rendszer használatakor ez a mező fontos az adatok eredetének nyomon követéséhez és elkülönítéséhez. Segít biztosítani, hogy az elemzés a megfelelő adatkészleten alapuljon, és az adatminőségi problémákat vissza lehessen vezetni a forrásukig. Miért fontos? Azonosítja az adatok forrását, ami fontos az adatirányításhoz, a hibaelhárításhoz és a több rendszert használó környezetekben. Hol szerezhető be? Általában az adatkinyerés során hozzáadott, rögzített érték, amely az adatkészlet forrását jelöli. Példák SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg azt mutatja, mikor frissítették utoljára a rekord adatait a forrásrendszerből. | ||
| Leírás Ez az attribútum az SAP S/4HANA rendszerből végzett legutóbbi adatkinyerés vagy frissítés dátumát és időpontját mutatja. Metaadatként jelzi, mennyire frissek az elemzett adatok. Segít a felhasználóknak megítélni, mennyire aktuális a folyamatelemzés. Az adatkésés figyelembevételével reális elvárásokat alakíthatnak ki, megtervezhetik az adatfrissítéseket, és megőrizhetik az adatok integritását. Miért fontos? Jelzi az adatok frissességét, így a felhasználók tudják, mennyire aktuális a folyamatelemzés. Hol szerezhető be? Az értéket a forrásrendszerből történő adatkinyeréskor állítják elő, majd minden rekordhoz hozzárendelik. Példák 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Beszállító neve VendorName | A számlát benyújtó beszállító neve. | ||
| Leírás Ez az attribútum a beszállító hivatalos nevét tartalmazza. A számladokumentumban tárolt beszállítói szám kapcsolja hozzá. A beszállítók elemzése segít a beszállítói kapcsolatok kezelésében és az egyes beszállítókhoz köthető folyamatproblémák feltárásában. Választ adhat például arra, hogy mely beszállítók számláin fordul elő a legtöbb eltérés, vagy hogy a stratégiai beszállítóknak rendszeresen időben fizetnek-e. A számlaszámmal és az összeggel együtt a lehetséges duplikált kifizetések felismeréséhez is használható. Miért fontos? Lehetővé teszi a folyamat teljesítményének beszállítónkénti elemzését, így azonosíthatók a problémás beszállítók, és hatékonyabban kezelhetők a stratégiai beszállítói kapcsolatok. Hol szerezhető be? A beszállítói törzsadatokat tartalmazó LFA1 táblából kérdezhető le a NAME1 mező alapján. Az összekapcsoláshoz a BKPF vagy az RBKP táblában szereplő beszállítói számot (LIFNR) kell használni. Példák Irodaszerek Kft.Globális Tanácsadó CsoportGépalkatrészek GmbH | |||
| Felhasználónév UserName | A tevékenységet végrehajtó személy felhasználói azonosítója. | ||
| Leírás Ez az attribútum rögzíti annak az SAP-felhasználónak az azonosítóját, aki egy adott tevékenységet végrehajtott, például könyvelt, jóváhagyott vagy kiegyenlített egy számlát. Így a folyamatlépések konkrét felhasználókhoz kapcsolhatók. A felhasználónév szerinti elemzés segít megérteni a munkaterhelés eloszlását, azonosítani a kiemelkedő teljesítményt nyújtókat, és megtalálni, kinek lehet szüksége további képzésre. A dashboardokon a jóváhagyási szűk keresztmetszetek elemzéséhez is hasznos, mert megmutatja, mely jóváhagyók okoznak késedelmet. Miért fontos? Az egyes tevékenységeket konkrét személyekhez rendeli, így elemezhető a felhasználók teljesítménye, munkaterhelése és a feladatok szétválasztására vonatkozó szabályok betartása. Hol szerezhető be? Általában a fejlécet tartalmazó táblákban található, például a BKPF-USNAM mezőben (rögzítette), vagy a módosítási bizonylatok tábláiban, például a CDHDR-USERNAME mezőben (módosította). Példák ABROWNJSMITHAP_AUTOMATION | |||
| Megrendelésszám PurchaseOrderNumber | A számlához tartozó megrendelés egyedi azonosítója, ha van ilyen. | ||
| Leírás Ez az attribútum egy előzetesen jóváhagyott megrendeléshez (PO) kapcsolja a számlát. A megrendelésszám megléte a háromoldalú egyeztetés alapja: megrendelés, számla és áruátvétel. Ez az attribútum fontos a megfelelés és a hatékonyság elemzéséhez. A „Megrendelés nélküli számlák aránya” KPI kiszámításához használható, amely a beszerzési szabályok betartását méri. A „Háromoldalú egyeztetés teljesítménye” dashboard alapja is, mert lehetővé teszi a megrendeléshez kapcsolódó számlák egyeztetési folyamatának elemzését. Miért fontos? Fontos a háromoldalú egyeztetés hatékonyságának elemzéséhez és a beszerzési szabályok betartásának méréséhez. Segítségével azonosíthatók a megrendelés nélkül feldolgozott számlák. Hol szerezhető be? A számlatételeket tartalmazó táblákban található, például MM-számláknál az RSEG-EBELN, FI-számláknál a BSEG-EBELN mezőben. Példák 45000012344500005678 | |||
| Számla esedékessége InvoiceDueDate | Az a dátum, ameddig a számlát ki kell fizetni a beszállítónak. | ||
| Leírás A számla esedékessége az a határidő, ameddig a beszállítónak fizetni kell a késedelmi díjak elkerülése és a jó beszállítói kapcsolat fenntartása érdekében. A dátum a számla bázisdátuma és a beszállítóval egyeztetett fizetési feltételek alapján számítható ki. Ez a dátum szükséges a „Fizetési megfelelés és lejárat” dashboardhoz, valamint az „Időben történő fizetések aránya” KPI-hoz. Az esedékesség és a tényleges fizetési dátum összevetésével kiderül, hogy időben, korábban vagy késve történik-e a fizetés, és milyen pénzügyi, illetve üzleti következményekkel jár. Miért fontos? Ez az időben történő fizetések elemzésének alapja. Segítségével mérhető a fizetési teljesítmény, valamint a beszállítói kapcsolatokra és a késedelmi díjakra gyakorolt hatása. Hol szerezhető be? Ezt a dátumot gyakran számítják. A nettó esedékességi dátum a BSEG-NETDT mezőben található. A fizetés bázisdátumából (BSEG-ZFBDT) és a fizetési feltételekből (BSEG-ZTERM) is kiszámítható. Példák 2023-10-312023-11-152024-01-10 | |||
| Számla összege InvoiceAmount | A számla teljes bruttó összege az eredeti bizonylat pénznemében. | ||
| Leírás A beszállító által benyújtott számla teljes értéke. Tartalmazza az áruk vagy szolgáltatások költségét, az adókat és az egyéb díjakat, a levonások és kedvezmények előtt. A számla összege számos pénzügyi elemzés fontos attribútuma. Segít előnyben részesíteni a nagy értékű számlákat, felmérni a folyamat késedelmeinek pénzügyi hatását, például a nagy összegű számlák késedelmi díjait, és szegmensekre bontani a folyamatot. Megvizsgálható például, hogy a nagy értékű számlák jóváhagyása eltérő útvonalon történik-e. Az attribútum a lehetséges duplikált kifizetések felismeréséhez is szükséges. Miért fontos? Pénzügyi kontextust ad a folyamatelemzéshez, így érték alapján vizsgálhatók és rangsorolhatók a számlák, valamint számszerűsíthetők a pénzügyi hatások. Hol szerezhető be? MM-számláknál például az RBKP-RMWWR mezőben található (bruttó számlaösszeg). FI-számláknál a BSEG tábla tételeiből számítható ki a WRBTR mező alapján. Példák 1500.00250.7512345.50 | |||
| Vállalatkód CompanyCode | Az a szervezeti egység, amelynek a számláját feldolgozzák. | ||
| Leírás A vállalatkód a legkisebb szervezeti egység, amelyhez külső beszámoláshoz szükséges, teljes és önálló számlakészlet állítható össze. A szállítói számlák esetében azt a jogi személyt jelöli, amely tartozik a beszállítónak. A vállalatkód szerinti elemzéssel összehasonlítható a folyamat teljesítménye a szervezet különböző jogi személyei között. Így feltárható, hol követik a standard folyamatokat, és mely területeken jobb a hatékonyság, hosszabb az átfutási idő vagy gyakoribb az utómunka. Miért fontos? Lehetővé teszi a folyamat teljesítményének összehasonlítását a különböző jogi személyek között, így feltárhatók a régiókra vagy üzleti egységekre jellemző problémák és bevált gyakorlatok. Hol szerezhető be? A bizonylatfejléc-táblákban található, elsősorban a BKPF-BUKRS mezőben FI-számlákhoz, illetve az RBKP-BUKRS mezőben MM-számlákhoz. Példák 10001710US01DE01 | |||
| Automatizált IsAutomated | Jelzi, hogy a tevékenységet a rendszer automatikusan, nem pedig egy felhasználó hajtotta-e végre. | ||
| Leírás Ez a logikai attribútum megkülönbözteti a felhasználó által indított tevékenységeket a rendszerfeladatok, workflow-k vagy botok által végrehajtottaktól. Automatizáltnak jelölhető például egy automatikus fizetési futás vagy a rendszer által létrehozott számla könyvelése. Az attribútum elemzésével felmérhető a szállítói számlafolyamat automatizáltsága. Segít mérni az automatizálási kezdeményezések eredményét, összehasonlítani az automatizált és a kézi lépések hatékonyságát, valamint további automatizálási lehetőségeket találni. Miért fontos? Segít felmérni a folyamat automatizáltságát, elemezni az automatizálás eredményességét és feltárni a további fejlesztési lehetőségeket. Hol szerezhető be? A felhasználónév alapján következtethető ki, például az olyan rendszerfelhasználók azonosítóiból, mint a „SAP_SYSTEM” vagy a „BATCHUSER”, illetve az automatizált feladatokhoz kapcsolódó tranzakciókódokból. Példák truefalse | |||
| Fizetési feltételek PaymentTerms | A szállítóval egyeztetett feltételek, amelyek meghatározzák a számla kifizetését, és gyakran kedvezményes fizetési lehetőséget is tartalmaznak. | ||
| Leírás A fizetési feltételek határozzák meg a fizetési határidőt és az esetleges előrehozott fizetési kedvezményeket. A „Z001” például jelentheti azt, hogy a számlát 30 napon belül kell kifizetni, 10 napon belüli fizetés esetén pedig 2% kedvezmény jár. Ez az attribútum az „Előrehozott fizetési kedvezmények érvényesítési aránya” dashboard alapja. A fizetési feltételek elemzésével azonosíthatók a kedvezményre jogosító számlák. Ha ezeket összeveti a ténylegesen igénybe vett kedvezményekkel, láthatóvá válnak az elszalasztott megtakarítási lehetőségek, és mérhetővé válik a fizetési folyamat hatékonysága. Miért fontos? Elengedhetetlen az előrehozott fizetési kedvezmények lehetőségeinek elemzéséhez, a fizetési folyamat pénzügyi teljesítményének méréséhez és az elszalasztott megtakarítások feltárásához. Hol szerezhető be? A szállítói tételsorokban, a BSEG-ZTERM táblában, illetve a számla fejlécében, az RBKP-ZTERM mezőben található. Példák Z0010001NT30 | |||
| Fizetési zárolás oka BlockingReason | A számla fizetési zárolásának oka, amely valamilyen eltérésre utal. | ||
| Leírás Ha a számla nem felel meg az ellenőrzésnek a háromoldalú egyeztetés vagy más ellenőrzési lépés során, fizetési zárolás alá kerül. A zárolás oka megadja a probléma jellegét, például mennyiségi eltérést, árkülönbséget vagy hiányzó áruátvételi bizonylatot. Ez az attribútum meghatározó az „Eltérések miatti számlajavítás elemzése” dashboard szempontjából. A különböző zárolási okok gyakoriságának elemzése segít feltárni a folyamat hatékonysági problémáinak kiváltó okait. Ha például gyakori az árkülönbség, az a beszerzési rendszer törzsadataival kapcsolatos problémára utalhat. Miért fontos? Közvetlenül megmutatja a számlaeltérések és az ismételt feldolgozás kiváltó okait, így célzott folyamatfejlesztésre ad lehetőséget. Hol szerezhető be? Az olyan számlatétel-táblákban található, mint az RSEG, az SPGR* kezdetű mezőkben (például SPGRP, SPGRQ, SPGRT). Az RBKP_BLOCKED táblában is szerepelhet. Példák ÁreltérésMennyiségi eltérésHiányzó áruátvételi bizonylat | |||
| Igénybe vett kedvezmény DiscountTaken | Logikai jelző, amely megmutatja, hogy sikerült-e érvényesíteni az előrehozott fizetési kedvezményt. | ||
| Leírás Ez az attribútum jelzi, hogy a számla kifizetésekor ténylegesen igénybe vették-e a pénzügyi kedvezményt. A szállítói számlák feldolgozásának pénzügyi hatékonyságát mérő egyik alapadat. Ez a jelző az „Előrehozott fizetési kedvezmények érvényesítési aránya” KPI alapja. A fizetési feltételek alapján kedvezményre jogosító számlák szűrésével, majd ennek a jelzőnek az elemzésével pontosan kiszámítható a megtakarítás és az elszalasztott kedvezmények száma. Így számszerűen mérhető a szállítói számlák feldolgozásának teljesítménye. Miért fontos? Közvetlenül méri, mennyire sikerül érvényesíteni az elérhető előrehozott fizetési kedvezményeket, amelyek közvetlenül befolyásolják a vállalat eredményét. Hol szerezhető be? A fizetési bizonylaton szereplő kedvezményösszeg-mező (BSEG-SKNTO) ellenőrzésével állapítható meg. Ha az érték nagyobb nullánál, a kedvezményt igénybe vették. Példák truefalse | |||
| Késedelmes fizetés IsLatePayment | Logikai jelző, amely megmutatja, hogy a számlát a fizetési határidő után fizették-e ki. | ||
| Leírás Ez a számított attribútum egy egyszerű igaz/hamis jelzővel mutatja meg, hogy a számlát a hivatalos esedékességi dátum után fizették-e ki. A „Rendezés dátuma” és a „Számla esedékességi dátuma” összevetésével számítható ki. A jelző egyszerűbbé teszi az elemzést a „Fizetési megfelelés és lejárt tételek” dashboardon, valamint a határidőre történő fizetés KPI esetében. Segítségével könnyen szűrhetők és összesíthetők a késedelmes fizetések, kiszámítható a határidőre teljesített fizetések aránya, és azonosíthatók a gyakran késve fizető szállítók vagy vállalatkódok. Miért fontos? Közvetlenül méri a fizetési feltételek betartását, egyszerűsíti a határidőre történő fizetés KPI kiszámítását, és segít feltárni a gyenge fizetési teljesítményű területeket. Hol szerezhető be? Számított attribútum. A logika: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Példák truefalse | |||
| Rendezés dátuma ClearingDate | Az a dátum, amikor a fizetés megtörtént, és a számla kikerült a nyitott tételek közül. | ||
| Leírás A rendezés dátuma jelzi a számla pénzügyi kiegyenlítését. Ekkor történik meg a „Kifizetés rendezve” tevékenység, amely a legtöbb sikeresen feldolgozott számla esetében az utolsó lépés. Ez a dátum mutatja a tényleges fizetés időpontját, amelyet a számla esedékességi dátumával lehet összevetni. Ezért elengedhetetlen a határidőre történő fizetés KPI kiszámításához és a fizetési teljesítmény elemzéséhez. A teljes számlafeldolgozási idő számításának végpontját is ez jelöli. Miért fontos? A számla végleges kiegyenlítését jelöli. Ez a feldolgozási idő számításának végpontja, és a határidőre történő fizetés elemzésének alapja. Hol szerezhető be? A kiegyenlített tételek tábláiban található, szállítók esetében például a BSAK-AUGDT mezőben. Példák 2023-10-282023-11-142024-01-09 | |||
| Szállítói számlaszám VendorInvoiceNumber | A szállító által a számlán feltüntetett számlaszám. | ||
| Leírás Ez a szállító saját könyvelési rendszeréből származó hivatkozási szám, amely a papíralapú vagy elektronikus számlán szerepel. A számla beérkezésekor kézzel rögzítik, vagy OCR-rel olvassák be. Ez a mező a napi működés és az elemzés szempontjából is különösen fontos, például a „Lehetséges kettős számlakifizetések” dashboard esetében. A duplikációk felderítésének egyik gyakori módja, hogy megkeresik azokat a belső számladokumentumokat, amelyeknél megegyezik a szállító neve, a szállítói számlaszám és a számla összege. Ez a számla elsődleges külső hivatkozási adata. Miért fontos? Fontos adat a lehetséges kettős kifizetések felderítéséhez, és a szállítókkal folytatott egyeztetés elsődleges külső hivatkozási alapja. Hol szerezhető be? A dokumentum fejlécének „Hivatkozás” mezőjében található, jellemzően a BKPF-XBLNR mezőben. Példák INV-2023-9876733401120231015-001 | |||
| Számla pénzneme InvoiceCurrency | A számla összegének pénznemkódja (például USD, EUR). | ||
| Leírás Ez az attribútum adja meg, milyen pénznemben szerepel a számla összege. A pénzügyi adatok értelmezéséhez elengedhetetlen. Nemzetközi szervezeteknél félrevezető lehet a számlák pénznemének figyelmen kívül hagyásával végzett elemzés. Ez a mező lehetővé teszi a pénzügyi adatok megfelelő kezelését: az összegek átválthatók egyetlen jelentési pénznemre, vagy pénznem szerint csoportosíthatók a regionális pénzügyi tevékenység megértéséhez. Miért fontos? Megadja a számla összegének értelmezéséhez szükséges pénznemet, így pontos pénzügyi elemzést és jelentéstételt tesz lehetővé, különösen nemzetközi környezetben. Hol szerezhető be? Elsősorban a dokumentumfejléc-táblákban található, a BKPF-WAERS vagy az RBKP-WAERS mezőben. Példák USDEURGBPJPY | |||
| Számladokumentum típusa InvoiceDocumentType | A számladokumentum besorolása, amely meghatározza, hogyan dolgozza fel az SAP. | ||
| Leírás A bizonylattípus az SAP egyik fontos beállítása, amely kategóriákba sorolja a könyvelési bizonylatokat. A „KR” jellemzően szállítói számlát, a „RE” MM-számlát, a „KG” pedig szállítói jóváíró bizonylatot jelöl. A típus többek között a számtartományt és a kötelező mezőket is meghatározza. A bizonylattípus szerinti szűréssel összehasonlíthatók a különböző számlatípusok folyamatai. A jóváíró bizonylatok jóváhagyása például eltérhet a normál számlákétól. Ez hasznos a „Számlajóváhagyási útvonalak változatai” dashboardhoz. Miért fontos? Lehetővé teszi a folyamat szegmentálását a különböző számlatípusok kezelése szerint, így feltárhatók a feldolgozási útvonalak és az átfutási idők eltérései. Hol szerezhető be? Közvetlenül a bizonylatfejléc-táblából, a BKPF-BLART mezőből. Példák KRREKG | |||
A szállítói számlák feldolgozásának tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Fizetés kiegyenlítve | Ez az esemény jelzi a számla végleges lezárását: az alszámlán egyeztették egymással a fizetést és a számlát. Ezzel a folyamat befejeződik. | ||
| Miért fontos? A folyamat végpontjaként ez az esemény szükséges a teljes átfutási idő pontos kiszámításához. Azt is megerősíti, hogy a kötelezettséget rendezték. Hol szerezhető be? Az esemény akkor rögzül, amikor a számladokumentum szállítói tételének kiegyenlítési dátum mezője (AUGDT) kitöltött a BSEG táblában. Rögzítés Használja a számlatétel kiegyenlítési dátumát (BSEG-AUGDT). Eseménytípus explicit | |||
| Fizetés végrehajtva | A számlát kifizették. Az esemény akkor rögzül, amikor a fizetési futás befejeződik, és létrejön, majd könyvelésre kerül a fizetési bizonylat. | ||
| Miért fontos? Ez az esemény fontos a cash flow elemzéséhez és az „Időben történő fizetések aránya” KPI méréséhez. Ehhez a fizetés dátumát a számla esedékességével kell összevetni. Hol szerezhető be? Az esemény a számlát kiegyenlítő fizetési bizonylat könyvelési dátumából nyerhető ki. A fizetési bizonylat száma a számlatétel kiegyenlítési bizonylat mezőjében (AUGBL) található a BSEG táblában. Rögzítés Azonosítsa a számlatételt kiegyenlítő fizetési bizonylat könyvelési dátumát (BUDAT). Eseménytípus explicit | |||
| Számla beérkezett | Ez az esemény azt jelzi, hogy a számladokumentum létrejött az SAP rendszerben, kézi rögzítéssel vagy például OCR/VIM-alapú automatizált interfészen keresztül. Az esemény általában a könyvelési bizonylat fejlécében szereplő létrehozási dátum és idő alapján azonosítható. | ||
| Miért fontos? A folyamat kezdőpontjaként ez az esemény szükséges a számlafeldolgozás teljes átfutási idejének és a teljes szállítói számlafolyamat átbocsátásának méréséhez. Hol szerezhető be? Az esemény a könyvelési bizonylat fejlécét tartalmazó táblából (BKPF) nyerhető ki, a bizonylat létrehozási dátuma (CPUDT) és időpontja (CPUTM) alapján. Rögzítés A számladokumentum létrehozási időbélyegét használja (BKPF-CPUDT, BKPF-CPUTM). Eseménytípus explicit | |||
| Számla fizetési zárolása | A rendszer automatikusan vagy egy felhasználó zárolta a számlát, ezért az nem fizethető ki. Ennek oka általában ár- vagy mennyiségi eltérés, illetve hiányzó jóváhagyás. | ||
| Miért fontos? Ez a problémák és az utómunka fontos jelzője. A zárolás okainak és időtartamának elemzésével feltárhatók a fizetési késedelmek és a folyamat hatékonysági problémáinak kiváltó okai. Hol szerezhető be? A zárolást a könyvelési bizonylat szállítói tételének fizetési zárolási kulcsa (ZLSPR) rögzíti a BSEG táblában. Rögzítés A rendszer módosítási bizonylatban naplózza, ha a BSEG-ZLSPR mezőbe zárolási ok kerül. Eseménytípus explicit | |||
| Számla jóváhagyva | A számla megkapta az összes szükséges jóváhagyást a workflow-rendszerben. Ez gyakran az utolsó lépés a számla könyvelése vagy fizetési zárolásának feloldása előtt. | ||
| Miért fontos? Ez a fontos mérföldkő jelzi a jóváhagyási folyamat végét. A továbbítás és a jóváhagyás közötti idő a hatékonyság egyik fontos mérőszáma. Hol szerezhető be? Az SAP Business Workflow naplóiban a folyamat befejezéseként vagy végső feloldási lépéseként rögzíthető. A továbbítás utáni fizetési zárolás feloldásából is következtethet rá. Rögzítés Nyerje ki a workflow befejezését jelző eseményeket az SAP workflow-naplóiból, vagy azonosítsa a végső „feloldás” eseményt. Eseménytípus explicit | |||
| Számla könyvelve | A számlát hivatalosan rögzítették a főkönyvben, ezzel pénzügyi kötelezettség keletkezett. Az előrögzített bizonylat könyveltté válik, vagy a számlát közvetlenül könyvelik. | ||
| Miért fontos? Ez fontos pénzügyi mérföldkő: megerősíti a vállalat fizetési kötelezettségét, és gyakran a fizetés ütemezésének előfeltétele. Hol szerezhető be? Az eseményt a bizonylat fejlécében szereplő könyvelési dátum (BUDAT) alapján lehet azonosítani (BKPF). A könyvelt bizonylat státusza (BKPF-BSTAT) üres. Rögzítés Az előrögzítetlen bizonylatoknál használja a könyvelési dátumot (BKPF-BUDAT), ha a BKPF-BSTAT mező üres. Eseménytípus explicit | |||
| Számla visszafordítva | A számladokumentumot visszafordították, így megszűnt a pénzügyi hatása. Ez a folyamat egyik lehetséges végállapota, amelyet gyakran hibás rögzítés vagy beszállítói vita okoz. | ||
| Miért fontos? A visszafordítások nyomon követésével feltárhatók a folyamat hibáinak okai, például a duplikált beküldések vagy a hibás számlaadatok. Ezek a problémák a folyamat korábbi szakaszaira is visszavezethetők. Hol szerezhető be? Az eseményt a visszafordító bizonylat létrehozásakor rögzítik. Az eredeti bizonylat fejlécében (BKPF) szerepel a visszafordító bizonylat száma (STBLG) és a visszafordítás oka. Rögzítés Azonosítsa a visszafordító bizonylat könyvelési dátumát, amely az eredeti bizonylat fejlécében található hivatkozással kapcsolódik hozzá (BKPF-STBLG). Eseménytípus explicit | |||
| Áruátvétellel egyeztetve | Ez az esemény azt jelzi, hogy a számla mennyiségeit és értékeit sikeresen egyeztették a hozzá tartozó áruátvételi bizonylattal. Ez a háromoldalú egyeztetés utolsó ellenőrzési lépése. | ||
| Miért fontos? Az esemény nyomon követésével feltárhatók a háromoldalú egyeztetés hatékonysági problémái, valamint a beérkezett áruk és a beszállító számláján szereplő tételek közötti eltérések. Hol szerezhető be? Az esemény a számlatételhez tartozó anyagbizonylat-hivatkozásból (áruátvételből) következtethető ki. Ez gyakran a megrendeléstétel előzményein keresztül kapcsolódik a számlához. Rögzítés A számlatételhez tartozó áruátvételi bizonylat hivatkozásából következtethető ki, például MIRO-számlák esetén az RSEG táblából. Eseménytípus inferred | |||
| Eltérés rendezve | Ez az esemény azt jelzi, hogy kivizsgálták és rendezték a korábban azonosított problémát, amely valószínűleg fizetési zárolást okozott. Az esemény akkor rögzül, amikor feloldják a számla fizetési zárolását. | ||
| Miért fontos? Ennek az utómunka-körnek a nyomon követése elengedhetetlen a „Számlaeltérések utómunkájának elemzése” dashboardhoz. Segít számszerűsíteni a hibák javítására fordított időt és munkát. Hol szerezhető be? Az esemény a fizetési zárolás feloldását rögzítő módosítási bizonylatokból következtethető ki. Elsődleges forrása a BSEG-ZLSPR mező módosítási naplója. Rögzítés Keresse meg azokat a BSEG-táblához tartozó módosítási bizonylatokat, amelyekben a ZLSPR mező értékről üresre változik. Eseménytípus inferred | |||
| Fizetési javaslat létrehozva | A számla bekerült egy fizetési futás fizetési javaslatába, például az F110-be. A futás végrehajtásáig a számla fizetésre vár. | ||
| Miért fontos? Ez az esemény azt mutatja, hogy a nyitott kötelezettségből fizetésre előkészített tétel lett. Segít elemezni a fizetések kezelésének hatékonyságát. Hol szerezhető be? Az eseményt a fizetési futás adatait tartalmazó táblák rögzítik, elsősorban a REGUP (a fizetési program által feldolgozott tételek) és a REGUH (fejléc). Rögzítés Azonosítsa, mikor jelenik meg a számla a REGUP táblában, a REGUH táblában azonosított fizetési futás részeként. Eseménytípus explicit | |||
| Lejárt a számla fizetési határideje | Számított esemény: a számla nettó esedékességi dátuma elmúlt, de a számlát még nem egyenlítették ki. Ez késedelmes vagy lejárt fizetést jelez. | ||
| Miért fontos? Ez az esemény a „Fizetési megfelelés és lejárat” dashboard egyik alapja. Segít időben azonosítani és kezelni a lejárt számlákat, valamint feltárni a késedelmes fizetések kiváltó okait. Hol szerezhető be? Az SAP rendszerben ez nem külön eseményként szerepel. A rendszer aktuális dátumát a nettó esedékességi dátummal veti össze, amely a BSEG-ZFBDT mezőből, illetve a bázisdátumból és a fizetési feltételekből számítható ki. Rögzítés A rendszer akkor állítja elő ezt a számított eseményt, ha az esemény időbélyege későbbi a számla nettó esedékességi dátumánál. Eseménytípus calculated | |||
| Megrendeléssel egyeztetve | Ez az esemény azt jelzi, hogy a számlát sikeresen egyeztették a hozzá tartozó megrendeléssel. A beszerzéshez kapcsolódó számlák háromoldalú egyeztetésének fontos lépése. | ||
| Miért fontos? Az esemény elemzésével mérhető az egyeztetési folyamat hatékonysága. Ez alapja a „Háromoldalú egyeztetés teljesítménye” és a „Megrendelés nélküli számlák aránya” KPI-nak. Hol szerezhető be? Az esemény akkor következtethető ki, ha a BSEG vagy az ACDOCA tábla számlatételében érvényes megrendelésszám (EBELN) és tételszám (EBELP) szerepel. Rögzítés A számladokumentum létrehozásakor a megrendelésre mutató hivatkozás (BSEG-EBELN) meglétéből következtethető ki. Eseménytípus inferred | |||
| Számla előrögzítve | A számlát rögzítették a rendszerben, de még nem könyvelték a főkönyvbe. Ez gyakran szándékos lépés: a hiányos bizonylatot későbbi feldolgozásra vagy jóváhagyásra mentik el. | ||
| Miért fontos? Az előrögzített számlák nyomon követésével feltárhatók a hivatalos könyvelés előtti késedelmek, valamint az adathiányból vagy a kezdeti ellenőrzésből eredő problémák. Hol szerezhető be? Az állapot a könyvelési bizonylat fejlécének státuszmezőjéből következtethető ki (BKPF-BSTAT = 'V' az előrögzített bizonylatnál). Az esemény akkor történik, amikor beállítják ezt az állapotot. Rögzítés Keresse meg azokat a BKPF-táblához tartozó módosítási bizonylatokat, amelyekben a BSTAT mező értéke 'V' (Vor-erfasst/előrögzített). Eseménytípus inferred | |||
| Számla elutasítva | A jóváhagyó elutasította a számlát a jóváhagyási workflow során. Ilyenkor a számla általában visszakerül a feldolgozóhoz javításra vagy pontosításra. | ||
| Miért fontos? Az elutasítások nyomon követésével feltárhatók a jóváhagyási folyamat utómunka-körei, és jelezhetők a szabályzatoknak való megfelelés vagy a számlakódolás problémái. Hol szerezhető be? Az esemény a számlához kapcsolódó SAP Business Workflow naplókban külön eredményként szerepel. Rögzítés Nyerje ki az SAP workflow-naplóiból az „elutasítva” állapotú eseményeket. Eseménytípus explicit | |||
| Számla jóváhagyásra továbbítva | A számlát az üzleti szabályok alapján szükséges jóváhagyásokra továbbították egy workflow-ba. Ezzel kezdődik a jóváhagyási részfolyamat. | ||
| Miért fontos? Ez az esemény az „Átlagos számlajóváhagyási idő” KPI mérésének és a jóváhagyási szűk keresztmetszetek elemzésének kiindulópontja. Hol szerezhető be? Az esemény az SAP Business Workflow naplóiból (SWW* táblák) nyerhető ki. Ezek rögzítik a számlához kapcsolódó workflow-példány indulását, például a BUS2081 objektumhoz kötve. Rögzítés Nyerje ki a számladokumentumhoz kapcsolódó workflow-indítási eseményeket az SAP workflow-naplóiból, például az SWW_WIHEAD táblából. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Előfeltételek és hozzáférés: Gondoskodjon arról, hogy rendelkezzen olyan felhasználóval, akinek olvasási jogosultsága van ahhoz az SAP S/4HANA-adatbázissémához (jellemzően SAPABAP1 vagy hasonló), amelyben a CDS View-k találhatók. Szüksége lesz egy SQL-kliensre is, amely csatlakozni tud az SAP HANA-adatbázishoz, például SAP HANA Studio, DBeaver vagy más adatbázis-lekérdező eszköz.
- A szükséges CDS View-k azonosítása: A kinyeréshez használt fő CDS View-k: I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails és I_PaymentProposalItem. Ismerje meg a fontos mezőiket.
- A lekérdezés hatókörének meghatározása: Nyissa meg az SQL-klienst, és csatlakozzon az SAP HANA-adatbázishoz. A teljes lekérdezés futtatása előtt határozza meg a kinyerés hatókörét. Adja meg a megfelelő forrásrendszer-azonosítót, a számlák dátumtartományát (CreationDateTime) és az érintett vállalatkódokat.
- A fő lekérdezés előkészítése: Másolja a lekérdezés szakaszában megadott teljes SQL-lekérdezést az SQL-kliensbe. A lekérdezés Common Table Expression (CTE) kifejezésekkel először kiválasztja a számlák alaphalmazát, majd 15 különböző tevékenység adataiból állítja össze az eseménynaplót.
- A lekérdezési paraméterek beállítása: Keresse meg a bemásolt SQL-lekérdezésben a helyőrzőket. Cserélje le a '[YYYY-MM-DD]' értéket az elemzési időszak kezdő- és záródátumára. A '[Your Company Code 1]' és '[Your Company Code 2]' helyére írja be az elemezni kívánt SAP-vállalatkódokat.
- A kinyerő lekérdezés futtatása: Futtassa a teljes SQL-lekérdezést. Az adatmennyiségtől és a kiválasztott dátumtartománytól függően ez néhány perctől akár több óráig is tarthat.
- Az előzetes eredmények ellenőrzése: A lekérdezés lefutása után tekintse át az első néhány száz sort. Ellenőrizze az adatok következetességét, hogy minden oszlop a várt értékeket tartalmazza-e, és hogy többféle ActivityName érték szerepel-e.
- Az eseménynapló exportálása: Exportálja az SQL-kliensből a teljes eredményhalmazt CSV-fájlba. A karakterkódolási problémák elkerüléséhez UTF-8 kódolást használjon. Adjon a fájlnak egyértelmű nevet, például sap_s4hana_ap_event_log.csv.
- Felkészülés a feltöltésre: Mielőtt feltölti az adatokat egy process mining eszközbe, ellenőrizze, hogy a CSV-fájl oszlopfejlécei pontosan megegyeznek-e az elvárt attribútumnevekkel: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName stb.
- Feltöltés a process mining eszközbe: Töltse fel az elkészített CSV-fájlt a process mining platformra, és rendelje az oszlopokat a megfelelő esetazonosító-, tevékenység- és időbélyegmezőkhöz.
Konfiguráció
- Fő CDS View-k: A kinyerés több szabványos S/4HANA CDS View-ra támaszkodik. A fő nézetek:
- I_JournalEntry és I_JournalEntryItem: A pénzügyi bizonylatok fejléceihez, tételeihez, könyvelési adataihoz és kiegyenlítési információihoz.
- I_SupplierInvoiceAPI01: Az MM (logisztikai) számlák részleteihez, beleértve a megrendelés-hivatkozásokat és a fizetési zárolásokat.
- I_ChangeDocument: A módosítások pontos időpontjának követéséhez, például fizetési zárolás beállításakor vagy feloldásakor.
- I_WorkflowStatusDetails: A számlajóváhagyási munkafolyamathoz kapcsolódó események kinyeréséhez.
- I_PaymentProposalItem: Annak megállapításához, hogy egy számla mikor került be egy fizetési futtatás javaslatába.
- I_Supplier: A szállítói törzsadatok, például a VendorName hozzáadásához.
- Dátumtartomány szűrése: Az adatmennyiség korlátozásához elengedhetetlen a dátumtartomány megadása. A lekérdezés az Invoices_Base CTE-ben a CreationDateTime mezőre szűr. Első elemzéshez 3–6 hónapos időszak javasolt, így a lekérdezés kezelhető teljesítmény mellett futtatható.
- Kötelező szűrők: Mindig szűrjön CompanyCode szerint. Az összes vállalatkód egyidejű elemzése rendkívül lassú lehet, és üzleti szempontból sem feltétlenül hasznos. A JournalEntryType mezőre is szűrjön, hogy csak a szállítókhoz kapcsolódó bizonylatok szerepeljenek, például 'KR' és 'RE'.
- Előfeltételek: A lekérdezést futtató adatbázis-felhasználónak SELECT jogosultsággal kell rendelkeznie a lekérdezésben használt összes CDS View-hoz és az alapul szolgáló HANA-sémához. Az SAP GUI-ban meglévő alkalmazásszintű hozzáférés önmagában nem elegendő.
- Teljesítménnyel kapcsolatos szempontok: Az I_ChangeDocument közvetlen lekérdezése jelentős erőforrásokat igényelhet. A megadott lekérdezés ezt úgy próbálja mérsékelni, hogy először leszűkíti a számlák körét. Nagyon nagy adathalmaz esetén futtassa a kinyerést csúcsidőn kívül, vagy kisebb dátumtartományokra bontva.
Példa-lekérdezés sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X'; Lépések
- Ellenőrizze, hogy rendelkezésre áll-e közvetlen olvasási hozzáférés az SAP HANA-sémához, amely a szükséges SAP S/4HANA-táblákat tartalmazza. Kérje el a kapcsolati karakterláncot, a hitelesítő adatokat, a séma nevét és a BKPF, ACDOCA, valamint a parkolt bizonylatokhoz, munkafolyamathoz, beszerzéshez, áruátvételhez, fizetési javaslatokhoz, kiegyenlítéshez és sztornózási adatokhoz beállított további táblák olvasásához szükséges jogosultságokat.
- A futtatás előtt ellenőrizze a célrendszer műszaki adatmodelljét. Érvényesítse a fizikai neveket, kulcsmezőket, időbélyegmezőket, sztornózási és fizetési kapcsolatokat, valamint a rendszerben használt munkafolyamat-adattárolást. Cserélje le a lekérdezés minden szögletes zárójelbe tett helyőrzőjét a rendszerben található megfelelő objektumra vagy mezőre. Ne feltételezze, hogy a munkafolyamat vagy a parkolt bizonylatok adatai egyetlen, minden rendszerben azonos táblában vannak.
- Állítsa be a kinyerési paramétereket. Adja meg a [Start date], [End date], [Company code filter], [Document type filter] és [Schema name] értékét. Kezdetben három-hat hónapos időszakot használjon, majd csak a teljesítmény és az adatok teljességének ellenőrzése után bővítse.
- Futtassa az SQL-lekérdezést egy jóváhagyott SAP HANA SQL-kliensben, például az SAP HANA Database Explorerben vagy más engedélyezett SQL-eszközben. A lekérdezés minden kinyert tevékenységhez külön sort ad vissza, és nem a ProcessMindre bízza az események kikövetkeztetését.
- Ellenőrizze az eredményhalmazt. Győződjön meg arról, hogy az Invoice az esetazonosító, az ActivityName mind a 15 szükséges tevékenységnevet tartalmazza, az EventTime ki van töltve és időrendileg életszerű, a SourceSystem az SAP S/4HANA-t jelöli, a LastDataUpdate pedig a kinyerés frissítési időbélyegét tartalmazza. Az adatok betöltése előtt vizsgálja meg a duplikált eseményeket, a sztornózási kapcsolatokat és a bizonylatok összekapcsolását.
- Alkalmazza a rendszerhez szükséges leképezéseket. Például a beállított parkoltbizonylat-forrást rendelje az Invoice Parked eseményhez, a munkafolyamat-forrást az Invoice Routed For Approval, Invoice Approved és Invoice Rejected eseményekhez, a fizetési forrást pedig a Payment Proposal Created és Payment Executed eseményekhez. Ha az auditálhatóság megköveteli, őrizze meg a forrásazonosítókat további oszlopokban.
- Exportálja az eredményt tagolt fájlba vagy adatbázis-lekérdezés eredményhalmazaként, eseményenként egy sorral. Használjon UTF-8 kódolást, egységes időzónában tárolja az időbélyegeket, és tartsa meg pontosan az Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber és InvoiceDueDate oszlopneveket. Ne vonja össze a tevékenységeket számlánként.
- Töltse fel az eseménynaplót a ProcessMindbe, és állítsa be az Invoice mezőt esetazonosítóként, az ActivityName mezőt tevékenységoszlopként, az EventTime mezőt pedig eseményidőként. Ellenőrizze, hogy a választható attribútumok a megfelelő mezőkhöz vannak-e rendelve. Mivel a ProcessMind változtatás nélkül olvassa be az eseménynaplót, feltöltés előtt minden megjeleníteni kívánt tevékenységnek külön sorban kell szerepelnie.
Konfiguráció
- Dátumtartomány: Kezdetben három-hat hónap adataival dolgozzon. A kinyert tevékenységnek megfelelően a könyvelési dátumot, a bizonylat létrehozási dátumát vagy a forrásesemény dátumát használja. Csak a lekérdezés futási idejének és a forrásadatok megőrzési idejének ellenőrzése után bővítse az időszakot.
- Vállalatkód szerinti szűrés: A [Company code filter] beállításával korlátozza a kinyerést a szükséges vállalatkódokra. Ha nincs szükség korlátozásra, az összes vállalatot ellenőrzött módon válassza ki, ne korlátozás nélküli éles lekérdezéssel.
- Bizonylattípus szerinti szűrés: A [Document type filter] beállítása előtt ellenőrizze, hogy a célrendszer milyen bizonylattípusokat használ szállítói számlákhoz, jóváírásokhoz, parkolt bizonylatokhoz, fizetési bizonylatokhoz és sztornókhoz.
- Séma és objektumok leképezése: Cserélje le a [Schema name] értékét és minden szögletes zárójelbe tett forrásobjektumot vagy mezőt a cél SAP S/4HANA-rendszerben ellenőrzött értékekre. A közvetlen HANA-lekérdezést a rendszer aktivált alkalmazásaihoz, bővítményeihez, munkafolyamatához és adatmodelljéhez kell igazítani.
- Időbélyegek kezelése: Egységesítse az összes forrásból származó időbélyeget egy időzónára. Ha csak dátum áll rendelkezésre, használjon dokumentált alapértelmezett időpontot, és rögzítse ezt a korlátozást az adatszótárban.
- Események jelentése: Minden tevékenységet külön sorban nyerjen ki. Ne vonjon össze több tevékenységet egy számlarekordba, és ne várja el a ProcessMindtől, hogy kikövetkeztesse az egyeztetési, jóváhagyási, esedékességi vagy kiegyenlítési eseményeket.
- Esedékességi esemény: Csak akkor hozza létre az Invoice Due Date Passed eseményt, ha a számla esedékességi dátuma korábbi a beállított kiértékelési időpontnál, és addig nem történt kiegyenlítés. A számításhoz a lekérdezés az [Evaluation timestamp] értékét használja.
- Teljesítmény: Kezdetben korlátozza az időszakot és az érintett vállalatok körét, szűrjön indexelt vagy particionálás szempontjából releváns mezőkre, kerülje a szükségtelenül sok oszlop lekérdezését, és a lekérdezést jóváhagyott jelentési időablakban futtassa. Ha az éles lekérdezés túllépi az egyeztetett futási időt, fontolja meg a forrásadatok részhalmazainak előkészítését.
- Frissítési stratégia: A LastDataUpdate mezőbe a kinyerés futtatásának időbélyegét írja. Növekményes betöltésnél a megfelelő forrásmódosítási időbélyeg alapján tartson fenn vízjelet, és alkalmazzon visszatekintési időszakot a későn érkező módosítások és sztornók rögzítéséhez.
- Előfeltételek: Szükség van a megfelelő adatbázis-jogosultságokra, jóváhagyott éles hozzáférésre, a rendszer Universal Journal-beállításainak ismeretére, a parkolt bizonylatokhoz, beszerzéshez, áruátvételhez, munkafolyamathoz, fizetéshez, kiegyenlítéshez és sztornózáshoz beállított források elérésére, valamint az esetleges SAP-licenc- és irányítási jóváhagyásokra.
Példa-lekérdezés sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Lépések
- Specifikáció és tervezés: A kódolás előtt egyeztessen az üzleti elemzőkkel mind a 15 szükséges tevékenység pontos kiváltási feltételeiről és adatmezőiről. Azonosítsa a releváns SAP-táblákat, bizonylattípusokat (például 'KR', 'RE') és a hatókörbe tartozó vállalatkódokat.
- ABAP-program létrehozása: Indítsa el az ABAP Editort az SE38 tranzakcióval. Hozzon létre egy új, futtatható programot, például Z_PM_AP_INVOICE_EXTRACT néven. Adjon neki egyértelmű címet, és állítsa az alkalmazást „Financial Accounting” értékre.
- Kiválasztóképernyő meghatározása: A programban a PARAMETERS és SELECT-OPTIONS kulcsszavakkal hozzon létre kiválasztóképernyőt, ahol a felhasználók megadhatják a kinyerés dátumtartományát (a számla létrehozási dátumát), a cél vállalatkódokat (BUKRS) és a releváns számlabizonylat-típusokat (BLART). Adjon hozzá egy paramétert az alkalmazáskiszolgálón használt kimeneti fájl elérési útjához is.
- Adatdeklarációk: Hozzon létre egy belső táblastruktúrát, amely megfelel a végleges eseménynapló formátumának (például TY_EVENT_LOG), és tartalmazza az összes kötelező, valamint ajánlott attribútumot. Deklaráljon belső táblákat a különböző SAP-forrástáblákból, például a BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS és REGUH táblákból kiválasztott adatok tárolására.
- A fő adatkiválasztás: Indítsa a kinyerést a felhasználó által a kiválasztóképernyőn megadott feltételek alapján az RBKP (logisztikai számlák) és a BKPF (pénzügyi számlák) táblából kiválasztott elsődleges számlakészlettel. A fő számlakulcsokat tárolja belső táblában, és használja őket a további adatlekérdezésekhez.
- Tevékenységek kinyerése egymás után: A fő számlakészlet minden eleméhez végezzen lekérdezéseket az egyes üzleti tevékenységek időbélyegének és részleteinek megkeresésére. Például a fizetési zárolások módosításaihoz kérdezze le a CDHDR és CDPOS táblákat, a fizetési futtatások adataihoz a REGUH és REGUP táblákat, a sztornóbizonylatok részleteihez pedig a BKPF táblát. Minden megtalált tevékenységhez adjon új rekordot a végleges eseménynapló-táblához.
- Számított események logikája: ABAP-logikával kezelje azokat a tevékenységeket, amelyek nem szerepelnek közvetlenül egy táblamezőben. Az „Invoice Due Date Passed” eseménynél használja a számla esedékességi dátumát (BSEG-ZFBDT + fizetési feltételek) és a kiegyenlítés dátumát (BSEG-AUGDT). Ha a kiegyenlítés dátuma későbbi az esedékességi dátumnál, hozzon létre új eseményrekordot, amelynek időbélyege az esedékesség dátuma.
- Adatok átalakítása és kiegészítése: Az egyes tevékenységek adatainak összegyűjtésekor töltse ki az összes szükséges attribútumot. Ehhez kérdezze le a szállítóneveket az LFA1 táblából, alakítsa a dátumokat és időpontokat egységes időbélyeg-karakterlánccá (CONCATENATE...INTO...), és állítsa be a SourceSystem értékét.
- Kimeneti fájl létrehozása: Miután az összes számlát és a hozzájuk tartozó tevékenységeket feldolgozta, és összegyűjtötte a végleges belső táblában, az OPEN DATASET, LOOP AT ... TRANSFER és CLOSE DATASET utasításokkal írja ki az adatokat a kiválasztóképernyőn megadott alkalmazáskiszolgáló-útvonalra.
- Letöltés és előkészítés a feltöltéshez: A CG3Y tranzakcióval töltse le az elkészült fájlt az alkalmazáskiszolgálóról a helyi gépére. Mentse UTF-8 kódolású CSV-fájlként. Feltöltés előtt ellenőrizze, hogy az oszlopfejlécek megfelelnek-e a szükséges attribútumoknak (Invoice, ActivityName, EventTime stb.).
Konfiguráció
- Dátumtartomány: A számla létrehozási dátumához (BKPF-CPUDT vagy RBKP-CPUDT) állítsa be a P_CPUDT kiválasztási feltételt. Első elemzéshez 6–12 hónap adata javasolt.
- Vállalatkód (P_BUKRS): Kötelező SELECT-OPTIONS paraméter az adott vállalatkódok szűréséhez. Ne dolgozza fel egyszerre az összes vállalatkódot, kivéve, ha ez feltétlenül szükséges.
- Számlabizonylat-típus (P_BLART): SELECT-OPTIONS paraméter a releváns számlabizonylat-típusok szűréséhez. A gyakori típusok közé tartozik a 'KR' (szállítói számla), a 'KG' (szállítói jóváírás) és a 'RE' (logisztikai számlaellenőrzés).
- Futtatási mód: Nagy adatmennyiségnél háttérfeladatként (SM36/SM37) futtassa a programot, hogy elkerülje az előtérben, párbeszédes módban fellépő időtúllépést. Ütemezze csúcsidőn kívülre.
- Kimeneti fájl elérési útja: PARAMETER segítségével adja meg a fájl elérési útját és nevét az SAP alkalmazáskiszolgálón, például a /tmp/ könyvtárban. A program először ide írja a fájlt, amelyet ezután letölthet.
- Előfeltételek: A jelentést futtató felhasználónak jogosultsággal kell rendelkeznie az FI-, CO- és MM-táblák (BKPF, BSEG, RBKP, RSEG, LFA1), a módosítási bizonylatok táblái (CDHDR, CDPOS) és a munkafolyamat-táblák olvasásához. Az alkalmazáskiszolgálóra történő fájlíráshoz az S_DATASET jogosultsági objektum is szükséges.
Példa-lekérdezés abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM. Készen áll a kezdésre?
Használja ezt a sablont a process mining bevezetéséhez, és tegye hatékonyabbá a szállítói számlák kezelését. Induljon el még ma egy egyszerűbb, gördülékenyebb folyamat felé.
Előzze meg a késedelmi díjakat: fejlessze még ma a szállítói számlák feldolgozását
Csökkentse 60%-kal a feldolgozási költségeket, és előzze meg a kettős kifizetéseket.
Nincs szükség bankkártyára, percek alatt elkezdheti.