Picking por Olas
Un almacén de acero, operado desde una tableta.
Una aplicación hecha a la medida para el CEDIS de Ventacero: reparte el trabajo del almacén en olas por zona, las surte desde una tableta a pleno sol, y deja cada kilo, cada pieza y cada firma registrados en Odoo sin que nadie teclee dos veces.
El problema
Un pedido de acero no se surte en un solo lugar
En el CEDIS de Ventacero un mismo pedido se arma con material que vive en tres zonas distintas: los atados completos están en General, los sobrantes en las posiciones de Picking, y la tornillería en Ferretería. Cada zona tiene su gente, su equipo y su ritmo.
Antes, el pedido viajaba completo de un lado a otro y el avance vivía en papel. No había forma de saber quién había bajado qué, ni cuánto tardó, ni por qué faltaba material.
La aplicación parte cada pedido en olas: una por zona, con su propio responsable. El montacarguista abre su ola en la tableta, captura en piezas o en kilos —lo que tenga sentido para ese fierro—, y el sistema convierte, valida contra el inventario y cierra el traslado en Odoo.
Lo que antes era una libreta ahora es un registro: quién, cuándo, cuánto y desde qué posición.
Funcional
Cinco roles, un solo usuario de Odoo
Los operadores comparten una tableta y una sesión de Odoo. La identidad real de la app es el empleado, y la credencial es su PIN, que el servidor verifica en cada operación sensible. Ningún permiso depende de en qué botón alcanzó a picar alguien.
| Puede | Picking | General | Ferretería | Aprobador | Supervisor |
|---|---|---|---|---|---|
| Surtir sus olas | Sí | Sí | Sí | Sí | Sí |
| Ver todas las olas y asignarlas | — | — | — | Sí | Sí |
| Aprobar o rechazar un lote | — | — | — | Sí | Sí |
| Crear reabastecimientos | — | Sí | — | Sí | Sí |
| Administrar operadores y PIN | — | — | — | — | Sí |
| Cancelar lotes y empaques | — | — | — | — | Sí |
Cada rol pinta la aplicación de su color durante toda la sesión —azul para Picking, índigo para General, ámbar para Ferretería, verde para el aprobador y morado para el supervisor—, de modo que nadie se confunde de tableta a media jornada.
Funcional
El día de un montacarguista, pantalla por pantalla
Todo lo que sigue son pantallas reales de la aplicación, con su hoja de estilo y su marcado de producción; solo los nombres y los clientes son de ejemplo.
1. El tablero: qué hay que surtir hoy
Al entrar, cada quien ve sus olas agrupadas por flujo y por zona. La tarjeta dice de un vistazo lo que importa a diez metros de distancia: el número de lote, si es prioritario, qué zona, cuántas líneas van, cuánto pesa y desde cuándo corre el cronómetro.
Tablero de un supervisor: pestañas por estado, olas agrupadas, y la barra superior con Reabastecer, Seleccionar y el cambio a modo oscuro.
2. La ola abierta: capturar lo que de verdad se bajó
Dentro del lote, cada renglón trae la posición de donde se toma el material, el pedido al que pertenece y la cantidad. El operador captura en piezas o en kilos, y la app convierte con el peso real de cada pieza. Si hay menos material del que pide la demanda, lo dice antes de que alguien camine en balde.
Las etiquetas P1, P2… sustituyen a la orden larga: el mismo material puede ir en varios pedidos, y el color del canto los separa sin leer un solo número.
3. Reabastecer una posición, sin salir de la app
Cuando una posición de Picking se vacía, el operador de General —o un aprobador, o el supervisor— arma la lista de productos y la app crea el traslado. Se busca por producto o por posición, y la cantidad se decide al surtir, no antes.
Solo aparecen productos que se manejan en atados y que tienen piezas completas disponibles en General. El sistema nunca deja mover material que no existe.
4. Los empaques, agrupados por unidad
El empaque es el paso previo al embarque. La aplicación lo agrupa por la unidad de la flotilla que se lo va a llevar, que es como se carga en el andén, y muestra el avance de las olas que lo alimentan.
La unidad se captura una sola vez en la orden de entrega y viaja sola hasta el empaque; la placa es lo que se lee de lejos, el modelo completo queda en el detalle.
5. Administración: operadores, PIN y permisos
El supervisor administra a su gente desde la misma tableta: cambia el tipo de operador, pone o quita PIN y nombra aprobadores, sin pedirle nada a sistemas. Cada cambio queda firmado con su nombre en el historial del empleado.
La pantalla pide el PIN del supervisor antes de abrirse, y lo vuelve a mandar al servidor en cada cambio: la tableta nunca decide sola quién tiene permiso.
Funcional
De la orden de venta al embarque
- Se confirma el pedidoOdoo genera la cadena de tres pasos: recolección, empaque y entrega.
- El Enrutador reparte por zonaCada línea se manda a General, a Picking o a Ferretería según la categoría del producto, su empaque en atados y la regla del 70 %: los atados completos salen de General y el sobrante de su posición en Picking.
- El Fragmentador arma las olasAgrupa por flujo y zona, respeta el límite de 2,000 kg por carrito y un máximo de clientes por ola, y crea un lote por grupo.
- El operador surte desde la tabletaCaptura piezas o kilos, el cronómetro corre desde el primer pickeo y la app guarda cada renglón conforme avanza.
- AprobaciónAl validar, el lote queda pendiente. Un aprobador o el supervisor lo resuelve con su PIN; su nombre y la hora quedan en el registro.
- Empaque y embarqueEl empaque sincroniza las cantidades realmente surtidas y se valida en un solo paso, agrupado por la unidad que lo transporta.
Trazabilidad real: el cronómetro de cada ola arranca con el primer pickeo y se detiene al validar, no cuando alguien se acuerda de apuntarlo. Los reportes salen de ahí.
Técnico
Cómo está hecha
No hay un módulo instalado ni un servidor aparte. La aplicación vive dentro de Odoo: es una vista QWeb publicada como página del sitio web, que habla con el ERP por JSON-RPC con la sesión del propio usuario. Eso la hace desplegable en minutos y sin reinicios, y la mantiene del lado correcto de los permisos de Odoo.
Odoo 18 Enterprise
Inventario, Ventas y RR. HH. estándar. Sin módulos a medida que compliquen la próxima actualización.
Vista QWeb website.picking_olas_app
Una sola vista servida en /olas: HTML, CSS y JavaScript propios, sin
dependencias externas salvo Font Awesome.
JSON-RPC
La tableta llama a search_read, write y a acciones de servidor
con la sesión del usuario; nada se expone fuera de Odoo.
Acciones de servidor
La lógica que no debe vivir en el cliente —permisos, reglas de negocio, cálculos de inventario— corre en Python dentro del ERP.
Las piezas del lado del servidor
| Acción | Qué hace | Quién puede |
|---|---|---|
| Enrutador | Decide la zona de cada movimiento y parte la línea entre atados completos y sobrante. | Automático, al crear o escribir el movimiento |
| Fragmentador de Olas | Agrupa los albaranes por flujo y zona, respeta peso y clientes por ola, y crea los lotes. | Manual, desde la lista de albaranes |
| Crear Reabastecimiento Manual | Valida que el producto se maneje en atados y que haya piezas completas en General; crea el traslado y reserva. | General, aprobador, supervisor |
| Solicitar / Resolver Aprobación | Deja el lote pendiente al validar y lo resuelve verificando el PIN del aprobador. | Aprobador, supervisor |
| Cambiar Tipo de Operador / PIN | Administra roles y credenciales desde la app, con registro en el historial del empleado. | Supervisor |
| Cancelar Lote o Empaque | Cancela uno o varios registros con motivo obligatorio, hasta 50 por llamada. | Supervisor |
Dos decisiones que vale la pena contar
La identidad es el empleado, no el usuario de Odoo. Como la tableta se comparte, un permiso basado en grupos no distingue al supervisor del montacarguista. Toda operación sensible manda el PIN y el servidor lo verifica contra el expediente del empleado; un PIN que no coincide no se guarda ni para el siguiente intento.
if sol.x_studio_tipo_operador != 'supervisor':
return (False, 'Solo un supervisor puede hacer esto.')
if not (sol.pin or '').strip():
return (False, 'Define tu PIN para poder administrar.')
if pin_val != (sol.pin or '').strip():
return (False, 'PIN incorrecto.')
Las acciones se buscan por nombre, no por id. Cuando se regeneró la base de pruebas, los identificadores cambiaron y un id quedó apuntando a una acción de otro módulo. Hoy la app resuelve cada acción por su nombre y, si no la encuentra, lo dice en lugar de llamar a ciegas a lo que sea que ocupe ese número.
Técnico
Cómo se evita romperla
La aplicación es un solo archivo grande que vive dentro de una base de datos en producción. Eso exige disciplina: cada cambio se construye con un parche reproducible, pasa por seis compuertas automáticas y luego por los arneses que ejercitan el código real antes de escribir una sola línea en Odoo.
1. El XML abre
La vista se parsea antes de intentar guardarla.
2. No se perdió ninguna función
Se comparan las funciones antes y después; una baja tiene que declararse a propósito.
3. Sin variables de color huérfanas
Toda variable CSS usada existe en los dos temas, claro y oscuro.
4. Iconos que existen
Cada icono se busca en Font Awesome 4.7: un nombre de la versión 5 se pinta en blanco.
5. El JavaScript compila
node --check sobre el código tal como quedará guardado.
6. Las funciones son alcanzables
Se ejecuta la app en una máquina virtual y se comprueba que cada función clave exista de verdad.
Arneses: probar el código real, no una maqueta
Quince arneses cargan la aplicación completa en una vm, le cambian el servidor por un doble que imita a Odoo —incluidas sus negativas— y ejercitan las funciones reales. Cuando un operador reporta algo, lo primero es escribir el arnés que reproduce la falla contra la versión desplegada; solo después se corrige.
Un ejemplo medido: validar un empaque hacía sesenta viajes al servidor, uno por línea, en fila. Con treinta líneas eran 64 segundos con el botón en “Validando…”. Reagrupadas en cuatro lecturas y escrituras en paralelo: 1.8 segundos. La medición está en el arnés, no en la intuición.
Operación
Entrega y mantenimiento
Dos ambientes, una sola verdad
Todo se construye y se prueba en la base de pruebas, con datos reales de inventario. Solo cuando el cliente lo valida se escribe en producción, con respaldo de la versión anterior y lectura de verificación después de cada escritura.
Las dos bases sirven exactamente el mismo archivo; las diferencias de identificadores entre ambientes se resuelven por nombre.
Bitácora del desarrollo
Cada entrega queda documentada en un registro técnico con el reporte original, la causa encontrada, la corrección, cómo se verificó y qué quedó pendiente. Hoy suma más de ochenta entradas y es lo que permite retomar el trabajo meses después sin arqueología.
Desarrollado por CODEVIA para Ventacero · Odoo 18 Enterprise
Las pantallas de esta página son el render real de la aplicación; los nombres de personas, clientes y sucursales son de ejemplo.