Consulta XMLs vs Gastos/Compras

App de solo consulta para Contabilidad de Trivasa: identifica CFDIs (XMLs) timbrados del mes que todavía no tienen un registro ligado en MPRO (gasto o compra), con un panel de historial de proveedor al seleccionar uno. Vive en exploracion/consulta_xmls_gastos/ del repo trivasa-bi-dev.

Se reconstruyó explícitamente como app Flask en vez de Streamlit — decisión de arquitectura tomada durante el proyecto, no la elección original.

Ingesta de CFDIs

Los XMLs se acceden vía un mount CIFS de solo lectura y persistente, en /etc/fstab: servidor //192.168.117.211/SincronizarXml, punto de montaje ~/trivasa-bi-dev/exploracion/consulta_xmls_gastos/mnt_xml/, ruta real mnt_xml/TRI970922TL2/XML RECIBIDOS/{año}/{año}_{mes}/{año}_{mes}_AC/. Gotcha: el UUID en el nombre del archivo tiene casing inconsistente (mayúsculas y minúsculas mezcladas) — normalizar siempre a mayúsculas al comparar.

Un pipeline dlt (raw.comprobante_digital en Postgres) hace la carga inicial + incremental + un cron diario a las 5am — completo y en producción, ver Pipelines dlt. El schema de destino se llama raw (reservado exclusivamente para datos que vienen de MPRO); un dato relacionado que originalmente vivía en un schema contabilidad se movió a raw_sat por esa misma convención (ver Warehouse Postgres).

No existe una tabla única “XMLs registrados en MPRO” — el match de pendientes usa dos fuentes de UUID distintas según el tipo de documento, unidas en la lógica de match (pandas), no en una tabla persistida: gastos vía Pago_Cxp_Comprobante.Pcc_Timbre_UUID, compras vía Comprobante_Digital.Cd_Timbre_UUID filtrado a cd_tabla='COMPRA'.

Falta replicar el mismo patrón de pipeline dlt para Pago_Cxp_Comprobante (lado gastos) — hoy ese dato entra al prototipo vía CSVs exportados manualmente de .207, no vía raw.*.

Decisiones de negocio del match

• RFC con múltiples Pv_Cve_Proveedor: se combina el historial de todos los códigos que matcheen (no se elige uno solo ni se alerta).
• Alcance del historial de proveedor: últimos 24 meses.
• Refresh de XMLs vía botón manual en la app (no cron) — no hay urgencia de frescura y así se mantiene control explícito del usuario. El cron diario sí aplica a las tablas raw de match (comprobante_digital, pendiente Pago_Cxp_Comprobante), que son infraestructura de fondo, no una acción del usuario.

Por qué no dlt/dbt para todo el prototipo

Se descartó a propósito un diseño inicial con pipeline dlt completo + proyecto dbt desde cero — sobre-ingeniería para un prototipo. Se optó por scripts Python + Streamlit/Flask, mismo patrón que Layout de Gastos y Trazabilidad Consumo Interno. Solo las tablas de match (Comprobante_Digital, Pago_Cxp_Comprobante) justifican dlt: se consultan en cada refresh de la app y crecen día a día. El resto (Gasto_Registro, Compra_Encabezado, historial de proveedor) sigue siendo consulta en vivo contra .207 — impacto trivial confirmado, se dispara solo al hacer clic en un proveedor puntual.

Estado del prototipo

El prototipo Streamlit/Flask corre hoy sobre una mezcla de CSVs exportados de .207 (uuid_gastos.csv, uuid_compras.csv, proveedor.csv, operadores.csv) y la tabla Postgres raw_sat.cfdi_recibidos — no es la arquitectura final. Migrar el prototipo a leer directo de raw.* en Postgres (sin CSVs intermedios) es el siguiente paso.

Conexiones nuevas creadas para este proyecto: connection_200_empresas2.py y connection_207_empresas2.py, ambas contra la tabla Operadores (nombre de operador), una por cada copia de la base (.200 / .207).

Pendiente

1. Pipeline dlt para Pago_Cxp_Comprobante, mismo patrón que comprobante_digital.
2. Migrar el prototipo de CSVs a raw.* en Postgres directo.
3. (Opcional, más adelante) replicar también raw.proveedor, raw.gasto_registro, raw.gasto_registro_documento, raw.compra_encabezado, raw.operadores — para que el panel de historial de proveedor deje de depender de consulta en vivo a .207 y de CSVs.

Véase también

• Layout de Gastos — otro reporte de Trivasa sobre la misma base MPRO, comparte convenciones de conexión (.200 vs .207).
• Infraestructura de datos Trivasa — detalle de los pipelines dlt, el warehouse Postgres y las conexiones que usa este proyecto.