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