Plant Cerebro
← datos
datoactivo29/10

El stock disponible está en data.available, NO en data.quantity — con quantity el inventario daba 7 veces más

<!-- ESTADO-VIVO:INICIO -->

⚡ ÚLTIMO ESTADO VIVO (Actualizado: 2026-10-29 16:48 · Orden Cronológico Inverso: Más Nuevo Arriba)

<!-- ESTADO-VIVO:FIN -->

El campo correcto es data.available del producto madre. Es el que Gabriel ve en Plant como "unidades disponibles para la venta". data.quantity no es stock disponible y usarlo estaba rompiendo todos los monitores.

La prueba: Queso Rallado de Vívet tiene available: 1020 y quantity: 70. Gabriel veía 1.020 en Plant y el monitor mostraba números chicos. Peor: había filas de Producción con nombres parecidos (SABOR QUESO SALU TAST QUESO RALLADO BLUMOS, available: 30) que se cruzaban por nombre y daban el "30 u" que apareció en el tablero.

Magnitud del error, sobre productos activos sin internos:

criteriovalorizadounidades
con quantity$2.381M544.544
con available$353,4M182.993
Mauro, contado$339,9M160.890

Pasó de estar 7 veces arriba a cuadrar al 4%. Corregido en build_stock.py (dos consultas) y build_vivet.py (el filtro de sin-stock y la de fichas).

Cuadre bueno, depósito por depósito (es el control que quedó en pantalla):

Lo que hay que excluir siempre del cuadre: los insumos y packaging (3,75 millones de unidades, están en unidades muy chicas y distorsionan cualquier total) y la mercadería de Luz Azul (469.559 u de terceros bajo nuestro techo, no es nuestra).

Sobre los $61,6M que faltan en FULL: la hipótesis de Gabriel es que Mauro cuenta como stock de ML la mercadería ya despachada por colecta que ML todavía no recibió. No se puede confirmar por API: Mercado Libre no expone los envíos en camino a FULL — probé ocho rutas, todas 403 o 404, y la documentación lo dice explícito ("a través de las APIs solo se puede consultar el stock de fulfillment y las operaciones realizadas"). Lo que sí se ve es el stock ya recibido y, con /inventories/{id}/stock/fulfillment, lo que está en FULL pero no disponible: hoy $4,12M, con motivos (internalProcess 440 u, withdrawal 43, lost 34, notSupported 26).

Dos trampas de unidades que hay que tener presentes siempre:

  1. Mongo cuenta unidades sueltas; una publicación de ML puede ser un pack. La conversión exacta es el atributo UNITS_PER_PACK de la publicación (ver ml-api-endpoints-utiles). El campo pack del producto no sirve para esto: Silk tiene pack: 12 pero la publicación vende 1 unidad.
  2. Para barrer todas las publicaciones hay que usar search_type=scan: la búsqueda normal corta en 1.000 por estado y tenemos 3.118.

Ver plant-datos-endpoints y ml-caja-de-compra.

Datos/plant-stock-sobrevaluado