Работа с расширениями в 1С:ЗУП 3.1 — это стандарт де-факто для адаптации системы под нужды конкретного бизнеса. Однако у многих разработчиков возникает резонный вопрос: насколько безопасно добавлять новые реквизиты и как это скажется на последующих обновлениях типовой конфигурации. Рассмотрим подробно, как реализовать эту задачу наиболее эффективно и безопасно.
Когда мы говорим о добавлении нового поля, мы подразумеваем два этапа: добавление реквизита в структуру данных (метаданные) и вывод этого реквизита на форму. Проанализируем, почему способ вывода на форму критически важен для обновлений.
Если мы просто добавим форму в расширение и визуально перетащим на нее новый реквизит в редакторе, мы создаем жесткую привязку к текущей структуре формы основной конфигурации. В ЗУП 3.1 формы очень динамичны: элементы могут скрываться, перемещаться или переименовываться программно в зависимости от настроек учетной политики (например, используется ли расчет по обособленным подразделениям или ведется ли воинский учет). При обновлении типовой конфигурации фирма «1С» может значительно изменить структуру элементов формы. В этом случае расширение может «сломаться», а ваш новый элемент — перекрыть важные типовые поля или вовсе исчезнуть.
Рекомендованный подход: добавить реквизит в объект (справочник) расширения, а на форму выводить его программно. Выясним, как это сделать правильно.
Для того чтобы обновление проходило гладко, лучше всего использовать перехват события ПриСозданииНаСервере с типом вызова «После». Разберем этот алгоритм по шагам:
Посмотрим на пример кода, который позволит нам добавить поле на форму, не нарушая логику основной конфигурации:
&НаСервере
&После("ПриСозданииНаСервере")
Процедура пр_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Определяем родительскую группу, куда хотим поместить поле
// Например, в группу "Шапка" или "ГруппаДополнительныхРеквизитов"
Родитель = ЭтаФорма.Элементы.Найти("ГруппаШапка");
Если Родитель <> Неопределено Тогда
// Добавляем новый элемент формы
НовыйЭлемент = ЭтаФорма.Элементы.Добавить("пр_ДополнительноеПоле", Тип("ПолеФормы"), Родитель);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
// Указываем путь к данным (реквизиту, который мы добавили в расширение)
НовыйЭлемент.ПутьКДанным = "Объект.пр_ДополнительноеПоле";
// Устанавливаем заголовок, если нужно
НовыйЭлемент.Заголовок = "Дополнительный параметр";
КонецЕсли;
КонецПроцедуры
Такой метод гарантирует, что даже если фирма «1С» изменит положение других элементов, ваш код просто создаст новое поле в указанной группе или в конце формы, не вызывая конфликтов при объединении форм.
Чтобы избежать проблем в будущем, проанализируем несколько аспектов, которые часто упускаются из виду при разработке расширений для ЗУП 3.1.
1. Использование уникальных префиксов
Это золотое правило разработчика. Всегда именуйте свои объекты и реквизиты с префиксом (например, пр_, ит_, наш_). Если вы добавите реквизит с именем ДатаДоговора, а в следующем релизе «1С» добавит реквизит с точно таким же именем в основную конфигурацию, возникнет конфликт имен. Система не сможет применить расширение, и вам придется в экстренном порядке переименовывать свое поле, что приведет к потере всех накопленных в нем данных в рабочей базе.
2. Риски потери данных при операциях с расширением
Важно помнить: данные реквизита, добавленного через расширение, физически хранятся в таблицах базы данных, но неразрывно связаны с самим расширением. Если расширение будет удалено из списка или его имя будет изменено, SQL-таблицы с данными этого расширения будут уничтожены платформой. Если задача критически важная, стоит рассмотреть типовой механизм «Дополнительные реквизиты и сведения». Данные в нем хранятся в основной конфигурации, что архитектурно безопаснее.
3. Настройка прав доступа
Типовые роли (например, «Кадровик» или «Расчетчик») ничего не знают о вашем новом реквизите. Даже если вы добавили поле на форму, пользователи могут его не увидеть из-за отсутствия прав на чтение или просмотр. Необходимо в этом же расширении создать новую роль, дать ей права на новый реквизит и назначить эту роль пользователям через профили групп доступа.
4. Работа с отчетами и СКД
Реквизиты из расширений не всегда автоматически становятся доступны в настройках типовых отчетов. Если отчет построен на сложном запросе или использует временные таблицы в модуле менеджера, вам придется расширять и запрос отчета, чтобы новое поле можно было вывести в колонки. В этом плане типовые доп. реквизиты выигрывают, так как они бесшовно интегрированы в механизм «Изменить вариант» большинства отчетов ЗУП.
5. Режим совместимости конфигурации
Перед началом работ проверим режим совместимости вашей базы. В старых версиях платформы работа с данными в расширениях была ограничена. Современные релизы ЗУП 3.1 (начиная с 3.1.14 и выше) позволяют полноценно добавлять реквизиты, но всегда полезно убедиться, что ваша версия платформы соответствует требованиям конфигурации.
Добавление реквизита через расширение — это отличный способ кастомизации ЗУП 3.1, который не усложняет обновление при соблюдении трех условий:
Соблюдая эти правила, вы обеспечите стабильную работу системы и легкое применение будущих патчей и обновлений от вендора.