Appearance
Consolidación de Informes Multi-Schema
Tipo: Arquitectural Alcance: Todos los módulos con informes/reportes Estado: En Uso (Implementación de referencia en Contabilidad) Fecha: 2025-12-31
Descripción General
Este documento describe el patrón arquitectural de consolidación de informes que permite generar reportes unificados combinando datos de múltiples sucursales/schemas en el Sistema Bautista. Es una solución transversal aplicable a cualquier módulo que genere informes (Contabilidad, Ventas, Compras, Stock, CRM, etc.).
Arquitectura Multi-Schema
Contexto Técnico
El Sistema Bautista utiliza una arquitectura multi-schema de PostgreSQL con tres niveles de segregación de datos:
Niveles de Schema:
- LEVEL_EMPRESA (1): Schema
public- Datos compartidos por toda la empresa - LEVEL_SUCURSAL (2): Schemas
sucXXXX(suc0001, suc0002, etc.) - Datos por sucursal - LEVEL_CAJA (3): Schemas
sucXXXXcajaXXXX(suc0001caja0001, etc.) - Datos por caja
Datos Compartidos (LEVEL_EMPRESA)
Las siguientes entidades residen en public y son compartidas por todas las sucursales:
Datos Maestros:
- Plan de cuentas contables (
cuentas) - Ejercicios contables (
ejerci) - Tipos de comprobantes (
comprob) - Alícuotas de IVA (
aliva) - Conceptos de retenciones (
congan,boniret, etc.) - Bancos (
bancos) - Provincias y localidades (
provincia,localidades) - Usuarios y permisos (
usuarios,grupos,permisos)
Ventaja para consolidación: Todas las sucursales usan los mismos datos maestros, no hay necesidad de mapeo entre sucursales.
Datos Transaccionales (Configurables)
Las tablas transaccionales pueden residir en diferentes niveles según la configuración de cada empresa mediante el campo configuracion_niveles_tablas en la tabla sistema.
Ejemplos:
- Movimientos contables (
movimi): LEVEL_EMPRESA, LEVEL_SUCURSAL y/o LEVEL_CAJA - Asientos contables (
nroasien): LEVEL_EMPRESA y/o LEVEL_SUCURSAL - Comprobantes de venta: LEVEL_SUCURSAL y/o LEVEL_CAJA
- Movimientos de stock: LEVEL_SUCURSAL
Patrón de Consolidación
Problema
Cuando un usuario necesita un informe consolidado (ej: Balance General de todas las sucursales), el sistema debe:
- Consultar datos de múltiples schemas
- Agregar/consolidar los resultados
- Mantener la trazabilidad del origen de cada dato
- Respetar permisos por sucursal del usuario
Solución: Consolidación Multi-Schema
Principios:
- Búsqueda multi-schema: Consultar datos en todos los schemas relevantes
- Agregación: Sumar/consolidar datos de las mismas entidades (ej: misma cuenta contable)
- Trazabilidad: Identificar el schema de origen de cada dato
- Respeto de permisos: Solo incluir sucursales donde el usuario tenga permisos
Componentes del Patrón
1. Activación por Usuario
El usuario activa la consolidación mediante un indicador visual (checkbox, toggle):
- Por defecto: Reportes muestran solo datos del schema actual
- Con consolidación activa: Reportes incluyen datos de todas las sucursales elegibles
2. Determinación de Schemas Objetivo
El sistema determina qué schemas consultar basándose en:
- Configuración de niveles: Consulta
configuracion_niveles_tablaspara saber en qué niveles están las tablas - Sucursal del usuario: Solo schemas de la sucursal actual (nunca schemas de otras sucursales)
- Permisos del usuario: Solo schemas donde el usuario tiene permisos del módulo
Ejemplo:
Usuario en: suc0001caja0001
Tabla movimi con niveles: [LEVEL_SUCURSAL, LEVEL_CAJA]
Schemas a consultar: suc0001, suc0001caja0001, suc0001caja0002, etc.
Schemas excluidos: suc0002, suc0003, public3. Búsqueda Multi-Schema
Para cada schema objetivo:
- Establecer
search_pathal schema - Ejecutar query del informe
- Agregar identificador de schema al resultado
- Consolidar resultados de todos los schemas
4. Agregación de Datos
Reglas de agregación:
- Datos maestros compartidos: Se consultan una sola vez desde
public - Datos transaccionales: Se suman/agregan por entidad común
- Ejemplo: Saldos de cuenta 1100 = suma(saldo_suc0001 + saldo_suc0002 + ...)
- Trazabilidad: Cada registro conserva identificación de schema de origen
5. Presentación
El informe consolidado debe:
- Indicar claramente que es un reporte consolidado
- Listar sucursales incluidas y excluidas
- Mostrar origen de cada dato (opcionalmente)
- Calcular totales consolidados correctamente
- Permitir desglose por sucursal
Reglas Arquitecturales
RA-001: Datos maestros compartidos
Descripción: Los datos maestros residen en LEVEL_EMPRESA y son únicos para toda la organización.
Implicación: No hay mapeo ni compatibilidad a validar - todas las sucursales usan los mismos.
Ejemplos:
- Plan de cuentas contables
- Ejercicios contables (períodos)
- Conceptos de retenciones
- Tipos de comprobantes
RA-002: Configuración dinámica de niveles
Descripción: El sistema consulta configuracion_niveles_tablas para determinar en qué schemas buscar datos.
Comportamiento:
- Si tabla tiene múltiples niveles configurados → búsqueda multi-schema
- Si tabla tiene un solo nivel → búsqueda simple en schema actual
- Si no hay configuración personalizada → usar niveles por defecto de la tabla
RA-003: Alcance limitado por sucursal
Descripción: La consolidación incluye únicamente schemas de la sucursal actual del usuario.
Fundamento: Mantener segregación de datos y respetar permisos por sucursal.
Ejemplo:
Usuario en sucursal 0001:
✅ Puede consolidar: suc0001, suc0001caja0001, suc0001caja0002
❌ No puede consolidar: suc0002, suc0003RA-004: Validación de permisos
Descripción: El usuario solo ve datos consolidados de sucursales donde tiene permisos del módulo.
Validación: Antes de ejecutar queries, verificar permisos del usuario en cada schema.
RA-005: Trazabilidad obligatoria
Descripción: Todo dato en un informe consolidado debe poder rastrearse a su schema de origen.
Implementación:
- Agregar columna
schema_origenosucursala resultados - Mantener identificación durante toda la agregación
- Incluir en exportaciones (Excel, PDF)
RA-006: Rendimiento aceptable
Descripción: La consolidación debe tener rendimiento aceptable considerando que consulta múltiples schemas.
Pautas:
- Para 2-5 sucursales: tiempo similar a reportes normales (segundos)
- Para 10+ sucursales: puede requerir hasta 30-60 segundos
- Mostrar indicador de progreso para operaciones > 3 segundos
- Considerar caché para datos maestros compartidos
Implementación por Módulo
Este documento define el patrón general. Cada módulo debe crear su propia documentación específica que:
- Referencie este documento para el patrón arquitectural
- Liste los informes específicos que soportarán consolidación
- Defina reglas particulares del dominio de negocio
- Especifique agregaciones propias del módulo
Módulos con Consolidación
- ✅ Contabilidad (Implementación de referencia):
- Balance de Comprobación ✅ Implementado (2025-12-31)
- Libro Diario General ⏭️ Pendiente
- Libro Mayor ⏭️ Pendiente
- Balance General ⏭️ Pendiente
- Estado de Resultados ⏭️ Pendiente
- Ver:
docs/features/contabilidad/consolidacion-informes-contables.md
- ⏭️ Ventas: Informes de facturación, estadísticas de ventas
- ⏭️ Compras: Informes de compras, proveedores
- ⏭️ Stock: Informes de inventario, movimientos
- ⏭️ CRM: Informes de clientes, oportunidades
- ⏭️ Tesorería: Informes de caja, bancos
Consideraciones Técnicas
Seguridad
Control de acceso:
- Validar permisos del usuario en cada schema antes de consultar
- No permitir acceso a schemas de otras sucursales
- Auditar accesos a datos consolidados
Integridad transaccional:
- Consolidación es solo lectura - no modifica datos originales
- Datos permanecen en sus schemas correspondientes
Auditoría
Información a registrar:
| Evento | Datos a Capturar |
|---|---|
| Generación de informe consolidado | Usuario, timestamp, módulo, tipo de informe |
| Schemas consultados | Lista de schemas incluidos |
| Resultados | Cantidad de registros por schema |
Performance
Optimizaciones:
- Caché de configuración: Mantener
configuracion_niveles_tablasen memoria - Consultas paralelas: Consultar múltiples schemas en paralelo cuando sea posible
- Límites razonables: Considerar límite de sucursales por consolidación
- Paginación: Para grandes volúmenes, implementar paginación o generación asíncrona
Expectativas:
- Prioridad: correctitud > velocidad
- Aceptable: 5-10 segundos para consolidar 5 sucursales
- Considerar: Generación en background para > 10 sucursales
Extensiones Futuras
Selección de Sucursales (Fase 2)
Permitir al usuario seleccionar manualmente qué sucursales incluir en lugar de todas:
- Selector visual con checkboxes
- Persistencia de selección durante la sesión
- Filtrado de resultados por sucursal
Nota: Esta funcionalidad es opcional y puede implementarse después de la consolidación automática básica.
Otras Extensiones
- Consolidación programada: Generación automática de reportes consolidados
- Alertas consolidadas: Notificaciones basadas en datos de múltiples sucursales
- Dashboards consolidados: Visualizaciones en tiempo real
- Exportación mejorada: Formatos específicos para consolidación (Excel con múltiples hojas por sucursal)
Referencias
Documentación Relacionada
- Multi-Schema Transactional Operations:
docs/architecture/multi-schema-transactional-operations-process.md - Configuración de Niveles: Campo
configuracion_niveles_tablasen tablasistema
Implementaciones por Módulo
- Contabilidad:
docs/features/contabilidad/consolidacion-informes-contables.md
Historial de Cambios
| Fecha | Version | Autor | Descripcion |
|---|---|---|---|
| 2025-12-30 | 1.0 | Sistema | Creación del documento de patrón arquitectural de consolidación multi-schema. Extracción de conceptos generales desde documentación de módulo de contabilidad. |
| 2025-12-31 | 1.1 | Sistema | Agregada sección de Implementación describiendo utilidades reutilizables para consolidación multi-schema. |
| 2025-12-31 | 1.2 | Sistema | Primera implementación de referencia del patrón: Balance de Comprobación en módulo de Contabilidad. Consolidación de todas las sucursales disponibles sin restricción por ubicación del usuario. Estado actualizado a "En Uso". |