Podpisywanie dokumentów w aplikacji: od wyboru podpisu do sprawdzenia wyniku

Dokument został wysłany do podpisu. Jedna osoba go zatwierdziła, druga poprosiła o zmianę załącznika, a trzecia nadal widzi poprzednią wersję. W aplikacji pojawia się zielony znacznik, lecz zespół nie wie, czy dotyczy całego kompletu czy tylko pierwszego podpisu. Integracja podpisu elektronicznego powinna pomagać właśnie w takich sytuacjach: pokazywać, co zostało podpisane, przez kogo i na jakim etapie znajduje się sprawa.

Zanim wybierzecie dostawcę, ustalcie rodzaj dokumentu, osoby uczestniczące i wymagania dotyczące formy. Następnie zaprojektujcie przekazanie konkretnej wersji pliku, odbiór statusów oraz sposób postępowania z odmową lub błędem. Sam przycisk „podpisz” jest widoczną częścią procesu. Reszta decyduje o tym, czy można bezpiecznie zakończyć sprawę.

Jeśli planujesz podpisywanie dokumentów w aplikacji, wyślij brief z opisem procesu, uczestników i systemów, w których przechowywane są pliki. Na początek wystarczy fikcyjny przykład. Nie przesyłaj rzeczywistych umów, dokumentów tożsamości ani kluczy dostępu.

Zacznij od dokumentu i skutku, który ma wywołać

Wyobraźmy sobie firmę, która zawiera umowy z dostawcami. Pracownik przygotowuje dokument, wskazuje osoby podpisujące, a po zakończeniu procesu przekazuje wynik do systemu zakupowego. To przykład projektowy, nie opis konkretnego wdrożenia ani porada dotycząca formy umowy. Firma powinna ustalić, kto odpowiada za treść i jak potwierdza gotowość dokumentu przed wysłaniem go dalej.

Zapiszcie przebieg jednej sprawy. Czy podpisuje jedna osoba, kilka osób równolegle, czy uczestnicy muszą działać w ustalonej kolejności? Czy do dokumentu należą załączniki i kto decyduje o ich ostatecznej wersji? Co dzieje się, gdy jedna strona odmawia albo stwierdza, że w treści jest błąd? Odpowiedzi wpływają na stan sprawy i możliwość jej wznowienia.

Ważne jest też rozróżnienie podpisu od wewnętrznego zatwierdzenia treści. Kierownik może zaakceptować projekt umowy przed wysłaniem go do podpisu, choć sam nie jest jej stroną. Te zdarzenia warto pokazywać osobno. W przeciwnym razie osoba przeglądająca historię nie będzie wiedziała, czy widzi akceptację wewnętrzną, czy podpis złożony w ramach właściwego procesu.

Ustalcie również, co ma się wydarzyć po zakończeniu podpisywania. Dokument może trafić do repozytorium, a informacja o nim do systemu obsługi klienta. Każda z tych operacji ma własny stan. Przy projektowaniu połączeń przydaje się analiza źródeł danych w integracji systemów: trzeba wiedzieć, który system przechowuje dokument, a który jedynie pokazuje jego status.

Dobierz rodzaj podpisu do sprawy

Podpisy elektroniczne występują w różnych formach i nie każda sytuacja wymaga tego samego rozwiązania. Przed podjęciem decyzji należy sprawdzić charakter czynności, wymagania właściwe dla danej sprawy oraz warunki używanej usługi. Osoba odpowiedzialna za kwestie prawne powinna ustalić wymagania dla dokumentu i jurysdykcji; projektant aplikacji może następnie zaproponować odpowiednią ścieżkę techniczną.

Rozporządzenie eIDAS w tekście opublikowanym w EUR-Lex opisuje między innymi skutki prawne podpisów elektronicznych oraz wymagania dotyczące podpisu zaawansowanego. Stan przepisów i ich zastosowanie do konkretnej sprawy trzeba sprawdzić przy wdrożeniu. Sam fakt użycia usługi podpisywania nie przesądza, że spełniono wszystkie wymagania dotyczące danego dokumentu.

Przy porównywaniu usług zwróćcie uwagę na sposób identyfikacji osoby podpisującej, obsługiwane formaty, dostępne potwierdzenia oraz możliwość sprawdzenia wyniku. Sprawdźcie też, jak uczestnik kończy proces na telefonie, co widzi przy odmowie i gdzie może uzyskać pomoc. Dobre doświadczenie nie polega na ukryciu wszystkich szczegółów, lecz na pokazaniu właściwych informacji wtedy, gdy są potrzebne.

Nie obiecujcie użytkownikom skutku prawnego na podstawie samego wyglądu przycisku. Komunikat powinien opisywać działanie i stan sprawy w sposób uzgodniony z osobami odpowiedzialnymi za proces. Jeżeli dokument wymaga innego trybu, aplikacja powinna pozwolić skierować go właściwą drogą zamiast sugerować, że każdą umowę podpisuje się identycznie.

Zamknij wersję przed wysłaniem

Uczestnicy powinni wiedzieć, który dokument podpisują. Przed wysłaniem potrzebna jest decyzja, że treść i komplet załączników są gotowe. Jeżeli po rozpoczęciu podpisywania ktoś zmieni plik, zespół musi ustalić, czy dotychczasowy proces należy przerwać i rozpocząć nowy dla poprawionej wersji. Nie warto pozostawiać tej decyzji domysłom użytkownika. Przed wysłaniem pomocne może być też porównanie kolejnych wersji umowy i przekazanie zmian do oceny.

Aplikacja może zachować identyfikator wersji dokumentu oraz powiązanie z konkretnym procesem podpisywania. Dzięki temu status otrzymany od dostawcy będzie można przypisać do właściwej sprawy. W interfejsie przyda się czytelna nazwa pliku, data przygotowania i informacja o dołączonych materiałach. Jeśli użytkownik porównuje kilka podobnych wersji, sama nazwa „umowa_finalna.pdf” szybko przestaje wystarczać.

Zadbajcie o zakres dostępu do dokumentu. Osoba podpisująca powinna widzieć materiały przeznaczone dla niej, a pracownik obsługi tylko te sprawy, do których ma uprawnienia. Link do dokumentu, wiadomość z zaproszeniem i plik wynikowy są osobnymi drogami dostępu. Przy projektowaniu granic danych warto skorzystać z zasad opisanych w artykule o uprawnieniach do dokumentów.

Jeśli dostawca umożliwia pobranie pliku wynikowego i informacji o procesie, ustalcie, które z nich są potrzebne w danym obiegu. Sprawdźcie też, kto i w jakim systemie ma do nich dostęp. Przenoszenie pliku do kolejnej lokalizacji powinno zachować powiązanie ze sprawą oraz odpowiednie zasady dostępu i przechowywania.

Rozróżnij stany i wyjątki

Przy kilku osobach podpisujących prosty podział na „podpisane” i „niepodpisane” może być za mało dokładny. Zespół może potrzebować informacji, że zaproszenie wysłano, jedna osoba już zakończyła swój etap, a odpowiedź drugiej pozostaje nieznana. Dostępne stany zależą od wybranej usługi. Ich nazwy w aplikacji powinny jasno odpowiadać rzeczywistym zdarzeniom.

Odmowa podpisu nie jest tym samym co błąd połączenia. W pierwszym przypadku potrzebna może być decyzja o poprawieniu dokumentu lub zakończeniu rozmów. W drugim trzeba sprawdzić, czy status dotarł do aplikacji i czy można go bezpiecznie pobrać ponownie. Ustalcie właściciela sprawy i kolejny krok dla obu przypadków, zamiast umieszczać je w jednej kolejce z opisem „niepowodzenie”.

Uczestnik może również nie odpowiedzieć przed upływem terminu zaproszenia. Czy system ma wysłać przypomnienie, poinformować opiekuna sprawy czy zakończyć próbę? Odpowiedź zależy od umówionego procesu i możliwości dostawcy. Powiadomienia powinny wskazywać właściwy dokument i adresata, a ich wysyłka nie może sugerować, że podpis został już złożony.

Jeśli warunki umowy zmienią się w trakcie procesu, trzeba ustalić, kto może przerwać wysyłkę oraz jak oznaczyć wcześniejszą próbę. Historia powinna pozwalać odróżnić dokument wycofany od podpisanego. W podobny sposób artykuł o obsłudze zapytań klientów zwraca uwagę na właściciela i następny krok sprawy: status ma pomagać działać, a nie tylko ładnie wyglądać na liście.

Odbierz potwierdzenie z integracji

Dostawca może przekazywać informacje o postępie za pomocą zdarzeń albo udostępniać stan do sprawdzenia przez API. W obu przypadkach trzeba sprawdzić aktualną dokumentację konkretnej usługi. Aplikacja powinna wiedzieć, do którego procesu należy informacja, czy jest wiarygodna i co zrobić, gdy zdarzenie dotrze ponownie albo w innej kolejności niż oczekiwano.

Odebranie zdarzenia i zapisanie wyniku w systemie firmowym to dwa różne kroki. Jeśli plik wynikowy nie został pobrany, aplikacja nie powinna sugerować, że cały proces archiwizacji zakończył się poprawnie. Podobny problem opisujemy w artykule o API i webhookach w automatyzacji. Dobrze zaprojektowana kolejka lub procedura obsługi błędu pozwala wrócić do sprawy bez tworzenia nowego procesu podpisywania.

Zdarza się, że odpowiedź nie dotrze mimo wykonania operacji po drugiej stronie. Przed ponowieniem trzeba sprawdzić dostępny stan i zasady dostawcy, aby nie wysłać kolejnego zaproszenia bez potrzeby. Użytkownik nie powinien dostawać kilku różnych próśb dotyczących tego samego dokumentu tylko dlatego, że system nie umiał rozpoznać wcześniejszej próby.

Przygotujcie także sposób ręcznego wyjaśnienia rozbieżności. Pracownik powinien móc odnaleźć sprawę po identyfikatorze, sprawdzić ostatni potwierdzony stan i przekazać problem dalej. Nie oznacza to udostępnienia mu wszystkich dokumentów w organizacji. Zakres dostępu należy powiązać z jego rolą oraz konkretną sprawą.

Sprawdź cały obieg przed uruchomieniem

Próba powinna obejmować przygotowanie dokumentu, wysłanie do kilku uczestników, podpisanie i przekazanie wyniku do właściwego miejsca. Dodajcie przypadek odmowy, zmianę wersji przed zakończeniem oraz sytuację, w której integracja nie otrzymała potwierdzenia. Dla każdego scenariusza ustalcie oczekiwany stan widoczny dla pracownika i dalszy krok.

Warto przetestować również dostęp na telefonie, działanie zaproszenia po upływie terminu oraz sytuację, w której jedna osoba nie może ukończyć procesu. Czy wie, do kogo się zwrócić? Czy pracownik widzi wystarczające informacje, aby pomóc bez proszenia o ponowne przesłanie dokumentu? Takie pytania ujawniają problemy, których nie pokaże sam poprawny wynik technicznego wywołania API.

Przed odbiorem zapiszcie kryteria wraz z właścicielami poszczególnych decyzji. W artykule o odbiorze aplikacji i kryteriach testu pokazujemy, jak zamienić ogólne oczekiwanie w zestaw sprawdzalnych sytuacji. Dla podpisywania dokumentów istotne jest między innymi poprawne powiązanie wyniku z wersją pliku oraz widoczny stan każdej osoby uczestniczącej.

Po uruchomieniu obserwujcie błędy integracji i sprawy, które zbyt długo pozostają bez następnego kroku. Nie każda zaległość oznacza awarię: uczestnik mógł jeszcze nie podjąć decyzji. Warto jednak odróżnić oczekiwanie od nieudanego pobrania wyniku. W artykule o monitorowaniu automatyzacji omawiamy sygnały potrzebne do takiej reakcji.

W planie odbioru warto uwzględnić również zastępstwo. Osoba wskazana do podpisu może być nieobecna albo zmienić zakres obowiązków, gdy dokument już czeka. Przed rozpoczęciem procesu ustalcie, kto może wskazać innego uczestnika oraz czy wymaga to nowej wersji zaproszenia. Aplikacja powinna zachować czytelną historię tej zmiany i pokazać pozostałym uczestnikom aktualny stan sprawy.

Osobno sprawdźcie, jak długo uczestnicy mają dostęp do zaproszenia i gdzie znajdą zakończony dokument. Rozwiązanie zależy od wybranego dostawcy oraz zasad organizacji. Informacja powinna być dostępna dla pracownika obsługi, aby mógł odpowiedzieć na pytanie bez wysyłania dokumentu na niesprawdzony adres. Jeśli dostęp do linku wygasł, proces pomocy musi obejmować weryfikację właściwej osoby i udostępnienie dokumentu odpowiednią drogą.

Po zmianie dostawcy lub formatu dokumentu powtórzcie testy istotnych przypadków. Nowa integracja może inaczej nazywać etapy albo przekazywać statusy w odmienny sposób. Przed przełączeniem sprawdźcie również, gdzie pozostaną dokumenty podpisane wcześniej i kto będzie mógł je odnaleźć. Plan przekazania powinien obejmować zarówno nowe sprawy, jak i dostęp do zakończonych procesów.

Dobrym początkiem może być jeden typ dokumentu oraz ograniczona grupa osób, które znają procedurę. Po sprawdzeniu rzeczywistego przebiegu łatwiej dodać kolejne warianty. Projektując integracje systemów, uwzględnijcie nie tylko wysyłkę dokumentu, lecz także potwierdzenia, odmowy i przekazanie gotowego wyniku do dalszej pracy.