Как запретить изменять документы в 1С

Запрет на изменение документов — одна из базовых задач защиты учётных данных в 1С. Закрытый период, случайное редактирование проведённой накладной, «тихое» перепроведение прошлого квартала — всё это приводит к расхождениям в отчётности, сбоям в обменах и вопросам при проверках. В типовых конфигурациях есть несколько независимых механизмов защиты, и правильный результат достигается их комбинацией, а не одной настройкой.

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

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

Определите, что именно нужно запретить

Прежде чем менять настройки, зафиксируйте задачу в конкретных терминах. «Запретить изменять документы» может означать разное: запрет редактирования закрытого периода для всех, запрет изменения проведённых документов для менеджеров, запрет изменения конкретного вида документов (например, «Реализация товаров и услуг») или запрет пометки на удаление. Для каждой задачи оптимальный механизм свой.

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

Дата запрета изменения данных — основной инструмент

Дата запрета изменения данных (в старых версиях — «дата запрета редактирования») блокирует создание и изменение документов раньше заданной даты для всех пользователей без специального права. В типовых конфигурациях на БСП настройка находится в разделе «Администрирование» → «Поддержка и обслуживание» → «Регламентные операции» → флажок «Даты запрета изменения данных» → ссылка «Настроить».

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

Обход запрета возможен: пользователю или группе можно выдать право «Изменение данных до даты запрета» либо установить для него индивидуальную, более раннюю дату. Это стандартный приём для главного бухгалтера — общий запрет действует, но у него остаётся возможность внести исправления по согласованию.

1. 1
   Откройте Администрирование → Поддержка и обслуживание → Регламентные операции
2. 2
   Включите флажок «Даты запрета изменения данных» и перейдите по ссылке «Настроить»
3. 3
   Задайте общую дату или выберите динамическое правило (например, конец прошлого квартала)
4. 4
   При необходимости задайте исключения для отдельных пользователей или разделов учёта
5. 5
   Запишите настройку и проверьте под обычным пользователем, что документ прошлого периода не записывается

Ограничение прав через профили и роли

Если задача — не закрыть период, а лишить конкретных сотрудников возможности менять чужие или определённые документы, работайте с правами. В типовых конфигурациях права назначаются через «Профили групп доступа» (Администрирование → Настройки пользователей и прав → Профили групп доступа). Пользователь включается в группу доступа, а группе назначается профиль с набором разрешённых ролей.

Для запрета изменения конкретного вида документов создайте копию типового профиля и уберите из неё роли, дающие право добавления и изменения нужного объекта, оставив роли на чтение. Например, менеджеру можно оставить просмотр реализаций, но убрать возможность их редактировать после проведения. Важно: снятие только одной роли часто недостаточно — право на изменение может приходить из нескольких ролей, поэтому проверяйте фактический результат под учётной записью пользователя.

Отдельно стоит убрать у рядовых пользователей право интерактивного удаления и, где это критично, право отмены проведения. Это защищает от самых разрушительных действий: удаления документа вместо корректной пометки и перепроведения цепочки документов задним числом.

Точечные запреты: расширения и подписки на события

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

В обработчике проверяется условие и при его выполнении вызывается отказ от записи с понятным сообщением пользователю. Например, запретить запись реализации, если по ней уже выставлен счёт-фактура и период закрыт. Классический вариант — подписка на событие «ПередЗаписью» документа с аналогичной логикой.

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	Если Не ЭтоНовый() И Дата < ДатаЗапрета Тогда
		Отказ = Истина;
		ВызватьИсключение "Изменение документа запрещено: период закрыт";
	КонецЕсли;
КонецПроцедуры

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

Проверка, что запрет реально работает

После настройки обязательно проверьте результат из-под учётной записи ограниченного пользователя, а не администратора. Тестовый сценарий минимум такой: попытка изменить документ закрытого периода, попытка перепровести документ текущего периода, попытка пометить документ на удаление, попытка создать документ задним числом.

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

Типичные ошибки и ограничения

Самая частая ошибка — установить дату запрета и считать задачу решённой, забыв про пользователей с полными правами и про обмены. Вторая по частоте — снять у пользователя одну роль, тогда как право изменения приходит из другой, и сделать вывод о защите без фактической проверки. Третья — доработать запрет записи напрямую в конфигурации и потерять изменение при первом же обновлении.

Учитывайте и ограничения: дата запрета не защищает от изменения документов текущего периода, а права не защищают от администратора. Для контроля действий тех, кто ограничения обходит, используйте журнал регистрации и версионирование объектов (в типовых — «Администрирование» → «Поддержка и обслуживание» → настройка версионирования): оно не запрещает изменение, но позволяет увидеть, кто и что поменял, и восстановить прежнюю версию.

Частые вопросы