Почему после обновления 1С:ERP программно созданные документы пропадают у пользователей без полных прав?

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

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

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

Симптоматика проблемы

Прежде чем переходить к лечению, важно провести детальный анализ прав доступа к объекту, чтобы точно диагностировать «болезнь». Ситуация выглядит так:

1. Пользователь обладает ограниченным набором прав (например, профиль «Казначей», но не «Полные права»).
2. Запускается обработка, которая программно создает новый документ.
3. В коде используется УстановитьПривилегированныйРежим(Истина), что позволяет обойти проверки прав на этапе записи.
4. Документ успешно записывается, подписки на события отрабатывают корректно.
5. Как только код выходит из привилегированного режима, переменная, содержащая ссылку на документ, при попытке чтения (или обновления интерфейса) превращается в «Объект не найден» (битую ссылку).
6. В журналах документов и списках этот документ для текущего пользователя отсутствует.
7. При этом, если тот же пользователь создает документ вручную через форму, он сохраняется и отображается корректно.

Это классическое поведение системы, когда физически запись в таблице базы данных существует, но механизм RLS (Record Level Security — ограничение доступа на уровне записей) запрещает текущему пользователю чтение этой записи. В таких случаях бывает полезен оперативный анализ прав доступа на объект базы данных непосредственно в режиме предприятия.

Анализ причин: Что изменилось в RLS?

Почему же раньше код работал, а после обновления перестал? В версиях ERP линейки 2.5 (и особенно в ветке 2.5.17) фирма «1С» провела серьезную оптимизацию механизмов казначейства и системы прав доступа.

Рассмотрим, как работает производительный RLS в современных типовых конфигурациях. Доступ к объекту определяется не прямым условием в запросе (как это было в старых версиях: ГДЕ Организация = &ТекущаяОрганизация), а через механизм Дескрипторов доступа.

При записи документа система анализирует его ключевые поля и формирует (или подбирает существующий) ключ доступа (дескриптор). Именно этот дескриптор связывает документ с группами доступа пользователей.

В случае с документом ЗаявкаНаРасходованиеДенежныхСредств ключевыми полями для расчета прав являются:

1. Организация (иногда требуется дополнительное исправление ограничения прав доступа по Организации, если типовой механизм работает некорректно)
2. Подразделение
3. КтоЗаявил (или «Заявитель») — поле, указывающее на инициатора заявки.

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

Почему ручное создание работает, а программное — нет?

Это важный вопрос для понимания механики работы 1С. Разберем разницу процессов.

Вариант 1. Создание вручную (Интерактивно)
Когда пользователь нажимает кнопку «Создать», открывается форма документа. В этот момент срабатывают обработчики события ПриСозданииНаСервере формы. Типовой код конфигурации в этот момент автоматически заполняет множество полей значениями по умолчанию:

• Текущий пользователь подставляется в поле «Автор» или «Кто заявил».
• Подставляется основное подразделение и организация.
• Заполняются приоритеты и даты.

В итоге, когда пользователь нажимает «Записать», документ уже содержит все необходимые данные для корректного расчета RLS.

Вариант 2. Программное создание
При выполнении кода:

НовыйДок = Документы.ЗаявкаНаРасходованиеДенежныхСредств.СоздатьДокумент();
НовыйДок.Дата = ТекущаяДата();
// ... заполнение реквизитов
НовыйДок.Записать();

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

Решение проблемы

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

На основе анализа ситуации выяснилось, что критичным является реквизит КтоЗаявил (в других версиях или документах это может быть Автор или Менеджер). Также для корректного отображения в списках (чтобы документ не отфильтровывался отборами журнала) важно заполнять реквизит ПриоритетОплаты.

Разберем алгоритм исправления:

Шаг 1. Определение текущего пользователя/заявителя

Нам нужно получить ссылку на физическое лицо или пользователя, который будет считаться инициатором заявки. В контексте выполнения обработки это обычно текущий пользователь.

Шаг 2. Доработка кода создания документа

Добавим заполнение недостающих реквизитов. Примерный код будет выглядеть так:

// Создание документа
ЗаявкаОбъект = Документы.ЗаявкаНаРасходованиеДенежныхСредств.СоздатьДокумент();

// ... заполнение основных реквизитов (Сумма, Контрагент и т.д.) ...

// ВАЖНО: Заполнение полей для корректной работы RLS
ТекущееФизЛицо = Пользователи.ТекущееФизическоеЛицо(); 
ЗаявкаОбъект.КтоЗаявил = ТекущееФизЛицо;

// Также крайне рекомендуется заполнять приоритет, чтобы документ не терялся в отборах
ЗаявкаОбъект.Приоритет = Перечисления.ПриоритетыОплаты.Средний; 

// Попытка записи
Попытка
    ЗаявкаОбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
    // Обработка ошибки
КонецПопытки;

Почему возникала ошибка «Объект не найден»?

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

1. Внутри привилегированного режима: Проверки прав отключены. Мы записываем объект. Переменная ЗаявкаОбъект.Ссылка содержит валидный GUID. Мы можем читать поля этого объекта.
2. Выход из привилегированного режима: Система возвращает стандартный контроль прав.
3. Обращение к ссылке: Когда код (или отладчик) пытается прочитать представление ссылки, платформа выполняет SQL-запрос к базе данных.
4. Работа RLS: К запросу автоматически добавляется условие (WHERE). Так как поле КтоЗаявил было пустым, условие RLS возвращает ЛОЖЬ.
5. Результат: Запрос не возвращает ни одной строки. Платформа интерпретирует это как отсутствие объекта в базе данных и отображает «<Объект не найден>».

Дополнительные рекомендации по диагностике

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

1. Сравнение версий и данных
Включите версионирование для проблемного вида документа. Создайте один документ вручную, а второй — программно. Зайдите под полными правами и сравните эти два документа. Ищите пустые поля в программном документе. Особое внимание уделите полям ссылочного типа.

2. Проверка прав и групп доступа
Используйте специализированные инструменты, чтобы провести просмотр прав и групп доступа на объекты для конкретного пользователя. Это поможет понять, в какие профили включена роль и какие ограничения накладываются дескрипторами.

3. Проверка Журнала регистрации
Посмотрите журнал регистрации на момент записи документа. Иногда там фиксируются ошибки доступа к данным («Доступ запрещен»), что прямо указывает на RLS.

4. Регламентное задание обновления прав
В некоторых случаях новые документы могут стать видимыми только после выполнения регламентного задания Обновление доступа на уровне записей. Однако при правильном заполнении всех полей дескриптор доступа должен формироваться «на лету» в момент записи.

Заключение

Проблема «исчезновения» документов после программного создания в 99% случаев связана с неполным заполнением реквизитов, участвующих в ограничении доступа RLS. В обновлениях 1С:ERP разработчики ужесточают контроль за целостностью данных доступа. Решение — явно инициализировать поля ответственных, заявителей и приоритетов в вашем программном коде, имитируя логику, заложенную в формы документов.