Всем привет.

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

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

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

Делал структуру в 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 (руб.)

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