Почему после обновления 1С:ERP возникает ошибка прав 'Объект не найден' при открытии документов?

← На главную

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

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

Анализ ситуации: когда RLS вводит в заблуждение

Рассмотрим типичный сценарий. После обновления 1С:ERP с версии 2.5.8 на 2.5.12 у пользователя возникла следующая проблема:

Пользователь имеет права на создание и просмотр документов Заявка на расходование ДС с ограничением по своему подразделению.
В списке есть два практически идентичных документа с одним и тем же контрагентом, договором и объектом расчетов.
Один документ пользователь открывает успешно, а при попытке открыть второй возникает ошибка прав доступа.
Отладка показывает, что сбой происходит в момент обращения к договору из "проблемной" заявки — система сообщает, что объект не найден, хотя пользователь может открыть этот же договор напрямую из справочника.
Что еще более странно, если создать копию "проблемной" заявки, то новая заявка открывается и редактируется без ошибок.

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

Ключевая подсказка к решению кроется в наблюдении: старые документы, созданные до обновления, не открываются, а новые, созданные после, — открываются. Это указывает на то, что проблема не столько в самих правах, сколько в данных внутри старых документов.

Поиск истинной причины: скрытые реквизиты и последствия копирования

Проанализируем, что произошло "под капотом" системы. При обновлении 1С:ERP с версии 2.5.8 на 2.5.12 произошли изменения в структуре метаданных документа Заявка на расходование ДС. В частности, реквизит Договор был перенесен из шапки документа в его табличную часть.

Теперь представим действия пользователя. Привыкнув к определенному порядку работы, он создает новые заявки не с нуля, а копированием существующей старой заявки, созданной еще до обновления. В этот момент и возникает коллизия:

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

Механизм RLS, анализируя права на документ, проверяет все связанные данные, включая и значения в этих "скрытых" устаревших реквизитах. Обнаружив ссылку на договор из запрещенного подразделения, RLS справедливо блокирует доступ ко всему документу. Именно поэтому система рапортует об ошибке прав.

Техническое объяснение ошибки "Объект не найден"

Важно понимать, что сообщение "Объект не найден", которое появляется в отладчике при работе RLS, не означает, что объект физически удален из базы данных. Это специфический результат работы механизма ограничения доступа.

Когда пользователь пытается прочитать данные, платформа 1С формирует SQL-запрос к базе данных, автоматически добавляя в него условия (JOIN'ы и WHERE) для проверки прав по таблицам ключей доступа. Если для текущего пользователя и запрашиваемого объекта (в нашем случае, "проблемной" заявки) проверка по одному из связанных полей (устаревшему реквизиту Договор) проваливается, итоговый запрос просто не возвращает ни одной строки. С точки зрения кода 1С, который ожидает получить ссылку на объект, это равносильно тому, что объект не найден.

Пошаговый план решения и рекомендации на будущее

Если вы столкнулись с подобной проблемой, следуйте этому плану для диагностики и устранения.

Шаг 1. Проверка способа создания документов

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

Решение: Проведите инструктаж для пользователей. Объясните, что после обновления, которое могло изменить структуру документов, необходимо создавать новые документы штатными командами (кнопка "Создать" в списке или "Создать на основании" из других актуальных документов). Это гарантирует, что все реквизиты будут заполнены корректно в соответствии с новой логикой.

Шаг 2. Глубокий анализ реквизитов проблемного документа

Чтобы окончательно подтвердить гипотезу, необходимо заглянуть внутрь "сломанного" документа и посмотреть на все его реквизиты, включая скрытые.

Это можно сделать несколькими способами:

Через "Все функции": В главном меню выберите "Все функции", затем в списке "Стандартные" найдите "Изменить реквизиты объекта". В открывшемся окне выберите тип вашего документа и сам проблемный элемент. Вы увидите полный список его реквизитов и их значения. Ищите дублирующиеся по смыслу названия (например, Договор и ДоговорШапка) или просто реквизиты, которых нет в видимой форме документа.
Через консоль запросов: Сформируйте простой запрос, который выводит все поля (*) из таблицы проблемного документа, и посмотрите на результат.

Сравните значения реквизитов "плохого" документа и "хорошего", который открывается без проблем. Обратите внимание на поля, связанные с измерениями прав: Подразделение, Организация, Партнер, Договор и т.д.

Шаг 3. Массовая корректировка данных (при необходимости)

Если проблема затронула большое количество документов, исправлять их вручную нецелесообразно. В этом случае потребуется небольшая обработка.

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

Примерный псевдокод логики обработки:


Процедура ОчиститьСтарыеРеквизиты()
    
    ДатаОбновления = '2023-10-25'; // Указать дату обновления системы

    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ЗаявкаНаРасходованиеДенежныхСредств.Ссылка
        |ИЗ
        |   Документ.ЗаявкаНаРасходованиеДенежныхСредств КАК ЗаявкаНаРасходованиеДенежныхСредств
        |ГДЕ
        |   ЗаявкаНаРасходованиеДенежныхСредств.Дата >= &ДатаОбновления
        |   И ЗаявкаНаРасходованиеДенежныхСредств.УстаревшийРеквизитДоговор <> ЗНАЧЕНИЕ(Справочник.ДоговорыКонтрагентов.ПустаяСсылка)";
        
    Запрос.УстановитьПараметр("ДатаОбновления", ДатаОбновления);
    
    Выборка = Запрос.Выполнить().Выбрать();
    
    Пока Выборка.Следующий() Цикл
        ОбъектДокумента = Выборка.Ссылка.ПолучитьОбъект();
        // Название реквизита нужно уточнить в конфигураторе
        ОбъектДокумента.УстаревшийРеквизитДоговор = Неопределено; 
        
        Попытка
            // Записываем с флагом, чтобы не менять остальные данные и не вызывать лишних проверок
            ОбъектДокумента.Записать(РежимЗаписиДокумента.Запись);
        Исключение
            // Логирование ошибки записи
        КонецПопытки;
    КонецЦикла;
    
КонецПроцедуры

Важно: перед запуском такой обработки на рабочей базе обязательно сделайте резервную копию и протестируйте ее на копии базы.

Шаг 4. Профилактические меры после обновлений

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

Принудительно обновите ключи доступа RLS. Даже если кажется, что все работает, запустите полное обновление. Это можно сделать через регламентное задание Заполнение данных для ограничения доступа (в разделе Администрирование -> Обслуживание -> Регламентные и фоновые задания).
Очистите кэш. Проблемы с правами и некорректным поведением форм часто связаны с устаревшим кэшем. Выполните очистку кэша как на сервере 1С, так и локально у пользователей.
Проводите комплексное тестирование. Перед установкой обновления на рабочую базу разверните его на тестовой копии. Обязательно проверьте ключевые бизнес-процессы под пользователями с разными, в том числе сильно ограниченными, правами. Протестируйте не только создание новых документов, но и открытие и копирование старых.

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

← На главную