Как обновить один объект конфигурации из файла поставки и сохранить данные?

← На главную

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

Анализ проблемы и риски выборочного обновления

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

Физическое удаление данных СУБД при реструктуризации: если в файле обновления старый реквизит удален, а вместо него добавлена новая табличная часть, то при обычном объединении и нажатии клавиши F7 (обновление конфигурации базы данных) платформа физически удалит колонку реквизита из таблицы базы данных. Вся информация пропадет еще до того, как вы запустите пользовательский сеанс для выполнения каких-либо обработок.
Сбой штатных механизмов обновления БСП: в типовых конфигурациях процедуры заполнения и миграции новых структур данных привязаны к номеру версии конфигурации в общем модуле ОбновлениеИнформационнойБазы. При выборочном обновлении одного объекта номер версии конфигурации не увеличивается, поэтому типовой обработчик обновления при старте системы не выполнится.
Нарушение связей и зависимостей: обновленный объект может ссылаться на новые процедуры и функции общих модулей, параметры подсистем или измененные роли, которые не были перенесены при частичном объединении.

Разберем по шагам, как безопасно выполнить процедуру на копии базы данных.

Способ 1. Обновление с временным сохранением старого реквизита

Рассмотрим наиболее надежный вариант, позволяющий выполнить миграцию данных встроенными средствами без риска затирания значений при реструктуризации.

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

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


// Пример вызова штатной процедуры обновления
ИмяОбработчика = "ОбновлениеИнформационнойБазыБП.ЗаполнитьТабличнуюЧастьПоРеквизиту";
Выполнить(ИмяОбработчика + "()");

Если штатной процедуры нет или ее запуск невозможен, используем собственную обработку переноса данных:


Выборка = Документы.ЗаказПокупателя.Выбрать();
Пока Выборка.Следующий() Цикл
    Если ЗначениеЗаполнено(Выборка.УдалитьСтарыйРеквизит) Тогда
        ДокОбъект = Выборка.ПолучитьОбъект();
        НоваяСтрока = ДокОбъект.НоваяТабличнаяЧасть.Добавить();
        НоваяСтрока.Значение = ДокОбъект.УдалитьСтарыйРеквизит;
        
        // Отключаем лишние проверки при записи, если это допустимо
        ДокОбъект.ОбменДанными.Загрузка = Истина;
        ДокОбъект.Записать(РежимЗаписиДокумента.Запись);
    КонецЕсли;
КонецЦикла;

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

Способ 2. Предварительная выгрузка и последующая загрузка данных

Проанализируем альтернативный вариант, который удобно использовать, если объем данных невелик или требуется полностью повторить структуру объекта от поставщика без промежуточных переименований.

Выгружаем данные до обновления: в режиме «1С:Предприятие» запускаем внешнюю обработку и сохраняем соответствие Ссылка -> ЗначениеРеквизита в файл (например, XML, JSON или временную таблицу).
Обновляем объект из файла поставки: в конфигураторе выполняем объединение, соглашаясь на удаление старого реквизита и создание табличной части, после чего применяем изменения (F7).
Загружаем данные в новую структуру: открываем внешнюю обработку загрузки, считываем сохраненный файл и заполняем строки созданной табличной части для каждого объекта по его ссылке.

Проверка зависимых объектов конфигурации

После переноса структуры и данных обязательно проверим связанные элементы системы, чтобы исключить ошибки во время работы пользователей:

Подписки на события: выясним, не обращаются ли обработчики подписок (например, ПередЗаписью или ОбработкаПроведения) к удаленному реквизиту.
Роли и права доступа: для добавленной табличной части и ее колонок права по умолчанию могут оказаться не назначенными. Проверяем доступность новых метаданных для основных рабочих ролей конфигурации.
Формы и динамические списки: убедимся, что удаленный реквизит не остался в запросах динамических списков журналов, критериях отбора или элементах управляемых форм.
Движения регистров: если реквизит влиял на логику проведения документов, проверяем модуль объекта и при необходимости запускаем перепроведение документов затронутого периода.