Как это сделано в нашей WMS. У нас стоит Manhattan SCALE.
Есть таблица с транзакциями - они отражают все возможные изменения движения товара.
Есть таблица с типами транзакций - описываются граничные условия применения - откуда-куда двигать, в каком количестве и так далее. Есть системные транзакции и пользовательские - первые зашиты по умолчанию, вторые можно создавать.
Есть таблица с остатками по ячейкам. Содержит помимо всего прочего 4 поля с количеством товара - остатки на сейчас, количество товара зарезервированного под движение, но еще не взятого, количество товара под вопросом (возникает когда происходит недобор например), количество товара перемещаемого в ячейку (необходимо потому что возможна ситуация с резервированием товара который еще в ячейку не приехал, но скоро там будет, чтобы не ждать окончания пополнения например).
Остатки на конкретное число и время в общем виде не получаются, требуется рассчитывать, или поднимать транзакцию ближайшую к нужному моменту. Каждая транзакция содержит остатки по изменяемой ячейке до изменения (все четыре количества) и остатки после изменения (все четыре опять же).
В результате, когда система резервирует товар по ячейкам под отбор у нее нет необходимости пересчитывать для всех 20000 ячеек остатки на текущий момент (тем более если у вас точка актуальности в начале месяца, сейчас конец месяца и через ячейку прошло несколько сотен операций отбора и пополнения разного товара и разных партий в общем случае) - дополнительно учитывайте, что резервирование это не одна операция в день, а постоянно по факту получения новых заказов (хоть каждые 5 минут). Склад должен постоянно иметь актуальные остатки прямо сейчас и не ждать пересчета при каждом вопросе.

Как-то так. Извиняюсь, что сумбурно.