Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Контроль количества в складских операциях

Страницы: < 1 2
Tormoz © (2005-02-17 12:46:00)
Уважаемые Коллеги!

Вот такая тема:

Есть складская программа. Рассмотрим метод списания товара со склада по FIFO(принципиально даже не FIFO, а то что товар лежит на складе "докучи").

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

Чем определяются Допустимый диапазон списания по количеству?

Если это списание последнее по дате для данного товара,
то допустимый Максимум - это кол-во требуемого товара на складе( Весь приход "минус" Весь расход) .

Если это списание задним числом (вполне возможная ситуация по разным причинам: например,
не редкость в момент внедрения программы), то Максимум - это, опять же, Весь приход "минус" Весь расход на дату списания,
а так же "минус" кол-во этого товара заимствованное списаниями из будущих дат (тоже возможно).

Допустимый Минимум по кол-ву списываемого товара - это Сумма кол-ва всех возвратов по тек. строке текущего расходного документа.

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

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

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

В результате(если не рассмматривать возможность возвратов Поставщику ), получилось что-то на подобие сберегательной книжки:
ПРИХОД/РАСХОД/ОСТАТОК, где в цикле от тек. приходной строки я контролирую, чтобы остаток не ушел в минус.
Когда он уйдет в минус, Бог его знает?
Да и случится ли это вообще?

Поделитесь опытом, мыслями, если кто воплощал более красивую реализацию, буду признателен!

Polevi (2005-02-17 14:37:00) [21]
я сторонник того что проведеный документ нельзя менять
производители крупных ERP систем тогоже мнения
для корректировок у меня существует специальный тип сторнирующих документов

Polevi (2005-02-17 14:32:00) [22]
>Petr V. Abramov © (17.02.05 14:29) [3]
я работаю с MS SQL и с чего ты взял что у автора поста IB

Petr V. Abramov (2005-02-17 14:29:00) [23]
> делается одним IF EXIST(SELECT ...)
Лихо!
Ведь IB/FB - версионник, то, что exists в контексте одной транзакции, в контексте другой может уже давно не exists

msguns (2005-02-17 13:52:00) [24]
>Polevi © (17.02.05 13:23) [1]

Совершенно справедливо ! Работает безотказно в обоих общепринятых системах учета: по товарам и по поставкам (партионный учет).

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

Есть другой метод, используемый в учете "по товару". Это хранение сальдовых остатков по товару. В этом случае забор остатка осуществляется по описанной в [1] схеме, однако отсутствует понятие "проводка зависимых документов". Т.е. перед редактирование документа, товар как бы "возвращается" на склад (для приходов - убирается), а после изменения - забирается (поступает). При откатах и правках документов и выписке новых активно используются текущие (для документов прошлых периодов - сальдовые соотв.месяца), блокирующие снятие кол-ва, превышающее наличия либо на тек.момент (док-ты тек.периода) либо на конец месяца (док.прошлых месяцев).

Polevi (2005-02-17 13:23:00) [25]
не надо контролировать "кол-ва редактируемой позиции в приходном документе"
у документа 2 состояние - не проведен и проведен
контроль остатков необходимо делать в момент проаедения, делается одним IF EXIST(SELECT ...)
редактирование списаных документов запрещать

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »