El bug de inventario más común en distribución es el mismo, en toda empresa, sin importar tamaño: tratar lo reservado como si siguiera disponible. Es la raíz detrás de la sobreventa, de la desconfianza del almacén hacia el equipo comercial, de las llamadas frenéticas del sábado en la mañana cuando el conductor llega a recoger producto que no está.
La trampa de un solo campo
Si tu tabla de inventario tiene una columna — cantidad — solo puedes hacer una cosa: restar. Cuando se cierra una cotización, restas. Cuando se cancela, sumas de vuelta. Cualquier entrega concurrente envía el número equivocado.
La causa raíz es que un solo campo no puede distinguir entre inventario físicamente presente e inventario prometido. Ambos estados colapsan en el mismo entero. Funciona en un sistema de un solo usuario donde la persona que resta es la misma que sabe lo que está prometido. Se rompe en el momento en que dos personas tocan el sistema — y se rompe silenciosamente. Nada lanza un error cuando sobrevendes. El número simplemente se vuelve negativo, o peor, se mantiene positivo pero representa una promesa que no puedes cumplir.
Dos campos, una propiedad
Quotery usa dos campos — on_hand y reserved — con available = on_hand − reserved. Cerrar una cotización aumenta reserved; cancelar lo baja. Solo una nota de entrega posteada reduce on_hand. La cuenta cierra en cualquier escenario concurrente.
La separación es lo que lo hace seguro. on_hand responde '¿qué hay físicamente en el almacén?' reserved responde '¿qué está comprometido con una cotización cerrada?' available responde '¿qué puedo todavía prometerle al próximo cliente?' Cada campo tiene exactamente un escritor — on_hand cambia solo por documentos de fulfillment posteados; reserved cambia solo por transiciones de estado de la cotización. Ningún campo es tocado por dos flujos diferentes, así que no hay condición de carrera.
Este diseño también hace posible la sobre-reserva como elección deliberada. Cuando una cotización se cierra con inventario disponible insuficiente, reserved puede exceder on_hand — available se vuelve negativo, lo cual es una señal visible, no una falla silenciosa. El equipo comercial lo ve y actúa. La restricción se impone en la entrega, no en la cotización. Para más sobre esta decisión, consulta nuestro post sobre por qué la sobre-reserva es feature.
Ledger, no aritmética
Cada cambio se escribe como fila en StockMovement. Los números del ítem son caché; el ledger es la verdad. Reconstruir cualquier punto en el tiempo es un query, no una oración.
El ledger significa que puedes responder preguntas que los sistemas de un solo campo ni siquiera pueden hacer. ¿Cuál era el inventario disponible del SKU X el martes pasado a las 3pm? ¿Qué cotizaciones estaban reteniendo reservas contra este producto cuando llegó la recepción? Si el on_hand cacheado alguna vez diverge de la suma de las entradas del ledger, el ledger es el árbitro. Reconstruyes el caché desde el log — nunca editas el log para que coincida con el caché.