← На главную

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

Рассмотрим различные подходы к решению этой задачи, от типовых механизмов платформы 1С до более гибких решений с использованием регламентных заданий и расширений.

1. Использование механизма "Дата запрета изменения данных"

Одним из самых распространенных и типовых механизмов в 1С является "Дата запрета изменения данных". Этот механизм позволяет установить дату, до которой или включительно с которой запрещено редактировать любые данные в информационной базе.

Разберем подробнее, как мы можем использовать этот механизм:

1. Общие настройки даты запрета: В 1С Розница 2.2, как и в других конфигурациях на платформе 1С:Предприятие 8.3, мы можем найти эту настройку в разделе Администрирование -> Поддержка и обслуживание -> Дата запрета изменения данных.
2. Выбор режима установки даты:
   • Произвольная дата: Мы можем установить конкретную дату, например, 18.10.2023. Все документы, датированные этой датой или ранее, будут заблокированы для изменения. Однако, как отмечают пользователи, это требует ежедневного ручного переноса даты, что крайне неудобно.
   • Предыдущий день: Гораздо более удобный вариант, предложенный в обсуждении, — это выбрать автоматическое определение даты запрета как "Предыдущий день". В этом случае система будет автоматически устанавливать дату запрета на вчерашний день. То есть, сегодня 20.10.2023, запрет будет установлен на 19.10.2023 и ранее. Документы, созданные 20.10.2023, можно будет редактировать.
3. Гибкие настройки даты запрета:
   • Мы можем настроить дату запрета изменения не только для всех пользователей, но и индивидуально для каждого сотрудника или группы пользователей. Это позволяет гибко управлять доступом, устанавливая разные даты запрета для разных групп пользователей. Например, для кассиров — предыдущий день, для старших менеджеров — предыдущая неделя.
   • Помимо установки конкретной даты, мы можем выбрать автоматическое определение даты запрета, например, конец прошлого года, квартала, месяца, недели или упомянутый предыдущий день.
   • Дата запрета может быть установлена для определенных разделов учета или даже для разделов и конкретных объектов.
   • Существует возможность отсрочить начало действия даты запрета, указав, через сколько дней ограничения вступят в силу. Например, мы можем разрешить редактирование документов двухдневной давности, установив дату запрета на "текущий день минус 2 дня".

Автоматизация "Даты запрета изменения" с помощью регламентных заданий

Для случаев, когда нам нужна более сложная логика установки даты запрета, например, не просто "предыдущий день", а "текущий день минус N дней" (например, минус 2 или 3 дня, как было предложено в обсуждении), ручное передвижение даты становится проблемой. В этом случае мы можем автоматизировать процесс с помощью регламентных заданий.

Рассмотрим шаги по автоматизации:

1. Создание или модификация обработки: Нам потребуется обработка, которая будет программно изменять значение даты запрета. Эту обработку можно выполнять через регламентное задание. В обсуждении упоминается, что можно использовать внешнюю обработку или создать свою.
2. Программное изменение даты запрета: Мы можем получить текущее значение даты запрета, вычислить новую дату (например, ТекущаяДата() - 2 Дня) и установить ее. Для этого мы можем использовать функционал общих модулей, отвечающих за работу с датой запрета. В конфигурациях на управляемых формах часто используется регистр сведений ДатыЗапретаИзменения или аналогичный.
3. Пример кода для установки даты запрета (концептуально):
   Скопировать код

   
   // Предполагаем, что у нас есть функция, которая устанавливает дату запрета
   // в зависимости от конфигурации и версии платформы, это может быть вызов общего модуля
   // или работа напрямую с регистром.
           
   Функция УстановитьДатуЗапрета(НоваяДатаЗапрета)
           
       // Пример для работы с регистром сведений 'ДатыЗапретаИзменения' (может отличаться)
       РегистрДатыЗапрета = РегистрыСведений.ДатыЗапретаИзменения;
               
       // Получаем существующую запись (или создаем новую, если ее нет)
       ЗаписьДатыЗапрета = РегистрДатыЗапрета.СоздатьНаборЗаписей();
       ЗаписьДатыЗапрета.Прочитать();
               
       Если ЗаписьДатыЗапрета.Количество() > 0 Тогда
           ЗаписьДатыЗапрета[0].ДатаЗапрета = НоваяДатаЗапрета;
       Иначе
           НоваяЗапись = ЗаписьДатыЗапрета.Добавить();
           НоваяЗапись.ДатаЗапрета = НоваяДатаЗапрета;
           // Также могут быть поля типа "ВидЗапрета" или "ГраницаЗапретаПоПользователям"
       КонецЕсли;
               
       Попытка
           ЗаписьДатыЗапрета.Записать();
           Возврат Истина;
       Исключение Как Искл
           Сообщить("Ошибка при установке даты запрета: " + Искл.Описание, СтатусСообщения.Ошибка);
           Возврат Ложь;
       КонецПопытки;
   КонецФункции
           
   // В теле регламентного задания или обработки:
   НоваяДатаЗапрета = ТекущаяДата() - 2 * 86400; // Минус 2 дня в секундах
   // Или так: НоваяДатаЗапрета = ДобавитьКДате(ТекущаяДата(), День, -2);
           
   Если УстановитьДатуЗапрета(НоваяДатаЗапрета) Тогда
       Сообщить("Дата запрета изменена на " + Формат(НоваяДатаЗапрета, "ДФ=dd.MM.yyyy"), СтатусСообщения.Информация);
   КонецЕсли;
   

4. Настройка регламентного задания:
   • Перейдите в Администрирование -> Поддержка и обслуживание -> Регламентные задания.
   • Создайте новое регламентное задание или используйте существующее.
   • Укажите метод (процедуру или функцию из общего модуля или внешней обработки), который будет выполнять установку даты.
   • Настройте расписание выполнения, например, ежедневно в конце рабочего дня или ночью.

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

2. Управление правами доступа через роли: "Интерактивное изменение проведенных"

Одним из наиболее эффективных и современных способов запрета редактирования проведенных документов является использование специализированного права в ролях пользователя, появившегося в последних версиях платформы 1С:Предприятие 8.3. Это право называется Интерактивное изменение проведенных.

Рассмотрим, как это работает:

1. Поиск права: Перейдите в раздел Администрирование -> Настройки пользователей и прав -> Профили групп доступа. Откройте нужный профиль (или создайте новый), который назначен вашим сотрудникам, для которых мы хотим установить запрет. Далее, в списке ролей, которые входят в этот профиль, или при редактировании конкретной роли, мы найдем право Интерактивное изменение проведенных.
2. Действие права:
   • Если это право не установлено для роли пользователя, то он не сможет:
     • Удалить проведенный документ.
     • Установить пометку удаления на проведенный документ.
     • Перепровести проведенный документ.
     • Отменить проведение проведенного документа.
   • В этом случае форма проведенного документа будет открываться только в режиме просмотра. Пользователь сможет просмотреть данные и сформировать печатные формы, но любые попытки изменить данные, перепровести или отменить проведение будут заблокированы системой.
3. Дополнительные права:
   • Помимо Интерактивного изменения проведенных, существуют и другие права, такие как Проведение, Отмена проведения, Интерактивное проведение и Интерактивная отмена проведения, которые также влияют на работу с проведенными документами. Мы должны убедиться, что они настроены соответствующим образом, чтобы не создавать конфликтов или не давать излишних разрешений.
   • Для точечного ограничения доступа к определенным реквизитам документа на уровне ролей может потребоваться доработка конфигурации, так как типовой механизм RLS (Row-Level Security) в основном работает при чтении данных, а не при записи.

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

3. Использование расширений конфигурации

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

Рассмотрим возможности, которые могут предоставлять такие расширения:

1. Гибкие варианты запрета:
   • Не использовать: Отключение функционала запрета через расширение.
   • Использовать для всех документов: Запрет редактирования всех проведенных документов.
   • Использовать для выбранных видов документов: Мы можем указать конкретные виды документов (например, Реализация товаров и услуг, Приходный кассовый ордер), для которых будет действовать запрет.
2. Дополнительные условия запрета:
   • Некоторые расширения позволяют запрещать редактирование не только для всех документов определенного вида, но и по указанным авторам документов или для выбранных проведенных документов по указанным пользователям. Например, кассир не может редактировать свои же проведенные чеки, но старший кассир может.
   • Расширения могут включать режим "Только просмотр" для проведенных документов, позволяя просматривать данные и формировать печатные формы, но запрещая любые изменения, если документ проведен.
   • Существуют расширения, позволяющие запрещать изменение даты и номера документов в 1С для пользователей без специальных прав, что является важным аспектом контроля.
3. Преимущества расширений: Использование расширений позволяет нам добавлять новый функционал или изменять поведение существующих объектов без снятия конфигурации с поддержки, что значительно упрощает обновление системы.

При выборе расширения мы должны убедиться, что оно совместимо с нашей версией 1С Розница 2.2 и соответствует нашим требованиям безопасности и функциональности.

4. Блокировка документов по статусу

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

Рассмотрим, как мы можем настроить это:

1. Ограничение права на изменение проведенных объектов: Мы уже рассмотрели право Интерактивное изменение проведенных, которое является ключевым для этой стратегии. Убирая это право, мы запрещаем любые изменения проведенных документов.
2. Разрешение изменения непроведенных документов: При этом для тех же пользователей должно быть сохранено право на изменение и проведение непроведенных документов. Это позволяет сотрудникам создавать и редактировать документы до их окончательного утверждения и проведения.
3. Влияние на бизнес-процессы: Такая модель требует четко выстроенных бизнес-процессов, где проведение документа является актом окончательного утверждения, после которого изменения возможны только через корректирующие документы или со специальными разрешениями.

Эта стратегия является частью общего подхода к управлению данными и их целостностью, где статус документа (проведен/не проведен) определяет возможности пользователя по его изменению.

Важные аспекты, которые следует учитывать

При внедрении любых ограничений на редактирование проведенных документов нам необходимо помнить о следующих критически важных моментах:

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

Применяя эти методы и учитывая важные аспекты, мы сможем эффективно запретить редактирование проведенных документов в 1С Розница 2.2 для определенных сотрудников, обеспечив при этом корректность и надежность учета.