Почему в авансовом отчете 1С:ERP не отображается статус «Утвержден»?

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием Управленческий учет IT и автоматизация бизнеса
← На главную

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

Проверка функциональных опций системы

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

  1. Перейдем в раздел НСИ и администрирование — Казначейство.
  2. Проверим наличие флага «Статусы авансовых отчетов». Если эта опция выключена, поле со статусами в документе просто не будет отображаться, и документ будет сразу иметь упрощенный жизненный цикл.
  3. Проанализируем настройку «Заявки на расходование денежных средств». В некоторых релизах ERP логика утверждения авансовых отчетов была тесно связана с подсистемой заявок, и отключение этого функционала могло приводить к некорректной работе экранных форм.

Анализ программной ошибки в проверке прав доступа

Одной из главных причин проблемы, выявленной техническими специалистами, является программная ошибка (баг), допущенная в некоторых релизах веток 2.2 и 2.4. Выясним причину, заглянув в логику работы формы документа Авансовый отчет.

При открытии или создании документа на сервере система выполняет процедуру ПриЧтенииСозданииНаСервере. В этой процедуре вызывается проверка прав текущего пользователя на возможность утверждения документа. Рассмотрим фрагмент проблемного кода:


Если ИспользоватьСтатусыАвансовыхОтчетов Тогда
    ПравоУтверждения = ПраваПользователяПовтИсп.УтверждениеЗаявокНаРасходованиеДенежныхСредств;
КонецЕсли;

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

Посмотрим на определение функции в общем модуле ПраваПользователяПовтИсп:


Функция УтверждениеЗаявокНаРасходованиеДенежныхСредств(Пользователь = Неопределено) Экспорт
    Возврат Пользователи.РолиДоступны("УтверждениеЗаявокНаРасходованиеДенежныхСредств", Пользователь, Ложь);
КонецФункции

Решение проблемы: если вы столкнулись с этим багом и не имеете возможности немедленно обновить конфигурацию до актуального релиза, у вас есть два пути:

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

Необходимая комбинация ролей в профиле доступа

Рассмотрим еще один важный аспект — правильное сочетание прав в профиле групп доступа. Для полноценной работы со статусом «Утвержден» пользователю недостаточно одной лишь роли утверждения. Проанализируем требуемый набор:

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

Влияние бизнес-процессов и связанных документов

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

1. Связь с заявкой на командировку. Если авансовый отчет создан на основании документа Заявка на командировку, система может накладывать дополнительные ограничения. В некоторых редакциях статус «Утвержден» становится доступен только после того, как заявка-основание пройдет свой цикл согласования.

2. Отметка «Проверено бухгалтером». В настройках учетной политики организации может быть установлено требование обязательной проверки первичных документов бухгалтерией. В этом случае поле статуса может управляться логикой: Подготовлен -> На проверке -> Проверен -> Утвержден. Если этап проверки пропущен, финальный статус может не отображаться.

Технические методы диагностики

Если визуальный осмотр настроек не помог, воспользуемся инструментами платформы 1С v8.3 для поиска причины:

  1. Отчет по правам доступа: В форме документа нажмите кнопку Еще — Права доступа. Выберите интересующего пользователя. Система сформирует детальный отчет, в котором будет видно, какие роли и ограничения RLS (Level Record Security) действуют на данный момент. Обратите внимание на ограничения по организациям или подразделениям — если на документ действует ограничение «Только чтение», сменить статус не удастся.
  2. Очистка локального кэша: Довольно часто после обновления прав элементы формы остаются в старом состоянии из-за кэширования метаданных. Рекомендуется запустить 1С с параметром /ClearCache или удалить базу из списка и добавить её снова.
  3. Проверка через консоль кода: Программист может быстро проверить доступность роли для конкретного пользователя, выполнив в консоли кода команду: Сообщить(РольДоступна("УтверждениеАвансовыхОтчетов")); Если возвращается Ложь при наличии роли в профиле, значит, проблема в обновлении кэша или в том, что роль не включена в состав используемого профиля безопасности.

Итоги и рекомендации

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

← На главную