Почему возникает ошибка "Преобразование значения к типу Булево не может быть выполнено" при создании группы контрагентов в 1С:УТ 11 и как ее решить?

Проанализируем ситуацию, с которой часто сталкиваются разработчики при попытке адаптировать типовую конфигурацию 1С:Управление торговлей 11 под специфичные требования пользователей. Допустим, стоит задача — разделить список контрагентов на логические группы (например, "Заказчики" и "Исполнители"), чтобы облегчить их выбор в документах. Первое, что приходит на ум — включить иерархию в справочнике Контрагенты.

Однако при попытке создать и записать новую группу в этом справочнике система выдает критическую ошибку в процедуре ОбработкаПроверкиЗаполнения:

Ошибка при выполнении обработчика - 'ОбработкаПроверкиЗаполнения' по причине: Преобразование значения к типу Булево не может быть выполнено.

В тексте ошибки система ссылается на строку кода, содержащую следующее условие:

Если Объект.ОбособленноеПодразделение И ЗначениеЗаполнено(Объект.ГоловнойКонтрагент) Тогда

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

Выясняем причину программной ошибки

Архитектура типовой конфигурации УТ 11 изначально не предполагает использования иерархии (групп) в справочнике Контрагенты. Платформа 1С позволяет жестко задавать свойство «Использование» для каждого реквизита справочника: оно может быть установлено в значения «Для элемента», «Для группы» или «Для элемента и группы».

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

Поскольку у группы физически не предусмотрен реквизит ОбособленноеПодразделение, обращение к нему возвращает пустое значение — Null или Неопределено. В строке с ошибкой используется логический оператор И, который требует, чтобы с обеих сторон от него находились строго значения типа Булево (Истина или Ложь). Поскольку Null не является логическим типом, платформа не может выполнить преобразование и прерывает работу с ошибкой.

Вариант 1. Программное решение (модификация кода)

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

Перед выполнением любых проверок, которые специфичны исключительно для элементов справочника (включая проверку обособленных подразделений), мы должны добавить системную проверку на принадлежность записываемого объекта к группе. Для этого используется свойство ЭтоГруппа.

Обернем проблемный участок кода в стандартное условие:

Если Не Объект.ЭтоГруппа Тогда
    // Здесь располагается типовой код проверки
    Если Объект.ОбособленноеПодразделение И ЗначениеЗаполнено(Объект.ГоловнойКонтрагент) Тогда
        // логика проверки обособленного подразделения
    КонецЕсли;
КонецЕсли;

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

Вариант 2. Правильные архитектурные решения в УТ 11 (Рекомендуется)

Рассмотрим подробнее альтернативные варианты. Добавление иерархии в плоские справочники типовой конфигурации — плохая практика. Это усложняет дальнейшие обновления и может сломать типовые алгоритмы работы с контрагентами. Для решения исходной задачи (фильтрация заказчиков и исполнителей) в УТ 11 уже заложены мощные штатные инструменты, не требующие программирования.

1. Раздельное ведение партнеров и контрагентов. В разделе администрирования «CRM и маркетинг» можно включить опцию «Независимо вести партнеров и контрагентов». В УТ 11 именно справочник Партнеры отвечает за управленческую структуру, сегментацию и иерархию (кто является клиентом, поставщиком, конкурентом). Контрагенты же выступают лишь как юридические лица, привязанные к партнерам. Пользуйтесь иерархией справочника партнеров, а контрагентов оставьте плоским списком.
2. Использование дополнительных реквизитов. Если нужно просто разделить контрагентов на категории, создайте для справочника дополнительный реквизит (например, «Категория контрагента» с типом значения «Список» и вариантами «Заказчик», «Исполнитель»). В формах выбора документов пользователи смогут накладывать отбор по этому реквизиту.
3. Виртуальная группировка списка. Мы можем визуально представить плоский справочник в виде дерева, не меняя его структуру. Для этого в форме списка контрагентов нужно зайти в меню «Еще» — «Настроить список». На вкладке «Группировка» выберите поле, по которому нужно сгруппировать данные (например, бизнес-регион или созданный ранее дополнительный реквизит). Платформа сама сгруппирует элементы в удобные папки прямо на экране пользователя.
4. Типовые соглашения с клиентами и поставщиками. Если стоит задача ограничить выбор контрагентов в конкретном типе документов, используйте функционал соглашений. При выборе соответствующего соглашения в документе, система автоматически отфильтрует доступных контрагентов и партнеров, оставляя только тех, кто подходит под заданные условия работы.

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