Signaturit en Odoo: qué te da un módulo nativo que no te da Zapier

Respuesta corta: Zapier te vale para disparar una firma y enterarte de que se ha completado. No te vale para reflejar dentro de Odoo los estados intermedios por los que pasa un documento, ni para recuperarte de un webhook perdido, ni para dejar el PDF firmado y su documento probatorio archivados en el registro correcto. Si tu proceso acaba cuando el cliente firma, un Zap es suficiente y es más barato. Si tu proceso empieza cuando el cliente firma —facturar, abrir expediente, dar de alta a un empleado—, necesitas los estados dentro del ERP.

El punto de partida: el documento viaja por correo

El circuito habitual tiene tres saltos manuales: alguien genera el PDF del presupuesto en Odoo, lo sube al panel de Signaturit y espera; cuando el cliente firma, el PDF firmado llega a la bandeja de una persona; esa persona lo vuelve a subir a Odoo, si se acuerda. Los síntomas son siempre los mismos: nadie sabe si el cliente lo ha abierto, el PDF firmado acaba en el escritorio de alguien, y cuando hace falta la prueba —el documento probatorio, el audit trail— no está al lado de la factura, que es donde cualquiera la buscaría.

Antes de nada, un requisito que afecta a los tres caminos por igual: tu plan de Signaturit tiene que incluir acceso a la API. La autenticación es un token Bearer que se saca del panel, y sandbox y producción son dos registros distintos con dos tokens distintos. Signaturit no publica en abierto qué planes incluyen ese acceso, así que confírmalo con ellos antes de diseñar nada. Sin token no hay ni Zap, ni n8n, ni módulo.

Las tres formas de unirlos, y dónde basta con Zapier

La app de Signaturit en Zapier publica, a día de hoy, un único trigger —«New Signed Document», es decir, «un documento se ha firmado»— y cinco acciones: crear una solicitud de firma, crearla desde una plantilla, cancelarla, enviar un recordatorio y crear un correo certificado. La app de Odoo autoalojado, por su parte, expone triggers y acciones genéricos de registro (crear un registro, un lead, una tarea…). Esa es toda la materia prima disponible.

Dónde basta con Zapier (y puedes dejar de leer)

Si envías un solo tipo de documento, pocos al mes, y solo necesitas que al firmarse se cree una tarea o se avise por chat, monta un Zap y no le des más vueltas. También basta si el documento no nace en Odoo —una NDA preparada en el panel de Signaturit—. La regla es esta: si el estado de la firma no cambia ninguna decisión dentro del ERP, el ERP no necesita saberlo.

Qué documento sale de qué modelo de Odoo

Esta es la parte que un paso genérico de «crear registro» no puede hacer: no sabe renderizar el informe QWeb de un pedido de venta. Cada modelo necesita tres cosas suyas: el título que verá el firmante, el destinatario por defecto y cómo se genera el PDF. En el conector que hemos construido, cada puente resuelve exactamente esos tres puntos.

• Presupuesto y pedido de venta (sale.order): el informe estándar de pedido de venta, con el cliente como firmante.
• Factura (account.move) y pedido de compra (purchase.order), para aceptaciones y confirmaciones de proveedor.
• Albarán de entrega (stock.picking): el informe de albarán, que una vez firmado funciona como prueba de entrega.
• Contrato laboral: hr.contract en Odoo 17 y 18, y hr.version en Odoo 19, donde el módulo de RRHH se refundió. El tipo de detalle que obliga a mantener tres ramas del código, no una.
• Oferta a un candidato (hr.applicant), oportunidad de CRM (crm.lead), ticket (helpdesk.ticket) y proyecto y tarea, para aceptaciones de trabajo realizado.

El ciclo de estados completo, que es donde se cae todo lo demás

La API v3 de Signaturit informa, por documento, de ocho estados: in_queue, ready, signing, completed, expired, canceled, declined y error. Sus eventos de webhook son todavía más granulares: correo entregado, correo rebotado, documento abierto, documento firmado, documento de identidad añadido, caducidad ampliada, audit trail generado…

Dentro de Odoo eso tiene que convertirse en dos cosas distintas. Primera: la solicitud en sí, con su propio ciclo —borrador, enviada, en curso, completada, rechazada, caducada, cancelada, error—. Segunda: un campo en el documento de origen, para que el comercial que abre el presupuesto vea el estado sin salir del presupuesto. En nuestro conector ese campo tiene siete valores: sin enviar, pendiente de firma, firmado, rechazado, caducado, cancelado y error.

Con varios firmantes, el estado hay que deducirlo del conjunto: todos completados, completada; uno que rechaza, rechazada; unos firmados y otros no, en curso. Y hay una protección que solo se aprende fallando: una solicitud cancelada a mano no debe dejarse sobrescribir nunca por un evento posterior, porque Signaturit puede reportar error por documento en una solicitud que tú ya habías cancelado. Sin ella, una cancelación deliberada se convierte sola en un error inexplicable.

La última pieza: los tres estados terminales malos —rechazado, caducado y error— no pueden acabar solo cambiando un color. En el conector generan una actividad pendiente para la persona que creó la solicitud, con la instrucción de decidir si se reenvía, se amplía el plazo o se reemplaza. Un rechazo que nadie mira es exactamente igual que no enterarse.

Reintentos y fallos: por qué un webhook perdido es peor que un error visible

Un error visible te para. Un webhook perdido te deja creyendo que el documento sigue pendiente cuando lleva días firmado —o al revés. La segunda situación es mucho más cara, porque nadie la busca.

Los reintentos tienen que ser asimétricos. En el conector, cada llamada tiene un tiempo máximo de espera de 30 segundos por defecto, configurable. Una lectura (GET) se reintenta hasta dos veces, con espera creciente, ante un 429, 500, 502, 503 o 504. Una escritura (POST, PATCH, DELETE) no se reintenta nunca: reintentar una creación que no es idempotente significa mandar el mismo contrato dos veces al mismo firmante. Vale más un error visible que un duplicado silencioso. Y una regla que suele faltar: una redirección de la API se trata como error duro y no se sigue nunca, porque seguirla con la cabecera de autorización puesta es entregar tu token a la dirección que diga el Location.

El webhook no es la verdad: es un timbre. Signaturit no firma criptográficamente sus webhooks —no hay HMAC— y su documentación no describe ninguna política de reintento automático; sí ofrece un endpoint para relanzar un evento a mano. Con eso encima de la mesa, el evento entrante en el conector se autentica con un token por cuenta dentro de la propia URL, opcionalmente se restringe a la IP de origen que Signaturit publica (una sola, la misma en sandbox y en producción), se registra con una clave de deduplicación SHA-256 del JSON canonizado, y entonces —y solo entonces— se vuelve a preguntar a la API autenticada. Una entrega duplicada responde 200 y no se procesa dos veces.

Y si el evento no llega nunca, hay una red de seguridad: un cron horario recorre hasta 200 solicitudes pendientes y las vuelve a consultar. Esa línea es la diferencia real con un Zap. El Zap depende del webhook; si el webhook se pierde, no hay nada más.

El adjunto que vuelve: dónde se guarda, con qué nombre y con qué auditoría

Cuando la solicitud llega a completada, vuelven dos ficheros, no uno. El PDF firmado se archiva como <nombre>.signed.pdf y el documento probatorio como <nombre>.audit_trail.pdf, ambos adjuntos al registro de la solicitud, que a su vez apunta al presupuesto, la factura o el albarán del que salió. Ninguno de los dos acaba en la bandeja de nadie.

Un detalle que solo aparece en producción: el documento probatorio no siempre está listo cuando el documento se firma. Signaturit lo genera aparte y emite un evento propio cuando está disponible. Si la descarga falla, no hay que dejar un hueco: hay que pedir explícitamente su generación y recuperarlo en el ciclo siguiente. Un conector que se baje el PDF firmado y se olvide de la traza te deja con la mitad de la prueba. Y si le has pedido al firmante que suba documentación —DNI, justificante de domicilio—, esos ficheros se bajan aparte, en un ZIP, al mismo registro.

Qué mirar antes de elegir enfoque

1. ¿Cuántos tipos de documento envías a firmar? Uno solo, un Zap. Cuatro o más, cada uno con su PDF y su destinatario, y mantener cuatro Zaps ya cuesta más que un módulo.
2. ¿El estado de la firma cambia alguna decisión dentro de Odoo? Si al firmarse hay que facturar, planificar o dar de alta a alguien, el ERP necesita el estado. Si solo hay que avisar a alguien, no.
3. ¿Necesitas el documento probatorio archivado? Si lo tienes que enseñar a una inspección o en un litigio, mejor que esté al lado de la factura.
4. ¿Qué pasa si nadie mira el panel durante dos semanas? Pregunta a quién le salta una tarea cuando un contrato caduca sin firmar. Si la respuesta es «a nadie», todavía no tienes integración.
5. ¿Cuántas versiones de Odoo tienes que sostener? Un Zap no depende de la versión; un módulo sí, y el salto de hr.contract a hr.version es el coste real de eso.
6. ¿Tu plan de Signaturit tiene API? Sin token no funciona ninguna de las tres opciones. Compruébalo antes de nada.

De dónde sale todo esto

Hemos construido siete módulos sobre esta integración: el núcleo, que resuelve cuentas, solicitudes, destinatarios, eventos y archivo, y seis puentes para CRM, servicio de asistencia, RRHH, proyectos, selección de personal y almacén. En total, 270 pruebas automatizadas en la rama de Odoo 19, 262 en la de 18 y 266 en la de 17: el mismo código se mantiene a la vez para las tres versiones.

Ninguna de las decisiones de este artículo sale de leer la documentación. Salen de rondas sucesivas de QA contra el conector real: en una sola ronda se corrigieron 23 defectos encontrados probándolo en vivo y 5 más de una auditoría adversarial contra la documentación de la API; en la siguiente, 17 más. El registro de cambios del módulo los enumera uno por uno, con fecha. Una ficha autogenerada de «producto A × producto B» no tiene ninguna de esas cicatrices, porque nadie la ha usado nunca.

Enlaces útiles dentro de FlexigoTech

Preguntas frecuentes