Выпуск файла обновления конфигурации 1С: от сравнения до cfu

Обновление конфигурации 1С выпускают в Конфигураторе: ставите конфигурацию на поддержку, дорабатываете её, сохраняете новую версию и создаёте файлы поставки и обновления (cf и cfu). Заказчик ставит cfu поверх своей базы, не потеряв ваших и своих правок.

Ниже — весь путь выпуска: какие файлы нужны, как сверить версии, что делать с данными, как проверить релиз и что отдать пользователю. Речь о доработанной типовой или собственной конфигурации на 1С 8.3, которую вы сопровождаете для других баз.

Что нужно до начала: версии, копии и режим поддержки

Сначала определитесь, от чего отталкиваетесь. Обновление всегда строится между двумя состояниями конфигурации: «было» и «стало». Без чёткой точки «было» выпустить корректный cfu нельзя.

Что собрать заранее:

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

Проверьте режим поддержки. В Конфигураторе откройте Конфигурация → Поддержка → Настройка поддержки. Там видно, какие объекты на замке, какие можно изменять с сохранением поддержки, а какие сняты с неё совсем.

Работайте на копии. Выгрузите конфигурацию в файл (Конфигурация → Сохранить конфигурацию в файл) и сделайте выгрузку информационной базы в dt. Перед любыми изменениями в рабочей базе — резервная копия и согласование с регламентом.

Единая нумерация версий

Решите, как будете нумеровать выпуски. Удобная схема — четыре числа: 1.4.12.3. Первые два — крупный функционал, третье — релиз, четвёртое — сборка. Номер версии задаётся в свойствах конфигурации, поле «Версия». Обновление cfu привязано к номерам: он умеет переводить базу только с указанных версий.

Как найти отличия между версиями конфигурации

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

Сравнение и объединение

Для сравнения есть два режима в меню Конфигурация:

1. Сравнить, объединить с конфигурацией из файла — для случая, когда новая версия лежит у вас в виде cf.
2. Сравнить конфигурации основной и базы данных — когда нужно увидеть, что изменено, но ещё не применено к базе.

Откроется дерево объектов. У каждого свой статус: изменён в одной конфигурации, изменён в обеих, добавлен, удалён. Для каждой строки вы выбираете действие: взять из основной, взять из файла, объединить.

💡 Начинайте не с модулей, а с метаданных: реквизиты, табличные части, формы. Структуру данных проще довести до конца, а модули потом правятся под неё.

Что смотреть в первую очередь

• 🔴 Объекты, изменённые и у вас, и у вендора — конфликты.
• 🟡 Объекты, добавленные вендором — обычно берёте как есть.
• 🟢 Ваши новые объекты — переносятся без вопросов.
• ⚪ Удалённые вендором объекты — проверьте, не используются ли они в ваших доработках.

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

Формирование файлов поставки и обновления

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

Что вы получите на выходе:

Порядок действий

1. Убедитесь, что конфигурация на поддержке, а в свойствах стоит нужный номер версии.
2. В диалоге создания укажите, что нужен файл поставки (cf) и/или файл обновления (cfu).
3. Для обновления добавьте файл предыдущей поставки — с него будет считаться разница. Если нужно поддержать старт с нескольких версий, добавляйте каждую.
4. Задайте каталог, куда сложится результат, и имя шаблона.
5. Запустите создание и дождитесь сообщения об окончании. Проверьте размер файлов: cfu заметно меньше cf. Если он почти равен полной конфигурации, значит, база сравнения выбрана неверно.

Свой выпуск поверх вендорского

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

Данные при обновлении: структура, обработчики и конвертация

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

Что обычно требуется:

• 🔧 Обработчик обновления. Процедура, которая один раз выполняется при переходе на новую версию: заполняет новые реквизиты, переносит значения из старых полей, пересчитывает итоги. В типовых конфигурациях для этого есть подсистема обновления информационной базы; свои обработчики регистрируют в ней и привязывают к номеру версии.
• 🔧 Заполнение по умолчанию. Новый обязательный реквизит у существующих элементов получит пустое значение — продумайте, чем его заполнить.
• 🔧 Перенос между объектами. Если данные уходят из одного справочника в другой, нужно сначала создать новое хранилище, затем перенести, затем только в следующем релизе удалять старое.

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

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

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

Тестирование релиза на копии базы

Выпуск без проверки — главный источник жалоб. Минимум, который стоит сделать каждый раз.

Проверка конфигурации

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

Проверка установки

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

Для баз с тяжёлой историей сделайте второй прогон на копии, максимально близкой к реальному объёму. Время работы обработчиков на малой тестовой базе ничего не говорит о времени на живой.

Хорошая практика — чек-лист выпуска, который проходите перед каждой отправкой:

Передача обновления заказчику и документация

Технически файл готов, но выпуск не закончен, пока пользователь не знает, что ему делать.

Что приложить к cfu:

• 📄 Описание изменений — человеческим языком: что исправлено, что добавлено, что поменялось в работе. Без названий модулей и процедур.
• 📄 Инструкцию по установке — два-три шага и предупреждение о резервной копии.
• 📄 Требования — минимальная версия платформы, версия конфигурации, с которой можно обновляться.
• 📄 Что делать после — ручные настройки, если они нужны: включить функциональную опцию, запустить обработку, перепроверить права.

Способы доставки

Для сравнения номеров платформы пишите однозначно: «платформа версии 8.3.х и выше», а не «не старше». Так нет разночтений.

Храните архив всех выпусков: cf каждой версии, cfu для переходов, описание изменений. Без архива вы не соберёте обновление с давней версии на текущую, если заказчик вдруг пропустил три выпуска.

Когда обновление делать не нужно

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

Типичные ошибки при выпуске обновлений

Ниже — то, что реально ломает релизы. Шаги из разделов выше не повторяются.

• ❌ Обновление строили от неверной базы. Признак: cfu слишком большой или установка падает с сообщением о несоответствии версий. Пересоздайте файл, указав правильный предыдущий cf.
• ❌ Забыли увеличить номер версии. База «обновилась» до той же версии, обработчики не запустились. Исправление — повысить номер и выпустить заново.
• ❌ Объект снят с поддержки «ради удобства». Через пару релизов такие объекты перестают получать правки вендора, а объём ручного объединения растёт.
• ❌ Обработчик не рассчитан на повторный запуск. Если обновление прервалось и запускается снова, обработчик дублирует данные. Делайте его идемпотентным: проверяйте, выполнено ли уже действие.
• ❌ Не проверили на копии боевой базы. На чистой тестовой базе всё работает, а на живой — другие данные, другие права, другие настройки.
• ❌ Не оставили путь отката. До установки у пользователя должна быть резервная копия, и он должен о ней знать.

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