При настройке распределенных информационных баз (РИБ) в конфигурации 1С:Бухгалтерия предприятия 3.0 пользователи часто сталкиваются с существенным ограничением: стандартный функционал позволяет настроить миграцию данных только в разрезе Организаций. Если же ваша бизнес-логика требует выделения отдельной базы для конкретного подразделения или склада в рамках одного юридического лица, типовых настроек «из коробки» оказывается недостаточно. Рассмотрим подробнее, какими способами можно реализовать отборы по подразделениям и складам, проанализируем риски и выберем оптимальную стратегию реализации.
Одним из наиболее часто предлагаемых решений является сочетание стандартного РИБ «По организации» и механизма RLS (Record Level Security). Этот метод позволяет ограничить видимость данных для пользователей в подчиненном узле, не прибегая к глубокой модификации правил обмена.
Разберем ситуацию: если в базе ведется учет по одной организации, но данные должны быть разделены между точками, мы настраиваем полный РИБ, а на стороне подчиненного узла включаем Ограничение доступа на уровне записей. В профилях групп доступа указываются конкретные подразделения или склады, к которым разрешен доступ.
Важные нюансы использования RLS:
Если нам необходимо, чтобы лишние данные физически не попадали в подчиненный узел (для экономии места и трафика), придется использовать «напильник», но в современном его исполнении — через расширение конфигурации. Это позволит сохранить базу на поддержке и обеспечит легкость обновлений.
Проанализируем механизм работы РИБ. В планах обмена существуют обработчики событий, которые позволяют управлять составом выгружаемых данных. Основной интерес представляет процедура ПриОтправкеДанныхПодчиненному в модуле плана обмена.
Рассмотрим пример логики, которую можно внедрить через расширение:
&После("ПриОтправкеДанныхПодчиненному")
Процедура Расш1_ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
// Проверяем, что это документ, имеющий реквизит Подразделение
Если Метаданные.Документы.Содержит(ЭлементДанных.Метаданные()) Тогда
// Попытаемся получить значение подразделения из объекта
ПодразделениеОбъекта = Неопределено;
Попытка
ПодразделениеОбъекта = ЭлементДанных.Подразделение;
Исключение
// У документа может не быть такого реквизита
КонецПопытки;
// Если подразделение не соответствует заданному для этого узла - отменяем отправку
Если ЗначениеЗаполнено(ПодразделениеОбъекта) И ПодразделениеОбъекта <> ПараметрыСеанса.ТекущийУзелПодразделение Тогда
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Используя данный подход, мы предотвращаем миграцию документов, не относящихся к целевому подразделению. Однако здесь кроется серьезная ловушка — нарушение ссылочной целостности. Если в разрешенном документе есть ссылка на объект (например, на другой документ-основание), который был отфильтрован, в подчиненной базе появится «битая ссылка».
Вместо классического РИБ (который по сути является репликацией на уровне платформы) в 1С:Бухгалтерии 3.0 можно использовать механизм Синхронизации данных. Этот механизм работает через Библиотеку Стандартных Подсистем (БСП) и использует формат EnterpriseData.
Выясним преимущества этого способа:
Для реализации отбора по подразделению в этом режиме, при настройке обмена нужно выбрать вариант «Синхронизация данных через универсальный формат» и в правилах отправки данных указать необходимые фильтры. В типовых сценариях БП 3.0 это зачастую требует минимальных доработок в расширении (через переопределение макета правил обмена), что гораздо безопаснее изменения логики миграции РИБ.
Разберем ситуацию, которая часто становится камнем преткновения при создании кастомных отборов. Допустим, мы настроили фильтр по Складу А. Документ «Перемещение товаров» со Склада Б на Склад А должен попасть в базу? А документ «Поступление товаров», где указано несколько складов в табличной части?
Основные проблемы, которые нужно решить при настройке отборов:
ВыгрузкаЗагрузкаДанныхXML с установленными фильтрами.Проанализировав ситуацию, можно сделать следующие выводы:
Если бюджет на разработку ограничен и база небольшая, стоит попробовать Метод 1 (RLS). Это самый безопасный путь с точки зрения целостности данных. Включите Производительный режим RLS и проверьте скорость работы на копии базы.
Если же критично ограничить объем передаваемых данных из-за нестабильного интернета, оптимальным будет Метод 3 (Синхронизация через EnterpriseData). Он современнее, гибче и лучше приспособлен для работы в условиях «плохой связи» по сравнению с классическим РИБ.
К Методу 2 (программный РИБ) стоит прибегать только в том случае, если вы опытный разработчик и готовы детально прописывать условия регистрации для каждого типа метаданных, чтобы не допустить появления пустых ссылок в базе приемнике.