При работе с типовыми конфигурациями, такими как УПП, часто возникает необходимость переноса доработок из одной базы в другую. Многих разработчиков интересует вопрос: можно ли создать отдельный файл обновления (CFU), содержащий только изменения, чтобы не затрагивать конфигурацию поставщика? Давайте разберем этот процесс подробно и проанализируем, какие инструменты предлагает платформа 1С для решения этой задачи.
Прежде чем приступать к разработке, важно четко различать понятия CF и CFU. CF-файл представляет собой полный дамп конфигурации. Когда мы выполняем объединение через CF, платформа сравнивает структуру метаданных всей базы с файлом, что требует от разработчика ручного управления каждым измененным объектом.
Файл CFU — это файл обновления, содержащий только «дельту» (разницу) между двумя версиями конфигурации. Его создание возможно только в том случае, если база, в которой ведутся разработки, официально является «поставкой». Это означает, что вы должны выступать в роли вендора собственной конфигурации, используя инструменты создания дистрибутива, предоставляемые платформой 1С.
Многие разработчики ошибочно пытаются создать поставку, используя существующую CF-конфигурацию. Однако платформа при попытке создания поставки требует соблюдения строгой структуры метаданных поставщика. Если вы просто берете типовую конфигурацию с внесенными изменениями, платформа не признает её «поставкой», так как нарушена целостность исходных данных поставщика.
Создание полноценной системы поставки оправдано только в случае разработки тиражных решений. Если ваша задача — разовая доработка одной базы, использование этого механизма является избыточным и требует неоправданных затрат времени.
Для большинства задач по доработке типовых конфигураций 1С, включая УПП, лучшим решением остается классическое сравнение и объединение файлов. Рассмотрим этот процесс по шагам:
CF.CF-файл.Если задача заключается в том, чтобы не изменять основную конфигурацию и оставить её максимально «типовой», рассмотрите следующие современные методы:
Это наиболее предпочтительный современный способ. Вместо того чтобы править метаданные основной конфигурации, вы создаете Расширение. В расширении можно:
Преимущество расширений заключается в том, что они существуют независимо от основной конфигурации. При обновлении типовой конфигурации 1С ваши доработки не будут конфликтовать с основной логикой, так как они находятся в отдельном слое метаданных.
Для командной разработки использование Хранилища является стандартом. Оно позволяет отслеживать историю изменений конкретных объектов. Если вам нужно перенести изменения в другую базу, вы можете получить объекты из хранилища в локальный репозиторий и объединить их с целевой базой. Это минимизирует риски ошибок, связанных с ручным выбором объектов при объединении.
Если перед вами стоит разовая задача по переносу изменений, не усложняйте процесс созданием собственной поставки. Используйте классический метод сравнения и объединения, аккуратно выбирая изменения в окне объединения. Это проверенный путь, который гарантирует контроль над каждым объектом. Если же вы планируете долгосрочное сопровождение доработок, рекомендуем перенести текущие изменения в Расширения, чтобы в будущем облегчить обновление конфигурации 1С до актуальных релизов.