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

← На главную

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

1. Анализ типового функционала перед началом разработки

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

Перед тем как приступать к доработке, выполним следующие шаги:

Проверим наличие нужного функционала в пользовательском интерфейсе через функциональные опции и константы.
Изучим состав отчетов и возможности схемы компоновки данных (СКД) — большинство запросов на аналитику решается сохранением нового варианта типового отчета.
Проверим возможность решения задачи через механизм дополнительных реквизитов и сведений без снятия конфигурации с поддержки.

2. Использование точек интеграции Библиотеки стандартных подсистем (БСП)

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

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

Дополнительные реквизиты и сведения: Если в справочник или документ требуется добавить новые реквизиты, сначала рассмотрим встроенный механизм БСП. Дополнительные реквизиты хранятся в штатной табличной части объектов, а дополнительные сведения — в отдельном регистре сведений, что позволяет расширять состав данных без редактирования метаданных в конфигураторе.

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

3. Разработка функционала с помощью расширений конфигурации

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

При переопределении серверных и клиентских методов в расширении важно правильно выбирать аннотации:

Аннотации &Перед и &После: Рекомендуются к использованию в первую очередь, так как они выполняют дополнительный код до или после вызова типового метода, не ломая основную логику и не конфликтуя с другими расширениями.
Аннотация &ИзменениеИКонтроля: Позволяет точечно заменить фрагмент кода типовой процедуры с помощью директив #Вставка и #Удаление. Если при обновлении основной конфигурации разработчики 1С изменят этот метод, платформа выдаст предупреждение о несовместимости, что защитит от скрытых ошибок в логике.
Аннотация &Вместо: Полностью замещает типовой метод. Ее использование следует свести к минимуму, поскольку при обновлении типовой код метода не выполнится, а разработчик может пропустить критические изменения в алгоритмах поставщика.

Рассмотрим пример правильного добавления логики перед проведением документа с помощью аннотации &Перед:


&Перед("ОбработкаПроведения")
Процедура Расш1_ОбработкаПроведения(Отказ, РежимПроведения)
    // Проверяем дополнительные условия перед типовым проведением
    Если Не Расш1_ПроверитьЗаполнениеПользовательскихДанных() Тогда
        Отказ = Истина;
        Возврат;
    КонецЕсли;
КонецПроцедуры

4. Правила внесения изменений в основную конфигурацию

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

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

5. Стандарты комментирования и контроля версий

При редактировании типовых процедур и функций в основной конфигурации весь добавленный или измененный код обязательно должен быть обрамлен стандартизированными комментариями. Это необходимо для корректного трехстороннего сравнения при обновлении конфигурации поставщика.

Рассмотрим типовой шаблон оформления доработок в коде:


// v8: Задача_145 ИнициалыДД.ММ.ГГГГ Начало
// Дополнительный расчет скидки для оптовых покупателей
Если ЭтоОптовыйПокупатель(ЭтотОбъект.Контрагент) Тогда
    РассчитатьСпециальнуюСкидку(ТабличнаяЧасть);
КонецЕсли;
// v8: Задача_145 Инициалы ДД.ММ.ГГГГ Конец

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


// v8: Задача_145 Инициалы ДД.ММ.ГГГГ Начало
// Типовой расчет заменен на специализированный алгоритм
// РассчитатьТиповуюСкидку();
РассчитатьПользовательскуюСкидку();
// v8: Задача_145 Инициалы ДД.ММ.ГГГГ Конец

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