Приветствую всех.

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

Как все это отслеживать? Какому клиенту сколько товара и какой начальной стоимости было отпущено. Тут надо обновлять данные по остатку товара на складе. Просто по ID товара не прокатит. (если входная цена всегда одна и таже, то без проблем)
На конец года надо делать отчет по наличию товара на складе и его общей стоимости. А тут может возникнуть ситуация:
товар А цена 10ед 100шт
товар А цена 12ед 500шт
товар А цена   9ед  25шт.
Всего 625шт 
Ну и так далее.

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

Заранее спасибо.       

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


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

Akina, 
спасибо за отклик.   

Но,  вопрос не про накладные, а про таблицу описывающую товары на складе.

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

Вот поэтому я и задал вопрос, как "взрослые" организовали хранение данных на товар в БД.

Какие поля и почему нужно добавить в таблицу "Товар" что бы получить реальную модель?
ID для поставщика, дату поставки, ... , что-то еще?   

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

thomas, прежде чем думать о полях таблицы, нужно определить логическую структуру процесса, одним добавлением полей в таблицу товаров не обойтись.
давай по порядку:
1) у нас есть поставщик который нам поставляет товар, таким образом у нас есть сущность "поставщик".
2) от поставщика мы получаем товар в партиях, иначе быть не может, отсуда еще сущность "партия"
3) и сущность "товар"
и так детализируем:
ПОСТВЩИК:
поставщик есть поставщик к нему не прикопаешься .

ПАРТИЯ:
при получении партии нужно сделать наценку на товар.
наценка на товар может идти несколькими способами.
     а) индивидуально(чаще всего не используется)
     б) по типу продукции (алкоголь, молочные продукты, консерванты и т.д.)
     в) в зависимомти от цены товара, к примеру если колбаса у поставщика стоит 200р. то наценка на нее 10%, а если бомжатник стоит 3р. то наценку 10% на него не сделаешь т.к.  за привоз больше отдашь(бензин, з.п. водителя, грузчики), соответственно наценка от 100% и выше.
вариант "в" чаще всего используется.
идем дальше нужно определиться где будут вестись ценовые изменения, для этого лучше добавить еще одну сущность т.к. наценка на товар из партии может меняться несколько раз.
и так выресовывается еще одна сущность, назовем ее "наценки(умнее ничего не придумал)".

ТОВАР:
эта сущность является справочником товаров которые сожержаться на складе. здесь тоже есть подвох, ведь товар может продаваться не только упаковками, но и штуками, к примеру шокаладку дольками продавать не будешь, а вот ампулы каких нить лекарств легко продаются штуками, соответственно это тоже нужно учитывать. пока по этому поводу предложить ни чего не могу. будем думать...

и так мы имеем 4 сушности которые 100% будем использовать:
ПОСТАВЩИК
ПАРТИЯ
НАЦЕНКИ
ТОВАР

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

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

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

схема такая:

ПОСТАВЩИК ---< ПАРТИЯ ---< НАЦЕНКИ >---ТОВАР ("<", ">"- вторичные ключи)

определим поля для каждой сущности (ограничимся минимальным набором полей):

ПОСТАВЩИК:
id
name (некое название поставщика)

ПАРТИЯ:
id
id_ПОСТАВЩИКA

ТОВАР
id
name (наименование товара)

НАЦЕНКИ (это та самая таблица о которой сказал выше SergeBS)
id
id_ТОВАРA
id_ПАРТИИ
количество
ед_имерения
цена_поставщика
наценка_на_товар
дата_изменения_наценки

DimW, 
В ПАРТИЯ еще полезно добавить поле "дата поставки". И перенести туда же поле "цена_поставщика". Получится динамика изменения цены товара. Но тут уже надо тщательно изучать, насколько это надо и т.п. Если "цена_поставщика" у партии может меняться (типа у.е. в рубли), то начальная дата - начальная цена, а дальше даты - изменение. Ну и т.п. Дальше мне думать лень... Информации мало.

ага, так будет лучше. 


да мне что то тоже т.к. сам автор не проявляет интереса.

SergeBS, 
DimW, 


Автор бился в конвульсиях.   
Днем работаем, вечером в вечерней вышке учимся, а в перерывах между боями решаем очень гадкую проблему.
Вот переустановился, пока полет нормальный   

На данный момент я имею такую структуру БД, см. прилагаемый файл.

От проблемы не соответствия цены в таблице описывающей товар и таблицах фактур и , скажем так, заказов я ушел следующим образом.
В таблице Artikel(товар) есть поле HuidigeVerkoopPrijs, которое описывает цену товара на данный момент времени. Она может быть изменена пользователем.
В таблицах WerkBonDetail и FactuurDetai есть поле VerkoopPris, которое содержит цену на товар в момент выписки WerkBon или Factuur. Оно остается неизменным.
Т.е. всегда можно увидеть по какой цены ушел товар.

SergeBS, 

А поподробнее можно?   

DimW, 
А партий там в принципе нет. Есть только LeveringsBon, типа "товарная накладная" если по русски, бумажка о доставке(цены там нет по определению). А примерно раз в месяц или квартал, как договоришься, поставщик делает Factuur на все что он поставил в этот период. Тут уже есть цена. И это уже надо проплачивать. Отсюда в принципе береться кол-во товара для изменения данных стока(voorraad) в таблице Artikel(товар).


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


ЗЫ и не ругайтесь, что ERD на Фламанском. Просто не было времени переделывать на русский.   

Это сообщение отредактировал(а) thomas - 14.9.2007, 13:26

Присоединённый файл ( Кол-во скачиваний: 2 )
 DBvoorLuk.zip 92,99 Kb