Как адаптировать запросы и отчеты при переходе со свойств объектов в 1С:Бухгалтерии 2.0 на дополнительные реквизиты в 1С:Бухгалтерии 3.0?

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

1. Архитектурные отличия хранения свойств в БП 2.0 и БП 3.0

Проанализируем, как была устроена подсистема свойств в более ранних редакциях («1С:Предприятие 8.1» и «8.2»):

1. Все свойства хранились в общем регистре сведений ЗначенияСвойствОбъектов.
2. Виды свойств описывались в плане видов характеристик СвойстваОбъектов.
3. Категории объектов хранились в отдельном регистре СоставКатегорийОбъектов.

В конфигурациях нового поколения на управляемых формах (БП 3.0, УТ 11, ERP 2, КА 2) подсистема свойств была унифицирована по стандартам БСП. Единый механизм был разделен на две независимые концепции, а план видов характеристик получил имя ДополнительныеРеквизитыИСведения:

1. Дополнительные реквизиты — это свойства, которые логически дополняют сам объект (например, справочник Номенклатура или Контрагенты). Они хранятся непосредственно в объекте — в его табличной части ДополнительныеРеквизиты. При изменении такого свойства перезаписывается и версионируется сам объект.
2. Дополнительные сведения — это свойства, которые не меняют сам объект и могут редактироваться без блокировки элемента справочника или документа. Они хранятся в независимом регистре сведений ДополнительныеСведения.

2. Корректировка прямых запросов к базе данных

Выясним причину неработоспособности запросов: если в старом коде обращение шло напрямую к регистру сведений РегистрСведений.ЗначенияСвойствОбъектов, такой запрос в БП 3.0 завершится ошибкой отсутствия метаданных.

Рассмотрим, как изменить текст запроса в зависимости от того, как именно создано пользовательское свойство.

Вариант А: Свойство является дополнительным реквизитом

Если свойство хранится в табличной части объекта, выполняем левое соединение с этой табличной частью:

ВЫБРАТЬ
    Номенклатура.Ссылка КАК Номенклатура,
    Номенклатура.Артикул КАК Артикул,
    ДопРеквизиты.Значение КАК ЗначениеСвойства
ИЗ
    Справочник.Номенклатура КАК Номенклатура
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизиты
        ПО ДопРеквизиты.Ссылка = Номенклатура.Ссылка
        И ДопРеквизиты.Свойство = &НужноеСвойство

Вариант Б: Свойство является дополнительным сведением

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

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

3. Настройка механизма характеристик в СКД

Чтобы отчеты оставались универсальными и пользователи могли гибко выбирать свойства в пользовательских настройках, группировках и отборах без жесткого кодирования запроса, настроим механизм «Характеристики» в схеме компоновки данных.

Разберем по шагам, как описать характеристики в наборе данных СКД:

1. Откроем схему компоновки данных внешнего отчета.
2. На вкладке «Наборы данных» перейдем к разделу описания характеристик (или добавим блок ХАРАКТЕРИСТИКИ непосредственно в текст запроса).
3. Для дополнительных реквизитов справочника укажем:
   • Тип объекта: СправочникСсылка.Номенклатура
   • Таблица характеристик: ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения
   • Таблица значений: Справочник.Номенклатура.ДополнительныеРеквизиты
   • Поле объекта: Ссылка
   • Поле вида характеристики: Свойство
   • Поле значения: Значение
4. Для дополнительных сведений свяжем тип объекта с таблицей значений РегистрСведений.ДополнительныеСведения (где полем объекта выступает измерение Объект).

При таком подходе СКД автоматически сгенерирует виртуальные реквизиты, и пользователь сможет обращаться к ним через точку в пользовательском режиме (например, Номенклатура.[Цвет] или Контрагент.[Категория надежности]).

4. Программный доступ через функции БСП

Если требуется получать или записывать свойства в программном коде модулей, рекомендуется избегать прямого чтения табличных частей и регистров. Используем стандартизированные методы общих модулей подсистемы БСП УправлениеСвойствами и УправлениеСвойствамиСервер.

Посмотрим на пример получения значения свойства с помощью штатного API:

// Получение значения дополнительного реквизита или сведения
ЗначениеСвойства = УправлениеСвойствами.ЗначениеСвойства(СсылкаНаОбъект, СсылкаНаСвойство);

Использование официального API БСП гарантирует стабильность работы доработок при последующих обновлениях типовой конфигурации.

5. Рекомендации по оптимизации и альтернативы

Проанализируем особенности производительности при работе со свойствами:

1. Скорость выполнения запросов: Поиск и фильтрация по табличной части ДополнительныеРеквизиты на больших объемах данных (сотни тысяч элементов) выполняются медленнее, чем по штатным реквизитам шапки, так как в СУБД табличная часть хранится в отдельной физической таблице и не имеет специализированных индексов под каждое конкретное свойство.
2. Использование расширений конфигурации: На платформе 1С:Предприятие 8.3 для добавления реквизитов, по которым требуется высокая скорость отборов и построения сложных отчетов, эффективнее создавать реальные реквизиты через механизм Расширений конфигурации с сохранением данных в базе. Это позволяет сохранить конфигурацию на полной поддержке и избежать ограничений таблиц дополнительных свойств.