En una empresa que corre sobre SAP, ninguna integración es un fin de semana de trabajo. Hay ambientes, transportes, roles, un comité que aprueba cambios y un equipo funcional que pregunta —con razón— por qué habría que tocar un proceso que ya funciona. Sumar firma electrónica a ese entorno exige decidir bien desde el inicio, porque rehacer la arquitectura después cuesta el triple.
Esta guía plantea las decisiones que un equipo de TI ecuatoriano tiene que tomar antes de abrir un ticket: qué se va a firmar, dónde vive la clave, qué componente dispara la firma y cómo se prueba sin comprometer el certificado de producción.
Tres escenarios que se confunden
Lo primero es separar necesidades que se nombran igual pero se resuelven distinto:
- Comprobantes electrónicos para el SRI. El sistema genera el XML del comprobante, lo firma y lo envía. Aquí el formato de firma y el flujo están definidos por el organismo y no hay margen de diseño.
- Documentos internos de negocio. Órdenes de compra, contratos con proveedores, actas de recepción, documentación de personal. Se firman normalmente en PDF y las reglas las pone la empresa.
- Documentos que entran firmados desde afuera. Lo que llega de un proveedor o un cliente y hay que validar y archivar. Es un problema de verificación, no de firma.
Un proyecto que mezcla los tres en un solo requerimiento termina con un diseño que no sirve para ninguno. Conviene abordarlos por separado, aunque compartan la misma infraestructura de firma.
Dónde ejecutar la firma
La decisión de arquitectura central. Las opciones realistas:
| Enfoque | Ventaja | Costo | Cuándo conviene |
|---|---|---|---|
| Servicio de firma externo, SAP como cliente | Aísla la criptografía del sistema central; se actualiza sin transportes | Un componente más que operar | La opción por defecto en la mayoría de los casos |
| Firma dentro del sistema, con sus componentes de seguridad | Sin dependencias externas | Configuración especializada y dependencia de perfiles escasos | Cuando la política prohíbe salir del entorno |
| Middleware de integración | Orquestación, reintentos y monitoreo listos | Licenciamiento y una capa más de diagnóstico | Si el middleware ya está en operación |
| Componente de terceros instalado en el sistema | Puesta en marcha rápida | Dependencia del proveedor para cada actualización | Alcance acotado y sin equipo de desarrollo propio |
La recomendación práctica: un servicio de firma independiente, expuesto por interfaz web, que recibe el documento o su resumen y devuelve el resultado firmado. El sistema central lo consume como cualquier servicio externo. Ventajas concretas: la clave privada no vive en el entorno del sistema de negocio, el componente se actualiza sin pasar por el ciclo de transportes, y el mismo servicio sirve para otras aplicaciones de la empresa.
Ese servicio de firma es un desarrollo acotado y bien conocido: recibe, firma con el perfil que corresponda y devuelve. El detalle de implementación por formato está en firmar PDF con PAdES desde tu backend. El enfoque general de integración con sistemas de gestión está en cómo automatizar la firma de documentos en tu ERP.
El caso ecuatoriano: comprobantes electrónicos
Las implantaciones que emiten comprobantes en Ecuador necesitan resolver la generación del XML según el esquema del SRI, la firma con el perfil exigido, el envío al servicio de recepción, la consulta de autorización y la conservación del comprobante autorizado con su respuesta.
Dos advertencias que ahorran retrabajo. Primera: el documento tributario es el XML; la representación impresa que se entrega al cliente no requiere una firma propia. Firmarla es opcional y no reemplaza nada. Segunda: la respuesta del SRI no es inmediata en todos los casos, así que el proceso necesita estados persistidos y reintentos, no una llamada síncrona que espera. El detalle de la firma está en XAdES para comprobantes del SRI y el marco general en firma electrónica y facturación electrónica ante el SRI.
Si la implantación es acotada o el proyecto no justifica construir el emisor dentro del sistema, el grupo ofrece Azur, sistema de facturación electrónica autorizado por el SRI, que puede recibir los datos desde tu integración y encargarse de la firma, el envío y la entrega. Puedes crear una cuenta en azur.com.ec/registro.
Documentos internos: dónde se dispara la firma
Para órdenes de compra, contratos y actas, la pregunta es en qué punto del proceso de negocio se firma. Tres criterios que ordenan el diseño:
- La firma va al final de la aprobación, no antes. El flujo de liberación del sistema ya resuelve quién autoriza; la firma electrónica se aplica cuando el documento queda aprobado, sobre la versión definitiva.
- Aprobar y firmar no son lo mismo. Los usuarios que solo liberan dentro del sistema no necesitan certificado. Solo lo necesita quien firma con efectos frente a terceros. Esta distinción es la que más reduce el costo del proyecto.
- El documento firmado se archiva enlazado al objeto de negocio, no en una carpeta suelta. Que el PDF firmado quede adjunto a la orden o al contrato es lo que hace útil el archivo dos años después.
Roles, autorizaciones y trazabilidad
Un servicio de firma consumido desde el sistema central introduce una pregunta de control: si el servicio firma con el certificado corporativo, ¿qué impide que cualquier proceso le pida firmar cualquier cosa? La respuesta es autorización en dos niveles.
- Dentro del sistema: solo determinados roles pueden disparar la operación, sobre determinados tipos de documento, y eso se controla con el esquema de autorizaciones que ya existe.
- En el servicio de firma: credenciales por aplicación, restricción por tipo de documento y registro de cada solicitud con su origen.
Con ambos niveles, una auditoría puede reconstruir quién pidió firmar qué y con qué facultad. Con uno solo, no. La custodia del certificado en el servicio tiene sus propias reglas, tratadas en firmar en servidor con .p12.
Rendimiento y cierre de periodo
Los sistemas de gestión concentran la carga en fechas conocidas: cierre contable, facturación masiva, generación de documentación de nómina. Si la firma se ejecuta de forma síncrona dentro de la transacción, esos días el usuario espera frente a la pantalla y el proceso de fondo se ahoga.
El diseño resistente saca la firma del ciclo transaccional: el sistema deja la solicitud en una cola, un proceso la toma y el resultado vuelve al objeto de negocio cuando está listo. Es más trabajo de diseño y es la diferencia entre un cierre normal y una incidencia mensual. El patrón está desarrollado en colas y workers para firma masiva, y el aviso de finalización se resuelve con webhooks de notificación.
Ambientes, transportes y pruebas
Un punto que se subestima y genera incidentes reales: cada ambiente necesita su propio certificado. El certificado de producción no debe existir en desarrollo ni en calidad, porque los ambientes previos tienen más accesos y menos control de cambios. Firmar documentos de prueba con el certificado real, además, produce documentos jurídicamente válidos que después nadie sabe qué hacer con ellos.
El resto de la disciplina es la habitual del entorno: la configuración de conexión al servicio de firma por parámetros y no fija en el código transportado, un plan de pruebas que incluya el caso del servicio caído, y un procedimiento documentado para la renovación del certificado que indique qué configuraciones hay que actualizar y en qué orden.
Cómo empezar sin bloquear el proyecto
Un alcance inicial razonable: un solo tipo de documento, un solo firmante, el servicio de firma funcionando fuera del sistema central y el enlace del documento firmado al objeto de negocio. Con eso operando, ampliar a otros tipos es incremental. Intentar cubrir todos los procesos en la primera entrega es la forma habitual de que el proyecto quede a medias.
Los certificados se emiten 100% en línea, en aproximadamente 30 minutos, en archivo .p12, token USB o firma en la nube según cómo vaya a operar el servicio. Consulta los valores por cantidad de firmantes en la página de precios.
Omnifox junto al proceso de negocio
El grupo también desarrolla Omnifox, plataforma omnicanal que reúne WhatsApp, correo, redes y llamadas en una sola bandeja compartida, con API para integrarse con los sistemas de la empresa. En entornos con procesos formales resuelve el tramo informal que ningún sistema registra: la confirmación con el proveedor, el aviso de que la orden fue emitida, el seguimiento de una recepción pendiente. Detalles en omnifox.io.
Preguntas frecuentes
¿Necesito un módulo adicional del fabricante para firmar?
No necesariamente. Un servicio de firma externo consumido por interfaz web cubre la mayoría de los casos y evita depender de componentes específicos. La decisión depende de la política interna y de qué componentes ya estén licenciados.
¿Todos los aprobadores del sistema necesitan certificado?
No. La liberación dentro del sistema es un control interno que se resuelve con roles y autorizaciones. El certificado lo necesita quien firma documentos con efecto frente a terceros o ante entidades.
¿Se puede firmar desde un proceso de fondo sin intervención humana?
Sí, con el certificado disponible para el servicio de firma. Eso exige autorización escrita del titular, límites por tipo de documento y registro de cada operación, además de las medidas técnicas de custodia.
¿Qué pasa si el servicio de firma no responde durante un cierre?
Con el diseño diferido, las solicitudes quedan en cola y se procesan al restablecerse el servicio, sin perder trabajo. Con diseño síncrono, la transacción falla y el usuario la repite, que es justamente el escenario a evitar.
¿Cómo valido los documentos firmados que recibo de proveedores?
Con un servicio de verificación que compruebe integridad, identidad del firmante y estado del certificado en la fecha de la firma, y que archive el informe junto al documento. Es un componente distinto del de firma y conviene planificarlo aparte.
Si tu empresa va a integrar firma electrónica con su sistema de gestión y necesita certificados para el servicio y sus firmantes, habla con un asesor de Firmas.com.ec. Solicita tu cotización corporativa.