Conectar e-commerce y almacén: cómo evitar existencias incoherentes

El problema no nace cuando los dos sistemas se comunican: nace cuando dicen números distintos y nadie ha decidido de antemano a cuál se le cree. Vender una pieza que no existe cuesta un reembolso, una disculpa y a veces un cliente; tener bloqueada una que sí existe cuesta una venta que nadie contabiliza. Conectar la tienda online y el almacén significa, sobre todo, establecer quién manda, y qué pasa cuando algo sale mal.

La parte técnica es la más sencilla. Las decisiones difíciles son comerciales, y hay que tomarlas antes de la conexión: después se convierten en parches.

Existencias y disponibilidad vendible no son el mismo número

La confusión más costosa es entre cuántas piezas hay en el almacén y cuántas se pueden vender ahora mismo. Entre las dos está todo lo que ya está prometido a alguien.

• Existencia física: lo que se cuenta en las estanterías, incluidas las devoluciones aún no recolocadas.
• Comprometido: piezas de pedidos aceptados y todavía no enviados, incluidas las ventas hechas en tienda, por teléfono y por los representantes.
• En camino: mercancía pedida al proveedor, con una fecha que es una previsión y no un hecho.
• Reservado: stock de seguridad, muestrario, piezas defectuosas a la espera de verificación, material destinado a un cliente concreto.

La disponibilidad vendible online es lo que queda. Si el número publicado es la existencia física, estás vendiendo también lo que ya es de otra persona.

Una única fuente oficial, decidida antes de la conexión

Cuando los dos sistemas divergen, uno de los dos debe tener razón por regla y no por discusión. Las tres configuraciones posibles, con el caso en el que cada una funciona.

Las soluciones en las que los dos sistemas pueden modificar la disponibilidad del mismo código generan las incoherencias más difíciles de reconstruir: dos verdades y ningún árbitro.

La última pieza: la secuencia que lo rompe todo

El caso que hay que diseñar no es la venta normal, es la simultánea. Secuencia ilustrativa, con una sola pieza disponible.

1. A las 10:31 un cliente online pone la pieza en el carrito. Si el carrito no reserva nada, la pieza sigue siendo vendible para cualquiera.
2. A las 10:32 el titular vende la misma pieza en la tienda y la da de baja en el sistema de gestión.
3. A las 10:33 el cliente online paga. La tienda acepta el pedido porque su copia de la disponibilidad está parada en el valor anterior.
4. A las 10:35 la sincronización alinea los números y la disponibilidad baja de cero. La pieza es una, los pedidos son dos.
5. A las 10:36 alguien tiene que darse cuenta. Si no existe un aviso, se dará cuenta el encargado del almacén al preparar el pedido, o el cliente cuando no reciba nada.

Las tres palancas que reducen el caso: reservar la disponibilidad en el pago y no en el envío, acortar el intervalo de sincronización en los códigos con pocas existencias, y decidir de antemano quién tiene prioridad cuando ocurre lo mismo. Ninguna de las tres lo elimina: la simultaneidad es un hecho, no un defecto que corregir.

Cuando la sincronización falla, y tarde o temprano falla

Una conexión entre dos sistemas se interrumpe: mantenimientos, credenciales caducadas, un código modificado, una red que se cae. La pregunta no es si va a ocurrir, sino qué pasa mientras tanto.

• Los cambios no entregados quedan en cola y se retoman en orden cuando la conexión vuelve, en vez de perderse.
• Un cambio repetido dos veces no debe restar dos veces. Se transmite el valor resultante en vez de la diferencia, o bien cada movimiento lleva un identificador que impide que se aplique dos veces.
• Si la sincronización lleva parada un tiempo determinado, alguien recibe un aviso. Una conexión rota en silencio es peor que una ausente, porque los números siguen pareciendo válidos.
• Una conciliación periódica compara los dos sistemas código por código y produce una lista de diferencias que revisar, no una corrección automática que esconde la causa.

Colchón de seguridad o venta hasta cero: es una decisión comercial

Mantener unas cuantas piezas no vendibles online reduce las anulaciones pero inmoviliza mercancía; vender hasta la última pieza aprovecha todo el almacén y aumenta las excepciones. No existe una respuesta técnica: depende de cuánto te cuesten a ti las dos cosas.

• Un colchón tiene sentido en los códigos que se venden en varios canales y rotan deprisa.
• En los códigos lentos y de alto valor, un colchón es dinero parado: mejor vender hasta cero y gestionar la excepción cuando ocurra.
• Para los productos bajo pedido, la disponibilidad no es el dato correcto: la promesa es un plazo de entrega y hay que escribirla como tal.
• El inventario nunca coincide perfectamente con el sistema, por roturas, faltantes y errores de ubicación: también eso lo absorbe el colchón.

Los pedidos límite que probar antes de abrir

Antes de conectar la tienda al público se prueban los casos que nunca ocurren durante una demostración, con mercancía real y personas reales.

1. Venta simultánea de la última pieza en dos canales, con la sincronización activa.
2. Pedido anulado por el cliente y pedido anulado por ti: la pieza vuelve a estar vendible, y se comprueba en cuánto tiempo.
3. Devolución recibida: la pieza vuelve a entrar como vendible, como pendiente de verificar o como descarte, y se establece quién lo decide.
4. Producto con variantes de talla, color o formato: la disponibilidad se gestiona por variante, no por producto padre.
5. Kits y productos compuestos: qué pasa con el kit cuando se agota uno de los componentes.
6. Conexión interrumpida durante una hora en horario de ventas y luego restablecida: ningún movimiento perdido, ninguno aplicado dos veces.
7. Código nuevo creado en el sistema de gestión: cuándo aparece online y con qué datos mínimos.

Lo que esta guía no cubre

Aquí se habla de la coherencia de la disponibilidad entre sistemas. Cómo está organizado físicamente el almacén, con ubicaciones, movimientos e inventarios, es un problema distinto y a veces es la verdadera causa de los números equivocados. Las verificaciones que hay que hacer antes de prometer una integración entre dos programas, cuando uno de los dos no se pensó para conectarse, también se tratan aparte.