Šablona dat pro zpracování vrácení zboží a refundací
Šablona dat pro zpracování vrácení zboží a refundací
- Doporučené atributy ke shromažďování
- Důležité činnosti ke sledování
- Pokyny k extrakci dat
Zpracování vrácení zboží a refundací: atributy
| Název | Popis | ||
|---|---|---|---|
| Čas události EventTime | Přesné časové razítko určující, kdy k dané činnosti došlo. | ||
| Popis Čas události zaznamenává datum a čas, kdy byla obchodní událost zapsána do systému. Toto časové razítko je důležité pro chronologické seřazení činností i pro veškeré časové analýzy. V process mining se tento atribut používá k výpočtu doby mezi činnostmi, určení délky jednotlivých kroků a analýze výkonnosti procesu v čase. Slouží jako základ pro odhalování úzkých míst, sledování dodržování SLA a pochopení časového průběhu procesu vrácení. Proč je to důležité Toto časové razítko je nezbytné pro řazení událostí, výpočet dob a časů vyřízení i odhalování prodlev v procesu. Kde data získat Obvykle pochází z polí data a času spojených s vytvořením dokladu nebo změnou stavu, například ERDAT (datum vytvoření) a ERZET (čas vytvoření) v tabulkách VBAK, LIKP a BKPF nebo z data zaúčtování (BUDAT) v účetních dokladech. Příklady 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID případu vrácení ReturnCaseId | Jedinečný identifikátor jednoho případu vrácení zboží, který propojuje všechny související činnosti od zahájení až po uzavření. | ||
| Popis ID případu vrácení je hlavní identifikátor, který sdružuje všechny události a činnosti patřící k jednomu případu vrácení. Každému požadavku zákazníka na vrácení se přiřadí jedinečné ID, které umožňuje sledovat celý proces od začátku do konce. V process mining je tento atribut základem pro rekonstrukci průběhu procesu. Propojuje jednotlivé události, například „Zahájení požadavku na vrácení“, „Příjem zboží“ a „Vrácení peněz zpracováno“, do souvislé časové osy každého případu. Díky tomu lze analyzovat dobu vyřízení, varianty procesu i úzká místa. Proč je to důležité Jde o nezbytný identifikátor pro sledování vrácení od začátku do konce a pro veškeré analýzy jednotlivých případů, včetně doby vyřízení a hledání variant procesu. Kde data získat Obvykle jde o číslo prodejního dokladu (VBELN) z tabulky hlaviček vratkových objednávek VBAK, kde kategorie dokladu (VBTYP) označuje vrácení. Příklady 600001896000019060000191 | |||
| Název činnosti ActivityName | Název konkrétní obchodní činnosti nebo události, ke které došlo v procesu vrácení zboží a vrácení peněz. | ||
| Popis Tento atribut popisuje jednotlivý krok nebo milník v průběhu vrácení. Činnosti představují vykonanou práci, například „Schválení vratkové objednávky“ nebo „Dokončení kontroly zboží“. Odvozují se ze změn stavů, vytvoření dokladů nebo konkrétních akcí uživatelů zaznamenaných v SAP S/4HANA. Analýza pořadí a četnosti těchto činností je základem process mining. Pomáhá zobrazit mapu procesu, odhalit běžné i méně časté postupy a určit činnosti, které se často opakují a mohou signalizovat nutnost oprav nebo neefektivitu. Proč je to důležité Činnosti tvoří základ mapy procesu a umožňují zobrazit a analyzovat průběh procesu, úzká místa i odchylky. Kde data získat Názvy činností se obvykle odvozují z kombinace dat, například ze změn stavu dokladů v tabulkách VBUK/VBUP, událostí vytvoření v tabulkách hlaviček, jako jsou VBAK (prodejní doklady) a BKPF (účetní doklady), a ze stavů pohybu zboží v MSEG. Příklady Zahájení požadavku na vráceníPříjem zboží ve skladuVytvoření dobropisuVrácení peněz zpracováno | |||
| ID zdrojového systému SourceSystemId | Identifikátor zdrojového systému, ze kterého byla data získána. | ||
| Popis Tento atribut určuje zdrojový systém, ve kterém událost vznikla. V tomto procesu jde obvykle o ID instance SAP S/4HANA. V prostředí s více systémy je toto pole důležité pro sledování původu dat, řešení problémů a zajištění jejich integrity. Pomáhá rozlišit data, pokud se vrácené zboží zpracovává v různých instancích ERP nebo pokud jsou systémy propojené s externími systémy, například se systémem pro správu skladu. Proč je to důležité Poskytuje důležitý kontext o původu a návaznosti dat, zejména v prostředí s více systémy, a umožňuje jejich dohledatelnost i ověření. Kde data získat Tato hodnota je obvykle neměnná a nastavuje se při získávání dat. Lze ji zjistit z administrativních údajů systému SAP, například z ID systému (SID). Příklady S4H_PROD_100S4Q_DEV_200 | |||
| Poslední aktualizace dat LastDataUpdateTimestamp | Časové razítko označující, kdy byla data této události naposledy aktualizována nebo získána. | ||
| Popis Tento atribut zaznamenává datum a čas posledního získání nebo aktualizace dat. Poskytuje informace o aktuálnosti analyzovaného souboru dat. Pomáhá posoudit, nakolik jsou výsledky process mining aktuální. Uživatelé vidí, jak čerstvá data jsou, což je důležité zejména při provozním sledování a v dashboardech, které zobrazují probíhající případy. Proč je to důležité Ukazuje aktuálnost dat. Díky tomu můžete ověřit, že analýzy a dashboardy vycházejí z aktuálních informací. Kde data získat Tuto hodnotu obvykle vygeneruje a připojí k souboru dat nástroj ETL nebo datový kanál při získávání dat. Příklady 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Čas ukončení události EventEndTime | Časové razítko označující dokončení činnosti, které slouží k výpočtu její délky. | ||
| Popis Zatímco StartTime (EventTime) označuje začátek činnosti, EventEndTime označuje její konec. U mnoha událostí generovaných systémem jsou časy začátku a konce totožné, protože událost nastane okamžitě. U činností s měřitelnou délkou, například „Kontrola zboží“, je však tento atribut důležitý. Umožňuje přímo vypočítat dobu zpracování činnosti. To je základem analýzy výkonnosti, protože pomáhá určit, které konkrétní kroky, nejen prodlevy mezi nimi, zabírají nejvíce času. Proč je to důležité Umožňuje přesně vypočítat dobu trvání jednotlivých činností a určit neefektivitu v konkrétních krocích procesu. Kde data získat Tato hodnota se často odvozuje. U některých činností může být uvedena v samostatném poli. Častěji jde o StartTime následující činnosti v daném případu. Příklady 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Částka vrácených peněz RefundAmount | Konečná částka vrácená zákazníkovi. | ||
| Popis Tento atribut představuje skutečnou částku připsanou nebo vrácenou zákazníkovi po dokončení procesu vrácení. Hodnota se zaznamenává ve finančních dokladech, například v dobropisech. Jde o důležitý finanční ukazatel pro různé analýzy. V dashboardu „Analýza rozdílů v částkách vrácených peněz“ slouží k porovnání se žádanou částkou. Umožňuje také rozdělit vrácené položky podle hodnoty a zjistit, zda se případy s vysokou hodnotou zpracovávají jinak nebo se vyřizují déle. Proč je to důležité Sleduje finanční dopad vráceného zboží a je důležitý pro analýzu správnosti vrácených částek, odhalování případů s vysokou hodnotou a pochopení celkových nákladů. Kde data získat Zdrojovým údajem je čistá hodnota (NETWR) dobropisu, která se nachází například v tabulkách VBRK (hlavička fakturačního dokladu) nebo BSEG (položka účetního dokladu). Příklady 125.50999.0049.99 | |||
| Důvod vrácení ReturnReason | Důvod, který zákazník uvedl při vrácení zboží. | ||
| Popis Tento atribut zachycuje důvod vrácení uvedený zákazníkem, například „Vadné zboží“, „Nesprávná velikost“ nebo „Už není potřeba“. Zákazník obvykle vybírá z předem definovaného seznamu důvodů při zahájení vrácení. Analýza důvodů vrácení je důležitá pro odhalení problémů s kvalitou výrobků, zlepšení jejich popisu nebo úpravu prodejních postupů. Ukazuje, s čím jsou zákazníci nespokojení, a pomáhá určit oblasti, na které se zaměřit, aby se snížil celkový počet vrácených položek. Proč je to důležité Ukazuje, proč zákazníci zboží vracejí, a umožňuje hledat příčiny problémů s kvalitou, chyb při vyřizování objednávek nebo nesouladu s očekáváním zákazníků. Kde data získat Obvykle se ukládá do pole ABGRU (důvod zamítnutí prodejního dokladu) v tabulce položek vratkové objednávky VBAP. Příklady 001 - Nízká kvalita002 - Poškozeno při přepravě005 - Odesláno nesprávné zboží | |||
| ID produktu ProductId | Jedinečný identifikátor vraceného zboží. | ||
| Popis Tento atribut určuje materiál nebo produkt, kterého se vrácení týká. Propojuje proces vrácení s konkrétní položkou v katalogu produktů. Analýza vráceného zboží podle produktu pomáhá odhalit položky s vysokou mírou vrácení, což může ukazovat na vady kvality, nepřesný popis nebo problémy ve výrobě. Firmy mohou tyto údaje využít při rozhodování o návrhu produktů, správě dodavatelů a plánování zásob. Proč je to důležité Propojuje proces vrácení s konkrétními produkty a umožňuje analyzovat míru vrácení jednotlivých položek i odhalit problémy s kvalitou nebo popisem. Kde data získat Nachází se v poli čísla materiálu (MATNR) v tabulce položek vratkové objednávky (VBAP) nebo položek vratkové dodávky (LIPS). Příklady FG-10023HW-45981SW-LICENSE-PREM | |||
| ID zákazníka CustomerId | Jedinečný identifikátor zákazníka, který zahájil vrácení. | ||
| Popis Tento atribut určuje zákazníka, který požádal o vrácení zboží. Propojuje případ v procesu s konkrétní osobou nebo firmou v kmenových datech zákazníků. Analýza vráceného zboží podle zákazníků pomáhá odhalit vzorce, například neobvykle vysokou míru vracení, která může ukazovat na podvodné jednání nebo nespokojenost. Umožňuje také rozdělit proces podle typu, hodnoty nebo historie zákazníka a přizpůsobit úroveň služeb. Proč je to důležité Propojuje vrácené zboží s konkrétními zákazníky a umožňuje analyzovat jejich chování, rozdělit je do skupin a odhalit zákazníky, kteří zboží vracejí často. Kde data získat Nachází se v poli čísla zákazníka (KUNNR) v tabulce hlaviček vratkových objednávek (VBAK). Příklady CUST-001234CUST-005678CUST-009012 | |||
| Jméno uživatele UserName | ID uživatele, který činnost provedl. | ||
| Popis Tento atribut určuje konkrétního uživatele nebo systémového agenta odpovědného za dokončení úkolu, například schválení vrácení nebo vytvoření dobropisu. V SAP se obvykle zaznamenává v polích, která evidují uživatele, jenž doklad vytvořil nebo změnil. Analýza podle uživatelů pomáhá odhalit výkonné pracovníky nebo týmy, potřeby školení a rozložení pracovní zátěže. Je důležitá také při prověřování odchylek, protože propojuje činnosti v procesu s konkrétními osobami a podporuje dodržování pravidel i audit. Proč je to důležité Přiřazuje činnosti v procesu konkrétním uživatelům a umožňuje analyzovat výkonnost týmů, pracovní zátěž a dodržování pravidel. Kde data získat Tento údaj se běžně nachází v hlavičkách dokladů, například v poli ERNAM (vytvořil) v tabulkách VBAK (prodejní objednávky), LIKP (dodávky) a BKPF (účetní doklady). Podrobnosti o uživatelích lze doplnit z kmenové tabulky uživatelů USR21. Příklady CBROWNASMITHWF_BATCH | |||
| Cílové datum SLA pro refundaci RefundSlaTargetDate | Datum, do kterého má být refundace za daný případ vrácení zboží zpracována. | ||
| Popis Tento atribut určuje termín SLA pro zpracování refundace. Datum se obvykle vypočítá podle obchodních pravidel, například jako určitý počet dní od schválení vrácení nebo přijetí zboží. Toto pole je základem dashboardu „Sledování dodržování SLA pro refundace“ a souvisejícího KPI. Umožňuje včas sledovat případy, u kterých hrozí nedodržení SLA, a analyzovat příčiny zpoždění. Tím pomáhá zvyšovat spokojenost zákazníků. Proč je to důležité Poskytuje základ pro měření dodržování SLA, sledování výkonu, určování priorit u dlouho otevřených případů a zvyšování spokojenosti zákazníků. Kde data získat Téměř vždy jde o odvozené pole. Výpočet vychází z rozhodného data, například data vytvoření žádosti o vrácení, a lhůty stanovené obchodními pravidly. Ta se mohou lišit například podle typu zákazníka nebo důvodu vrácení. Příklady 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Číslo dobropisu CreditMemoNumber | Jedinečný identifikátor dobropisu, který opravňuje k vrácení peněz. | ||
| Popis Dobropis je fakturační doklad, kterým se zákazníkovi oficiálně připíše částka za vrácené zboží. Tento atribut obsahuje jedinečné číslo finančního dokladu. Sledování čísla dobropisu je důležité pro analýzu finančního vypořádání vrácení. Jde o důležitý milník, který často zahajuje samotnou platbu. Číslo je také potřeba pro finanční odsouhlasení a audit. Proč je to důležité Představuje oficiální finanční transakci vrácení peněz. Je důležitý pro sledování závěrečných kroků procesu i pro finanční audit. Kde data získat Jde o číslo fakturačního dokladu (VBELN) z tabulky hlaviček fakturačních dokladů (VBRK), kde kategorie dokladu označuje dobropis. Příklady 900003459000034690000347 | |||
| Číslo vratkové dodávky ReturnDeliveryNumber | Jedinečný identifikátor dokladu vratkové dodávky. | ||
| Popis Když zákazník fyzicky vrací zboží, vytvoří se v SAP doklad vratkové dodávky pro správu příchozí logistiky. Tento atribut obsahuje jedinečné číslo dokladu. ID je důležité pro sledování fyzického pohybu vráceného zboží. Propojuje finanční a logistickou část vrácení a umožňuje podrobně analyzovat příjem zboží a jeho kontrolu. Proč je to důležité Propojuje vratkovou objednávku s fyzickým příjmem zboží a umožňuje analyzovat logistiku i dobu zpracování ve skladu. Kde data získat Jde o číslo dodacího dokladu (VBELN) z tabulky hlaviček dodávek (LIKP), kde kategorie dokladu označuje vratkovou dodávku. Příklady 840000128400001384000014 | |||
| Dodržení SLA pro refundaci RefundSlaAdherence | Příznak určující, zda byla refundace zpracována v cílovém termínu SLA. | ||
| Popis Tento vypočítaný atribut ověřuje, zda k činnosti „Refundace zpracována“ došlo nejpozději v cílovém datu SLA pro refundaci. Pro každý případ uvádí jednoduchou hodnotu ano/ne, která vyjadřuje dodržení SLA. Jde o hlavní metriku dashboardu „Sledování dodržování SLA pro refundace“ a KPI „Míra dodržení SLA pro refundace“. Pomáhá měřit plnění závazků vůči zákazníkům a odhalovat případy, které nesplnily očekávání. Umožňuje také analyzovat příčiny zpoždění. Proč je to důležité Přímo měří plnění závazků vůči zákazníkům, a je proto důležitým ukazatelem kvality služeb a spokojenosti zákazníků. Kde data získat Vypočítává se porovnáním času události EventTime u činnosti „Refundace zpracována“ s hodnotou RefundSlaTargetDate pro každý případ. Příklady truefalse | |||
| Dodržování zásad pro vrácení zboží ReturnPolicyAdherence | Příznak určující, zda případ vrácení zboží splňuje stanovená pravidla. | ||
| Popis Tento vypočítaný logický atribut určuje, zda vrácení zboží splňuje kritéria stanovená příslušnými pravidly. Výpočet může například ověřit, zda bylo vrácení zahájeno v povolené lhůtě nebo zda je důvod vrácení pro daný produkt platný. Atribut přímo podporuje dashboard „Přehled dodržování pravidel pro vrácení zboží“. Umožňuje vyčíslit míru dodržování pravidel a přejít k případům, které je nesplňují, a zjistit příčiny odchylek. Díky tomu lze pravidla účinněji uplatňovat. Proč je to důležité Vyčísluje dodržování obchodních pravidel a pomáhá odhalovat a omezovat jejich porušování, které může snižovat ziskovost nebo vést k výjimkám v procesu. Kde data získat Vypočítává se podle obchodních pravidel. Například: (datum zahájení vrácení − datum původního nákupu) <= [povolený počet dní pro vrácení]. K výpočtu je potřeba datum původního nákupu a pravidla pro vrácení. Příklady truefalse | |||
| ID pravidel pro vrácení zboží ReturnPolicyId | Identifikátor pravidel pro vrácení zboží, která se vztahují na konkrétní případ vrácení. | ||
| Popis Tento atribut určuje, která pravidla pro vrácení zboží se na transakci vztahují. Pravidla se mohou lišit podle typu produktu, zákaznického segmentu nebo doby od nákupu. Tento údaj je nezbytný pro dashboard „Přehled dodržování pravidel pro vrácení zboží“. Přiřazením pravidel ke každému případu může systém automaticky ověřit jejich dodržování, například lhůtu pro vrácení nebo požadovaný stav zboží, a označit odchylky k analýze. Proč je to důležité Umožňuje automaticky kontrolovat dodržování obchodních pravidel a pomáhá zajistit, aby se vratky zpracovávaly jednotně a v souladu s nastavenými pravidly. Kde data získat V SAP obvykle nejde o standardní pole. Hodnotu může být potřeba odvodit podle obchodní logiky a údajů, jako je typ produktu, zákazník nebo datum prodeje. Pokud je tato možnost implementována, lze ji ukládat do vlastního pole. Příklady STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Jde o opakovanou práci IsRework | Příznak určující, zda se činnost v rámci případu opakuje. | ||
| Popis Tento vypočítaný logický atribut označuje případy opakované práce, kdy se stejná činnost provede v rámci jednoho případu vícekrát. Může jít například o opakovanou kontrolu položky nebo o vytvoření dobropisu, jeho zrušení a následné opětovné vytvoření. Atribut je nezbytný pro dashboard „Analýza opakované práce při zpracování refundací“ a KPI „Míra opakované práce u refundací“. Pomáhá vyčíslit neefektivitu procesu tím, že upozorňuje na činnosti náchylné k chybám nebo vyžadující více pokusů. Ukazuje tak, kde je potřeba zlepšit kontroly nebo školení. Proč je to důležité Upozorňuje na neefektivitu a chyby v procesu tím, že označuje opakovanou práci. Umožňuje cíleně omezovat plýtvání a zpoždění. Kde data získat Tento příznak obvykle vypočítává samotný nástroj process mining nebo se předem vypočítá při transformaci dat. Ověřuje, zda se stejný název činnosti již dříve objevil v rámci téhož případu. Příklady truefalse | |||
| Je automatizováno IsAutomated | Příznak určující, zda činnost provedl systém, nebo člověk. | ||
| Popis Tento logický atribut rozlišuje činnosti provedené automaticky systémem, například prostřednictvím workflow nebo úlohy na pozadí, od činností, které ručně provedl uživatel. Je nezbytný pro výpočet KPI „Podíl automaticky schválených refundací“ a pro hledání příležitostí k rozšíření automatizace. Filtrováním ručních úkolů se můžete zaměřit na části procesu, kde by automatizace nejvíce přispěla k rychlosti, nákladům a přesnosti. Proč je to důležité Rozlišuje ruční a automatizované úkoly. To je důležité při hledání příležitostí k automatizaci a měření dopadu digitální transformace. Kde data získat Obvykle se odvozuje z uživatelského jména. Pokud je například uživatelem „WF_BATCH“ nebo jiné systémové ID, činnost se označí jako automatizovaná. Příklady truefalse | |||
| Požadovaná částka k vrácení RequestedRefundAmount | Částka, o jejíž vrácení zákazník původně požádal nebo kterou očekával při zahájení procesu. | ||
| Popis Tento atribut zachycuje hodnotu zboží podle původního požadavku na vrácení. Slouží jako základ pro porovnání s konečnou vrácenou částkou. Toto pole je potřeba pro dashboard „Analýza rozdílů v částkách vrácených peněz“. Porovnání požadované a skutečně vrácené částky pomáhá odhalit například částečné vrácení peněz kvůli poškození zboží, poplatkům za opětovné naskladnění nebo jiným úpravám. Zajišťuje tak přesnost a transparentnost finančního vypořádání. Proč je to důležité Slouží jako referenční hodnota pro měření přesnosti refundací a pomáhá odhalit a analyzovat rozdíly mezi očekávanou a skutečnou výší refundace. Kde data získat Obvykle se přebírá z čisté hodnoty položek v původní prodejní objednávce na vrácené zboží. Jde o čistou hodnotu (NETWR) odpovídajících položek v tabulce VBAP. Příklady 125.501050.0049.99 | |||
| Prodejní organizace SalesOrganization | Organizační jednotka odpovědná za původní prodej a vrácení zboží. | ||
| Popis Prodejní organizace je důležitou součástí organizační struktury SAP. Představuje jednotku odpovědnou za prodej a distribuci produktů a služeb a přiřazuje se k transakci vrácení. Tento atribut umožňuje filtrovat a porovnávat proces vrácení napříč různými obchodními jednotkami, regiony nebo divizemi. Pomáhá zjistit, zda mají některé prodejní organizace vyšší míru vrácení nebo méně efektivní postupy, a poskytuje podklad pro analýzu výkonnosti jednotlivých částí organizace. Proč je to důležité Umožňuje porovnat výkonnost a míru vrácení v různých obchodních jednotkách, regionech nebo prodejních kanálech. Kde data získat Nachází se v poli prodejní organizace (VKORG) v tabulce hlaviček vratkových objednávek (VBAK). Příklady 10002100US01 | |||
| Stav objednávky na vrácení zboží ReturnOrderStatus | Aktuální celkový stav případu vrácení zboží. | ||
| Popis Tento atribut uvádí celkový stav případu vrácení zboží v daném okamžiku, například „Otevřeno“, „Probíhá“ nebo „Uzavřeno“. Často jde o souhrnný stav odvozený od posledního dokončeného hlavního milníku. Tento údaj je nezbytný pro dashboard „Aktuální stav případů vrácení zboží“, který poskytuje provozní přehled o aktuální pracovní zátěži a rozložení případů. Vedoucí pracovníci díky němu zjistí, kolik případů se nachází v jednotlivých fázích procesu, a mohou lépe rozdělit zdroje a řídit pracovní zátěž. Proč je to důležité Ukazuje, v jaké fázi procesu se každý případ nachází. Je nezbytný pro provozní dashboardy, které sledují aktuální pracovní zátěž a stav případů. Kde data získat Odvozuje se ze stavových polí příslušných dokumentů. Například ze stavu hlavičky (GBSTK) nebo položky (LFSTK) související prodejní objednávky (VBUK/VBUP) či dodacích dokumentů. Příklady Čeká se na příjem zbožíČeká se na kontroluČeká se na refundaciUzavřeno | |||
| Výsledek kontroly položky ItemInspectionOutcome | Výsledek fyzické kontroly vrácené položky. | ||
| Popis Tento atribut zaznamenává výsledek kontroly provedené po přijetí zboží ve skladu. Mezi běžné výsledky patří „Přijato, lze znovu prodat“, „Zamítnuto, poškozeno“ nebo „Přijato, určeno k dalšímu prodeji“. Tento údaj poskytuje důležitý kontext pro další kroky procesu. Určuje, zda bude vyplacena plná nebo částečná refundace, případně zda nebude vyplacena vůbec. Analýza výsledků pomáhá odhalit příčiny zamítnutí. Pokud se zboží často poškodí při přepravě, může také upozornit na problémy s balením nebo přepravními partnery. Proč je to důležité Objasňuje, na základě čeho se refundace schvalují nebo zamítají. Poskytuje údaje o stavu zboží a důvodech úprav výše refundace. Kde data získat Tyto informace mohou být zaznamenány v kontrolní dávce modulu řízení kvality (QM) nebo jako stavový kód či kód důvodu u položky dodávky vráceného zboží (LIPS). Mohou být také uloženy ve vlastním poli. Příklady Přijato, lze znovu prodatPřijato, určeno k renovaciZamítnuto, poškození způsobené zákazníkemZamítnuto, vrácena nesprávná položka | |||
| Zpracovatel ProcessingAgent | Konkrétní pracovník nebo skupina zdrojů odpovědná za provedení ruční činnosti. | ||
| Popis Tento atribut určuje osobu nebo tým, který provedl daný úkol. Může být konkrétnější než „Uživatelské jméno“, protože označuje roli nebo tým, zejména v prostředí sdílených služeb. Údaj je užitečný pro dashboard „Efektivita schvalování refundací“, který umožňuje porovnávat výkon jednotlivých pracovníků nebo týmů. Pomáhá sledovat rozložení pracovní zátěže, určit potřebu školení a rozpoznat úspěšné pracovníky či týmy, které mohou sdílet osvědčené postupy. Proč je to důležité Umožňuje analyzovat výkon jednotlivých pracovníků a týmů, řídit jejich pracovní zátěž, určit potřebu školení a zvyšovat efektivitu. Kde data získat Tyto informace mohou být dostupné prostřednictvím funkcí SAP Business Partner, pokud jsou pracovníci přiřazeni. Lze je také odvodit z oddělení nebo role uživatele v organizační struktuře HR. Příklady Podpora 1. úrovněTým kontroly ve skladuFinanční oddělení, závazky | |||
Zpracování vrácení zboží a refundací: aktivity
| Aktivita | Popis | ||
|---|---|---|---|
| Dokončení kontroly zboží | Tato činnost představuje dokončení kontroly kvality a stavu vráceného zboží. V rámci Advanced Returns Management jde často o explicitní krok, který zaznamená výsledek kontroly a určí další postup, například vrácení peněz nebo likvidaci. | ||
| Proč je to důležité Délka a výsledek kontroly přímo ovlivňují dobu zpracování vrácení peněz a správu zásob. Tato činnost je důležitá pro analýzu efektivity kontrol a opakovaných oprav. Kde data získat V SAP Advanced Returns Management (ARM) může jít o explicitní událost z transakce kontroly. Lze ji také odvodit ze změny stavu položky vratkové objednávky, která označuje výsledek kontroly. Zachycení Událost se zaznamená z protokolů transakcí nebo změn stavů souvisejících s navazujícími logistickými činnostmi v ARM. Typ události explicit | |||
| Příjem zboží ve skladu | Tato událost označuje fyzické přijetí vráceného zboží ve skladu nebo zpracovatelském centru. Zaznamená se explicitně při zaúčtování příjmu zboží (PGR) k vratkové dodávce, které vytvoří materiálový doklad. | ||
| Proč je to důležité Jde o důležitý milník, od kterého se počítá doba kontroly a rozhodování o dalším postupu. Prodlevy před tímto bodem způsobuje zákazník, zatímco prodlevy po něm vznikají uvnitř organizace. Kde data získat Událost se zaznamená z tabulek materiálových dokladů MSEG a MKPF pro druh pohybu příjmu zboží spojený s vrácením. Čas události určuje datum zaúčtování (MKPF-BUDAT). Zachycení Událost odpovídá zaúčtování příjmu zboží k vratkové dodávce. Typ události explicit | |||
| Uzavření případu vrácení | Jde o závěrečnou činnost, která označuje dokončení procesu vrácení a potvrzuje, že se u případu neočekávají žádné další kroky. Obvykle se odvozuje od dosažení konečného stavu uzavření vratkového dokladu v systému. | ||
| Proč je to důležité Tato událost označuje konec životního cyklu procesu, a umožňuje tak vypočítat celkovou dobu vyřízení. Potvrzuje, že byl případ zcela vyřešen. Kde data získat Událost se odvozuje od dosažení stavu „Dokončeno“ nebo „Uzavřeno“ u celkového stavu vratkové objednávky v tabulce VBAK nebo jejích položek v tabulce VBAP. Výsledek závisí na konfiguraci správy stavů v systému. Zachycení Událost se odvozuje od změny stavu vratkového dokladu na „Dokončeno“. Typ události inferred | |||
| Vrácení peněz zpracováno | Tato činnost označuje závěrečný krok procesu vrácení peněz. Finanční dobropis je vyrovnán, což znamená, že platba byla odeslána zákazníkovi. Událost se odvozuje od vytvoření vyrovnávacího dokladu ve finančním modulu, který vyrovná otevřenou pohledávku na zákaznickém účtu. | ||
| Proč je to důležité V tomto okamžiku zákazník skutečně obdrží peníze. Doba od zahájení vrácení do tohoto kroku výrazně ovlivňuje spokojenost zákazníků a je důležitá pro měření dodržování SLA. Kde data získat Událost se odvozuje z údajů o vyrovnání v tabulce položek finančního účetnictví BSEG. Datum vyrovnání (BSEG-AUGDT) u zákaznické položky propojené s dobropisem určuje, kdy byly peníze vráceny. Zachycení Událost se odvozuje od vyplněného pole data vyrovnání u účetního dokladu spojeného s dobropisem. Typ události inferred | |||
| Vytvoření dobropisu | Jde o vytvoření oficiálního fakturačního dokladu, kterým se zákazníkovi připíše částka za vrácené zboží. Událost se zaznamená explicitně při vystavení dobropisu na základě žádosti o dobropis. | ||
| Proč je to důležité Vytvoření dobropisu je důležitým finančním milníkem. Potvrzuje částku, která se má vrátit, a umožňuje zahájit proces platby. Kde data získat Událost se zaznamená při vytvoření fakturačního dokladu v tabulce VBRK s kategorií dokladu označující dobropis. S žádostí o dobropis je propojen v tabulce VBFA. Zachycení Událost se zaznamená při uložení nového fakturačního dokladu dobropisu (například pomocí transakce VF01). Typ události explicit | |||
| Vytvoření žádosti o dobropis | Po úspěšné kontrole tato činnost označuje vytvoření žádosti o připsání částky zákazníkovi. Zaznamená se jako nový prodejní doklad, tedy žádost o dobropis, která odkazuje na původní vratkovou objednávku. | ||
| Proč je to důležité Tento krok zahajuje finanční vypořádání vrácení. Analýza doby od kontroly po tento krok ukazuje, jak efektivně se předávají případy z logistiky do finančního oddělení. Kde data získat Událost se zaznamená při vytvoření prodejního dokladu v tabulce VBAK s kategorií dokladu žádost o dobropis. Propojení s vrácením je vedeno v tabulce toku dokladů VBFA. Zachycení Událost se zaznamená při uložení nové žádosti o dobropis. Typ události explicit | |||
| Zahájení požadavku na vrácení | Tímto krokem začíná proces vrácení zboží. V systému se formálně vytvoří vratková objednávka. Událost se zaznamená při uložení nového prodejního dokladu typu vratková objednávka v SAP S/4HANA. | ||
| Proč je to důležité Tato činnost označuje oficiální začátek životního cyklu případu vrácení. Analýza doby od této události do uzavření je důležitá pro měření celkové doby vyřízení i zákaznické zkušenosti. Kde data získat Jde o explicitní událost zaznamenanou při vytvoření prodejního dokladu v tabulce VBAK, kde kategorie dokladu (VBAK-VBTYP) označuje vratkovou objednávku. Čas vytvoření je uveden v poli VBAK-ERDAT. Zachycení Událost se zaznamená při uložení nové vratkové objednávky (například pomocí transakce VA01). Typ události explicit | |||
| Schválení vratkové objednávky | Tato činnost představuje formální schválení nebo uvolnění vratkové objednávky, která pak může pokračovat do další fáze. Obvykle se odvozuje ze změny stavu hlavičky nebo položky prodejního dokladu, která značí uvolnění případné blokace. | ||
| Proč je to důležité Schvalování může být významným zdrojem prodlev. Sledováním této činnosti odhalíte úzká místa v počáteční fázi schvalování vrácení. Kde data získat Událost se odvozuje z tabulek správy stavů nebo z polí stavu přímo v tabulkách VBAK či VBAP. Schválení může značit změna stavu uvolnění nebo odstranění blokace dodávky (VBAP-LIFSP). Zachycení Událost se odvozuje ze změny stavových polí hlavičky nebo položky vratkové objednávky, která značí uvolnění či schválení. Typ události inferred | |||
| Vytvoření objednávky na výměnu | Tato činnost představuje alternativní řešení, kdy se místo vrácení peněz vytvoří nová prodejní objednávka na zaslání náhradního zboží zákazníkovi. Událost se zaznamená při vytvoření nové prodejní objednávky s odkazem na původní vrácení. | ||
| Proč je to důležité Tato činnost umožňuje rozlišit vrácení zboží s vrácením peněz od výměny zboží. Tyto případy mají odlišný průběh i výsledek pro zákazníka. Rozlišení je důležité pro analýzu variant procesu. Kde data získat Událost se zaznamená při vytvoření nového prodejního dokladu v tabulce VBAK, který je propojen s vratkovou objednávkou v tabulce toku dokladů VBFA. Zachycení Událost se zaznamená při uložení nové prodejní objednávky určené jako náhrada. Typ události explicit | |||
| Vytvoření účetního dokladu | K této události dojde, když se dobropis úspěšně zaúčtuje ve finančním účetnictví. V hlavní knize se vytvoří odpovídající zápisy a dobropis se stane oficiálním z účetního hlediska. | ||
| Proč je to důležité Tato činnost potvrzuje, že byl dobropis zaevidován ve finančním systému. Doba mezi vytvořením dobropisu a jeho zaúčtováním může odhalit problémy na rozhraní mezi fakturací a finančním oddělením. Kde data získat Událost se zaznamená při vytvoření hlavičky dokladu v účetní tabulce BKPF, která je propojena s dobropisem v tabulce VBRK (VBRK-BELNR). Zachycení Událost se zaznamená po úspěšném zaúčtování fakturačního dokladu ve finančním účetnictví. Typ události explicit | |||
| Vytvoření vratkové dodávky | Tato činnost označuje vytvoření příchozího dodacího dokladu, který slouží k evidenci fyzického příjmu vráceného zboží. Systém ji zaznamená jako explicitní událost při vytvoření dodacího dokladu s odkazem na vratkovou objednávku. | ||
| Proč je to důležité Jde o důležitý logistický milník. Doba mezi schválením vrácení a vytvořením dodávky ukazuje, jak efektivně se informace o vrácení předávají skladu nebo příjmovému oddělení. Kde data získat Událost se zaznamená při vytvoření hlavičky dodávky v tabulce LIKP. S předchozí vratkovou objednávkou ji propojuje tabulka toku dokladů VBFA. Zachycení Událost se zaznamená při uložení nového dokladu vratkové dodávky (například pomocí transakce VL01N). Typ události explicit | |||
| Zamítnutí vrácení | Označuje, že vrácené zboží nesplňuje podmínky pro vrácení a žádost o vrácení peněz nebo dobropis byla zamítnuta. Obvykle se zaznamená přiřazením konkrétního stavu nebo kódu důvodu k položce vratkové objednávky po kontrole. | ||
| Proč je to důležité Sledování zamítnutých případů pomáhá analyzovat dodržování pravidel pro vracení zboží a odhalit časté důvody zamítnutí. Jde o důležitou výjimečnou větev procesu. Kde data získat Událost se odvozuje od vyplnění důvodu zamítnutí (VBAP-ABGRU) u položky vratkové objednávky nebo od přiřazení konkrétního stavu během kontroly v Advanced Returns Management. Zachycení Událost se odvozuje od vyplnění důvodu zamítnutí nebo přiřazení konkrétního stavu „zamítnuto“ k položce vratkového dokladu. Typ události inferred | |||
Návody na extrakci dat
Kroky
- Ověření předpokladů: Ověřte, že uživatelský účet použitý k extrakci má v SAP S/4HANA potřebná oprávnění pro přístup k požadovaným CDS View (Core Data Services). Mezi důležitá view patří I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry a I_ClearedItem.
- Otevření nástroje pro dotazy: Přihlaste se do preferovaného SQL klienta nebo nástroje pro integraci dat, který je připojený k databázi SAP S/4HANA. Může jít například o nástroje SAP, jako je SAP Analytics Cloud, nebo o platformu ETL třetí strany.
- Nastavení parametrů dotazu: Před spuštěním upravte dodaný SQL dotaz. Najděte zástupné hodnoty a nahraďte je správnými parametry pro vaše prostředí. Nastavte například
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]a filtry pro další typy dokladů nebo kódy společností. - Spuštění extrakčního dotazu: Zkopírujte celý SQL dotaz a spusťte ho ve svém nástroji. Dotaz shromáždí všechny určené aktivity do jedné datové sady spojením výsledků několika příkazů SELECT.
- Porozumění logice dotazu: Každý blok
SELECTve struktuřeUNION ALLextrahuje jednu konkrétní aktivitu. Propojuje několik CDS View, aby získal potřebné atributy, přiřadí pevný řetězec do poleActivityNamea vybere odpovídající časové razítko proEventTime. - Kontrola nezpracovaných dat: Po dokončení dotazu stručně zkontrolujte výstup. Ověřte, že počet řádků odpovídá očekávání a že jsou vyplněné důležité sloupce, například
ReturnCaseId,ActivityNameaEventTime. - Transformace dat: Dotaz vytváří záznam událostí v plochém formátu. Obvykle nejsou potřeba žádné zásadní změny struktury. Podle požadavků cílového systému však může být nutné upravit formát časových razítek nebo datové typy.
- Export záznamu událostí: Exportujte výsledek dotazu do souboru CSV. Použijte kódování UTF-8, aby nedošlo k problémům se znaky, zejména v uživatelských jménech a popisech produktů.
- Nahrání do nástroje pro process mining: Výsledný soubor CSV můžete nahrát do platformy pro process mining, například ProcessMind. Namapujte sloupce ze souboru na odpovídající pole v nástroji, například
ReturnCaseIdna ID případu,ActivityNamena aktivitu aEventTimena časové razítko.
Konfigurace
- Předpoklady: Uživatel, který extrakci spouští, potřebuje oprávnění k zobrazení objektů souvisejících s prodejními doklady (VBAK), dodávkami (LIKP), fakturací (VBRK) a účetnictvím (BSEG, BKPF). Nezbytný je také přístup k podkladovým CDS View.
- Filtry rozsahu dat: Dotaz je nutné filtrovat podle konkrétních typů dokladů, aby zahrnoval pouze proces vrácení zboží. Nastavte zástupné hodnoty pro typy objednávek na vrácení (například 'RE'), typy požadavků na dobropis (například 'G2') a typy objednávek na výměnu (například 'SO'). Rozsah dat doporučujeme omezit také pomocí
CompanyCodeneboSalesOrganization. - Filtr časového období: Kvůli výkonu a objemu dat vždy použijte filtr časového období. Začněte daty za poslední 3 až 6 měsíců. Dotaz jako hlavní podmínku filtru používá datum vytvoření původní objednávky na vrácení (
I_SalesDocument.CreationDate). - Dopad na výkon: Tento rozsáhlý dotaz propojuje několik velkých CDS View. Jeho spuštění může výrazně zatížit zdrojový systém S/4HANA. Extrakci naplánujte mimo špičku, abyste omezili dopad na provoz. U velmi rozsáhlých datových sad zvažte postupné načítání.
Ukázkový dotaz 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' Kroky
- Ověřte, že máte přímý přístup pro čtení schématu SAP HANA s příslušnými daty o prodeji, dodávkách, fakturaci, materiálových dokladech, kontrolách, stavech a účetnictví. Konkrétní schéma, view a názvy polí se liší podle nasazení SAP S/4HANA. Každý zástupný text v hranatých závorkách proto nahraďte objekty a poli nastavenými ve vašem systému.
- Rozsah extrakce určete pomocí parametrů [Start date], [End date], [Company Code filter] a [Return document type filter]. Při první extrakci použijte průběžné období tří až šesti měsíců. Prodlužte je až po ověření výkonu a úplnosti dat.
- Seznam objednávek na vrácení vytvořte z [Your sales document header table] a [Your sales document item table]. Omezte jej na typy dokladů objednávek na vrácení nastavené v [Your return order document type configuration]. Číslo objednávky na vrácení a číslo položky zachovejte jako hlavní vazbu na navazující doklady.
- Pomocí [Your document flow table or view] určete tok dokladů od objednávek na vrácení k příchozím dodávkám vráceného zboží, požadavkům na dobropis, objednávkám na výměnu a dobropisům. Nepředpokládejte, že je tok dokladů uložený v VBAK nebo VBAP. Pole vztahů nastavte podle modelu toku dokladů používaného v systému.
- Události vytvoření extrahujte přímo z příslušných záznamů hlaviček a položek dokladů. Události schválení, zamítnutí, kontroly, uzavření, příjmu zboží, zaúčtování a vyrovnání extrahujte z nastavených zdrojů stavů, kontrol, materiálových dokladů, účetnictví a vyrovnání. Každou aktivitu uložte jako samostatný řádek události, protože ProcessMind události neodvozuje.
- Sjednoťte časová razítka na konzistentní databázový typ a časové pásmo. Pro každou aktivitu použijte nastavené pořadí přednosti časových razítek. Pokud je k dispozici pouze datum a čas, spojte je pomocí časového pásma systému nastaveného v [Your system time zone].
- Vyplňte
ReturnCaseIdu každé události. Použijte číslo původní objednávky na vrácení, případně nastavený identifikátor případu vrácení, pokud Advanced Returns Management ukládá samostatný klíč případu. Události, které nelze přiřadit k případu vrácení, vyřaďte nebo je uložte do výstupu výjimek k nápravě. - Vyplňte povinné sloupce
ReturnCaseId,ActivityName,EventTime,SourceSystemIdaLastDataUpdateTimestamp. Pokud jsou k dispozici, doplňte také doporučené sloupce, napříkladEventEndTime,UserName,ReturnReason,RefundAmount,ProductIdaCustomerId. Každý výskyt aktivity uložte do samostatného řádku a neslučujte aktivity do jednoho řádku případu. - Výsledek ověřte podle kontrol uvedených v validationSteps. Potvrďte, že jsou zastoupeny všechny názvy dvanácti aktivit, časová razítka jsou v každém případu v logickém pořadí a odkazy na doklady odpovídají zdrojovým tabulkám.
- Výsledek exportujte jako soubor CSV v kódování UTF-8 nebo v jiném tabulkovém formátu podporovaném ProcessMind. Zachovejte přesné názvy sloupců, použijte jeden řádek záhlaví, časová razítka uložte v jednoznačném formátu ISO a při nahrávání nastavte
ReturnCaseIdjako identifikátor případu aActivityNamejako sloupec aktivity.
Konfigurace
- Časové období: Začněte obdobím tří až šesti měsíců. Použijte parametry [Start date] a [End date] a zahrňte dostatečnou historii, aby se zachytily případy zahájené před vybraným obdobím, ale dokončené během něj.
- Výběr vráceného zboží: Filtrujte podle typů dokladů objednávek na vrácení nastavených v [Your return order document type configuration]. Typ dokladu nezadávejte napevno, dokud jeho platnost v cílovém systému neověříte.
- Organizační filtry: Filtry [Company Code filter], prodejní organizace, distribučního kanálu, divize, závodu nebo zákazníka použijte pouze v případě potřeby. Ověřte, že nevyloučí navazující doklady mezi společnostmi nebo v rámci jedné společnosti.
- Zdrojové objekty: Nahraďte zástupné texty [Your table name] a [Your view name] schválenými tabulkami nebo CDS View SAP S/4HANA. V daném nasazení mohou být dostupné VBAK, VBAP, VBRK a VBRP, jejich použití a rozšíření je však nutné před spuštěním ověřit.
- Práce s časovými razítky: Pro každou aktivitu nastavte zdrojová pole časových razítek a časové pásmo. Hodnoty
EventTimeaEventEndTimeukládejte jednotně, nejlépe v UTC nebo v dohodnutém časovém pásmu ProcessMind. - Interpretace stavů: Nastavte přesné hodnoty stavů, kódy důvodů, výsledky kontrol a indikátory uzavření, které v systému odpovídají schválení, zamítnutí, dokončení kontroly a uzavření případu.
- Identifikátor zdrojového systému: Nahraďte [Source system identifier] stabilní hodnotou, například identifikátorem systému SAP používaným platformou pro extrakci.
- Časové razítko obnovení: Nahraďte [Extraction timestamp] časovým razítkem začátku běhu dotazu nebo vytvoření snímku zdroje. Pokud nejsou potřeba časová razítka pro jednotlivé řádky, použijte stejnou hodnotu pro všechny řádky jednoho běhu extrakce.
- Výkon: Před propojením s rozsáhlými zdroji toku dokladů, účetnictví, materiálových dokladů a stavů omezte počáteční výběr objednávek na vrácení. Používejte indexovaná pole nebo pole umožňující omezení čtení oddílů, vyhněte se neomezenému procházení tabulek a mezivýsledky ukládejte pouze se souhlasem správce databáze.
- Postupná extrakce: Při pravidelných bězích použijte [Last successful extraction timestamp] a řízené překryvné období, abyste zachytili pozdější aktualizace. Duplicitní záznamy odstraňujte podle
ReturnCaseId,ActivityName, klíče zdrojového dokladu aEventTime. - Oprávnění a předpoklady: Získejte oprávnění ke čtení všech nastavených zdrojových objektů a polí, schválení přímého přístupu k databázi a potvrzení, že jsou aktivní potřebné komponenty SAP a funkce Advanced Returns Management, pokud se používají.
- Ochrana dat: Omezte zákaznická a finanční pole na nezbytné minimum, dodržujte interní pravidla ochrany soukromí a zabezpečte exportované soubory.
Ukázkový dotaz 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; Můžete začít?
Tato šablona vám poskytne základní informace potřebné k extrakci a analýze dat o zpracování vrácení zboží a refundací. Začněte zlepšovat své procesy ještě dnes.
Zlepšete zpracování vrácení zboží a refundací v SAP S/4HANA
Odhalte neefektivní postupy, zkraťte dobu průchodu procesem o 30 % a zvyšte spokojenost.
Platební kartu nepotřebujete. Začněte zlepšovat procesy ještě dnes.