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

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

Структура базы.
Таблицы построены по принципу ядра, модулей и справочных таблиц.
Есть две основные таблицы-регистры (ядро базы): RegisterStorage (Складские остатки), RegisterTraffic (Регистр движения товаров). И куча таблиц-документов (модулей). Таблица-документ - это таблица соответствующая типу операции. Например: Приход, Расход, Перемещение, Инспекция, Продажа, Растаможка и т.д. до бесконечности. В этом главный плюс такой структуры: таблицы-документы можно добавлять сколько угодно и когда угодно - структуру базы переделывать не придется. Например, вздумалось руководству добавить новый тип товарооборота: Перепаковка - да запросто: добавляете в базу новую таблицу-документ Перепаковка, и пишете форму для нее.
В справочных таблицах хранятся описания товаров: типы, размеры, сорта.

Теперь подробнее о структуре таблиц.

Таблица RegisterStorage (текущие складские остатки)
Поля:
RegisterStorageID - автономер записи
Created - дата записи
ArrivalDetailID - уникальный номер продукта
StorageID - номер склада, где находится продукт
Qty - кол-во продукта
Weight - вес продукта
Lot - номер ячейки, где лежит продукт
RegisterStorageStatusID - статус продукта (нормальный, зарезервирован, в обработке и т.д.)
ProcessingDocumentTypeID - тип документа, по которому сейчас обрабатывается продукт
ProcessingDocumentID - номер документа, по которому сейчас обрабатывается продукт

Таблица RegisterTraffic (движение продуктов).
Поля:
RegisterTrafficID
Created
UserID
TrafficTypeID (приход, расход, внутренние складские операции)
ContactID - клиент - от кого получено или кому отпущено
DocumentTypeID - тип документа операции
DocumentStatusID - статус документа
StorageID - номер склада
DocumentID - номер документа
Qty - кол-во
Weight - вес
Price - цена
ArrivalDetailID - уникальный номер продукта

Теперь таблицы-документы:

Таблица-документ Arrival (поступление товара на склад)
ArrivalID
Created
UserID
StorageID
ShipperID (поставщик)

Таблица детализации поступления ArrivalDetail:
ArrivalID
ArrivalDetailID
ProductID
ProductPackageID (упаковка продукта)
ProductSizeID (размер)
ProductSortID (сорт)
Lot (№ ячейки на складе)
Qty
Weight
Notes (заметки)


Таблица-документ Sale (продажа)
SaleID
UserID
Created
DocumentStatusID (статус документа: в обработке, закрыт, отменен)
ContactID (покупатель)
RecipientName (имя компании-получателя)
RecipientCEOName (имя ответственного лица получателя)
RecipientPhone
RecipientFax
DeliveryServiceID
дальше идут адресные текстовые поля: индекс, страна, улица и т.д.
ProductCost (общая стоимость продуктов)
DeliveryCost (стоимость доставки)
OtherCosts (другие расходы)
OtherCostsDesc (пояснение других расходов)
Tax (налог - в денежном исчислении, а не в процентах!)

Таблица SaleDetail (детализация продажи)
SaleDetailID
SaleID
ArrivalDetailID (уникальный номер продукта - по нему можно определить св-ва продукта и номер партии поступления)
Qty
Weight
SalePrice (цена продукта)
ShipperPrice (цена поставщика)
StorageID
Lot

Остальные таблицы-документы (перемещение, растаможка и т.д.) строятся по аналогии таблиц Sale, SaleDetail. Общее во всех таблицах-документах одно: поле ArrivalDetailID (уникальный номер продукта), по которому всегда можно проследить продукт.

Все эти таблицы хранятся в серверной части.

В клиентской части есть аналогичные таблицы-документы, которые используются как черновики. Когда юзер хочет, например, продать товар, он сначала добавляет эти товары в таблицу-черновик, там выполняются все нужные проверки и т.д., и когда все готово, юзер жмет "Создать документ" и тогда по списку продуктов в таблице-черновике выполняются движения в серверной части: с таблицы RegisterStorage списываются продукты, в таблицу RegisterTraffic добавляются записи о движении продуктов (в данном случае о том, что они были проданы), в таблице Sale создаются записи о совершенной продаже. После чего таблица-черновик очищается.

Справочные таблицы: Pricelist, Product, User, Group и т.д.

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

Основы изложил. На вопросы отвечу.

Хороший вопрос. Я это сразу не описал, чтобы не загромождать деталями. Для этого в таблице RegisterStorage есть поля QtyProcessing, WeightProcessing.
Например, если Qty=10 и QtyProcessing=0, то продавец может начать готовить на продажу 10 шт.
Допустим он взял 6 шт. Тогда прибавляем к полю QtyProcessing 6 шт.
Когда второй продавец посмотрит поле Qty, он увидит: 4 (10) - 4 доступно из 10 имеющихся на складе. И программа позволит ему взять не больше 4.
Когда оформляется документ, программа еще раз проверяет, что кол-во и вес свободных и имеющихся на складе продуктов не превышает указанных продавцом.
Да и кстати, в силу вышесказанного блокировки этой таблицы у меня просто отключены за ненадобностью.

Извини, я схемы баз данных не юзаю за ненадобностью.

ну и концептуальная ошибка - в классическом случае в задачи склада не входит реализация (продажа) товара.

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

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

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

ну не знаю, не знаю :)
я считаю, что идеальная модель, которую мне удалось реализовать вместе с товарищами - это именно та, которую мне удалось реализовать вместе с товарищами.

а все, что пишут другие - ущербное.

Ну как же нет связей. Есть. Например, в таблице Sale есть поле ContactID, так вот при создании этой таблицы в источнике данных этого поля я прописал:
SELECT Contact.ContactID, Contact.ContactName FROM Contact ORDER BY Contact.ContactName
Это и есть связь. И так для всех связанных таблиц. А схема - она же ни на что не влияет, она чисто визуальная надстройка.
Завтра постараюсь распределить основные таблицы по схеме и сделать скрин.

применение полей подстановки в таблицах далеко не самое бесспорное решение

Да-да-да.

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

>>> Но переделывать лееень.

я склонен предположить, что решения Станислава не существует в виде реализованного проекта или проекта проекта.

утверждать этого не могу и не стану, но выглядит все как общие рассуждения "на тему склад+продажи"

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

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

==>>>

не качает

а скрины можно выложить прямо сюда - примерно так, как выложил я в предыдущем сообщении.

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

для нагладности хотелось получить общее представление.

впрочем я его уже получил и без скриншотов схемы БД

3

спасибо

Да.

Станислав, не нужно меня троллить. это пустое и бесперспективное занятие.

да уж :)

2