Podpis eIDAS w Odoo z e-Signature.eu: itsme, Evrotrust i opłata za podpis

e-Signature.eu to europejska platforma podpisu eIDAS: nie sprzedaje rocznych abonamentów, sprzedaje kredyt, a każdy podpis go zużywa. Konektor, który podłącza ją do Odoo, zbudowaliśmy i utrzymujemy my, z osobną wersją dla każdej serii (17, 18 i 19) (karta modułu). Ten artykuł dotyczy tego, o czym prawie nikt nie mówi przed zakupem: jaki poziom jest Ci naprawdę potrzebny, co musi zrobić druga strona, żeby podpisać, i jak zmienia się rachunek, gdy płacisz za podpis, a nie za rok.

Trzy poziomy eIDAS, opisane przez to, co zmieniają w Twoim procesie

Rozporządzenie (UE) 910/2014 definiuje trzy poziomy, a różnica prawna jest zapisana w jego własnym tekście (artykuły 3, 25 i 26). Czego w rozporządzeniu nie ma, to różnicy operacyjnej: każdy poziom wymaga od podpisującego czegoś innego, a im więcej od niego wymagasz, tym więcej osób odpada po drodze.

Te cztery metody to pełny katalog konektora i nie można go edytować: nikt nie może oznaczyć jako „kwalifikowanego” podpisu, który nim nie jest.

Kiedy naprawdę potrzebny jest QES?

Większość firm, które pytają o podpis kwalifikowany, chce go do dokumentów, które go nie wymagają. Przydatne kryterium to nie „ile wart jest kontrakt”, tylko „czy ktoś będzie go wymagał na piśmie”:

• Sprawy wobec administracji, która go wymaga. We Francji e-Signature.eu dokumentuje, że od stycznia 2023 roku INPI wymaga podpisu kwalifikowanego przy formalnościach zmiany i zakończenia działalności firmy w Guichet unique. Tu nie ma dyskusji: albo QES, albo wniosek nie przejdzie.
• Kontrahenci, którzy mają to w swojej polityce zakupowej. Duzi klienci, ubezpieczyciele i niektóre banki wymagają tego domyślnie.
• Dokumenty, które według Ciebie ktoś zakwestionuje. Jeśli spór jest realnym scenariuszem, QES przerzuca ciężar dowodu na Twoją korzyść.

Wszystko inne (potwierdzenia, pokwitowania odbioru, wewnętrzne załączniki) mieści się w SES; standardowe umowy B2B w AES. I uczciwa uwaga: QES nie zastępuje czynności, które prawo nakazuje sporządzić w formie aktu notarialnego. Najdroższy błąd to nie wybranie zbyt niskiego poziomu: to ustawienie QES jako domyślnego, a potem zastanawianie się, dlaczego ludzie podpisują dowód dostawy cztery dni.

itsme, Evrotrust, Veriff i OTP: czego każdy z nich wymaga od podpisującego

itsme® to belgijska tożsamość cyfrowa. W Belgii klasyczna rejestracja wymaga eID z czytnikiem kart albo karty belgijskiego banku; poza Belgią wystarczy, według e-Signature.eu, paszport, dowód tożsamości lub zezwolenie na pobyt, ale zasięg zależy od listy krajów itsme®: sprawdź ją, zanim obiecasz komukolwiek QES. Evrotrust to bułgarski kwalifikowany dostawca usług zaufania (QTSP) wpisany na unijną listę zaufania; jest też aplikacją mobilną, ma szerszy zasięg i jest metodą, którą francuski INPI akceptuje od 2026 roku, według e-Signature.eu.

Veriff nie jest QTSP: to weryfikacja tożsamości, dokument plus selfie, i z tego powstaje AES. OTP to kod przesłany e-mailem lub SMS-em i z tego powstaje SES. Jest tu szczegół, który kosztował nas całą rundę przeglądu z e-Signature.eu: platforma po cichu odrzuca każdy numer telefonu, który nie jest „+” z samymi cyframi. Człowiek wpisuje „+32 483 22 90 07”, platforma zapisuje pustą wartość, a OTP przez SMS wraca bez ostrzeżenia do e-maila. Konektor normalizuje numer przed wysłaniem; ujawniła to siódma runda przeglądu, 14 lipca 2026 roku.

Co zmienia się w przepływie Odoo w zależności od poziomu

Konektor dodaje przycisk Send for Signature do ofert, faktur, zamówień zakupu, umów o pracę (hr.version w Odoo 19, hr.contract w 18 i 17), kandydatur, kontaktów i dowolnego załączonego pliku PDF. Nie zależy od aplikacji Sign, której nie ma nawet w manifeście, a to ma znaczenie, bo dokumentacja samej Odoo mówi, że Sign generuje proste podpisy elektroniczne, czyli pierwszy z trzech poziomów: do AES lub QES trzeba skorzystać z zewnętrznego dostawcy.

Kreator każe wybrać osobno minimalny poziom prawny i metody i nie pozwoli ich źle połączyć: przy minimum ustawionym na „Kwalifikowany” wysyłka z OTP lub Veriff jest odrzucana, a ta sama walidacja dotyczy domyślnych metod konta. Wygląda to na drobiazg, a zapobiega najczęstszej usterce: procesowi oznaczonemu jako QES, obsłużonemu kodem SMS.

Przy SES wysyłka idzie od razu: podpisujący wpisuje kod, a podpisany PDF wraca sam. Przy QES jest krok identyfikacji, który musisz zaprojektować Ty: podpisujący potrzebuje zainstalowanej aplikacji i już zweryfikowanej tożsamości, a jeśli robi to pierwszy raz, rejestracja może trwać dłużej niż sama umowa. Praktyczny wniosek jest nudny i działa: uprzedź drugą stronę przed wysłaniem.

Są dwa tryby: w trybie e-mail zaproszenie wysyła e-Signature.eu; w trybie przepływu Odoo oferta wychodzi natywnym obiegiem, a klient podpisuje w swoim portalu, gdzie „Podpisz” zastępuje „Zaakceptuj i zapłać”. Drugi tryb krył błąd, który poprawiliśmy: sesja w e-Signature.eu powinna powstawać tylko wtedy, gdy e-mail zostanie naprawdę wysłany; wcześniej odrzucenie wersji roboczej zostawiało prośbę jako wysłaną.

Subskrypcja kontra opłata za podpis: rachunek na serwetce

Subskrypcję płaci się tak samo, czy podpisujesz, czy nie, i prawie zawsze ma limit kopert. Model e-Signature.eu jest odwrotny: kupujesz pakiety kredytów, cena za kredyt spada wraz z wolumenem, a każdy podpis zużywa kredyt zależnie od poziomu. W ich katalogu (tym samym, który odwzorowuje konektor) QES z itsme® lub Evrotrust zużywa jeden kredyt na podpisującego, AES z Veriff 0,7, a SES przez OTP 0,4, niezależnie od tego, czy w prośbie jest jeden dokument, czy pięć.

Rachunek mieści się w jednej linijce: podziel roczną opłatę przez cenę kredytu, a otrzymasz liczbę podpisów, od której subskrypcja się opłaca. Zrób go z opłatą, którą Ci zaproponują, i z cennikiem, który e-Signature.eu publikuje na swojej stronie: wynik to liczba, a nie opinia. Jest też efekt drugiego rzędu: przy subskrypcji płacisz tyle samo za SES i za QES, więc nic nie zachęca Cię do dopasowania poziomu; przy kredytach wybór AES zamiast QES kosztuje 30 % mniej za ten podpis. Wybór poziomu przestaje być abstrakcyjną dyskusją prawną, a staje się decyzją ekonomiczną przy każdej wysyłce.

Saldo jest widoczne w Odoo wraz z datą aktualizacji: API nie ma endpointu salda (zwraca je w odpowiedzi na każdą prośbę), więc konektor pobiera je z ostatniej odpowiedzi i odświeża zadaniem cron raz dziennie, zamiast udawać dane na żywo, których nie ma.

Co jest zapisywane i gdzie znajduje się dowód

Podpis bez dowodu, który można odzyskać, jest bezużyteczny w dniu, gdy jest potrzebny. Po zakończeniu prośby w Odoo zostają trzy rzeczy:

• Podpisany PDF, załączony do dokumentu źródłowego i nazwany na jego podstawie (S00026-signed.pdf), a nie według wewnętrznego identyfikatora prośby. Brzmi to kosmetycznie, dopóki ktoś nie szuka swojej umowy i jej nie znajduje.
• Oficjalny audit trail z e-Signature.eu, zapisany jako <documento>-audit-trail.pdf. Uwaga: platforma generuje go chwilę po zakończeniu prośby, więc może go nie być, jeśli poprosisz o niego dokładnie w chwili podpisu; konektor Ci o tym powie, zamiast zawieść bez wyjaśnienia.
• Własny raport dowodowy modułu, z faktycznie osiągniętym poziomem eIDAS, metodami, czasem podpisu, SHA-256 podpisanego dokumentu oraz, dla każdego podpisującego, jego zweryfikowaną tożsamością, użytą metodą i czasem podpisu.

I przycisk, którego nie zobaczysz w wielu konektorach: Verify eIDAS signature otwiera narzędzie walidacji DSS Komisji Europejskiej, żebyś mógł zweryfikować podpisany PDF czymś, co nie jest ani nami, ani e-Signature.eu. Pod spodem stan synchronizuje webhook podpisany HMAC-SHA256, rejestr idempotencji i godzinny cron ratunkowy; a usunięcie zakończonej prośby usuwa ją także z historii e-Signature.eu.

Dziesięć rund przeglądu z e-Signature.eu

Ten konektor nie został napisany na podstawie dokumentacji i wypuszczony: pokazaliśmy go zespołowi e-Signature.eu, zepsuliśmy i napisaliśmy od nowa. W repozytorium jest jeden plik testów na każdą rundę, od test_round2.py do test_round10.py. Dwa przykłady, oprócz telefonu z rundy 7:

• Runda 9. Prośba anulowana z panelu e-Signature.eu zostawała w Odoo „Wysłana” na zawsze. A oczywista poprawka (ponowne zapytanie o nią) też nie działała: anulowanie z panelu usuwa ją w e-Signature.eu, a zapytanie zwraca 401.
• Runda 10. Zatrzymanie prośby w połowie podpisywania zostawiało podpisującego w stanie oczekiwania na zawsze: platforma odrzuca operację, jeśli nikt jeszcze nie podpisał, a kod połykał błąd i mimo to oznaczał ją jako zatrzymaną.

Jest nawet funkcja, której konektor odmawia udawania: ręczne umieszczanie podpisu jest udokumentowane, ale walidator produkcyjny je odrzuca (22 warianty przetestowane na prawdziwym API 10 lipca 2026 roku, wszystkie odrzucone). Pominięcie pola sprawiłoby, że wysyłka by się udała, a podpis zostałby umieszczony automatycznie, po cichu ignorując Twoje współrzędne; wolimy, żeby kończyła się błędem z wyjaśnieniem. Dziś to 121 zielonych testów w Odoo 17, 18 i 19 z tego samego kodu źródłowego, a zestaw przeszedł też na prawdziwym buildzie Odoo.sh.

Przydatne linki

Najczęściej zadawane pytania