Как правильно реализовать возврат по эквайрингу в программах 1С: выбор между отменой и возвратом

← На главную

При разработке функционала для работы с банковскими терминалами (эквайрингом) программисты 1С неизбежно сталкиваются с вопросом: какую операцию инициировать на терминале при оформлении возврата товара — отмену (Void) или возврат (Refund)? От правильного выбора зависит не только скорость поступления денег клиенту, но и сумма банковской комиссии, которую заплатит торговая точка. Рассмотрим подробно, как реализовать этот механизм, разберем технические нюансы и требования законодательства.

Понятийный аппарат: VOID против REFUND

Для начала проанализируем ситуацию с точки зрения банковских процессов. Существует два принципиально разных типа операций, которые в пользовательском интерфейсе 1С часто объединяются под общим словом «Возврат»:

Отмена операции (VOID): Эта процедура возможна только до выполнения операции «Сверка итогов» (закрытия смены на терминале). Когда покупатель оплачивает товар, деньги на его карте не списываются мгновенно, а «холдируются» (блокируются). Если мы делаем отмену до закрытия смены, банк просто снимает блокировку, и деньги становятся доступны клиенту практически сразу. Для магазина это выгодно, так как транзакция не попадает в окончательный клиринг, и комиссия за эквайринг обычно не взимается.
Возврат (REFUND): Данная операция выполняется после того, как смена была закрыта и данные ушли в банк-эквайер. В этом случае деньги уже физически покинули счет покупателя и находятся в процессе зачисления на счет продавца. Чтобы вернуть их, инициируется новая транзакция. Деньги могут идти до 30 дней (зависит от банка-эмитента), а комиссия за первоначальную продажу магазину не возвращается.

Алгоритм выбора операции в коде 1С

Разберем, как реализовать логику выбора в программе. Оставлять этот выбор на откуп кассиру — не самое удачное решение, так как это ведет к человеческим ошибкам и лишним затратам на комиссии. Проанализируем наиболее эффективную стратегию автоматизации:

Шаг 1: Проверка текущей смены. Программа должна проверить, был ли пробит чек продажи в текущей кассовой смене. Если смена еще не закрыта, приоритетной операцией должна быть «Отмена».

Шаг 2: Попытка выполнения отмены. Мы отправляем на терминал команду отмены. Важно помнить, что для этого терминалу почти всегда требуется уникальный идентификатор транзакции — RRN (Retrieval Reference Number) или номер чека из самого терминала. Эти данные должны быть сохранены в базе 1С в момент совершения продажи.

Шаг 3: Обработка отказа и переход к возврату. Если терминал возвращает ошибку (например, «Транзакция не найдена», что часто бывает, если сверка итогов уже прошла), программа должна автоматически или через подтверждение кассира переключиться в режим «Возврат».

Пример логической структуры кода для взаимодействия с терминалом (условно):


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

Особенности работы с интегрированными терминалами Сбербанка

Рассмотрим специфику самого популярного решения — библиотеку Pilot.exe от Сбербанка. В интегрированных решениях кассир не может вручную нажать кнопку на терминале, все команды идут из 1С. Для выполнения отмены вам обязательно потребуется передать правильные параметры в метод 1С-обработки, которая взаимодействует с драйвером. Если вы не сохранили RRN при продаже, сделать «Отмену» программно будет крайне сложно.

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

Фискализация: требования 54-ФЗ

Выясним причину, по которой нельзя путать банковскую операцию и кассовый чек. С точки зрения налоговой и 54-ФЗ, как бы ни прошла операция по терминалу (как VOID или как REFUND), по кассовому аппарату (ККТ) всегда должен пройти документ с признаком расчета «Возврат прихода».

Ни в коем случае нельзя пытаться делать «аннулирование» чека или просто удалять его из базы. Фискальный накопитель должен зафиксировать обратный поток денежных средств. При этом способ оплаты в чеке возврата должен соответствовать способу оплаты в чеке продажи — «Безналичными».

Проблема токенизации (Mir Pay, Apple Pay, СБП)

Проанализируем ситуацию, упомянутую в обсуждении: покупатель платит телефоном, а при возврате прикладывает физическую карту. В современных реалиях (использование токенов) номер карты в телефоне не совпадает с номером на пластике. Если вы инициируете Отмену, терминал может выдать ошибку «Оригинальная операция не найдена», так как он ищет транзакцию по конкретному номеру (токену).

В таких случаях рекомендуется:

Просить клиента прикладывать именно то устройство, которым совершалась оплата.
Если устройство недоступно, использовать операцию «Возврат», которая позволяет выполнить транзакцию без жесткой привязки к ID исходной операции (хотя это зависит от политики безопасности конкретного банка).

Безопасность и транзакционность в коде

Посмотрим на ситуацию со стороны надежности системы. Самая опасная ошибка программиста — когда терминал успешно вернул деньги клиенту, а 1С «упала» или потеряла связь, не пробив фискальный чек. В итоге: у клиента деньги, у магазина — недостача по Z-отчету и нарушение кассовой дисциплины.

Правильная последовательность действий в коде должна быть следующей:

Блокировка интерфейса кассира.
Вызов команды терминала.
Получение и обязательная запись ответа терминала (RRN, номер слип-чека) в информационную базу.
Печать фискального чека на ККТ.
В случае ошибки на шаге 4 — запись лога для администратора, чтобы он мог пробить чек коррекции или вручную завершить процесс, не повторяя запрос к терминалу (иначе деньги спишутся/вернутся дважды).

Использование штатных механизмов БПО (Библиотеки подключаемого оборудования) от 1С значительно упрощает эту задачу, так как там основные сценарии обработки ошибок уже предусмотрены. Однако при написании собственных обработок обслуживания всегда закладывайте логирование каждого шага взаимодействия с эквайринговым терминалом.