В практике администрирования 1С:УПП (Управление производственным предприятием) нередко возникают ситуации, которые кажутся магическими: дата запрета редактирования установлена, права настроены корректно, но данные в закрытом периоде всё равно оказываются измененными. Сегодня мы проанализируем реальный кейс, когда сотрудница смогла снять документ июля с проводки при установленной дате запрета на 31.07.2019, и выясним, какие технические лазейки в типовых конфигурациях позволяют это сделать.
Разберем конкретный механизм, который был использован в описанном случае. Основная проблема заключается в логике проверки даты запрета при записи объекта. Проанализируем последовательность действий пользователя:
В итоге мы получаем «испорченный» документ: он находится в июле, он не проведен, и пользователь не может его исправить, так как период уже заблокирован. Мы видим ситуацию, когда механизм защиты сработал наполовину, позволив разрушить целостность данных, но не дав их восстановить.
Рассмотрим, как это выглядит с точки зрения программного кода. В конфигурации 1С:УПП проверка даты запрета обычно инициируется в модуле объекта в процедуре ПередЗаписью или через подписки на события. Проанализируем типичный алгоритм проверки:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Проверка даты запрета
Если Не ПроверитьДатуЗапрета(ЭтотОбъект) Тогда
Отказ = Истина;
Возврат;
КонецЕсли;
КонецПроцедуры
Проблема кроется в функции ПроверитьДатуЗапрета. Во многих редакциях старых конфигураций проверка осуществляется только для новой даты документа. Если логика проверки не учитывает «старую» дату (ту, которая была в документе до момента редактирования), возникает описанная выше брешь. Для надежной защиты система должна проверять оба значения: и то, которое было, и то, которое станет.
Выясним, почему пользователи с административными полномочиями часто игнорируют ограничения. В 1С существует важная настройка, о которой часто забывают администраторы. Рассмотрим её подробнее:
В регистре сведений "Настройки прав доступа пользователей" или в константах может существовать флаг "Применять дату запрета для пользователей с полными правами". Если эта галочка не установлена, то любой пользователь с ролью ПолныеПрава может редактировать документы в любом периоде, несмотря на установленную дату запрета. При этом в Журнале регистрации изменений самой даты запрета не будет, так как пользователь её не менял — он просто воспользовался своим правом её игнорировать.
Также проанализируем ситуацию с отсутствием записей в Журнале регистрации. Если вы не видите события изменения документа, проверьте следующие настройки:
ГрупповаяОбработкаСправочниковИДокументов, запись в журнале может быть менее информативной, особенно если обработка написана с использованием метода Объект.Записать() без должной инициализации параметров регистрации.Рассмотрим еще один сценарий — программный обход. В 1С:УПП существует возможность записи документа в так называемом привилегированном режиме. Если код выполняется на стороне сервера внутри фрагмента:
УстановитьПривилегированныйРежим(Истина);
ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);
УстановитьПривилегированныйРежим(Ложь);
В этом случае проверки прав доступа (включая RLS) могут игнорироваться. Если на предприятии используются внешние обработки для автоматического формирования или корректировки документов, они могут обходить дату запрета, если разработчик не предусмотрел явный вызов процедур проверки.
Чтобы минимизировать риск «внезапного» разпроведения документов в закрытых периодах, выполним следующие шаги:
ПередЗаписью. Проверяйте как ЭтотОбъект.Дата, так и ЭтотОбъект.Ссылка.Дата (значение в базе до записи).ОбменДанными.Загрузка = Истина отключает большинство проверок. Если сотрудники имеют доступ к загрузке данных через COM-соединение или XML, они могут менять документы в обход всех экранных ограничений.Подводя итог, можно сказать, что ситуация в 1С:УПП была вызвана сочетанием человеческого фактора (попытка исправить ошибку в последний момент) и технической особенности проверки дат. Своевременный контроль настроек прав и понимание логики работы платформы позволяют избежать подобных "детективных" историй в будущем.