Inventario omnicanal: cuándo un artículo debe estar disponible para vender

Qué significa "disponible para vender"

La existencia en sistema y la disponibilidad para vender no son lo mismo. La primera es un número en una tabla; la segunda es una promesa hacia un cliente. Un artículo puede existir y no estar disponible porque está apartado para un pedido, en un exhibidor que no se vende, en tránsito, en revisión de calidad o en una ubicación que nadie puede surtir en tiempo útil.

Una fórmula razonable de partida, que cada operación debe ajustar, descompone el disponible por ubicación: existencia confirmada menos reservas activas menos un colchón de seguridad. El colchón existe porque el dato tiene incertidumbre: si el sistema dice que hay dos piezas y existe una probabilidad no menor de que alguna no esté, prometer ambas es arriesgado. Qué tan grande debe ser el colchón no puede deducirse de un artículo de blog; se calibra con la historia de cancelaciones y diferencias de cada categoría.

Lo importante es que el cálculo sea explícito y lo conozcan quienes consumen el dato: marketplace, sitio propio, atención a clientes y tiendas.

Reservas: cuándo nacen, cuándo mueren

La reserva es la pieza que más errores produce. Una pieza se reserva cuando el cliente confirma, pero algunos sistemas la reservan al agregarla al carrito, lo cual agota artificialmente un artículo. Otros reservan al pagar, con el riesgo de vender dos veces un último ejemplar. No hay una opción correcta universal; hay compromisos entre tasa de conversión y tasa de cancelación.

Cada reserva debe tener tres atributos: de dónde se aparta (tienda o almacén concreto), cuánto dura y qué evento la libera. Si no hay caducidad de reserva, los pedidos abandonados dejan piezas "atrapadas" que ningún canal puede vender. Si la caducidad es demasiado corta, el cliente pierde su pieza durante el pago.

• Origen de la reserva: ubicación específica.
• Duración y evento de liberación definidos.
• Registro de quién la creó (canal o proceso).
• Regla para convertir la reserva en salida física cuando se surte.

Frescura del dato y tolerancia a información vieja

La frescura es la antigüedad del último evento que confirmó la existencia. Un artículo contado esta mañana y sin ventas desde entonces tiene un dato más confiable que uno que no se toca hace meses, aunque ambos digan "1". Registrar esa antigüedad permite aplicar reglas distintas: mostrar "últimas piezas" solo cuando la confirmación es reciente o pedir verificación antes de prometer retiro en tienda cuando es antigua.

El modelo de eventos de GS1 EPCIS registra el "cuándo" y el "dónde" de cada observación, lo que facilita calcular esa antigüedad si los eventos se almacenan con su sello de tiempo. Si su sistema solo conserva el saldo actual y no la fecha de la última observación, será difícil aplicar reglas de frescura.

La información vieja no se elimina; se gestiona. Se puede degradar la prioridad de una tienda como origen de surtido cuando su dato es antiguo, o exigir una verificación rápida antes de asignarle un pedido.

Umbrales por tipo de artículo

No todos los artículos necesitan la misma política. Un producto de alta rotación y bajo valor tolera un colchón pequeño y verificaciones raras; uno de alto valor, de pocas piezas o difícil de reponer pide más cautela. La tabla siguiente es un marco de decisión, sin valores numéricos, para que cada operación asigne los propios.

El uso de GTIN por presentación es clave: una política por variante solo funciona si cada variante tiene su propio identificador y el maestro no los mezcla.

Qué hacer cuando la promesa falla

Aun con buenas reglas habrá pedidos que no se pueden surtir. Lo que distingue a una operación madura es cómo responde: notifica rápido, ofrece alternativas honestas (otra tienda, otra variante, reembolso) y registra la causa de la falla. Ese registro es la mejor materia prima para ajustar umbrales, porque conecta cada cancelación con la tienda, el artículo y la antigüedad del dato.

Conviene definir quién decide una sustitución y cómo se informa al cliente; ese tema se profundiza en la guía sobre captura para click & collect. Mientras tanto, evite reintentar automáticamente el mismo origen sin cambiar el criterio: si una tienda falló dos veces con un artículo, probablemente el dato está mal y debe verificarse físicamente antes de volver a asignarle pedidos.

Integración y captura: lo que tiene que viajar

El motor de disponibilidad depende de datos que alguien capturó. Si las terminales de tienda envían movimientos por lotes cada noche, la información puede quedar desactualizada durante gran parte del intervalo entre envíos. Si ciertos eventos, como una devolución o un daño, se registran en otra aplicación, el disponible será erróneo aunque el motor sea correcto. Antes de comprar un módulo omnicanal, revise de qué sistema sale cada evento y con qué retraso.

En terminales Android de Zebra, el middleware DataWedge puede entregar datos de código de barras a una aplicación y, según la versión, analizar elementos GS1 en la salida por intent; los campos concretos disponibles deben confirmarse en la versión instalada; la documentación de DataWedge advierte que las funciones varían con la versión, por lo que la prueba debe hacerse con la versión instalada en sus equipos.

Por último, GS1 Digital Link describe cómo los códigos 2D podrán llevar identificador y atributos en un solo símbolo; en retail esa transición es un tema de mediano plazo que conviene vigilar al elegir escáneres.

Siguiente paso

Escriba en una página las reglas actuales de disponibilidad: cómo se calcula, cuándo nace y vence una reserva, qué colchón se aplica y cuándo se considera viejo un dato. Casi siempre aparecen inconsistencias entre canales. Resuélvalas antes de pensar en nueva tecnología. Si necesita evaluar equipos de captura para tienda, puede contactar a ARKCOM en garkcom.com/contact.

¿Se debe mostrar la cantidad exacta al cliente?

Depende de la confianza en el dato. Con datos poco frescos suele ser más prudente mostrar solo "disponible" o "pocas piezas" que una cifra exacta.

¿El colchón de seguridad reduce ventas?

Puede, porque oculta piezas que quizás sí existen. Es un intercambio entre ventas potenciales y cancelaciones, y se calibra con datos propios.