При обновлении информационных систем, особенно таких комплексных, как 1С:ERP, мы можем столкнуться с неожиданными сложностями. Одной из таких распространенных проблем является зависание процесса обновления, особенно когда оно связано с серьезными изменениями в структуре данных. В данной статье мы подробно рассмотрим ситуацию, когда обновление 1С:ERP с версии 2.5.6 на 2.5.7 застревает на этапах, связанных с переходом на новые регистры распределения запасов. Мы выясним причины такого поведения и предложим пошаговое решение, основанное на реальном опыте.
Переход на версию 2.5.7 в 1С:ERP (а также в 1С:КА и 1С:УТ) принес значительные изменения в механизме учета запасов. В частности, были удалены шесть старых регистров, и вместо них введены два новых: регистр сведений "Распределение запасов" и регистр накопления "Распределение запасов – движения". Регистр сведений "Распределение запасов" предназначен для хранения уже рассчитанных значений остатков, что должно уменьшить зависимость от регистра накопления для этих расчетов. Он представляет собой сложный механизм, собирающий и обрабатывающий информацию на основе данных регистра накопления "Запасы и потребности". В свою очередь, регистр накопления "Распределение запасов – движения" служит для отражения движений этих запасов. Для выявления нетиповых доработок, обращающихся к удаленным метаданным, можно использовать инструмент поиска некорректных запросов после обновления.
Именно эти изменения и приводят к длительной обработке данных во время обновления, поскольку требуется полное заполнение новых регистров на основе существующих документов. В нашем случае, процесс дополнительной обработки данных доходит до стадии "216 из 223" и останавливается. Отчет по прогрессу показывает, что большая часть работы выполнена, но зависли следующие объекты:
Распределение запасов - Движения 12 184
Распределение запасов 1 613
Реестр документов 5 311
Состояния заказов клиентов 114
В такой ситуации ожидание в течение нескольких часов или даже суток может не принести результатов. Мы должны понимать, что, хотя некоторые процессы обновления действительно могут занимать много времени (например, перевод ERP с 2.4 на 2.5.8 с 533 обработками может длиться 5-6 часов), полное зависание без какого-либо прогресса указывает на проблему. Для сокращения времени простоя при масштабных обновлениях крупных баз можно использовать технологию обновления через копию.
Для ускорения заполнения регистра "Распределение запасов" предусмотрен специальный ускоренный режим, который выполняется в монопольной части обновления. Если этот режим не срабатывает должным образом, процесс обновления может затянуться. Заполнение регистра "Распределение запасов – движения" происходит позднее, в отложенном режиме, и, как правило, не должно препятствовать работе пользователей. Тем не менее, в нашем случае оба регистра остаются пустыми или заполняются лишь частично даже после длительного ожидания.
Прежде чем приступать к диагностике и исправлению ошибок, мы всегда должны помнить о критической важности создания полной резервной копии информационной базы. Это позволит нам восстановить систему в исходное состояние в случае любых непредвиденных проблем в процессе устранения неполадок. Для автоматического выполнения резервного копирования и обслуживания баз можно использовать программу для пакетного архивирования и обновления 1С.
Первым шагом при зависании обновления является определение того, какой именно обработчик вызывает проблему. 1С предоставляет удобные инструменты для мониторинга статуса выполнения обработчиков. Мы будем использовать отчет о текущем состоянии выполнения и регистр сведений "Обработчики обновления".
Откроем отчет о текущем состоянии выполнения: Перейдите в раздел "Администрирование – Обслуживание – Результаты обновления и дополнительная обработка данных". Здесь мы увидим общий прогресс и списки объектов, ожидающих обработки. Мы можем установить отбор на объекты с прогрессом менее 100%, чтобы сфокусироваться на незавершенных задачах.
Используем регистр сведений "Обработчики обновления": Это ключевой инструмент для детальной диагностики. Мы выполним следующие шаги:
Откройте регистр сведений "Обработчики обновления". Это можно сделать через "Функции для технического специалиста" (если они включены) или напрямую из конфигуратора.
Отсортируйте данные по колонке Очередь отложенной обработки по возрастанию. Эта колонка показывает порядок выполнения обработчиков.
Установите отбор по колонке Статус со значением "Не равно Выполнен". Это отфильтрует все уже завершенные обработчики и покажет только те, что еще ждут своей очереди, находятся в работе или зависли.
Теперь мы можем проанализировать верхние строки в списке после отбора. Первая строка с наименьшим номером очереди, у которой прогресс не меняется (или колонки вроде Длительность обработки остаются пустыми, как в нашем случае), будет указывать на зависший обработчик. В нашем случае, мы обнаружили, что зависший обработчик имеет имя Документы.питЗаказНаПеремещениеВНоменклатуруПроизводства.ОбработатьДанныеДляПереходаНаНовуюВерсию. При этом колонки Длительность обработки и Обработка порции завершена для него были пустыми.
Определив конкретный обработчик, мы можем использовать обработку "Регистрация изменений для обмена". Выберите узел с номером, соответствующим значению Очередь отложенной обработки для найденного обработчика. В изменениях этого узла мы увидим данные, которые еще не обработаны текущей очередью. Пока текущая очередь не отработана, следующие обработчики не запустятся, даже если их статус показывает "Выполняется".
В нашем случае, после применения этих шагов, мы четко увидели, что обновление застряло на обработчике, относящемся к документу питЗаказНаПеремещениеВНоменклатуруПроизводства. Это был модуль от стороннего разработчика (Рарус, входящий в состав конфигурации как интегрированное решение "Общепит"). При этом было установлено, что в базе нет ни одного такого документа, и в плане обмена ОбновлениеИнформационнойБазы для него ничего не было зарегистрировано.
Мы продолжаем наш анализ, чтобы выяснить, почему обработчик зависает, даже если соответствующих документов в базе нет. Мы обнаружили, что в журнале регистрации системы появляется ошибка: Таблица не найдена "Документ.питЗаказНаПеремещениеВНоменклатуруПроизводства.Изменения".
Эта ошибка возникает в типовой процедуре ОбновлениеИнформационнойБазы.СоздатьВременнуюТаблицуЗаблокированныхДляЧтенияИИзмененияДанных. Внутри этой процедуры формируется запрос, где используется строка ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "#ТаблицаИзменений", ПолноеИмяОбъекта + ".Изменения");. Очевидно, что система пытается получить доступ к служебной таблице Изменения для объекта Документ.питЗаказНаПеремещениеВНоменклатуруПроизводства. Однако, если этот документ не зарегистрирован в плане обмена ОбновлениеИнформационнойБазы, то такой служебной таблицы не существует. В результате, типовая процедура не может получить данные, зависает в бесконечном цикле ожидания или попыток, при этом не выводя явных сообщений об ошибке на экран пользователя, что затрудняет диагностику.
Таким образом, корень проблемы заключался в том, что документы интегрированных сторонних модулей (в данном случае, модуля "Общепит" от Рарус) не были корректно выбраны для регистрации изменений в плане обмена ОбновлениеИнформационнойБазы.
Решение проблемы:
Откройте план обмена ОбновлениеИнформационнойБазы. Это можно сделать через конфигуратор (ветка "Планы обмена") или через "Функции для технического специалиста" в режиме 1С:Предприятие.
Перейдите на вкладку "Состав" или аналогичную, где перечислены объекты, подлежащие регистрации для обмена.
Внимательно просмотрите список документов и других объектов. Убедитесь, что все документы интегрированных (сторонних) модулей, которые затрагиваются обновлением (в нашем случае, это был документ Документ.питЗаказНаПеремещениеВНоменклатуруПроизводства и, возможно, другие объекты модуля "Общепит"), выбраны для регистрации изменений. Для них должны быть установлены соответствующие флажки.
Сохраните изменения в плане обмена.
После корректной регистрации документов в плане обмена, запустите обновление повторно или продолжите зависшее обновление. В нашем случае, после установки флажков, обновление успешно завершилось всего за 30 минут.
Альтернативный временный обход (не рекомендуется как основное решение):
В некоторых случаях, если доступ к изменению плана обмена затруднен или требуется срочный обход, можно использовать расширение для принудительного завершения работы конкретного обработчика. Это позволяет пропустить проблемный обработчик и дать возможность завершиться остальным. Однако это может привести к неполноценному обновлению данных, если этот обработчик действительно должен был выполнить какие-либо действия (даже при нулевом количестве документов).
Пример кода, который был применен для обхода проблемы (в расширении):
// В модуле объекта 'Документы.питЗаказНаПеремещениеВНоменклатуруПроизводства.ОбработатьДанныеДляПереходаНаНовуюВерсию'
#Удаление
Параметры.ОбработкаЗавершена = ОбновлениеИнформационнойБазы.ОбработкаДанныхЗавершена(Параметры.Очередь, ПолноеИмяОбъекта);
#КонецУдаления
#Вставка
Параметры.ОбработкаЗавершена = Истина;
#КонецВставки
Этот код заменяет стандартную проверку завершения обработки на прямое присвоение Истина, что принудительно завершает работу данного обработчика. Мы должны использовать такой подход с большой осторожностью и только после тщательного анализа последствий.
Для минимизации рисков и ускорения процесса обновления 1С:ERP, особенно при работе с комплексными изменениями и сторонними модулями, мы рекомендуем придерживаться следующих практических советов:
Регулярное обновление: Стараемся обновлять систему 1С регулярно. Это не только обеспечивает получение исправлений ошибок и актуализацию форм отчетности согласно законодательству, но и позволяет избежать накопления большого объема изменений, которые могут сделать переход на новую версию более сложным.
Мониторинг через "Результаты обновления и дополнительная обработка данных": Активно используем раздел "Администрирование – Обслуживание – Результаты обновления и дополнительная обработка данных". Здесь мы отслеживаем статус выполнения обработчиков, просматриваем отчеты по прогрессу и оперативно выявляем ошибки.
Изменение приоритета обработки данных: Для ускорения выполнения отложенных обработчиков, особенно если обновление проводится в нерабочее время, мы можем изменить приоритет обработки данных с "Работа пользователей" на "Обработка данных". Это высвободит больше ресурсов для процессов обновления.
Перезапуск обработчиков: При наличии ошибок, после их исправления или установки патчей, мы можем перезапустить отложенное обновление через меню "Еще" в "Результатах обновления и дополнительная обработка данных".
Ручное управление очередностью: В сложных случаях, особенно при наличии нескольких потоков обновления, может потребоваться ручное изменение порядка выполнения обработчиков через регистр сведений "Обработчики обновления", как мы уже рассматривали.
Использование "Функций для технического специалиста": Этот инструмент предоставляет доступ к скрытым обработкам, регистрам и другим объектам, которые могут существенно помочь в диагностике и устранении ошибок. Обязательно активируем его в начале работы с проблемным обновлением.
Проверка фоновых заданий: В случае зависания обновлений мы должны убедиться, что нет конфликтующих фоновых процессов 1С, которые могут мешать монопольному обновлению или занимать критические ресурсы.
Постепенный переход: Иногда, при значительных изменениях между версиями, поэтапное обновление через промежуточные релизы может быть более стабильным, хотя поддержка 1С часто рекомендует прямой переход на последнюю актуальную версию. Мы всегда оцениваем риски и преимущества каждого подхода.
Особенности работы с заказами в 2.5.7: Обращаем внимание, что с обновлением до версии 2.5.7 изменилось поведение действия "К обеспечению" в заказах клиентов. Теперь заказы с таким действием могут автоматически резервировать товар на складе, уменьшая свободный остаток. Это может создавать сложности, если автоматическое резервирование не требуется или нарушает график отгрузок. В качестве решения мы предлагаем переход на действие "Не обеспечивать" или использование нового функционала "К обеспечению" без резервирования товаров на складе, если это применимо к нашей бизнес-логике.
В заключение, мы должны помнить, что успешное обновление 1С:ERP, особенно при наличии комплексных изменений и сторонних модулей, требует тщательной подготовки, внимательной диагностики и системного подхода к решению возникающих проблем. Надеемся, что этот подробный разбор поможет нам эффективно справляться с вызовами обновления и поддерживать наши системы в актуальном и работоспособном состоянии.