Как исправить ошибку при обновлении узлов РИБ в 1С:Розница

← На главную

При обновлении распределенных информационных баз (РИБ) в 1С:Розница, особенно при переходе через несколько релизов (например, с 2.2.6 на 2.2.12), технические специалисты часто сталкиваются с критической остановкой процесса. Ошибка обычно проявляется на этапе завершения обновления (около 94%) в режиме «1С:Предприятие». В журнале регистрации фиксируется сообщение: «В данной транзакции уже происходили ошибки!». Рассмотрим подробнее причины возникновения этой ситуации и разберем по шагам методы её решения.

Анализ причины возникновения ошибки

Первоочередная проблема заключается не в самой фразе о транзакции, а в том, что ей предшествует. Ошибка «В данной транзакции уже происходили ошибки!» является вторичной. Она означает, что внутри одной транзакции обмена или обновления какой-то программный обработчик вызвал исключение, которое было перехвачено блоком Попытка — Исключение, но флаг «битой» транзакции в СУБД уже установился. После этого любой вызов метода Следующий() в выборке или попытка записи объекта приводит к аварийному завершению.

Проанализируем ситуацию: в 1С:Розница при обновлении узла система пытается автоматически провести документы Ввод начальных остатков узла. Этот документ специфичен для РИБ «по магазинам». Если в базе нарушена целостность данных или установлена дата запрета редактирования, выполнение кода в модуле плана обмена ПоМагазину прерывается.

Решение 1: Правильный порядок обновления через конфигуратор

Одной из главных рекомендаций опытных специалистов является отказ от завершения обновления в пользовательском режиме, если база является периферийным узлом РИБ. Рассмотрим алгоритм, позволяющий минимизировать риски:

Выполните обновление центральной базы (ЦБ) в обычном режиме: конфигуратор, затем режим «Предприятие», дождитесь окончания всех отложенных обработчиков обновления.
Выполните сеанс обмена в ЦБ, чтобы сформировалось сообщение с изменениями конфигурации для подчиненного узла.
В периферийном узле (ПЗ) запустите Конфигуратор и примите изменения через пункт меню «Конфигурация — Обновить конфигурацию базы данных».
Важно: Не запускайте сразу режим «Предприятие». Сначала убедитесь, что в узле нет активных сеансов, кроме вашего.
Если ошибка на 94% всё же возникла, попробуйте временно отключить дату запрета изменения данных для всех пользователей и повторить запуск.

Решение 2: Программная корректировка модуля плана обмена

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


ВыборкаДокументов = Документы.ВводНачальныхОстатковУзла.Выбрать(,, Новый Структура("КодУзлаОбмена", ПредопределенныйУзел.Код), "Дата");
Пока ВыборкаДокументов.Следующий() Цикл
    ДокументВыборки = ВыборкаДокументов.ПолучитьОбъект();
    Если ДокументВыборки <> Неопределено
        И НЕ ДокументВыборки.ПометкаУдаления
        И НЕ ДокументВыборки.Проведен Тогда
        
        ДокументВыборки.Узел = Ссылка;
        // Попытка проведения документа, которая может вызывать скрытую ошибку
        Если НЕ ОбменДаннымиПереопределяемый.ЗаписатьВводОстатков(ДокументВыборки, РежимЗаписиДокумента.Проведение) Тогда
            Отказ = Истина;
        КонецЕсли;
    КонецЕсли;
КонецЦикла;

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

Решение 3: Восстановление связи с главным узлом (если база была отвязана)

Иногда в процессе борьбы с ошибками администраторы «отвязывают» периферийную базу от центральной, используя команду: ПланыОбмена.УстановитьГлавныйУзел(Неопределено). После этого база обновляется без проверок РИБ, но кнопка «Главный узел» в интерфейсе может исчезнуть. Чтобы восстановить связь, воспользуемся внешней обработкой или консолью кода:


// Укажите ссылку на узел, который должен быть главным (обычно это узел с кодом "000" или "M")
УзелГлавный = ПланыОбмена.ПоМагазину.НайтиПоКоду("КодВашегоЦентра");
Если НЕ УзелГлавный.Пустая() Тогда
    ПланыОбмена.УстановитьГлавныйУзел(УзелГлавный);
    Сообщить("Связь с главным узлом восстановлена");
КонецЕсли;

Проблема регистрации данных в самописных регистрах

После успешного обновления вы можете заметить, что движения по вашим собственным (кастомизированным) регистрам накопления перестали передаваться между базами. В 1С:Розница 2.2 и выше механизмы регистрации объектов претерпели изменения. Проанализируем, где искать причину:

Подписки на события: Проверьте подписки, отвечающие за регистрацию объектов для обмена (например, ОбменДаннымиПоМагазинуЗарегистрироватьИзменениеРегистра). Убедитесь, что ваш новый регистр включен в состав объектов этой подписки.
Состав плана обмена: Проверьте, добавлен ли регистр в состав самого плана обмена ПоМагазину с признаком «Авторегистрация — Разрешить».
Правила регистрации объектов (ПРО): В плане обмена есть макет ПравилаРегистрацииОбъектов. Это XML-файл, который фильтрует данные. Если вы добавили объект в метаданные, но не обновили правила регистрации в режиме «Предприятие» (через параметры обмена данными), система может игнорировать этот объект при регистрации изменений.

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