Защита документов и справочников от изменений в 1С
Содержание
Сдали декларацию по НДС, а через неделю кто-то поправил реализацию в закрытом квартале — и данные в базе разошлись с отчётностью. Чтобы такого не было, в 1С есть несколько независимых механизмов запрета на редактирование: дата запрета изменения данных, права доступа к объектам, ограничение на уровне записей (RLS) и запрет на правку проведённых документов. Каждый решает свою задачу.
Самый быстрый способ закрыть прошлые периоды — Администрирование → Настройки пользователей и прав → Даты запрета изменения. Чтобы ограничить, что видит и меняет конкретный пользователь, работают профили групп доступа и RLS. А чтобы бухгалтер не правил уже проведённый документ — настраивается соответствующее право роли.
Ниже разберём каждый механизм: где включается, кого ограничивает и в каком случае выбрать именно его.
Какой механизм запрета выбрать
Прежде чем лезть в настройки, определитесь, что именно вы защищаете. Механизмы не заменяют друг друга — их часто комбинируют.
| Механизм | Что ограничивает | Когда применять |
|---|---|---|
| Дата запрета изменения | Правку данных до указанной даты | Закрыть сданный период для всех или части пользователей |
| Права доступа (роли, профили) | Доступ к видам документов и справочников | Разграничить функции: кадровик, бухгалтер, кладовщик |
| RLS | Доступ к конкретным записям (по организации, складу) | Несколько юрлиц или подразделений в одной базе |
| Запрет правки проведённых | Изменение документа после проведения | Не дать менять то, что уже попало в учёт |
| Блокировка пользователей | Вход в базу целиком | Техработы, обновление, закрытие на инвентаризацию |
Для 90% задач «закрыть прошлый период» хватает одной даты запрета. К ролям и RLS переходят, когда нужно разграничить пользователей, а не периоды.
Дата запрета изменения данных: закрываем период
Это главный инструмент бухгалтера. После сдачи отчётности вы фиксируете дату, раньше которой документы править нельзя.
Путь в «1С:Бухгалтерии 3.0»: Администрирование → Настройки пользователей и прав → Даты запрета изменения. Включите флажок Даты запрета изменения данных и перейдите по ссылке настройки.
Дату можно задать тремя способами:
- Общая дата для всех — самый простой вариант. Указали
31.12прошлого года — и база не даст провести или перепровести документ с датой до этого дня. - По пользователям — главбуху оставляете возможность правок, рядовым бухгалтерам закрываете. Выбираете способ «По пользователям» и задаёте дату каждому или группе.
- По разделам учёта и объектам — закрываете, например, только банк и кассу, а зарплату оставляете открытой.
При попытке изменить закрытый документ 1С покажет сообщение вида Нельзя изменять данные в периоде, по которому установлен запрет и не даст записать.
Дата запрета не удаляет и не блокирует старые документы — она запрещает их изменение и проведение. Открыть и посмотреть документ по-прежнему можно.
Удобно использовать относительную дату — «Конец прошлого месяца» или «Конец прошлого квартала». Тогда граница сдвигается автоматически с каждым новым периодом, и возвращаться к настройке не придётся.
Рядом есть вторая, отдельная настройка — Дата запрета загрузки данных. Она нужна, когда база обменивается документами с другой программой (например, с «1С:Управление торговлей» или сайтом). Запрет изменения не мешает синхронизации, поэтому присланный извне документ может «прилететь» в закрытый период. Дата запрета загрузки блокирует именно такие записи из обмена — её задают отдельно, если у вас настроена синхронизация.
Права доступа к документам и справочникам
Когда задача — не закрыть период, а разграничить сотрудников, работают роли и права на объекты метаданных. Кладовщик видит только склад, кадровик — только кадровые документы.
В типовых конфигурациях права настраиваются не через Конфигуратор напрямую, а через профили групп доступа: Администрирование → Настройки пользователей и прав → Профили групп доступа. Каждый профиль — это набор ролей. Пользователю назначается группа доступа, связанная с профилем.
Порядок такой:
- Создайте или скопируйте профиль (например, от типового «Бухгалтер»).
- В составе профиля отметьте нужные роли — чтения, добавления, изменения конкретных разделов.
- В карточке пользователя (
Администрирование → Настройки пользователей и прав → Пользователи) на вкладке прав привяжите его к группе доступа.
Не редактируйте типовые роли в Конфигураторе. При очередном обновлении конфигурации ваши правки затрёт, и запрет перестанет работать. Создавайте свой профиль на основе типового.
Если же вы ведёте учёт в собственной конфигурации, права на объект настраиваются в Конфигураторе: откройте нужный справочник или документ, вкладка Права роли. Для каждой роли задаются флажки — Чтение, Добавление, Изменение, Удаление, Проведение. Снимите Изменение — и пользователи с этой ролью смогут только просматривать объект.
Запрет на изменение проведённых документов
Отдельная и частая задача: документ провели, движения попали в учёт — и больше его трогать нельзя, даже если период ещё открыт.
За это отвечает право роли Интерактивное изменение проведённых на конкретный документ. Если его снять, пользователь не сможет открыть проведённый документ на редактирование — сначала придётся отменить проведение (если на это есть право).
В Конфигураторе это выглядит так: объект-документ → вкладка Права роли → снимите флажок Интерактивное изменение проведенных. Рядом есть родственные права — Интерактивная пометка удаления проведенных, Интерактивное удаление проведенных; их тоже стоит проверить.
В типовых конфигурациях прямого флажка в пользовательском режиме для этого нет — управление идёт через состав ролей в профиле. Поэтому для большинства практических случаев проще закрыть период датой запрета: она надёжнее и не зависит от тонкой настройки прав.
Снятие права действует на всех пользователей с этой ролью. Прежде чем менять, проверьте, кому ещё назначен профиль.
Ограничение доступа на уровне записей (RLS)
Роли ограничивают доступ к виду объекта целиком: «можно работать с реализациями» или «нельзя». А RLS (Record Level Security) ограничивает доступ к конкретным записям — например, бухгалтер юрлица «Альфа» не видит документы юрлица «Бета», хотя оба хранятся в одной базе.
Чтобы включить механизм: Администрирование → Настройки пользователей и прав, флажок Ограничивать доступ на уровне записей.
RLS заметно нагружает сервер. На каждый запрос добавляются проверки прав, и большие списки открываются медленнее. Включайте только при реальной необходимости разграничения — для одной организации в базе RLS не нужен.
После включения разграничение задаётся через группы доступа. В профиле группы указываются виды доступа (Организации, Склады, Группы контрагентов), а в самой группе доступа — конкретные значения, которые разрешены её участникам.
Пример настройки по организациям:
- Включите ограничение на уровне записей.
- В профиле отметьте вид доступа «Организации».
- Создайте группу доступа «Бухгалтеры Альфы», в ней разрешите только организацию «Альфа».
- Включите в группу нужных пользователей.
Теперь эти пользователи не увидят и не смогут править документы других организаций — RLS отфильтрует записи ещё на уровне запроса к базе.
Блокировка работы пользователей администратором
Иногда нужно запретить не отдельные правки, а вход в базу целиком — на время обновления, свёртки или инвентаризации. Для этого есть блокировка работы пользователей.
Путь: Администрирование → Обслуживание → Блокировка работы пользователей. Задаются дата и время начала блокировки, при необходимости — окончания, и текст сообщения, который увидят пользователи при попытке входа.
Перед включением посмотрите, кто сейчас в базе: Администрирование → Обслуживание → Активные пользователи. Там же в клиент-серверном варианте администратор может завершить чужой сеанс.
Блокировка и принудительное завершение сеансов оборвут работу пользователей — несохранённые данные пропадут. Назначайте дату начала с запасом и предупреждайте сотрудников заранее, а не завершайте сеансы в разгар рабочего дня.
Для планового обслуживания разумно задать блокировку, например, на 19:00 с сообщением «База закрывается на обновление, сохраните данные». Тогда к назначенному часу люди успеют закончить работу сами.
Завершить чужой сеанс принудительно можно в клиент-серверном варианте — через список активных пользователей или через консоль администрирования кластера. В файловой базе такой кнопки нет: там пользователь выходит сам, а на время работ базу просто копируют или ограничивают доступ к сетевой папке. Поэтому для файловой базы блокировка по дате начала — основной цивилизованный способ всех предупредить.
Контроль изменений: журнал регистрации и версионирование
Запрет — это половина дела. Вторая половина — видеть, кто и что менял. В 1С для этого два механизма.
Журнал регистрации фиксирует действия пользователей: вход, изменение и проведение документов, изменение настроек. Путь: Администрирование → Обслуживание → Журнал регистрации. Отбор настраивается по пользователю, дате, виду события и конкретному объекту — так находят, кто изменил документ и когда.
Версионирование объектов хранит историю версий документа или элемента справочника и позволяет сравнить, что именно поменялось. Включается в Администрирование → Настройки пользователей и прав → Версионирование объектов: вы выбираете виды объектов, для которых ведётся история. После этого в карточке объекта через меню «Ещё» доступны версии с построчным сравнением.
Версионирование занимает место в базе и растёт со временем. Включайте его точечно — для документов, вокруг которых бывают споры (реализации, начисления зарплаты), а не для всех объектов подряд.
Связка «дата запрета + журнал регистрации + версионирование» закрывает задачу целиком: прошлое защищено от правок, а любое разрешённое изменение видно и обратимо.
Типичные ошибки при настройке запрета
Механизмы простые, но на них регулярно спотыкаются. Вот что ломает защиту чаще всего.
- 🔧 Правят типовую роль в Конфигураторе. Снятый флажок держится до ближайшего обновления конфигурации, а потом возвращается обратно — и запрет тихо перестаёт действовать. Решение: собственный профиль групп доступа, а не изменение поставляемых ролей.
- 📅 Путают дату запрета изменения и дату запрета загрузки. Закрыли период вручную, а документы из обмена продолжают записываться задним числом, потому что за них отвечает отдельная настройка. Если есть синхронизация — проверьте обе.
- 🗂 Включают RLS «на всякий случай». В базе одна организация, разграничивать нечего, а список документов стал открываться заметно дольше. RLS имеет смысл только при реальном разделении между юрлицами, складами или подразделениями.
- 👤 Забывают про пользователей с полными правами. У сотрудника остался профиль с административными правами — и дата запрета для него не ограничение. Проверьте, у кого полный доступ, прежде чем полагаться на запрет.
- 🔑 Снимают право на правку проведённых, не глядя на состав профиля. Право действует на всех носителей роли сразу. Один сотрудник может потерять возможность исправить свою же ошибку в текущем, ещё открытом периоде.
Перед внедрением запрета зайдите в базу под обычным пользователем (не администратором) и попробуйте изменить закрытый документ сами. Это надёжнее, чем проверять настройку по галочкам.