Adatsablon az Order to Cash vevőirendelés-feldolgozási folyamathoz
Adatsablon az Order to Cash vevőirendelés-feldolgozási folyamathoz
- Javasolt attribútumok
- Követendő fő tevékenységek
- Adatkinyerési útmutató SAP ECC-hez
Az Order to Cash vevőirendelés-feldolgozási folyamat attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Értékesítési rendelés SalesOrder | Az értékesítési rendelés bizonylatának egyedi azonosítója. Ez szolgál elsődleges esetazonosítóként a rendeléstől a pénz beérkezéséig tartó teljes folyamat követéséhez. | ||
| Leírás Az értékesítési rendelés az értékesítési folyamat központi bizonylata, amely az ügyfél áru- vagy szolgáltatásigényét rögzíti. Tartalmazza az igény teljesítéséhez szükséges összes adatot. A process mining során ez az attribútum szolgál esetazonosítóként (Case ID). Minden egyedi értékesítésirendelés-szám egy teljes folyamatpéldányt jelöl. Az értékesítési rendelések szerinti elemzéssel nyomon követhető a teljes folyamat, mérhető a ciklusidő, és feltárhatók az egyes ügyfélrendelések közötti eltérések. Miért fontos? Ez az alapvető azonosító kapcsolja össze az összes kapcsolódó tevékenységet és eseményt, így minden ügyfélrendelés teljes folyamata elemezhető. Hol szerezhető be? Az értékesítési bizonylat fejlécadatait tartalmazó VBAK táblában, a VBELN mezőben található. Példák 900001234590000123469000012347 | |||
| Forrásrendszer SourceSystem | Megadja, melyik forrásrendszerből származnak a kinyert adatok. | ||
| Leírás Ez az attribútum azonosítja a forrásrendszert, például egy adott SAP ECC-példány nevét vagy kliensszámát. Kontextust ad az adatokhoz, különösen akkor, ha több éles rendszerből vagy korábbi rendszerekből származnak. Az elemzésben az adatok forrás szerinti szűrésére és csoportosítására használható. Ez különösen hasznos a különböző rendszerek folyamatainak összehasonlításakor, illetve rendszerbevezetéskor, amikor ellenőrizni kell az adatok sértetlenségét és következetességét. Miért fontos? Megadja a szükséges kontextust, különösen több rendszer használatakor. Lehetővé teszi a folyamatok összehasonlítását, és segít egyértelműen nyomon követni az adatok eredetét. Hol szerezhető be? Ezt az értéket jellemzően az adatkinyerés során adják hozzá. Többnyire az SAP-rendszerazonosítót (SAPSID) vagy a klienst (MANDT) jelöli. Példák ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Kezdési idő StartTime | Az az időbélyeg, amely megmutatja, mikor kezdődött egy tevékenység vagy esemény. | ||
| Leírás A kezdési idő, más néven esemény-időbélyeg, rögzíti egy adott tevékenység pontos dátumát és időpontját. Megmutatja például, mikor hozták létre az értékesítési rendelést, mikor könyvelték az árukiadást, vagy mikor könyvelték a számlát. Ez az időbélyeg a process mining minden időalapú elemzésének alapja. Segítségével kiszámítható a tevékenységek közötti ciklusidő és az eset teljes időtartama, valamint azonosíthatók a késedelmek és a szűk keresztmetszetek. A pontos időbélyegek elengedhetetlenek a teljesítményt mérő dashboardokhoz, például a határidőre történő szállítást vagy a teljesítés átfutási idejét követő nézetekhez. Miért fontos? Ez az attribútum szükséges a teljesítménymutatók, például a ciklusidők és az időtartamok kiszámításához, amelyek alapján azonosíthatók a szűk keresztmetszetek. Hol szerezhető be? Ez összetett attribútum, amelyet jellemzően különböző SAP-táblák, például a VBAK (értékesítési rendelés), a LIKP (szállítás) és a VBRK (számla) dátummezőinek (például ERDAT) és időmezőinek (például ERZET) összekapcsolásával állítanak elő. Példák 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
| Tevékenység Activity | Az értékesítési rendelés folyamatában végrehajtott üzleti lépés vagy bekövetkezett esemény neve. | ||
| Leírás Ez az attribútum a rendeléstől a pénz beérkezéséig tartó folyamat egyetlen lépését írja le, például az értékesítési rendelés létrehozását, a szállítás létrehozását vagy a fizetés beérkezését. Ezekből a tevékenységekből állítható össze az egyes értékesítési rendelések folyamata. A tevékenységek sorrendjének és időzítésének elemzése a process mining alapja. Segít megjeleníteni a folyamattérképet, azonosítani a szűk keresztmetszeteket, feltárni a folyamatváltozatokat, és ellenőrizni, hogy a folyamat megfelel-e a standard modellnek. A tevékenységeket jellemzően a bizonylatok létrehozására, az állapotváltozásokra vagy a rendszerben rögzített tranzakciókódokra alapozva határozzák meg. Miért fontos? A tevékenységek adják a folyamattérkép alapját. Segítségükkel megjeleníthető és elemezhető a folyamat menete, az eltérések és a szűk keresztmetszetek. Hol szerezhető be? Ez egy származtatott attribútum. Az adatkinyerés során jellemzően az SAP tranzakciókódokat (T-Code), a bizonylatállapotok változásait (például a VBUK és VBUP táblákban), illetve a módosítási naplókat (CDHDR és CDPOS táblák) felhasználóbarát tevékenységnevekhez rendelik. Példák Értékesítési rendelés létrehozvaSzállítás létrehozvaÁru kiadvaSzámla létrehozvaFizetés beérkezett | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg azt mutatja, mikor frissítették utoljára a rekord adatait a forrásrendszerből. | ||
| Leírás Ez az attribútum rögzíti, mikor történt legutóbb adatkinyerés vagy frissítés az adott eseményhez vagy esethez. Így látható, mennyire frissek az elemzett adatok. A dashboardokon és jelentésekben ez segít a felhasználóknak megítélni, mennyire aktuálisak az elemzés eredményei. Megmutatja, hogy az elemzés a működés jelenlegi állapotát tükrözi-e, vagy régebbi adatokon alapul, így a felhasználók tudják, mikorra vonatkoznak az adatok. Miért fontos? A felhasználók látják, mennyire frissek az adatok. Ez fontos ahhoz, hogy a process mining elemzésére támaszkodva időben és megalapozottan dönthessenek. Hol szerezhető be? Ez egy metaadat-attribútum, amelyet az adatbetöltéskor az adatkinyerő eszköz vagy folyamat tölt ki. A forrás SAP-táblákban nem szerepel. Példák 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| Anyagszám MaterialNumber | Az értékesített termék vagy szolgáltatás egyedi azonosítója. | ||
| Leírás Az anyagszám azonosítja az értékesítési rendelés egy adott tételét. Mivel egy rendelés több anyagot is tartalmazhat, ezt az attribútumot jellemzően tételszinten elemzik. Az anyagszám szerinti elemzés feltárja a termékspecifikus problémákat. Megmutathatja, hogy egyes termékekhez hosszabb teljesítési idő, gyakoribb szállítási zárolás vagy több számlaeltérés kapcsolódik-e. Ez segít az ellátási lánc és a termékmenedzsment területén a különböző termékcsoportok folyamatainak fejlesztésében. Miért fontos? Lehetővé teszi a termékenkénti folyamatelemzést, és megmutatja, mely termékekhez kapcsolódnak késedelmek, zárolások vagy utómunka miatti hatékonysági problémák. Hol szerezhető be? Az értékesítési bizonylat tételadatait tartalmazó VBAP táblában, a MATNR mezőben található. Példák FG-1001-ARAW-205BSERV-INSTALL | |||
| Elutasítási ok RejectionReason | Az értékesítési rendelés egy tételének elutasítását vagy törlését indokló kód. | ||
| Leírás Az elutasítási ok megmutatja, miért nem teljesítették az értékesítési rendelést vagy annak egy adott tételét. Az ok lehet például az ügyfél lemondása, a termék hiánya vagy más üzleti körülmény. Ez az attribútum fontos az „Értékesítési rendelések törlési trendjei” dashboardhoz. A leggyakoribb elutasítási okok elemzésével feltárhatók az elvesztett értékesítések kiváltó okai. Az eredmények alapján fejleszthető a készletgazdálkodás, az árképzés vagy az ügyfélkommunikáció, és csökkenthető a rendelések törlési aránya. Miért fontos? Megmutatja, miért törölték a rendeléseket. A kiváltó okok elemzésével csökkenthető az elvesztett értékesítések száma, és pontosabbá tehető az előrejelzés. Hol szerezhető be? Az értékesítési bizonylat tételadatait tartalmazó VBAP táblában, az ABGRU mezőben található. Példák 0215Z5 | |||
| Értékesítési szervezet SalesOrganization | A termékek vagy szolgáltatások értékesítéséért felelős szervezeti egység. | ||
| Leírás Az értékesítési szervezet az SAP egyik alapvető szervezeti egysége, amely a vállalatot az értékesítési igényei szerint tagolja. Feladata az értékesítési feltételek kialakítása, valamint az áruk és szolgáltatások értékesítése. A process mining során ez az attribútum fontos elemzési szempont. Segítségével összehasonlítható a folyamatok teljesítménye, hatékonysága és megfelelése az egyes értékesítési egységek, régiók vagy üzletágak között. Így azonosíthatók a jól teljesítő szervezetek bevált gyakorlatai, valamint a többi területen szükséges fejlesztések. Miért fontos? Lehetővé teszi a szervezeti egységek összehasonlítását, így mérhető a folyamatok hatékonysága és megfelelése az egyes üzletágakban vagy régiókban. Hol szerezhető be? Az értékesítési bizonylat fejlécadatait tartalmazó VBAK táblában, a VKORG mezőben található. Példák 100025003100 | |||
| Felhasználó User | Annak a munkatársnak a felhasználói azonosítója, aki létrehozta vagy utoljára módosította a bizonylatot, illetve végrehajtotta a tevékenységet. | ||
| Leírás Ez az attribútum rögzíti, melyik SAP-felhasználó felelős egy adott folyamatbeli eseményért. Megmutatja például, ki rögzítette a rendelést, vagy ki könyvelte az árukiadást a raktárban. A felhasználó szerinti elemzés segít megérteni a munkaterhelés eloszlását, feltárni a képzési igényeket, és észrevenni, ha a felhasználók eltérően végzik ugyanazt a feladatot. Hasznosak azokhoz a dashboardokhoz, amelyek az erőforrások teljesítményét, a megfelelést és a manuális beavatkozásokat követik. Miért fontos? Láthatóvá teszi az erőforrások teljesítményét és terhelését, segít feltárni a felhasználókhoz köthető folyamateltéréseket, és támogatja a megfelelés, valamint az automatizálási lehetőségek elemzését. Hol szerezhető be? Számos SAP-fejléctáblában megtalálható a „Létrehozta” (ERNAM) vagy a „Módosította” (AENAM) mezőben, például a VBAK, LIKP és VBRK táblákban. Példák CBURKEJSMITHRWILLIAMS | |||
| Nettó érték NetAmount | Az értékesítési rendelés teljes értéke, a fejléc szintjén, adók és kedvezmények nélkül. | ||
| Leírás A nettó érték az értékesítési rendelés pénzben kifejezett értéke. Minden folyamatpéldányhoz fontos pénzügyi mutató. Az értékalapú process mining során ez az attribútum segít a nagy értékű rendelésekre összpontosítani a folyamatfejlesztést. Az elemzők összevethetik a folyamatproblémákat, például a késedelmeket és az utómunkát, azok pénzügyi hatásával. Ez megalapozza a változtatások üzleti indoklását. Megvizsgálható például, hogy a nagy értékű rendelések feldolgozása hatékonyabb vagy kevésbé hatékony-e, mint a kisebb értékűeké. Miért fontos? Értékalapú elemzést tesz lehetővé, így a fejlesztési erőfeszítések azokra a rendelésekre összpontosíthatók, amelyek a legnagyobb pénzügyi hatással vannak a vállalatra. Hol szerezhető be? Az értékesítési bizonylat fejlécadatait tartalmazó VBAK táblában, a NETWR mezőben található. Példák 1500.0012550.75850.50 | |||
| Szállítási zárolás DeliveryBlock | Azt jelző kód, hogy az értékesítési rendelés szállítása zárolva van-e, ami megakadályozza a szállítási bizonylat létrehozását. | ||
| Leírás A szállítási zárolás az értékesítési rendelés fejléc- vagy tételszintű állapota, amely ideiglenesen megállítja a folyamatot a szállítás előtt. A zárolást a felhasználó manuálisan is beállíthatja, de a rendszer is elrendelheti például hitelkeret-túllépés vagy hiányos adatok miatt. Ez az attribútum fontos a „Szállítási zárolások és utómunka elemzése” dashboardhoz. A zárolások gyakoriságának, időtartamának és okainak elemzése feltárja a teljesítési folyamat fő szűk keresztmetszeteit. A zárolások csökkentése javítja a határidőre történő szállítást és a teljes ciklusidőt. Miért fontos? Közvetlenül megmutatja a teljesítési folyamat szűk keresztmetszeteit. A folyamat hatékonyabbá tételéhez fontos megérteni, miért és milyen gyakran zárolják a rendeléseket. Hol szerezhető be? Az értékesítési bizonylat fejlécadatait tartalmazó VBAK táblában, a LIFSK mezőben található. Példák 0102Z1 | |||
| Ügyfélszám CustomerNumber | Az értékesítési rendelést leadó ügyfél egyedi azonosítója. | ||
| Leírás Ez az attribútum a „Vevő” szerepkört jelöli, vagyis az értékesítési rendeléshez tartozó elsődleges ügyfélszámlát. A tranzakciót az alapadatokban szereplő ügyfélhez kapcsolja. Az ügyfélszám szerinti elemzéssel feltárhatók az egyes ügyfelekre jellemző folyamatok és teljesítmény. Megválaszolható például, mely ügyfeleknél a leghosszabb a ciklusidő, a leggyakoribb az utómunka, vagy a legtöbb a rendelésmódosítás. Ez segít javítani az ügyfélkapcsolat-kezelést és a szolgáltatás színvonalát. Miért fontos? Lehetővé teszi az ügyfélközpontú elemzést, így feltárhatók az egyes ügyfeleket érintő folyamatproblémák, és mérhető az ügyfelenkénti teljesítmény. Hol szerezhető be? Az értékesítési bizonylat fejlécadatait tartalmazó VBAK táblában, a KUNNR mezőben található. Példák 100234100567200112 | |||
| Határidőre történt a szállítás IsOnTimeDelivery | Logikai jelző, amely megmutatja, hogy az árut a visszaigazolt szállítási dátumon vagy az előtt adták-e fel. | ||
| Leírás Ez a számított attribútum összeveti az árukiadás tényleges dátumát az értékesítési rendeléshez tartozó „ConfirmedDeliveryDate” értékével. Ha az árukiadás dátuma a visszaigazolt dátummal megegyezik vagy korábbi, az érték igaz, egyébként hamis. Ez az attribútum megkönnyíti az „Határidőre történő szállítás teljesítménye” dashboard létrehozását és a határidőre történő szállítási arány KPI kiszámítását. Az elemzésekben és diagramokon nem kell minden alkalommal külön összehasonlítani a dátumokat, így a teljesítmény könnyen összesíthető és megjeleníthető. A szállítás megbízhatósága egy pillantással felmérhető. Miért fontos? Egyszerűen és egyértelműen méri a szállítási teljesítményt, így könnyen kiszámítható a határidőre történő szállítási arány KPI. Hol szerezhető be? Ez egy számított attribútum. A logika összeveti az „Árukiadás” tevékenység időbélyegét a „ConfirmedDeliveryDate” attribútum értékével. Példák truefalse | |||
| Hitelvizsgálat állapota CreditCheckStatus | Megmutatja az értékesítési bizonylathoz tartozó hitelvizsgálat állapotát. | ||
| Leírás Ez az attribútum az értékesítési rendelés automatikus vagy manuális hitelvizsgálatának eredményét mutatja. Gyakori állapotok: „Jóváhagyva”, „Elutasítva” és „Zárolva”. Ez az attribútum fontos a „Hitelvizsgálat feldolgozási idejének elemzése” dashboardhoz. A hitelvizsgálat szakaszában fellépő késedelmek és zárolások jelentősen növelhetik a rendelés teljesítési ciklusidejét. Az állapot elemzésével felmérhető a hitelkezelési folyamat hatékonysága és az értékesítés ütemére gyakorolt hatása. Miért fontos? Közvetlenül befolyásolja a rendelések feldolgozási sebességét. Az állapot elemzésével feltárhatók a hitelkezelés azon szűk keresztmetszetei, amelyek késleltetik a rendelések teljesítését. Hol szerezhető be? Az értékesítési bizonylat állapotát tartalmazó VBUK táblában vagy közvetlenül a VBAK táblában, a hitelállapot mezőben (például CMGST) található. Példák ABD | |||
| Szállítási feltételek ShippingConditions | Meghatározza az áruk ügyfélhez történő szállításának általános módját. | ||
| Leírás A szállítási feltételek határozzák meg, hogyan szállítják ki a rendelést, például normál, expressz vagy személyes átvétellel. Ezekről az ügyféllel állapodnak meg, és befolyásolják a logisztikai tervezést. Ez az attribútum a „Szállítási módok hatékonysága és költsége” elemzéshez használható. A folyamat szállítási feltételek szerinti csoportosításával megvizsgálható, hogy egyes módoknál gyakoribbak-e a késedelmek, vagy hosszabb-e a ciklusidő. Az adatok segítenek a logisztika fejlesztésében és az ügyfelek szállítási időkkel kapcsolatos elvárásainak kezelésében. Miért fontos? Lehetővé teszi a logisztikai teljesítmény elemzését, és megmutatja, hogy egyes szállítási módokhoz késedelem vagy nagyobb hatékonyság kapcsolódik-e. Hol szerezhető be? Az értékesítési bizonylat fejlécadatait tartalmazó VBAK táblában, a VSBED mezőben található. Példák 011020 | |||
| Történt utómunka IsRework | Logikai jelző, amely megmutatja, hogy az értékesítési rendelésen történt-e jelentős módosítás vagy utómunka a létrehozása után. | ||
| Leírás Ez a számított attribútum azonosítja azokat a folyamatpéldányokat, amelyeknél utómunka történt, például egy vagy több „Értékesítési rendelés módosítva” tevékenység. Az utómunka pontos meghatározását, például az ár, a mennyiség vagy a szállítási dátum módosítását, a projekt beállításakor rögzítik. Ez az attribútum fontos az „Értékesítési rendelések utómunkája és módosítási gyakorisága” dashboardhoz, valamint az értékesítésirendelés-utómunka aránya KPI-hoz. Egyszerűvé teszi azoknak a rendeléseknek a szűrését és összehasonlítását, amelyek egyenes úton haladtak végig, illetve manuális módosítást igényeltek. Így mérhető az utómunka ciklusidőre és költségekre gyakorolt hatása. Miért fontos? Közvetlenül méri az utómunka gyakoriságát, így elemezhetők annak okai, valamint a folyamat hatékonyságára és ciklusidejére gyakorolt hatása. Hol szerezhető be? Ez az eseménynaplóból származtatott számított attribútum. A logika azt ellenőrzi, hogy szerepel-e „Értékesítési rendelés módosítva” tevékenység vagy a CDHDR/CDPOS táblákban rögzített konkrét módosítási esemény. Példák truefalse | |||
| Visszaigazolt szállítási dátum ConfirmedDeliveryDate | Az a dátum, amelyre az áruk vagy szolgáltatások szállítását az ügyfélnek visszaigazolták. | ||
| Leírás Ez az ügyfélnek vállalt szállítási dátum, amelyet az anyagok rendelkezésre állása és az ütemezés alapján határoznak meg. Ez szolgál alapul a szállítási teljesítmény méréséhez. Ez az attribútum az „Határidőre történő szállítás teljesítménye” dashboard és a határidőre történő szállítási arány KPI alapja. A visszaigazolt szállítási dátum és a tényleges árukiadási dátum összevetésével megállapítható, hogy a rendelést időben, korábban vagy késve teljesítették-e. Ez az ellátási lánc megbízhatóságának és az ügyfél-elégedettségnek egyik fő mérőszáma. Miért fontos? Ez az alap a határidőre történő szállítás méréséhez, amely az ügyfél-elégedettség és az ellátási lánc hatékonyságának fontos KPI-ja. Hol szerezhető be? Az értékesítési bizonylat ütemezési sorait tartalmazó VBEP táblában, az EDATU mezőben található. Példák 2023-05-102023-06-202023-07-01 | |||
Az Order to Cash vevőirendelés-feldolgozási folyamat tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Áru kiadva | Fontos esemény, amely során az áru tulajdonjoga átszáll, és az áru hivatalosan elhagyja a raktárt. Ez egy kifejezett pénzügyi könyvelési esemény, amely anyagbizonylatot hoz létre és frissíti a készletet. | ||
| Miért fontos? Ez a „szállítás” eseménye, és fontos mérföldkő a határidőre történő kézbesítés, valamint a teljesítési átfutási idő mérésében. Pénzügyi adatokat frissít, és a fizikai teljesítési folyamatban már nem visszafordítható pontot jelent. Hol szerezhető be? Anyagbizonylat (MKPF/MSEG) létrehozása árukiadási mozgásnemmel (például 601), a szállítási bizonylathoz kapcsolva. Rögzítés Anyagbizonylat (MKPF/MSEG) létrehozása árukiadási mozgásnemmel, a szállításhoz kapcsolva. Eseménytípus explicit | |||
| Értékesítési rendelés létrehozva | Új értékesítési rendelés létrehozását jelzi. Ez kifejezett eseményként rögzül, amikor a felhasználó elment egy új rendelést, jellemzően az SAP VA01 tranzakciójával. | ||
| Miért fontos? Ez az Order to Cash folyamat elsődleges kezdő eseménye. Időpontjának elemzése elengedhetetlen a teljes átfutási idő és a beérkező rendelések számának méréséhez. Hol szerezhető be? A VBAK táblában (értékesítési bizonylat fejadatai) rögzül a létrehozás dátuma (ERDAT) és időpontja (ERZET). A tranzakciókód a VBAK-TCODE mezőben található. Rögzítés A VBAK táblában szereplő létrehozási időbélyeg (ERDAT, ERZET) alapján meghatározott esemény. Eseménytípus explicit | |||
| Fizetés beérkezett | Ez az esemény azt jelzi, hogy az ügyfél befizetése beérkezett, és hozzárendelték a számlához, így a nyitott vevőkövetelés rendezetté vált. Ez könyvelési esemény, amelyre egy pénzügyi bizonylat kiegyenlítéséből lehet következtetni. | ||
| Miért fontos? Ez az értékesítésből származó pénz beérkezésének utolsó lépése. Ezzel zárul a számlázástól a fizetésig, valamint az értékesítési rendelés teljesítéséig eltelt idő mérése. Hol szerezhető be? A rendszer a BSEG tábla vevői tételéhez tartozó kiegyenlítési bizonylat adataiból következtet erre. Ha a BSEG-AUGBL (kiegyenlítési bizonylat) és a BSEG-AUGDT (kiegyenlítés dátuma) mező ki van töltve, a fizetés beérkezett. Rögzítés A rendszer a BSEG táblában a vevőkövetelési tétel kiegyenlítési dátumának (AUGDT) kitöltöttségéből következtet erre. Eseménytípus inferred | |||
| Rendelés visszaigazolva | Ez a tevékenység azt jelzi, hogy az értékesítési rendelés sikeresen teljesítette az első ellenőrzéseket, és visszaigazolták a teljesítését. Általában abból állapítható meg, hogy a rendelés már nincs zárolva, és az ütemezési sorokban visszaigazolt mennyiségek szerepelnek. | ||
| Miért fontos? Ez fontos mérföldkő, amely elválasztja a rendelésfelvételt a teljesítéstől. Ettől a ponttól mérhető a teljesítési átfutási idő és a határidőre történő szállítás. Hol szerezhető be? A VBEP ütemezési soraiban szereplő visszaigazolt mennyiség (BMENG > 0) és a szállítási zárolás hiánya alapján állapítható meg (például a VBUK-LIFSK mező üres). Rögzítés Az ütemezési sor visszaigazolása (VBEP-BMENG > 0) és a fej szintű zárolások feloldása alapján következtethető ki. Eseménytípus inferred | |||
| Rendeléstétel lezárva | Ez a tevékenység jelzi az értékesítési rendelés egy tételének végleges lezárását. A tétel teljesítettnek számít, ha az árut kiszállították és kiszámlázták. A lezárásra a tétel összesített állapotából lehet következtetni. | ||
| Miért fontos? Ez a folyamat sikeres záróeseménye. A tételek lezárási idejének elemzésével megérthető a folyamat teljes időtartama, és azonosíthatók a szükségtelenül nyitva maradó rendelések. Hol szerezhető be? A rendszer a tétel VBUP táblában szereplő összesített állapotából (értékesítési bizonylat: tételállapot) következtet erre. Ha a VBUP-GBSTA értéke 'C' (teljesen feldolgozva), a tétel lezártnak számít. Rögzítés A rendszer abból következtet erre, hogy a tétel állapota (VBUP-GBSTA) 'C' értékre (teljesen feldolgozva) változik. Eseménytípus inferred | |||
| Számla létrehozva | A vevői számla vagy számlázási bizonylat létrehozását jelzi. Ez kifejezett esemény: új bizonylatot hoz létre a rendszerben, és elindítja a folyamat fizetési szakaszát. | ||
| Miért fontos? Ez a mérföldkő indítja el a számlázástól a fizetésig eltelt idő mérését. A számlázás késedelme közvetlenül rontja a pénzforgalmat. Hol szerezhető be? A VBRK táblában (számlázási bizonylat: fejlécadatok) rögzül a létrehozás dátuma (ERDAT) alapján. Az értékesítési rendeléshez vagy a szállításhoz a VBFA tábla kapcsolja. Rögzítés A VBRK táblában szereplő létrehozási időbélyeg (ERDAT) alapján rögzített esemény. Eseménytípus explicit | |||
| Áruk összekészítése befejezve | Azt jelzi, hogy a szállításhoz tartozó összes tételt fizikailag kivették a raktárból. Raktárirányítási rendszer (WM) használata esetén ez az áthelyezési rendelés állapotából következtethető ki. | ||
| Miért fontos? Az összekészítési idő elemzése segít javítani a raktári működést. Az itt jelentkező késedelmek közvetlenül befolyásolják a teljes szállítási időt és a teljesítési ciklust. Hol szerezhető be? A LIPS-KOSTA mezőben szereplő szállításitétel-összekészítési státusz „C” értékre változásából állapítható meg, ami a teljes összekészítést jelenti. Aktív WM esetén az áthelyezési rendelés visszaigazolásából is következtethető (LTAK/LTAP táblák). Rögzítés Az összekészítési státusz (LIPS-KOSTA) változásából vagy a WM áthelyezési rendelésének visszaigazolásából következtethető ki. Eseménytípus inferred | |||
| Értékesítési rendelés módosítva | A már létrehozott értékesítési rendelés módosítását jelzi. A változások a külön erre szolgáló módosítási naplótáblákban (CDHDR, CDPOS) rögzülnek, amikor például a mennyiség, az ár vagy a dátum változik. | ||
| Miért fontos? A módosítások nyomon követésével feltárhatók az utómunkák, a folyamat instabilitása és az adatminőségi problémák. A gyakori módosítások a kezdeti rendelésfelvétel hibáira utalhatnak, amelyek késedelmet okoznak. Hol szerezhető be? A CDHDR (fej) és CDPOS (tétel) módosításidokumentum-táblákból nyerhető ki, az OBJECTCLAS = 'VERKBELEG' feltétellel. Az időbélyeg és a módosított mező is azonosítható. Rögzítés Az értékesítési bizonylatok módosításidokumentum-tábláiból (CDHDR, CDPOS) származó esemény. Eseménytípus explicit | |||
| Hitelképesség-ellenőrzés elvégezve | Azt jelzi, hogy befejeződött az értékesítési rendeléshez tartozó ügyfél automatikus vagy kézi hitelképesség-ellenőrzése. Ez általában a bizonylat általános hitelstátuszának változásából állapítható meg. | ||
| Miért fontos? A hitelképesség-ellenőrzés gyakran szűk keresztmetszet. A lépés időtartamának mérése elengedhetetlen a „Hitelképesség-ellenőrzés feldolgozási idejének elemzéséhez” és a rendelésfeldolgozás felgyorsításához. Hol szerezhető be? A VBUK tábla hitelstátusz-mezőiből (értékesítési bizonylat: fejstátusz) következtethető ki. A VBUK-CMGST mező zárolt állapotról felszabadítottra változása jelzi ezt a tevékenységet. Rögzítés Az általános hitelstátuszmező (VBUK-CMGST) változásából következtethető ki. Eseménytípus inferred | |||
| Kézbesítés igazolva | Ez a tevékenység azt jelzi, hogy az ügyfél átvette az árut. Akkor rögzül, amikor a rendszerben feljegyzik az átvételi igazolást, ami gyakran a szállítási bizonylat állapotát is frissíti. | ||
| Miért fontos? Ez az esemény rögzíti a tényleges szállítási dátumot. Erre van szükség ahhoz, hogy pontosan mérhető legyen, a szállítás a vállalt határidőre történt-e. Hol szerezhető be? A rendszer a szállítási igazolás állapotából (VBUK-PODAT) következtet erre, ha az érték „C” (megerősítve). A megerősítés dátuma a VLPOD-PODAT mezőben található. Ezt nem minden rendszerben vezetik be. Rögzítés A rendszer a szállítás POD-állapotának frissítéséből (VBUK-PODAT) vagy a VLPOD táblában szereplő bejegyzésből következtet erre. Eseménytípus inferred | |||
| Rendelés törölve | Azt jelzi, hogy az értékesítési rendelést a teljesítés előtt törölték. Ez általában úgy jelenik meg a rendszerben, hogy a rendelés minden érintett tételéhez elutasítási okot rendelnek. | ||
| Miért fontos? Ez a folyamat sikertelen záróeseménye, amely közvetlenül támogatja a rendeléstörlési arány KPI mérését. A törlések időpontjának és okának megértése rávilágít az értékesítési folyamat problémáira. Hol szerezhető be? A rendszer abból következtet erre, hogy az értékesítési rendelés minden aktív tételénél ki van töltve a VBAP-ABGRU (elutasítási ok) mező. A módosítás dátuma a CDHDR/CDPOS táblákban található. Rögzítés A rendszer abból következtet erre, hogy minden tételnél ki van töltve az elutasítási ok mező (VBAP-ABGRU). Eseménytípus inferred | |||
| Szállítás létrehozva | Ez az esemény jelzi a kimenő szállítási bizonylat létrehozását. A bizonylat utasítja a raktárt az áruk összekészítésének és feladásának megkezdésére. Az esemény a bizonylatfolyamatból közvetlenül rögzíthető. | ||
| Miért fontos? Ez a fizikai teljesítési folyamat első lépése. A rendelés visszaigazolása és a szállítás létrehozása közötti idő megmutatja, milyen gyorsan indul el a logisztikai folyamat. Hol szerezhető be? A LIKP táblában (SD-bizonylat: szállítási fejadatok) létrejövő rekord. Az értékesítési rendeléshez a VBFA bizonylatfolyam-tábla kapcsolja. Rögzítés A LIKP táblában szereplő létrehozási időbélyeg alapján meghatározott esemény, a VBFA táblán keresztül összekapcsolva. Eseménytípus explicit | |||
| Szállítási zárolás beállítva | Azt jelzi, hogy szállítási zárolást állítottak be az értékesítési rendeléshez, így nem hozható létre szállítási bizonylat. Ez a módosítási naplókból közvetlenül rögzíthető, vagy az állapottáblákból következtethető ki. | ||
| Miért fontos? Ez a tevékenység közvetlenül kapcsolódik az „Értékesítési rendelések zárolási aránya” KPI-hoz. A zárolások okának és gyakoriságának feltárásával megértheti a teljesítési késedelmek hátterét. Hol szerezhető be? A VBAK-LIFSK mező módosítási naplóiban (CDHDR/CDPOS) található meg. A VBAK-LIFSK mező kitöltésének megfigyelésével is kikövetkeztethető. Rögzítés A VBAK-LIFSK vagy a VBAP-LIFSP mező módosítási dokumentumaiból származó esemény. Eseménytípus explicit | |||
| Számla sztornózva | Egy korábban létrehozott számlázási bizonylat visszavonását jelzi. Ez kifejezett tranzakció: új sztornóbizonylatot hoz létre az eredeti bizonylat ellentételezésére. | ||
| Miért fontos? A számlák sztornózásának követése segít feltárni az árazási problémákat, a szállítási eltéréseket és az adathibákat. Ez a számlaeltérések aránya KPI mérését is támogatja. Hol szerezhető be? Kifejezett esemény, amelyet egy sztornó számlázási bizonylat létrehozása rögzít (VBRK-VBTYP = 'N' vagy 'O'). Az eredeti számlára a VBRK-SFAKN hivatkozik. Rögzítés Sztornóbizonylat létrehozása a VBRK táblában, az eredeti számlára hivatkozva. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Program fejlesztése: Az SE38 vagy SE80 tranzakcióval hozzon létre új, futtatható ABAP-programot. Ebben a programban helyezze el az adatok kinyerésének teljes logikáját.
- A kiválasztási képernyő beállítása: Hozzon létre a programban egy kiválasztási képernyőt az adatok szűréséhez. Vegyen fel paramétereket az értékesítési bizonylat létrehozási dátumához (VBAK-ERDAT), az értékesítési szervezethez (VBAK-VKORG) és az értékesítési bizonylat típusához (VBAK-AUART). Így az adatkinyerés újra felhasználható és könnyen kezelhető lesz.
- Adatdeklarációk: Definiálja a különböző SAP-táblákból származó adatok tárolásához szükséges belső táblákat és struktúrákat, például a VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK és BSAD táblákhoz. Definiálja az eseménynapló végső kimeneti struktúráját is, a szükséges attribútumokkal.
- Alapul szolgáló értékesítési rendelések lekérése: Írja meg a kezdeti SELECT utasítást, amely a felhasználó által a kiválasztási képernyőn megadott feltételek alapján lekéri az értékesítési rendelés fejléceit (VBAK) és tételeit (VBAP). Ezek alkotják az elemzendő esetek alapadatkészletét.
- A „Létrehozás” esemény kinyerése: Járja végig a kiválasztott VBAK-rekordokat. Minden rekordnál töltse ki az eseménynapló struktúráját a „Értékesítési rendelés létrehozva” tevékenységgel. A StartTime értékéhez használja a VBAK-ERDAT és VBAK-ERZET mezőt.
- Módosítási napló eseményeinek kinyerése: Kérje le a CDHDR és CDPOS táblákból a kiválasztott értékesítési rendelések azon rekordjait, amelyeknél az OBJECTCLAS értéke „VERKBELEG”. Járja végig az eredményeket, és azonosítsa a konkrét mezőváltozásokat. Például a VBAK-LIFSK módosítása a „Szállítási zárolás beállítva”, a VBUK-CMGST módosítása pedig a „Hitelvizsgálat elvégezve” eseményt jelzi. Minden más releváns módosítást „Értékesítési rendelés módosítva” eseményként rögzíthet.
- Bizonylatfolyamat adatainak kinyerése: A kiválasztott értékesítési rendelésekhez kérdezze le a bizonylatfolyamat-táblát (VBFA). Ez a tábla kapcsolja össze az értékesítési rendeléseket a későbbi bizonylatokkal, például a szállításokkal, az anyagmozgásokkal és a számlákkal. Kérje le az összes kapcsolódó bizonylatot a további feldolgozáshoz.
- Szállítási és teljesítési események kinyerése: A VBFA táblából lekért szállítási bizonylatszámok alapján kérdezze le a LIKP és LIPS táblákat a „Szállítás létrehozva” eseményhez. A „Áru kiadva” esemény rögzítéséhez kérdezze le az MKPF és MSEG táblákat az árukiadási bizonylatokra, ahol a mozgásnem „601”. Ha aktív a Raktárgazdálkodás, kérdezze le az LTAK és LTAP táblákat, és keresse meg az utolsó átszállítási rendelési tétel visszaigazolási idejét a „Komissiózás befejezve” esemény meghatározásához. A „Kézbesítés igazolva” eseményhez ellenőrizze a szállítási fejléc VBUK-PODAT állapotát.
- Számlázási és fizetési események kinyerése: A VBFA táblából lekért számlázási bizonylatszámok alapján kérdezze le a VBRK és VBRP táblákat a „Számla létrehozva” és a „Számla sztornózva” eseményekhez. Az utóbbi eseményt a VBRK-FKSTO = „X” feltétel jelzi. A „Fizetés beérkezett” eseményhez kapcsolja össze a VBRK számláját a BKPF könyvelési bizonylatával, majd keresse meg a kiegyenlítési bizonylatot és a kiegyenlítés dátumát a BSAD táblában.
- Állapotokon alapuló események kinyerése: Az üzleti események meghatározásához használja a VBUP (tételállapot) és VBUK (fejlécállapot) táblákat. Például egy tétel akkor tekinthető „Rendeléstétel lezárva” állapotúnak, ha a VBUP-GBSTA értéke „C”. A rendelés akkor „Rendelés törölve”, ha minden érintett tételnél meg van adva az elutasítás oka (VBAP-ABGRU).
- Egyesítés és formázás: Egyesítse az összes rögzített eseményt egyetlen végső belső táblába. Minden eseményrekordnál töltse ki helyesen az összes attribútumot, például a SalesOrder, Activity, StartTime és User mezőt. Adja hozzá a SourceSystem és LastDataUpdate értékét is.
- Kimeneti fájl létrehozása: A végső belső tábla CSV-fájlba exportálásához használja a GUI_DOWNLOAD funkciómodult vagy a cl_gui_frontend_services=>gui_download metódust. A fájlt UTF-8 kódolással mentse a felhasználó helyi gépére.
Konfiguráció
- Előfeltételek: ABAP-fejlesztői jogosultságok, például hozzáférés az SE38 tranzakcióhoz, valamint olvasási jogosultság az összes szükséges SAP-táblához, többek között a VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG és BSAD táblákhoz.
- Kiválasztási paraméterek: A programban szűrési paramétereket tartalmazó kiválasztási képernyőre van szükség. A fő paraméterek:
- Dátumtartomány: Kötelezően adjon meg dátumtartományt a vevői rendelések létrehozásához (VBAK-ERDAT). Kezdje az utolsó 3–6 hónappal, hogy kezelhető méretű maradjon az adathalmaz.
- Értékesítési szervezet: A VBAK-VKORG mező alapján szűkítse az elemzést a kiválasztott üzleti egységekre.
- Értékesítési bizonylat típusa: A VBAK-AUART mező alapján csak a releváns rendeléstípusokat, például a normál rendeléseket vegye fel, az egyéb típusokat, például az árajánlatokat és a visszárukat pedig zárja ki.
- Teljesítmény: Nagy adatmennyiségnél a módosítási naplókat (CDHDR, CDPOS) és a bizonylatfolyamot (VBFA) tartalmazó táblák lekérdezése nagyon lassú lehet. Optimalizálja a programot úgy, hogy a WHERE feltételekben indexelt mezőket használjon. Nagyon nagy adatmennyiség esetén az SM36 tranzakcióval ütemezze a programot háttérfeladatként, csúcsidőn kívülre.
- Módosítási naplózás aktiválása: Ez a módszer az SAP módosítási bizonylatok funkciójára támaszkodik. Ellenőrizze, hogy be van-e kapcsolva a módosítások naplózása a fontos adatelemeknél, például a LIFSK, CMGST és ABGRU mezőknél. Ezt a VERKBELEG objektumhoz tartozó SCDO tranzakcióban ellenőrizheti.
Példa-lekérdezés abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM. Lépések
- Előfeltételek: Gondoskodjon arról, hogy közvetlen, csak olvasási hozzáférése legyen az SAP ECC adatbázisához. A csatlakozáshoz és a lekérdezések futtatásához szüksége lesz egy adatbázis-kezelő eszközre, például a DBeaverre, az SQL Server Management Studióra vagy az Oracle SQL Developerre.
- Az SQL-szkript beszerzése: Másolja ki a dokumentum „Lekérdezés” szakaszában megadott teljes SQL-lekérdezést.
- Csatlakozás az adatbázishoz: Nyissa meg az adatbázis-kezelő eszközt, és csatlakozzon az SAP ECC adatbázis-példányához. Szüksége lesz a kiszolgáló címére, a portra, az adatbázis nevére és a megfelelő bejelentkezési adatokra.
- A lekérdezés beállítása: Illessze be az SQL-szkriptet egy új lekérdezésszerkesztő-ablakba. Keresse meg a SalesOrders nevű fő Common Table Expression (CTE) konfigurációs részét. Cserélje le a kezdő dátum (
'{StartDate}'), a záró dátum ('{EndDate}'), az értékesítési szervezetek ('{SalesOrgs}') és a bizonylattípusok ('{DocTypes}') helyőrző értékeit az elemzéshez használni kívánt tényleges értékekre. - A lekérdezés futtatása: Futtassa a beállított SQL-szkriptet. A dátumtartománytól és az SAP-adatbázis méretétől függően a lekérdezés több percig is futhat.
- Az eredmények ellenőrzése: A lekérdezés lefutása után megjelenik az eredményhalmaz. Röviden ellenőrizze, hogy a várt oszlopokat tartalmazza-e, például SalesOrder, Activity és StartTime, valamint hogy többféle tevékenységhez is vannak-e sorok.
- Az adatok exportálása: Az adatbázis-kezelő exportálási funkciójával mentse az eredményhalmazt CSV-fájlba. Adjon a fájlnak beszédes nevet, például SAP_O2C_Event_Log.csv.
- Formázás a ProcessMind használatához: Nyissa meg a CSV-fájlt egy táblázatszerkesztőben. Ellenőrizze, hogy az oszlopfejlécek pontosan megfelelnek-e a szükséges attribútumoknak, például SalesOrder, Activity és StartTime. A StartTime és LastDataUpdate dátum- és időformátuma legyen egységes, és a ProcessMind által támogatott, például YYYY-MM-DD HH:MI:SS.
- Feltöltés a ProcessMindba: Töltse fel a végleges, megfelelően formázott CSV-fájlt a ProcessMind-projektbe elemzésre.
Konfiguráció
- Dátumtartomány: A lekérdezés a '{StartDate}' és '{EndDate}' helyőrzőkkel szűri a vevői rendeléseket a létrehozás dátuma (VBAK.ERDAT) alapján. Általában 3–6 hónapnyi adat elegendő ahhoz, hogy reprezentatív mintát kapjon anélkül, hogy túlzottan terhelné az adatbázist.
- Értékesítési szervezet szűrője: A '{SalesOrgs}' helyőrzővel korlátozza az adatkinyerést a kiválasztott értékesítési szervezetekre, például '1000' vagy '2000'. Ez segít az elemzés fókuszálásában és a lekérdezés gyorsításában.
- Bizonylattípus szűrője: A '{DocTypes}' helyőrzővel válassza ki a kívánt vevőirendelés-típusokat, például az 'OR' normál rendelést. Így kizárhatja a fő folyamatból a nem releváns bizonylatokat, például az ingyenes szállításokat és a visszárukat.
- Forrásrendszer-azonosító: A '{SourceSystemName}' rögzített helyőrző minden rekordhoz hozzárendeli a forrásrendszer nevét. Adjon meg egy beszédes nevet az SAP ECC-példányhoz, például SAP_ECC_PRD.
- Adatbázis-kompatibilitás: A dátum- és időmezők egyesítésére szolgáló [Your DB-specific timestamp function] helyőrző. Cserélje le az adatbázisának megfelelő függvényre, például SAP HANA esetén a TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS'), SQL Server esetén pedig a CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) kifejezésre.
- Előfeltételek: Ehhez a módszerhez közvetlen, csak olvasási jogosultságú adatbázis-hozzáférés szükséges. Az adatbázis-felhasználónak hozzá kell férnie a lekérdezésben hivatkozott összes táblához, többek között a VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK és BSAD táblákhoz.
Példa-lekérdezés sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''; Kezdje el most?
Használja ezt az adatsablont az Order to Cash vevőirendelés-feldolgozási folyamat lehetőségeinek feltárásához. Tegye meg az első lépést a hatékonyabb működés és a gyorsabb pénzbeáramlás felé.
Optimalizálja még ma az Order to Cash értékesítési folyamatot
Szüntesse meg a szűk keresztmetszeteket, csökkentse 30%-kal a ciklusidőt, és gyorsítsa fel a pénz beérkezését.
Nincs szükség bankkártyára. Néhány perc alatt beállíthatja.