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

Несколько оговорок:
- русскоязычные названия полей, используемые в схемах, приведены исключительно для наглядности. Я рекомендую пользоваться во-первых, одним языком при описании структуры таблиц, во-вторых, языком английским. Рекомендую я это с точки зрения удобства написания программ. При использовании англоязычных названий вам придется реже переключать раскладку клавиатуры, и дело будет идти быстрее. Еще одна причина не использовать русские названия: программа, написанная с их использованием, может не работать в версиях windows, локализованных на другие языки.
- справочники Складов, Контрагентов и прочие я описываю в линейном виде, хотя сам предпочитаю делать их иерархическими, по аналогии с приведенной структурой справочника Номенклатуры. Поскольку организация иерархии - это отдельная и объемная тема, то останавливаться на ней здесь я не буду.
- обратите внимание, что в таблицах документов введены поля как для хранения цены по строке, так и для суммы. Сделано это осмысленно, т.к. в разных учетных системах может быть первична как сумма, так и цена, и при обратных расчетах возможны ошибки округления. Хранение лишних 8 байт на запись я считаю несущественным по сравнению с потенциальными проблемами, с которыми вы можете столкнуться в связи с этим, и временем, которое придется потратить на объяснения с контрагентами и инстанциями. Кроме того, однажды введенный документ ни при каких обстоятельствах не должен меняться, если вы вдруг решили поменять алгоритмы расчета или округления. В служебных же таблицах я храню только сумму - они предназначены для формирования отчетов по остаткам и оборотам товаров, в том числе и суммовых, но никак не для получения цен товаров.

Вариант 1.

Самый аскетичный вариант. Подразумевается, что все документы хранятся в общей таблице Doc, а их табличные части в одной для всех таблице DocTable. Для примера к таблице Doc "пристёгнуты" справочники Контрагентов и Складов, аналогично по мере необходимости добавляются и другие справочники, например: валют, причин списания, корреспондентских счетов и пр.

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

Плюсы:
- простая и компактная схема БД.
Минусы:
- много избыточной информации. Многие документы имеют исключительно свои поля, которые не используются в других документах. И чем дальше развивается программа, тем больше будет таких полей. В качестве возможного развития подобной схемы иногда предлагается хранить все поля, отличающие один документ от другого, в отдельной (или отдельных) таблице(-ах) метаданных, а в таблице Docs оставить только общие поля. Но подобная схема отрицательно влияет на и без того невысокое быстродействие данного варианта, и умаляет единственный его плюс - простоту.
- при использовании выделенного sql сервера для обработки и хранения данных, придется писать громоздкие и неудобные в восприятии триггеры на таблицы Doc и DocTable.
- весьма неудобные запросы для получения остатков и оборотов.
- по мере роста базы очень большое время получения остатков и оборотов.

Вариант 2.

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

Плюсы:
- простая схема БД.
Минусы:
- неудобные запросы для получения остатков и оборотов.
- по мере роста базы очень большое время получения остатков и оборотов.

Примечание
Оба эти варианта очень просты, но отличаются сложностью обработки информации и получения отчетов. Поэтому имеет смысл делать одну или несколько служебных таблиц, которые заполняются по мере редактирования таблиц документов. При работе с полноценным sql-сервером их заполнение разумно делать триггерами, при использовании же "чистого" Access, они заполняются в процедурах обслуживания событий форм: при удалении, редактировании и создании записей. В последнем случае так же нельзя будет забывать обо всех других способах изменения таблиц, например, при импорте данных, загрузках из ТСД и прочее. Во всех этих случаях надо будет изменять и служебные таблицы.

Вариант 3.
Добавляем таблицу операций (или проводок). "Развивать" я буду вариант 2, но не вижу препятствий и для соответствующих изменений варианта 1.



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

Плюсы:
- очень простые и удобные запросы для получения остатков и оборотов товаров.
Минусы:
- При достижении определенных (и не очень больших, кстати) объемов товарооборота, все эти запросы начнут здорово тормозить. И особенно в случаях, когда данные будут располагаться на другом компьютере в сети, либо потребуется получать остатки при вводе документов, производительности этого варианта окажется недостаточно, и вам придется развивать программу дальше.

Вариант 4.
Операции (проводки) + текущие остатки.



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

Текущие остатки хранятся на "последний момент". Чтобы посчитать остатки на любую прошедшую дату, или получить отчеты по движению товаров, используются те же запросы, что и в варианте 3. Отсюда получаем:

Плюсы:
- очень простые и удобные запросы для получения остатков и оборотов товаров.
- очень быстрые запросы на получение текущих остатков по товарам (особенно важно, если вы собираетесь контролировать отрицательные остатки, или показывать пользователю текущие остатки товаров при вводе расходных документов).
Минусы:
- Довольно скоро запросы на остатки задним числом могут начать работать ощутимо медленно.

Вариант 5.
Периодические остатки.



В таблицу остатков добавляем поле "дата остатков". Текущие остатки, если они нужны, хранятся на дату, в которой программа работать не будет, например, на 01.01.1901. А с определенной периодичностью (зависящей, в первую очередь, от объемов товарооборота) создаются промежуточные остатки на начало этого периода. Например, на первое число каждого месяца. С введением периодических остатков мы получаем:

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

Примечание
Дальнейшее развитие базы возможно приведет вас к необходимости партионного учета. То есть товар из очередного поступления надо отличать от остальных поступлений того же товара. Например и как минимум по сроку годности. Этот вариант я (пока или совсем) описывать здесь не буду.

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

qwerty112Geo,

картинок, почему-то, нет ...


гм. Сейчас поправлю... Джудж место экономит и картинки в удаленных постах не хранит. Придется выложить их ниже