Прошу дать мне рекомендации

← →
Denizzz (2003-10-01 08:10) [0]

Здравствуйте, мастера!
В моей программе реализован учет продукции: в одной таблице поступление а в другой отгрузка.
Хочу реализовать формирование остатков на складах.
Пожалуйста, дайте свои рекомендации как это лучше всего реализовать.

← →
Deniz (2003-10-01 08:27) [1]

Неплохо бы было посмотреть на структуру(общую) БД.

← →
Digitman (2003-10-01 08:31) [2]

схема, конечно, примитивная у тебя.
и вносит ряд ощутимых ограничений.

но в принципе, если ограничения для тебя несущественны, ее можно доработать таким образом, что для получения оперативных остатков на складах достаточно будет сделать простую выборку из таблицы "П" (поступление)

добавляешь в таблицу "П" числовое поле RQty (тек.остаток), куда при создании записи заносишь копию поля "Количество поступления".

таблица "О" (отгрузка) должна ссылаться по втор.ключу на уник.перв.ключ таблицы "П".
при создании/модификации/удалении записи в "О" поле RQty соотв.записи в "П" должно (после проверки на допустимость нового значения) модифицироваться примерно след.образом

- создание нового акта отгрузки :
New.RQty = Old.RQty - New.Qty

- модификация существующего акта отгрузки :
New.RQty = Old.RQty + Old.Qty - New.Qty

- удаление существующего акта отгрузки :
New.RQty = Old.RQty + Old.Qty

где Qty - поле "Кол-во" в "О", т.е. кол-во отгрузки

← →
Digitman (2003-10-01 08:35) [3]

тогда оперативные остатки по заданному складу можно сделать простым запросом

SELECT * FROM "П" WHERE StockNo = такой_то AND RQty > 0 ORDER BY ActDate

← →
Denizzz (2003-10-01 08:38) [4]

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

← →
Denizzz (2003-10-01 08:43) [5]

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

← →
DenK_vrtz (2003-10-01 08:51) [6]

Denizzz, я чего не ясно?
Общий принцип расчета остатков уважаемый Digitman © тебе объяснил, а дальше частности.

Да и еще. Телепатов здесь нет!

← →
Denizzz (2003-10-01 09:00) [7]

Dial-up 2kb/s межгород....
Такая вот дикая скорость (пока что-то отправишь - скопытится можно).

← →
Sergey13 (2003-10-01 09:34) [8]

ИМХО, оптимальнее всего будет создание новой таблицы остатков с полями (условно):
ID_tovar
ID_sklad
Kolichestvo
Заполнять ее тригерами при проведении операций приемки/отгрузки.

>Dial-up 2kb/s межгород....
Маловато, конечно, но проводки то ты делаешь? Если да, то тригеры трафика не добавят.

← →
Digitman (2003-10-01 09:36) [9]

> Denizzz

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

скажем, некоем новом акте отгрузки фигурирует 10 единиц такой-то номенклатуры, в то время как в разное время выло зафиксировано 3 акта поставок той же номенклатуры на общее кол-во 9 единиц (т.е. отгружаемое кол-во больше реально поступившего).

или, скажем, отгрузка данной номенклатуры производится на день раньше, чем та же номенклатура фигурирует в акте поставки

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

← →
Denizzz (2003-10-01 09:49) [10]

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

← →
Denizzz (2003-10-01 09:50) [11]

А остатки придется формировать по окончании рабочего дня.

← →
Sergey13 (2003-10-01 09:56) [12]

2Denizzz (01.10.03 09:49) [10]
А зачем дата актуальности? Там должны быть текущие остатки. На дату надо к остаткам прикрутить расход/приход в обратном порядке.

← →
MsGuns (2003-10-01 13:01) [13]

>Digitman © (01.10.03 08:31) [2]
>добавляешь в таблицу "П" числовое поле RQty (тек.остаток), куда при создании записи заносишь копию поля "Количество поступления".
таблица "О" (отгрузка) должна ссылаться по втор.ключу на уник.перв.ключ таблицы "П".
при создании/модификации/удалении записи в "О" поле RQty соотв.записи в "П" должно (после проверки на допустимость нового значения) модифицироваться примерно след.образом

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

← →
MsGuns (2003-10-01 13:14) [14]

>Sergey13 © (01.10.03 09:34) [8]
>Заполнять ее тригерами при проведении операций приемки/отгрузки.

А что, в парадоксе появились триггера ?

>Denizzz (01.10.03 08:38) [4]
>Вообще в них хранится только количество и цена (в табл отгрузки), а остальные поля связаны со справочниками видов и сортов, водителей, складов, мот.

1. Цена для продукции не так актуальна как сумма, т.к. одна и та же продукция может поступать на склады из цехов с разной себестоимостью, а реализовываться (отгружаться) по одной и той же отп.цене
2. Хранимая на складе позиция (складская номенклатура, обычно в справочнике) должна храниться по приходу и отпускаться со ссылкой на этот приход. Т.е. если одна и та же болванка (1 запись в справочнике-номенклатурнике) поступила на склад 3 раза (3 документа), то в движении по складу должно быть 3 позиции. А при отгрузке позиции списываются опять же с привязкой к приходам.
Эти ты решишь не только количественную, но и суммовую (а, след-но, и бухгалтерскую) проблему движения и остатков.
3. Не имеет смысла хранить дату остаков. Если у тебя будет правильно организовано движение, то можно будет абсолютно достоверно определить остатки на любую дату любой позиции или в целом по складу (фирме).
4. Если у тебя намечается совместное юзание БД, да еще удаленное, настоятельно рекомендую тщательно продумать вопрос о целесообразности использования в качестве хранилища формат парадокса.

← →
Deniz (2003-10-01 14:05) [15]

Не автор просто ники похожие
>MsGuns © (01.10.03 13:14) [14]
А как быть в случае, когда приход 3 раза по 1 болванке, и единовременный расход 3 болванок придется пробивать 3 раза?

← →
Digitman (2003-10-01 14:23) [16]

> MsGuns

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

← →
Леван Варшанидзе (2003-10-01 15:20) [17]

У меня работающая программа для аптечной сети, пока тоько, уви, на клиппере и перевожу на Дельфи

нескольо принципиальных замечании:
И прихло: и расход (с количеством с отрицательным знаком) хранятся в одном файле и различаются по коду операции тоже
(приход положительнцй, но могут разние источники : возврать или закупка ии перенос из другого склада. Расход отрицательнйи, но могут разные причини: продажа , списание, промоциЯ. возрат поставщику и т.п)

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

разные партии одного и того-же товара хранятся в разних записях
все обьекти (склади, поставщики, потребители) хранятся в однном справочнике

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

Подробности - по майлу
Удачи
Леван

← →
Леван Варшанидзе (2003-10-01 15:28) [18]

Огромные извинения за опечатки в предидущем сообшении !!!

← →
MsGuns (2003-10-01 17:00) [19]

>Леван Варшанидзе (01.10.03 15:20) [17]
>нескольо принципиальных замечании:
И прихло: и расход (с количеством с отрицательным знаком) хранятся в одном файле и различаются по коду операции тоже
(приход положительнцй, но могут разние источники : возврать или закупка ии перенос из другого склада. Расход отрицательнйи, но могут разные причини: продажа , списание, промоциЯ. возрат поставщику и т.п)

В большинстве случаев верный подход

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

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

Только откуда 55 файлов-то ?

← →
Труп Васи Доброго (2003-10-02 08:22) [20]

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

← →
Sergey13 (2003-10-02 08:34) [21]

2MsGuns © (01.10.03 13:14) [14]
>А что, в парадоксе появились триггера ?
Про парадокс прохлопал, каюсь.

2MsGuns © (01.10.03 17:00) [19]
>В клиент-серверной БД стоит хранить остатки только если очень большой объем данных.
А какой объем считать "очень большим"? И как определить когда объем станет "очень большим", что бы своевременно переписать всю работающую систему практически с нуля? Может сразу предусмотреть узкие места все таки правильнее. Кроме того как ты при таком подходе собираешься обеспечивать отсутствие минусов на остатках? На каждый чих пересчитывать все движение? Ну уж нафиг.

← →
Сергей Суровцев (2003-10-02 09:16) [22]

>MsGuns © (01.10.03 17:00) [19]
>В клиент-серверной БД стоит хранить остатки только если очень
>большой объем данных.
Согласен, причем для любой системы. Постоянный паралельный
контроль текущих остатков вещь бессмысленная в общем случае,
т.к. выборки могут быть любыми и за любое число, но при этом
очень трудоемкое. Действительно оптимально иметь одну базу
на приход-расход и делать из нее соответствующие выборки.
Т.е. структура примерно: /дата/код товара/сумма/кол-во/признак
приход-расход/код склада/документ/.....другие признаки/
Громоздко, зато просто, дешево и быстро, а главное надежно.

>Sergey13 © (02.10.03 08:34) [21]
>На каждый чих пересчитывать все движение? Ну уж нафиг.
Только так можно получить ДОСТОВЕНЫЕ остатки. Иначи только с долей вероятности. А это чревато. Не игрушку ведь пишет.

← →
Sergey13 (2003-10-02 09:35) [23]

2Сергей Суровцев © (02.10.03 09:16) [22]
>Только так можно получить ДОСТОВЕНЫЕ остатки. Иначи только с долей вероятности. А это чревато.
Это почему же? Если оператор ввел не 10 а 100, то как при расчете, так и при хранении получишь ошибку. Если правильно использовать механизм транзакций, то разночтений между хранением/расчетом быть не может. Но вот ресурсов "расчетный" вариант требует на порядки больше. Кроме того, никто не запрещает делать "контрольные" пересчеты для самоуспокоения. 8-)

> Не игрушку ведь пишет.
Вот именно!!!

← →
Сергей Суровцев (2003-10-02 10:08) [24]

Самый главный недостаток этого способа - ограниченость. Мы всегда
имеет остатки ТОЛЬКО на самый последний момент. Оформляя, к примеру документ "задним" числом, а это частая практика Вы этим способом результата на получите, вернее получите, но неверный, что гораздо хуже. К примеру получите остаток 100, хотя приход был позже той даты, на которую оформляют расход, т.е. на момент ТОЙ даты никакого остатка не было. Кроме того часто возникает необходимость получить остатки по опеределенному признаку, к примеру по остаткам от определенной партии. С Вашим подходом необходимо знать ВСЕ варианты выборки ЗАРАНЕЕ, т.к. Вы должны хранить остатки в этом разрезе. Но зачастую никто не может знать заранее все необходимые потребности. Кроме того они могут возникнуть по ходу. И Вам с ВАшим способом придется переписывать код, дабы теперь хранить остатки по другому, а заодно и разбить те, что имеются. И так каждый раз. В то время, как пересчет дает Вам возможность получить ЛЮБУЮ выборку сразу, ничего не меняя и не завися от изменений условий в будущем.
Кроме того работать, особенно в многопользовательской среде
с одной базой гораздо проще, чем с двумя, да и надежнее.
Транзакции, они ведь тоже не гарантия. Намного умнее хорошо
продуманые блокировки.

← →
Sergey13 (2003-10-02 10:29) [25]

2Сергей Суровцев © (02.10.03 10:08) [24]
Такое ощущение, что я предлагал хранить ТОЛЬКО остатки, а все документы движения стирать. Нет, нет и еще раз нет. Хронология операций прихода/расхода никуда не девается и ее можно использовать как угодно для получения остатков на любую дату. Только часто ли (по сравнению с текущим наличием) нужна такая инфа?
Про приход позже отгрузки. Объясни мне темному, зачем это надо, и не является ли это нарушением бизнес правил и просто здравого смысла? Если на складе нет товара, что отгружаем?

>Кроме того работать, особенно в многопользовательской среде
с одной базой гораздо проще, чем с двумя, да и надежнее.
Ты про что это? Какие 2 базы?
>Транзакции, они ведь тоже не гарантия. Намного умнее хорошо
продуманые блокировки.
Здрасьте. Дожили.

← →
SergeyKatruk (2003-10-02 16:30) [26]

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

← →
MsGuns (2003-10-02 17:01) [27]

>Sergey13 © (02.10.03 10:29) [25]
Мне приходилось писать подобные программы много раз и я использовал как метод с остатками, так и без (подсчитываемыми по мере необходимости из движения). На основании опыта могу боле-менее ответственно заявить, что если хранить остатки, то сальдовые, т.е. на начало периода (обычно - месяца). Это оправдано в больших комплексных системах, где учет ведется не только складской, но и бухгалтерско-экономический. В этих системах блокировка лазания в закрытый период - достаточно жесткое требование. Но если все же надо, то система пересчитывает все сальдовые остатк, начиная с 1-го месяца, следующего за "тронутым".
Хранение же текущего остатка часто не имеет смысла (если еще учесть такие вещи как резервирование, некондиция, подготовленный к отгрузке и оплаченный, но не вывезенный и т.д.), т.к. при достаточно интенсивной работе с БД вероятность его ошибочности (т.е. несоответствию с кол-вом, находящимся в данный момент на складе) плавно катится к цифре 100.

Прошу дать мне рекомендации Найти похожие ветки