Как добавить дополнительные реквизиты к характеристикам номенклатуры в УТ 11, если план видов характеристик нельзя доработать в расширении?

При переходе со старых систем, например, с 1С 7.7, на современные конфигурации, такие как "Управление торговлей 11.5", часто возникает задача переноса данных со сложной структурой. Классический пример — характеристики номенклатуры, у которых в старой системе были собственные реквизиты (атрибуты). В УТ 11 для этого используется ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения. Однако, если попытаться добавить в него новые реквизиты через расширение, можно столкнуться с технологическим ограничением платформы, которое не позволяет модифицировать таким образом этот тип объектов.

Рассмотрим, как решить эту задачу, не изменяя типовую конфигурацию, а используя правильные архитектурные подходы, рекомендованные для платформы 1С:Предприятие 8.

Решение 1: Использование Регистра сведений для хранения дополнительных настроек

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

Разберем по шагам, как это сделать:

1. Создайте в расширении новый объект — Регистр сведений. Назовем его, например, ДополнительныеНастройкиХарактеристик.
2. Определите структуру регистра:
   • Измерение: Добавьте одно измерение, назовем его Характеристика. Его тип должен быть ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения. Это поле будет связывать запись в нашем регистре с конкретной характеристикой (например, с "Тип крепления").
   • Ресурсы: Здесь мы добавляем все недостающие поля. Например, для задачи из форума это будут: ВыгружатьНаСайт (тип Булево), УсловиеПроверки (тип Строка), ТипРасчета (тип Строка или ссылка на новый справочник) и так далее.
3. Создайте форму для удобного редактирования этих настроек. Ее можно открывать из формы элемента плана видов характеристик по кнопке.

В чем преимущества такого подхода?

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

Посмотрим на пример, как получить значение настройки программно:

// Предположим, у нас есть ссылка на характеристику "Тип крепления"
// Переменная СсылкаНаХарактеристику содержит эту ссылку

// Создаем структуру для отбора
Отбор = Новый Структура("Характеристика", СсылкаНаХарактеристику);

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

Если ЗначенияНастроек <> Неопределено И ЗначенияНастроек.ВыгружатьНаСайт Тогда
    // Выполняем логику выгрузки на сайт
    ВыполнитьВыгрузкуНаСайт();
КонецЕсли;

Решение 2: Пересмотр архитектуры и логики выгрузки

Иногда проблема кроется не в технических ограничениях, а в самой постановке задачи. Стоит задаться вопросом: действительно ли признак "Выгружать на сайт" является неотъемлемым свойством самой характеристики?

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

• В модуле обмена с сайтом создается настройка, где пользователь сам выбирает, какие характеристики (или группы характеристик) нужно выгружать.
• Это позволяет отделить данные (характеристики) от логики их обработки (выгрузка).
• Такой подход более гибкий: если завтра появится второй сайт с другими правилами выгрузки, вам не придется добавлять еще одно булево поле "Выгружать на сайт 2" во все характеристики. Вы просто создадите новый профиль обмена.

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

Почему стандартный механизм "Дополнительные реквизиты" не подходил?

В обсуждении возникла путаница с основным механизмом платформы — дополнительными реквизитами и сведениями. Важно понимать разницу:

Механизм дополнительных реквизитов предназначен для расширения свойств объектов (например, конкретного товара или его характеристики-значения), а не их типов.

Например, вы можете добавить доп. реквизит "Выгружать на сайт" к самой номенклатуре или к ее характеристике-экземпляру (например, к конкретной характеристике "Крепление: Стена, Цвет: Красный"). Доступ к значениям таких реквизитов осуществляется через общий модуль УправлениеСвойствами.

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