Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevCarlosRodriguez/Documentacion-Arccnova-2.0/llms.txt

Use this file to discover all available pages before exploring further.

El módulo LegalDocs es el motor único de documentos legales para todo el sistema. Centraliza las plantillas HTML con variables, la generación de instancias inmutables y el proceso completo de firma electrónica. Lo consumen dos módulos: Sales (contratos de compraventa de lotes) y Hr (contratos laborales); gracias al patrón Strategy internamente, las fases futuras de firma —NOM-151 y Adobe Sign— se podrán activar sin alterar el esquema ni la lógica existente.

Modelo de dominio

LegalDocs trabaja con cuatro entidades principales.

Plantilla

HTML por empresa, versionado en plano (Code + VersionNumber + IsCurrent). Se puede importar desde .docx —la app lo convierte a HTML—, editar en rich text y previsualizar en PDF o Word. Solo una versión activa por código de plantilla (índice parcial único).

Variable del sistema

Catálogo global de variables inyectables con su fuente de datos. Sintaxis {{nombreVariable}}, case-insensitive. Una variable sin valor se sustituye por cadena vacía.

Documento (instancia)

Snapshot HTML con variables resueltas. Estados: Draft, PendingSignatures, Signed, Cancelled, Expired. Al completarse todas las firmas se genera el PDF definitivo (FinalPdfUrl + FinalPdfHash).

Firma

Firmantes tipados (cliente final, usuario, externo, empleado). Token único con expiración configurable para firma remota. Trazo guardado como imagen (SignatureImageUrl) con IP y fecha. IsSigned + SignedAt.

Motor de variables

El motor reemplaza las marcas {{nombreVariable}} con los datos de la venta o del contrato laboral. El orden de procesamiento es obligatorio y fijo.
1

Firmas

Se insertan primero los tokens de imagen de firma de cada firmante.
2

Variables especiales de lotes

{{lotsInline}} (lista en párrafo), {{lotsWithArea}} (con superficie), {{lotsBlock}} (bloque HTML con colindancias y medidas por lote). Para un solo lote las variables simples usan el primer lote.
3

Variables de propiedad/proyecto

Nombre del proyecto, municipio, estado, datos de la empresa.
4

Bloques condicionales

Sintaxis {{#if}}...{{/if}}. Si todas las variables del bloque tienen valor, el contenido se muestra; si cualquiera está vacía, el bloque completo se elimina (uso típico: párrafos de cónyuge).
5

Resto de variables

Datos de venta, cliente, totales económicos, planes (enganche, principal, adicional, servicio) y formatos (uppercase, currencytext, dateupper, datetext, percentage, etc.).
Los formatos disponibles para cada variable son: uppercase, currencytext (importe con letra: $5,000.00 (CINCO MIL PESOS 00/100 M.N.)), dateupper, datebirth, dateshort, datetext, percentage, integer, text, modalityplural, string.

Flujos principales

  1. El usuario con permiso de Contratos crea la plantilla en el editor rich text o la importa desde .docx (la app convierte a HTML automáticamente).
  2. Editar una plantilla ya publicada genera una versión nueva (VersionNumber + IsCurrent); el historial es completo y se puede reactivar cualquier versión anterior.
  3. Las instancias ya generadas conservan la versión con la que fueron creadas: los cambios al contrato base no afectan ventas existentes.
  4. Plantillas y versiones consumen cuota del plan (recursos TEMPLATES LEGALES / VERSIONES).
  1. El módulo consumidor (Sales o Hr) solicita la generación indicando la entidad origen (venta o contrato laboral).
  2. El motor resuelve las variables en el orden indicado arriba y guarda el snapshot HTML (estado Draft o PendingSignatures).
  3. El preview lleva marca de agua mientras las firmas digitales estén incompletas (RT-18).
  4. El documento de un cliente específico puede editarse sin afectar la plantilla base ni a otros clientes.
Cuando la entidad origen se anula (por ejemplo, una cancelación de venta), el contrato pasa a estado Cancelled y queda en el histórico; no se borra. Los documentos anulados son consultables pero no descargables como definitivos.

Estrategia de firma electrónica — 4 fases

La arquitectura de firma usa el patrón Strategy (ADR-017): agregar NOM-151 o Adobe Sign en fases futuras no altera el esquema ni la lógica de fase 1.
MVP funcional — sin costo adicional.Trazo simple en pantalla (firma autógrafa digital) almacenado como imagen, con una capa de transparencia e información de contexto para el firmante.Qué se incorpora en esta fase:
  • Aviso informativo antes de firmar: el firmante ve un mensaje claro sobre la naturaleza de la firma electrónica utilizada.
  • Cláusula de aceptación expresa en el contrato: reconocimiento y aceptación explícita por parte del firmante.
  • Casilla de confirmación previa: el firmante debe marcarla antes de proceder a trazar la firma.
  • Aviso en el acuse final: en el correo o pantalla de cierre se reitera la naturaleza del documento firmado.
Esta capa de transparencia protege a la empresa demostrando buena fe ante cualquier eventualidad legal futura.
La fase actual es la Fase 1. La decisión de avanzar a cada fase siguiente es independiente y se toma cuando hay justificación clara de negocio, sin compromisos adquiridos con proveedores externos.

Firma híbrida (RT-28)

La firma híbrida ocurre cuando uno de los dos firmantes firma de forma manuscrita (en papel) y el otro digitalmente en el sistema.

Dos firmantes en venta

Cliente y responsable (asesor/empleado). Cuando ambas son digitales, no hay orden obligatorio. En modo híbrido la digital va primero, la manuscrita después (decisión informada y aceptada por el stakeholder).

Marca de agua

El preview del documento lleva marca de agua hasta que todas las firmas digitales estén completas. Al completarse las digitales se retira la marca de agua; si hay una manuscrita pendiente, el documento queda listo para imprimirse.

Enlace remoto

Cada firmante recibe un token único con expiración configurable para firmar de forma remota. El firmante puede rechazar la firma (R18).

En RH

Los contratos laborales aplican la misma mecánica. El enlace remoto y la posibilidad de rechazo aplican igual.

Generación del PDF definitivo (RT-30)

Al completarse todas las firmas del proceso:
  1. El backend genera el PDF definitivo con QuestPDF.
  2. Se calcula el hash SHA-256 del binario generado.
  3. El PDF y su hash se persisten en un bucket S3 aislado (inmutable).
  4. Ese PDF es el único archivo descargable; cualquier alteración posterior es matemáticamente detectable.
  5. Se envía copia automáticamente a todos los firmantes por correo.
El PDF de operaciones (comprobantes de pago, recibos informativos) lo genera el front según el patrón RT-29. Solo los documentos legales formales —contratos y recibos de nómina— se generan en el backend con QuestPDF y se almacenan con hash (RT-30). No confundas los dos flujos.

Contratos laborales en RH

El módulo LegalDocs es el proveedor de contratos para Hr.EmployeeDocs: las plantillas de contratos laborales, el motor de variables (con el catálogo de variables de empleado como employee.first_name, branch.legal_name, contract.base_salary) y la firma electrónica son los mismos que para los contratos de venta.
El catálogo completo de variables para contratos laborales está pendiente de confirmación con el equipo al construir Hr.EmployeeDocs. El apéndice actual cubre el catálogo de ventas; el catálogo de RH se derivará del mismo modelo.

Matriz de permisos

SecciónPermisoDescripción
Ajustes › Contratossettings.contracts.viewVer plantillas de la empresa
Ajustes › Contratossettings.contracts.editCrear, editar y versionar plantillas
G. Comercial › Contratossales.contracts.viewVer contratos de venta generados
G. Comercial › Contratossales.contracts.signIniciar y completar proceso de firma (protegido)

Reglas de negocio consolidadas

ReglaDescripción
RN-01Solo una versión activa por plantilla (IsCurrent con índice parcial único).
RN-02Variable sin valor = cadena vacía; bloque {{#if}} se elimina completo si alguna variable del bloque está vacía.
RN-03Orden de procesamiento de variables fijo (ver sección Motor de variables).
RN-04Firma fase 1: trazo simple + avisos de transparencia; sin NOM-151 ni e.firma.
RN-05Firma híbrida: digital primero; marca de agua hasta completar digitales.
RN-06Token de firma remota con expiración configurable; rechazo permitido.
RN-07PDF protegido = PDF hasheado y almacenado; es el único descargable definitivo.
RN-08Documento anulado se conserva en histórico, no se borra.
RN-09Patrón Strategy para firma: agregar NOM-151 o Adobe no altera esquema ni lógica existente (ADR-017).

Build docs developers (and LLMs) love