Форум: "Базы";
Текущий архив: 2003.09.29;
Скачать: [xml.tar.bz2];
Вниз
Расчет остатков Найти похожие ветки
← →
Виталий Панасенко (2003-09-10 08:56) [0]Я в этом форуме много хорошего слышал о методе расчта складских остатков "на лету", т.е. по приходно-расходным документам. Можно узнать основные "краеугльные камни" данного метода ?.. Меня интересуют такие моменты: по всем ли документам нужно вести подсчет или должен быть какой-то период, на начало которого рассчитанные остатки заносятся каким-то документом из предыдущего периода, хранить приходно-расходные в одной таблице или можно разнести по разным и тд и тп... Если несложно ответить.. Или напишите на мой e-mail.
Спасибо.
← →
Anatoly Podgoretsky (2003-09-10 09:12) [1]Это смешанный вариант, работа с остатками плюс движение, иногда остаток в таблице определяют как прихо/расход, а движение удаляют, зачем это нужно трудно сказать, я бы понял если бы речь шла о файл/серверных базах. Но так делают.
Другой вариант это когда в отдельной таблице содержатся остатки на начало периодов, например по месяцам.
Ну и третий вариант когда остатки отсутсвую как класс.
У всех трех методов естественно есть преимущества и недостатки, притом разные люди могут считать эти преимущества недостатками и наоборот, зависит от идеологии и вложенных критериев и бизнес правил.
Вот если ты объяснишь, что для тебя премущества, а что недостатки то тебе поскажут вариант, но если ты сможешь это объяснить, то тебе и не потребуется отчет.
← →
Danilka (2003-09-10 09:13) [2]Думаю, зависит от задачи. если в день 1-2 приходно-расходных документа, то остатки на лету будут рассчитываться быстро в течении нескольких лет, а т.к. сервер к тому времени морально стареет, купят новый и его хватит еще надолго. :))
А так, мое мнение, правильнее сделать периодами. Период - месяц, или квартал - зависит от задачи. В таблице констатнт писать дату последнего закрытого периода. При закрытии периода - рассчитывать все остатки. Запретить проводить документы, дата которых меньше даты конца последнего закрытого периода. Если очень надо - пусть открывают заново период, проводят и потом опять закрывают, но лучше обойтись без этого, иначе возможны отрицательные остатки на складах. Лучше давить бухгалтеров которые проводят док-ты задним числом. Или заставлять их перепроводить все документы, после проведенного "задним числом" - пусть порадуются жизни.
А остатки рассчитывать так, брать остатки на конец закрытого периода, а до необходимой даты уже рассчитывать "на лету".
← →
dima_shapkin (2003-09-10 09:50) [3]Действительно все зависит от СУБД. Первый вариант расчета на лету дает наибольшую вероятность правильности расчета остатков.
И гемороя меньше. Например, в моем случае CУБД Oracle, без всяких тормозов расчитывались остатки по нескольким тысяч позиций товара по нескольким десятков складов и в таблице движения товара было порядка 100000 записей. Есенно все максимально было оптимизированно. Если будут тормоза можно применять снэпшоты, опять же все это в случае с Ораклей.
Если уж совсем в немноготу то можно придумать и закрытие периода, и конечно предусмотерть откат с возможность пересчета всех остатков. Многи дрочливые бух. проги типа Бэста и 1сэ закрывают период без возможности отката.
← →
DenK_vrtz (2003-09-10 10:11) [4]dima_shapkin ©, вопросик.
>>Например, в моем случае CУБД Oracle, без всяких тормозов расчитывались остатки по нескольким тысяч позиций товара по нескольким десятков складов и в таблице движения товара было порядка 100000 записей.
По времени сколько?
← →
Виталий Панасенко (2003-09-10 10:17) [5]А документы как организовать ? Держать все в одной таблице или можно распределить на приходные/расходные ? И можно механизм (собственно макет запроса) подсчета остатка ? Допустим, в моем случае есть разграничение товара по нескольким признакам: Владелец, Код-Товара, Поставщик, Цена_Прихода, Цена_Расхода, Количество_В_Упаковке. Как мне тут поступить ?
← →
Mike Kouzmine (2003-09-10 10:29) [6]dima_shapkin © (10.09.03 09:50) [3] У бэста есть возможность отката. Возможно, и 1С имеет.
← →
Виталий Панасенко (2003-09-10 10:32) [7]И еще одна проблема: отсутствие отрицательного остатка на складе. Имея таблицу остатков, я указываю что-то типа Saldo numeric(9,3) check (saldo>=0.000)
Если взять вариант (хотя в принципе любой из предложенных), когда остатки отсутсвуют "как класс", как мне это дело "обскакать" ? В однопользовтельском режиме вроди проблем нет - подсчитал, смотришь что будет если отнимешь... А если много пользовательский ? Ведь за этот промежуток времени кто-то другой может списать товар ? Как тут выкручиваются люди ?
← →
Mike Kouzmine (2003-09-10 10:38) [8]Существует такое понятие "Складские остатки на утро/вечер (или что угодно)"
Можно ночью считать остаки. А днем, в отчетах или запросах пересчитывать. Правда все это туфта, если задним числом правят движение.
← →
Sergey13 (2003-09-10 11:00) [9]2Виталий Панасенко (10.09.03 10:32) [7]
>И еще одна проблема: отсутствие отрицательного остатка на складе. Имея таблицу остатков, я указываю что-то типа Saldo numeric(9,3) check (saldo>=0.000)
Именно эта проблема и отличает по большому счету два варианта налету/не на лету, ИМХО. Т.е. говорит в пользу хранения остатка и обработки его тригерами. В этом случае никто не мешает иногда пересчитывать их, для контроля или корректировки например. Кроме того затараты серверных ресурсов в разы меньше и то что это у кого то работает быстро не показатель. Возможно при этом другое работает медленнее.
Я за хранение. Как? Дофига вариантов.
← →
kaif (2003-09-10 12:14) [10]Как правило проблема расчета остатков пересекается с проблемой расчета их стоимости (сбестоимости). Здесь важно принять решения по методам расчета себестоимости. Дело в том, что разумно было бы придерживаться такого правила: на момент вставки документа отгрузки берется средняя себестоимость по каждой позиции и списывается. При этом вся история начислений/списаний хранится. При вставке приходного/расходного документа задним числом может возникать некоторое нарушение в списанных себестоимостях. Однако ИМХО совсем не обязательно все "перетряхивать" из-за этого, как делает, например, 1С. Ведь в будущем эти цифры все равно будут учтены в новых отгрузках и скомпенсируют мелкие прошлые ошибки. Но не всегда такой подход встречает понимание. Некоторые заказчики обожают учет ради учета и перерасчеты задним числом. Это противоречит принципу периодизации учета, но они этого не понимают.
Так что сначала нужно разобраться в самой идеологии учета, а уже затем принимать решение.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.09.29;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.063 c