Почему возникает ошибка «Объект не найден» при сохранении нового документа пользователем с ограниченными правами в 1С:ERP и УХ?

← На главную

При работе в современных конфигурациях, таких как 1С:ERP Управление предприятием или 1С:Управление холдингом, разработчики часто сталкиваются с парадоксальной ситуацией. Пользователь с ограниченными правами (имеющий роли на добавление и чтение) пытается создать документ через нетиповую обработку, но в момент записи получает ошибку «Объект не найден» или «Отказ в праве на чтение». При этом под полными правами всё работает корректно, а уже созданный документ проблемный пользователь может открывать и редактировать без проблем. Особенно остро эта проблема проявилась на платформе версии 8.3.25.1374 и выше.

Разберем детально, почему так происходит, и как исправить эту ошибку, учитывая механизмы Производительного RLS и особенности работы ядра платформы.

Причина 1: Механизм ключей доступа (Производительный RLS)

В конфигурациях на базе БСП (Библиотеки стандартных подсистем) последних версий используется так называемый «производительный режим» ограничения доступа. В отличие от классического RLS, где условия проверки встраиваются в каждый запрос к базе данных, здесь права проверяются через специальные вспомогательные таблицы — регистры сведений, такие как РегистрСведений.КлючиДоступаКОбъектам.

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

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

Причина 2: Особенности платформы 8.3.25 и кэширование прав

Начиная с версии 8.3.25, механизмы платформы по работе с кэшем прав доступа и временными таблицами стали более чувствительны к моменту обновления метаданных. Зафиксированы случаи, когда внутри одной транзакции (например, в процедуре ПриЗаписи модуля объекта) обращение к свойству ЭтотОбъект.Ссылка возвращает битую ссылку для пользователя с RLS, хотя физически запись уже существует.

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

Решение 1: Принудительное обновление ключей доступа

Если вы создаете документ программно, важно убедиться, что система успела рассчитать права. В типовых конфигурациях за это отвечает модуль УправлениеДоступом. Разберем пример кода, который помогает форсировать обновление прав перед завершением работы с объектом:


// В обработке создания документа
НовыйДокумент = Документы.ЗаявкаНаОплату.СоздатьДокумент();
// Заполнение реквизитов...
НовыйДокумент.Записать();

// Если ошибка сохраняется, попробуем явно вызвать обновление доступа
УправлениеДоступом.ОбновитьКлючиДоступа(НовыйДокумент.Ссылка);

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

Решение 2: Проверка связанных объектов и составных типов

Зачастую ошибка «Отказ в праве на чтение ЗНО» (Заявки на оплату) является следствием отсутствия прав на один из её реквизитов. В документе «Заявка на оплату» огромное количество ссылочных полей: Организация, БанковскийСчет, Контрагент, Договор, ДокументОснование.

Проанализируем составной тип реквизита ДокументОснование. Даже если это поле пустое, RLS может пытаться проверить права на все типы, входящие в этот составной тип. Если у пользователя нет права Чтение хотя бы на один из типов документов, входящих в состав основания (даже если этот документ не используется в вашей системе), RLS может сработать некорректно.

Что нужно сделать:

Убедиться, что у пользователя есть право Чтение и Просмотр на все справочники, используемые в реквизитах.
Проверить права на связанные регистры. Например, в ERP при записи ЗНО могут обновляться данные в регистрах накопления по бюджетированию или очереди платежей.

Решение 3: Диагностика через «Отчет по правам доступа»

Чтобы не гадать, какой именно реквизит блокирует доступ, воспользуемся мощным встроенным инструментом. В разделе Администрирование — Настройки пользователей и прав найдите отчет «Права доступа».

Рассмотрим пошагово процесс диагностики:

Выберите проблемного пользователя.
Выберите объект метаданных (Документ «Заявка на оплату»).
Обязательно включите вариант отчета «С расшифровкой по ограничениям (RLS)».
Проанализируйте колонку «Ограничение». Если там указано условие (например, по Организации или Подразделению), убедитесь, что в реквизитах создаваемого документа подставлены значения, которые входят в разрешенную группу для этого пользователя.

Решение 4: Регламентное задание и серверный кэш

Иногда причина кроется в «зависшем» регламентном задании. В ERP/УХ за актуальность прав отвечает задание Заполнение данных для ограничения доступа. Если оно завершилось с ошибкой или давно не запускалось, новые объекты не будут попадать в индекс ключей доступа.

Выясним причину через монитор регламентных заданий. Если задание активно, но ошибка сохраняется, попробуйте выполнить очистку серверного кэша. На платформе 8.3.25 это критически важно, так как старые сеансовые данные могут хранить неверную структуру прав доступа даже после изменения ролей пользователя.

Совет: В некоторых случаях помогает временная установка права Чтение на уровне всей конфигурации (без RLS) для конкретной роли в расширении, чтобы «протолкнуть» запись объекта, но это является крайней мерой и снижает безопасность системы.

Резюме

Для исправления ошибки доступа при создании документа на платформе 8.3.25 в связке с ERP/УХ, рекомендуем придерживаться следующего алгоритма:

Проверьте, обновляются ли ключи доступа (регистр КлючиДоступаКОбъектам) сразу после записи документа.
Убедитесь, что в коде создания документа не используется ОбменДанными.Загрузка = Истина без последующего вызова УправлениеДоступом.ОбновитьКлючиДоступа().
Используйте отчет по правам доступа с расшифровкой RLS для поиска «скрытых» ограничений по полям.
Проверьте работу регламентного задания по заполнению данных доступа.

Следуя этим шагам, мы сможем выявить точную причину отказа и обеспечить стабильную работу пользователей с ограниченными правами в сложных корпоративных системах.