Как исправить критические ошибки и сбои обмена после обновления 1С:Бухгалтерия предприятия 3.0?

← На главную

Обновление конфигурации «1С:Бухгалтерия предприятия» (БП) 3.0 — рутинный процесс, который, однако, нередко преподносит неприятные сюрпризы для разработчиков и системных администраторов. В частности, при переходе на новые релизы (например, в районе 3.0.52.x и смежных версий) разработчики часто сталкиваются с целым комплексом взаимосвязанных проблем. К ним относятся внезапное прекращение обмена данными с другими конфигурациями (в частности, «1С:Управление торговлей»), системные ошибки платформы при обращении к кэшированным константам, а также внезапные изменения в программном интерфейсе (API) стандартных библиотек.

В этой статье мы подробно разберем наиболее распространенные «нежданчики» при обновлении БП 3.0, проанализируем их технические причины и предоставим пошаговые инструкции и готовые примеры кода для их оперативного решения.

---

Проблема №1: Отказ обмена по универсальному формату (EnterpriseData) после удаления версии 1.1

При обновлении конфигурации «1С:Бухгалтерия предприятия» 3.0 фирма «1С» планомерно избавляется от поддержки устаревших версий универсального формата обмена EnterpriseData (в частности, версий 1.0 и 1.1). Это делается с целью оптимизации объема конфигурации и сокращения устаревшего кода в Библиотеке стандартных подсистем (БСП).

Суть проблемы: Если ваша база БП 3.0 обменивается данными с конфигурацией-корреспондентом, которая давно не обновлялась (например, нетиповая «1С:Управление торговлей» версии 11.1 или ранних релизов 11.2), обмен полностью прекратит работу. На стороне БП или УТ начнет возникать критическая ошибка:

Не определен Менеджер конвертации для версии формата обмена 1.1

Рассмотрим по шагам несколько вариантов решения этой проблемы в зависимости от того, готовы ли вы обновлять сопутствующую конфигурацию или вам требуется оперативное временное решение «здесь и сейчас» без глобального обновления.

Вариант А. Штатное решение проблемы (рекомендуемое)

Самый правильный и надежный путь — обновить конфигурацию «Управление торговлей» (или иную базу-корреспондент) до актуального релиза (например, УТ 11.2.3.150 или выше), в котором на уровне метаданных добавлена штатная поддержка формата EnterpriseData 1.2 и выше. В этом случае синхронизация восстановится автоматически после обновления.

Вариант Б. Быстрый обход проблемы в коде (без обновления УТ)

Если быстро обновить УТ невозможно (например, база сильно доработана), нам придется форсировать использование формата 1.2 со стороны УТ вручную. Разберем по шагам, как это реализовать:

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


Процедура ПолучитьВерсииФорматаОбмена(ВерсииФормата) Экспорт
    
    Запрос = Новый Запрос(
        "ВЫБРАТЬ
        |   СинхронизацияДанныхЧерезУниверсальныйФормат.ПутьКМенеджеруОбмена КАК ПутьКМенеджеруОбмена
        |ИЗ
        |   ПланОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат КАК СинхронизацияДанныхЧерезУниверсальныйФормат
        |ГДЕ
        |   СинхронизацияДанныхЧерезУниверсальныйФормат.ПутьКМенеджеруОбмена <> """""
    );
    
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        ОбработкаДляОтладки = ВнешниеОбработки.Создать(Выборка.ПутьКМенеджеруОбмена);
        ВерсииФормата.Вставить("1.0.beta", ОбработкаДляОтладки);
        ВерсииФормата.Вставить("1.0", ОбработкаДляОтладки);
        ВерсииФормата.Вставить("1.1",  ОбработкаДляОтладки);
        ВерсииФормата.Вставить("1.2",  ОбработкаДляОтладки); // Принудительно добавляем поддержку версии 1.2
    Иначе
        ВерсииФормата.Вставить("1.0.beta", МенеджерОбменаЧерезУниверсальныйФормат);
        ВерсииФормата.Вставить("1.0", МенеджерОбменаЧерезУниверсальныйФормат);
        ВерсииФормата.Вставить("1.1",  МенеджерОбменаЧерезУниверсальныйФормат);
        ВерсииФормата.Вставить("1.2",  МенеджерОбменаЧерезУниверсальныйФормат); // Принудительно добавляем поддержку версии 1.2
    КонецЕсли;
    
КонецПроцедуры

Важное дополнение: Для того чтобы база УТ могла корректно валидировать файлы выгрузки нового формата, необходимо импортировать схему XDTO. Для этого скопируйте из конфигурации «Бухгалтерия предприятия» XDTO-пакет EnterpriseData_1_2_3 (или актуальный пакет версии 1.2) и добавьте его в конфигурацию УТ в раздел Общие -> XDTO-пакеты.

---

Проблема №2: Ошибка «Значение не является значением объектного типа (ЭтоСсылочныйТип)» при выгрузке

После реализации принудительного перехода на формат 1.2 без полноценного обновления правил обмена разработчики часто сталкиваются со следующей ошибкой при выполнении синхронизации:

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(776)}: Значение не является значением объектного типа (ЭтоСсылочныйТип) Если ПравилоКонвертации.ЭтоСсылочныйТип Тогда

Выясним причину проблемы: Данный сбой происходит в общем модуле ОбменДаннымиXDTOСервер во время попытки преобразования данных информационной базы в формат XDTO. Программа обращается к правилу конвертации конкретного объекта. Однако, поскольку мы форсировали версию формата 1.2, а используем старый менеджер обмена (правила) от версии 1.1 или 1.0, система не находит сопоставленного правила конвертации объектов (ПКО) для новых метаданных. Переменная ПравилоКонвертации принимает значение Неопределено, что и вызывает падение системы.

Решение проблемы:

Если вы используете измененные правила обмена, вам потребуется загрузить их в конфигурацию «1С:Конвертация данных 3.0», обновить структуру формата до версии 1.2/1.3 и перегенерировать модуль менеджера обмена.
В качестве быстрого обходного пути для нетиповых обменов можно откатить версию формата обмена в БП 3.0 назад до 1.1, внедрив правила старого формата непосредственно в БП с помощью механизма расширений конфигурации.

---

Проблема №3: Ошибка формата потока при обращении к константе «ПараметрыРезервногоКопирования»

После обновления платформы (особенно часто проблема регистрировалась на версиях ветки 8.3.10, например 8.3.10.2580) при запуске программы или выполнении регламентных операций может возникнуть критический сбой:

Ошибка формата потока при попытке выполнить метод Константы.ПараметрыРезервногоКопирования.Получить().

Анализ ситуации: Константа ПараметрыРезервногоКопирования имеет тип ХранилищеЗначения и хранит внутри себя сложную сериализованную структуру настроек. Из-за ошибок кэширования метаданных или некорректного обновления бинарных представлений платформой 1С при чтении сериализованных данных происходит аппаратный сбой десериализации, возвращающий ошибку формата потока.

Рассмотрим два метода устранения этой неприятности.

Способ 1. Принудительное очищение и заполнение константы кодом (быстродействующий)

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


ПараметрыРезервногоКопирования = Новый Структура;
// Заполняем структуру дефолтными значениями, если это необходимо для БСП
Константы.ПараметрыРезервногоКопирования.Установить(Новый ХранилищеЗначения(ПараметрыРезервногоКопирования));

Этот способ занимает не более 30 секунд и сразу возвращает базу в работоспособное состояние.

Способ 2. Реструктуризация таблиц базы данных (наиболее надежный)

Если база данных небольшая или у вас есть технологическое окно для обслуживания, выполните следующие действия:

Запустите информационную базу в режиме Конфигуратора.
Предварительно создайте резервную копию базы данных.
Перейдите в меню Администрирование -> Тестирование и исправление...
Установите флаг напротив пункта Реструктуризация таблиц информационной базы (остальные флаги можно снять для экономии времени).
Нажмите кнопку Выполнить.

Реструктуризация принудительно пересоздаст физическую таблицу хранения констант на диске (или в СУБД), что гарантированно устранит физическое повреждение структуры данных.

---

Проблема №4: Ошибка «Поле объекта не обнаружено» при отправке почты (переименование в БСП)

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

В рамках обновления БСП до версии 2.4, которая вошла в состав новых релизов БП 3.0, разработчики «1С» провели унификацию кода. В общем модуле РаботаСПочтовымиСообщениями в процедуре ОтправитьПочтовоеСообщение у структуры параметров письма было переименовано одно из ключевых полей:

Было: СлепыеКопии
Стало: СкрытыеКопии

Симптомы сбоя: Любой внешний программный код, который пытается отправить письмо и использует старое свойство структуры СлепыеКопии, мгновенно падает с ошибкой рантайма:

Поле объекта не обнаружено (СкрытыеКопии) или Ключ не найден в структуре.

Как правильно исправить код с сохранением обратной совместимости?

Проанализируем пример кода, который позволит вашей обработке или внешней печатной форме безопасно работать как на старых релизах конфигураций, так и на новых:


ПараметрыПисьма = Новый Структура;
ПараметрыПисьма.Вставить("Кому", "client@domain.com");
ПараметрыПисьма.Вставить("Тема", "Счет на оплату");
ПараметрыПисьма.Вставить("Тело", "Добрый день! Во вложении ваш счет.");

// Обеспечиваем универсальность кода для старых и новых версий БСП:
АдресаСкрытыхКопий = "manager@ourcompany.com";

// Проверяем, какая версия API используется в текущей конфигурации
Попытка
    // Пытаемся использовать новое наименование свойства
    ПараметрыПисьма.Вставить("СкрытыеКопии", АдресаСкрытыхКопий);
Исключение
    // Если упало — значит, перед нами старая версия БСП, используем старое свойство
    ПараметрыПисьма.Вставить("СлепыеКопии", АдресаСкрытыхКопий);
КонецПопытки;

РаботаСПочтовымиСообщениями.ОтправитьПочтовоеСообщение(СистемнаяУчетнаяЗапись, ПараметрыПисьма);

Такой подход гарантирует бесперебойную работу вашего кастомного функционала независимо от того, на какой именно релиз БП 3.0 или версию БСП перешел ваш клиент.

---

Резюме и рекомендации по проведению обновлений

Чтобы минимизировать появление описанных выше проблем при каждом обновлении крупных и доработанных баз данных 1С, рекомендуем придерживаться следующих правил:

Всегда обновляйте платформу своевременно. Многие ошибки десериализации кэша (как в случае с ПараметрыРезервногоКопирования) исправляются разработчиками платформы в последующих минорных сборках.
Анализируйте состав БСП перед обновлением. Чтение файлов изменений (ReadMe.txt или документации на портале ИТС) к новым релизам БСП позволяет заранее узнать о переименовании методов почты, механизмов работы с файлами или регламентными заданиями.
Используйте расширения для адаптации. Если вам необходимо вернуть поддержку старого формата обмена или исправить поведение типового общего модуля, делайте это через расширения конфигурации в режиме Вместо или После, чтобы не снимать основную конфигурацию с поддержки.