Adatsablon a visszáru- és visszatérítési folyamatokhoz
Adatsablon a visszáru- és visszatérítési folyamatokhoz
- Javasolt attribútumok
- Nyomon követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez
Visszáru- és visszatérítés-kezelés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | Az esemény pontos időbélyege, amely megmutatja, mikor történt egy adott tevékenység. | ||
| Leírás Az esemény időpontja azt a dátumot és időt rögzíti, amikor az üzleti eseményt feljegyezték a rendszerben. Ez az időbélyeg elengedhetetlen a tevékenységek időrendi sorba rendezéséhez és minden időalapú elemzéshez. A process mining ezt az attribútumot használja a tevékenységek közötti átfutási idők kiszámítására, az egyes lépések időtartamának meghatározására és a folyamat teljesítményének időbeli elemzésére. Ez az alapja a szűk keresztmetszetek feltárásának, az SLA betartásának nyomon követésének és a visszáru-folyamat időbeli alakulása megértésének. Miért fontos? Ez az időbélyeg elengedhetetlen az események sorrendbe állításához, az időtartamok és átfutási idők kiszámításához, valamint a folyamat késéseinek feltárásához. Hol szerezhető be? Általában a bizonylatok létrehozásához vagy az állapotváltozásokhoz kapcsolódó dátum- és időmezőkből származik. Ilyen például az ERDAT (létrehozás dátuma) és az ERZET (létrehozás időpontja) a VBAK, LIKP és BKPF táblákban, illetve a könyvelési bizonylatok könyvelési dátuma (BUDAT). Példák 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Tevékenység neve ActivityName | A visszáru- és visszatérítési folyamatban végrehajtott konkrét üzleti tevékenység vagy bekövetkezett esemény neve. | ||
| Leírás Ez az attribútum a visszáru-folyamat egy lépését vagy mérföldkövét írja le. A tevékenységek az elvégzett munkát jelölik, például a „Visszáru-megrendelés jóváhagyása” vagy a „Termékellenőrzés befejezése” lépést. Ezek az SAP S/4HANA rendszerben rögzített állapotváltozásokból, bizonylatlétrehozásokból vagy konkrét felhasználói műveletekből származnak. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segít megjeleníteni a folyamattérképet, felismerni a gyakori és ritka útvonalakat, valamint azonosítani a gyakran ismétlődő tevékenységeket, amelyek utómunkára vagy hatékonysági problémákra utalhatnak. Miért fontos? A tevékenységek adják a folyamattérkép alapját, és lehetővé teszik a folyamat, a szűk keresztmetszetek és az eltérések megjelenítését és elemzését. Hol szerezhető be? A tevékenységnevek általában több adatforrásból származnak: ilyenek a VBUK/VBUP táblák bizonylatállapot-változásai, a fejlécet tartalmazó VBAK (értékesítési bizonylatok) és BKPF (könyvelési bizonylatok) táblák létrehozási eseményei, valamint az MSEG táblában szereplő anyagmozgási állapotok. Példák Visszáru-kérelem indításaÁru beérkezése a raktárbaJóváíró bizonylat létrehozásaVisszatérítés feldolgozása | |||
| Visszáruügy-azonosító ReturnCaseId | Egy adott ügyfél-visszáru egyedi azonosítója, amely összekapcsolja az ügy összes tevékenységét a kezdetétől a lezárásáig. | ||
| Leírás A visszáruügy-azonosító az elsődleges azonosító, amely egy adott visszáruhoz rendeli az összes eseményt és tevékenységet. Minden ügyfél-visszáru-kérelem egyedi azonosítót kap, így a teljes folyamat az elejétől a végéig követhető. A process miningben ez az attribútum alapvető a folyamat rekonstruálásához. Segítségével elemezhetők az ügyek időtartamai, a folyamatváltozatok és a szűk keresztmetszetek, mert az olyan különálló eseményeket, mint a „Visszáru-kérelem indítása”, az „Áru beérkezése” és a „Visszatérítés feldolgozása”, egy adott visszáru egységes idővonalára rendezi. Miért fontos? Ez az alapvető azonosító teszi lehetővé a visszáru teljes folyamatának követését, valamint az ügyek szintjén végzett elemzéseket, például az átfutási idő és a folyamatváltozatok feltárását. Hol szerezhető be? Ez általában a visszáru-megrendelés fejlécét tartalmazó VBAK tábla értékesítési bizonylatszáma (VBELN), ahol a bizonylatkategória (VBTYP) visszárut jelez. Példák 600001896000019060000191 | |||
| Forrásrendszer-azonosító SourceSystemId | Annak a forrásrendszernek az azonosítója, amelyből az adatokat kinyerték. | ||
| Leírás Ez az attribútum megadja, melyik nyilvántartó rendszerből származnak az eseményadatok. Ennél a folyamatnál ez általában az SAP S/4HANA-példány azonosítója. Több rendszer használatakor ez a mező elengedhetetlen az adatok eredetének követéséhez, a hibakereséshez és az adatok sértetlenségének biztosításához. Segít megkülönböztetni az adatokat, ha a visszárukat több ERP-példányban dolgozzák fel, vagy külső rendszerekkel, például raktárkezelő rendszerrel integrálják. Miért fontos? Fontos információt ad az adatok eredetéről és útjáról, különösen több rendszer használatakor, így az adatok nyomon követhetők és megbízhatók. Hol szerezhető be? Ez az érték általában állandó, és az adatok kinyerésekor állítják be. Az SAP rendszer adminisztrációs adataiból, például a rendszerazonosítóból (SID) kérdezhető le. Példák S4H_PROD_100S4Q_DEV_200 | |||
| Utolsó adatfrissítés LastDataUpdateTimestamp | Az időbélyeg, amely megmutatja, mikor frissítették vagy nyerték ki utoljára az esemény adatait. | ||
| Leírás Ez az attribútum rögzíti az utolsó adatkinyerés vagy -frissítés dátumát és időpontját. Információt ad az elemzett adatkészlet aktualitásáról. Segít megítélni, mennyire naprakész a process mining elemzés. A felhasználók láthatják, milyen frissek az adatok, ami különösen fontos a folyamatban lévő ügyeket követő operatív felügyelet és dashboardok esetén. Miért fontos? Megmutatja, mennyire frissek az adatok. Ez elengedhetetlen ahhoz, hogy az elemzések és a dashboardok naprakész információkra épüljenek. Hol szerezhető be? Ezt az értéket általában az ETL- vagy adatfolyam-eszköz állítja elő és rögzíti az adatkészleten az adatkinyeréskor. Példák 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Esemény befejezési időpontja EventEndTime | A tevékenység befejezését jelző időbélyeg, amely az időtartam kiszámítására használható. | ||
| Leírás A StartTime (EventTime) a tevékenység kezdetét, az EventEndTime pedig a végét jelöli. Sok rendszer által generált eseménynél a kezdési és befejezési idő megegyezik, mert az esemény azonnal bekövetkezik. A mérhető időtartamú tevékenységeknél, például a „Termékellenőrzésnél”, ez az attribútum különösen fontos. Segítségével közvetlenül kiszámítható a tevékenység feldolgozási ideje. Ez alapvető a teljesítmény elemzéséhez, mert megmutatja, mely konkrét lépések veszik igénybe a legtöbb időt, nem csupán az egyes lépések közötti várakozást. Miért fontos? Lehetővé teszi az egyes tevékenységek időtartamának pontos kiszámítását, így feltárhatók az adott folyamatlépések hatékonysági problémái. Hol szerezhető be? Ezt az értéket gyakran számítással határozzák meg. Egyes tevékenységeknél külön mezőben szerepelhet, de jellemzően az adott ügy következő tevékenységének StartTime értéke. Példák 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Felhasználónév UserName | A tevékenységet végrehajtó munkatárs felhasználói azonosítója. | ||
| Leírás Ez az attribútum azonosítja azt a felhasználót vagy rendszerügynököt, aki egy feladatot, például egy visszáru jóváhagyását vagy egy jóváíró bizonylat létrehozását elvégezte. Az SAP rendszerben ezt gyakran olyan mezők rögzítik, amelyek megadják, ki hozott létre vagy módosított egy bizonylatot. A felhasználók szerinti elemzés segít felismerni a kiemelkedően teljesítő munkatársakat vagy csapatokat, a képzési igényeket és a munkaterhelés eloszlását. Az eltérések vizsgálatához is elengedhetetlen, mert a folyamatműveleteket konkrét személyekhez kapcsolja, támogatva a megfelelést és az auditálást. Miért fontos? Az egyes tevékenységeket konkrét felhasználókhoz rendeli, így elemezhető a csapatok teljesítménye, munkaterhelése és a szabályok betartása. Hol szerezhető be? Gyakran a bizonylatfejléceket tartalmazó táblákban található, például a VBAK (értékesítési megrendelések), LIKP (szállítások) és BKPF (könyvelési bizonylatok) ERNAM (létrehozta) mezőjében. A felhasználói adatok az USR21 felhasználói törzstáblából egészíthetők ki. Példák CBROWNASMITHWF_BATCH | |||
| Termékazonosító ProductId | A visszaküldött termék egyedi azonosítója. | ||
| Leírás Ez az attribútum megadja, melyik anyagra vagy termékre vonatkozik a visszáru. A folyamatot a termékkatalógus egy konkrét tételéhez kapcsolja. A termékek szerinti visszáru-elemzés alapvető a magas visszaküldési arányú termékek felismeréséhez, amely minőségi hibára, pontatlan termékleírásra vagy gyártási problémára utalhat. Ezek az adatok segítik a vállalatokat a terméktervezéssel, a beszállítók kezelésével és a készletezéssel kapcsolatos döntésekben. Miért fontos? A visszáru-folyamatot konkrét termékekhez kapcsolja, így elemezhető az egyes termékek visszaküldési aránya, és feltárhatók a minőségi vagy leírásbeli problémák. Hol szerezhető be? A visszáru-megrendelés tételeit tartalmazó VBAP vagy a visszáru-szállítás tételeit tartalmazó LIPS tábla anyagszámmezőjében (MATNR) található. Példák FG-10023HW-45981SW-LICENSE-PREM | |||
| Ügyfél-azonosító CustomerId | A visszárut kezdeményező ügyfél egyedi azonosítója. | ||
| Leírás Ez az attribútum azonosítja a visszárut kérő ügyfelet. A folyamatot az ügyféltörzs egy konkrét szereplőjéhez kapcsolja. Az ügyfelek szerinti elemzés segít felismerni a mintákat, például a szokatlanul magas visszaküldési arányú ügyfeleket, ami csalásra vagy elégedetlenségre utalhat. Az ügyféltípus, az ügyfélérték vagy az előzmények alapján a visszáru-folyamat is csoportosítható, így az ügyfelek igényeihez igazítható a kiszolgálás. Miért fontos? A visszárukat konkrét ügyfelekhez kapcsolja, így elemezhető az ügyfelek viselkedése, csoportosíthatók az ügyfelek, és felismerhetők a gyakran visszaküldők. Hol szerezhető be? A visszáru-megrendelés fejlécét tartalmazó VBAK tábla ügyfélszámmezőjében (KUNNR) található. Példák CUST-001234CUST-005678CUST-009012 | |||
| Visszáru oka ReturnReason | Az ügyfél által megadott ok, amiért visszaküldi a terméket. | ||
| Leírás Ez az attribútum rögzíti az ügyfél által megadott visszaküldési okot, például „Hibás termék”, „Nem megfelelő méret” vagy „Már nincs rá szükség”. Ezt általában egy előre meghatározott indokkódlistából választják ki a visszáru indításakor. A visszaküldési okok elemzése segít feltárni a termékminőségi problémákat, javítani a termékleírásokat és fejleszteni az értékesítési folyamatokat. Közvetlen képet ad az ügyfelek elégedetlenségéről, és segít rangsorolni a fejlesztési területeket a visszáruk arányának csökkentéséhez. Miért fontos? Megmutatja, miért küldik vissza a termékeket, így feltárhatók a kiváltó okok, például a minőségi problémák, a teljesítési hibák vagy az ügyfélelvárások és a termék közötti eltérések. Hol szerezhető be? Általában a visszáru-megrendelés tételeit tartalmazó VBAP táblában, az ABGRU mezőben tárolják (értékesítési bizonylat elutasításának oka). Példák 001 - Gyenge minőség002 - Szállítás közben megsérült005 - Nem megfelelő terméket küldtek | |||
| Visszatérítés összege RefundAmount | Az ügyfélnek visszatérített végleges pénzösszeg. | ||
| Leírás Ez az attribútum a visszáru-folyamat végén az ügyfélnek jóváírt vagy visszatérített tényleges összeget jelöli. Az értéket pénzügyi bizonylatok, például jóváíró bizonylatok rögzítik. Ez fontos pénzügyi mutató, amely többféle elemzéshez használható. A „Visszatérítési összeg eltérésének elemzése” dashboardon a kért összeggel való összehasonlításra szolgál. Az érték szerinti csoportosítás azt is megmutatja, hogy a nagy értékű visszáruk folyamata eltér-e, vagy hosszabb időt vesz-e igénybe. Miért fontos? Nyomon követi a visszáruk pénzügyi hatását, és elengedhetetlen a visszatérítések pontosságának elemzéséhez, a nagy értékű ügyek felismeréséhez és a teljes költség megértéséhez. Hol szerezhető be? A jóváíró bizonylat nettó érték mezőjéből (NETWR) származik, amely például a VBRK (számlázási bizonylat fejléce) vagy a BSEG (könyvelési bizonylat tételei) táblában található. Példák 125.50999.0049.99 | |||
| Automatizált IsAutomated | Jelző, amely megmutatja, hogy a tevékenységet rendszer vagy személy végezte-e. | ||
| Leírás Ez a logikai attribútum megkülönbözteti a rendszer által automatikusan végrehajtott tevékenységeket, például egy workflow-t vagy háttérfeladatot, a felhasználó által manuálisan végzettektől. Az „Automatizált visszatérítés-jóváhagyási arány” KPI kiszámításához és az automatizálási lehetőségek feltárásához is szükséges. Ha a manuális feladatokra szűr, a folyamatfejlesztést azokra a területekre összpontosíthatja, ahol az automatizálás a legtöbbet javíthatja a sebességen, a költségeken és a pontosságon. Miért fontos? Megkülönbözteti a manuális és az automatizált feladatokat. Ez segít feltárni az automatizálási lehetőségeket és mérni a digitális átalakulás hatását. Hol szerezhető be? Ezt általában a felhasználónév alapján határozzák meg. Ha például a felhasználó „WF_BATCH” vagy más rendszerazonosító, a tevékenység automatizáltnak minősül. Példák truefalse | |||
| Értékesítési szervezet SalesOrganization | Az eredeti értékesítésért és a visszáruért felelős szervezeti egység. | ||
| Leírás Az értékesítési szervezet az SAP egyik fontos szervezeti egysége, amely a termékek és szolgáltatások értékesítéséért és elosztásáért felel. A visszáru-tranzakcióhoz van rendelve. Ez az attribútum lehetővé teszi a visszáru-folyamat szűrését és összehasonlítását különböző üzleti egységek, régiók vagy részlegek között. Segít felismerni, ha egyes értékesítési szervezeteknél magasabb a visszáru aránya, vagy kevésbé hatékony a visszáruk kezelése, így alapot ad a szervezeti teljesítmény elemzéséhez. Miért fontos? Lehetővé teszi a visszáru-folyamat teljesítményének és arányainak összehasonlítását az üzleti egységek, régiók és értékesítési csatornák között. Hol szerezhető be? A visszáru-megrendelés fejlécét tartalmazó VBAK tábla értékesítési szervezet mezőjében (VKORG) található. Példák 10002100US01 | |||
| Feldolgozó ügyintéző ProcessingAgent | Az a konkrét ügyintéző vagy erőforráscsoport, amely egy manuális tevékenységért felel. | ||
| Leírás Ez az attribútum azonosítja azt a személyt vagy csapatot, amely elvégezte az adott feladatot. A „Felhasználónév” mezőnél pontosabban is megadhatja a felelőst, például szerepkör vagy csapat szerint, különösen megosztott szolgáltatási környezetben. A „Visszatérítés-jóváhagyás hatékonysága” dashboardon összehasonlíthatja a különböző ügyintézők vagy csapatok teljesítményét. Az adat segít megérteni a munkaterhelés eloszlását, felmérni a képzési igényeket, valamint azonosítani a kiemelkedően teljesítő munkatársakat és a megosztható bevált gyakorlatokat. Miért fontos? Ügyintézői vagy csapatszinten teszi lehetővé a teljesítmény elemzését. Segít kezelni a munkaterhelést, feltárni a képzési lehetőségeket és javítani a hatékonyságot. Hol szerezhető be? Ez az információ elérhető lehet az SAP Business Partner funkcióin keresztül, ha az ügyintézőket hozzárendelték, vagy meghatározható a felhasználó HR-szervezeti struktúrában szereplő részlege vagy szerepköre alapján. Példák 1. szintű támogatásRaktári ellenőrző csapatPénzügyi részleg, szállítói számlák | |||
| Jóváíró bizonylat száma CreditMemoNumber | A visszatérítést engedélyező jóváíró bizonylat egyedi azonosítója. | ||
| Leírás A jóváíró bizonylat az a számlázási bizonylat, amely hivatalosan jóváírja az ügyfél számláján a visszaküldött termékek értékét. Ez az attribútum a pénzügyi bizonylat egyedi száma. A jóváíró bizonylat számának követése elengedhetetlen a visszáru-folyamat pénzügyi rendezési szakaszának elemzéséhez. Fontos mérföldkövet jelöl, amely gyakran elindítja a tényleges visszatérítést, és szükséges a pénzügyi egyeztetéshez és az auditáláshoz. Miért fontos? A visszatérítés hivatalos pénzügyi tranzakcióját jelöli. Elengedhetetlen a folyamat utolsó szakaszainak követéséhez és a pénzügyi auditáláshoz. Hol szerezhető be? Ez a számlázási bizonylat száma (VBELN) a VBRK számlázási bizonylat fejlécét tartalmazó táblából, ahol a bizonylatkategória jóváíró bizonylatot jelez. Példák 900003459000034690000347 | |||
| Kért visszatérítési összeg RequestedRefundAmount | A folyamat kezdetén kért vagy várt visszatérítési összeg. | ||
| Leírás Ez az attribútum a kezdeti visszáru-kérelemben szereplő visszaküldött áru értékét rögzíti. Ez az alapérték hasonlítható össze a végül visszatérített összeggel. Ez a mező szükséges a „Visszatérítési összeg eltérésének elemzése” dashboardhoz. A kért és a ténylegesen visszatérített összeg összehasonlítása segít feltárni például a terméksérülés, a készlet-visszavételezési díj vagy más korrekció miatt részlegesen visszatérített összegeket, így biztosítható a pénzügyi pontosság és átláthatóság. Miért fontos? Alapul szolgál a visszatérítések pontosságának méréséhez, és segít feltárni, illetve elemezni a várt és a tényleges visszatérítési összegek közötti eltéréseket. Hol szerezhető be? Az érték általában az eredeti visszáruértékesítési rendelés tételeinek nettó értékéből származik. Ez a VBAP táblában szereplő megfelelő tételek nettó értéke (NETWR). Példák 125.501050.0049.99 | |||
| Termékellenőrzés eredménye ItemInspectionOutcome | A visszaküldött termék fizikai ellenőrzésének eredménye. | ||
| Leírás Ez az attribútum rögzíti a termék raktári beérkezése után végzett ellenőrzés eredményét. Gyakori értékei például: „Elfogadva”, „Elutasítva, sérült” vagy „Elfogadva, újra értékesíthető”. Ez az adat fontos háttér-információt ad a folyamat további lépéseihez. Meghatározza, hogy teljes vagy részleges visszatérítés jár-e, illetve hogy egyáltalán jár-e visszatérítés. Az eredmények elemzésével feltárhatók az elutasítások okai. Ha a termékek gyakran sérülnek meg szállítás közben, az adatok a csomagolás vagy a szállítópartnerek felülvizsgálatát is segíthetik. Miért fontos? Megmutatja, mi áll a visszatérítések jóváhagyása vagy elutasítása mögött. Adatot szolgáltat a termék állapotáról és a visszatérítés módosításának okairól. Hol szerezhető be? Az információt rögzíthetik a minőségirányítási modul (QM) ellenőrzési tételében, vagy a visszáru-szállítás tételének (LIPS) állapotaként, illetve indokkódjaként. Egyéni mezőben is tárolható. Példák Elfogadva, újra értékesíthetőElfogadva, felújítandóElutasítva, az ügyfél által okozott sérülésElutasítva, nem a megfelelő terméket küldték vissza | |||
| Újramunka IsRework | Jelző, amely megmutatja, hogy egy ügyben megismételtek-e egy korábbi tevékenységet. | ||
| Leírás Ez a számított logikai attribútum azonosítja az újramunkát, vagyis amikor ugyanazt a tevékenységet egy ügyön belül többször végzik el. Ilyen például, ha újra kell ellenőrizni egy terméket, vagy ha egy jóváíró bizonylatot létrehoznak, visszavonnak, majd ismét létrehoznak. Ez az attribútum szükséges az „Újramunka elemzése a visszatérítések feldolgozásában” dashboardhoz és az „Újramunkák aránya a visszatérítési folyamatban” KPI-hoz. A hibára hajlamos vagy többszöri próbálkozást igénylő tevékenységek kiemelésével mérhetővé teszi a folyamat veszteségeit, és rámutat azokra a területekre, ahol jobb ellenőrzésre vagy képzésre van szükség. Miért fontos? Az ismételt munka megjelölésével feltárja a folyamat veszteségeit és hibáit, így célzott fejlesztésekkel csökkenthetők a felesleges ráfordítások és a késések. Hol szerezhető be? Ezt a jelzőt általában maga a process mining eszköz számítja ki, de az adatátalakítás során előre is meghatározható. Azt ellenőrzi, hogy ugyanaz a tevékenységnév szerepelt-e már korábban az adott ügyben. Példák truefalse | |||
| Visszaküldési szabályzat betartása ReturnPolicyAdherence | Jelző, amely megmutatja, hogy a visszáruügy megfelel-e a meghatározott visszáru-szabályzatnak. | ||
| Leírás Ez a számított logikai attribútum jelzi, hogy a visszáru megfelel-e az alkalmazandó szabályzat feltételeinek. Az ellenőrzés például vizsgálhatja, hogy a visszaküldést a megengedett határidőn belül kezdeményezték-e, illetve hogy a megadott indok érvényes-e az adott terméknél. Az attribútum közvetlenül támogatja a „Visszáru-szabályzat betartásának áttekintése” dashboardot. Segítségével mérhető a szabályzatnak megfelelő ügyek aránya, és megvizsgálhatók a nem megfelelő ügyek, hogy kiderüljön az eltérések oka. Így a szabályok következetesebben érvényesíthetők. Miért fontos? Méri az üzleti szabályok betartását, és segít feltárni, illetve csökkenteni azokat a szabályszegéseket, amelyek ronthatják a jövedelmezőséget vagy kivételes eseteket okozhatnak a folyamatban. Hol szerezhető be? Az üzleti szabályok alapján számítható ki. Például: (Visszáru kezdeményezésének dátuma - Eredeti vásárlás dátuma) <= [Engedélyezett visszaküldési napok]. Ehhez szükség van az eredeti vásárlás dátumára és a szabályzatban rögzített feltételekre. Példák truefalse | |||
| Visszáru-rendelés állapota ReturnOrderStatus | A visszáruügy aktuális, összesített állapota. | ||
| Leírás Ez az attribútum egy adott időpontban magas szintű állapotot ad a visszáruügyről, például „Nyitott”, „Folyamatban” vagy „Lezárt”. Az állapot gyakran az utolsó teljesített fő mérföldkő alapján képzett összesített érték. A „Visszáruügyek aktuális állapota” dashboardon látható a folyamatban lévő munka és az ügyek megoszlása. A vezetők áttekinthetik, hogy az egyes szakaszokban hány ügy van, így hatékonyabban oszthatják el az erőforrásokat és kezelhetik a munkaterhelést. Miért fontos? Megmutatja, hogy az egyes ügyek hol tartanak a folyamatban. Ez szükséges az aktuális munkaterhelést és állapotot követő operatív dashboardokhoz. Hol szerezhető be? A kapcsolódó dokumentumok állapotmezőiből származik. Például az értékesítési rendelés (VBUK/VBUP) vagy a szállítási dokumentumok fejlécállapotából (GBSTK), illetve tételállapotából (LFSTK). Példák Áru beérkezésére várEllenőrzésre várVisszatérítésre várLezárt | |||
| Visszáru-szabályzat azonosítója ReturnPolicyId | Az adott visszáruügyre vonatkozó szabályzat azonosítója. | ||
| Leírás Ez az attribútum jelzi, hogy az ügyletre melyik visszáru-szabályzat vagy szabályrendszer vonatkozik. A szabályzat eltérhet a termék típusától, az ügyfélszegmenstől vagy a vásárlás óta eltelt időtől függően. Ez az adat szükséges a „Visszáru-szabályzat betartásának áttekintése” dashboardhoz. Ha minden ügyhöz hozzárendeli a vonatkozó szabályzatot, a rendszer automatikusan ellenőrizheti a szabályok betartását, például a visszaküldési határidőt vagy a termék állapotára vonatkozó előírásokat, és megjelölheti az elemzendő eltéréseket. Miért fontos? Lehetővé teszi az üzleti szabályok automatikus ellenőrzését, így a visszáruk feldolgozása következetesen, a szabályzatnak megfelelően történhet. Hol szerezhető be? Ez általában nem szabványos SAP-mező, ezért az üzleti logika alapján, például a termék típusa, az ügyfél és az értékesítés dátuma szerint kell meghatározni. Ha bevezették, egy egyéni mezőben is tárolható. Példák STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Visszáru-szállítási bizonylat száma ReturnDeliveryNumber | A visszáru-szállítási bizonylat egyedi azonosítója. | ||
| Leírás Amikor az ügyfél fizikailag visszaküldi az árut, az SAP rendszerben visszáru-szállítási bizonylat készül a bejövő logisztika kezelésére. Ez az attribútum a bizonylat egyedi száma. Ez az azonosító fontos a visszaküldött áru fizikai mozgásának követéséhez. Összekapcsolja a visszáru pénzügyi és logisztikai oldalát, így részletesen elemezhetők az áruátvételi és ellenőrzési szakaszok. Miért fontos? Összekapcsolja a visszáru-megrendelést az áru fizikai átvételével, ami elengedhetetlen a logisztikai és raktári feldolgozási idők elemzéséhez. Hol szerezhető be? Ez a szállítási bizonylat száma (VBELN) a LIKP fejlécet tartalmazó táblából, ahol a bizonylatkategória visszáru-szállítást jelez. Példák 840000128400001384000014 | |||
| Visszatérítés SLA-határidő RefundSlaTargetDate | Az a határidő, ameddig a visszáruhoz kapcsolódó visszatérítést fel kell dolgozni. | ||
| Leírás Ez az attribútum határozza meg a visszatérítés feldolgozására vonatkozó szolgáltatási szintű megállapodás (SLA) határidejét. A dátumot rendszerint üzleti szabályok alapján számítják ki, például a visszáru jóváhagyásától vagy az áru beérkezésétől számított napok alapján. Ez a mező szolgál alapul a „Visszatérítési SLA betartásának nyomon követése” dashboardhoz és a kapcsolódó KPI-hoz. Segítségével előre nyomon követheti azokat az ügyeket, amelyeknél fennáll az SLA megsértésének kockázata, és elemezheti a késések kiváltó okait. Mindez hozzájárulhat az ügyfél-elégedettség javításához. Miért fontos? Alapot ad az SLA betartásának méréséhez. Segít nyomon követni a teljesítményt, előnyben részesíteni a régóta nyitott ügyeket és javítani az ügyfél-elégedettséget. Hol szerezhető be? Ez szinte mindig számított mező. A számítás egy kiinduló dátumon, például a visszáruigény létrehozásának dátumán és az üzleti szabályokban meghatározott időtartamon alapul. Az időtartam az ügyfél típusától vagy a visszaküldés okától is függhet. Példák 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Visszatérítési SLA betartása RefundSlaAdherence | Jelző, amely megmutatja, hogy a visszatérítést az SLA-határidőn belül dolgozták-e fel. | ||
| Leírás Ez a számított attribútum ellenőrzi, hogy a „Visszatérítés feldolgozva” tevékenység a „Visszatérítés SLA-határidő” dátumán vagy az előtt történt-e. Ügyenként egyszerű, igaz vagy hamis értéket ad az SLA betartásáról. Ez a „Visszatérítési SLA betartásának nyomon követése” dashboard és a „Visszatérítési SLA betartási aránya” KPI alapmutatója. Segít mérni, hogy a folyamat megfelel-e az ügyfeleknek tett vállalásoknak, és azonosítani az elvárásoknak nem megfelelő ügyeket, hogy elemezhetők legyenek a késések kiváltó okai. Miért fontos? Közvetlenül méri, hogy a folyamat megfelel-e az ügyfeleknek tett vállalásoknak, ezért a szolgáltatás minőségének és az ügyfél-elégedettségnek fontos mutatója. Hol szerezhető be? Ügyenként a „Visszatérítés feldolgozva” tevékenység EventTime értékét kell összehasonlítani a „RefundSlaTargetDate” értékével. Példák truefalse | |||
Visszáru- és visszatérítés-kezelési tevékenységek
| Tevékenység | Leírás | ||
|---|---|---|---|
| Áru beérkezése a raktárba | Ez az esemény jelzi, hogy a visszaküldött termék fizikailag megérkezett a raktárba vagy a feldolgozóközpontba. Kifejezetten akkor rögzül, amikor a visszáru-szállításra könyvelik az áruátvételt (PGR), és létrejön az anyagbizonylat. | ||
| Miért fontos? Ez fontos mérföldkő, ettől kezdődik az ellenőrzésre és a termék további sorsának eldöntésére fordított idő mérése. Az ezt megelőző késések az ügyféltől, az ezt követők a vállalaton belüli folyamatoktól függenek. Hol szerezhető be? A visszáruhoz tartozó áruátvételi mozgásnem anyagbizonylataiból, az MSEG és MKPF táblákból rögzíthető. Az esemény időpontját a könyvelési dátum (MKPF-BUDAT) jelzi. Rögzítés Az esemény a visszáru-szállítás áruátvételének könyvelésének felel meg. Eseménytípus explicit | |||
| Jóváírási kérelem létrehozása | Sikeres ellenőrzés után ez a tevékenység jelzi az ügyfél jóváírására irányuló kérelem létrehozását. Ez új értékesítési bizonylatként, jóváírási kérelemként kerül rögzítésre, amely az eredeti visszáru-megrendelésre hivatkozik. | ||
| Miért fontos? Ez indítja el a visszáru-folyamat pénzügyi rendezési szakaszát. Az ellenőrzés és e lépés közötti idő elemzése megmutatja, mennyire hatékony az átadás a logisztika és a pénzügy között. Hol szerezhető be? A VBAK táblában létrehozott, jóváírási kérelem kategóriájú értékesítési bizonylatból rögzíthető. A visszáruhoz való kapcsolódást a VBFA bizonylatfolyam-tábla tartalmazza. Rögzítés Az esemény akkor kerül rögzítésre, amikor elmentenek egy új jóváírási kérelmet. Eseménytípus explicit | |||
| Jóváíró bizonylat létrehozása | Ez az a hivatalos számlázási bizonylat, amely jóváírja az ügyfél számláján a visszaküldött termék értékét. Kifejezetten akkor rögzül az esemény, amikor a jóváíró bizonylat a jóváírási kérelem alapján létrejön. | ||
| Miért fontos? A jóváíró bizonylat létrehozása fontos pénzügyi mérföldkő. Megerősíti a visszatérítendő összeget, és engedélyezi a kifizetés elindítását. Hol szerezhető be? A VBRK táblában létrehozott, jóváíró bizonylat kategóriájú számlázási bizonylatból rögzíthető. A VBFA tábla kapcsolja össze a jóváírási kérelemmel. Rögzítés Az esemény akkor kerül rögzítésre, amikor elmentenek egy új jóváíró számlázási bizonylatot, például a VF01 tranzakcióval. Eseménytípus explicit | |||
| Termékellenőrzés befejezése | A visszaküldött termék minőségének és állapotának felmérését jelzi. Az Advanced Returns Management rendszerben ez gyakran külön lépés, amely rögzíti az ellenőrzés eredményét, és meghatározza a következő intézkedést, például a visszatérítést vagy a selejtezést. | ||
| Miért fontos? Az ellenőrzés időtartama és eredménye közvetlenül befolyásolja a visszatérítés feldolgozási idejét és a készletkezelést. Ez a tevékenység elengedhetetlen az ellenőrzés hatékonyságának és az utómunkának az elemzéséhez. Hol szerezhető be? Az SAP Advanced Returns Management (ARM) rendszerben ez az ellenőrzési tranzakcióból származó, kifejezetten rögzített esemény lehet. A visszáru-megrendelés tételének állapotváltozásából is következtetni lehet rá, ha az jelzi az ellenőrzés eredményét. Rögzítés Az ARM rendszerben a logisztikai utókövetési tevékenységekhez kapcsolódó tranzakciós naplókból vagy állapotváltozásokból rögzíthető. Eseménytípus explicit | |||
| Visszáru-kérelem indítása | A visszáru-folyamat itt kezdődik: a rendszerben hivatalosan létrejön a visszáru-megrendelés. Az esemény akkor rögzül, amikor az SAP S/4HANA rendszerben elmentenek egy új, visszáru-megrendelés típusú értékesítési bizonylatot. | ||
| Miért fontos? Ez a tevékenység jelöli a visszáruügy hivatalos kezdetét. Az esemény és a lezárás közötti idő elemzése elengedhetetlen a teljes visszáru-átfutási idő és az ügyfélélmény méréséhez. Hol szerezhető be? Ez egy kifejezetten rögzített esemény: a VBAK táblában létrejön egy értékesítési bizonylat, amelynek bizonylatkategóriája (VBAK-VBTYP) visszáru-megrendelést jelez. A létrehozás időbélyege a VBAK-ERDAT mezőben található. Rögzítés Az esemény akkor kerül rögzítésre, amikor elmentenek egy új visszáru-megrendelést, például a VA01 tranzakcióval. Eseménytípus explicit | |||
| Visszáruügy lezárása | Ez az utolsó tevékenység, amely jelzi, hogy a visszáru-folyamat befejeződött, és az ügyben nincs további teendő. Erre általában abból lehet következtetni, hogy a visszáru-megrendelés végleges, lezárt állapotba kerül a rendszerben. | ||
| Miért fontos? Ez az esemény jelöli a folyamat végét, és lehetővé teszi a teljes átfutási idő kiszámítását. Megerősíti, hogy az ügyet teljesen rendezték. Hol szerezhető be? A VBAK táblában szereplő visszáru-megrendelés vagy a VBAP táblában szereplő tételeinek általános állapotából következtethető ki, ha az „Teljesítve” vagy „Lezárva” állapotba kerül. Ezt a rendszer állapotkezelési beállításai határozzák meg. Rögzítés A visszáru-megrendelés bizonylatállapotának „Teljesítve” értékre változásából következtethető ki. Eseménytípus inferred | |||
| Visszatérítés feldolgozása | Ez a visszatérítési folyamat utolsó lépése: a pénzügyi jóváírás kiegyenlítésével jelzi, hogy a kifizetést elküldték az ügyfélnek. Erre a pénzügyi modulban létrehozott kiegyenlítési bizonylatból lehet következtetni, amely rendezi az ügyfél számláján fennálló nyitott jóváírást. | ||
| Miért fontos? Ekkor kapja meg ténylegesen az ügyfél a pénzt. A visszáru indításától eddig eltelt idő jelentősen befolyásolja az ügyfél elégedettségét, és fontos mutató az SLA betartásának méréséhez. Hol szerezhető be? A pénzügyi számvitel BSEG tételtáblájában szereplő kiegyenlítési adatokból következtethető ki. A jóváíró bizonylathoz kapcsolódó ügyféltétel kiegyenlítési dátuma (BSEG-AUGDT) jelzi, mikor dolgozták fel a visszatérítést. Rögzítés A jóváíró bizonylathoz kapcsolódó könyvelési bizonylat kiegyenlítési dátumának kitöltéséből következtethető ki. Eseménytípus inferred | |||
| Csere-megrendelés létrehozása | Ez egy alternatív megoldást jelöl: visszatérítés helyett új értékesítési megrendelés készül, hogy csereárut küldjenek az ügyfélnek. Az esemény akkor rögzül, amikor az eredeti visszárura hivatkozó új értékesítési megrendelés jön létre. | ||
| Miért fontos? Ez a tevékenység megkülönbözteti a visszatérítéssel végződő visszárukat a termékcseréktől, amelyek folyamata és ügyfélre gyakorolt eredménye eltérő. Ez fontos a folyamatváltozatok elemzéséhez. Hol szerezhető be? A VBAK táblában létrehozott új értékesítési bizonylatból rögzíthető, amelyet a VBFA bizonylatfolyam-tábla kapcsol a visszáru-megrendeléshez. Rögzítés Az esemény akkor kerül rögzítésre, amikor elmentenek egy csereáruként megjelölt új értékesítési megrendelést. Eseménytípus explicit | |||
| Könyvelési bizonylat létrehozása | Ez az esemény akkor következik be, amikor a jóváíró bizonylatot sikeresen lekönyvelik a pénzügyi számvitel modulban. Ekkor létrejönnek a főkönyvi tételek, és a jóváírás számviteli szempontból hivatalossá válik. | ||
| Miért fontos? Ez a tevékenység megerősíti, hogy a jóváírás bekerült a pénzügyi rendszerbe. A jóváíró bizonylat létrehozása és a könyvelés közötti idő rávilágíthat a számlázás és a pénzügy közötti kapcsolódási problémákra. Hol szerezhető be? A BKPF könyvelési táblában létrehozott bizonylatfejlécből rögzíthető, amely a VBRK táblában szereplő jóváíró bizonylathoz kapcsolódik (VBRK-BELNR). Rögzítés Az esemény akkor kerül rögzítésre, amikor a számlázási bizonylatot sikeresen lekönyvelik a pénzügyi számvitelben. Eseménytípus explicit | |||
| Visszáru elutasítása | Azt jelzi, hogy a visszaküldött termék nem felelt meg a visszáru-szabályzat feltételeinek, ezért elutasították a visszatérítési vagy jóváírási kérelmet. Ezt általában az ellenőrzés után a visszáru-megrendelés tételéhez rendelt konkrét állapot vagy indokkód rögzíti. | ||
| Miért fontos? Az elutasítások követése segít elemezni a visszáru-szabályzat betartását és feltárni az elutasítások gyakori okait. Ez a folyamat egyik fontos kivételes útvonala. Hol szerezhető be? A visszáru-megrendelés tételéhez rendelt elutasítási okból (VBAP-ABGRU), vagy az Advanced Returns Management rendszerben az ellenőrzés során beállított konkrét állapotból következtethető ki. Rögzítés Az elutasítási ok vagy egy konkrét „elutasítva” állapot beállításából következtethető ki a visszáru-bizonylat tételén. Eseménytípus inferred | |||
| Visszáru-megrendelés jóváhagyása | A visszáru-megrendelés hivatalos jóváhagyását vagy felszabadítását jelzi, amely után az ügy továbbléphet a következő szakaszba. Ez általában az értékesítési bizonylat fejlécében vagy tételén bekövetkező állapotváltozásból következtethető ki, amely azt mutatja, hogy a zárolásokat feloldották. | ||
| Miért fontos? A jóváhagyási lépések jelentős késést okozhatnak. Ennek a tevékenységnek a követése segít feltárni a visszáru-folyamat kezdeti engedélyezési szakaszának szűk keresztmetszeteit. Hol szerezhető be? Az állapotkezelési táblákból vagy közvetlenül a VBAK, illetve VBAP táblák állapotmezőiből következtethető ki. A felszabadítási állapot megváltozása vagy a szállítási zárolás (VBAP-LIFSP) feloldása jóváhagyást jelezhet. Rögzítés A visszáru-megrendelés fejlécében vagy tételén szereplő állapotmezők felszabadítást vagy jóváhagyást jelző változásából következtethető ki. Eseménytípus inferred | |||
| Visszáru-szállítási bizonylat létrehozása | Ez a tevékenység a bejövő szállítási bizonylat létrehozását jelzi, amely a visszaküldött termékek fizikai átvételét kezeli. A rendszer kifejezetten rögzíti ezt az eseményt, amikor létrejön a visszáru-megrendelésre hivatkozó szállítási bizonylat. | ||
| Miért fontos? Ez fontos logisztikai mérföldkő. A visszáru jóváhagyása és a szállítási bizonylat létrehozása közötti idő megmutatja, milyen hatékonyan jutnak el a visszáruval kapcsolatos információk a raktárhoz vagy az áruátvételi részleghez. Hol szerezhető be? A LIKP táblában létrehozott szállítási bizonylat fejlécéből rögzíthető, amelyet a VBFA bizonylatfolyam-tábla kapcsol az előző visszáru-megrendeléshez. Rögzítés Az esemény akkor kerül rögzítésre, amikor elmentenek egy új visszáru-szállítási bizonylatot, például a VL01N tranzakcióval. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Előfeltételek ellenőrzése: Ellenőrizze, hogy az adatkinyerést végző felhasználói fiók rendelkezik-e az SAP S/4HANA rendszerben a szükséges Core Data Services (CDS) nézetek eléréséhez szükséges jogosultságokkal. A fontos nézetek: I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry és I_ClearedItem.
- Lekérdezőeszköz megnyitása: Jelentkezzen be a választott SQL-ügyfélprogramba vagy adatintegrációs eszközbe, amely már kapcsolódik az SAP S/4HANA-adatbázishoz. Ilyen eszköz lehet például az SAP Analytics Cloud vagy egy külső ETL-platform.
- Lekérdezési paraméterek beállítása: Futtatás előtt módosítsa a megadott SQL-lekérdezést. Keresse meg a helyőrző értékeket, és cserélje le őket a környezetének megfelelő paraméterekre. Ilyen például a
[Start Date], az[End Date], a[Your Source System ID], a[Your Return Order Type], valamint az egyéb bizonylattípus- és vállalatkód-szűrő. - Adatkinyerő lekérdezés futtatása: Másolja ki a teljes SQL-lekérdezést, majd futtassa az eszközében. A lekérdezés több SELECT utasítás eredményét egyesíti, így az összes megadott tevékenységet egyetlen adathalmazba gyűjti.
- A lekérdezés működésének megértése: A UNION ALL szerkezet minden
SELECTblokkja egy adott tevékenység adatainak kinyeréséért felel. Több CDS-nézet összekapcsolásával gyűjti össze a szükséges attribútumokat, rögzített szöveget rendel azActivityNamemezőhöz, és kiválasztja azEventTimemezőhöz tartozó időbélyeget. - Nyers adatok ellenőrzése: A lekérdezés lefutása után röviden ellenőrizze az eredményt. Nézze meg, hogy a sorok száma ésszerű-e, és a fontos oszlopok, például a
ReturnCaseId, azActivityNameés azEventTime, a várt módon ki vannak-e töltve. - Adatok átalakítása: A lekérdezés lapos eseménynapló-formátumot állít elő, ezért általában nincs szükség jelentős szerkezeti átalakításra. Előfordulhat azonban, hogy az időbélyegek formátumát vagy az adattípusokat a célrendszer követelményeihez kell igazítania.
- Eseménynapló exportálása: Exportálja a lekérdezés eredményét CSV-fájlba. Használjon UTF-8 kódolást, hogy elkerülje a karakterek megjelenítésével kapcsolatos problémákat, különösen a felhasználónevek és a termékleírások esetében.
- Feltöltés process mining eszközbe: A létrehozott CSV-fájl feltölthető a process mining platformra, például a ProcessMindba. Rendelje hozzá a fájl oszlopait az eszköz megfelelő mezőihez, például a
ReturnCaseIdmezőt az esetazonosítóhoz, azActivityNamemezőt a tevékenységhez, azEventTimemezőt pedig az időbélyeghez.
Konfiguráció
- Előfeltételek: Az adatkinyerést végző felhasználónak megtekintési jogosultságra van szüksége az értékesítési bizonylatokhoz (VBAK), a szállításokhoz (LIKP), a számlázáshoz (VBRK) és a könyveléshez (BSEG, BKPF) kapcsolódó objektumokhoz. Az alapul szolgáló CDS View nézetek elérése is szükséges.
- Adatkör szűrése: A visszáru-folyamat elkülönítéséhez szűrje a lekérdezést a megfelelő dokumentumtípusokra. Állítsa be a visszáru-rendeléstípusok (például 'RE'), a jóváírási igénylések típusai (például 'G2') és a csere-rendeléstípusok (például 'SO') helyőrzőit. Az adatkör szűkítéséhez erősen ajánlott a
CompanyCodevagy aSalesOrganizationszerinti szűrés is. - Dátumtartomány szűrése: A teljesítmény és az adatmennyiség kezelése érdekében mindig adjon meg dátumtartományt. Első lépésként az elmúlt 3–6 hónap adatait használja. A lekérdezés elsődleges szűrési feltétele a kezdeti visszáru-rendelés létrehozási dátuma (
I_SalesDocument.CreationDate). - Teljesítményre vonatkozó szempontok: Ez az összetett lekérdezés több nagy CDS View nézetet kapcsol össze. Futtatása jelentős erőforrásokat igényelhet a forrásként használt S/4HANA rendszertől. Az esetleges terhelés csökkentése érdekében az adatkinyerést a kevésbé forgalmas üzleti órákra időzítse. Nagy adathalmazok esetén fontolja meg a fokozatos betöltést.
Példa-lekérdezés sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Lépések
- Ellenőrizze, hogy rendelkezésre áll-e közvetlen olvasási hozzáférés a releváns értékesítési, szállítási, számlázási, anyagbizonylati, ellenőrzési, státusz- és könyvelési adatokat tartalmazó SAP HANA-sémához. A séma, a nézetek és a mezőnevek az SAP S/4HANA telepítésétől függően eltérhetnek. Minden szögletes zárójelben szereplő helyőrzőt cseréljen le a rendszerben beállított objektumra és mezőre.
- Határozza meg az adatkinyerés körét a [Start date], [End date], [Company Code filter] és [Return document type filter] paraméterekkel. Első alkalommal három-hat hónapnyi gördülő időszak adatait nyerje ki, és csak a teljesítmény, illetve az adatok teljességének ellenőrzése után bővítse az időszakot.
- Azonosítsa a visszáru-rendeléseket a [Your sales document header table] és a [Your sales document item table] táblákból. Szűrje az adatokat a [Your return order document type configuration] beállításban megadott visszáru-rendelési dokumentumtípusokra. A későbbi bizonylatok összekapcsolásához őrizze meg a visszáru-rendelés számát és a tételszámot.
- A [Your document flow table or view] segítségével kövesse a bizonylatfolyamot a visszáru-rendelésektől a beérkező visszáru-szállításokig, a jóváírási igénylésekig, a csere-rendelésekig és a jóváírásokig. Ne feltételezze, hogy a bizonylatfolyam a VBAK vagy a VBAP táblában található. A kapcsolódó mezőket a rendszerben használt bizonylatfolyam-modell szerint állítsa be.
- Nyerje ki a létrehozási eseményeket a megfelelő bizonylatfej- és tételrekordokból. A jóváhagyási, elutasítási, ellenőrzési, lezárási, áruátvételi, könyvelési és kiegyenlítési eseményeket a beállított státusz-, ellenőrzési, anyagbizonylati, könyvelési és kiegyenlítési adatforrásokból nyerje ki. Minden tevékenységhez külön eseménysort kell létrehozni, mert a ProcessMind nem következtet ki eseményeket.
- Egységesítse az időbélyegeket, és alakítsa őket azonos adatbázis-időbélyeg-típussá és időzónává. Az egyes tevékenységeknél használja a beállított időbélyeg-prioritást. Ha csak dátum és idő áll rendelkezésre, a kettőt a [Your system time zone] mezőben megadott rendszer-időzóna szerint egyesítse.
- Minden eseménynél töltse ki a ReturnCaseId mezőt. Használja a kiinduló visszáru-rendelés számát, vagy az előre beállított visszáru-azonosítót, ha az Advanced Returns Management külön ügyazonosítót tárol. A visszáru-ügyhöz nem kapcsolható eseményeket hagyja ki, vagy helyezze külön kivétellistába a javításhoz.
- Töltse ki a kötelező ReturnCaseId, ActivityName, EventTime, SourceSystemId és LastDataUpdateTimestamp oszlopokat. Ha rendelkezésre állnak, a javasolt oszlopokat is töltse ki, köztük az EventEndTime, UserName, ReturnReason, RefundAmount, ProductId és CustomerId mezőket. Minden tevékenység-előfordulás külön sorba kerüljön, ne vonja össze a tevékenységeket egyetlen ügyrekordba.
- A validationSteps ellenőrzéseivel vizsgálja meg az eredményt. Ellenőrizze, hogy mind a tizenkét tevékenységnév szerepel-e, az időbélyegek ügyenként életszerű sorrendben követik-e egymást, és a bizonylathivatkozások egyeznek-e a forrástáblák adataival.
- Exportálja az eredményt UTF-8 kódolású CSV-fájlként vagy más, ProcessMind által támogatott táblázatos formátumban. Őrizze meg a pontos oszlopneveket, használjon egyetlen fejlécsort, az időbélyegeket egyértelmű ISO-formátumban tárolja, majd töltse fel az eseménynaplót. A ReturnCaseId mezőt állítsa be ügyazonosítóként, az ActivityName mezőt pedig tevékenységoszlopként.
Konfiguráció
- Dátumtartomány: Kezdje három-hat hónapnyi adattal. Használja a [Start date] és [End date] paramétereket, és vegyen fel elegendő előzményt ahhoz, hogy a kiválasztott időszak előtt indult, de azon belül lezárult ügyek is szerepeljenek.
- Visszáru-ügyek köre: Szűrjön a [Your return order document type configuration] beállításban megadott visszáru-rendelési dokumentumtípusokra. Ne rögzítsen előre dokumentumtípust, amíg nem ellenőrizte a célrendszerben.
- Szervezeti szűrők: Csak szükség esetén szűrjön a [Company Code filter], az értékesítési szervezet, az értékesítési csatorna, a divízió, az üzem vagy az ügyfél alapján. Ellenőrizze, hogy a szűrők nem zárják-e ki a vállalatok közötti vagy vállalatcsoporton belüli kapcsolódó bizonylatokat.
- Forrásobjektumok: A [Your table name] és [Your view name] helyőrzőket cserélje le jóváhagyott SAP S/4HANA-táblákra vagy CDS View nézetekre. A VBAK, VBAP, VBRK és VBRP elérhető lehet a telepített rendszerben, de használatukat és bővítéseiket futtatás előtt ellenőrizni kell.
- Időbélyegek kezelése: Minden tevékenységhez állítsa be a forrás időbélyegmezőit és az időzónát. Az EventTime és EventEndTime mezőket egységesen tárolja, lehetőleg UTC-ben vagy a ProcessMind rendszerben egyeztetett időzónában.
- Státuszok értelmezése: Állítsa be pontosan azokat a státuszértékeket, indokkódokat, ellenőrzési eredményeket és lezárási jelzőket, amelyek a rendszerben a jóváhagyást, az elutasítást, az ellenőrzés befejezését és az ügy lezárását jelentik.
- Forrásrendszer-azonosító: A [Source system identifier] helyőrzőt cserélje le egy állandó értékre, például az adatkinyerési platform által használt SAP-rendszer-azonosítóra.
- Frissítés időbélyege: Az [Extraction timestamp] helyőrző helyére a lekérdezés futásának kezdeti időpontját vagy a forrás pillanatképének létrehozási idejét írja. Egy adatkinyerési futás minden sorában ugyanazt az értéket használja, kivéve, ha soronkénti frissítési időbélyegre van szükség.
- Teljesítmény: A nagy bizonylatfolyam-, könyvelési, anyagbizonylati és státuszforrások összekapcsolása előtt szűkítse le a kezdeti visszáru-adatkört. Használjon indexelt vagy partíciószűrést lehetővé tevő mezőket, kerülje a korlátozás nélküli táblabeolvasást, és csak az adatbázis-adminisztrátor jóváhagyásával hozzon létre köztes eredményeket.
- Fokozatos adatkinyerés: Ismétlődő futtatásoknál használja a [Last successful extraction timestamp] értékét, és állítson be szabályozott átfedési időszakot a késői módosítások rögzítéséhez. Az ismétlődő rekordokat a ReturnCaseId, ActivityName, forrásbizonylat-azonosító és EventTime alapján szűrje ki.
- Jogosultságok és előfeltételek: Kérjen olvasási jogosultságot minden beállított forrásobjektumhoz és mezőhöz, jóváhagyást a közvetlen adatbázis-hozzáféréshez, valamint megerősítést arról, hogy a szükséges SAP-komponensek és az Advanced Returns Management funkciók aktívak, ha alkalmazandók.
- Adatvédelem: Csak a szükséges ügyfél- és pénzügyi adatokat használja, tartsa be a szervezeti adatvédelmi előírásokat, és gondoskodjon az exportált fájlok biztonságáról.
Példa-lekérdezés sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Készen áll a kezdésre?
A sablon segítségével elsajátíthatja a visszáru- és visszatérítés-kezelési adatok kinyerésének és elemzésének alapjait. Kezdje el még ma a folyamatok fejlesztését.
Fejlessze most a visszáru- és visszatérítés-kezelést SAP S/4HANA rendszerben
Tárja fel a hatékonysági problémákat, csökkentse 30%-kal az átfutási időt, és növelje az elégedettséget.
Nincs szükség bankkártyára. Kezdje el még ma a folyamatok fejlesztését.