Как организовать учет и слияние данных в распределенной базе 1С при межфилиальном обмене?

← На главную

При организации распределенного учета между головной компанией и филиалами нередко возникает коллизия: филиал-получатель регистрирует поступившую технику самостоятельно, создавая новый элемент справочника. В результате после завершения обмена в головной базе образуются две одинаковые физические единицы с разными внутренними идентификаторами (GUID). Рассмотрим причины возникновения этой проблемы и разберем проверенные архитектурные и программные методы ее решения.

Проанализируем природу проблемы и ограничения платформенного РИБ

В стандартном механизме распределенных информационных баз (РИБ) синхронизация объектов ссылочного типа осуществляется строго по внутреннему уникальному идентификатору УникальныйИдентификатор. Платформа 1С при получении пакета обмена не проводит сопоставление по реквизитам (заводской номер, наименование, артикул). Если филиал №1 и филиал №2 независимо друг от друга ввели элемент с одинаковым заводским номером, для платформы это два абсолютно разных объекта.

Автоматического «слияния» на уровне ядра СУБД в РИБ не предусмотрено. Попытка решать задачу постфактум приводит к усложнению логики и необходимости постоянного ручного или программного поиска дублей. Поэтому правильное решение лежит в плоскости проектирования архитектуры учета и обмена.

Способ 1. Централизация ввода нормативно-справочной информации (НСИ)

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

Вся номенклатура и карточки основных средств создаются исключительно в головном узле информационной базы.
В периферийных базах накладывается программное ограничение на добавление новых элементов справочников. Для этого используем проверку в подписке на событие ПередЗаписью или проверку прав доступа.

Посмотрим на пример кода подписки на событие перед записью элемента справочника в периферийной базе:


Процедура ЗапретСозданияНСИВПериферииПередЗаписью(Источник, Отказ) Экспорт
    
    // Проверяем, является ли текущий узел подчиненным
    Если ЗначениеЗаполнено(ПланыОбмена.ГлавныйУзел()) И Источник.ЭтоНовый() Тогда
        // Запрещаем интерактивное создание новых элементов в филиале
        ВызватьИсключение "Создание новых позиций техники разрешено только в центральной базе!";
    КонецЕсли;
    
КонецПроцедуры

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

Способ 2. Использование механизма межфилиальных авизо

Если филиалу-получателю необходимо принимать технику, которой ранее не было в его узле, применим схему с документами «Авизо исходящее» и «Авизо входящее»:

Филиал-отправитель оформляет документ «Авизо исходящее», в котором указывает передаваемый объект, его заводской номер, пробег, историю ТО и прочие эксплуатационные характеристики.
В процессе обмена через центральный узел пакет данных (документ вместе с привязанной аналитикой и объектом учета) транслируется по правилам адресации в базу филиала-получателя.
Филиал-получатель не создает элемент вручную, а регистрирует документ «Авизо входящее», созданный на основании входящего пакета. Объект справочника регистрируется с тем же самым GUID, с которым он существовал в узле-отправителе.

Способ 3. Разделение сущностей на общую номенклатуру и экземпляры (серии)

Часто ошибкой является попытка хранить каждую единицу техники как отдельный элемент справочника Номенклатура. Разберем правильную модель учета:

В справочнике Номенклатура ведется обобщенная позиция (например, «Трактор К-700»), которая заводится один раз в центре и присутствует во всех филиалах.
Учет конкретных заводских номеров, номеров двигателя и эксплуатационных параметров выносится в подчиненный справочник СерииНоменклатуры или ОсновныеСредства.
Распоряжение головной организации формируется на общую номенклатуру. Филиал-отправитель при оформлении расхода указывает конкретную серию/экземпляр. При синхронизации переносится документ расхода вместе со ссылкой на существующую серию.

Способ 4. Переход с платформенного РИБ на обмен по правилам конвертации (КД / EnterpriseData)

Если специфика бизнеса требует автономного ввода данных в узлах, стандартный РИБ заменяют на обмен по правилам конвертации данных (КД 2.0 / КД 3.0 / EnterpriseData). В этом случае сопоставление объектов выполняется не по GUID, а по полям поиска:

В правилах конвертации объектов (ПКО) отключаем флаг поиска только по внутреннему идентификатору.
Настраиваем поля поиска: например, реквизиты ВидТехники и ЗаводскойНомер (или VIN).
При получении данных из филиала база-приемник сначала выполняет поиск существующей техники по указанным реквизитам. Если совпадение найдено, документ привязывается к существующей ссылке, и дубликат не создается.

Способ 5. Программное объединение дублей в центральной базе

Если коллизия уже произошла, и в центральной базе зафиксированы два элемента с разными GUID, выполним объединение дублирующихся ссылок средствами подсистемы БСП «Поиск и удаление дублей» или программным методом замены ссылок.

Рассмотрим пример программной замены ссылок:


Процедура ЗаменитьДубльТехники(СсылкаДубль, СсылкаЭталон) Экспорт
    
    ТаблицаЗамены = Новый ТаблицаЗначений;
    ТаблицаЗамены.Колонки.Добавить("Ссылка", Новый ОписаниеТипов("СправочникСсылка.Техника"));
    ТаблицаЗамены.Колонки.Добавить("СсылкаЭталон", Новый ОписаниеТипов("СправочникСсылка.Техника"));
    
    СтрокаЗамены = ТаблицаЗамены.Добавить();
    СтрокаЗамены.Ссылка = СсылкаДубль;
    СтрокаЗамены.СсылкаЭталон = СсылкаЭталон;
    
    // Используем типовой механизм БСП для замены ссылок во всех документах и регистрах
    ПараметрыЗамены = ПодсистемыБСП.ПоискИУдалениеДублей.ПараметрыЗаменыСсылок();
    ПодсистемыБСП.ПоискИУдалениеДублей.ЗаменитьСсылки(ТаблицаЗамены, ПараметрыЗамены);
    
    // Помечаем дубликат на удаление
    ОбъектДубль = СсылкаДубль.ПолучитьОбъект();
    ОбъектДубль.УстановитьПометкуУдаления(Истина);
    
КонецПроцедуры

После выполнения процедуры замены и проведения документов изменения регистрируются к выгрузке в планы обмена и транслируются в филиалы, исправляя некорректные ссылки во всей распределенной сети.

Способ 6. Онлайн-проверка и получение GUID через Web/HTTP-сервисы

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

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


// Создание объекта в филиале с идентификатором центральной базы
ИдентификаторИзЦентра = Новый УникальныйИдентификатор(СтрокаGUIDИзЦентра);
НоваяСсылка = Справочники.Техника.ПолучитьСсылку(ИдентификаторИзЦентра);

НовыйОбъект = Справочники.Техника.СоздатьЭлемент();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
НовыйОбъект.Наименование = "Трактор К-700";
НовыйОбъект.ЗаводскойНомер = "888";
НовыйОбъект.Записать();

Такой подход гарантирует консистентность ссылочной целостности во всех узлах еще до момента начала регулярного обмена сообщениями РИБ.