При работе в конфигурации 1С:Бухгалтерия предприятия, редакция 3.0 (релиз 3.0.67.67) пользователи и системные администраторы часто сталкиваются со сбоем при выполнении регламентной операции закрытия месяца. Ошибка локализуется в общем модуле ПомощникРасчетаНДС, в процедуре ЕстьСМРХозспособом. Проблема проявляется исключительно в базах данных, где активировано ограничение доступа на уровне записей (RLS) по организациям. При попытке выполнить закрытие месяца система выдает критическую ошибку СУБД или компоновки данных, сообщая о невозможности обратиться к полю «Организация».
В этой статье мы подробно разберем причины возникновения данной ошибки, проанализируем поведение платформы «1С:Предприятие 8.3» при наложении ограничений RLS и рассмотрим три практических способа устранения этой проблемы. Кроме того, мы затронем критически важный сопутствующий баг этого периода, связанный с потерей данных при тестировании и исправлении (ТиИ) из-за расширений конфигурации.
Выясним причину сбоя в алгоритмах закрытия месяца. При запуске этой процедуры система обращается к функции ДоступенАвтоматическийРасчетНДС. Внутри этой функции реализована комплексная проверка условий с множеством логических операторов «ИЛИ». Одним из таких условий является вызов функции ЕстьСМРХозспособом, которая проверяет наличие строительно-монтажных работ, выполненных хозяйственным способом в текущем налоговом периоде.
Внутри функции ЕстьСМРХозспособом разработчиками фирмы «1С» написан запрос к базе данных. Проблема заключается в структуре первого пакета (или временной таблицы) этого запроса: в нем выбираются данные из таблиц, которые напрямую не содержат реквизит Организация. Когда у пользователя включен RLS по организациям, шаблон ограничений платформы пытается автоматически внедрить во все запросы условие фильтрации вида:
ГДЕ Организация В (&ПараметрДоступныеОрганизации)
Поскольку в исходной таблице (или во временной таблице на первом этапе запроса) поле Организация отсутствует физически, механизм RLS платформы не может выполнить сопоставление полей. Происходит аварийное завершение запроса с системной ошибкой. Проанализируем способы обхода этой недоработки.
Рассмотрим самый быстрый способ исправления ошибки непосредственно в коде конфигурации. Если у вас нет возможности оперативно обновить систему на более свежий релиз, можно внести изменения в текст запроса через расширение или напрямую в конфигурацию поставщика (предварительно сняв ее с поддержки с сохранением возможности обновления).
Посмотрим на пример изменения структуры запроса. Нам необходимо принудительно указать платформе, что выборка должна производиться только по тем записям, к которым у пользователя есть права, без генерации жестких ошибок RLS. Для этого в начало текста запроса добавляется ключевое слово РАЗРЕШЕННЫЕ.
До модификации запрос выглядит стандартным образом:
ВЫБРАТЬ
Ссылка КАК ДокументСсылка
ИЗ
Документ.НачислениеНДСПоСМР
После модификации мы принудительно ограничиваем выборку разрешенными записями:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Ссылка КАК ДокументСсылка
ИЗ
Документ.НачислениеНДСПоСМР
Использование ключевого слова РАЗРЕШЕННЫЕ заставляет платформу игнорировать проверку ограничений на уровне записей для тех таблиц, где RLS не может быть корректно применен, и возвращать пустой или отфильтрованный результат без аварийного завершения сеанса.
Проанализируем ситуацию с точки зрения безопасности данных. Функция ЕстьСМРХозспособом выполняет сугубо техническую роль — она проверяет саму техническую возможность автоматического расчета НДС. Здесь нет прямой угрозы утечки конфиденциальной информации пользователю, у которого ограничены права. Следовательно, мы можем полностью отключить механизм RLS на время выполнения этой проверки.
Для этого в общем модуле перед вызовом проблемного запроса (или в самом начале процедуры) мы устанавливаем привилегированный режим, а после выполнения запроса — отключаем его. Разберем по шагам, как это реализовать программно:
// Устанавливаем привилегированный режим, отключающий проверку прав и RLS
УстановитьПривилегированныйРежим(Истина);
// Здесь выполняется штатный запрос функции ЕстьСМРХозспособом
// ...код запроса...
// Обязательно отключаем привилегированный режим по завершении работы с запросом
УстановитьПривилегированныйРежим(Ложь);
Этот метод гарантирует, что запрос отработает максимально быстро (так как платформа не будет тратить ресурсы СУБД на наложение дополнительных условий RLS) и без ошибок, независимо от того, какие роли и ограничения настроены для текущего пользователя.
Фирма «1С» признала наличие этой ошибки в релизе 3.0.67.67. Если вы не хотите вносить изменения в программный код вручную, лучшим решением будет обновление конфигурации «Бухгалтерия предприятия» до релиза 3.0.67.74 или выше. В последующих сборках разработчики оптимизировали структуру запросов в модуле ПомощникРасчетаНДС, добавив корректную обработку контекста прав и исключив падение системы при активном RLS по организациям.
Поскольку в обсуждениях данного релиза программисты часто упоминают сопутствующие проблемы, разберем еще одну критическую ошибку, актуальную для периода выпуска релиза 3.0.67.67 (начало 2019 года). Ошибка была связана с работой платформы «1С:Предприятие 8.3» (версии 8.3.12 и первые сборки 8.3.13) при взаимодействии расширений конфигурации и механизма «Тестирование и исправление».
Суть проблемы: Если разработчик добавлял новые реквизиты к типовым справочникам или документам (например, к справочнику Контрагенты или ДоговорыКонтрагентов) через механизм расширения данных, а затем запускал стандартную процедуру Тестирования и Исправления с включенной опцией проверки логической целостности, платформа давала сбой.
Утилита ТиИ некорректно сопоставляла метаданные основной конфигурации и расширения, в результате чего связи между владельцами и подчиненными объектами признавались «битыми». Платформа автоматически, без предупреждения пользователя, безвозвратно удаляла подчиненные справочники (например, банковские счета или договоры контрагентов), считая их сиротами. Это приводило к потере колоссальных объемов информации в рабочих базах данных.
Чтобы избежать подобных катастрофических последствий при администрировании баз данных 1С, настоятельно рекомендуем придерживаться следующих правил:
ДополнительныеРеквизитыИСведения или создавайте новые регистры сведений в расширениях для хранения сопутствующих данных.