Skip to content

consumo-interno-fifo — estado vivo

2026-08-24 (round2, tarde)

  • Primera corrida en vivo desde esta ubicación, contra .205: marzo 2026 y semestre completo (2026-01-01 a 2026-06-30). 100% reconciliado en ambos (7,306 y 8,568 productos, 0 sin cuadrar). V2 FIFO también sin descuadres en el semestre (105,857 salidas, cobertura exacta en todas).
  • Fix en movimientos_lib.py: 6 tipos de movimiento (053, 201, 903, 905, 981, 983) que colaban como "SIN CLASIFICAR" ahora están en TIPOS_ANULACION_REALES y CLASIFICACION. No cambia ningún resultado de reconciliación, solo limpia el listado.
  • Avance real en el pendiente heredado (reconciliación Consumo_Interno → Contabilidad): confirmado el camino de join completo Consumo_Interno → Gasto_Registro → Poliza_Control → Poliza_Detalle, y documentada la estructura de dos pólizas (memo 10500/10600 + gasto real con Abono a 1140.010.XXX.007 por almacén). Detalle en index.md.
  • Hallazgo nuevo: solo 65% de los folios de Consumo_Interno tienen Movimiento tipo 060 ligado 1:1. El 35% restante (concentrado 90% en almacén 0030 REFACCIONES) genera tipo 800 "Refacciones / consumo" en vez de 060 — tipo que también usa ORDEN_SERVICIO, así que Tm_Cve_Tipo_Movimiento solo no basta para identificar el origen; hace falta Mv_Tabla = 'CONSUMO_INTERNO' AND Mv_Documento = Ci_Folio.

Próxima acción

Confirmar si el 35% de folios sin Movimiento propio tiene otra vía de rastreo o es un hueco de datos real — y decidir si el reporte de reconciliación Consumo_Interno→Contabilidad debe filtrar por Mv_Tabla en vez de por tipo de movimiento. Ver sección "Sigue pendiente" en index.md.

2026-08-24

  • Promovido de ~/por_ordenar/: código base V1 (Kardex de movimientos, entradas/ salidas de negocio, sin traspasos internos, reconciliado 100% enero 2026) y V2 (UUID de compra vía FIFO). 8 archivos en scripts/ (movimientos_lib.py, fifo_lib.py, movimientos_uuid_lib.py, CLIs 05/06, dos apps Streamlit, connection_205_trivasadb3.py). Detalle completo en index.md.
  • Corregido al promover: import de conexión apuntaba a connection_200_trivasadb3 (módulo que ya no existe — TRIVASADB3 se movió a .205 el 2026-08-13). Ahora usa connection_205_trivasadb3.
  • No corrido todavía desde esta ubicación — solo verificado que compila (py_compile), no probado en vivo contra .205/TRIVASADB3.

Próxima acción

Definir cómo incorporar los movimientos internos (traspasos/transferencias, hoy excluidos a propósito porque netean a 0) como su propia vista, sin romper la reconciliación 100% que ya tiene V1. Ver "Por qué se está retomando" en index.md.