Szablon danych do obsługi zwrotów i refundacji
Szablon danych do obsługi zwrotów i refundacji
- Zalecane atrybuty do zebrania
- Czynności do śledzenia
- Instrukcje pobierania danych z NetSuite
Atrybuty procesu obsługi zwrotów i refundacji
| Nazwa | Opis | ||
|---|---|---|---|
| Identyfikator sprawy zwrotu ReturnCaseId | Unikalny identyfikator pojedynczej sprawy zwrotu lub refundacji, który łączy wszystkie powiązane czynności od rozpoczęcia do zamknięcia. | ||
| Opis Identyfikator sprawy zwrotu służy do śledzenia całego przebiegu zwrotu. Każdy unikalny identyfikator odpowiada jednej autoryzacji zwrotu i pozwala analizować wszystkie powiązane zdarzenia, takie jak przyjęcie produktu, kontrola i realizacja refundacji. W process mining identyfikator ten jest niezbędny do odtworzenia pełnego przebiegu każdej sprawy, obliczenia czasu jej obsługi i wykrycia odstępstw. Dlaczego to ważne To podstawowy atrybut w process mining, ponieważ łączy pojedyncze zdarzenia w spójne instancje procesu od początku do końca. Dzięki temu można analizować przebieg i wyniki procesu. Skąd pobrać Zwykle jest to Internal ID lub Transaction ID rekordu Return Authorization w NetSuite. Przykłady RMA-0012345RMA-0012346RMA-0012347 | |||
| Nazwa czynności ActivityName | Nazwa konkretnego zdarzenia biznesowego lub kroku w procesie zwrotu, na przykład „Kontrola zwracanego produktu” lub „Realizacja refundacji”. | ||
| Opis Nazwa czynności opisuje konkretny krok lub etap obsługi zwrotu i refundacji. Zdarzenia są porządkowane według znaczników czasu, aby odtworzyć przebieg procesu. Analiza kolejności i częstotliwości czynności pomaga wykryć najczęstsze ścieżki, wąskie gardła między etapami oraz poprawki i powtarzające się działania. Przykłady: „Utworzenie autoryzacji zwrotu”, „Otrzymanie zwracanego produktu” i „Zatwierdzenie noty kredytowej”. Dlaczego to ważne Ten atrybut określa kroki procesu. Jest niezbędny do wizualizacji mapy procesu, analizy różnych przebiegów oraz wykrywania wąskich gardeł i powtarzających się czynności. Skąd pobrać Ten atrybut zwykle ustala się na podstawie zmian statusu transakcji, takich jak Return Authorization i Credit Memo, albo konkretnych działań użytkowników zapisanych w notatkach systemowych lub niestandardowych dziennikach zdarzeń. Przykłady Utworzenie autoryzacji zwrotuOtrzymanie zwracanego produktuKontrola zwracanego produktuRealizacja refundacjiZamknięcie autoryzacji zwrotu | |||
| Znacznik czasu zdarzenia EventTimestamp | Dokładna data i godzina wykonania czynności, które określają chronologię procesu. | ||
| Opis Znacznik czasu zdarzenia wskazuje dokładny moment wykonania czynności. Dane te są niezbędne do prawidłowego uporządkowania zdarzeń i wszystkich analiz czasu. Służą do obliczania czasu między czynnościami, całkowitego czasu obsługi sprawy i czasu oczekiwania. Wskaźniki te są podstawą monitorowania wyników, analizy wąskich gardeł i kontroli realizacji SLA. Dokładne znaczniki czasu są warunkiem wiarygodnych wyników process mining. Dlaczego to ważne Ten atrybut określa chronologię zdarzeń, niezbędną do odtworzenia przebiegu procesu i obliczenia wskaźników, takich jak czas obsługi i czas oczekiwania. Skąd pobrać Informacje te pochodzą zwykle z pól „Date Created” lub „Last Modified Date” w rekordach NetSuite albo ze znaczników czasu na liście System Notes powiązanej z transakcją. Przykłady 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:12:05Z | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane dotyczące procesu zostały ostatnio odświeżone lub zaktualizowane. | ||
| Opis Ten atrybut informuje, kiedy dane zostały ostatnio zaktualizowane na podstawie systemu źródłowego. To ważna metadana, która pozwala ocenić aktualność analizy. Wyświetlanie tej informacji na dashboardach pomaga właściwie interpretować wyniki i podejmować decyzje ze świadomością, jak aktualne są dane. Dlaczego to ważne Informuje o aktualności danych. Dzięki temu użytkownicy mogą ocenić wiarygodność analizy i jej przydatność w odniesieniu do bieżącego stanu operacji. Skąd pobrać Ten znacznik czasu jest generowany i dodawany podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL). Przykłady 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| System źródłowy SourceSystem | System, z którego wyodrębniono dane. Informacja ta służy do śledzenia ich pochodzenia. | ||
| Opis Ten atrybut wskazuje źródło danych o procesie. W tym przypadku będzie to zwykle „NetSuite”. Podanie systemu źródłowego jest ważne, gdy dane pochodzą z kilku systemów, ponieważ ułatwia śledzenie ich pochodzenia i przepływu. Dlaczego to ważne Wskazuje pochodzenie danych, co ma znaczenie dla zarządzania danymi, rozwiązywania problemów i łączenia danych z wielu systemów w celu uzyskania pełnego obrazu procesu. Skąd pobrać To stała wartość („NetSuite”), dodawana zwykle podczas wyodrębniania i przekształcania danych. Przykłady NetSuiteNetSuite ERP | |||
| Dział Department | Dział lub zespół odpowiedzialny za obsługę sprawy zwrotu na danym etapie. | ||
| Opis Ten atrybut przypisuje czynności w procesie do konkretnego działu, na przykład obsługi klienta, magazynu lub finansów. Pomaga analizować przekazywanie spraw między zespołami i wykrywać wąskie gardła w poszczególnych działach. Analiza czasu obsługi spraw w danym dziale i czasu oczekiwania na jego działania pozwala ustalić źródła opóźnień i lepiej przydzielać zasoby. To jeden z głównych wymiarów dashboardu „Wyniki obsługi zwrotów według działu”. Dlaczego to ważne Umożliwia analizę wyników procesu według obszaru działalności i wskazuje opóźnienia przy przekazywaniu spraw między działami oraz wąskie gardła w poszczególnych działach. Skąd pobrać Atrybut można ustalić na podstawie rekordu użytkownika lub pracownika powiązanego z czynnością albo pola „Department” w samej transakcji. Często jest skonfigurowany w rekordach pracowników w NetSuite. Przykłady MagazynObsługa klientaFinanseKontrola jakości | |||
| Faktyczna kwota zwrotu ActualRefundAmount | Ostateczna kwota faktycznie zwrócona klientowi. | ||
| Opis Ten atrybut przedstawia kwotę faktycznie zaksięgowaną na koncie klienta lub mu zwróconą, zgodnie z danymi z transakcji Credit Memo lub refund. Może różnić się od kwoty wnioskowanej z powodu opłat za ponowne przyjęcie do magazynu, kosztów wysyłki lub częściowego zwrotu za uszkodzony produkt. Atrybut jest niezbędny w raportowaniu finansowym i przy obliczaniu KPI „Wskaźnik rozbieżności kwot zwrotu”. Dlaczego to ważne Pokazuje rzeczywisty wpływ zwrotu na finanse. Jest niezbędny do uzgadniania rozliczeń i analizy poprawności zwrotów. Skąd pobrać Wartość pochodzi z pola „Total” transakcji Credit Memo utworzonej na podstawie Return Authorization. Przykłady 99.99140.000.00 | |||
| Pracownik obsługujący ProcessingAgent | Pracownik lub użytkownik, który wykonał daną czynność w procesie zwrotu. | ||
| Opis Atrybut „Pracownik obsługujący” wskazuje osobę odpowiedzialną za wykonanie danego zadania, na przykład zatwierdzenie zwrotu lub kontrolę produktu. Jest niezbędny do analizy wyników pracy poszczególnych użytkowników. Pomaga wskazać pracowników osiągających dobre wyniki, obszary wymagające dodatkowych szkoleń i nierównomierne obciążenie zespołu. Analiza czynności według pracownika jest ważnym elementem dashboardu „Wyniki obsługi zwrotów według działu”. Dlaczego to ważne Umożliwia analizę wyników pracy poszczególnych osób i zespołów, równoważenie obciążenia oraz identyfikację potrzeb szkoleniowych, co bezpośrednio wpływa na sprawność operacyjną. Skąd pobrać Dane można pobrać z pól takich jak „Created By” i „Approved By” lub z pól użytkownika na liście System Notes w transakcjach NetSuite. Przykłady Alice JohnsonBob WilliamsCharlie Brown | |||
| Rodzaj zwrotu ReturnType | Klasyfikacja zwrotu na podstawie przyczyny podanej przez klienta. | ||
| Opis Atrybut „Rodzaj zwrotu” klasyfikuje zwroty według przyczyny, na przykład wadliwego produktu, niewłaściwego rozmiaru, zmiany decyzji lub niezgodności produktu z opisem. Taka klasyfikacja jest niezbędna do analizy przyczyn źródłowych. Analiza wskaźników procesu dla różnych rodzajów zwrotów pozwala wykryć problemy z jakością produktów, nieścisłości w opisach lub błędy w realizacji zamówień. Atrybut ten jest ważnym elementem dashboardu „Wyniki obsługi zwrotów według rodzaju i kanału”. Dlaczego to ważne Pomaga ustalić przyczyny zwrotów i ukierunkować usprawnienia produktów, opisów marketingowych lub realizacji zamówień, aby ograniczyć liczbę zwrotów. Skąd pobrać To zwykle pole niestandardowe albo standardowe pole listy lub rekordu w formularzu Return Authorization, w którym zapisuje się przyczynę zwrotu. Przykłady Wadliwy produktWysłano niewłaściwy produktNiezadowolenie klientaNiewłaściwy rozmiar lub kolor | |||
| Status zwrotu ReturnAuthorizationStatus | Bieżący status autoryzacji zwrotu, na przykład „Pending Approval”, „Approved” lub „Closed”. | ||
| Opis Ten atrybut wskazuje bieżący etap sprawy zwrotu. Pomaga śledzić postęp zwrotów i dzielić sprawy na grupy. Na przykład długi czas w statusie „Pending Receipt” może wskazywać na opóźnienia w dostawie, a długi czas w statusie „Pending Approval” może oznaczać wewnętrzne wąskie gardło. Atrybut służy też do ustalenia końcowego wyniku zwrotu, na przykład „Closed” lub „Rejected”. Dlaczego to ważne Pokazuje, na jakim etapie procesu znajduje się każdy zwrot, co pozwala analizować liczbę spraw, czas trwania poszczególnych statusów i wyniki procesu. Skąd pobrać Odpowiada polu „Status” lub podobnemu polu w rekordzie Return Authorization w NetSuite. Przykłady Oczekuje na akceptacjęOczekuje na przyjęcieZatwierdzonoOdrzuconoZamknięto | |||
| Docelowy termin zwrotu zgodny z SLA RefundSlaTargetDate | Termin, do którego zwrot powinien zostać zrealizowany zgodnie z ustalonym poziomem usług. | ||
| Opis Docelowy termin zwrotu zgodny z SLA to obliczony timestamp określający zobowiązanie wobec klienta dotyczące realizacji zwrotu. Zwykle wyznacza się go przez dodanie ustalonego okresu, na przykład 5 dni roboczych, do ważnego zdarzenia, takiego jak „Produkt otrzymany” lub „Zwrot zatwierdzony”. Atrybut ten jest niezbędny w dashboardzie „Monitorowanie zgodności zwrotów z SLA” i przy obliczaniu KPI „Odsetek zwrotów zrealizowanych w SLA”. Pozwala mierzyć wyniki względem zobowiązań firmy. Dlaczego to ważne Umożliwia ilościową ocenę realizacji zobowiązań wobec klientów, co pomaga utrzymać ich zadowolenie i zaufanie. Skąd pobrać Zwykle nie jest to standardowe pole. Termin trzeba obliczyć, dodając ustalony okres SLA, na przykład 5 dni, do ważnego timestampu, takiego jak data „Produkt otrzymany”. Przykłady 2023-11-01T23:59:59Z2023-11-05T23:59:59Z2023-11-10T23:59:59Z | |||
| Identyfikator klienta CustomerId | Unikalny identyfikator klienta zgłaszającego zwrot. | ||
| Opis Identyfikator klienta łączy transakcję zwrotu z konkretnym klientem. Umożliwia analizę zachowań poszczególnych klientów, na przykład wskazanie osób często zwracających produkty, co może świadczyć o niezadowoleniu lub nadużyciach. Pozwala też porównywać przebieg procesu w różnych grupach klientów, na przykład według segmentu lub wartości, i ustalać priorytety obsługi najważniejszych klientów. Dlaczego to ważne Umożliwia analizę zwrotów na poziomie klienta oraz podział procesu według cech klientów, takich jak segment czy wartość klienta w całym okresie współpracy. Skąd pobrać To pole „Customer” lub „Entity” w nagłówku rekordu Return Authorization w NetSuite. Przykłady CUST-001CUST-002CUST-003 | |||
| Identyfikator produktu ProductIdentifier | Unikalny identyfikator zwracanego produktu, na przykład SKU lub numer produktu. | ||
| Opis Ten atrybut wskazuje konkretny produkt objęty zwrotem. Analiza zwrotów na poziomie produktu pomaga wykryć produkty o wysokim odsetku zwrotów, co może wskazywać na wady jakościowe, nieprecyzyjne opisy lub inne problemy. Dane te umożliwiają szczegółową analizę wyników produktów i mogą wspierać decyzje dotyczące rozwoju produktu, zaopatrzenia i marketingu. Dlaczego to ważne Łączy dane o procesie zwrotu z konkretnymi produktami, ułatwiając analizę przyczyn problemów związanych z produktami i ograniczenie ogólnej liczby zwrotów. Skąd pobrać Informacja znajduje się na liście „Items” w rekordzie Return Authorization, w polu „Item”. Przykłady SKU-TEE-BL-LPROD-00543ITEM-987123 | |||
| Kanał zwrotu ReturnChannel | Kanał, w którym dokonano pierwotnego zakupu lub zgłoszono zwrot. | ||
| Opis Atrybut „Kanał zwrotu” wskazuje źródło zwrotu, na przykład sklep internetowy, sklep stacjonarny lub marketplace. W poszczególnych kanałach mogą obowiązywać inne procesy zwrotu, koszty i oczekiwania klientów. Analiza wyników według kanału pomaga usprawniać poszczególne procesy, efektywnie przydzielać zasoby i rozpoznawać problemy charakterystyczne dla danego kanału. To podstawowy atrybut dashboardu „Wyniki obsługi zwrotów według rodzaju i kanału”. Dlaczego to ważne Umożliwia porównanie wyników w różnych kanałach sprzedaży i pomaga wykryć nieefektywne działania oraz dobre praktyki związane ze zgłaszaniem i obsługą zwrotów. Skąd pobrać Informacje te pochodzą często z pierwotnego rekordu Sales Order powiązanego ze zwrotem. Mogą być zapisane w polu „Channel” lub „Location”. Przykłady Sklep internetowySklep stacjonarnyMarketplace AmazonZamówienie telefoniczne | |||
| Rozbieżność kwoty zwrotu RefundAmountDiscrepancy | Obliczona różnica między wnioskowaną a faktycznie zwróconą kwotą. | ||
| Opis Wskaźnik oblicza się, odejmując „Faktyczną kwotę zwrotu” od „Wnioskowanej kwoty zwrotu”. Wartość różna od zera oznacza korektę wprowadzoną w trakcie procesu, na przykład opłatę za ponowne przyjęcie do magazynu lub potrącenie za uszkodzony produkt. Atrybut służy do analizy KPI „Wskaźnik rozbieżności kwot zwrotu” i wskazywania spraw z dużymi korektami finansowymi, które wymagają weryfikacji. Dlaczego to ważne Pokazuje korekty finansowe wprowadzone podczas obsługi zwrotu. Umożliwia analizę przyczyn rozbieżności oraz ocenę, czy są one spójne i uzasadnione. Skąd pobrać To atrybut obliczany według wzoru: Przykłady 0.0010.00-5.00 | |||
| Stan zwracanego produktu ReturnCondition | Stan zwracanego produktu oceniony podczas kontroli, na przykład „Nowy”, „Uszkodzony” lub „Używany”. | ||
| Opis Ten atrybut opisuje wynik fizycznej kontroli zwracanego produktu. Od jego stanu zależą dalsze działania, na przykład zwrot pełnej kwoty, ponowne przyjęcie produktu do magazynu lub jego utylizacja. Dashboard „Jakość oceny stanu zwracanych produktów” służy do analizy spójności ocen i czasu ich przeprowadzania. Dane te są też istotne przy uzgadnianiu finansów i zarządzaniu zapasami. Dlaczego to ważne Bezpośrednio wpływa na rozliczenie zwrotu i dalsze działania dotyczące zapasów. Niespójne oceny mogą prowadzić do strat finansowych i konieczności ponownego wykonania pracy. Skąd pobrać To prawdopodobnie pole niestandardowe w rekordzie Item Receipt lub Return Authorization, uzupełniane przez pracowników magazynu podczas kontroli. Przykłady Nadaje się do ponownej sprzedażyUszkodzony, w opakowaniuUżywany, w dobrym stanieBrakujące części | |||
| Wnioskowana kwota zwrotu RequestedRefundAmount | Kwota pieniężna zwrotu pierwotnie wnioskowana lub przewidywana dla danej sprawy. | ||
| Opis Ten atrybut przechowuje przewidywaną kwotę zwrotu na początku procesu. Zwykle odpowiada ona pierwotnej cenie zakupu zwracanych produktów. Stanowi punkt odniesienia przy porównaniu z kwotą faktycznie zwróconą. KPI „Wskaźnik rozbieżności kwot zwrotu” porównuje tę wartość z atrybutem „Faktyczna kwota zwrotu”, aby wykryć różnice wynikające z opłat za ponowne przyjęcie do magazynu, częściowych zwrotów lub innych korekt. Dlaczego to ważne Stanowi punkt odniesienia w analizie finansowej. Ułatwia śledzenie różnic między przewidywaną a faktyczną kwotą zwrotu oraz ustalanie przyczyn korekt. Skąd pobrać Wartość pochodzi z pól „Amount” lub „Rate” pozycji transakcji Return Authorization. Przykłady 99.99150.0025.50 | |||
| Wykonano automatycznie IsAutomated | Wskaźnik logiczny informujący, czy system wykonał daną czynność automatycznie. | ||
| Opis Ten atrybut wskazuje, czy czynność wykonał użytkownik, czy system, skrypt albo workflow. Na przykład zdarzenie „Utworzono Return Authorization” może być generowane automatycznie przez portal klienta, a „Skontrolowano produkt” wymagać pracy ręcznej. Śledzenie automatyzacji pomaga znaleźć czynności, które można zautomatyzować, i mierzyć efekty już wdrożonych rozwiązań. Dlaczego to ważne Pozwala odróżnić czynności ręczne od automatycznych. Jest to istotne przy szukaniu możliwości automatyzacji i ocenie efektów transformacji cyfrowej. Skąd pobrać Można to ustalić na podstawie użytkownika przypisanego do zdarzenia. Zdarzenia generowane przez system w NetSuite są często powiązane z konkretnym użytkownikiem systemowym lub identyfikatorem skryptu. Przykłady truefalse | |||
| Zgodność z polityką zwrotów ReturnPolicyAdherence | Informuje, czy zwrot jest zgodny z obowiązującą w firmie polityką zwrotów. | ||
| Opis Ten atrybut logiczny lub kategoryczny wskazuje, czy zwrot spełnia wszystkie ustalone kryteria, takie jak termin zwrotu, stan produktu i dowód zakupu. Służy do monitorowania zgodności i obsługi wyjątków. Dashboard „Wyjątki od polityki zwrotów” wykorzystuje ten atrybut do wskazywania spraw wymagających szczególnej obsługi lub weryfikacji. Pomaga to ograniczać ryzyko i zapewniać spójne stosowanie zasad. Dlaczego to ważne Ułatwia monitorowanie i egzekwowanie zasad zwrotów, ogranicza ryzyko finansowe związane ze zwrotami niezgodnymi z polityką oraz pomaga zapewnić równe i spójne traktowanie klientów. Skąd pobrać To niemal na pewno pole niestandardowe, na przykład pole wyboru lub lista w rekordzie Return Authorization, obsługiwane za pomocą workflow. Przykłady Zgodny z politykąNiezgodny, po upływie terminuZatwierdzony wyjątek | |||
| Zgodność z SLA IsSlaCompliant | Obliczany wskaźnik informujący, czy zwrot zrealizowano w wyznaczonym terminie SLA. | ||
| Opis Ten atrybut logiczny wyznacza się przez porównanie timestampu „Zwrot zrealizowany” z „Docelowym terminem zwrotu zgodnym z SLA”. Jeśli zwrot zrealizowano najpóźniej w terminie docelowym, wartość wynosi true, w przeciwnym razie false. Wskaźnik ułatwia tworzenie raportów i dashboardów zgodności, takich jak „Monitorowanie zgodności zwrotów z SLA”, oraz obliczanie KPI „Odsetek zwrotów zrealizowanych w SLA”. Dlaczego to ważne Daje jednoznaczny wynik oceny SLA dla każdej sprawy, dzięki czemu można łatwo śledzić, raportować i analizować zgodność w czasie. Skąd pobrać Atrybut oblicza się podczas transformacji danych lub w narzędziu process mining. Reguła: Przykłady truefalse | |||
Czynności w procesie obsługi zwrotów i refundacji
| Działanie | Opis | ||
|---|---|---|---|
| Otrzymanie zwracanego produktu | To zdarzenie oznacza fizyczne przyjęcie zwracanego produktu w magazynie lub centrum obsługi. W NetSuite jest rejestrowane przez utworzenie transakcji Item Receipt powiązanej z pierwotną autoryzacją zwrotu. | ||
| Dlaczego to ważne To ważny etap, który przenosi proces od działań klienta do obsługi wewnętrznej. Czas między „Return Approved” a „Item Received” pokazuje, jak szybko klient odsyła produkt. Czas po tym zdarzeniu obrazuje sprawność obsługi wewnętrznej. Skąd pobrać To zdarzenie odpowiada znacznikowi czasu utworzenia transakcji ItemReceipt. Rekord jest bezpośrednio powiązany z pierwotnym ReturnAuthorization. Rejestrowanie Data utworzenia transakcji ItemReceipt w NetSuite powiązanej z RA. Typ zdarzenia explicit | |||
| Realizacja refundacji | To końcowe rozliczenie finansowe, w ramach którego środki są zwracane klientowi. W NetSuite jest rejestrowane przez utworzenie transakcji Customer Refund na podstawie Credit Memo. | ||
| Dlaczego to ważne To zdarzenie ma znaczenie dla pomiaru realizacji SLA i zadowolenia klientów. Czas od „Credit Memo Approved” do „Refund Processed” bezpośrednio pokazuje szybkość pracy działu skarbu lub finansów. Skąd pobrać To zdarzenie odpowiada znacznikowi czasu utworzenia transakcji CustomerRefund. Pole „Created From” w tej transakcji łączy ją z CreditMemo. Rejestrowanie Data utworzenia transakcji CustomerRefund w NetSuite. Typ zdarzenia explicit | |||
| Utworzenie autoryzacji zwrotu | To zdarzenie rozpoczyna proces zwrotu, gdy klient zgłasza chęć oddania produktu. W NetSuite jest rejestrowane przez utworzenie nowego rekordu Return Authorization (RA), który pełni funkcję głównego identyfikatora sprawy zwrotu. | ||
| Dlaczego to ważne Jako pierwszy krok procesu zdarzenie to pozwala mierzyć całkowity czas obsługi zwrotu i analizować liczbę napływających zgłoszeń w czasie. Skąd pobrać To zdarzenie odpowiada znacznikowi czasu utworzenia rekordu ReturnAuthorization w NetSuite. Rekord zwykle zawiera informacje o użytkowniku, dacie i początkowym statusie, na przykład „Pending Approval”. Rejestrowanie Data utworzenia transakcji ReturnAuthorization w NetSuite. Typ zdarzenia explicit | |||
| Utworzenie noty kredytowej | To zdarzenie oznacza rozpoczęcie finansowej części zwrotu przez utworzenie noty kredytowej (Credit Memo). Dokument określa kwotę refundacji dla klienta i jest tworzony na podstawie Return Authorization po otrzymaniu i zatwierdzeniu produktu. | ||
| Dlaczego to ważne Utworzenie Credit Memo to ważny etap finansowy. Czas od przyjęcia produktu do utworzenia noty pokazuje sprawność procesu od kontroli do rozliczenia. Skąd pobrać To zdarzenie odpowiada znacznikowi czasu utworzenia transakcji CreditMemo. Pole „Created From” w Credit Memo łączy ją z ReturnAuthorization. Rejestrowanie Data utworzenia transakcji CreditMemo w NetSuite. Typ zdarzenia explicit | |||
| Zamknięcie autoryzacji zwrotu | To ostatnie zdarzenie oznacza administracyjne zamknięcie sprawy zwrotu po zakończeniu wszystkich czynności. Ustala się je na podstawie końcowej zmiany statusu rekordu Return Authorization na „Closed”. | ||
| Dlaczego to ważne Jako ostateczny koniec procesu zdarzenie to pozwala obliczyć całkowity czas obsługi i wykryć sprawy, które pozostają otwarte długo po realizacji refundacji. Skąd pobrać Zdarzenie ustala się na podstawie notatek systemowych lub historii workflow rekordu ReturnAuthorization, gdy pole „Status” zmienia się na końcowy status, na przykład „Closed”. Rejestrowanie Wykrycie zmiany statusu rekordu ReturnAuthorization na „Closed”. Typ zdarzenia inferred | |||
| Zatwierdzenie autoryzacji zwrotu | To formalna akceptacja zgłoszenia zwrotu przez pracownika, która pozwala kontynuować proces. Zdarzenie zwykle ustala się na podstawie zmiany statusu rekordu Return Authorization, na przykład z „Pending Approval” na „Pending Receipt”. | ||
| Dlaczego to ważne Śledzenie tego etapu akceptacji pomaga wykrywać wąskie gardła podczas wstępnej weryfikacji. Opóźnienia bezpośrednio wydłużają czas potrzebny na poinformowanie klienta i otrzymanie zwracanego produktu. Skąd pobrać Zdarzenie ustala się na podstawie notatek systemowych lub historii workflow rekordu ReturnAuthorization, a konkretnie zmiany pola „Status” na status oznaczający akceptację, na przykład „Pending Receipt”. Rejestrowanie Wykrycie zmiany statusu rekordu ReturnAuthorization na „Approved”. Typ zdarzenia inferred | |||
| Kontrola zwracanego produktu | To pojęciowe zdarzenie oznacza zakończenie fizycznej kontroli zwracanego produktu i ocenę jego stanu. NetSuite nie ma standardowego obiektu „Inspection”, dlatego zdarzenie zwykle ustala się na podstawie pola niestandardowego lub zmiany statusu w Return Authorization albo Item Receipt. | ||
| Dlaczego to ważne Kontrola często stanowi poważne wąskie gardło. Śledzenie czasu jej zakończenia pomaga analizować wydajność pracowników, spójność decyzji i wpływ tego etapu na późniejszą akceptację refundacji. Skąd pobrać Wymaga analizy systemu. Zdarzenie można ustalić na podstawie zmiany niestandardowego pola „Inspection Status” w rekordzie ReturnAuthorization. Możliwe też, że kontrola odbywa się poza systemem i nie jest rejestrowana. Rejestrowanie Zdarzenie ustala się na podstawie zmiany niestandardowego pola statusu w Return Authorization lub Item Receipt. Typ zdarzenia inferred | |||
| Odrzucenie autoryzacji zwrotu | To decyzja o odrzuceniu zgłoszenia zwrotu, często z powodu niezgodności z zasadami. Zdarzenie ustala się na podstawie zmiany statusu rekordu Return Authorization na „Rejected” lub „Closed”, bez dalszego przetwarzania. | ||
| Dlaczego to ważne Analiza odrzuconych zgłoszeń pozwala ustalić częste przyczyny niezgodności z zasadami zwrotów. Wnioski mogą pomóc w komunikacji z klientami i doprecyzowaniu zasad. To istotne odstępstwo od standardowego przebiegu procesu. Skąd pobrać Zdarzenie ustala się na podstawie notatek systemowych lub historii workflow rekordu ReturnAuthorization, gdy pole „Status” zmienia się na końcowy status „Rejected”. Rejestrowanie Wykrycie zmiany statusu rekordu ReturnAuthorization na „Rejected”. Typ zdarzenia inferred | |||
| Powiadomienie klienta | To wysłanie klientowi powiadomienia o ważnej zmianie statusu, na przykład o akceptacji, otrzymaniu produktu lub realizacji refundacji. Zdarzenie zwykle ustala się na podstawie znacznika czasu wiadomości e-mail wygenerowanej przez system i zapisanej w zakładce komunikacji rekordu. | ||
| Dlaczego to ważne Terminowa komunikacja wpływa na zadowolenie klientów. Pomiar czasu między ważnym etapem a powiadomieniem klienta pomaga wykrywać luki w obsłudze. Skąd pobrać Wymaga analizy systemu. Zdarzenie można odczytać ze znacznika czasu wysłanej wiadomości e-mail lub notatki użytkownika w podzakładce Communication rekordu ReturnAuthorization lub CreditMemo. Rejestrowanie Znacznik czasu wiadomości e-mail lub wpisu w dzienniku komunikacji powiązanego ze sprawą. Typ zdarzenia inferred | |||
| Rozliczenie noty kredytowej | To alternatywa dla zwrotu gotówki: nota kredytowa jest rozliczana z nieopłaconą fakturą klienta. Zdarzenie ustala się na podstawie powiązania „Applied To” w Credit Memo, które wskazuje, że kredyt został wykorzystany. | ||
| Dlaczego to ważne Rozróżnienie zwrotów gotówkowych i rozliczeń kredytowych jest ważne w analizie finansowej. Ta ścieżka oznacza inny sposób zakończenia procesu niż bezpośrednia refundacja. Skąd pobrać Zdarzenie ustala się na podstawie notatek systemowych lub powiązanych rekordów CreditMemo, a konkretnie powiązania z transakcją Invoice w celu zmniejszenia salda klienta. Rejestrowanie Wykrycie rozliczenia CreditMemo z transakcją Invoice. Typ zdarzenia inferred | |||
| Utworzenie zamówienia wymiany | To wariant wymiany, w którym zamiast refundacji tworzone jest nowe zamówienie sprzedaży dla klienta. Zdarzenie zwykle rejestruje się przez utworzenie Sales Order powiązanego z pierwotnym Return Authorization. | ||
| Dlaczego to ważne Śledzenie wymian jako osobnej ścieżki pozwala analizować preferencje klientów oraz sprawność wymiany w porównaniu z refundacją. To częsty i istotny wariant procesu. Skąd pobrać To zdarzenie odpowiada znacznikowi czasu utworzenia nowej transakcji SalesOrder. Powiązanie z ReturnAuthorization może znajdować się w polu standardowym lub niestandardowym, dlatego wymaga analizy systemu. Rejestrowanie Data utworzenia transakcji SalesOrder powiązanej z ReturnAuthorization. Typ zdarzenia explicit | |||
| Zatwierdzenie noty kredytowej | To formalna akceptacja noty kredytowej, często wymagana przy refundacjach na wysokie kwoty lub w ramach kontroli finansowej. Zdarzenie ustala się na podstawie zmiany statusu rekordu Credit Memo, która oznacza gotowość do rozliczenia lub wypłaty. | ||
| Dlaczego to ważne Jeśli wymagana jest akceptacja finansowa, ten etap może stać się poważnym wąskim gardłem. Analiza czasu jego trwania pomaga usprawnić kontrolę finansową bez opóźniania refundacji dla klientów. Skąd pobrać Zdarzenie ustala się na podstawie notatek systemowych rekordu CreditMemo, a konkretnie zmiany pola statusu akceptacji z „Pending Approval” na „Approved” lub „Open”. Rejestrowanie Wykrycie zmiany statusu transakcji CreditMemo na „Approved”. Typ zdarzenia inferred | |||
Instrukcje pobierania danych
Kroki
- Przejdź do tworzenia Saved Search: Zaloguj się do NetSuite. Otwórz Reports > New Search. Na stronie New Saved Search kliknij „Transaction”.
- Ustaw kryteria wyszukiwania: Na stronie konfiguracji Saved Search, w zakładce „Criteria” i podzakładce „Standard”, ustaw filtry, aby wyodrębnić rekordy Return Authorization:
TypetoReturn AuthorizationMain LinetoYes- Dodaj filtr
Date Createdi ustaw wybrany zakres dat, na przykład „ostatnie 3 miesiące”. To ważne, aby kontrolować ilość danych.
- Skonfiguruj kolumny wyników dla atrybutów: Otwórz zakładkę „Results”. Dodaj poniższe pola, które staną się atrybutami w dzienniku zdarzeń. W razie potrzeby użyj opcji „Custom Label”, aby nadać im czytelne nazwy.
- Identyfikator sprawy:
Document NumberlubTranID(Custom Label: ReturnCaseId) - Status zwrotu:
Status(Custom Label: ReturnAuthorizationStatus) - Osoba obsługująca:
Created Bylub odpowiednie pole niestandardowe (Custom Label: ProcessingAgent) - Dział:
Department(Custom Label: Department) - Typ zwrotu: pole niestandardowe, na przykład
[Your Return Reason Field](Custom Label: ReturnType) - Kwota zwrotu:
Amount(Custom Label: ActualRefundAmount)
- Identyfikator sprawy:
- Dodaj kolumny formuł dla timestampów zdarzeń: To najważniejszy krok. Dla każdej z 12 czynności dodaj kolumnę „Formula (Date/Time)”. Każda formuła używa instrukcji CASE, aby zwrócić timestamp tylko wtedy, gdy wystąpiło dane zdarzenie. Dokładne formuły dla poszczególnych czynności znajdziesz w sekcji „query”.
- Dodaj kolumny statyczne: Dodaj do wyników dwie kolumny „Formula (Text)”:
- Dla
SourceSystemużyj formuły:'NetSuite'. - Dla
LastDataUpdateużyj formuły zwracającej datę uruchomienia, na przykład{today}. Dokładny timestamp będzie odpowiadał godzinie eksportu.
- Dla
- Zapisz i wyeksportuj wyszukiwanie: Nadaj wyszukiwaniu opisową nazwę, na przykład „ProcessMind Returns Extraction”. Kliknij „Save & Run”. Po wyświetleniu wyników kliknij ikonę eksportu i wybierz „CSV”.
- Przekształć dane w dziennik zdarzeń: Wyeksportowany plik CSV będzie miał format szeroki: jeden wiersz na sprawę zwrotu i wiele kolumn z timestampami różnych zdarzeń. Trzeba przekształcić go w dziennik zdarzeń w formacie długim. Można użyć Microsoft Excel Power Query (Unpivot Columns), Pythona lub innego narzędzia do skryptów.
- Dla każdego wiersza pliku CSV utwórz wiele nowych wierszy, po jednym dla każdej niepustej kolumny z timestampem zdarzenia.
- W nowej tabeli powinny znaleźć się kolumny takie jak
ReturnCaseId,ActivityNameiEventTimestamp. WartośćActivityNamepochodzi z nagłówka pierwotnej kolumny z timestampem, na przykład „Return Authorization Created”, aEventTimestampz jej wartości.
- Przygotuj plik do przesłania: Upewnij się, że końcowy plik CSV zawiera wymagane nagłówki:
ReturnCaseId,ActivityName,EventTimestamp,SourceSystem,LastDataUpdateoraz zalecane atrybuty. Plik jest gotowy do przesłania do ProcessMind.
Konfiguracja
- Typ wyszukiwania: Saved Search musi być wyszukiwaniem typu
Transaction. - Zakres dat: Należy ustawić filtr zakresu dat dla pola
Date Createdw Return Authorization. Zalecany zakres od 3 do 6 miesięcy pozwala zachować kompletność danych i sprawne działanie wyszukiwania. - Główny filtr: Wyszukiwanie musi uwzględniać
TyperówneReturn AuthorizationorazMain LinerówneYes, aby zwrócić jeden rekord początkowy dla każdej sprawy zwrotu. - Pola niestandardowe: Dokładność pobierania, zwłaszcza zdarzeń pojęciowych, takich jak „Skontrolowano produkt”, oraz atrybutów, takich jak „Typ zwrotu”, zależy w dużej mierze od użycia pól niestandardowych w rekordach transakcji. W podanych formułach znajdują się symbole zastępcze, na przykład
{custbody_...}, które należy dostosować do konfiguracji NetSuite. - Uprawnienia użytkownika: Użytkownik uruchamiający wyszukiwanie musi mieć uprawnienia do wyświetlania wszystkich typów transakcji objętych analizą: Return Authorization, Item Receipt, Credit Memo, Customer Refund i Sales Order.
- Wydajność: Przy bardzo dużej liczbie zwrotów wyszukiwanie może działać wolno. Warto uruchamiać je poza godzinami szczytu lub zaplanować automatyczny eksport do szafki plików.
Przykładowe zapytanie config
This configuration represents the settings in the NetSuite Saved Search UI. The 'Results' tab should be configured with the following columns and formulas.
**Criteria Tab:**
* `Type` = `Return Authorization`
* `Main Line` = `true`
* `Date Created` = `[Specify Desired Date Range]`
**Results Tab (Columns):**
| Custom Label | Field / Formula Type | Formula / Field ID |
|---|---|---|
| `ReturnCaseId` | Formula (Text) | `{tranid}` |
| `SourceSystem` | Formula (Text) | `'NetSuite'` |
| `LastDataUpdate` | Formula (Date/Time) | `{today}` |
| `ReturnAuthorizationStatus` | Field | `Status` |
| `ProcessingAgent` | Field | `Created By` |
| `Department` | Field | `Department` |
| `ReturnType` | Field | `{custbody_return_reason}` |
| `ActualRefundAmount` | Field | `Amount` |
| `CycleTime` | Formula (Numeric) | `CASE WHEN {status} = 'Closed' THEN {lastmodifieddate} - {datecreated} ELSE NULL END` |
| `Activity_ReturnAuthorizationCreated` | Field | `Date Created` |
| `Activity_ReturnAuthorizationApproved` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Pending Receipt' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ReturnAuthorizationRejected` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Rejected' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ItemReceived` | Formula (Date/Time) | `{applyingtransaction.trandate}` |
| `Activity_ItemInspected` | Formula (Date/Time) | `CASE WHEN {custbody_inspection_status} = 'Complete' THEN {custbody_inspection_date} ELSE NULL END` |
| `Activity_CreditMemoCreated` | Formula (Date/Time) | `{createdfrom.trandate}` |
| `Activity_CreditMemoApproved` | Formula (Date/Time) | `MIN(CASE WHEN {createdfrom.systemnotes.newvalue} = 'Open' AND {createdfrom.systemnotes.field} = 'Status' THEN {createdfrom.systemnotes.date} ELSE NULL END)` |
| `Activity_RefundProcessed` | Formula (Date/Time) | `{createdfrom.appliedtotransaction.trandate}` |
| `Activity_CreditMemoApplied` | Formula (Date/Time) | `CASE WHEN {createdfrom.status} = 'Fully Applied' AND {createdfrom.appliedtotransaction.type} = 'Invoice' THEN {createdfrom.appliedtotransaction.date} ELSE NULL END` |
| `Activity_ExchangeOrderCreated` | Formula (Date/Time) | `{custbody_exchange_order.trandate}` |
| `Activity_CustomerNotified` | Formula (Date/Time) | `MAX({messages.messagedate})` |
| `Activity_ReturnAuthorizationClosed` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Closed' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` | Kroki
- Włącz SuiteAnalytics Connect: Upewnij się, że konto NetSuite ma licencję SuiteAnalytics Connect. Administrator musi włączyć tę funkcję w Setup > Company > Enable Features > Analytics.
- Nadaj uprawnienia użytkownikowi: Przypisz roli użytkownika łączącego się z systemem uprawnienie „SuiteAnalytics Connect”. Użytkownik musi też mieć uprawnienia do wyświetlania wszystkich odpytywanych rekordów, takich jak transakcje, pracownicy i klienci.
- Zainstaluj sterownik ODBC: Pobierz i zainstaluj sterownik NetSuite ODBC odpowiedni dla systemu operacyjnego ze strony pobierania SuiteAnalytics Connect w NetSuite.
- Skonfiguruj DSN: Utwórz nazwę źródła danych (DSN) na komputerze, na którym będzie uruchamiane zapytanie. Podaj Service Data Source, Server Hostname, Port, Role ID, Account ID i dane logowania.
- Połącz klienta SQL: Użyj klienta SQL, takiego jak DBeaver lub Microsoft SQL Server Management Studio, aby połączyć się z NetSuite za pomocą skonfigurowanego DSN.
- Przygotuj zapytanie SQL: Skopiuj podane zapytanie SQL do klienta. Zostało ono przygotowane do pobrania wszystkich najważniejszych zdarzeń w procesie obsługi zwrotów i refundacji.
- Dostosuj zapytanie: Zmień wartości zastępcze w zapytaniu. Co najmniej zaktualizuj zakres dat w wyrażeniu Common Table Expression (CTE)
ReturnAuthorizations. Możliwe, że trzeba też zmienić nazwy pól niestandardowych, takich jakCUSTBODY_RETURN_TYPE, lub konkretne wartości statusów, aby odpowiadały konfiguracji NetSuite. - Uruchom zapytanie: Wykonaj dostosowane zapytanie SQL na replice bazy danych NetSuite. Czas wykonania zależy od zakresu dat i ilości danych.
- Sprawdź i wyeksportuj dane: Po zakończeniu zapytania sprawdź, czy wyniki są poprawne. Wyeksportuj cały zestaw do pliku CSV.
- Przygotuj plik do przesłania: Upewnij się, że nagłówki w pliku CSV odpowiadają wymaganym atrybutom:
ReturnCaseId,ActivityName,EventTimestamp,SourceSystem,LastDataUpdateitd. Sprawdź, czy kolumnaEventTimestampma spójny format daty i godziny. Plik jest gotowy do przesłania do ProcessMind.
Konfiguracja
- Wymagania wstępne: Potrzebna jest licencja NetSuite z modułem dodatkowym SuiteAnalytics Connect. Użytkownik nawiązujący połączenie musi mieć rolę z uprawnieniem „SuiteAnalytics Connect” oraz dostępem do odczytu rekordów transakcji, podmiotów i pracowników.
- Konfiguracja źródła danych: Należy skonfigurować DSN (nazwę źródła danych) za pomocą sterownika NetSuite ODBC. Wymaga to Account ID, Role ID i danych logowania. W środowisku produkcyjnym adresem hosta usługi jest zwykle
odbcserver.netsuite.com. - Filtrowanie według zakresu dat: Należy koniecznie ustawić filtr zakresu dat w początkowym CTE wybierającym Return Authorization. Bez filtra zapytanie spróbuje pobrać dane o wszystkich zwrotach, co prawdopodobnie znacznie je spowolni lub spowoduje przekroczenie limitu czasu. Do wstępnej analizy zalecany jest zakres od 3 do 6 miesięcy.
- Główne typy transakcji: Zapytanie obejmuje kilka podstawowych typów transakcji: ReturnAuthorization, ItemReceipt, CreditMemo, CustomerRefund i SalesOrd (wymiany). Należy upewnić się, że proces korzysta z tych standardowych obiektów.
- Zależność od pól niestandardowych: Zdarzenia takie jak „Skontrolowano produkt” i atrybuty takie jak „Typ zwrotu” są często zapisywane w polach niestandardowych. W zapytaniu użyto symboli zastępczych, takich jak
CUSTBODY_INSPECTION_STATUSiCUSTBODY_RETURN_TYPE. Należy ustalić właściwe identyfikatory pól w systemie i odpowiednio zaktualizować zapytanie. - Wydajność: To złożone zapytanie zawiera wiele złączeń i rozbudowaną strukturę
UNION ALL. Aby ograniczyć wpływ na wydajność systemu, należy uruchamiać je poza godzinami szczytu. W przypadku bardzo dużych zbiorów danych warto pobierać dane w krótszych przedziałach czasu i łączyć wyniki.
Przykładowe zapytanie sql
WITH ReturnAuthorizations AS (
SELECT
T.TRANSACTION_ID AS ReturnCaseId,
T.TRANDATE
FROM
TRANSACTION T
WHERE
T.TYPE = 'ReturnAuthorization'
AND T.TRANDATE BETWEEN TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD') AND TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD')
)
SELECT
RA.ReturnCaseId AS "ReturnCaseId",
'Return Authorization Created' AS "ActivityName",
T.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION T
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON T.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Pending Receipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Rejected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE IN ('Rejected', 'Closed')
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Received' AS "ActivityName",
IR.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION IR
INNER JOIN TRANSACTION T_RA ON IR.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON IR.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE IR.TYPE = 'ItemReceipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Inspected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.CUSTBODY_INSPECTION_STATUS' AND SN.NEW_VALUE = 'Completed'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Created' AS "ActivityName",
CM.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION CM
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON CM.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.APPROVAL_STATUS' AND SN.NEW_VALUE = 'Approved'
UNION ALL
SELECT
RA.ReturnCaseId,
'Refund Processed' AS "ActivityName",
REF.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
ABS(REF.TOTAL) AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION REF
INNER JOIN TRANSACTION CM ON REF.APPLIED_TO_TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON REF.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE REF.TYPE = 'CustomerRefund'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Applied' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Fully Applied'
UNION ALL
SELECT
RA.ReturnCaseId,
'Exchange Order Created' AS "ActivityName",
SO.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION SO
INNER JOIN TRANSACTION T_RA ON SO.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SO.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SO.TYPE = 'SalesOrd'
UNION ALL
SELECT
RA.ReturnCaseId,
'Customer Notified' AS "ActivityName",
MSG.MESSAGE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM MESSAGES MSG
INNER JOIN TRANSACTION T ON MSG.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON MSG.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE MSG.INCOMING = 'F'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Closed' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE T.TYPE = 'ReturnAuthorization' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE LIKE '%Closed%'; Gotowi do rozpoczęcia?
Wykorzystajcie ten szablon danych, aby usprawnić obsługę zwrotów i refundacji. Zacznijcie optymalizować workflow w NetSuite, by zwiększyć efektywność i zadowolenie klientów.
Usprawnij obsługę zwrotów i refundacji, zwiększ efektywność NetSuite
Skróć czas obsługi zwrotów w NetSuite o 30%. Zacznij usprawniać operacje już dziś.
Karta kredytowa nie jest wymagana • Konfiguracja zajmuje kilka minut