Как временно наделить РМК правами администратора для корректировки данных без перезапуска 1С:Розница 2.3?

Программист 1С v8.3 (Управляемые формы) 1С:Розница Управленческий учет Торговля и дистрибуция
← На главную

При работе в розничной торговле часто возникает ситуация, когда кассиру, работающему в Рабочем месте кассира (РМК), необходимо вызвать администратора для выполнения корректирующих операций, таких как исправление ошибочно пробитого чека или других административных действий. При этом стандартно кассир обладает ограниченными правами, а администратор – полными. Задача заключается в том, чтобы дать возможность администратору временно получить расширенные права на РМК кассира для выполнения корректировок, не требуя выхода кассира из системы и перезапуска программы.

Стандартный подход к управлению правами доступа в 1С:Предприятии 8.3 подразумевает назначение пользователям определенных ролей и профилей групп доступа. Эти настройки обычно выполняются в режиме "Конфигуратор" или в разделе "Администрирование" и требуют перезапуска программы или повторного входа пользователя для полного вступления изменений в силу. Однако, в условиях динамичной розничной торговли, перезапуск РМК для каждой корректировки крайне неудобен и замедляет работу.

Давайте рассмотрим, как можно решить эту проблему, используя программные механизмы платформы 1С.

Ограничения стандартного подхода

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

  1. Необходимость перезапуска: Изменения в правах доступа, присвоенных пользователю через роли или профили групп доступа, вступают в силу только после перезапуска сеанса пользователя. Это означает, что для получения административных прав придется выйти из РМК и войти снова, что прерывает работу.
  2. Неправильная логика прав: Чтобы пользователь (кассир) мог сам себе изменить права или чтобы система могла временно 'назначить' ему другие роли, у этого пользователя должно быть право на изменение собственных настроек доступа. Это является в корне неправильным с точки зрения безопасности, так как предоставляет кассиру потенциальную возможность получить неограниченный доступ к системе.

Таким образом, мы понимаем, что прямое переназначение ролей не является рабочим или безопасным решением для нашей задачи.

Программно-реализованное повышение прав: детальное решение

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

Шаг 1: Предоставление расширенных прав кассиру на уровне ролей

В начале мы предоставляем пользователю-кассиру более широкие права, чем обычно требуются для его повседневной работы. Например, включаем в его профиль те роли, которые необходимы администратору для корректировки данных (например, возможность изменения документов, проведения чеков коррекции). На первый взгляд это может показаться нарушением безопасности, но ключевая особенность этого метода заключается в следующем шагом.

Шаг 2: Программное урезание прав кассира

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

Например, в модулях форм РМК или общих модулях, отвечающих за работу РМК, мы можем добавить проверки:


Если РольДоступна("Кассир") Тогда
    // Скрываем или отключаем кнопки для административных операций
    ЭлементыФормы.КнопкаКорректировкаЧека.Доступность = Ложь;
    ЭлементыФормы.ПолеАдминистратора.Видимость = Ложь;
    // Блокируем выполнение определенных команд
    ОтменитьСтандартнуюОбработку = Истина;
    СообщениеПользователю("У вас нет прав для выполнения этой операции.");
КонецЕсли;

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

Шаг 3: Реализация механизма запроса пароля администратора

Когда требуется выполнить административную операцию, например, корректировку чека, система должна запросить подтверждение от администратора. Мы создаем процедуру запроса пароля, которую можем разместить, например, в общем модуле или в модуле формы РМК.

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

Шаг 4: Временное снятие программных ограничений

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

  1. Использование глобальной переменной сеанса: Мы можем установить глобальную переменную сеанса (например, ПараметрыСеанса.АдминистраторАктивен = Истина). В наших проверках функционала мы теперь будем учитывать эту переменную:
  2. 
    Если РольДоступна("Кассир") И Не ПараметрыСеанса.АдминистраторАктивен Тогда
        // Ограничения для кассира
        ЭлементыФормы.КнопкаКорректировкаЧека.Доступность = Ложь;
    Иначе
        // Разрешенные действия для администратора
        ЭлементыФормы.КнопкаКорректировкаЧека.Доступность = Истина;
    КонецЕсли;
    
  3. Внутри одной процедуры: Если административные действия ограничены одной конкретной процедурой (например, корректировкой одного чека), мы можем просто выполнять код администратора внутри блока Если после успешной проверки пароля, не меняя глобальные флаги.
  4. 
    Процедура КорректироватьЧекНаСервере()
        Если Не ЗапроситьПарольАдминистратора() Тогда
            Возврат;
        КонецЕсли;
    
        // Здесь выполняем код корректировки чека, доступный только после ввода пароля
        // ...
    КонецПроцедуры;
    

Важно помнить, что снятие ограничений должно быть временным и четко контролируемым. После выполнения административной операции или по истечении заданного времени (например, 5-10 минут), флаг "администратор активен" должен быть сброшен, и ограничения должны снова вступить в силу.

Шаг 5: Корректировка чеков и фискальных данных

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

  1. "Чек коррекции": Используется в случаях, когда не удалось применить онлайн-кассу при расчетах, или были допущены ошибки в работе с ККТ. Он позволяет скорректировать данные о приходе/расходе.
  2. "Возврат прихода": Применяется, если необходимо полностью отменить операцию продажи и затем провести ее заново с правильными данными.

Администратор, используя временно расширенные права, сможет создавать, изменять и проводить эти документы коррекции, пробивая их через ККТ, если это предусмотрено законодательством и настройками ФФД (Формата Фискальных Данных). Для массового исправления ошибок подойдёт обработка для формирования чеков коррекции за период в 1С:Розница 2.3.

Примерная структура кода для запроса пароля и использования прав

Рассмотрим пример, как это может выглядеть в коде.

Общий модуль (например, УправлениеПравамиРМК)


// В общем модуле, например "УправлениеПравамиРМК"
// Процедура для запроса пароля администратора
Функция ПроверитьПарольАдминистратора(Пароль) Экспорт
    // Здесь должна быть ваша логика проверки пароля.
    // Это может быть проверка с системным пользователем,
    // или с заранее определенным паролем, хранящимся где-либо безопасно.
    // Пример: простой пароль для демонстрации
    Если Пароль = "admin123" Тогда
        Возврат Истина;
    Иначе
        Возврат Ложь;
    КонецЕсли;
КонецФункции;

// Функция для получения флага активности администратора
Функция АдминистраторАктивен() Экспорт
    Если ПараметрыСеанса.Свойство("АдминистраторАктивен") Тогда
        Возврат ПараметрыСеанса.АдминистраторАктивен;
    Иначе
        Возврат Ложь;
    КонецЕсли;
КонецФункции;

// Процедура для установки/сброса флага активности администратора
Процедура УстановитьАктивностьАдминистратора(Значение) Экспорт
    ПараметрыСеанса.АдминистраторАктивен = Значение;
КонецПроцедуры;

Форма запроса пароля (например, ОбщаяФорма.ЗапросПароляАдминистратора)

Эта форма будет содержать поле для ввода пароля и кнопку "ОК".


// В модуле формы "ЗапросПароляАдминистратора"
// Переменная для результата
Перем мПарольВведен;

Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    мПарольВведен = Ложь;
КонецПроцедура;

Процедура ОКНажатие(Команда)
    Если УправлениеПравамиРМК.ПроверитьПарольАдминистратора(Элементы.ПолеПароль.Значение) Тогда
        мПарольВведен = Истина;
        Закрыть();
    Иначе
        СообщениеПользователю("Неверный пароль администратора.");
    КонецЕсли;
КонецПроцедуры;

Функция ПарольВведен() Экспорт
    Возврат мПарольВведен;
КонецФункции;

Модуль формы РМК (например, ФормаРМК.МодульФормы)


// В модуле формы РМК
Процедура ПриОткрытии()
    ОбновитьВидимостьИДоступностьЭлементов();
КонецПроцедуры;

Процедура ПослеЗаписи()
    ОбновитьВидимостьИДоступностьЭлементов();
КонецПроцедуры;

Процедура ОбновитьВидимостьИДоступностьЭлементов()
    // Предполагаем, что есть кнопка для корректировки чека
    Если РольДоступна("Кассир") И Не УправлениеПравамиРМК.АдминистраторАктивен() Тогда
        Элементы.КнопкаКорректировкаЧека.Доступность = Ложь;
        Элементы.КнопкаКорректировкаЧека.Видимость = Ложь;
        // ... другие ограничения
    Иначе
        Элементы.КнопкаКорректировкаЧека.Доступность = Истина;
        Элементы.КнопкаКорректировкаЧека.Видимость = Истина;
        // ... другие разрешения
    КонецЕсли;
КонецПроцедуры;

Процедура КнопкаКорректировкаЧекаНажатие(Команда)
    Если Не УправлениеПравамиРМК.АдминистраторАктивен() Тогда
        // Запрашиваем пароль, если администратор не активен
        ФормаВводаПароля = ОткрытьФорму("ОбщаяФорма.ЗапросПароляАдминистратора");
        Если ФормаВводаПароля.ПарольВведен() Тогда
            УправлениеПравамиРМК.УстановитьАктивностьАдминистратора(Истина);
            // Устанавливаем таймер для автоматического сброса активности администратора
            ПодключитьОбработчикОжидания("СброситьАктивностьАдминистратора", 300, Истина); // Через 300 секунд (5 минут)
            ОбновитьВидимостьИДоступностьЭлементов(); // Обновим интерфейс
        Иначе
            СообщениеПользователю("Операция отменена. Пароль администратора не введен.");
            Возврат;
        КонецЕсли;
    КонецЕсли;

    // Если администратор активен (или только что ввел пароль), выполняем корректировку
    ВыполнитьКорректировкуЧека();
КонецПроцедура;

Процедура ВыполнитьКорректировкуЧека()
    // Здесь размещаем логику корректировки чека
    // Например, открытие формы документа "Чек коррекции"
    СообщениеПользователю("Выполняем корректировку чека...");
    // ...
КонецПроцедуры;

Процедура СброситьАктивностьАдминистратора()
    УправлениеПравамиРМК.УстановитьАктивностьАдминистратора(Ложь);
    ОтключитьОбработчикОжидания("СброситьАктивностьАдминистратора");
    ОбновитьВидимостьИДоступностьЭлементов(); // Обновим интерфейс
    СообщениеПользователю("Режим администратора отключен по истечении времени.");
КонецПроцедуры;

Этот пример демонстрирует базовый подход. В реальной системе потребуется более сложная логика для проверки паролей (например, по пользователям ИБ), более гранулярное управление состоянием "администратор активен" и более надежный механизм сброса активности.

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

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

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

Рекомендации по безопасности

При реализации механизмов временного повышения прав крайне важно уделить внимание вопросам безопасности:

  1. Не давайте кассиру право на изменение своих прав: Мы уже обсудили, что предоставление кассиру возможности изменять собственные настройки доступа является фундаментально неправильным и открывает путь к несанкционированному доступу. Наша программная реализация должна обходить это правило, а не нарушать его.
  2. Хранение и проверка паролей: Если вы используете собственный механизм проверки паролей (не через системных пользователей 1С), убедитесь, что пароли хранятся в зашифрованном виде или через хеширование, а их проверка выполняется безопасно. Избегайте хранения паролей в открытом виде в коде или константах.
  3. Время активности администратора: Сделайте период активности административного режима максимально коротким или привяжите его к одной конкретной операции. Автоматический сброс активности (например, через таймер) предотвратит злоупотребления, если администратор отойдет от РМК.
  4. Аудит операций: Все административные корректировки, выполненные после ввода пароля, должны быть зафиксированы в журнале регистрации с указанием, кто (кассир) и когда (администратор) выполнил операцию. Это повышает прозрачность и ответственность.

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

← На главную