Documenso 2.11 en camaras: firmas, plantillas y auditoria
Caso anonimizado para ordenar firmas internas con Documenso: plantillas, destinatarios, PostgreSQL, S3, permisos, webhooks y respaldo.
Acta, contrato y autorizacion: si la firma llega por tres canales, la auditoria llega tarde. En una camara 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 como se recupera sin perseguir correos perdidos.
Donde se pierde una firma antes de archivarla
La cifra que corrige la rutina esta en la documentacion de entorno: Documenso requiere PostgreSQL 14 o superior para una instalacion 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 mas de 180 millones de desarrolladores y 630 millones de repositorios. Una camara 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 ultima pagina y sin registro de quien 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 guia 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 aplicacion.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, administracion crea una plantilla de convenio, autorizacion o alta. Segundo, Documenso recibe PDF, campos y destinatarios. Tercero, PostgreSQL guarda documento, firmantes, estados, equipos, permisos y auditoria. 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.
Que se instala o configura primero
La pila inicial usa Documenso 2.11.0, PostgreSQL 18, S3 o MinIO, SMTP autenticado, HTTPS, secretos de aplicacion, equipos por area, 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 dolar vendedor oficial de $1.416 informado por Bluelytics. Incluye cuatro plantillas, veinte firmas de prueba, permisos y restauracion.
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. Administracion duplica un convenio viejo, cambia el texto y lo manda a revision. El sistema debe marcar nueva version, 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 auditoria.
El reporte diario lista pendientes por responsable y antiguedad.
Donde se rompe y como probarlo
Primer riesgo: plantillas sin version. La senal 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 senal es una firma enviada a un correo personal equivocado. La prueba exige doble revision antes del envio.
Tercer riesgo: webhooks sin validacion. La senal 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 senal 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.