Условие видимости команд: расширение функционала БСП на примере 1С:ERP
1. Условия видимости подключаемых команд в БСП
Подключаемые команды — мощный механизм БСП в системе учета 1С, управляющий в числе прочего командами печати и отчётов. Этот механизм позволяет добавить команды для конкретного документа или иного объекта метаданных, и команды будут активны вне зависимости от того, как именно происходит доступ к объекту — через форму списка, форму самого объекта или элемента или вообще через какую-то обработку: список команд останется неизменным, что является очень удобным в работе.
Механизм в учетной системе 1С обладает гибкими настройками, позволяя задавать обработчик команды, приоритет и многие другие параметры. Он даже позволяет задать условия видимости — при помощи метода ДобавитьУсловиеВидимостиКоманды модуля ПодключаемыеКоманды или УправлениеПечатью. Однако методы эти обладают некоторыми ограничениями, которые могут помешать в реализации задуманной логики: задаваемые условия могут относиться только к тем реквизитам, которые отображаются на форме, так как сравнение происходит через ДанныеФормыКоллекция, и выполняется основная часть на клиентской стороне. Кроме того, невозможно проверить, к примеру, тип значения и задать условия, относящиеся к нему.
2. Расширение механизма проверки условий видимости подключаемых команд в конфигурации 1С:ERP
Проверка условий в конфигурации системы 1С происходит в функции УсловияВыполняются общего модуля ПодключаемыеКомандыКлиентСервер. В функцию передаётся массив условий и значения реквизитов, которые, как уже упоминалось выше, имеют тип ДанныеФормыКоллекция. Начало функции выглядит так:
Функция УсловияВыполняются(Условия, ЗначенияРеквизитов)
Для Каждого Условие Из Условия Цикл
ИмяРеквизита = Условие.Реквизит;
Если Не ЗначенияРеквизитов.Свойство(ИмяРеквизита) Тогда
Продолжить;
КонецЕсли;
УсловиеВыполняется = Истина;
Предположим, что стоит задача проверять тип значения определённого реквизита, которого нет на форме. К примеру, для любого списка, где есть документ «Приходный ордер на товары», нужно проверять тип основания. Для этого потребуется выполнить ряд шагов:
Для того чтобы получить возможность указывать проверяемые реквизиты через точку, необходимо переписать эту функцию так, чтобы в прежнем варианте использования она возвращала те же значения, но ещё и получила расширенный функционал. Для этого расширенные условия можно начинать с префикса (например, «Произвольный_») и прописать отдельную логику для подобных случаев:
Если СтрНачинаетсяС(ИмяРеквизита, “Произвольный_”) Тогда
ИмяРеквизита = СтрЗаменить(ИмяРеквизита, “Произвольный_”, “”);
В таком случае потребуется передавать реквизит как «Произвольный_Ссылка».
Затем можно проверить, есть ли обращение к реквизитам через точку — в таком случае на первом месте должен быть реквизит, который гарантированно есть на форме (например, Ссылка), а проверяться будет всё, что после точки:
МассивИмяРеквизита = СтрРазделить(ИмяРеквизита, “.”);
ИмяДоТочки = МассивИмяРеквизита[0];
ИмяПослеТочки = СтрЗаменить(ИмяРеквизита, ИмяДоТочки + “.”, “”);
Теперь уже получится «Произвольный_Ссылка.Основание».
Кроме того, было бы не лишним иметь возможность проверять тип значения реквизита — это может быть полезно в случаях, когда реквизит имеет составной тип, а команда печати или отчёта должна быть отображена только в случае конкретного типа (например, если основанием для приходного ордера является документ «Возврат товаров от клиента» и только в этом случае). Можно решить этот вопрос разными способами — например, добавлять к проверяемому реквизиту через точку «ТипЗначения» — это будет сигналом, что требуется сравнить с нужным не сам реквизит, а тип его значения.
После всех доработок добавление условия видимости будет выглядеть следующим образом:
ПодключаемыеКоманды.ДобавитьУсловиеВидимостиКоманды(
НоваяКоманда,
“Произвольный_Ссылка.Основание.ТипЗначения”,
Тип(“ДокументСсылка.ВозвратТоваровОтКлиента”),
ВидСравнения.Равно);
Необходимо отметить, что для правильной обработки условий необходимо сначала создать новую структуру с реквизитами, где именами будут проверяемые реквизиты, а значениями — то, что будет получено при помощи вспомогательных функций (подойдёт ЗначениеРеквизитаОбъекта из общего модуля ОбщегоНазначенияУТВызовСервера). При необходимости нужно будет проверить тип полученного значения.
Но проверка отсутствующих на форме реквизитов — это не единственная доработка, которую можно сделать. К примеру, ещё одной потенциальной доработкой может быть внесение в механизм проверки условий изменений, которые позволят проверять значения реквизитов табличной части документа (или вообще её заполненность).
Данный способ имеет как свои преимущества, так и недостатки. К числу преимуществ относится универсальность по отношению к любым формам, к числу недостатков — снижение быстродействия, связанное с постоянной проверкой значения реквизитов объекта; следует иметь это в виду при выборе стратегии доработки.
Подобная доработка позволит более гибко подходить к процессу управления подключаемыми командами, накладывая более сложные условия. Необходимо лишь помнить, что подключаемые команды не обновляются сами по себе — для обновления состава команд после изменения реквизитов может потребоваться или обновление формы, или указание, что после изменения определённых реквизитов нужно обновить команды (процедура НачатьОбновлениеКоманд).
Наша компания может осуществить эту или подобную доработку программы 1С:ERP под ваши нужды, чтобы отключить возможность печати документа или просмотра отчёта в тех случаях, когда это необходимо.
Горбунов Роман ,
Специалист компании ООО “Кодерлайн”