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