← На главную
В розничной торговле нередко возникает неприятная ситуация: кассир открывает в рабочем месте кассира (РМК) возврат по чеку одного покупателя, а к эквайринговому терминалу прикладывает карту совершенно другой клиент, стоящий у кассы. В итоге операция успешно завершается, а деньги с торговой точки списываются на карту случайного человека. Разберем детально, почему типовая конфигурация 1С:Управление торговлей 11 допускает подобное действие, как работает связка программы с банковским оборудованием и какими организационно-техническими мерами можно исключить человеческий фактор.
Архитектура безопасности: почему 1С не проверяет номер банковской карты
Первый вопрос, который возникает у руководства: почему программа 1С не выдала предупреждение о том, что приложена карта другого клиента? Выясним причину такого поведения системы.
Согласно международным стандартам безопасности данных индустрии платежных карт (PCI DSS), учетная система не имеет права принимать, обрабатывать и хранить критические платежные данные клиентов. К ним относятся полный номер карты (PAN), срок действия и секретные коды CVV/CVC. В информационную базу 1С:УТ 11 записываются только открытые реквизиты завершенной транзакции:
- Маскированный номер карты (например,
* 1234). - Уникальный ссылочный номер транзакции (RRN).
- Код авторизации банка.
- Сумма и идентификатор терминала.
Когда кассир нажимает кнопку возврата, механизм БПО (Библиотеки подключаемого оборудования) передает драйверу эквайрингового терминала команду на проведение операции и сумму. Непосредственное чтение микрочипа карты, бесконтактного модуля NFC, шифрование данных и отправка запроса в процессинговый центр происходят целиком внутри терминала. Конфигурация 1С физически не видит полный номер карты в момент прикладывания и не может программно сопоставить его с оригинальным покупателем.
Типы транзакций на терминале: «Отмена» против «Возврата»
Поведение оборудования в момент прикладывания карты напрямую зависит от того, какую банковскую операцию инициирует терминал. Проанализируем два базовых сценария:
- Отмена операции (Void): выполняется внутри текущей кассовой и банковской смены (до закрытия смены и сверки итогов). Терминал отправляет в банк команду на аннулирование исходного холда/списания по номеру RRN. В зависимости от настроек банка при «Отмене» терминал либо вообще не просит прикладывать карту, либо сверяет внутренний хеш карты и при несовпадении выдает отказ.
- Возврат (Refund): представляет собой самостоятельную финансовую операцию перечисления денег из банка торговой точки на счет клиента. Она применяется по умолчанию после сверки итогов (закрытия банковского дня), а на некоторых прошивках терминалов — даже в течение смены. При финансовом возврате банковское ПО по умолчанию готово принять любую валидную карту.
Такое поведение не считается сбоем программы. В розничной практике карта клиента на момент возврата может быть утеряна, заблокирована банком или перевыпущена с другим номером (при сохранении того же банковского счета), поэтому жесткая аппаратная блокировка включена далеко не всегда.
Настройка контроля карт на стороне банка-эквайера
Если специфика бизнеса требует строгой защиты от подмены карты, эту задачу необходимо решать на уровне банковского терминала, а не доработкой конфигурации 1С. Рассмотрим действия для реализации такого контроля:
- Обращение в техническую поддержку эквайера: необходимо направить запрос в обслуживающий банк с просьбой активировать в профиле терминала опцию «Контроль карты при возврате» (название параметра может отличаться в зависимости от процессинга банка).
- Загрузка новой конфигурации в терминал: после включения флага специалист банка или кассир выполняет операцию «Загрузка параметров» / «Сверка итогов» на терминале.
- Приоритет отмены внутри дня: убедитесь совместно с инженером банка, что при возврате чека «день в день» драйвер эквайринга выполняет транзакцию отмены (Void), требующую совпадения исходных реквизитов платежа.
После включения контроля терминал при попытке приложить чужую карту выдаст ошибку авторизации и прервет операцию, не допуская списания средств.
Исключение человеческого фактора средствами 1С:УТ 11
Главная причина описанного инцидента — ошибка кассира, который выбрал в интерфейсе чек не того покупателя. В конфигурации 1С:Управление торговлей 11 есть штатные инструменты, позволяющие предотвратить подобные инциденты на организационном уровне:
- Возврат строго по сканированию чека: запретите кассирам искать чеки вручную через общий список чеков смены в РМК. Если настроить процесс так, чтобы чек возврата создавался исключительно путем считывания штрихкода (или QR-кода) со зримого бумажного чека клиента с помощью 2D-сканера, вероятность возврата по чеку другого человека исключается.
- Ограничение прав кассиров: в настройках дополнительных прав пользователей или профилей групп доступа отключите кассирам возможность проводить возвраты самостоятельно. Настройте обязательное подтверждение операции картой старшего кассира или администратора магазина.
- Регламент возврата на другую карту: при утере карты или ее перевыпуске возврат должен производиться не через быстрое меню РМК, а по официальному заявлению клиента с паспортом через документ
Возврат товаров от клиента и безналичное Списание безналичных ДС с расчетного счета.
Что делать, если ошибочный возврат уже произошел
Разберем порядок действий, если инцидент уже случился и деньги ушли клиенту А вместо клиента Б:
- Кассовый учет: если смена еще не закрыта, проанализируйте остатки и взаиморасчеты. Чтобы закрыть обязательства перед клиентом Б, потребуется корректно оформить его фактический возврат, а по ошибочной операции оформить исправительные чеки (или чек коррекции, если смена уже закрыта).
- Работа с клиентом: денежные средства, ошибочно поступившие на карту клиента А, с точки зрения гражданского законодательства являются неосновательным обогащением. Администрации магазина необходимо оперативно связаться с клиентом А, объяснить ситуацию и запросить повторную оплату через терминал либо добровольный возврат средств на расчетный счет торговой точки.