Чёрный пояс 1С. Разделение итогов в регистре: снимает блокировки записи, но не спасёт при контроле остатков

11 июня 2026 · infolimp.ru

Конец месяца, операторы массово проводят документы, и база встаёт: «Конфликт блокировок при выполнении транзакции». Виноват при этом не «слабый сервер» и не «кривая конфигурация» — одна из самых частых причин в клиент-серверной базе: две транзакции честно подрались за одну и ту же строку итогов регистра. Точного виновника покажет технологический журнал, события ожиданий на блокировках; дальше — про случай, когда он указал на итоги. Если вы хоть раз разводили такую пробку руками, разберём механизм, который для этого и придуман.

Вопрос с собеседования

Каким образом свойство «Разрешить разделение итогов» в регистре бухгалтерии предотвращает блокировки при массовом параллельном проведении документов? И в каком сценарии оно не поможет вообще?

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

Откуда берётся блокировка

Сразу граница применимости: разговор про клиент-серверную базу — в файловом режиме конкуренции транзакций в этом смысле просто нет. Итоги регистра — бухгалтерии или накопления — физически лежат в отдельной таблице СУБД. Без разделения итогов остаток по конкретному счёту и аналитике за период — это одна строка. Каждое проведение документа, задевающего этот счёт, выполняет обновление этой строки: прибавляет своё движение к хранимому итогу.

Дальше арифметика конкуренции. Два оператора проводят два разных документа по одному счёту — оба документа должны изменить одну и ту же строку итогов. СУБД выстраивает их в очередь: пока транзакция первого не завершится, второй ждёт. На живом документообороте, где половина проводок крутится вокруг 60, 62 и 41 счетов, эта очередь и превращается в «конфликт блокировок» — документы разные, аналитика разная, а строка итогов общая.

Что меняет разделение итогов

С включённым свойством «Разрешить разделение итогов» платформа хранит итог не одной строкой, а несколькими: в таблице итогов появляется служебное поле-разделитель, и каждая пишущая транзакция вместо обновления общей строки добавляет свою строку-приращение. Вставка новой строки чужих строк не трогает — двум параллельным проведениям больше нечего делить, и в типичном клиент-серверном сценарии очередь на строке итогов исчезает.

Цена этой развязки — чтение: чтобы получить остаток, платформа теперь суммирует группу строк, а не берёт готовое значение. Поэтому строки-приращения периодически сворачиваются обратно в компактный вид — это происходит при пересчёте итогов. Механизмом можно управлять и программно: у менеджера регистра есть методы УстановитьРазделениеИтогов() и ПолучитьРазделениеИтогов(), ими же пользуется стандартная обработка «Управление итогами» (Все функции → Стандартные). Типичный приём: на время массовой загрузки — в монопольном окне, не при активных пользователях — разделение включают, а после свёртки оценивают, нужно ли оно в штатном режиме.

Вторая половина вопроса — где это не работает

А теперь каверза, ради которой вопрос и задают. Разделение итогов помогает только «слепой» записи: транзакция добавляет движения и не интересуется, что в итогах лежит. Как только документ в той же транзакции читает остатки — например, контролирует отрицательные остатки при оперативном проведении — выигрыш исчезает. Прочитать «сумму всех строк-приращений» и принять по ней решение можно, только гарантировав, что параллельно никто не дописывает свои приращения. То есть честный контроль остатков всё равно сериализует доступ — уже на уровне управляемых блокировок, которые вы ставите сами: набор записей с БлокироватьДляИзменения или явная управляемая блокировка на измерения, по которым читаете.

Что спросить себя на проекте

• Кто на самом деле дерётся? Посмотрите, на чём висят ожидания: если на таблице итогов — разделение поможет; если на управляемых блокировках — проблема в логике контроля остатков, и решать её надо там.
• Нужен ли контроль здесь и сейчас? Для регистров, где отрицательный остаток невозможен по смыслу (выручка, обороты по услугам), контроль не нужен — там разделение итогов раскрывается полностью.
• Что с чтением? Отчёты по регистру с разделением чуть дороже до свёртки строк. При умеренном объёме деградация чтения обычно незаметна, но она растёт с числом несвёрнутых строк-приращений: на нагруженных регистрах измерьте ключевые отчёты до и после, прежде чем включать.

Свойство одно, а решения два разных: развязать запись — галочкой, развязать «прочитал и записал» — головой. Платформа честно делает первое и принципиально не может сделать второе за вас. Кандидат, который объясняет эту разницу и может привести пример, где одного разделения итогов не хватило, скорее всего разбирал пробку на проде — таких и берите.