Scrive y Odoo: firma electrónica sin salir del ERP

Scrive lista más de setenta sistemas en su propio directorio de integraciones —Salesforce, HubSpot, Dynamics 365, Teamtailor, SD Worx, Make, Microsoft Teams, Pipedrive— y Odoo no está entre ellos: lo que ofrece en su lugar es un formulario para pedir la integración que falte. Por eso, si tu empresa usa las dos cosas, lo normal es el circuito manual: exportar el PDF desde Odoo, subirlo al portal de Scrive, esperar, y volver a adjuntar el documento firmado a mano en el pedido o en el contrato. Este artículo explica qué cambia cuando ese circuito vive dentro de Odoo, qué no cambia y cuándo no compensa moverlo.

Por qué te encuentras Scrive y no otro proveedor

En España casi nadie elige Scrive por su cuenta. Scrive AB es sueca, y el catálogo de identificación electrónica que ofrece lo dice todo: BankID sueco, BankID noruego, MitID danés, MitID Erhverv, la Finnish Trust Network, Freja eID. Es exactamente lo que necesita un grupo nórdico y exactamente lo que no usa nadie en Barcelona. El escenario típico del lector de este artículo es ese: la matriz firmó con Scrive, la decisión bajó, y la filial española se encontró con un proveedor de firma que no eligió y que no va a cambiar.

Eso cambia la pregunta. No es «qué firma electrónica compro», que es la pregunta de casi todos los artículos que encontrarás; es «cómo dejo de trabajar fuera del ERP con el proveedor que ya tengo». FlexigoTech es System Partner de Scrive —consta en nuestra página de partners tecnológicos y de Odoo— y construye y mantiene el conector de Scrive para Odoo 19, 18 y 17. Lo que sigue sale de ese código y de lo que hace contra la API real de Scrive, no de un folleto.

Qué se rompe cuando no hay integración

El circuito exportar-firmar-reimportar funciona. Ese es el problema: funciona lo justo para que nadie lo arregle, y falla siempre por los mismos cuatro sitios.

• El documento firmado vive en el correo. El PDF sellado llega al buzón de quien lo envió. Si esa persona está de vacaciones, cambia de puesto o se va, el contrato firmado no está en Odoo: está en una conversación de correo que nadie más ve.
• Nadie sabe el estado sin preguntar. El pedido de venta en Odoo sigue en presupuesto. Si el documento se envió, si se abrió, si lo firmó una de las dos partes, si caducó o si lo rechazaron solo se sabe entrando al portal de Scrive, y solo lo sabe quien tiene usuario allí.
• El adjunto que vuelve no siempre es el bueno. Reimportar a mano invita a subir el borrador en lugar del PDF sellado, o a subir el sellado y perder el registro de evidencias que lo acompaña. Cuando alguien impugna un documento, esa diferencia es todo lo que tienes.
• Los datos del firmante se teclean dos veces. Nombre, correo y móvil ya están en el contacto de Odoo. Volver a escribirlos en otro portal es la vía más corta a mandar un contrato a una dirección antigua.

El flujo con un módulo nativo: del registro de Odoo al PDF sellado en el chatter

Con el conector instalado, el punto de partida es un registro de Odoo, no un fichero. En un pedido de venta, una factura, un pedido de compra o directamente sobre cualquier adjunto aparece un botón de envío a firma que abre un asistente. Ahí se elige la cuenta de Scrive, una plantilla si la hay, el título que verán los firmantes, el idioma del documento, los días para firmar y el recordatorio automático; y se listan las partes, que se rellenan solas desde el contacto de Odoo.

De cada parte se define su papel (firmante, aprobador u observador), su etapa dentro del orden de firma, cómo se le hace llegar el documento —correo, SMS, ambos, un enlace para compartir a mano, o firma presencial en el mismo dispositivo— y con qué método se identifica para ver y para firmar. Al confirmar, el asistente crea un documento de Scrive enlazado al registro de origen: el conector guarda el modelo y el identificador del registro del que salió, y ese vínculo es lo que hace que todo lo demás caiga en el sitio correcto.

A partir de ahí el estado del documento en Scrive se refleja en el registro de Odoo. Estos son los estados que maneja el conector, mapeados uno a uno contra los que devuelve la API de Scrive:

Los cambios de estado llegan por dos vías a la vez, y eso es deliberado: Scrive avisa por callback en cuanto algo pasa, y además una tarea programada del conector repasa cada hora los documentos que siguen en circulación. La primera vía da inmediatez; la segunda es la red de seguridad para el día en que el callback no llegue. En los dos casos el estado que se guarda es el que devuelve la API al volver a preguntar, no el que venía dentro del aviso.

Cuando el documento se cierra, el conector descarga el PDF sellado, lo crea como adjunto del registro de origen —no de un modelo aparte— y publica una nota en el chatter de ese registro con el PDF colgado. El paquete completo de evidencias, el ZIP con el documento firmado, el registro de firma y los ficheros, se descarga a demanda y se archiva igual. El pedido de venta, a partir de ese momento, lleva encima su propio contrato firmado.

Identificación del firmante: un sueco y un español no tienen lo mismo

Esta es la parte que más sorprende al equipo español, y conviene mirarla antes de firmar nada con clientes. Scrive separa dos cosas: con qué se identifica una persona para ver el documento y con qué se identifica para firmarlo. El conector expone las dos listas tal cual las define la API, sin recortarlas.

• Para ver hay quince opciones: sin identificación, PIN por SMS, BankID sueco, BankID noruego, MitID danés, MitID Erhverv, Finnish Trust Network, iDIN de Países Bajos, Freja eID, Freja OrgID, OneID, tres variantes de Onfido y Verimi.
• Para firmar hay veinte: las anteriores más BankID noruego en modalidad QES, itsme (QES), Smart-ID (QES), Verimi (QES) y las dos opciones de QES propias de Scrive.

Cuenta los métodos ligados a un país concreto y verás el patrón: Suecia, Noruega, Dinamarca, Finlandia, Países Bajos, Bélgica, los países bálticos, Alemania. No hay ningún método de identificación específicamente español en la lista. Ni Cl@ve, ni DNIe, ni certificado de la FNMT. Y no es un olvido: es que la plataforma está construida sobre el esquema de identidad electrónica que sí existe en el norte de Europa.

En la práctica, un firmante sueco se identifica con BankID y el conector le exige el personnummer antes de dejar salir el envío, porque sin él Scrive rechazaría el documento. Un firmante español acabará, casi siempre, en una de estas tres: firma estándar sin identificación electrónica, PIN por SMS —que obliga a tener el móvil del contacto en formato internacional, y el conector lo valida antes de enviar— o una de las opciones QES, si la tenéis contratada con Scrive.

Esa elección determina el nivel eIDAS del documento, y por tanto quién tiene que probar qué si alguien lo impugna. La firma estándar o con PIN por SMS es firma simple: el artículo 25.1 del Reglamento (UE) 910/2014 impide negarle efecto jurídico por ser electrónica, pero no le da presunción de autenticidad. Solo la firma cualificada tiene, por el artículo 25.2, «el efecto jurídico equivalente al de una firma manuscrita» en toda la UE. Si el contrato es de los que acaban en un juzgado, esa distinción vale más que la comodidad del flujo; lo desarrollamos en firma electrónica eIDAS en Odoo.

Qué no cubre: esto no sustituye a Odoo Sign

Conviene decirlo pronto porque ahorra una discusión interna. Odoo Sign es un módulo de la edición Enterprise: no aparece entre los addons del código de Odoo Community, así que si estáis en Community la comparación ni se plantea. Si estáis en Enterprise, Sign ya lo tenéis pagado y hace bien lo suyo: el firmante traza su firma con el ratón o el dedo y el documento queda archivado en el chatter. Lo que no hace es verificar la identidad del firmante contra un documento oficial ni emitir un certificado cualificado, así que se queda en firma simple.

El criterio práctico es repartir, no migrar. Documentos internos y de bajo riesgo —un anexo, un acuse de recibo, una autorización entre departamentos— con Odoo Sign, que es inmediato y ya está dentro. Documentos con contraparte externa, con dinero o con riesgo legal, por Scrive: ahí es donde el registro de evidencias de un tercero y la identificación fuerte valen lo que cuestan. Las dos cosas conviven en la misma base de datos; el conector no toca Odoo Sign ni compite con él.

Qué hace falta para probarlo

1. Una cuenta de Scrive, la que ya tenéis. El conector obtiene las credenciales intercambiando un login de Scrive por los cuatro tokens de acceso personal, contra el endpoint que la propia API expone para eso. Está comprobado contra producción con una cuenta de prueba gratuita creada desde la web, sin pasar por comercial: la prueba de conexión respondió correctamente. Para conectar no hace falta negociar nada.
2. Decidir el entorno. El conector distingue producción del API Testbed de Scrive. El testbed es el sitio para desarrollar y validar la integración; no tiene garantías de datos ni de disponibilidad, así que no se mezclan documentos reales con pruebas.
3. Elegir modo de autenticación. Hay tres: credenciales de acceso personal, que son cuatro tokens estáticos y es lo más simple; OAuth2 con vuestro propio cliente registrado en Scrive, que obliga a registrar una URL de retorno para esa base de datos exacta; o la conexión a través del cliente OAuth2 de FlexigoTech, que evita ese registro.
4. Dos permisos en Odoo. El módulo trae un grupo de usuario, que envía a firma y sigue el estado, y un grupo de responsable, que además configura cuentas y credenciales. Las credenciales no las ve el usuario normal. Si tenéis varias compañías en la misma base de datos, las reglas de registro ya separan cuentas, documentos y partes por compañía.
5. Un firmante de pruebas con datos reales. El asistente valida antes de enviar que exista el correo o el móvil que el método de entrega elegido necesita, y que el móvil esté en formato internacional. Es a propósito: vale más un error en Odoo que un rechazo de Scrive a mitad del envío.

Sobre versiones: el conector existe en 19, 18 y 17, y no es una línea en un manifiesto. El módulo principal lleva 241 pruebas automáticas y las mismas 241 están en las tres ramas; con los puentes a recursos humanos, almacén y proyecto son 255 en Odoo 19 y 253 en 18 y 17, y la diferencia son pruebas específicas de versión. Se ejecutan en cada versión en vez de dar por bueno el port, que es la única forma de que «compatible con 17, 18 y 19» signifique algo.

Cuándo no compensa integrarlo

Un conector no se instala porque exista. Hay tres situaciones en las que el circuito manual sigue siendo la respuesta correcta, y decirlo por adelantado ahorra un proyecto que nadie va a usar.

• Volumen bajo y una sola persona. Si firmáis cinco o diez documentos al mes y siempre los envía la misma persona, exportar y reimportar cuesta menos que instalar, configurar y formar. El umbral real no es el número de firmas: es cuánta gente distinta necesita saber el estado sin preguntar. En cuanto son tres o cuatro personas y ninguna tiene usuario en Scrive, el cálculo cambia.
• El documento no nace en Odoo. Si el contrato se redacta en Word, pasa por legal y nunca vive dentro de un registro del ERP, la integración no te ahorra el paso que duele: seguirás subiendo un fichero. Aquí lo que hay que arreglar primero es de dónde sale el documento, no cómo se firma.
• Necesitas firma cualificada para firmantes españoles y no la tienes contratada. Conectar funciona desde cualquier cuenta, pero el método con el que se identifica el firmante depende de lo que tengáis con Scrive. Si el requisito es QES en España y no está en vuestro contrato, esa conversación es con Scrive antes que con nadie; y si el proveedor estuviera abierto, compáralo con lo que ofrecen alternativas europeas como e-Signature.eu o Signaturit, que también tienen conector para Odoo.

Si quieres el detalle técnico —los endpoints concretos de la API que usa el conector, el mapeo de niveles eIDAS y las diferencias entre las tres ramas de Odoo—, está escrito en la versión inglesa de este artículo: Scrive Odoo integration: e-signing without leaving the ERP.

Seguir leyendo en FlexigoTech

Preguntas frecuentes