Proceso: solicitud de material → compra → entrega

Cómo funciona de verdad el proceso, con evidencia de datos. Es una personalización de Trivasa (ZTRV_*), no existe en el ERP estándar.

Exploración 2026-07-31, corregida y ampliada 2026-08-10 y 2026-08-13.

Resumen en una línea

El proceso tiene dos ramas: 99.97 % de las solicitudes se surten directo de almacén (vía Movimiento, sin tocar compras) y solo ~16 % generan una Requisicion_Compra formal — de esas, una fracción menor llega a Orden_Compra → Compra → Cuenta_X_Pagar.

Las dos ramas

Solicitud de Material (Sm_Folio)
        │
        ├── 99.97% ──► hay existencia ──► Movimiento (salida de almacén)  [FIN, ciclo corto]
        │
        └── una fracción ──► NO hay existencia
                 │
                 ▼
         Requisicion_Compra (~16% de todas las solicitudes)
                 │
                 ▼
         Orden_Compra ──► Compra_Encabezado/Compra ──► Cuenta_X_Pagar ──► Pago_CXP

La implicación para cualquier modelo: la inmensa mayoría de "solicitudes de material" no tocan compras. El ciclo largo con aprobación presupuestal es la minoría, y dentro de esa minoría el tramo Requisición→OC→Compra es el que más ruido de datos tiene (ver Calidad de datos).

Máquina de estados: `ZTRV_Estado_Solicitud`

Es la única tabla que registra tramos de tiempo por estado, con Fecha_Inicio/Fecha_Fin. Por eso es la pieza que permite medir tiempo de ciclo y cuellos de botella por etapa.

Estado	Descripción	Folios que lo visitan
`AC`	ACTIVO	113,681
`CE`	CERRADO	95,840
`AB`	ABIERTO	59,782
`PR`	PROGRAMADO	21,395
`FN`	FINALIZADO	18,403

Secuencias más frecuentes: AC>CE (38,623) · AC>AB>CE (18,291) · AB>CE>AC (9,776) · AC>PR>CE (6,103) · AC sin cerrar (4,380).

93 % de las solicitudes pasan por 2–4 estados. Los casos de 6+ (hasta 19) son outliers de reproceso administrativo, no proceso normal.

Tres advertencias sobre esta tabla

AB dejó de usarse después de 2024-11-18 — cambio de proceso, no anomalía.
Fecha_Fin = '2000-01-01' es sentinela de "abierto", no NULL. Filtrar antes de restar fechas.
Hay duplicados de captura. Deduplicar por (Sm_Folio, Estado, Fecha_Inicio, Fecha_Fin) y no usar Estado_Activo='SI' como estado vigente sin tomar MAX(Fecha_Inicio).

Autorización presupuestal

Corrige una conclusión previa: se creía que el sistema "no captura consistentemente quién aprobó el presupuesto y cuándo". Es incorrecto — sí se captura, en tablas que no se habían inventariado.

`ZTRV_Presupuesto_Autorizacion_Documento` (101,348 filas)

Bitácora polimórfica, un renglón por cada paso de revisión/autorización:

Columna	Rol
`Pad_Operador`	quién hizo la acción
`Pad_Tabla`	`ZTRV_SOLICITUD_MATERIAL` / `ORDEN_COMPRA` / `Requisicion_Compra` / `ZTRV_Presupuesto_Cambio` / `ZTRV_GASTO_SOLICITUD`
`Pad_Documento`	el folio (`Sm_Folio`/`Oc_Folio`/`Rc_Folio`)
`Pad_Estado`	código de paso
`Pad_Fecha`	la fecha de autorización

Arranca 2024-03-31 y cubre 98.7 % de las solicitudes creadas desde entonces (30,489 de 30,886). Un folio tiene como máximo 1 fila AU — tabla limpia, sin los duplicados de ZTRV_Estado_Solicitud.

Joins validados por coherencia de fecha:

`Pad_Tabla`	filas	% coherente
`ZTRV_SOLICITUD_MATERIAL` → `Sm_Folio`	60,272	100 %
`ORDEN_COMPRA` → `Oc_Folio`	44,893	99.8 %
`Requisicion_Compra` → `Rc_Folio` (fan-out por líneas)	18,144	99.99 %

Catálogo `Pad_Estado`

Código	Significado	n
`AU`	Autorizado (paso final positivo)	52,182
`RE`	Revisado (primer paso)	39,270
`TE`	Terminado (solo en `ORDEN_COMPRA`)	8,589
`RZR`	Rechazado en revisión	760
`RZA`	Rechazado en autorización	380
`RZ`	Rechazado (genérico)	141
`RZRE`	Rechazo re-enviado tras modificación	18
`JU` / `EN`	outliers, casi no se usan	8

Mediana de ~1.5 min para autorizar una solicitud ya revisada.

⚠️ Filtrar Pad_Documento <> '{FOLIO}' — hay filas con el placeholder de plantilla sin sustituir.

El flujo NO es monótono — existe ciclo de retrabajo

El catálogo de Pad_Estado de arriba sugiere un flujo lineal (RE → AU como final feliz, o RZR/RZA/RZ como rechazo final). En la práctica no es así: un folio rechazado en revisión puede corregirse y reingresar, generando una secuencia más larga sobre el mismo folio en la misma tabla (Pad_Documento repetido con Pad_Fecha distintas).

Patrón de retrabajo confirmado (2026-08-13), sobre la traza completa de ZTRV_Presupuesto_Autorizacion_Documento:

RZR (rechazado en revisión) → RZRE (reenviado tras corrección) → RE (revisado de nuevo) → AU o RZA

Secuencias completas observadas (Pad_Estado ordenado por Pad_Fecha, muestra sobre folios de Pad_Tabla='ZTRV_SOLICITUD_MATERIAL', 15 secuencias distintas en total):

Secuencia	n folios	%
`RE>AU`	30,115	96.27%
`RZR` (solo, sin seguimiento aún)	412	1.32%
`RE>RZA`	365	1.17%
`AU` (solo, autorización directa sin `RE` previo)	271	0.87%
`RE` (solo, sin resolución aún)	76	0.24%
`RZR>RZRE>RE>AU`	15	0.05%
`RZ` (solo)	14	0.04%
`RE>RZA>JU>AU`	6	0.02%
`AU>RE>RZA`	2	0.01%

Casos que rompen la intuición de "una sola pasada":

Un folio puede tener AU seguido de RE/RZA posteriores, meses después (ej. autorizado en julio, vuelto a revisar y rechazado en agosto del mismo año) — AU no es garantía de estado final estable.
Un folio puede tener dos ciclos completos de rechazo separados por meses (RZR en febrero, otro RZR en agosto para el mismo folio).

Implicación práctica: al tomar "el último Pad_Estado" de un folio (ROW_NUMBER() ... ORDER BY Pad_Fecha DESC), ese valor es el más reciente observado a la fecha de la consulta, no necesariamente un estado terminal — puede volver a cambiar. No cachear ni asumir estabilidad de este campo sin volver a consultar.

Folios con autorización sin resolver siguen "activos" en la cabecera

De los folios cuyo último Pad_Estado (a fecha de corte 2026-06-30) no es AU (873 folios: RZR 404, RZA 358, RE 51, RZ 14, RZRE 1), se cruzó contra ZTRV_Solicitud_Material.Es_Cve_Estado de la cabecera:

`Es_Cve_Estado` (cabecera)	n	%
`AC` (activa)	508	58.19%
`CE` (cerrada)	300	34.36%
`FN` (finalizada)	31	3.55%
`CA` (cancelada)	22	2.52%
`AB` (abierta)	7	0.80%
`RZ`	3	0.34%
`PR`	2	0.23%

Hallazgo operativo: 508 folios (58% de los que nunca resolvieron a AU) siguen con la solicitud en estado AC (activa) en la cabecera — la solicitud sigue "viva" en el sistema mientras su autorización presupuestal está trabada (en revisión o rechazada) sin resolverse. "Activa" en la cabecera no implica que la autorización esté avanzando.

Pestañas AB, PR y APG de `ZTRV098` "Control de Solicitudes de material v3"

Exploración 2026-08-13, reconciliada contra baseline real exportado de pantalla (no solo conteos). Ver también la pestaña DISPONIBLE arriba y Calidad de datos para el detalle del join polimórfico que hizo posible esto.

El indicador de la propia pantalla resume el significado de cada pestaña: AC solicitud activa no autorizada · AU solicitud autorizada · AB solicitud con requisición de compra · PR solicitud con orden de compra · APG solicitud con orden de compra atrasada · DISPONIBLE solicitud con apartado · FN surtida en su totalidad o finalizada.

En la práctica, a nivel de línea (Sm_Folio, Pr_Cve_Producto):

AB = existe una Requisicion_Compra activa (Rc_Tabla= 'ZTRV_Solicitud_Material', Es_Cve_Estado='AC') para esa línea, y la cabecera de la solicitud no está CE/FN.
PR = existe una Orden_Compra vigente (Es_Cve_Estado='AC', por la ruta directa o indirecta descrita en Calidad de datos) con Oc_Fecha_Entrega >= HOY.
APG = mismo criterio que PR pero con Oc_Fecha_Entrega < HOY (orden vigente mas ya vencida) — inferido del nombre del indicador, sin baseline exportado propio que lo confirme (no confundir con hecho verificado).

Reconciliado contra baseline real exportado el mismo día:

Pestaña	Baseline	Cobertura	Precisión
AB	89 líneas	92.13 %	93.18 %
PR	165 líneas	96.97 %	97.56 %

El hallazgo que más subió la precisión de PR (de 36 % a 97.6 %): sin el filtro Oc_Fecha_Entrega >= HOY, se contaban órdenes Es_Cve_Estado= 'AC' de hasta 2020 nunca cerradas — AC en Orden_Compra no implica "a tiempo", ver Calidad de datos.

Query final y notebooks de cierre: 52_notebook_ab_solicitud_material.py, 53_notebook_pr_solicitud_material.py.

Pestaña AU — parcialmente explorada, sin converger

A diferencia de AB/PR, la pestaña AU (bucket residual: autorizada pero aún sin apartado/requisición/OC) no llegó a una query limpia contra un baseline real de 20 líneas (19 folios): mejor resultado 90 % cobertura / ~26 % precisión, sin causa raíz única para los ~50 sobrantes (se descartaron: apartados históricos CE/CA, Sm_Revisar_Oc, Sm_Es_Servicio, antigüedad de Pad_Fecha). Confirmado con un caso real que parte del ruido es inherente a comparar contra producción en vivo: a un folio se le creó un apartado activo la misma tarde, después de que se exportó el baseline de pantalla. Detalle completo en PROGRESS.md del proyecto.

Estado en el warehouse

9 tablas del dominio están replicadas a Postgres (raw.ztrv_solicitud_* + raw.ztrv_apartado + raw.ztrv_presupuesto_autorizacion_documento, 1,109,448 filas, reconciliadas al 100 % contra .207). Ver Warehouse.

Las 7 tablas originales son la excepción a la regla de backfillear desde TRIVASADB3: en su momento, .200 (hoy .205, ver Servidores y bases) era el staging de la app de solicitudes y escribía estas tablas a diario. Ver Servidores y bases. Las 2 tablas agregadas el 2026-08-13 (ZTRV_Apartado, ZTRV_Presupuesto_Autorizacion_Documento) sí se backfillearon desde TRIVASADB3 (ahora .205) — el pre-flight no encontró la misma señal de escritura activa que forzó la excepción original, ver Warehouse para el detalle.

Reporte nativo equivalente

RPTRV04 "Pendientes por surtir" — ver Reportes nativos.

Columnas de cabecera y detalle (inventario básico)

Verificado 2026-08-28 vía INFORMATION_SCHEMA.COLUMNS contra .205/TRIVASADB3 (sin credenciales de .207 a mano en esa sesión — el runbook solo trae un placeholder, ver Servidores y bases). El esquema se asume idéntico en .207 por la nota ya documentada ahí ("prácticamente idéntico"), pero no se confirmó columna por columna en .207 mismo. Consulta de prueba corrida contra .205 con datos reales (folios 05-0071470..05-0071474, agosto 2026) para validar que las columnas abajo existen y traen valores esperados — no solo que aparecen en el catálogo.

Contexto que motivó este inventario: no había, hasta ahora, un listado de columnas base de ZTRV_Solicitud_Material/_Detalle en este repo — solo columnas mencionadas de pasada en el contexto de otros hallazgos (estados, fechas de autorización). Útil para cualquier reporte básico (no de compras) sobre la solicitud misma.

`ZTRV_Solicitud_Material` (cabecera, PK `Sm_Folio`)

Columna	Qué es
`Sm_Folio`	folio, PK
`Sm_Fecha`	fecha de creación de la solicitud
`Sm_Fecha_Entrega`	fecha de entrega solicitada
`Sc_Cve_Sucursal`	sucursal (FK a `Sucursal.Sc_Cve_Sucursal`)
`Al_Cve_Almacen`	almacén
`Oper_Alta`	operador que dio de alta el folio — es el campo más cercano a "solicitante" (usuario del sistema, no nombre de persona)
`Sm_Prioridad`	prioridad
`Sm_Comentario` / `Sm_Comentario_Comprador` / `Sm_Comentario_Cierre`	comentarios libres en distintas etapas
`Es_Cve_Estado`	estado de cabecera (`AC`/`CE`/`AB`/`PR`/`FN`/`CA`, ver máquina de estados arriba)
`Sm_Fecha_Cierre`	fecha de cierre — sentinela `2001-01-01` = "no cerrado" (ya documentado arriba)
`Sm_Revisor` / `Sm_Autorizador`	texto libre, no confirmado que coincida con `Pad_Operador` de `ZTRV_Presupuesto_Autorizacion_Documento`
`Sm_Tabla` / `Sm_Documento`	patrón polimórfico propio de la cabecera (origen), no confirmado su uso — pendiente de explorar

`ZTRV_Solicitud_Material_Detalle` (línea, PK `Sm_Folio, Sm_ID`)

Columna	Qué es
`Sm_ID`	consecutivo de línea dentro del folio
`Pr_Cve_Producto`	FK a `Producto.Pr_Cve_Producto` — puede venir vacío (`''`), no siempre NULL
`Sm_Concepto`	descripción libre de la línea (a veces igual a `Producto.Pr_Descripcion`, a veces distinta, ej. cuando `Pr_Cve_Producto` viene vacío)
`Sm_Cantidad_1` / `Sm_Unidad_1`	cantidad y unidad solicitada
`Es_Cve_Estado`	estado propio de línea — diverge de la cabecera con frecuencia, ver hallazgo de `fct_documento_trazabilidad` en Warehouse
`Sm_Es_Servicio`	bit, línea de servicio en vez de material físico
`Sm_Costo` / `Sm_Costo_Importe`	costo unitario y monto de la línea
`Sm_Revisar_Oc`	bit, mencionado ya como descartado en la exploración de la pestaña AU

No exploradas en esta pasada (quedan para cuando haga falta): Sm_Referencia, Te_Cve_Tecnico, Sm_Interno, Sm_Activo_Fijo, Pv_Cve_Proveedor, Sm_Provision, Sm_Cambio_PPTO (cabecera); Pr_Numero_Parte (detalle — ya documentado arriba que casi siempre viene vacío y no es lo que muestra pantalla), Sm_Cantidad_Control_2, Sm_Monto_Ppto, Sm_Marca/Sm_Modelo/Sm_Vin.

`Eq_Cve_Equipo`, `Tg_Cve_Tipo_Gasto`, `Sm_Materia_Prima` — las 3 modalidades de captura de una solicitud

Exploración 2026-08-31, diseñando el rediseño del reporte 1 de streamlit-reportes (ver Análisis de Solicitud de Material). Confirmado contra las consultas internas del módulo (no reportes, ver Reportes nativos — EMPRESAS_2.dbo.Consultas, claves ZTRV_SOLICITUD_DETALLADA / ZTRV_SOLICITUD_DETALLADA_PP).

El módulo de Solicitud de Material tiene 3 formas de abrirse, y el ERP las distingue con este filtro (aplicado a nivel línea de detalle):

Origen	Condición	Cómo llega el equipo
Orden de Servicio	`Tg_Cve_Tipo_Gasto = ''`	Heredado: `ZTRV_Solicitud_Material.Os_Folio` → `Orden_Servicio.Os_Equipo` → `Equipo`
Consumo Interno	`Tg_Cve_Tipo_Gasto <> ''`	Directo: `ZTRV_Solicitud_Material.Eq_Cve_Equipo` → `Equipo` — el usuario lo captura junto con el tipo de gasto
Materia Prima	`Sm_Materia_Prima = '1'` (cabecera)	Agrupada con Consumo Interno en el mismo filtro `OR` — el ERP no la trata como rama independiente en esta consulta, lo que sugiere que sí se consume/gasta igual (contradice la sospecha inicial de "solo entra a stock, no se consume")

Eq_Cve_Equipo vive en cabecera (ZTRV_Solicitud_Material), no en detalle — el equipo es propiedad de la solicitud completa, no de la línea.

Equipo.Eq_UserDef_1 es donde vive la descripción real del equipo — no existe columna Eq_Descripcion. Confirmado con datos reales: Eq_Cve_Equipo='0000000253' → Eq_UserDef_1='DOLLY ATRO 2018 SUSP NEU 20 TON'. Eq_Numero_Economico es un campo aparte (numérico corto), no la descripción.

Sm_Cantidad_Control_1 (detalle) es lo pedido (confirmado con el usuario) — no confundir con Sm_Cantidad_1, que también existe y en la práctica se usa igual en algunos reportes ya en producción (ver Solicitud de Material - Detalle); no se investigó a fondo si difieren en algún caso.

Tipo_Gasto.Tg_Descripcion (catálogo, PK Tg_Cve_Tipo_Gasto) es el join directo para mostrar el nombre del tipo de gasto — no hace falta la regla más compleja de ZTRV_SOLICITUD_TIPO_GASTO (consulta interna, no explorada) salvo que aparezcan discrepancias.

El surtido no tiene fecha propia — sale de `Movimiento`

Ni la cabecera ni el detalle de la solicitud traen una fecha de "cuándo se surtió". La única fuente real es Movimiento.Mv_Fecha, vía:

ZTRV_SOLICITUD_MATERIA_DOCUMENTO.Smd_Documento = Movimiento.Mv_Folio
AND ZTRV_SOLICITUD_MATERIA_DOCUMENTO.Smd_Tabla = 'MOVIMIENTO'
AND ZTRV_SOLICITUD_MATERIA_DOCUMENTO.Smd_Producto = Movimiento.Pr_Cve_Producto

Confirmado contra la consulta nativa ZTRV_SOLICITUD_SURTIDO del ERP (mismo join, Mv_Cantidad_1 * -1 como cantidad surtida — negativo porque es salida de almacén). La cantidad ya se conocía (SUM(Smd_Cantidad) de ZTRV_SOLICITUD_MATERIA_DOCUMENTO, Estatus<>'CA', usada ya por el reporte 3); lo nuevo de esta exploración es la fecha.

Query de referencia (reporte básico, grano línea): ver notificacion-solicitud-material o el repo sm-reporte.