полиномэта схема выходит за рамки подсистемы собственно WMS, что ИМХО и порождает разные недоразумения
в ней присутствуют избыточные для БД "чистый склад" таблицы "сделки" и "закупки"
таблица "сделки" не лишняя, просто она должна входить в рамки другой подсистемы, м.б. "учет договоров"
таблица "закупки" также не лишняя но и она должна входить в другую подсистему, м.б. "учет взаиморасчетов"
ну или как-то так...

пока предположим, что WMS должна учитывать только операции с ТМЦ на складе
или в месте хранения ТМЦ на основе документов первичного учета.

полином, я не знаю кто такое WMS, что туда входит или оттуда выходит.
Просто хочу обратить твое внимание на то, что показанная тобой здесь

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=998443&msg=13818953

картинка, как схема составленная access, полностью идентична "Схеме 1" из первого сообщения Geo
Вот соответствие по названиям таблиц.

Закупки - Docs
Сделки - DocTable
Товары - dNomenkl
Сотрудники - dStorages
Поставщики - idContra

Учет прихода и ухода происходит по таблице Сделки
Остаток, с учетом продаж и утруски, выводится построчно, по каждой из поступивших в таблицу Сделки "партий товара".
Таким образом, в акцессный склад встроен некий прообраз "партионного учета",
без порождения специальных приходных, расходных и утрусочных документов.

Вероятно, предполагается учет чего-то вроде ТМЦ.
Поэтому, глядя на схему, понятие "места хранения" можно считать полностью эквивалентным понятию "материально ответственное лицо", которое в данной схеме совпадает с содержимым таблицы Сотрудники.

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

Состав наличных полей акцессного шаблона достаточен для реализации распределенных по пользовательским ролям функций.
- До фактического поступления товар числится "в заказе" - эту операцию может делать пользователь1, оформляющий заказ.

- по поступлению товара пользователь2 (ответственное лицо) должно сквитовать количество фактически поступившего товара,
Отдельно (пользователем3 или пользователем2) может оформляется выбытие("продажа"/списание-утруска) по поступившей партии с оформлением усушки.

Т.е акцессный шаблон пригоден для реализации достаточно богатого спектра операций, для того, чтобы считать, что это работоспособный прототип склада.
Сформулированный непосредственно в бизнес-терминах.

Видно, что при желании передача ценностей между отвтственными лицами в рамках акценссного шаблона тоже возможна.

Это можно сделать так:
- предварительно список поставщиков дополняется сотрудниками, для которых допускатеся передача ценностей между собой

Далее само движение проводится тремя действиями -
1)в таблице сделок оформляется "продажа",
2)затем оформляется "заказ" на передачу, где поставщиком является передающий сотрудник, а материально ответственным лицом - сотрудник, принимающий ценности.
3) принимающий ценности сотрудник квитует прием ценностей.

Желающим оставлена возможность навести на этот процесс автоматизацию.
Сжема допускает.

Кроме того, такая акцессная схема по разнице между заказанными и полученными количествами теоретически позволяет оперировать виртуальными понятиями "товар в пути" и "потери при транспортировке".

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

некая подстава интерфейсе шаблона все-таки есть.
проектировщик интерфейса явно предполагал, что склад единственный (поняте места хранения в его сознании не выделялось) и "сотрудник" в результате просто висит в воздухе этого интерфейса никому не нужный. Разработчик интерфейса явно не знал, зачем нужен "сотрудник".