W opisywanym wdrożeniu wejścia do systemu reklamacji to trzy formularze o różnych polach i uprawnieniach. Wszystkie wołają tę samą procedurę zapisu z innymi stałymi i zapisują reklamację jako wiersz jednej tabeli dokumentów. Różnice między grupami zgłaszających wynikają z menu i definicji list, a nie z kopii danych.
Jedna tabela dokumentów zamiast trzech
Każda reklamacja jest w opisywanym wdrożeniu wierszem jednej tabeli dokumentów reklamacji, niezależnie od tego, kto ją zgłosił. Dział IT nie utrzymuje więc osobnego zbioru dla każdej grupy zgłaszających. Zgłoszenie pracownika i zgłoszenie klienta bez konta leżą w tej samej tabeli, a różni je tylko to, z jakimi stałymi trafiły do zapisu.
Numer RMA dla klienta powstaje w każdej z trzech ścieżek od razu, przy rejestracji. Każde wejście ustawia też ten sam początek cyklu: status Nowa i etap Nowa. Dalej obowiązuje jeden słownik statusów, który steruje listami. Jak etap i status prowadzą sprawę między listami, opisuje tekst o etapie i statusie reklamacji.
Ogólne ujęcie jednej bazy dla wszystkich działów znajdziesz na stronie o jednej bazie reklamacji. Tutaj pokazujemy, jak jedna tabela obsługuje trzy wejścia w jednym wdrożeniu i co dział IT widzi po stronie konfiguracji.
Trzy formularze o różnych polach i uprawnieniach
Własne formularze są trzy: jeden dla działu reklamacji i serwisu, drugi dla partnera sprzedaży, trzeci dla klienta bez konta. Każdy ma inny zestaw pól i inne uprawnienia. Podstawowe różnice zbiera tabela, a pod nią opisujemy, co każda grupa widzi na ekranie.
| Wejście | Firma w formularzu | Stan po zapisie | Numer reklamacji | Gdzie sprawa się pojawia |
|---|---|---|---|---|
| Formularz pracownika | wybór z listy | przyjęte | nadawany od razu z licznika | lista Przyjęte Nowe |
| Formularz partnera sprzedaży | zablokowana na zalogowanego kontrahenta | przyjęte | nadawany od razu z licznika | lista reklamacji partnera |
| Formularz publiczny klienta | brak pola | stan roboczy | pusty do przyjęcia przez pracownika | lista Oczekujące RMA |
Pracownik wybiera firmę z listy z wyszukiwaniem. W trybie edycji widzi dodatkowo sekcje Składniki i Komunikacja. Po zapisie sprawa jest przyjęta i ma numer reklamacji z licznika miesięcznego, więc od razu leży na liście Przyjęte Nowe.
W formularzu partnera sprzedaży pole Firma jest ustawione na zalogowanego kontrahenta i zablokowane. Reszta pól ma inny zestaw niż u pracownika. Tę ścieżkę od strony sklepu opisuje tekst o reklamacjach partnera sprzedaży.
Formularz publiczny nie ma pola Firma. Ma za to kod PIN przepisywany z ekranu i zgodę na przetwarzanie danych. Oba elementy należą do formularza: nie opisujemy ich jako weryfikacji tożsamości ani jako dowodu zgody. Zgłoszenie z Internetu zapisuje się w stanie roboczym, bez numeru reklamacji, i trafia na osobną listę Oczekujące RMA, gdzie czeka na przyjęcie przez pracownika. Pola i kolejność kroków tego formularza opisuje tekst o formularzu dla klienta bez konta, a pracę z listą Oczekujące RMA tekst o kolejce zgłoszeń z Internetu.
Procedura jest wspólna, a wejścia różnią się stałymi
Wszystkie trzy formularze wołają tę samą procedurę zapisu. Formularz nie ma własnej wersji reguł: przekazuje procedurze zestaw stałych, a o reszcie decyduje procedura. Różni je cztery stałe.
- Oznaczenie rejestru dokumentu. Inne dla zgłoszenia z Internetu niż dla zgłoszenia pracownika i partnera, więc to ono odróżnia wejście publiczne od pozostałych.
- Znacznik stanu roboczego. Zgłoszenie z Internetu zapisuje się w stanie roboczym, zgłoszenie pracownika i partnera od razu jako przyjęte.
- Numer reklamacji. Pracownik i partner dostają numer z licznika miesięcznego przy zapisie, a zgłoszenie z Internetu zostaje bez numeru do czasu przyjęcia.
- Oddział i magazyn. Para stałych, którą każde wejście przekazuje procedurze obok pozostałych.
Reguły zapisane w procedurze zmieniają się w jednym miejscu dla wszystkich trzech wejść naraz. Przykładem jest domyślny termin rozpatrzenia, czternaście dni. Jak ten termin zamienia się w kolor liczby dni na liście, opisuje tekst o kolorze terminu reklamacji.
Trzy wejścia to trzy formularze i jedna procedura zapisu, więc reguła zapisana w procedurze obowiązuje wszystkich naraz.
Role oglądają ten sam zbiór przez różne listy
Cztery role aplikacyjne korzystają z jednej konfiguracji menu. Wszystkie leżą w jednej tabeli menu i odróżnia je kolumna roli. Ogólny podział ról w programie opisuje strona o rolach użytkowników, a poniżej widać, jak wygląda on w tym wdrożeniu.
- Pełna obsługa. Dział reklamacji i serwis, ze wszystkimi listami.
- Serwis zewnętrzny. Lista reklamacji w serwisie i archiwum, bez przycisków edycji i zmiany statusu.
- Partner z własnym formularzem. Listy z filtrem kontrahenta.
- Partner ze standardowym formularzem. Te same listy z filtrem kontrahenta.
W tabeli zestawień każda lista ma swoją definicję. Definicja ma cztery elementy: zapytanie, kolumny, kolory i przyciski. Listy partnera sprzedaży to osobne definicje oparte na tym samym widoku dokumentów, z dodatkowym warunkiem: identyfikator kontrahenta zalogowanego użytkownika i magazyn. Ten sam identyfikator zamyka pole Firma w formularzu. Kontrola leży więc w formularzu i w warunkach list.
Partner widzi własne reklamacje tylko do odczytu. Jego listy mają przyciski Podgląd i Wydruk, a nie mają Edycji ani zmiany statusu. Role różnią się zatem tym, które definicje list dostają w menu, a nie tym, w której tabeli leżą dane.
Czwarta ścieżka korzysta ze standardu produktu
Obok trzech własnych formularzy działa czwarta ścieżka: standardowy formularz produktu Studio RMA.net, którego używa jedna z ról partnerskich. Zapisuje on przez wariant procedury zgodny ze standardowym formularzem, a nie przez procedurę trzech formularzy własnych. Obie procedury zapisują do tej samej tabeli dokumentów.
To rozróżnienie wraca w ostatniej części tekstu jako pytanie o aktualizacje: dostosowania wdrożenia i standard produktu to dwie osobne ścieżki zapisu.
Co zmienia się w jednym miejscu, a co osobno dla każdego wejścia
Menu wskazuje formularz dla każdej roli, więc przypisanie formularza do roli to zmiana wiersza menu, a nie zmiana programu. Podział jest prosty i da się go zapisać w dwóch punktach.
- W jednym miejscu dla wszystkich wejść. Reguły zapisane w procedurze, na przykład domyślny termin. Zmiana obowiązuje od następnego zgłoszenia.
- Osobno dla każdego wejścia. Pola i uprawnienia formularza oraz jego przypisanie do roli w menu.
To, co administrator aplikacji zmienia w słownikach bez nowej wersji programu, a co zostaje programiście, opisuje osobny tekst: co administrator zmieni sam w module reklamacji.
Jeden dzień z trzema zgłoszeniami (przykład)
Przykład z fikcyjnymi danymi. Dział IT opisywanego producenta ma trzy grupy zgłaszających. Pierwszą jest pracownik działu reklamacji, drugą Partner Testowy, trzecią klient bez konta.
Pracownik wybiera firmę z listy z wyszukiwaniem i zapisuje reklamację. Procedura zapisuje ją jako przyjętą z numerem reklamacji 2026-10-0007, więc sprawa od razu leży na liście Przyjęte Nowe. Partner Testowy zgłasza w swoim formularzu, w którym firma jest już ustawiona i zablokowana. Sprawa pojawia się od razu na jego liście reklamacji, z przyciskami Podgląd i Wydruk.
Klient Testowy zgłasza przez formularz publiczny, przepisuje kod PIN z ekranu i zaznacza zgodę. Dostaje numer RMA 7C3A-1E94-B20F, ale zgłoszenie nie ma jeszcze numeru reklamacji. Czeka na liście Oczekujące RMA, aż pracownik je przyjmie. Gdy dział IT zmienia domyślny termin w procedurze, zmiana obowiązuje wszystkie trzy wejścia od następnego zgłoszenia.
Pytania przed budową podobnych wejść
Poniższe pytania nie opisują wdrożenia producenta. To lista, od której zaczynamy rozmowę o wejściach w Twojej organizacji.
- Grupy. Którzy zgłaszający w Twojej organizacji potrzebują osobnego formularza, a którym wystarczy ten sam formularz z innymi uprawnieniami?
- Poczekalnia. Czy wszystkie wejścia mają dopisywać reklamacje do jednej tabeli, czy część ma najpierw trafiać do poczekalni?
- Reguły wspólne. Gdzie w Twoim systemie leżą reguły wspólne dla wejść i kto może je zmieniać?
- Standard. Jak odróżnisz dostosowania własne od standardu produktu przy kolejnej aktualizacji?
Odpowiedzi wyznaczają liczbę formularzy i zakres list. Pracę zaczynamy od analizy przedwdrożeniowej, a zakres ustalamy z Twoją firmą.