Итоги по регистру остатков - когда они рассчитываются? #229400

Такая вот тема. Есть большая база - 10^7 записей по регистру остатков. Ну, большая, небольшая, а 5 гигов в непроведённом состоянии весит. Задача - надо провести все документы. Условие - разумеется, с максимальным быстродействием. Я провожу встроенными средствами 1С - "Проведение документов" Остатки при каждом проведении документа "Продажи" (наиболее ресурсоёмкий  документ) я получаю запросом к ВТ. И что я держу при этом в памяти (своей)..? Что поскольку все документы проводятся последовательно – итоги должны быть всегда актуальны. То есть, эти итоги вообще нечего считать – всегда бери их на 3999 год – и всё будет здорово.. Но наблюдение за процессом проведения заставило задуматься, и докопаться до сути происходящего. Чёрт его знает, что происходит в недрах 1С. Я выделил три, на мой взгляд возможных варианта. 1.    Данные берутся из «Актуальных остатков» - максимальное быстродействие. 2.    Данные рассчитываются от последних рассчитанных итогов – 1С хранит их с периодичностью «Месяц» - быстродействие падает на порядок. 3.    Данные рассчитываются С НАЧАЛА проведения документов, с нулевых остатков – о быстродействии тут говорить не приходится, о каком-то КПД тоже – И ЭТО КАТАСТРОФА. И у меня есть подозрения, что события развиваются по третьему варианту. Почему: Contra 1.    ВО первых – чем больше доков проведено – тем медленнее они это делают. Значительно медленнее. Во вторых – в большой и тяжёлой книге сказано, что итоги будут извлекаться из таблицы итогов, если в запросе передать Период либо НЕОПРЕДЕЛЕНО, либо «Дата по умолчанию». В моём случае – ПЕРИОД – дата документа – хоть она и всегда больше дата последней записи в регистре. Значит ли это – что на первый вариант мне рассчитывать не приходится? 2.    Ну туда-сюда – хоть так. Но я посмотрел периоды в таблице AccumRegTotals – они там нифига не с месячной периодичностью! Там начальная дата – дата начала проведения! Вот когда я их вручную рассчитал (с помощью «Управление итогами») – вот тогда они и появились за каждый проведённый месяц. Я, признаться, думал, что ИТОГИ РАССЧИТЫВАЮТСЯ САМОСТОЯТЕЛЬНО!! 3.    Из второго пункта CONTRA следует, что верен 3-ий вариант. Это так? Я пошёл вешаться… Поделитесь соображениями, господа, пожалуйста… Мне бы очень хотелось к утру провести базу. При нынешнем темпе – это нереально. Мысль такая – в процедуру глСписаниеТоваров, в запросе к остаткам поставить Период=Неопределено – и погнали… Спасибо.

1. Расчет остатков по регистру накоплений на дату документа будет считаться примерно таким способом, берется остаток на дату актуальности итогов и вычитаются все движения до даты документа. На партнерском форуме приведен такой пример: "(...) например, для того чтобы рассчитать остаток на 01.06 от рассчитанного актуального остатка «вычитаются» все движения за период, начиная с 01.06. Соответственно, получение остатка на начало месяца будет занимать большее количество времени, чем в конце." # 2. Совет из той же ветки: "Чтобы минимизировать временные затраты на обработку записей в таблице движений регистра, перед выполнением перепроведения по партиям можно попробовать удалить из партионных регистров движения, сформированные предыдущем проведением по партиям."

Ну, Дата актуальности итогов - это неясное в данном случае определение, и, собственно, вопрос в этом и состоял - что считается актуальными итогами? А что касается "совета из той же ветки" - то я не понял - к чему он? Странно - когда я формирую отчёты (с разной периодичностью) - то они строятся - будто рассчитаные итоги в AccumRegTotal есть. Но когда они там появляются? КОгда я доки провожу обработкой - их там нету.

Совет в п.2 был дан сотрудником фирмы 1С по поводу жалобы партнера на долгое перепроведение документов в начале периода. По поводу итогов - выскажу предположение - что доки ты проводишь обработкой в транзакции и значит итоги у таблице у тебя появятся только после успешного завершения транзакции.

"что доки ты проводишь обработкой в транзакции и значит итоги у таблице у тебя появятся только после успешного завершения транзакции." - это неправильно. чтоб остатки брались из таблицы на 3999 год (типа ТА) - надо анализировать РежимПроведения - если оперативный - брать остатки без указания Периода.

А будут ли доки проводится оперативно при перепроведении прошлых периодов?

если в базе нет более поздних проведенных документов - да. И судя по у автора именно такая ситуация.

Всеже, думаю автор напоролся на ситуацию описанную в , когда при происходит долгое перепроведении документов прошлыми периодами.

Режим проведения - всегда неоперативный. Нет. Я перед гипер-проведением вообще уничтожаю ВСЕ записи в регистрах - то есть как бы могло перепроводиться и в оперативном режиме, но я его отключил -только лишние менюхи вылезают. То есть - никаким прошлым периодом и не пахнет. Про транзакции вроде бы мысль дельная, но... У меня 5 гигов за три года - я конца бы никогда не дожался бы - а я дожидался. Вся база проводится за трое суток - хочется убыстрить, где возможно. У меня такая мысль. В 1С есть закладка - управление итогами. Может ли быть такое - что именно она управляет периодичностью рассчитанных итогов? Скажем, если я ставлю дату рассчитанных итогов 01.01.2008 - то итоги у меня появляются с самого начала деятельности и по указанную дату,с периодичнстью в месяц. Понятное дело, что проведение документов начинает тормозить - движок обновляет итоги за каждый месяц до 2008 года - быстро это не будет... Получается - при пакетном проведении за большой период- нужно 1. Сделать так, чтобы система не обновляла промежуточные итоги - зря потраченное время. 2. именно брать итоги на 3999 год, причём, система автоматически этого не делает, похоже.. Я поигрался с Profiler - и увидел, что если выставить период=НЕОПРЕДЕЛЕНО, то он использует ТОЛЬКО таблицу _AccumRegTotal, а вот если использовать период=Док.МоментВремени - тогда он результаты начинает ОБЪЕДИНЯТЬ из _AccumRegTotal с _AccumReg***. И ЭТО НЕ СМОТРЯ НА ТО, ЧТО ПоследняяЗаписьВРегистре<МоментВремениПолучаемыхОстатков<Итоги 3999 года И вроде всё понятно, и можно с этим жить - но не даёт покоя одна вещь - я озаботился этой фичей только недавно - а отчёты у меня ваялись достаточно быстро - с адеквтной периодичностью (год,месяц,день и т.п) - когда же они в таком случае рассчитываются??

Управлять периодичностью итогов нельзя, она намертво защита в систему и равняется месяцу. Чтобы система не обновляла итоги нужно просто перед проведение отключить расчет итогов, а потом его включить, с помощью: То что ты видел в профайлере - это алгоритм словами был озвучен на партнерском форуме и его уже приводил в

Мы вообще говорим о разных вещах. В принципе. Чтобы система не обновляла итоги нужно просто перед проведение отключить расчет итогов, ЗАЧЕМ МНЕ ЭТО? Соответственно, получение остатка на начало месяца будет занимать большее количество времени, чем в конце. ПоследняяЗаписьВРегистре<МоментВремениПолучаемыхОстатков<Итоги 3999 года

"что доки ты проводишь обработкой в транзакции и значит итоги у таблице у тебя появятся только после успешного завершения транзакции." - это неправильно. Почему тогда их(итогов) нету?

Написал же перед проведением отключить, а потом включить и пересчитать итоги. "Почему если ПоследняяЗаписьВРегистре<МоментВремениПолучаемыхОстатков<Итоги 3999 года" и  формируется запрос к двум регистрам AccumRegTotal и _AccumReg? Честно, не знаю такая вот внутренняя структура работы с регистрами остатков 1С.

Дружище, я может дурной, но объясни мне - как я ПЕРЕД проведением отключу РАСЧЁТ ИТОГОВ, если САМ СМЫСЛ проведения заключается в постоянном анализе ЭТИХ ИТОГОВ???

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

Я тебя понял. Но у меня их всего два. И остатков из них - один. %)

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

Хм... Хорошо помнится?

Я сказал глупость, а меня никто не поправил. :) "Странно - когда я формирую отчёты (с разной периодичностью) - то они строятся - будто рассчитаные итоги в AccumRegTotal есть. Но когда они там появляются? КОгда я доки провожу обработкой - их там нету." Разная ПЕРИОДИЧНОСТЬ - свойство РЕГИСТРА ОБОРОТОВ, А НЕ ОСТАТКОВ! Итоги оборотов - в таблице AccumRegTurnOver - вот там-то все итоги есть. Запутался я в таблицах и отчётах - что к чему обращается. В общем - я просёк всю тему.

Хм-м-м... Нет, не до конца просёк. Запрашиваю остатки на 01.05.2006 Итоги рассчитаны по 30.12.2005 ВРемя выполенния - 50 секунд. Рассчитываю итоги на 30.10.2006 (Долго) Беру остаток на 01.05.2006 (думаю про скорость) Время выполнения - всё те же 50 секунд. Почему???? Ведь в первом случае программа считает от актуальных остатков на 3999 год, вычитая все движения, а во втором она должна считать от ДатаЗапроса+Месяц, что по времени должно быть быстрее. Но быстрее не получается....