Adatsablon a szállítói számlák kifizetési folyamatához
Adatsablon a szállítói számlák kifizetési folyamatához
- Alapvető attribútumok a szállítók és a kifizetések elemzéséhez
- A fizetési ciklus fontos folyamatmérföldkövei
- SAP S/4HANA-rendszerekhez készült speciális adatkinyerési logika
A szállítói számlák kifizetési folyamatának attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | A tevékenység pontos időpontja. | ||
| Leírás Az esemény időpontja azt a pontos dátumot és időt rögzíti, amikor a tevékenység bekerült az SAP adatbázisába. Ez adja meg az eset eseményeinek időrendi sorrendjét. Az időbélyeg általában a rendszer naplóiból vagy a bizonylatfejlécekből származó CPU Date és CPU Time mezők összekapcsolásával áll elő. Az elemzésben ez az attribútum szükséges az átfutási idők, az időtartamok és az átbocsátás kiszámításához. Segítségével mérhető az egyes lépések közötti idő, például a számla beérkezése és végső jóváhagyása között eltelt idő. Ez segít feltárni a szűk keresztmetszeteket és értékelni a KPI-k, például az átlagos számlajóváhagyási idő alakulását. Miért fontos? Megadja az események időrendi sorrendjét, és ez az alapja minden időalapú teljesítményszámításnak. Hol szerezhető be? SAP BKPF tábla CPUDT (rögzítés dátuma) és CPUTM (rögzítés időpontja) mezője, vagy a CDHDR UDATE és UTIME mezője Példák 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Számlaszám InvoiceNumber | A feldolgozás alatt álló szállítói számla egyedi azonosítója. | ||
| Leírás A számlaszám az SAP S/4HANA rendszerben a szállítói tétel életútjának elsődleges azonosítója. A főkönyvi könyveléskor létrejövő könyvelési bizonylat számát jelöli. Az SAP szabványos terminológiájában ez a Document Number (BELNR), amelyet a vállalatkód és az üzleti év határoz meg. A folyamat elemzésekor ez az attribútum szolgál Case ID-ként. Összekapcsolja a számla beérkezését és előzetes rögzítését, a jóváhagyási zárolásokat és módosításokat, valamint a végső fizetési kiegyenlítést. Az események e szerinti csoportosításával az elemzők rekonstruálhatják minden fizetési kötelezettség teljes életútját. Miért fontos? Ez az egyértelmű Case ID, amely lehetővé teszi a fizetési folyamat teljes menetének rekonstruálását. Hol szerezhető be? SAP BKPF tábla (könyvelési bizonylat fejléce), BELNR mező vagy ACDOCA tábla, BELNR mező Példák 1900000523510000289119000006015100003002 | |||
| Tevékenység Activity | A számlához rögzített konkrét feladat vagy eseményállapot-változás. | ||
| Leírás Ez az attribútum a számla életútja során végrehajtott különálló folyamatlépéseket jelöli. Ilyen esemény például a számla létrehozása, könyvelése, zárolása, jóváhagyása és kiegyenlítése. A tevékenységnevek a forrásrendszer tranzakciókódjaiból, módosítási naplóiból vagy workflow-állapotfrissítéseiből származnak. Az elemzés során ez a mező alapvető a folyamatváltozatok feltérképezéséhez. A process mining motor megjeleníti vele a lépések sorrendjét, feltárja az újramunkát okozó hurkokat, és megmutatja, hol tér el a folyamat a szokásos menettől. Ez az eseménynapló egyik alapvető eleme. Miért fontos? Meghatározza a folyamattérkép csomópontjait, így megjeleníthető a munkafolyamat és azonosíthatók a szűk keresztmetszetek. Hol szerezhető be? Tranzakciókódokból (TCODE), illetve a módosítási bizonylat fejlécéből (CDHDR) és tételéből (CDPOS) származik Példák Számla könyveléseFizetési zárolás beállításaFizetési futás végrehajtvaSzámla kiegyenlítve | |||
| Forrásrendszer SourceSystem | Annak az SAP S/4HANA-példánynak az azonosítója, ahonnan az adatok származnak. | ||
| Leírás Ez az attribútum azonosítja azt az ERP-rendszert vagy klienst, amelyből a folyamatadatokat kinyerték. Ha több SAP-példány vagy régi rendszer működik párhuzamosan, a mező segít megőrizni az adatok eredetének nyomon követhetőségét, és lehetővé teszi a rendszerek közötti összehasonlítást. Az elemzésben ez a mező magas szintű szűrőként használható. Segítségével az elemzők elkülöníthetik az adatokat, amikor különböző régiók rendszereinek teljesítményét hasonlítják össze, vagy rendszerátálláskor ellenőrzik az adatok konzisztenciáját. A rendszerbeállításokból eredő folyamateltérések így megfelelő kontextusba helyezhetők. Miért fontos? Többrendszeres környezetben megkülönbözteti az adatforrásokat, így pontos szegmentálást tesz lehetővé. Hol szerezhető be? Rendszerazonosító (SY-SYSID) az SAP telepítési környezetéből Példák SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg azt mutatja, mikor nyerték ki vagy frissítették utoljára a rekordot. | ||
| Leírás Az utolsó adatfrissítés azt az időpontot jelöli, amikor az adatok sikeresen betöltődtek a process mining platformra. Nem az üzleti esemény időpontját mutatja, hanem azt, hogy mennyire frissek az adatok. Ez fontos ahhoz, hogy megbízhatók legyenek az elemzési dashboardok. Az elemzés során ez az attribútum segít megállapítani, mennyire aktuális a megjelenített információ. Különösen fontos a közel valós idejű dashboardok, például a fizetési zárolások elemzésének figyelésekor, hogy a döntések az SAP S/4HANA rendszer legfrissebb állapotán alapuljanak. Miért fontos? Tájékoztatja a felhasználókat az adatok frissességéről, ami az operatív dashboardoknál különösen fontos. Hol szerezhető be? Az ETL- vagy adatkinyerési folyamat hozza létre Példák 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Bizonylattípus DocumentType | A könyvelési bizonylat besorolása, például szállítói számla, fizetés vagy jóváíró bizonylat. | ||
| Leírás A bizonylattípus az SAP-ban a könyvelési tranzakciót besoroló, két karakterből álló kód. Gyakori típus például a szállítói számláknál használt „KR”, a szállítói fizetéseknél használt „KZ” és a bruttó számlabeérkezést jelölő „RE”. Meghatározza a bizonylat számtartományát és mezőinek állapotát. Az elemzésben ezzel az attribútummal szűkíthető a folyamat vizsgálati köre. Az elemző például kizárhatja a jóváíró bizonylatokat, ha kizárólag a kimenő fizetések hatékonyságát szeretné vizsgálni. Az attribútum a feldolgozott tranzakciótípusok arányának feltárásában és a folyamatváltozatok összetettségét bemutató dashboard használatában is segít. Miért fontos? Besorolja az esetet, például számlaként vagy jóváíró bizonylatként, így szűrhetővé teszi az elemzést. Hol szerezhető be? SAP BKPF tábla BLART mezője Példák KRREKZKG | |||
| Érintés nélküli feldolgozás IsTouchless | Logikai jelző, amely azt mutatja, hogy a számlát manuális beavatkozás nélkül dolgozták-e fel. | ||
| Leírás Ez az attribútum az eset eseménysorának elemzésével számítható ki. A rendszer érintés nélküliként jelöli az esetet, ha kizárólag automatizált tevékenységeket tartalmaz, például „system” felhasználót vagy meghatározott háttérben futó TCODES-okat, és nem történt manuális módosítás vagy zárolás. Az elemzésben ez az Érintés nélküli számlafeldolgozási arány KPI alapmutatója. Segítségével nyomon követhető az automatizálási kezdeményezések eredménye, és azonosíthatók azok az esettípusok, például szállító vagy régió szerint, amelyek emberi beavatkozás nélkül haladnak végig a rendszeren. Miért fontos? A folyamat automatizáltságának és hatékonyságának elsődleges mérőszáma. Hol szerezhető be? A tevékenységek sorrendje és a felhasználótípusok alapján számítva Példák truefalse | |||
| Felhasználónév UserName | Az adott tevékenységet végrehajtó felhasználó azonosítója. | ||
| Leírás A felhasználónév a folyamatlépésért felelős személy vagy rendszerügynök bejelentkezési azonosítóját rögzíti. Ez lehet adatot rögzítő felhasználó vagy háttérfeladat-azonosító, például „BATCH_USER”, amely automatizált feladatokat végez. Az elemzésben ez az attribútum lehetővé teszi a tevékenységek automatizálási arányának kiszámítását. Az emberi felhasználók és a rendszerfiókok megkülönböztetésével mérhető a folyamat automatizáltsága. A kézi beavatkozási pontok megoszlását bemutató dashboard a csapatok munkaterhelésének értékelésére is használja. Miért fontos? Megkülönbözteti a kézi és az automatizált munkát, így kiszámítható az automatizálási arány. Hol szerezhető be? SAP BKPF tábla USNAM mezője vagy CDHDR tábla USERNAME mezője Példák BSMITHWF-BATCHRJONES | |||
| Fizetési feltételek PaymentTerms | A fizetés és az engedmények megállapodás szerinti feltételeit jelölő kód. | ||
| Leírás A fizetési feltételek határozzák meg a számla esedékességét és azt, hogy jár-e engedmény a korai fizetésért. Ez a kód, például „Z001”, olyan szabályoknak felel meg, mint a „30 napon belül” vagy a „2% 10 napon belül, nettó 30 nap”. A kód a szállítói törzsadatból kerül át a számlára, de kézzel módosítható. Ez az attribútum alapvető a korai fizetési engedményeket optimalizáló és a szállítói fizetési feltételek megfelelését vizsgáló dashboardokhoz. Segítségével kiszámítható az alapértelmezett esedékesség, és megállapítható, hogy a fizetés az engedmény érvényesítéséhez szükséges időablakban történt-e. Miért fontos? Meghatározza a várt fizetési határidőt és a pénzügyi ösztönzőket, ezért fontos az engedmények elemzéséhez. Hol szerezhető be? SAP BSEG tábla ZTERM mezője Példák Z001NT300001 | |||
| Fizetési zárolás oka PaymentBlockReason | A fizetési zárolás okát jelölő kód. | ||
| Leírás Ez az attribútum tartalmazza a számlához rendelt okkódot, amely miatt az automatikus fizetési futás nem veszi fel a számlát. Ilyen lehet például az „A” fizetési zárolás, az „R” számlaellenőrzés vagy a felhasználó által beállított kézi zárolás. Az elemzésben ez a mező a kézi fizetési zárolások elemzését bemutató dashboard fő adata. A különböző zárolási okok gyakoriságának összesítésével feltárhatók a fizetési folyamatot hátráltató rendszerszintű problémák, például a gyakori áreltérések vagy a hiányzó áruátvételek. Miért fontos? Megmutatja a folyamat elakadásának konkrét okát, így célzottan vizsgálhatók a kiváltó okok. Hol szerezhető be? SAP BSEG tábla ZLSPR mezője Példák ABR* | |||
| Késedelmes fizetés IsLatePayment | Logikai jelző, amely azt mutatja, hogy a kifizetés a nettó esedékesség után történt-e. | ||
| Leírás Ez a számított attribútum akkor igaz, ha a Clearing Date későbbi, mint a Net Due Date. A folyamat teljesítményének kétértékű besorolására szolgál. Az elemzésben ezzel a jelzővel számolható meg a Late Payment Penalty Frequency KPI szempontjából nem megfelelő esetek száma. A dashboard létrehozását is egyszerűsíti: az összetett dátumszámítások helyett elég megszámolni az „igaz” értékeket. Miért fontos? Egyszerűbbé teszi a határidőre teljesítést mérő KPI-k kiszámítását. Hol szerezhető be? Számítás: Clearing Date > Net Due Date Példák truefalse | |||
| Kiegyenlítés dátuma ClearingDate | Az a dátum, amikor a számlát fizetéssel kiegyenlítették. | ||
| Leírás A kiegyenlítés dátuma azt rögzíti, mikor egyenlítették ki a szállítói analitika nyitott tételét, jellemzően fizetési futással vagy kézi fizetés könyvelésével. Ezzel a kötelezettség lezárul. Az elemzésben ez az attribútum a folyamat teljes átfutási idejének kiszámítására szolgál. Ez az időpont tartozik a „Fizetés kiegyenlítve” tevékenységhez. A nettó esedékességgel összevetve meghatározható, hogy a fizetés időben történt-e. Az adat közvetlenül bekerül a fizetési kiegyenlítés hatékonyságát bemutató dashboardba. Miért fontos? Jelzi a fizetési folyamat végét, és segít megállapítani, hogy a fizetés időben történt-e. Hol szerezhető be? SAP BSEG tábla, AUGDT mező Példák 2023-11-012023-11-15 | |||
| Nettó esedékesség NetDueDate | A kiszámított határidő, ameddig a számlát a kötbér elkerülése érdekében ki kell fizetni. | ||
| Leírás A nettó esedékesség a fizetés végső határideje. A bázisdátumhoz hozzáadott maximális fizetési határidő alapján számítják ki. Bár néha külön mezőben tárolják, az elemzési nézetekben gyakran számított érték. Az elemzésben ez a késedelmes fizetéseket és kötbéreket követő mutató elsődleges viszonyítási alapja. A tényleges kiegyenlítési dátum és a nettó esedékesség összevetésével kiszámítható a késedelmes fizetés napjainak száma. Ez segít felmérni a szállítói számlákat kezelő csapat hatékonyságát és a szállítói kapcsolatok megromlásának kockázatát. Miért fontos? A folyamat célhatárideje. Elmulasztása ronthatja a hitelminősítést és többletköltséget okozhat. Hol szerezhető be? Számítás: bázisdátum + maximális fizetési határidő napokban (ZBD1T/ZBD2T/ZBD3T) Példák 2023-11-302023-12-01 | |||
| Szállítóazonosító VendorNumber | A számlához tartozó szállító egyedi azonosítója. | ||
| Leírás A szállítóazonosító az SAP analitikában szereplő hitelezői számlát jelöli. Összekapcsolja a számlát a fizetési feltételeket, banki adatokat és kapcsolattartási információkat tartalmazó törzsadattal. Az S/4HANA rendszerben gyakran az üzleti partner fogalmához kapcsolódik, de sok táblában továbbra is a régi LIFNR mezőnév szerepel. Az elemzésben ez az attribútum alapja a szállítói fizetési feltételek megfelelését vizsgáló dashboardnak. Segítségével a folyamat teljesítménye szállítónként összesíthető, így azonosíthatók azok a szállítók, akiknél rendszeresen zárolás, áreltérés vagy késedelem merül fel. Az adatok a stratégiai beszerzési döntéseket és a szállítói kapcsolatok kezelését is támogatják. Miért fontos? Lehetővé teszi a teljesítmény szállítónkénti összesítését, ami segít feltárni a késedelmek kiváltó okait. Hol szerezhető be? SAP BKPF tábla LIFNR mezője vagy ACDOCA tábla LIFNR mezője Példák 100050VEND-US-99200400 | |||
| Számla összege InvoiceAmount | A számla teljes bruttó összege a bizonylat pénznemében. | ||
| Leírás Ez az attribútum a forrásbizonylaton rögzített számla pénzügyi értékét mutatja. Ez az az összeg, amelyet a szállítónak ki kell fizetni. Az SAP S/4HANA rendszerben jellemzően a bizonylat pénznemében megadott összeg mezőben tárolják. Az elemzésben a számla összege segít a munka rangsorolásában. A kézi beavatkozási pontok megoszlását bemutató dashboard például megmutatja, hogy a sok kézi munkát igénylő tevékenységeket alacsony értékű számlákra fordítják-e. Így a folyamatfejlesztés a nagy értékű tranzakciókra összpontosíthat, ahol a folyamathibák nagyobb pénzügyi kockázatot jelentenek. Miért fontos? Megmutatja az eset pénzügyi súlyát, ami segít előnyben részesíteni a nagy értékű folyamatproblémák kezelését. Hol szerezhető be? SAP BKPF vagy BSEG tábla WRBTR mezője Példák 1500.00250.5010000.00 | |||
| Vállalatkód CompanyCode | Az a szervezeti egység, amelyre a mérleget és az eredménykimutatást elkészítik. | ||
| Leírás A vállalatkód a vállalatcsoport önálló számviteli egységét jelöli. A külső számvitel központi szervezeti egységeként a pénzügyi adatok rendszerezésére szolgál. Minden számla pontosan egy vállalatkódhoz tartozik. Az elemzésben ezzel az attribútummal a KPI-k jogi személy vagy régió szerint szegmentálhatók. A dashboardok segítségével összehasonlítható a szállítói számlákat kezelő csapatok hatékonysága a különböző leányvállalatoknál. Például kideríthető, hogy egy adott telephelyen a vállalati átlagnál gyakrabban zárolják-e kézzel a fizetéseket. Miért fontos? Jogi személyenként bontja a folyamatot, így támogatja a vállalaton belüli összehasonlítást. Hol szerezhető be? SAP BKPF tábla BUKRS mezője Példák US01DE1010002000 | |||
| 1. pénzügyi engedmény napjai CashDiscountDays1 | A bázisdátumtól számított napok száma, ameddig az első pénzügyi engedmény igénybe vehető. | ||
| Leírás Ez az attribútum határozza meg a legkedvezőbb fizetési feltételek időablakát, például a „2% 10 napon belül, nettó 30 nap” feltételben a 10 napot. A számlatételben tárolt feltételekből származik. Segítségével meghatározható a korai fizetési engedményeket optimalizáló elemzés célzott dátuma. Ha a számlát ezen az időablakon belül egyenlítik ki, érvényesíthető az engedmény. A mező megmutatja, mekkora lehetőségi költséggel járnak a lassú feldolgozási ciklusok. Miért fontos? Meghatározza a pénzügyi megtakarítás lehetőségét biztosító időablakot. Hol szerezhető be? SAP BSEG tábla ZBD1T mezője Példák 10140 | |||
| 1. pénzügyi engedmény százaléka CashDiscountPercentage1 | Az engedmény százalékos mértéke, ha a fizetés az első kedvezményes időszakon belül történik. | ||
| Leírás Ez az attribútum a szállító által korai fizetésért kínált pénzügyi kedvezmény mértékét jelöli, például a „2% 10 napon belül” feltételben szereplő 2%-ot. Az elemzésben ebből számítható ki a lehetséges pénzügyi engedmény összege. A százalék és a számla összegének szorzatával a dashboardok megmutathatják, mekkora összegtől esik el a vállalat a folyamat hatékonysági problémái miatt. Ez alátámaszthatja az automatizálás üzleti indoklását. Miért fontos? Számszerűsíti a lehetséges megtakarítás mértékét, ami elengedhetetlen a ROI kiszámításához. Hol szerezhető be? SAP BSEG tábla ZBD1P mezője Példák 2.03.00.0 | |||
| Bázisdátum BaselineDate | Az a dátum, amelytől a fizetési feltételek érvényesek, és amelyből az esedékességet számítják. | ||
| Leírás A bázisdátum a nettó esedékesség és a pénzügyi engedmény időszakának kiszámítási alapja. A beállításoktól és a szállítói törzsadattól függően általában a számla vagy a könyvelés dátuma. Az elemzésben ez a dátum szükséges a „Késedelmes” állapot kiszámításához. A hibás bázisdátum korai fizetéshez, így pénzforgalmi hatáshoz, vagy késedelmes fizetéshez, így kötbérhez vezethet. A dátum pontosságának ellenőrzése része a szállítói fizetési feltételek megfelelőségi elemzésének. Miért fontos? Ez az alapja minden esedékesség-számításnak. Hol szerezhető be? SAP BSEG tábla ZFBDT mezője Példák 2023-10-012023-10-15 | |||
| Beszerzési bizonylat PurchasingDocument | A számlához tartozó megrendelés száma. | ||
| Leírás Ez az attribútum összekapcsolja a számlát a beszerzési folyamat korábbi lépéseivel. A számlához tartozó megrendelés (PO) számát tartalmazza. Nem minden számlához, például a vegyes költségekhez kapcsolódókhoz tartozik megrendeléshivatkozás. Ez a mező elengedhetetlen a háromutas egyeztetési arány elemzéséhez. Segítségével elkülöníthetők a megrendeléshez kapcsolódó és az anélküli számlák, amelyek jóváhagyási munkafolyamata jellemzően eltér. A szállítói számlák adatainak beszerzési adatokkal való összekapcsolásával a teljes folyamat is elemezhető. Miért fontos? Összekapcsolja a szállítói számlák kezelését a beszerzéssel, így elemezhető a háromutas egyeztetés és kiterjeszthető a folyamat vizsgálata. Hol szerezhető be? SAP BSEG tábla EBELN mezője Példák 45000012344500009876 | |||
| Elvesztett engedmény összege DiscountLostAmount | Az igénybe vehető, de ki nem használt pénzügyi engedmények értéke. | ||
| Leírás Ez a számított attribútum azt mutatja meg, mennyi pénz maradt kihasználatlanul. A rendszer ellenőrzi, hogy a kifizetés az engedmény határideje után történt-e. Ha igen, kiszámítja a számla összegére alkalmazható, de elmaradt engedmény értékét. Az elemzésben ez az Early Payment Discount Optimizer egyik fontos pénzügyi mutatója. Pénzben fejezi ki a nem hatékony működés költségét, így számszerű üzleti érvet ad a folyamatfejlesztéshez. Miért fontos? Számszerűsíti a folyamat késedelmei miatt keletkező közvetlen pénzügyi veszteséget. Hol szerezhető be? Számítás: ha Clearing Date > Discount Date, akkor Invoice Amount * Discount % Példák 30.000.00150.00 | |||
| Pénznem Currency | A számla összegéhez tartozó pénznemkód. | ||
| Leírás A pénznem attribútum jelöli, hogy milyen pénznemben szerepel a számla összege, például USD, EUR vagy GBP. Segítségével helyesen értelmezhetők a pénzügyi értékek, és több ország vállalatkódjainak adatai is összesíthetők. Az elemzésben ez a mező biztosítja a pénzügyi KPI-k helyes kiszámítását. Gyakran használják az értékek egységesítésére és egy közös jelentési pénznemre történő átváltására a globális dashboardokon. Enélkül az olyan összesített mutatók, mint a teljes kiadás vagy az átlagos számlaérték, több pénznem használatakor nem lennének értelmezhetők. Miért fontos? Megadja a pénzügyi összegek értelmezéséhez szükséges kontextust, ami pontos globális jelentésekhez kell. Hol szerezhető be? SAP BKPF tábla WAERS mezője Példák USDEURGBPJPY | |||
| Üzleti év FiscalYear | Az az üzleti év, amelyhez a számla tartozik. | ||
| Leírás Az üzleti év a pénzügyi jelentések időszaka. A vállalatkóddal és a bizonylatszámmal együtt az SAP-ban a pénzügyi bizonylat összetett elsődleges kulcsát alkotja. Az elemzésben ez az attribútum technikailag szükséges az esetek egyedi azonosításához, és az évek közötti összehasonlítást is támogatja. Biztosítja, hogy a számlaszámként használt Case ID több évtizednyi adat esetén is egyedi maradjon. Miért fontos? Az esetek egyedi azonosításának technikai feltétele az SAP FI rendszerben. Hol szerezhető be? SAP BKPF tábla GJAHR mezője Példák 20232024 | |||
A szállítói számlák kifizetési folyamatának tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Fizetés kiegyenlítve | A végső egyeztetést jelzi, amikor a szállítói számla nyitott tétele a fizetéssel szemben kiegyenlítésre kerül. A BSEG tábla AUGDT (Clearing Date) mezőjéből olvasható ki. | ||
| Miért fontos? A folyamat végállapota: a folyamat lezárult, a könyvelés egyensúlyban van. A kézi kiegyenlítések magas aránya az egyeztetés hatékonysági problémáira utal. Hol szerezhető be? BSEG tábla, AUGDT mező (Clearing Date). Rögzítés Az AUGDT mező kitöltésekor naplózva Eseménytípus explicit | |||
| Fizetési bizonylat létrehozva | A bankot jóváíró és a szállítót megterhelő könyvelési bizonylat létrehozása. A BKPF táblában található, fizetési bizonylattípussal (például ZP, KZ). | ||
| Miért fontos? A fizetés pénzügyi teljesítését jelzi, és a Days Payable Outstanding (DPO) kiszámításához használható. Hol szerezhető be? BKPF tábla, a fizetésekre jellemző bizonylattípus (BLART) szerint szűrve. Rögzítés A BKPF fizetési bizonylat létrehozásakor naplózva Eseménytípus explicit | |||
| Fizetési futás végrehajtva | A fizetési futás végrehajtását jelzi, amely során létrejönnek az átutalási megbízások. A folyamat a REGUH vagy REGUP táblában rögzített állapotváltozás alapján követhető. | ||
| Miért fontos? A fizetésre vonatkozó operatív kötelezettségvállalást jelzi, ami alapvető a fizetések csoportosítási folyamatának hatékonysági elemzéséhez. Hol szerezhető be? REGUH tábla, jellemzően a futás dátuma és azonosítója alapján. Rögzítés A fizetési futás állapotának frissítésekor naplózva Eseménytípus explicit | |||
| Fizetési zárolás beállítása | Azt jelzi, hogy zárolást állítottak be a számla tételsorára, ezért az nem kerülhet be a fizetési futtatásba. Az esemény a BSEG tábla ZLSPR mezőjének módosításait követő változásbizonylatokból állapítható meg. | ||
| Miért fontos? A zárolások a késedelmes fizetések és a folyamat fennakadásainak elsődleges okai. Közvetlenül befolyásolják a Manual Payment Block Analysis dashboardot. Hol szerezhető be? A CDPOS és CDHDR táblák (változásbizonylatok), a BSEG-ZLSPR mező módosításait keresve. Rögzítés A CDPOS ZLSPR-mezőjének módosításakor naplózva Eseménytípus explicit | |||
| Fizetési zárolás feloldása | Azt jelzi, hogy feloldották a korábban beállított fizetési zárolást, így a számla kifizethetővé vált. Az esemény akkor azonosítható, amikor a BSEG ZLSPR mezőjének értéke üresre vagy nullára változik. | ||
| Miért fontos? Az olyan rendszerekben, amelyek nem rögzítenek külön munkafolyamat-naplót, gyakran a „Számla jóváhagyva” esemény helyettesítőjeként használható, és jelzi a szűk keresztmetszet időszakának végét. Hol szerezhető be? A CDPOS és CDHDR táblák, a BSEG-ZLSPR mező üresre változását keresve. Rögzítés A CDPOS ZLSPR-mezőjének törlésekor naplózva Eseménytípus explicit | |||
| Számla könyvelése | A kötelezettség hivatalos rögzítését jelenti a főkönyvben. Ez az esemény a BKPF tábla létrehozási időbélyegéből vagy az ACDOCA tábla könyvelési dátumából származik. | ||
| Miért fontos? Ez a pénzügyi idővonal elsődleges kezdőpontja, amely alapul szolgál a fizetési határidők és a lejárt tételek elemzéséhez. Hol szerezhető be? A BKPF tábla CPUDT (rögzítés dátuma) és CPUTM (rögzítés időpontja) mezője alapján. Rögzítés A BKPF-rekord létrehozásakor naplózva Eseménytípus explicit | |||
| Áreltérés észlelése | Következtetett tevékenység, amely a számlaár és a megrendelési ár közötti eltérést jelzi. Az esemény abból állapítható meg, hogy a könyveléskor automatikusan beállítanak egy adott fizetési zárolási kulcsot, jellemzően az „R” értéket a számlaellenőrzéshez. | ||
| Miért fontos? Feltárja a manuális újramunka kiváltó okait, és támogatja a Three Way Match Rate Analysis elemzést. Hol szerezhető be? A könyvelés időpontjában a BSEG-ZLSPR értéke „R” (vagy a rendszerben az ár miatti zároláshoz beállított érték) alapján következtethető ki. Rögzítés A ZLSPR értékének összevetése az „R” értékkel Eseménytípus inferred | |||
| Elveszített pénzügyi kedvezmény | Számított esemény, amely a pénzügyi kedvezmény igénybevételi határidejének lejártát jelzi. A kedvezményes fizetési határidő és az aktuális dátum vagy a kifizetés dátumának összevetésével állapítható meg. | ||
| Miért fontos? Az Early Payment Discount Optimizer elemzéséhez szükséges, hogy láthatóvá tegye az elmaradt megtakarítási lehetőségeket. Hol szerezhető be? Számítás: BSEG-ZFBDT + BSEG-ZBD1T (1. kedvezményes időszak napjai). Rögzítés A dátum és a kedvezményes fizetési határidő összevetésével állapítható meg Eseménytípus calculated | |||
| Fizetési feltételek módosítása | A nyitott számlához tartozó fizetési feltételek módosítását rögzíti, ami megváltoztatja a fizetési határidőt vagy a kedvezményre való jogosultságot. Az esemény a BSEG tábla ZTERM mezőjének változásnaplójából követhető. | ||
| Miért fontos? A gyakori módosítások törzsadat-hibákra vagy manuális felülbírálásra utalhatnak, amelyek befolyásolják a pénzforgalmi előrejelzést és a Vendor Payment Term Compliance mutatót. Hol szerezhető be? A CDPOS és CDHDR táblák, a BSEG-ZTERM mező módosításait keresve. Rögzítés A CDPOS ZTERM-mezőjének módosításakor naplózva Eseménytípus explicit | |||
| Fizetési javaslat létrehozása | Azt jelzi, hogy a számla bekerült egy fizetési javaslatot készítő futtatásba (F110), amely az automatizált fizetési program első lépése. Az esemény a kiegyenlítési adatokat tároló REGUH táblából olvasható ki. | ||
| Miért fontos? Azt jelzi, hogy a számlát kiválasztották kifizetésre, és megfelelt a fizetési program ellenőrzésein. Hol szerezhető be? A REGUH tábla létrehozásának időbélyege (LAUFD és LAUFI kulcsok). Rögzítés A REGUH rekord létrehozásakor naplózva Eseménytípus explicit | |||
| Mennyiségi eltérés észlelése | Következtetett tevékenység, amely a számlázott mennyiség és az áruátvételi mennyiség közötti eltérést jelzi. Az esemény abból állapítható meg, hogy a tételsorhoz adott fizetési zárolási kulcsot rendelnek, jellemzően az „M” értéket mennyiségi eltérés esetén. | ||
| Miért fontos? Nélkülözhetetlen az egyeztetés hatékonyságának és az ellátási lánc adatminőségének elemzéséhez. Hol szerezhető be? A BSEG-ZLSPR „M” értéke (vagy a rendszerben a mennyiségi zároláshoz beállított érték) alapján következtethető ki. Rögzítés A ZLSPR értékének összevetése az „M” értékkel Eseménytípus inferred | |||
| Számla fizetési határideje | Számított időbélyeg, amely a számla nettó fizetési határidejét jelöli. A BSEG táblában szereplő alapdátumhoz hozzáadjuk a fizetési feltételekben megadott napok számát. | ||
| Miért fontos? Az On-Time Payment Performance és a Late Payment Penalty Tracker viszonyítási pontjaként szolgál. Hol szerezhető be? Számítás: BSEG-ZFBDT (alapdátum) + BSEG-ZBD1T/ZBD2T/ZBD3T (napok). Rögzítés A jelenlegi dátum és a nettó fizetési határidő összevetésével állapítható meg Eseménytípus calculated | |||
| Számla rögzítése parkolt állapotban | Azt jelzi, hogy a számlát rögzítették az SAP rendszerben, de még nem könyvelték a főkönyvbe. Ezt az állapotot gyakran használják az előzetes adatbevitelhez. Az esemény közvetlenül a VBKPF táblából olvasható ki, vagy a BKPF táblában a könyvelés előtt parkolt státuszúként jelölt bizonylatok azonosításával állapítható meg. | ||
| Miért fontos? A parkolás az adatbevitel kezdetét jelzi, és segít mérni a beérkezés és a pénzügyi kötelezettség rögzítése közötti időt. Hol szerezhető be? A parkolt bizonylatok fejlécadataihoz a VBKPF tábla, vagy a BKPF tábla a megfelelő bizonylatstátusszal (BSTAT = V). Rögzítés A VBKPF-rekord létrehozásakor naplózva Eseménytípus explicit | |||
| Számla sztornózva | Azt jelzi, hogy a számlabizonylatot sztornózták vagy törölték. A BKPF tábla STBLG (Reversal Document) mezőjének ellenőrzésével állapítható meg. | ||
| Miért fontos? Újramunkát és folyamathibát jelez, így feltárhatók a veszteségek és az esetleges párhuzamos munkavégzés. Hol szerezhető be? BKPF tábla, az STBLG mező nem üres. Rögzítés Az STBLG mező kitöltésekor naplózva Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
A szükséges CDS-nézetek azonosítása: Ellenőrizze, hogy elérhetők-e a szabványos SAP S/4HANA CDS-nézetek. Elsősorban az I_JournalEntry (fejléc), az I_OperationalAcctgDocItem (tételek, a BSEG megfelelője), az I_SupplierInvoice (logisztika), az I_PaymentProposalItem (F110) és az I_ChangeDocument (naplókhoz) szükséges.
Felhasználói jogosultságok beállítása: Győződjön meg arról, hogy az adatbázis-felhasználó vagy a technikai szolgáltatásfelhasználó SELECT-jogosultsággal rendelkezik a CDS-entitásokhoz tartozó DDL SQL-nézeteken. Ezt általában az SAP HANA Studio vagy az ABAP Eclipse Development Tools (ADT) segítségével állítják be.
Az SQL-környezet előkészítése: Nyissa meg az SQL-felületet, például az SAP HANA Studiót, a HANA-adatbázishoz csatlakozó DBeavert vagy egy SQL-t fogadó process mining csatlakozót. Ez a módszer közvetlen SQL-hozzáférést feltételez a HANA-réteghez, ahol a CDS-nézetek nézetként érhetők el.
A hatókör meghatározása: Adja meg a vállalatkódot (CompanyCode) és a pénzügyi év tartományát az adatmennyiség korlátozásához. Ez különösen fontos az Operational Accounting Document Item nézet lekérdezésének teljesítménye szempontjából.
A tevékenységlogika megvalósítása: Másolja be az alábbi SQL-lekérdezést. A lekérdezés UNION ALL használatával 14 különálló logikai blokkot egyesít egyetlen eseménynapló-struktúrába. Minden blokk egy adott tevékenységre vonatkozik, például a számla könyvelésére vagy a fizetés kiegyenlítésére.
Módosítási bizonylatok kezelése: A lekérdezés a fizetési feltételek módosítására és a zárolások kezelésére vonatkozó részeket is tartalmaz. Ezek az I_ChangeDocument nézetre támaszkodnak. Ha ez a nézet az Ön S/4-kiadásában nem aktív, előfordulhat, hogy az alapul szolgáló táblákat (CDHDR/CDPOS) egyéni CDS-nézetbe kell foglalnia.
Számított események kezelése: Ellenőrizze a számla esedékességére és az elvesztett pénzügyi engedményre vonatkozó logikát. Ezek az események úgy számíthatók ki, hogy a működési tételnézetben szereplő alapdátumhoz napokat ad hozzá.
Adatkinyerés futtatása: Futtassa a lekérdezést. Nagy adathalmazoknál erősen ajánlott az adatkinyerést pénzügyi év vagy vállalatkód szerint részekre bontani, hogy elkerülje a memória túlterhelését.
Dátumformátumok ellenőrzése: Győződjön meg arról, hogy az EventTime oszlop formátuma YYYY-MM-DD HH:MM:SS. Az SAP HANA SQL időbélyegeit a célalkalmazástól függően esetleg át kell alakítani.
Adatok exportálása: Mentse az eredményt CSV- vagy Parquet-fájlba. Ellenőrizze, hogy az oszlopfejlécek megegyeznek a végső SELECT utasításban megadott oszlopnevekkel.
Átalakítás feltöltéshez: Ha a process mining eszköz meghatározott CSV-formátumot, például egyedi dátummaszkot igényel, végezze el az átalakításokat utófeldolgozó szkripttel vagy az SQL-ben, TO_VARCHAR függvényekkel.
Végső ellenőrzés: Töltsön be egy mintát a ProcessMindba, és ellenőrizze, hogy az esetazonosítóként használt számlaszám megfelelően csoportosítja-e a könyveléstől a kiegyenlítésig tartó összes tevékenységet.
Konfiguráció
- Vállalatkód szerinti szűrés: A lekérdezést korlátozza meghatározott szervezeti egységekre (CompanyCode = '1000') a megfelelő kontextus és teljesítmény érdekében.
- Dátumtartomány: Szűrjön a PostingDate vagy a CreationDate mezőre, például az elmúlt 12 hónapra, az adatmennyiség kezelése érdekében.
- Számlatípus: Az I_OperationalAcctgDocItem nézetben szűrjön FinancialAccountType = 'K' értékre (szállító), így kizárhatja a főkönyvi és vevői tételeket.
- CDS-nézetek aktiválása: Ellenőrizze, hogy az I_JournalEntry, az I_OperationalAcctgDocItem és az I_PaymentProposalItem nézet aktív, és SQL-hozzáférésre ki van-e adva.
- Módosítási napló teljesítménye: Az I_ChangeDocument lekérdezése erőforrásigényes lehet. Korlátozza az allekérdezéseket a 'BELEG' ObjectClass értékre és az olyan konkrét mezőnevekre, mint a ZLSPR és a ZTERM.
Példa-lekérdezés sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Lépések
- Ellenőrizze, hogy rendelkezésre áll-e közvetlen SQL-hozzáférés az SAP HANA-sémához, amely az ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP és a vonatkozó módosítási dokumentumtáblákat tartalmazza. A [Your SAP HANA schema] és a kapcsolati adatok helyére írja be a rendszeréhez jóváhagyott értékeket.
- Határozza meg a vizsgálandó számlákat és a jelentési időszakot. A [Start date] és [End date] helyén adja meg a dátumokat YYYYMMDD formátumban, a [Company code filter] értékét pedig állítsa be érvényes SQL-feltételként, például BUKRS IN ('1000','2000').
- Ellenőrizze az SAP-verziót és a helyi beállításokat a parkolt bizonylatok, a fizetési program állapotmezői, a fizetési bizonylattípusok és a módosítási dokumentumok tárolása szempontjából. A lekérdezés dokumentált forrásobjektumokat és óvatos mező-hozzárendeléseket használ, de éles használat előtt ellenőrizze a helyi bővítéseket és a verziók közötti eltéréseket.
- Futtassa a lekérdezést SAP HANA rendszeren, jóváhagyott SQL-klienssel vagy adatkinyerő szolgáltatással. A lekérdezés minden kifejezetten kinyert tevékenységhez egy eseménysort hoz létre. A ProcessMind nem következtet ki olyan tevékenységekre, amelyek nem szerepelnek az eredményben.
- Vizsgálja át a forrásadatokat, és módosítsa a megjelölt konfigurációs feltételeket a parkolt állapot, a fizetési bizonylattípusok, a fizetési javaslat és a fizetési futás állapota, valamint a módosítási dokumentumok objektumosztályai szerint. Ne bővítse ezeket a feltételeket anélkül, hogy egyeztetné az esetleges duplikált vagy nem kapcsolódó könyvelési bizonylatokat.
- Ellenőrizze az összekapcsolásokat az InvoiceNumber, CompanyCode, pénzügyi év, könyvelési bizonylatszám, szállítói szám és szükség esetén tételsor alapján. Győződjön meg arról, hogy a számlabizonylat-számok következetesen szerepelnek a BKPF, BSEG, ACDOCA, REGUH és REGUP táblákban a célrendszerben.
- Egyeztesse a számított eseményeket. Az Invoice Due esemény a számított nettó esedékesség napján jön létre. A Cash Discount Lost esemény a legkorábbi alkalmazható engedményes határidőre kerül, ha addig nem történt kifizetés. Ezek származtatott sorok, ezért különböztesse meg őket a forrásrekordokból származó eseményektől.
- Exportálja az eredményt lapos, UTF-8 kódolású CSV-fájlként vagy más, a ProcessMind által támogatott táblázatos formátumban. Őrizze meg pontosan az InvoiceNumber, Activity, EventTime, SourceSystem és LastDataUpdate oszlopneveket. Minden eseményhez egy sort használjon, és ne vonja össze a tevékenységeket számlánként.
- Töltse fel az eseménynaplót a ProcessMindba. Az InvoiceNumber mezőt rendelje az esetazonosítóhoz, az Activity mezőt a tevékenység nevéhez, az EventTime mezőt pedig az esemény időbélyegéhez. A többi oszlopot a ProcessMind importbeállításainak megfelelően rendelje az esemény- vagy esetattribútumokhoz.
Konfiguráció
- Dátumtartomány: Az első adatkinyeréshez használjon gördülő, 3–6 hónapos időszakot. A könyvelési dátumra, a módosítás dátumára és a fizetési program dátumára vonatkozó feltételeket következetesen alkalmazza. Hosszú fizetési határidők ellenőrzésekor bővítse az időszakot.
- Séma: A [Your SAP HANA schema] helyére annak a sémának a nevét írja, amely az SAP-objektumokat tartalmazza. Ellenőrizze, hogy a környezet a kiválasztott sémán keresztül teszi-e elérhetővé a kliensfüggő objektumokat, vagy külön kliensfeltételre van szükség.
- Vállalat szerinti szűrés: A [Company code filter] beállításával korlátozza a BUKRS értékét a szükséges vállalatkódokra. Ugyanezt a hatókört alkalmazza a BKPF, BSEG, ACDOCA, REGUH, REGUP és a módosítási bizonylatok forrásaira is, ahol ezek a mezők rendelkezésre állnak.
- Bizonylatok szűrése: Ellenőrizze a számlabizonylat-típusra és a fizetési bizonylattípusra vonatkozó feltételeket. A lekérdezés gyakori példákat tartalmaz, de a bizonylattípusok konfigurálhatók, ezért igazítsa őket a célrendszerhez.
- Parkolt számlák: Ellenőrizze, hogyan jelöli a VBKPF vagy a BKPF a parkolt bizonylatok állapotát. A lekérdezés konfigurálható feltételt használ, mert a parkolt állapot kódolása kiadásonként és megvalósításonként eltérhet.
- Fizetési módosítások: Ellenőrizze a módosítási bizonylatok objektumosztályát, táblanevét, mezőneveit és értékábrázolását a BSEG-ZLSPR és BSEG-ZTERM mezőknél. A módosítási bizonylatok tárolását és a mezőneveket a célrendszerben kell ellenőrizni.
- Fizetési program: Ellenőrizze a REGUH és REGUP táblákban a javaslat és a végrehajtás állapotához, a futtatás dátumához és azonosítójához, valamint a könyvelési bizonylat összekapcsolásához használt mezőket. A helyi fizetésiprogram-beállítások befolyásolhatják az elérhető állapotértékeket.
- Teljesítmény: Korlátozza a dátumtartományt és a vállalatkódokat, csak a szükséges oszlopokat válassza ki, és az összekapcsolások előtt alkalmazza a forrásspecifikus szűrőket. Nagy adathalmazoknál hozzon létre szűrt forrásrészhalmazokat, vagy használjon jóváhagyott HANA calculation view-t vagy adatkinyerési sémát.
- Jogosultságok: Olvasási jogosultság szükséges a megfelelő SAP HANA-séma objektumaihoz, valamint a könyvelési, fizetésiprogram- és módosításibizonylat-adatokat megjelenítő nézetekhez. Egyeztessen az SAP-biztonsági és adatirányítási csapatokkal.
- Működési előfeltételek: A megfelelő pénzügyi számviteli, szállítói számlázási, fizetésiprogram- és módosításibizonylat-funkcióknak aktívnak és feltöltöttnek kell lenniük. Ha a megvalósítás nem használ egy forrástáblát, a rendszer kialakításának megfelelő, jóváhagyott helyettesítő forrást állítson be.
- Időbélyegek kezelése: A BKPF és a BSEG általában külön mezőben tárolja a dátumot és az időt. A lekérdezés ezeket időbélyeggé egyesíti. Ellenőrizze a forrásrendszer időzónáját, és végezze el a szükséges átalakítást a ProcessMindba való feltöltés előtt.
- Adatvédelem: A szállítói és könyvelési adatokat korlátozza a jóváhagyott körre, és alkalmazza a szervezet adatmegőrzési, maszkolási és hozzáférési szabályait.
Példa-lekérdezés sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Kezdheti?
Alakítsa pénzügyi adatait hasznosítható elemzésekké, és kezdje el még ma optimalizálni a fizetési ciklusokat. Csapatunk a process mining bevezetésének minden lépésében támogatja.
Fejlessze a szállítói számlák kifizetési folyamatát SAP S/4HANA rendszerben
Szüntesse meg a szűk keresztmetszeteket, és csökkentse 30%-kal a folyamat átfutási idejét.
Nincs szükség bankkártyára. Beállítás 5 perc alatt.