Adatsablon a visszaküldések és visszatérítések feldolgozásához
Adatsablon a visszaküldések és visszatérítések feldolgozásához
- Javasolt attribútumok
- Nyomon követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez
A visszaküldések és visszatérítések feldolgozásának attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | A tevékenység pontos dátuma és időpontja. | ||
| Leírás Ez az időbélyeg jelöli az üzleti esemény pontos időpontját. A folyamat minden tevékenységénél rögzítik, így megállapítható az események sorrendje az adott ügyön belül. Az esemény időpontja minden időalapú elemzéshez szükséges: ebből számítható ki a tevékenységek közötti átfutási idő, azonosíthatók a várakozással töltött idő szűk keresztmetszetei, és mérhető az ügy teljes időtartama. Emellett lehetővé teszi a teljesítmény elemzését és a szolgáltatási szintre vonatkozó megállapodások (SLA-k) betartásának ellenőrzését. Miért fontos? Ez az időbélyeg szükséges az időtartamok kiszámításához, a folyamat teljesítményének elemzéséhez, a szűk keresztmetszetek feltárásához és az egyes visszáru-ügyek időrendjének megértéséhez. Hol szerezhető be? Az SAP-táblák különböző dátum- és időmezőiből származik. A létrehozási eseményeknél gyakran az ERDAT és ERZET mezőket használják (például a VBAK táblában). A módosítási eseményeknél a CDHDR tábla UDATE és UTIME mezői szolgálnak forrásként. Példák 2023-04-15T10:22:05Z2023-04-16T14:01:30Z2023-04-18T09:15:00Z | |||
| Tevékenység neve ActivityName | A visszáru-folyamatban bekövetkezett konkrét üzleti esemény vagy lépés neve. | ||
| Leírás Ez az attribútum a visszáru-folyamat egyetlen, jól elkülöníthető műveletét vagy státuszváltozását írja le, például „Visszáru-megrendelés létrehozása”, „Áruátvétel könyvelése” vagy „Jóváíró számla létrehozása”. Ezek a tevékenységek alkotják a folyamattérkép építőelemeit. A tevékenységek sorrendjének és gyakoriságának elemzése segít feltárni a leggyakoribb folyamatútvonalakat, az eltéréseket és az újramunkálási köröket. Ez alapvető annak megértéséhez, hogy mi történik egy ügyben, és milyen sorrendben, valamint minden process mining elemzés kiindulópontja. Miért fontos? A tevékenységek határozzák meg a folyamat lépéseit. Sorrendjük, időtartamuk és gyakoriságuk elemzése a process mining alapja, és megmutatja, hogyan zajlik valójában a munka. Hol szerezhető be? A VBUK/VBUP táblák státuszváltozásaiból, a bizonylatok létrehozásának eseményeiből (például a VBAK, LIKP, VBRK táblákból) vagy a CDHDR/CDPOS táblák módosítási naplóiból származik. Példák Visszáru-rendelés létrehozvaÁruátvétel könyveléseJóváírás létrehozvaVisszáru-megrendelés tételének feldolgozása befejeződött | |||
| Visszáru-ügy azonosítója ReturnCaseId | Az ügyfél visszáru-kérelmének egyedi azonosítója, amely összekapcsolja az összes kapcsolódó tevékenységet és bizonylatot. | ||
| Leírás A visszáru-ügy azonosítója a visszáru-folyamat teljes életciklusának nyomon követésére szolgáló elsődleges kulcs, az indítástól a lezárásig. Minden azonosító egy adott ügyfél-visszárut jelöl, és magában foglalja a kapcsolódó eseményeket, például a megrendelés létrehozását, a szállítást, az ellenőrzést és a jóváíró számla feldolgozását. A folyamat elemzéséhez ez az attribútum elengedhetetlen a folyamattérkép összeállításához. Segítségével a rendszer az egyes eseményeket teljes ügyfolyamatokká rendezi, így elemezhetők a folyamatváltozatok, az átfutási idők és az egyes visszáru-esetek szűk keresztmetszetei. Miért fontos? Ez az ügy egyedi azonosítója, amely összekapcsolja a visszáru-folyamat összes lépését, és lehetővé teszi a teljes folyamatmenet és teljesítmény elemzését. Hol szerezhető be? Ez általában az értékesítési és disztribúciós (SD) modulban szereplő visszáru-megrendelés száma. A VBAK táblában (értékesítési bizonylat fejlécadatai), a VBELN mezőben található. A bizonylatkategória (VBAK-VBTYP) visszáru esetén „H”. Példák 600001236000045660000789 | |||
| Forrásrendszer SourceSystem | Az a rendszer, amelyből az adatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja az adatok forrását, ami több rendszerből álló környezetben különösen fontos. Kontextust ad, és segít biztosítani az adatok eredetének nyomon követhetőségét és sértetlenségét. Elemzéskor az adatok forrásrendszer szerinti szűrésére vagy csoportosítására használható, ha több rendszer folyamatait egyesítik. Megerősíti, hogy az események a várt alkalmazásból, ebben az esetben az SAP ECC-ből származnak. Miért fontos? Azonosítja az adatok forrását, ami elengedhetetlen az adatirányításhoz és a több vállalati rendszert átfogó elemzésekhez. Hol szerezhető be? Ez egy statikus érték, amelyet az adatkinyerés során adnak meg az adott SAP ECC-példány azonosítására (például „ECC_PROD_100”). Példák SAP_ECC_PRODSAPECC_FINANCE_200 | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg, amely megmutatja, mikor frissítették utoljára a folyamathoz tartozó adatokat. | ||
| Leírás Ez az attribútum rögzíti a legutóbbi adatkinyerés vagy frissítés dátumát és időpontját. Megmutatja, mennyire frissek az elemzett adatok. Az elemzés során segít megítélni, mennyire naprakészek az eredmények. A felhasználók láthatják, mikoriak az adatok, ami befolyásolja a megállapítások érvényességét, különösen a folyamatban lévő működés nyomon követésekor. Miért fontos? Jelzi az adatok frissességét, így a felhasználók tudják, mennyire naprakész a folyamatelemzés, és mikorra várható a következő frissítés. Hol szerezhető be? Ez egy metaadat-attribútum, amely az adatkinyerési feladat futásának időbélyegét tartalmazza. Példák 2023-05-20T02:00:00Z2023-05-21T02:00:00Z | |||
| Anyagszám MaterialNumber | A visszaküldött termék egyedi azonosítója. | ||
| Leírás Az anyagszám, más néven SKU, pontosan azonosítja a visszáru tárgyát képező terméket, így részletes termékszintű elemzés végezhető. Az anyagszám szerinti visszáru-elemzéssel azonosíthatók a gyakran visszaküldött termékek. Ez minőségi problémára, pontatlan termékleírásra vagy gyártási hibára utalhat. Az attribútum hasznos például a „Visszáruk készletre gyakorolt hatása” dashboardhoz, és megmutatja, hogyan haladnak a különböző termékek a visszáru-folyamatban. Miért fontos? Azonosítja a visszaküldött termékeket, és rávilágíthat a minőség-ellenőrzés vagy a termékleírások pontosságának problémáira. Hol szerezhető be? Az értékesítési bizonylat tételeit tartalmazó VBAP táblában, a MATNR mezőben található. Példák RM-1025FG-2050-BACC-5591 | |||
| Feldolgozást végző felhasználó ProcessingAgent | A tevékenységet végző munkatárs felhasználói azonosítója. | ||
| Leírás Ez az attribútum rögzíti annak a személynek a felhasználónevét, aki egy adott folyamatlépésért, például a visszáru-megrendelés létrehozásáért vagy az áruátvétel könyveléséért felel. A mező neve gyakran „Módosította” vagy „Létrehozta”. A feldolgozást végző felhasználó szerinti elemzés fontos a teljesítmény és az erőforrások vizsgálatához. Segít azonosítani a kiemelkedően teljesítő munkatársakat, a további képzést igénylő felhasználókat, valamint a csapaton belüli munkaterhelés eloszlását. Az „Ügyintézők visszáru-feldolgozási teljesítménye” dashboardon például összehasonlíthatók az átfutási idők és a feldolgozási mennyiségek. Miért fontos? Nyomon követi a felhasználók részvételét, így elemezhető a csapat teljesítménye és a munkaterhelés eloszlása, valamint azonosíthatók a képzési igények és a bevált gyakorlatok. Hol szerezhető be? A fejlécet tartalmazó táblákban, például a VBAK, LIKP és VBRK táblában található ERNAM (létrehozta) vagy AENAM (módosította) mezőben. Módosítási eseményeknél a CDHDR tábla USERNAME mezője használható. Példák CBURNSDSCRANTONJHALPERT | |||
| Igényelt visszatérítési összeg RequestedRefundAmount | A visszatérítés várható összege, amelyet általában a visszaküldött termékek nettó értéke alapján határoznak meg. | ||
| Leírás Ez az attribútum a visszáru-megrendelésben rögzített kezdeti pénzösszeget jelöli. Ez szolgál a pénzügyi elemzés és egyeztetés alapjául. Az összeget a „Tényleges visszatérítési összeggel” összevetve nyomon követhetők az eltérések. Ez a „Visszatérítési összeg eltéréseinek nyomon követése” dashboard egyik fontos mutatója. Az érték elemzésével felmérhető a visszáruk pénzügyi hatása, és feltárhatók az árazással vagy a jóváírás kiszámításával kapcsolatos problémák. Miért fontos? Rögzíti a visszáru kezdeti pénzügyi értékét, ami szükséges az eltérések nyomon követéséhez és a visszaküldött áruk összértékének megértéséhez. Hol szerezhető be? Ez az érték általában a visszáru-megrendelés tételszintű nettó értéke. A VBAP táblában, a NETWR mezőben található. Példák 150.0049.991250.75 | |||
| Tényleges visszatérítési összeg ActualRefundAmount | Az ügyfélnek jóváírt végleges összeg, a pénzügyi bizonylatok szerint. | ||
| Leírás Ez az attribútum a ténylegesen feldolgozott és a könyvelési rendszerben rögzített, végleges visszatérítési összeget jelöli. Ez eltérhet az igényelt összegtől például a visszáru kezelési díja, a termék állapota miatti korrekció vagy más szabályok alkalmazása miatt. Ez az attribútum fontos a „Visszatérítési összeg eltéréseinek nyomon követése” dashboardhoz. Az igényelt összeggel összevetve feltárhatók a visszatérítés kiszámításának és jóváhagyásának rendszerszintű problémái, és ellenőrizhető a pénzügyi pontosság. Miért fontos? A visszáru végleges pénzügyi eredményét mutatja. Az igényelt összeggel összevetve ellenőrizhető a pontosság, és feltárhatók a pénzügyi veszteségek. Hol szerezhető be? A jóváíró számlához kapcsolódó pénzügyi bizonylatból származik. Általában a BSEG táblában (könyvelési bizonylat tételei), a WRBTR mezőben (összeg a bizonylat pénznemében), a megfelelő főkönyvi számlára könyvelt tételnél található. Példák 150.0045.001200.75 | |||
| Visszaküldés oka ReturnReason | Az ügyfél által a termék visszaküldéséhez megadott okkód. | ||
| Leírás Ez az attribútum az SAP-ban előre meghatározott okkódokkal jelzi, miért küldték vissza a terméket. Ilyen ok lehet például a „Szállítás közben megsérült”, a „Nem megfelelő terméket küldtek” vagy a „Nem megfelelő a méret”. Ez az attribútum fontos a kiváltó okok elemzéséhez. Ha az elemzők a folyamattérképet vagy a KPI-kat a visszaküldés oka szerint szűrik, kiderülhet, hogy egyes okok hosszabb feldolgozási idővel, több sikertelen ellenőrzéssel vagy bizonyos folyamateltérésekkel járnak-e. Az eredmények alapján javítható a termékminőség, a logisztika vagy az értékesítési folyamat. Miért fontos? Megmutatja, miért küldik vissza a termékeket. A kiváltó okok elemzésével csökkenthető a visszáruk aránya a termékminőség, a szállítás vagy a termékleírások javításával. Hol szerezhető be? Az értékesítési bizonylat tételeit tartalmazó VBAP táblában, az ABGRU mezőben található (értékesítési bizonylat elutasításának oka). Példák 001 - Sérült termék002 - Nem megfelelő termék005 - Késve érkezett | |||
| Visszáru-csatorna ReturnChannel | Az a csatorna, amelyen keresztül a visszárut kezdeményezték, például online, üzletben vagy telefonos ügyfélszolgálaton. | ||
| Leírás Ez az attribútum megadja, honnan érkezett a visszáru-kérelem, illetve milyen módon vették át. Segítségével elkülöníthetők a webes portálon, fizikai üzletben vagy ügyfélszolgálati munkatárson keresztül indított visszáruk. A folyamat visszáru-csatorna szerinti bontása segít megérteni a működésbeli különbségeket és az erőforrások elosztását. Az üzletben visszavitt termékek ellenőrzése például gyorsabb lehet, miközben a dokumentációs lépések eltérnek az online visszárukétól. Ez fontos dimenzió a „Visszáru-folyamat áteresztőképességének alakulása” dashboardon. Miért fontos? Megmutatja, milyen csatornán indítják a visszárut. A csatorna gyakran befolyásolja a folyamat menetét, az erőforrásigényt és az átfutási időt. Hol szerezhető be? Ez gyakran nem szabványos mező az SAP ECC-ben, ezért egy egyéni mezőből (például a VBAK táblából) kell kinyerni, vagy más adatokból, például az értékesítési szervezetből (VKORG) vagy a disztribúciós csatornából (VTWEG) kell kikövetkeztetni. Az adott megvalósítás részleteiért tekintse meg az SAP ECC dokumentációját. Példák Online portálÜzletbenTelefonos ügyfélszolgálat | |||
| Eredeti értékesítési bizonylat OriginalSalesDocument | Annak az eredeti értékesítési megrendelésnek a száma, amelyhez a visszáru kapcsolódik. | ||
| Leírás Ez az attribútum közvetlen kapcsolatot teremt az ügyfél eredeti vásárlásával. Hivatkozási bizonylatként összekapcsolja a visszárut az eredeti tranzakció adataival. Ez a kapcsolat részletesebb elemzést tesz lehetővé. Az elemzők megvizsgálhatják, miért küldik vissza bizonyos megrendelések termékeit, ellenőrizhetik az eredeti árakat és feltételeket, valamint áttekinthetik az ügyfél megrendeléstől a visszáruig tartó teljes folyamatát. Arra is választ adhat, hogy egyes kampányokban vagy csatornákon értékesített termékeknél magasabb-e a visszáruk aránya. Miért fontos? Összekapcsolja a visszárut az eredeti értékesítéssel, így a teljes ügyféltranzakció áttekinthető, és részletesebben elemezhetők a kiváltó okok. Hol szerezhető be? Ez a hivatkozás a visszáru-megrendelés tételszintjén található. A VBAP táblában, a VGBEL mezőben kereshető (a hivatkozási bizonylat száma). Példák 100034561000987110012345 | |||
| Jóváíró számla száma CreditMemoNumber | A visszatérítéshez kiállított jóváíró számla egyedi azonosítója. | ||
| Leírás Az SAP-ban a jóváíró számla az a hivatalos számlázási bizonylat, amely rögzíti az ügyfélnek fizetendő visszatérítést. Ez a szám egyedileg azonosítja a pénzügyi bizonylatot. Ez az attribútum szükséges a pénzügyi egyeztetéshez és a folyamat visszáru-feldolgozástól a pénzügyi elszámolásig tartó nyomon követéséhez. Fontos mérföldkő a folyamatban, és segítségével megkereshetők a kapcsolódó könyvelési bizonylatok, például a „Tényleges visszatérítési összeg” attribútumhoz. Miért fontos? Közvetlen hivatkozást ad az ügyfél visszatérítését engedélyező pénzügyi bizonylathoz, ami szükséges a pénzügyi ellenőrzéshez és egyeztetéshez. Hol szerezhető be? A jóváíró számla számlázási bizonylat. A száma a VBRK táblában (számlázási bizonylat fejlécadatai), a VBELN mezőben található. A visszáru-megrendelés bizonylatfolyamán keresztül kapcsolható hozzá. Példák 900011229000334490005566 | |||
| SLA-megfelelés IsSLACompliant | Jelző, amely megmutatja, hogy a visszatérítést a megállapodott szolgáltatási szintnek (SLA) megfelelően dolgozták-e fel. | ||
| Leírás Ez egy számított logikai attribútum, amely összeveti a „Visszatérítés feldolgozása” tevékenység tényleges dátumát a „Visszatérítés SLA-határideje” értékével. Értéke igaz, ha a visszatérítés időben lezárult, egyébként hamis. Az attribútum minden ügy SLA-teljesítését egyértelmű, kétértékű eredménnyel mutatja, így egyszerűbbé teszi az elemzést és a jelentéskészítést. Ezzel számítható ki a „Visszatérítés feldolgozásának SLA-megfelelése” arány, és könnyen kiszűrhetők a nem megfelelően teljesített ügyek. Miért fontos? Egyértelmű, kétértékű jelzést ad az egyes ügyek SLA-teljesítéséről, így egyszerűbbé teszi a megfelelés nyomon követését és jelentését. Hol szerezhető be? Ez egy számított attribútum. A logika: „Visszatérítés feldolgozása” EventTime <= RefundSLATargetDate. Példák truefalse | |||
| Ügyfélazonosító CustomerId | A visszárut kezdeményező ügyfél egyedi azonosítója. | ||
| Leírás Ez az attribútum azonosítja azt az ügyfelet, aki az SAP szóhasználatában a „vevő” (Sold-to Party), és visszaküldi a terméket. A visszáru-tranzakciót összekapcsolja az ügyféltörzs adataival. Az ügyfélazonosító szerinti elemzés feltárhatja a gyakran visszaküldő ügyfeleket, ami elégedetlenségre vagy a visszáru-szabályzat esetleges kijátszására utalhat. Az ügyfélszegmentáció adataival együtt azt is megmutathatja, hogy egyes ügyfélcsoportok visszaküldési szokásai vagy folyamattapasztalatai eltérnek-e. Miért fontos? Az ügyfelekhez kapcsolja a visszárukat, így elemezhető az ügyfélviselkedés, azonosíthatók a rendszeresen visszaküldők, és felmérhető a visszáruk ügyfélkapcsolatokra gyakorolt hatása. Hol szerezhető be? Az értékesítési bizonylat fejlécét tartalmazó VBAK táblában, a KUNNR mezőben található (vevő). Példák CUST-100432CUST-203991CUST-831102 | |||
| Üzem Plant | Az a fizikai helyszín vagy létesítmény, ahol a visszaküldött terméket átveszik és feldolgozzák. | ||
| Leírás Az SAP-ban az üzem olyan fizikai helyszínt jelöl, például raktárt vagy elosztóközpontot, ahol az árukat kezelik. Visszáru esetén általában itt veszik át és ellenőrzik a terméket. A folyamat üzem szerinti elemzésével feltárhatók a különböző létesítmények közötti teljesítménykülönbségek. Megmutathatja, mely raktárak ellenőrzik hatékonyabban a termékeket, vagy hol nagyobb az áteresztőképesség. Ez támogatja a „Tételvizsgálat áteresztőképessége és hatékonysága” dashboardot. Miért fontos? Azonosítja a visszárut feldolgozó helyszínt, így összehasonlítható a különböző raktárak és elosztóközpontok teljesítménye. Hol szerezhető be? A visszáru-megrendelés tételszintjén, a VBAP táblában, a WERKS mezőben található. Példák PL01WH02DC05 | |||
| Vállalatkód CompanyCode | A tranzakcióért felelős jogi személy vagy vállalat. | ||
| Leírás Az SAP-ban a vállalatkód önálló számviteli egységet jelöl. Minden pénzügyi tranzakciót, így a visszárukat és a visszatérítéseket is, egy adott vállalatkódhoz könyvelnek. Ez az attribútum szükséges a pénzügyi jelentésekhez, valamint a folyamat több országban vagy több jogi személynél működő szervezetek szerinti bontásához. A vállalatkód szerinti elemzéssel összehasonlítható a visszáru-folyamat teljesítménye a vállalat különböző jogi személyeinél. Miért fontos? Lehetővé teszi a visszáru-folyamatok szűrését és összehasonlítását a szervezet különböző jogi személyei között, ami fontos a pénzügyi elemzéshez. Hol szerezhető be? Az értékesítési bizonylat fejlécét tartalmazó VBAK táblában, a BUKRS_VF mezőben található (számlázó vállalatkód). Példák 10002000US01 | |||
| Visszáru-megrendelés státusza ReturnOrderStatus | A visszáru-megrendelés teljes feldolgozási státusza. | ||
| Leírás Ez az attribútum pillanatképet ad a visszáru-ügy aktuális állapotáról, például „Nyitott”, „Folyamatban” vagy „Befejezett”. Az értékesítési bizonylat fejléc- vagy tételszintű státuszainak összesítéséből származik. Elemzéskor az attribútummal kiszűrhetők az aktív vagy lezárt visszáruk. Segít nyomon követni a nyitott ügyek teljes munkaterhelését és előrehaladását, valamint összefoglalja az egyes visszáru-folyamatok eredményét. Miért fontos? Magas szinten mutatja, hol tart az ügy az életciklusában, így szűrhetők és elemezhetők a nyitott, folyamatban lévő vagy lezárt visszáruk. Hol szerezhető be? A VBUK (fejlécstátusz) és a VBUP (tételstátusz) táblák státuszmezőiből származik. A VBUK-GBSTK például a bizonylat teljes feldolgozási státuszát jelöli. Példák NyitottFolyamatbanBefejezett | |||
| Visszáru-szabályzat betartása ReturnPolicyAdherence | Jelző, amely megmutatja, hogy a visszáru megfelel-e az összes meghatározott üzleti szabálynak és előírásnak. | ||
| Leírás Ez a számított logikai attribútum jelzi, hogy a visszáru-ügy a vállalat előírt szabályai szerint zajlott-e. A számítás több feltételt is ellenőrizhet, például hogy a visszárut a megengedett határidőn belül kezdeményezték-e, érvényes-e az okkód az adott termékhez, illetve kivétel esetén megadta-e a jóváhagyást a vezető. Ez az attribútum szolgáltat adatot a „Visszáru-jóváhagyási szabályoknak való megfelelés” dashboardhoz. Közvetlenül mérhető vele a megfelelési arány, és azonosíthatók a leggyakrabban megkerült szabályok, így célzott folyamatfejlesztés vagy képzés indítható. Miért fontos? Méri az üzleti szabályok betartását, segít következetesen érvényesíteni az előírásokat, és azonosítani a külön felülvizsgálatot vagy jóváhagyást igénylő ügyeket. Hol szerezhető be? Üzleti szabályok alapján származtatott attribútum. Például: (Return Initiation Date - Original Purchase Date) <= 30 days AND ReturnReason IS NOT NULL. Példák truefalse | |||
| Visszatérítés SLA-határideje RefundSLATargetDate | Az a határidő, ameddig a szolgáltatási szintre vonatkozó megállapodás szerint fel kell dolgozni a visszatérítést. | ||
| Leírás Ez az attribútum meghatározza a visszatérítési folyamat befejezésének határidejét az adott visszáru-ügyben. A határidőt általában üzleti szabályok alapján számítják ki, például „az áruátvételtől számított 5 munkanap”. Ez a határidő az a viszonyítási alap, amelyhez a tényleges teljesítményt mérik. A „Visszatérítés feldolgozásának SLA-megfelelése” dashboard alapja: segítségével nyomon követhető az ügyfeleknek tett vállalások betartása, és azonosíthatók az SLA-túllépés kockázatának kitett ügyek. Miért fontos? Teljesítési célt határoz meg a visszatérítések feldolgozásához, így mérhető és jelenthető az SLA-megfelelés, valamint előnyben részesíthetők a lejárt ügyek. Hol szerezhető be? Ez általában nem szabványos SAP-mező, ezért üzleti szabályok alapján kell meghatározni. Kiszámítható például egy fontos dátummezőből (például az MKPF táblában szereplő áruátvételi dátumból) és egy beállított időtartamból. További részletekért tekintse meg az SAP ECC dokumentációját vagy az üzleti követelményeket. Példák 2023-04-25T23:59:59Z2023-04-28T23:59:59Z2023-05-02T23:59:59Z | |||
| Visszatérítési összeg eltérése RefundAmountDiscrepancy | A tényleges és az igényelt visszatérítési összeg különbsége. | ||
| Leírás Ez a számított mutató pénzben fejezi ki a visszáru-megrendelésben eredetileg igényelt és a jóváíró számlán végül kiállított összeg különbségét. A pozitív érték részleges visszatérítésre utalhat, a negatív érték pedig szokatlan, de túlfizetést jelezhet. Ez az attribútum a „Visszatérítési összeg eltéréseinek nyomon követése” dashboard fő mérőszáma. Segít gyorsan azonosítani és elemezni a pénzügyi eltéréssel járó ügyeket, amelyek hátterében a termék állapotának felmérése, kezelési díj vagy hiba állhat. Nyomon követésével biztosítható a pénzügyi kontroll és a szabályok betartása. Miért fontos? Közvetlenül méri a visszatérítési folyamat pénzügyi eltéréseit, így feltárhatók a szabályszegések, a feldolgozási hibák és a pénzügyi veszteségek. Hol szerezhető be? Számított mező: ActualRefundAmount - RequestedRefundAmount. Példák 0.00-4.99-50.00 | |||
A visszaküldések és visszatérítések feldolgozásának tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Áruátvétel könyvelése | Ez a tevékenység akkor történik, amikor a visszaküldött termék fizikailag megérkezik a raktárba vagy a feldolgozóközpontba. A visszáru-szállításhoz kapcsolódó anyagmozgási bizonylat könyvelése rögzíti az eseményt. | ||
| Miért fontos? Fontos mérföldkő, amely jelzi, hogy a vállalat átvette a visszaküldött terméket. Ez a fizikai ellenőrzés kezdőpontja, és hatással van a készletadatok pontosságára. Hol szerezhető be? Az esemény a VBUP táblában szereplő visszáru-szállítási tétel anyagmozgási állapotából vezethető le, például ha a WBSTA értéke „C”. A pontos időbélyeg a megfelelő áruátvétel anyagbizonylatának fejlécében, az MKPF-BUDAT mezőben található. Rögzítés Keresse meg az MKPF táblában a visszáru-szállításhoz kapcsolódó anyagbizonylat könyvelési dátumát (BUDAT). Eseménytípus inferred | |||
| Felhasználási döntés meghozva | Az ellenőrzés után a minőségügyi mérnök vagy ellenőr hivatalosan dönt a visszaküldött termék állapotáról. A döntés határozza meg a további folyamatot, például a készletre vételt, a selejtezést vagy a javítást. | ||
| Miért fontos? Ez a tevékenység fontos az ellenőrzés hatékonyságának és eredményének megértéséhez. A döntés közvetlenül befolyásolja a visszatérítés összegét és a készlet kezelését. Hol szerezhető be? Ha a rendszerben SAP QM-et használnak, ez a QAVE táblában (ellenőrzési tétel felhasználási döntése) rögzített esemény. A döntés időpontját a QAVE-VDATUM mező tárolja. A szállítási bizonylathoz a QALS táblán keresztül kapcsolódik. Rögzítés Használja a QAVE táblában szereplő felhasználásidöntés-dátumot (VDATUM), amely az ellenőrzési tételen (QALS-PRUEFLOS) keresztül kapcsolódik. Eseménytípus explicit | |||
| Jóváírás létrehozva | Számlázási bizonylat (jóváíró számla) készül, amely jóváhagyja az ügyfélnek járó pénzügyi jóváírást. Ez a hivatalos pénzügyi bizonylat rögzíti a visszatérítés összegét. | ||
| Miért fontos? Ez a folyamat egyik fontos pénzügyi mérföldköve. A jóváíró számla elkészítéséhez szükséges idő elemzésével feltárhatók az áruátvétel és -ellenőrzés utáni pénzügyi bizonylatfeldolgozás késedelmei. Hol szerezhető be? Ez a VBRK táblában (számlázási bizonylat fejléce) rögzített, egyértelmű esemény. A létrehozás dátuma a VBRK-ERDAT mezőben található. A jóváíró számla a bizonylatfolyamatban kapcsolódik a visszáru-megrendeléshez vagy a jóváírási kérelemhez. Rögzítés A megfelelő számlázási bizonylat létrehozási időbélyegét (ERDAT) használja a VBRK táblából. Eseménytípus explicit | |||
| Jóváíró számla könyvelése a FI modulba | A jóváíró számlát átvezetik a pénzügyi könyvelésbe, így hivatalos vevőkövetelés-könyveléssé válik. Ez a lépés indítja el az ügyfélnek történő tényleges visszatérítést. | ||
| Miért fontos? Ez a tevékenység jelzi, hogy a vállalat pénzügyileg elszámolta a visszatérítést. A jóváíró számla létrehozása és könyvelése közötti késedelem lassíthatja az ügyfélnek történő tényleges visszatérítést. Hol szerezhető be? Ez egy következtetett esemény: akkor azonosítható, amikor a számlázási bizonylat fejlécében a könyvelési státusz (VBRK-RFBSK) értéke „C”-re változik (a könyvelési bizonylat létrejött). A tényleges könyvelési bizonylat létrehozásának dátuma a BKPF táblában található. Rögzítés Azonosítsa azt az időbélyeget, amikor a VBRK-RFBSK értéke „C”-re változik, vagy használja a kapcsolódó BKPF könyvelési bizonylat létrehozási dátumát (CPUDT). Eseménytípus inferred | |||
| Visszáru-megrendelés lezárult | Ez a tevékenység jelzi a visszáru-folyamat végét az értékesítés és disztribúció szempontjából. Akkor következik be, amikor a visszáru-megrendelés összes tétele teljesen feldolgozott és lezárt. | ||
| Miért fontos? Ez a folyamat elsődleges záróeseménye. A „Visszáru-megrendelés létrehozása” és e tevékenység közötti idő megmutatja a visszáru teljes átfutási idejét. Hol szerezhető be? Ez egy státusztáblákból következtetett esemény. Akkor rögzíthető, amikor az értékesítési bizonylat fejlécének teljes státusza (VBUK-GBSTK) „C”-re változik (teljesen feldolgozva). Rögzítés Azonosítsa a CDHDR/CDPOS módosítási bizonylatokban azt az időbélyeget, amikor a fejléc VBUK-GBSTK státuszmezője „C”-re változik. Eseménytípus inferred | |||
| Visszáru-rendelés létrehozva | Ez a tevékenység jelzi a visszáru-folyamat kezdetét, amikor az ügyfél termékvisszaküldést kér. Az SAP ECC-ben akkor rögzül, amikor létrejön egy új, „Return” típusú értékesítési bizonylat, például RE rendeléstípusú. | ||
| Miért fontos? Ez a visszáru-folyamat elsődleges kezdőeseménye. Az ettől a tevékenységtől a többi lépésig eltelt idő elemzésével mérhető a teljes átfutási idő, és feltárhatók a kezdeti feldolgozási késedelmek. Hol szerezhető be? Ez a VBAK táblában (értékesítési bizonylat fejléce) rögzített esemény. A létrehozás időbélyegét a VBAK-ERDAT és a VBAK-ERZET mező tárolja az adott, VBAK-VBELN azonosítójú értékesítési bizonylathoz, ha a rendeléstípus a VBAK-AUART mezőben „RE”. Rögzítés Használja a VBAK táblában az „RE” értékesítésibizonylat-típushoz tartozó létrehozási időbélyeget (ERDAT, ERZET). Eseménytípus explicit | |||
| Jóváírási igény létrehozva | A visszatérítés szükségességének hivatalos rögzítésére jóváírási igény jön létre. Sok rendszerbeállítás esetén maga a visszáru-rendelés szolgál jóváírási igényként. | ||
| Miért fontos? Ez jelzi a visszáru-folyamat pénzügyi elszámolási szakaszának hivatalos kezdetét. Elindítja a további pénzügyi jóváhagyásokat és bizonylatok létrehozását. Hol szerezhető be? Ez lehet a VBAK táblában rögzített, „Credit Memo Request” típusú értékesítési bizonylat eseménye, például CR. Ha a rendeléstípus rendeléshez kapcsolódó számlázásra van beállítva, akkor megegyezhet a „Return Order Created” eseménnyel. Rögzítés Használja a VBAK táblában a „CR” bizonylattípus létrehozási időbélyegét (ERDAT), vagy használja újra a visszáru-rendelés létrehozásának eseményét. Eseménytípus explicit | |||
| Jóváíró számla kiegyenlítve | A vevőkövetelések között nyitott jóváírást kiegyenlítik, rendszerint az ügyfélnek indított kifizetéssel. Ez az esemény jelzi a visszatérítés pénzügyi lezárását. | ||
| Miért fontos? Ez a tevékenység megerősíti a kifizetést, és lezárja a folyamat pénzügyi részét. Az ügyfél szempontjából ekkor ér véget ténylegesen a visszatérítés. Hol szerezhető be? Ez a FI modulból származó, egyértelmű esemény. A könyvelési bizonylat kiegyenlítési dátuma a BSEG táblában (BSEG-AUGDT), a megfelelő vevői tételnél található. Rögzítés Használja a jóváíró számlához kapcsolódó könyvelési bizonylat kiegyenlítési dátumát (AUGDT) a BSEG vagy a BSAD táblából. Eseménytípus explicit | |||
| Visszáru-megrendelés tételének elutasítása | A visszáru-megrendelés egy adott tételét elutasítják, akár az első ellenőrzéskor, akár a vizsgálat után. Ez azt jelenti, hogy a tételt nem dolgozzák fel tovább, így visszatérítésre sem kerül sor. | ||
| Miért fontos? Az elutasítások elemzése segít feltárni az érvénytelen visszáru-kérelmeket, és alapot adhat az ügyfeleknek szóló tájékoztatás javításához. Ez a folyamat egyik olyan útvonala, amely nem vezet visszatérítéshez. Hol szerezhető be? Ez egy következtetett esemény. Általában akkor rögzíthető, amikor a VBAP táblában egyedi „Elutasítási ok” kódot állítanak be a tételhez (VBAP-ABGRU). Az időbélyeget a módosítási naplókból kell kinyerni. Rögzítés Azonosítsa a CDHDR/CDPOS módosítási bizonylatokban azt az időbélyeget, amikor a VBAP-ABGRU mező értéket kap egy visszáru-tételnél. Eseménytípus inferred | |||
| Visszáru-megrendelés tételének feldolgozása befejeződött | A visszáru-megrendelés egy adott tételét teljesen feldolgozottként jelölik meg. Ez rendszerint akkor történik, amikor az adott tételhez kapcsolódó összes logisztikai és pénzügyi utólagos bizonylat elkészült. | ||
| Miért fontos? A tételek szintjén végzett nyomon követés megmutatja, mely termékek vagy visszaküldési okok okozzák a leghosszabb késedelmet. Így részletesebben látható, hogyan halad a folyamat a lezárás felé. Hol szerezhető be? Ez egy státusztáblákból következtetett esemény. Akkor rögzíthető, amikor az értékesítési bizonylat tételének teljes státusza (VBUP-GBSTK) „C”-re változik (teljesen feldolgozva). Rögzítés Azonosítsa a CDHDR/CDPOS módosítási bizonylatokban azt az időbélyeget, amikor a tétel VBUP-GBSTK státuszmezője „C”-re változik. Eseménytípus inferred | |||
| Visszáru-rendelés zárolásának feloldása | A visszáru-igény jóváhagyását jelzi, amely után az ügy továbbléphet a következő szakaszba. Ezt általában a bizonylat állapotának változása vagy a szállítási, illetve számlázási zárolás feloldása alapján lehet rögzíteni. | ||
| Miért fontos? Ez a tevékenység fontos jóváhagyási mérföldkő. Az ide való eljutás idejének mérése segít feltárni a visszáru engedélyezésének és jóváhagyásának szűk keresztmetszeteit. Hol szerezhető be? Ez a változásnaplókból levezetett esemény. Keresse a CDHDR és CDPOS táblákban a VBAK vagy VBAP zárolási mezőinek, illetve a VBUK/VBUP állapotmezőinek változásait. Rögzítés Keresse meg a változásbizonylat-táblákban (CDHDR/CDPOS) azt az időbélyeget, amikor feloldották a megfelelő zárolási állapotot. Eseménytípus inferred | |||
| Visszáru-szállítás létrehozva | A visszaküldött termékek fizikai átvételének kezeléséhez szállítási bizonylat jön létre. Ez az esemény jelzi a visszáru logisztikai folyamatának kezdetét. | ||
| Miért fontos? Az adminisztratív feldolgozás és a fizikai logisztika közötti átmenetet követi nyomon. Az itt jelentkező késedelmek hatással lehetnek a raktári tervezésre és a teljes visszáru-átfutási időre. Hol szerezhető be? Ez a LIKP táblában (szállítási bizonylat fejléce) rögzített esemény. A létrehozás időbélyege a LIKP-ERDAT mezőben található. A forrásként szolgáló visszáru-rendelésre a LIPS táblában, a LIPS-VGBEL mezőn keresztül lehet hivatkozni. Rögzítés Használja a LIKP táblában a visszáru-rendeléshez kapcsolódó szállítás létrehozási időbélyegét (ERDAT). Eseménytípus explicit | |||
Útmutatók az adatok kinyeréséhez
Lépések
- ABAP-program létrehozása: Az
SE38tranzakcióval hozzon létre egy új, futtatható ABAP-programot, példáulZ_PM_RETURN_EXTRACTIONnéven. Adjon neki egy leíró címet, majd mentse helyi objektumként vagy fejlesztési csomagba. - Kiválasztóképernyő meghatározása: A programban hozzon létre kiválasztóképernyőt az adatok szűréséhez. A fő szűrők a visszáru-rendelések létrehozási dátumtartománya (
S_ERDAT), a visszárukhoz használt értékesítési bizonylattípus (S_AUART, például 'RE') és a vállalatkód (P_BUKRS). - Adatszerkezetek meghatározása: Hozzon létre egy helyi struktúrát, amely megfelel az eseménynapló elvárt formátumának. Tartalmazza a
ReturnCaseId,ActivityName,EventTime,SourceSystem,LastDataUpdate,ProcessingAgent,ReturnReasonés a többi szükséges attribútum mezőjét. - Adatkiválasztási logika megírása: Írja meg az ABAP-logikát a 12 szükséges tevékenység adatainak kiválasztásához. Ehhez több SAP-táblából kell adatot lekérdeznie, például a VBAK, VBAP, LIKP, VBRK, BKPF, CDHDR és CDPOS táblákból. A bizonylatfolyam-táblával (VBFA) kapcsolja az összetartozó bizonylatokat, például a szállításokat és jóváíró bizonylatokat az eredeti visszáru-rendeléshez.
- A „Visszáru-rendelés létrehozva” esemény kinyerése: A kiválasztóképernyő feltételei alapján válasszon rekordokat a
VBAKésVBAPtáblákból. Az értékesítési bizonylat száma (VBAK-VBELN) lesz aReturnCaseIdértéke. - Állapotváltozások és fontos események kinyerése: Az olyan tevékenységekhez, mint a „Visszáru-rendelés zárolásának feloldása” vagy a „Visszáru-rendelés tételének elutasítása”, kérdezze le a módosítási bizonylatok tábláit (
CDHDR,CDPOS), vagy vizsgálja meg az olyan táblák állapotmezőit, mint aVBAP(ABGRU). A logisztikai és pénzügyi további tevékenységekhez válasszon adatokat például aLIKP,MKPF,VBRKésBKPFtáblákból. AVBFAsegítségével ellenőrizze, hogy ezek az eredeti visszáru-rendelésekhez kapcsolódnak-e. - Az eseménynapló tábla feltöltése: Minden lekért tevékenységhez hozzon létre egy új rekordot az eseménynapló struktúrájával definiált belső táblában. Rendelje hozzá a forrás SAP-táblák adatait a megfelelő mezőkhöz, például a
VBAK-ERNAMértékét aProcessingAgent, aVBAK-ERDATésVBAK-ERZETértékét pedig azEventTimemezőhöz. - Tevékenységadatok egyesítése: Gondoskodjon róla, hogy az egyes tevékenységekhez tartozó SELECT utasítások eredményei ugyanahhoz a fő belső táblához adódjanak hozzá. Így jön létre a végleges, lapos fájlstruktúra, amelyben minden sor egy eseményt jelöl.
- Időbélyegek és rendszeradatok kezelése: A
SY-DATUMésSY-UZEITrendszermezőkkel töltse ki minden sorLastDataUpdateidőbélyegét. ASourceSystemmezőhöz használja aSY-SYSIDértékét. - Kimenet megjelenítése: Adja hozzá az eredmények ALV-rácsban (SAP List Viewer) történő megjelenítését, például a
REUSE_ALV_GRID_DISPLAYfüggvénymodullal, hogy online elemezhetők legyenek. Tegye lehetővé a végleges belső tábla letöltését CSV- vagy egyszerű szöveges fájlként a felhasználó számítógépére. - Futtatás és exportálás: Futtassa a programot az
SE38tranzakcióval. Adja meg a kívánt kiválasztási feltételeket, majd indítsa el. Az adatok megjelenítése vagy feldolgozása után exportálja az eseménynaplót a program funkciójával. A fájl ProcessMinddel kompatibilis formátumban készüljön, jellemzően fejlécsort tartalmazó CSV-ként.
Konfiguráció
- Dátumtartomány: A kiválasztóképernyőn adja meg a visszáru-rendelés létrehozási dátumának tartományát. Első elemzéshez 3–6 hónapnyi adat javasolt, így kezelhető marad az adatmennyiség, miközben a folyamat is jól áttekinthető.
- Visszáru-bizonylat típusa: Szűrjön a rendszerében visszárukhoz használt értékesítési bizonylattípusra, például 'RE' a visszáruhoz vagy 'CR' a jóváírási igényhez. Ez a szűrő szükséges a megfelelő folyamat elkülönítéséhez. Adja meg az értékeket az
S_AUARTkiválasztási mezőben. - Vállalatkód: Adja meg a megfelelő vállalatkódot (
P_BUKRS), hogy az adatokat egy adott jogi személyre korlátozza. Ez több vállalatot kezelő környezetben különösen fontos. - Előfeltételek: A programot futtató felhasználónak rendelkeznie kell az
SE38tranzakcióhoz szükséges jogosultsággal, valamint hozzáféréssel az alapul szolgáló SD-, MM- és FI-táblákhoz, például a VBAK, LIKP, VBRK, BKPF és CDHDR táblákhoz. A fejlesztéshez ABAP-fejlesztői szerepkör szükséges. - Teljesítmény: Több évnyi, nagy adatmennyiség feldolgozása hosszú ideig tarthat. Ilyenkor futtassa a programot háttérfeladatként (
SM36), és az eredményt az alkalmazásszerver fájlrendszerébe írja, ne online jelenítse meg.
Példa-lekérdezés abap
REPORT Z_PM_RETURN_EXTRACTION.
" =======================================================================
" DATA DECLARATIONS
" =======================================================================
TYPES: BEGIN OF ty_event_log,
returncaseid TYPE vbeln_va,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE sysysid,
lastdataupdate TYPE timestamp,
processingagent TYPE ernam,
returnreason TYPE augru,
materialnumber TYPE matnr,
returnchannel TYPE string, " Placeholder, needs custom logic
requestedrefundamount TYPE netwr,
actualrefundamount TYPE netwr,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lv_timestamp TYPE timestamp,
lv_last_update TYPE timestamp.
" =======================================================================
" SELECTION SCREEN
" =======================================================================
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY,
s_auart FOR vbak-auart.
PARAMETERS: p_bukrs TYPE bukrs OBLIGATORY.
" =======================================================================
" MAIN LOGIC
" =======================================================================
START-OF-SELECTION.
" Set static values for the extraction run
GET TIME STAMP FIELD lv_last_update.
" 1. Return Order Created & 6. Credit Memo Request Created
" Note: In many SAP standard processes, the Return Order itself acts as the Credit Memo Request.
SELECT h~vbeln, h~erdat, h~erzet, h~ernam, h~augru, i~matnr, i~netwr
INTO TABLE @DATA(lt_return_orders)
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN @s_erdat
AND h~auart IN @s_auart
AND h~bukrs_vf = @p_bukrs.
LOOP AT lt_return_orders INTO DATA(ls_return_order).
" Activity: Return Order Created
ls_event_log-returncaseid = ls_return_order-vbeln.
ls_event_log-activityname = 'Return Order Created'.
CONVERT DATE ls_return_order-erdat TIME ls_return_order-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_return_order-ernam.
ls_event_log-returnreason = ls_return_order-augru.
ls_event_log-materialnumber = ls_return_order-matnr.
ls_event_log-requestedrefundamount = ls_return_order-netwr.
APPEND ls_event_log TO lt_event_log.
" Activity: Credit Memo Request Created
ls_event_log-activityname = 'Credit Memo Request Created'.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
IF lt_return_orders IS NOT INITIAL.
" 2. Return Order Block Removed (Example for Delivery Block)
SELECT objectid, udate, utime, username
FROM cdhdr
INTO TABLE @DATA(lt_block_changes)
FOR ALL ENTRIES IN @lt_return_orders
WHERE objectclas = 'VERKBELEG'
AND objectid = @lt_return_orders-vbeln
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT objectid, fname, value_new
INTO TABLE @DATA(lt_cdpos_block)
FROM cdpos
FOR ALL ENTRIES IN @lt_block_changes
WHERE objectclas = @lt_block_changes-objectclas
AND objectid = @lt_block_changes-objectid
AND changenr = @lt_block_changes-changenr
AND tabname = 'VBAK'
AND fname = 'LIFSK' " Delivery Block field
AND value_new = ''.
LOOP AT lt_cdpos_block INTO DATA(ls_cdpos_block).
READ TABLE lt_block_changes INTO DATA(ls_block_change) WITH KEY objectid = ls_cdpos_block-objectid.
IF sy-subrc = 0.
ls_event_log-returncaseid = ls_cdpos_block-objectid.
ls_event_log-activityname = 'Return Order Block Removed'.
CONVERT DATE ls_block_change-udate TIME ls_block_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_block_change-username.
CLEAR: ls_event_log-returnreason, ls_event_log-materialnumber, ls_event_log-requestedrefundamount, ls_event_log-actualrefundamount.
APPEND ls_event_log TO lt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" Get subsequent documents from flow
SELECT vbelv, vbtyp_n, vbeln, rfbsk
INTO TABLE @DATA(lt_doc_flow)
FROM vbfa
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbelv = @lt_return_orders-vbeln
AND vbtyp_n IN ('J', 'R', 'M'). " J=Delivery, R=Goods Mvmt, M=Invoice
" 3. Return Delivery Created
SELECT vbeln, erdat, erzet, ernam FROM likp
INTO TABLE @DATA(lt_deliveries)
FOR ALL ENTRIES IN @lt_doc_flow
WHERE vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'J'.
LOOP AT lt_deliveries INTO DATA(ls_delivery).
READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_del) WITH KEY vbeln = ls_delivery-vbeln.
ls_event_log-returncaseid = ls_doc_flow_del-vbelv.
ls_event_log-activityname = 'Return Delivery Created'.
CONVERT DATE ls_delivery-erdat TIME ls_delivery-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_delivery-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 4. Goods Receipt Posted
SELECT mblnr, mjahr, budat, cputm, usnam FROM mkpf
INTO TABLE @DATA(lt_goods_receipt)
FOR ALL ENTRIES IN @lt_doc_flow
WHERE xblnr = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'R'.
LOOP AT lt_goods_receipt INTO DATA(ls_goods_receipt).
READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_gr) WITH KEY vbeln = ls_goods_receipt-mblnr.
ls_event_log-returncaseid = ls_doc_flow_gr-vbelv.
ls_event_log-activityname = 'Goods Receipt Posted'.
CONVERT DATE ls_goods_receipt-budat TIME ls_goods_receipt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_goods_receipt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 5. Usage Decision Made (Requires QM Module implementation)
SELECT q~prueflos, q~vdatu, q~vzeit, q~vname
FROM qals AS q
INNER JOIN qave AS v ON q~prueflos = v~prueflos
INTO TABLE @DATA(lt_usage_decisions)
FOR ALL ENTRIES IN @lt_deliveries
WHERE q~kdauf = @lt_deliveries-vbeln.
LOOP AT lt_usage_decisions INTO DATA(ls_ud).
SELECT SINGLE vbelv FROM vbfa INTO @DATA(lv_vbelv_ud) WHERE vbeln = @ls_ud-prueflos.
ls_event_log-returncaseid = lv_vbelv_ud.
ls_event_log-activityname = 'Usage Decision Made'.
CONVERT DATE ls_ud-vdatu TIME ls_ud-vzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_ud-vname.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 7. Credit Memo Created
SELECT h~vbeln, h~erdat, h~erzet, h~ernam, i~netwr, i~vgbel
INTO TABLE @DATA(lt_cred_memos)
FROM vbrk AS h
INNER JOIN vbrp AS i ON h~vbeln = i~vbeln
FOR ALL ENTRIES IN @lt_doc_flow
WHERE h~vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'M'.
LOOP AT lt_cred_memos INTO DATA(ls_cred_memo).
ls_event_log-returncaseid = ls_cred_memo-vgbel.
ls_event_log-activityname = 'Credit Memo Created'.
CONVERT DATE ls_cred_memo-erdat TIME ls_cred_memo-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_cred_memo-ernam.
ls_event_log-actualrefundamount = ls_cred_memo-netwr.
APPEND ls_event_log TO lt_event_log.
" 8. Credit Memo Posted To FI
SELECT SINGLE budat, cputime, usnam FROM bkpf
INTO @DATA(ls_bkpf_post)
WHERE awkey = @ls_cred_memo-vbeln AND awtyp = 'VBRK'.
IF sy-subrc = 0.
ls_event_log-activityname = 'Credit Memo Posted To FI'.
CONVERT DATE ls_bkpf_post-budat TIME ls_bkpf_post-cputime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-processingagent = ls_bkpf_post-usnam.
APPEND ls_event_log TO lt_event_log.
ENDIF.
" 12. Credit Memo Cleared
SELECT SINGLE augdt FROM bseg
INTO @DATA(lv_augdt)
WHERE bukrs = @p_bukrs
AND belnr = @ls_cred_memo-vbeln
AND augdt IS NOT NULL.
IF sy-subrc = 0 AND lv_augdt IS NOT INITIAL.
ls_event_log-activityname = 'Credit Memo Cleared'.
CONVERT DATE lv_augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
CLEAR: ls_event_log-processingagent.
APPEND ls_event_log TO lt_event_log.
ENDIF.
ENDLOOP.
" 9. Return Order Item Completed
SELECT vbeln, erdat, erzet, ernam, abgru FROM vbap
INTO TABLE @DATA(lt_items_completed)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND gbsta = 'C'.
LOOP AT lt_items_completed INTO DATA(ls_item_completed).
ls_event_log-returncaseid = ls_item_completed-vbeln.
ls_event_log-activityname = 'Return Order Item Completed'.
CONVERT DATE ls_item_completed-erdat TIME ls_item_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_item_completed-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 10. Return Order Completed
SELECT vbeln, erdat, erzet, ernam FROM vbak
INTO TABLE @DATA(lt_orders_completed)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND gbsta = 'C'.
LOOP AT lt_orders_completed INTO DATA(ls_order_completed).
ls_event_log-returncaseid = ls_order_completed-vbeln.
ls_event_log-activityname = 'Return Order Completed'.
CONVERT DATE ls_order_completed-erdat TIME ls_order_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_order_completed-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" 11. Return Order Item Rejected
SELECT vbeln, erdat, erzet, ernam FROM vbap
INTO TABLE @DATA(lt_items_rejected)
FOR ALL ENTRIES IN @lt_return_orders
WHERE vbeln = @lt_return_orders-vbeln
AND abgru IS NOT NULL AND abgru <> ''.
LOOP AT lt_items_rejected INTO DATA(ls_item_rejected).
ls_event_log-returncaseid = ls_item_rejected-vbeln.
ls_event_log-activityname = 'Return Order Item Rejected'.
CONVERT DATE ls_item_rejected-erdat TIME ls_item_rejected-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-sourcesystem = sy-sysid.
ls_event_log-lastdataupdate = lv_last_update.
ls_event_log-processingagent = ls_item_rejected-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
ENDIF.
" =======================================================================
" OUTPUT
" =======================================================================
cl_salv_table=>factory(
IMPORTING
r_salv_table = DATA(lo_alv)
CHANGING
t_table = lt_event_log ).
lo_alv->display( ). Lépések
- Előfeltételek: Gondoskodjon róla, hogy rendelkezzen olvasási jogosultságú adatbázis-felhasználóval a szükséges SAP ECC-táblákhoz. Ezek közé tartoznak az értékesítési és disztribúciós (SD), az anyaggazdálkodási (MM) és a pénzügyi számviteli (FI) modul táblái. Az adatbázishoz való csatlakozáshoz használjon megfelelő SQL-klienst, például DBeavert, SAP HANA Studiót vagy Oracle SQL Developert.
- Rendszerspecifikus beállítások azonosítása: A lekérdezés futtatása előtt állapítsa meg, hogy a szervezet mely bizonylattípusokat használja visszárukhoz. A lekérdezésben szereplő
[YOUR_RETURN_ORDER_TYPES]helyőrzőt cserélje le a tényleges értékekre, például a szokásos visszáru-bizonylattípusra, a 'RE'-re. - A lekérdezés előkészítése: Másolja be a „query” szakaszban megadott teljes SQL-lekérdezést az SQL-kliensbe.
- Paraméterek beállítása: Keresse meg a lekérdezés elején található
BaseReturnOrdersnevű közös táblakifejezést (CTE). AWHEREfeltételben adja meg a kívánt dátumtartományt a[START_DATE]és[END_DATE]helyőrzők cseréjével. Frissítse a visszáru-bizonylattípusok listáját, és szükség esetén szűrjön egy adott vállalatkódra (BUKRS_VF). - A lekérdezés futtatása: Futtassa a módosított lekérdezést az SAP ECC-adatbázison. A futási idő a megadott dátumtartománytól és az adatbázis méretétől függ.
- Nyers adatok ellenőrzése: A lekérdezés lefutása után gyorsan ellenőrizze az eredményt. Nézze meg, hogy a
ReturnCaseId,ActivityNameésEventTimeoszlopok ki vannak-e töltve, és több tevékenységhez is megjelennek-e adatok. - Exportálás CSV-be: Exportálja az SQL-kliens teljes eredményhalmazát CSV-fájlba. UTF-8 kódolást használjon, hogy minden karakter helyesen jelenjen meg.
- Feltöltés előkészítése: Nyissa meg a CSV-fájlt, és ellenőrizze, hogy az oszlopfejlécek pontosan megfelelnek-e a szükséges attribútumoknak:
ReturnCaseId,ActivityName,EventTime,SourceSystemstb. Ha az SQL-kliens módosította a fejléceket exportáláskor, javítsa őket. - Feltöltés: Töltse fel a megfelelően előkészített CSV-fájlt a ProcessMind platformra elemzéshez.
Konfiguráció
- Visszáru-bizonylattípusok: A lekérdezést az SAP-rendszerben visszáru-rendelésként használt értékesítési bizonylattípusokra kell beállítani. Ehhez cserélje le a
[YOUR_RETURN_ORDER_TYPES]helyőrzőt. Gyakori példa a 'RE' vagy egy egyedi 'Z' típus. - Dátumtartomány: Az adatok kinyeréséhez megfelelő dátumtartományt kell megadni. Első elemzéshez általában 3–6 hónapnyi adat javasolt. A
[START_DATE]és[END_DATE]helyőrzőket 'YYYYMMDD' formátumban töltse ki. - Vállalatkód: Több vállalatkódot használó szervezetnél szűrje az adatokat, hogy az elemzés a megfelelő területre összpontosítson. A kezdeti CTE-hez például hozzáadhatja a
VBAK.BUKRS_VF = '[YOUR_COMPANY_CODE]'feltételt. - Adatbázis SQL-dialektusa: A megadott lekérdezés általános SQL-függvényeket használ. A dátum- és időkonverziók, például a
TO_TIMESTAMP, valamint a karakterláncok összefűzése (CONCAT) azonban az adatbázisrendszertől függően kisebb szintaktikai módosítást igényelhet, például Oracle, HANA vagy DB2 esetén. - Szükséges jogosultságok: Az adatbázis-felhasználónak olvasási jogosultsággal kell rendelkeznie a következő fő táblákhoz: VBAK, VBAP, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG, BKPF, BSAD, QALS, QAVE, CDHDR és CDPOS.
Példa-lekérdezés sql
WITH BaseReturnOrders AS (
SELECT
VBAK.VBELN AS ReturnOrderNumber,
VBAP.POSNR AS ReturnOrderItemNumber
FROM VBAK
JOIN VBAP ON VBAK.VBELN = VBAP.VBELN
WHERE VBAK.AUART IN ('[YOUR_RETURN_ORDER_TYPES]') -- e.g., 'RE'
AND VBAK.ERDAT BETWEEN '[START_DATE]' AND '[END_DATE]' -- e.g., '20230101' and '20231231'
)
-- 1. Return Order Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(VBAK.ERDAT, VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
VBAK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
UNION ALL
-- 2. Return Order Block Removed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Block Removed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBAK'
AND CDPOS.FNAME IN ('LIFSK', 'FAKSK')
AND CDPOS.VALUE_NEW = ''
AND CDPOS.VALUE_OLD <> ''
UNION ALL
-- 3. Return Delivery Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(LIKP.ERDAT, LIKP.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
LIKP.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIKP ON VBFA.VBELN = LIKP.VBELN
UNION ALL
-- 4. Goods Receipt Posted
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Goods Receipt Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(MKPF.CPUDT, MKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
MKPF.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIPS ON VBFA.VBELN = LIPS.VBELN AND VBFA.POSNN = LIPS.POSNR
JOIN MSEG ON LIPS.VBELN = MSEG.LFBNR AND LIPS.POSNR = MSEG.LFPOS
JOIN MKPF ON MSEG.MBLNR = MKPF.MBLNR AND MSEG.MJAHR = MKPF.MJAHR
WHERE MSEG.BWART IN ('651', '653', '655') -- Standard returns movement types
UNION ALL
-- 5. Usage Decision Made
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Usage Decision Made' AS "ActivityName",
TO_TIMESTAMP(CONCAT(QAVE.ADAT, QAVE.ATIM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
QAVE.AENAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN QALS ON VBFA.VBELN = QALS.VBELN AND VBFA.POSNN = QALS.POSNR -- Linking inspection lot to delivery item
JOIN QAVE ON QALS.PRUEFLOS = QAVE.PRUEFLOS
UNION ALL
-- 6. Credit Memo Request Created (assumes a separate doc, or can be the return order itself)
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CMR_VBAK.ERDAT, CMR_VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CMR_VBAK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'K' -- 'K' is Credit Memo Request
JOIN VBAK AS CMR_VBAK ON VBFA.VBELN = CMR_VBAK.VBELN
UNION ALL
-- 7. Credit Memo Created
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(VBRK.ERDAT, VBRK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
VBRK.ERNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
WHERE VBRK.FKART IN ('[YOUR_CREDIT_MEMO_TYPES]') -- e.g., 'G2'
UNION ALL
-- 8. Credit Memo Posted To FI
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Posted To FI' AS "ActivityName",
TO_TIMESTAMP(CONCAT(BKPF.CPUDT, BKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
BKPF.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BKPF ON VBRK.VBELN = BKPF.AWKEY AND BKPF.AWTYP = 'VBRK'
UNION ALL
-- 9. Return Order Item Completed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Item Completed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBUP'
AND CDPOS.FNAME = 'GBSTA'
AND CDPOS.VALUE_NEW = 'C'
UNION ALL
-- 10. Return Order Completed
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Completed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBUK'
AND CDPOS.FNAME = 'GBSTK'
AND CDPOS.VALUE_NEW = 'C'
UNION ALL
-- 11. Return Order Item Rejected
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Return Order Item Rejected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CDHDR.USERNAME AS "ProcessingAgent",
CDPOS.VALUE_NEW AS "ReturnReason", -- Using rejection reason for this specific event
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
AND CDPOS.TABNAME = 'VBAP'
AND CDPOS.FNAME = 'ABGRU'
AND CDPOS.VALUE_NEW <> ''
UNION ALL
-- 12. Credit Memo Cleared
SELECT
CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
'Credit Memo Cleared' AS "ActivityName",
TO_TIMESTAMP(BSAD.AUGDT, 'YYYYMMDD') AS "EventTime",
'SAP ECC' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
CLEAR_DOC.USNAM AS "ProcessingAgent",
VBAK.AUGRU AS "ReturnReason",
VBAP.MATNR AS "MaterialNumber",
VBAK.VTWEG AS "ReturnChannel",
VBAP.NETWR AS "RequestedRefundAmount",
VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BSAD ON VBRK.VBELN = BSAD.VBELN
JOIN BKPF AS CLEAR_DOC ON BSAD.AUGBL = CLEAR_DOC.BELNR AND BSAD.BUKRS = CLEAR_DOC.BUKRS AND BSAD.GJAHR_AUGL = CLEAR_DOC.GJAHR; Kezdheti?
Használja már ma ezt a sablont az adatgyűjtés egyszerűsítéséhez, és tárja fel a visszaküldési és visszatérítési folyamat működését.
Fejlessze most a visszaküldések és visszatérítések feldolgozását
Egyszerűsítse a visszaküldések feldolgozását SAP ECC-ben, és csökkentse 30%-kal a ciklusidőt. Kezdje el még ma.
Nincs szükség bankkártyára, a beállítás néhány percet vesz igénybe