Adatsablon az Order-to-Cash számlázási folyamatához
Adatsablon az Order-to-Cash számlázási folyamatához
- Javasolt attribútumok
- Követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez SAP S/4HANA rendszerből
Az Order-to-Cash számlázási folyamat attribútumai
| Név | Leírás | ||
|---|---|---|---|
| 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ójaként szolgál. | ||
| Leírás A számlaszám, amelyet az SAP-ban számlázási bizonylatszámnak neveznek, egyedileg azonosít minden számlázási tranzakciót. Ez az összekötő kulcs kapcsolja össze a számlához tartozó tevékenységeket a létrehozástól és könyveléstől a fizetés beérkezéséig és egyeztetéséig. A process miningben ez az attribútum elengedhetetlen az esetek összerendeléséhez. Az azonos számlaszámhoz tartozó események egy folyamatpéldányba kerülnek, így minden számla teljes életciklusa elemezhető. Ez lehetővé teszi a ciklusidők mérését, az eltérések feltárását és az egyes számlák útjának elemzését. Miért fontos? Ez az alapvető azonosító kapcsolja egyetlen esetbe a számlázáshoz tartozó tevékenységeket, így lehetővé teszi a teljes folyamat elemzését. Hol szerezhető be? SAP-tábla: VBRK, mező: VBELN Példák 900012349000567890009012 | |||
| Esemény időpontja EventTime | Az a pontos időbélyeg, amely megmutatja, mikor történt egy tevékenység vagy esemény. | ||
| Leírás Az esemény időpontja minden tevékenységhez megadja a dátumot és az időt, így ez adja a folyamat időrendi alapját. Ez az időbélyeg elengedhetetlen a számlázási folyamat lépései közötti időtartamok, ciklusidők és várakozási idők kiszámításához. Az elemzés során az esemény időpontja alapján rendezhetők sorba a tevékenységek, számíthatók ki az olyan teljesítménymutatók, mint a vevői kintlévőségi idő és a számlakibocsátási ciklusidő, valamint feltárhatók az időbeli szűk keresztmetszetek. Segítségével nyomon követhető, hogyan változik a folyamat teljesítménye, és mennyi ideig tartanak a számlázási ciklus egyes szakaszai. Miért fontos? Megadja az események időrendi sorrendjét, amely elengedhetetlen az időalapú mutatók, például a ciklusidők és az időtartamok kiszámításához. Hol szerezhető be? A tevékenységtől függően különböző dátum- és időmezőkből származik, például a létrehozás dátumából és időpontjából (VBRK-ERDAT, VBRK-ERZET), a módosítás időbélyegéből (CDHDR-UDATE, CDHDR-UTIME) vagy a könyvelés dátumából (BKPF-BUDAT). Példák 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Tevékenység neve ActivityName | A számlázási folyamatban végrehajtott üzleti tevékenység vagy bekövetkezett esemény neve, például „Számla kiállítva” vagy „Fizetés beérkezett”. | ||
| Leírás A tevékenység neve a számlázási életciklus egy adott lépését vagy mérföldkövét jelöli. A tevékenységek különböző SAP-adatokból származnak, például tranzakciókódokból, bizonylatstátusz-változásokból vagy naplóbejegyzésekből. Ezekből áll össze a folyamat lépéseinek sorrendje. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segít megjeleníteni a folyamattérképet, feltárni a gyakori és ritka folyamatváltozatokat, azonosítani a lépések közötti szűk keresztmetszeteket, valamint mérni az értéket nem teremtő tevékenységek, például az utómunka vagy a sztornózás gyakoriságát. Miért fontos? Ez az attribútum határozza meg a folyamat lépéseit, így megjeleníthető a folyamattérkép, és elemezhető a folyamat menete, változatossága és szűk keresztmetszetei. Hol szerezhető be? Többféle forrásból származhat, például tranzakciókódokból (SY-TCODE), módosítási bizonylatok státuszaiból (CDHDR/CDPOS táblák) vagy üzleti workflow-naplókból, például az SWW_WI2OBJ táblából. Példák Számla kiállítvaSzámla könyvelve a pénzügybenVevői befizetés beérkezettSzámla sztornózva | |||
| Befejezés időpontja EndTime | Az időbélyeg, amely pontosan jelzi, mikor fejeződött be egy tevékenység vagy esemény. | ||
| Leírás A befejezés időpontja jelzi, mikor ért véget egy tevékenység. A process mining során ezt gyakran az eset következő tevékenységének kezdési időpontjából állapítják meg. Ha a rendszer a kezdési és befejezési eseményeket is naplózza, az adat közvetlenül is kinyerhető. Ez az attribútum szükséges az egyes tevékenységek feldolgozási idejének kiszámításához. A kezdési időpontot kivonva a befejezés időpontjából megmérhető az egyes lépések időtartama. Ez segít a szűk keresztmetszetek feltárásában, például a számlajóváhagyás késedelmeinek azonosításában. Miért fontos? Lehetővé teszi az egyes tevékenységek pontos feldolgozási idejének kiszámítását, ami alapvető a szűk keresztmetszetek feltárásához. Hol szerezhető be? Ez a process mining során származtatott attribútum. Általában az eset eseménysorában következő esemény StartTime értékéből számítják ki. Egyes esetekben külön táblákban is szerepelhet a befejezés időpontja. Példák 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Felhasználónév UserName | A tevékenységet végrehajtó munkatárs felhasználói azonosítója. | ||
| Leírás Ez az attribútum rögzíti annak az SAP-felhasználónak az azonosítóját, aki egy adott eseményért felelős, például számlát állít ki, bizonylatot könyvel vagy befizetést egyenlít ki. Összekapcsolja a folyamat lépéseit az azokat végrehajtó személyekkel vagy csapatokkal. A felhasználónév szerinti elemzés segít azonosítani a kiemelkedően teljesítő munkatársakat, a képzési igényeket és a munkaterhelés egyenlőtlenségeit. A megfelelés vizsgálatához is fontos, mert megmutatja, ki hajtotta végre a kritikus tevékenységeket, és feltárja, hogyan végzik ugyanazt a folyamatot a különböző felhasználók. Miért fontos? A folyamattevékenységeket konkrét felhasználókhoz kapcsolja, így egyéni és csapatszinten is elemezhető a munkaterhelés, a teljesítmény és a megfelelés. Hol szerezhető be? A létrehozási eseményeknél a VBRK-ERNAM mezőből származik. A későbbi módosításoknál a módosítási előzményeket tároló táblákban, például a CDHDR-USERNAME mezőben vagy a workflow-naplókban található. Példák CBURNSHSIMPSONLLEONARD | |||
| Fizetési határidő PaymentDueDate | Az a dátum, ameddig a vevőnek ki kell fizetnie a számlát. | ||
| Leírás A fizetési határidő a számla dátuma és a megállapodott fizetési feltételek alapján számítható ki. Ez az a végső dátum, ameddig a fizetésnek be kell érkeznie ahhoz, hogy a számla ne váljon lejárttá. Ez az attribútum elengedhetetlen a követeléskezelés hatékonyságának nyomon követéséhez és a cash flow előrejelzéséhez. Közvetlenül felhasználható a határidőre történő fizetések arányát mérő KPI kiszámításához és a számlák korosítási riportok szerinti csoportosításához. A határidő és a tényleges fizetési dátum közötti eltérések elemzésével értékelhetők a különböző fizetési feltételek. Miért fontos? Meghatározza a vevő fizetési határidejét, ezért elengedhetetlen a határidőre történő fizetések arányának kiszámításához és a vevőkövetelések kezeléséhez. Hol szerezhető be? Ez a dátum nincs közvetlenül tárolva. Az SAP szabványos dátum-meghatározó funkciói a számla dátuma (VBRK-FKDAT) és a fizetési feltételek kódja (VBRK-ZTERM) alapján számítják ki. Példák 2023-04-192023-05-012023-06-17 | |||
| Régió Region | A vevő földrajzi régiója. | ||
| Leírás A régió attribútum a vevő címéhez tartozó földrajzi területet, például államot vagy tartományt jelöli. Az adat jellemzően a vevőtörzsben található. Ez az attribútum a regionális számlázási teljesítményt bemutató dashboard egyik alapja. Segítségével összehasonlíthatók a fő mutatók, például a ciklusidők, a hibaarányok és a DSO a különböző régiók között. Az összehasonlítás feltárhatja a folyamatvégrehajtás, a megfelelés vagy a hatékonyság regionális eltéréseit, és alapot adhat a célzott fejlesztéshez, valamint a bevált gyakorlatok egységesítéséhez. Miért fontos? Lehetővé teszi a számlázási teljesítmény földrajzi területek szerinti összehasonlítását, így feltárhatók a regionális eltérések és egységesíthetők a folyamatok. Hol szerezhető be? A KNA1 vevőtörzsadat-táblából származik (mező: REGIO), a számlafejlécben szereplő fizetőazonosító (VBRK-KUNRG) alapján összekapcsolva. Példák CANYTXBA | |||
| Számla dátuma InvoiceDate | Az a hivatalos dátum, amikor a számlát kiállították a vevőnek. | ||
| Leírás A számla dátuma, amelyet az SAP-ban számlázási dátumnak is neveznek, számos pénzügyi számítás kiindulópontja. Ez alapján határozzák meg a fizetési feltételeket, a fizetési határidőt és a követelés korát. Ez az eset szintjén fontos pénzügyi attribútum. Ez az alapja a vevői kintlévőségi időt (DSO) mérő KPI kiszámításának és a lejárt számlákról készített korosítási riportoknak, amelyek nélkülözhetetlenek a cash flow és a követelések kezeléséhez. Miért fontos? Ez a pénzügyi számítások elsődleges dátuma, a DSO, a fizetési határidők és a számlák korosítási elemzésének kiindulópontja. Hol szerezhető be? SAP-tábla: VBRK, mező: FKDAT Példák 2023-03-202023-04-012023-05-18 | |||
| Számla összege InvoiceAmount | A számla teljes nettó értéke. | ||
| Leírás Ez az attribútum a számlázott áruk vagy szolgáltatások teljes, adó nélküli pénzértékét jelöli. Minden számlához alapvető pénzügyi adat. A számla összege számos elemzésben felhasználható. Lehetővé teszi a folyamat érték szerinti csoportosítását, például annak vizsgálatát, hogy a nagy értékű számlákat másképp dolgozzák-e fel, vagy gyakrabban késnek-e. Emellett a pénzügyi riportok és a fennálló követelések összértékének kiszámításához is alapul szolgál. Miért fontos? Megmutatja az egyes számlák pénzügyi értékét, így lehetővé teszi az érték szerinti elemzést, a követeléskezelési prioritások meghatározását és a pénzügyi hatás felmérését. Hol szerezhető be? SAP-tábla: VBRK, mező: NETWR Példák 1500.0025000.50125.75 | |||
| Vevő neve CustomerName | Annak a vevőnek a neve, akinek a számlát kiállították. | ||
| Leírás Ez az attribútum a számlázott vevő hivatalos nevét azonosítja. Az SAP központi vevőtörzsadataiból származik. A vevőnkénti elemzés feltárja az egyes ügyfelekre jellemző mintákat. Megmutathatja például, mely vevők fizetnek rendszeresen késve, kik nyújtják be a legtöbb reklamációt, vagy mely ügyfeleknél a legkevésbé hatékony a számlázás. Ez célzottabb ügyfélkapcsolat-kezelést és a vevőkre szabott követeléskezelési stratégiákat tesz lehetővé. Miért fontos? Lehetővé teszi a vevőnkénti elemzést, így feltárhatók az egyes ügyfelek fizetési szokásai, reklamációinak gyakorisága és a folyamataik hatékonysági problémái. Hol szerezhető be? A KNA1 vevőtörzsadat-táblából származik (mező: NAME1), a számlafejlécben szereplő fizetőazonosító (VBRK-KUNRG) alapján összekapcsolva. Példák Springfieldi erőműKwik-E-MartCyberdyne Systems | |||
| A reklamáció oka CustomerDisputeReason | Az ügyfél által a számla vitatásakor megadott indok. | ||
| Leírás Ha az ügyfél vitat egy számlát, általában rögzítik a reklamáció okát. Ilyen lehet például az árazási hiba, a hibás mennyiség vagy a sérült áru. Az adat az SAP Dispute Management moduljában vagy szöveges megjegyzésként is szerepelhet. A reklamációs okok elemzése alapvető a számlázási hibaarány KPI méréséhez és a hibák vizsgálatához. Segít feltárni a számlázási pontatlanságok kiváltó okait, így a vállalat megszüntetheti a korábbi folyamatokban jelentkező rendszerszintű problémákat, javíthatja a számlák minőségét és növelheti az ügyfelek elégedettségét. Miért fontos? Megmutatja, miért vitatják az ügyfelek a számlákat, így közvetlenül feltárhatók a számlázási hibák és az ügyfél-elégedetlenség kiváltó okai. Hol szerezhető be? Az SAP Dispute Management használata esetén az adat például az UDM_DISPUTE táblában található. Más esetben a kapcsolódó bizonylatok okkódjaiból vagy szöveges mezőiből nyerhető ki. Példák Hibás árMennyiségi eltérésSérült áru átvétele | |||
| Fizetési állapot PaymentStatus | A számla aktuális fizetési állapota, például nyitott, kifizetett vagy lejárt. | ||
| Leírás A fizetési állapot megmutatja, hol tart a számla a követeléskezelési folyamatban. Az SAP-ban ez nem egyetlen mező, hanem a kapcsolódó könyvelési bizonylat kiegyenlítési állapota alapján állapítható meg. Ez az attribútum szükséges a lejárt, kifizetetlen számlákat bemutató dashboardhoz. Segítségével a nyitott számlák állapot és kor szerint csoportosíthatók, így a követeléskezelő csapat hatékonyabban rangsorolhatja a teendőket. Az állapotváltozások követésével maga a követeléskezelési folyamat is nyomon követhető. Miért fontos? Egy pillantással megmutatja, hol tart a számla követeléskezelése. Ez segít a kintlévőségek kezelésében és a behajtási feladatok rangsorolásában. Hol szerezhető be? A könyvelési bizonylat (VBRK-BELNR) kiegyenlítési állapota alapján állapítható meg, például a BSID (nyitott tételek) és a BSAD (kiegyenlített tételek) pénzügyi táblákból. Példák NyitottKifizetettLejártRészben kifizetett | |||
| Fizetési feltételek PaymentTerms | A fizetési feltételeket meghatározó kód, például a fizetési határidő. | ||
| Leírás A fizetési feltételek az ügyféllel előre egyeztetett szabályok, amelyek meghatározzák, mikor esedékes a számla kifizetése. Ilyen például a „30 napos fizetési határidő”, illetve a „2/10, nettó 30” feltétel, amely 2% kedvezményt ad, ha az ügyfél 10 napon belül fizet, ellenkező esetben pedig 30 nap a határidő. A fizetési feltételek elemzésével felmérhető, mennyire hatékonyak. Ha összeveti az egyes feltételeket a tényleges fizetési idővel, megállapíthatja, melyek ösztönzik leginkább a gyors fizetést. Ezek alapján módosíthatja a feltételeket, és javíthatja a pénzforgalmat. Miért fontos? Megadja az egyeztetett fizetési ütemezést, így elemezhető, mely feltételek segítik leginkább az ügyfeleket abban, hogy időben fizessenek. Hol szerezhető be? SAP-tábla: VBRK, mező: ZTERM Példák Z030Z060ZB60 | |||
| Forrásrendszer SourceSystem | Azonosítja azt a forrásrendszert, amelyből az adatokat kinyerték. | ||
| Leírás Ez az attribútum jelzi az adatok forrását, ami különösen hasznos több SAP-példányt vagy más integrált rendszereket használó környezetben. Jellemzően a rendszerazonosítót és a klienst tartalmazza. Az elemzésben segít összehasonlítani a különböző rendszerek vagy szervezeti egységek folyamatait és teljesítményét. Nyomon követhetővé teszi az adatok eredetét, és kontextust ad, különösen akkor, ha több forrás adataiból készül egységes folyamatnézet. Miért fontos? Fontos információt ad az adatok eredetéről, így több rendszer használatakor is egyértelmű marad az értelmezés, és támogatja az adatirányítást. Hol szerezhető be? Ez jellemzően az adatkinyerés során meghatározott, statikus érték, amely gyakran a rendszerazonosítót (SY-SYSID) és a klienst (SY-MANDT) egyesíti. Példák S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Határidőre fizetve IsPaidOnTime | Logikai érték, amely jelzi, hogy a számlát legkésőbb a fizetési határidő napján kifizették-e. | ||
| Leírás Ez a számított attribútum a tényleges fizetési dátumot veti össze a fizetési határidővel. Értéke „true”, ha a fizetés határidőre történt, és „false”, ha késve. Ez a jelző egyszerűsíti a határidőre történő fizetések arányát mérő KPI kiszámítását és megjelenítését. Segítségével könnyen szűrhetők és csoportosíthatók a számlák, így összehasonlíthatók a késve és határidőre kifizetett számlák jellemzői. Ezzel feltárhatók az egyes ügyfelekhez, régiókhoz vagy fizetési feltételekhez kapcsolódó késedelmes fizetési minták. Miért fontos? Egyértelműen jelzi, hogy az egyes számlákat határidőre vagy késve fizették-e ki, így egyszerűbb a teljesítmény mérése és a határidőre történő fizetések arányát mérő KPI követése. Hol szerezhető be? Ez egy számított mező. A logika összeveti az „Ügyfél fizetése beérkezett” tevékenység időbélyegét a „PaymentDueDate” attribútum értékével. Példák truefalse | |||
| Jóváírás oka CreditMemoReason | Az okkód, amely megadja, miért állították ki a jóváíró bizonylatot. | ||
| Leírás Ha a számla hibás, és jóváírásra van szükség, általában okot rendelnek a jóváíró bizonylathoz. Így rendszerezhető, mi vezetett a számlázási hibához. Ez az attribútum közvetlenül támogatja a számlázási hibaarány KPI mérését. A jóváírások okainak összesítésével és elemzésével a vállalat azonosíthatja a leggyakoribb hibákat, például az árazási tévedéseket vagy a termékvisszaküldéseket. Az elemzés alapján fejleszthetők a folyamatok, csökkenthető a pénzügyi korrekciók és az ismételt munka szükségessége. Miért fontos? Csoportosítja a jóváírások okait, így feltárhatók a számlázási hibák leggyakoribb forrásai, és javítható a minőség. Hol szerezhető be? SAP-tábla: VBRK, mező: AUGRU (rendelés oka). Ezt a mezőt a később kiszámlázott jóváírási és terhelési igényeknél használják. Példák 001 - Áreltérés002 - Gyenge minőség005 - Vevői visszáru | |||
| Pénznem Currency | A számla összegének pénznemkódja. | ||
| Leírás Ez az attribútum jelzi, milyen pénznemben szerepelnek a számlaösszegek, például USD-ben, EUR-ban vagy JPY-ben. Megadja a pénzösszegek értelmezéséhez szükséges kontextust. Nemzetközi szervezeteknél a pénznem ismerete elengedhetetlen a pontos pénzügyi elemzéshez és riportokhoz. Lehetővé teszi az összegek közös riportolási pénznemre váltását, valamint a számlázási teljesítmény összehasonlítását az eltérő helyi pénznemeket használó régiók között. Miért fontos? Megadja a pénzösszegek értelmezéséhez szükséges kontextust, és segíti a pontos pénzügyi elemzést és riportolást, különösen több országban működő szervezeteknél. Hol szerezhető be? SAP-tábla: VBRK, mező: WAERK Példák USDEURGBP | |||
| Számlázási bizonylat típusa BillingDocumentType | A számlázási bizonylatot besoroló kód, például számla, jóváíró bizonylat vagy sztornó. | ||
| Leírás A számlázási bizonylat típusa a számlázási folyamat tranzakcióit besoroló fontos mező. Meghatározza a bizonylat feldolgozásának módját, többek között a számtartományt és a könyvelési szabályokat. Az attribútum alapján a folyamat adott tranzakciótípusokra szűrhető. Külön folyamatnézet készíthető például a jóváíró bizonylatokról, hogy megérthetők legyenek a pénzügyi korrekciók okai és lépései. A normál számlák a sztornóktól elkülönítve is elemezhetők, így tisztább képet kaphat az alapvető számlázási folyamatról. Miért fontos? Besorolja a tranzakciókat, így külön elemezhetők például a normál számlák, a jóváíró bizonylatok és a sztornók. Hol szerezhető be? SAP-tábla: VBRK, mező: FKART Példák F2G2S1L2 | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg azt mutatja, mikor nyerték ki vagy frissítették utoljára az esemény adatait. | ||
| Leírás Ez az attribútum rögzíti, mikor történt utoljára adatkinyerés a forrásrendszerből. Olyan metaadatmező, amely segít megítélni, mennyire frissek az elemzett adatok. Az információval ellenőrizhető, hogy az elemzés mennyire naprakész, és megtervezhetők az adatfrissítések. Így az érintettek a process mining dashboardok és elemzések alapján hozott döntéseknél figyelembe vehetik az adatok aktualitását. Miért fontos? Jelzi az adatok frissességét, ami elengedhetetlen az elemzés megbízhatóságának és a működés aktuális állapotához való relevanciájának megítéléséhez. Hol szerezhető be? Ezt az időbélyeget az ETL-folyamat során generálják, majd minden rekordhoz hozzárendelik. Példák 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Vállalati kód CompanyCode | Az a szervezeti egység, amelyhez a pénzügyi tranzakciót rögzítik. | ||
| Leírás Az SAP Financials rendszerben a vállalati kód alapvető szervezeti egység. Egy jogilag önálló vállalatot jelöl, amelynek pénzügyi kimutatásai készülnek. Minden számlázási bizonylat egy adott vállalati kódhoz tartozik. Több vállalatból álló szervezeteknél a vállalati kód szerinti elemzés segít összehasonlítani a folyamatok teljesítményét, a pénzügyi mutatókat, például a DSO-t, valamint a megfelelést az egyes jogi egységek között. A folyamatok dashboardjain szervezeti szintű szűrésre is használható. Miért fontos? Lehetővé teszi a folyamatok jogi egység szerinti elemzését, így összehasonlítható a teljesítmény, és konszolidálhatók a szervezet pénzügyi adatai. Hol szerezhető be? SAP-tábla: VBRK, mező: BUKRS Példák 10002000US01 | |||
| Vevői rendelés száma SalesOrderNumber | Az eredeti vevői rendelés azonosítója, amely alapján a számla készült. | ||
| Leírás A vevői rendelés száma összekapcsolja a számlázási bizonylatot az azt megelőző értékesítési tevékenységekkel. Egy vevői rendelésből egy vagy több számla is készülhet, a kapcsolat pedig megmutatja a teljes bizonylatláncot. Ez az attribútum elengedhetetlen az Order-to-Cash folyamat valódi, végpontok közötti elemzéséhez. A folyamatnézetet a számlázást megelőző lépésekre is kiterjeszti, így a számlázási problémák összekapcsolhatók a vevői rendelés rögzítésének vagy teljesítésének lehetséges okaival. Például kiszámítható vele a számlakiállítás teljes átfutási ideje a rendelés teljesítésétől kezdve. Miért fontos? Összekapcsolja a számlát az eredeti vevői rendeléssel, így a számlázáson túl az Order-to-Cash folyamat egésze is elemezhető. Hol szerezhető be? SAP-tábla: VBRP (számlázási bizonylat tételadatai), mező: AUBEL Példák 100001231000045610000789 | |||
Az Order-to-Cash számlázási folyamat tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Befizetés hozzárendelve/egyeztetve | Azt a pillanatot jelöli, amikor a vevőtől érkező befizetést hozzárendelik a nyitott számlatételhez, és kiegyenlítik a vevőkövetelési analitikában. Pénzügyi szempontból ezzel zárul le a tranzakció. | ||
| Miért fontos? A befizetések számlákhoz rendelésének hatékonyságát méri. A késedelmes egyeztetés miatt a vevői számlák állapota félrevezető lehet, és felesleges munkát okozhat a követeléskezelő csapatnak. Hol szerezhető be? Az eseményt az eredeti számla könyvelési bizonylatának tételén szereplő kiegyenlítési dátum (BSEG-AUGDT) rögzíti. Ez a dátum akkor töltődik ki, amikor a kiegyenlítési bizonylat rendezi a tételt. Rögzítés A számlatétel BSEG/ACDOCA táblájának kiegyenlítési dátum (AUGDT) mezőjéből származik. Eseménytípus explicit | |||
| Számla kiállítva | Ez a tevékenység jelzi, hogy a rendszerben létrejött a számlázási bizonylat. Az esemény rögzül, amikor egy felhasználó például a VF01 tranzakcióval kiállítja a számlát, vagy amikor egy háttérfeladat létrehozza azt. Ennek eredményeként új sor kerül a számlázási bizonylat fejlécét tároló táblába. | ||
| Miért fontos? Ez a számlázási folyamat elsődleges kezdőeseménye. A rendelés teljesítése és e tevékenység közötti idő elemzése elengedhetetlen a számlakibocsátási ciklusidő méréséhez és a folyamat elején jelentkező késések feltárásához. Hol szerezhető be? A létrehozáskor az SAP S/4HANA VBRK táblájába (számlázási bizonylat: fejlécadatok) kerül. Az időbélyeget a létrehozás dátuma (VBRK-ERDAT) és időpontja (VBRK-ERZET) adja. Rögzítés Az esemény a VBRK tábla számlázási bizonylatrekordjának létrehozási időbélyegéből származik. Eseménytípus explicit | |||
| Számla könyvelve a pénzügyben | A számlázási bizonylat sikeres könyvelése a pénzügyi modulban. Ez fontos mérföldkő: a számla hivatalos vevőköveteléssé válik, és főkönyvi tételek jönnek létre. | ||
| Miért fontos? Ez a tevékenység igazolja, hogy a számla hivatalos pénzügyi bizonylat. A kiállítás és a könyvelés közötti idő fontos teljesítménymutató, amely a belső feldolgozás hatékonyságát jelzi. Hol szerezhető be? Az esemény a kapcsolódó könyvelési bizonylat létrehozásakor rögzül. A számlázási bizonylat (VBRK-VBELN) a VBRK-BELNR mezőn keresztül kapcsolódik a könyvelési bizonylathoz (BKPF-BELNR). A könyvelés dátuma a BKPF-BUDAT mezőben található. Rögzítés A számlázási bizonylathoz kapcsolódó, BKPF táblában szereplő könyvelési bizonylat könyvelési dátumából (BUDAT) származik. Eseménytípus explicit | |||
| Számla lezárva | Ez a tevékenység a sikeresen kifizetett számla végállapotát jelzi. Funkcionálisan megegyezik a „Befizetés hozzárendelve/egyeztetve” eseménnyel, és azt mutatja, hogy a számlához kapcsolódó folyamat befejeződött. | ||
| Miért fontos? Ez a folyamat elsődleges, sikeres lezáró eseménye. Az eddig eltelt teljes ciklusidő mérése átfogó képet ad a számlázás teljes folyamatáról. Hol szerezhető be? A könyvelési bizonylat vevői tételének státuszából állapítható meg. A tétel akkor zárt, vagyis kiegyenlített, ha a kiegyenlítési dátum (BSEG-AUGDT) és a kiegyenlítési bizonylat (BSEG-AUGBL) mezője ki van töltve. Rögzítés A számlatétel BSEG/ACDOCA táblájában szereplő kiegyenlítési dátum (AUGDT) kitöltöttségéből állapítható meg. Eseménytípus inferred | |||
| Vevői befizetés beérkezett | Ez a tevékenység jelzi, hogy a vevőtől érkező befizetést rögzítették a pénzügyi rendszerben. Ekkor a befizetés még nem feltétlenül kapcsolódik egy konkrét számlához, de az összeg már szerepel a nyilvántartásban. | ||
| Miért fontos? Fontos mérföldkő a vevői kintlévőségi idő (DSO) kiszámításához. Azt jelzi, hogy a pénz beérkezett, még akkor is, ha az egyeztetés még nem történt meg. Hol szerezhető be? A vevői befizetés könyvelési bizonylatának könyvelési dátumából (BKPF-BUDAT) származik. A BKPF táblában ez jellemzően „DZ” bizonylattípusú tétel. Rögzítés Az esemény a BKPF/BSEG táblákban szereplő befizetési bizonylat létrehozásán alapul. Eseménytípus explicit | |||
| Fizetési felszólítás kiküldve | Azt jelzi, hogy lejárt számla miatt fizetési emlékeztetőt vagy felszólítást küldtek a vevőnek. Ez a rendszeres automatikus felszólítási eljárás során keletkező, kifejezetten rögzített esemény. | ||
| Miért fontos? Segít elemezni a felszólítási folyamat hatékonyságát. Megmutatja, hogy az emlékeztetők gyorsítják-e a fizetést, és melyik felszólítási fokozat a leghatásosabb. Hol szerezhető be? A MAHNV és MHND felszólítási előzménytáblákban rögzül, amikor a számla nyitott tételére lefuttatják a felszólítási eljárást (F150 tranzakció). Rögzítés A felszólítási előzménytáblákban rögzített futtatási dátumból származik. Eseménytípus explicit | |||
| Fizetési határidő elérkezett | Számított esemény, amely azt a dátumot jelöli, amikor a megállapodott fizetési feltételek szerint esedékessé válik a számla. Nem tranzakciós esemény, hanem a számla adataiból származik. | ||
| Miért fontos? Ez az alapérték segít mérni a határidőre történő fizetést és elemezni a vevők fizetési szokásait. Elkülöníthetők vele a határidőben és a késve teljesített fizetések. Hol szerezhető be? A fizetés alapdátuma (BSEG-ZFBDT) és a könyvelési bizonylat vevői tételében tárolt fizetési feltételek alapján számítható ki. Rögzítés A könyvelési bizonylat tételében (BSEG) szereplő fizetési alapdátumhoz hozzáadott fizetési határidő napjaiból származik. Eseménytípus calculated | |||
| Jóváíró bizonylat létrehozva | Ez a tevékenység jóváíró bizonylat létrehozását jelzi. A bizonylatot túlszámlázás korrigálására vagy visszaküldött áru jóváírására állítják ki a vevőnek. Gyakran az eredeti számlához kapcsolódik. | ||
| Miért fontos? Rávilágít a számlázás után szükségessé váló pénzügyi korrekciókra. A jóváíró bizonylatok elemzésével feltárhatók az árazási hibák, a termékproblémák és az árbevétel-kiesés egyéb kiváltó okai. Hol szerezhető be? Új számlázási bizonylatként jön létre a VBRK táblában, a jóváíró bizonylatokhoz használt bizonylattípussal, például „G2” típussal. Gyakran az eredeti értékesítési rendelésre vagy számlára hivatkozik. Rögzítés A VBRK táblában jóváíró bizonylattípussal létrehozott számlázási bizonylatból származik. Eseménytípus explicit | |||
| Számla elküldve a vevőnek | Ez a tevékenység jelzi, hogy a számlát továbbították a vevőnek, például nyomtatva, e-mailben vagy EDI-n keresztül. A rögzítés módja az SAP kimenetkezelési beállításaitól függ. | ||
| Miért fontos? A vevő szempontjából ekkor indul a fizetési határidő. A számla elküldésének késése közvetlenül növeli a vevői kintlévőségi időt (DSO), és rontja a cash flow-t. Hol szerezhető be? Az esemény rögzíthető a kimenetvezérlési táblákban, például a régebbi megoldásoknál használt NAST táblában vagy annak S/4HANA-megfelelőjében. Ha nincs külön naplózva, gyakran a „Számla könyvelve a pénzügyben” esemény időpontjára teszik. Rögzítés Ellenőrizze a kimenetkezelési táblák feldolgozási naplóiban, hogy szerepel-e időbélyeg a számla kimenettípusához. Eseménytípus explicit | |||
| Számla könyvelése zárolva | Ez az esemény akkor következik be, ha a számla létrejön, de különböző okok, például hitelvizsgálat vagy adatok közötti ellentmondás miatt a rendszer automatikusan megakadályozza a pénzügyi könyvelését. Az esemény a számlázási bizonylat könyvelési státuszából állapítható meg. | ||
| Miért fontos? Megmutatja, hol jönnek létre számlák, amelyeket nem engednek tovább a pénzügyre, így késik a teljes pénzbeszedési ciklus. Az ilyen esetek adatminőségi problémára vagy a hitelkezelés hiányosságaira utalhatnak. Hol szerezhető be? A számlázási bizonylat fejlécét tároló tábla könyvelési státuszmezőjéből állapítható meg (VBRK-RFBSK). Az „A” státusz például azt jelzi, hogy a számlázási bizonylat továbbítása az FI felé zárolva van. Rögzítés A számla kiállítása után közvetlenül ellenőrizze a könyvelési státuszmező értékét (VBRK-RFBSK). Eseménytípus inferred | |||
| Számla sztornózva | Akkor történik, amikor egy korábban kiállított számlát sztornóznak, jellemzően egy kapcsolódó sztornóbizonylat létrehozásával. Ezzel visszafordítják az eredeti számlát és annak könyvelési hatását. | ||
| Miért fontos? Utómunkára, javításra vagy számlázási hibára utal. A gyakori sztornózás komoly, korábbi szakaszokban jelentkező problémákra hívja fel a figyelmet, például az értékesítési rendelések rögzítésében vagy a számlázás beállításaiban. Hol szerezhető be? A sztornó számlázási bizonylat létrehozásakor rögzül, például „S1” bizonylattípus esetén. A VBRK táblában létrejövő új bizonylat a VBRK-SFAKN mezőben hivatkozik az eredeti számlaszámra. Rögzítés Az esemény a VBRK táblában az eredeti számlára hivatkozó sztornóbizonylat létrehozási dátumából származik. Eseménytípus explicit | |||
| Számlázási utómunka azonosítva | Számított esemény, amely olyan utómunka-kört azonosít, amikor egy számlát sztornóznak, majd ugyanahhoz az értékesítési rendeléshez új számlát állítanak ki. Nem egyetlen tranzakciót, hanem eseménymintát jelöl. | ||
| Miért fontos? Közvetlenül támogatja a számlázási utómunka arányát mérő KPI-t, mert számszerűsíti a javításokat. Segít feltárni a hatékonysági problémákat és mérni a számlázási folyamat gyenge minőségének költségét. Hol szerezhető be? A rendszer azonosítja a „Számla sztornózva” eseményt, amelyet új „Számla kiállítva” esemény követ, és mindkettő ugyanahhoz a forrásbizonylathoz, például ugyanahhoz az értékesítési rendeléshez kapcsolódik. Rögzítés Az azonos értékesítési rendeléshez tartozó „Számla sztornózva” és „Számla kiállítva” eseménysorozat felismerésével állapítható meg. Eseménytípus calculated | |||
| Vevői reklamáció megnyitva | Ez a tevékenység akkor történik, amikor a vevő kifogást emel egy számla ellen, és azt hivatalosan rögzítik a rendszerben. Ehhez az SAP Dispute Management modul használata szükséges. | ||
| Miért fontos? Rávilágít a számlázás pontosságával, a termékminőséggel vagy a szolgáltatás teljesítésével kapcsolatos problémákra, amelyek késleltetik a fizetést. A reklamációk okainak elemzése segíthet a kiváltó okok kezelésében és a vevői elégedettség javításában. Hol szerezhető be? A reklamációs ügy Dispute Management táblákban, például az UDM_CASE táblában történő létrehozásakor rögzül. Az ügy a könyvelési bizonylat tételéhez kapcsolódik. Rögzítés A számlához kapcsolódó reklamációs ügy létrehozási időbélyegéből származik. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Előfeltételek: Ellenőrizze, hogy rendelkezik-e SAP S/4HANA-felhasználói fiókkal és a Core Data Services (CDS) nézetek lekérdezéséhez szükséges jogosultságokkal. Különösen az I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase és I_DunningHistory nézetekhez szükséges olvasási hozzáférés.
- Adatkinyerő eszköz megnyitása: Jelentkezzen be az SAP S/4HANA rendszerbe. A CDS nézetek SQL-lekérdezéséhez többféle eszközt használhat, például az SAP HANA Studio alkalmazást, az SAP HANA kliensen keresztül csatlakozó DBeavert vagy az SAP Analysis for Microsoft Excel bővítményt. Az útmutató egy általános SQL-klienst feltételez.
- Rendszerparaméterek meghatározása: A lekérdezés futtatása előtt határozza meg a vizsgálni kívánt vállalatkódokat és dátumtartományt. Érdemes kezdetben szűkebb időszakot választani, például az elmúlt 3–6 hónapot, hogy a lekérdezés kezelhető idő alatt fusson le.
- SQL-lekérdezés előkészítése: Másolja a dokumentum „query” szakaszában található teljes SQL-lekérdezést a kiválasztott SQL-kliensbe.
- Helyőrzők testreszabása: Módosítsa a lekérdezésben szereplő helyőrzőket. Cserélje le a
'YYYY-MM-DD'értékeket a kívánt kezdő- és záródátumra, a'XXXX'értéket pedig a célként megadott vállalatkódokra. A rendszer beállításaitól függően a jóváíró számla bizonylattípusának helyőrzőjét is módosítania kell, például'G2'értékre. - Lekérdezés futtatása: Futtassa a módosított SQL-lekérdezést az SAP S/4HANA-adatbázison. A futási idő a kiválasztott időszak adatainak mennyiségétől függ.
- Eredmények ellenőrzése: A lekérdezés lefutása után ellenőrizze az eredményt. Egy soros táblázatot kell kapnia, amelyben minden sor a számlázási folyamat egy tevékenységét jelöli. Ez lesz az eseménynapló.
- Adatátalakítás, ha szükséges: A lekérdezés rendezett eseménynapló-formátumot állít elő. Ellenőrizze azonban, hogy az időbélyegek formátuma kompatibilis-e a process mining eszközzel. A lekérdezés az
ABAP_SYSTEM_UTCL_TO_TIMESTAMPfüggvénnyel alakítja át az értékeket szabványos UTC-időbélyeggé, amely a legtöbb rendszerrel kompatibilis. - Eseménynapló exportálása: Exportálja az SQL-kliensből a teljes eredményt CSV-fájlba. A karakterhibák elkerülése érdekében UTF-8 kódolást használjon.
- Feltöltés a ProcessMindba: Töltse fel az elkészült CSV-fájlt a ProcessMind platformra, és rendelje hozzá a fájl oszlopait, például az InvoiceNumber, ActivityName és EventTime mezőket a megfelelő mezőkhöz.
Konfiguráció
- Dátumtartomány: A kezdő- és záródátumot a kezdeti Common Table Expression (CTE)
WHEREfeltételében adja meg. Első elemzéshez 3–6 hónapnyi adat javasolt, hogy az adatmennyiség és a teljesítmény egyensúlyban legyen. A szűrés aBillingDocumentDatemező alapján történik. - Vállalatkód: Egy vagy több
CompanyCodeértékkel szűkítse a kinyerést az érintett jogi személyekre. Ezzel szabályozhatja a feldolgozott adatok körét. - Bizonylattípusok: A lekérdezés a
BillingDocumentTypemező alapján azonosítja a jóváíró számlákat. Állítsa be a helyőrzőt, például('G2', 'CR')értékre, az Önök szervezetében használt bizonylattípusoknak megfelelően. - Előfeltételek: Az alapul szolgáló CDS nézetekhez való hozzáférés kötelező. Ehhez az SAP biztonsági csapatának kell kiosztania a megfelelő szerepköröket és jogosultságokat. A „Customer Dispute Opened” és a „Payment Reminder Issued” tevékenységekhez az SAP Dispute Management, illetve az SAP Financials Dunning modul aktív használata is szükséges.
- Teljesítmény: A lekérdezés több összekapcsolást és uniót használ. Nagy adathalmazok, például több évnyi adat esetén futtassa a lekérdezést csúcsidőn kívül, vagy szűkítse tovább a szűrőket az első adatkinyerés méretének csökkentéséhez.
Példa-lekérdezés sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Lépések
- Ellenőrizze, hogy rendelkezésre áll-e közvetlen olvasási hozzáférés a számlázási és kapcsolódó pénzügyi táblákat tartalmazó SAP HANA-sémához. Kérje el a séma nevét, a csatlakozási adatokat, az engedélyezett dátumtartományt, a vállalatkódok körét, a számlázási bizonylattípusokat, valamint az esetleges ügyfél- vagy régiószűrőket a rendszer felelősétől. A lekérdezésben csak a csatlakozási és szűrési helyőrzőket cserélje le.
- Ellenőrizze a célrendszerben az érintett SAP S/4HANA-adatforrásokat és mező-hozzárendeléseiket. A lekérdezés a számlázási adatokhoz a VBRK és VBRP táblákat használja. Emellett beállított adatforrásokra van szükség a könyveléshez, a kimenetkezeléshez, a vitakezeléshez, a fizetési felszólításokhoz, a beérkező kifizetésekhez, a kiegyenlítéshez és a bizonylatkapcsolatokhoz. A szögletes zárójelben lévő adatforrás- és mezőhelyőrzőket csak azután cserélje le, hogy ellenőrizte őket a rendszer adatszótárában.
- Állítsa be a kinyerési időszakot úgy, hogy a kezdő időbélyeg benne legyen, a záró időbélyeg pedig már ne. Első futtatásra 3–6 hónapnyi időszak javasolt. A mennyiség szabályozásához és az eltérő számlázási folyamatok összekeverésének elkerüléséhez szűrjön vállalatkódra, és szükség esetén számlázási típusra is.
- A lekérdezést csak olvasási jogosultságú HANA-adatbázis-felhasználóval futtassa. A lekérdezés minden kifejezetten kinyert tevékenységhez egy eseménysort hoz létre. Nem a ProcessMind következteti ki az eseményeket. A számított tevékenységeket, köztük a Payment Due Date Reached és a Billing Rework Identified eseményt, az SQL-logika állítja elő, és külön sorokként adja vissza.
- Ellenőrizze a visszaadott séma mezőit. Az eseménynaplónak tartalmaznia kell az InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region és EndTime mezőket. Minden sornál ellenőrizze, hogy az InvoiceNumber, ActivityName és EventTime mező ki van-e töltve.
- Ellenőrizze az események jelentését és kapcsolatait. Hasonlítsa össze az Invoice Generated sorokat a számlázási bizonylat fejléceinek létrehozási adataival, az Invoice Posted To Accounting sorokat a könyvelési státusszal, az Invoice Sent To Customer sorokat a kimeneti rekordokkal, a fizetési sorokat a könyvelési bizonylatokkal, a kiegyenlítési sorokat pedig a kiegyenlített számlatételekkel. Éles használat előtt vizsgálja át a helyőrzőktől függő lekérdezésrészeket.
- Készítse elő az eredményt a ProcessMind számára. Minden esemény külön sorban szerepeljen, az időbélyegek adattípusa és időzónája legyen egységes. Az InvoiceNumber értékét szövegként őrizze meg, hogy a kezdő nullák ne vesszenek el, az ActivityName értékei pedig pontosan egyezzenek az előírt tevékenységnevekkel. Rendezze az adatokat InvoiceNumber és EventTime szerint. Ha több esemény időbélyege azonos, használjon egyértelmű másodlagos rendezési szempontot.
- Exportálja az eredményt UTF-8 kódolású CSV-fájlba vagy más, ProcessMind által támogatott táblázatos formátumba. Az InvoiceNumber mezőt rendelje az esetazonosítóhoz, az ActivityName mezőt a tevékenységoszlophoz, az EventTime mezőt pedig az esemény időpontjához. Ha rendelkezésre állnak, vegye fel a javasolt attribútumokat is, majd töltse fel a fájlt a beállított ProcessMind-importálási folyamaton keresztül. Végül ellenőrizze a sorok és a tevékenységek számát.
Konfiguráció
- Dátumtartomány: Kezdetben 3–6 hónapnyi adatot használjon. A kezdő időbélyeg legyen benne, a záró pedig már ne, így az egymást követő adatkinyerések között nem keletkeznek duplikált események.
- Esetazonosító: A számlázási bizonylat fejlécéből származó InvoiceNumber mezőt használja. Szövegként őrizze meg, mert az SAP bizonylatszámai kezdő nullákat tartalmazhatnak.
- Szükséges tevékenységek: A kinyerésnek külön sorokat kell visszaadnia a következő tevékenységekhez: Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created és Billing Rework Identified.
- Szűrők: A Company Code, a számlázási bizonylattípus, az értékesítési szervezet, az ügyfél, a régió és a dátum szerinti szűrést csak azután alkalmazza, hogy ellenőrizte a megfelelő mezőket és az üzleti hatókört a célrendszerben. Ne feltételezze, hogy minden számlázási bizonylattípus azonos könyvelési vagy kimenetkezelési folyamatot követ.
- Adatforrások beállítása: A számlázási adatok elsődleges forrásai a VBRK és a VBRP. A könyvelési, kimenetkezelési, vitakezelési, fizetésifelszólítási, fizetési, kiegyenlítési és bizonylatfolyam-adatforrásokat a telepített SAP S/4HANA-verzió és az engedélyezett modulok alapján kell beállítani. A szögletes zárójelben lévő adatforrás-hivatkozásokat ellenőrzött objektumokra és mezőkre cserélje.
- Számított események: A Payment Due Date Reached esemény a fizetési feltételekből és az esedékességi adatokból származik. A Billing Rework Identified eseményt a sztornózási és az azt követő számlagenerálási minták alapján számítja ki a rendszer. Ezek SQL által létrehozott eseménysorok, nem natív tranzakciós rekordok.
- Teljesítmény: A dátum-, vállalatkód-, számlázásitípus- és bizonylatszám-szűrőket minden adatforrás lekérdezésébe építse be. Csak a szükséges oszlopokat válassza ki, kerülje a nagy könyvelési táblák korlátozás nélküli összekapcsolását, az időszakot pedig havi vagy heti adagokban dolgozza fel. A költséges összekapcsolások azonosításához használja az adatbázis végrehajtási terveit.
- Növekményes adatkinyerés: Használjon stabil vízjelet a forrás létrehozási vagy könyvelési időbélyege alapján. Dolgozzon fel újra egy rövid átfedő időszakot is, hogy a késve érkező kimeneti, fizetési, vita- és kiegyenlítési rekordok se maradjanak ki. Ezután távolítsa el a duplikátumokat az InvoiceNumber, ActivityName és EventTime, valamint a megfelelő forrásbizonylat-kulcs alapján.
- Jogosultságok: Az adatkinyerést végző felhasználónak olvasási jogosultságra van szüksége a kiválasztott HANA-sémaobjektumokhoz és -mezőkhöz. Ellenőrizze, hogy a szervezet biztonsági szabályzata engedélyezi-e a közvetlen adatbázis-hozzáférést, és teljesülnek-e a személyes, illetve ügyféladatok kezelésére vonatkozó követelmények.
- Funkcionális előfeltételek: A kimenetkezelési, könyvelési integrációs, vitakezelési, fizetésifelszólítási, beérkező fizetési és kiegyenlítési adatok csak akkor érhetők el, ha a megfelelő funkciókat beállították és használják a rendszerben. Ha egy modul vagy forrásrekord hiányzik, a hozzá tartozó tevékenység sem jelenik meg, a rendszer nem következteti ki.
- Időzóna: Az időbélyegeket a ProcessMind által elvárt időzónára egységesítse. Dokumentálja, hogy a forrás időbélyegei UTC-ben, helyi rendszeridő szerint vagy más beállított időzónában vannak-e tárolva.
Példa-lekérdezés sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Kezdjük el?
Használja ezt a sablont az adat-előkészítés felgyorsításához, és kezdje el fejleszteni a rendeléstől a pénz beérkezéséig tartó számlázási folyamatot. Alakítsa át SAP S/4H4ANA-adatait hasznosítható információvá még ma.
30%-kal gyorsabb pénzbeáramlás a rendeléstől a pénz beérkezéséig tartó számlázási folyamat fejlesztésével
Szüntesse meg a hatékonysági problémákat, és csökkentse 30%-kal a számlázási ciklus idejét már ma.
Nincs szükség bankkártyára. Néhány perc alatt elkezdheti.