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