Как решить проблему рассинхронизации идентификаторов пользователей при обмене в РИБ?

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

Техническая природа проблемы

Для начала проанализируем ситуацию и выясним причину конфликта. В платформе «1С:Предприятие 8» сущность «Пользователь» разделена на две составляющие:

1. Объект метаданных (Справочник Пользователи) — это обычная запись в таблице базы данных, которая содержит ФИО, подразделение и другие реквизиты. Этот объект успешно мигрирует между узлами РИБ.
2. Пользователь информационной базы (ИБ) — это системная учетная запись, хранящаяся на уровне платформы (в файле v8users.lst или в системных таблицах SQL-базы). Эти записи по умолчанию не переносятся через механизмы РИБ.

Связующим звеном между ними выступает реквизит ИдентификаторПользователяИБ (тип УникальныйИдентификатор). Когда мы выполняем выгрузку из центрального узла в периферийный, XML-файл содержит GUID пользователя центральной базы. При загрузке в периферийном узле этот GUID записывается в справочник, но в списке пользователей ИБ этой базы такого идентификатора нет. В итоге связь разрывается.

Способ 1. Программная блокировка перезаписи (рекомендуемый)

Самый эффективный и простой метод решения — это модификация логики записи справочника Пользователи. Мы должны сказать системе: «Если данные пришли по обмену, не трогай идентификатор пользователя». Рассмотрим, как это реализовать в модуле объекта справочника Пользователи.

Нам необходимо перехватить событие ПередЗаписью. Проанализируем пример кода:

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

Разберем по шагам, что делает этот код. Сначала мы проверяем свойство ОбменДанными.Загрузка. Это критически важно: если оно равно Истина, значит, объект загружается из XML-пакета обмена. Далее мы проверяем, не является ли элемент новым. Если элемент уже существовал в базе, мы берем его старое значение ИдентификаторПользователяИБ через обращение к Ссылка и принудительно устанавливаем его обратно в записываемый объект. Таким образом, GUID пользователя в локальной базе остается неизменным, и связь с системной учетной записью не теряется.

Способ 2. Настройка правил обмена (Конвертация данных)

Если в вашей конфигурации (например, в УПП или самописной базе) используются правила конвертации данных (КД 2.0), можно решить проблему на уровне проектирования обмена. Посмотрим на алгоритм настройки:

1. Откройте правила обмена в конфигурации «Конвертация данных».
2. Найдите ПКС (Правило конвертации свойства) для реквизита ИдентификаторПользователяИБ справочника Пользователи.
3. В обработчике «Перед выгрузкой» для этого свойства можно прописать Отказ = Истина;. В этом случае идентификатор вообще не попадет в файл обмена.
4. В качестве полей поиска (синхронизации) используйте Наименование или Код, но ни в коем случае не GUID пользователя ИБ.

Этот метод хорош тем, что не требует внесения изменений в сам код конфигурации, если вы используете внешние правила обмена.

Особенности использования Windows-аутентификации

Проанализируем ситуацию с доменными пользователями. Если в вашей организации используется авторизация через Active Directory, проблема рассинхронизации становится еще более острой. Когда ИдентификаторПользователяИБ затирается, 1С перестает понимать, что вошедший под доменным именем сотрудник DOMAIN\Ivanov — это тот самый «Иванов Иван» из справочника.

В этом случае при входе пользователя система может:

• Выдать ошибку доступа.
• Создать «пустую» запись пользователя без прав.
• Перестать применять настройки RLS (разграничение прав на уровне записей), так как система не может определить принадлежность пользователя к группам доступа.

Важный совет: При использовании РИБ старайтесь создавать пользователей в центральном узле, а в периферийных базах выполнять только их сопоставление или использовать автоматизированные скрипты создания пользователей ИБ на основе данных справочника сразу после загрузки обмена.

Использование Библиотеки стандартных подсистем (БСП)

В современных конфигурациях (ERP, КА 2.5, УТ 11) механизмы БСП уже содержат встроенную защиту от подобных проблем. Разберем, как это работает в типовых решениях. Подсистема «Пользователи» при обмене данными через РИБ использует регистр сведений Сведения о пользователях.

Если вы столкнулись с проблемой в типовой конфигурации, проверьте:

• Выполняется ли регламентное задание по обновлению пользователей ИБ.
• Корректно ли заполнены сопоставления в регистре.
• Не вносились ли изменения в типовой план обмена, которые могли бы принудительно включить выгрузку системных идентификаторов.

Резюме

Подведем итог. Чтобы пользователи не «терялись» после обмена в РИБ, необходимо обеспечить неизменность реквизита ИдентификаторПользователяИБ в каждой локальной базе. Самым надежным способом является вставка программной проверки в событие ПередЗаписью модуля справочника Пользователи. Это гарантирует сохранение связи между справочником и системными таблицами платформы, обеспечивая стабильную работу прав доступа и настроек интерфейса для сотрудников во всех узлах распределенной системы.