При работе с распределенными информационными базами (РИБ) в конфигурации «1С:Розница» администраторы и разработчики часто сталкиваются с неприятной ситуацией: после настройки обмена между центральной базой (ЦБ) и периферийной базой (ПБ) документы (например, «Отчет о розничных продажах») приходят в центральный узел без указания ответственного лица. Поле Ответственный (кассир) оказывается пустым или отображает классическое «Объект не найден».
В этой статье мы подробно разберем, почему стандартный механизм РИБ ведет себя именно так, проанализируем разницу между пользователями на уровне платформы и базы данных, а также рассмотрим пошаговые практические варианты решения этой проблемы без изменения типовой конфигурации.
Для того чтобы понять суть проблемы, нам необходимо четко разграничить две сущности в системе «1С», которые часто ошибочно принимают за одно и то же:
Ответственный).Механизм РИБ работает исключительно на уровне таблиц базы данных. Он физически не умеет отслеживать изменения и передавать данные из системного списка «Пользователи ИБ». Когда мы создаем начальный образ подчиненного узла, пользователи ИБ копируются туда один раз. Любые последующие изменения пользователей ИБ (пароли, новые учетные записи) в автоматический обмен РИБ никогда не попадут.
Что касается справочника Пользователи, по умолчанию в типовых правилах обмена БСП (Библиотеки стандартных подсистем) автоматическая регистрация его элементов отключена или сильно ограничена. Это сделано для безопасности и предотвращения конфликтов прав доступа в периферийных узлах.
Согласно официальной документации БСП, элементы справочника Пользователи переносятся в подчиненные узлы без автоматического сопоставления с конкретными пользователями информационной базы. Добавление пользователя в список «Пользователи ИБ» и настройка его прав всегда должны выполняться непосредственно в локальном узле.
Более того, в «1С:Рознице» часто используются ограничения миграции по магазинам. Если кассир привязан к конкретной торговой точке, то при определенных настройках его карточка из справочника может вообще не выгружаться в центральную базу или в другие узлы, что приводит к появлению пустых ссылок в документах.
Рассмотрим подробнее четыре основных способа решения проблемы пустых ответственных в РИБ.
Выясним, включен ли вообще справочник Пользователи в состав используемого плана обмена. Для этого нам понадобится открыть базу в режиме «Конфигуратор» (в центральной базе):
РИБПоМагазинам или Полный).Пользователи.Оптимальным решением является перевод авторегистрации в режим Разрешить (если это допустимо политикой компании) или использование режима Выгружать по необходимости. При режиме «Выгружать по необходимости» элемент справочника Пользователи будет автоматически выгружен вместе с документом, в котором он выбран в качестве ответственного.
Если мы принципиально не хотим снимать конфигурацию с поддержки и вносить изменения в правила обмена, мы можем воспользоваться встроенным в БСП инструментом регистрации изменений. Разберем этот процесс по шагам:
Пользователи. Мы увидим, что зарегистрированных к отправке объектов 0.После выполнения этой процедуры при следующем сеансе обмена все карточки пользователей будут физически переданы в периферийную базу (или наоборот — из ПБ в ЦБ), и ссылки в документах корректно сопоставятся.
Для автоматизации этого процесса на стороне разработчика можно написать простую процедуру, которая будет принудительно регистрировать пользователей при создании узла или по расписанию. Посмотрим на пример кода:
// Пример принудительной регистрации справочника "Пользователи" для узла обмена
Процедура ЗарегистрироватьПользователейДляОбмена(УзелСсылка) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Пользователи.Ссылка КАК Ссылка
|ИЗ
| Справочник.Пользователи КАК Пользователи";
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
ПланыОбмена.ЗарегистрироватьИзменения(УзелСсылка, ВыборкаДетальныеЗаписи.Ссылка);
КонецЦикла;
КонецПроцедуры
Если перед нами стоит задача не просто передавать «карточки» ответственных, а полноценно автоматизировать создание учетных записей для входа в периферийных базах, идеальным решением будет использование расширений конфигурации. Этот механизм не требует снятия базы с поддержки.
Мы можем написать или установить готовое расширение, которое будет перехватывать событие записи справочника Пользователи при его загрузке в периферийную базу через обмен. Расширение будет программно создавать Пользователя ИБ:
// Концептуальный пример обработчика в расширении при загрузке данных в ПБ
&После("ПриЗаписи")
Процедура Расш_ПриЗаписиПользователя(Отказ)
Если ОбменДанными.Загрузка Тогда
// Проверяем, существует ли пользователь ИБ с таким именем
ИмяПользователя = ЭтотОбъект.Наименование;
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени(ИмяПользователя);
Если ПользовательИБ = Неопределено Тогда
// Создаем нового пользователя информационной базы программно
НовыйПользовательИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
НовыйПользовательИБ.Имя = ИмяПользователя;
НовыйПользовательИБ.АутентификацияСтандартная = Истина;
НовыйПользовательИБ.Пароль = "ВременныйПароль123";
// Назначаем базовую роль для работы в рознице
РольКассира = Метаданные.Роли.ПродавецКассир;
НовыйПользовательИБ.Роли.Добавить(РольКассира);
НовыйПользовательИБ.Записать();
// Связываем элемент справочника с созданным пользователем ИБ
ЭтотОбъект.ИдентификаторПользователяИБ = НовыйПользовательИБ.УникальныйИдентификатор;
ЭтотОбъект.Записать();
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Если количество торговых точек и кассиров невелико (например, до 5-10 магазинов), наиболее надежным и бесконфликтным методом для абсолютно типовой конфигурации является строгое соблюдение административного регламента:
Пользователи в Центральной базе.Этот способ исключает риск взаимных блокировок СУБД (Deadlocks) на кассовых узлах, которые иногда возникают при попытке зарегистрировать и перезаписать системные таблицы прав пользователей непосредственно во время активного сеанса обмена данными.