Как правильно изменять типовую конфигурацию в 1С?

← На главную

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

Главное правило разработчика 1С

Перед тем как открыть конфигуратор и внести первые изменения, мы должны четко зафиксировать ключевой постулат: типовую конфигурацию по возможности изменять НЕЛЬЗЯ. Любое прямое вмешательство в типовой код увеличивает стоимость владения системой, усложняет обслуживание и повышает риск возникновения критических ошибок при автоматических обновлениях.

Прежде чем прибегать к программированию, проанализируем задачу и пойдем по пути от простого к сложному, используя иерархию методов доработки.

Этап 1. Возможности пользовательского режима (No-code / Low-code)

Современные типовые решения 1С, построенные на Библиотеке стандартных подсистем (БСП), обладают колоссальным встроенным функционалом для адаптации под требования пользователя без изменения кода:

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

Если этих возможностей недостаточно, мы переходим к программным методам, стараясь сохранить конфигурацию "на замке" (на полной поддержке).

Этап 2. Внешние отчеты, обработки и печатные формы

Для создания новых печатных форм, отчетов или обработок заполнения табличных частей используем механизм Дополнительных отчетов и обработок. Эти объекты создаются во внешних файлах с расширениями .epf или .erf и регистрируются в информационной базе через пользовательский интерфейс.

Преимущества этого подхода:

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

Этап 3. Расширения конфигурации — современный стандарт доработки

Если нам необходимо изменить логику проведения документов, добавить новые экранные формы или внедрить уникальные алгоритмы расчетов, мы используем расширения конфигурации. Этот механизм позволяет кастомизировать систему, не снимая основную конфигурацию с поддержки.

Однако при работе с расширениями необходимо соблюдать жесткие правила безопасности, чтобы не потерять данные и не нарушить стабильность системы:

Проблема долговечности данных: Платформа позволяет создавать новые реквизиты и справочники непосредственно внутри расширения. Но помните: если расширение будет удалено, отключено или повреждено в процессе неквалифицированного обновления, все данные, накопленные в этих объектах расширения, будут безвозвратно удалены из СУБД!
Гибридный подход: Для предотвращения потери данных опытные разработчики используют гибридную схему. Новые реквизиты и таблицы создаются в основной конфигурации (для этого объект снимается с поддержки с правилом "редактируется с сохранением поддержки"), а вся бизнес-логика работы с ними выносится в расширение.

Разберем правильный выбор аннотаций в коде расширений:

Избегайте злоупотребления аннотацией &Вместо (&Instead): Данная аннотация полностью переопределяет оригинальный метод. Если вендор (фирма 1С) в очередном обновлении исправит баг или изменит логику в оригинальной процедуре, ваша система продолжит выполнять старый код из расширения, что приведет к скрытым ошибкам.
Используйте аннотации &Перед (&Before) и &После (&After): Они позволяют встроить пользовательский код до или после выполнения стандартной процедуры, сохраняя при этом актуальность типовых алгоритмов.

Ниже рассмотрим пример правильного расширения метода проведения документа с использованием безопасной аннотации:


&После("ОбработкаПроведения")
Процедура ИмяПрефикса_ОбработкаПроведенияПосле(Отказ, РежимПроведения)
    
    // Проверим, не отказалась ли система от проведения на стандартном этапе
    Если Отказ Тогда
        Возврат;
    КонецЕсли;
    
    // Выполняем нашу уникальную логику, например, запись в собственный регистр
    ИмяПрефикса_ПроведениеСервер.ЗаписатьДополнительныеДвижения(ЭтотОбъект);
    
КонецПроцедуры

Этап 4. Правила изменения типового кода (когда изменения неизбежны)

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

Переходим в меню Конфигурация — Поддержка — Настройка поддержки.
Включаем возможность изменения. При этом для объектов, которые мы планируем дорабатывать, устанавливаем правило "Редактируется с сохранением поддержки". Полностью снимать конфигурацию с поддержки (правило "Объект снят с поддержки") категорически запрещено.
Принцип изоляции кода: Никогда не пишите длинные алгоритмы внутри типовых модулей. Создайте свой общий модуль (например, с префиксом вашей компании _НашаКомпания_ОбщийМодуль) и разместите весь код там. В типовом модуле оставьте только вызов вашей процедуры.
Тегирование изменений: Обязательно обрамляйте любые изменения стандартного кода комментариями установленного образца. Это позволит быстро находить доработки при сравнении и объединении баз.

Разберем пример правильного внедрения в типовой код общего модуля:


// +++ [ИвановИИ] [25.10.2023] [Задача_№154]
// Интеграция с корпоративным порталом: отправка уведомления при изменении статуса
_НашаКомпания_ОбщийМодуль.ОтправитьУведомлениеОбИзмененииСтатуса(ЭтотОбъект);
// --- [ИвановИИ]

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


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Программная корректировка текста запроса динамического списка
    ТекстЗапроса = Список.ТекстЗапроса;
    ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "ВЫБРАТЬ", "ВЫБРАТЬ ИмяПрефикса_ДополнительноеПоле КАК ДополнительноеПоле, ");
    Список.ТекстЗапроса = ТекстЗапроса;
    
КонецПроцедуры

Как происходит обновление измененной конфигурации?

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

При обновлении через файл .cf или .cfu конфигуратор автоматически определит, какие объекты были изменены вами и поставщиком одновременно.
Откроется окно Сравнения и объединения конфигураций. Посмотрим на его настройки: нам необходимо использовать фильтры для отображения только дважды измененных объектов (измененных и вами, и поставщиком в новом релизе).
Для каждого такого объекта мы настраиваем индивидуальный режим объединения. Наша задача — аккуратно перенести новые функции от поставщика, не затерев при этом свои программные вставки, отмеченные комментариями.

Именно благодаря строгому соблюдению правил тегирования и изоляции кода (вынесению логики в отдельные модули) процесс сравнения и ручного объединения будет проходить быстро и безболезненно.