RMA system - architektura aplikacji i integracje

RMA system - warstwy aplikacji

Od strony technicznej system RMA to aplikacja webowa, w której każda reklamacja jest rekordem z numerem i statusem, a każda zmiana trafia do historii. Według opisu producenta Studio RMA.net działa na platformie ASP.NET, a dane przechowuje w bazie Microsoft SQL Server. Interfejs użytkownika opiera się na HTML5, CSS3 i bibliotece jQuery, dzięki czemu ten sam ekran działa na komputerze oraz na urządzeniach mobilnych.

Podział na warstwy ma znaczenie praktyczne. Logika przejść między statusami i reguły uprawnień muszą leżeć po stronie serwera i bazy, bo interfejs w przeglądarce można obejść. Warstwa prezentacji odpowiada za czytelność i szybkość pracy, a nie za bezpieczeństwo danych.

Moduły mobilne mają według opisu producenta umożliwiać serwisantom rejestrowanie zgłoszeń, aktualizację statusów napraw i przeglądanie historii serwisowej urządzeń. Ogólną architekturę aplikacji uruchamianych w przeglądarce opisuje tekst o aplikacji webowej, a samą platformę przedstawia przegląd ASP.NET w dokumentacji Microsoft Learn.

Model danych sprawy reklamacyjnej

Sprawa reklamacyjna rozkłada się na kilka tabel. Nagłówek przechowuje stan bieżący, pozycje opisują reklamowane towary, a osobna tabela historii dopisuje wiersz przy każdej zmianie statusu. Taki podział pozwala odtworzyć przebieg sprawy w dowolnym momencie i policzyć czas spędzony w każdym stanie.

Historia zmian w bazie

Historię statusów można prowadzić ręcznie, dopisując wiersz w procedurze zmiany, albo powierzyć ją mechanizmowi bazy. Tabele czasowe (temporal tables), dostępne w SQL Server od wersji 2016, zapisują poprzednie wersje wierszy automatycznie i pozwalają zapytać o stan sprawy z dowolnej chwili. Ich opis znajduje się w dokumentacji tabel czasowych. Ręczna historia daje z kolei pełną kontrolę nad tym, kto i z jakim uzasadnieniem zmienił status, dlatego w systemach z obiegiem decyzji stosuje się oba podejścia obok siebie.

Atrybuty definiowane przez użytkownika

Firmy reklamują różny sprzęt, więc lista pól opisujących urządzenie nie jest wspólna. Według opisu producenta użytkownicy mogą samodzielnie definiować własne atrybuty reklamowanego sprzętu oraz niestandardowe statusy napraw. W bazie robi się to zwykle modelem słownikowym, w którym definicja atrybutu i jego wartość leżą w osobnych tabelach.

CREATE TABLE dbo.AtrybutDef (
    Id    INT IDENTITY(1,1) PRIMARY KEY,
    Kod   VARCHAR(30)  NOT NULL UNIQUE,
    Nazwa NVARCHAR(80) NOT NULL,
    Typ   CHAR(1)      NOT NULL  -- T tekst, L liczba, D data
);

CREATE TABLE dbo.AtrybutWartosc (
    IdSprawy   INT NOT NULL,
    IdAtrybutu INT NOT NULL REFERENCES dbo.AtrybutDef (Id),
    Wartosc    NVARCHAR(200) NOT NULL,
    CONSTRAINT PK_AtrybutWartosc PRIMARY KEY (IdSprawy, IdAtrybutu)
);

Przykład jest uproszczony i ma charakter poglądowy. Poniższe zestawienie porównuje trzy sposoby przechowywania cech, które różnią się dla każdej grupy towarów.

Reguła: cechę urządzenia dodaje się rekordem w słowniku, a nie kolumną w tabeli, żeby zmiana wymagań nie wymuszała wdrożenia nowej wersji kodu.

Dwa obiegi: rękojmia i gwarancja

Zgłoszenia obsługiwane w systemie RMA dotyczą najczęściej dwóch podstaw prawnych. Dobrze skonfigurowany system rozróżnia je już przy rejestracji i przypisuje do każdej inny obieg dokumentów oraz inny licznik terminu SLA. Pracownik od razu wie, czy sprawę rozpatruje jako sprzedawca odpowiadający z rękojmi, czy jako gwarant realizujący warunki karty gwarancyjnej.

Poniższa tabela pokazuje, które parametry obiegu zależą od podstawy roszczenia. Konkretne terminy i zakres wynikają z przepisów oraz z karty gwarancyjnej, więc system przechowuje je jako konfigurację.

Rozdzielenie ścieżek na etapie rejestracji ogranicza pomyłki i przyspiesza kolejne kroki. Ma też znaczenie, gdy w sprawie uczestniczy kilka podmiotów, bo wtedy z zapisu widać, kto odpowiada za decyzję.

Numer RMA i etykieta przesyłki

Numer RMA łączy fizycznie odsyłany towar z rekordem w systemie. Klient oznacza przesyłkę tym numerem, najczęściej w formie etykiety z kodem kreskowym lub kodem QR generowanym automatycznie. Pracownik serwisu albo magazynu otwiera paczkę i skanuje etykietę, a system od razu pokazuje właściwą sprawę, bez szukania po nazwisku klienta.

Numer generuje się w bazie, a nie w aplikacji, bo baza jako jedyna widzi wszystkie równoległe zapisy. Obiekt SEQUENCE zwraca kolejne wartości bez blokowania tabeli spraw, a sposób jego działania opisuje dokumentacja CREATE SEQUENCE. Przed zapisem numeru w formacie tekstowym wartość pobiera się do zmiennej, ponieważ w niektórych konstrukcjach zapytania odwołanie do sekwencji jest ograniczone.

CREATE SEQUENCE dbo.SeqNumerRma AS INT START WITH 1 INCREMENT BY 1;

DECLARE @n INT = NEXT VALUE FOR dbo.SeqNumerRma;
SELECT CONCAT('RMA/', YEAR(SYSDATETIME()), '/', FORMAT(@n, '000000')) AS NumerRma;

Sekwencja nie cofa numerów po wycofaniu transakcji, więc w numeracji mogą powstać luki. Numer ma jednoznacznie identyfikować sprawę, a nie dokumentować liczbę zgłoszeń. Dobór symboliki kodu opisuje tekst o kodach kreskowych w magazynie, a znaczenie samego numeru wyjaśnia artykuł numer RMA - co to jest i do czego służy.

Integracja z WMS i ERP

System RMA nie działa w oderwaniu od reszty infrastruktury firmy. Po zatwierdzeniu reklamacji może zainicjować zwrot magazynowy albo wystawienie korekty faktury, a pracownik serwisu widzi historię zakupów klienta bez przełączania się między aplikacjami. Taka integracja usuwa ręczne przepisywanie danych i skraca czas obsługi.

Największym ryzykiem integracji jest powtórne wykonanie tej samej operacji, na przykład dwóch korekt tej samej faktury po ponowieniu żądania. Ogranicza je klucz idempotentności, czyli stały identyfikator operacji przekazywany razem z żądaniem. Rolę takiego klucza dobrze pełni numer RMA z dopisanym rodzajem operacji. Nagłówek o nazwie Idempotency-Key jest stosowany w wielu interfejsach API, ale nie jest standardem, więc trzeba sprawdzić, czy przyjmuje go system docelowy.

var zadanie = new HttpRequestMessage(HttpMethod.Post, "https://erp.example.com/api/korekty");
zadanie.Headers.Add("Idempotency-Key", numerRma + "-korekta");
zadanie.Content = new StringContent(json, Encoding.UTF8, "application/json");

var odpowiedz = await klient.SendAsync(zadanie);
odpowiedz.EnsureSuccessStatusCode();

Adres i nagłówek w przykładzie są poglądowe. Zasady łączenia magazynu z innymi systemami opisuje tekst o integracji systemów magazynowych, a dokumenty, które powstają przy przyjęciu zwrotu, omawia strona o dokumentach magazynowych. Ogólne wzorce łączenia aplikacji zebrano w artykule o integrowaniu aplikacji webowych.

Interfejs API w integracjach

Producent opisuje, że Studio RMA.net udostępnia API REST do integracji z ERP oraz z platformami zewnętrznymi. Interfejs tego typu opiera się na zasobach adresowanych przez URL i na standardowych metodach HTTP, więc dowolny system zdolny wysłać żądanie może zarejestrować zgłoszenie lub odczytać status sprawy. Poniższy układ jest przykładem dobrej praktyki, a nie opisem konkretnego produktu.

Kody odpowiedzi niosą informację, którą system wołający potrafi przetworzyć bez czytania komunikatu. Kod 409 mówi, że stan sprawy nie pozwala na zmianę, a kod 422 wskazuje błąd w danych, który da się poprawić. Uwierzytelnienie odbywa się tokenem przypisanym do konta technicznego z ograniczonymi uprawnieniami, tak aby integracja ze sklepem nie mogła zmieniać cudzych spraw.

Wydajność listy spraw i współbieżność

Lista otwartych spraw to widok, który pracownicy odświeżają przez cały dzień, więc jego koszt ma znaczenie. Zamknięte reklamacje stanowią z czasem większość tabeli, ale w kolejce pracy nie biorą udziału. Indeks filtrowany obejmuje wyłącznie sprawy otwarte, jest mniejszy od pełnego indeksu i szybciej się aktualizuje. Zasady jego zakładania opisuje dokumentacja indeksów filtrowanych.

CREATE NONCLUSTERED INDEX IX_Reklamacje_Otwarte
ON dbo.Reklamacje (DataPrzyjecia)
INCLUDE (NrRma, Status)
WHERE Status <> 'ZAM';

Drugim problemem jest jednoczesna edycja tej samej sprawy przez dwóch pracowników. Blokowanie rekordu na czas otwarcia karty wstrzymuje pracę innych, dlatego stosuje się kontrolę optymistyczną. Kolumna typu ROWVERSION zmienia wartość przy każdej modyfikacji wiersza, a polecenie UPDATE porównuje wersję odczytaną z bieżącą. Przy rozbieżności zapis się nie wykonuje, a użytkownik dostaje komunikat o konieczności odświeżenia karty.

Raportowanie i analiza przyczyn

Gromadzenie zgłoszeń w jednej bazie pozwala pytać, które produkty generują najwięcej reklamacji i z jakich dostaw pochodzą. Dział jakości może na tej podstawie zastosować metodę 8D, czyli ustrukturyzowaną analizę przyczyn źródłowych w ośmiu krokach, zamiast reagować na każde zgłoszenie z osobna. Takiej wiedzy nie da się uzyskać z rozproszonej korespondencji.

SELECT TOP (10) k.Kod, k.Nazwa, COUNT(*) AS LiczbaZgloszen
FROM dbo.Reklamacje AS r
JOIN dbo.Kartoteka AS k ON k.Id = r.IdTowaru
WHERE r.DataPrzyjecia >= DATEADD(MONTH, -6, SYSDATETIME())
GROUP BY k.Kod, k.Nazwa
ORDER BY COUNT(*) DESC;

Zapytanie zwraca dziesięć towarów o największej liczbie zgłoszeń w ostatnich sześciu miesiącach. Wynik warto zestawić ze sprzedażą, ponieważ produkt sprzedawany w dużych ilościach będzie miał więcej reklamacji bez względu na jakość. Różnicę między pracą ręczną a pracą na danych z systemu pokazuje tabela.

Raporty przygotowuje się zwykle w usługach raportowania, a ich budowę opisuje tekst o Microsoft SQL Reporting Services. Wpływ danych reklamacyjnych na poprawę wyrobów omawia artykuł o zarządzaniu reklamacjami a jakość produktów.

Konfiguracja systemu i ślad zmian

Każda firma ma własne procedury, więc system musi dać się dostosować bez ingerencji dostawcy w kod. Według opisu producenta można definiować niestandardowe statusy napraw i mapować etapy cyklu życia reklamacji. Dostosowanie działa jak zestaw parametrów: to firma decyduje o kolejności statusów, a nie odwrotnie.

Przy ocenie rozwiązania warto sprawdzić cztery rzeczy.

• Konfiguracja statusów i pól - zmiana bez udziału dostawcy i bez wdrażania nowej wersji.
• Integracje - gotowe połączenia z WMS oraz ERP, które ograniczają ręczne przepisywanie.
• Kontrola dostępu według ról - użytkownik widzi tylko sprawy i pola dostępne dla jego grupy.
• Pełna historia zmian - w każdej sprawie widać, kto i kiedy zmienił status lub dane.

Sprawę zapisu zdarzeń warto rozstrzygnąć na etapie projektu, bo dopisanie historii do gotowej bazy jest trudne. Podobnie z kopiami zapasowymi: harmonogram i sprawdzanie odtworzenia opisuje dokumentacja tworzenia i odtwarzania kopii baz SQL Server, a środowiska testowe i produkcyjne powinny mieć osobne bazy, aby próby konfiguracji nie dotykały danych klientów. Wersję demonstracyjną można przejrzeć w serwisie demo reklamacji, a opis funkcji aplikacji znajduje się na stronie Studio RMA.net. Rozwiązanie dostępne w przeglądarce opisuje także tekst o systemie RMA online, a przegląd zastosowań w firmie zawiera strona Studio RMA.net.