Odoo concentra la facturación, las órdenes de compra, los contratos de personal y los expedientes de cliente. El documento nace ahí, pero la firma casi siempre ocurre afuera: alguien descarga el PDF, lo firma con el token y lo vuelve a subir como adjunto. Ese salto manual es donde se pierden las horas y donde aparecen las tres versiones del mismo contrato sin que nadie sepa cuál es la buena.
Integrar la firma dentro de Odoo no es complicado técnicamente. Lo difícil es decidir tres cosas antes de escribir la primera línea: qué objeto se firma, dónde vive la clave privada y cómo se comporta el sistema cuando la firma falla.
Qué vas a firmar: XAdES o PAdES no son intercambiables
En una instalación típica de Odoo en Ecuador conviven al menos tres tipos de documento y cada uno exige un tratamiento distinto:
- El XML de comprobantes electrónicos del SRI: la firma va incrustada dentro del propio XML en formato XAdES, siguiendo la estructura que define la ficha técnica del SRI. No es un PDF firmado ni un archivo adjunto aparte; si el XML se altera después de firmar, aunque sea un espacio en blanco, el comprobante se rechaza.
- El PDF de negocio: contratos, actas, órdenes de compra, certificados. Aquí corresponde PAdES, la firma incrustada en el propio PDF, con o sin representación visual en la página.
- Documentos internos sin efecto frente a terceros: en muchos casos no requieren certificado y basta la trazabilidad del sistema.
Mezclar los dos primeros es el error de arranque más común: equipos que firman el PDF de la factura y creen que con eso cumplieron ante la administración tributaria. El detalle de lo que exige el organismo está en la guía de firma electrónica y facturación electrónica ante el SRI.
Dónde vive el certificado (y dónde nunca debería vivir)
Guardar el archivo .p12 en un campo binario del modelo o en el filestore de Odoo es tentador porque funciona a la primera. También es la peor decisión del proyecto: ese archivo hereda los permisos de lectura del ORM, viaja en cada respaldo y termina en el entorno de pruebas cuando alguien clona producción.
Las alternativas razonables, en orden creciente de control:
- Firma en la nube del proveedor: la clave privada no sale del entorno del emisor y Odoo solo consume un servicio. Es el camino más corto y el que menos superficie de ataque deja del lado del ERP.
- Servicio de firma propio en la red interna: un componente pequeño que lee el .p12 desde un almacén de secretos y expone la operación de firma solo a Odoo. Odoo nunca ve la clave.
- Token USB o HSM: el token obliga a tener una máquina encendida con el dispositivo conectado y alguien que ponga el PIN, lo cual choca con cualquier proceso desatendido. Para volumen alto, el camino es un módulo de hardware dedicado.
Si todavía no está definido el formato de emisión, la comparación entre firma en la nube, archivo .p12 y token ayuda a cerrar esa discusión antes de diseñar la integración.
Tres formas de integrar y qué cuesta cada una
| Enfoque | Cómo funciona | Cuándo conviene | Costo de mantenimiento |
|---|---|---|---|
| Módulo Odoo propio | Un módulo en Python que extiende los modelos existentes, agrega estados y llama al servicio de firma | Cuando la firma es parte del proceso central y hay equipo Python interno | Alto: cada actualización mayor de Odoo obliga a revisar el módulo |
| Capa intermedia | Un servicio externo escucha eventos de Odoo, firma y devuelve el resultado | Cuando hay varios sistemas que necesitan firmar, no solo el ERP | Medio: se actualiza independiente del ERP |
| Automatizador visual | Un orquestador conecta Odoo con el servicio de firma sin código propio | Volumen bajo o medio, procesos que cambian seguido | Bajo al inicio, crece con la cantidad de escenarios |
El tercer enfoque es el más subestimado: para un flujo de veinte contratos al mes no tiene sentido mantener un módulo propio. En ese rango funcionan bien las opciones descritas en firma electrónica con n8n. La contrapartida es que se pierde el control transaccional que sí da un módulo nativo.
La firma no es una llamada de dos segundos
El error de diseño más caro es tratar la firma como una operación síncrona dentro del clic del usuario. Entre la generación del documento, la llamada al servicio, la respuesta y el sellado de tiempo pueden pasar minutos, y el navegador no espera. El patrón correcto es asincrónico:
- El documento tiene un estado propio, no un booleano: borrador, en cola, enviado a firma, firmado, error. Un booleano no permite distinguir un documento que nunca se envió de uno que falló.
- La solicitud entra a una cola de trabajos con su propio reintento, fuera del hilo del usuario.
- Cada solicitud lleva una clave de idempotencia derivada del documento y su versión, para que un reintento no genere dos firmas ni dos adjuntos.
- Los reintentos usan espera creciente y tienen tope. Superado el tope, el documento entra a una bandeja de errores que alguien revisa; no se reintenta en silencio para siempre.
El retorno conviene resolverlo con notificaciones del proveedor en lugar de consultar en bucle. La mecánica, con verificación de origen y reintentos, está explicada en webhooks de firma electrónica.
El PDF que se regenera y borra la firma
Odoo genera los reportes PDF al vuelo cada vez que alguien pulsa imprimir. Si la acción de impresión sigue apuntando a la plantilla después de firmar, el usuario descarga un PDF nuevo, idéntico en apariencia pero sin firma. Es el reclamo más frecuente en estas integraciones y no es un fallo del certificado.
La regla práctica: una vez firmado, el PDF pasa a ser un adjunto inmutable y la acción de impresión debe devolver ese adjunto cuando existe, no volver a renderizar. Un cambio posterior en la plantilla no debe tocar los documentos ya firmados. Si el síntoma es una firma que existe pero no se ve, revisa por qué la firma no aparece en el PDF.
Multicompañía, multifirmante y permisos
En instalaciones con varias compañías en la misma base, cada una tiene su RUC y su certificado. La selección tiene que derivarse de la compañía del documento, nunca de la compañía activa del usuario: quien tiene acceso a tres empresas puede firmar con el certificado equivocado sin notarlo, y ese comprobante es inválido.
Además conviene separar dos permisos: quién puede disparar la firma y quién firma. El asistente contable puede tener el primero; el representante legal es titular del segundo. Cuando hay varias personas firmando desde el mismo ERP, la administración de esos certificados se vuelve un tema en sí mismo, tratado en gestión corporativa de varios firmantes.
Qué monitorear cuando ya está en producción
- Vigencia de los certificados: una alerta con semanas de anticipación evita el día en que la facturación se detiene.
- Tasa de error por tipo: no es lo mismo un tiempo de espera agotado que una cadena de certificados incompleta.
- Documentos detenidos en estado enviado por más de un umbral definido.
- Verificación independiente: una rutina que abre el archivo firmado y comprueba la firma, en lugar de confiar en que el servicio respondió bien. El enfoque está en validar firmas de forma programática.
El esquema de estados, colas y verificación aplica a cualquier ERP; la versión general está en cómo automatizar la firma de documentos en tu ERP.
El certificado y la emisión
Firmas.com.ec emite certificados con trámite 100% en línea y entrega en aproximadamente 30 minutos, en archivo .p12, token USB o firma en la nube, con validez legal y ante el SRI. Para un proyecto con Odoo, la firma en la nube suele ser la opción natural porque no exige hardware conectado al servidor. El precio actualizado está en la página de precios.
Si además de firmar necesitas emitir los comprobantes electrónicos autorizados por el SRI, el grupo cuenta con Azur, un sistema de facturación electrónica autorizado que se encarga del ciclo de firma, envío, autorización y entrega del comprobante. Puedes revisarlo en azur.com.ec.
La coordinación que ninguna integración captura
El grupo también desarrolla Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida.
En un proyecto de integración con Odoo hay un tramo que ningún flujo formal registra: el mensaje al cliente avisando que el contrato ya está disponible, el reclamo del proveedor que no recibió la orden firmada, el seguimiento comercial mientras el documento circula. Con historial por cuenta y asignación por responsable, esa conversación deja de vivir en celulares personales. Más información en omnifox.io.
Preguntas frecuentes
¿Existe un módulo estándar de firma electrónica ecuatoriana para Odoo?
Hay módulos de localización que cubren la parte fiscal, pero el componente de firma depende del proveedor y de dónde se guarde la clave privada. En la práctica, casi todos los proyectos terminan con una capa propia o con un servicio externo que Odoo consume.
¿Puedo firmar con un token USB desde el servidor de Odoo?
Técnicamente el token requiere que el dispositivo esté conectado a la máquina que firma y que alguien introduzca el PIN. Para procesos desatendidos ese modelo no escala; se usa firma en la nube o un módulo de hardware.
¿Qué pasa si el certificado vence a mitad de mes?
Los documentos firmados antes siguen siendo válidos si la firma incluye sello de tiempo, porque se puede demostrar que el certificado estaba vigente en ese momento. Los nuevos fallan hasta que se cargue el certificado renovado.
¿Conviene guardar el PDF firmado en Odoo o en un repositorio aparte?
Depende del volumen. Odoo sirve como índice; para volúmenes grandes es común almacenar el binario en un repositorio externo y dejar en Odoo la referencia, el hash y el estado.
Si tu equipo diseña la integración de firma dentro de Odoo y quiere resolver primero la parte del certificado, conversa con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.