Как правильно вносить изменения в 1С

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

Любая доработка начинается не с конфигуратора, а с резервной копии и понимания задачи. Ошибка в коде, внесённая напрямую в рабочую базу, может остановить проведение документов, исказить отчёты или повредить данные. Поэтому безопасный процесс всегда выглядит одинаково: копия базы, разработка и проверка на копии, перенос в рабочую базу в нерабочее время, контроль результата.

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

Выберите способ: расширение или доработка конфигурации

Расширение конфигурации — это надстройка, которая хранится отдельно от основной конфигурации и подключается к ней. Расширение позволяет добавлять новые объекты (справочники, документы, отчёты, обработки, роли), изменять формы, дополнять модули через аннотации &ИзменениеИКонтроль, &Вместо, &Перед, &После. Типовая конфигурация при этом остаётся на полной поддержке, и обновления устанавливаются штатно.

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

Практическое правило: сначала проверьте, не закрывается ли задача внешней обработкой или расширением. К прямой доработке переходите только с письменным обоснованием, почему другие способы не подходят, — это сэкономит десятки часов при будущих обновлениях.

Подготовьте базу: копия, доступы и режим работы

Перед любыми изменениями сделайте резервную копию. Для файловой базы достаточно выгрузки через конфигуратор («Администрирование» → «Выгрузить информационную базу») или копирования файла 1Cv8.1CD при отсутствии активных сеансов. Для клиент-серверной базы надёжнее средство СУБД: резервная копия через MS SQL Server Management Studio, pgAdmin или pg_dump для PostgreSQL.

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

1. 1
   Сделайте резервную копию базы штатным средством (выгрузка .dt или бэкап СУБД).
2. 2
   Проверьте, что копия восстанавливается: разверните её в отдельном каталоге или на тестовом сервере.
3. 3
   Создайте тестовую базу из копии — все доработки выполняйте только на ней.
4. 4
   Проверьте права учётной записи: администрирование и изменение конфигурации.
5. 5
   Запланируйте окно для переноса в рабочую базу — нерабочее время с блокировкой сеансов.

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

Внесите изменения через расширение конфигурации

Расширение создаётся в конфигураторе: меню «Конфигурация» → «Расширения конфигурации» → «Создать». Задайте имя, префикс объектов и назначение. Префикс нужен, чтобы новые объекты расширения не конфликтовали по именам с типовыми и с объектами других расширений.

Чтобы изменить типовой объект, добавьте его в расширение через контекстное меню «Добавить» с контролем: заимствованный объект помечается как контролируемый, и платформа при подключении расширения проверит, не изменился ли он в основной конфигурации. Для изменения кода модулей используйте аннотации:

• &Перед и &После — выполнить свой код до или после типовой процедуры, не меняя её текст;
• &Вместо — полностью заменить типовую процедуру своей; используйте только когда без этого нельзя, так как при обновлении типовой процедуры вы не получите её изменения;
• &ИзменениеИКонтроль — вставить типовой текст процедуры в расширение и изменить его точечно; при обновлении платформа покажет расхождения с новой типовой версией.

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

Для добавления реквизита в типовой объект используйте команду «Добавить» → «Реквизиты» в заимствованном объекте или механизм дополнительных реквизитов и сведений в пользовательском режиме, если реквизит чисто информационный. После сохранения расширения обновите конфигурацию базы данных (F7) и проверьте работу в пользовательском режиме.

Внесите изменения напрямую в конфигурацию

Если расширение задачу не закрывает, откройте конфигуратор и включите возможность изменения: «Конфигурация» → «Поддержка» → «Настройка поддержки» → «Включить возможность изменения». Для каждого изменяемого объекта задайте правило поддержки осознанно: «Объект поставщика редактируется с сохранением поддержки» позволит получать обновления с ручным сопоставлением, а «Изменения не рекомендуются» оставит объект под полным контролем поставщика.

Все изменения документируйте прямо в коде: помечайте вставки комментариями с маркером доработки, например // {Доработка: причина, дата} и парным маркером окончания блока. Это кардинально упрощает сопоставление при обновлении — по маркеру легко найти все вмешательства в типовой код.

После правок выполните «Конфигурация» → «Проверка конфигурации» с включённой проверкой логической целостности и ссылок. Это выявит обращения к удалённым объектам, ошибки в модулях и проблемы прав доступа до того, как с ними столкнутся пользователи.

Протестируйте изменения на копии базы

Тестирование начинается с воспроизведения сценария, ради которого делалась доработка: создайте документ, проведите его, сформируйте отчёт, проверьте печатную форму. Затем проверьте смежные сценарии — типовые операции, которые могли задеть изменения: обмены данными, регламентные задания, права пользователей с ограниченными ролями.

Отдельно проверьте поведение под пользователем без административных прав. Частая ситуация: у разработчика всё работает, а у менеджера новый реквизит не виден или отчёт падает с ошибкой доступа, потому что забыли настроить роли и права на новые объекты.

Перенесите изменения в рабочую базу и обновляйте доработанную конфигурацию

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

После переноса проведите экспресс-проверку в рабочей базе: войдите под типовым пользователем, выполните ключевую операцию, посмотрите журнал регистрации. Только после этого снимайте блокировку сеансов и сообщайте пользователям о готовности.

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

Частые вопросы