Как исправить ошибку «Преобразование значения к типу Булево не может быть выполнено» в 1С:УПП при создании Отчета производства за смену?

Перенос конфигурации в новую базу данных — стандартная задача при реструктуризации учета, свертке информационной базы или переходе на новые серверные мощности. Однако при ручном или частичном переносе справочников пользователи часто сталкиваются с непредвиденными ошибками при проведении документов. Одна из самых распространенных и критических ошибок в решениях на обычных формах, таких как «1С:Управление производственным предприятием 1.3» (УПП), связана с некорректной работой доработанных алгоритмов при обращении к пустым аналитическим разрезам.

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

Выясняем причину: почему возникает эта ошибка?

Для начала проанализируем текст ошибки, с которой сталкивается пользователь:

{ОбщийМодуль.ОбработкаТабличныхЧастей.Модуль(451)}: Преобразование значения к типу Булево не может быть выполнено

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

Если КатегорияПооперационныйУчет Тогда

В типовой конфигурации «1С:Управление производственным предприятием 1.3» данной строки в общем модуле ОбработкаТабличныхЧастей нет. Это означает, что конфигурация подверглась кастомной доработке со стороны программистов под нужды конкретного предприятия. Целью доработки было разделение логики проведения документов в зависимости от того, ведется ли по конкретной номенклатуре, подразделению или документу-основанию пооперационный учет.

Для реализации этого функционала разработчик использовал стандартный механизм платформы — «Свойства и категории объектов». Давайте вспомним, как устроен этот механизм:

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

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

В результате при выполнении обработчика заполнения документа программа пытается инициализировать переменную КатегорияПооперационныйУчет. Поскольку в базе данных нет нужной категории, поисковый запрос или метод НайтиПоНаименованию() возвращает пустую ссылку типа СправочникСсылка.КатегорииОбъектов или значение Неопределено (либо NULL при левом соединении в запросе). Когда выполнение доходит до условной конструкции Если, платформа 1С пытается неявно привести пустую ссылку или значение NULL к логическому типу Булево. Так как платформа не умеет этого делать, сессия аварийно завершается с системной ошибкой.

Решение проблемы на уровне пользователя (без изменения конфигурации)

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

1. Анализ старой информационной базы. Перейдите в исходную базу данных, из которой переносилась конфигурация. Откройте справочник «Категории объектов» (его можно найти через меню «Операции» -> «Справочники» -> «Категории объектов»). Найдите элемент, который отвечает за пооперационный учет. Обратите внимание на его точное наименование (важен каждый символ, пробел и регистр букв). Например: Пооперационный учет.
2. Воссоздание категории в новой базе. Откройте новую базу данных. Перейдите в справочник «Категории объектов» и создайте новый элемент. Введите наименование в точности так, как оно было написано в старой базе. Это критически важно, поскольку кастомный программный код, скорее всего, ищет эту категорию по наименованию.
3. Привязка категории к объектам учета. В зависимости от того, к какому объекту в старой базе привязывалась эта категория, вам необходимо установить соответствующую «галочку» в новой базе. Чаще всего категории привязываются к:
   • карточке конкретной Номенклатуры;
   • карточке Подразделения или ПодразделенияОрганизации;
   • документу-основанию ЗаданиеНаПроизводство.
   Откройте нужный объект в новой базе, перейдите на вкладку «Категории» (она доступна во многих стандартных справочниках и документах УПП), найдите созданную категорию «Пооперационный учет» и установите напротив нее флаг.

После этого попробуйте снова создать или заполнить документ ОтчетПроизводстваЗаСмену. Ошибка должна исчезнуть, так как код сможет успешно найти категорию и определить ее логическое значение.

Решение проблемы на уровне разработчика (исправление кода)

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

Рассмотрим, как исправить уязвимый код в общем модуле ОбработкаТабличныхЧастей на строке 451.

Вариант 1. Исправление логического условия (если переменная содержит ссылку)

Предположим, исходный код выглядит следующим образом:

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

Чтобы избежать ошибки при отсутствии категории в справочнике, перепишем условие, добавив проверку на заполненность ссылки:

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

Вариант 2. Исправление запроса к регистру сведений (если переменная получается из запроса)

Очень часто разработчики получают статус категории с помощью запроса к регистру сведений РегистрСведений.КатегорииОбъектов. Если в запросе используется левое соединение, а запись в регистре отсутствует, поле вернет значение NULL. Попытка использовать его в условии Если гарантированно вызовет ошибку.

Рассмотрим пример небезопасного запроса:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	КатегорииОбъектов.Категория КАК КатегорияПооперационныйУчет
    |ИЗ
    |	Справочник.Номенклатура КАК Номенклатура
    |	ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КатегорииОбъектов КАК КатегорииОбъектов
    |		ПО КатегорииОбъектов.Объект = Номенклатура.Ссылка
    |		И КатегорииОбъектов.Категория.Наименование = ""Пооперационный учет""
    |ГДЕ
    |	Номенклатура.Ссылка = &Ссылка";

В данном случае, если связь не найдена, поле КатегорияПооперационныйУчет примет значение NULL. Чтобы этого избежать, используем функцию ЕСТЬNULL непосредственно в тексте запроса, преобразуя отсутствующую связь в явное булево значение ЛОЖЬ:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ВЫБОР
    |		КОГДА КатегорииОбъектов.Категория ЕСТЬ NULL ТОГДА ЛОЖЬ
    |		ИНАЧЕ ИСТИНА
    |	КОНЕЦ КАК КатегорияПооперационныйУчет
    |ИЗ
    |	Справочник.Номенклатура КАК Номенклатура
    |	ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КатегорииОбъектов КАК КатегорииОбъектов
    |		ПО КатегорииОбъектов.Объект = Номенклатура.Ссылка
    |		И КатегорииОбъектов.Категория.Наименование = ""Пооперационный учет""
    |ГДЕ
    |	Номенклатура.Ссылка = &Ссылка";

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

Рекомендации по безопасному переносу данных в 1С

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

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

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