W skrócie
Według dokumentacji starszej wersji dane firmy przeznaczone do dokumentów, czyli nazwę, adres, telefon i NIP, administrator wpisuje w pozycji Parametry modułu administratora. Konto pocztowe i połączenie z bazą SQL leżą w pliku web.config na serwerze, więc ich zmiana wymaga dostępu do serwera, a nie tylko konta w programie. Opisy programu podają różne miejsca ustawień bramki SMS i poczty wychodzącej, dlatego ustalamy je przy wdrożeniu. Od konta pocztowego zależy, czy klient dostanie odpowiedź na reklamację w terminie.
Parametry w module administratora
Według dokumentacji starszej wersji moduł administratora ma pięć pozycji: Numeracja, Użytkownicy, Parametry, Dziennik i Skorowidze. W pozycji Parametry administrator wpisuje dane firmy przeznaczone do dokumentów, czyli nazwę, adres, telefon i NIP. Ta sama dokumentacja wymienia sekcję Parametry globalne, do której wprowadza się dane z licencji. Pozostałe pozycje modułu opisujemy przy administracji programem do reklamacji.
Część ustawień nie trafia jednak do parametrów, bo wymaga ochrony przed łatwym dostępem. Dokumentacja przenosi je do pliku web.config na serwerze, a opisy programu różnią się w sprawie poczty wychodzącej i bramki SMS. Zestawiamy ustawienia, o których mówią źródła, z miejscem ich zapisu i osobą, która je zmienia:
| Ustawienie | Miejsce zapisu według źródeł | Kto je zmienia |
|---|---|---|
| Dane firmy: nazwa, adres, telefon, NIP | Pozycja Parametry w module administratora | Użytkownik z rolą Administrator |
| Dane licencji | Sekcja Parametry globalne | Użytkownik z rolą Administrator |
| Konto pocztowe | Plik web.config na serwerze | Osoba ze specjalnymi uprawnieniami do serwera |
| Połączenie z bazą SQL | Plik web.config na serwerze | Osoba ze specjalnymi uprawnieniami do serwera |
| Serwer SMTP i bramka SMS | Parametry według jednego opisu, bez potwierdzenia w pozostałych | Ustalamy przy wdrożeniu |
| Klucze i hasła API | Parametry według tego samego opisu | Ustalamy przy wdrożeniu |
Podział na dwa miejsca zapisu ma skutek praktyczny. Zmianę adresu siedziby wprowadza użytkownik z rolą Administrator w oknach programu, a zmiana hasła do skrzynki działu wymaga osoby z dostępem do serwera. Przy planowaniu zmian w firmie trzeba więc wiedzieć, która z tych osób odpowiada za dane ustawienie. Role i ich uprawnienia opisujemy przy rolach użytkowników w programie do reklamacji.
Dane firmy na dokumentach reklamacji
Po rejestracji reklamacji program generuje protokół reklamacyjny, a potwierdzenie złożenia reklamacji wysyła klientowi e-mailem. Dane firmy z parametrów są przeznaczone do dokumentów, więc wskazują na nich stronę, która przyjęła reklamację. Błąd w NIP albo nieaktualny adres pojawia się na każdym dokumencie wydanym przed poprawką. Protokół i jego sekcje opisujemy przy protokole reklamacyjnym generowanym w programie.
Dokumentacja nie opisuje, czy program zapisuje dane firmy w dokumencie w chwili jego utworzenia, czy pobiera je z parametrów przy każdym wydruku. Od tego zależy, jaki adres pokaże ponowny wydruk starej reklamacji po przeprowadzce firmy. Dlatego po zmianie parametrów otwieramy wydruk reklamacji sprzed zmiany i sprawdzamy dane firmy, zanim dokument trafi do klienta.
Plik web.config i dane chronione
Według dokumentacji starszej wersji dane konta pocztowego i połączenie z bazą SQL zapisuje się w pliku web.config, a nie w parametrach. Dokumentacja uzasadnia to ochroną tych danych przed łatwym dostępem, bo hasło do skrzynki i dane logowania do bazy nie pojawiają się w oknach programu. Zmiana w pliku albo w tabelach bazy SQL wymaga według tej samej dokumentacji specjalnych uprawnień. Samo konto z rolą Administrator w programie do niej nie wystarcza.
Kto technicznie zmienia plik, zależy od modelu uruchomienia programu. Przy abonamencie z hostingiem w chmurze prywatnej serwer utrzymuje SoftwareStudio, a przy instalacji na serwerze klienta dostęp do serwera ma jego dział IT. Ustawienia dzielą się więc na dwie grupy, które zmieniają różne osoby:
- Parametry w oknach programu - dane firmy i dane licencji, które zmienia użytkownik z rolą Administrator.
- Plik web.config na serwerze - konto pocztowe i połączenie z bazą SQL, które zmienia osoba z dostępem do serwera.
Zmianę adresu siedziby wprowadza Administrator, a zmiana hasła do skrzynki działu wymaga dostępu do serwera.
Instalację na serwerze klienta opisujemy przy instalacji programu RMA na własnym serwerze. W tym modelu plik web.config powinien trafiać do kopii zapasowej serwera, bo bez niego program po odtworzeniu serwera nie połączy się z bazą SQL. Zabezpieczenia danych, w tym role i logowanie przez Active Directory, opisujemy przy bezpieczeństwie danych w systemie reklamacyjnym.
Konto pocztowe a powiadomienia dla klienta
Według opisów programu wysyłka e-maili wymaga skonfigurowanego konta poczty. Z tego konta wychodzi potwierdzenie rejestracji zgłoszenia oraz e-mail do pracowników o nowej reklamacji. Klient B2C dostaje ponadto e-mail przy każdej zmianie statusu, od przyjęcia po zakończenie sprawy. Wiadomość można też wysłać ręcznie przyciskiem Wyślij, który na listach reklamacji rozwija opcje SMS i Mail.
Po awarii konta pocztowego program nie wyśle klientowi potwierdzenia ani odpowiedzi na reklamację, a przyczyną bywa np. zmiana hasła do skrzynki. Konsument ma prawo do odpowiedzi w ciągu 14 dni, a brak odpowiedzi w tym terminie oznacza uznanie reklamacji. Zmianę hasła do skrzynki działu uzgadniamy więc wcześniej z osobą, która ma dostęp do pliku web.config. W sprawach między firmami termin odpowiedzi wynika z umowy, ale skutek niedziałającej poczty jest podobny, bo klient nie dostaje informacji o decyzji.
Treść wiadomości pochodzi z szablonów korespondencji, które konfigurujemy przy wdrożeniu. Konto pocztowe decyduje o tym, czy wiadomość wyjdzie z programu, a szablon o tym, co klient w niej przeczyta. Okno wysyłki i historię wysłanych wiadomości opisujemy przy wysyłaniu e-maili z programu do reklamacji.
Sposób powiadomienia i bramka SMS
Kanał powiadomień dla konkretnej reklamacji wybiera się na formularzu w polu Sposób powiadomienia. W starszym interfejsie pole ma opcje Telefon/SMS i e-mail, a w nowym interfejsie osobna sekcja ma opcje SMS i E-mail. Program wysyła SMS albo e-mail przy zmianie statusu, a pracownik może wysłać wiadomość ręcznie w dowolnym momencie sprawy. Wybór na formularzu nie zastępuje konfiguracji wysyłki, bo bez bramki SMS albo konta pocztowego wiadomość w wybranym kanale nie wyjdzie z programu.
Do wysyłki SMS program potrzebuje bramki SMS, czyli usługi operatora, która przyjmuje wiadomość od programu i dostarcza ją na telefon klienta. Dane dostępowe do bramki traktujemy jak hasło, bo pozwalają wysyłać wiadomości w imieniu firmy. Powiadomienia SMS i ich historię opisujemy przy powiadomieniach SMS o statusie reklamacji.
Rozbieżne opisy miejsca ustawień poczty i SMS
Opisy programu nie są zgodne co do miejsca, w którym ustawia się pocztę wychodzącą. Jeden z nich umieszcza w parametrach dostępnych w interfejsie ustawienia serwerów SMTP i bramek SMS, a obok nich klucze i hasła do API. Kilka innych opisów podaje, że dane konta pocztowego leżą w pliku web.config. Obie wersje mogą dotyczyć różnych wydań programu, ale źródła tego nie rozstrzygają.
Dlatego przy wdrożeniu ustalamy, gdzie w wersji używanej przez firmę leżą ustawienia poczty i bramki SMS oraz kto może je zmienić. Standardowe wdrożenie trwa 4-8 tygodni od podpisania umowy, a etap konfiguracji zajmuje w nim 1-2 tygodnie. W tym etapie przygotowujemy też szablony korespondencji, z których korzystają powiadomienia. Przebieg konfiguracji opisujemy przy konfiguracji programu przy wdrożeniu.
Klucze API do wymiany danych z innymi systemami
Według opisów integracji program wymienia dane z innymi systemami m.in. przez moduł API i WebAPI REST z danymi w formacie JSON albo XML. Dostęp do tej wymiany zabezpieczają klucze API. Klucz identyfikuje system, który łączy się z programem, np. ERP albo system magazynowy WMS, więc działa jak hasło tego systemu. Wymianę danych przez API opisujemy przy API programu do reklamacji.
Każdy system powinien mieć własny klucz, bo tylko wtedy da się odciąć jedno połączenie bez przerywania pozostałych. Klucza nie przesyłamy w treści zwykłego e-maila, tylko przekazujemy osobie, która konfiguruje połączenie po stronie drugiego systemu. Dokumentacja nie opisuje, jak w programie wymienia się klucz, więc tę procedurę ustalamy przy wdrożeniu integracji.
Zmiany w firmie a ustawienia programu
Zmiany organizacyjne w firmie często wymagają poprawki w jednym z opisanych miejsc. Zanim zmiana wejdzie w życie, ustalamy, kto ją wprowadzi i jak sprawdzimy jej skutek w programie. Przy najczęstszych zmianach sprawdzamy cztery miejsca:
- Nowy adres siedziby albo NIP - administrator poprawia Parametry, a potem otwieramy wydruk reklamacji sprzed zmiany.
- Nowe hasło do skrzynki działu - osoba z dostępem do serwera zmienia dane konta w pliku web.config, a potem wysyłamy próbny e-mail.
- Nowy operator SMS - ustalamy miejsce ustawień bramki w używanej wersji programu i wysyłamy próbny SMS.
- Nowy system ERP - nowy system dostaje własny klucz API, a połączenie ze starym systemem zamykamy po zakończeniu migracji danych.
Próbna wiadomość po każdej zmianie w konfiguracji poczty albo SMS pokazuje błąd, zanim zauważy go klient. Wysyłamy ją na adres albo numer telefonu działu, a nie do klienta. Ślad takiej wiadomości zostaje w menu Historia w pozycjach Wysłane e-mail i Wysłane SMSy, więc widać, od kiedy wysyłka znowu działa.
Kontekst pracy i licencja w stopce programu
Stopka starszego interfejsu pokazuje pole Licencja oraz kontekst pracy zalogowanego użytkownika: Komórka, Magazyn, Oddział i Firma. W nowym interfejsie po lewej stronie stopki stoi numer wersji, np. 1.36.0, a po prawej pięć pozycji: Reklamacje: Centrala, SoftwareStudio, Siedziba, Główny i Główna. Przy wspólnej bazie zgłoszeń dla wielu lokalizacji kontekst pokazuje oddział i firmę, w których pracuje użytkownik. Numer wersji ze stopki podajemy przy zgłoszeniu błędu, bo zestaw przycisków różni się między wersjami programu.
Dokumentacja starszej wersji łączy dane licencji z sekcją Parametry globalne, ale nie opisuje, które pola licencji w niej widać. Według cennika licencje dostępowe liczy się jako użytkowników jednocześnie zalogowanych, a nie jako nazwane konta. Liczba kont założonych przez administratora może więc być większa niż liczba licencji, o ile nie wszyscy pracują w programie w tym samym czasie. Przy wzroście zatrudnienia w dziale o liczbie licencji w abonamencie decyduje szczyt jednoczesnych logowań, a nie liczba kont.