Как в 1С сделать запрет редактирования данных

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

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

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

Что такое дата запрета изменения данных и когда её применять

Дата запрета изменения данных — это граница, раньше которой пользователи не могут создавать, изменять, проводить и удалять документы, а также изменять связанные движения по регистрам. Механизм встроен в библиотеку стандартных подсистем (БСП), поэтому работает во всех современных типовых решениях на управляемых формах.

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

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

Как установить дату запрета через интерфейс

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

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

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

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

Как проверить, что запрет работает

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

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

Запрет редактирования через права и роли

Дата запрета решает задачу закрытия периода, но не ограничивает работу с актуальными документами. Если нужно запретить конкретному пользователю изменять определённый вид объектов вообще — например, чтобы менеджер мог смотреть, но не править справочник «Номенклатура» — используется настройка прав доступа.

В файловых базах без доработки доступны профили групп доступа: «Администрирование» → «Настройки пользователей и прав» → «Группы доступа». Создайте профиль, в котором для нужного объекта разрешено только чтение, и включите в него пользователя. В клиент-серверном варианте и при работе через конфигуратор права настраиваются тоньше — на уровне ролей с галочками «Чтение», «Добавление», «Изменение», «Удаление».

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

Программные способы для разработчика

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

Минимальный пример обработчика: если документ имеет признак «Согласован», при попытке записи вызывается Отказ = Истина с текстом сообщения пользователю. Важно выдавать понятное сообщение, иначе пользователи будут считать, что программа «зависла» или сломана.

Альтернатива подпискам — переопределение логики в модуле объекта или использование расширения конфигурации. Расширение предпочтительнее для типовых решений на поддержке: доработка не снимает конфигурацию с замка и не усложняет обновления. Любой программный запрет тестируйте сначала на копии базы.

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

Запрет редактирования в формах и отдельных объектах

Иногда задача локальная: сделать конкретную форму или поле доступными только для чтения. В управляемых формах для этого есть свойство «ТолькоПросмотр» — его можно установить у формы целиком или у отдельных элементов. Программно это выглядит как ЭтаФорма.ТолькоПросмотр = Истина; в обработчике «ПриСозданииНаСервере» по нужному условию.

Для блокировки объекта от одновременного редактирования несколькими пользователями платформа использует объектные блокировки: пока один пользователь редактирует документ в форме, второй получит сообщение о блокировке. Это штатное поведение, дополнительной настройки оно не требует, но полезно понимать, что такие сообщения — не ошибка, а защита от конфликта версий.

Отдельный частный случай — запрет изменения помеченных на удаление или закрытых заказов, сданных на склад документов. Здесь обычно комбинируют подходы: статусная модель документа плюс программная проверка при записи, либо запрет через права на изменение после определённого состояния.

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

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

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

Третья группа проблем — производительность и ложные срабатывания. Слишком широкие RLS-ограничения замедляют запросы, а программные запреты без проверки ОбменДанными.Загрузка ломают обмены и обработки загрузки: при загрузке данных проверку запрета обычно пропускают осознанно.

Как выбрать подходящий способ

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

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

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