Konfiguracja systemu reklamacji bez programisty jest w opisywanym wdrożeniu możliwa dla większości zmiennej części modułu, bo zapisano ją jako wpisy w słownikach. Zmiana wpisu nie wymaga nowej wersji programu. Domyślny termin rozpatrzenia i formularze rejestracji zostają po stronie programisty, a granica biegnie przez poziom potrzebnej wiedzy, nie przez ważność zmiany.
Listy wyboru zmienia administrator przyciskami Dopisz i Edycja
W opisywanym wdrożeniu zmienna część modułu reklamacji jest zapisana jako wpisy w tabelach konfiguracji, a nie w kodzie programu. Zmiana takiego wpisu nie wymaga nowej wersji programu. Tabela poniżej zestawia dwanaście zmian i dla każdej podaje miejsce zapisu oraz potrzebną wiedzę. Ostatnia kolumna mówi, czy zmiana wymaga nowej wersji programu.
| Co zmieniamy | Gdzie to jest zapisane | Potrzebna wiedza | Nowa wersja programu |
|---|---|---|---|
| Pozycja listy wyboru, na przykład żądanie klienta albo dział | wpis w słowniku z menu Słowniki | administrator aplikacji | nie |
| Nazwa, etap, kolor i kolejność statusu | słownik statusów | administrator aplikacji | nie |
| Kolor komórki z liczbą dni do terminu | słownik kolorów terminu | administrator aplikacji | nie |
| Pole wyszukiwarki Szukaj | słownik pól wyszukiwarki | administrator aplikacji, przy podpowiedziach osoba znająca SQL (zapytanie podpowiedzi to osobny wpis) | nie |
| Treść e-maila lub SMS-a | słownik szablonów | administrator aplikacji | nie |
| Szablon przypisany do etapu | wiersz menu z przyciskiem wiadomości | osoba znająca konfigurację menu | nie |
| Eksport do Excela | słownik eksportów (zapytanie i nazwa pliku) oraz wiersz menu uruchamiający eksport | osoba znająca SQL | nie |
| Treść kodu kreskowego lub QR | słownik kodów | osoba znająca SQL | nie |
| Pole formularza edycji (status, serwis) | definicja formularza w konfiguracji | osoba znająca konfigurację formularzy | nie |
| Domyślny termin i inne stałe przy rejestracji | procedura zapisu | programista | tak |
| Pole formularza rejestracji | skrypt formularza | programista | tak |
| Układ wydruku i raportów | raport na serwerze raportów | autor raportów | nie (zmiana raportu na serwerze raportów, wdrożenie raportu) |
Pełne menu działu reklamacji ma w sekcji Kartoteki pozycję Słowniki, która otwiera kilkanaście list. Konta zewnętrzne, czyli sklepu i partnera oraz serwisu spoza zakładu, mają okrojone menu bez tej pozycji. Czym jest skorowidz w programie, opisuje strona o skorowidzach.
Każda lista w menu Słowniki pokazuje wpisy jednego rodzaju. Na większości list przyciski Dopisz i Edycja otwierają formularz zdefiniowany w konfiguracji. Na listach rodzajów wady i wad przypisanych do produktu te same przyciski nazywają się Dodaj i Edytuj. Są tam między innymi żądania reklamującego i statusy.
Nowy słownik powstaje z wpisów konfiguracji. Są to definicja listy, definicja formularza, dwa przyciski paska i pozycja menu, razem cztery rodzaje wpisów. Program zostaje bez zmian, ale potrzebne jest kilka powiązanych wpisów naraz.
Listy wyboru w formularzach czytają słowniki przy otwieraniu pola. Żądanie reklamującego wybiera się ze słownika w formularzach rejestracji, składnik reklamacji ze słownika składników, a dział przy karcie pracownika ze słownika działów. Rodzaj wady pochodzi ze słownika wad zawężonego przypisaniami do produktu. Tę zależność opisuje tekst o rodzaju wady zależnym od produktu.
Kolory terminu i statusu są wpisami słownika
Kolor liczby dni do terminu pochodzi ze słownika, w którym kluczem jest liczba dni, a wartością nazwa koloru. Widok liczy dni do terminu, a lista koloruje komórkę z tą liczbą. Zmiana koloru we wpisie zmienia wygląd listy bez zmiany programu. Mechanizm od wiersza słownika do koloru komórki opisuje tekst o kolorze terminu reklamacji, a jego zapis w T-SQL pokazuje artykuł kolor z liczby dni w widoku.
Kolor statusu i etapu na listach pochodzi z pola Kolor wpisu w słowniku statusów. Status ma w tym samym wpisie etap, do którego należy, więc zmiana nazwy lub koloru statusu odbywa się w jednym wpisie. Dwie osie, etap i status, omawia tekst o etapie i statusie reklamacji.
Formularz słownika statusów ma siedem pól: Aktywne, Kod, Kod1 (drugi kod, który określa etap), Opis (nazwa statusu), Kolejność, Kolor i Uwagi. Kolor wpisuje się jako nazwa koloru. Pole Aktywne wyłącza wpis bez kasowania.
W menu modułu nie ma osobnej pozycji dla słownika kolorów terminu. Taki wpis edytuje administrator aplikacji w ogólnym edytorze słowników z konsoli administratora, który jest standardem produktu. Zmiana wpisu nie wymaga programisty.
Wyszukiwarka i eksporty do Excela składają się z wpisów
Wyszukiwarka Szukaj składa się z pól zapisanych jako wpisy słownika. Wpis podaje podpis pola i nazwę parametru. Jeśli pole ma podpowiedzi, wskazuje też osobne zapytanie podpowiedzi zapisane w tabeli zapytań. Parametr z wyszukiwarki staje się warunkiem na kolumnie listy o tej samej nazwie, więc nowe pole wymaga kolumny o odpowiedniej nazwie w liście wynikowej. Działanie ekranu opisuje tekst o wyszukiwaniu reklamacji po telefonie i e-mailu.
Każdy eksport do Excela zapisano jako wpis słownika: zawiera zapytanie SQL z limitem wierszy oraz nazwę pliku. W nazwie pliku stoi znacznik loginu, który system zamienia na login osoby wykonującej eksport, a wykonanie eksportu trafia do dziennika. Kolumny eksportu zmienia się przez zmianę zapytania we wpisie.
Eksport potrzebuje też wpisu menu, który go uruchamia. Zapytanie SQL we wpisie powinna edytować osoba znająca SQL, więc ten wiersz tabeli ma inny poziom wiedzy niż listy wyboru, choć tak samo nie wymaga nowej wersji programu.
Treść wiadomości do klienta zmienia się w szablonie
Treść wiadomości do klienta zapisano we wpisach słownika: temat i treść e-maila oraz treść SMS-a. W treści specjalne znaczniki wstawiają wartość pola z wybranej tabeli i rekordu. Wśród znaczników są też podział wiersza i odnośnik. Który znacznik działa w jakim rodzaju wiadomości, opisuje tekst o szablonach wiadomości do klienta.
Szablon wskazuje też, skąd wziąć adres e-mail albo numer telefonu odbiorcy. Wiadomość nadal wysyła pracownik z szablonu, a nie system sam z siebie.
Pasek przycisków każdej listy to wiersze menu przypisane do tej listy. Przycisk wiadomości wskazuje szablon po nazwie, więc szablon przypisany do etapu zmienia się we wpisie menu, a nie w kodzie. Wymaga to osoby znającej konfigurację menu.
Kod kreskowy zależy od wpisu, a układ wydruku od raportu
Kod kreskowy i kod QR na wydruku zapisano jako wpisy słownika. Wpis zawiera typ kodu i klucz rekordu oraz wskazanie, skąd wziąć treść: tabelę z kolumną albo wyrażenie. Obraz kodu powstaje przy pierwszym wydruku dokumentu i jest zapamiętany. Treść kodu zmienia się we wpisie, a miejsce kodu na kartce wynika z raportu wydruku.
Wyrażenie we wpisie wykonuje się jako zapytanie SQL, więc powinna je edytować tylko osoba znająca SQL. Wydruk protokołu przyjęcia i raporty statystyczne to raporty uruchamiane na serwerze raportów, a nie wpisy słownika. Zmiana ich układu wymaga narzędzia do edycji raportów.
Procedura zapisu i formularze rejestracji zostają po stronie programisty
Formularze edycji, takie jak zmiana statusu i formularz serwisowy, a także formularze słowników, są definiowane w konfiguracji: pola z podpisami oraz wymagalność z podpowiedziami. Trzy formularze rejestracji reklamacji (pierwszy dla działu reklamacji, drugi dla partnera sprzedaży, trzeci dla klienta końcowego) są skryptami. Zmiana ich pól wymaga programisty. Budowę tych trzech wejść opisuje tekst o jednej tabeli i trzech wejściach do systemu.
Domyślny termin rozpatrzenia, czternaście dni, a także typ i rodzaj nadawane nowej reklamacji są stałymi w procedurze zapisu. Ich zmiana jest zmianą procedury, więc wymaga programisty i wdrożenia nowej wersji.
Zmiana wpisu w słowniku zmienia zachowanie modułu bez nowej wersji programu, ale reguła zaszyta w procedurze zapisu zmienia się tylko razem z programem.
Podział na trzy poziomy wiedzy, od administratora aplikacji przez osobę znającą SQL do programisty, to nasza ocena na podstawie konstrukcji konfiguracji, a nie opis pracy zespołu producenta. Ogólne zasady administracji programem opisuje strona o administracji programem reklamacji, a kryteria wyboru między konfiguracją a kodem strona o zmianach w programie na zamówienie.
Jeden dzień administratora (przykład)
Przykład z fikcyjnymi danymi. Partner Testowy prosi o dodatkowy status, który pokazuje, że reklamacja czeka na zdjęcia. Administrator otwiera Słowniki i wybiera Statusy. Przyciskiem Dopisz tworzy wpis „Status przykładowy C” z etapem W realizacji i wpisaną nazwą koloru. Status trafia na listę wyboru.
Przy okazji administrator zmienia treść SMS-a o przyjęciu zgłoszenia, żeby zawierała numer RMA, na przykład 7C3A-1E94-B20F. Prośba, by domyślny termin rozpatrzenia z czternastu dni skrócić do dziesięciu, trafia do programisty, bo termin wylicza procedura zapisu. Zmianę kodu na wydruku reklamacji 2026-10-0007 administrator zleca osobie znającej SQL, bo treść kodu jest wyrażeniem w słowniku kodów.
Pytania przy podziale odpowiedzialności
Poniższe pytania nie opisują wdrożenia producenta. To lista, od której zaczynamy rozmowę o utrzymaniu systemu reklamacji w Twojej firmie.
- Częstotliwość. Które listy wyboru w Twoim procesie zmieniają się częściej niż raz na kwartał i kto ma je prowadzić po wdrożeniu?
- Treść wiadomości. Czy zmiany treści wiadomości do klienta mają przechodzić akceptację działu prawnego, zanim trafią do szablonu?
- Liczby. Jakie liczby w procesie, na przykład terminy i progi, traktujesz jako dane do zmiany przez administratora, a jakie jako regułę zmienianą tylko przez programistę?
- Uprawnienia. Kto ma dostać prawo do edycji słowników, a kto tylko do przeglądania, i czy zmiana wpisu ma zostawiać ślad?
Odpowiedzi wyznaczają, które zmiany zostaną po stronie administratora, a które trafią do programisty. Zakres ustalamy z Twoją firmą przy analizie wdrożeniowej.