Администрирование · 11 мин
Как создать РИБ в 1С: полная инструкция по настройке
Пошаговая инструкция по созданию РИБ в 1С: настройка плана обмена, создание узлов, начальный образ, обмен данными, типичные ошибки и проверка результата.
РИБ (распределённая информационная база) — механизм платформы 1С:Предприятие, который позволяет вести учёт в нескольких территориально разнесённых базах и автоматически обмениваться данными между ними. Классический сценарий: центральная база в головном офисе и периферийные базы в филиалах, магазинах или на складах, где нет стабильного канала связи.
Создание РИБ сводится к четырём шагам: включить план обмена, создать узлы, сформировать начальный образ периферийной базы и настроить регулярный обмен. Вся работа выполняется штатными средствами конфигуратора и режима «Предприятие», без доработки кода.
Перед началом убедитесь, что конфигурация поддерживает РИБ: в типовых решениях (Управление торговлей, Розница, Бухгалтерия предприятия и др.) план обмена «Полный» или «По организации» уже включён в состав. Если плана обмена в конфигурации нет, его придётся разрабатывать самостоятельно — это уже задача уровня разработчика.
Что такое РИБ и когда он действительно нужен
Распределённая информационная база — это система из двух и более одинаковых по конфигурации баз, связанных иерархией узлов обмена. Главный узел (центральная база) хранит полные данные, периферийные узлы работают автономно и периодически синхронизируются с центром. Изменения передаются пакетами сообщений обмена в формате XML.
РИБ оправдан в трёх ситуациях: филиалы работают без постоянного интернет-канала, нужна автономность касс и складов при отключении связи, требуется снизить нагрузку на центральный сервер. Если у филиалов стабильный канал связи, проще и дешевле использовать тонкий клиент или веб-доступ к единой базе — обслуживание РИБ требует заметно больше усилий.
Подготовка: что проверить перед созданием узлов
Первое требование — конфигурация не должна быть на полной поддержке с запретом изменений, если план обмена нужно дорабатывать. Для типового сценария с готовым планом обмена изменения не потребуются, но базу всё равно придётся переводить в режим «РИБ» через создание образа, поэтому проверьте, что у вас есть полные права администратора.
Второе — версии платформы на всех рабочих местах должны быть совместимы. Конфигурации центральной и периферийной баз обязаны полностью совпадать: после обновления конфигурации в центре периферийная база получит обновление через обмен, но до момента синхронизации версий обмен может блокироваться.
Третье — сделайте резервную копию центральной базы. Создание начального образа и первые обмены — операции, где ошибка в настройке состава узла может привести к рассылке лишних или неполных данных, и откатить это проще всего из копии.
Шаг 1. Создание узлов плана обмена
Откройте центральную базу в режиме «Предприятие» и перейдите в раздел настройки синхронизации данных (в типовых конфигурациях: «Администрирование» → «Синхронизация данных»). Включите флаг «Синхронизация данных» и задайте префикс центральной базы, например «ЦБ» — префиксы нужны, чтобы номера документов разных узлов не пересекались.
В списке планов обмена откройте нужный план (например, «Полный»). Первый узел — «Этот узел», он уже создан и соответствует центральной базе. Задайте ему понятный код и наименование. Затем создайте новый узел для периферийной базы: укажите код (например, «Ф1»), наименование филиала и, если план обмена поддерживает, настройте отбор по организациям и дату начала выгрузки документов.
Отбор по организациям важен для планов «По организации»: периферийная база получит только документы своего филиала, а не весь массив данных центра. Это снижает объём обмена и защищает данные других подразделений.
- 1Откройте «Администрирование» → «Синхронизация данных» и включите обмен
- 2Задайте префикс центральной базы
- 3Откройте план обмена, заполните данные центрального узла
- 4Создайте новый узел для филиала с уникальным кодом
- 5Настройте отбор по организациям и дату начала выгрузки
- 6Сохраните узел и проверьте, что он появился в списке
Шаг 2. Создание начального образа периферийной базы
Начальный образ — это копия центральной базы, из которой удалены данные, не относящиеся к периферийному узлу, и которая уже настроена на связь с центром. Создаётся он из центральной базы: в списке узлов плана обмена выделите периферийный узел и нажмите «Создать начальный образ».
Система предложит выбрать тип расположения образа: на этом компьютере, на компьютере в локальной сети или на сервере 1С:Предприятия. Для файлового варианта укажите каталог — в нём будет создана новая информационная база. Процесс может занять продолжительное время на больших базах, пользователям центральной базы в этот момент лучше не работать с изменением данных.
После создания образа перенесите базу на компьютер филиала (если она создавалась в центре), подключите её в списке баз и запустите. Периферийная база уже «знает» своего центрального узла и готова к первому обмену.
Шаг 3. Настройка транспорта и выполнение обмена
Обмен между узлами выполняется через сообщения — XML-файлы вида Message_ЦБ_Ф1.xml. Способ доставки файлов выбирается в настройках узла: локальный или сетевой каталог, FTP-ресурс, электронная почта (в типовых — через настройки транспорта) либо прямое подключение к базе-корреспонденту.
Самый простой вариант для старта — общий сетевой каталог, доступный обеим базам. Для филиалов без VPN удобен FTP. В настройках узла укажите путь и проверьте подключение кнопкой «Проверить». Обмен запускается командой «Выполнить обмен данными» либо автоматически по расписанию через регламентное задание.
Порядок первого обмена важен: сначала центральная база записывает сообщение для периферийной (выгрузка), затем периферийная база загружает его и отправляет ответное подтверждение. Пока подтверждение не получено, центр будет считать сообщение недоставленным и отправлять его повторно — это нормальный механизм гарантированной доставки.
Первый обмен после создания образа может быть тяжёлым: в него попадают все изменения, накопленные с момента создания узла. Запускайте его в нерабочее время и следите за размером файла сообщения — файлы в сотни мегабайт по FTP передаются долго и чувствительны к обрывам связи.
Обновление конфигурации и обслуживание РИБ
Ключевое правило эксплуатации: конфигурация обновляется только в центральной базе. Периферийные узлы получают изменения конфигурации вместе с очередным сообщением обмена и применяют их автоматически при загрузке — пользователю филиала будет предложено обновить конфигурацию базы данных.
Регулярно контролируйте монитор обмена: непринятые сообщения, ошибки коллизий и отложенные движения. Коллизия возникает, когда один объект изменён в обоих узлах до обмена — по умолчанию приоритет у центральной базы, и изменения филиала будут перезаписаны. Настройте расписание обмена так, чтобы интервал был короче типичного цикла работы с документом, это снижает число коллизий.
Как проверить результат
Периферийный узел создан, код уникален, отборы заполнены
Узел без кода или с пустым составом выгрузки
Файлы Message_*.xml создаются и удаляются после приёма
Файлы копятся — значит, приём на другой стороне не работает
Нет ошибок, номера отправленных и принятых сообщений совпадают
Растёт номер отправленного при неизменном принятом — обмен застопорился
Новый документ из центра появился после обмена, префиксы корректны
Документы дублируются или не приходят вообще
Типичные ошибки при создании и работе РИБ
Самая частая ошибка — попытка подключить к РИБ обычную копию базы вместо начального образа. Копия, сделанная через конфигуратор или файловое копирование, не содержит связи с узлом обмена, и обмен с ней работать не будет. Только штатное создание образа из плана обмена.
Вторая группа ошибок — одинаковые префиксы узлов и работа под одним узлом из разных баз. Если две периферийные базы получили один код узла, номера документов начнут конфликтовать, а сообщения будут приниматься не той базой. Каждый узел должен иметь уникальный код и использоваться строго одной базой.
Третья проблема — обновление конфигурации напрямую в периферийной базе через конфигуратор. Это разрывает механизм РИБ: платформа фиксирует несоответствие и блокирует обмен. Восстановление потребует либо отката, либо повторного создания образа с потерей несинхронизированных данных филиала.
Альтернативы РИБ: когда выбрать другой вариант
РИБ — не единственный способ организовать работу филиалов. Если связь стабильна, единая клиент-серверная база с доступом через тонкий клиент или веб-сервер проще в обслуживании: нет обменов, коллизий и задержек данных. Для обмена между разными конфигурациями (например, УТ и БП) вместо РИБ используется универсальный формат EnterpriseData и механизм синхронизации данных.
Сравнение вариантов
Подходит для филиалов без стабильной связи и для автономной работы. Ограничение: одинаковая конфигурация во всех узлах и заметные затраты на сопровождение.
Подходит при стабильном канале связи. Данные всегда актуальны, обслуживание минимально. Ограничение: при обрыве связи филиал не работает.
Подходит для обмена между разными конфигурациями. Ограничение: это не репликация, а передача выбранных данных по правилам.
Частые вопросы о создании РИБ в 1С
Сколько периферийных узлов можно создать в РИБ?
Жёсткого ограничения платформы на число узлов нет, на практике РИБ работает с десятками баз. Реальные ограничения — рост времени обмена, объёма сообщений и сложности сопровождения. При большом числе филиалов заранее продумайте расписание обменов и мониторинг.
Можно ли превратить периферийную базу в самостоятельную?
Да. В периферийной базе нужно выполнить сброс главного узла: в типовых конфигурациях это делается через обработку или команду установки главного узла с пустым значением. После этого база становится обычной автономной базой, но обратно включить её в РИБ можно только через новый начальный образ.
Почему периферийная база не принимает сообщения обмена?
Чаще всего причины: неверный путь к каталогу обмена, отсутствие прав на запись в каталог, обновление конфигурации, которое сначала нужно применить, либо рассинхронизация номеров сообщений после восстановления базы из копии. Начните проверку с монитора обмена и журнала регистрации.
Что делать, если в обоих узлах изменили один документ?
Возникнет коллизия, и по умолчанию выиграет версия центральной базы. Изменения филиала будут заменены. Чтобы минимизировать такие ситуации, разграничьте зоны ответственности: филиал работает со своими документами, центр — со справочниками и общими данными, и сократите интервал между обменами.
Нужен ли отдельный сервер для периферийной базы?
Нет, периферийная база может работать в файловом варианте на обычном компьютере филиала. Клиент-серверный вариант имеет смысл при большом числе пользователей в самом филиале, но для механизма РИБ тип развёртывания значения не имеет.
Можно ли настроить автоматический обмен по расписанию?
Да, в типовых конфигурациях для каждого узла задаётся расписание, и обмен выполняется регламентным заданием без участия пользователя. В файловом варианте базы регламентные задания выполняются только при запущенном сеансе, поэтому для автономности настраивают отдельный сеанс или внешнюю обработку запуска.
Что важно запомнить
РИБ создаётся в четыре шага: включить план обмена, создать узлы с уникальными кодами, сформировать начальный образ из центральной базы и настроить транспорт сообщений. Конфигурация обновляется только в центре, резервная копия перед настройкой обязательна, а контроль обмена ведётся через монитор синхронизации.