При работе с конфигурациями 1С, разработанными на основе Библиотеки стандартных подсистем (БСП), разработчики часто сталкиваются с проблемой при обновлении: многие типовые объекты, которые, казалось бы, не подвергались изменениям, система 1С помечает как модифицированные. Это явление мы называем «фантомными» изменениями. Такая ситуация приводит к ошибкам при обновлении и может стать серьезным препятствием для внедрения новых версий БСП. Давайте подробно разберем, почему возникают эти фантомные изменения и как эффективно с ними бороться, обеспечивая гладкое и безопасное обновление вашей конфигурации.
Мы выясним, как правильно анализировать конфликты при сравнении и объединении, какие подходы использовать для объектов, которые действительно не менялись, и как организовать работу с доработками, чтобы минимизировать сложности при будущих обновлениях. Особое внимание уделим современному и наиболее рекомендуемому методу — использованию расширений.
Прежде чем перейти к решению, давайте проанализируем, почему платформа 1С может считать неизмененные объекты БСП модифицированными. Это важно для понимания логики процесса и выбора правильной стратегии.
«Фантомные» изменения возникают из-за особенностей внутреннего механизма сравнения конфигураций 1С. Даже если вы не редактировали вручную код общего модуля, изменения могут быть вызваны следующими факторами:
ИдентификаторКонфигурации, ПредставлениеКонфигурации, СинонимКонфигурации, Версия, могут «ехать» и вызывать ложные изменения в связанных объектах.Понимание этих причин поможет нам правильно оценить статус объекта в окне сравнения и объединения.
Прежде чем приступить к непосредственному обновлению, мы должны выполнить несколько подготовительных шагов, чтобы обезопасить себя от потери данных и иметь возможность вернуться к рабочему состоянию системы:
.dt, так и копия базы средствами СУБД (для клиент-серверного варианта). Мы должны быть уверены, что в случае неудачного обновления мы сможем легко восстановить систему.После выполнения этих шагов мы можем переходить к процессу обновления.
Давайте подробно рассмотрим каждый шаг процесса обновления, фокусируясь на правильной обработке «фантомных» изменений.
Мы открываем вашу конфигурацию в режиме "Конфигуратор". Затем переходим в меню "Конфигурация" -> "Поддержка" -> "Настройка поддержки". В открывшемся окне нажимаем кнопку "Сравнить, объединить с конфигурацией из файла". В появившемся диалоге выбираем файл новой версии БСП, на которую мы хотим обновиться (обычно это файл с расширением .cf или .cfu, содержащий обновление БСП).
После выбора файла и запуска сравнения перед нами появится окно "Сравнение и объединение конфигураций". Это ключевой инструмент, который мы будем использовать. Обратите внимание на следующие моменты:
Этот шаг является центральным в решении нашей проблемы. Мы сталкиваемся с ситуацией, когда типовые объекты БСП (например, общие модули, подсистемы, роли), которые вы уверены, что не меняли, помечены как "Измененные".
Для таких объектов мы должны выбрать действие "Взять из файла поставщика". Это означает, что мы полностью перезапишем этот объект версией из файла обновления БСП. Мы уверены в этом действии, потому что знаем, что сами его не модифицировали, и любое изменение является "фантомным" или внутренним изменением в БСП, которое мы должны принять.
Примеры объектов, для которых часто встречаются "фантомные" изменения и которые можно смело брать из файла поставщика (если вы их не трогали):
ОбщиеНастройкиКлиентСервер, СтандартныеПодсистемыКлиентСервер, РаботаСКриптовойКонсолью.Важный момент: Мы должны быть абсолютно уверены, что объект действительно не менялся нами или другими разработчиками. Как это проверить, мы рассмотрим далее.
Если же вы обнаруживаете, что какой-то типовой объект БСП был действительно изменен в вашей конфигурации (например, вы добавили реквизит в стандартный справочник или изменили код в типовом общем модуле), то подход "Взять из файла поставщика" здесь неприменим, так как он сотрет все ваши доработки.
В этой ситуации у нас есть два основных пути:
Это более трудоемкий и рискованный путь, который мы применяем, если доработок мало и они простые, или если нет возможности использовать расширения. Мы выбираем действие "Объединить" для такого объекта. После этого нам придется вручную сравнить код или свойства объекта из вашей конфигурации с версией из файла поставщика. В случае с общими модулями это означает открытие двух версий модуля (вашей и из обновления) и построчное слияние изменений. Мы переносим свои доработки в новый код поставщика, стараясь сохранить всю типовую логику. Этот процесс требует высокой внимательности и понимания кода, так как легко допустить ошибку и нарушить работоспособность типового функционала.
Это самый правильный и современный подход к доработкам в 1С. Он позволяет нам сохранить типовую конфигурацию на полной поддержке без изменений, а все наши доработки вынести в отдельные расширения. При обновлении основной конфигурации, расширения не затрагиваются, что значительно упрощает процесс.
Давайте разберем последовательность работы с расширениями:
// Пример подписки на событие типового модуля
// В расширении создаем подписку на событие "ПриСозданииНаСервере" для типовой формы
Процедура ПриСозданииНаСервере_Расширение(Форма, Отказ, СтандартнаяОбработка) Экспорт
// Наша доработка
Форма.Элементы.МойНовыйРеквизит.Видимость = Истина;
КонецПроцедуры
Использование расширений значительно упрощает процесс обновления, делает конфигурацию более гибкой и устойчивой к изменениям БСП. Это стратегически верное решение для долгосрочной поддержки сложных конфигураций.
Возникает логичный вопрос: как мы можем быть абсолютно уверены, что объект не менялся нами, а его изменение является "фантомным"?
Обычно, если объект помечен как "Изменен", но относится к типовым механизмам БСП (например, ОбщиеНастройкиКлиентСервер, Подсистемы, роли без ваших доработок), и вы не помните, чтобы вы его трогали, то чаще всего это "фантомное" изменение, которое можно безопасно перезаписать из файла поставщика.
После того как мы приняли все решения по объединению и определили действия для каждого измененного объекта (либо "Взять из файла поставщика", либо "Объединить", либо перенесли в расширение и приняли из файла поставщика), мы нажимаем кнопку "Выполнить" в окне "Сравнение и объединение конфигураций".
Платформа начнет процесс объединения. В зависимости от количества изменений и мощности вашего оборудования, это может занять некоторое время. После завершения объединения, система предложит обновить конфигурацию базы данных. Мы обязательно соглашаемся с этим. Во время обновления конфигурации базы данных может потребоваться реструктуризация таблиц, что также может занять время.
После успешного обновления конфигурации базы данных мы можем запустить систему в режиме "Предприятие" для проведения тестов. Обязательно проверим работоспособность основных типовых механизмов БСП, а также функционал, связанный с нашими доработками (если они были перенесены в расширения или объединены вручную). Мы должны убедиться, что все работает стабильно и без ошибок.
Для того чтобы минимизировать проблемы с обновлениями в будущем, мы рекомендуем придерживаться следующих практик:
Применяя эти подходы, мы сможем эффективно справляться с проблемой «фантомных» изменений при обновлении конфигураций на основе БСП, обеспечивая стабильность и актуальность вашей информационной системы 1С.