Как исправить ошибку «Превышено допустимое количество запусков процедуры обновления» при переходе на ЗУП 3.1.10

При обновлении конфигурации 1С:Зарплата и управление персоналом 8 на ветку 3.1.10 многие администраторы и программисты сталкиваются с критической остановкой процесса обновления. Система выдает сообщение о том, что выполнение прервано для предотвращения зацикливания механизма обработки данных. Чаще всего это происходит на шагах, связанных с заполнением данных по документам Возврат из отпуска по уходу за ребенком или Отпуск по уходу за ребенком.

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

Разберем причину ошибки: радикальная смена архитектуры штатного расписания

Для начала проанализируем, что именно изменилось в версии 3.1.10. Разработчики 1С перешли от использования регистра накопления ЗанятыеПозицииШтатногоРасписания к новой системе, построенной на базе регистров сведений. Теперь за учет занятости отвечают ЗанятостьПозицийШтатногоРасписания и его вспомогательный интервальный регистр.

Проблема зацикливания (ошибка 30168669) возникает в механизме Библиотеки стандартных подсистем (БСП). Когда обработчик обновления пытается пересчитать движения документа, он натыкается на логическую коллизию в данных (например, накладывающиеся периоды). Система помечает порцию данных как необработанную и пробует запустить процедуру снова. БСП по умолчанию предоставляет 10 попыток. Если после десятого раза ситуация не исправляется, выдается исключение: Превышено допустимое количество запусков процедуры обновления.

Выясним, какие ситуации в данных провоцируют сбой

Проанализируем наиболее частые случаи, на которых спотыкается алгоритм формирования интервалов:

1. Совпадение дат кадровых событий: Сотрудник возвращается из отпуска по уходу за ребенком (документ Возврат из отпуска по уходу за ребенком) и в этот же самый день увольняется или уходит в новый отпуск по беременности и родам.
2. Освобождение ставки: Ситуации, когда в одном документе стоит флаг Освободить ставку, а в другом документе, введенном той же датой, происходит движение по той же позиции штатного расписания.
3. «Грязные» исторические данные: Ошибки часто возникают на документах, которые были перенесены из старых версий (например, ЗУП 2.5). В старой модели записи с совпадающими датами начала и окончания могли существовать, но новая интервальная модель их не приемлет.

Решение 1: Поиск и временное распроведение документов (ручной метод)

Если документов в базе немного, мы можем воспользоваться методом исключения. Рассмотрим алгоритм действий:

1. Запускаем обновление и дожидаемся ошибки. В журнале регистрации или в окне дополнительных процедур обновления фиксируем шаг, на котором произошел сбой (например, шаг 26 или 93).
2. Поскольку система не всегда прямо указывает на конкретный документ, нам придется найти его вручную. Откроем список документов Возврат из отпуска по уходу за ребенком.
3. Попробуем временно снять с проведения документы за последний период (или те, где дата возврата совпадает с датой увольнения/перевода).
4. Повторим выполнение процедур обновления через Функции для технического специалиста — Регистры сведений — Обновление информационной базы.
5. Если процедуры завершились успешно, значит, мы нашли проблемный объект. После завершения всех этапов обновления документ нужно будет провести заново, при необходимости скорректировав время документа или дату события.

Решение 2: Программная корректировка времени событий

Иногда коллизия возникает из-за того, что два документа имеют одинаковое время (например, 00:00:00). Разберем, как можно развести эти события. Если Возврат из отпуска по уходу за ребенком и Увольнение созданы одной датой, попробуем установить время возврата на 09:00:00, а увольнения — на 18:00:00.

Для массовой проверки можно воспользоваться простейшим запросом в консоли отчетов, чтобы найти сотрудников, у которых в один день зарегистрировано несколько кадровых изменений:

ВЫБРАТЬ
    КадровыеПереводы.Сотрудник,
    КадровыеПереводы.Период,
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ КадровыеПереводы.Регистратор) КАК КолДокументов
ИЗ
    РегистрСведений.ДанныеСостоянийСотрудников КАК КадровыеПереводы
СГРУППИРОВАТЬ ПО
    КадровыеПереводы.Сотрудник,
    КадровыеПереводы.Период
ИМЕЮЩИЕ
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ КадровыеПереводы.Регистратор) > 1

Важный момент: Если вы обнаружили такие записи, попробуйте разнести их по времени или убедитесь, что последовательность документов логична с точки зрения программы.

Решение 3: Исправление ошибки с ПЕРВЫЕ и УПОРЯДОЧИТЬ

Существует еще одна техническая ошибка (30168494), которая проявляется на этапе обновления кадрового учета. Она связана с тем, что в коде запроса используется конструкция УПОРЯДОЧИТЬ ПО без использования ПЕРВЫЕ внутри вложенных запросов или при формировании временных таблиц. Это вызывает ошибку на стороне СУБД (особенно на актуальных версиях платформы 8.3.12+).

Если вы столкнулись с сообщением При формировании временной таблицы предложение УПОРЯДОЧИТЬ может использоваться только совместно с предложением ПЕРВЫЕ, необходимо либо обновить конфигурацию до релиза 3.1.10.50 и выше, либо (если вы программист) внести правки в общий модуль КадровыйУчетРасширенный, удалив лишнюю сортировку в проблемном запросе.

Решение 4: Обновление на исправленный релиз

Фирма 1С официально признала данные ошибки и выпустила исправления. Рассмотрим хронологию:

• В релизе 3.1.10.50 была исправлена ошибка с запросом (ПЕРВЫЕ/УПОРЯДОЧИТЬ).
• В релизе 3.1.10.78 и выше значительно доработаны механизмы обработки интервальных регистров для исключения зацикливания.

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

Заключение и выводы

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

Рассмотрим краткий чек-лист при возникновении проблемы:

1. Проверить наличие документов с одинаковой датой события по одному сотруднику.
2. Проанализировать документы Возврат из отпуска по уходу на предмет корректности флага освобождения ставок.
3. Если используется серверный вариант — убедиться, что версия платформы соответствует требованиям релиза.
4. В крайнем случае — временно распровести документы, завершить обновление и провести их заново в новой версии, где механизмы контроля отработают уже в режиме реального времени и подскажут, в чем именно ошибка.