Por qué el stock publicado nunca coincide con el real
Vendiste algo que no tenías. Ahora alguien tiene que llamar al cliente, pedirle disculpas y ofrecerle otra cosa o devolverle la plata. Pasa en todos lados, y casi siempre se diagnostica como un descuido de quien carga los datos. No lo es: es un problema de arquitectura, y por eso no se arregla pidiendo más cuidado.
La causa real: nadie es dueño de la verdad
Una PyME que vende por varios canales termina con el stock escrito en varios lugares a la vez: el ERP, la tienda propia, el marketplace donde también publica, y muy probablemente una planilla que alguien actualiza los lunes.
Mientras cada uno de esos lugares pueda modificar el número, el sistema está roto por diseño. No importa con cuánta frecuencia sincronices: si dos sistemas pueden escribir la misma cifra, en algún momento van a escribir cosas distintas, y nadie va a poder decir cuál de las dos es la correcta.
La primera decisión, entonces, no es técnica: hay que elegir un único dueño del stock — normalmente el ERP, que es donde impacta la compra y la producción — y degradar a todos los demás a lectores. El canal de venta muestra lo que el ERP dice. No opina.
La ventana que nadie mira
Supongamos que ya elegiste dueño y sincronizás cada quince minutos. Seguís teniendo el problema, más chico pero vivo: entre una sincronización y la siguiente, el número publicado es una mentira.
Si te queda una unidad y en esos quince minutos entran dos pedidos, vendiste dos. El sistema hizo exactamente lo que le pediste. La sincronización periódica no resuelve la concurrencia: la disimula.
Hay dos formas de atacarlo, y conviene usar las dos. La primera es reservar el stock en el momento en que se confirma el pedido, no cuando llega la sincronización. La segunda es publicar menos de lo que tenés: dejar un colchón en los artículos de alta rotación. Es menos sofisticado y resuelve la mayor parte de los casos reales.
El problema de fondo: los códigos no son los mismos
Acá es donde la mayoría de las integraciones se rompen de verdad. En el ERP, el artículo es un modelo y el talle vive en la descripción. En el canal de venta, cada variante es una publicación independiente con su propio código. Y en la planilla alguien lo escribió con guion, o con un espacio de más.
Cuando llega un pedido, el sistema tiene que decidir a qué artículo del ERP corresponde. Si esa correspondencia se resuelve por aproximación —y en algún punto siempre hay que aproximar— la pregunta importante es qué hace el sistema cuando no está seguro.
Si una coincidencia es dudosa, la respuesta correcta no es elegir la más probable. Es frenar y preguntar.
Un descuento mal aplicado se nota al cerrar el mes. Un talle mal asignado se nota cuando el cliente abre la caja, tres días después, y ya se despacharon otros doscientos pedidos con el mismo criterio equivocado. Por eso, en el sistema que opero, el control cruzado que compara el ERP con los canales frena ante una discrepancia de talle o color y pide confirmación humana en vez de resolverla solo. Es más lento y es lo correcto.
Lo que cuesta de verdad
El costo visible es la venta caída. El invisible, que es bastante más grande, tiene tres partes.
Está el tiempo de la persona que resuelve cada caso a mano, que es trabajo puro de reparación y no produce nada. Está la reputación en el canal de venta, que en los marketplaces grandes se traduce directamente en menos exposición: cancelar pedidos te hunde en el ranking, y recuperarlo lleva meses. Y está lo peor, que es el efecto sobre las decisiones: cuando nadie confía del todo en el número de stock, se empieza a comprar por sensación y a mantener inventario de más "por las dudas".
Ese inventario extra es capital inmovilizado que está pagando el precio de un problema de software.
Por dónde empezar si esto te está pasando
Primero, ponerle número al problema: cuántos pedidos por mes se caen por falta de stock. Suele ser un dato que nadie midió, y casi siempre es peor de lo que se cree.
Segundo, elegir el dueño del stock y sacarle a todos los demás la capacidad de editarlo. Esta sola decisión resuelve una parte grande de los casos y no requiere desarrollo: requiere acordar.
Tercero, recién ahí, automatizar la sincronización y la conciliación de códigos — con una regla explícita de qué hacer ante una coincidencia dudosa.
Invertir ese orden es el error más común. Se automatiza primero, sobre un modelo donde nadie es dueño de nada, y lo que se consigue es propagar el desorden más rápido.