Order to Cash számlázási folyamatának adatsablonja
Order to Cash számlázási folyamatának adatsablonja
- Az alapos elemzéshez javasolt attribútumok
- Követendő folyamatlépések és mérföldkövek
- Gyakorlati útmutató az adatok kinyeréséhez SAP ECC rendszerből
Order to Cash számlázási attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Kezdési idő EventTime | Az időbélyeg azt mutatja, mikor történt egy adott tevékenység vagy esemény. | ||
| Leírás Az esemény időpontja rögzíti a számla életciklusának egyes tevékenységeihez tartozó pontos dátumot és időt. Ez az időbélyeg alapja a process mining minden időalapú elemzésének, így az átfutási idők kiszámításának, a szűk keresztmetszetek feltárásának és a folyamat teljesítménye szolgáltatási szintű megállapodásokhoz viszonyított nyomon követésének. Az attribútum jellemzően több SAP-tábla dátum- és időmezőinek összekapcsolásával áll elő. Ilyen például a könyvelési dátum (BUDAT) és az időmező (UZEIT), amelyek a módosításokat vagy a bizonylatok létrehozását rögzítik. A pontos időbélyegek megbízható eseménynapló és érvényes teljesítményelemzés alapját adják. Miért fontos? Ez az attribútum alapozza meg a teljesítményelemzést: segítségével kiszámíthatók az átfutási idők, az időtartamok és a folyamatlépések közötti várakozási idők. Hol szerezhető be? Több tábla dátum- és időmezőiből áll elő, például a BKPF (BUDAT, CPUTM), a VBRK (ERDAT, ERZET) és a módosításnapló-táblák, például a CDHDR (UDATE, UTIME) adataiból. Példák 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Számlaszám InvoiceNumber | A számlázási bizonylat egyedi azonosítója, amely a számlázási folyamat elsődleges esetazonosítója. | ||
| Leírás A számlaszám, amelyet az SAP-ban számlázási bizonylatszámnak neveznek, minden számlát egyedileg azonosít. A process mining elemzésben ez a CaseId: egyetlen folyamatpéldányba rendezi az összes kapcsolódó tevékenységet, például a létrehozást, a könyvelést, a küldést, a fizetést és a kiegyenlítést. A számlaszám szerinti elemzés megmutatja az egyes számlázási tranzakciók teljes életútját a létrehozástól a végső kiegyenlítésig. Ez szükséges az olyan KPI-k kiszámításához, mint a vevőkövetelések átlagos futamideje (DSO) és a számlázási ciklus teljes hossza. Az eredmények így megbízható alapot adnak a teljesítmény méréséhez és javításához. Miért fontos? Ez az alapvető azonosító teszi lehetővé a számla teljes életútjának nyomon követését, valamint az egyes számlázási tranzakciók átfutási idejének, szűk keresztmetszeteinek és eltéréseinek elemzését. Hol szerezhető be? SAP ECC tábla: VBRK, mező: VBELN Példák 90001234900012359000123690001237 | |||
| Tevékenység ActivityName | Az üzleti esemény vagy a számla életciklusa során végrehajtott lépés neve. | ||
| Leírás Ez az attribútum a számlázási folyamat egy adott műveletét vagy állapotváltozását írja le, például: „Számla létrehozva”, „Számla könyvelve” vagy „Ügyfélfizetés beérkezett”. Ezek a tevékenységek különböző rendszereseményekből, a bizonylatok állapotváltozásaiból vagy a felhasználók által végrehajtott tranzakciókódokból származnak. A tevékenységek sorrendje adja a folyamat menetét, amely a process mining elemzés alapja. A tevékenységek vizsgálatával a szervezet megértheti, milyen lépések történnek, milyen sorrendben és milyen gyakran. Így összevethető a tényleges működés a tervezett folyamattal. Miért fontos? Meghatározza a folyamattérkép lépéseit, így megjeleníthetők és elemezhetők a folyamatmenetek, az eltérések és a szűk keresztmetszetek. Hol szerezhető be? Ez egy több forrásból származtatott fogalmi attribútum. Forrása lehet például a tranzakciókód (CDHDR-TCODE), a bizonylat állapotváltozása (VBUK-FKSTK) vagy a könyvelési bizonylat. Példák Számla kiállítvaSzámla könyvelveFizetési emlékeztető elküldveSzámla kiegyenlítve | |||
| Felhasználónév UserName | Annak a felhasználónak az azonosítója, aki végrehajtotta a tevékenységet vagy létrehozta a bizonylatot. | ||
| Leírás Ez az attribútum rögzíti annak az SAP-felhasználónak az azonosítóját, aki egy adott eseményért felelős, például létrehozott egy számlát vagy könyvelt egy fizetést. Segítségével elemezhető a folyamat emberi oldala. Az adatok alapján megvizsgálhatók a felhasználók és csapatok közötti teljesítménykülönbségek, feltárhatók a képzési igények és az esetleges megfelelési problémák. Az attribútum a felhasználók által végzett manuális tevékenységeket is megkülönbözteti a rendszer- vagy kötegelt felhasználók automatizált lépéseitől. Ez szükséges az automatizáltság méréséhez. Miért fontos? Lehetővé teszi a felhasználói teljesítmény és a munkaterhelés eloszlásának elemzését, valamint a manuális és automatizált tevékenységek megkülönböztetését. Ezzel támogatja az automatizálást és a hatékonyság javítását célzó kezdeményezéseket. Hol szerezhető be? SAP ECC tábla: VBRK, mező: ERNAM (létrehozó); vagy BKPF, mező: USNAM (felhasználónév); vagy CDHDR, mező: USERNAME (felhasználó). Példák JSMITHBW_BATCHLROSSIMKUMAR | |||
| Számla teljes összege TotalInvoiceAmount | A számlázási bizonylat teljes nettó értéke. | ||
| Leírás Ez az attribútum a számla teljes nettó összegét jelöli, adók nélkül. A számla összege a számlázási folyamathoz kapcsolódó fontos pénzügyi adat. Az elemzés során például érték szerint csoportosíthatók a számlák, így megvizsgálható, hogy a nagy és kis összegű számlák folyamata eltér-e. Az összeg alapján rangsorolhatók a követelésbeszedési feladatok, és feltárható, miért tart tovább a nagy összegű számlák jóváhagyása vagy kifizetése. Ez a pénzügyi háttér segít részletesebben elemezni a folyamatot. Miért fontos? Pénzügyi hátteret ad az elemzéshez. A számlaérték alapján például megvizsgálható, hogy a nagy összegű számlák folyamata eltér-e, vagy tovább tart-e a kiegyenlítésük. Hol szerezhető be? SAP ECC tábla: VBRK, mező: NETWR Példák 1500.7525000.00500.0012345.67 | |||
| Számlázási bizonylat típusa BillingDocumentType | A számlázási bizonylat típusát jelölő kód, például számláé, jóváíró számláé vagy terhelési értesítőé. | ||
| Leírás A számlázási bizonylat típusa az üzleti cél szerint sorolja kategóriákba a tranzakciókat. Az „F2” például normál vevőszámlát, a „G2” pedig jóváíró számlát jelöl. Az SAP-ban beállított típus határozza meg, hogyan kell feldolgozni az egyes számlázási bizonylatokat. A process mining elemzésben ez az attribútum lehetővé teszi a különböző számlázási esetek szűrését és összehasonlítását. Az elemzők külön vizsgálhatják a normál számlák és a jóváíró számlák folyamatait, átfutási idejét és problémáit. Az eredmények célzottabb folyamatfejlesztést tesznek lehetővé. Miért fontos? Lehetővé teszi a különböző számlázási folyamatok, például a normál számlák és a jóváíró számlák elkülönítését és elemzését. Ezek folyamata gyakran jelentősen eltér. Hol szerezhető be? SAP ECC tábla: VBRK, mező: FKART Példák F2G2L2IV | |||
| Ügyfélszám CustomerNumber | A számlán szereplő ügyfelet egyedileg azonosító szám. | ||
| Leírás Az ügyfélszám összekapcsolja a számlát az adott ügyféllel vagy üzleti partnerrel. Ez az attribútum lehetővé teszi, hogy az ügyfél jellemzői szerint bontsuk fel és elemezzük a számlázási folyamatot. Az elemzők összehasonlíthatják az egyes ügyfelek vevőköveteléseinek átlagos futamidejét (DSO), azonosíthatják a rendszeresen késve fizető ügyfeleket, és megvizsgálhatják, mennyire tartják be a fizetési feltételeket. Ezek az összefüggések segítenek az ügyfélkapcsolatok kezelésében és az egyes ügyfélcsoportokhoz igazított követelésbeszedési stratégia kialakításában. Miért fontos? Ügyfélközpontú elemzést tesz lehetővé: feltárhatók a fizetési szokások, ügyfelenként mérhető a DSO, és az eredmények alapján alakítható a követelésbeszedés. Hol szerezhető be? SAP ECC tábla: VBRK, mező: KUNRG (fizető) vagy KUNAG (vevő). Példák 100023200541CUST-A487910345 | |||
| Vállalatkód CompanyCode | A számlát kibocsátó jogi személy azonosítója. | ||
| Leírás Az SAP-ban a vállalatkód önálló jogi és számviteli egységet jelöl. Minden pénzügyi tranzakciót, így a számlákat is, egy adott vállalatkódhoz könyvelnek. Ez alapvető szervezeti adat. A process mining elemzésben a vállalatkód segítségével összehasonlítható a különböző jogi személyek számlázási folyamatainak teljesítménye. Így azonosíthatók azok a bevált gyakorlatok, amelyek más egységeknél is alkalmazhatók, és az elemzés a vállalat szervezeti felépítéséhez igazítható. Miért fontos? Lehetővé teszi a folyamatok szűrését és összehasonlítását a különböző jogi személyek között. Ez alapvető a pénzügyi elemzéshez és a szervezeti összehasonlításhoz. Hol szerezhető be? SAP ECC tábla: VBRK, mező: BUKRS Példák 10002000US01DE01 | |||
| Automatizált-e IsAutomated | Jelző, amely megmutatja, hogy a tevékenységet rendszerfelhasználó vagy automatizálás hajtotta-e végre. | ||
| Leírás Ez a számított attribútum logikai jelzőként különbözteti meg a manuális és az automatizált tevékenységeket. Jellemzően a felhasználónév attribútumot veti össze az ismert rendszer- vagy kötegelt felhasználók listájával, például a „BATCHUSER” vagy a „SAPSYSTEM” azonosítóval. A jelzővel mérhető a számlázási folyamat automatizáltsága, ami sok szervezetnél a hatékonyság javításának és a költségek csökkentésének egyik célja. Az automatizált számlázás arányát mérő KPI közvetlenül ebből az attribútumból számítható ki, így nyomon követhető az automatizálási kezdeményezések előrehaladása. Miért fontos? Közvetlenül támogatja az automatizált számlázás arányának kiszámítását, így mérhető a folyamat hatékonysága és az automatizálási projektek eredménye. Hol szerezhető be? A felhasználónév attribútumból származik. A logika például a következő lehet: IF UserName IN ('BATCH', 'SYSTEM', 'RFCUSER') THEN true ELSE false. Példák truefalse | |||
| Bizonylat dátuma DocumentDate | Az eredeti bizonylaton szereplő dátum, amelyet a szállító vagy a létrehozó adott meg. | ||
| Leírás A bizonylat dátuma az eredeti dokumentum kiállításának napja. Számlázás esetén ez jellemzően a számla létrehozásának dátuma, és gyakran ebből számítják a fizetési határidőt. Ez a dátum fontos a pénzügyi jelentésekhez és az olyan mutatók kiszámításához, mint a vevőkövetelések átlagos futamideje (DSO). Az ügyfél szempontjából ez jelöli a követelésbeszedési időszak kezdetét. A bizonylat dátuma és a könyvelési dátum közötti eltérések feltárhatják a beérkező számlák belső feldolgozásának késedelmeit. Miért fontos? A számla korának és a DSO-nak a kiszámítási alapja, ezért fontos viszonyítási pont a pénzügyi és fizetési feltételek elemzéséhez. Hol szerezhető be? SAP ECC tábla: VBRK, mező: FKDAT (számlázási dátum) Példák 2023-04-152023-04-162023-05-20 | |||
| Értékesítési bizonylat száma SalesDocumentNumber | Az eredeti vevői rendelés azonosítója, amelyből a számla készült. | ||
| Leírás Ez az attribútum közvetlenül összekapcsolja a számlát az azt elindító vevői rendeléssel. Ez a nyomon követhetőség szükséges az Order to Cash folyamat teljes körű elemzéséhez. Ha a számlázási folyamatot összekapcsolják az azt megelőző rendelési folyamattal, a szervezet a vevői rendeléstől a pénz beérkezéséig tartó teljes átfutási időt is elemezheti. Így kiderülhet, hogy a számlázás késedelmét az értékesítés, a teljesítés vagy maga a számlázási részleg okozza. Ez teljesebb képet ad a folyamatról. Miért fontos? Összekapcsolja a számlázást a vevői rendeléssel, így lehetővé teszi az Order to Cash folyamat teljes körű elemzését és a részlegek közötti késedelmek feltárását. Hol szerezhető be? SAP ECC tábla: VBRP, mező: VGBEL Példák 100000451000004610000047 | |||
| Értékesítési szervezet SalesOrganization | Az a szervezeti egység, amely a termékek vagy szolgáltatások értékesítéséért felel. | ||
| Leírás Az SAP-ban az értékesítési szervezet felel az áruk és szolgáltatások értékesítéséért, valamint az értékesítési feltételek kialakításáért. Az értékesítési és disztribúciós működés egyik alapvető szervezeti egysége. A process mining elemzésben ez az attribútum az értékesítési struktúra szerint teszi vizsgálhatóvá a számlázási folyamatot. Összehasonlíthatóvá válik a különböző értékesítési szervezetek teljesítménye, így kiderülhet, mely régiók vagy üzletágak számláznak hatékonyabban. Az eredmények segítenek a bevált gyakorlatok egységesítésében. Miért fontos? Lehetővé teszi a különböző értékesítési egységek és régiók teljesítményének összehasonlítását, valamint a bevált gyakorlatok és a fejlesztendő területek azonosítását. Hol szerezhető be? SAP ECC tábla: VBRK, mező: VKORG Példák 1000NA01EU01AP01 | |||
| Fizetési feltételek PaymentTerms | Az eladó által meghatározott értékesítési feltételek, köztük a fizetési ütemezés. | ||
| Leírás A fizetési feltételek határozzák meg, mikor esedékes a fizetés, például „30 napos fizetési határidő” vagy „60 napos fizetési határidő” esetén. Ezeket az ügyféllel egyeztetik, és jelentősen befolyásolják a pénzforgalmat. A fizetési feltételek szerinti elemzésből kiderülhet, hogy bizonyos feltételek hosszabb fizetési ciklussal vagy több késedelmes fizetéssel járnak-e. Ez segíthet kedvezőbb feltételeket kialkudni az ügyfelekkel vagy módosítani a pénzügyi tervezést. A fizetési feltételek a számla fizetési határidejének kiszámításához is szükségesek. Miért fontos? Segít feltárni, hogyan befolyásolják az egyeztetett feltételek az ügyfelek fizetési szokásait és a pénzforgalmat. Az eredmények alapján javíthatók a kereskedelmi megállapodások. Hol szerezhető be? SAP ECC tábla: VBRK, mező: ZTERM Példák Z030Z060Z001 | |||
| Forrásrendszer SourceSystem | Megadja, melyik forrásrendszerből származnak a kinyert adatok. | ||
| Leírás Ez az attribútum azt a nyilvántartó rendszert jelöli, amelyből az adatok származnak. Ha a vállalat több ERP-példányt vagy integrált rendszert használ, a mező segít megkülönböztetni az egyes források adatait. A process mining elemzésben az attribútum az adatok ellenőrzéséhez, valamint a különböző rendszerek vagy szervezeti egységek folyamatainak összehasonlításához szükséges. Az adatkinyerés során jellemzően állandó értékként kerül az adatkészletbe. Miért fontos? Megmutatja az adatok eredetét. Több rendszer használatakor ez segít megőrizni az adatok integritását, és lehetővé teszi az egyes rendszerek külön elemzését. Hol szerezhető be? Az adatkinyerés, -átalakítás és -betöltés (ETL) során hozzáadott, jellemzően állandó érték, amely az adott SAP ECC-példányt azonosítja, például: „ECC_PROD_NA”. Példák SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
| Kiegyenlítés dátuma ClearingDate | Az a dátum, amikor a fizetés beérkezett, és a számlát kiegyenlítették a vevőkövetelések között. | ||
| Leírás A kiegyenlítés dátuma azt mutatja, mikor jelöltek fizetettként, vagyis kiegyenlítettként egy nyitott tételt, például egy számlát a pénzügyi rendszerben. Ez a dátum jelzi, hogy a pénz beérkezett és az elszámolás megtörtént. Ez az Order to Cash ciklus egyik legfontosabb dátuma. A vevőkövetelések átlagos futamidejének (DSO) és a számlától a pénz beérkezéséig tartó teljes ciklusidőnek a kiszámításához ez jelöli a végpontot. A kiegyenlítés dátumának elemzése megmutatja, mennyire hatékony a követelésbeszedés. Miért fontos? A számla életciklusának utolsó lépését jelöli. Ez a DSO és a teljes ciklusidő kiszámításának végpontja, és a pénzbeszedés hatékonyságáról is képet ad. Hol szerezhető be? SAP ECC tábla: BSAD, mező: AUGDT Példák 2023-05-142023-06-012023-06-25 | |||
| Könyvelési dátum PostingDate | Az a dátum, amikor a bizonylatot a pénzügyi könyvelésben rögzítik. | ||
| Leírás A könyvelési dátum határozza meg, melyik pénzügyi időszakban kerül a tranzakció a főkönyvbe. A számvitel és a pénzügyi jelentések szempontjából alapvető adat. A bizonylat létrehozása és könyvelése közötti késedelem a számlázási bizonylatok belső feldolgozásának hiányosságaira utalhat. A process mining elemzésben a könyvelési dátum a számla életciklusának fontos mérföldköve. A számla létrehozása és könyvelése között eltelt idő a számlázási részleg hatékonyságának egyik mérőszáma lehet. Miért fontos? Fontos pénzügyi mérföldkő, amely a számvitelhez is nélkülözhetetlen. A számla létrehozása és könyvelése között eltelt idő a belső feldolgozás hatékonyságát méri. Hol szerezhető be? SAP ECC tábla: BKPF, mező: BUDAT Példák 2023-04-152023-04-172023-05-21 | |||
| Pénznem Currency | A számlán szereplő összegek pénznemkódja. | ||
| Leírás Ez az attribútum jelzi a tranzakció pénznemét, például USD, EUR vagy JPY. Megadja a pénzügyi értékek, például a számla teljes összegének értelmezéséhez szükséges hátteret. Nemzetközi vállalatok adatainak elemzésekor a pénznemmező nélkülözhetetlen a pénzügyi adatok helyes értelmezéséhez és átváltásához. Egységes jelentéskészítést tesz lehetővé, és megakadályozza, hogy az összegeket megfelelő átváltás nélkül összesítsék, ami hibás pénzügyi elemzéshez vezetne. Miért fontos? Megadja a pénzügyi értékek értelmezéséhez szükséges hátteret, és pontos elemzést tesz lehetővé, különösen több pénznem használatakor. Hol szerezhető be? SAP ECC tábla: VBRK, mező: WAERK Példák USDEURGBPJPY | |||
| Számla fizetési határideje InvoiceDueDate | Az a dátum, ameddig az ügyfélnek várhatóan ki kell fizetnie a számlát. | ||
| Leírás A számla fizetési határideje a fizetési feltételekben meghatározott végső dátum. Ez az adat alapvető a vevőkövetelések kezeléséhez és a követelésbeszedés megkezdéséhez. Az időben történő fizetések arányát mérő KPI kiszámításához ezt a dátumot összevetik a tényleges fizetési dátummal. A számlák határidő szerinti elemzése segít a pénzforgalom előrejelzésében és a közelgő vagy lejárt fizetések rangsorolásában. A határidő jellemzően a bázisdátum és a fizetési feltételek alapján számítható ki. Miért fontos? Az időben történő fizetések teljesítményének mércéje, amely szükséges a vevőkövetelések kezeléséhez és a pénzforgalom előrejelzéséhez. Hol szerezhető be? A bázisdátum (BSEG-ZFBDT) és a fizetési feltételek (BSEG-ZTERM) alapján számítható ki. Nem mindig tárolják külön mezőben. Példák 2023-05-152023-05-302023-06-20 | |||
| Tranzakciókód TransactionCode | A tevékenység végrehajtásához használt SAP-tranzakciókód. | ||
| Leírás A tranzakciókód, vagyis a T-Code, az SAP egy adott funkciójának vagy programjának egyedi azonosítója. Ilyen például a számlázási bizonylat létrehozására szolgáló „VF01”. Az eseményekhez rögzített T-Code megmutatja, hogyan hajtották végre a folyamatot a rendszerben. Ez az információ hasznos a kiváltó okok feltárásához. Ha például gyakoriak a hibák, az elemzők ellenőrizhetik, hogy használtak-e nem szabványos tranzakciókódot. A tranzakciókód az aktivitás nevének meghatározásában és a folyamatban használt rendszerfunkciók megértésében is segít. Miért fontos? Megmutatja, hogyan hajtották végre a tevékenységet a rendszerben. Segít feltárni a folyamattól való eltérések okait és azonosítani a nem szabványos felhasználói műveleteket. Hol szerezhető be? SAP ECC tábla: CDHDR, mező: TCODE Példák VF01VF02FB01F-28 | |||
| Utolsó adatfrissítés LastDataUpdate | A forrásrendszerből végzett legutóbbi adatfrissítés vagy adatkinyerés időbélyege. | ||
| Leírás Ez az attribútum jelzi, mikor frissült utoljára az adatkészlet a forrásrendszerből. Segít értelmezni az elemzést, mert megmutatja, mennyire frissek a megjelenített adatok. A dashboardokon és jelentésekben ez az időbélyeg tájékoztatja az érintetteket az adatok aktualitásáról, és jelzi, hogy a legutóbbi tranzakciók mikor válnak láthatóvá. Az érték jellemzően az adatkinyerési folyamat végén jön létre. Miért fontos? Tájékoztat az adatok aktualitásáról, ami fontos az elemzésre épülő működési döntésekhez. Hol szerezhető be? Az adatkinyerés, -átalakítás és -betöltés (ETL) során jön létre és kerül tárolásra. Példák 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Utómunka-e IsRework | Jelző, amely megmutatja, hogy a tevékenység utómunka vagy javítási lépés-e. | ||
| Leírás Ez a számított attribútum az utómunkát jelentő tevékenységeket azonosítja, például a „Számla javítva” eseményt vagy a bizonylat visszafordítását. Jellemzően logikai jelző, amelyet a tevékenység nevéből vagy a javításhoz és sztornózáshoz kapcsolódó tranzakciókódokból, például a számlázási bizonylat sztornózására szolgáló „VF11” kódból származtatnak. A process mining elemzésben ez a jelző számszerűsíti a számlázási folyamatban végzett utómunkát. Közvetlenül támogatja az olyan KPI-k mérését, mint a számlajavítási arány, és láthatóvá teszi az utómunka ismétlődő köreit a folyamattérképen. Így feltárhatók azok a hatékonysági és minőségi problémák, amelyek növelik a működési költségeket és késleltetik a fizetést. Miért fontos? Megmutatja, mennyi munka megy el a hibák javítására, így számszerűsíthetők a folyamat hiányosságai és a minőségi problémák, valamint mérhetők az utómunkához kapcsolódó KPI-k. Hol szerezhető be? A tevékenység nevéből vagy a tranzakciókódból származik. Például: IF ActivityName = 'Invoice Corrected' OR TransactionCode = 'VF11' THEN true ELSE false. Példák truefalse | |||
Order to Cash számlázási tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Számla elküldve az ügyfélnek | Azt jelzi, hogy a számlát meghatározott csatornán, például nyomtatva, e-mailben vagy EDI-n keresztül elküldték az ügyfélnek. Az esemény általában a kimenetkezelő rendszer naplóiból rögzíthető. | ||
| Miért fontos? Ez fontos mérföldkő, mert ekkor indul az ügyfél fizetési határidejének számítása. Az itt jelentkező késedelem közvetlenül befolyásolja, mikorra várható a fizetés, és rontja a beszedés hatékonyságát. Hol szerezhető be? Az esemény a számlához tartozó kimenettípus feldolgozási dátuma és időpontja alapján állapítható meg az üzenetállapotokat tároló NAST táblából. Rögzítés A NAST táblában szereplő, „1” feldolgozási állapotú, vagyis sikeresen feldolgozott bejegyzés alapján állapítható meg. Eseménytípus inferred | |||
| Számla kiállítva | A számlázási bizonylat létrehozását jelzi a rendszerben. Az esemény akkor rögzíthető, amikor a BKPF könyvelési bizonylatfej-táblában új bejegyzés jön létre a számlákhoz tartozó bizonylattípussal. | ||
| Miért fontos? Ez a teljes számlázási folyamat kezdőpontja. Az eseménytől eltelt idő elemzésével mérhető a számlakészítési ciklusidő, és ez az alapja a Days Sales Outstanding (DSO) kiszámításának. Hol szerezhető be? A BKPF táblában rögzítik. Az eseményt az adott bizonylatszámhoz (BELNR) tartozó létrehozási dátum (CPUDT) és idő (CPUTM) jelöli. A bizonylattípus (BLART) azonosítja a számlát. Rögzítés A számlabizonylat BKPF táblában rögzített létrehozási időbélyege (CPUDT) alapján. Eseménytípus explicit | |||
| Számla kiegyenlítve | A sikeresen kifizetett számla végleges állapota. A nyitott tételt a hozzá tartozó fizetéssel vagy jóváíró bizonylattal lezárták, így a számla teljes egészében kiegyenlítettnek tekinthető. | ||
| Miért fontos? A számlához tartozó, megrendeléstől a pénz beérkezéséig tartó folyamat sikeres lezárását jelzi. Ez a fő záróesemény az átlagos számlázási ciklusidő méréséhez. Hol szerezhető be? Akkor következik be, amikor a számlatételhez tartozó kiegyenlítési bizonylatszám (AUGBL) és kiegyenlítési dátum (AUGDT) mezője kitöltődik a BSEG táblában. Rögzítés Az esemény a számlatételhez tartozó, BSEG táblában rögzített kiegyenlítési dátumon (AUGDT) következik be. Eseménytípus explicit | |||
| Számla könyvelve | A számlát hivatalosan rögzítették a vevőkövetelések analitikájában és a főkönyvben. Ezzel a számla jogilag kötelezővé válik, és megjelenik az ügyfél tartozása. | ||
| Miért fontos? Ez fontos mérföldkő, mert ekkor indul a beszedési idő számítása. A számla kiállítása és könyvelése közötti idő megmutathatja a pénzáramlást befolyásoló belső feldolgozási késedelmeket. Hol szerezhető be? A BKPF táblában rögzítik. Az eseményt a bizonylatszámhoz (BELNR) tartozó könyvelési dátum (BUDAT) jelöli. Előzetesen rögzített bizonylat esetén ekkor válik a bizonylat könyveltté. Rögzítés A számlabizonylat BKPF táblában rögzített könyvelési dátuma (BUDAT) alapján. Eseménytípus explicit | |||
| Ügyfélfizetés beérkezett | Az ügyfél befizetése beérkezett, és készpénzbevételként vagy banki jóváírásként rögzítették a rendszerben. Ekkor külön fizetési bizonylat jön létre, amelyet még nem rendeltek hozzá az adott számlához. | ||
| Miért fontos? Ez fontos mérföldkő a pénzkonverziós ciklusban. A számla elküldése és a fizetés beérkezése közötti idő a Days Sales Outstanding (DSO) egyik fő összetevője. Hol szerezhető be? Új bizonylatként rögzítik a BKPF és a BSEG táblában, jellemzően az ügyfélfizetést jelölő „DZ” bizonylattípussal. Az eseményt a könyvelési dátum (BUDAT) jelöli. Rögzítés Az ügyfélfizetési bizonylat BKPF táblában rögzített könyvelési dátuma alapján. Eseménytípus explicit | |||
| Elérkezett a számla fizetési határideje | Számított esemény, amely a fizetési feltételek szerinti hivatalos esedékesség napját jelöli. Nem felhasználó vagy rendszer által végrehajtott tevékenység, hanem egy fontos időpont. | ||
| Miért fontos? A fizetési szokások és a megfelelés elemzéséhez elengedhetetlen. Ez az alapja annak, hogy megállapítsuk, időben vagy késve fizettek-e, és kiszámítsuk a határidőre történő fizetések arányát mérő KPI-t. Hol szerezhető be? Az esemény az aktuális dátum és a nettó esedékességi dátum összevetésével határozható meg. Az esedékességi dátum a BSEG-ZFBDT mezőben található, vagy a bázisdátum és a fizetési feltételek alapján számítható ki. Rögzítés Hasonlítsa össze a rendszer dátumát a számlatétel BSEG táblában szereplő nettó esedékességi dátumával. Eseménytípus calculated | |||
| Fizetés hozzárendelve a számlához | A beérkezett ügyfélfizetést egyeztették az adott nyitott számlával, és hozzárendelték ahhoz, hogy a tétel kiegyenlíthető legyen. Ez az egyeztetési lépés kapcsolja össze a fizetést a tartozással. | ||
| Miért fontos? Ez a tevékenység elengedhetetlen a beérkező fizetések számlákhoz rendelésének ciklusidejéhez. Ha a befizetést későn rendelik a számlához, a vevőkövetelések tényleges állapota pontatlannak tűnhet, és a rendelkezésre álló pénz is rejtve maradhat. Hol szerezhető be? Az esemény a kiegyenlítési tranzakcióból, például az F-32-ből állapítható meg, amely kitölti a számlatétel kiegyenlítési mezőit. Az esemény időpontja a kiegyenlítés dátuma. Rögzítés Az esemény abból állapítható meg, hogy a számlatétel BSEG táblájában kitöltötték a kiegyenlítés dátumát (AUGDT). Eseménytípus inferred | |||
| Fizetési emlékeztető elküldve | A rendszer fizetési felszólítást vagy emlékeztetőt készített, és elküldte az ügyfélnek egy lejárt számla miatt. Az esemény a felszólítási előzmények naplóiból rögzíthető. | ||
| Miért fontos? Segít felmérni a beszedési stratégia eredményességét. Az emlékeztető és a fizetés beérkezése közötti idő elemzése fontos a fizetési emlékeztetők eredményességét mérő KPI-hoz. Hol szerezhető be? A felszólítási adatokat tároló táblákban rögzítik, különösen az MHNK (felszólítási adatok fejléce) és az MHND (felszólítási adatok tételei) táblában. Ezeket a felszólítási futtatás hozza létre az F150 tranzakcióval. Rögzítés A lejárt tételre vonatkozó felszólítási futtatás (F150) végrehajtásakor kerül a naplóba. Eseménytípus explicit | |||
| Számla előzetesen rögzítve | A számlabizonylatot előzetes állapotban mentették el, de még nem könyvelték a főkönyvbe. Ezt gyakran akkor alkalmazzák, ha hiányosak az adatok, vagy a végleges könyvelés előtt ellenőrzésre van szükség. | ||
| Miért fontos? Nyomon követi a könyvelés előtti lépéseket és az esetleges késedelmeket. Ha a bizonylat sokáig előzetes állapotban marad, az adatok minőségi problémájára vagy az előzetes jóváhagyás szűk keresztmetszetére utalhat. Hol szerezhető be? Az előzetesen rögzített bizonylatokat a VBKPF tábla tárolja. A tevékenységet egy később könyvelt bizonylat létrehozása jelzi ebben a táblában. Rögzítés Az előzetesen rögzített bizonylat mentésekor, például az FV70 tranzakcióval, kerül a naplóba. Eseménytípus explicit | |||
| Számla javítva | Újramunkálást jelez: az eredeti számláról kiderült, hogy hibás, ezért később visszafordították. Az esemény az eredeti számlához kapcsolódó sztornóbizonylatok azonosításával rögzíthető. | ||
| Miért fontos? Feltárja a folyamat hatékonysági és minőségi problémáit. A gyakori javítások a korábbi értékesítési vagy számlázási adatok hibáira utalnak, és segítik a Számlajavítások és hibaarányok dashboard elemzését. Hol szerezhető be? Az esemény egy olyan sztornóbizonylat megkeresésével azonosítható, amelynek BKPF-STBLG mezője az eredeti bizonylatra mutat. Az esemény a sztornóbizonylat létrehozása. Rögzítés A sztornóbizonylat létrehozásakor kerül a naplóba, például az FB08 tranzakció használatakor. Eseménytípus explicit | |||
| Számla jóváhagyva | A számla hivatalos jóváhagyását jelzi, amely lehetővé teszi a könyvelést vagy a számla ügyfélnek történő elküldését. Ez gyakran abból állapítható meg, hogy az előzetesen rögzített bizonylat könyveltté válik. | ||
| Miért fontos? Nyomon követi a belső jóváhagyási munkafolyamatot, amely gyakran szűk keresztmetszetet jelent. Az esemény elemzésével a Számlajóváhagyási folyamat elemzése dashboardon azonosíthatók a lassan jóváhagyó felhasználók. Hol szerezhető be? Az esemény az előzetesen rögzített bizonylat VBKPF táblában jelzett állapotából a BKPF táblában jelzett könyvelt állapotba való átmenet alapján állapítható meg. Ha a szervezet workflow-rendszert használ, az esemény a workflow-naplókban is szerepelhet. Rögzítés Hasonlítsa össze az előzetes bizonylat létrehozási dátumát (VBKPF) a végleges bizonylat könyvelési dátumával (BKPF). Eseménytípus inferred | |||
| Számla leírva | Alternatív végállapot: a számlát behajthatatlannak minősítették, a fennálló összeget pedig behajthatatlan követelésként vezették ki. A számlát ügyfélfizetés nélkül zárják le. | ||
| Miért fontos? Kedvezőtlen folyamatkimenetelt és bevételkiesést jelez. Az ilyen események nyomon követése segít feltárni a behajthatatlan követelések okait és javítani a hitelkezelési szabályokon. Hol szerezhető be? A számlához kapcsolódó kiegyenlítési tranzakció elemzéséből következtethető ki. Ha a kiegyenlítési bizonylat egy meghatározott behajthatatlan követelések ráfordítására szolgáló főkönyvi számlára könyvel, a számlát leírtnak tekintjük. Rögzítés Akkor következtethető ki, ha a kiegyenlítési tranzakció során könyvelés történik egy kijelölt, behajthatatlan követelésekre szolgáló főkönyvi számlára. Eseménytípus inferred | |||
| Vitaügy létrehozva | Hivatalos vitát rögzítettek a számlával kapcsolatban, jellemzően ügyfélpanasz miatt. Az eseményt az SAP Dispute Management rendszer tárolja. | ||
| Miért fontos? Azonosítja a késedelmes fizetés kockázatának kitett számlákat, és feltárja az ügyfél-elégedetlenség mögött álló problémákat. Ezzel kezdetét veszi egy fontos kivételkezelési folyamat. Hol szerezhető be? Az esemény a számla könyvelési bizonylatához kapcsolódó vitaügy létrehozásakor rögzíthető az UDM_CASE táblából. Rögzítés Akkor kerül a naplóba, amikor egy felhasználó az UDM_DISPUTE tranzakcióval vitaügyet hoz létre. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Az ABAP-szerkesztő megnyitása: Jelentkezzen be az SAP ECC rendszerbe. Nyissa meg az ABAP-szerkesztőt az
SE38tranzakciókóddal. - Program létrehozása: Adjon nevet az új programnak a Program mezőben, például
Z_PM_O2C_INVOICE_EXTRACT, majd kattintson a Létrehozás gombra. Adjon meg egy leíró címet, a program típusaként pedig válassza a „Végrehajtható program” lehetőséget. - Kiválasztási képernyő meghatározása: A program forráskódjában adja meg a kiválasztási képernyő paramétereit. Ezekkel szűrhetők az adatok a kinyerés előtt. A fontos paraméterek közé tartozik a bizonylat létrehozási dátumának tartománya (
S_ERDAT), a vállalatkód (S_BUKRS) és a számlázási bizonylat típusa (S_VBTYP). - Adatszerkezetek meghatározása: Deklaráljon egy belső táblát a végleges eseménynapló adatainak tárolására. A szerkezetnek tartalmaznia kell az
InvoiceNumber,ActivityNameésEventTimemezőket, valamint az ajánlott attribútumokat, például aUserName,BillingDocumentType,CustomerNumber,CompanyCodeésTotalInvoiceAmountmezőket. - Adatkiválasztási logika megírása: Írja meg az adatok kiválasztásához szükséges ABAP-logikát. Először válassza ki az elsődleges számlázási bizonylatokat a
VBRKésBKPFtáblákból a kiválasztási képernyőn megadott feltételek alapján. Az eredményeket tárolja egy ideiglenes belső táblában. - Tevékenységek kinyerése: Járja végig a számlázási bizonylatok listáját. Minden bizonylathoz végezzen további lekérdezéseket a különböző táblákból, hogy azonosítsa a 13 szükséges tevékenységet. Például a
NASTtáblában keresse a „Számla elküldve az ügyfélnek” eseményeket, aBSEGtáblában a kiegyenlítés adatait („Számla kiegyenlítve”, „Fizetés hozzárendelve”), azMHNKtáblában pedig a fizetési felszólítások adatait („Fizetési emlékeztető kiküldve”). - Eseménynapló-tábla összeállítása: Az előző lépésben talált minden tevékenységhez hozzon létre egy rekordot a végleges eseménynapló belső táblájában. Ügyeljen arra, hogy az
InvoiceNumber,ActivityName,EventTimeés a többi attribútum a megfelelő forrástáblából származó értéket kapja. - Fájl írása az alkalmazáskiszolgálóra: A ciklus végén, miután az eseménynapló-tábla minden rekordja elkészült, az
OPEN DATASET,LOOP AT... TRANSFERésCLOSE DATASETutasításokkal írja ki a belső tábla tartalmát egy egyszerű szöveges fájlba az SAP alkalmazáskiszolgálón. Adjon meg egy elérhető logikai fájlútvonalat. - Fájl lekérése: Az
AL11tranzakciókóddal nyissa meg az alkalmazáskiszolgáló könyvtárait, és keresse meg a létrehozott fájlt. Egyeztessen az SAP Basis csapattal, hogy a fájlt letölthesse a kiszolgálóról a saját gépére vagy egy megosztott hálózati helyre. - Végső formázás: Nyissa meg a letöltött fájlt, és ellenőrizze, hogy fejlécsort tartalmazó, vesszővel tagolt CSV-fájl-e. A ProcessMindbe való feltöltéshez UTF-8 kódolással mentse.
Konfiguráció
- Előfeltételek: Jogosultság ABAP-programok létrehozására és futtatására (
SE38tranzakció). Olvasási jogosultság az FI- és SD-táblákhoz, többek között aVBRK,VBRP,BKPF,BSEG,NAST,MHNKésUDM_CASE_ATTR00táblákhoz (Dispute Management). - Dátumtartomány kiválasztása: A programban kötelezően meg kell adni egy dátumtartományt, jellemzően a bizonylat létrehozási dátuma (
ERDATa VBRK/BKPF táblában) alapján. Az első adatkinyeréshez 3–6 hónapos időszakot javaslunk, hogy az adatmennyiség kezelhető maradjon. - Fontos szűrők: Mindig szűrjön a vállalatkód (
CompanyCode,BUKRS) alapján, hogy korlátozza a kinyerés hatókörét. Javasoljuk a számlázási bizonylat típusa (VBRK-ból aVBTYP) vagy a könyvelési bizonylat típusa (BKPF-ből aBLART) szerinti szűrést is. Így csak a releváns számlatípusok kerülnek be, például a normál könyvelési számlákhoz használt „RV” típus, a jóváíró bizonylatok és más dokumentumok pedig kimaradnak. - Teljesítmény: Ha az adatállomány több hónapra terjed ki, a munkamenet időtúllépésének elkerülése érdekében futtassa a programot háttérfeladatként. Az ABAP-logikát optimalizálja indexelt táblalekérdezésekre, és kerülje az adatbázis-lekérdezéseket tartalmazó egymásba ágyazott ciklusokat. Először töltse az adatokat belső táblákba, majd azokkal dolgozzon.
- Kimeneti fájl beállítása: Az ABAP-kódban adja meg az alkalmazáskiszolgálón használt kimeneti fájl útvonalát és a CSV-elválasztó karaktert, amely általában vessző vagy pontosvessző. Az útvonal egy globálisan beállított, elérhető könyvtárra mutasson.
Példa-lekérdezés abap
REPORT Z_PM_O2C_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables
*&---------------------------------------------------------------------*
TABLES: VBRK, BKPF.
*&---------------------------------------------------------------------*
*& Type Definitions for Event Log Output
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoicenumber TYPE vbrk-vbeln,
activityname TYPE string,
eventtime TYPE timestamp,
username TYPE xubname,
billingdocumenttype TYPE vbrk-vbtyp,
customernumber TYPE vbrk-kunnr,
companycode TYPE vbrk-bukrs,
totalinvoiceamount TYPE vbrk-netwr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: BEGIN OF gs_invoice,
vbeln TYPE vbrk-vbeln, " SD Doc (Invoice)
awkey TYPE bkpf-awkey, " Accounting Doc Reference Key
bukrs TYPE vbrk-bukrs, " Company Code
kunnr TYPE vbrk-kunnr, " Customer
vbtyp TYPE vbrk-vbtyp, " SD Doc Type
netwr TYPE vbrk-netwr, " Net Value
waerk TYPE vbrk-waerk, " Currency
fkdat TYPE vbrk-fkdat, " Billing Date
erdat TYPE vbrk-erdat, " Creation Date
erzet TYPE vbrk-erzet, " Creation Time
ernam TYPE vbrk-ernam, " Creator
belnr TYPE bkpf-belnr, " Acct Doc
gjahr TYPE bkpf-gjahr, " Fiscal Year
cpudt TYPE bkpf-cpudt, " Acct Doc Entry Date
cputm TYPE bkpf-cputm, " Acct Doc Entry Time
usnam TYPE bkpf-usnam, " Acct Doc User
stblg TYPE bkpf-stblg, " Reversal Doc
END OF gs_invoice.
DATA: gt_invoices LIKE TABLE OF gs_invoice.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbrk-erdat OBLIGATORY,
s_bukrs FOR vbrk-bukrs OBLIGATORY,
s_vbtyp FOR vbrk-vbtyp.
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/trans/tmp/invoice_extract.csv' OBLIGATORY.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" 1. Select base set of invoices
SELECT vbrk~vbeln, vbrk~bukrs, vbrk~kunnr, vbrk~vbtyp, vbrk~netwr, vbrk~waerk,
vbrk~fkdat, vbrk~erdat, vbrk~erzet, vbrk~ernam,
bkpf~belnr, bkpf~gjahr, bkpf~cpudt, bkpf~cputm, bkpf~usnam, bkpf~stblg, bkpf~awkey
INTO CORRESPONDING FIELDS OF TABLE gt_invoices
FROM vbrk
INNER JOIN bkpf ON bkpf~awkey = vbrk~vbeln AND bkpf~awtyp = 'VBRK'
WHERE vbrk~erdat IN s_erdat
AND vbrk~bukrs IN s_bukrs
AND vbrk~vbtyp IN s_vbtyp.
IF gt_invoices IS INITIAL.
MESSAGE 'No invoices found for the selected criteria.' TYPE 'I'.
RETURN.
ENDIF.
LOOP AT gt_invoices INTO gs_invoice.
CLEAR gs_event_log.
gs_event_log-invoicenumber = gs_invoice-vbeln.
gs_event_log-billingdocumenttype = gs_invoice-vbtyp.
gs_event_log-customernumber = gs_invoice-kunnr.
gs_event_log-companycode = gs_invoice-bukrs.
gs_event_log-totalinvoiceamount = gs_invoice-netwr.
" Activity: Invoice Generated (using accounting doc creation)
gs_event_log-activityname = 'Invoice Generated'.
gs_event_log-username = gs_invoice-usnam.
CONCATENATE gs_invoice-cpudt gs_invoice-cputm INTO DATA(lv_ts_gen).
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Posted (same as generated for non-parked docs)
gs_event_log-activityname = 'Invoice Posted'.
gs_event_log-username = gs_invoice-usnam.
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Approved (inferred by posting)
gs_event_log-activityname = 'Invoice Approved'.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Sent To Customer
SELECT SINGLE addat, aduhr FROM nast
INTO (DATA(lv_nast_date), DATA(lv_nast_time))
WHERE kappl = 'V3' AND objky = gs_invoice-vbeln AND vszst > '0'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Sent To Customer'.
gs_event_log-username = sy-uname.
CONVERT DATE lv_nast_date TIME lv_nast_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Corrected / Reversed
IF gs_invoice-stblg IS NOT INITIAL.
SELECT SINGLE cpudt, cputm, usnam FROM bkpf
INTO (DATA(lv_rev_date), DATA(lv_rev_time), DATA(lv_rev_user))
WHERE belnr = gs_invoice-stblg AND gjahr = gs_invoice-gjahr.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Corrected'.
gs_event_log-username = lv_rev_user.
CONVERT DATE lv_rev_date TIME lv_rev_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
" Activity: Payment Applied, Cleared, Due Date, Written Off (from BSEG)
SELECT SINGLE augdt, augbl, zfBDT, hkont FROM bseg
INTO (DATA(lv_augdt), DATA(lv_augbl), DATA(lv_zfbdt), DATA(lv_hkont))
WHERE bukrs = gs_invoice-bukrs
AND belnr = gs_invoice-belnr
AND gjahr = gs_invoice-gjahr
AND koart = 'D'. " Customer line
IF sy-subrc = 0.
" Due Date Reached (Calculated event)
IF lv_zfbdt IS NOT INITIAL.
gs_event_log-activityname = 'Invoice Due Date Reached'.
gs_event_log-username = 'System'.
CONVERT DATE lv_zfbdt INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Cleared, Applied, Write-Off
IF lv_augdt IS NOT INITIAL.
SELECT SINGLE usnam, cpudt, cputm, blart FROM bkpf
INTO (DATA(lv_clear_user), DATA(lv_clear_date), DATA(lv_clear_time), DATA(lv_clear_type))
WHERE belnr = lv_augbl AND bukrs = gs_invoice-bukrs.
IF sy-subrc = 0.
gs_event_log-username = lv_clear_user.
CONVERT DATE lv_clear_date TIME lv_clear_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
IF lv_clear_type = 'DZ'. " Standard Customer Payment
gs_event_log-activityname = 'Customer Payment Received'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Payment Applied To Invoice'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Invoice Cleared'. APPEND gs_event_log TO gt_event_log.
ELSE. " Assuming other clearing doc types could be write-offs
gs_event_log-activityname = 'Invoice Written Off'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
" Activity: Payment Reminder Issued (Dunning)
SELECT COUNT(*) FROM mhnk WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
IF sy-subrc = 0 AND sy-dbcnt > 0.
SELECT SINGLE lafdn FROM mhnk
INTO DATA(lv_dunning_date)
WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
gs_event_log-activityname = 'Payment Reminder Issued'.
gs_event_log-username = 'System'.
CONVERT DATE lv_dunning_date INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Parked (Example from VBKPF, may require system specific logic)
SELECT SINGLE cpudt, cputm, usnam FROM vbkpf
INTO (DATA(lv_park_date), DATA(lv_park_time), DATA(lv_park_user))
WHERE awkey = gs_invoice-vbeln AND awsys = 'LOG' AND bstat = 'V'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Parked'.
gs_event_log-username = lv_park_user.
CONVERT DATE lv_park_date TIME lv_park_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Dispute Case Created (Requires Dispute Management module)
SELECT SINGLE create_date, create_time, create_user FROM udm_case_attr00
INTO (DATA(lv_disp_date), DATA(lv_disp_time), DATA(lv_disp_user))
WHERE [Your logic to link invoice to dispute case, e.g., via a custom field or object link].
IF sy-subrc = 0.
gs_event_log-activityname = 'Dispute Case Created'.
gs_event_log-username = lv_disp_user.
CONVERT DATE lv_disp_date TIME lv_disp_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Write data to file
*&---------------------------------------------------------------------*
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
" Header
DATA(lv_header) = 'InvoiceNumber,ActivityName,EventTime,UserName,BillingDocumentType,CustomerNumber,CompanyCode,TotalInvoiceAmount'.
TRANSFER lv_header TO p_path.
LOOP AT gt_event_log INTO gs_event_log.
DATA(lv_line) = |
{ gs_event_log-invoicenumber }|
,{ gs_event_log-activityname }|
,{ gs_event_log-eventtime }|
,{ gs_event_log-username }|
,{ gs_event_log-billingdocumenttype }|
,{ gs_event_log-customernumber }|
,{ gs_event_log-companycode }|
,{ gs_event_log-totalinvoiceamount }|.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: 'Extraction complete. File created at:', p_path. Lépések
- Előfeltételek és hozzáférés: Gondoskodjon róla, hogy rendelkezzen csak olvasási jogosultságú adatbázis-felhasználóval a szükséges SAP ECC-táblákhoz, többek között a VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE táblákhoz és a lekérdezésben felsorolt egyéb táblákhoz. Ilyen hozzáférést általában csak rendszergazdák vagy kijelölt adatelemző csapatok kapnak.
- Kapcsolódás az adatbázishoz: Csatlakozzon az SAP ECC-adatbázishoz egy szabványos SQL-klienssel, például a DBeaver, az Oracle SQL Developer vagy a Microsoft SQL Server Management Studio használatával.
- SQL-lekérdezés előkészítése: Másolja a „query” szakaszban megadott teljes SQL-lekérdezést az SQL-kliens szerkesztőjébe.
- Helyőrzők testreszabása: A lekérdezésben több helyőrzőt kell a saját környezetének megfelelő értékre cserélnie:
'YYYYMMDD': Cserélje le minden előfordulását az elemzéshez kívánt időszak kezdő- és záródátumára. Az adatokat mindenképpen szűrje kezelhető időszakra.'XXXX': Adja meg az elemezni kívánt vállalatkódot vagy vállalatkódokat.[Your Invoice Output Type]: Adja meg az ügyfeleknek küldött számlák kimenettípus-kódját, például az „RD00” értéket.[Your Bad Debt G/L Account]: Adja meg a behajthatatlan számlák leírására használt főkönyvi számlaszámot.[Your Dispute Case Invoice Attribute]: Adja meg a Dispute Management beállításában a számlaszám tárolására használt attribútum nevét, például az „INVOICE_ID” értéket.
- Időbélyeg-függvények ellenőrzése: A lekérdezés általános
CAST(CONCAT(date_field, time_field) AS TIMESTAMP)szintaxist használ. Előfordulhat, hogy ezt az adatbázisához kell igazítania, például Oracle eseténTO_TIMESTAMP, SQL Server esetén pedigDATETIMEFROMPARTShasználatával. - Lekérdezés futtatása: Futtassa a módosított lekérdezést. A futás az SAP-táblák méretétől és a kiválasztott időszaktól függően sokáig tarthat.
- Eredmények ellenőrzése: A lekérdezés lefutása után ellenőrizze, hogy a kimenet tartalmazza-e a várt oszlopokat: InvoiceNumber, ActivityName, EventTime és az ajánlott attribútumok. Nézze meg, hogy nincs-e hiba vagy üres eredmény.
- Exportálás CSV-be: Exportálja a teljes eredményhalmazt az SQL-kliensből CSV-fájlba. A speciális karakterek megőrzéséhez UTF-8 kódolással mentse a fájlt.
- Feltöltés előkészítése: Mielőtt feltölti az adatokat egy process mining eszközbe, ellenőrizze, hogy a CSV oszlopfejlécei pontosan megegyeznek-e a szükséges attribútumnevekkel, például:
InvoiceNumber,ActivityName,EventTime,UserName.
Konfiguráció
- Adatbázis-kapcsolat: Közvetlen, csak olvasási jogosultságú SQL-kapcsolat szükséges az SAP ECC alapjául szolgáló adatbázishoz. Ez a módszer teljesen megkerüli az SAP alkalmazási rétegét.
- Jogosultságok: Az adatbázis-felhasználónak
SELECTjogosultsággal kell rendelkeznie a lekérdezésben használt összes táblához. Ezek az FI-, SD- és esetleg FSCM-modulok tábláit is magukban foglalják. - Dátumtartomány: A megfelelő teljesítmény és adatmennyiség érdekében elengedhetetlen, hogy a lekérdezést meghatározott időszakra szűrje. Kezdésként 3–6 hónapot javaslunk. A
'YYYYMMDD'dátumszűrő helyőrzőit a lekérdezés több pontján is be kell állítani. - Vállalatkód szerinti szűrés: A lekérdezést vállalatkód (
BUKRS) szerinti szűrésre tervezték. Egyszerre egy vagy néhány vállalatkód elemzése bevett gyakorlat. - Bizonylattípusok beállítása: Az olyan események azonosítása, mint a számlajavítás, a leírás vagy a bizonylat elküldése, a szabványos SAP-beállításoktól függ. Módosítsa a lekérdezést, ha a szervezet egyéni bizonylattípusokat (
BLART), kimenettípusokat (KSCHL) vagy főkönyvi számlákat használ ezekhez a folyamatokhoz. - Teljesítmény: A lekérdezés futtatása éles SAP-rendszeren jelentős erőforrásokat vehet igénybe, és lassíthatja a működést. Nagyobb adatkinyerést lehetőleg csúcsidőn kívül vagy az adatbázis külön riportkészítő másolatán végezzen.
Példa-lekérdezés sql
WITH InvoiceBase AS (
SELECT
VBRK.VBELN AS InvoiceNumber,
VBRK.FKART AS BillingDocumentType,
VBRK.KUNRG AS CustomerNumber,
VBRK.BUKRS AS CompanyCode,
VBRK.NETWR AS TotalInvoiceAmount,
VBRK.ERNAM AS CreatorName,
VBRK.ERDAT AS CreationDate,
VBRK.ERZET AS CreationTime
FROM VBRK
WHERE VBRK.ERDAT BETWEEN '20230101' AND '20231231' -- Filter by Invoice Creation Date
AND VBRK.BUKRS IN ('1000') -- Filter by Company Code
AND VBRK.FKART NOT IN ('S1', 'S2') -- Exclude cancelled invoices
)
-- 1. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS ActivityName,
CAST(CONCAT(ib.CreationDate, ib.CreationTime) AS TIMESTAMP) AS EventTime,
ib.CreatorName AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM InvoiceBase ib
UNION ALL
-- 2. Invoice Parked
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Parked' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = 'V' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 3. Invoice Posted
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Posted' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = '' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 4. Invoice Approved (from Parked to Posted)
SELECT
SUBSTRING(h.OBJECTID, 4, 10) AS InvoiceNumber,
'Invoice Approved' as ActivityName,
CAST(CONCAT(h.UDATE, h.UTIME) AS TIMESTAMP) AS EventTime,
h.USERNAME AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM CDHDR h
JOIN CDPOS p ON h.MANDANT = p.MANDANT AND h.OBJECTCLAS = p.OBJECTCLAS AND h.OBJECTID = p.OBJECTID AND h.CHANGENR = p.CHANGENR
JOIN InvoiceBase ib ON SUBSTRING(h.OBJECTID, 4, 10) = ib.InvoiceNumber
WHERE h.OBJECTCLAS = 'BELEGV'
AND p.TABNAME = 'BKPF'
AND p.FNAME = 'BSTAT'
AND p.VALUE_OLD = 'V'
AND p.VALUE_NEW = ' '
AND h.UDATE BETWEEN '20230101' AND '20231231'
UNION ALL
-- 5. Invoice Sent To Customer
SELECT
n.OBJKY AS InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
CAST(CONCAT(n.DATVR, n.UHRVR) AS TIMESTAMP) AS EventTime,
n.VSTAT AS UserName, -- User who processed is not directly available, using processing status as a proxy
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM NAST n
JOIN InvoiceBase ib ON n.OBJKY = ib.InvoiceNumber
WHERE n.KSCHL = '[Your Invoice Output Type]' -- E.g., 'RD00'
AND n.VSTAT = '1' -- Processed successfully
AND n.DATVR BETWEEN '20230101' AND '20231231'
UNION ALL
-- 6. Invoice Corrected (Reversed)
SELECT
SUBSTRING(orig_doc.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Corrected' AS ActivityName,
CAST(CONCAT(rev_doc.CPUDT, rev_doc.CPUTM) AS TIMESTAMP) AS EventTime,
rev_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
rev_doc.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF orig_doc
JOIN BKPF rev_doc ON orig_doc.STBLG = rev_doc.BELNR AND orig_doc.BUKRS = rev_doc.BUKRS AND orig_doc.GJAHR = rev_doc.STJAH
JOIN InvoiceBase ib ON SUBSTRING(orig_doc.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE orig_doc.AWTYP = 'VBRK' AND orig_doc.STBLG IS NOT NULL AND rev_doc.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 7. Invoice Due Date Reached
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Due Date Reached' AS ActivityName,
CAST(CONCAT(bs.ZFBDT, '000000') AS TIMESTAMP) AS EventTime,
'System' AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSEG bs
JOIN BKPF b ON bs.MANDT = b.MANDT AND bs.BUKRS = b.BUKRS AND bs.BELNR = b.BELNR AND bs.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND bs.KOART = 'D' AND bs.ZFBDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 8. Payment Reminder Issued
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(CONCAT(h.LAUFD, '000000') AS TIMESTAMP) AS EventTime,
h.LAUFI AS UserName, -- Dunning Run ID
ib.BillingDocumentType,
ib.CustomerNumber,
d.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM MHND d
JOIN MHNK h ON d.MANDT = h.MANDT AND d.LAUFD = h.LAUFD AND d.LAUFI = h.LAUFI
JOIN BKPF b ON d.MANDT = b.MANDT AND d.BUKRS = b.BUKRS AND d.BELNR = b.BELNR AND d.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE h.LAUFD BETWEEN '20230101' AND '20231231'
UNION ALL
-- 9. Dispute Case Created
SELECT
attr.ATTR_VALUE AS InvoiceNumber,
'Dispute Case Created' AS ActivityName,
sc.CREATE_TIME AS EventTime,
sc.CREATED_BY AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM SCMG_T_CASE_ATTR attr
JOIN SCASE sc ON attr.CASE_GUID = sc.CASE_GUID
JOIN InvoiceBase ib ON attr.ATTR_VALUE = ib.InvoiceNumber
WHERE attr.ATTR_NAME = '[Your Dispute Case Invoice Attribute]' -- e.g., 'INVOICE_ID'
AND CAST(sc.CREATE_TIME AS DATE) BETWEEN '20230101' AND '20231231'
UNION ALL
-- 10, 11, 12. Clearing Events (Payment, Clearing, Write-Off)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
BillingDocumentType,
CustomerNumber,
CompanyCode,
TotalInvoiceAmount
FROM (
SELECT
bsad.XBLNR AS InvoiceNumber,
CASE
WHEN clearing_item.HKONT = '[Your Bad Debt G/L Account]' THEN 'Invoice Written Off'
ELSE 'Customer Payment Received'
END AS ActivityName,
CAST(CONCAT(clearing_doc.CPUDT, clearing_doc.CPUTM) AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
LEFT JOIN BSEG clearing_item ON clearing_doc.MANDT = clearing_item.MANDT AND clearing_doc.BUKRS = clearing_item.BUKRS AND clearing_doc.BELNR = clearing_item.BELNR AND clearing_doc.GJAHR = clearing_item.GJAHR AND clearing_item.HKONT = '[Your Bad Debt G/L Account]' -- e.g. '148000'
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Payment Applied To Invoice' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '000000') AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Invoice Cleared' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '235959') AS TIMESTAMP) AS EventTime, -- Add time to separate from 'Payment Applied'
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
) AS ClearingEvents Lépések
- Előfeltételek: Rendelkezzen licenccel egy SAP-tanúsítvánnyal rendelkező összekötőt használó ETL-eszközhöz, például az SAP Connectorral kiegészített Informatica PowerCenterhez vagy Talendhez. Ellenőrizze, hogy rendelkezik-e SAP-felhasználói hitelesítő adatokkal, valamint a szükséges pénzügyi, értékesítési és rendszeradatokat tartalmazó táblák olvasási jogosultságával (BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS).
- Kapcsolódás az SAP-hoz: Az ETL-eszközben hozzon létre új kapcsolatot az SAP ECC-rendszerhez. Adja meg a kapcsolat adatait, többek között az alkalmazáskiszolgálót, a rendszerszámot, a klienst, a felhasználót és a jelszót. Tesztelje a kapcsolatot.
- Adatforrások meghatározása: Minden kinyerni kívánt tevékenységhez adja meg a megfelelő SAP-táblát vagy táblákat az ETL-feladat adatforrásaként. Például a számlák létrehozásához vegye fel a VBRK, a könyvelési eseményekhez a BKPF, az ügyfélkommunikációhoz pedig a NAST táblát.
- Adatkinyerési logika kialakítása tevékenységenként: Hozzon létre külön adatfolyamot vagy átalakítást mind a 13 szükséges tevékenységhez. Mindegyikben szűrje ki a releváns rekordokat. Például szűrjön vállalatkód (
BUKRS), bizonylattípus (BLART) és meghatározott dátumtartomány, például létrehozási dátum (ERDAT) alapján. - Mezők megfeleltetése és adatok átalakítása: Minden adatfolyamban rendelje hozzá a forrás SAP-tábla mezőit a cél eseménynapló szerkezetéhez: InvoiceNumber, ActivityName, EventTime, UserName és a többi ajánlott attribútum. Az átalakítási logikában adja meg az adott adatfolyamhoz tartozó „ActivityName” értékét, és állítsa be helyesen a dátumok és időbélyegek formátumát.
- Összetett tevékenységek kezelése: A számított eseményekhez, például a „Számla esedékessé vált” eseményhez, a ZFBDT alapfizetési dátum és a fizetési feltételek alapján számítsa ki az esedékesség dátumát, vagy kérje le közvetlenül a BSEG táblából a nettó esedékesség dátumát (
NETDT). A változásnaplókból származó eseményekhez, például a „Számla jóváhagyva” eseményhez, a bizonylatszám és a dátum alapján össze kell kapcsolnia a BKPF, CDHDR és CDPOS táblákat. - Tevékenységek adatainak egyesítése: Az ETL-eszköz „Union” vagy „Merge” átalakításával egyesítse a 13 különálló adatfolyam eredményét egyetlen adathalmazzá. Az egyesítés előtt ellenőrizze, hogy minden adatfolyamban egyeznek-e az oszlopnevek és az adattípusok.
- Célhely beállítása: Adja meg az eseménynapló végleges kimeneti helyét. Ez lehet egyszerű szöveges fájl (CSV), adatbázistábla vagy közvetlen kapcsolat egy átmeneti tárolóhoz.
- Adatkinyerési ütemezés beállítása: Adja meg az adatkinyerés dátumtartományát. Az első betöltéshez 6–12 hónapnyi adatot is kinyerhet. A későbbi, változásokat betöltő futtatásoknál állítsa be, hogy a feladat az előző futtatás dátumától kezdve kérje le az adatokat.
- Futtatás és exportálás: Futtassa az ETL-feladatot. Ha elkészült, ellenőrizze, hogy a kimeneti fájl megfelel-e az elvárt formátumnak. Az eredmény egyetlen CSV-fájl legyen, amelynek minden sora egy eseményt jelöl, és közvetlenül feltölthető a ProcessMindbe.
Konfiguráció
- SAP-kapcsolat: Kapcsolat szükséges a cél SAP ECC-rendszer alkalmazáskiszolgálójához. Az SAP-felhasználónak RFC-hozzáféréssel és a VBRK, BKPF, BSEG, NAST, valamint a lekérdezésben megadott egyéb táblák olvasásához szükséges jogosultságokkal kell rendelkeznie.
- ETL-eszköz licence: Rendelkeznie kell az ETL-eszköz és a hozzá tartozó SAP-összekötő érvényes kereskedelmi licencével.
- Dátumtartomány: Az elemzéshez reprezentatív adatminta kinyerésére javasolt 3–6 hónapos időszak, a rendszer túlzott terhelése nélkül. A kezdő és záró dátumot beállítható paraméterként adja meg.
- Fontos szűrők: Mindig szűrjön vállalatkód (
BUKRS) alapján, hogy korlátozza az adatkinyerés hatókörét. A releváns számlázási bizonylattípusok (VBRK-FKART) és könyvelési bizonylattípusok (BKPF-BLART) szerinti szűrés is elengedhetetlen. Így csak a normál számlák kerülnek be, a jóváíró bizonylatok és a belső dokumentumok pedig kimaradnak. - Teljesítmény: A nagy táblákból, például a BSEG-ből történő adatkinyerés lassú lehet. Használjon célzott szűrőket, ne kérjen le szükségtelen mezőket, és az SAP-forrásrendszer terhelésének csökkentése érdekében csúcsidőn kívülre ütemezze az adatkinyerést.
Példa-lekérdezés config
// ETL Data Extraction Logic for SAP Order-to-Cash Invoicing
// This represents the configuration logic within a graphical ETL tool.
// == Global Parameters ==
// $StartDate: '[Start Date]' (e.g., '2023-01-01')
// $EndDate: '[End Date]' (e.g., '2023-06-30')
// $CompanyCodes: '[Company Code(s)]' (e.g., '1000', '2000')
// $BillingDocTypes: '[Billing Document Type(s)]' (e.g., 'F1', 'F2')
// == Source 1: Invoice Generated ==
// Tables: VBRK
DATA_SOURCE generated_invoices FROM VBRK WHERE
ERDAT >= $StartDate AND ERDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND FKART IN ($BillingDocTypes)
MAP {
InvoiceNumber: VBELN,
ActivityName: 'Invoice Generated',
EventTime: ERDAT + ERZET, // Combine date and time
UserName: ERNAM,
BillingDocumentType: FKART,
CustomerNumber: KUNAG,
CompanyCode: BUKRS,
TotalInvoiceAmount: NETWR
}
// == Source 2: Invoice Posted ==
// Tables: BKPF joined with VBRK
DATA_SOURCE posted_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Posted',
EventTime: A.BUDAT + A.CPUTM, // Posting date and entry time
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 3: Invoice Parked ==
// Tables: BKPF joined with VBRK
DATA_SOURCE parked_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.CPUDT >= $StartDate AND A.CPUDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = 'V'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Parked',
EventTime: A.CPUDT + A.CPUTM,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 4: Invoice Approved (Transition from Parked to Posted) ==
// Tables: BKPF joined with VBRK
DATA_SOURCE approved_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
AND EXISTS (SELECT 1 FROM VBELEGV C WHERE C.BELNR = A.BELNR) // Check if it was ever parked
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Approved',
EventTime: A.BUDAT + A.CPUTM, // Use posting date as approval date
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 5: Invoice Sent To Customer ==
// Tables: NAST joined with VBRK
DATA_SOURCE sent_invoices FROM NAST as A
INNER JOIN VBRK as B ON (A.OBJKY = B.VBELN)
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND B.BUKRS IN ($CompanyCodes)
AND A.VSTAT = '1' // Successfully processed
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Sent To Customer',
EventTime: A.ERDAT + A.ERUHR,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: B.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 6: Invoice Corrected (Reversed) ==
// Tables: VBRK (for the reversal document)
DATA_SOURCE corrected_invoices FROM VBRK as A
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.SFAKN <> '' // SFAKN is the original cancelled invoice
MAP {
InvoiceNumber: A.SFAKN, // Case ID is the original invoice
ActivityName: 'Invoice Corrected',
EventTime: A.ERDAT + A.ERZET,
UserName: A.ERNAM,
BillingDocumentType: A.FKART,
CustomerNumber: A.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: NULL // Amount belongs to the reversal doc, not original
}
// == Source 7: Invoice Due Date Reached ==
// Tables: BSEG joined with VBRK
DATA_SOURCE due_invoices FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.NETDT >= $StartDate AND A.NETDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.KOART = 'D' // Customer line item
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Due Date Reached',
EventTime: A.NETDT, // Net due date
UserName: 'System',
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 8: Payment Reminder Issued ==
// Tables: MHNK, MHND, VBRK
DATA_SOURCE reminders FROM MHNK as A
INNER JOIN MHND as D ON (A.LAUFD = D.LAUFD AND A.LAUFI = D.LAUFI)
INNER JOIN VBRK as B ON (SUBSTRING(D.XBLNR, 1, 10) = B.VBELN) // XBLNR may need parsing
WHERE A.LAUFD >= $StartDate AND A.LAUFD <= $EndDate
AND D.BUKRS IN ($CompanyCodes)
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Reminder Issued',
EventTime: A.LAUFD, // Dunning date
UserName: A.IDAPS,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: D.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 9: Dispute Case Created ==
// Tables: UDM_CASE_ATTR00
DATA_SOURCE disputes FROM UDM_CASE_ATTR00 as A
WHERE A.CREATE_TIMESTAMP >= $StartDate // Timestamp format may vary
AND A.FIN_COMP_CODE IN ($CompanyCodes)
AND A.PROCESS = 'FIN_FSCM_DIS'
MAP {
InvoiceNumber: A.BILL_DOC_ID,
ActivityName: 'Dispute Case Created',
EventTime: A.CREATE_TIMESTAMP,
UserName: A.CREATE_USER,
BillingDocumentType: NULL,
CustomerNumber: A.BP_NUMBER,
CompanyCode: A.FIN_COMP_CODE,
TotalInvoiceAmount: A.DISPUTED_AMOUNT
}
// == Source 10: Customer Payment Received ==
// Tables: BKPF
DATA_SOURCE payments FROM BKPF
WHERE BUDAT >= $StartDate AND BUDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND BLART = 'DZ' // Example for Customer Payment
MAP {
InvoiceNumber: NULL, // Invoice not yet known
ActivityName: 'Customer Payment Received',
EventTime: BUDAT + CPUTM,
UserName: USNAM,
BillingDocumentType: NULL,
CustomerNumber: NULL, // Requires join to BSEG to get customer
CompanyCode: BUKRS,
TotalInvoiceAmount: NULL
}
// == Source 11 & 12: Payment Applied To Invoice & Invoice Cleared ==
// Tables: BSEG joined with VBRK
DATA_SOURCE cleared_items FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.AUGBL <> ''
// Generate two records from this source
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Applied To Invoice',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM, // User from header of original invoice doc
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
UNION WITH {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Cleared',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 13: Invoice Written Off ==
// Tables: BSEG (for the invoice line) and BKPF (for clearing doc type)
DATA_SOURCE written_off FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
INNER JOIN BKPF as C ON (A.AUGBL = C.BELNR AND A.BUKRS = C.BUKRS AND A.AUGGJ = C.GJAHR)
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND C.BLART = '[Your Write-Off Document Type]' // e.g., 'AB'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Written Off',
EventTime: A.AUGDT,
UserName: C.USNAM, // User who posted the write-off
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Final Union of all sources ==
OUTPUT generated_invoices
UNION ALL posted_invoices
UNION ALL parked_invoices
UNION ALL approved_invoices
UNION ALL sent_invoices
UNION ALL corrected_invoices
UNION ALL due_invoices
UNION ALL reminders
UNION ALL disputes
UNION ALL payments
UNION ALL cleared_items
UNION ALL written_off Kezdheti?
Használja ezt a sablont az adatok előkészítésének egyszerűsítésére, és tárja fel a számlázási folyamat fejlesztési lehetőségeit. Tegye meg az első lépést a gyorsabb pénzbeáramlás felé.
Gyorsítsa fel a pénzbeáramlást: fejlessze számlázását még ma!
Szüntesse meg a hatékonysági problémákat, csökkentse 30%-kal az átfutási időt, és javítsa a pénzáramlást.
Nincs szükség bankkártyára. Kezdje el a folyamatok fejlesztését néhány perc alatt.