Всем привет.

В приложении к посту картинка со схемой БД по учету товаров (приход/продажа/возвраты/инвентаризация). Пока что только связи, типы данных еще не приводил в порядок.

Хотелось бы услышать комментарии по поводу структуры. Насколько корректно сделана? Надо ли что-то поправить?

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

Делал структуру в MYSQL Workbench. В приложении также рабочий файлик.

Изображение структуры в PNG.

Dimitry Sibiryakov,

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

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

Нужен журнал движения товаров.

Да много чего еще нужно.

Желательно немного упростить имена, т.к. их придется часто писать. Очень :).

Вендоры и Кастомеры, Имена - практически согласен.

На счет товарных документов:
Немного не понимаю что вы имеете ввиду. У прихода, как сущности, есть свои атрибуты, у возвратов свои и т.д.... Место нахождения товара определяется связью таблиц Products =>> Warehouses_Products =>> Warehouses.

Движение товаров вытаскивается запросами из соответствующих таблиц:



Для чего журнал движения товаров? Не будет ли это дублированием информации?

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

Cane Cat Fishermake.believe,

По партиям учет не хочешь делать?

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

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


Cane Cat Fishermake.believe,

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

А разве добавление еще одной строки в табл.Sales_Products с указанием другой цены на тот же самый ProductID не решает эту задачу? Потом в табл.Sales в поле SaleNote делается текстовая заметка, раскрывающая суть продажи.


Cane Cat Fishermake.believe,

Когда ты делаешь возврат от покупателя, ты указываешь связь, от какой продажи этот возврат.

А вот когда делается возврат поставщику - вообще не указываешь, от какой это поставки: нате вам разворованный в дороге ящик, сами не знаем, откуда он у нас взялся. А поставщику-то интересно, какого экспедитора штрафовать...

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

Cane Cat Fishermake.believeпропущено...


А разве добавление еще одной строки в табл.Sales_Products с указанием другой цены на тот же самый ProductID не решает эту задачу? Потом в табл.Sales в поле SaleNote делается текстовая заметка, раскрывающая суть продажи.


Судя по схеме, в таблице Sales_Products первичный ключ - SalesID + ProductID. То есть в рамках одной продажи SalesID может быть только один продукт ProductID. Еще одну строку с тем же ProductID оно не даст добавить.

Понял. Вы правы. Какой вариант можете предложить, чтобы избежать этой проблемы?

В принципе, чисто с практической точки зрения, решается созданием еще одной продажи. Но...

LSV//У прихода, как сущности, есть свои атрибуты, у возвратов свои и т.д
Их сущности на самом деле очень подобны. Склады тоже следует вести в справочнике контрагентов (с соотв. признаком)

Для чего журнал движения товаров? Не будет ли это дублированием информации?Там будет подготовленная информация "всё-в-одном": когда, кто, откуда, куда, сколько и т.д. Ед.Изм. приведена к базовой (в первичке может быть любой).
Приход с "+", расход с "-".

Это не избыточность. Все отчетность по движению будет браться с одной таблицы элементарными запросами. И предельно быстро.
Партионный учет хорошо ложится на эту таблицу.

Скл.Учет - банальное перемещение ТМЦ между точками(склад, контрагент, POS)

Даже финансы можно вести подобным образом.

Идею понял. Мне это напоминает лист EXCEL'я - все в одном месте, где просто пользуешься фильтрами. Согласен, удобно. Даже больше скажу: намного привычнее для меня.

А вы можете привести пример БД исполненной по такой схеме? Это бы очень помогло.


LSVЕсли товар одинаковый от разных вендоров, то планировалось учитывать их под разными ProductID. Очень опасная ошибка. Размножение одинаковых карточек - огромная беда всех баз. И с ней надо постоянно бороться.

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

Cane Cat Fishermake.believe,

А как вообще планируется вести денежный учет этого дела?

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

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

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

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

автор Пример расчета по методу средней себестоимости
На начало месяца в магазине «Канцтовары» оставалось 370 шариковых ручек по закупочной цене 10 рублей. В течение месяца было поставлено еще 1000 ручек двумя партиями — 500 по 9 рублей 50 копеек и 500 по 9 рублей. Считаем среднюю стоимость.

Стоимость ТМЦ на начало месяца: 370 X 10 = 3700 (руб.)
Стоимость 1-й новой поставки ТМЦ: 500 X 9.5 = 4750 (руб.)
Стоимость 2-й новой поставки ТМЦ: 500 X 9 = 4500 (руб.)
Средняя стоимость ТМЦ: (3700 + 4750 + 4500) : (370 + 1000) = 9.45 (руб.)

По этой средней стоимости и будут считаться списанные товары и высчитываться прибыль. Например, если ручки продаются по 15 рублей, и за месяц было продано 1100 ручек, прибыль конкретно за эти ручки будет считаться так:

1100 X 15 – 1100 X 9.45 = 6105 (руб.)

Преимущества метода расчета по средней себестоимости — в стабильности цены продаваемых материалов и простоте.

ПАРТИОННЫЙ УЧЕТ.

Ребят, такое ощущение, что это какая-то проторенная дорожка. Чисто с бухгалтерской точки зрения это значит учет себестоимости по методу FIFO? Есть у кого-нибудь пример структуры, в которой реализован партионный учет? Очень интересно посмотреть.


Sergueimake.believeИзображение структуры в PNG.



ProductStatuses_Product подозрительно живет своей жизнью независимо от поставок и продаж. Какие статусы там предполагаются?

Статус товара:
1. В наличии (готов к реализации)
2. В пути
3. На ремонте
4. Неликвид (описать состояние товара: царапины, наличие упаковки и т.д.)


SergueiSergueiProductStatuses_Product подозрительно живет своей жизнью независимо от поставок и продаж. Какие статусы там предполагаются?

Я так понимаю Warehoses_products -попытка сделать движения товаров между складами? Если да то - то подумайте получше что там не так.

Ммм... да, я создавал эту таблицу чтобы иметь возможность отслеживать именно размещение по складам. Т.е. например всего поступило 10 штук какого-то товара, из них 3 в магазин, 7 на склад. Далее "+1" в магазин, например, "-1" на складе. Дальше пока не думается, помощь окажите?

Гигабайт Мегабайтович Килобайтови да продавать "товары" очень не рационально , ибо тогда нельзя будет по закону "продать" "телефон+ пленку в подарок", ибо нельзя продать товар по цене 0.
для этого делают отдельную сущность.
и таки не вижу "услуг" или даже возможность "впихнуть" услуги в данную структуру, а если таки предполагается торговля электроникой, то таки услуги наверняка должны быть.

Закону РФ? Привет из КР, тут можно.

Услуги есть, вы правы. Планировал делать отдельной схемой, чтобы не мешать с товарами.