Un software de gestión de stock a medida que sea fiable se apoya en cuatro decisiones de arquitectura: almacenes divididos en ubicaciones, artículos identificados por SKU con lote o número de serie cuando hace falta, un libro de movimientos del que se calcula el stock y reservas que separan lo físico de lo disponible. Es la base que usamos en cada software de gestión de stock a medida en Madrid que desarrollamos.
El síntoma que lleva a plantearlo siempre es el mismo: el sistema dice que hay unidades y la estantería dice otra cosa. Se vende lo que no existe, se compra lo que ya había y cada recuento acaba en un ajuste sin explicación. Casi siempre el origen está en un diseño que guarda la cantidad como un número que se sobrescribe, o en un Excel de inventario que varias personas editan a la vez.
Al terminar sabrás cómo modelar almacenes, ubicaciones y lotes, por qué el stock debe ser un libro de movimientos y cómo evitar que dos pedidos se lleven la última unidad, con un ejemplo en SQL probado y criterios para estimar los plazos reales de un proyecto así.
Qué es un software de gestión de stock a medida
Es la aplicación que registra cada entrada, salida y traslado de mercancía, sabe en qué almacén y ubicación está cada unidad y calcula en tiempo real cuánto puedes vender. A medida significa que el modelo se adapta a tu operativa, con lotes, caducidades o números de serie, sin los campos forzados de una herramienta genérica o low-code.
Suele formar parte de un sistema más amplio. Si estás valorando el conjunto, en el módulo de almacén dentro de un ERP propio explicamos cómo encaja con compras, ventas y facturación; aquí bajamos al detalle de la arquitectura del inventario.
El modelo de datos: almacenes, ubicaciones y artículos
Las entidades de base son pocas, pero cada una tiene que estar bien definida desde el principio, porque cambiarlas con datos reales es caro. Es el trabajo previo que hace cualquier estudio de software para almacenes en Madrid antes de diseñar pantallas:
- Almacén: cada nave o tienda con stock propio. Pertenece a una empresa y tiene sus reglas de entrada y salida.
- Ubicación: el hueco concreto dentro del almacén, por ejemplo pasillo, estantería y altura. Permite preparar pedidos por rutas y saber dónde buscar.
- Artículo y SKU: la referencia interna que identifica cada producto vendible, con su código de barras asociado.
- Unidad de medida: unidad, caja o palé, con su conversión. Se compra por cajas y se vende por unidades sin cálculos a mano.
- Lote y caducidad: agrupan unidades fabricadas juntas y permiten servir primero lo que caduca antes.
- Número de serie: identifica una unidad concreta, imprescindible en equipos con garantía o mantenimiento.
Lotes y trazabilidad
En alimentación la trazabilidad es una obligación legal. El artículo 18 del Reglamento (CE) 178/2002 exige poder identificar a quién te suministró cada producto y a qué empresas lo suministraste tú. Con un buen modelo, eso se traduce en una consulta: dado un lote, qué entradas lo trajeron y qué pedidos lo sacaron, algo que depende de cómo se diseña el backend y sus relaciones de datos.
Por qué el stock es un libro de movimientos
El error de diseño más común es guardar el stock como un campo «cantidad» que se actualiza con cada venta. Funciona hasta que algo falla: un proceso que se interrumpe a medias, dos usuarios que editan a la vez o un ajuste que nadie sabe explicar. El campo muestra un número, pero no cómo se llegó a él, y la única pista queda en el registro de auditoría del panel interno, si existe.
La alternativa es la misma que usa la contabilidad: un libro de apuntes en el que cada entrada, salida, traspaso o ajuste es una fila que no se modifica, y el stock es la suma de esos apuntes. Es el principio que Martin Fowler describe como Event Sourcing, registrar cada cambio como un evento, y en inventario encaja de forma natural. Cada apunte guarda su motivo y el documento que lo origina, como el albarán de compra, el pedido o el recuento.
Los errores se corrigen con un apunte de ajuste, nunca borrando. Y el arranque del sistema también es un apunte: el stock inicial se carga como entrada de apertura dentro de un plan de migración con conciliación de cantidades, para que el primer día el libro y la estantería coincidan.
Stock físico, reservado y disponible
Del libro de movimientos salen varias cifras distintas, y confundirlas es lo que provoca la sobreventa en el almacén y en la tienda online que vende sobre ese mismo stock:
- Físico: lo que hay en la estantería según los movimientos registrados.
- Reservado: lo comprometido con pedidos confirmados que todavía no han salido.
- Disponible: físico menos reservado. Es lo único que se puede prometer a un cliente.
- Pendiente de recibir: lo pedido a proveedores, útil para dar fechas de entrega, nunca para vender como si ya estuviera.
La reserva nace cuando se confirma el pedido y desaparece cuando sale la mercancía, momento en que se registra el movimiento de salida. Por eso el stock y la gestión de pedidos con reserva de stock en Madrid se diseñan juntos: los estados del pedido deciden cuándo se reserva y cuándo se descuenta.
Concurrencia: dos pedidos y la última unidad
Imagina que quedan 40 unidades de un artículo y entran a la vez dos pedidos de 30. Si cada proceso lee el disponible, comprueba que hay suficiente y después inserta su reserva, los dos ven 40 y los dos reservan. Es un problema clásico de concurrencia entre procesos que leen y escriben a la vez, y en una tienda online con picos de tráfico ocurre más de lo que parece.
La solución es que la comprobación y la reserva sean una única operación protegida. PostgreSQL ofrece para ello bloqueos de fila y bloqueos consultivos: la segunda transacción espera a que termine la primera y, al continuar, ya ve la reserva hecha.
CodeZone Pro Tip: calcula el stock desde un libro de movimientos y reserva con bloqueo para no vender por debajo de cero
-- Libro de movimientos: el stock nunca se edita, se calcula sumando apuntes
CREATE TABLE movimientos (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
sku text NOT NULL,
almacen text NOT NULL,
cantidad integer NOT NULL CHECK (cantidad <> 0), -- positivo entra, negativo sale
motivo text NOT NULL CHECK (motivo IN ('compra', 'envio', 'ajuste', 'traspaso', 'devolucion')),
referencia text NOT NULL, -- albarán, pedido o recuento que lo justifica
creado_en timestamptz NOT NULL DEFAULT now()
);
CREATE TABLE reservas (pedido text, sku text, almacen text, cantidad integer NOT NULL CHECK (cantidad > 0),
PRIMARY KEY (pedido, sku, almacen));
-- Físico, reservado y disponible por artículo y almacén, siempre derivados de los apuntes
CREATE VIEW stock_disponible AS
SELECT sku, almacen, sum(fisico) AS fisico, sum(reservado) AS reservado, sum(fisico) - sum(reservado) AS disponible
FROM (SELECT sku, almacen, cantidad AS fisico, 0 AS reservado FROM movimientos
UNION ALL SELECT sku, almacen, 0, cantidad FROM reservas) t
GROUP BY sku, almacen;
-- Reserva atómica: dos pedidos simultáneos del mismo artículo esperan turno y nunca venden por debajo de cero
CREATE FUNCTION reservar(p_pedido text, p_sku text, p_almacen text, p_cant integer) RETURNS boolean AS $$
BEGIN
PERFORM pg_advisory_xact_lock(hashtext(p_sku || '@' || p_almacen)); -- se libera al terminar la transacción
IF coalesce((SELECT disponible FROM stock_disponible WHERE sku = p_sku AND almacen = p_almacen), 0) < p_cant THEN
RETURN false; -- sin stock suficiente: el pedido queda pendiente
END IF;
INSERT INTO reservas VALUES (p_pedido, p_sku, p_almacen, p_cant);
RETURN true;
END $$ LANGUAGE plpgsql;La vista calcula físico, reservado y disponible a partir de los apuntes, así que no hay un número que pueda desincronizarse. La función bloquea solo la combinación de artículo y almacén, de modo que pedidos de otros artículos no esperan. En la prueba, con 40 unidades y dos reservas simultáneas de 30, una se confirma y la otra devuelve false; sin el bloqueo, las dos se aceptaban y el disponible quedaba en menos 20. Para el negocio es la diferencia entre avisar a un cliente antes de cobrar y llamarle después para cancelar, algo que importa todavía más si vendes también en marketplaces que comparten tu inventario.
Lector de códigos y operativa en el almacén
El almacén trabaja con el escáner en la mano, no con un ordenador. Cada operación se resuelve con lecturas: primero la ubicación, después el artículo o el lote y por último la cantidad. Cada lectura confirmada genera su movimiento en el libro. Para eso hace falta una app de inventario con lector de códigos en Madrid pensada para pantallas pequeñas, guantes y prisa. Las operaciones habituales son estas:
- Recepción: se lee el albarán del proveedor y se comparan cantidades antes de dar entrada.
- Ubicación: se asigna cada palé o caja a un hueco concreto.
- Preparación de pedidos: la app guía por la ruta de ubicaciones y valida cada artículo leído.
- Recuento cíclico: se cuenta una zona cada día en lugar de cerrar el almacén para el inventario anual.
En naves grandes la cobertura falla en algunos pasillos, así que la app debe guardar las lecturas y enviarlas al recuperar conexión, con el enfoque de una app que sigue trabajando sin cobertura. El servidor valida cada movimiento al recibirlo, de modo que una lectura duplicada no cuente dos veces.
Integración con compras, ventas y ERP
El inventario recibe movimientos de muchos sitios: compras, ventas, devoluciones y traspasos. Cada origen debe escribir apuntes en el libro, nunca tocar cantidades directamente. Si además tienes un CRM o un ERP comercial, la sincronización del stock entre ERP y CRM en Madrid define qué sistema manda en cada dato. Y los avisos de reposición, cuando el disponible baja de un mínimo, se automatizan con la misma lógica que los procesos administrativos que conviene automatizar en Madrid, sin que nadie revise listados.
Si tus empleados de calle o tus clientes consultan disponibilidad, la lectura debe venir del mismo cálculo, ya sea desde una app de campo conectada al ERP y al CRM o desde el portal donde tus clientes ven el stock antes de pedir. Una sola fuente evita que cada canal prometa una cifra distinta.
El Coste de un Stock en el que Nadie Confía
Cuando el equipo deja de creer en el stock del sistema, vuelve a contar a mano, compra de más por seguridad y avisa tarde a los clientes. El dinero se va en inventario parado, pedidos cancelados y horas de recuento. Un libro de movimientos con reservas y control de concurrencia devuelve esa confianza, y su coste conviene medirlo junto con el coste de mantener el sistema año a año.
En Codezone diseñamos y desarrollamos el inventario, la app de almacén y sus integraciones, y seguimos con el soporte del sistema de inventario en Madrid una vez en marcha. Si tu stock no cuadra con la estantería, cuéntanos cómo registráis hoy las entradas y salidas y te proponemos una arquitectura concreta.
