Конвертация данных: как перенести и синхронизировать базы 1С
Содержание
Частое заблуждение: «конвертация данных » — это кнопка «Выгрузить» в одной базе 1С и «Загрузить» в другой. На деле выгрузка и загрузка — лишь финал. Главное — правила обмена: таблица соответствия, по которой документ, справочник или регистр из базы-источника превращается в объект базы-приёмника.
Эти правила готовят в отдельной программе — конвертации данных. Живых редакции две: КД 2.0 работает через XML-файл правил, КД 3.0 — через универсальный формат EnterpriseData. Ниже — когда какая нужна, как собрать правила обмена и не споткнуться на типовых ошибках выгрузки и загрузки.
Когда конвертация действительно нужна
Сначала проверьте, не решается ли задача без КД. В типовых конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11, КА, ERP) синхронизация между знакомыми парами баз уже встроена.
Открывается она в разделе Администрирование → Синхронизация данных. Там есть готовые настройки для распространённых связок — например, бухгалтерия с зарплатой или бухгалтерия с торговлей. Если ваша пара в списке, конвертор КД не нужен.
Собственные правила через конвертацию данных нужны в других случаях:
- 🔁 Переход между конфигурациями — разовый перенос остатков и справочников при смене программы (с устаревшей редакции на актуальную, с самописной базы на типовую).
- 🔗 Нестандартный обмен — связка, для которой типовой настройки нет: доработанная конфигурация, обмен с отраслевым решением, выгрузка в стороннюю систему.
- 🏢 Обмен с внешними программами — когда 1С отдаёт или принимает данные по согласованному XML-формату от сайта, CRM, складской системы.
- 🧩 Донастройка типового обмена — типовая синхронизация есть, но нужно добавить своё поле или свой объект в состав выгрузки.
Разовый переход и постоянная синхронизация — разные задачи. Для переезда «один раз и забыли» хватит выгрузки по правилам. Для регулярного обмена нужен план обмена с отслеживанием изменений, иначе каждый сеанс будет гонять всю базу целиком.
Конвертор КД 2.0 и КД 3.0: чем отличаются
Обе редакции — это самостоятельные базы, которые вы разворачиваете на той же платформе 1С:Предприятие 8.3. Разница в том, как хранятся и применяются правила.
Конвертация данных 2.0 строит произвольный XML-формат обмена. Вы загружаете в неё описание структуры метаданных источника и приёмника, вручную сопоставляете объекты и реквизиты, задаёте правила поиска, по которым приёмник ищет уже существующий объект. На выходе — XML-файл правил обмена.
Конвертация данных 3.0 работает поверх универсального формата EnterpriseData. Здесь обмен идёт не «база ↔ база», а «база ↔ формат»: каждая конфигурация умеет выгружать и загружать данные в общий стандарт. Правила описываются в модулях (кодом), а не только мышью.
Сравнение по ключевым свойствам:
| Свойство | КД 2.0 | КД 3.0 |
|---|---|---|
| Основа обмена | Произвольный XML-формат | Универсальный формат EnterpriseData |
| Описание правил | Визуально + обработчики на встроенном языке | Модули менеджеров объектов, код |
| Связь баз | Прямое соответствие «источник → приёмник» | Через общий формат-посредник |
| Переносимость | Правила привязаны к паре баз | Один формат для многих конфигураций |
| Обновление релизов | Правила приходится пересобирать | Легче: меняется формат, а не каждая пара |
| Порог входа | Ниже, нагляднее | Выше, нужен навык программирования |
Вывод простой. КД 2.0 быстрее освоить и удобнее для разовых и нестандартных переносов. КД 3.0 — стратегический выбор для регулярной синхронизации, которую вы будете поддерживать годами.
Как устроены правила обмена
Что бы вы ни выбрали, обмен состоит из трёх логических частей. Понимание этой схемы снимает половину вопросов по ошибкам.
- Правила конвертации объектов — какой объект источника становится каким объектом приёмника. «Контрагент» → «Контрагент», «Расходная накладная » → «Реализация товаров».
- Правила конвертации свойств — какое поле источника ложится в какое поле приёмника, с преобразованием значения при необходимости.
- Правила поиска — по каким реквизитам приёмник проверяет, нет ли уже такого объекта. Это самая ответственная часть: от неё зависит, появятся дубли или данные встанут поверх существующих.
Сопоставление полей — ядро любых правил. На практике карта соответствий выглядит так:
Ключ поиска (в примере — ИНН) должен быть максимально уникальным. Если искать контрагента только по наименованию, два «ООО Ромашка» с разными ИНН либо склеятся в один, либо задвоятся.
Правила обмена жёстко привязаны к структуре конфигурации. Добавили в источник новый реквизит или обновили релиз — правила могут перестать совпадать со структурой, и обмен упадёт. Перед использованием чужих или старых правил сверяйте, под какую версию они собраны.
Порядок настройки: от структуры до выгрузки
Общая последовательность для КД 2.0 (для 3.0 шаги похожи, но правила пишутся в модулях):
- Выгрузите структуру метаданных источника и приёмника. В каждой рабочей базе это делает обработка универсального XML-обмена — она отдаёт файл описания конфигурации.
- Загрузите обе структуры в конвертацию данных и создайте новую конвертацию «источник → приёмник».
- Настройте правила конвертации объектов: сопоставьте справочники, документы, регистры, которые участвуют в обмене. Лишние объекты не тащите — только то, что реально переносится.
- Пропишите правила конвертации свойств и правила поиска. Для каждого объекта задайте уникальный ключ поиска.
- Выгрузите из конвертации готовый XML-файл правил обмена.
- В базе-источнике запустите обработку универсального обмена, подключите файл правил и выгрузите данные в XML.
- В базе-приёмнике той же обработкой загрузите этот XML.
Перед первым боевым переносом прогоните цикл на копии приёмника:
Выгружайте данные порциями — по периодам или по видам объектов. Если обмен прервётся на середине одного большого файла, разбираться, что успело загрузиться, намного тяжелее, чем перезапустить один небольшой пакет.
После тестовой загрузки сверьте результат, не доверяя сообщению «обмен завершён». Минимум три проверки: число загруженных объектов совпадает с числом выгруженных; итоговые суммы по ключевым документам сошлись; выборочно открыты несколько карточек и в них заполнены нужные поля. Расхождение по количеству чаще всего означает, что часть объектов отсеялась на правилах поиска или не прошла по правам доступа пользователя обмена.
Форматы обмена и скорость работы
Два формата дают разную гибкость и разную цену поддержки.
Произвольный XML (КД 2.0). Формат вы определяете сами — можно описать ровно то, что нужно, включая экзотические структуры. Расплата — поддержка: при каждом серьёзном обновлении конфигурации правила приходится пересобирать под новую структуру.
EnterpriseData (КД 3.0). Формат общий и версионируется. Конфигурации обмениваются через него, не зная внутреннего устройства друг друга. Обновление одной стороны реже ломает обмен, если версия формата осталась совместимой. Минус — меньше свободы: то, чего в формате нет, через него не передать без доработки.
На скорость обмена сильнее всего влияет не редакция КД, а три вещи:
- 📦 Объём за один сеанс. Полная первичная выгрузка идёт долго; дальше, при регистрации изменений, гоняются только правки — это быстро.
- 🔍 Правила поиска. Поиск по неиндексированному или составному набору полей замедляет загрузку на больших справочниках.
- 🖥 Режим и оборудование. Клиент-серверный вариант на нормальном сервере обрабатывает большие пакеты заметно быстрее файловой базы.
Практический ориентир: разовый перенос средней базы — это часы, а не минуты, и его планируют на нерабочее время. Регулярная синхронизация после первого полного обмена укладывается в секунды-минуты, потому что передаются только изменения.
Ещё один рычаг скорости — режим выгрузки. Интерактивный запуск обработки удобен для разовой задачи, но на большом объёме выгоднее фоновая выгрузка через регламентное задание: она не держит открытой форму и не зависит от сеанса конкретного пользователя. Для клиент-серверной базы тяжёлый обмен логично выносить на время, когда фоновые задания не конкурируют с пользователями за ресурсы сервера.
Автоматизация и контроль обмена
Запускать выгрузку-загрузку руками каждый раз необязательно. В типовой синхронизации на БСП расписание задаётся прямо в настройке обмена: укажите интервал, и регламентное задание будет переносить изменения по графику.
Следить за обменом помогают встроенные средства:
- Состав и предупреждения. Карточка настройки синхронизации показывает, какие данные ушли и пришли, и подсвечивает предупреждения — например, объекты, которые не удалось сопоставить.
- Коллизии. Если один объект поменяли в обеих базах, система фиксирует конфликт версий. Правило разрешения коллизий (чья версия главнее) задаётся в настройке обмена заранее.
- Журнал регистрации. Технические ошибки сеанса обмена пишутся в журнал регистрации базы — это первое место, куда смотрят при разборе сбоя.
- Протокол обмена. Обработка универсального обмена ведёт свой протокол загрузки с перечнем проблемных объектов.
Не ставьте автоматический обмен сразу в боевом режиме «вслепую». Первые несколько циклов запускайте вручную и проверяйте результат по протоколу — пока не убедитесь, что правила поиска не плодят дубли.
Частые ошибки при выгрузке и загрузке
Самые типовые срывы обмена — и что с ними делать.
- Дубли в приёмнике. Причина почти всегда одна — слабый ключ поиска. Контрагенты искались по наименованию, а не по ИНН. Правьте правила поиска и чистите задвоенные объекты до следующего обмена.
- «Объект не найден» / не загрузились связанные данные. В документе есть ссылка на справочник, который в этот пакет не попал. Включите связанные справочники в состав выгрузки или выгружайте их первым пакетом.
- Правила не соответствуют структуре. После обновления релиза поле переименовали или перенесли. Обмен падает на выгрузке. Пересоберите правила под актуальную структуру обеих баз.
- Несовпадение версии формата (КД 3.0). Базы обмениваются разными версиями EnterpriseData. Приведите обе стороны к совместимой версии формата.
- Данные встали не туда. Ошибка в правиле конвертации свойства: поле источника легло в неверное поле приёмника. Ловится только сверкой контрольного документа после тестовой загрузки.
Частые вопросы
Чем конвертация данных отличается от простой синхронизации?
Нужно ли программировать, чтобы настроить обмен?
Можно ли перенести данные без конвертации, через выгрузку-загрузку?
.dt) переносит конфигурацию целиком и подходит только для одинаковых баз. Перенести данные между разными конфигурациями такой выгрузкой нельзя — для этого и нужны правила обмена.