Assinatura eletrónica no Odoo: como escolher fornecedor consoante o nível eIDAS, o volume e o país do signatário

A escolha de fornecedor de assinatura eletrónica para o Odoo é determinada por três perguntas, não pela marca: que nível eIDAS exige o documento, quantos documentos assina por ano e em que país está quem assina. Se a resposta for «simples, poucos e o país é indiferente», o Odoo Sign basta. Se precisar de assinatura qualificada, de um método de identificação de um país concreto ou de um volume que compense pagar por assinatura, entra um dos três fornecedores para os quais construímos conector: e-Signature.eu, Scrive ou Signaturit. O que é o eIDAS está em assinatura eletrónica eIDAS no Odoo.

Odoo Sign nativo: que nível dá e onde basta

A documentação oficial do Odoo di-lo sem rodeios: dos três tipos que o eIDAS distingue, «o Odoo gera o primeiro, assinaturas eletrónicas simples». O Sign é um módulo do Enterprise, não está nos addons da Community, e faz bem o seu trabalho: o signatário desenha a assinatura ou aceita com um clique e o documento fica no chatter com um certificado de conclusão (hash por signatário, selo temporal e IP). Como identificação extra oferece código por SMS, itsme® (UE, Reino Unido, Islândia e Noruega) e Aadhaar na Índia; os três consomem créditos de compra integrada e, sem crédito, a identificação é ignorada.

Basta para o que se assina entre partes que não vão discutir a autoria: avisos de receção, autorizações internas, anexos, aceitações de clientes habituais. Não basta quando alguém exige por escrito assinatura avançada ou qualificada, quando o signatário precisa de um esquema de identidade nacional que o Sign não traz, ou quando o fornecedor já foi escolhido pela casa-mãe do grupo.

Os quatro, lado a lado

«Países fortes» é onde o método de identificação é aquele que as pessoas já têm instalado. Sem valores de preço: cada fornecedor define os seus.

Por tipo de documento

• Orçamento e encomenda de venda. O que mais se assina e o que menos nível precisa: Odoo Sign ou o nível simples de qualquer fornecedor. Levá-lo para fora tem uma razão operacional, não legal: que o estado «assinado» chegue sozinho à encomenda.
• Contrato com contraparte externa. Identidade verificada (AES) e, se o litígio for realista ou a contraparte o exigir, QES. O erro caro é pôr QES por defeito e a contraparte demorar dias a registar-se numa identidade digital que não tinha.
• Contrato de trabalho e RH. Nasce em RH (hr.version no Odoo 19, hr.contract no 18 e 17); os três conectores têm ponte com RH e o nível simples ou avançado costuma bastar. O que importa é que o contrato assinado e a sua evidência voltem ao processo.
• Setor regulado e administração. Quando a norma diz «qualificada» não há nível a escolher: é QES ou o processo não entra, como no Guichet unique francês para alterações e cessações de empresas. O que se escolhe é o método: com a e-Signature.eu, itsme® ou Evrotrust; na Scrive, as QES do BankID norueguês, Smart-ID, Verimi ou as próprias.

O fluxo dentro do Odoo muda consoante o fornecedor

Os três conectores começam num botão do registo do Odoo e terminam com o PDF assinado anexado a esse registo; muda o que fica pelo meio, porque cada API conta o estado à sua maneira e nenhuma das três assina o seu aviso de alteração: os três tratam-no como uma campainha e voltam a perguntar à API antes de tocar em seja o que for. A e-Signature.eu gere seis estados no pedido (rascunho, enviado, assinado, parado, cancelado, erro) e sete no documento de origem, contando «por enviar»; deduplica o aviso pelo hash do corpo e tem um cron horário de recuperação. Ao fechar-se ficam o PDF assinado, o audit trail do fornecedor e um relatório probatório próprio. Passo a passo, em assinatura eIDAS no Odoo com a e-Signature.eu.

A Scrive distingue dez estados (rascunho, preparação, pendente de arranque, pendente, assinado, cancelado, expirado, rejeitado, erro e guardado como modelo); as alterações chegam por callback, autenticado com um token próprio de cada conta no URL, e por um cron horário. A sua particularidade: o PDF é selado duas vezes e o conector atualiza o mesmo anexo para não deixar dois contratos na mesma encomenda. Está em Scrive e Odoo e, com os endpoints, na sua versão técnica em inglês.

A Signaturit também não assina os seus eventos: o conector autentica-os com um token próprio de cada conta no URL e, se for ativado, verificando o IP de origem; depois deduplica e volta a perguntar à API. O pedido passa por oito estados e o documento de origem mostra sete; rejeitado, expirado e erro programam uma atividade para quem criou o pedido. O detalhe, em Signaturit no Odoo.

Mudar de fornecedor sem mudar de Odoo

Os fornecedores mudam-se: o contrato termina, surge uma exigência de QES que o atual não cobre. O que não deveria mudar é o que o Odoo sabe de cada documento. Quatro coisas devem manter-se estáveis para que a mudança seja um módulo novo e não uma migração:

• A ligação entre o pedido e o registo de origem: modelo e identificador.
• Um campo de estado na origem com vocabulário comum: por enviar, pendente, assinado, rejeitado, expirado, cancelado, erro.
• O PDF assinado e a sua evidência como anexos do registo de origem, nomeados pelo documento e não pelo identificador do fornecedor.
• Uma nota no chatter por cada mudança de estado.

Com isso, o que foi assinado antes continua pesquisável e as automatizações não notam a mudança. Os pedidos em curso não se migram: terminam-se com o fornecedor antigo ou reenviam-se com o novo. É o critério de qualquer conector do Odoo para o software de um parceiro.

Checklist de decisão

1. Quem poderia exigir-lhe por escrito um nível concreto para cada documento? Se ninguém, é SES e o Odoo Sign serve.
2. Veja o país dos signatários, não o seu: o método que já têm instalado pesa mais do que o logótipo.
3. Divida a quota anual pelo preço por assinatura: esse é o ponto em que compensa cada modelo.
4. Verifique que o plano inclui API. Sem token não há conector.
5. Exija que o PDF assinado e a evidência voltem ao registo de origem do Odoo.
6. Pergunte o que acontece quando o webhook não chega. Sem uma ação agendada que volte a perguntar, não há integração.
7. Se o fornecedor já foi escolhido pelo grupo, integre o que existe e deixe o interno no Odoo Sign. Os três estão em parceiros tecnológicos e do Odoo e em soluções.

Perguntas frequentes

Ligações úteis dentro da FlexigoTech

O que fazemos sobre isto