Планы обмена в 1С: что это такое и как они работают

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

Без планов обмена типичная ситуация выглядит так: менеджер создаёт реализацию в торговой базе, а бухгалтер вручную повторяет тот же документ в бухгалтерской программе. Это двойная работа, расхождения в данных и ошибки. План обмена решает задачу: документ вводится один раз, а затем автоматически «приезжает» в связанную базу по заданным правилам.

Механизм планов обмена встроен в платформу 1С:Предприятие 8 и не требует отдельной покупки. Однако правильная настройка требует понимания логики регистрации изменений, состава обмена и способов транспорта данных — файлы, веб-сервисы, прямое подключение. Ниже разберём устройство механизма, типовые сценарии, порядок настройки и способы контроля.

Как устроен план обмена: узлы, состав и регистрация изменений

Ключевое понятие плана обмена — узел. Каждая база, участвующая в обмене, представлена в плане отдельным узлом. Одна база считается главной (или центральной), остальные — подчинёнными, либо обмен идёт между равноправными узлами — это зависит от архитектуры. В каждой базе хранится «свой» узел и узлы-корреспонденты, с которыми она обменивается.

Второй элемент — состав плана обмена. В конфигураторе разработчик указывает, какие объекты метаданных входят в обмен: справочники «Номенклатура» и «Контрагенты», документы «Реализация товаров», регистры сведений и так далее. Объект, не включённый в состав, синхронизироваться не будет — платформа просто не отслеживает его изменения.

Третий механизм — регистрация изменений. Когда пользователь создаёт или изменяет объект, входящий в состав плана обмена, платформа записывает этот факт в специальную служебную таблицу для каждого узла-получателя. При очередном сеансе обмена из этой таблицы формируется сообщение: выгружаются только изменённые данные, а не вся база целиком. После успешной выгрузки и подтверждения приёма регистрация изменений очищается.

Типовые сценарии использования планов обмена

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

Второй сценарий — распределённые информационные базы (РИБ). Здесь используется специальный режим плана обмена, при котором создаётся центральная база и периферийные копии с идентичной конфигурацией. Типичный пример — сеть розничных магазинов: каждая точка работает в своей базе, а в центральную стекаются все продажи, оттуда же рассылаются цены и номенклатура.

Третий сценарий — обмен с сайтом, мобильными приложениями и внешними системами. План обмена фиксирует изменения товаров и цен, а механизм выгрузки передаёт их на сайт в формате CommerceML или через веб-сервисы. Четвёртый вариант — обмен между филиалами холдинга, где каждая организация ведёт учёт в собственной базе, но справочники должны быть едиными.

Чем план обмена отличается от универсального обмена данными

План обмена — это «транспорт и адресная книга»: он определяет, куда и что отправлять, и ведёт учёт изменений. Логику преобразования данных (как документ одной конфигурации превращается в документ другой) задают правила обмена, которые обычно создаются в конфигурации «Конвертация данных». В типовых решениях правила уже встроены, но при доработке конфигураций их часто приходится корректировать.

Как работает сеанс обмена: от выгрузки до подтверждения

Сеанс обмена состоит из двух встречных операций. При выгрузке платформа читает зарегистрированные изменения для конкретного узла, формирует сообщение обмена — XML-файл с уникальным номером — и передаёт его получателю. Способ передачи зависит от настроек: каталог на диске или FTP, прямое подключение к базе-корреспонденту, веб-сервис, электронная почта.

При загрузке база-получатель разбирает сообщение, создаёт или обновляет объекты и записывает номер принятого сообщения. При следующем сеансе отправитель узнаёт, какие сообщения подтверждены, и удаляет соответствующую регистрацию изменений. Это гарантирует, что данные не потеряются: если сообщение не дошло, изменения будут отправлены повторно.

Важно понимать роль номеров сообщений. Если базу-получатель восстановили из старой копии или долго не проводили обмен, номера могут разойтись — тогда потребуется либо повторная регистрация данных, либо сброс номеров сообщений вручную. Это одна из самых частых причин «зависшего» обмена.

1. 1
   Откройте раздел «Синхронизация данных» (в типовых — через «Администрирование») и включите использование синхронизации.
2. 2
   Создайте новую настройку синхронизации, выберите программу-корреспондент и способ подключения.
3. 3
   Задайте префикс базы, правила отправки и получения данных, дату начала использования обмена.
4. 4
   Выполните первоначальную выгрузку данных и загрузите её в базу-корреспондент.
5. 5
   Проверьте сопоставление объектов (контрагентов, номенклатуру) и запустите сеанс синхронизации.
6. 6
   Настройте расписание автоматического обмена или запускайте его вручную по необходимости.

Начальная выгрузка и сопоставление объектов

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

Типовые механизмы синхронизации предлагают автоматическое сопоставление по реквизитам — ИНН и КПП для контрагентов, артикулу и наименованию для номенклатуры. Затем пользователь вручную проверяет предложенные соответствия и доустанавливает связи для оставшихся объектов. Пропускать этот шаг нельзя: исправлять тысячи дублей после запуска обмена гораздо труднее, чем потратить время на сопоставление заранее.

Для РИБ ситуация проще: периферийная база создаётся из образа центральной, поэтому идентификаторы объектов изначально совпадают. Но и здесь важно выполнить первоначальное формирование образа именно через штатный механизм, а не копированием файла базы — иначе связь узлов не установится корректно.

Типичные проблемы и способы их диагностики

Самая частая жалоба — «обмен не работает, данные не приходят». Причины обычно одни и те же: изменения не зарегистрированы (объект не входит в состав плана обмена или отбор по организации отсекает документ), сообщение не дошло до получателя (недоступен каталог обмена, нет прав на запись), либо сообщение пришло, но загрузка завершилась с ошибками — например, в получателе заполнены не все обязательные реквизиты.

Вторая группа проблем — коллизии, когда один и тот же объект изменён в обеих базах до сеанса обмена. Приоритет зависит от настроек: обычно побеждает изменение из главного узла либо более позднее по времени. Третья группа — дубли объектов из-за пропущенного сопоставления или изменения ключевых реквизитов поиска.

Для диагностики используйте штатные инструменты: журнал регистрации (ищите события обмена данными), отчёт о результатах синхронизации, обработку «Регистрация изменений для обмена данными» — она показывает, какие объекты ожидают выгрузки по конкретному узлу, и позволяет вручную зарегистрировать или снять с регистрации нужные данные.

Как контролировать корректность синхронизации

После запуска обмена нужен регулярный контроль, а не разовая проверка. Минимальный набор: сверка количества документов за период в обеих базах, контроль остатков по ключевым регистрам, просмотр предупреждений синхронизации. В типовых конфигурациях есть «Результаты синхронизации данных» — там видны незагруженные объекты и причины ошибок.

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

Контрольные точки

Как проверить результат

Счётчик зарегистрированных изменений по узлу

Норма

После успешного обмена очередь пуста или близка к нулю

Тревожный признак

Очередь растёт от сеанса к сеансу — сообщения не подтверждаются

Количество документов за период в обеих базах

Норма

Количество совпадает с учётом заданных отборов

Тревожный признак

Расхождения при корректных отборах — часть данных теряется

Предупреждения в результатах синхронизации

Норма

Нет незагруженных объектов и ошибок сопоставления

Тревожный признак

Есть объекты с ошибками — требуется разбор причин

Дубли в справочниках-участниках обмена

Норма

Один реальный объект — одна запись

Тревожный признак

Повторяющиеся контрагенты или товары с разными ссылками

Когда план обмена не нужен: альтернативы

План обмена не всегда оптимальное решение. Если базы находятся в одной сети и объём данных невелик, иногда проще вести учёт в одной базе с разграничением прав, чем поддерживать синхронизацию. Для разовой миграции данных достаточно обработки «Выгрузка и загрузка данных XML» или «Универсальный обмен данными» — без постоянного плана обмена.

Для интеграции с внешними системами в реальном времени (CRM, интернет-магазин с мгновенным резервированием) лучше подходят HTTP-сервисы и очереди сообщений: план обмена работает пакетно, по расписанию, и не гарантирует мгновенной доставки. Выбор зависит от требований к скорости, объёму и надёжности канала.

Сравнение вариантов интеграции

Планы обмена (синхронизация)

Подходит для регулярного обмена между базами 1С. Ограничение: пакетный режим, данные передаются по расписанию, а не мгновенно.

Распределённая база (РИБ)

Подходит для филиалов с идентичной конфигурацией. Ограничение: конфигурация меняется только в центральном узле, гибкость ниже.

HTTP/веб-сервисы

Подходит для онлайн-интеграции с внешними системами. Ограничение: требует разработки и постоянной доступности обеих сторон.

Разовая выгрузка/загрузка

Подходит для миграции и переноса исторических данных. Не решает задачу постоянной синхронизации.

Частые вопросы о планах обмена

Можно ли настроить план обмена без программиста?

Типовую синхронизацию между стандартными конфигурациями (например, УТ и БП) обычно настраивает администратор или продвинутый пользователь через мастер настройки — готовые правила уже встроены. Программист нужен, когда конфигурации доработаны, требуются нестандартные отборы или обмен с самописной системой.

Что делать, если обмен остановился после восстановления базы из копии?

Проверьте номера отправленных и принятых сообщений в настройках узла — после отката базы они расходятся. Обычно помогает сброс номеров сообщений и повторная регистрация изменённых данных за нужный период с последующим сеансом обмена.

Удалятся ли документы в базе-получателе, если их удалили в источнике?

По умолчанию удаление объектов передаётся как пометка на удаление, а физическое удаление зависит от настроек правил. Во многих типовых синхронизациях помеченные на удаление объекты передаются, но автоматическое физическое удаление в получателе не выполняется — это защита от потери данных.

Сколько баз можно связать одним планом обмена?

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

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

Чаще всего причина в том, что при первоначальной настройке не выполнено сопоставление объектов, либо изменились реквизиты поиска (например, артикул), по которым система находит соответствия. Дубли нужно объединить штатной обработкой поиска и удаления дублей, а затем проверить настройки сопоставления.

Можно ли обмениваться только частью данных, например одной организацией?

Да. В настройках синхронизации задаются отборы: по организации, подразделению, дате начала выгрузки, видам документов. Объекты, не проходящие отбор, не регистрируются к отправке и в базу-корреспондент не попадают.