Почему не создаются документы при обмене ЗУП 3.1 под ограниченными правами?

Ситуация, когда при использовании обработки «Универсальный обмен данными XML» система сообщает об успешной загрузке объектов, но сами документы не появляются в списках, является классической проблемой прав доступа и механизмов RLS в конфигурации «Зарплата и управление персоналом 3.1». Особенно часто это проявляется после обновления конфигурации, когда меняются типовые роли или алгоритмы проверки бизнес-логики.

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

Анализ механизма загрузки данных

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

Разберем по шагам, почему документ может «исчезать» без видимых ошибок в журнале регистрации.

Шаг 1. Проверка роли «Выполнение обмена данными»

Проанализируем состав прав пользователя. Для того чтобы платформа позволяла записывать объекты с установленным свойством ОбменДанными.Загрузка = Истина, у пользователя **обязательно** должна быть роль «Выполнение обмена данными» (в метаданных — DataExchange).

Если этой роли нет:

1. Платформа игнорирует флаг загрузки.
2. Включаются все стандартные проверки бизнес-логики (проверка заполнения, проверка прав на подразделения, организации, физических лиц).
3. Если какое-то поле недоступно пользователю по RLS, запись просто не происходит. При этом внешняя обработка может перехватить исключение в блоке Попытка...Исключение и инкрементировать счетчик «Загружено», не выводя ошибку пользователю.

Шаг 2. Отладка и поиск точки «отказа»

Как было замечено в обсуждении, под полными правами остановка в процедуре ПередЗаписью срабатывает, а под ограниченными — нет. Это критически важный симптом. Если выполнение не доходит до ПередЗаписью, значит, отказ происходит на уровне платформенной проверки прав «Добавление» или «Изменение» для данного объекта метаданных.

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

// Пример упрощенного фрагмента кода загрузки
Попытка
    Объект.ОбменДанными.Загрузка = Истина;
    Объект.Записать();
Исключение
    // Если здесь нет вывода сообщения об ошибке, 
    // пользователь увидит "Загружено", но объект не запишется
    ЗаписьЖурналаРегистрации("Загрузка данных", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;

Для диагностики выполним следующие действия:

1. Запустим сеанс под пользователем с ограниченными правами в режиме отладки.
2. Установим точку останова в обработке загрузки на строке Объект.Записать().
3. Когда выполнение прервется, попробуем вычислить выражение ПравоДоступа("Добавление", Объект.Метаданные()).
4. Если результат Ложь, значит, проблема в ролях. Если Истина, но запись не проходит, дело в RLS.

Шаг 3. Диагностика RLS и ключей доступа

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

Проанализируем состояние системы прав:

• Перейдем в раздел Администрирование — Обслуживание — Регламентные операции.
• Найдем задания «Заполнение данных для ограничения доступа» и «Обновление ключей доступа». Если они зависли или завершились с ошибкой, их нужно перезапустить.
• Проверим настройки в Настройки пользователей и прав — Ограничивать доступ на уровне записей. Если используется «Производительный» режим, попробуйте временно переключить его в «Стандартный» для проверки.

Шаг 4. Влияние бизнес-логики ЗУП 3.1

В ЗУП 3.1 при записи документов часто вызывается функция ЗарплатаКадры.ОтключитьБизнесЛогикуПриЗаписи(ЭтотОбъект). Рассмотрим, как это работает под разными правами.

Функция ОтключитьБизнесЛогикуПриЗаписи(Объект) Экспорт
    // Если это загрузка данных, часто возвращается Истина,
    // и тяжелые кадровые проверки пропускаются.
    Если Объект.ОбменДанными.Загрузка Тогда
        Возврат Истина;
    КонецЕсли;
    ...
КонецФункции

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

Резюме и рекомендации

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

1. Назначьте роль «Выполнение обмена данными» в профиль групп доступа пользователя. Это позволит платформе корректно обрабатывать свойство ОбменДанными.Загрузка = Истина.
2. Обновите регистры ключей доступа. Запустите вручную регламентное задание по обновлению прав доступа.
3. Проверьте Журнал регистрации под Администратором. Выставьте фильтр по времени, но снимите фильтр по пользователю. Ошибки записи под ограниченным пользователем иногда регистрируются системой как общие ошибки транзакции сервера.
4. Проверьте права на вспомогательные справочники. В ЗУП документы тянут за собой физических лиц и сотрудников. Если у пользователя есть право на «Прием на работу», но нет права на «Изменение» справочника «Физические лица», и при загрузке данные физлица меняются — транзакция записи документа будет откачена целиком.

Используя эти методы, мы сможем точно определить, на каком этапе происходит «тихий» отказ системы, и обеспечить корректную загрузку кадровых документов в ЗУП 3.1.