Как задать дополнительные свойства для определенной группы номенклатуры в 1С:Управление торговлей 11?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Торговля и дистрибуция
← На главную

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

Архитектурные ограничения подсистемы свойств БСП

Выясним причину, почему в типовой конфигурации нельзя привязать свойства непосредственно к папке (группе) номенклатуры:

  1. Назначение иерархии справочника: В современных типовых конфигурациях на платформе 1С:Предприятие 8.3 папки справочника Номенклатура служат исключительно для визуальной группировки и навигации в формах списка. Они не являются классификаторами учетных характеристик.
  2. Владелец набора свойств: В Библиотеке стандартных подсистем (БСП) в подсистеме «Свойства» наборы дополнительных реквизитов жестко привязаны к предопределенным наборам или отдельным объектам-владельцам. Для номенклатуры таким владельцем всегда выступает справочник ВидыНоменклатуры.
  3. Зависимости реквизитов: Типовой механизм настройки видимости и доступности реквизитов умеет проверять условия только по значениям других дополнительных реквизитов того же набора. Настроить видимость по значению стандартного реквизита объекта (в том числе по реквизиту Родитель) штатными средствами невозможно.

Вариант 1. Методологически правильное решение (без изменения конфигурации)

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

Разберем по шагам, как перенести классификацию свойств на виды номенклатуры:

  1. Перейдем в раздел НСИ и администрирование — Классификаторы номенклатуры — Виды номенклатуры.
  2. Создадим отдельный вид номенклатуры для каждой товарной категории, требующей уникального состава полей.
  3. В карточке созданного вида номенклатуры перейдем на закладку Дополнительные реквизиты и добавим только те свойства, которые относятся именно к этой категории.
  4. Перенесем существующие позиции номенклатуры в новые виды с помощью встроенной обработки Групповое изменение реквизитов либо штатного помощника изменения вида номенклатуры.

Вариант 2. Использование служебного дополнительного реквизита

Если специфика учета категорически запрещает создавать множество отдельных видов номенклатуры (например, вид должен оставаться один — «Товар»), рассмотрим обходной путь через типовые механизмы условий видимости.

Разберем реализацию этого способа:

  1. В карточке общего вида номенклатуры создадим общий дополнительный реквизит со списком значений, например КатегорияСвойств или Подкатегория.
  2. Для каждого целевого дополнительного реквизита настроим зависимость видимости и доступности от значения созданного реквизита КатегорияСвойств.
  3. При заполнении карточки номенклатуры пользователь выбирает категорию свойств, после чего на форме динамически активируются нужные поля.

Вариант 3. Программное управление видимостью через расширение конфигурации

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

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


&НаСервере
Процедура УправлениеВидимостьюСвойствПоГруппе(Форма, ТекущийОбъект)
    
    // Проверяем принадлежность родительской группе справочника
    ЭтоОдежда = ТекущийОбъект.Родитель.ПринадлежитЭлементу(Справочники.Номенклатура.НайтиПоНаименованию("Одежда"));
    ЭтоОбувь  = ТекущийОбъект.Родитель.ПринадлежитЭлементу(Справочники.Номенклатура.НайтиПоНаименованию("Обувь"));
    
    // Находим элементы формы, созданные подсистемой свойств БСП, и управляем их видимостью
    ЭлементРазмер = Форма.Элементы.Найти("ДополнительныйРеквизит_Размер");
    Если ЭлементРазмер <> Неопределено Тогда
        ЭлементРазмер.Видимость = ЭтоОдежда ИЛИ ЭтоОбувь;
    КонецЕсли;

    ЭлементМатериалПодошвы = Форма.Элементы.Найти("ДополнительныйРеквизит_МатериалПодошвы");
    Если ЭлементМатериалПодошвы <> Неопределено Тогда
        ЭлементМатериалПодошвы.Видимость = ЭтоОбувь;
    КонецЕсли;

КонецПроцедуры

Подводные камни при смене групп и видов номенклатуры

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

  1. Хранение данных в табличной части: Значения дополнительных реквизитов физически сохраняются в табличной части ДополнительныеРеквизиты объекта СправочникСсылка.Номенклатура.
  2. Появление неактуальных данных: Если позиция номенклатуры перемещается в другую группу (или у нее меняется вид), скрытые реквизиты не удаляются автоматически из табличной части. На форме они перестают отображаться (либо выводятся как зачеркнутые), но продолжают сохраняться в базе, попадать в универсальные отчеты и передаваться при интеграциях (например, при выгрузке на сайт или в маркетплейсы).
  3. Очистка реквизитов: При изменении иерархического родителя или смене вида номенклатуры рекомендуется программно очищать строки табличной части ДополнительныеРеквизиты, свойства которых больше не входят в актуальный набор объекта.
← На главную