Обновление нетиповых (доработанных) конфигураций — одна из самых частых и ответственных задач программиста 1С. Обычно процесс отлажен: запускаем обновление, фильтруем "дважды измененные" объекты, выполняем объединение модулей в разрезе методов и переносим код. Однако иногда стандартный механизм дает сбой: вы обнаруживаете, что часть типовых объектов (макеты, новые реквизиты) не подтянулась из обновления, хотя вы их не меняли, или ваши доработки объединились некорректно.
В этой статье мы подробно разберем, почему возникают такие ситуации, как правильно "дообновить" конфигурацию и какие настройки поддержки гарантируют корректный перенос изменений поставщика. Мы проанализируем как стандартные методы, так и нюансы работы с кэшем метаданных, полными файлами поставки и статический анализ кода проектов для выявления скрытых конфликтов.
Многие разработчики при обновлении привыкли полагаться на фильтр "Показывать только дважды измененные свойства". Логика понятна: мы хотим видеть только те места, где есть конфликт между нашими доработками и обновлением поставщика. Однако этот подход таит в себе опасность.
Механизм обновления работает в два этапа:
Если вы используете фильтр "только дважды измененные", вы говорите платформе: "Скрой от меня объекты, которые изменил поставщик, но не менял я". В идеальном мире платформа сама перенесет их автоматически. Но на практике случаются сбои:
1С:Предприятие иногда возникают ошибки в механизме сравнения, когда изменения не детектируются.Если вы заметили, что после нажатия кнопки "Выполнить" в окне обновления часть объектов осталась старой (например, не появились новые макеты в справочниках), необходимо выполнить принудительное сравнение с уже обновленной конфигурацией поставщика.
Давайте рассмотрим правильный алгоритм действий, если стандартное обновление прошло не идеально:
Это действие инициирует сравнение вашей текущей Основной конфигурации с той версией Конфигурации поставщика, которая уже загружена в базу. Это самый надежный способ увидеть реальные расхождения.
В окне сравнения и объединения важно правильно настроить фильтры. Не используйте "Только дважды измененные". Вместо этого:
Вы увидие объекты, которые отличаются. Если это типовой объект (например, Справочник.Номенклатура), и вы видите, что в конфигурации поставщика есть новый макет или реквизит, а в основной конфигурации его нет — смело ставьте галочку напротив этого объекта. При этом убедитесь, что ваши доработки в этом объекте (если они были) не затираются.
Часто причиной проблем становится "зоопарк" в правилах поддержки объектов. Например, корневой объект конфигурации может стоять на замке, а подчиненные объекты — быть редактируемыми, или наоборот. Это вызывает коллизии при обновлении.
Разберем рекомендации по настройке правил для минимизации проблем:
Правило 1: Единообразие прав редактирования.
Старайтесь придерживаться следующей логики: у всех объектов конфигурации (включая подчиненные реквизиты, формы, макеты) должно быть установлено правило "Объект поставщика редактируется с сохранением поддержки".
Ситуация, когда родитель (например, Справочник) имеет правило "Объект поставщика не редактируется", а его реквизит — "Редактируется", может привести к тому, что обновление не сможет корректно примениться к родительскому объекту.
Правило 2: Включение новых объектов в поддержку.
Когда поставщик добавляет новые объекты (новые справочники, документы), при обновлении платформа спрашивает правила для них. Всегда устанавливайте "Объект поставщика редактируется с сохранением поддержки". Даже если вы не планируете их менять сейчас, это избавит вас от проблем с блокировкой изменений в будущем.
Если проблемы с частичным обновлением повторяются из раза в раз, или если вы видите странные ошибки ("фантомные" изменения), возможно, структура вашей конфигурации рассинхронизировалась с конфигурацией поставщика на глубоком уровне.
В этом случае обновление через файл .cfu (файл обновления) может работать некорректно, так как он содержит только разницу между версиями. Нам нужно восстановить целостность структуры.
Рассмотрим алгоритм "лечебного" обновления:
setup) той версии типовой конфигурации, на которую вы хотите обновиться (или которая у вас сейчас должна быть)..cf)..cf файл.При таком подходе платформа принудительно сопоставит все идентификаторы метаданных и восстановит корректную структуру конфигурации поставщика. Это часто решает проблемы с объектами, которые "не хотели" обновляться. Чтобы зафиксировать итог работ и предоставить заказчику отчет, можно использовать анализ изменений конфигурации с выгрузкой в Excel.
Давайте разберем специфические проблемы, с которыми можно столкнуться при дообновлении.
Вы можете заметить, что некоторые подсистемы (например, ВнеоборотныеАктивы) всегда помечаются как измененные, даже если вы их не трогали. Это происходит из-за различия в порядке объектов в составе подсистемы.
Решение: В окне сравнения-объединения найдите проблемную подсистему, кликните правой кнопкой мыши и выберите "Установить режим объединения для всех подчиненных" -> "Взять из конфигурации поставщика". Это синхронизирует порядок объектов с поставщиком.
Иногда при сравнении показывается, что изменены макеты (особенно HTML или Active Document) или справочная информация. При детальном просмотре различий не видно.
Причина: Это часто связано с техническими различиями в формате сохранения файлов разными версиями платформы (разные переводы строк, служебные символы).
Решение: Если вы точно знаете, что не правили типовые макеты и справку, смело замещайте их объектами поставщика. Для этого в настройках фильтра включите отображение всех изменений и проставьте галочки на обновление этих "фантомных" объектов.
Чтобы избежать подобных проблем в будущем, давайте сформируем чек-лист правильного обновления сильно доработанной конфигурации:
.cfu. Ставьте их последовательно.Используя эти методы, вы сможете корректно завершить обновление, даже если автоматический процесс прошел с ошибками.