Расчет регистров накопления (остатков) #153167

В типовых при начале работы вызывается процедура ОпределитьНеобходимостьПерестановкиГраницыИтогов, которая предлагает выполнить метод регистра УстановитьПериодРассчитанныхИтогов. Так вот если, скажем, у меня база за три года и я установил период на 2006 год, то документ 2003 года только записывается (до алгоритма проведения даже еще не доходит!) в базу 15 минут, а, если на конец месяца даты документа, то запись + проведение занимает 15 секунд :o) Вопрос: если нужно перепровести документ за 2203 год, то что делать, устанавливать период на 2003 год?

Да

Эээ..., прочитал свой пост, ошибся, не 2203, а 2003 год :o) Время установки периода примерно полчаса :o)

А зачем перепроводить документы за 2003 год?! Причины для этого придумать не могу

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

Я ждал этого вопроса :)) Но ветка не об этом :))

Мда, вот если спросить про ВыборГрупп или определение модуля числа, сразу вагон напишут, а чуть посерьезнее и... приплыли :o)

В общем-то прихожу к выводу, что в случае, если нужно использовать много разрезов в регистре накопления остатков (типа контрагент, договор, документ расчетов и т. д.), кои все можно взять из одного измерения (документ расчетов), то лучше использовать одно измерение, а в запросах образщаться к этим измерениям через точку. Плюсы: 1. Повышается скорость установки периода расчитанных итогов 2. Повышается скорость движений 3. Упрощается код по записи движений, мелочь, а приятно :)) Минусы: 1. В запросах приходится делать неявное соединение с таблицей документа, да и *** бы с ним, все-расно соединение только одно :o)

ну не знаю... ИМХО проведение позапрошлогодних документов не каждый день делается, а вот скорость выполнения запросов - весчь критичная ИМХО

В том-то и дело, что имхается мне, что скорость запросов почти не пострадает, а вот перепроведение в моем случае делается очень часто и перепроводится много доков :o)

пострадает, будь уверен. а почему так часто делается перепровдение?

Закачал в восьмерку из 7.7 100 000 доков клиента, остальные потом :)) Сначала сделал регистр расчетов с клиентами с кучей измерений, все тормозит не по детски :o) Сейчас пробую с одним измерением, вот запросы и посмотрим :)) А перепроведение часто потому, что обнаруживают ошибки разного типа в прошлых годах, а кроме того, долги и поступление денег чередуются по времени, доки приходят и забиваются в базу с опозданием :o)

В общем-то пока не смотрел отчеты, но с записью  и проведением доков эффект совершенно налицо: - при границе на начало 2006 года и кучей измерений запись и проведение дока в начале 2002 года занимает 15 минут - при границе на начало 2002 года и кучей измерений запись и проведение дока в начале 2002 года занимает 15 секунд - при границе на начало 2006 года и одним измерением запись и проведение дока в начале 2002 года занимает 1 секунду Осталось тестануть отчеты :))

Мда, отчеты просто сдохли :( Как по времени выполнения, так и по количеству отжираемой озу Мдя, приходится искать компромисс между скоростью формирования отчетов и количеством измерений :o)

Ну вот сам и решил все свои проблемы..

Я уже давно привык, что на мои вопросы как правило не отвечают :))

Что лучше, много реквизитов в регистре накопления или один регистр с доступом через точку? Как ускорить работу с регистрами накопления? В чем смысл жизни? ТелепатБот, ответь

Что молчим? ТелепатБот, ответь, зараза молчаливая :o)

Правильной проектировкой БД В регистре должно быть только необходимое (особенно ресурсы), иначе лучше 2 сделать. Плюс индексация, но только там где действительно надо. Как сделана УПП и УТ в этом смысле - это ужос

Хотя из 1С говорят: увеличивайте мощность серверов