Выгрузка из 1С в другую базу 2026: EnterpriseData, XML, планы обмена и защита от дублей

Открыли второе юрлицо, отделили филиал, перешли с самописной УТ 10.3 на БП 3.0 или решили сделать рабочую копию базы для нового подразделения. Кажется, что задача простая: выгрузить контрагентов, номенклатуру и документы из одной базы 1С в другую. На практике ломается не сама выгрузка, а сопоставление: один и тот же контрагент появляется дважды, документ загружается без договора, номенклатура приезжает без единиц измерения, а после повторной загрузки база-приёмник получает еще 3 000 дублей.

Эта статья для владельца, бухгалтера и 1С-разработчика, которым нужно выбрать способ переноса данных между базами 1С в 2026 году. Здесь нет универсального совета «выгрузите XML». Правильный способ зависит от 4 вещей: одинаковые ли конфигурации, нужен ли разовый перенос или регулярная синхронизация, есть ли типовая поддержка EnterpriseData, и по каким полям вы будете узнавать уже существующие объекты.

Ключевые факты

• Файл выгрузки информационной базы из Конфигуратора (.dt) не переносит отдельные справочники и документы в существующую базу. Он заменяет базу целиком при восстановлении.
• Распределенная информационная база (РИБ) подходит для территориально распределенной системы на основе идентичных конфигураций. Это не универсальный мост между УТ, БП, ERP и доработанными базами.
• План обмена в 1С хранит узлы обмена, состав передаваемых данных и регистрацию изменений. Если объект не зарегистрирован для обмена, он не попадет в очередное сообщение.
• EnterpriseData - официальный XML-формат 1С для обмена бизнес-сущностями: контрагентами, договорами, кассовыми ордерами, актами и другими объектами. Он работает через веб-сервис, каталог, FTP или email.
• Универсальный обмен данными в формате XML полезен для разового переноса по правилам конвертации, но правила должны соответствовать версиям и структурам обеих баз.
• Главный риск переноса - не XML, а идентификация объектов. До загрузки нужно решить, как сопоставлять контрагентов, номенклатуру, договоры и документы: по GUID, ИНН+КПП, артикулу, коду, номеру+дате или внешнему ключу.

Сначала выберите сценарий, а не инструмент

В нашем тестовом контуре для статей 1С мы проверяем перенос на копиях баз, а не на боевых данных: сначала выгружаем 50 контрагентов, 100 позиций номенклатуры и 20 документов за закрытый месяц, затем считаем объекты до и после загрузки. Самые частые ошибки находятся уже на этом малом наборе: у контрагентов разный КПП, у номенклатуры не совпадают единицы измерения, у документов не создана организация или договор.

Разделите задачу на один из 5 сценариев:

Если вам нужно «перенести справочник контрагентов и 2 года реализаций в уже работающую БП», .dt и РИБ почти всегда не подходят. Если нужно «сделать удаленный склад с той же конфигурацией», наоборот, не надо писать кастомную конвертацию: сначала смотрите РИБ и штатные планы обмена.

Что важно понять про EnterpriseData

EnterpriseData - это не «выгрузка всей базы». Это универсальный бизнес-формат, основанный на XML: в файле описываются бизнес-сущности, а не физические таблицы базы. В официальном описании 1С прямо приводит примеры таких сущностей: акт выполненных работ, приходный кассовый ордер, контрагент, договор.

Практически это означает 3 вещи:

1. Формат отвязан от внутренней структуры таблиц. В УТ и БП один и тот же бизнес-объект может храниться по-разному, но обмен работает через согласованное представление.
2. Передаются изменения, а не каждый раз вся база. В сообщениях есть MessageNo, ReceivedNo и квитанции. После подтверждения принятые изменения больше не выгружаются.
3. Нужна дисциплина узлов обмена. У приложения есть уникальный код, канал обмена и состояние принятых/отправленных сообщений. Нельзя бездумно копировать настройки узла в другую базу и ждать, что очередь обмена останется корректной.

Для типовых связок вроде УТ 11 -> БП 3.0, ERP -> БП, Розница -> БП EnterpriseData обычно лучше самописной XML-выгрузки: меньше привязки к таблицам, больше типовой поддержки со стороны 1С. Но он не отменяет подготовку НСИ. Если в приёмнике уже есть контрагент с тем же ИНН, но другим КПП или наименованием, автоматическое сопоставление может создать дубль или конфликт.

Универсальный XML и правила конвертации

«Универсальный обмен данными в формате XML» - рабочий инструмент для разового переноса, когда есть правила. В руководствах 1С по переходам между редакциями этот путь используется для ситуаций, когда нужно выгрузить не все данные, а выбранные справочники, документы или регистры за период. Ключевая деталь: обработке нужен файл правил переноса.

Правила описывают, как объект источника превращается в объект приёмника:

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

Если конфигурация источника доработана, типовые правила могут быть недостаточны. Например, в карточку контрагента добавлен реквизит «Сегмент клиента», а в базе-приёмнике такого реквизита нет. Правило должно явно решить: игнорировать поле, записывать в дополнительный реквизит или создавать новое соответствие. Без этого перенос выглядит успешным, но часть данных теряется.

Планы обмена и РИБ: когда они уместны

План обмена - это объект конфигурации, через который 1С описывает узлы, состав обмена и регистрацию изменений. В плане обмена можно включить авторегистрацию: платформа сама отслеживает изменения объектов и формирует набор данных для очередного сообщения. Это удобно для регулярной синхронизации, но плохо подходит для хаотичного разового импорта «что-нибудь из старой базы».

РИБ строится поверх планов обмена и предназначена для распределенной системы на идентичных конфигурациях. Она умеет передавать не только данные, но и изменения конфигурации от корневого узла к подчиненным. Это сильный инструмент для филиалов, складов и удаленных точек, но у него строгая организационная модель: дерево узлов, главный/подчиненный, правила коллизий.

РИБ не нужно использовать там, где задача звучит как «перенести номенклатуру из УТ в ERP» или «подлить документы из старой БП в новую». Там нужны EnterpriseData, правила конвертации или кастомный перенос.

Идентификаторы: почему появляются дубли

В 1С у объектов есть ссылки и внутренние идентификаторы, но при переносе между разными базами ссылка из источника не равна ссылке в приёмнике. Поэтому перенос должен хранить соответствия: «контрагент A из базы-источника соответствует контрагенту B в базе-приёмнике». Если соответствие не найдено, создаётся новый объект.

На практике мы закладываем такие ключи:

Перед загрузкой 10 000 объектов делайте пробу на 100-200 строках и строите отчет: сколько найдено существующих, сколько создано новых, сколько ушло в конфликт. Если отчет не сходится на малом объеме, большая загрузка только умножит проблему.

Таблица рисков переноса

Порядок безопасного переноса

1. Сделайте копии обеих баз. Для файловой базы достаточно копии каталога при остановленных пользователях; для SQL - штатный бэкап СУБД. Боевой перенос без отката не запускайте.
2. Зафиксируйте версии. Запишите конфигурацию, релиз, режим совместимости, тип базы, список расширений и доработок. Для EnterpriseData отдельно проверьте поддерживаемую версию формата.
3. Опишите состав данных. Не «перенести всё», а конкретно: контрагенты, договоры, номенклатура, единицы, остатки, реализации с 2024-01-01, поступления без проведения.
4. Выберите ключи сопоставления. Для каждого справочника и документа должен быть ключ поиска существующего объекта.
5. Очистите НСИ до миграции. Поиск и удаление дублей лучше делать до обмена, а не после, когда документы уже ссылаются на новые карточки.
6. Сделайте малую тестовую загрузку. Берите разные типы объектов: юрлица с КПП, ИП, услуги, товары, документы с НДС и без НДС.
7. Сверьте контрольные цифры. Количество элементов, суммы документов, незаполненные обязательные реквизиты, ошибки проведения, новые дубли.
8. Только потом запускайте полный перенос. После загрузки сохраните протокол: дата, версия правил, число созданных/обновленных/пропущенных объектов.

Где здесь Синхрон1С

Синхрон1С полезен не как «магическая XML-кнопка», а как слой контроля вокруг обмена: подключаемся к обеим базам, фиксируем правила сопоставления, запускаем перенос по расписанию или вручную, а в Telegram отправляем не общую ошибку «обмен не выполнен», а конкретику: какой контрагент не сопоставился, какой документ не прошел дату запрета, где создан новый дубль.

Для разовой миграции мы обычно начинаем с тестовой выборки и протокола соответствий. Для постоянной синхронизации добавляем расписание, мониторинг очереди сообщений и уведомления о конфликтах. Стоимость поддержки интеграции - 5 000 ₽/мес; разовую настройку оцениваем после просмотра состава баз и объёма данных.

Смотрите также

• Выгрузка из 1С УТ в Бухгалтерию: EnterpriseData, НДС 5/7%, конфликты
• Интеграция 1С УТ и Бухгалтерия: обмен данными
• Форматы выгрузки из 1С: CSV, JSON, XML
• Выгрузка документов из 1С: УПД, счета, акты
• Регламентные задания 1С: автоматизация без программиста

Часто задаваемые вопросы

Можно ли выгрузить из одной базы 1С только контрагентов?

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

Почему нельзя просто загрузить .dt в другую рабочую базу?

Потому что .dt - это образ информационной базы для восстановления, а не импорт выбранных данных. Восстановление заменит содержимое базы-приёмника. Если там уже ведётся учёт, нужен перенос объектов, а не восстановление дампа.

Что лучше: EnterpriseData или универсальный XML?

Для регулярной синхронизации типовых современных конфигураций обычно лучше EnterpriseData. Для разового перехода между редакциями, где у 1С есть готовые правила, подходит универсальный XML. Для нетиповых баз нужен анализ правил и доработок.

Как избежать дублей контрагентов?

До переноса очистить справочник, выбрать ключ сопоставления и проверить спорные пары вручную. Для юрлиц базовый ключ - ИНН+КПП, для ИП - ИНН. Наименование нельзя считать надежным ключом.

Можно ли переносить документы без справочников?

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

Что делать, если базы на разных релизах?

Сначала проверить, какие реквизиты и версии формата поддерживает каждая база. Если релизы сильно разошлись, безопаснее обновить копии до согласованного состояния или скорректировать правила переноса. Боевой перенос между неподготовленными релизами часто заканчивается потерей реквизитов и ошибками проведения.

Можно ли повторно запустить один и тот же импорт?

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

Напишите в Telegram: @onoutnoxon - проверим состав баз, подберём способ переноса и настроим контроль дублей. Подробнее о возможностях - на странице Синхрон1С.

Источники

• Формат EnterpriseData, официальное описание 1С: https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/format-enterprisedata/
• План обмена в платформе 1С:Предприятие: https://v8.1c.ru/platforma/plan-obmena/
• Распределенная информационная база 1С:Предприятие: https://v8.1c.ru/platforma/raspredelennaya-informatsionnaya-baza/
• Выгрузка и загрузка данных XML, методическая поддержка 1С: https://its.1c.ru/db/metod8dev/content/4126/hdoc
• Руководство 1С по переходу с Бухгалтерии 1.6 на 2.0, раздел про универсальный XML и правила переноса: https://its.1c.ru/docs/perehod_1.6_2.0/perehod_1.6_2.0
• Внешнее соединение COM в 1C:Enterprise Development Tools: https://its.1c.ru/db/content/edtdoc/src/topics/t000419.html
• Поиск и удаление дублей в 1С:Бухгалтерии 8: https://its.1c.ru/db/answers1c/content/32/hdoc

Материал подготовлен при участии AI-ассистента для поиска источников и структурирования, затем отредактирован вручную. Практические рекомендации по ключам сопоставления, тестовой загрузке и контролю дублей основаны на рабочих сценариях миграции 1С. Финальную редактуру выполнил Александр Руин, основатель habab.ru. Обновлено: 2026-05-04.