Smart Reorder: cuándo pedir mercadería sin tener stock muerto ni stockout

01El dilema del reorder

Imaginá: tu mejor SKU vende 8 unidades/día. Lead time del proveedor: 21 días. Tenés 60 unidades en stock.

¿Pedís hoy o esperás? Si esperás 7 días, te quedan 60 − 56 = 4 unidades cuando hagas el pedido. Si el proveedor demora un día más de lo prometido, te quedás sin stock 1 día y perdés 8 ventas.

Pero si pedís hoy y el lead time es el habitual, te van a llegar 200 unidades cuando todavía tenés 25 — terminás con 225 unidades para 28 días = months of stock alto.

La diferencia entre stockout y stock muerto es safety stock.

02La fórmula que importa

reorder_point = (avg_daily_velocity × lead_time_days) + safety_stock

safety_stock = z_score × stddev_velocity × √lead_time

z_score: - 1.65 → cubrís el 95% de los días. - 2.33 → cubrís el 99% de los días.

Para un SKU con velocity 8/día, stddev 2.5, lead time 21d, safety stock al 95%:

reorder_point = (8 × 21) + (1.65 × 2.5 × √21) = 168 + 19 = 187 unidades

Cuando tu stock baja de 187, hacés pedido.

qty_to_order = (forecast_velocity × forecast_window) − stock_actual − safety_stock

Para forecast 60 días: qty = (8 × 60) − 187 − 19 = 274 unidades.

03Por qué nadie lo hace bien

Calcular esto a mano por 300 SKUs es imposible. La intuición humana subestima la varianza y termina pidiendo "por las dudas un poco más".

04Cómo lo resolvemos

KANDIMA corre el cron smart-reorder que computa reorder_point y qty_suggested para cada SKU activo. Considera:

• Velocity 7d y 30d (para detectar trend).
• Lead time histórico del proveedor (no el prometido — el real).
• Stddev de la demanda.
• Seasonality (si lo tenés taggeado).

Endpoint: GET /api/v1/reorder?status=pending devuelve las recomendaciones priorizadas por confidence.

Cuando un SKU entra en zona crítica, te llega un push: "Pedí 274 unidades de SKU-001 antes del 18-05".