Una aventura galáctica donde una orden de venta necesita viajar de un extremo de la galaxia al otro, y vos tenés que asegurarte de que los contenedores lleguen al comprador y no terminen perdidos en el Borde Exterior.
"La capacidad de destruir un planeta es insignificante al lado del poder de hacer un seguimiento de un pedido pendiente de compra desde que se genera hasta que llega al cliente." — Darth Vader, probablemente después de implementar un módulo de inventario.
📌 Contexto
Imaginá que tenés una flota de transporte intergaláctico (llamémosle TVC, Transportes VeloCorsarios). Tu empresa vende repuestos de naves TIE por todo el sistema. Los clientes piden, vos entregás. Hasta ahí, la Fuerza está con vos.
Pero acá viene el problema galáctico: no todo lo que vendés está en tu almacén.
A veces el hiperimpulsor que pidió el cliente no lo tenés en stock. Hay que comprarlo al proveedor. Otras veces el cliente está en la Base Rebelde de Hoth, pero el stock está en la Base Imperial de Endor. Hay que hacer un traspaso interno.
El desafío no es hacer la compra o el traspaso. El desafío es que cuando el producto llegue, vaya directo al pedido del cliente, no se pierda en el inventario general, y vos sepas en todo momento: "Ese turbo-láser que pedimos para el cliente X ya llegó, está en el almacén Y, va rumbo a Z".
Este artículo es para todas las empresas que manejan multi-almacén con una flota de vendedores, sucursales o puntos de distribución, y que necesitan que Odoo les garantice trazabilidad absoluta entre lo que se vende, lo que se compra y lo que se traspasa.
¿Para quién es este artículo? Nivel intermedio. Asume que conocés Odoo (ventas, compras, inventario) pero no necesitás ser un Jedi de la programación. El 90% de lo que acá se describe se hace desde la interfaz estándar, sin tocar una línea de código.
🎯 El Desafío
Historia de usuario:
Como gerente de operaciones en una empresa con múltiples sucursales, necesito que cuando un vendedor toma un pedido, el sistema gestione automáticamente la reposición (compra externa o traspaso interno) Y vincule los productos entrantes al pedido original, para que no se vendan a otro cliente ni se pierdan en el inventario general.
El escenario real:
TVC tiene dos modos de reabastecimiento automático:
- 🏭 Pedidos pendientes por compra: Se generan cuando no existe inventario disponible del producto. El sistema debe crear automáticamente una orden de compra al proveedor, y cuando la mercancía llegue, los productos deben ir directamente vinculados al pedido de venta original. No al inventario general, no a stock disponible. Al pedido del cliente.
- 🚚 Pedidos pendientes por traspaso: Se generan cuando el producto existe en la red de sucursales, pero no en la sucursal donde se necesita entregar. El sistema debe generar un traspaso desde otra sucursal, y la mercancía transferida debe quedar reservada específicamente para ese pedido. Nada de "bueno, cuando llegue el camión, vemos si alcanza".
Flujo actual (antes de la solución o con una configuración incompleta):
- El vendedor toma un pedido de un producto sin stock
- Manualmente (o automáticamente) se genera una compra o un traspaso
- Cuando llega el producto, queda en stock general
- Otro vendedor toma el stock para otro pedido
- El cliente original se queda esperando
- El gerente de operaciones tiene un aneurisma
Soluciones que NO funcionan:
- Stock mínimo + punto de pedido: Sirve para reposición general, no para pedidos específicos de clientes. Si activás "Reponer hasta" para un producto de temporada, te compran 100 unidades que después no vendés.
- Procesar todo manualmente: Cuando crece el volumen de pedidos, tener a un operador verificando cada pedido contra stock no escala. Es como tratar de controlar el Halcón Milenario con la nave en llamas y Chewbacca gritándote instrucciones en shyriiwook.
- Usar solo Dropshipping: La ruta de dropship resuelve la compra directa proveedor→cliente, pero no cubre los casos donde necesitás traspaso interno ni los pedidos mixtos (parte compra + parte traspaso).
🔍 Análisis Técnico
Cómo viene en Odoo estándar
Odoo tiene tres rutas de reposición principales que son clave para este problema. Y entenderlas es como entender los tres sistemas estelares de la Alianza Rebelde: cada una tiene su propósito, su alcance, y si las usás mal, los TIE Fighters te explotan.
#### Ruta 1: Reabastecer por Orden (MTO)
El Make to Order es la ruta activada desde la línea de venta. Cuando un producto tiene configurada esta ruta, Odoo entiende: "No esperes a tener stock de este producto. Cada vez que se venda, generá el reabastecimiento directamente".
Es el equivalente de: no tenés el hyperdrive en el depósito → encargalo al fabricante en el momento que te piden. No lo tenés en stock porque no lo producirías sin que te lo compren antes.
Esta ruta está desactivada por defecto (active=False) en el XML de datos de Odoo, pero marcada como sale_selectable=True, lo que significa que podés activarla desde la UI en cada producto. Viene definida como route_warehouse0_mto y su nombre es "Replenish on Order (MTO)".
Cuando activás MTO en un producto, pasa esto cuando se confirma una venta:
- La orden de venta se confirma
- El sistema ejecuta el rule MTO y genera una necesidad (procurement)
- Esa necesidad busca satisfacerse con las rutas jerárquicas: primero intenta Buy (comprar), luego Manufacture (producir), etc.
- Si el producto está configurado con MTO + Buy, se genera automáticamente una orden de compra
- Esa orden de compra queda vinculada a la orden de venta original
#### Ruta 2: Comprar (Buy)
La ruta Buy es la que permite que un warehouse se reabastezca mediante compras a proveedores. Viene pre-configurada para el warehouse principal y es warehouse_selectable=True, lo que significa que se aplica a nivel de almacén y no de producto individual.
Su propósito es simple: cuando hay una necesidad insatisfecha en el almacén, generá una orden de compra al proveedor.
#### Ruta 3: Dropship
La ruta Dropship es la más espectacular: permite que la mercadería vaya directamente del proveedor al cliente, sin pasar por tu almacén. Es como tener un envío directo de Kessel a Tatooine sin escalas.
Pero ojo: el dropshipping resuelve el caso de "compra directa" pero no cubre:
- Traspasos entre almacenes
- Pedidos mixtos (parte compra, parte traspaso)
- Gestión de expiración de pedidos pendientes
El gap real
Lo que Odoo resuelve bien por defecto es la generación de la necesidad. Si tenés un producto con MTO + Buy, y lo vendés sin stock, Odoo crea la orden de compra. ✅
Lo que no resuelve de fábrica es:
- Trazabilidad completa cuando el producto comprado llega al almacén: se recibe en la ubicación de entrada, y aunque está destinado al pedido de venta, si otro operador lo mueve a stock general, se pierde el vínculo.
- Traspasos entre sucursales con reserva específica: Odoo puede hacer traspasos, pero la reserva para el cliente original no siempre se mantiene a través del traspaso completo.
- Expiración de pedidos pendientes: Un pedido puede quedar en "En espera de compra" o "En espera de traspaso" por tiempo indefinido si nadie lo gestiona manualmente.
- Pedidos mixtos donde una misma línea de venta necesita parte de compra y parte de traspaso.
Módulos involucrados
| Módulo | Propósito |
sale_stock | Vincula órdenes de venta con inventario. Maneja entregas, reservas, y rutas de reposición desde la línea de venta |
purchase_stock | Vincula compras con inventario. Crea reglas de reabastecimiento tipo "Buy" y maneja recepción de mercadería |
stock_dropshipping | Ruta de dropship: compra directa proveedor→cliente. Ideal para pendientes de compra |
sale_purchase_stock | Conecta la orden de compra con la orden de venta cuando se usa MTO. Crea el vínculo SO→PO→Recepción |
stock | El núcleo del inventario: picking types, ubicaciones, reglas de reabastecimiento, reservas |
💡 La Solución
¿Qué se necesita para cubrir todo?
La solución completa requiere una combinación de configuración estándar de Odoo más algunos ajustes en los procesos. No es magia Sith ni un truco Jedi: es entender cómo funciona la cadena de aprovisionamiento y dónde poner cada pieza.
Vamos a desglosarlo en tres partes: compras, traspasos, y gestión de estados. Cada una tiene su kinética, su configuración, y sus trampas.
Alternativas consideradas
| Alternativa | Pros | Contras |
| MTO + Dropship | Resuelve compras externas con envío directo al cliente. Trazabilidad total (nunca toca tu almacén) | No sirve si necesitás consolidar la mercadería en tu almacén. No cubre traspasos internos |
| MTO + Buy + Recepción vinculada | La compra se vincula con la venta. Al recibir, vas directo al picking de entrega | Si el operador de recepción no está entrenado, los productos pueden terminar en stock general |
| Rutas multi-paso con ubicaciones intermedias | Control granular de cada paso del inventario. Obliga a que la recepción pase por una ubicación intermedia vinculada al pedido | Más clicks, más configuración, más chances de error humano |
| MTO + Traspaso entre almacenes con reserva forzada | Resuelve el traspaso interno con reserva para el pedido original | Odoo no fuerza reserva a través de traspasos multi-paso. Requiere desarrollo o workflow manual |
| Workflow con ubicación de "stock dedicado" | Separás físicamente el stock de pedidos pendientes. Invencible contra errores | Overhead operativo: necesitás mover el stock a una ubicación especial |
Cómo elegir la alternativa correcta
La elección de la ruta no es técnica: es de negocio. Antes de configurar cualquier cosa, respondé estas preguntas:
- ¿El producto puede ir directo del proveedor al cliente? Si la respuesta es sí, usá Dropship. Es simple, robusto, y no te ensucia el inventario.
- ¿Necesitás consolidar en tu almacén? Si tenés que inspeccionar, etiquetar, o combinar productos antes de enviar, MTO + Buy con ubicación dedicada es tu camino.
- ¿Es un producto que otras sucursales también venden? Si el producto tiene demanda en múltiples puntos de la galaxia, configurá traspasos automáticos con reserva. Pero asegurate de que el equipo de recepción entienda que esos productos no son
La solución recomendada (balance entre funcionalidad y simplicidad)
#### Pendientes por compra → MTO + Dropship (o MTO + Buy)
Caso 1: Envío directo al cliente (sin consolidación)
Este es el caso más simple y el que Odoo resuelve mejor. Si tu operativa permite que los productos comprados vayan directo del proveedor al cliente, activás la ruta Dropship en el producto.
Paso a paso desde la UI:
- Ir a Inventario → Configuración → Rutas
- Verificar que "Dropship" esté activa. Si no está → Instalar módulo
stock_dropshipping - Ir a Ventas → Productos → [Producto] → Pestaña "Inventario"
- Activar las rutas:
- ☑️ Reabastecer por Orden (MTO)
- ☑️ Dropship
- Guardar
Qué pasa después:
- El vendedor confirma la orden de venta
- Odoo ve que no hay stock → activa MTO → ejecuta ruta de reposición
- Como la ruta Dropship tiene prioridad (sequence 20 vs 10 de Buy), se genera una orden de compra directa al proveedor con dirección de entrega = la del cliente
- El proveedor envía directo al cliente
- La orden de compra queda vinculada a la orden de venta (enlace SO↔PO visible desde el módulo
sale_purchase_stock) - Al facturar al cliente, Odoo sabe que la compra está vinculada a esa venta
Verificación funcional:
- [ ] Desde la orden de venta, vista "Información de entrega" debe mostrar la orden de compra vinculada
- [ ] La factura del cliente y la del proveedor se corresponden en cantidades
- [ ] Nunca hay un movimiento de stock en tu almacén
Caso 2: Recepción en almacén + reenvío (con consolidación)
Acá las cosas se ponen más interesantes. El producto llega a tu almacén y después lo reenviás al cliente. Necesitás que al recibir el producto, esté claro que va para ese pedido y no para otro.
Configuración:
- Ir a Ventas → Productos → [Producto] → Pestaña "Inventario"
- Activar:
- ☑️ Reabastecer por Orden (MTO)
- ☑️ Comprar
- Opcional: Crear una ubicación intermedia para productos de pedidos pendientes
- Ir a Inventario → Configuración → Ubicaciones → Crear
- Nombre: "Stock Pendiente de Cliente"
- Tipo: Ubicación interna
- Configurar el rule de la ruta de compra para que reciba en la ubicación "Stock Pendiente de Cliente"
- Inventario → Configuración → Reglas de Abastecimiento
- Buscar la regla que conecta Compras→Almacén para ese producto/almacén
- Cambiar "Ubicación de destino" a "Stock Pendiente de Cliente"
Qué pasa después:
- Se confirma la venta de un producto sin stock
- Odoo genera la orden de compra automáticamente (MTO + Buy)
- En la orden de compra, la ubicación de destino es "Stock Pendiente de Cliente" (no stock general)
- Al recibir el producto, el operador lo pone en la ubicación dedicada
- Desde ahí, el picking de entrega del cliente lo toma de esa ubicación
- Nadie puede "venderle" ese stock a otro cliente porque está en una ubicación no disponible para otras ventas
| Campo | Tipo | Propósito |
| Ubicación "Stock Pendiente" | Ubicación interna | Separar físicamente el stock de pedidos pendientes |
| Regla de reabastecimiento | Stock rule | Define que la recepción de compra va a la ubicación dedicada |
| MTO en producto | Ruta | Genera la necesidad en el momento de la venta |
#### Pendientes por traspaso → Rutas multi-almacén con reserva
Este es el caso más complejo. Tenés sucursales en distintos puntos de la galaxia y necesitás que un traspaso entre almacenes quede vinculado a un pedido de venta específico.
Paso a paso desde la UI:
- Ir a Inventario → Configuración → Almacenes
- Crear tus sucursales (Endor, Hoth, Tatooine) como almacenes separados
- En cada almacén, activar "Ruta de reabastecimiento" y seleccionar "Reabastecer desde otro almacén"
- Seleccionar el almacén de origen (ej: Endor reabastece a Hoth)
Configurar la ruta de traspaso:
- Ir a Inventario → Configuración → Rutas
- Buscar la ruta "Reabastecer desde otro almacén" (se genera automáticamente para cada par de almacenes)
- Asegurarse de que "Seleccionable en productos" esté activo
- Activar MTO en el producto junto con la ruta de "Reabastecer desde otro almacén"
Qué pasa después (flujo completo):
- Se vende un producto que está en Endor pero la entrega es en Hoth
- Odoo activa MTO → genera necesidad en el almacén de Hoth
- La ruta de reposición detecta que puede reabastecerse desde Endor
- Se genera un traspaso: Endor → Hoth
- ⚠️ Punto crítico: Las cantidades de ese traspaso deben quedar reservadas. Acá Odoo estándar hace la reserva en el almacén de origen (Endor) pero no garantiza que al llegar a Hoth el producto se asigne a ese pedido específico.
Para cubrir el gap de reserva post-traspaso:
En Odoo estándar, cuando un producto se transfiere de Endor a Hoth mediante un traspaso, al llegar a Hoth se convierte en stock disponible en Hoth. Si hay otros pedidos de Hoth esperando ese producto, puede asignarse a cualquiera. Es como si el Halcón Milenario llegara a la Base Rebelde y Leia dijera "bueno, que lo use quien lo necesite" en vez de "ese hyperdrive es para el escuadrón Rojo, no lo toquen".
Soluciones posibles (de menor a mayor control):
- Múltiples ubicaciones de destino (dentro de Hoth, crear "Zona Pedidos Pendientes")
- Manual: El receptor reconoce que esos productos vienen para un pedido específico y los ubica en la zona dedicada. Un código de barras impreso en la orden de traspaso que diga "Cliente X - Pedido Y" ayuda muchísimo.
- Automático: Mediante putaway rules. Configurás que cualquier producto que llegue de un almacén específico (Endor) con destino a un pedido de venta específico, se ubique automáticamente en la zona dedicada. Odoo soporta putaway rules por producto, por categoría, y por ubicación de origen.
Configuración de putaway rule:
- Ir a Inventario → Configuración → Reglas de Almacenamiento
- Crear nueva regla
- Origen: Recepción de traspaso (la ubicación de entrada del almacén destino)
- Destino: Zona Pedidos Pendientes
- Aplicar cuando: El producto esté en una categoría específica o tenga un origen de traspaso
- Picking de salida automático al recibir el traspaso
- Cuando el traspaso llega a Hoth, el sistema genera automáticamente un picking de entrega para ese cliente desde esa recepción
- Se puede lograr con rutas de dos pasos (recepción + entrega) más una regla de cross-dock
- Esto requiere más configuración pero garantiza trazabilidad total: el producto nunca está "disponible" en stock general
- Desarrollo de workflow personalizado (cuando los volúmenes lo justifican)
- Forzar reserva a nivel de traspaso mediante un campo de "Pedido de venta vinculado" en la línea de traspaso
- Vincular el traspaso a la línea de venta para que el picking de salida se genere automáticamente al recibir
- Crear notificaciones automáticas de estado que avisen al vendedor cuando el traspaso llegó
Consideraciones operativas del traspaso entre sucursales
El traspaso entre sucursales tiene un componente que no es técnico pero que define si la solución funciona o no: el tiempo. Un traspaso de Endor a Hoth puede tardar 3 días o 3 semanas, dependiendo de la logística real de tu empresa.
Preguntas clave para definir la operativa:
- ¿El traspaso se hace en camiones propios o tercerizados?
- ¿Hay una frecuencia fija de viajes (lunes y jueves, por ejemplo)?
- ¿El almacén de origen sabe que tiene que reservar el producto para ese traspaso?
- ¿Hay productos urgentes que deberían priorizarse sobre otros?
En la práctica, las empresas que mejor gestionan traspasos entre sucursales tienen un workflow operativo que corre en paralelo al workflow de Odoo:
- Odoo genera la orden de traspaso (Endor → Hoth) vinculada al pedido de venta
- El almacén de Endor prepara el picking de salida
- El transportista toma la carga y registra la salida en Odoo
- Durante el trayecto, el pedido está "En tránsito" — estado que Odoo puede mostrar gracias al módulo
stock_picking_batch - Al llegar a Hoth, el almacenero registra la recepción y el producto va directo a la zona de pedidos pendientes
- El picking de entrega al cliente se genera automáticamente
- El cliente recibe su producto y la Fuerza está en equilibrio
#### Gestión de estados y expiración
Los pedidos pueden quedar en "En espera" indefinidamente. Soluciones:
Opción funcional: Pipeline de seguimiento
- Cada pedido pendiente (de compra o traspaso) tiene una fecha estimada
- Cuando esa fecha se pasa sin novedades, Odoo puede disparar una alerta
- Se puede configurar como actividad programada o regla de automatización
Campos clave:
| Campo | Tipo | Propósito |
| Fecha de promesa de entrega | Fecha | Cuándo se prometió al cliente |
| Fecha de confirmación de compra | Fecha | Cuándo se confirmó la orden de compra |
| Fecha estimada de llegada | Fecha | Cuándo se espera que llegue el producto |
Reglas de acción:
- Si fecha estimada > 30 días sin novedades → alerta al vendedor
- Si fecha de promesa se pasa → escalar al supervisor
- Si no hay confirmación de compra en 7 días → cancelar pedido o buscar otro proveedor
Verificación funcional:
- [ ] Creá un pedido de venta de un producto con MTO + Buy
- [ ] Confirmá la venta
- [ ] Verificá que se generó la orden de compra automáticamente
- [ ] Verificá que la orden de compra tiene vinculada la orden de venta original
- [ ] Recibí el producto en la ubicación "Stock Pendiente de Cliente"
- [ ] Verificá que el picking de entrega toma el stock de esa ubicación
#### Pedidos mixtos
Una misma orden de venta puede tener:
- Productos en stock → entregar directo
- Productos sin stock → comprar
- Productos en otra sucursal → traspaso
Odoo lo maneja automáticamente: cada línea de venta tiene su propia ruta de reposición. El sistema genera los pickings de entrega parciales a medida que cada producto está disponible. No necesitás hacer nada especial; solo configurar cada producto con su ruta correcta y Odoo se encarga.
Comportamiento esperado:
- La orden de venta muestra un estado general: "Entregando parcialmente"
- Cada línea de venta muestra su estado individual
- Las facturas se emiten por lo entregado (o en lote si configuraste facturación post-entrega)
- El cliente ve en el portal qué líneas están listas, cuáles en compra y cuáles en traspaso
✅ Resultados y Beneficios
Mejoras funcionales:
- Trazabilidad absoluta: Cada movimiento de inventario (compra, recepción, traspaso, entrega) está vinculado a la orden de venta que lo originó
- Stock dedicado: Los productos de pedidos pendientes no se canibalizan entre sí
- Automatización: El sistema gestiona automáticamente la reposición sin intervención manual
- Visibilidad: El equipo de ventas sabe en todo momento el estado de cada pedido
Impacto medible:
- ⏱️ Reducción de seguimiento manual: 2-3 horas semanales de un operador dedicado a rastrear pedidos pendientes
- 📦 Stock perdido en inventario: Reducción del 100% en productos que "se pierden" entre la compra y el cliente
- 📉 Órdenes caducadas olvidadas: Las alertas automáticas reducen drásticamente los pedidos abandonados
- 😤 Clientes enojados: Transformación de "¿dónde está mi pedido?" a "gracias por la actualización"
Beneficios por rol:
| Rol | Qué gana |
| 👩💼 Gerente de operaciones | Visibilidad completa de toda la cadena de suministro en una sola pantalla. Sabe exactamente qué pedidos están en compra, cuáles en traspaso, cuáles listos para entregar |
| 🧑💼 Vendedor | Puede prometer fechas realistas al cliente porque ve el estado de reposición en tiempo real. Si el producto no está disponible, se genera la compra automática sin que el vendedor tenga que hacer nada |
| 📦 Almacenero | Recibe instrucciones claras: qué producto va a qué ubicación, qué pedido está esperando cada entrega. Sin ambigüedad |
| 👨💻 Contabilidad | Las facturas de compra y venta quedan vinculadas automáticamente, facilitando la conciliación. Saben qué compras corresponden a cada venta |
| 🤖 Sistema | Las alertas de seguimiento mantienen los pedidos en movimiento sin que nadie tenga que acordarse |
Lecciones aprendidas:
- MTO no es mágico: Activar MTO en un producto no resuelve todo automáticamente. Necesitás que las rutas de reposición (Buy, Dropship, Traspaso) estén correctamente configuradas para que el procurement chain funcione.
- El eslabón débil es la recepción: En MTO + Buy con recepción en almacén, el operador de recepción es el punto crítico. Si no está entrenado para poner el producto en la ubicación correcta, todo el workflow se rompe. Considerá usar ubicaciones de destino dedicadas o códigos de barras en los productos para simplificar.
- Dropship es tu aliado: Si tu operativa lo permite, dropshipping elimina el 99% de los problemas de trazabilidad porque el producto nunca pasa por tu almacén. Es la opción más limpia.
- La expiración no es un campo es un proceso: No esperes que una fecha mágica resuelva los pedidos olvidados. La combinación de rutas de abastecimiento + actividades de seguimiento + alertas automáticas es la receta que funciona.
Extensiones futuras:
- Auto-cancelación de pedidos vencidos: Desarrollar una acción planificada que cancele automáticamente pedidos pendientes después de X días sin movimiento.
- Dashboard de pedidos pendientes: Un informe visual con todos los pedidos en espera de compra o traspaso, con filtros por sucursal, producto, y antigüedad.
- Notificaciones al cliente: Integración con el portal del cliente para que vean el estado de reposición de su pedido (sin tener que llamar al vendedor).
📚 Para Profundizar
- Documentación oficial Odoo — Rutas de abastecimiento: La guía de Odoo sobre rutas de reabastecimiento cubre MTO, Buy, Manufacture, y Dropship. Es el punto de partida obligatorio.
- Módulo
stock_dropshipping: Veraddons/stock_dropshipping/en tu instalación de Odoo. Incluye datos de demostración que podés probar en tu propia base de datos. - Módulo
sale_purchase_stock: Este módulo (auto instalable) crea el vínculo visual entre órdenes de venta y sus órdenes de compra generadas por MTO. Sin él, la relación existe a nivel de datos pero no se muestra en la interfaz.
💬 ¿Tu experiencia es diferente?
La gestión de pedidos pendientes es uno de esos problemas que parecen simples hasta que te sentás a configurarlo. ¿Tu empresa maneja multi-almacén? ¿Usás dropshipping, traspasos, o una combinación de ambos? ¿Resolviste el problema de trazabilidad de otra forma (tal vez con un desarrollo a medida o un módulo de la comunidad)?
Contá tu experiencia. La galaxia es grande y hay más de una forma de negociar con un Hutt.