В розничной торговле безопасность данных и контроль за действиями персонала играют решающую роль. Администраторы систем на базе 1С часто сталкиваются с дилеммой: с одной стороны, необходимо максимально урезать права продавцов-кассиров, чтобы исключить возможность изменения проведенных документов задним числом и предотвратить злоупотребления; с другой стороны, при жестком ограничении прав встроенные механизмы закрытия смены в Рабочем месте кассира (РМК) начинают давать сбои. В журнале регистрации лавинообразно появляются ошибки «Доступ. Отказ в доступе», связанные с документом ОтчетОРозничныхПродажах, а в худшем случае транзакция закрытия смены полностью блокируется.
В этой статье мы подробно проанализируем причины возникновения этой проблемы в конфигурации «1С:Управление торговлей 11» (а также в «1С:Комплексная автоматизация» и «1С:ERP»), разберем разницу между интерактивными и программными действиями и рассмотрим несколько надежных практических способов настройки системы, которые позволят защитить ваш бизнес без ущерба для стабильности программы.
Для начала разберем по шагам, что происходит в системе в тот момент, когда продавец нажимает кнопку «Закрыть смену» в интерфейсе РМК:
ОтчетОРозничныхПродажах (ОРП).Коллизия прав доступа возникает на третьем этапе. Платформа 1С строго разграничивает операции проведения. Проведение считается оперативным только в том случае, если документ проводится текущей секундой реального времени сервера. Однако закрытие смены зачастую происходит в самом конце рабочего дня (или даже после полуночи, когда дата смены формально уже прошла). В этот момент время создаваемого документа ОРП может не совпадать с текущим временем сервера, и платформа расценивает попытку проведения как неоперативную. Для успешного выполнения этой операции кассиру требуется право Неоперативное проведение.
Более того, в процессе работы алгоритма закрытия смены документ ОтчетОРозничныхПродажах может записываться и проводиться несколько раз (например, сначала проводится сам документ, а затем в него дописываются данные об эквайринговых операциях или архивных чеках). Повторная запись уже проведенного документа требует права Изменение проведенных. Если администратор безопасности заблокировал эти права в роли кассира, система выдает ошибку доступа в Журнале регистрации.
Самый простой и правильный способ решить проблему штатными средствами — это точечная настройка прав в конфигураторе без изменения кода. Разработчики платформы 1С предусмотрели разделение прав на программные (которые выполняются кодом системы от имени пользователя) и интерактивные (которые пользователь совершает вручную мышкой в интерфейсе).
Чтобы система могла беспрепятственно закрывать смену, а кассир при этом не имел физической возможности зайти в список документов и изменить ОРП, выполним следующую настройку роли кассира:
Общие -> Роли и найдем роль, назначенную вашим продавцам (например, ДобавлениеИзменениеЧековККМ или специализированную роль кассира).ОтчетОРозничныхПродажах.Изменение, Проведение, Отмена проведения. Это позволит фоновому коду РМК успешно создавать и проводить документ при закрытии смены.Интерактивное изменение проведенных, Интерактивная отмена проведения, Интерактивное неоперативное проведение, Интерактивное проведение и Интерактивная пометка на удаление.После обновления конфигурации базы данных фоновые транзакции РМК будут проходить без единой ошибки. При этом, если продавец попытается открыть проведенный ОтчетОРозничныхПродажах через стандартный интерфейс и нажать кнопку «Записать» или «Распровести», платформа мгновенно заблокирует это действие, выдав предупреждение о недостатке прав.
Если корпоративная политика безопасности вашей организации категорически запрещает давать роли кассира любые права на изменение и проведение документов типа ОтчетОРозничныхПродажах (даже программные), нам на помощь придет механизм расширений и **привилегированный режим**.
Привилегированный режим позволяет выполнять программный код без проверки прав доступа текущего пользователя. Это идеальное решение: у кассира вообще нет прав на ОРП, но система при закрытии смены временно «повышает» его права до уровня администратора для успешного выполнения транзакции.
Создадим расширение конфигурации и перехватим процедуру записи и проведения документа. Рассмотрим пример реализации кода в модуле расширения:
&ВОбходе
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Включаем привилегированный режим для обхода ограничений прав текущего пользователя
УстановитьПривилегированныйРежим(Истина);
// Проверяем, включен ли режим успешно
Если ПривилегированныйРежим() Тогда
// Здесь выполняется системный код проведения Отчета о розничных продажах
// Платформа проигнорирует ограничения роли кассира
КонецЕсли;
КонецПроцедуры
Использование привилегированного режима гарантирует, что ручные манипуляции кассира с документом будут невозможны на уровне платформы, но автоматическое закрытие смены отработает безупречно.
Для дополнительной гарантии безопасности мы можем заблокировать возможность редактирования документа непосредственно в его интерфейсной форме. Даже если у пользователя есть базовые права, форма документа откроется для него исключительно в режиме просмотра.
Реализуем это с помощью расширения для формы документа ОтчетОРозничныхПродажах. Разберем по шагам код обработчика события ПриСозданииНаСервере:
&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверим, обладает ли текущий пользователь правами администратора или супервайзера
Если НЕ РольДоступна("ПолныеПрава") И НЕ РольДоступна("ЧтениеПросмотрВсехДокументов") Тогда
// Блокируем форму для редактирования кассиром
ЭтаФорма.ТолькоПросмотр = Истина;
// Дополнительно скрываем критически важные кнопки, если это необходимо
ЭтаФорма.Элементы.ФормаПровестиИЗакрыть.Доступность = Ложь;
ЭтаФорма.Элементы.ФормаПровести.Доступность = Ложь;
ЭтаФорма.Элементы.ФормаОтменаПроведения.Доступность = Ложь;
КонецЕсли;
КонецПроцедуры
Такой подход обеспечивает наглядность: пользователь сразу видит, что документ закрыт для редактирования. Все поля становятся серыми, кнопки проведения пропадают, что исключает любые попытки случайного или намеренного искажения данных.
Профессиональное построение системы учета требует использования встроенных сервисных механизмов БСП (Библиотеки Стандартных Подсистем), которые дополняют настройки прав доступа.
Во-первых, настроим Дату запрета изменения данных.
Этот инструмент позволяет жестко ограничить редактирование любых документов прошлыми датами. Рекомендуется установить автоматический сдвиг даты запрета. Например, настроить правило «Запретить изменения с разницей в 1 день» для профиля кассиров. В таком случае, даже если у кассира останутся какие-то права на изменение документов текущего дня, он никогда не сможет вернуться к отчетам за прошлую неделю или месяц, чтобы «подчистить» остатки или изменить суммы продаж.
Во-вторых, включим Версионирование объектов.
Версионирование — это инструмент тотального контроля изменений. Перейдем в раздел Администрирование -> Поддержка и обслуживание -> Версионирование объектов и включим историю изменений для документа Отчет о розничных продажах в режиме «Версионировать при записи».
Проанализируем преимущества этого механизма:
Наличие включенного версионирования само по себе является мощным психологическим фактором для персонала, сводящим к минимуму желание совершать махинации в учетной системе.
Мы подробно разобрали причины коллизии прав доступа при закрытии смены в 1С. Для создания надежной и защищенной системы рекомендуем использовать комбинированный подход:
ТолькоПросмотр = Истина для всех пользователей с ролью продавца.Эти меры позволят полностью устранить ошибки в Журнале регистрации, обеспечат стабильную работу кассы в конце смены и надежно защитят ваши торговые данные от несанкционированного вмешательства.