При работе в конфигурации «1С:Комплексная автоматизация 2.4» (или «1С:ERP 2») пользователи и разработчики часто сталкиваются с ограничением стандартного механизма дополнительных реквизитов. По умолчанию система позволяет выбирать в качестве типов значений только примитивные типы (строка, число, дата, булево) или элементы справочника Дополнительные значения. Однако на практике часто возникает задача связать документ, например, «Заказ поставщику», с другим документом, таким как «Приходный ордер на товары», напрямую через механизм свойств. Разберем подробно, как решить эту задачу, проанализируем ограничения и выберем наиболее эффективный метод.
Механизм дополнительных реквизитов и сведений построен на базе Библиотеки стандартных подсистем (БСП). В основе лежит План видов характеристик (ПВХ) ДополнительныеРеквизитыИСведения. Список доступных типов данных в этом ПВХ жестко ограничен разработчиками фирмы «1С» на уровне метаданных. Это сделано для обеспечения универсальности: система должна гарантированно уметь отображать, выбирать и обрабатывать значения в общих формах и отчетах.
Если мы попытаемся просто создать дополнительный реквизит в пользовательском режиме, мы увидим ограниченный набор справочников. Типы ДокументСсылка в этот список, как правило, не входят, так как это могло бы привести к избыточному росту таблиц и сложностям при обновлении конфигурации. Проанализируем способы обхода этого ограничения.
Это наиболее технологичный способ, если мы хотим остаться в рамках стандартного механизма «Дополнительные реквизиты». Рассмотрим по шагам, как добавить тип ДокументСсылка.ПриходныйОрдерНаТовары в список доступных типов.
ДополнительныеРеквизитыИСведения.Тип значения.Приходный ордер на товары.Важный нюанс: После изменения типа в ПВХ через расширение, стандартная форма выбора значения может работать некорректно, если БСП ожидает там только «Дополнительные значения». Рассмотрим программную корректировку этого поведения далее.
Иногда требуется изменить тип реквизита программно, не меняя метаданные вручную для каждого объекта. Мы можем использовать встроенный язык 1С для динамического расширения описания типов. Рассмотрим пример кода, который позволяет модифицировать описание типов для конкретного элемента ПВХ.
Проанализируем ситуацию: нам нужно, чтобы конкретный доп. реквизит «понял», что в нем теперь хранится ссылка на документ. Для этого можно использовать следующий подход:
// Пример программной установки типа значения для дополнительного реквизита
СсылкаНаСвойство = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("Приходный ордер");
ОбъектСвойства = СсылкаНаСвойство.ПолучитьОбъект();
// Формируем новый массив типов, добавляя к существующим ссылку на документ
МассивТипов = ОбъектСвойства.ТипЗначения.Типы();
МассивТипов.Добавить(Тип("ДокументСсылка.ПриходныйОрдерНаТовары"));
ОбъектСвойства.ТипЗначения = Новый ОписаниеТипов(МассивТипов);
ОбъектСвойства.Записать();
Однако помните, что если в самих метаданных ПВХ ДополнительныеРеквизитыИСведения (в конфигураторе) этот тип не разрешен, ОписаниеТипов может его проигнорировать. Именно поэтому предварительное расширение метаданных через механизм расширений является обязательным шагом.
Как отмечалось в обсуждении, использование дополнительных реквизитов для хранения ссылок на важные документы — это не всегда лучшее решение. Рассмотрим альтернативу: добавление реального реквизита в объект Документ.ЗаказПоставщику через расширение.
Преимущества этого подхода:
Для реализации этого метода выполним следующие действия:
Заказ поставщику в наше расширение.ПриходныйОрдер_Расш с типом ДокументСсылка.ПриходныйОрдерНаТовары.Если задача заключается только в том, чтобы иметь возможность быстро перейти из «Заказа поставщику» в «Приходный ордер», выясним причину, по которой не используется стандартный механизм связей. В «1С:КА 2.4» существует регистр сведений СвязиДокументов, который наполняет отчет «Структура подчиненности».
Если мы создаем ордер на основании заказа, связь создается автоматически. Если же нам нужно создать связь вручную или программно, мы можем просто сделать запись в этот регистр. Разберем пример кода:
МенеджерЗаписи = РегистрыСведений.СвязиДокументов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Источник = СсылкаНаЗаказ;
МенеджерЗаписи.Приемник = СсылкаНаОрдер;
МенеджерЗаписи.ТипСвязи = Перечисления.ТипыСвязейДокументов.Основание;
МенеджерЗаписи.Записать();
После этого документ появится в стандартном отчете «Связанные документы», и пользователь сможет легко перемещаться между ними без создания дополнительных полей.
В сообщении №3 предлагалось использовать строковый тип. Рассмотрим подробнее, почему это плохая практика для ссылочных данных. Если записать в строковый доп. реквизит просто представление документа, мы потеряем возможность:
Поэтому, если требуется именно ссылка, лучше потратить время на настройку типа через расширение ПВХ или создание прямого реквизита.
Проанализировав ситуацию, можно сделать следующие выводы:
1. Если вам нужно быстрое и надежное решение для типовой конфигурации, используйте расширение для добавления реального реквизита в документ. Это избавит от проблем с производительностью и отображением в отчетах.
2. Если политика компании запрещает менять структуру таблиц объектов, используйте программное расширение типов в ПВХ ДополнительныеРеквизитыИСведения через расширение, но будьте готовы к кастомизации форм выбора.
3. Для простой навигации между документами рассмотрите возможность регистрации связей в типовом регистре СвязиДокументов.
Выбор метода зависит от того, насколько часто этот реквизит будет использоваться в аналитике. Для разовых связей подойдет стандартная структура подчиненности, для глубокой аналитики — только типизированный реквизит.