Структура бд для ведения склада

Возникла задача организовать свою систему учета ведения склада/складов.
После некоторого обдумывания у меня получилась следующая схема бд:

где:
MeasureUnits - Справочник единиц измерения (кг/шт/прочее) DocumentTypes - Справочник типы документов (Приходная/Расходная накладная) Warehouses - Справочник складов (Список складов); MaterialAssets - Справочник подотчетных позиций ROFs - Таблица для задания наличия необходимого минимального/максимального количества на складе Documents - Таблица документов (Приход/Расход) ItemsDocument - Таблица список позиций для документа
Помогите придумать как хранить остатки по складу, т.е. какие поля следует включить в таблицу: Остатки
Был бы премного благодарен за советы касательно приведенной мной схемы: может что то стоит изменить.

Update
Наличие единиц измерения в приходной документации обусловлено тем что одна и та же позиция может прийти с другой единицей измерения, т.е. некоторые поставщики могут поставить в штуках а некоторые например в килограммах, соответственно бухгалтерия и приходует так же, и отсюда получается что в определенный момент на складе может быть одна позиция в разных единицах измерения

Update2
в исходную схему внес следующие изменения:
ItemsDocument переименовал в DocumentItems в таблицу ROFs добавил поле MeasureUnitId, для того что бы было понятно в какой единице измерения отслеживать количество добавил таблицу Units - Справочник подразделений добавил макет таблицы Remains в которой будут остатки; добавил таблицу ConversionOfMeasureUnits, в данную таблицу планирую записывать коэффициент который будет использоваться для приведения из одной единицы измерения в другую.

Update3
для чего я сделал связь между DocumentItems и ConversionOfMeasureUnits
Предположим у нас на складе есть Проволока, в свое время она пришла в метрах и так и была оприходована, в один прекрасный момент эта проволока приходит в килограммах(поставщик сменился), в DocumentItems появляется запись следующего вида:
+----+------------+------------------+---------------+--------+ | Id | DocumentId | MaterialAssetsId | MeasureUnitId | Amount | |----+------------+------------------+---------------+--------| | 55 | 5 | 8 | 1 | 5 | +-------------------------------------------------------------+
где:
5 - идентификатор документа; 8 - идентификатор товарно-материальной ценности; 1 - ед. измерения в чем был оприходован данный товар; 5,000 - оприходованное количество
что бы перевести полученные килограммы и показывать остаток в нужных нам метрах кладовщик, через интерфейс программы добавляет запись в таблицу ConversionOfMeasureUnits следующего вида:
+----------------+-----------------+---------------------+ | DocumentItemId | AtMeasureUnitId | TransformationRatio | |----------------+-----------------+---------------------| | 55 | 2 | 0,100 | +--------------------------------------------------------+
где:
55 - идентификатор позиции в таблице DocumentItems 2 - индетификатор ед. измерения в которую будем переводить; 0,100 - в данном случае это вес одного метра проволоки
имея подобную структуру я смогу приводить одну ед. измерения в другую, и отображать(возможно и хранить) остаток в нужных единицах, и в тоже время приход/расход будет вестись в тех же единицах что и в бухгалтерии

Update4
На основании предложений и советов изменил схему следующим образом.

Вынес ед. измерения в справочник материалов; Коэффициент преобразования связал со справочником материалов, добавил два поля типа DateTime дата начала действия и дата окончания действия(default value = "31.12.9999 23:59:59.99") коэффициента;

Ответ

Единицы измерения надо ставить на конкретный материал (товар), а не на запись документа. Т.е. что бы конкретный товар везде был в одних единицах. А то вычисление тех самых остатков на складе будет весьма нетривиально. На склад по документу завели 3 тонны сахара, по другим документам со склада отгрузили 30 кг, 45000 г и 2 мешка. Вопрос: сколько кубических дециметров сахара осталось при относительной влажности 80% и температуре 70 градусов фаренгейта ?
А остатки - это сумма всех записей по данному товару из ItemsDocument, учетом отгрузок как отрицательных величин. Для удобства работы, и оптимизации по производительности можно либо фиксировать остаток на складе на конкретную дату или по точке ухода документов в архив. Или вести триггерами текущее значение. Структура во всех случаях простейшая:
MaterialAssetsId WarehouseId Ammount Date -- возможно, если нужна, дата последней операции или фиксации остатка
Правда что то мне подсказывает, что следующим шагом развития системы будет отслеживать товары в пределах склада с указанием стеллажей или как там место указывается. Тогда придется делать много записей остатков с указанием размещения, например
Upd: ConversionOfMeasureUnits очень странно привязана к записям в документах. С одной стороны я конечно подозреваю, что какие то сложные пересчеты могут быть к документу. С другой стороны, представить перевод грамм в килограмм по разным формулам на разных документах очень сложно. Я бы в таком случае в DocumentItems добавил бы поле "кол-во в базовой единице измерения", в таблицу товаров добавил "базовая единица". Коэффициенты пересчета (хорошо если формулы не понадобятся, не дай бог жидкие материалы, для которых приходится учитывать плотность) вынес отдельно. И еще конечно надо подумать, что будет если в одной поставке мешки по 30 кг, а в другой по 35. Но тут вы похоже все равно хотели, что бы человек к конкретному документу эти коэффициенты откуда то брал. Может произвести "Стандартный расчет" и позволить исправить уже посчитанное кол-во в базовой единице.
С другой стороны, если отгрузка идет всегда в той же единице и пол-мешка отсыпать не пытаются, то тогда вопрос а нужна ли некая базовая единица. Базовая нужна если потом хотят выдавать какие нибудь статистические формы например, что бы в них товар был без разбивки на единицы. Но готовы ли ради них обеспечить перевод и ввод корректных "базовых количеств".