Настройка распределенной информационной базы (РИБ) в крупных конфигурациях, таких как 1С:ERP Управление предприятием 2.4, часто сопряжена с необходимостью разделения данных. Типовой функционал ERP, в отличие от «1С:Бухгалтерии» или «1С:Зарплаты и управления персоналом», не всегда предоставляет «коробочное» решение для обмена с фильтрацией по конкретной организации. В этой статье мы подробно разберем, как реализовать механизм разделения баз по юридическим лицам, как избежать критической ошибки дублирования предопределенных данных и какие нюансы платформы 1С:Предприятие 8.3 следует учитывать.
Рассмотрим ситуацию, с которой часто сталкиваются разработчики: при создании нового подчиненного узла используется метод выгрузки и загрузки cf-файла (конфигурации) в пустую базу. Разберем, почему этот путь ведет к проблемам. Когда мы запускаем пустую базу с загруженной конфигурацией ERP, платформа автоматически инициирует процесс заполнения предопределенных данных и идентификаторов объектов метаданных. В результате в новой базе создаются элементы с собственными уникальными идентификаторами (UUID), которые не совпадают с идентификаторами в главной базе.
При первой же попытке обмена система попытается сопоставить эти данные. Поскольку UUID различаются, механизмы платформы воспримут их как разные объекты, что приведет к появлению «двойников» справочников, предопределенных элементов и настроек. Это критично для ERP, так как на этих данных завязаны алгоритмы закрытия месяца, партионного учета и формирования отчетности.
Проанализируем самый гибкий программный способ фильтрации данных — использование обработчика события ПриОтправкеДанныхПодчиненному в модуле плана обмена. Этот метод позволяет на лету решать, какие объекты должны уйти в конкретный узел, а какие — нет. Выясним, как это реализовать технически.
Для начала нам необходимо определить логику фильтрации. В плане обмена следует добавить реквизит (или использовать настройки), который будет указывать на принадлежность узла к определенной организации. В коде обработчика мы будем проверять тип отправляемого объекта и наличие у него реквизита Организация.
Пример программной логики:
Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
// Проверяем, что элемент является документом или справочником с реквизитом Организация
МетаданныеОбъекта = ЭлементДанных.Метаданные();
Если Метаданные.Документы.Содержит(МетаданныеОбъекта) Тогда
// Если у документа есть реквизит Организация, проверяем его
Если ОбщегоНазначения.ЕстьРеквизитОбъекта("Организация", МетаданныеОбъекта) Тогда
Если ЭлементДанных.Организация <> Получатель.ОрганизацияФильтр Тогда
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Важный нюанс: использование только этого обработчика не очищает таблицу регистрации изменений в главной базе. Если мы просто игнорируем отправку, запись о том, что данные «изменились», остается. Со временем это приведет к деградации производительности. Чтобы этого избежать, проанализируем ситуацию глубже: необходимо также использовать подписку на событие ПриЗаписи, где принудительно вызывать ПланыОбмена.УдалитьРегистрациюИзменений() для узлов, которым эти данные не положены по фильтру.
В современных конфигурациях на базе БСП (Библиотека стандартных подсистем), к которым относится и ERP 2.4, существует механизм работы с приоритетными данными. К ним относятся предопределенные элементы и идентификаторы метаданных. Проблема дублей часто кроется именно в них.
Разберем, как БСП управляет этим процессом. В конфигурации существуют процедуры, которые записывают данные в начало или конец сообщения обмена. Если мы хотим избежать передачи определенных системных данных или, наоборот, гарантировать их идентичность, нам нужно обратить внимание на Параметры сеанса ПриоритетныеДанныеОбмена.
Посмотрим на пример кода, который позволяет управлять этим процессом (аналогично механизмам в ЗУП):
// Очистка приоритетных данных перед формированием сообщения
ОбменДаннымиСлужебный.ОчиститьПриоритетныеДанныеОбмена();
// Ручная запись изменений метаданных и предопределенных элементов
ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения, КоличествоЭлементовВТранзакции);
// Если необходимо передать специфические идентификаторы
ЗаписатьПриоритетныеИзмененияВСообщениеОбмена(ЗаписьСообщения);
Для корректной работы РИБ по организациям крайне важно, чтобы справочники-классификаторы (валюты, единицы измерения, страны мира) имели одинаковые UUID во всех узлах. Если создавать базу через cf, этого добиться невозможно без использования специальных обработок по переносу UUID («Выгрузка/загрузка данных XML»).
Вместо того чтобы пытаться «подружить» две разные базы, созданные из одного cf, рассмотрим более надежный, хотя и более трудоемкий метод. Выясним последовательность действий:
ОбменДанными.Загрузка = Истина), чтобы информация об удалении не улетела обратно в главную базу и не стерла данные там.ПриОтправкеДанныхПодчиненному или расширения), чтобы в дальнейшем в этот узел попадали только нужные данные.Такой подход исключает появление дублей предопределенных данных, так как база-приемник является физической копией части базы-источника на момент создания.
Подведем итог нашему анализу. Настройка РИБ в ERP 2.4 с фильтрацией — это задача, требующая понимания механизмов БСП и платформенного обмена. Использование cf-файла для создания узла — это путь к дублированию данных. Наилучшим решением будет либо использование ПриОтправкеДанныхПодчиненному с тщательным контролем регистрации изменений, либо создание полного образа с последующей программной очисткой «чужих» организаций.
Помните, что в ERP 2.4 разделение по организациям официально не поддерживается во всех типах обмена «из коробки», поэтому любые доработки в этой области должны сопровождаться тщательным тестированием процесса закрытия месяца в подчиненном узле, так как отсутствие некоторых «общих» данных (например, настроек распределения затрат) может сделать работу в базе невозможной.