Блокировка изменения данных прошлых периодов в 1С 8.3

За блокировку правок в прошлых периодах в 1С 8.3 отвечает один штатный механизм — дата запрета изменения данных. Включают его в разделе Администрирование → Настройки пользователей и прав → Даты запрета изменения данных. После настройки программа не даст провести, перепровести, изменить или удалить документ с датой раньше указанной — и даже создать новый задним числом.

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

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

Что блокирует дата запрета, а что нет

Дата запрета изменения данных закрывает период на запись. Под неё попадают четыре действия с объектами, датированными не позже указанного дня:

• 📝 изменение и повторное проведение документа;
• ↩️ отмена проведения;
• 🗑️ пометка на удаление и удаление;
• ➕ создание нового документа задним числом.

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

Смысл механизма — защитить сданную отчётность. По Федеральному закону № 402-ФЗ данные утверждённой бухгалтерской отчётности менять нельзя, а ошибки прошлых периодов исправляют по правилам ПБУ 22/2010 — отдельными операциями, а не прямой правкой старого документа. Дата запрета как раз страхует от того, чтобы кто-то «по-быстрому» поправил проводку в закрытом квартале.

Способ 1. Настроить дату запрета изменения данных

Это основной способ, которого в 90% случаев достаточно. Путь к настройке зависит от конфигурации, но логика везде одна.

Порядок действий:

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

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

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

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

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

Способ 2. Ограничить права: кто вправе менять дату запрета

Сам механизм — только половина защиты. Вторая половина — права: кто может эту дату сдвинуть или снять флажок.

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

Что проверить при настройке прав:

• 🔑 у обычных пользователей не должно быть профиля Администратор — иначе запрет для них чисто декоративный;
• 👤 работать всем в базе под одной учётной записью «главбух с полными правами» нельзя: тогда дату запрета сможет двигать любой, кто за компьютером;
• 🧾 если нужен промежуточный вариант — право видеть настройку, но не менять её — это решается индивидуальным профилем доступа, но для большинства баз хватает штатного разделения «администратор / пользователь».

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

Способ 3. Закрыть загрузку данных из обменов

Отдельная ловушка — распределённые базы (РИБ) и синхронизации. Дата запрета изменения данных останавливает человека за клавиатурой, но документ может прийти из другой базы через обмен — и «приземлиться» в уже закрытый период.

Для этого есть второй, самостоятельный механизм — дата запрета загрузки данных. Он настраивается в области синхронизации: Администрирование → Синхронизация данных (в УТ 11 — в разделе НСИ и администрирование), в настройках обмена есть отдельный пункт про дату запрета загрузки.

Логика такая же: загружаемый документ с датой раньше границы в базу-приёмник не попадёт. Настраивается запрет загрузки так же гибко — общий или по узлам обмена.

Способ 4. Программная блокировка через расширение

Штатная дата запрета покрывает типовые сценарии. Нестандартные правила — например, «закрыть период только по одной организации» или «запретить правку конкретного вида документа» — настройкой не задаются. Здесь нужна программная проверка.

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

Схема такая:

1. Создают расширение конфигурации.
2. Добавляют подписку на событие ПередЗаписью нужных документов.
3. В обработчике сравнивают дату документа с собственной границей и при необходимости отказывают в записи.

Скелет обработчика выглядит так:

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

Если своей командой разработки нет — это задача для специалиста 1С. Самостоятельно лезть в модули рабочей базы без копии не стоит.

Способ 5. Почему не нужно блокировать период на уровне СУБД

Иногда советуют закрыть период «жёстко» — повесить триггер или урезать права на таблицы в SQL Server или PostgreSQL. На практике это плохая идея.

• 🚫 1С не рассчитана на внешнее вмешательство в структуру таблиц. Имена и состав полей меняются при обновлениях — триггер отвалится или начнёт блокировать не то.
• 🚫 Любая правка на уровне СУБД в обход платформы снимает базу с поддержки: при обращении в 1С вам укажут на недопустимое вмешательство.
• 🚫 Блокировка таблицы ломает штатные механизмы — проведение, обмены, регламентные задания, — потому что платформа пишет в те же таблицы.

Единственное, что уместно на уровне СУБД, — это резервное копирование и мониторинг. А запрет периода решается штатно, датой запрета изменения (Способ 1). Она надёжнее любого ручного триггера и переживает обновления.

Как убедиться, что период действительно закрыт

Настроить дату мало — стоит проверить, что защита работает так, как задумано. Самый надёжный способ — короткий тест на реальном примере.

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

Отдельно полезно понимать, кто и когда правил данные. Для разбора спорных случаев в типовых конфигурациях ведётся журнал регистрации (Администрирование → Обслуживание → Журнал регистрации или аналогичный раздел обслуживания) — по нему видно, какой пользователь менял документ и в какой момент. Запрет периода предотвращает правку, а журнал помогает разобраться в том, что успело случиться до его установки.

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

Самые частые промахи — не в настройке даты, а вокруг неё:

• Путают закрытие месяца и запрет. Закрыли месяц регламентной операцией и думают, что он защищён. Нет — проводки по-прежнему можно переправить, пока не стоит дата запрета.
• Ставят запрет, но не трогают права. Все работают под администратором, и запрет отодвигают в пару кликов. Сначала учётные записи, потом дата (см. Способ 2).
• Забывают про обмен. Период закрыт от ручной правки, но синхронизация продолжает грузить документы прошлых месяцев из другой базы. Нужна и дата запрета загрузки (Способ 3).
• Фиксированную дату не переставляют. Поставили 31.03 и больше не тронули — к концу года открытыми остаются уже три закрытых квартала. Используйте относительную дату.
• Закрывают слишком рано. Граница упёрлась в период, который ещё правит бухгалтер. Разнесите даты по пользователям или разделам учёта.

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