Администрирование · 13 мин
План обмена в 1С: для чего нужен и как работает
План обмена 1С — механизм синхронизации данных между базами. Разбираем назначение, настройку, узлы, регистрацию изменений и типовые ошибки обмена.
Когда в компании работает одна база 1С, все данные живут в одном месте. Но как только появляются филиалы, интернет-магазин, отдельная база зарплаты или мобильное приложение для торговых представителей, возникает задача: как согласованно переносить документы, справочники и остатки между системами. Делать это вручную долго и опасно — ошибки ввода приводят к расхождениям в учёте. Для решения этой задачи в платформе 1С:Предприятие предусмотрен механизм планов обмена.
План обмена — это объект конфигурации, который описывает состав передаваемых данных (какие документы и справочники участвуют в обмене) и топологию обмена — список узлов, между которыми идёт синхронизация. Каждый узел — это конкретная база-участница: центральная, периферийная, другая конфигурация или внешняя система. Платформа автоматически отслеживает изменения объектов, входящих в план обмена, и формирует сообщения обмена только с теми данными, которые изменились.
Понимание того, как устроен план обмена, нужно и администратору, и разработчику, и даже продвинутому пользователю: от этого зависит, почему документ «не уехал» в другую базу, почему справочник задвоился и как безопасно восстановить обмен после сбоя. Ниже разберём назначение, устройство, настройку и типовые проблемы.
Для чего нужен план обмена: основные сценарии
Классический сценарий — распределённая информационная база (РИБ). Центральная база в головном офисе и периферийные базы в филиалах или магазинах обмениваются данными: в филиалы уходят справочники, цены и настройки, обратно приходят продажи, кассовые документы и складские операции. План обмена здесь определяет иерархию узлов и гарантирует, что каждый узел получит только свои изменения.
Второй частый сценарий — обмен между разными конфигурациями. Например, «Управление торговлей» передаёт документы реализации и счета в «Бухгалтерию предприятия», а та возвращает данные об оплатах. Или «Зарплата и управление персоналом» выгружает ведомости и кадровые документы в бухгалтерскую базу. Здесь план обмена работает в связке с правилами конвертации данных.
Третья группа сценариев — обмен с внешними системами: сайтом на «1С-Битрикс», мобильными приложениями, CRM, маркетплейсами через промежуточные сервисы. Состав плана обмена определяет, какие товары, цены и заказы участвуют в синхронизации, а узел представляет внешнюю систему.
- РИБ: центральный офис и филиалы, автономная работа магазинов без постоянной связи.
- Синхронизация УТ ↔ БП, ЗУП ↔ БП и других пар конфигураций.
- Обмен с сайтом: товары, цены, остатки, заказы.
- Перенос данных при переходе на новую конфигурацию.
- Интеграция с мобильными клиентами и внешними сервисами.
Как устроен план обмена: узлы, состав и регистрация изменений
В основе механизма лежат три понятия. Первое — состав плана обмена: список типов объектов (справочников, документов, регистров), которые могут передаваться. Если документ «Реализация товаров» не включён в состав плана обмена, он никогда не уедет в другую базу этим механизмом. Состав задаётся разработчиком в конфигураторе.
Второе — узлы обмена. Каждый узел — это запись в плане обмена, представляющая конкретную базу. В РИБ есть главный узел и подчинённые; при обмене между конфигурациями обычно два узла: «этот узел» (текущая база) и узел корреспондента. Узел хранит номера отправленных и принятых сообщений — по ним система понимает, какие изменения уже переданы, а какие ещё нет.
Третье — регистрация изменений. Когда пользователь записывает документ, входящий в состав плана обмена, платформа помечает его как изменённый для всех узлов-получателей. При выгрузке формируется сообщение обмена (обычно XML-файл) с накопленными изменениями, после успешной отправки регистрация для этого узла снимается. Благодаря этому передаются только изменения, а не вся база целиком.
Входит ли тип объекта в состав плана обмена и зарегистрирован ли он для нужного узла
Номер принятого сообщения у узла и подтверждение получения
Номера отправленных/принятых сообщений в обоих базах
Какие бывают виды обменов и чем они отличаются
Практически важно различать два подхода. Первый — распределённая информационная база: все узлы имеют одинаковую конфигурацию, данные передаются «как есть», без преобразования. Настройка простая, но изменение конфигурации требует обновления сначала центрального узла, затем периферийных, и на время обновления обмен останавливается.
Второй подход — обмен по правилам конвертации данных. Конфигурации могут быть разными (УТ и БП), а объекты при выгрузке преобразуются по правилам: реквизиты сопоставляются, значения пересчитываются, часть данных отсекается отборами. Это гибче, но сложнее в сопровождении: после обновления конфигураций правила иногда нужно дорабатывать.
Сравнение подходов
Подходит для филиалов с той же конфигурацией. Простая настройка, но жёсткая связанность версий и сложное изменение структуры.
Подходит для связки разных конфигураций (УТ–БП, ЗУП–БП). Гибкие отборы и преобразования, но правила требуют сопровождения.
Современный вариант синхронизации между типовыми конфигурациями через стандартный XML-формат. Не требует внешней обработки конвертации, но поддерживает ограниченный набор объектов.
Как настроить план обмена на практике
В типовых конфигурациях настройка выполняется через раздел «Администрирование» → «Синхронизация данных». Нужно включить флаг синхронизации, создать настройку обмена, указать префикс базы (он предотвращает пересечение номеров документов из разных узлов), выбрать способ транспорта: каталог обмена, FTP, почта, прямое подключение или веб-сервис.
Для РИБ порядок иной: в центральной базе создаётся подчинённый узел, затем формируется начальный образ периферийной базы — файл, из которого разворачивается база филиала. Важно: периферийную базу нельзя создавать простым копированием центральной, иначе обе базы будут считать себя одним узлом, и обмен развалится.
- 1Включите синхронизацию данных в разделе «Администрирование» и задайте уникальный префикс базы.
- 2Создайте настройку обмена (или подчинённый узел РИБ) и укажите состав передаваемых данных и отборы.
- 3Настройте транспорт: каталог, FTP или прямое подключение, проверьте доступность канала.
- 4Выполните первичную выгрузку (начальный образ для РИБ) и загрузите данные в базу-корреспондент.
- 5Запустите обмен, проверьте, что тестовый документ появился во второй базе, и настройте регламентное задание для автоматического обмена.
Типовые проблемы и как их диагностировать
Самая частая жалоба — «документ не пришёл в другую базу». Причин несколько: объект не входит в состав плана обмена, не прошёл отборы (например, по дате или организации), не зарегистрирован для узла, либо сообщение с ним сформировано, но не отправлено из-за ошибки транспорта. Проверку начинают с регистрации изменений: в типовых конфигурациях есть команда показа зарегистрированных изменений по узлу.
Вторая группа проблем — коллизии и дубли. Если один и тот же элемент справочника создан независимо в двух базах, при обмене появятся дубли с разными ссылками. Типовые механизмы синхронизации умеют сопоставлять объекты по ключевым полям (наименование, ИНН, код), но при расхождениях нужна ручная разметка сопоставления на этапе первой загрузки.
Третья группа — рассинхронизация номеров сообщений после восстановления базы из копии. База «откатилась», а вторая уже получила сообщения с новыми номерами — обмен встаёт с ошибкой. Лечится аккуратной корректировкой номеров отправленных и принятых сообщений у узла или повторной регистрацией данных за нужный период.
Ограничения механизма и когда он не подходит
План обмена — не инструмент резервного копирования и не способ объединить две независимо жившие базы «задним числом» без подготовки. Он также не решает задачу онлайн-доступа: обмен работает пакетами, с задержкой, и для оперативной работы нескольких офисов в реальном времени правильнее использовать единую базу с тонким или веб-клиентом.
Есть и ограничения по составу: далеко не все объекты конфигурации включены в планы обмена, а в РИБ часть системных данных (пользователи, некоторые настройки) передаётся с особенностями или не передаётся вовсе. Перед внедрением стоит сверить состав плана обмена с реальным списком данных, которые нужны в филиалах.
Как проверить, что обмен работает правильно
Базовая проверка — контрольный документ: создайте тестовый документ в одной базе, выполните обмен и убедитесь, что он появился во второй с теми же суммами и реквизитами. Затем измените его во второй базе (если обмен двусторонний) и проверьте обратное движение. Это подтверждает работу всей цепочки: регистрация → выгрузка → транспорт → загрузка.
Для регулярного контроля следите за журналом регистрации и типовыми отчётами о результатах синхронизации: количество отправленных и принятых объектов, ошибки загрузки, неотправленные сообщения. Полезно периодически сверять ключевые итоги между базами — например, остатки по складу или количество документов за период: расхождения накапливаются незаметно, если ошибки обмена игнорировать.
Как проверить результат
Появился во второй базе с корректными реквизитами и суммами
Отсутствует, задвоился или пришёл с пустыми полями
После успешной выгрузки список зарегистрированных изменений пустеет
Изменения висят в регистрации и уходят повторно
Номер принятого в одной базе соответствует отправленному в другой
Разрыв номеров, ошибки «сообщение уже принималось»
Остатки и количество документов за период совпадают
Стабильные расхождения, растущие со временем
План обмена — фундамент интеграций в 1С: он определяет состав передаваемых данных, список баз-участниц и механику отслеживания изменений. Грамотно настроенный обмен избавляет от ручного ввода и расхождений, а понимание узлов, регистрации и номеров сообщений позволяет быстро диагностировать сбои. Главные правила безопасности: уникальные префиксы, резервные копии перед любыми манипуляциями с узлами и регулярный контроль журнала обмена.
Что важно запомнить
План обмена задаёт, какие данные и между какими базами синхронизируются. Платформа регистрирует изменения по узлам и передаёт только их. Периферийную базу создают начальным образом, префиксы у баз делают разными, а перед исправлением номеров сообщений обязательно делают копии.
Частые вопросы
Чем план обмена отличается от обработки выгрузки-загрузки?
Обработка переносит данные разово и «в лоб»: выгрузил файл, загрузил в другую базу. План обмена — постоянно действующий механизм: он сам отслеживает изменения, ведёт учёт переданных сообщений и передаёт только новое. Для разовой миграции хватит обработки, для регулярной синхронизации нужен план обмена.
Можно ли добавить свой документ в план обмена?
Да, но только через конфигуратор: объект включается в состав плана обмена разработчиком, после чего требуется обновление конфигурации базы. В РИБ состав должен совпадать во всех узлах, поэтому изменение делается в центральном узле и распространяется на подчинённые.
Почему документ виден в базе-источнике, но не приходит в базу-приёмник?
Проверьте по цепочке: входит ли тип документа в состав плана обмена, проходит ли он отборы настройки синхронизации (дата, организация), зарегистрирован ли он для узла и нет ли ошибки в журнале обмена. Чаще всего причина — отборы или ошибка загрузки из-за незаполненного обязательного реквизита в приёмнике.
Что делать, если базу восстановили из старой копии и обмен встал?
Сначала зафиксируйте ситуацию: не запускайте обмен и сделайте копию текущего состояния. Затем сравните номера отправленных и принятых сообщений в обеих базах. Обычно требуется либо скорректировать номера у узла, либо повторно зарегистрировать изменения за период после даты копии и выполнить выгрузку заново.
Подходит ли план обмена для работы нескольких офисов в реальном времени?
Нет. Обмен работает пакетами с задержкой — от минут до часов в зависимости от расписания. Если офисам нужно видеть общие остатки и документы мгновенно, правильнее развернуть единую базу с доступом через тонкий клиент, веб-клиент или терминальный доступ.
Можно ли настроить обмен без программиста?
Типовые сценарии — да: синхронизация УТ–БП, ЗУП–БП, обмен с сайтом настраиваются мастерами в пользовательском режиме. Нестандартные требования — свои отборы, новые объекты, доработка правил конвертации — уже требуют участия разработчика или опытного консультанта.