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