Generator pism rozliczeniowych

VESTRA Care Sp. z o.o. — etap M0 · wersja demo na danych testowych

Wersja demonstracyjna · etap M0

Generator pism rozliczeniowych

Narzędzie wewnętrzne działu obsługi klienta. Zamienia dane sprawy w gotowe pismo rozliczeniowe .docx — bez przepisywania pól z CRM, kasowania wariantów w Wordzie, liczenia kwot słownie i ręcznej odmiany „Pani/Pana”.

Jak działa

  1. Wpisz sygnaturę i kliknij „Pokaż dane” — zobaczysz, co przyszło ze źródła i co aplikacja wylicza sama.
  2. Wybierz scenariusz rozliczenia. Decyzja zawsze należy do pracownika.
  3. Sprawdź alert. Jeśli sprawie brakuje danych do tego pisma, aplikacja powie czego i nie wygeneruje pliku.
  4. Generuj pismo, przeczytaj je i wyślij samodzielnie — aplikacja niczego nie wysyła.
Teraz działa na danych testowych (SYG-001 … SYG-005). To wymyślone osoby — można klikać bez obaw. To pokaz na serwerze — wygenerowane pisma nie zostają na serwerze, a prawdziwych danych nie da się tu podpiąć. Docelowa wersja działa w firmie, bez dostępu z internetu.

Do ustalenia

Dodatkowe funkcje i reguły czekają na decyzje — niżej na stronie jest sekcja „Do ustalenia”, a w schemacie działania dwie drogi wdrożenia.

Dane ze źródła

Wpisz sygnaturę po prawej i kliknij „Pokaż dane", żeby zobaczyć, co zwraca źródło.

W danych testowych: SYG-001 SYG-002 SYG-003 SYG-004 SYG-005

Decyzję o scenariuszu podejmuje człowiek — aplikacja nigdy nie wybiera sama.

Płatna do ostatniego dnia miesiąca. Kolejne raty co miesiąc. Dotyczy tylko pism ratalnych.

Źródło: dane testowe (data/fake_sprawy.json)

Jak powstaje pismo

Od sygnatury do pliku .docx. Dane sprawy żyją tylko w pamięci, przez czas generowania.

  1. 1

    Źródło danych

    Sprawa pobierana po sygnaturze: dane testowe albo baza CRM — wyłącznie odczyt.

    26 pól, w tym 9 przełączników decydujących o akapitach.

  2. 2

    Wybór scenariusza człowiek

    Pracownik wybiera jedno z 6 pism. Aplikacja nigdy nie wybiera sama.

  3. 3

    Sprawdzenie danych bramka

    Czy sprawa ma wszystko, czego wymaga ten szablon: adres, płeć, kwoty, raty, aneks, opiekun.

    Braki → czerwony alert, plik nie powstaje. Pola „do ustalenia” nie są jeszcze sprawdzane.

  4. 4

    Wyliczenia po naszej stronie

    Kwoty słownie, daty słowne, „Pani/Pana”, kwota pozostała, harmonogram rat, lista załączników, data pisma.

    Kwoty w groszach (int) — zawsze zgodne z liczbą źródłową.

  5. 5

    Szablon .docx

    Dane trafiają do wzorca scenariusza. Przełączniki zostawiają właściwy wariant akapitu.

  6. 6

    Gotowe pismo

    Plik {sygnatura}_{scenariusz}_{data}.docx zapisany w folderze wyjściowym i pobrany w przeglądarce.

  7. 7

    Akceptacja przed wysyłką człowiek

    Pracownik czyta pismo i wysyła je sam. Aplikacja niczego nie wysyła.

Wdrożenie dla zespołu — dwie drogi do decyzji

Ta wersja demo nie ma logowania i działa tylko na danych testowych. Żeby korzystał z niej zespół, trzeba wybrać jedną z dróg. W obu dochodzi logowanie firmowym kontem, HTTPS i rejestr pobrań pism.

A. Serwer w firmie rekomendowana

np. pisma.vestra.local — tylko sieć firmowa lub VPN pracownika

  • Stoi obok CRM — bez tunelu do bazy
  • Dane nie wychodzą poza firmę
  • Brak zewnętrznego dostawcy i umowy powierzenia
  • Potrzebny serwer w firmie i informatyk do utrzymania
  • Praca z domu tylko przez VPN

B. Domena publiczna z bramką logowania

np. pisma.vestra.info — hosting w UE

  • Dostęp z każdego miejsca po zalogowaniu
  • Bez własnego serwera w firmie
  • Szyfrowany tunel do CRM — baza nie może być otwarta na internet
  • Umowa powierzenia z hostingiem (art. 28 RODO)
  • Dane o zdrowiu poza firmą — najpewniej ocena skutków (DPIA)

Do ustalenia

5 otwarte

Otwarte decyzje przed wdrożeniem. Do czasu ustalenia aplikacja nie sprawdza pól oznaczonych w panelu „do ustalenia”.

1. Odczyt danych z CRM: baza czy API

Aplikacja obsłuży obie drogi — źródło siedzi za jednym interfejsem. Wybór zależy od informatyka.

Jak aplikacja ma czytać sprawy z CRM?

  • Konto do bazy tylko z prawem SELECT — najszybciej, bez pisania kodu po stronie CRM.
  • API: jeden endpoint tylko do odczytu GET /sprawy/{sygnatura}, który zwraca JSON z polami sprawy (kwoty jako liczby, daty jako daty, przełączniki jako wartości ze słownika), zabezpieczony tokenem i dostępny tylko z komputera operatora.

2. Konto wpływu świadczenia a scenariusz

Pole nie zmienia treści pisma — konto wynika już z nazwy scenariusza.

Czy blokować pismo, gdy konto nie zgadza się ze scenariuszem?

  • Tak: „raty – konto klienta” i „7 dni” tylko przy koncie klienta; „raty – konto Vestra”, „potrącenie całości” i „aneks / nadpłata” tylko przy koncie Vestra.
  • Nie: scenariusz wybiera pracownik, pole usuwamy z listy dla CRM.

3. Oświadczenie do ZUS o zmianie konta

Pisma „potrącenie całości” i „aneks / nadpłata” zawsze zawierają zdanie „do ZUS zostało wysłane oświadczenie o zmianie numeru konta”. Oryginały nie mają wariantu bez tego zdania.

Czy blokować te dwa pisma, gdy oświadczenie nie zostało wysłane?

  • Tak: bez wysłanego oświadczenia pismo nie powstaje.
  • Nie: oświadczenie jest zawsze wysyłane przed pismem, pole usuwamy z listy dla CRM.

4. Honorarium pobrane w całości

Pisma „potrącenie całości” i „aneks / nadpłata” zawsze zawierają zdanie „Należna kwota honorarium została pobrana automatycznie”. Dziś przechodzą także sprawy, w których pobrano tylko część albo nic.

Czy blokować te dwa pisma, gdy kwota pobrana jest mniejsza niż honorarium?

  • Tak: pismo powstaje tylko, gdy kwota pobrana jest równa honorarium.
  • Nie: te pisma wysyłane są także przed pełnym potrąceniem.

5. Pole „Zmieniona aneksem”

Pole nie zmienia treści pisma. O aneksie świadczą już numer i data aneksu.

Co zrobić z tym polem?

  • Usunąć: aneks = wypełniony numer i data aneksu, o jedno pole mniej w CRM.
  • Blokować pismo „aneks / nadpłata”, gdy sprawa nie ma aneksu.
  • Dodatkowo blokować pozostałe pisma przy sprawie z aneksem (nie wspominają o aneksie) — jeśli tak jest w praktyce.