Пересчёт итогов в 1С: когда ускоряет отчёты, а когда впустую съедает регламентное окно
Что такое «итоги» в 1С
Итоги — это предрассчитанные таблицы остатков и оборотов на конец каждого периода, которые платформа хранит рядом с реальными движениями регистра. Когда отчёт спрашивает «остаток на 1 января 2025» — платформа берёт его готовым из итогов, не пересчитывает миллион движений с начала эксплуатации. Это и есть основа скорости отчётов на больших базах.
У каких регистров есть итоги
- Регистры накопления с видом «Остатки» — да, есть итоги остатков и оборотов;
- Регистры накопления с видом «Обороты» — есть итоги оборотов (без остатков);
- Регистр бухгалтерии — есть итоги (в нём корреспонденция счетов делает это сложнее, но механизм тот же);
- Регистры сведений и регистры расчёта — итогов в обычном смысле нет.
Когда пересчёт реально ускоряет работу
Сценарий 1: данные «задним числом»
Бухгалтер провёл документ февраля в ноябре. Платформа отметила итоги «начиная с февраля» как требующие пересчёта. Если регламент пересчёта не отработал — каждый отчёт по остаткам на дату после февраля начнёт читаться медленно, потому что платформа честно пройдётся по всем движениям, не доверяя «протухшим» итогам. Пересчёт после массовой загрузки задним числом — реальная польза.
Сценарий 2: после переноса данных или загрузки исторических документов
Импорт пятилетней истории документов через обмен или ручной перенос. Все эти проводки помечают итоги как неактуальные. Без пересчёта первая выборка остатков на «любую дату из импортированных» будет страшно медленной.
Сценарий 3: после смены состава измерений регистра
При обновлении конфигурации добавили или убрали измерение в регистре накопления. Платформа после реструктуризации пересчитывает итоги сама — но иногда регулярная регламентная операция в первые дни после такого обновления действительно ускоряет работу, добивая фоновый пересчёт.
Когда пересчёт — пустая трата времени
База, в которой никто не правит документы задним числом
Если все документы проводятся «сегодня» и редко перепроводятся за прошлые периоды — итоги и так всегда актуальны. Ежемесячный пересчёт ничего не «доделает». Он только нагружает диск и удлиняет регламентное окно.
Маленькая база
На базах примерно до 100 000 движений в активном регистре разница от пересчёта итогов чаще всего малозаметна — но это надо подтвердить замером (см. фрагмент кода ниже), а не считать правилом: бывают сложные запросы или редкие СУБД-конфигурации, где даже на такой базе итоги дают выигрыш.
Отчёты по «текущему моменту», не по дате
Если отчётность всегда выводит «остатки на текущий момент» (виртуальная таблица Остатки() без параметра даты), платформа читает самую свежую таблицу итогов — при условии, что расчёт итогов в принципе включён и граница рассчитанных итогов охватывает текущий период. При выключенном расчёте или сильно смещённой границе даже «текущие» остатки могут читаться медленно.
Как измерить, есть ли смысл
Прежде чем «на всякий случай раз в месяц» — замерьте. Простейший способ — выполнить тестовый запрос к итоговой таблице на дату, где предположительно есть «протухшие» итоги, и зафиксировать время.
// Замер длительности запроса к виртуальной таблице итогов.
// Имя регистра — для УТ 11 / ERP; в БП 3.0 подставьте свой регистр остатков товаров.
ДатаЗамера = Дата("20250601000000");
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Остатки.Номенклатура,
| Остатки.Склад,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки(&Дата) КАК Остатки";
Запрос.УстановитьПараметр("Дата", ДатаЗамера);
Начало = ТекущаяУниверсальнаяДатаВМиллисекундах();
Результат = Запрос.Выполнить();
Длительность = ТекущаяУниверсальнаяДатаВМиллисекундах() - Начало;
Сообщить("Запрос на " + Формат(ДатаЗамера, "ДЛФ=ДД") + " отработал за "
+ Длительность + " мс");Запустите этот замер дважды: на дату, когда итоги «должны быть актуальны» (например, прошлый месяц без правок задним числом), и на дату, где было перепроведение. Если разница в десятки раз — проблема актуальности итогов реальна, пересчёт оправдан. Если разница в проценты — пересчёт ничего не лечит.
Сравнение ситуаций
| Что у вас происходит | Пересчёт итогов | Лучше делать |
|---|---|---|
| Часто перепроводят документы задним числом | Нужен регулярно | Регламентное задание раз в сутки или после массовых правок |
| Был массовый импорт исторических данных | Нужен разово | Сразу после загрузки, до открытия базы пользователям |
| Документы проводятся только «текущим днём» | Не нужен | Снять регламентную операцию, проверять актуальность раз в квартал |
| База до 100 000 движений в активном регистре | Не нужен | Платформа справляется без итогов; пересчёт не даст разницы |
| Жалуются на медленные отчёты «на дату» | Может помочь | Сначала замерить (см. фрагмент кода выше), потом решать |
Главная ошибка с пересчётом итогов — делать его «по совету в интернете», не измерив свою ситуацию. На разных базах одна и та же регламентная операция или критична, или абсолютно бесполезна. Короткий замер до и после нередко окупается тем, что регламентное окно перестаёт расходоваться впустую.
Чек-лист «решить, нужен ли пересчёт»
- Откройте «НСИ и администрирование → Обслуживание → Управление итогами» (в БП 3.0 — «Администрирование»). Посмотрите, на какие даты у регистров стоит «требуется пересчёт».
- Если в списке есть регистры с признаком «требуется пересчёт за давний период» — это сигнал, что у вас было перепроведение задним числом.
- Возьмите 2–3 тяжёлых отчёта, которые жалуются на медленность, и замерьте их выполнение на «свежей» и «протухшей» дате. Сравните время.
- Если разница в десятки раз — настройте регламент пересчёта в окно низкой нагрузки.
- Если разница в разы (2–5×) — это пограничный случай: смотрите на частоту таких отчётов и стоимость регламентного окна, не запускайте пересчёт «на автомате».
- Если разницы нет — не вешайте ритуальный пересчёт. Снимите старую регламентную операцию, если она была.
- Раз в квартал повторите замер: профиль работы базы меняется со временем.
Типичные ошибки
- «Пересчитываем еженедельно для подстраховки». Без перепроведения задним числом подстраховывать нечего — итоги и так актуальны. Регламент тратит окно обслуживания, ничего не давая.
- Пересчёт всех регистров одной операцией. На большой базе это часы. Если вы знаете, какой именно регистр «протух», — пересчитывайте только его, через интерфейс «Управление итогами».
- Пересчёт во время рабочего дня. Это блокирует регистр на время операции. Только в окно низкой нагрузки, а не «между запросов».
- Жалоба «1С тормозит» → запуск пересчёта как первый шаг. Сначала измерьте, потом действуйте. Часто виновата не актуальность итогов, а тяжёлый запрос, неоптимальный план или блокировки — пересчёт их не лечит.
- Игнорирование «минимального периода рассчитанных итогов». Платформа хранит итоги начиная с определённой даты — обычно «начало эксплуатации». Если эта дата сдвинута на неудачное место, пересчёт может работать дольше необходимого. Проверьте границу через интерфейс «Управление итогами».
- Без замера до и после. Самая частая ошибка — запустили пересчёт, ничего не замерили, поверили, что «стало лучше». Без цифр сравнения это самообман.
Перейти в каталог решений →