Calculadora de Reabasto Full
Cuántas piezas mandar al fulfillment del marketplace, con números
Cruza la venta de cada canal con lo que hay en el fulfillment, tu inventario disponible y lo que viene en camino, y saca cuántas piezas de cada SKU embarcar. Separa el ideal de lo que hoy sí alcanza.
Cómo lo recibes
Todos nuestros desarrollos funcionan en los tres entornos de Odoo. Lo único que cambia es la forma de entregarlos.
Odoo Online (SaaS)
No necesitas poder instalar módulos. Un consultor de Millora entra con un acceso temporal que tú autorizas y lo implementa con Odoo Studio. Cuando termina, revocas el acceso.
Odoo.sh o servidor propio
Recibes el módulo y la guía de instalación por correo en cuanto se confirma el pago. Lo instalas tú, o lo instalamos nosotros contigo.
Instalación · shell
# 1 · copia el módulo a tu addons_path
cp -r millora_calculadora_de_reabasto_full /mnt/extra-addons/
# 2 · reinicia y actualiza la lista de apps
odoo-bin -u all -d tu_base --stop-after-init
# 3 · instala desde Apps
# busca "Calculadora de Reabasto Full"Qué resuelve
El problema
El inventario en fulfillment está consignado: vive en el centro de distribución del marketplace, no en el tuyo. Mandar de menos es quedarte sin vender justo en el canal que más vende. Mandar de más es congelar dinero y pagar almacenaje en un lugar del que sacar el producto cuesta tiempo y dinero.
Y la decisión se toma cada semana, SKU por SKU: de memoria, o con una hoja que cruza mal cuatro datos que viven en cuatro lugares distintos — la venta del canal, lo que el marketplace dice que tiene hoy, lo disponible en tu almacén y lo que viene en camino.
Cómo funciona
Se define un canal por cada fulfillment —uno para cada marketplace— con su equipo de ventas, sus días de cobertura y su lead time. No tardan lo mismo en dar de alta un embarque, y por eso los tiempos viven en el canal y no en una fórmula fija.
La demanda se mide con un promedio ponderado de dos ventanas: por defecto, 70% los últimos 30 días y 30% los últimos 90. Es a propósito. Con sólo la ventana corta, una semana rara —un Hot Sale, una quincena muerta— manda en el resultado; con sólo la larga, un producto que despegó hace un mes se reabastece tarde.
Sobre esa venta diaria se calcula el objetivo —cobertura más lead time más días de seguridad—, se le resta lo que ya está en el fulfillment y lo que va en camino, y se redondea al múltiplo de empaque.
Entonces viene lo que distingue a esta calculadora: no entrega una cifra, entrega tres.
- Sugerido — el ideal, sin mirar si hay con qué cubrirlo.
- Enviable hoy — lo que alcanza con el disponible no reservado de los almacenes que elegiste. No cuenta el stock que ya está apartado para un pedido: mandarlo a Full sería quitárselo a un cliente que ya compró.
- Enviable con entrante — lo mismo, contando lo que viene de proveedor o de producción.
Lo que ni así se cubre queda en Faltante, en su propia columna. Esa columna es la orden de compra o de producción, ya calculada.
Cada SKU sale además con semáforo —agotado, urgente, reabastecer, sano o sobrestock— y con una línea que explica por qué quedó así.
Un detalle que cambia el número
La demanda puede medirse de dos formas, y la diferencia es de fondo. Por defecto cuenta toda la venta del canal, incluida la que se despachó desde tu casa porque el fulfillment estaba agotado. Un producto que se acabó en el CEDIS y siguió vendiéndose por otra vía no tiene por qué verse como si hubiera dejado de venderse — que es exactamente el error que hace que un agotado se vuelva permanente.
Si se prefiere medir sólo lo que salió del CEDIS del canal, se configura y listo.
Sirve igual en Studio
Aunque se entrega como módulo, está construido dentro de lo que Odoo Studio sabe reproducir: modelos normales, campos almacenados que llena un botón y el importador nativo de Odoo para la foto del marketplace. Si la operación está en Odoo Online, se implementa ahí sin perder nada.
Qué no hace
No mueve inventario. Es una calculadora: termina en una lista. El embarque se arma después, con esa lista en la mano.
El inventario del fulfillment se sube a mano. Se carga el reporte que da el propio marketplace, por SKU. No hay conexión en vivo con el CEDIS del canal, así que el dato es tan fresco como la última foto que subiste — y la corrida avisa cuando tiene más de una semana. Volver a subir el archivo del día corrige el dato, no lo duplica.
Un SKU del marketplace que no exista en tu catálogo no cuenta. Queda apartado en su propia lista y el cálculo asume cero en el fulfillment, diciéndolo en el renglón en lugar de callarlo.
No sabe de las restricciones del canal: topes de envío, categorías bloqueadas, cupo del CEDIS. Sugiere; validar contra las reglas del marketplace sigue siendo tuyo.
Un lanzamiento sin historia de venta no se puede proyectar. Para ésos hay que capturar a mano las piezas diarias que se esperan; el módulo lo permite, pero el número lo pones tú.
Qué cambia
La pregunta semanal deja de contestarse de memoria. Y sobre todo, deja de contestarse con una sola cifra: se ve al mismo tiempo cuánto convendría mandar, cuánto se puede mandar hoy y cuánto hay que comprar para poder mandarlo — que son tres decisiones distintas y hasta ahora venían revueltas.
Cada corrida guarda los parámetros con los que se calculó, así que dos meses después la pregunta «¿por qué mandamos 40 piezas de esto?» tiene respuesta en el mismo registro.
Incluye
- Calcula el sugerido de envío por SKU cruzando venta del canal, inventario en el fulfillment, disponible propio y entrante
- Mide la demanda con un promedio ponderado de dos ventanas, para no sobrerreaccionar a una semana atípica
- Entrega tres cifras por producto: el ideal, lo enviable hoy y lo enviable contando lo que viene en camino
- Deja el faltante en su propia columna: es la compra o la producción que hace falta, ya calculada
- Toma como disponible sólo el stock no reservado, sin quitárselo a pedidos que ya lo tienen apartado
- Cuenta como entrante sólo lo que llega de proveedor o producción, no los traspasos entre almacenes propios
- Clasifica cada SKU con semáforo —agotado, urgente, reabastecer, sano o sobrestock— y explica el porqué renglón por renglón
- Un canal por fulfillment, con su cobertura, su lead time, su múltiplo de empaque y su envío mínimo
- Excepciones por producto para el descontinuado, el voluminoso y el lanzamiento sin historia de venta
- Congela los parámetros en cada corrida, así que meses después se puede explicar por qué se mandó lo que se mandó
Requisitos
- Módulos de Inventario y Ventas activos
- Que las ventas del marketplace lleguen a Odoo con su equipo de ventas: es lo que hace Odoo Marketplugin. El módulo no lo exige técnicamente, pero sin la venta del canal en Odoo no hay demanda que medir
- Un equipo de ventas por cada canal de fulfillment
- El reporte de inventario del marketplace, para subirlo con la misma frecuencia con que se decida embarcar
- Los SKU del marketplace empatados con el código del producto en Odoo
- Decidir la política de inventario del canal: cuántos días de cobertura se buscan y cuánto tarda un embarque en quedar disponible
También te puede servir
Citas de embarque a Full
Que la cita no se caiga por algo que ya se sabía
Inventario y almacén
Contenedores
Sabes lo que te costó cada pieza antes de que el barco atraque
Inventario y almacén
Recompra
En qué mes te quedas sin producto, y cuánto pedir para que no pase
Inventario y almacén