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

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

Зачем нужна собственная поставка

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

Собственная поставка решает это:

Без своей поставкиСо своей поставкой
Отличия от типовой смешаны: ваши выпуски и локальные правкиКонфигурация поставщика = ваша последняя сборка
Обновление доработок — ручное объединениеОбновление файлом .cf или .cfu
Локальные изменения не видныЛюбое изменение после поставки видно при сравнении
Можно случайно перезаписать чужие правкиРежим поддержки защищает объекты от правки
Поставка конфигурации 1С: путь от типовой конфигурации через доработку к собственной сборке у заказчика
Поставка конфигурации 1С: путь от типовой конфигурации через доработку к собственной сборке у заказчика

Перед началом

  • Сделайте выгрузку информационной базы (.dt) и сохраните текущую конфигурацию в файл. Все дальнейшие шаги меняют настройки поддержки, откатывать их вручную неудобно.
  • Убедитесь, что конфигурация в режиме «на поддержке с возможностью изменения».
  • Если база подключена к хранилищу конфигурации, для изменения настроек поддержки понадобится захват корня конфигурации.
  • Решите, какую версию указать: номер версии конфигурации (свойство корня) пригодится, чтобы отличать ваши выпуски.

Шаг 1. Создаём файл поставки

  1. Откройте конфигурацию, в которую уже внесены доработки, и обновите конфигурацию базы данных.
  2. Меню «Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления конфигурации».
  3. Если имя и поставщик конфигурации не менялись, конфигуратор предупредит об этом — подтвердите.
  4. Укажите путь к файлу поставки .cf.
  5. Флажок «Создать файл обновления конфигурации» (.cfu) для первой постановки не нужен — снимите его.
  6. Нажмите «Выполнить».

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

Шаг 2. Обновляем конфигурацию поставщика своим файлом

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

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

Шаг 3. Ставим все объекты на поддержку

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

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

Как выпускать следующие версии

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

Такой цикл хорошо ложится на CI: сборка поставки из хранилища или Git и автоматическая проверка обновления на копии базы заказчика. Это я настраиваю в рамках DevOps для 1С.

Важный риск: обновление на релиз фирмы «1С»

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

Поэтому на проектах я держу двухуровневую схему:

  • в базе разработки поставщик — «1С», туда ставится новый типовой релиз и объединяется с доработками;
  • из базы разработки выпускается ваш .cf;
  • база заказчика обновляется только вашими сборками.

Так типовой релиз объединяется один раз, в контролируемой среде, а у заказчика обновление сводится к штатной процедуре. Сами обновления типовых конфигураций с доработками выполняю в рамках услуги обновление 1С.

Настройка поставки: что разрешить менять у заказчика

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

Практическое правило:

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

Чем строже правила, тем проще обновления. Каждый редактируемый объект — потенциальное ручное объединение при выпуске следующей версии.

Типичные ошибки

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

Итог

  • Файл поставки создаётся в «Поставка конфигурации → Создать файлы поставки и обновления».
  • Конфигурацию поставщика обновляют этим .cf через «Поддержка → Обновить конфигурацию».
  • В настройке поддержки ставят правило «не редактируется» для всех объектов, предварительно выбрав «Нет фильтра».
  • Следующие версии передаются как .cf или .cfu с увеличенным номером версии.
  • Типовые релизы объединяйте в базе разработки, а заказчику отдавайте готовую сборку.