Как перенести данные между разными релизами базы 1С?

Довольно часто в практике возникает задача переноса данных за небольшой период (например, за один рабочий день) из одной базы 1С в другую. Ситуация усложняется, когда базы имеют разные версии конфигурации. Например, источник — это нетиповая 1С:Управление торговлей релиза 10.3.11, а приемник — обновленная база релиза 10.3.41. Разберем по шагам, как можно перенести документы и справочники так, чтобы не пришлось вбивать их заново вручную.

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

Решение 1. Временное обновление копии и выгрузка XML

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

Разберем алгоритм действий:

1. Создаем полную копию базы-источника (релиз 11).
2. Накатываем на эту копию конфигурацию (cf-файл) от базы-приемника (релиз 41). Смело принимаем изменения структуры.
3. В обновленной копии открываем типовую обработку Выгрузка и загрузка данных XML (обычно находится в меню Сервис или поставляется на дисках ИТС).
4. Настраиваем отбор по нужному периоду (например, за вчерашний день) и выбираем необходимые виды документов.
5. Критически важно: устанавливаем флаг выгрузки связанных ссылочных объектов. Если за день пользователи создали новых контрагентов или номенклатуру, без этого флага загруженные документы окажутся "битыми" (с пустыми ссылками).
6. Выгружаем данные в XML-файл.
7. В базе-приемнике открываем ту же обработку и загружаем полученный файл.

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

Решение 2. Использование "Конвертации данных 2.x"

Если обновление копии по каким-то причинам невозможно (например, добавлены новые обязательные реквизиты, которые не заполнятся при простом обновлении), наиболее безопасным вариантом станет полноценное использование конфигурации Конвертация данных 2.x (КД).

Посмотрим на процесс работы с КД:

1. Выгружаем описания структур метаданных из обеих баз (с помощью специальной обработки, идущей в комплекте с КД).
2. Загружаем обе структуры в конфигурацию Конвертация данных.
3. Автоматически генерируем правила обмена. Для полностью совпадающих объектов система создаст правила сама.
4. Для измененных документов визуально настраиваем маппинг новых и старых реквизитов, пишем обработчики событий при необходимости.
5. Сохраняем правила обмена в файл.
6. В базе-источнике используем обработку Универсальный обмен данными в формате XML, выбираем созданные правила и выгружаем данные.
7. Загружаем файл в базе-приемнике через ту же обработку.

Решение 3. Программный перенос через COM-соединение

Альтернативным вариантом для опытных разработчиков является написание скрипта переноса с использованием COM-соединения. Для этого используется объект V82.COMConnector.

При передаче данных через COM объекты из другой базы воспринимаются как COM-объекты. Их нельзя напрямую присваивать реквизитам текущей базы. Требуется программное сопоставление каждого ссылочного объекта. Если вы пишете собственный скрипт, обязательно сохраняйте оригинальные идентификаторы (GUID). Если перенести данные, просто создавая новые элементы без явного указания старого GUID, базы необратимо рассинхронизируются.

Посмотрим на пример того, как правильно устанавливать ссылку новому объекту в коде базы-приемника, чтобы сохранить связь:

// Предположим, мы прочитали GUID документа из COM-базы
СтарыйУникальныйИдентификатор = ТекДокументCOM.УникальныйИдентификатор();

// Создаем документ в текущей базе
НовыйДокумент = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
НовыйДокумент.УстановитьСсылкуНового(СтарыйУникальныйИдентификатор);

// ... программное заполнение реквизитов документа ...

НовыйДокумент.Записать(РежимЗаписиДокумента.Запись);

Решение 4. Перенос через табличный документ (Excel)

Если за пропущенный день пользователи ввели документы всего одного-двух видов (например, только реализации и приходные ордера), быстрым решением без программирования является использование стандартной обработки загрузки из табличного документа.

Рассмотрим этот экспресс-метод:

1. В старой базе открываете список нужных документов, выводите список с нужными колонками (контрагент, сумма, номенклатура из табличной части).
2. Копируете данные в буфер обмена или сохраняете в Excel.
3. В новой базе открываете обработку Загрузка данных из табличного документа.
4. Вставляете скопированные строки и настраиваете синхронизацию ссылочных полей (по наименованиям, ИНН или артикулам).
5. Генерируете новые документы.

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