Доработка и обновление конфигурации 1С без потери поддержки

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

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

Подготовка базы перед изменением конфигурации

Любая работа с конфигурацией начинается с точки возврата. Без неё откатить неудачное обновление структуры базы нельзя.

1. Попросите пользователей выйти из программы. Монопольный доступ нужен на этапе обновления структуры базы данных и выгрузки, а не для открытия Конфигуратора.
2. Запустите Конфигуратор и выполните Администрирование → Выгрузить информационную базу.... Получите файл .dt — это полная копия данных и конфигурации.
3. Дополнительно сохраните саму конфигурацию: Конфигурация → Сохранить конфигурацию в файл... (файл .cf). Он пригодится для сравнения «до» и «после».
4. Запишите номер платформы и релиз конфигурации: Справка → О программе.
5. Разверните копию: создайте новую пустую базу в окне запуска и загрузите в неё .dt через Администрирование → Загрузить информационную базу....

💡 Для клиент-серверной базы на MS SQL или PostgreSQL выгрузку .dt дополняйте бэкапом средствами СУБД. Он быстрее восстанавливается на больших объёмах.

Если базу дорабатывает несколько человек, подключите хранилище конфигурации (Конфигурация → Хранилище конфигурации). Оно хранит версии объектов и не даёт двум разработчикам одновременно править один модуль.

Какой способ изменения выбрать

Прежде чем открывать Конфигуратор, решите, где будет жить доработка. От этого зависит, сколько стоит каждое следующее обновление.

Свои доработки через расширения и Конфигуратор

Расширение конфигурации

Расширения появились в платформе 8.3.6 и с тех пор стали основным способом дорабатывать типовые решения.

1. В Конфигураторе откройте Конфигурация → Расширения конфигурации.
2. Нажмите «Добавить» и задайте имя и префикс. Префикс (например, мр_) потом попадает в имена новых объектов и сразу показывает, что это не типовой код.
3. Откройте конфигурацию расширения и в дереве основной конфигурации через контекстное меню объекта выберите «Добавить в расширение».
4. В заимствованном объекте добавьте реквизит, форму или процедуру. Для изменения типового метода используйте аннотации &Перед, &После, &Вместо.
5. Сохраните расширение и обновите конфигурацию базы данных для него.

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

&После("ОбработкаПроверкиЗаполнения")
Процедура мр_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
	Если НЕ ЗначениеЗаполнено(Комментарий) Тогда
		ОбщегоНазначения.СообщитьПользователю("Заполните комментарий", ЭтотОбъект, "Комментарий", , Отказ);
	КонецЕсли;
КонецПроцедуры

В БП 3.0 готовое расширение можно подключить и без Конфигуратора: Администрирование → Печатные формы, отчеты и обработки → Расширения.

💡 У расширения есть свойство «Безопасный режим». Если оно включено, часть операций (работа с файлами, COM, внешние компоненты) недоступна. Отключайте его только для проверенного кода.

Правка конфигурации с сохранением поддержки

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

1. Конфигурация → Поддержка → Настройка поддержки...
2. Если стоит «Изменения не разрешены», нажмите «Включить возможность изменения». Платформа предложит правило для объектов поставщика — выберите «Объект поставщика редактируется с сохранением поддержки».
3. Правьте только нужные объекты. Каждое изменение помечайте комментарием с датой и автором, например // мр 2026-10 начало и // мр 2026-10 конец.
4. Не удаляйте типовые объекты и реквизиты: отключите их использование кодом. Удалённый объект при следующем обновлении вернётся и даст конфликт.

Обновление типовой конфигурации

Порядок зависит от того, менялась ли конфигурация.

Конфигурация без изменений

Если типовая на полной поддержке (а доработки — только в расширениях), обновление проходит штатно. В БП 3.0, ЗУП 3.1 и УТ 11 можно обновить программу из пользовательского режима через Администрирование → Интернет-поддержка и сервисы, раздел обновления версии. Программа сама скачает нужные релизы, сделает копию по настройке и применит обновление.

Изменённая конфигурация

Здесь работают в Конфигураторе файлом обновления .cfu (или полным дистрибутивом .cf).

1. Убедитесь, что текущий релиз указан в списке тех, с которых возможен переход. Перепрыгнуть через несколько релизов нельзя: файл обновления содержит список допустимых исходных версий, и обновляться приходится цепочкой.
2. Конфигурация → Поддержка → Обновить конфигурацию..., укажите файл.
3. Платформа построит сравнение трёх конфигураций: старой поставщика, новой поставщика и вашей основной.
4. Разберите объекты, изменённые и у вас, и у поставщика (об этом — в следующем разделе).
5. Нажмите «Выполнить», затем Конфигурация → Обновить конфигурацию базы данных (F7). На этом шаге нужен монопольный доступ.
6. Запустите базу в режиме 1С:Предприятие под администратором. На первом запуске выполняются обработчики обновления: они переносят данные под новую структуру. Не прерывайте их.

После обновления расширения тоже нужно проверить: если поставщик переименовал или удалил заимствованный объект, расширение перестанет применяться, и платформа сообщит об этом при запуске.

Сравнение и объединение конфигураций

Сравнение — главный инструмент, который отличает аккуратное обновление от поломки. Оно открывается при обновлении изменённой конфигурации, а вручную — через Конфигурация → Сравнить, объединить с конфигурацией из файла....

В окне сравнения у каждого объекта есть статус и флажок объединения. Объекты делятся на группы:

• 🟢 изменены только у поставщика — смело берите из новой конфигурации;
• 🟡 изменены только у вас — остаются как есть, поставщик их не трогал;
• 🔴 изменены и у вас, и у поставщика — требуют ручного разбора.

Для объектов третьей группы:

1. Откройте объект через контекстное меню и посмотрите отличия по модулям, формам и реквизитам.
2. Для модулей выберите режим объединения на уровне процедур. Где ваш код и код поставщика пересекаются, установите «Взять из файла» и затем верните свою вставку вручную, сверившись с сохранённым .cf.
3. Формы чаще всего проще взять у поставщика целиком, а свои элементы добавить заново или перенести в расширение.
4. После объединения выполните Конфигурация → Проверка конфигурации..., чтобы поймать синтаксические ошибки и ссылки на исчезнувшие объекты.

💡 Чем больше ваших изменений в типовых модулях, тем дольше этот разбор. Именно поэтому новые доработки разумно переносить в расширение: в следующий раз объектов «красной» группы станет меньше.

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

Проверка изменений и откат

Как тестировать

Изменения сначала проверяют на копии, развёрнутой на первом шаге. Минимальный набор:

1. Открыть изменённые формы и провести несколько документов, которых касалась доработка.
2. Перепровести документы за закрытый месяц на копии и сравнить оборотно-сальдовую ведомость до и после. Расхождений быть не должно, если доработка не меняла учёт.
3. Запустить регламентные операции, которые используются в базе (закрытие месяца, расчёт зарплаты).
4. Проверить обмены, если база отдаёт данные в другую программу или на сайт.
5. Выполнить Администрирование → Тестирование и исправление... в Конфигураторе в режиме «только тестирование», без исправления — чтобы увидеть, нет ли битых ссылок после изменения структуры.

Перенос в рабочую базу

Готовую конфигурацию с копии переносят файлом .cf через сравнение и объединение, а расширение — файлом .cfe. Загрузка .cfe и обновление конфигурации базы данных — это два отдельных шага.

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

Как откатить

Отсюда простое правило: выгрузка .dt делается непосредственно перед переносом в рабочую базу, а не накануне. Иначе при откате пропадут данные за целый день.

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

Частые ошибки при доработке 1С

• ❌ Правка рабочей базы напрямую. Ошибка в модуле проведения сразу останавливает работу всех пользователей.
• ❌ Динамическое обновление на работающей базе. Платформа позволяет применить часть изменений без отключения пользователей, но открытые сеансы продолжают работать со старой конфигурацией. Это даёт непредсказуемые ошибки до перезапуска.
• ❌ Снятие с поддержки «чтобы не мешало». Через полгода база отстаёт на несколько релизов, а обязательные изменения законодательства не приходят.
• ❌ Изменения без пометок. Через год никто не помнит, что из модуля типовое, а что добавлено, и при сравнении доработка теряется.
• ❌ Удаление типовых объектов. Удалённый реквизит поставщик вернёт при обновлении, а ваши данные, которые на него ссылались, уже не восстановить.
• ❌ Пропуск обработчиков обновления. Если после F7 сразу пустить пользователей, они увидят окно обновления данных и будут ждать или закрывать его.