← На главную

При доработке типовых конфигураций разработчики регулярно сталкиваются с задачей добавления новых справочников, документов, регистров или реквизитов. Главная сложность заключается в выборе имени объекта: если назвать его слишком абстрактно или стандартно, существует высокий риск того, что фирма «1С» в очередном релизе типового решения введет одноименный объект. В таком случае при сравнении и объединении конфигураций возникнет критическая коллизия, способная привести к потере данных или нарушению структуры таблиц СУБД. Разберем основные стандарты платформы, рекомендации вендора и проверенные практические подходы к именованию кастомных объектов метаданных.

Официальные стандарты платформы и общие правила

Прежде чем выбирать стратегию префиксов, проанализируем базовые требования стандартов разработки 1С к идентификаторам объектов:

1. Стиль PascalCase (UpperCamelCase): каждое логическое слово в имени объекта пишется слитно и начинается с заглавной буквы (например, НастройкиИнтеграцииСКлентом).
2. Отказ от символа подчеркивания: стандарт не рекомендует использовать знак «_» в именах объектов метаданных. Имя должно состоять исключительно из букв и цифр и обязательно начинаться с буквы. Символ подчеркивания резервируется платформой для служебных конструкций и сгенерированных имен форм.
3. Ограничение длины: длина имени любого объекта метаданных не должна превышать 80 символов. Слишком громоздкие префиксы и длинные названия могут вызвать ошибки при сериализации метаданных и выгрузке конфигурации в файлы.
4. Читаемость и отказ от «птичьего языка»: не следует применять нечитаемые сокращения инициалов или аббревиатур. Имена должны легко читаться и однозначно отражать бизнес-смысл объекта.

Вариант 1. Узкоспециализированные функциональные имена

Один из самых надежных способов избежать коллизий без засорения конфигурации техническими префиксами — правильный выбор уровня абстракции названия. Типовые библиотеки (например, БСП) резервируют за собой общие имена: Настройки, Логирование, Интеграция, ОчередьЗаданий. Если добавить объект с простым именем НастройкиФормы, вероятность пересечения с типовым релизом в будущем крайне велика.

Рассмотрим правила формирования специализированного имени:

1. Определим точный бизнес-контекст доработки (например, не просто Настройки, а НастройкиИнтеграцииЛогистики).
2. Укажем целевую функциональную подсистему в названии (например, УправлениеДоставкойРабочееМестоДиспетчера).
3. Конкретизируем сущность, чтобы она не могла появиться в универсальной типовой конфигурации в таком же виде.

Вариант 2. Использование проектных префиксов и суффиксов

Если в компании принят регламент обязательного выделения доработанных объектов префиксами, важно выбрать правильный шаблон. Использование имени конкретного разработчика или юридического наименования организации-заказчика создает проблемы: код становится непереносимым между базами, а после смены нескольких специалистов дерево метаданных превращается в хаотичный набор разнородных приставок.

Разберем оптимальные подходы к формированию префиксов и постфиксов:

1. Префикс проекта или подсистемы: фиксированная аббревиатура из 2–4 символов, отражающая название дорабатываемого функционального контура (например, ПРЖ_ или СБС_). При этом в свойстве Синоним префикс обязательно убирается, чтобы пользователи в режиме «1С:Предприятие» видели аккуратное название.
2. Унифицированный суффикс (постфикс): добавление смыслового слова в конец идентификатора (например, НастройкиФормРасширенный, ПечатьЭтикетокДополнительный). Суффиксная схема удобна тем, что в дереве метаданных Конфигуратора объекты сортируются по алфавиту основного слова, а не группируются искусственно по одинаковому префиксу.

Вариант 3. Разработка в расширениях конфигурации (.cfe)

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

Проанализируем механику работы расширений:

1. При создании расширения ему задается уникальный префикс (например, МойПроект_).
2. Все добавляемые в расширение объекты метаданных, реквизиты и формы автоматически получают этот префикс во внутреннем пространстве имен.
3. Основная конфигурация остается на типовой поддержке без риска коллизий при обновлении, так как объекты расширения хранятся отдельно от структуры поставщика.

Организация кастомных объектов в дереве метаданных

Независимо от выбранной схемы именования, для удобства сопровождения и последующего обновления конфигурации рекомендуется придерживаться следующего алгоритма группировки:

1. Создадим отдельную подсистему для доработок (например, ДоработанныйФункционал или подсистему с названием конкретного проекта).
2. Включим все созданные объекты метаданных в состав этой подсистемы. Это позволит при обновлении конфигурации быстро отфильтровать дерево объектов по подсистеме и визуально контролировать целостность кастомных решений.
3. Заполним свойство Комментарий у каждого нового объекта, указав номер задачи, дату создания и назначение объекта, чтобы исключить потерю контекста при работе в команде.

Технические риски при коллизиях имен

Посмотрим, что происходит при совпадении имени кастомного объекта с новым объектом поставщика при обновлении. Механизм сравнения и объединения конфигураций сопоставляет собственные объекты по внутренним идентификаторам (UUID), а новые объекты поставщика — по имени. Если имена совпадут, конфигуратор может предложить объединить ваш объект с типовым. Это приведет к несовместимости типов, изменению структуры таблиц базы данных и возможным ошибкам механизмов БСП (таких как печать, регламентные задания и версионирование), где имена метаданных часто используются в виде строковых констант.

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