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.

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.

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

EntidadContenidoReferencia
Empresa (Tenant)Nombre, datos de contacto, estadoConsolidado desde Identity
Tipo de pago / Método de pagoCatálogos por empresa para la cobranzaImagen C48 (Ajustes)
MonedaCatálogo de monedas que la empresa operaC32, C43, Imagen C48
Tipo de cambioValor vigente por par de monedas, actualizado manualmente desde BanxicoC45
Tipo de reciboCatálogo por empresa; lleva el correlativo del folio de reciboImagen C48; Cobros-Flujos §5
SedeCatálogo por empresa; el proyecto referencia una sedeC09; Imagen C48
Día festivoCalendario por empresa (con ámbito Global / Empresa / Proyecto en el modelo único)C44; Decisión 17; ADR-021
Modalidad de pagoCatálogo global de periodicidades (lista cerrada)C25

Catálogo de modalidades de pago (lista cerrada — C25)

IdNombreFrequencyDaysFrecuencyYears
1SEMANAL7752
2QUINCENAL151526
3MENSUAL13012
4BIMESTRAL2606
5TRIMESTRAL3904
6CUATRIMESTRAL41203
7SEMESTRAL61802
8ANUAL13601
9DIARIO11365
Interpretación de fechas: para modalidades mensuales o mayores las fechas avanzan con 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).
Administrar festivos:
  1. La empresa captura su calendario (fecha, nombre, tipo, multiplicadores de nómina).
  2. 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)

En ArccNova v2, Branch = proyecto inmobiliario, no sucursal física (ADR-007). Un Tenant puede tener múltiples Branches (proyectos de lotificación).
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)

CampoNota
Nombre del proyecto
SedeCatá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 LocalidadCatálogos Geo
MonedaCatálogo de la empresa
TEATasa de interés anual del proyecto; default de los planes de financiamiento

Proyecto — campos opcionales

CampoNota
Número catastralVariable de contrato {{projectCadastralCode}}
Costo aproximado por lote
Número de contrato correlativoFolio de contratos del proyecto (RT-33)
Número de recibo correlativoFolio de recibos del proyecto (RT-33)
Imagen (portada)Vía Files
Descripción del proyecto
CURP del propietario
Oficina registral del predioVariable {{projectLandRegistryOffice}}
Denominación del predio
Colindancias (Norte, Sur, Este, Oeste)Variables {{projectBoundary*}}
Descuento (porcentaje)
Tasa de incumplimientoDefault del porcentaje de mora de las ventas (C23 segunda ronda)
Días de graciaPerí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.
Un usuario puede ser Admin en el proyecto A y tener solo lectura en el proyecto B. Los permisos efectivos del JWT corresponden siempre al proyecto activo en sesión.

Flujos

1

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).
2

HU-02 — Editar proyecto

Se puede editar cualquier campo del alta con las mismas validaciones (C11).
3

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).
4

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).
5

HU-05 — Cambiar de proyecto activo

El usuario abre el catálogo de proyectos (tarjetas con portada, ubicación, moneda, estado y botón de entrar) y selecciona el proyecto deseado. La sesión cambia su proyecto activo; los permisos efectivos pasan a ser los del rol en ese nuevo proyecto (C12).

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

  1. El usuario elige el País; el sistema devuelve sus Estados.
  2. Al elegir Estado, el sistema devuelve sus Municipios.
  3. Al elegir Municipio, el sistema devuelve sus Localidades.
Consumidores: alta de proyecto (C09), alta de contacto (campos geográficos del cliente), empleado de RH (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)

1

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).
2

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.
3

Subida directa a S3

El front realiza el PUT directamente a S3 (o MinIO en desarrollo) con el binario del archivo.
4

Confirmación de metadata

El front notifica al backend que la subida completó. El backend persiste la metadata del archivo. Un registro sin confirmación no se considera un adjunto válido.

Flujo de descarga

  1. El front solicita la descarga de un archivo por su id.
  2. El backend valida el permiso y emite una URL prefirmada GET temporal.
  3. El front descarga el binario directamente desde S3.

Reglas de negocio

ReglaDetalleReferencia
RN-01Tipos permitidos: jpg, png, webp, pdf, docx, xlsxT06
RN-02Tamaño máximo 10 MB por archivoT06
RN-03Sin límite de cantidad de adjuntos por registroT06
RN-04Retención indefinida; no se purgan binariosT06
RN-05El binario va directo navegador → S3; la API solo emite URLs y guarda metadata. En dev el destino es MinIO con el mismo SDKDecisió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

EstadoSignificadoAcceso
IncompleteCheckout iniciado sin completar (sesión de Checkout dura 30 min; ventana incomplete de Stripe dura 23 h)Bloqueado (paywall)
IncompleteExpiredLa ventana de 23 horas vencióBloqueado; siempre se crea checkout nuevo desde pricing
Trialing / ActiveAl día (incluida prueba si el plan la define)Completo
PastDue / UnpaidFalló el cobro recurrente; Stripe reintenta (Smart Retries)Bloqueado (paywall) con CTA “Actualizar método de pago”
CanceledCancelació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.
Patrón de consumo atómico (ExecuteWithQuotaAsync):
// Pseudocódigo del patrón de cuota atómica
var result = await quotaService.ExecuteWithQuotaAsync(
    tenantId,
    ResourceType.Lotes,
    quantity: 1,
    action: async () =>
    {
        // Lógica de creación del lote
        return await lotRepository.CreateAsync(lot);
    }
);
// Si la acción falla después de consumir, TryReleaseResource libera el recurso

Flujos principales

Registro y primer pago (C04):
  1. Identity crea usuario + empresa + rol CEO en todos los casos.
  2. El CEO continúa a Stripe Checkout. Si la sesión (30 min) expira, se crea una nueva.
  3. Webhook de pago exitoso: suscripción activa. La prueba aplica solo en la primera suscripción y solo si el plan la define (C03).
Cambio de plan (C02): solo el CEO puede ejecutarlo. Un mismo endpoint maneja upgrade y downgrade. Stripe aplica prorrateo automático: upgrade = cargo proporcional inmediato; downgrade = crédito a la siguiente factura, sin reembolso inmediato. Cancelación voluntaria: se delega al Stripe Customer Billing Portal. Antes de redirigir, el flujo muestra una pantalla de retención con planes alternativos. El acceso se mantiene hasta el fin del período facturado.

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).

Build docs developers (and LLMs) love