Какую структуру должна иметь таблица движения запасов, если у разных клиентов системы разные требования к хранению остатков:
Клиент №1. Достаточно в разрезе кодов товара.
Клиент №2. Код товара + кол-во штук в упаковке.
Клиент №3. Код товара + номер партии + срок реализации.

Я вижу два варианта:
1. Включить в таблицу движения требуемые поля и заполнять их там где требуется. Минус - если появится новый клиент с новыми требованиями, то придется исправлять много кода.
2. Создать 10 текстовых полей под хранение требуемой информации и для каждого клиента указать, какое поле, что хранит. Минус - довольно сложный начальный код.

Кто что может посоветовать?

номенклатура общее
это верно

В разрезе номенклатуры и партий поступления (в партиях есть поле - срок хранения)
Уточняю: если бы у клиента №3 у одного товара в одной партии был одинаковый срок реализации, то не было бы требования "Код товара + номер партии + срок реализации ".
В целом примерно так и реализовано как Вы предлагаете, за исключением того, что вместо ссылок на ед.изм., номер партии и срок реализации в таблице движения используются сами значения. Это и есть первый вариант.
Как быть если завтра появиться новый клиент и попросит хранить обувь в разрезе моделей, размеров и цветов? Переписывать кучу кода на клиенте и сервере?
Может быть есть более универсальные решения?

RodionATr2d22,
Таблицы
client: client_id;client_name ...
tovar: tovar_id; tovar_name ...
tovar_client_prop: client_id; tovar_id;property_name; property_value ...
Вот как-то так.
Осталось только привести пример таблицы движения запасов и остатков... Сделайте одолжение :)

Naf
Более обще:
Таблица свойств (ключ,наименование) , например: цвет, размер, срокхранения
Таблица значений свойств (ключ, строк. значение (даже если размер обуви числовой) за универсальность платим, ключ_свойства) , например: (цвет, красный), (размер, 40) (срокхранения, 12)
Таблица движений (ключ, приход/расход, ключ_номенклатуры, количество, дата, и т.д. и т.п. - но значений свойств нет)
Таблица набора свойств движения (ключ, ключ_значения_свойства, ключ_движения)

можно еще ограничить допустимые свойства по номенклатуре:
Таблица свойств номенклатуры (ключ, ключ_номенклатуры, ключ_свойства)
А для чего нужна Таблица значений свойств Можно в Таблица набора свойств движения указывать ключ свойства и само значение. Только все равно мне кажется эта система тяжело управляемой. Таблицу набора свойств придется создавать не только для таблицы движения но и всех таблиц содержащих строки с товарам (приход, расход и т.д.). Или как вариант хранить набор свойств толко в приходе, а в других таблицах ссылаться на этот приход. И все равно минус в виде трудоемкости кода на ввод, обновление, удаление данных, поддержание целостности данных и построение отчетов превышает плюс в виде возможности хранения неограниченного количества свойств по товару.
авторРесурсы накопления
Это я просмотрел еще в самом начале. Как раз в этом варианте, если я правильно понял, мои цвета, размеры, сроки и будут измерениями в таблице движений. Проблема в том, как удовлетворить требования разных клиентов. Что если сделать запас этих измерений, допустим 5 полей и для каждого клиента указать что там хранить? При этом запросы будут не сложными, а минусом - ограничение количества свойств - 5 шт. Что бы Вы выбрали из этих вариантов?

Понимаю, что это уже вопросы не проектирования, но все же для меня существенной проблемой является - если хранить характеристики товара в приходе вертикально, то как их разворачивать на клиенте в перечень полей напротив товара в той же строке? Drilldown не устраивает.

RodionAT,
Можно подчиненным отчетом r2d22Drilldown не устраивает
можно процедурой/функцией сцепить несколько строк в поле отчета
Я себе представлял работу при приходе примерно так:
1. Создаем приходный документ для конкретного клиента системы.
2. В зависимости от клиента системы появляется спецификация прихода требуемые характеристики в которой, заполняются в отдельных полях непосредственно в каждой строке спецификации напротив необходимого товара.

Если использовать метод сцепки характеристик, то поле в табличной части всегда одно и редактируется он отдельной кнопкой вызывающей тот самый Drilldown, где и происходит заполнение значений характеристик. Помимо этого в других отчетах и таблицах теряется возможность сортировки/фильтрации (щелкая по наименованию поля) в разрезе каждой характеристики в отдельности.