# Criterio de compras — por qué existe Pedidos a Proveedor y en qué orden se construye > **Borrador del 11-ago-2026.** Sale de tres respuestas de Manuel en una conversación de esa > tarde, no de una teoría de escritorio. Está escrito para que lo corrija él: donde diga algo > que no es, se cambia. Lo que **no** puede pasar es que se quede sin escribir — ese criterio > hoy vive en su cabeza y ahí no le sirve a nadie más. --- ## 1. La tesis > *"La experiencia es del cliente y lo que hay que darle son opciones y cálculos claros para que > decida. Mi experiencia en 40 años es que la mayoría compra mal porque lo hace en supuestos. La > idea es darle lineamientos claros, tomando todos los parámetros que la teoría indica y que es > muy probable que ni se le han ocurrido — especialmente si el comprador no es el dueño sino > alguien que tiene alguna o ninguna experiencia. Ahí es donde tiene mayor valor nuestra > propuesta: en que la curva de aprendizaje sea mínima o nula."* Cinco cosas se siguen de ahí, y conviene no perderlas: 1. **El sistema no decide.** Da opciones y cálculos claros; la decisión es del cliente. 2. **El problema real es comprar sobre supuestos**, no la falta de un número. 3. **El valor está en mostrar las variables que el comprador no sabía que existían**, no en calcular mejor que él. 4. **Se diseña para quien no es el dueño** y tiene poca o ninguna experiencia. 5. **El orden es artesanal → datos sólidos → ML e IA.** Saltárselo es vender humo. --- ## 2. El momento real de uso Manuel, sobre qué ve el comprador: > *"Hoy viene el proveedor X, ¿qué tengo que pedir?"* Eso no es un tablero ni un análisis: **es alguien parado en la puerta**. La pantalla de cotización tiene que resolver esa pregunta en ese momento, con los parámetros a la vista. De ahí se sigue un criterio de diseño: **una "cantidad sugerida" grande y sola contradice la tesis**, porque esconde justamente lo que hay que enseñar. Tiene que verse de qué se compone y qué pasa si se mueve cada variable. --- ## 3. Dos usuarios distintos, dos pantallas distintas | | El comprador | El dueño / financiero | |---|---|---| | Su pregunta | "Viene el proveedor X, ¿qué pido?" | "¿Cuánta plata tengo dormida y por qué?" | | Cuándo | En el momento, con el proveedor esperando | Cuando revisa el negocio | | Dónde vive | Módulo de cotización (mbinv) | Panel del ML (repo `Demo-AI`) | | Estado | Construido y desplegado | Construido: sobrestock, understock, productos fantasma | **No mezclarlas.** Meterle análisis financiero a la pantalla del comprador la vuelve inútil para el momento en que se usa; y meterle la mecánica del pedido al panel del dueño, también. --- ## 4. Tres capas, y de qué se puede fiar cada una Manuel, sobre por qué no se puede empezar por lo financiero: > *"Hay que ir afinando progresivamente, ya que en la actualidad las existencias, por ejemplo, no > son confiables, y los pedidos en tránsito no los reciben y quedan flotando."* Eso define tres capas. **No es una fila donde cada una espera a la anterior** —los switches de la capa 2 lo demuestran—: es que **cada capa dice de qué se puede fiar**, y por eso la de la plata va última. ### Capa 1 — Que el dato sea cierto Hoy no lo es, y está medido. El panel del ML ya lo cuantifica en `/api/dashboard/data_quality_inventory`: - `rows_negative_stock` — existencia en negativo - `rows_sales_without_stock` — vendió sin tener: understock y descuadre a la vez - `rows_stock_without_sales_30d` — stock sin rotación Y el agujero concreto que Manuel nombra: **los pedidos en tránsito no se reciben y quedan flotando**. Mientras eso pase, la existencia y el tránsito mienten, y **toda sugerencia construida encima miente igual**. > **Consecuencia práctica:** la pieza que cierra el tránsito es la **recepción de producto contra > el pedido** (#23310). No es una función más del módulo: es lo que hace que las otras dos capas > signifiquen algo. ### Capa 2 — Que el comprador decida con datos Es lo que ya está construido: cobertura (entrega + ciclo de compra + colchón), venta diaria con estacionalidad y tendencia, empaque, existencia, tránsito. **Y ya existe la respuesta al dato sucio: los switches.** La pantalla de armar cotización tiene *«No confiar en la existencia»* y *«No contar los pedidos en tránsito»*, separados a propósito porque la duda sobre uno no arrastra al otro. Manuel: *"pedir lo que tengamos cierta certeza y en la duda que decida el comprador"*. Eso corrige una lectura fácil de la capa 1: **no es una fila donde cada capa espera a la anterior.** El módulo ya sabe operar sobre datos que no son confiables — lo que hace es declararlo en vez de esconderlo, que es exactamente la tesis. Lo que falta acá no es cálculo, es **exhibición**: que el comprador vea los parámetros y entienda la consecuencia de moverlos, sin estudiar nada. Parámetros que la teoría pide y hoy no se muestran: - **Nivel de servicio** — el colchón hoy es un número de días que alguien escribe. Debería salir de cuánta varía la venta y cuánto varía el plazo de entrega: nadie decide "5 días", uno decide "acepto quedarme sin producto 1 de cada 20 veces". - **Variabilidad, no solo promedio** — dos productos que venden 10 al día no son iguales si uno vende 10 todos los días y el otro vende 70 el lunes y 0 el resto. - **Costo de tener contra costo de faltar** — pedir de más inmoviliza plata, pedir de menos pierde venta. Esa balanza *es* la decisión. - **Mínimos y descuentos del proveedor** — comprar 100 cuando el descuento arranca en 120 es una decisión, no un redondeo. - **Vencimiento** — comprar tres meses de algo que caduca en dos. - **Confiabilidad del propio número** — producto nuevo, venta errática o dato sucio no dan una sugerencia sólida, y el comprador debería poder distinguirla de una que sí lo es. ### Capa 3 — Que el dueño vea la plata El panel del ML ya lo hace. El dato que le da sentido está medido: en **La Chimalteca el sobrestock inmovilizado es de Q3.4 millones**. Eso es, con número, el costo de comprar sobre supuestos — el problema que esta tesis describe. Pero mostrar Q3.4M calculados sobre existencias que no son confiables es peor que no mostrarlos: enseña a desconfiar del sistema. **Por eso esta capa va después de la 1, no antes.** --- ## 5. Por qué todavía no lo usa nadie **No es que se haya estancado: no está liberado, y es a propósito.** Manuel, 11-ago-2026: > *"El sistema no lo usa nadie porque no lo he liberado. Estoy en reuniones de progreso con el > cliente, casi obligando a que documenten los casos de uso."* Eso no es un paso administrativo previo: **es parte del método**. La tesis dice que el producto se diseña para un comprador con poca o ninguna experiencia y con curva de aprendizaje cero. No se puede diseñar eso para alguien a quien no se vio comprar. Los casos de uso documentados por el propio cliente son lo que evita que el módulo se construya sobre lo que nosotros suponemos que hace un comprador. Se nota en lo que ya pasó: **la recepción (#23310) nació de un documento que mandó el cliente**, no de una idea nuestra. Ése es el camino que funciona, y es el mismo que estas reuniones buscan repetir. ⚠️ **Corolario incómodo:** si un caso de uso no está documentado, la función que lo atendería no debería construirse todavía. Es más barato esperar el documento que adivinar y rehacer. ## 6. Qué se sigue de todo esto 1. **La prioridad no es agregarle funciones al módulo.** Está completo desde julio y lo que falta no es capacidad: es el uso real que diga qué sobra y qué falta. 2. **La prioridad es la capa 1**: la recepción (#23310), que cierra el tránsito. Y ya tiene su caso de uso documentado por el cliente, así que cumple la condición de arriba. 3. **Los switches son la respuesta provisional** mientras el dato no sea confiable: *"pedir lo que tengamos cierta certeza y en la duda que decida el comprador"*. No son un parche — son la tesis aplicada, porque hacen explícito de qué se puede fiar en vez de esconderlo. --- ## Para corregir Manuel: donde esto diga algo que no es tu criterio, cambialo. Y donde falte un parámetro que un comprador debería mirar y no está en la lista de la capa 2, agregalo — ese es el contenido que solo vos tenés. --- ## 7. Pendiente para mañana: los parámetros dependen del tipo de negocio Manuel, 11-ago-2026 al cerrar el día, dejándolo anotado para retomarlo: > *"También depende del negocio. Una panadería usa ingredientes que no se venden y se vencen > rápido. Un supermercado compra y vende, y los vencimientos varían pero son difíciles de > controlar — es la última etapa del control de inventario que yo recomiendo, a menos que sea > crítica y tengan pérdidas cuantiosas. Unas se venden, otras se consumen. Las tiendas de > conveniencia tienen de los dos tipos."* Tres ideas para desarrollar: **1. Hay dos naturalezas de producto, y la sugerencia no puede tratarlas igual.** | | Se vende | Se consume | |---|---|---| | Qué es | Producto terminado que sale por caja | Ingrediente o insumo que entra a producción | | Cómo se mide su salida | Venta | Consumo por receta o producción | | Ejemplo | Una gaseosa en la tienda | La harina de la panadería | **Esto ya nos mordió hoy**: en el #23350, la carga de facturas de Alimenti rechazó 307 de 307 porque la validación medía existencia local de **pan, pupusas y dobladas** — productos de producción cuya existencia nunca se alimenta. La distinción venden/consumen no es teórica: es la causa de un bug que le costó un día a un cliente. **2. El giro del negocio define qué parámetros importan.** - **Panadería** — ingredientes que no se venden y se vencen rápido. El vencimiento sí manda. - **Supermercado** — compra y vende; los vencimientos varían y son difíciles de controlar. - **Tienda de conveniencia** — tiene de los dos tipos a la vez. **3. El vencimiento va al final, y es una recomendación explícita de Manuel.** > *"Es la última etapa del control de inventario que yo recomiendo, a menos que sea crítica y > tengan pérdidas cuantiosas."* Vale la pena subrayarlo porque va contra el instinto: controlar vencimientos suena a lo primero que debería hacer un sistema de inventario, y su experiencia dice que **es lo último**, salvo que el cliente ya esté perdiendo plata medible por eso. Antes hay que tener bien lo demás. **Qué falta decidir mañana:** cuáles de los parámetros de la capa 2 aplican a cada giro, y si eso se configura por cliente, se deduce del catálogo (productos con receta vs sin receta) o se pregunta una vez al implementar.