Как запретить пользователю редактирование документов прошедшей датой в 1С:УТ 11

← На главную

В процессе сопровождения систем на базе 1С:Управление торговлей 11 часто возникает задача ограничить возможность редактирования документов задним числом. Это необходимо для обеспечения сохранности данных, корректности себестоимости и предотвращения ошибок персонала. Мы рассмотрим, как решить эту задачу как стандартными средствами, так и с помощью программного кода, если типовой функционал не покрывает ваши потребности.

Использование типового механизма Даты запрета изменения

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

Разберем по шагам, как активировать и настроить этот функционал:

Перейдем в раздел НСИ и администрирование, далее выберем пункт Настройки пользователей и прав.
Найдем группу настроек Даты запрета изменения и установим соответствующий флаг.
Нажмем на ссылку Настроить. Здесь мы можем задать общую дату запрета для всех пользователей или настроить исключения.

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

Проблема непроводящих документов (на примере Заказа клиента)

В ходе эксплуатации мы можем столкнуться с ситуацией, когда дата запрета установлена, но документ Заказ клиента все равно доступен для редактирования. Выясним причину такого поведения. В типовых конфигурациях, таких как УТ 11 или ERP, механизм даты запрета часто ориентирован на документы, делающие движения по регистрам (финансово значимые). Документы типа "Заказ", которые являются лишь намерениями, могут игнорироваться системой проверки.

Чтобы исправить это, нам необходимо убедиться, что документ включен в состав проверяемых объектов. Рассмотрим, как это реализовано в коде БСП. Поиск следует вести в общем модуле ДатыЗапретаИзмененияПереопределяемый в процедуре ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения.

Проанализируем пример кода, который регистрирует документы для проверки:


ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Документ.ПриобретениеТоваровУслуг", "Дата", "Закупки", "Организация");
ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Документ.РеализацияТоваровУслуг", "Дата", "Продажи", "Организация");

Если в этом списке отсутствует Документ.ЗаказКлиента, система не будет блокировать его редактирование автоматически. В таком случае потребуется программное расширение.

Программная настройка ограничений через расширение

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

Мы будем использовать обработчик ПередПроверкойЗапретаИзменения. Посмотрим на пример реализации:


&После("ПередПроверкойЗапретаИзменения")
Процедура Р1_ПередПроверкойЗапретаИзменения(Объект, ПроверкаЗапретаИзменения, УзелПроверкиЗапретаЗагрузки, ВерсияОбъекта)
    
    // Если проверка еще не сработала стандартными средствами
    Если НЕ ПроверкаЗапретаИзменения Тогда
        // Проверяем конкретный тип документа
        Если ТипЗнч(Объект) = Тип("ДокументОбъект.ПриобретениеТоваровУслуг") Тогда
            // Проверяем дату документа относительно текущего момента
            Если Объект.Дата < НачалоДня(ТекущаяДата()) Тогда
                // Устанавливаем флаг запрета
                ПроверкаЗапретаИзменения = Истина;
            КонецЕсли;
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Этот подход гораздо надежнее, чем простое управление свойством формы ТолькоПросмотр = Истина, так как проверка в модуле сработает даже при записи объекта программно или через внешнюю обработку.

Важные технические нюансы работы подсистемы

Рассмотрим важные аспекты, о которых часто забывают администраторы и разработчики при настройке дат запрета:

Регламентные задания: Когда мы устанавливаем относительную дату (например, "Предыдущий день"), за обновление реальных дат в регистре отвечает задание Обновление дат запрета изменения данных. Если оно не запущено, дата запрета не будет "двигаться".
Приоритеты настроек: В 1С действует иерархия. Персональные настройки пользователя имеют наивысший приоритет. Если пользователь входит в несколько групп, система выберет самую раннюю (мягкую) дату запрета среди всех его групп. Это часто является причиной того, что запрет "не работает".
Привилегированный режим: Любой код, выполняемый на сервере внутри конструкции УстановитьПривилегированныйРежим(Истина), полностью игнорирует даты запрета. Проанализируем это при написании собственных обработок загрузки данных.
Разделы и объекты: Если вы настраиваете дату запрета "По разделам", убедитесь, что ваш документ правильно сопоставлен с разделом (Закупки, Продажи, Склад и т.д.) в процедурах переопределяемых модулей. Если соответствие не задано, будет применяться Общая дата.

Настройка исключений для разделов

Иногда требуется запретить всё старее сегодняшнего дня, кроме одного типа документов (например, разрешить вводить Приобретение товаров и услуг за прошлую неделю). В этом случае в настройках даты запрета нужно выбрать способ По разделам и объектам.

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

Используя предложенные методы, мы обеспечиваем гибкий контроль над вводом данных в 1С:Управление торговлей 11, комбинируя удобство типового интерфейса и мощность программной модификации платформы.

← На главную