Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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
8-96305
zumozzz
2003-06-04 07:22
2003.09.29
Язык


3-96062
Фикус
2003-09-10 13:31
2003.09.29
dbf -> interbase (2)


6-96335
IBSN
2003-08-01 11:05
2003.09.29
ClientSocket


1-96266
explorer
2003-09-17 07:12
2003.09.29
Защита программ от взлома и копирования


1-96168
scorpi
2003-09-16 12:54
2003.09.29
События объекта





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский