Как правильно обновить 1С:Управление торговлей с редакции 11.1 на 11.2 и устранить возникающие ошибки?

← На главную

Переход между промежуточными редакциями конфигурации «1С:Управление торговлей» — в частности с ветки 11.1 на 11.2 — сопряжен с существенной переработкой структуры метаданных и прикладных механизмов. Разработчики полностью переработали архитектуру взаиморасчетов, логику выписки складских ордеров, формат хранения единиц измерения, правила синхронизации данных и механизмы обмена. Если выполнять обновление без соблюдения строгой последовательности релизов или с нарушениями правил объединения нетиповых конфигураций, можно столкнуться с фатальными ошибками проверки структуры базы, зависанием обработчиков и искажением данных регистров. Разберем по шагам правильную технологию перехода и методы решения типовых сбоев.

Особенности параллельного выпуска 11.1 и 11.2 и схема релизов

При выходе новой редакции 11.2 разработчики продолжали выпускать обновления для 11.1. Это стандартная практика переходного периода: старая ветка поддерживается ограниченное время для исправления критических ошибок законодательства, пока пользователи готовятся к переходу. Однако перепрыгнуть с любого случайного релиза 11.1 сразу на актуальный релиз 11.2 невозможно. Попытка накатить файл обновления сразу на релиз 11.2.3 приводит к синтаксическим ошибкам, так как в конфигурации удаляется огромное количество устаревших объектов, логика удаления которых заложена только в определенных опорных версиях.

Опытным путем и требованиями поставщика определена минимальная обязательная цепочка обновления:

Обновление текущей версии 11.1 до финального стабильного релиза ветки — 11.1.10.199.
Обязательный переход на опорный релиз — 11.2.2.119 (пропускать этот шаг категорически нельзя, именно в нем выполняется первый этап очистки и конвертации структуры метаданных).
Обновление до опорного релиза следующей подветки — 11.2.3.95 или 11.2.3.66.
Переход на финальный рабочий релиз ветки 11.2 (например, 11.2.3.159 или старше).

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

Ошибка: Ни один из документов не является регистратором для регистра

Проанализируем распространенную ситуацию: при попытке обновить базу по нажатию клавиши F7 конфигуратор выдает ошибку: «При проверке метаданных обнаружены ошибки. РегистрНакопления... Ни один из документов не является регистратором для регистра». Часто в списке фигурируют регистры с префиксом «Удалить» (например, УдалитьТоварыОрганизаций, УдалитьПартииЗатратНаВыпуск, УдалитьДвиженияНоменклатураПрочиеАктивыПассивы).

Выясним причину ошибки: в платформе «1С:Предприятие 8.3» регистр накопления не может существовать без единого регистратора. В редакции 11.2 фирма 1С вывела данные регистры из эксплуатации, сняв с них все типовые документы-регистраторы. Если база снята с поддержки («находится на поддержке с возможностью изменений»), то при сравнении и объединении конфигураций платформа по умолчанию не удаляет объекты основной конфигурации. В итоге регистры поставщика остаются в метаданных вашей базы, но документов-регистраторов у них больше нет.

Рассмотрим, как правильно устранить эту проблему:

Если база дорабатывалась, но сами удаляемые типовые регистры не использовались в ваших доработках: в окне сравнения и объединения конфигураций обязательно установим флаг «Разрешить удаление объектов основной конфигурации» и проставим отметки на удаление всех устаревших объектов поставщика.
Если база фактически типовая, но ранее была включена возможность изменений, наиболее чистый способ — выполнить команду «Конфигурация — Загрузить конфигурацию из файла» (выбрав .cf файл опорного релиза поставщика) либо через меню «Конфигурация — Поддержка — Настройка поддержки» нажать кнопку «Включить поддержку» / вернуть типовое соответствие, загрузив эталонный файл.
Если конфигурацию необходимо временно сохранить для реструктуризации данных, а в дереве метаданных остался регистр без регистраторов: временно назначим ему в свойствах любой фиктивный документ-регистратор, применим изменения по F7, выполним перенос данных и удалим объект на следующем шаге.

Пропадание движений по расчетам с клиентами и поставщиками

После успешного перехода на 11.2 часто обнаруживается, что в регистрах РасчетыСКлиентамиПоДокументам и РасчетыСПоставщикамиПоДокументам исчезают записи по части накладных, из-за чего искажается управленческий баланс и отчеты по дебиторской задолженности.

Разберем внутренний механизм: в редакции 11.2 кардинально изменена схема взаиморасчетов. Движения по регистрам «...ПоДокументам» рассчитываются в офлайн-режиме специальным фоновым заданием «Выполнение отложенных движений по расчетам с клиентами/поставщиками». Механизм работает следующим образом: фоновый процесс считывает записи из регистра сведений ЗаданияКРаспределениюРасчетов, очищает старые движения документа и формирует их заново.

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

Зацикливание обработчика обновления РасчетыСКлиентами

В процессе запуска информационной базы после наката релиза 11.2.3 может возникнуть ошибка: «Произошло зацикливание процедуры обработки данных. Выполнение прервано. РегистрыНакопления.РасчетыСКлиентами.ОбработатьДанныеДляПереходаНаНовуюВерсию».

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

Для исправления ситуации выполним следующие действия:

Найдем проблемные записи запросом к служебной таблице регистрации:


ВЫБРАТЬ 
    Ссылка,
    НомерСообщения
ИЗ 
    РегистрНакопления.РасчетыСКлиентами.Изменения

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

Обновление баз с внешними модулями и узлами обмена

Если в конфигурации используется интеграция с интернет-магазином (модуль Битрикс) или обмен с «1С:Бухгалтерия предприятия», учтем два критически важных требования:

Модули интеграции с сайтом: категорически запрещено обновлять саму конфигурацию УТ, если предварительно не был подготовлен модуль обмена. При переходе с версий 4.x на 5.x на стороне 11.1 сначала обновляется сам модуль, затем запускается специализированная внешняя обработка конвертации настроек обмена в формат 5.x. Только после создания контрольной резервной копии выполняется обновление самой базы «1С:Управление торговлей».
Синхронизация данных: при переходе на 11.2 стандартные правила обмена заменяются форматом EnterpriseData (универсальный формат). После обновления конфигурации необходимо открыть форму настроек синхронизации и обязательно нажать кнопку «Загрузить стандартные правила» во всех существующих узлах обмена, иначе документы будут регистрироваться по старым алгоритмам и выгрузка перестанет функционировать.