Skip to content

poliza-explor — estado vivo

2026-09-02

  • Primera sesión completa: censo de las pólizas de enero 2026 por Poliza_Control.Pc_Tabla (16 orígenes, 3,600 pólizas). Hallazgo base: Poliza.Pl_Tabla/Pl_Documento vienen vacíos siempre — el enlace real es vía Poliza_Control, documentado en docs/schema/calidad-de-datos.md.
  • Criterio de simplicidad ("0 sub-orígenes propios + baja consolidación") aplicado a los 15 orígenes, y corregido con datos: Compra_Indirecto parecía simple (Ci_Tabla vacío) pero comparte el patrón de doble póliza de CONSUMO_INTERNO.
  • Reconciliados los dos orígenes que sí resultaron simples:
  • Cheque: 100% en enero 2026 (1,128 pólizas) y Q1 2026 completo (3,372). Requirió resolver que Pd_Referencia no es confiable (72% de los casos) — se aísla el Abono por monto en su lugar.
  • Recibo_Pago: 100% enero 2026 (69/69), 99.66% Q1 2026 (293/294, 1 excepción sin explicar).
  • Compra_Indirecto: 100% (5/5) del lado Cargo de la póliza real, volumen bajo, no se amplió el rango ni se validó el Abono.
  • Documentado en trivasa-context: nuevo proyecto (este), 3 gotchas nuevos en docs/schema/calidad-de-datos.md, Poliza_Control agregado como ejemplo del patrón polimórfico en docs/schema/convenciones.md, y el ER de docs/schema/dominios.md corregido (Poliza como cabecera de Poliza_Control/Poliza_Detalle, que faltaba).

Próxima acción

Decidir si se investiga Deposito_Pago (sospecha de patrón de doble póliza sin sub-orígenes visibles en su propia columna Tabla, igual que pasó con Compra_Indirecto) o si se prioriza otro origen del censo para la siguiente reconciliación. Ver "Pendiente" en index.md.

2026-09-03

  • Segunda sesión: el lado de configuración. Documentada la pantalla CT001 y las 5 tablas Poliza_Configuracion* en configuracion-polizas.md, a partir de la conversación con Marcelino Canche (soporte TIC) + verificación en BD de todo lo que afirmó. El proyecto queda fusionado: index.md cubre el lado de salida, configuracion-polizas.md el de entrada.
  • Poliza.Pl_Configuracion existe y está al 98.97% — liga cada póliza con la regla que la generó. Reemplaza la inferencia por Poliza_Control.Pc_Tabla cuando la pregunta es por qué una póliza trae ciertas cuentas.
  • Doble póliza explicada: son dos configuraciones sobre la misma Pc_Tabla, una (CUENTAS DE ORDEN), ambas automáticas. Hay un caso triple (0454/0455/0456). Deja de ser anomalía.
  • Deposito_Pago: pendiente cerrado — no tiene doble póliza, sus 3 configs son versiones sucesivas por vigencia. Consolidación legítima.
  • Pólizas manuales de Contabilidad identificadas: los 3,494 registros sin Pl_Configuracion tampoco tienen Poliza_Control (0 de 3,494). Son ~500/año, por todos los años, con capturista nombrado. Responde la pregunta que quedó abierta con Marcelino sobre movimientos manuales.
  • Causa raíz del único descuadre vivo de 2026 (0000478288): CeCo 000501 PLANTA CONCRETERA fuera de las listas IN de la config 0394 → 80 cargos para 81 CeCos. Corrige la hipótesis de "todo es redondeo": el redondeo eran $0.41 de $5.36.
  • Nuevo scripts/05_huecos_ceco_configuracion.py. Reconstruye el query del botón "Generar script" desde las tablas de configuración. Corrido sobre 71 configs de Gasto_Registro en uso, H1 2026, 0 errores: solo 2 con huecos reales (0394 y 0371). Un primer intento por regex daba 69 "candidatos" — era ruido, descartado y documentado como tal.

Próxima acción

Tres frentes, en orden de valor:

  1. Pedirle a Marcelino fecha y empresa exactas de su corrida de 0428 para reproducir el descuadre de $87.20 — no es hueco de CeCo (descartado) ni importe negativo (no hay filas negativas en su Excel).
  2. Revisar con Contabilidad los CeCos activos descubiertos de 0371 (000020 DIRECCION GENERAL, 000028 RRHH, 000068 TRACTOS PLANAS, 000582 BLOQUERA 1, 000103 TRITURADORA METSO): su reclasificación no se está haciendo y ninguna validación de cuadre lo detecta, porque los renglones son simétricos.
  3. Generalizar 05_ a configs que no son de Gasto_Registro, leyendo Poliza_Configuracion_Tabla.Pc_Campo_Dia en vez de asumir Gr_Fecha.