Make se diferencia de otros automatizadores en un punto que importa mucho para la firma de documentos: permite ver y manipular el recorrido de los datos paso a paso, con ramificaciones, ciclos y manejo de errores por rama. Eso lo vuelve especialmente adecuado para procesos por lotes, que es exactamente la forma en que la mayoría de las empresas ecuatorianas firma: cincuenta contratos de nómina el mismo día, doscientas actas al cierre de mes, un paquete de certificados cuando termina un curso.
Ese mismo poder es la trampa. Un escenario con iteradores, agregadores y tres rutas condicionales es un programa, y como todo programa necesita control de errores, idempotencia y una forma de saber qué pasó con el documento número 47 del lote.
El vocabulario que hay que tener claro
Antes de diseñar conviene fijar cuatro conceptos, porque las decisiones de arquitectura dependen de ellos:
- Módulo: cada paso del escenario. Consume una operación cada vez que se ejecuta, y esa cuenta es la que define el costo del proceso.
- Paquete de datos: la unidad que viaja entre módulos. Si un módulo devuelve cincuenta elementos, los módulos siguientes se ejecutan cincuenta veces.
- Iterador y agregador: el primero descompone una colección en elementos individuales; el segundo vuelve a juntarlos. Un lote de firma casi siempre necesita los dos, y olvidar el agregador es la causa típica de escenarios que envían cincuenta correos en vez de uno.
- Enrutador: bifurca el flujo según condiciones. Cada rama puede tener su propio tratamiento de errores.
Un escenario de firma por lotes, descrito paso a paso
- Disparador programado: a una hora definida, consulta al sistema de negocio qué documentos están aprobados y pendientes de firma.
- Filtro: descarta lo que no debe pasar (sin firmante, sin archivo, tipo no contemplado). Filtrar temprano ahorra operaciones y evita errores tardíos.
- Iterador: separa el lote en documentos individuales.
- Llamada al servicio de firma, documento por documento, con clave de idempotencia y tiempo de espera explícito.
- Registro del resultado en un almacén de datos del propio escenario o, mejor, en el sistema de origen.
- Agregador: consolida los resultados del lote.
- Cierre: un resumen al responsable con cuántos se firmaron, cuántos fallaron y por qué.
El paso siete es el que convierte un escenario en un proceso operable. Sin resumen, nadie descubre que tres actas del lote quedaron sin firmar hasta que alguien las reclama. El mismo principio, aplicado a volúmenes mayores, está en firma masiva en la nube para grandes volúmenes.
Manejo de errores por rama, no por escenario
La fortaleza real de Make en este caso es que cada módulo puede tener su propio controlador de error con una directiva distinta. Las decisiones que hay que tomar:
| Tipo de fallo | Directiva razonable | Efecto |
|---|---|---|
| Servicio no disponible o tiempo agotado | Reintento con espera | El documento se firma en el siguiente intento sin intervención |
| Documento inválido o firmante inexistente | Continuar y registrar | El lote sigue; ese documento queda marcado para revisión |
| Certificado vencido o revocado | Detener el escenario | Evita que todo el lote falle uno por uno y dispara la alerta |
| Error al archivar el documento ya firmado | Reintento y registro obligatorio | El documento existe firmado: perderlo es peor que no haberlo firmado |
La tercera fila es la más importante y la que casi nadie configura al inicio. Un certificado caducado en medio de un lote de doscientos documentos genera doscientos errores idénticos y un consumo inútil de operaciones. Anticiparlo es cuestión de alertas de vigencia, como se explica en cómo verificar si un certificado está caducado.
Almacenes de datos: el estado que el escenario no tiene
Los escenarios son sin memoria entre ejecuciones. Si el proceso necesita recordar qué documentos ya se enviaron a firma, o cuántos reintentos lleva cada uno, ese estado tiene que vivir en algún lado. Make ofrece almacenes de datos propios, y sirven bien para casos acotados.
Dicho eso, hay una jerarquía de preferencias que conviene respetar:
- Lo ideal es que el estado viva en el sistema de negocio, porque ahí es donde la gente lo consulta y donde tiene sentido auditarlo.
- El almacén del escenario es aceptable para control de duplicados y contadores de reintento.
- Lo que no funciona es depender del historial de ejecuciones como registro del proceso: tiene retención limitada y no se puede consultar como una tabla.
Archivos y consumo de memoria
Cada paquete de datos que contiene un archivo lleva ese binario consigo mientras avanza por el escenario. En un lote de documentos escaneados grandes, eso se nota. Tres prácticas concretas:
- Mover referencias, no archivos. Enviar al servicio de firma un identificador y un enlace temporal de descarga en lugar del contenido completo reduce el peso del escenario y el riesgo de tropezar con límites de tamaño.
- Dividir lotes grandes en tandas más chicas ejecutadas de forma secuencial, en lugar de intentar procesar mil documentos en una sola corrida.
- No encadenar conversiones a texto codificado: cada una infla el tamaño y ninguna aporta al resultado final.
Programado o instantáneo
Un escenario puede ejecutarse por intervalo o reaccionar a un webhook. Para firma, la elección depende del caso de uso:
- Por intervalo: adecuado para lotes de fin de mes, nómina, cierres. Concentra el trabajo, es fácil de monitorear y no exige que el sistema de origen sepa notificar.
- Instantáneo: adecuado cuando el usuario espera el documento firmado en pantalla. Requiere que el sistema de origen envíe la notificación y que el escenario responda rápido.
Muchas empresas terminan con los dos: uno instantáneo para el flujo comercial y uno programado que barre lo pendiente y sirve de red de seguridad. Ese segundo escenario es el que detecta los documentos que se perdieron por una notificación no entregada, un problema tratado en webhooks de firma electrónica.
Verificar antes de dar por cerrado
Un módulo que responde correctamente no garantiza que el documento resultante sea válido. Vale la pena incluir un paso de verificación que compruebe la firma del archivo devuelto antes de archivarlo y notificar. Es una operación adicional por documento y evita descubrir meses después que un lote entero quedó con la cadena de certificados incompleta, un fallo explicado en qué significa el error de cadena de certificados. El procedimiento de comprobación está en validar firmas de forma programática.
Cuándo el escenario ya no alcanza
Hay tres señales de que el proceso creció más que la herramienta: el consumo de operaciones se vuelve un renglón visible del presupuesto, el escenario tiene tantas ramas que nadie se anima a tocarlo, o el equipo necesita reconstruir con precisión qué pasó con un documento específico hace seis meses. Cuando aparecen dos de las tres, conviene mover la lógica a un servicio propio y dejar el automatizador solo como disparador; el enfoque comparado está en firma electrónica con n8n y el marco general en cómo automatizar la firma de documentos en tu ERP.
Los certificados
Firmas.com.ec emite certificados de firma electrónica con trámite 100% en línea y entrega en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube, con validez legal y ante el SRI. Para escenarios desatendidos, la firma en la nube es la modalidad que corresponde, porque no depende de un equipo con token conectado. Consulta el precio actualizado en la página de precios y, si hay varios firmantes, revisa gestión corporativa de varios firmantes.
Automatizar también el aviso al cliente
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 proceso por lotes, el aviso a cada destinatario suele ser el paso más descuidado: se envía por correo y nadie lo abre. Centralizar esos canales con historial por contacto y responsable asignado cierra el circuito entre el documento firmado y la persona que tiene que recibirlo. Más información en omnifox.io.
Preguntas frecuentes
¿Cuántas operaciones consume firmar un documento?
Depende de cuántos módulos tenga el escenario, no del documento. Un diseño compacto que delega el trabajo a un servicio propio consume mucho menos que uno que resuelve todo con módulos encadenados.
¿Puedo firmar un lote completo con una sola llamada?
Eso depende de lo que ofrezca el proveedor. Algunos aceptan solicitudes por lote y otros trabajan documento por documento. Es una pregunta concreta para la etapa de selección, porque cambia por completo el diseño del escenario.
¿Cómo evito firmar dos veces el mismo documento?
Con una clave de idempotencia por documento y versión, y con un registro de estado consultado antes de enviar. Depender solo del filtro inicial no alcanza si dos ejecuciones se solapan.
¿Qué pasa si el escenario se detiene a mitad del lote?
Los documentos ya firmados quedan firmados y el resto sigue pendiente. Por eso el estado debe registrarse documento por documento y no al final del lote: permite reanudar sin repetir.
¿Sirve para firmar comprobantes electrónicos del SRI?
No es el camino adecuado. El comprobante requiere firma sobre el XML con el formato definido por la administración tributaria y autorización posterior; corresponde un sistema de facturación autorizado.
Si tu empresa firma por lotes y quiere automatizar el proceso con un certificado válido en Ecuador, conversa con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.