Обмен данными между базами

Гарантии, которые вы получаете при штатном обмене

При использовании встроенного механизма РИБ (распределённой информационной базы) или универсального обмена данными в конфигурациях 1С, платформа гарантирует следующие вещи:

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

Риски, которые остаются и требуют контроля

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

Что проверить перед выбором сценария обмена, чтобы не пожалеть

Выбор между РИБ, обменом через файл, через COM-соединение или веб-сервис — это не вопрос удобства, а вопрос границ гарантий. Перед утверждением архитектуры проверьте следующие точки:

Режим работы с конфликтами. Узнайте у разработчика или из документации: какой узел является «главным» по справочнику Номенклатура? Если приоритет не закреплён — риск перезаписи корректных данных о цене из второстепенного узла.
Алгоритм восстановления после сбоя связи. В штатном обмене нет механизма «отката» частично принятых данных. Если связь оборвалась на середине — нет гарантии, что файлы временных таблиц не останутся на диске. Проверьте: есть ли на вашем узле обработка очистки временных сессий обмена.
Совместимость версий платформы и конфигураций. Обмен между базой на 8.3.10 и 8.3.25 — это не гарантированный сценарий. Разработчики 1С гарантируют корректный обмен только в пределах одной мажорной ветки (например, 8.3) и при одинаковой версии конфигурации с точностью до релиза. Любое несовпадение — риск потери данных при передаче структуры метаданных.
Логирование и мониторинг. Без отдельного журнала событий обмена вы не сможете определить, виноват ли механизм обмена или ошибка оператора. При выборе решения проверьте: ведётся ли запись каждого факта приёма-передачи с указанием контрольных сумм файлов обмена.
Скорость и блокировки. При синхронном обмене через COM-соединение нет гарантии, что приёмник не будет заблокирован длительной транзакцией на стороне отправителя. Это прямой риск паралича работы для всех пользователей. Проверка: настроен ли таймаут ожидания соединения и блокировки таблиц.

Главный критерий для экзамена по 1С: понимание зоны ответственности

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

Добавлено: 24.04.2026