При разработке расширений для типовых конфигураций (например, 1С:Бухгалтерия 3.0 или 1С:ERP) программисты часто сталкиваются с необходимостью добавить новые документы или справочники в стандартные механизмы поиска и отображения связей — для этого подойдёт настройка связей между документами без изменения конфигурации. Одним из таких механизмов является Критерий отбора (например, популярный критерий СвязанныеДокументы). Однако при попытке изменить его состав в расширении многие обнаруживают, что это свойство недоступно для редактирования. Давайте разберем, почему так происходит и какими способами можно решить эту задачу.
Для начала выясним причину, по которой платформа 1С:Предприятие (даже в самых современных версиях, таких как 8.3.24 и выше) не позволяет изменять свойство Состав у заимствованных критериев отбора. С технической точки зрения КритерийОтбора — это не просто логическое описание связей, а физическая таблица в базе данных SQL — разобраться в устройстве базы поможет анализ физической структуры таблиц и индексов базы данных. Когда мы добавляем объект в состав критерия в основной конфигурации, платформа перестраивает индексы и структуру этой таблицы, чтобы обеспечить мгновенный поиск всех связанных записей.
Механизм расширений задуман как надстройка, которая должна подключаться «на лету» без масштабной реструктуризации базы данных. Если бы платформа позволяла динамически менять состав критерия через расширение, каждое обновление расширения могло бы приводить к длительной блокировке таблиц для перестроения индексов критерия отбора. Именно поэтому разработчики 1С оставили список объектов критерия доступным только для чтения. Ни версия платформы (например, 8.3.19 или 8.3.22), ни режим совместимости напрямую не снимают это архитектурное ограничение.
Если нам необходимо сгруппировать данные по определенному типу ссылки, мы можем пойти путем создания нового объекта метаданных — в этом поможет инструмент для анализа и редактирования объектов метаданных. Рассмотрим этот процесс по шагам:
КритерийОтбора.ДокументСсылка.МойНовыйДокумент).Этот способ хорош тем, что он работает на уровне базы данных и обеспечивает высокую скорость выборки, но требует дополнительных трудозатрат на интеграцию в пользовательский интерфейс.
В современных типовых решениях, построенных на базе Библиотеки стандартных подсистем (БСП), вывод связанных документов в структуру подчиненности реализован более гибко. Вместо жесткой привязки только к критерию отбора, система использует программный интерфейс. Разберем, как добавить наш объект в структуру подчиненности через расширение модуля.
Проанализируем работу подсистемы «Связанные документы» — для решения этой задачи есть инструмент архитектурного анализа конфигураций и расширений. В БСП существует механизм переопределения объектов. Нам нужно найти общие модули, отвечающие за определение связей. Чаще всего это модули типа СвязанныеДокументыПереопределяемый или использование процедур-обработчиков в модулях менеджеров объектов.
Рассмотрим пример программного добавления связи через расширение метода в БСП:
&После("ПриОпределенииОбъектовСвязанныхДокументов")
Процедура Расш1_ПриОпределенииОбъектовСвязанныхДокументов(СписокОбъектов)
// Добавляем наш новый документ из расширения в общий список
// объектов, для которых должна работать структура подчиненности
СписокОбъектов.Добавить(Метаданные.Документы.Расш1_МойНовыйДокумент);
КонецПроцедуры
После этого необходимо убедиться, что в модуле менеджера вашего нового документа прописаны правила поиска связей. Система БСП сама обратится к метаданным или программным запросам, чтобы построить дерево документов, не опираясь исключительно на стандартный КритерийОтбора.
Если ваша задача — сделать так, чтобы в типовой форме структуры подчиненности (которая открывается из документа по кнопке «Связанные документы») отображались специфические связи, которые не предусмотрены типовым критерием, мы можем применить метод «перехвата» формирования данных.
Выполним следующие шаги:
СтруктураПодчиненности.&После или &Вместо, модифицируем запрос.Пример логики изменения запроса — для реализации подобных доработок пригодится анализ метаданных и отладка сложных запросов:
Проанализируем ситуацию: стандартный запрос выбирает данные из КритерийОтбора.СвязанныеДокументы. Мы можем добавить к этому результату объединение (UNION ALL) с нашим собственным запросом, который выбирает данные по новым реквизитам, добавленным в расширении.
&Вместо("СформироватьДеревоСвязей")
Процедура Расш1_СформироватьДеревоСвязей(Параметры)
// Вызываем оригинальную логику, если нужно получить типовые связи
ПродолжитьВызов(Параметры);
// Дописываем свой код для поиска дополнительных связей
// Например, ищем записи в нашем регистре сведений или по новым реквизитам
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Док.Ссылка КАК Ссылка
|ИЗ
| Документ.Расш1_МойДокумент КАК Док
|ГДЕ
| Док.ДокументОснование = &ОсновнойОбъект";
Запрос.УстановитьПараметр("ОсновнойОбъект", Параметры.ТекущийОбъект);
// Далее следует логика добавления найденных строк в дерево на форме
КонецПроцедуры
Мы выяснили, что напрямую изменить состав критерия отбора в расширении нельзя из-за ограничений архитектуры платформы. Однако, это не является непреодолимым препятствием. Выбор решения зависит от вашей конечной цели:
СтруктураПодчиненности через программный код.Помните, что использование механизмов БСП является наиболее «чистым» и предпочтительным способом при работе с типовыми конфигурациями, так как это сохраняет поддержку и упрощает дальнейшие обновления системы.