Как исправить ошибку «Преобразование значения к типу Булево не может быть выполнено» в обработчике события ПослеЗагрузкиОбъекта?

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

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

Выясняем причину возникновения ошибки

Проанализируем ситуацию: ошибка локализована в модуле менеджера документа СчетФактураВыданный, примерно в районе 655-й строки (номер может меняться в зависимости от релиза БП 3.0). Проблема кроется в функции ПолучитьКодВидаОперации. В последних обновлениях «1С:Бухгалтерии» разработчики добавили проверку на то, является ли организация налоговым агентом по определенным видам операций (например, реализация сырых шкур, лома металлов или алюминия).

В коде это выглядит следующим образом:

УчетАгентскогоНДСПокупателем = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ДоговорКонтрагента, "УчетАгентскогоНДСПокупателем");
Если УчетАгентскогоНДСПокупателем Тогда
    // Логика определения кода операции
КонецЕсли;

Ошибка возникает из-за того, что переменная УчетАгентскогоНДСПокупателем получает значение Неопределено или NULL. В языке 1С попытка использовать такое значение в логическом условии Если ... Тогда приводит к исключению «Преобразование значения к типу Булево не может быть выполнено».

Почему значение оказывается пустым? Рассмотрим основные причины:

1. Новый договор: Если в Счете-фактуре указан новый договор, который создается в этой же транзакции обмена, ссылка на него может быть еще не полностью доступна для метода ЗначениеРеквизитаОбъекта.
2. Устаревшие правила обмена: Правила в УНФ передают «вручную» сформированную структуру параметров вместо полноценного объекта, и в этой структуре отсутствуют необходимые данные для корректной работы модуля менеджера БП.
3. Несоответствие релизов: Конфигурация БП была обновлена, а правила обмена в УНФ остались старыми.

Способ 1. Обновление типовых правил обмена

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

Посмотрим, как это сделать в БП 3.0:

1. Перейдем в раздел Администрирование — Синхронизация данных.
2. Выберем пункт Настройки синхронизации данных.
3. В карточке вашей настройки обмена с УНФ найдите возможность загрузки правил. Обычно это кнопка «Загрузить правила» или использование кнопки «Восстановить типовые правила».
4. После обновления правил в приемнике (БП) обязательно выгрузите их для источника (УНФ), если обмен использует внешние файлы правил.

Способ 2. Программное исправление обработчика в ПКО

Если обновление типовых правил не помогло или вы используете модифицированные правила обмена, необходимо внести изменения в само ПКО СчетФактураВыданный. Разберем пример кода, который часто встречается в старых правилах и вызывает ошибку.

Проанализируем старый код в обработчике ПослеЗагрузкиОбъекта:

СтруктураПараметров = Новый Структура;
СтруктураПараметров.Вставить("Дата", Объект.Дата);
СтруктураПараметров.Вставить("ДоговорКонтрагента", Объект.ДоговорКонтрагента);
// ... заполнение других полей ...
Объект.КодВидаОперации = Документы.СчетФактураВыданный.ПолучитьКодВидаОперации(СтруктураПараметров);

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

Разберем исправленный вариант кода для обработчика ПослеЗагрузкиОбъекта:

Попытка
    Если РежимЗагрузкиДанныхВИнформационнуюБазу Тогда
        // Проверяем заполнение организации
        Если НЕ ЗначениеЗаполнено(Объект.Организация) Тогда
            Объект.Организация = Параметры.ОсновнаяОрганизация;
        КонецЕсли;

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

        // Установка стандартных параметров выставления
        Объект.КодСпособаВыставления = 1;
        Объект.Выставлен = Истина;
        Объект.ДатаВыставления = Объект.Дата;
    КонецЕсли;
Исключение
    // Запись ошибки в лог, если необходимо
КонецПопытки;

Почему это решение работает?

Рассмотрим подробнее изменения в коде:

• Передача Объекта вместо Структуры: Метод ПолучитьКодВидаОперации(Объект) позволяет платформе обращаться к свойствам самого объекта документа. Даже если некоторые реквизиты еще не записаны в базу, они уже присутствуют в оперативной памяти объекта Объект, что предотвращает получение NULL.
• Проверка ЗначениеЗаполнено: Мы добавили условие Если Не ЗначениеЗаполнено(Объект.КодВидаОперации). Это позволяет избежать лишних вычислений, если код уже пришел из УНФ корректно.
• Значение по умолчанию: Установка кода "01" (основной код операции реализации) является «страховкой». Это гарантирует, что документ будет записан и проведен, даже если автоматическое определение кода не сработало.

Рекомендации по отладке

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

Посмотрим на рекомендации по отладке:

1. Использование внешней обработки: Попробуйте выполнить загрузку данных не через типовое окно синхронизации, а через обработку «Универсальный обмен данными в формате XML». В ней можно отключить выполнение обмена в фоновом задании и поймать ошибку точкой останова.
2. Логирование: Если доступа к конфигуратору нет, добавьте в код обработчика вывод сообщений через Сообщить() или запись в журнал регистрации (ЗаписьЖурналаРегистрации). Проверьте, какое именно значение содержится в Объект.ДоговорКонтрагента в момент падения.
3. Проверка договора: Убедитесь, что в УНФ в договоре, по которому не выгружается счет-фактура, заполнены все обязательные реквизиты (Вид договора, Организация, Наименование). Иногда «битая» ссылка на договор в источнике является корнем проблемы.

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