O que preencher ao criar um fornecedor
A ficha do fornecedor é o primeiro sítio onde mexes. Alguns campos são comuns e outros dependem de o fornecedor ser DocuSign ou Yousign. Os nomes dos campos estão em inglês no módulo, por isso aqui aparecem tal e qual.

Providers com fornecedores de demonstração DocuSign e Yousign, todos em Not TestedQue campos são comuns ao DocuSign e ao Yousign?
Cada fornecedor fica ligado a uma empresa através de company_id, um campo Many2one para res.company. Tem também a lista Allowed Levels, cuja ajuda diz Empty = every level the provider supports.: se a deixares vazia, valem todos os níveis que esse fornecedor suporta; se quiseres restringi-la, adiciona apenas os níveis que vais permitir. Há ainda uma caixa de seleção DPA Confirmed, um campo Account / Plan e um campo Hourly API Call Limit, que no código se chama max_envelope_limit e guarda o limite de chamadas à API por hora.
O que pede a ficha de um fornecedor DocuSign?
As credenciais vão em Integration Key, API User ID e RSA Private Key. Segundo a ajuda, API User ID é o GUID do utilizador que a integração representa, e RSA Private Key é guardada cifrada. Depois tens AES Signature Provider e QES Signature Provider: em cada um vai o signatureProviderName usado para os destinatários AES e para os destinatários QES, respetivamente.
E a de um fornecedor Yousign?
Aqui a credencial é API Key, que também é guardada cifrada. O outro campo próprio é a caixa QES activated by Yousign. A ajuda explica que o Yousign mantém o QES desativado até o seu suporte o ativar, por isso a caixa deve refletir se o Yousign já o ativou na tua conta.
O que acontece se editar um fornecedor e deixar a chave vazia?
Tanto RSA Private Key como API Key têm a mesma ajuda: Stored encrypted. Leave empty to keep the current one. Se editares a ficha e não escreveres nada nesse campo, mantém-se a chave que já estava guardada. Só tens de o preencher quando quiseres substituí-la.
Os estados que vais ver no Odoo
O módulo usa vários campos de estado. Convém conhecer os seus valores antes de começar a rever listas, porque são os que aparecem nas colunas e nos filtros.
O que significa o estado do último teste de um fornecedor?
É o campo last_test_status, com três valores: Not Tested, Success e Failure. Na lista de Providers da captura anterior, os fornecedores de demonstração estão todos em Not Tested.
Que estados pode ter um registo de assinatura?
Um dos campos state do módulo admite estes valores: Draft, Queued, Sent, Viewed, Partially Signed, Completed, Declined, Voided, Expired e Error. Se quiseres ver o percurso interno de um registo e que menus intervêm, tens tudo em como funciona o módulo por dentro.

Signature Requests com registos de demonstração e fornecedores dos ambientes Sandbox e Demo EnvironmentExiste outro conjunto de estados mais curto?
Sim. Outro campo state do módulo tem apenas quatro valores: Pending, Viewed, Signed e Declined. Repara que Viewed e Declined existem nos dois campos, por isso confirma em que lista estás antes de tirar conclusões de um filtro.

Evidence Vault com um registo de demonstração em Completed, nível pedido AES e ligado a sale.orderO que rever na primeira semana
Por onde começo a rever?
Pela lista de Providers. Confirma que o estado do último teste de cada fornecedor que vais usar está em Success e não em Not Tested ou Failure. Depois revê, ficha a ficha, que a empresa em company_id é a correta, que Allowed Levels contém o que queres permitir (ou está vazio de propósito), que DPA Confirmed reflete a tua situação e, no Yousign, que QES activated by Yousign coincide com o que o suporte te confirmou. No DocuSign, verifica que AES Signature Provider e QES Signature Provider têm o signatureProviderName correspondente.
Que registos de assinatura convém analisar com atenção?
Filtra os registos de assinatura pelos estados Error, Expired, Declined e Voided e abre-os um a um. Se um registo mostrar uma mensagem de erro, tens os textos literais do módulo e o que fazer com cada um em as mensagens de erro e avisos. Dentro da app há mais listas que podes percorrer nessa revisão: Retention Policies, Webhook Events e Audit Events.

Anota que fornecedor usa cada empresa e que níveis permitiste em cada um. Quando alguém perguntar porque é que um nível não aparece, a resposta está em Allowed Levels dessa ficha.
Como a FlexigoTech te ajuda
O módulo está publicado na Odoo Apps para Odoo 17, 18, 19 e 20, a 9 € sem IVA, pagamento único por versão, em cada uma delas. Podes vê-lo na ficha da Odoo Apps ou na página do módulo. Se também precisares de implementar o Odoo 17, 18, 19 ou 20, ou de um conector ou integração à medida em torno dos teus fluxos de assinatura, na FlexigoTech desenvolvemo-lo contigo.
Continue a ler
Verificado no código do módulo (versão 20.0) e nas fontes indicadas
Fontes
- Código do módulo: flexigo_docusign_yousign_bridge_for_regulated_sign_work 20.0 (d528b22d): models/sign_bridge_provider.py
- Código do módulo: flexigo_docusign_yousign_bridge_for_regulated_sign_work 20.0 (d528b22d): models/sign_bridge_request.py
- Código do módulo: flexigo_docusign_yousign_bridge_for_regulated_sign_work 20.0 (d528b22d): models/sign_bridge_signer.py
- apps.odoo.com/apps/modules/20.0/flexigo_docusign_yousign_bridge_for_regulated_sign_work
- apps.odoo.com/apps/modules/17.0/flexigo_docusign_yousign_bridge_for_regulated_sign_work
- apps.odoo.com/apps/modules/18.0/flexigo_docusign_yousign_bridge_for_regulated_sign_work
- apps.odoo.com/apps/modules/19.0/flexigo_docusign_yousign_bridge_for_regulated_sign_work
- flexigotech.com/en/services.html
