← На главную

В процессе доработки типовых конфигураций (1С:ERP, 1С:Управление торговлей, 1С:Комплексная автоматизация) регулярно возникает задача добавить новое поле к справочнику или документу. На практике разработчики и аналитики выбирают между несколькими подходами: использование встроенного механизма дополнительных реквизитов, добавление поля в конфигураторе с программным выводом на форму или создание реквизита в расширении. Проанализируем плюсы и минусы каждого варианта с точки зрения производительности, сложности обновления и работы в отчетах и алгоритмах.

Вариант 1. Использование механизма дополнительных реквизитов (БСП)

Штатный механизм Библиотеки Стандартных Подсистем (БСП) позволяет добавлять пользовательские поля в режиме «1С:Предприятие» без вмешательства в конфигуратор.

Преимущества:

1. Конфигурация остается на полной поддержке поставщика.
2. Пользователи и администраторы могут добавлять новые поля самостоятельного без привлечения программиста.
3. Типовые отчеты 1С автоматически поддерживают фильтрацию и группировку по дополнительным реквизитам.

Недостатки и ограничения:

1. Снижение производительности: Дополнительные реквизиты хранятся в табличной части объекта. В запросах к базе данных СУБД вынуждена делать соединения таблиц (JOIN), что на больших объемах данных замедляет выборку и исключает прямое использование физических индексов СУБД.
2. Сложность использования в алгоритмах: Для чтения и записи значений требуется обращаться к служебным функциям БСП или обходить табличную часть объекта, что усложняет программный код.
3. Ограничения типов данных и RLS: Поддерживаются только определенные типы данных. Настроить гибкое ограничение прав доступа (RLS) на конкретный дополнительный реквизит нельзя.

Использование дополнительных реквизитов в произвольных отчетах и СКД

Если дополнительный реквизит необходимо использовать в произвольном запросе или отчете на базе Система Компоновки Данных (СКД), можно связать его через механизм характеристик. Рассмотрим, как это работает на уровне СКД:

В конструкторе схемы компоновки данных на вкладке Характеристики настраивается связь основной таблицы со справочником видов свойств и табличной частью дополнительных реквизитов. После этого реквизит становится доступен через «плюс» от ссылки в пользовательском режиме так же, как и обычные поля объекта.

Вариант 2. Обычный реквизит в конфигураторе + программный вывод на форму

Этот способ заключается в том, что сам реквизит добавляется в объект справочника в конфигураторе, а его отображение на форме реализуется программно (через вызов из общего модуля) или через расширение.

Преимущества:

1. Высокая скорость работы и индексация: В свойствах реквизита можно установить признак Индексировать. СУБД создаст физический индекс, обеспечивающий мгновенный поиск и фильтрацию в динамических списках.
2. Простота в коде и запросах: Реквизит доступен напрямую (Ссылка.ИмяРеквизита) без вызова процедур БСП или обращения к табличным частям.
3. Готовность к интеграциям: Поле автоматически публикуется в REST API (OData), участвует в штатной синхронизации данных (EnterpriseData) и доступно для RLS.
4. Гибкость размещения на форме: Программный вывод позволяет поместить элемент в любую часть формы, а не только в стандартную группу доп. реквизитов.

Недостатки: Объекту требуется снять замок полной поддержки (перевести в режим поддержки с сохранением изменений).

Вариант 3. Реквизит непосредственно в Расширении конфигурации

Современная платформа 1С позволяет добавлять реквизиты прямо в расширение без изменения основной конфигурации.

Преимущества: Конфигурация остается на полной поддержки.

Риски и нюансы: Данные реквизитов расширений хранятся в отдельных таблицах СУБД. При случайном удалении или отключении расширения существует серьезный риск безвозвратно потерять накопленные данные. Также стоит учитывать нюансы реструктуризации при работе с распределенными базами данных (РИБ).

Итоговые рекомендации по выбору решения

Разберем, какой подход выбрать в зависимости от задачи:

1. Выбираем дополнительный реквизит (БСП): Если поле нужно только для визуального отображения информационного свойства, аналитики в типовых отчетах или если база должна оставаться на 100% нетронутой типовой конфигурацией.
2. Выбираем реквизит в конфигурации: Если поле будет активно участвовать в алгоритмах проведения, проверках при записи (ПередЗаписью, ПриЗаписи), участвовать в поиске по большим массивам данных или передаваться по интеграциям (OData / Web-сервисы). Для сохранения удобства обновлений вывод поля на форму лучше выполнить программно через модуль формы или расширение.