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