Los módulos de la Fase 1 Foundation —Tenants, Branches, Geo, Files y BillingSaas— forman el núcleo operativo sobre el que se apoyan todos los demás módulos del sistema. Juntos habilitan el alta de una empresa, la creación de proyectos inmobiliarios con sus catálogos operativos, la gestión geográfica multinacional, el almacenamiento de archivos adjuntos y el control de acceso por suscripción SaaS. Esta página documenta los cinco módulos de la Fase 1 distintos a Identity.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.
Módulo 02 — Tenants (empresa y configuración)
El módulo Tenants representa a la empresa cliente del SaaS (Tenant) y concentra su configuración operativa: catálogos de ámbito empresa que el resto de los módulos consumen.El ciclo de suscripción y los límites del plan no viven en Tenants; se gestionan en BillingSaas. Los datos del Stripe customer también se administran en BillingSaas.
Modelo de dominio
| Entidad | Contenido | Referencia |
|---|---|---|
| Empresa (Tenant) | Nombre, datos de contacto, estado | Consolidado desde Identity |
| Tipo de pago / Método de pago | Catálogos por empresa para la cobranza | Imagen C48 (Ajustes) |
| Moneda | Catálogo de monedas que la empresa opera | C32, C43, Imagen C48 |
| Tipo de cambio | Valor vigente por par de monedas, actualizado manualmente desde Banxico | C45 |
| Tipo de recibo | Catálogo por empresa; lleva el correlativo del folio de recibo | Imagen C48; Cobros-Flujos §5 |
| Sede | Catálogo por empresa; el proyecto referencia una sede | C09; Imagen C48 |
| Día festivo | Calendario por empresa (con ámbito Global / Empresa / Proyecto en el modelo único) | C44; Decisión 17; ADR-021 |
| Modalidad de pago | Catálogo global de periodicidades (lista cerrada) | C25 |
Catálogo de modalidades de pago (lista cerrada — C25)
| Id | Nombre | Frequency | Days | FrecuencyYears |
|---|---|---|---|---|
| 1 | SEMANAL | 7 | 7 | 52 |
| 2 | QUINCENAL | 15 | 15 | 26 |
| 3 | MENSUAL | 1 | 30 | 12 |
| 4 | BIMESTRAL | 2 | 60 | 6 |
| 5 | TRIMESTRAL | 3 | 90 | 4 |
| 6 | CUATRIMESTRAL | 4 | 120 | 3 |
| 7 | SEMESTRAL | 6 | 180 | 2 |
| 8 | ANUAL | 1 | 360 | 1 |
| 9 | DIARIO | 1 | 1 | 365 |
AddMonths(Frequency); para DIARIO, SEMANAL y QUINCENAL con AddDays(Days); ANUAL con AddYears. El campo FrecuencyYears indica el número de períodos por año y divide la tasa anual para obtener la tasa por período (Cobros-Flujos §3.3).
Flujos principales
Configurar catálogos: CRUD estándar por catálogo, restringido por la matriz de permisos (grupo Ajustes). Reglas especiales:- Tipo de cambio: el usuario lo actualiza bajo demanda desde Banxico (C45). No hay actualización automática diaria; cada pago usa el tipo de cambio del día del pago (C32, RT-18).
- La empresa captura su calendario (fecha, nombre, tipo, multiplicadores de nómina).
- Los multiplicadores (
1.00= sin prima) los consume únicamente Nómina (Hr). El núcleo del sistema solo usa la fecha para calcular gracia en vencimientos de cobranza (C24).
Reglas de negocio
- RN-01. Los festivos se administran por empresa (C44); el modelo soporta ámbito Global / Empresa / Proyecto (Decisión 17).
- RN-02. El tipo de cambio se actualiza manualmente bajo demanda (C45).
- RN-03. La lista de modalidades de pago es cerrada: las nueve de la tabla anterior (C25).
- RN-04. Los catálogos de empresa son de ámbito solo-TenantId (RT-02, ADR-010).
Módulo 03 — Branches (proyectos inmobiliarios)
El módulo Branches administra los proyectos inmobiliarios de cada empresa: alta, edición, eliminación lógica, membresías de usuarios con rol por proyecto y el cambio de proyecto activo en sesión. En esta versión el tipo de proyecto es exclusivamente Lotificación (C08); los tipos Construcción y Venta de bienes raíces están en análisis sin fecha definida.Modelo de dominio
Proyecto — campos obligatorios (C09)
| Campo | Nota |
|---|---|
| Nombre del proyecto | |
| Sede | Catálogo de la empresa (Tenants) |
| Área total del proyecto (colonia) | |
| Estado (status del proyecto) | |
| Propietario del predio | |
| Ubicación del proyecto | |
| País, Estado, Municipio y Localidad | Catálogos Geo |
| Moneda | Catálogo de la empresa |
| TEA | Tasa de interés anual del proyecto; default de los planes de financiamiento |
Proyecto — campos opcionales
| Campo | Nota |
|---|---|
| Número catastral | Variable de contrato {{projectCadastralCode}} |
| Costo aproximado por lote | |
| Número de contrato correlativo | Folio de contratos del proyecto (RT-33) |
| Número de recibo correlativo | Folio de recibos del proyecto (RT-33) |
| Imagen (portada) | Vía Files |
| Descripción del proyecto | |
| CURP del propietario | |
| Oficina registral del predio | Variable {{projectLandRegistryOffice}} |
| Denominación del predio | |
| Colindancias (Norte, Sur, Este, Oeste) | Variables {{projectBoundary*}} |
| Descuento (porcentaje) | |
| Tasa de incumplimiento | Default del porcentaje de mora de las ventas (C23 segunda ronda) |
| Días de gracia | Período de gracia para vencimientos (C24) |
| Términos y condiciones | |
| Observaciones |
Membresía usuario-proyecto
Un usuario pertenece a un proyecto con un rol específico en ese proyecto (C12). El modelo completo de roles vive en el módulo Identity.Flujos
HU-01 — Crear proyecto
El CEO captura los campos obligatorios (y los opcionales que desee). El alta consume cuota del recurso “proyectos” del plan (RT-35). El proyecto queda operativo de inmediato; no existe un paso adicional de “configuración completa” (C10).
HU-03 — Eliminar proyecto
El CEO elimina el proyecto con soft-delete (C11): desaparece de catálogos y selectores, pero se conserva en BD por trazabilidad. Se permite eliminar un proyecto con ventas activas o cobranza pendiente, sin bloqueo (C11 segunda ronda).
HU-04 — Asignar usuarios al proyecto
El CEO registra usuarios con su rol en ese proyecto. Puede delegar el alta a un Admin o a un usuario con el permiso correspondiente (C12). El mismo usuario puede tener roles distintos en proyectos distintos (C12 segunda ronda).
Reglas de negocio
- RN-01. Tipo de proyecto fijo en Lotificación en esta versión (C08).
- RN-02. El proyecto es operativo desde su creación (C10).
- RN-03. Eliminar = soft-delete, sin bloqueo por ventas activas (C11 + segunda ronda).
- RN-04. La tasa de incumplimiento y los días de gracia del proyecto son defaults; la venta captura su propio porcentaje de mora (C23) y la gracia del proyecto aplica a los vencimientos (C24).
- RN-05. TEA del proyecto = tasa de referencia para los planes de financiamiento de sus ventas (C09).
- RN-06. Membresía con rol por proyecto (C12).
- RN-07. El alta de proyecto está sujeta a la cuota del plan (recurso “proyectos”, C01 segunda ronda).
Módulo 04 — Geo (catálogos geográficos)
El módulo Geo provee los catálogos geográficos jerárquicos de solo lectura que consumen el alta de proyectos, el expediente de contactos y RH. La jerarquía es estricta de cuatro niveles:País → Estado → Municipio → Localidad.
Cobertura desde el día uno: el seed inicial incluye México y Estados Unidos (T02). Los catálogos son globales del sistema (sin tenancy); todos los tenants los leen.
Flujo HU-06 — Selección en cascada
- El usuario elige el País; el sistema devuelve sus Estados.
- Al elegir Estado, el sistema devuelve sus Municipios.
- Al elegir Municipio, el sistema devuelve sus Localidades.
CountryExternalId / StateExternalId / MunicipalityExternalId en Employee; v6 §A.3).
RH referencia la geografía por identificadores externos al módulo Geo; no se duplican tablas geográficas en Hr (v6 §2.1).
Reglas de negocio
- RN-01. Seed inicial con México y Estados Unidos (T02).
- RN-02. Catálogo global del sistema, sin tenancy (lectura para todos los tenants).
- RN-03. Los catálogos son de solo lectura para el usuario final; no se editan desde el UI.
Módulo 05 — Files (archivos adjuntos)
El módulo Files gestiona todos los archivos adjuntos del sistema mediante URLs prefirmadas a S3: el binario nunca pasa por la API; el back valida, emite la URL y guarda la metadata. Casos de uso: portadas de proyecto, vouchers de cobro, expedientes de contactos y empleados, imágenes de firma.Los PDFs legales generados por el back (contratos, etc.) los persiste LegalDocs en su propio almacenamiento aislado (Decisión 10). Esos PDFs no pasan por este flujo de subida.
Flujo de subida (HU-14)
Solicitar URL prefirmada de subida
El front envía al backend: nombre del archivo, tipo MIME, tamaño en bytes y la entidad dueña (por ejemplo,
contact:uuid).Validación y emisión de URL
El backend valida el permiso del usuario sobre la entidad dueña y verifica las reglas de tipo (RN-01) y tamaño (RN-02). Si pasa, emite una URL prefirmada de
PUT con Content-Type específico y expiración corta.Subida directa a S3
El front realiza el
PUT directamente a S3 (o MinIO en desarrollo) con el binario del archivo.Flujo de descarga
- El front solicita la descarga de un archivo por su id.
- El backend valida el permiso y emite una URL prefirmada
GETtemporal. - El front descarga el binario directamente desde S3.
Reglas de negocio
| Regla | Detalle | Referencia |
|---|---|---|
| RN-01 | Tipos permitidos: jpg, png, webp, pdf, docx, xlsx | T06 |
| RN-02 | Tamaño máximo 10 MB por archivo | T06 |
| RN-03 | Sin límite de cantidad de adjuntos por registro | T06 |
| RN-04 | Retención indefinida; no se purgan binarios | T06 |
| RN-05 | El binario va directo navegador → S3; la API solo emite URLs y guarda metadata. En dev el destino es MinIO con el mismo SDK | Decisión 7, 8; ADR-013 |
Módulo 06 — BillingSaas (suscripción y cuotas)
El módulo BillingSaas administra el ciclo de vida comercial de cada empresa en el SaaS: planes, precios, período de prueba, suscripción en Stripe (checkout, portal, webhooks), estados de acceso (paywall) y el sistema de cuotas por recurso que limita lo que cada plan permite crear.Estados de la suscripción
| Estado | Significado | Acceso |
|---|---|---|
Incomplete | Checkout iniciado sin completar (sesión de Checkout dura 30 min; ventana incomplete de Stripe dura 23 h) | Bloqueado (paywall) |
IncompleteExpired | La ventana de 23 horas venció | Bloqueado; siempre se crea checkout nuevo desde pricing |
Trialing / Active | Al día (incluida prueba si el plan la define) | Completo |
PastDue / Unpaid | Falló el cobro recurrente; Stripe reintenta (Smart Retries) | Bloqueado (paywall) con CTA “Actualizar método de pago” |
Canceled | Cancelación confirmada (webhook customer.subscription.deleted) | Bloqueado (paywall) |
Sistema de cuotas por recurso (C01 segunda ronda)
Los recursos actualmente limitables son:CLIENTES, VENTAS, COTIZACIONES, RESERVAS, PROYECTOS, CONCEPTOS, GASTOS DE PROYECTO, LOTES, MANZANAS, TEMPLATES LEGALES, TEMPLATE LEGALES VERSIONES, COBROS, USUARIOS.
Cada recurso tiene un tipo de medición:
- SNAPSHOT: valor fijo, sin reinicio (por ejemplo, espacio en GB).
- PERIODIC: se reinicia al llegar la fecha del período. El único recurso PERIODIC en el v1 es
COBROS.
ExecuteWithQuotaAsync):
Flujos principales
Registro y primer pago (C04):- Identity crea usuario + empresa + rol CEO en todos los casos.
- El CEO continúa a Stripe Checkout. Si la sesión (30 min) expira, se crea una nueva.
- Webhook de pago exitoso: suscripción activa. La prueba aplica solo en la primera suscripción y solo si el plan la define (C03).
Reglas de negocio destacadas
- RN-01. Planes, precios, prueba, módulos y límites se configuran desde el sistema sin redeploy (C01).
- RN-05. Sin días de gracia propios ni dunning propio: Stripe gobierna reintentos y recordatorios (C02).
- RN-07. La cuenta nunca se borra por falta de pago en esta versión (C04).
- RN-09. Recursos SNAPSHOT no se reinician; PERIODIC se reinician por fecha de período. El job de reinicio queda pendiente de implementar.
- RN-10. Consumo atómico con liberación compensatoria (
TryReleaseResource) si la acción falla (C01 segunda ronda).