v1.0 — Layout de Gastos por cuenta contable y centro de costo (DEFINITIVA)
Primera versión que sale de “estamos probando reglas” a “esto se sirve en FlexMonster tal cual”. Pedido de Contabilidad: detalle real por cuenta contable y centro de costo, no un número agregado por folio.
Archivo de producción
docs/queries/gastos/v03_detalle_cuenta_centro_costo.sql — la única
query que consume FlexMonster. Recibe :fecha_ini/:fecha_fin, entrega
una fila por (folio, cuenta contable, centro de costo) con CARGO/ABONO.
Sin CASE, sin UNION, sin CTE — un solo SELECT, mismo camino para
todos los orígenes. No decide qué cuenta “cuenta” como gasto real (a
diferencia de v0.2): se entrega el detalle crudo, Contabilidad lo lee con
sus propios ojos.
v01_gastos_por_folio.sql — solo referencia, NO se usa en producción
Sirve únicamente para la comprobación interna (saber el IMPORTE esperado
por folio y poder validar el rollup de v1.0). No se conecta a FlexMonster,
no se le entrega a nadie más. Vive en docs/queries/gastos/ por si hace
falta re-validar en el futuro, no como parte del reporte.
Validación (comprobación interna, vive en Python — NO en la query de producción)
v03_detalle_cuenta.py / v03_semestre.py: suman el detalle de v1.0 por
folio y lo comparan contra IMPORTE de v0.1, con 3 reglas según el caso
(normal, reversión, GASTO_RECLASIFICACION) — ver docs/v02_cierre.md
para el detalle de cada regla, sigue aplicando igual aquí.
Resultado: 99.96% (9,158/9,162) contra .207 (producción),
enero-junio 2026. Mismas 4 excepciones conocidas que v0.2 — no son bugs
de v1.0, son datos reales (ruido de redondeo en folios con cientos de
líneas, doble-póliza en lotes de costeo estándar). Ver docs/v02_cierre.md.
Diferencia clave vs v0.2
v0.2 resolvía “¿cuánto es el Cargo/Abono real del folio en un solo número?”
— necesitaba 3 queries porque esa pregunta tiene reglas distintas según el
origen. v1.0 no hace esa pregunta — muestra el detalle tal cual vive en
Poliza_Detalle, así que una sola query sirve para todos los casos.
Detalle importante encontrado al bajar a este nivel: agrupar sin centro
de costo mezcla movimientos reales. Reclasificaciones que mueven un gasto
de un centro de costo a otro (misma cuenta contable en Cargo y Abono)
parecían “cancelarse solas” si no se separaba por centro — confirmado con
drill-down, folio 01-0037346 (“RECLA PLANEACION Y PRESUPUESTO A
TESORERIA”), 2026-08-04.
Pendiente (no bloqueante, evaluado y pausado)
Se probó una variante con LEFT JOIN desde Poliza_Control en adelante
(para que GASTO_REGISTRO_NOMINA/CONSUMO_INTERNO y folios sin póliza
posteada todavía aparezcan con Cargo/Abono vacío en vez de desaparecer del
reporte). Encontró una discrepancia sin resolver entre .200 y .207 para
folios de GASTO_RECLASIFICACION (posible desfase de sincronización, sin
confirmar) y una duda abierta sobre si NOMINA/CONSUMO_INTERNO sí tienen
Poliza_Control pero nunca se les hizo join en ninguna versión anterior.
Pausado por decisión del usuario — retomar si escalabilidad del reporte lo
vuelve a requerir.
Véase también
docs/v02_cierre.md— reglas de negocio y bugs de join resueltos (aplican igual aquí, no se repiten).docs/queries/gastos/— las queries guardadas.