Дополнительная обработка данных после обновления 1С: как устроена и когда ждать её завершения

Отложенное обновление в 1С — это часть перехода на новый релиз, которая выполняется уже после того, как программа открылась и пользователи начали работать. Его выполняет регламентное задание в фоне, а ход работы видно в Администрирование → Поддержка и обслуживание → Результаты обновления программы. Включать его отдельно не нужно: так работают все типовые конфигурации на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11, КА, ERP).

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

Что такое отложенное обновление информационной базы и зачем его придумали

Новый релиз конфигурации почти всегда меняет не только формы и отчёты, но и данные. Появился новый реквизит — его надо заполнить у старых документов. Изменился регистр — в него нужно перенести записи из старого. Такие преобразования делают обработчики обновления — процедуры, которые разработчик конфигурации привязывает к номеру версии.

Если все обработчики выполнять сразу, база с данными за 5–10 лет может обновляться часами. Всё это время пользователи сидят без программы. Поэтому в Библиотеке стандартных подсистем (БСП) обработчики делятся на три режима:

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

💡 Выбор режима для каждого обработчика закладывает фирма-разработчик конфигурации. Бухгалтер или администратор не переводит обработчик из одного режима в другой — он управляет только тем, когда и как быстро идёт фоновая часть.

Как работает отложенная обработка данных изнутри

После установки релиза и первого запуска программа фиксирует, какие отложенные обработчики нужно выполнить, и передаёт их регламентному заданию. Его можно найти в списке регламентных заданий по словам «Отложенное обновление».

Дальше задание идёт порциями:

1. 🔹 Берёт очередной обработчик и пачку объектов, которые он должен обработать (например, 1 000 документов реализации).
2. 🔹 Обрабатывает пачку и отмечает объекты как готовые.
3. 🔹 Переходит к следующей порции, пока не закончится очередь.
4. 🔹 Если обработчик упал — фиксирует ошибку в журнале регистрации и пробует ещё раз при следующем запуске задания.

Почему часть документов временно нельзя изменить

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

Это не ошибка, а защита. Документ станет доступен, как только до него дойдёт очередь.

Файловая база и клиент-серверная: разница принципиальная

• 🖥️ Клиент-серверная база . Регламентные задания выполняет сервер 1С. Обработка идёт сама, даже ночью, когда никто не работает . Нужно только, чтобы в свойствах базы в консоли кластера не стояла блокировка регламентных заданий.
• 📁 Файловая база. Отдельного сервера нет, регламентные задания выполняются в сеансе одного из пользователей. Если в базу никто не зашёл — обработка стоит. Закрыли программу на ночь — она продолжится только утром.

Отсюда частая жалоба «обработка идёт уже неделю». В файловой базе она просто почти не получает времени.

Чем отложенное обновление отличается от обычного

Под «обычным» обычно понимают вариант, когда всё выполняется за один заход и база недоступна до конца. Сравним:

Есть ещё две вещи, которые тоже называют «отложенным обновлением», хотя это другие механизмы.

Установка релиза по расписанию

В помощнике обновления (Администрирование → Поддержка и обслуживание → Обновление версии программы) можно выбрать, когда ставить загруженный релиз: сразу, при завершении работы или ночью по расписанию. Это откладывает саму установку, а не обработку данных. После установки отложенные обработчики всё равно запустятся.

Фоновое обновление конфигурации базы данных

Это механизм платформы для клиент-серверных баз. Реструктуризацию таблиц можно запустить в фоне в Конфигураторе (Конфигурация → Фоновое обновление конфигурации базы данных) или из командной строки с ключом /UpdateDBCfg -BackgroundStart. Пользователи работают, а в конце нужен короткий монопольный шаг, чтобы применить изменения (-BackgroundFinish). К обработчикам БСП он отношения не имеет.

Где посмотреть и как настроить отложенное обновление: пошагово

Шаг 1. Откройте результаты обновления

1. Зайдите в Администрирование → Поддержка и обслуживание.
2. В группе обновления версии программы откройте ссылку «Результаты обновления программы».
3. Раздел о дополнительной обработке данных покажет состояние: идёт, завершена или завершена с ошибками, и сколько процентов готово.

Ссылка «Подробнее» или похожая откроет список обработчиков с их статусами. Здесь видно, какой именно обработчик стоит или упал.

Шаг 2. Проверьте, что регламентное задание не выключено

1. Откройте Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания.
2. Найдите задание про отложенное обновление.
3. Убедитесь, что оно включено, и посмотрите время последнего запуска и результат.

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

Шаг 3. Ускорьте обработку, если она идёт слишком долго

• ⚡ Число потоков. В новых версиях БСП в настройках результатов обновления можно задать, сколько потоков параллельно обрабатывают данные. На сервере с 8 ядрами 4 потока обычно ускоряют процесс в разы. В файловой базе толку мало.
• 🕐 Приоритет. В некоторых конфигурациях есть переключатель между приоритетом обработки данных и работы пользователей. Выберите обработку данных на выходные, работу пользователей — на рабочие дни.
• 📁 Файловая база. Оставьте одного пользователя в программе на ночь — например, на отдельном компьютере. Задания будут выполняться в его сеансе.

Шаг 4. Дождитесь статуса «завершено»

Пока обработка не закончена:

• не закрывайте период и не формируйте регламентную отчётность по прошлым периодам без проверки;
• не ставьте следующий релиз: программа предупредит, что дополнительная обработка данных предыдущей версии не завершена;
• не правьте массово старые документы обработками.

Что ломается чаще всего и как это исправить

Здесь собраны ситуации, которые встречаются на практике снова и снова.

Когда отложенная обработка мешает и как с этим жить

Отключить отложенные обработчики в типовой конфигурации нельзя, и делать это не надо: без них часть данных останется в старом формате. Но есть ситуации, когда фон создаёт проблемы.

• 📅 Обновление в конце месяца или квартала. Отчёты за прошлые периоды могут считаться по неполным данным, а часть документов будет заблокирована. Не ставьте крупный релиз за 2–3 дня до сдачи отчётности.
• 🐢 Слабый сервер и много пользователей. Фон и работа людей делят процессор и диск. Лучше обновить в пятницу вечером и дать обработке все выходные.
• 🧪 Тестовая копия для проверки релиза. Если тестировать отчёты на копии, пока обработка не закончилась, выводы будут неверными. Дождитесь статуса «завершено» и на копии тоже.
• 🔁 Пропуск нескольких релизов. Если база отстала на 5–10 релизов, лучше ставить их по очереди и дожидаться завершения обработки после каждого. Так проще найти, на каком шаге возникла ошибка.

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

Как вернуться назад, если обновление пошло не так

Отменить отложенную обработку или «откатить» её штатной кнопкой нельзя. Обработчики уже изменили данные, и обратных процедур у них нет. Единственный надёжный способ вернуться — восстановить базу из резервной копии, сделанной до установки релиза.

Порядок действий:

1. Убедитесь, что откат действительно нужен. Часто достаточно исправить один документ или дождаться патча.
2. Предупредите пользователей и выгоните их из базы: при восстановлении все сеансы оборвутся, а данные, введённые после копии, пропадут.
3. Восстановите копию: для файловой базы — подмените файл 1Cv8.1CD из копии или загрузите .dt через Конфигуратор (Администрирование → Загрузить информационную базу); для клиент-серверной — восстановите бэкап СУБД.
4. Перенесите документы, введённые после обновления, заново вручную или выгрузкой из обновлённой копии, если она сохранилась.

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

Частые вопросы