Перенос данных одной организации из многофирменной базы 1С:Бухгалтерия предприятия 2.0 в уже функционирующую базу 3.0 — это задача, требующая четкой последовательности действий. В отличие от стандартного обновления, здесь мы сталкиваемся с необходимостью «вычленения» конкретного юридического лица и интеграции его данных в существующую структуру другой базы. Разберем подробно основные методы, их преимущества и риски.
Этот способ считается одним из самых надежных с точки зрения сохранения целостности ссылок. Проанализируем алгоритм действий:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено).УниверсальныйОбменДаннымиXML. Выгружаем все данные и загружаем их в общую рабочую базу 3.0.Рассмотрим более современный подход, который предлагает сама платформа. В конфигурации БП 3.0 реализован механизм «Загрузка данных из 1С:Бухгалтерии 8 ред. 2.0». Посмотрим, как это работает на практике:
Прямое подключение к базе 2.0 позволяет избежать промежуточных файлов XML. В мастере загрузки мы можем выбрать конкретную организацию. Программа предложит два варианта: перенос остатков на начало года или перенос всех документов. Важно помнить: перенос всей истории за много лет через этот инструмент может быть нестабильным из-за различий в архитектуре регистров между 2.0 и 3.0. Оптимально переносить остатки на начало года и обороты текущего периода.
Выясним причину, почему иногда стоит прибегнуть к свертке (конволиции) данных. Если в исходной базе 2.0 накоплен огромный объем информации за 10 лет, переносить этот «балласт» в новую базу 3.0 нецелесообразно. Рассмотрим шаги:
Используем обработку СверткаИнформационнойБазы. Она сформирует документы ВводОстатков на выбранную дату. После этого мы переносим только справочники и эти документы ввода остатков. Это значительно ускоряет процесс и минимизирует количество ошибок, связанных с «битыми» ссылками прошлых периодов.
При слиянии данных двух баз неизбежно возникновение дублей в справочниках Контрагенты, Номенклатура и ФизическиеЛица. Проанализируем ситуацию: в целевой базе уже может быть «ООО Вектор», и в переносимой базе он тоже есть, но с другим внутренним идентификатором (GUID).
Для решения этой проблемы после загрузки данных обязательно запускаем стандартную обработку «Поиск и удаление дублей». Рекомендуем настраивать правила поиска по ИНН и КПП для организаций/контрагентов. Это позволит «схлопнуть» записи, сохранив историю движений на правильных объектах.
Разберем критически важный момент — нумерацию документов. Если в целевой базе 3.0 уже ведется учет и используются префиксы (например, «ОФ»), а в переносимой базе префикс такой же или отсутствует, вы получите ошибку уникальности номеров.
Рассмотрим решение: перед миграцией в базе-источнике (БП 2.0) следует установить для организации новый уникальный префикс, который ранее не использовался в базе-приемнике. Только после этого приступаем к выгрузке. Это обеспечит сквозную и корректную нумерацию в общей базе.
Обратим внимание, что УниверсальныйОбменДаннымиXML часто переносит только справочники и документы, но может пропустить специфические настройки. После переноса нам необходимо вручную проверить:
Завершающим этапом нашей совместной работы должна стать проверка корректности данных. Выполним следующие действия:
Проанализировав все способы, можно сделать вывод: метод через РИБ наиболее безопасен для сохранения ссылочной целостности, а использование Data Conversion (Конвертация данных) лучше всего подходит, если требуется сложная синхронизация объектов не по GUID, а по уникальным реквизитам (ИНН/Артикул).