Assinatura eIDAS no Odoo com e-Signature.eu: itsme, Evrotrust e pagamento por assinatura

A e-Signature.eu é uma plataforma europeia de assinatura eIDAS: não vende anuidades, vende crédito, e cada assinatura gasta-o. O conector que a liga ao Odoo foi construído e é mantido por nós, com uma versão para cada série (17, 18 e 19) (ficha do módulo). Este artigo trata do que quase ninguém conta antes de comprar: que nível é realmente necessário, o que a outra parte tem de fazer para assinar e como muda a conta quando se paga por assinatura em vez de por ano.

Os três níveis do eIDAS, explicados pelo que mudam no seu processo

O Regulamento (UE) 910/2014 define três níveis e a diferença legal está no seu próprio texto (artigos 3.º, 25.º e 26.º). O que não está no regulamento é a diferença operacional: cada nível pede algo diferente ao signatário e, quanto mais se pede, mais gente desiste pelo caminho.

Estes quatro métodos são o catálogo completo do conector, e não é editável: ninguém pode etiquetar como «qualificada» uma assinatura que não o é.

Quando é que é mesmo preciso QES?

A maioria das empresas que pergunta por assinatura qualificada quer-na para documentos que não a exigem. O critério útil não é «quanto vale o contrato», é «há alguém que a vai exigir por escrito»:

• Trâmites perante uma administração que a exige. Em França, a e-Signature.eu documenta que, desde janeiro de 2023, o INPI exige assinatura qualificada para as formalidades de alteração e cessação de empresa do Guichet unique. Aí não há discussão: ou é QES ou o trâmite não entra.
• Contrapartes que o incluem na sua política de compras. Grandes contas, seguradoras e alguns bancos pedem-na por defeito.
• Documentos que espera que alguém impugne. Se o litígio for um cenário realista, a QES coloca o ónus da prova a seu favor.

Tudo o resto (confirmações, avisos de receção, anexos internos) fica em SES; os contratos B2B habituais, em AES. E uma ressalva honesta: a QES não substitui os atos que a lei obriga a elevar a escritura pública perante notário. O erro mais caro não é ficar aquém: é pôr QES por defeito e depois perguntar porque é que as pessoas demoram quatro dias a assinar uma guia de remessa.

itsme, Evrotrust, Veriff e OTP: o que cada um pede ao signatário

itsme® é a identidade digital belga. Na Bélgica, o registo clássico pede o eID com leitor de cartões ou o cartão de um banco belga; fora da Bélgica basta, segundo a e-Signature.eu, passaporte, documento de identificação ou autorização de residência, mas a cobertura depende da lista de países do itsme®: confirme-a antes de prometer uma QES a alguém. A Evrotrust é um prestador qualificado de serviços de confiança (QTSP) búlgaro inscrito na lista de confiança da UE; é também uma app móvel, tem uma cobertura mais ampla e é o método que o INPI francês admite desde 2026, segundo a e-Signature.eu.

A Veriff não é um QTSP: é verificação de identidade, documento mais selfie, e daí sai uma AES. O OTP é um código por e-mail ou SMS, e daí sai uma SES. Há aqui um pormenor que nos custou uma ronda inteira de revisão com a e-Signature.eu: a plataforma descarta em silêncio qualquer telefone que não seja «+» seguido de dígitos simples. Uma pessoa escreve «+32 483 22 90 07», a plataforma guarda-o vazio e o OTP por SMS volta a cair no e-mail sem avisar. O conector normaliza o número antes de o enviar; foi descoberto na sétima ronda de revisão, a 14 de julho de 2026.

O que muda no fluxo do Odoo consoante o nível

O conector acrescenta um botão Send for Signature a orçamentos, faturas, pedidos de compra, contratos de funcionários (hr.version no Odoo 19, hr.contract no 18 e no 17), candidaturas, contactos e qualquer PDF anexo. Não depende da app Sign, que nem sequer consta do manifesto, e isso importa porque a própria documentação do Odoo diz que a Sign gera assinaturas eletrónicas simples, o primeiro dos três níveis: para AES ou QES é preciso recorrer a um prestador.

O assistente obriga a escolher em separado o nível legal mínimo e os métodos, e não deixa combiná-los mal: com o mínimo em «Qualificada», o envio com OTP ou Veriff é rejeitado, e a mesma validação aplica-se aos métodos por defeito da conta. Parece um pormenor e evita a falha mais comum: um processo etiquetado como QES servido por um código SMS.

Com SES o envio sai diretamente: o signatário introduz o código e o PDF assinado regressa sozinho. Com QES há um passo de identificação que tem de desenhar: o signatário precisa da app instalada e da identidade já verificada, e, se for a primeira vez, esse registo pode demorar mais do que o contrato. A consequência prática é aborrecida e funciona: avise a contraparte antes de enviar.

Há dois modos: no modo e-mail o convite é enviado pela e-Signature.eu; no modo fluxo do Odoo o orçamento sai pelo circuito nativo e o cliente assina a partir do seu portal, onde «Assinar» substitui «Aceitar e pagar». O segundo escondia uma falha que corrigimos: a sessão na e-Signature.eu só deve ser criada quando o e-mail é realmente enviado; antes, descartar o rascunho deixava o pedido como enviado.

Subscrição contra pagamento por assinatura: a conta de cabeça

Uma subscrição paga-se igual, assine ou não, e quase sempre traz um limite de envelopes. O modelo da e-Signature.eu é o contrário: compram-se pacotes de créditos, o preço por crédito desce com o volume e cada assinatura consome crédito consoante o seu nível. No seu catálogo (o mesmo que o conector replica), uma QES com itsme® ou Evrotrust consome um crédito por signatário, uma AES com Veriff 0,7 e uma SES por OTP 0,4, quer vá um ou cinco documentos no pedido.

A conta é de uma linha: divida a anuidade pelo preço do crédito e obtém o número de assinaturas a partir do qual a subscrição compensa. Faça-a com a anuidade que lhe proponham e com a tarifa que a e-Signature.eu publica no seu site: o resultado é um número, não uma opinião. E há um efeito de segunda ordem: com subscrição paga o mesmo assine SES ou QES, pelo que nada o incentiva a ajustar o nível; com créditos, escolher AES em vez de QES custa 30 % menos nessa assinatura. Escolher o nível passa de discussão jurídica abstrata a decisão económica, em cada envio.

O saldo vê-se dentro do Odoo, com a sua data de atualização: a API não tem endpoint de saldo (devolve-o dentro da resposta de cada pedido), pelo que o conector capta-o do último e atualiza-o com um cron diário, em vez de fingir um dado em tempo real que não existe.

O que se guarda e onde fica a evidência

Uma assinatura sem evidência recuperável não serve no dia em que é preciso. Quando o pedido é concluído, ficam três coisas no Odoo:

• O PDF assinado, anexado ao documento de origem e nomeado a partir dele (S00026-signed.pdf), não do identificador interno do pedido. Parece cosmético até alguém procurar o seu contrato e não o encontrar.
• O audit trail da e-Signature.eu, guardado como <documento>-audit-trail.pdf. Atenção: a plataforma gera-o pouco depois de o pedido ser concluído, pelo que pode não estar disponível se o pedir logo no momento da assinatura; o conector avisa-o em vez de falhar sem explicação.
• Um relatório probatório próprio do módulo, com o nível eIDAS efetivamente alcançado, os métodos, a hora da assinatura, o SHA-256 do documento assinado e, por cada signatário, a sua identidade verificada, o método usado e quando assinou.

E um botão que não verá em muitos conectores: Verify eIDAS signature abre a ferramenta de validação DSS da Comissão Europeia para que valide o PDF assinado com algo que não somos nós nem a e-Signature.eu. Por baixo, o estado sincroniza-se com um webhook assinado com HMAC-SHA256, um registo de idempotência e um cron horário de recuperação; e apagar um pedido concluído apaga-o também do histórico da e-Signature.eu.

Dez rondas de revisão com a e-Signature.eu

Este conector não foi escrito apenas com base na documentação: foi colocado à frente da equipa da e-Signature.eu, partiu-se e voltou a ser escrito. No repositório há um ficheiro de testes por cada ronda, de test_round2.py a test_round10.py. Dois exemplos, além do telefone da ronda 7:

• Ronda 9. Um pedido cancelado a partir do painel da e-Signature.eu ficava em «Enviado» dentro do Odoo para sempre. E a correção óbvia (voltar a consultá-lo) também não servia: cancelar a partir do painel apaga-o na e-Signature.eu e a consulta responde 401.
• Ronda 10. Parar um pedido a meio da assinatura deixava o signatário pendente eternamente: a plataforma rejeita a operação se ainda ninguém assinou, e o código engolia o erro e marcava-o como parado na mesma.

Há até uma função que o conector se recusa a fingir: a colocação manual da assinatura está documentada, mas o validador de produção rejeita-a (22 variantes testadas contra a API real a 10 de julho de 2026, todas rejeitadas). Omitir o campo faria o envio funcionar colocando a assinatura automaticamente, ignorando em silêncio as suas coordenadas; preferimos que falhe com uma explicação. Hoje são 121 testes verdes no Odoo 17, 18 e 19 com o mesmo código-fonte, e a suite também foi executada numa build real do Odoo.sh.

Ligações úteis

Perguntas frequentes