Szablon danych do analizy obsługi zwrotów i zwrotów środków
Szablon danych do analizy obsługi zwrotów i zwrotów środków
- Zalecane atrybuty do zebrania
- Czynności do śledzenia
- Wskazówki dotyczące ekstrakcji danych
Obsługa zwrotów i refundacji: atrybuty
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność. | ||
| Opis Czas zdarzenia określa datę i godzinę zarejestrowania zdarzenia biznesowego w systemie. Ten znacznik czasu pozwala uporządkować czynności chronologicznie i stanowi podstawę analiz opartych na czasie. W process mining służy do obliczania czasu między czynnościami, mierzenia czasu trwania poszczególnych etapów i analizy wyników procesu w czasie. Na tej podstawie można wykrywać wąskie gardła, monitorować dotrzymanie SLA i analizować przebieg procesu zwrotu w czasie. Dlaczego to ważne Ten znacznik czasu pozwala uporządkować zdarzenia, obliczać czas trwania i czas obsługi oraz wykrywać opóźnienia w procesie. Skąd pobrać Dane pochodzą zwykle z pól daty i godziny związanych z utworzeniem dokumentu lub zmianą statusu, takich jak ERDAT (data utworzenia) i ERZET (godzina utworzenia) w tabelach VBAK, LIKP i BKPF albo data księgowania (BUDAT) w dokumentach księgowych. Przykłady 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Identyfikator sprawy zwrotu ReturnCaseId | Unikalny identyfikator pojedynczej sprawy zwrotu klienta, który łączy wszystkie powiązane czynności od rozpoczęcia do zamknięcia. | ||
| Opis Identyfikator sprawy zwrotu to główny identyfikator, który grupuje wszystkie zdarzenia i czynności dotyczące jednego zwrotu. Każde zgłoszenie zwrotu otrzymuje unikalny identyfikator, dzięki czemu można śledzić cały proces od początku do końca. W process mining ten atrybut jest podstawą odtworzenia przebiegu procesu. Łączy różne zdarzenia, takie jak „Zgłoszenie zwrotu”, „Przyjęcie towaru” i „Realizacja zwrotu pieniędzy”, w spójną oś czasu dla każdej sprawy. Umożliwia analizę czasu obsługi, wariantów procesu i wąskich gardeł. Dlaczego to ważne To podstawowy identyfikator, który pozwala śledzić zwrot od początku do końca i prowadzić analizy na poziomie sprawy, w tym mierzyć czas obsługi i wykrywać warianty procesu. Skąd pobrać Zwykle jest to numer dokumentu sprzedaży (VBELN) z tabeli nagłówka zlecenia zwrotu VBAK, gdzie kategoria dokumentu (VBTYP) wskazuje na zwrot. Przykłady 600001896000019060000191 | |||
| Nazwa czynności ActivityName | Nazwa konkretnej czynności biznesowej lub zdarzenia, które wystąpiło w procesie zwrotu i zwrotu pieniędzy. | ||
| Opis Ten atrybut opisuje pojedynczy etap lub ważny moment w cyklu obsługi zwrotu. Czynności pokazują, jakie prace są wykonywane, na przykład „Zatwierdzenie zlecenia zwrotu” lub „Zakończenie kontroli produktu”. Są ustalane na podstawie zmian statusu, utworzenia dokumentów lub konkretnych działań użytkowników zarejestrowanych w SAP S/4HANA. Analiza kolejności i częstotliwości tych czynności stanowi podstawę process mining. Pozwala przedstawić mapę procesu, wykryć częste i rzadkie ścieżki oraz wskazać czynności często powtarzane, które mogą oznaczać poprawki lub nieefektywność. Dlaczego to ważne Czynności tworzą podstawę mapy procesu, która pozwala przedstawić i analizować jego przebieg, wąskie gardła oraz różnice między wariantami. Skąd pobrać Nazwy czynności są zwykle ustalane na podstawie różnych danych, takich jak zmiany statusu dokumentów w tabelach VBUK/VBUP, zdarzenia utworzenia dokumentów w tabelach nagłówków, takich jak VBAK (dokumenty sprzedaży) i BKPF (dokumenty księgowe), oraz statusy ruchów towarów w MSEG. Przykłady Zgłoszenie zwrotuPrzyjęcie towaru w magazynieUtworzenie noty uznaniowejRealizacja zwrotu pieniędzy | |||
| Identyfikator systemu źródłowego SourceSystemId | Identyfikator systemu źródłowego, z którego pobrano dane. | ||
| Opis Ten atrybut wskazuje system, w którym pierwotnie zarejestrowano dane o zdarzeniu. W tym procesie będzie to zwykle identyfikator instancji SAP S/4HANA. W środowiskach z wieloma systemami pole to ma znaczenie dla śledzenia pochodzenia danych, rozwiązywania problemów i zapewnienia ich integralności. Pozwala rozróżnić dane, gdy zwroty są obsługiwane w różnych instancjach ERP lub zintegrowane z systemami zewnętrznymi, na przykład systemem zarządzania magazynem. Dlaczego to ważne Dostarcza informacji o pochodzeniu i przepływie danych, szczególnie w środowiskach z wieloma systemami, co ułatwia ich śledzenie i weryfikację. Skąd pobrać Ta wartość jest zwykle stała i konfigurowana podczas pobierania danych. Można ją odczytać z informacji administracyjnych systemu SAP, na przykład z identyfikatora systemu (SID). Przykłady S4H_PROD_100S4Q_DEV_200 | |||
| Ostatnia aktualizacja danych LastDataUpdateTimestamp | Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone lub pobrane. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych. Informuje, jak aktualny jest analizowany zbiór danych. Pozwala ocenić aktualność analizy process mining. Użytkownicy mogą sprawdzić, jak świeże są dane, co ma szczególne znaczenie przy monitorowaniu operacyjnym i dashboardach śledzących bieżące sprawy. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu można sprawdzić, czy analizy i dashboardy opierają się na najnowszych informacjach. Skąd pobrać Znacznik jest zwykle generowany i zapisywany w zbiorze danych podczas ich pobierania przez narzędzie ETL lub potok danych. Przykłady 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Czas zakończenia zdarzenia EventEndTime | Znacznik czasu wskazujący zakończenie czynności, używany do obliczania czasu jej trwania. | ||
| Opis StartTime (EventTime) oznacza początek czynności, a EventEndTime jej zakończenie. W przypadku wielu zdarzeń generowanych przez system czas rozpoczęcia i zakończenia jest taki sam, ponieważ zdarzenie następuje w jednej chwili. Ten atrybut ma jednak zasadnicze znaczenie dla czynności o mierzalnym czasie trwania, takich jak „Kontrola produktu”. Pozwala bezpośrednio obliczyć czas realizacji czynności. Jest to podstawa analizy wyników, która pomaga wskazać konkretne etapy, a nie tylko przerwy między nimi, pochłaniające najwięcej czasu. Dlaczego to ważne Pozwala dokładnie obliczyć czas trwania poszczególnych czynności i wskazać nieefektywność na konkretnych etapach procesu. Skąd pobrać Wartość jest często wyliczana. Dla niektórych czynności może pochodzić z osobnego pola. Częściej jest to StartTime kolejnej czynności w danej sprawie. Przykłady 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Identyfikator klienta CustomerId | Unikalny identyfikator klienta zgłaszającego zwrot. | ||
| Opis Ten atrybut wskazuje klienta, który zgłosił zwrot. Łączy daną sprawę z konkretnym podmiotem w głównych danych klientów. Analiza zwrotów według klientów pomaga wykrywać wzorce, na przykład nietypowo wysoki odsetek zwrotów, który może wskazywać na nadużycia lub niezadowolenie. Umożliwia też podział procesu według rodzaju, wartości lub historii klienta, co pozwala dostosować poziom obsługi. Dlaczego to ważne Łączy zwroty z konkretnymi klientami, umożliwiając analizę ich zachowań, segmentację i wykrywanie osób często zwracających produkty. Skąd pobrać Numer klienta (KUNNR) znajduje się w tabeli nagłówka zlecenia zwrotu (VBAK). Przykłady CUST-001234CUST-005678CUST-009012 | |||
| Identyfikator produktu ProductId | Unikalny identyfikator zwracanego produktu. | ||
| Opis Ten atrybut wskazuje materiał lub produkt, którego dotyczy zwrot. Łączy proces zwrotu z konkretną pozycją w katalogu produktów. Analiza zwrotów według produktu pomaga wykrywać pozycje o wysokim odsetku zwrotów, co może wskazywać na wady jakościowe, nieprecyzyjne opisy lub problemy produkcyjne. Dane te ułatwiają podejmowanie decyzji dotyczących projektu produktów, zarządzania dostawcami i strategii zapasów. Dlaczego to ważne Łączy proces zwrotu z konkretnymi produktami, co pozwala analizować odsetek zwrotów dla poszczególnych pozycji i wykrywać problemy z jakością lub opisem. Skąd pobrać Numer materiału (MATNR) znajduje się w tabeli pozycji zlecenia zwrotu (VBAP) lub tabeli pozycji dostawy zwrotnej (LIPS). Przykłady FG-10023HW-45981SW-LICENSE-PREM | |||
| Kwota zwrotu pieniędzy RefundAmount | Ostateczna kwota wypłacona klientowi w ramach zwrotu. | ||
| Opis Ten atrybut określa kwotę faktycznie uznaną lub zwróconą klientowi po zakończeniu procesu zwrotu. Jest zapisywana w dokumentach finansowych, takich jak noty uznaniowe. To ważny wskaźnik finansowy wykorzystywany w różnych analizach. Jest niezbędny na dashboardzie „Analiza rozbieżności kwot zwrotów”, gdzie porównuje się go z kwotą wnioskowaną. Pozwala też grupować zwroty według wartości i sprawdzać, czy obsługa spraw o wysokiej wartości przebiega inaczej lub trwa dłużej. Dlaczego to ważne Pokazuje finansowy wpływ zwrotów i pomaga analizować poprawność wypłat, wykrywać sprawy o wysokiej wartości oraz oceniać łączne koszty. Skąd pobrać Dane pochodzą z pola wartości netto (NETWR) dokumentu noty uznaniowej, dostępnego w tabelach takich jak VBRK (nagłówek dokumentu rozliczeniowego) lub BSEG (pozycja dokumentu księgowego). Przykłady 125.50999.0049.99 | |||
| Nazwa użytkownika UserName | Identyfikator użytkownika, który wykonał daną czynność. | ||
| Opis Ten atrybut wskazuje użytkownika lub agenta systemowego odpowiedzialnego za wykonanie zadania, na przykład zatwierdzenie zwrotu lub utworzenie noty uznaniowej. W SAP informacja ta jest często zapisywana w polach wskazujących użytkownika, który utworzył lub zmienił dokument. Analiza według użytkownika pomaga wykrywać osoby i zespoły osiągające dobre wyniki, określać potrzeby szkoleniowe i oceniać rozkład obciążenia pracą. Ułatwia też badanie odstępstw, ponieważ łączy działania w procesie z konkretnymi osobami, wspierając zgodność i audyt. Dlaczego to ważne Przypisuje czynności w procesie do konkretnych użytkowników, co pozwala analizować wyniki zespołów, obciążenie pracą i zgodność. Skąd pobrać Dane te są zwykle dostępne w tabelach nagłówków dokumentów, na przykład w polu ERNAM (utworzył) w tabelach VBAK (zlecenia sprzedaży), LIKP (dostawy) i BKPF (dokumenty księgowe). Informacje o użytkownikach można uzupełnić danymi z tabeli głównej użytkowników USR21. Przykłady CBROWNASMITHWF_BATCH | |||
| Przyczyna zwrotu ReturnReason | Powód zwrotu produktu podany przez klienta. | ||
| Opis Ten atrybut zapisuje podaną przez klienta przyczynę zwrotu, na przykład „Produkt wadliwy”, „Niewłaściwy rozmiar” lub „Produkt nie jest już potrzebny”. Zwykle podczas zgłaszania zwrotu wybiera się ją z predefiniowanej listy kodów przyczyn. Analiza przyczyn zwrotów pomaga wykrywać problemy z jakością produktów, poprawiać ich opisy i usprawniać sprzedaż. Pokazuje, co powoduje niezadowolenie klientów, i ułatwia ustalenie, które obszary warto poprawić, aby ograniczyć liczbę zwrotów. Dlaczego to ważne Pokazuje, dlaczego klienci zwracają produkty, i ułatwia analizę przyczyn problemów z jakością, błędów realizacji zamówień lub rozbieżności między oczekiwaniami a produktem. Skąd pobrać Dane są zwykle przechowywane w tabeli pozycji zlecenia sprzedaży dotyczącego zwrotu (VBAP), w polu ABGRU (przyczyna odrzucenia dokumentu sprzedaży). Przykłady 001 - Niska jakość002 - Uszkodzenie w transporcie005 - Wysłano niewłaściwy produkt | |||
| Czy czynność jest zautomatyzowana IsAutomated | Wskaźnik określający, czy czynność wykonał system, czy człowiek. | ||
| Opis Ten atrybut logiczny odróżnia czynności wykonywane automatycznie przez system, na przykład w ramach workflow lub zadania w tle, od czynności wykonywanych ręcznie przez użytkownika. Jest niezbędny do obliczania KPI „Odsetek automatycznie zatwierdzonych zwrotów” i wskazywania możliwości zwiększenia automatyzacji. Filtrowanie zadań ręcznych pozwala skupić działania na ulepszaniu procesów tam, gdzie automatyzacja może najbardziej skrócić czas, obniżyć koszty i poprawić dokładność. Dlaczego to ważne Pozwala odróżnić zadania ręczne od zautomatyzowanych. Jest to istotne przy wskazywaniu możliwości automatyzacji i pomiarze efektów transformacji cyfrowej. Skąd pobrać Wartość zwykle ustala się na podstawie nazwy użytkownika. Na przykład jeśli użytkownikiem jest „WF_BATCH” lub inne konto systemowe, czynność oznacza się jako zautomatyzowaną. Przykłady truefalse | |||
| Czy wystąpiła ponowna praca IsRework | Wskaźnik określający, czy czynność w danej sprawie jest powtórzeniem wcześniejszej czynności. | ||
| Opis Ten wyliczany atrybut logiczny wskazuje przypadki ponownej pracy, gdy tę samą czynność wykonano więcej niż raz w ramach jednej sprawy. Może to być na przykład ponowna kontrola produktu albo utworzenie noty kredytowej, jej anulowanie i ponowne utworzenie. Atrybut ten jest niezbędny do dashboardu „Analiza ponownej pracy przy obsłudze zwrotów” i KPI „Odsetek spraw wymagających ponownej pracy”. Pomaga mierzyć nieefektywność procesu, wskazując czynności podatne na błędy lub wymagające kilku prób. Dzięki temu można określić, gdzie potrzebne są lepsze mechanizmy kontroli lub szkolenia. Dlaczego to ważne Wskazuje nieefektywność i błędy w procesie, oznaczając powtarzane czynności. Ułatwia to kierowanie działań naprawczych na ograniczenie strat i opóźnień. Skąd pobrać Wskaźnik ten zwykle wylicza samo narzędzie process mining. Można go też obliczyć wcześniej podczas transformacji danych. Sprawdza, czy ta sama nazwa czynności pojawiła się już wcześniej w tej samej sprawie. Przykłady truefalse | |||
| Docelowa data zwrotu środków według SLA RefundSlaTargetDate | Termin, do którego należy przetworzyć zwrot środków w danej sprawie. | ||
| Opis Ten atrybut określa termin przetworzenia zwrotu środków wynikający z umowy o gwarantowanym poziomie świadczenia usług (SLA). Datę zwykle wylicza się na podstawie reguł biznesowych, na przykład jako określoną liczbę dni od zatwierdzenia zwrotu lub otrzymania towaru. Pole to stanowi podstawę dashboardu „Monitorowanie realizacji SLA dla zwrotów” i powiązanego z nim KPI. Umożliwia bieżące śledzenie spraw zagrożonych przekroczeniem terminu SLA oraz analizę przyczyn opóźnień, co pomaga poprawiać satysfakcję klientów. Dlaczego to ważne Stanowi punkt odniesienia przy pomiarze realizacji SLA. Pomaga monitorować wyniki, ustalać priorytety dla długo otwartych spraw i poprawiać satysfakcję klientów. Skąd pobrać Prawie zawsze jest to pole wyliczane. Wartość ustala się na podstawie daty bazowej, na przykład daty utworzenia zgłoszenia zwrotu, i okresu określonego w regułach biznesowych. Okres może zależeć między innymi od rodzaju klienta lub przyczyny zwrotu. Przykłady 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Identyfikator polityki zwrotów ReturnPolicyId | Identyfikator polityki zwrotów obowiązującej w danej sprawie zwrotu. | ||
| Opis Ten atrybut wskazuje, która polityka zwrotów lub który zestaw zasad ma zastosowanie do transakcji. Zasady mogą się różnić w zależności od rodzaju produktu, segmentu klienta lub czasu, jaki upłynął od zakupu. Dane te są niezbędne do przygotowania dashboardu „Przegląd zgodności z polityką zwrotów”. Przypisanie polityki do każdej sprawy pozwala systemowi automatycznie sprawdzać przestrzeganie zasad, takich jak terminy zwrotu czy wymagany stan produktu, oraz oznaczać odstępstwa do analizy. Dlaczego to ważne Umożliwia automatyczne sprawdzanie zgodności z regułami biznesowymi, co pomaga zapewnić spójne przetwarzanie zwrotów zgodnie z obowiązującą polityką. Skąd pobrać Często nie jest to standardowe pole SAP. Może być konieczne wyliczenie jego wartości na podstawie reguł biznesowych i danych, takich jak rodzaj produktu, klient czy data sprzedaży. Jeśli zostało to wdrożone, wartość może być przechowywana w polu niestandardowym. Przykłady STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Numer dostawy zwrotnej ReturnDeliveryNumber | Unikalny identyfikator dokumentu dostawy zwrotnej. | ||
| Opis Gdy klient fizycznie zwraca towar, w SAP tworzy się dokument dostawy zwrotnej, który służy do obsługi logistyki przychodzącej. Ten atrybut zawiera unikalny numer tego dokumentu. Identyfikator pozwala śledzić fizyczny przepływ zwracanego towaru. Łączy finansową i logistyczną część zwrotu, umożliwiając szczegółową analizę przyjęcia towaru i kontroli. Dlaczego to ważne Łączy zlecenie zwrotu z fizycznym przyjęciem towaru, co ma znaczenie przy analizie logistyki i czasu obsługi w magazynie. Skąd pobrać To numer dokumentu dostawy (VBELN) z tabeli nagłówka dostawy (LIKP), w której kategoria dokumentu wskazuje na dostawę zwrotną. Przykłady 840000128400001384000014 | |||
| Numer noty uznaniowej CreditMemoNumber | Unikalny identyfikator dokumentu noty uznaniowej, który zatwierdza zwrot pieniędzy. | ||
| Opis Nota uznaniowa to dokument rozliczeniowy, który formalnie uznaje konto klienta kwotą za zwrócone produkty. Ten atrybut zawiera unikalny numer dokumentu finansowego. Śledzenie numeru noty uznaniowej jest niezbędne do analizy finansowego rozliczenia zwrotu. Oznacza ważny etap, który często uruchamia wypłatę, i jest potrzebne do uzgadniania danych finansowych oraz audytu. Dlaczego to ważne Oznacza oficjalną transakcję finansową związaną ze zwrotem pieniędzy. Ułatwia śledzenie końcowych etapów procesu i przeprowadzanie audytu finansowego. Skąd pobrać To numer dokumentu rozliczeniowego (VBELN) z tabeli nagłówka dokumentu rozliczeniowego (VBRK), w której kategoria dokumentu wskazuje na notę uznaniową. Przykłady 900003459000034690000347 | |||
| Organizacja sprzedaży SalesOrganization | Jednostka organizacyjna odpowiedzialna za pierwotną sprzedaż i obsługę zwrotu. | ||
| Opis Organizacja sprzedaży to ważny element struktury organizacyjnej SAP, oznaczający jednostkę odpowiedzialną za sprzedaż i dystrybucję produktów oraz usług. Jest przypisywana do transakcji zwrotu. Ten atrybut pozwala filtrować i porównywać proces zwrotu w różnych jednostkach biznesowych, regionach i działach. Pomaga sprawdzić, czy w niektórych organizacjach sprzedaży odsetek zwrotów jest wyższy lub ich obsługa przebiega mniej sprawnie, co stanowi podstawę analizy wyników organizacji. Dlaczego to ważne Pozwala porównywać wyniki procesu zwrotu i odsetek zwrotów w różnych jednostkach biznesowych, regionach i kanałach sprzedaży. Skąd pobrać Kod organizacji sprzedaży (VKORG) znajduje się w tabeli nagłówka zlecenia zwrotu (VBAK). Przykłady 10002100US01 | |||
| Osoba lub zespół obsługujący ProcessingAgent | Osoba lub grupa zasobów odpowiedzialna za wykonanie czynności ręcznej. | ||
| Opis Ten atrybut wskazuje osobę lub zespół, który wykonał dane zadanie. Może określać rolę lub zespół, a nie konkretnego użytkownika, co jest szczególnie przydatne w środowisku usług wspólnych. Dane te pomagają analizować wyniki pracy poszczególnych osób i zespołów na dashboardzie „Efektywność zatwierdzania zwrotów”. Ułatwiają ocenę rozkładu obciążenia, wskazanie potrzeb szkoleniowych oraz wyróżnienie osób i zespołów, które mogą podzielić się dobrymi praktykami. Dlaczego to ważne Umożliwia analizę wyników pracy na poziomie osoby lub zespołu, co pomaga zarządzać obciążeniem, wskazywać potrzeby szkoleniowe i poprawiać efektywność. Skąd pobrać Informacje te mogą być dostępne w funkcjach SAP Business Partner, jeśli przypisano do nich osoby obsługujące. Można je też wywnioskować z działu lub roli użytkownika w strukturze organizacyjnej HR. Przykłady Wsparcie pierwszej liniiZespół kontroli magazynowejDział finansowy, zobowiązania | |||
| Przestrzeganie zasad zwrotów ReturnPolicyAdherence | Wskaźnik określający, czy sprawa zwrotu jest zgodna z obowiązującą polityką zwrotów. | ||
| Opis Ten wyliczany atrybut logiczny wskazuje, czy zwrot spełnia kryteria określone w obowiązującej polityce. Reguły mogą na przykład sprawdzać, czy zwrot zgłoszono w dozwolonym terminie lub czy podana przyczyna zwrotu jest dopuszczalna dla danego produktu. Atrybut ten bezpośrednio wspiera dashboard „Przegląd zgodności z polityką zwrotów”. Pozwala obliczać poziom zgodności i przybliżać sprawy niezgodne z zasadami, aby ustalić przyczyny odstępstw i skuteczniej egzekwować politykę. Dlaczego to ważne Pozwala mierzyć zgodność z regułami biznesowymi i wskazywać naruszenia polityki, które mogą obniżać rentowność lub powodować wyjątki w procesie. Skąd pobrać Wartość wylicza się na podstawie reguł biznesowych. Przykładowo: (data zgłoszenia zwrotu - data pierwotnego zakupu) <= [dozwolona liczba dni na zwrot]. Do obliczenia potrzebne są data pierwotnego zakupu i zasady polityki zwrotów. Przykłady truefalse | |||
| Realizacja SLA dla zwrotu środków RefundSlaAdherence | Wskaźnik określający, czy zwrot środków został przetworzony w terminie wyznaczonym przez SLA. | ||
| Opis Ten wyliczany atrybut sprawdza, czy czynność „Przetworzono zwrot środków” nastąpiła w dniu docelowej daty zwrotu według SLA lub wcześniej. Dla każdej sprawy wskazuje, czy SLA zostało dotrzymane. To podstawowa miara dla dashboardu „Monitorowanie realizacji SLA dla zwrotów” i KPI „Odsetek zwrotów środków zrealizowanych zgodnie z SLA”. Pomaga mierzyć realizację zobowiązań wobec klientów i wskazywać sprawy, w których nie dotrzymano terminu, aby można było analizować przyczyny opóźnień. Dlaczego to ważne Bezpośrednio mierzy realizację zobowiązań wobec klientów, dlatego jest ważnym wskaźnikiem jakości obsługi i satysfakcji klientów. Skąd pobrać Wartość wylicza się, porównując EventTime czynności „Przetworzono zwrot środków” z wartością RefundSlaTargetDate dla każdej sprawy. Przykłady truefalse | |||
| Status zlecenia zwrotu ReturnOrderStatus | Bieżący ogólny status sprawy zwrotu. | ||
| Opis Ten atrybut przedstawia ogólny status sprawy zwrotu w danym momencie, na przykład „Otwarte”, „W trakcie” lub „Zamknięte”. Często jest to status zbiorczy wyliczany na podstawie ostatniego zakończonego głównego etapu. Jest niezbędny do dashboardu „Bieżący status spraw zwrotów”, który pokazuje aktualne obciążenie i rozkład spraw. Pomaga kierownikom sprawdzić, ile spraw znajduje się na poszczególnych etapach procesu, a następnie lepiej przydzielać zasoby i zarządzać obciążeniem. Dlaczego to ważne Pokazuje, na jakim etapie procesu znajduje się każda sprawa. Jest to niezbędne w dashboardach operacyjnych monitorujących bieżące obciążenie i statusy. Skąd pobrać Wartość wylicza się na podstawie pól statusu w odpowiednich dokumentach. Może to być na przykład status nagłówka (GBSTK) lub pozycji (LFSTK) powiązanego zlecenia sprzedaży (VBUK/VBUP) albo dokumentów dostawy. Przykłady Oczekiwanie na przyjęcie towaruOczekiwanie na kontrolęOczekiwanie na zwrot środkówZamknięte | |||
| Wnioskowana kwota zwrotu pieniędzy RequestedRefundAmount | Kwota zwrotu pieniędzy wnioskowana lub przewidywana na początku procesu. | ||
| Opis Ten atrybut zapisuje wartość zwracanych towarów podaną w pierwotnym zgłoszeniu zwrotu. Stanowi punkt odniesienia do porównania z ostateczną kwotą zwrotu pieniędzy. To pole jest wymagane na dashboardzie „Analiza rozbieżności kwot zwrotów”. Porównanie wnioskowanej i faktycznie zwróconej kwoty pomaga wykrywać problemy, takie jak częściowy zwrot pieniędzy z powodu uszkodzenia produktu, opłaty za ponowne przyjęcie do magazynu lub inne korekty. Ułatwia to zapewnienie poprawności i przejrzystości rozliczeń. Dlaczego to ważne Stanowi punkt odniesienia przy pomiarze poprawności zwrotów i pomaga wykrywać oraz analizować różnice między oczekiwaną a faktyczną kwotą zwrotu. Skąd pobrać Zwykle jest to wartość netto pozycji z pierwotnego zlecenia sprzedaży zwrotu. Chodzi o wartość netto (NETWR) odpowiednich pozycji w tabeli VBAP. Przykłady 125.501050.0049.99 | |||
| Wynik kontroli zwracanego produktu ItemInspectionOutcome | Wynik fizycznej kontroli zwróconego produktu. | ||
| Opis Ten atrybut zapisuje wynik kontroli przeprowadzonej po dostarczeniu towaru do magazynu. Typowe wyniki to „Przyjęty, nadaje się do ponownej sprzedaży”, „Odrzucony, uszkodzony” lub „Przyjęty, do odnowienia”. Dane te dostarczają kontekstu dla kolejnych etapów procesu. Decydują o tym, czy klient otrzyma pełny zwrot środków, częściowy zwrot czy nie otrzyma zwrotu. Analiza wyników kontroli pomaga ustalić przyczyny odrzucenia. Jeśli produkty często ulegają uszkodzeniu w transporcie, może też wskazać problemy z opakowaniem lub przewoźnikiem. Dlaczego to ważne Wyjaśnia, na jakiej podstawie zatwierdzono lub odrzucono zwrot, i dostarcza danych o stanie produktu oraz przyczynach korekt kwoty zwrotu. Skąd pobrać Informacje te mogą być zapisane w partii kontrolnej modułu zarządzania jakością (QM) albo jako status lub kod przyczyny w pozycji dostawy zwrotnej (LIPS). Mogą też znajdować się w polu niestandardowym. Przykłady Przyjęty, nadaje się do ponownej sprzedażyPrzyjęty, do odnowieniaOdrzucony, uszkodzony przez klientaOdrzucony, zwrócono niewłaściwy produkt | |||
Obsługa zwrotów i refundacji: działania
| Działanie | Opis | ||
|---|---|---|---|
| Przyjęcie towaru w magazynie | To zdarzenie oznacza fizyczne przyjęcie zwróconego produktu w magazynie lub centrum obsługi. Jest rejestrowane wprost po zaksięgowaniu przyjęcia towaru (PGR) dla dostawy zwrotnej, co powoduje utworzenie dokumentu materiałowego. | ||
| Dlaczego to ważne To ważny etap, od którego zaczyna się pomiar czasu kontroli i decyzji o dalszym postępowaniu z produktem. Opóźnienia przed tym momentem zależą od klienta, a późniejsze wynikają z działań wewnętrznych. Skąd pobrać Zdarzenie jest rejestrowane w tabelach dokumentów materiałowych MSEG i MKPF dla rodzaju ruchu przyjęcia towaru powiązanego ze zwrotami. Datę zdarzenia wskazuje data księgowania (MKPF-BUDAT). Rejestrowanie Zdarzenie odpowiada zaksięgowaniu przyjęcia towaru dla dostawy zwrotnej. Typ zdarzenia explicit | |||
| Realizacja zwrotu pieniędzy | Ta czynność oznacza ostatni etap procesu zwrotu pieniędzy. Rozliczenie uznania potwierdza, że płatność została wysłana klientowi. Zdarzenie można wywnioskować z utworzenia dokumentu rozliczeniowego w module finansowym, który zamyka otwarte uznanie na koncie klienta. | ||
| Dlaczego to ważne To moment, w którym klient faktycznie otrzymuje pieniądze. Czas od zgłoszenia zwrotu do tego etapu w dużym stopniu wpływa na zadowolenie klientów i pozwala ocenić dotrzymanie SLA. Skąd pobrać Zdarzenie można wywnioskować z informacji o rozliczeniu w tabeli pozycji dokumentów księgowych BSEG. Data rozliczenia (BSEG-AUGDT) w pozycji klienta powiązanej z notą uznaniową wskazuje, kiedy zrealizowano zwrot pieniędzy. Rejestrowanie Zdarzenie można wywnioskować z wypełnienia pola daty rozliczenia w dokumencie księgowym powiązanym z notą uznaniową. Typ zdarzenia inferred | |||
| Utworzenie noty uznaniowej | To utworzenie oficjalnego dokumentu rozliczeniowego, który uznaje konto klienta kwotą za zwrócony produkt. Zdarzenie jest rejestrowane wprost po wygenerowaniu noty uznaniowej na podstawie wniosku o jej wystawienie. | ||
| Dlaczego to ważne Utworzenie noty uznaniowej to ważny etap finansowy. Potwierdza kwotę do zwrotu i pozwala rozpocząć proces płatności. Skąd pobrać Zdarzenie jest rejestrowane podczas utworzenia dokumentu rozliczeniowego w tabeli VBRK, którego kategoria wskazuje na notę uznaniową. Dokument jest powiązany z wnioskiem o notę uznaniową w tabeli VBFA. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu nowego dokumentu rozliczeniowego noty uznaniowej (np. za pomocą transakcji VF01). Typ zdarzenia explicit | |||
| Utworzenie wniosku o notę uznaniową | Po pomyślnym zakończeniu kontroli ta czynność oznacza utworzenie wniosku o uznanie należności klienta. Jest on rejestrowany jako nowy dokument sprzedaży, wniosek o notę uznaniową, powiązany z pierwotnym zleceniem zwrotu. | ||
| Dlaczego to ważne To początek finansowego rozliczenia zwrotu. Analiza czasu od kontroli do tego etapu pokazuje sprawność przekazania sprawy z logistyki do finansów. Skąd pobrać Zdarzenie jest rejestrowane podczas utworzenia dokumentu sprzedaży w tabeli VBAK z kategorią dokumentu „wniosek o notę uznaniową”. Powiązanie ze zwrotem jest zapisane w tabeli przepływu dokumentów VBFA. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu nowego wniosku o notę uznaniową. Typ zdarzenia explicit | |||
| Zakończenie kontroli produktu | Oznacza zakończenie oceny jakości i stanu zwróconego towaru. W Advanced Returns Management jest to często jawny etap, w którym zapisuje się wynik kontroli i określa dalsze postępowanie, na przykład zwrot pieniędzy lub złomowanie. | ||
| Dlaczego to ważne Czas trwania i wynik kontroli bezpośrednio wpływają na czas obsługi zwrotu pieniędzy i zarządzanie zapasami. Ta czynność ma zasadnicze znaczenie przy analizie sprawności kontroli i liczby poprawek. Skąd pobrać W SAP Advanced Returns Management (ARM) może to być jawne zdarzenie zarejestrowane podczas transakcji kontroli. Można je też wywnioskować ze zmiany statusu pozycji zlecenia zwrotu wskazującej wynik kontroli. Rejestrowanie Zdarzenie jest rejestrowane na podstawie dzienników transakcji lub zmian statusu związanych z działaniami następczymi w obszarze logistyki w ARM. Typ zdarzenia explicit | |||
| Zamknięcie sprawy zwrotu | To ostatnia czynność, która oznacza zakończenie procesu zwrotu i brak dalszych działań w danej sprawie. Zwykle można ją wywnioskować z osiągnięcia przez dokument zlecenia zwrotu końcowego statusu zamknięcia w systemie. | ||
| Dlaczego to ważne To zdarzenie wyznacza koniec cyklu życia procesu i pozwala obliczyć łączny czas obsługi od początku do końca. Potwierdza, że sprawa została w pełni rozwiązana. Skąd pobrać Zdarzenie można wywnioskować z osiągnięcia przez ogólny status zlecenia zwrotu w tabeli VBAK lub jego pozycji w VBAP stanu „Zakończono” albo „Zamknięto”. Sposób ustalania tego stanu zależy od konfiguracji zarządzania statusami w systemie. Rejestrowanie Zdarzenie można wywnioskować ze zmiany statusu dokumentu zlecenia zwrotu na „Zakończono”. Typ zdarzenia inferred | |||
| Zgłoszenie zwrotu | To początek procesu zwrotu, kiedy w systemie formalnie tworzone jest zlecenie zwrotu. Zdarzenie jest rejestrowane wprost w chwili zapisania nowego dokumentu sprzedaży typu zlecenie zwrotu w SAP S/4HANA. | ||
| Dlaczego to ważne Ta czynność rozpoczyna cykl życia sprawy zwrotu. Analiza czasu od tego zdarzenia do zamknięcia sprawy ma zasadnicze znaczenie dla pomiaru łącznego czasu obsługi zwrotu i oceny doświadczeń klientów. Skąd pobrać Jest to jawne zdarzenie rejestrowane podczas tworzenia dokumentu sprzedaży w tabeli VBAK, gdy kategoria dokumentu (VBAK-VBTYP) wskazuje na zlecenie zwrotu. Czas utworzenia zapisuje pole VBAK-ERDAT. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu nowego zlecenia zwrotu (np. za pomocą transakcji VA01). Typ zdarzenia explicit | |||
| Odrzucenie zwrotu | Oznacza, że zwrócony produkt nie spełnia warunków określonych w zasadach zwrotów, a wniosek o zwrot pieniędzy lub uznanie należności został odrzucony. Zwykle zdarzenie jest rejestrowane przez przypisanie do pozycji zlecenia zwrotu określonego statusu lub kodu przyczyny po kontroli. | ||
| Dlaczego to ważne Śledzenie odrzuconych zwrotów pomaga analizować zgodność z zasadami zwrotów i wykrywać najczęstsze przyczyny odmowy. To jedna ze ścieżek wyjątków w procesie. Skąd pobrać Zdarzenie można wywnioskować z przypisania przyczyny odrzucenia (VBAP-ABGRU) do pozycji zlecenia zwrotu lub z nadania określonego statusu podczas kontroli w Advanced Returns Management. Rejestrowanie Zdarzenie można wywnioskować z przypisania przyczyny odrzucenia lub statusu „odrzucono” do pozycji dokumentu zwrotu. Typ zdarzenia inferred | |||
| Utworzenie dokumentu księgowego | To zdarzenie występuje po zaksięgowaniu noty uznaniowej w module rachunkowości finansowej. Powstają wtedy odpowiednie zapisy w księdze głównej, a uznanie zostaje formalnie ujęte w księgach. | ||
| Dlaczego to ważne Ta czynność potwierdza, że uznanie zostało ujęte w systemie finansowym. Czas między utworzeniem noty uznaniowej a jej zaksięgowaniem może wskazać problemy na styku rozliczeń i finansów. Skąd pobrać Zdarzenie jest rejestrowane podczas utworzenia nagłówka dokumentu w tabeli księgowej BKPF, powiązanego z notą uznaniową w VBRK (VBRK-BELNR). Rejestrowanie Zdarzenie jest rejestrowane po pomyślnym zaksięgowaniu dokumentu rozliczeniowego w rachunkowości finansowej. Typ zdarzenia explicit | |||
| Utworzenie dostawy zwrotnej | Ta czynność oznacza utworzenie dokumentu dostawy przychodzącej, który służy do obsługi fizycznego przyjęcia zwracanych towarów. System rejestruje ją jako jawne zdarzenie utworzenia dokumentu dostawy powiązanego ze zleceniem zwrotu. | ||
| Dlaczego to ważne To ważny etap logistyczny. Czas od zatwierdzenia zwrotu do utworzenia dostawy pokazuje, jak sprawnie informacje o zwrocie trafiają do magazynu lub działu przyjęć. Skąd pobrać Zdarzenie jest rejestrowane podczas utworzenia nagłówka dostawy w tabeli LIKP, powiązanego z wcześniejszym zleceniem zwrotu przez tabelę przepływu dokumentów VBFA. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu nowego dokumentu dostawy zwrotnej (np. za pomocą transakcji VL01N). Typ zdarzenia explicit | |||
| Utworzenie zlecenia wymiany | Ta czynność oznacza alternatywny sposób rozwiązania sprawy: zamiast zwrotu pieniędzy tworzone jest nowe zlecenie sprzedaży, aby wysłać klientowi produkt na wymianę. Zdarzenie jest rejestrowane po utworzeniu nowego zlecenia sprzedaży powiązanego z pierwotnym zwrotem. | ||
| Dlaczego to ważne Ta czynność pozwala odróżnić zwroty zakończone zwrotem pieniędzy od tych, które kończą się wymianą. Każdy z tych wariantów ma inną ścieżkę procesu i inny rezultat dla klienta. To ważne przy analizie wariantów. Skąd pobrać Zdarzenie jest rejestrowane podczas utworzenia nowego dokumentu sprzedaży w VBAK, powiązanego ze zleceniem zwrotu w tabeli przepływu dokumentów VBFA. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu nowego zlecenia sprzedaży oznaczonego jako zlecenie na produkt zastępczy. Typ zdarzenia explicit | |||
| Zatwierdzenie zlecenia zwrotu | Oznacza formalne zatwierdzenie lub zwolnienie zlecenia zwrotu, które pozwala przejść do kolejnego etapu. Zwykle wnioskuje się o nim na podstawie zmiany statusu nagłówka lub pozycji dokumentu sprzedaży, wskazującej na usunięcie blokady. | ||
| Dlaczego to ważne Etapy zatwierdzania mogą znacząco opóźniać proces. Śledzenie tej czynności pomaga wykryć wąskie gardła na początkowym etapie autoryzacji zwrotu. Skąd pobrać Informacje o zdarzeniu można wywnioskować z tabel zarządzania statusami lub pól statusu w tabelach VBAK albo VBAP. Zmiana statusu zwolnienia lub usunięcie blokady dostawy (VBAP-LIFSP) może oznaczać zatwierdzenie. Rejestrowanie Zdarzenie można wywnioskować ze zmiany pól statusu nagłówka lub pozycji zlecenia zwrotu, która wskazuje na zwolnienie lub zatwierdzenie. Typ zdarzenia inferred | |||
Instrukcje ekstrakcji danych
Kroki
- Sprawdzenie wymagań wstępnych: Upewnij się, że konto użytkownika wykonującego ekstrakcję ma w SAP S/4HANA uprawnienia do wymaganych widoków Core Data Services (CDS). Należą do nich między innymi I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry i I_ClearedItem.
- Otwórz narzędzie do wykonywania zapytań: Zaloguj się do wybranego klienta SQL lub narzędzia do integracji danych, które ma połączenie z bazą SAP S/4HANA. Może to być narzędzie SAP, takie jak SAP Analytics Cloud, albo platforma ETL innego dostawcy.
- Ustaw parametry zapytania: Przed uruchomieniem zmodyfikuj podane zapytanie SQL. Znajdź wartości zastępcze i wpisz parametry właściwe dla danego środowiska. Ustaw między innymi
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]oraz filtry typów dokumentów i kodów spółek. - Uruchom zapytanie ekstrakcyjne: Skopiuj całe zapytanie SQL i uruchom je w wybranym narzędziu. Zapytanie zbiera wskazane działania w jednym zbiorze danych, łącząc wyniki wielu instrukcji SELECT.
- Sprawdź logikę zapytania: Każdy blok
SELECTw strukturzeUNION ALLodpowiada za ekstrakcję jednego działania. Łączy kilka widoków CDS, aby pobrać wymagane atrybuty, przypisuje stałą wartość tekstową doActivityNamei wybiera odpowiedni znacznik czasu dlaEventTime. - Sprawdź surowe dane: Po zakończeniu zapytania krótko przejrzyj wyniki. Sprawdź, czy liczba wierszy jest wiarygodna i czy kluczowe kolumny, takie jak
ReturnCaseId,ActivityNameiEventTime, zawierają oczekiwane wartości. - Przekształcanie danych: Zapytanie tworzy płaski dziennik zdarzeń, który zwykle nie wymaga istotnych zmian struktury. W razie potrzeby dostosuj format znaczników czasu lub typy danych do wymagań systemu docelowego.
- Eksport dziennika zdarzeń: Wyeksportuj wyniki zapytania do pliku CSV. Zapisz plik w kodowaniu UTF-8, aby uniknąć problemów z wyświetlaniem znaków, zwłaszcza w nazwach użytkowników i opisach produktów.
- Prześlij dane do narzędzia process mining: Plik CSV można teraz przesłać na platformę process mining, taką jak ProcessMind. Przypisz kolumny z pliku do odpowiednich pól w narzędziu, na przykład
ReturnCaseIddo Case ID,ActivityNamedo Activity, aEventTimedo Timestamp.
Konfiguracja
- Wymagane uprawnienia: Użytkownik wykonujący ekstrakcję potrzebuje uprawnień do wyświetlania obiektów związanych z dokumentami sprzedaży (VBAK), dostawami (LIKP), fakturowaniem (VBRK) i księgowością (BSEG, BKPF). Niezbędny jest dostęp do bazowych widoków CDS.
- Filtry zakresu danych: Aby wyodrębnić proces zwrotów, należy filtrować zapytanie według określonych typów dokumentów. Ustaw wartości zastępcze dla typów zleceń zwrotu (np. 'RE'), wniosków o notę kredytową (np. 'G2') i zleceń wymiany (np. 'SO'). Warto również filtrować według
CompanyCodelubSalesOrganization, aby ograniczyć zakres danych. - Filtrowanie według dat: Aby kontrolować wydajność i ilość danych, zawsze stosuj filtr zakresu dat. Na początek wybierz ostatnie 3–6 miesięcy. Głównym warunkiem filtrowania w zapytaniu jest data utworzenia początkowego zlecenia zwrotu (
I_SalesDocument.CreationDate). - Wydajność: To rozbudowane zapytanie łączy wiele dużych widoków CDS, dlatego może znacznie obciążać źródłowy system S/4HANA. Aby ograniczyć wpływ na pracę systemu, zaplanuj ekstrakcję poza godzinami szczytu. W przypadku bardzo dużych zbiorów danych warto rozważyć ładowanie przyrostowe.
Przykładowe zapytanie 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' Kroki
- Sprawdź, czy dostępny jest bezpośredni dostęp do odczytu schematu SAP HANA zawierającego dane dotyczące sprzedaży, dostaw, fakturowania, dokumentów materiałowych, kontroli, statusów i księgowości. Dokładne nazwy schematów, widoków i pól zależą od wdrożenia SAP S/4HANA. Zastąp każdy element w nawiasach kwadratowych obiektami i polami skonfigurowanymi w danym systemie.
- Określ zakres ekstrakcji za pomocą parametrów [Start date], [End date], [Company Code filter] i [Return document type filter]. Przy pierwszej ekstrakcji wybierz okres od trzech do sześciu miesięcy. Wydłuż go dopiero po sprawdzeniu wydajności i kompletności danych.
- Zidentyfikuj zbiór zleceń zwrotu w tabelach [Your sales document header table] i [Your sales document item table]. Ogranicz go do typów dokumentów zleceń zwrotu skonfigurowanych w [Your return order document type configuration]. Zachowaj numer zlecenia zwrotu i numer pozycji jako podstawowe identyfikatory powiązań z kolejnymi dokumentami.
- Ustal przepływ dokumentów od zleceń zwrotu do dostaw przychodzących zwrotów, wniosków o notę kredytową, zleceń wymiany i not kredytowych, korzystając z [Your document flow table or view]. Nie zakładaj, że przepływ dokumentów jest zapisany w VBAK lub VBAP. Skonfiguruj pola relacji zgodnie z modelem przepływu dokumentów używanym w systemie.
- Pobierz jawne zdarzenia utworzenia z odpowiednich rekordów nagłówków i pozycji dokumentów. Zdarzenia zatwierdzenia, odrzucenia, kontroli, zamknięcia, przyjęcia towaru, księgowania i rozliczenia pobierz ze skonfigurowanych źródeł statusów, kontroli, dokumentów materiałowych, księgowych i rozliczeniowych. Każde działanie musi być osobnym wierszem zdarzenia, ponieważ ProcessMind nie wyznacza zdarzeń automatycznie.
- Ujednolić znaczniki czasu, stosując spójny typ znacznika czasu bazy danych i jedną strefę czasową. Dla każdego działania zastosuj skonfigurowaną kolejność wyboru znaczników czasu. Jeśli dostępne są tylko data i godzina, połącz je, używając strefy czasowej systemu określonej w [Your system time zone].
- Wypełnij pole ReturnCaseId dla każdego zdarzenia. Użyj numeru źródłowego zlecenia zwrotu albo skonfigurowanego identyfikatora sprawy zwrotu, jeśli Advanced Returns Management przechowuje osobny klucz sprawy. Zdarzenia, których nie można powiązać ze sprawą zwrotu, należy wykluczyć lub umieścić w osobnym zbiorze wyjątków do dalszej obsługi.
- Wypełnij wymagane kolumny: ReturnCaseId, ActivityName, EventTime, SourceSystemId i LastDataUpdateTimestamp. Jeśli są dostępne, uzupełnij również zalecane kolumny, w tym EventEndTime, UserName, ReturnReason, RefundAmount, ProductId i CustomerId. Zachowaj jeden wiersz dla każdego wystąpienia działania. Nie łącz działań w jeden wiersz sprawy.
- Sprawdź wyniki zgodnie z kontrolami opisanymi w validationSteps. Potwierdź obecność wszystkich dwunastu nazw działań, wiarygodną kolejność znaczników czasu w każdej sprawie oraz zgodność odwołań do dokumentów z tabelami źródłowymi.
- Wyeksportuj wyniki do pliku CSV w kodowaniu UTF-8 lub innym obsługiwanym przez ProcessMind formacie tabelarycznym. Zachowaj dokładne nazwy kolumn, jeden wiersz nagłówka i jednoznaczny format ISO znaczników czasu. Prześlij dziennik zdarzeń, ustawiając ReturnCaseId jako identyfikator sprawy, a ActivityName jako kolumnę działania.
Konfiguracja
- Zakres dat: Zacznij od okresu od trzech do sześciu miesięcy. Użyj parametrów [Start date] i [End date]. Uwzględnij dane historyczne potrzebne do uchwycenia spraw rozpoczętych przed wybranym okresem, ale zakończonych w jego trakcie.
- Zbiór zwrotów: Filtruj według typów dokumentów zleceń zwrotu skonfigurowanych w [Your return order document type configuration]. Nie wpisuj typu dokumentu na stałe, dopóki nie zostanie zweryfikowany w systemie docelowym.
- Filtry organizacyjne: Stosuj filtry [Company Code filter], organizacji sprzedaży, kanału dystrybucji, działu, zakładu lub klienta tylko wtedy, gdy są potrzebne. Sprawdź, czy filtry nie wykluczają dokumentów następczych z innych spółek lub transakcji międzyspółkowych.
- Obiekty źródłowe: Zastąp wartości [Your table name] i [Your view name] zatwierdzonymi tabelami lub widokami CDS SAP S/4HANA. W danym wdrożeniu mogą być dostępne VBAK, VBAP, VBRK i VBRP, ale przed uruchomieniem należy sprawdzić, czy można ich użyć i czy zostały rozszerzone.
- Obsługa znaczników czasu: Skonfiguruj źródłowe pola znaczników czasu i strefę czasową dla każdego działania. Zapisuj EventTime i EventEndTime w spójnym formacie, najlepiej w UTC lub uzgodnionej strefie czasowej ProcessMind.
- Interpretacja statusów: Skonfiguruj dokładne wartości statusów, kody przyczyn, wyniki kontroli i wskaźniki zamknięcia, które w systemie oznaczają zatwierdzenie, odrzucenie, zakończenie kontroli i zamknięcie sprawy.
- Identyfikator systemu źródłowego: Zastąp [Source system identifier] stałą wartością, na przykład identyfikatorem systemu SAP używanym przez platformę ekstrakcyjną.
- Znacznik czasu odświeżenia: Zastąp [Extraction timestamp] znacznikiem czasu rozpoczęcia zapytania lub utworzenia migawki źródła. Użyj tej samej wartości dla wszystkich wierszy jednego przebiegu ekstrakcji, chyba że wymagane są znaczniki czasu odświeżenia dla poszczególnych wierszy.
- Wydajność: Ogranicz początkowy zbiór zleceń zwrotu przed połączeniem z dużymi źródłami przepływu dokumentów, księgowości, dokumentów materiałowych i statusów. Korzystaj z pól indeksowanych lub umożliwiających eliminację partycji, unikaj skanowania całych tabel i twórz tabele pośrednie tylko za zgodą administratora bazy danych.
- Ekstrakcja przyrostowa: Przy cyklicznych ekstrakcjach używaj [Last successful extraction timestamp] i kontrolowanego okna nakładania się, aby uwzględnić późniejsze aktualizacje. Usuń duplikaty na podstawie ReturnCaseId, ActivityName, klucza dokumentu źródłowego i EventTime.
- Uprawnienia i wymagania wstępne: Uzyskaj uprawnienia do odczytu wszystkich skonfigurowanych obiektów i pól źródłowych, zgodę na bezpośredni dostęp do bazy danych oraz potwierdzenie, że wymagane komponenty SAP i funkcje Advanced Returns Management są aktywne, jeśli mają zastosowanie.
- Ochrona danych: Ogranicz zakres danych klienta i finansowych do niezbędnego minimum, stosuj firmowe zasady ochrony prywatności i zabezpieczaj wyeksportowane pliki.
Przykładowe zapytanie 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; Gotowi do rozpoczęcia?
Ten szablon zawiera podstawowe informacje potrzebne do ekstrakcji i analizy danych dotyczących obsługi zwrotów i refundacji. Można od razu rozpocząć pracę nad usprawnieniem procesu.
Usprawnij obsługę zwrotów i refundacji w SAP S/4HANA
Wykryj nieefektywne działania, skróć czas realizacji o 30% i zwiększ satysfakcję.
Nie trzeba podawać danych karty płatniczej. Można zacząć usprawnianie procesu już dziś.