Mapa completo del sistema
de Reportes Zonas Áridas
Análisis integral de los 5 módulos productivos
(Venta · Caja · Cashflow · Artículos · Listas) sobre una base
u120688891_chess con 33 tablas y más de
515.000 líneas de ventas en producción. Incluye mapeo de
archivos, relaciones BD ↔ código, diagramas de flujo, análisis de errores,
propuestas de mejora y plan de escalabilidad a un segundo nivel.
§1 🎯 Resumen ejecutivo
El sistema de reportes de Zonas Áridas es una BI casera modular
construida sobre PHP 8 + MariaDB en hosting compartido (Hostinger), con frontend
vanilla JS + Tabulator 6.3 + Chart.js 4.4. Está
funcionando en producción, alineado al milímetro con ChessERP, y resuelve
análisis de venta, gastos, tesorería, cashflow e impuestos.
ventas · caja_* · cashflow_* · articulos_* · catalogo_*Fortalezas
- Arquitectura modular bien definida: cada módulo tiene su
config/database.php,api/_schema.phpidempotente ysyncindependiente. - Fórmula ChessERP unificada como constantes PHP reutilizables
en
data_api.phpyfilter.php. - Bootstrap cross-module:
venta/db_reportes.phpdisparaarticulos_ensure_schema()para que los JOINs no fallen. - Schema v2 de caja con todas las tablas raw históricas +
caja_audit_log+caja_cajerosdenormalizado. - Tabulator + Chart.js eliminó ~500 KB de bundle React manteniendo todas las features (árbol, virtual scroll, bottomCalc).
- Documentación markdown extensa y versionado semver real en
cada módulo (
version.phpcon changelog inline).
Riesgos principales
- CRÍTICO
Credenciales hardcoded en
config/database.php(multiplicado en 5 archivos) — incluye API ChessERP. - CRÍTICO
Sin autenticación: los endpoints
reset_db.php,sync.php,save.phpson públicos. El session_start está comentado. - CRÍTICO
Dump SQL completo (765 MB) servido como archivo estático en
/reportes/u120688891_chess.sql— descargable por cualquiera. - ALTO
Algunas queries interpolan variables:
WHERE sync_id=$sidencaja/api/save.php:63y otros (mitigado por cast a int, pero es mala práctica). - ALTO
5 copias de las constantes de BD (
venta · caja · cashflow · articulos · listas) — divergen ya (ej.UPLOAD_MAX_MBsolo en venta). - ALTO
caja/dashboard.jsx(~22 KB) sigue versionado en producción aunque ya no se usa (legado React).
§2 📐 Alcance del análisis
Esta auditoría cubre todo lo que vive bajo /public_html/reportes/:
Incluido
- Mapa de archivos con tamaños y propósito.
- Schema completo de BD (33 tablas) con FKs e índices.
- Relaciones archivo ↔ tabla ↔ endpoint.
- Fórmulas y cálculos clave (margen, peso, runway, aging).
- Diagramas de flujo de los syncs.
- Hallazgos de seguridad, performance, mantenibilidad.
- Propuestas concretas de escalabilidad y mejoras visuales.
Fuera de alcance
- Análisis de tráfico real / logs de Hostinger.
- Pen-testing activo (sólo revisión estática).
- Auditoría de los Excel de origen (formatos exactos).
- Comparativa de TCO con SaaS BI (Metabase, Superset, Looker).
- Reescritura del backend a frameworks (Laravel, Symfony).
- Otros módulos del sitio (
/intranet,/catalogo,/freddo).
§3 📈 Métricas del proyecto
Volumen de código por módulo
| Módulo | Archivos | Líneas aprox. | Peso total | Versión |
|---|---|---|---|---|
| 📊 venta/ | 13 | ~10.500 | 375 KB | v2.4.0 |
| 🏦 caja/ (+ submódulos) | 27 | ~12.000 | 505 KB | v2.0.2 |
| 💸 cashflow/ | 8 | ~3.200 | 132 KB | v1.1.0 |
| 📦 articulos/ | 6 | ~1.600 | 68 KB | s/v |
| 🏷️ listas/ | 6 | ~900 | 36 KB | s/v |
| landing + docs | 3 | ~1.100 | 55 KB | — |
| TOTAL | 63 | ~29.300 | 1,17 MB |
Volumen de datos en BD (Mayo 2026)
| Tabla | AUTO_INCREMENT | Tipo | Comentario |
|---|---|---|---|
ventas | 515.811 | histórica | 22 períodos · ~23K filas/mes |
caja_raw_egresos_detalle | 261.627 | histórica | ~12K filas/mes promedio |
caja_raw_gastos_tipificados | 28.398 | histórica | ~600 filas/mes |
caja_raw_movimiento_detalle | 21.765 | histórica | ~800 filas/mes |
caja_raw_movimiento_resumido | 8.508 | histórica | ~400 filas/mes |
caja_raw_egresos_caja | 11.070 | histórica | ~500 filas/mes |
caja_gastos (derivada) | 5.804 | derivada | línea de gasto clasificada |
caja_cajeros | 15.339 | denormalización | mapa empresa·caja·cajero |
caja_audit_log | 1.217 | auditoría | logs de cada sync |
cashflow_cheques_cartera | 2.448 | snapshot | ~3 cortes |
cashflow_cartera_clientes | 801 | snapshot | |
cashflow_extractos_bancarios | 1.744 | snapshot | |
cashflow_cartera_proveedores | 118 | snapshot | |
articulos_raw | ~7.870 | catálogo | PK codigo |
articulos_precios | ~7.870 | catálogo | 22 columnas lista_N |
clientes_raw | ~3.000 | catálogo | JSON datos_raw validado |
sincronizaciones | 33 | control | 22 completadas |
📊 Dump SQL en producción
El archivo u120688891_chess.sql pesa 765 MB (volcado completo
con datos). Sirve como respaldo manual pero no debe quedar accesible
en el doc root (riesgo de exfiltración total). Ver §10 hallazgo SEC-03.
§4 🧩 Mapa de módulos
Cada tarjeta linkea a la sección detallada con flujos, fórmulas, BD y mejoras.
Módulo Venta
Análisis de ventas desde API ChessERP. KPIs, márgenes, ABC, rentabilidad por vendedor / cliente / artículo / proveedor.
Módulo Caja
Hub con 3 submódulos: Gastos (pipeline 3-tier), Tesorería (5 pestañas), Finanzas (IVA, percepciones, rentabilidad cruzada).
caja_*
v2.0.2
Módulo Cashflow
Flujo proyectado. Cartera clientes/proveedores, cheques en cartera, calendario semanal, cruce comercial.
cashflow_*
v1.1.0
Módulo Artículos
Catálogo maestro de SKUs (66 columnas). Cross-module bootstrap. JOIN con venta para enriquecer peso.
articulos_*
~7.870 SKUs
Módulo Listas
Listas de precios por canal/sucursal (22 columnas lista_N). Consultor sin sync activo (delega a /catalogo).
Diagramas de flujo
Sync lote × lote (venta) · Pipeline 3-tier (caja gastos) · Cruce comercial cashflow · Bootstrap cross-module.
Dependencias cross-module
┌──────────────────────────┐
│ u120688891_chess (BD) │
└────────────┬─────────────┘
│
┌───────────┬──────────┬──────┴──────┬──────────┬────────────┐
▼ ▼ ▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐ ┌──────────┐
│ VENTA │ │ CAJA │ │CASHFLOW│ │ARTICULOS │ │ LISTAS │ │ Hub / │
│ │ │ (hub) │ │ │ │ catálogo │ │ precios │ │ landing │
└───┬────┘ └───┬────┘ └───┬────┘ └────┬─────┘ └────┬────┘ └─────┬────┘
│ │ │ │ │ │
│ │ │ │ │ │
▼ JOIN articulos_raw ───┘ │ │ │
│ │ │ │
▼ db_reportes.php → articulos_ensure_schema() ◄───┘ │
│ │
▼ filter.php / dashboard.php │
│
CAJA ──► cashflow lee caja_raw_egresos_caja (saldo de caja) ─────┤
CAJA ──► finanzas lee ventas (cruce rentabilidad) │
CASHFLOW ► lee ventas (cruce comercial 6 meses) │
│
landing (/reportes/index.php) ── usa stats de los 3 grandes ───────┘
§5 ⚠️ Hallazgos prioritarios
Top issues que valen la pena resolver primero. Detalle completo en §10 Análisis de errores.
| ID | Categoría | Hallazgo | Impacto | Esfuerzo | Prioridad |
|---|---|---|---|---|---|
SEC-01 |
Seguridad | Endpoints reset_db.php, sync.php, save*.php sin auth. El session_start() está comentado. |
Cualquiera con la URL puede borrar la base. | 2–4 h | Crítico |
SEC-02 |
Seguridad | Credenciales DB + API ChessERP hardcoded en 5 config/database.php. |
Si se publica el repo o se filtra un archivo, expone todo. | 3 h | Crítico |
SEC-03 |
Seguridad | u120688891_chess.sql (765 MB con datos) accesible desde la web. |
Exfiltración total de la BD vía HTTP GET. | 15 min | Crítico |
SEC-04 |
Seguridad | Algunas queries con interpolación de variables: WHERE sync_id=$sid. |
Bajo (var casteada a int) pero mala práctica. | 2 h | Alto |
ARQ-01 |
Arquitectura | Las constantes de BD se redefinen en 5 archivos. DB_HOST, DB_NAME, etc. |
Riesgo de divergencia / errores duplicados al rotar password. | 3 h | Alto |
ARQ-02 |
Arquitectura | caja/dashboard.jsx (22 KB) legado React quedó en producción. |
Confusión + riesgo de servir un archivo obsoleto. | 30 min | Alto |
ARQ-03 |
Arquitectura | Mapeo CAJERO_PROV hardcoded en JS, duplicado entre sync.php y sync_bulk.php. |
Cada cajero nuevo requiere editar 2 archivos. | 4 h | Medio |
PERF-01 |
Performance | Landing /reportes/index.php hace N+1 queries: 12 prepares secuenciales para totales por mes de caja. |
~12 round-trips innecesarios cada hit a la landing. | 1 h | Medio |
PERF-02 |
Performance | Falta índice compuesto (sync_id, anulado) en ventas. |
Cada query del dashboard escanea por sync_id y luego filtra anulado='NO'. |
30 min | Medio |
PERF-03 |
Performance | JOIN CAST(idArticulo AS UNSIGNED) en cada query del dashboard inhibe uso de índice en articulos_raw.codigo. |
Aceptable hoy (~7K SKUs) pero degradará con escala. | 2 h | Medio |
UX-01 |
UX | No hay empty state consistente en dashboards. Cuando un período está vacío se ve "0,00" en vez de mensaje. | Confusión del usuario. | 4 h | Medio |
DOC-01 |
Docs | Algunas funciones de data_api.php no tienen docstring (50+ funciones). |
Onboarding lento de nuevos devs. | 6 h | Bajo |
§6 🚀 Roadmap propuesto al segundo nivel
Plan en 4 fases ordenadas por impacto y dependencias. Detalle completo en §11 y §12.
Fase 0 — Hardening (1–2 semanas)
- Implementar auth (session + roles) en todos los endpoints administrativos.
- Mover credenciales a
.env+ undb_shared.phpúnico en/reportes/_shared/. - Mover el dump SQL fuera del doc root o bloquear con
.htaccess. - Reemplazar interpolaciones
$sidpor prepared statements (aunque casteado). - Eliminar
dashboard.jsxobsoleto. - Crear
robots.txty.htaccesscon bloqueo de*.sql,*.md,*.bak,config/.
Fase 1 — Refactor de plataforma compartida (3–4 semanas)
- Crear paquete
/reportes/_shared/: PDO singleton, logger, helpers de formato, validators. - Migrar los 5
config/database.phpa un único cargador. - Extraer
CAJERO_PROVa tabla DB editable desde UI (admin). - Estandarizar respuesta de APIs: envelope
{ok, data, meta, error}. - Crear contratos JSON Schema para cada endpoint (autodocumentación).
- Añadir
composer.jsonmínimo si crece la cantidad de helpers.
Fase 2 — Capa BI estable (4–6 semanas)
- Vistas materializadas (
caja_gastos_mensual,ventas_mensual_supervisor) con refresh nocturno. - Cron job para syncs automáticos:
cron daily 03:00 → /reportes/venta/sync_api_cron.php?mes=…. - Cache HTTP (
ETag + Last-Modified) en endpoints JSON pesados. - Exportación a Excel/CSV con descargas firmadas (token + expiración).
- Dashboard multi-período comparativo (overlay de 2 meses lado a lado).
- Drill-down universal: clic en cualquier KPI → tabla detallada filtrada.
Fase 3 — Inteligencia y proyecciones (6–8 semanas)
- Forecast de cashflow a 30/60/90d con regresión sobre estacionalidad por rubro.
- Alertas activas: enviar email/WhatsApp cuando "saldo proyectado < X" o "margen mes baja > Y%".
- Detección de anomalías en gastos (z-score sobre media histórica por rubro × provincia).
- Recomendador de límite de crédito por cliente (basado en histórico de cobranza + cheques rechazados).
- Reporte ejecutivo PDF mensual generado automáticamente.
- API pública (read-only) con tokens para integraciones futuras (Power BI, Looker, etc).
Esfuerzo total estimado: 14–20 semanas-persona. ROI esperado: reducción del 70% en horas mensuales dedicadas a consolidar reportes manualmente + detección temprana de problemas de cobranza/margen.