Почему 1С пробивает фискальный чек, но не списывает деньги через эквайринговый терминал?

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

Разберем подробнее механизм возникновения этой ошибки, методику ее диагностики по логам драйвера эквайринга и способы устранения проблемы на программном и административном уровнях.

Диагностика через журналы драйвера эквайринга

Для того чтобы точно выяснить, отправляла ли 1С команду на терминал и какой ответ был получен от банковского сервиса, проанализируем системные логи драйвера Сбербанка (взаимодействие с терминалами VeriFone, Ingenico и др.).

По умолчанию компонента эквайринга формирует служебные файлы на системном диске в каталоге C:\sc552 (или C:\sc52). В этой папке находятся файлы журналов, в которых фиксируются все транзакции и коды их возврата.

Рассмотрим основные коды операций, которые передаются терминалу:

1. 4000 — операция оплаты (покупка);
2. 4002 — операция возврата средств на карту;
3. 4003 — отмена предыдущей операции авторизации.

При штатной успешной операции лог фиксирует строку вида:

Result = 0, Amount = 150.00, Card = '42**********74'

Значение Result = 0 свидетельствует об успешном завершении банковской авторизации.

Если списание не произошло, в журнале может быть зафиксирована ошибка. Например:

Result = 2000 — операция прервана нажатием клавиши «ОТМЕНА» (на пинпаде или в интерфейсе программы);

Result = 4117 — клиент отказался от ввода PIN-кода на терминале.

Причина ошибки: сбой в логике обработки формы оплаты 1С

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

1. Кассир открывает окно приема оплаты в документе (например, Чек, Розничные продажи (чек) или в РМК) и нажимает кнопку оплаты картой.
2. 1С посылает команду 4000 на банковский терминал.
3. Покупатель или кассир нажимает клавишу отмены (на пинпаде или в диалоговом окне 1С), либо происходит сбой связи. Терминал возвращает код ошибки (например, 2000 или 4117).
4. В интерфейсной форме 1С строка с безналичной оплатой на заданную сумму остается зафиксированной в табличной части оплат, но флаг необходимости повторного обращения к драйверу эквайринга сбрасывается.
5. Кассир повторно нажимает «Пробить чек» или «Принять оплату». Программа считает, что безналичная оплата уже получена (или оформлена автономно), и отправляет команду только на онлайн-кассу (ККТ).
6. Фискальный чек пробивается со способом расчета «Безналичными», а на терминал запрос не отправляется. Покупатель уходит с чеком, не заплатив за покупку.

Программные способы решения

Для гарантированного исключения ситуаций, когда чек фискализируется без подтвержденной транзакции эквайринга, применяются доработки типовой конфигурации через расширение или изменение модуля БПО (Библиотеки подключаемого оборудования).

1. Валидация банковских реквизитов перед фискализацией

Перед отправкой чека на печать в ККТ необходимо проверять наличие обязательных параметров успешно завершенной транзакции эквайринга: ссылочного номера (RRN) и Кода авторизации. Если оплата указана как безналичная, но реквизиты авторизации отсутствуют или пусты, пробитие чека блокируется.

Посмотрим на пример логики проверки в обработчике перед пробитием чека:

Для Каждого СтрокаОплаты Из Объект.Оплата Цикл
    Если СтрокаОплаты.ТипОплаты = Перечисления.ТипыОплатЧекаККМ.Безналичные Тогда
        Если ПустаяСтрока(СтрокаОплаты.НомерЧекаЭТ) Или ПустаяСтрока(СтрокаОплаты.КодАвторизации) Тогда
            ВызватьИсключение "Оплата по банковской карте не была подтверждена терминалом! Повторите операцию авторизации.";
        КонецЕсли;
    КонецЕсли;
КонецЦикла;

2. Принудительная очистка табличной части оплат при отказе

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

Настройка оборудования и регламентные меры

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

1. Отключение автономного режима эквайринга: В настройках рабочего места и прав кассира исключите возможность ручного выбора безналичной оплаты в обход подключенного терминала.
2. Настройка энергосбережения USB-портов: В диспетчере устройств Windows для USB-концентраторов и виртуальных COM-портов терминала снимите флаг «Разрешить отключение этого устройства для экономии энергии», чтобы исключить потерю связи с терминалом при простое.
3. Увеличение таймаута ожидания: В параметрах драйвера эквайринга увеличьте время ожидания ответа от терминала (до 60–90 секунд), чтобы предотвратить ложные прерывания транзакций при медленной связи или задержке ввода PIN-кода.
4. Инструктаж персонала: Кассир обязан проверять обязательную печать слип-чека эквайринга. Если вышел только кассовый чек без слипа, операция не может считаться завершенной, и товар не должен выдаваться покупателю.