В процессе разработки или глубокой настройки системы «1С:Управление торговлей 11» (начиная с версий 11.4 и выше) часто возникает задача найти программный «корень» той или иной настройки. Пользователь видит флажок в интерфейсе, но программисту необходимо знать имя конкретной константы или функциональной опции, чтобы использовать её в запросах, коде или при доработке форм. Одной из таких неочевидных настроек является «Реализация товаров с нескольких складов». Разберем детально, как устроена эта функциональность «под капотом».
Начнем с того, что названия опций в пользовательском интерфейсе (в разделе «НСИ и администрирование») далеко не всегда совпадают с именами объектов в конфигураторе. Проанализируем, где именно система хранит состояние этого флажка.
Основным объектом метаданных, отвечающим за хранение этой настройки, является константа ИспользоватьСкладыВТабличнойЧастиДокументовПродажи. Именно в неё записывается значение Истина или Ложь при установке соответствующего флажка пользователем. Однако для управления интерфейсом в 1С используется механизм функциональных опций (ФО). Рассмотрим их связь:
ИспользоватьСкладыВТабличнойЧастиДокументовПродажи.Склад в табличной части Товары документов «Заказ клиента» или «Реализация товаров и услуг»), а также элементы форм и даже целые объекты.Таким образом, когда мы программно или интерактивно меняем константу, система автоматически скрывает или отображает колонки в документах продажи, опираясь на состав ФО.
Часто возникает вопрос: как эта опция влияет на справочник Склады? Посмотрим на реквизит ВыборГруппы (тип перечисления ВыборГруппыСкладов). Логика системы здесь следующая:
Если опция «Реализация товаров с нескольких складов» выключена, система ограничивает возможность использования групп складов в документах. Группа складов может служить лишь для удобства поиска («Для разрежения выбора»). Но как только мы включаем опцию, становится доступным значение «Для использования в заказах и накладных». Программно это проверяется в модулях справочника Склады через обращение к функциональной опции:
// Пример логики проверки функциональной опции
Если ПолучитьФункциональнуюОпцию("ИспользоватьСкладыВТабличнойЧастиДокументовПродажи") Тогда
// Разрешить использование групп в документах продажи
КонецЕсли;
Рассмотрим, откуда берется та самая «портянка» с настройками в разделе продаж. Форма настроек не генерируется полностью динамически, но и не является жестко зашитой. Основным инструментом здесь выступает обработка ПанельАдминистрированияУТ.
Проанализируем структуру этой обработки:
Продажи).НаборКонстант.ПриИзмененииРеквизита в модуле формы), который не только записывает константу, но и вызывает обновление параметров функциональных опций.Если вы хотите найти, как конкретный флажок влияет на интерфейс, выполните в конфигураторе «Поиск ссылок на объект» для константы ИспользоватьСкладыВТабличнойЧастиДокументовПродажи. Вы увидите, в каких процедурах обработки ПанельАдминистрированияУТ она используется.
Выясним, что происходит в момент проведения документа, когда эта опция включена. Традиционно склад указывается в «шапке» документа (реквизит Склад). Однако включение «Реализации с нескольких складов» меняет приоритеты:
Склад в каждой строке табличной части Товары.ТоварыНаСкладах измерение Склад заполняется значениями из строк. Это позволяет одним документом отгрузить товар, лежащий физически в разных местах.Проанализируем ситуацию: иногда программисты включают опцию для продаж и ожидают, что она заработает и для поступлений товаров. Это распространенная ошибка. В УТ 11 (и ERP) эти контуры разделены. Для закупок существует отдельная константа и функциональная опция — ИспользоватьСкладыВТабличнойЧастиДокументовЗакупок.
Если вам необходимо реализовать аналогичное поведение для документов «Приобретение товаров и услуг», вам придется активировать настройку в разделе НСИ и администрирование — Закупки. Механика работы там абсолютно идентична описанной выше.
Если вы столкнулись с задачей поиска подобной опции в будущем, воспользуйтесь следующим алгоритмом:
ФормаДокумента в РеализацияТоваровУслуг).Этот метод позволяет за считанные секунды сопоставить «человеческое» название из интерфейса с «программистским» именем объекта метаданных.