Importar lotes de terminal portátil en Odoo: diseña la importación antes del escáner
Importar lotes de terminal portátil en Odoo: diseña la importación antes del escáner
Integración Odoo

Importar lotes de terminal portátil en Odoo: diseña la importación antes del escáner

Un terminal que cuenta sin conexión es fácil de comprar y difícil de creer. La diferencia está en si la importación se diseña como una tubería de staging con idempotencia, tiempo y reglas de conflicto, o como un CSV que alguien sube el lunes.

12 min· By SpidersRFID Editorial Team

Los equipos de almacén compran terminales portátiles por una razón simple: el stock no está donde está la red. Las estanterías bloquean el Wi-Fi, las cámaras frigoríficas matan la cobertura y un patio de camiones no tiene señal. Así que el dispositivo cuenta sin conexión y sincroniza después, y ahí es exactamente donde se gana o se pierde la exactitud de inventario.

El dispositivo no es lo difícil. La importación lo es.

Por qué el lote es una decisión de diseño

La captura por lotes es un intercambio deliberado, y nombrarlo con honestidad mantiene el diseño cuerdo.

  • La captura offline garantiza que el conteo termine, a cambio de llegar tarde.
  • Los datos tardíos significan que el ERP ya avanzó: recepciones, ventas y transferencias ocurrieron entre el conteo y la subida.
  • Un lote no es una foto del ahora; es un conjunto de observaciones tomadas durante horas o días.
  • Por eso la importación debe llevar tiempo, y debe declarar su intención: fijar, sumar, restar o confirmar.
  • Los sistemas que lo ignoran producen conteos correctos en el pasillo e incorrectos en el libro mayor.

Tres formas de carga, tres comportamientos

Casi todos los fallos de importación vienen de mezclar las tres en un archivo y esperar que el importador adivine.

  • Un conteo es una afirmación absoluta: esta ubicación contiene esta cantidad de este artículo en este momento.
  • Un evento es un movimiento: una unidad pasó de A a B, se consumió o se recibió.
  • Un delta es un ajuste: suma o resta esta cantidad, porque el registro anterior estaba mal.
  • Conteos y deltas no pueden compartir regla de conflicto, porque uno reemplaza la verdad y el otro afirma un cambio.
  • Elige por proceso: el conteo cíclico admite conteos, la confirmación de picking admite eventos, las correcciones admiten deltas.

Aterriza todo en staging primero

La tabla de staging es el componente más valioso de la tubería, y suele ser el que se omite.

  • Escribe cada registro recibido en staging con su carga original, id de dispositivo, operador y hora del dispositivo.
  • Valida en staging, no en la entrada: un registro rechazado debe seguir siendo visible para diagnosticar.
  • Nunca dejes que el importador escriba stock directamente desde un archivo elegido por el usuario; el archivo es entrada, no autoridad.
  • Conserva las filas de staging con un estado tras el procesamiento, para que una disputa se rastree hasta el escaneo original.
  • Trata el staging como una bandeja de entrada: sin procesar, procesado, rechazado y resuelto a mano son estados distintos.

La idempotencia es la única defensa contra la repetición

Un terminal que reintenta tras una sincronización fallida enviará el mismo lote dos veces, y eso es normal.

  • Da a cada lote un identificador determinista construido con dispositivo, operador y ventana de tiempo.
  • Da a cada registro una clave que no cambie al reenviarse; un UUID aleatorio por intento arruina la idempotencia.
  • Guarda la clave aplicada en la base y rechaza duplicados con un estado claro, no con un error.
  • Prueba el camino de reintento a propósito: corta la sincronización a medias, reenvía y verifica que el stock no cambió.
  • Si la tubería no puede ser idempotente, convierte la importación en un paso de revisión manual en vez de una escritura automática.

Reglas de conflicto defendibles

Hay conflicto cuando el ERP cambió desde la observación, y cada regla debe ser explícita.

  • Compara la hora del dispositivo con el último movimiento de stock de ese producto y ubicación.
  • Si el ERP cambió antes de la observación, acepta el conteo, porque se midió después.
  • Si el ERP cambió después de la observación, márcalo; el conteo puede llevar horas de retraso.
  • Nunca elijas en silencio el valor mayor o menor; una regla de "gana el más conservador" esconde pérdidas reales.
  • Envía cada conflicto marcado a una cola corta de revisión con ambos valores y los movimientos que los causaron.

El tiempo es el campo que todos olvidan

Los relojes de los dispositivos derivan, las zonas horarias difieren, y un conteo sin marca de tiempo no se puede conciliar.

  • Guarda dos marcas: cuándo observó el dispositivo la etiqueta y cuándo la recibió el servidor.
  • Fuerza la sincronización de hora al inicio de cada sesión y rechaza registros con horas inverosímiles.
  • Mantén el reloj del dispositivo en UTC y convierte solo para mostrar; la hora local crea fallos dos veces al año.
  • Usa la hora de observación en la lógica de conflicto, y la de recepción solo para auditoría.
  • Un conteo que llega una semana tarde sigue siendo dato, pero no debe sobrescribir una semana de movimientos.

Valida antes de escribir

La corrección más barata ocurre antes de crear el movimiento de stock.

  • Comprueba que producto, ubicación y lote existan, y rechaza códigos desconocidos en lugar de crear artículos.
  • Comprueba las conversiones de unidad de medida de forma explícita; un desajuste caja-pieza es un error silencioso de cien veces.
  • Comprueba que el operador esté autorizado para esa ubicación, sobre todo en configuraciones multiempresa.
  • Comprueba la plausibilidad de la cantidad contra una banda configurada y manda los extremos a revisión en vez de bloquear.
  • Registra el resultado de validación por registro, para que la razón del rechazo llegue al operador.

Dile al terminal qué pasó

Una importación que solo informa un total es una importación que el equipo de campo dejará de usar.

  • Devuelve el estado por registro al dispositivo en la siguiente sincronización, con la clave de registro.
  • Distingue aceptado, aceptado con ajuste y rechazado, con una razón de una línea.
  • Deja que el operador corrija los registros rechazados en el dispositivo en lugar de reescribirlos en la oficina.
  • Muestra un resumen por sesión que el supervisor pueda leer sin abrir una hoja de cálculo.
  • Vigila la distribución de motivos de rechazo; un aumento de "ubicación desconocida" suele indicar un problema de mapeo.

Un informe de conciliación que finanzas aceptará

El conteo debe ser explicable, no solo correcto.

  • Informa la cantidad previa, la observada y el ajuste creado, línea por línea.
  • Atribuye cada ajuste a un dispositivo, operador, sesión y ventana temporal.
  • Separa los ajustes por error de conteo de los causados por movimientos no registrados.
  • Compara el valor de los ajustes con el valor del inventario del periodo, para que la deriva sea visible.
  • Guarda el informe de forma inmutable, porque un auditor lo pedirá meses después.

Orden de despliegue y qué probar primero

Secuencia el despliegue para que los fallos ocurran donde son baratos.

  • Empieza con una clase de ubicación y un modelo de dispositivo en modo sombra: importa a staging, compara, no escribas.
  • Luego habilita escrituras para una categoría de bajo valor y alta rotación.
  • Después amplía a un conteo cíclico completo, manteniendo el recuento manual como desempate.
  • Prueba pronto los casos feos: sin señal, batería agotada a media sesión, sincronización duplicada, zona horaria equivocada.
  • Publica un procedimiento de una página para el operador, porque la mayoría de "errores del sistema" son errores de secuencia.
Integración Odoo RFID — solución integral

Usamos cookies para mejorar su experiencia de navegación, analizar el tráfico del sitio y personalizar el contenido. Haga clic en “Aceptar todas” para aceptar todas las cookies, o elija “Solo necesarias”. Consulte nuestra Política de privacidad para más detalles.