Protokół PDF 1:1 z Waszym wzorem: jak budujemy generator dokumentów w aplikacji serwisowej
Każda firma serwisowa z kilkuletnim stażem ma swoje wzory protokołów. Dopracowane po kontrolach, uwagach klientów i sporach — i znane odbiorcom tak dobrze, że każda zmiana wyglądu budzi pytania. Gotowe systemy mówią: „macie nasz szablon, można dodać logo”. My mówimy: pokażcie wzór, system ma go drukować. Oto jak to wygląda od środka, na przykładzie dwóch wdrożeń z ostatnich tygodni.
Wdrożenie pierwsze: 41 wzorów protokołów ppoż.
Kierownik firmy przeglądowej przyniósł 41 wzorów: gaśnice, hydranty, systemy sygnalizacji pożaru, oddymianie, oświetlenie awaryjne, drzwi przeciwpożarowe — każdy z własnym tytułem, podstawą normową i rytmem przeglądów. Część różniła się tylko jednym akapitem dla konkretnego klienta. Zamiast 41 sztywnych szablonów zbudowaliśmy katalog szablonów bazowych z wariantami, które system dobiera sam.
| Element protokołu | Skąd się bierze |
|---|---|
| Tytuł dokumentu zgodny z normą | pole szablonu |
| Podstawa normowa | pole szablonu, drukowane w nagłówku |
| Częstotliwość przeglądu (także nietypowa, np. co 4 miesiące) | słownik edytowalny przez administratora |
| Własny opis „Zakresu” zamiast domyślnego | pole szablonu; pusty = tekst standardowy |
| Lista czynności z oceną OK / NOK | edytor szablonu |
| Sekcja po czynnościach (np. zalecenia, parametry) | szablon, z możliwością dopisania w zadaniu |
| Wariant dla konkretnego klienta, budynku albo instalacji | wariant szablonu, dobierany automatycznie przy tworzeniu zadania |
| Miejsce spisania protokołu | wyliczane z adresu budynku, w którym jest instalacja |
Warianty to rzecz, którą najbardziej doceniają kierownicy. Jeśli jeden szpital wymaga dodatkowego oświadczenia na protokole hydrantów, tworzy się wariant tylko dla tego klienta — a przy planowaniu zadania system sam podsuwa właściwy, oznaczając go gwiazdką. Technik nie musi pamiętać, który klient ma „swój” protokół.
Wdrożenie drugie: protokół kotła gazowego, 96 czynności
W systemie dla firmy instalacyjnej wzorem był ośmiostronicowy protokół przeglądu kotła gazowego: 96 czynności i 9 miejsc na zdjęcia, każde z limitem liczby fotografii. Tu przyjęliśmy inną zasadę niż w ppoż.: lista czynności w aplikacji JEST treścią protokołu. Technik przechodzi kreator krok po kroku, a PDF powstaje jako wierne odwzorowanie wzoru — tej samej kolejności, tych samych rubryk, tego samego układu zdjęć. Jeden przepływ, dwa podpisy (serwisant od razu, klient na telefonie technika albo przez link ważny 72 godziny).
Diabeł w typografii: co poprawialiśmy na prawdziwych protokołach
Większość pracy nad generatorem nie dotyczy logiki, tylko drobiazgów, które widać dopiero na wydruku prawdziwego protokołu z prawdziwymi danymi:
- margines górny 30 mm — bo protokoły trafiają do segregatorów i dziurkacz nie może zjadać nagłówka
- oświadczenie końcowe drukowane w jednym bloku — nigdy przełamane między stronami, żeby podpis nie wisiał samotnie na ostatniej kartce
- przecinek dziesiętny zamiast kropki w pomiarach
- skróty norm i nazwy własne nietknięte przez automatyczną zmianę wielkości liter — „PN-EN” nie może zamienić się w „pn-en”
- „brak uwag” zamiast pustej rubryki przy pozytywnej ocenie bez komentarza
- opisy pod zdjęciami, żeby odbiorca wiedział, na co patrzy
- wersja protokołu bez podpisów — do wysłania klientowi przed wizytą albo do wewnętrznej kontroli
Jak to jest zbudowane (i dlaczego tak)
Protokół składamy jako stronę HTML z danych zadania i drukujemy do PDF-u tym samym silnikiem, którego używa przeglądarka Chrome — na serwerze, bez udziału telefonu technika. Takie podejście daje pełną kontrolę nad typografią, tabelami i łamaniem stron, a jednocześnie pozwala pokazać kierownikowi podgląd dokładnie tego, co zostanie wysłane. Biblioteki rysujące PDF „ręcznie” są szybsze, ale każda zmiana układu wzoru to wtedy godziny pracy zamiast minut.
Druga zasada: dane w bazie, nie w szablonie. Nazwa klienta, osoba reprezentująca go na protokole, adres obiektu i domyślny adres e-mail do wysyłki to pola w kartotece, a nie tekst wklejony do dokumentu. Dzięki temu system może też ostrzec, zanim protokół pójdzie w świat — przy wdrożeniu okazało się na przykład, że 9 budynków nie ma żadnego adresu, więc zamiast kropek w rubryce „miejsce spisania” karta protokołu pokazuje ostrzeżenie z linkiem do uzupełnienia danych.
Checklist: co przygotować do wdrożenia własnego wzoru
- aktualne wzory w wersji edytowalnej lub PDF — każdy rodzaj przeglądu osobno
- listę klientów, którzy mają „swoje” wersje protokołów, z opisem różnic
- dwa–trzy wypełnione protokoły z prawdziwymi danymi — to na nich wychodzą problemy z łamaniem stron i długimi nazwami
- informację, kto podpisuje po stronie klienta i jak ma być opisany na dokumencie
- decyzję, co ma się dziać przy ocenie negatywnej: sam komentarz, usterka ze zdjęciem czy wstrzymanie zadania
Najczęstsze pytania
Czy mogę sam zmieniać wzór protokołu po wdrożeniu?
Treść — tak: tytuły, podstawę normową, zakres, listę czynności, częstotliwość i warianty dla klientów zmienia administrator w edytorze szablonów. Zmiany układu graficznego (nowa tabela, inne ułożenie zdjęć) robimy my w ramach utrzymania — zwykle to kwestia godzin.
Co jeśli każdy nasz klient chce trochę inny protokół?
Do tego służą warianty szablonów: bazowy protokół plus wariant dla klienta, budynku lub konkretnej instalacji. System sam dobiera właściwy wariant przy tworzeniu zadania, więc technik nie musi o tym pamiętać.
Czy protokół da się też wydrukować i podpisać na papierze?
Tak. Protokół można wydrukować z podpisem technika, a po podpisaniu przez klienta dołączyć skan. Status zadania odzwierciedla, że dokument został podpisany papierowo.