Versiones y cuándo usar cada una
Esta tabla es de la primera exploración (~junio-julio 2026, repo
layout-gastos-streamlit-claude). Existe una segunda exploración independiente (2026-08-04) con su propia numeración de versión (v0.2,v0.3,v1.0,v2.1,v2.2) que colisiona en el nombre pero no es la misma serie — ver Segunda exploración (2026-08-04).
Todas las versiones coexisten en el mismo hub Streamlit (selector de versión en la barra lateral) para poder comparar resultados una contra otra — no son iteraciones que reemplazan a la anterior sin dejar rastro.
| Versión | Motor | Atribución | Comprobación (2025 completo) | Notas |
|---|---|---|---|---|
| v0.1 | Python | Réplica exacta del reporte nativo de MPRO, sin Cargo/Abono | — | Útil cuando se necesita el formato nativo tal cual, filtrable por fechas. |
| v0.2 | Python | Cargo/Abono a nivel folio completo (pegado al último documento) | ~74–99% según origen | Primera versión con póliza; expone el problema de granularidad. |
| v0.3 | Python | Por documento vía centro de costo, emparejamiento posicional simple | Mejor que v0.2, aún con fallos en folios grandes | Encuentra Gasto_Registro_Control pero empareja por orden de creación, no por valor. |
| v0.4.1 | Python | Por documento, emparejamiento por valor + reparto proporcional + salvaguarda de re-enrutado | ~99.6% | Corrige el bug de orden de creación de v0.3. |
| v0.4.2 | Python | v0.4.1 + reversiones contables + fallback de cuenta “Gastos a cuenta de costo estandar” | 99.96% (0 casos sin explicar) | Recomendada para análisis y validación — el pipeline más completo. |
| v0.5 | SQL puro | Cargo/Abono a nivel folio completo (como v0.2, pero con los casos especiales de v0.4.2 hardcodeados) | 99.90% (mismo total que v0.4.2, sin desglose por documento) | Una sola consulta, sin Gasto_Registro_Control — para hand-off a un programador que no necesita mantener el pipeline de Python. |
| v0.5.1 | SQL puro | Por documento vía Gasto_Registro_Control (mismo método que v0.4.2), sin la salvaguarda de re-enrutado | 99.90%, mismos totales que v0.4.2 | Recomendada para SQL/FlexMonster — mismo detalle que v0.4.2 en una sola consulta. Requiere tablas #temporales para materializar los CTEs reusados (ver nota de rendimiento abajo). |
Por qué v0.4.2 y v0.5.1 dan el mismo resultado
v0.4.2 hace 3 consultas SQL simples (documentos, póliza, Gasto_Registro_Control) y
resuelve el emparejamiento por valor / reparto proporcional / reversiones en memoria
con pandas. v0.5.1 hace el mismo trabajo dentro de SQL Server con CTEs y
ROW_NUMBER() OVER. El resultado final es idéntico porque es el mismo algoritmo — la
diferencia es dónde corre.
Nota de rendimiento (SQL puro): CTEs no se materializan
La primera versión de v0.5.1 usaba CTEs para todo, incluyendo dos (poliza_linea y
grc) referenciadas 5 y 3 veces más abajo en la consulta. SQL Server no materializa
las CTEs — son macros que se re-expanden en cada referencia — así que el join pesado
de póliza se recalculaba 5 veces por consulta: 14 minutos para un año completo, contra
22 segundos de v0.5 (que no tiene ese patrón de reuso). Fix: materializar esas CTEs en
tablas #temporales (con índice) antes del SELECT final, para que se calculen una
sola vez — bajó el tiempo a ~24 segundos, prácticamente igual a v0.5 pero con la
granularidad completa por documento. Es el mismo patrón a tener en cuenta en cualquier
consulta T-SQL que reuse una CTE varias veces sobre un volumen de datos no trivial.
Véase también
- Layout de Gastos — panorama general del reporte.
- Atribución de Cargo/Abono por documento — el método de emparejamiento por valor que comparten v0.4.x y v0.5.1.