При адаптации типовых конфигураций «1С:Предприятие 8» (например, «1С:Зарплата и управление персоналом 3.1», «1С:ERP» или «1С:Управление торговлей 11») разработчики регулярно сталкиваются с задачей добавления новых реквизитов в документы. Современная платформа предоставляет для этого сразу несколько механизмов. Каждый из них имеет свои критически важные особенности, связанные с производительностью СУБД, безопасностью хранения данных и трудоемкостью последующих обновлений.
В этой статье мы подробно проанализируем три основных подхода к добавлению реквизитов, разберем их плюсы и минусы, а также выработаем оптимальные правила выбора архитектурного решения под конкретные бизнес-требования.
---
Этот инструмент является частью стандартной подсистемы БСП (Библиотека стандартных подсистем) и доступен пользователям непосредственно в режиме «1С:Предприятие» без необходимости изменения метаданных в конфигураторе.
Технические особенности реализации:
Дополнительные реквизиты физически хранятся не в основной таблице документа СУБД, а в скрытой табличной части ДополнительныеРеквизиты конкретного объекта. С технической точки зрения эта табличная часть связывает документ с Планом видов характеристик ДополнительныеРеквизитыИСведения и справочником ЗначенияСвойствОбъектов.
Рассмотрим детально преимущества данного подхода:
Разберем существенные недостатки и ограничения использования дополнительных реквизитов БСП:
ПеречислениеСсылка без доработки Плана видов характеристик в конфигураторе невозможно. Чтобы обойти это ограничение без программирования, мы рекомендуем использовать предопределенный тип данных «Дополнительное значение». В этом случае вы можете создать закрытый список строковых значений прямо в режиме «1С:Предприятие», что для конечного пользователя будет выглядеть как выбор из стандартного перечисления.---
Начиная с версии платформы 8.3.11, разработчики получили возможность добавлять собственные реквизиты, влияющие на структуру базы данных, непосредственно внутрь расширений конфигурации.
Технические особенности реализации:
При добавлении реквизита в расширение платформа физически создает в СУБД отдельную «таблицу-спутник» (satellite table), которая связана с основной таблицей документа отношением «один к одному» по внутреннему уникальному идентификатору (GUID). При обращении к реквизиту расширения в запросе платформа неявно соединяет эти таблицы.
Рассмотрим преимущества использования расширений:
ДокументСсылка.ИмяРеквизита), а также без проблем использовать его в любых запросах и алгоритмах проведения.Проанализируем критические недостатки и риски добавления реквизитов через расширения:
---
Профессиональный подход, который сочетает в себе максимальную производительность, надежность сохранения данных и простоту дальнейших обновлений системы.
Технические особенности реализации:
Для добавления нового поля мы включаем возможность изменения основной конфигурации (снимаем «замочек» с конкретного документа, при этом общая поддержка всей конфигурации сохраняется). Добавляем реквизит непосредственно в структуру документа в основной конфигурации, обязательно используя уникальный префикс (например, Префикс_ВидСогласования). Всю программную логику (обработку проведения, валидацию данных при записи, интеграционные обмены) мы пишем исключительно в расширении конфигурации.
Рассмотрим, почему этот способ является наиболее предпочтительным для крупных и ответственных проектов:
---
Если вы выбрали гибридный метод или добавление через расширение, вам потребуется отобразить новое поле на управляемой форме документа. Многие разработчики заимствуют типовую форму в расширение и перетаскивают реквизит на нее визуально в редакторе форм. Это грубая ошибка!
Если фирма «1С» в очередном релизе изменит интерфейс, состав элементов или структуру этой формы, ваша заимствованная форма в расширении вступит в конфликт с новой типовой формой. В лучшем случае у пользователя поплывет дизайн, в худшем — документ вообще откажется открываться.
Выясним правильный путь решения этой задачи — программное добавление элементов на форму. Мы перехватываем событие формы в расширении и создаем элементы кодом.
Проанализируем пример кода, который реализует такое добавление в процедуре ПриСозданииНаСервере:
&После("ПриСозданииНаСервере")
Процедура Префикс_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверим, не добавлен ли уже элемент на форму, чтобы избежать дублирования
Если Элементы.Найти("Префикс_ВидСогласования") = Неопределено Тогда
// Определим группу на форме, куда мы хотим поместить наш новый реквизит
ГруппаФормы = Элементы.ГруппаШапка;
// Добавим новое поле ввода на форму программно
НовыйЭлемент = Элементы.Добавить("Префикс_ВидСогласования", Тип("ПолеФормы"), ГруппаФормы);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
// Свяжем элемент формы с реквизитом объекта базы данных
НовыйЭлемент.ПутьКДанным = "Объект.Префикс_ВидСогласования";
НовыйЭлемент.Заголовок = "Вид согласования документа";
КонецЕсли;
КонецПроцедуры
При таком подходе обновление основной конфигурации от поставщика никак не сломает интерфейс вашего документа, поскольку платформа автоматически скомпонует типовую форму, а ваше расширение аккуратно встроит элемент ввода в нужную группу при открытии.
---
Чтобы быстро и безошибочно принять решение при проектировании архитектуры базы данных, ориентируйтесь на следующую логическую схему: