← На главную

Часто при поддержке нетиповых конфигураций, например, 1С:Розница, мы сталкиваемся с ситуацией, когда предыдущий разработчик изменил имя типового общего модуля (добавив суффикс _old), а вместо него создал свой собственный с таким же именем (например, ОбменДаннымиXDTOСервер). Разберем ситуацию: при попытке обновить базу файлом .cfu изменения поставщика "цепляются" к старому модулю с суффиксом _old, игнорируя ваш новый кастомный модуль. Выясним причину такого поведения платформы и рассмотрим рабочие способы решения данной проблемы.

Почему обновление применяется к переименованному модулю?

Проанализируем механику работы обновлений платформы 1С. При использовании файла обновления (формат .cfu) платформа жестко сопоставляет объекты метаданных исключительно по их внутренним идентификаторам (UUID), а не по именам. Внутренний идентификатор присваивается объекту при его создании и никогда не меняется, даже если вы переименуете объект в конфигураторе. Именно поэтому официальные стандарты разработки категорически запрещают переименовывать типовые объекты.

Поскольку ваш кастомный модуль был создан с нуля, он имеет новый UUID. А переименованный модуль _old сохранил оригинальный идентификатор поставщика. Поэтому обновление корректно находит старый объект по UUID и пытается записать новый код поставщика именно в него.

Вариант 1: Возврат оригинальных имен и перенос доработок

Рассмотрим наиболее правильный способ, который вернет конфигурацию к стандартам разработки 1С.

1. Верните типовому переименованному модулю (который с _old) его изначальное имя — ОбменДаннымиXDTOСервер.
2. Вашему нетиповому модулю задайте другое имя, например, ОбменДаннымиXDTOСервер_Нетиповой.
3. Выполните стандартное обновление базы из файла .cfu. Важно: после завершения обновления конфигурации базы данных не запускайте базу в режиме 1С:Предприятие.
4. Откройте обновленный типовой модуль и перенесите в него все необходимые доработки из вашего модуля ОбменДаннымиXDTOСервер_Нетиповой. Настоятельно рекомендуем выносить эти изменения в расширение конфигурации, чтобы в будущем избежать проблем с обновлениями.
5. Только после аккуратного переноса кода и сохранения конфигурации запускайте базу в пользовательском режиме для выполнения отложенных обработчиков обновления.

Вариант 2: Использование полного файла .cf вместо .cfu

Разберем ситуацию, когда мы хотим принудительно указать платформе, какие объекты следует сопоставлять друг с другом. Файл .cfu не позволяет менять стратегию сравнения, поэтому нам потребуется полный файл конфигурации поставщика (.cf) требуемого релиза.

1. В конфигураторе выберите пункт меню для сравнения и объединения с конфигурацией из файла и укажите полный .cf файл.
2. В открывшемся окне сравнения перейдите в настройки сопоставления объектов.
3. Измените стратегию сопоставления. Выберите сопоставление «По имени» или вручную укажите соответствие между новым модулем из файла поставщика и вашим текущим рабочим модулем.
4. Выполните объединение. После этого конфигурацию можно будет снова вернуть на стандартную поддержку.

Вариант 3: Подмена внутренних идентификаторов через файлы (XML)

Посмотрим на более глубокий, но эффективный способ решения задачи. Если необходимо сохранить текущую структуру и "починить" связь с конфигурацией поставщика без ручного переноса кода, мы можем поменять UUID объектов местами в исходных файлах конфигурации.

1. Выгрузите текущую конфигурацию базы данных в файлы (формат XML) через команду конфигуратора «Выгрузить конфигурацию в файлы».
2. Перейдите в папку с выгрузкой и найдите XML-файлы обоих модулей: ОбменДаннымиXDTOСервер и ОбменДаннымиXDTOСервер_old.
3. Откройте оба файла в любом текстовом редакторе. Найдите теги, отвечающие за внутренний идентификатор (обычно это тег uuid или Id).
4. Аккуратно скопируйте идентификатор из старого модуля и вставьте в новый, а идентификатор из нового перенесите в старый. Обязательно сохраните файлы.
5. Загрузите конфигурацию из файлов обратно в информационную базу.

В результате этих действий ваш рабочий кастомный модуль получит типовой UUID от поставщика, а переименованный старый модуль получит пользовательский идентификатор. Теперь при обновлении из .cfu платформа подхватит именно нужный нам модуль.

Вариант 4: Очистка старых объектов и повторная постановка на поддержку

Разберем по шагам радикальный метод на случай, если старый модуль (_old) больше не несет смысловой нагрузки, и вы хотите оставить все доработки в новом модуле, сделав его типовым и поддерживаемым.

1. В настройках поддержки полностью снимите конфигурацию с поддержки.
2. Удалите неактуальный модуль с суффиксом _old.
3. Выполните сравнение и объединение с полным .cf файлом типовой конфигурации нужного релиза. На вопрос системы о постановке на поддержку ответьте утвердительно.
4. В окне сравнения обязательно проконтролируйте и сопоставьте типовой модуль поставщика с вашим текущим модулем ОбменДаннымиXDTOСервер.

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