Cómo estandarizamos los precios mayoristas de SNIIM

Convertimos los 47 reportes del SNIIM (25 esquemas de origen distintos) en un solo modelo canónico: una tabla de hechos, dimensiones compartidas y reglas explícitas de unidad y de calidad de dato.

Generado desde sniim-extractor/src/core/canonical.py — no editar a mano. Regenerar con sniim-extractor/.venv/bin/python scripts/build_standardization_note.py.

Por qué estandarizar

El SNIIM publica 47 reportes independientes: boletines diarios por central de abasto para productos agrícolas, pecuarios y pesqueros. Cada reporte se publica como su propia tabla, con nombres de columna, unidades y supuestos que cambian de un sector a otro y, a veces, dentro del mismo sector.

Sin estandarizar, esas tablas no forman una superficie de análisis: el precio viaja en columnas que se llaman Precio Mín en un boletín, Pmín en otro y Pechuga_Mín($/kg) en un tercero; la misma columna mezcla precios por caja, manojo, pieza o kilogramo; y 0.00 se usa para decir «no reportado», no para decir «gratis».

El modelo canónico resuelve esas diferencias una sola vez, en el pipeline, para que una consulta funcione igual en los tres sectores y cualquier precio pueda compararse por kilogramo.

Antes y después

Cuatro reportes reales, cada uno con su forma de origen, y las filas que produce el pipeline. Los valores son ilustrativos; la transformación es la misma que ejecuta scripts/build_catalog.py sobre los datos completos.

frutas_y_hortalizas — Agrícolas

La misma observación en prices (una fila por componente de precio):

destino_pescados_marinos — Pesqueros

La misma observación en prices (una fila por componente de precio):

aves_pollo_pza — Pecuarios

La misma observación en prices (una fila por componente de precio):

azucar — Agrícolas

La misma observación en prices (una fila por componente de precio):

Mapeo de columnas

Tabla generada desde el registro core.canonical.ENDPOINTS. Cada columna de origen termina en un campo canónico o en una medida con su price_kind. El archivo standardization-note.json trae el mapeo columna por columna para las 47 tablas.

Agrícolas (5 endpoints)

Pecuarios (22 endpoints)

Pesqueros (20 endpoints)

Reglas de unidad y precio

Presentación → unidad → precio por kilo

parse_presentation traduce la presentación publicada a una unidad (kg, caja, manojo, docena, litro, …). kg_per_unit solo se llena cuando el boletín declara un peso —Caja de 10 kg, Caja con 48 latas de 425 gr— o cuando la presentación es el kilogramo. Con peso, price_per_kg = price_mxn / kg_per_unit; sin peso, price_per_kg queda NULL y presentations.conversion_note explica por qué.

Mercado → estado, nombre y tipo

parse_market separa el prefijo de estado (Q.R., N.L., Michoacán) del nombre del mercado o planta y clasifica el tipo (mercado, rastro_planta, obrador, zona_metropolitana, nacional). La etiqueta original se conserva en market_aliases, de modo que cada fila puede rastrearse hasta el texto exacto del boletín. El catálogo resuelve 1.060 etiquetas en 227 mercados canónicos.

Calidad de dato

Las reglas se aplican en el build y cada valor afectado queda registrado en dq_issues; nada se corrige en silencio.

Vistas de compatibilidad

Los 47 nombres de tabla originales siguen disponibles como vistas reconstruidas desde observations + prices, con las mismas columnas y en el mismo orden que el boletín. scripts/verify_catalog.py --roundtrip compara fila por fila todas las columnas que no son de precio: si una vista se desvía del origen, el build falla.

El resultado en números

Conteos del registro de endpoints y del último catálogo construido (docs/catalog-stats.json, 2026-11-05):

Límites

El modelo no inventa pesos: 90,5 % de las filas de precio se pueden llevar a MXN/kg; el resto corresponde a presentaciones por pieza, manojo, docena o litro, donde el boletín no publica peso. Esas filas se conservan con price_per_kg NULL y una nota de conversión.

Esta nota describe el pipeline, no la calidad del dato de origen: los huecos de cobertura y las correcciones del SNIIM se documentan aparte, en _manifest.json y en el ledger de data_gaps.