Логика в работе склада

[Евгений_Магистр]

Здравствуйте! Может кто сталкивался, каким образом работает склад в БД? Вот как я себе это представляю. Существует каталог позиций, где указывается артикул, наименование, цена и т.д. и т.п. Далее существует сам документ, например приходная накладная. Вот внес я несколько позиций в документ, допустим, "гвоздь" в количестве 100 шт. В другой документ я внес такую же позицию, в количестве 50 шт. В Итоге, в остатках на складе, у меня должно получиться 150 шт. Но вот вопрос, сам подсчет происходит в некой, третьей таблице? Я так понимаю, что пишется некий скрипт, который сравнивает = если ID одинаковы, то необходимо суммировать количество. Был бы благодарен, если кто-нибудь растолкует данный процесс.

[Stilet]

сам подсчет происходит в некой, третьей таблице?

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

Я здесь уже приблизительно одному челу рассказывал свое видение...
Посмотри вот такие темы:
http://www.programmersforum.ru/showthread.php?t=145049
http://www.programmersforum.ru/showthread.php?t=151513
http://www.programmersforum.ru/showthread.php?t=198706

[Евгений_Магистр]

Сообщение от Stilet

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

Я здесь уже приблизительно одному челу рассказывал свое видение...
Посмотри вот такие темы:
http://www.programmersforum.ru/showthread.php?t=145049
http://www.programmersforum.ru/showthread.php?t=151513
http://www.programmersforum.ru/showthread.php?t=198706

Спасибо за ссылки. Я вот с последнего сообщения наткнулся ещё вот на эту ссылку:

http://basicsprog.ucoz.ru/publ/3-2-2

Но сам принцип, так и не понял. Хотя он там пишет прогу для работы склада. Я так полагаю, что сумма (наличие на складе) позиции, должна находиться в таблице товаров. Они там будут уникальны и соответственно там и можно подсчитывать. Ну а если выбрать из каталога позицию в расходную накладную, то она соответственно отнимается.

Т.е. на кнопке "Сохранить Приходную накладную", необходимо создать некую процедуру, которая найдет в каталоге товаров тот товар, который выбран в документе и прибавит количество то, которое указано в документе, по отдельной позиции. Как ты считаешь, это правильное решение?

[Прик]

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

[Евгений_Магистр]

Сообщение от Прик

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

Согласен. Ибо как мы потом отследим движение товара, если не указывать дату/время событий. Я вообще знаком с деятельностью склада, достаточно глубоко. Просто что проблемы в технической реализации вопроса. Теория есть, как говорится, а вот на практике сталкивался лишь с готовой БД и программой. А вот как самому реализовать, не понимаю. Ну вот сейчас уже ближе к делу, как говорится. Т.е. должна быть всё-таки таблица, куда будут писаться действия с товарами. Наверно она и будет только для того, чтобы записать id, артикул, наименование, цена, склад-источник, склад-приемник (в случае межскладской передачи). Но вот где всё-таки будет происходить сам подсчет. Где та самая цифра, какое количество у позиции фактически. Всё-таки в таблице, где находится сам товар? Ведь позиция уникальна и считать будет проще. Да и таблица не будет перегружена большим количеством записей, потому что часто позиции в 80% не меняются, изредка только пополняются новыми позициями.

[Прик]

И количественная мера и стоимостная никак не должна хранится в таблице объектов учета (товаров).
Цена - само собой в таблице товаров храниться не может из-за постоянного ее изменения (в наш то век растущей инфляции). Количество так же должно фиксироваться в таблице операций. Только так можно определить КОГДА произошло изменение в остатках конкретного товара. В цене тоже.
Для того чтобы узнать сальдо по товару с использованием таблицы операций нужно всего лишь сложить весь приход по этому товару и вычесть расход.
Понятно, что для этого нужно отличать операции по приходу и расходу (числовой признак, например). А для сложения существует серверная агрегатная функция SUM. Т.е. суммы и разность можно подсчитать одним единственным SQL запросом к БД.
Остатки и обороты по товарам ВСЕГДА вычисляются.

[Евгений_Магистр]

Сообщение от Прик

И количественная мера и стоимостная никак не должна хранится в таблице объектов учета (товаров).
Цена - само собой в таблице товаров храниться не может из-за постоянного ее изменения (в наш то век растущей инфляции). Количество так же должно фиксироваться в таблице операций. Только так можно определить КОГДА произошло изменение в остатках конкретного товара. В цене тоже.
Для того чтобы узнать сальдо по товару с использованием таблицы операций нужно всего лишь сложить весь приход по этому товару и вычесть расход.
Понятно, что для этого нужно отличать операции по приходу и расходу (числовой признак, например). А для сложения существует серверная агрегатная функция SUM. Т.е. суммы и разность можно подсчитать одним единственным SQL запросом к БД.
Остатки и обороты по товарам ВСЕГДА вычисляются.

Тогда я наверно теперь немного запутался... Вот у меня есть две таблицы (рассмотрим пока их).

1. Заголовочная часть (Фирма, дата документа, контрагент, тип документа [приход, расход] и т.д.)

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

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

[=master=]

Расчеты не в таблице а в логике.

[Arishk@]

Напоминает немного 1С:Бухгалтерию... может посмотреть как там и сделать наподобие, ведь конфигурация со складом тоже есть

[Прик]

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