Conceptualmente es el problema que resuelve la contabilidad doble: Si no se conserva la historia y flujo de las transacciones se pueden generar errores (o fraudes).
El problema de fondo es que el manejo del estado de los datos normales en forma CRUD es *destructivo* y no hay manera de saber como se llego al resultado actual. Para un inventario, al igual que un libro contable - de hecho, un inventario es una forma especial de contabilidad- es mas solido usar un diseño inmutable (donde no se sobreescribe sino que se agregan los resultados).
Osea, un log.
Es mejor que el inventario sea asi:
Cita:
Feb1 - Ref:ABC BUY = Qty:1, Value:$10
Feb2 - Ref:ABC SELL = Qty:1, Value:$15
Feb3 - Ref:ABC BUY = Qty:10, Value:$20
Feb3 - Ref:ABC TRANSFER = Qty:10, Value:$20 TO Store: 2
|
Nota: Se registra luego de hacer las validaciones. Por eso, si no se permiten vender por debajo del stock, no saldran lineas con inventarios negativos. Osea, se registra solo un hecho real y concreto (en el pasado) y no lo que se va a hacer y que *puede* ser rechazado por la logica del negocio.
Y usar la tabla de inventarios como "cache" con el valor actual del stock (Asi que obvio tienes un campo Stock actual). Asi, teniendo la historia en forma de log, puedes tener claro como se movio el flujo del inventario.
Entonces, si hay un problema con un producto, puedes consultar tu log y ver en que momento se genero el problema.