1С РИБ: как работает распределённая информационная база

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

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

Обмен в РИБ построен на механизме планов обмена и регистрации изменений. Каждый узел фиксирует, какие объекты изменились с момента последней выгрузки, формирует файл сообщения обмена (обычно XML), а при загрузке применяет изменения и подтверждает их квитанцией. Ниже разберём, как это устроено на практике, как настроить обмен и что делать при сбоях.

Из чего состоит РИБ и как устроена топология

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

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

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

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

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

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

Регистрация изменений — ключевой механизм. Каждый раз, когда пользователь записывает документ или элемент справочника, платформа отмечает этот объект в таблицах регистрации для всех узлов, куда он должен быть отправлен. Если регистрация разрослась (например, узел долго не обменивался), размер файла сообщения увеличивается, а обмен замедляется.

Настройка РИБ: пошаговый порядок

Настройка начинается в центральной базе. Сначала проверяют, что в конфигурации есть план обмена с признаком РИБ (в типовых конфигурациях он обычно называется «Полный» или «По организации»). Затем создают элемент плана обмена для нового подчинённого узла, задают ему код и наименование.

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

1. 1
   В центральной базе откройте план обмена РИБ и создайте новый узел с уникальным кодом
2. 2
   Настройте состав выгружаемых данных и отборы, если они предусмотрены конфигурацией
3. 3
   Создайте начальный образ подчинённого узла (стандартная обработка или командой плана обмена)
4. 4
   Разверните образ на рабочем месте филиала и укажите каталог обмена
5. 5
   Выполните первую выгрузку из центрального узла и загрузку в подчинённом
6. 6
   Проверьте, что квитанция вернулась в центральный узел и регистрация изменений очистилась

Если филиалов много, каждый образ создаётся отдельно, и на каждом узле настраивается собственный сценарий обмена. В типовых конфигурациях для этого используют «Синхронизацию данных» с настройкой расписания через регламентные задания.

Коллизии и ограничения РИБ

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

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

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

Контроль работоспособности обмена

Стабильность РИБ определяется регулярным мониторингом. Минимальный набор проверок: дата и номер последнего отправленного и принятого сообщения по каждому узлу, размер регистрации изменений, наличие незагруженных файлов в каталоге обмена, ошибки в журнале регистрации.

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

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

Как проверить, что обмен работает

Номера сообщений в настройках узла

Норма

Номер отправленного сообщения растёт, принятый подтверждён квитанцией

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

Отправленное сообщение давно не подтверждено — файл не дошёл или не загружен

Регистрация изменений по узлу

Норма

После обмена количество зарегистрированных объектов близко к нулю

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

Регистрация постоянно растёт — данные не уходят или квитанции не приходят

Журнал регистрации

Норма

Нет ошибок выгрузки и загрузки данных

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

Ошибки записи объектов, конфликты блокировок, нехватка места в каталоге обмена

Сверка данных

Норма

Обороты и остатки в узлах сходятся после обмена

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

Расхождения в документах — есть незагруженные сообщения или коллизии

Когда РИБ подходит, а когда лучше выбрать другое решение

РИБ оправдан, когда филиалы работают автономно, связь нестабильна, а данные нужно собирать в центре. Это типичная ситуация для розничных сетей, складов, удалённых офисов. Механизм встроен в платформу, не требует дополнительных лицензий и работает даже при передаче файлов на флеш-накопителе.

Если же связь между площадками стабильная и быстрая, часто проще развернуть единую клиент-серверную базу с тонкими или веб-клиентами — это снимает проблемы коллизий, задержек синхронизации и администрирования множества баз. Для интеграции с разнородными системами (сайт, CRM, WMS) РИБ не подходит: там используют нераспределённые планы обмена, веб-сервисы или шину данных.

РИБ и альтернативы

РИБ

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

Единая клиент-серверная база

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

Нераспределённые планы обмена

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

FAQ

Можно ли обмениваться между подчинёнными узлами напрямую?

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

Что делать, если файл обмена потерялся или повредился?

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

Почему в подчинённом узле нельзя изменить конфигурацию?

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

Как избежать дублирования номеров документов в разных узлах?

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

Как часто нужно выполнять обмен?

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

Можно ли превратить обычную базу в подчинённый узел РИБ?

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