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

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

Использование расширений конфигурации для программной блокировки

Самый прямой способ — использование механизма расширений. Мы можем перехватить событие записи объекта и проверить, является ли текущая база центральным узлом. Если база является подчиненным узлом, мы принудительно запрещаем запись.

Для реализации этого метода:

1. Создайте расширение конфигурации.
2. Добавьте в него справочник Номенклатура.
3. В модуле объекта справочника или через обработчик подписки на событие ПередЗаписью реализуйте проверку.

Пример программного кода для проверки:

&ПередЗаписью
Процедура ПередЗаписьюНоменклатуры(Отказ)
    Если Не ЭтоЦентральныйУзел() Тогда
        ВызватьИсключение "Редактирование номенклатуры в филиале запрещено!";
    КонецЕсли;
КонецПроцедуры

Функция ЭтоЦентральныйУзел()
    ГлавныйУзел = ПланыОбмена.ГлавныйУзел();
    Возврат ГлавныйУзел = Неопределено;
КонецФункции

Важно: Учитывайте, что если ваше расширение добавляет новые объекты метаданных (например, реквизиты), его необходимо устанавливать во всех узлах обмена, иначе при загрузке сообщения обмена возникнет ошибка несоответствия метаданных.

Ограничение доступа через роли и RLS

Более правильным с точки зрения архитектуры 1С является разделение прав доступа на уровне ролей. Вы можете создать отдельную роль, например ТолькоЧтениеНоменклатуры, и назначить её пользователям в филиалах.

Если требуется более гибкое ограничение, используйте RLS (ограничение доступа на уровне записей). Чтобы избежать замедления работы системы, не используйте сложные запросы внутри шаблонов ограничений. Рекомендуется:

1. При запуске системы сохранять статус базы (Центр или Филиал) в ПараметрыСеанса.
2. В шаблоне RLS для справочника Номенклатура прописать условие, которое проверяет этот параметр.

Централизованное управление через константы

Чтобы иметь возможность оперативно включать или отключать запрет без изменения кода расширений, можно создать собственную Константу, например ЗапретитьРедактированиеНоменклатурыВФилиалах. При настройке правил обмена РИБ убедитесь, что эта константа передается в подчиненные узлы.

Таким образом, логика будет выглядеть следующим образом:

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

Рекомендации по безопасности и целостности данных

При реализации запрета на редактирование важно учитывать архитектурные особенности РИБ:

• Приоритет центра: Помните, что механизм РИБ всегда отдает приоритет данным из центральной базы. Любая попытка изменить данные в филиале, которая не была заблокирована, при следующей синхронизации может привести к возникновению конфликтов GUID.
• Синхронизация расширений: Если вы используете расширения, обязательно следите за тем, чтобы версии расширений во всех филиалах были идентичны версии в центральной базе.
• Использование ролей: Всегда отдавайте предпочтение типовым механизмам прав доступа. Назначение пользователям ролей с ограниченными правами (только чтение) является наиболее надежным способом, не требующим постоянной поддержки программного кода.

Мы проанализировали основные подходы к решению задачи. Выбор конкретного метода зависит от ваших бизнес-процессов: если необходимо жесткое ограничение для всех — используйте программный запрет через расширения, если нужно гибкое управление правами сотрудников — настраивайте роли и RLS.