
Готовые универсальные переносы данных 1С
Список всех решений для переноса данных между различными конфигурациями 1С.
Содержание
- Обмен данными 1С
- Классификация задач обмена данными 1С
- Синхронизация и формат XDTO (EnterpriseData)
- Начальный перенос данных: конвертация XML
- Перенос между одинаковыми базами
- Типовые проблемы обмена данными
- Последовательность выгрузки данных
- Выгрузка только изменённых объектов
- Сверка данных после обмена
- Сопоставление объектов в обмене
- Заключение
Классификация задач обмена данными 1С
Обмен данными в 1С охватывает несколько разных задач. Основные сценарии такие:
- Постоянная синхронизация (online): автоматический обмен данными между базами по расписанию. Например, центральная база «1С:ERP» и офисная «1С:УНФ» постоянно обмениваются заказами и остатками.
- Первичный перенос данных: разовый импорт полного набора данных. Это актуально при переходе на новую конфигурацию или объединении баз – нужно передать контрагентов, номенклатуру, остатки и историю.
- Перенос между идентичными базами: простая выгрузка/загрузка целиком. Такой обмен часто используют при создании тестовой копии системы или резервном копировании.
| Задача обмена | Предпочтительный метод |
|---|---|
| Постоянная синхронизация (online) | Формат XDTO (EnterpriseData), встроенный механизм 1С |
| Первичный перенос между разными базами | Правила конвертации данных (XML). Готовые ПКО для типовых сценариев |
| Перенос между одинаковыми базами | Внешняя обработка «Выгрузка и загрузка данных XML» (ИТС) |
| Обмен 1С:7.7 ↔ 1С:8 | Конвертация данных 2.0 (XML) или специальные утилиты миграции |
И действительно: обмен данными — это обмен данными, и сама формулировка отражает суть процесса. Независимо от задачи всегда происходит одно и то же – передача информации из одной системы в другую и поддержка её актуальности. Суть в передаче и синхронизации данных.
Синхронизация и формат XDTO (EnterpriseData)
При синхронизации современные конфигурации 1С используют универсальный формат EnterpriseData (XDTO). Этот формат предназначен специально для обмена бизнес-сущностями (документами и элементами справочников). Формат основан на JSON, но он «человекоориентирован»: по структуре легко увидеть реальные объекты (например, документ «Реализация» или справочник «Контрагенты»), а не просто произвольные теги. Стандартные продукты (ERP, БП, УТ, ЗУП, Розница и др.) поддерживают обмен в ED «из коробки». В 1С есть мастер синхронизации («Синхронизация данных»). Нужно указать, какие объекты (регистры, справочники, документы) участвуют, задать правила конвертации и расписание обмена. Платформа сама сформирует JSON-файл сообщения обмена и отправит его по назначенному каналу (файловому, веб-сервису, электронной почте и т.д.). При таком обмене одна база высылает изменения, а вторая их загружает и отвечает квитанцией об успешном приёме. Проще говоря, после первого полного обмена последующие пакеты будут передавать только новые изменения. Это существенно экономит время и ресурсы.
Ключевые достоинства формата EnterpriseData:
- Широкая поддержка: встроен во многие типовые конфигурации 1С (ERP, УТ, БП, ЗУП, Розница и др.).
- Бизнес-ориентированность: в файле только реальные поля документов/справочников, нет лишних технических тегов (интерфейсных настроек, служебных флагов).
- Эффективность: после первого полного обмена последующие пакеты содержат лишь дельты (изменённые и новые объекты), что экономит трафик.
Таким образом, при синхронизации 1С-система сама упаковывает данные в XDTO, и пользователю достаточно настроить мастера обмена. Сохранность и целостность данных проверяется через квитанции, встроенные в формат ED.
Начальный перенос данных: конвертация XML
Для одноразового переноса данных между разными конфигурациями часто используют механизм Конвертация данных 2.0 (XML). С помощью стандартной обработки выгружают данные из исходной базы в файл XML по набору правил, а затем загружают их в целевую базу. Это позволяет переносить целые иерархии: справочники с реквизитами, табличные части документов и т.д. Система 1С поддерживает множество готовых примеров правил (ПКО) для типовых миграций, которые можно взять за основу. Например, в документации и на сайтах специалистов есть готовые правила «Перенос из версии Х в версию Y» (с учётом различий в конфигурациях).
Профессиональный подход: использовать готовые правила обмена 1С и адаптировать их под задачу. Это экономит массу времени. MoscowSoft разработала набор типовых правил для популярных сценариев переноса – их можно протестировать на сайте Sky1C, чтобы убедиться, что всё перенесётся корректно. Готовые правила учтут связи между объектами и преобразуют реквизиты автоматически. Главное – правильно сопоставить ключевые поля (например, по коду или наименованию) и проверить итоговый результат.
Выбрать правила обмена 1С в формате XML >>
Перенос между одинаковыми базами
Когда конфигурации в базах идентичны по структуре, перенос проще. Можно воспользоваться внешней обработкой «Выгрузка и загрузка данных XML» (доступна на сайте 1С:ИТС). Эта обработка позволяет выгрузить из одной базы всё необходимое в XML-файл и загрузить в другую без сложных правил конвертации. Если базы действительно совпадают (одинаковый релиз, те же доработки), то новый сервер буквально «примет» документы и справочники со старыми ссылками. При этом важно, чтобы версии конфигураций были синхронизированы: даже небольшие изменения (новое поле или реквизит) могут вызвать несоответствия. Если всё в порядке, такой «чистый» перенос данных эффективен – пример: клонирование боевой базы на тестовый сервер. В результате новая база получает копию объектов, документов и остатков так, как есть.
Типовые проблемы обмена данными
При организации обмена легко столкнуться с типовыми ошибками:
- Неправильный порядок выгрузки: если сначала выгрузить документ, а потом его справочник (напр., сначала продажу, а потом контрагента), при загрузке ссылка «уйдёт в никуда». Всегда сначала выгружайте справочники, потом документы.
- Чрезмерная фильтрация: слишком жёсткие условия фильтра могут отрезать нужные записи. Например, выгрузили товары только по одному складу, а потом удивляетесь, почему в приёмнике не все продажи.
- Устаревшие метаданные: если в конфигурации добавили новые реквизиты, но забыли обновить правила обмена (XML-схему), загрузка выдаст ошибку «Тип не определён». Всегда после изменений в структуре пересоздавайте правила обмена.
- Отсутствие уникальных ключей (ПКО): если ключ поиска не задан или неуникален, при загрузке появляются дубликаты. Например, без ПКО по артикулу характеристик каждую загрузку в базу будут создаваться новые идентичные объекты.
- Проблемы с кодировкой: файл XML всегда должен быть в UTF-8. При другой кодировке русские буквы превратятся в иероглифы, и обмен упадёт.
- Пропуск системных реквизитов: если не выгрузить флаги «Проведен» или «ПометкаУдаления», в приёмнике документы могут получить неверный статус. К примеру, считаете документ проведённым, а при загрузке он оказался «непроведённым».
К каждой такой проблеме можно добавить пояснение, но одна мысль общая: ошибки обмена часто бывают «скрытыми граблями», которые трудно сразу заметить. Кстати, обмен данными иногда сравнивают с эстафетой: один раздел системы передаёт «эстафетную палочку» другому, и если синхронизация нарушена — система «спотыкается». Это метафора, но она наглядно показывает: без чёткой координации обмен часто сбоит. Впрочем, вернёмся к теме. Хорошая новость: большинство описанных ошибок решается при правильной настройке правил конвертации и тщательном тестировании обмена.
Последовательность выгрузки данных
Порядок передачи объектов обычно определяется зависимостями. Рекомендуемая последовательность такая:
- Базовые справочники: сначала выгружаем фундаментальные справочники – Организации, Подразделения, Контрагенты, Сотрудники, Номенклатуру и т.д. Эти данные базовые, на них ссылаются документы.
- Справочники-«документы»: затем идут «справочники», выполняющие роль документов: Договоры, Проекты, План счетов – всё, что формирует бизнес-ссылки, но устроено как справочник.
- Основные документы: теперь можно переносить документы: закупки, продажи, производство, финансовые операции. Желательно группировать по типам: сначала закупочные документы, затем продажные, и т.д. Главное – чтобы перед загрузкой документа были уже загружены все справочники, на которые он ссылается.
- Регистры и остатки: в самом конце переносятся регистры накопления (остатки). После документов логично выгрузить информацию об остатках товаров на складах, денежных средств, открытых заказов и т.п. Так при загрузке будут корректно восстановлены все итоги.
Маленькое отступление: на крупных проектах иногда так же жарко спорят о правильном порядке обмена, как о тактике в шахматах. Но эту шутку оставим в стороне – главное, что логика простая: сначала сущности, потом операции. Как говорится, порядок задаёт структура данных, и её нужно соблюдать.
Выгрузка только изменённых объектов
1С умеет оптимизировать обмен: после первого полного импорта она отправляет лишь изменения. При настройке обмена сохраняется номер последнего пакета в узлах. При первой передаче выгружаются все объекты. После этого каждая сторона «помнит» квитанцию о приёме и в следующих обменах формирует только дельты – новые, изменённые и удалённые записи. Получается, первоначальный обмен самый «тяжёлый», а последующие пакеты обычно значительно меньше. Проще говоря, после начального полного обмена повторно передаются только обновления. Это существенно экономит трафик и время обработки.
Алгоритм синхронизации таков: первая база выгружает свою информацию (ED XML), вторая база её загружает и отвечает квитанцией о приёме, после чего первая база знает, что данный пакет доставлен. Благодаря этому при следующем обмене будут отправлены лишь несинхронизированные ранее объекты (новые или изменённые). Иными словами, дублирования данных нет – каждая сторона передаёт только то, чего нет у партнёра.
Сверка данных после обмена
Важно проверять результат после обмена. Сверять можно разными способами: вручную или с помощью инструментов. В базовом варианте проверяют ключевые отчёты: сравнивают остатки товаров по складам и бухгалтерским счетам, суммы по документам, обороты. Если отчёты в обеих базах совпадают, скорее всего обмен прошёл корректно.
Для автоматизации используют специальные методы. Например, MoscowSoft предлагает обработку «МС:Автовыверка», которая автоматически сравнивает проводки и остатки между базами и указывает расхождения. Также в 1С есть регистр «СоответствияОбъектовИнформационныхБаз», который помогает сопоставлять объекты и выявлять несоответствия. В целом задачи сверки могут быть такими:
- Сравнить отчёты: итоговые остатки по регистрах, обороты по документам.
- Сравнить списки объектов: проверить, что все важные справочники (контрагенты, товары и т.д.) попали и одинаковы в обеих базах.
- Проверить контрольные суммы: по возможности сопоставить суммы в документах (акты, счета-фактуры) и остатки регистров.
В итоге важно убедиться, что в приёмной базе нет пропущенных или дублированных записей, и обмен можно считать успешным. Без такой проверки легко «пролететь» и обнаружить ошибку уже в процессе работы системы. Поэтому сверка – обязательный шаг.
Сопоставление объектов в обмене
Наконец, рассмотрим способы сопоставления объектов между базами. По умолчанию 1С «сводит» объекты по внутренним Ссылкам (GUID): если в обеих базах изначально был один и тот же объект, он совпадёт. Но чаще объекты нужно искать по ключевым полям. Основные приёмы такие:
- Ключи поиска (ПКО): в правилах обмена можно задать ключевые реквизиты для поиска. Например, сопоставлять «Контрагент» по ИНН или по коду, «Номенклатуру» по артикулу. Система попытается найти объект в приёмнике по этому ключу. При корректной настройке ключей поиск работает автоматически.
- Регистр соответствий: если объекты нужно связать вручную (например, один документ 1С и другой в целевой базе имеют разные номера), используют регистр «СоответствияОбъектовИнформационныхБаз». В нём явно записывают пары соответствующих ссылок: «этот объект из базы А = тот объект из базы Б».
- Специальные обработчики: в менеджере конвертации данных есть события (например, ПриКонвертацииДанныхXDTO), где можно написать код и самостоятельно найти нужный объект. Это полезно в сложных сценариях, когда ни ключ, ни регистр не помогли.
Новичку лучше всего начать с настройки ПКО – указать уникальные поля (код, артикул, ИНН). Обычно этого достаточно для большинства объектов. Более тонкие случаи можно решать через регистр соответствий или код. Главное – убедиться, что каждая сущность в исходной базе найдёт в целевой свою пару.
Заключение
Обмен данными 1С – процесс многогранный, требующий внимания к деталям. Мы рассмотрели ключевые моменты: разные сценарии обмена, использование формата XDTO, правила конвертации XML для миграции, способ простой выгрузки XML для идентичных баз, типовые проблемы и их решения, порядок обмена и методы верификации. Каждый из этих аспектов сам по себе может стать отдельной задачей. И всё же часто возникает открытый вопрос: готовы ли вы применить эти рекомендации на практике и настроить безошибочный обмен, или в следующий раз найдётся новый неожиданный нюанс?
Хотите сэкономить время на разработку своего обмена 1С? Приобретайте готовый инструмент для обмена данными в формате XML на сайте Sky1C: Переносы данных 1С

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