El módulo Contacts gestiona el directorio de clientes finales (compradores de lotes) de cada proyecto: sus datos personales, residencia, cónyuge, beneficiario y los archivos de su expediente. Es el punto de entrada de la información de personas sobre la que se apoyan todos los procesos comerciales del sistema: ventas, cobranza y generación de contratos.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.
Los contactos están acotados al proyecto activo. El
BranchId del JWT determina sobre qué proyecto opera cada alta y consulta. Un mismo comprador que adquiere lotes en dos proyectos distintos tendría dos registros de contacto independientes.Modelo de dominio
Cliente (Contacto) — entidad principal
Campos según el v1 (apéndice de variables B.1, tablaContacts + joins):
| Grupo | Campos |
|---|---|
| Identidad | Nombre completo; CURP/RFC (campo único CurpRfc; sirve para MX y US, RN-01); fecha de nacimiento; género (catálogo); estado civil (catálogo); ocupación |
| Ubicación | Dirección (texto); País / Estado / Municipio / Localidad (catálogos Geo) |
| Cónyuge | Nombre; ocupación; CURP; fecha de nacimiento (todos opcionales — los contratos los envuelven en bloques condicionales {{#if}} para que desaparezcan si no hay cónyuge, RN-02) |
| Beneficiario | Nombre; género; fecha de nacimiento (variables A.4 del apéndice, RN-02) |
| Adjuntos | Identificaciones y comprobantes vía módulo Files (RT-12/RT-13) |
Campos adicionales del expediente (teléfonos, correo del cliente final) son un punto abierto: las fuentes actuales no los enumeran; confirmarlos con el equipo antes del alta definitiva (punto abierto 1).
Flujos
Flujo 4.1 — Alta y edición
CRUD estándar bajo la matriz de permisos (submódulo Contactos del grupo G. Comercial).Capturar datos del contacto
El usuario completa el formulario con los datos de identidad, ubicación geográfica (en cascada desde el módulo Geo) y, opcionalmente, los datos del cónyuge y beneficiario.
Adjuntar archivos del expediente
Las identificaciones y comprobantes se suben mediante el flujo de URLs prefirmadas del módulo Files (RT-12/RT-13): el front solicita la URL al backend, realiza el
PUT directo a S3 y confirma la metadata.Flujo 4.2 — Consumo por ventas
La venta referencia al contacto por su id. Al generar el contrato, LegalDocs resuelve las variables del cliente, cónyuge y beneficiario desde este módulo (apéndice A.2 a A.4).Matriz de permisos
Los permisos de este módulo se configuran en la matriz RBAC del grupo G. Comercial.| Grupo | Submódulo | Ver | Escribir | Actualizar | Eliminar | Descargar |
|---|---|---|---|---|---|---|
| G. Comercial | Contactos | ✓ | ✓ | ✓ | ✓ | ✓ |
Reglas de negocio
RN-01 — Identificación fiscal flexible
RN-01 — Identificación fiscal flexible
El campo
CurpRfc es un identificador fiscal único y flexible: sirve para México (CURP/RFC) y para Estados Unidos (T02: el sistema es agnóstico al país).RN-02 — Cónyuge y beneficiario opcionales
RN-02 — Cónyuge y beneficiario opcionales
Los datos de cónyuge y beneficiario son completamente opcionales. Su ausencia no bloquea el alta del contacto ni ningún proceso posterior (ventas, contratos). Las plantillas de LegalDocs manejan su ausencia con bloques condicionales
{{#if}} (apéndice A.3).RN-03 — Cuota del plan
RN-03 — Cuota del plan
El alta de un contacto está sujeta a la cuota del recurso
CLIENTES del plan de suscripción (C01 segunda ronda). Si se alcanza el límite, el sistema rechaza el alta con un error de validación.Puntos abiertos
Los siguientes puntos están pendientes de confirmación con el equipo:
- Campos adicionales del expediente (teléfonos, correo del cliente final): las fuentes actuales no los enumeran; confirmarlos con el equipo. Si es necesario, extraer del código del v1 en
old/para verificar los campos exactos. - Puente lead → Contacto: la relación con el módulo CRM (leads y pipeline) queda diferida al análisis del CRM (decisiones-internas sección 5, punto 7).