В розничной торговле мотивация персонала часто напрямую зависит от объема личных продаж. Однако в условиях интенсивного потока покупателей кассиры нередко забывают указывать конкретного продавца-консультанта в чеке, из-за чего продажи регистрируются на «Продавца по умолчанию» или на самого кассира. Это создает серьезные трудности для бэк-офиса при расчете бонусов и анализе эффективности сотрудников.
В рамках данной статьи мы подробно разберем, как технически реализовать механизм принудительного выбора продавца в интерфейсе Рабочего места кассира (РМК). Мы проанализируем различные способы вмешательства в логику программы: от блокировки добавления товара до финальной проверки перед пробитием чека.
Прежде чем приступать к программированию, кратко рассмотрим штатный механизм. В современных релизах 1С:Розница 2.3 и выше существует функционал «Личные продажи». В настройках магазина или профиля РМК можно активировать опцию использования личных продаж. Если не указывать продавца по умолчанию в настройках, система в некоторых случаях может запрашивать выбор сотрудника. Однако зачастую типовой логики недостаточно (например, нужно запретить любое действие до сканирования карты сотрудника), и тогда требуется кастомизация кода.
Рассмотрим ситуацию, когда кассир начинает работу со сканирования товара. Нам необходимо прервать этот процесс, если поле Продавец еще не заполнено. Для реализации этой логики нам потребуется внести изменения в обработку РМК. Выясним, какая процедура отвечает за обработку входящих данных от торгового оборудования.
В модуле формы обработки РМК найдем процедуру ОбработатьДанныеПОВФормеСервер. Нам нужно вставить проверку в блок, где происходит поиск товара. Рассмотрим пример кода:
ИначеЕсли СтруктураПараметров.Действие = "ПроверкаТоваров" Тогда
Если СтруктураПараметров.ЗначенияПоиска.Количество > 0 Тогда
// Начало вставки: проверка заполнения продавца
Если Не ЗначениеЗаполнено( Продавец ) Тогда
СтрокаСообщения = НСтр("ru = 'Не выбран продавец! '");
СтрокаСообщения = СтрокаСообщения + Символы.ПС + НСтр("ru = 'Набор нового чека начинайте с выбора продавца.'");
ВывестиИнформациюОбОшибке(СтрокаСообщения);
СтруктураПараметровКлиента.Вставить("ПрекратитьПоиск");
Возврат СтруктураПараметровКлиента;
КонецЕсли;
// Конец вставки
Если СтруктураПараметров.ЗначенияПоиска.Количество = 1 Тогда
// Далее стандартная логика добавления...
Этот код эффективно отсекает попытки добавить товар через сканер, если кассир предварительно не идентифицировал продавца (например, не считал его бейдж).
Опытные кассиры могут обходить проверку сканера, используя горячие клавиши или кнопку «Поиск» (Insert/F3). Чтобы закрыть эту «дыру», нам нужно модифицировать процедуры, отвечающие за интерактивное добавление строк в табличную часть Товары.
Проанализируем процедуру ТоварыПередНачаломДобавления. Добавим в нее аналогичный блок проверки в самое начало:
Процедура ТоварыПередНачаломДобавления(Элемент, Отказ, Копирование)
// Запрещаем добавление, если продавец не указан
Если Не ЗначениеЗаполнено( Продавец ) Тогда
Отказ = Истина;
СтрокаСообщения = НСтр("ru = 'Не выбран продавец! Пожалуйста, укажите сотрудника перед подбором товара.'");
ВывестиИнформациюОбОшибке(СтрокаСообщения);
Возврат;
КонецЕсли;
// Стандартная обработка серий и других параметров
ОбработкаТабличнойЧастиТоварыКлиент.ОбновитьКэшированныеЗначенияДляУчетаСерий(ЭлементыФормы.Товары, КэшированныеЗначения, ПараметрыУказанияСерий, Копирование);
КонецПроцедуры
Также не забудем про процедуру КнопкаПоискНажатие. Если пользователь нажимает кнопку поиска, форма подбора не должна открываться до момента выбора ответственного за продажу:
Процедура КнопкаПоискНажатие(Элемент)
Если Не ЗначениеЗаполнено( Продавец ) Тогда
ВывестиИнформациюОбОшибке("Не выбран продавец! Выбор товара заблокирован.");
Возврат;
КонецЕсли;
// Стандартный вызов формы поиска
СтруктураПараметровОткрытия = Новый Структура;
// ...
КонецПроцедуры
Если в магазине используются сенсорные панели с кнопками быстрого выбора популярных позиций, кассир может нажать на них. Чтобы предотвратить добавление товара в этом случае, найдем процедуру КоманднаяПанельБыстрыеТоварыТовар. Здесь также уместно вставить проверку перед вызовом функции ВыбратьНоменклатуру.
Важный нюанс: Вместо того чтобы дублировать код во многих местах, правильнее будет создать одну общую функцию-проверку в модуле формы, которая будет возвращать Истина или Ложь, и вызывать ее из всех обработчиков событий добавления товара.
Если специфика бизнеса позволяет указывать разных продавцов для разных строк чека, то блокировка при добавлении может быть неудобной. В этом случае целесообразно перенести проверку на этап завершения чека. Разберем, как реализовать контроль перед вызовом формы оплаты.
Нам потребуется процедура ОплатитьТовары. Вставим вызов проверки после проверки состояния кассовой смены:
Процедура ПроверитьЗаполнениеПоляСотрудник(Отказ)
ТекстОшибки = "";
Для каждого СтрокаТовары из Товары Цикл
Если СтрокаТовары.Продавец.Пустая() Тогда
ТекстОшибки = ТекстОшибки + "В строке №" + СтрокаТовары.НомерСтроки + " не указан продавец!" + Символы.ПС;
Отказ = Истина;
КонецЕсли;
КонецЦикла;
Если Отказ Тогда
ВывестиИнформациюОбОшибке("Оплата невозможна:" + Символы.ПС + ТекстОшибки);
КонецЕсли;
КонецПроцедуры
Этот метод считается наиболее «мягким», так как он не тормозит процесс сканирования, но гарантирует, что к моменту фискализации документа все данные будут заполнены корректно.
Для тех, кто до сих пор использует первую версию программы (на обычных формах), логика может быть внедрена непосредственно в процедуру открытия формы регистрации или при создании нового чека. Посмотрим на пример кода в процедуре УстановитьНомерЧекаПриОткрытии:
Если Не ЗначениеЗаполнено(Продавец) Тогда
Пока ПустаяСтрока(Продавец) Цикл
Предупреждение("Введите штрихкод продавца");
Результат = РаботаСТорговымОборудованием.ВвестиШтрихкод();
РаботаСТорговымОборудованием.ОбработатьВведенныйШтрихкод(Результат, ЭтаФорма, Истина);
КонецЦикла;
КонецЕсли;
Данный код создает бесконечный цикл до тех пор, пока кассир не предоставит корректный идентификатор сотрудника. Будьте осторожны с этим методом, так как он может «завесить» РМК, если у кассира возникнут проблемы со считыванием карты.
Мы проанализировали основные точки входа для модификации РМК. Выбор конкретного метода (блокировка «на лету» или проверка перед оплатой) зависит от бизнес-процессов вашего магазина и требований руководства к скорости обслуживания клиентов.