При переходе с версии ЗУП 3.1.9 на 3.1.10 (а также на некоторые промежуточные релизы) многие администраторы и программисты сталкиваются с критической ошибкой выполнения отложенного обновления программных данных. Проблема локализуется в процедуре Документы.ВозвратИзОтпускаПоУходуЗаРебенком.ЗаполнитьДвиженияЗанятостьПозицийШтатногоРасписания.
Текст ошибки в журнале регистрации обычно выглядит следующим образом:
«Превышено допустимое количество запусков процедуры обновления. Выполнение прервано для предотвращения зацикливания механизма обработки данных».
В этой статье мы подробно разберем, почему возникает эта ситуация, как проанализировать проблемный код и какие шаги предпринять для успешного завершения обновления.
Для начала проанализируем, как работает механизм отложенного обновления в Библиотеке стандартных подсистем (БСП), на которой построена ЗУП. Когда конфигурация запускает обработчики обновления, она отслеживает количество итераций для каждой процедуры. Если один и тот же обработчик запускается многократно (обычно более 20-50 раз), но очередь данных для обработки не уменьшается, система делает вывод, что алгоритм «зациклился», и принудительно останавливает процесс.
В нашем случае процедура пытается дозаполнить движения по регистру ЗанятостьПозицийШтатногоРасписания для старых документов ВозвратИзОтпускаПоУходуЗаРебенком. Если по какой-то причине документ не может создать эти движения, он остается в выборке запроса и при следующем запуске фонового задания выбирается снова.
Рассмотрим фрагмент кода из модуля менеджера документа, который вызывает проблему:
Процедура ЗаполнитьДвиженияЗанятостьПозицийШтатногоРасписания(ПараметрыОбновления = Неопределено) Экспорт
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 1000
| ТаблицаДокумента.Ссылка КАК Регистратор
|ПОМЕСТИТЬ ВТРегистраторыКОбновлению
|ИЗ
| Документ.ВозвратИзОтпускаПоУходуЗаРебенком КАК ТаблицаДокумента
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КадроваяИсторияСотрудников КАК КадроваяИсторияСотрудников
| ПО ТаблицаДокумента.ОсновнойСотрудник = КадроваяИсторияСотрудников.Сотрудник
| И (КОНЕЦПЕРИОДА(ТаблицаДокумента.ДатаВозврата, ДЕНЬ) >= КадроваяИсторияСотрудников.Период)
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗанятостьПозицийШтатногоРасписания КАК ЗанятостьПозицийШтатногоРасписания
| ПО ТаблицаДокумента.Ссылка = ЗанятостьПозицийШтатногоРасписания.Регистратор
| ГДЕ
| ТаблицаДокумента.Проведен
| И ЗанятостьПозицийШтатногоРасписания.Регистратор ЕСТЬ NULL
| И НЕ КадроваяИсторияСотрудников.Сотрудник ЕСТЬ NULL";
КонецПроцедуры
Обратим внимание на условие ЗанятостьПозицийШтатногоРасписания.Регистратор ЕСТЬ NULL. Программа выбирает первую тысячу документов, по которым еще нет записей в регистре. После этого она пытается их провести или пересчитать. Если после выполнения процедуры записи в регистре так и не появились, этот же документ снова попадет в ПЕРВЫЕ 1000 при следующем запуске. Это и есть техническая причина «бесконечного цикла».
Как показывает практика, чаще всего виноваты не ошибки в коде 1С, а логические коллизии в данных кадрового учета. Основной сценарий, приводящий к ошибке: сотрудник был уволен раньше или в тот же день, когда оформлен возврат из отпуска по уходу за ребенком.
Выясним причину, выполнив следующие действия:
Увольнение.Если мы находим ситуацию, где ДатаВозврата в документе стоит, например, 15.06.2023, а сотрудник уволен 14.06.2023, то типовой механизм проведения не сможет корректно отразить занятость позиции штатного расписания, так как на дату возврата сотрудник уже не является штатной единицей.
Разберем, как исправить такие документы:
Возврат из отпуска по уходу за ребенком является ошибочным или дублирующим, его следует пометить на удаление.Перед повторным запуском обновления после исправления данных, рекомендуется выполнить рекомендации службы поддержки 1С:
chdbfl.exe (для файловых баз) или выполните Тестирование и исправление в конфигураторе (с включенными опциями проверки логической и ссылочной целостности).srvinfo (конкретнее — каталоги с именами GUID баз).Рассмотрим ситуацию, когда последовательное обновление через файлы .cfu не помогает. Опытные специалисты рекомендуют обновляться сразу на актуальный стабильный релиз, используя полный файл конфигурации (.cf).
Проанализируем почему это эффективно: в полной конфигурации список обработчиков обновления содержит все необходимые процедуры для прыжка через несколько версий. Часто разработчики 1С выпускают исправления для алгоритмов обновления в более поздних патчах. Обновив конфигурацию до версии 3.1.10.78 или выше с помощью .cf, вы получите исправленный код обработчика, который может игнорировать некоторые ошибки данных, не входя в бесконечный цикл.
Важный момент: Даже при обновлении через .cf, процедура отложенного обновления данных всё равно должна быть запущена и завершена без ошибок. Проверить статус можно в разделе Администрирование — Обслуживание — Результаты обновления программы.
Для успешного решения проблемы проанализируйте документы Возврат из отпуска по уходу за ребенком на предмет логических ошибок в датах относительно Увольнения. После исправления данных и очистки кэша процедура обновления должна завершиться штатно. Помните, что механизм защиты БСП от зацикливания — это индикатор того, что стандартный алгоритм не может «переварить» конкретную запись в вашей базе данных.