Documenso 2.11 en cámaras: firmas, plantillas y auditoría
Caso anonimizado para ordenar firmas internas con Documenso: plantillas, destinatarios, PostgreSQL, S3, permisos, webhooks y respaldo.
Acta, contrato y autorización: si la firma llega por tres canales, la auditoría llega tarde. En una cámara empresaria de San Martin, Mendoza, convenios, altas de socios y poderes viajan por correo, mensajeria y papel. Documenso 2.11.0 permite plantillas, destinatarios, enlaces y API. Este caso muestra donde vive cada documento, quien firma, quien consulta y cómo se recupera sin perseguir correos perdidos.
Dónde se pierde una firma antes de archivarla
La cifra que corrige la rutina esta en la documentación de entorno: Documenso requiere PostgreSQL 14 o superior para una instalación propia. Esa exigencia baja una discusion practica: las firmas y estados deben vivir en una base consultable, no solo en PDFs sueltos. Un PDF firmado sin estado deja a tesoreria contando correos. El dato de contexto viene de Octoverse 2025, que informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una cámara regional trabaja con otra escala, pero necesita el mismo rastro: plantilla, destinatario, fecha, evento, archivo final y permiso.
El convenio que volvia sin dueño
El antagonista es el convenio reenviado cinco veces, con una firma en la última página y sin registro de quién lo aprobo. El tesorero conserva un bibliorato negro con separadores amarillos y una caja de recibos al lado del sello de la institucion. El objeto que decide la discusion es el PDF final con evento de envio, apertura, firma y cierre. La guía de self-hosting de Documenso describe despliegue con Docker, base, correo, almacenamiento S3 compatible y certificado de firma. La referencia de variables de entorno lista secretos, URL publica, base PostgreSQL, SMTP y opciones de almacenamiento. La API permite crear, consultar y enviar documentos con clave de aplicación.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, administración crea una plantilla de convenio, autorización o alta. Segundo, Documenso recibe PDF, campos y destinatarios. Tercero, PostgreSQL guarda documento, firmantes, estados, equipos, permisos y auditoría. Cuarto, S3 guarda PDFs originales y finales con metadatos. Quinto, SMTP envia avisos y enlaces de firma. Sexto, webhooks informan eventos a un sistema interno. Septimo, backup copia base, objetos, variables y plantillas, y se prueba restaurando un documento cerrado. Documenso recibe documentos, campos y destinatarios; entrega enlaces, estados, PDF final y eventos. PostgreSQL recibe registros estructurados y entrega consultas por socio, expediente y fecha. S3 recibe archivos grandes y entrega originales y firmados. El permiso separa autor, revisor, firmante, consulta y administrador. Si falla SMTP, no salen invitaciones. Si falla S3, queda el estado sin archivo. Si falla la base, el PDF existe pero no queda trazabilidad operativa.
Qué se instala o configura primero
La pila inicial usa Documenso 2.11.0, PostgreSQL 18, S3 o MinIO, SMTP autenticado, HTTPS, secretos de aplicación, equipos por área, backup diario y webhook de cierre. El piloto cuesta entre USD 1.100 y USD 3.500, entre ARS 1,56 y ARS 4,96 millones al dólar vendedor oficial de $1.416 informado por Bluelytics. Incluye cuatro plantillas, veinte firmas de prueba, permisos y restauración. El plazo va de tres a cinco semanas. UMSA suele pedir un entregable verificable: plantilla aprobada, envio a dos firmantes, estado abierto, PDF final, webhook recibido, usuario de consulta y recuperacion en otro host. El costo no incluye dictamen legal sobre validez de instrumentos, compra de certificados ni firma masiva historica. La primera prueba conviene hacerla con un convenio de adhesion. Secretaria crea el documento, tesoreria revisa monto, presidencia autoriza, el socio firma y un usuario externo intenta entrar al archivo. El sistema debe rechazarlo y dejar evento. La segunda prueba usa una plantilla vencida. Administración duplica un convenio viejo, cambia el texto y lo manda a revisión. El sistema debe marcar nueva versión, bloquear la anterior para envios nuevos y conservar documentos ya firmados. Esa prueba evita que un cambio de modelo contamine expedientes cerrados. La tercera prueba revisa salida. Se descarga el PDF final, se consulta el evento por API y se abre el archivo desde un perfil de solo lectura. Si cualquiera de los tres pasos falla, la firma queda incompleta para auditoría. El reporte diario lista pendientes por responsable y antiguedad.
Dónde se rompe y cómo probarlo Primer riesgo: plantillas sin versión.
La señal aparece cuando dos socios firman textos distintos con el mismo nombre. La prueba guarda hash, fecha y aprobador de cada plantilla. Segundo riesgo: destinatario mal cargado. La señal es una firma enviada a un correo personal equivocado. La prueba exige doble revisión antes del envio. Tercer riesgo: webhooks sin validación. La señal aparece cuando el sistema interno acepta eventos sin secreto. La prueba envia un evento falso y exige rechazo. Cuarto riesgo: backup sin objetos S3. La señal es una base restaurada con documentos que no abren. La prueba restaura base y bucket en otro entorno. La validez juridica de cada documento queda en manos del asesor legal de la entidad.