Как организовать оплату произвольной суммы долга через интернет-эквайринг на сайте и правильно пробить чек в 1С:УТ 11.4

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

В современной оптовой торговле все чаще возникает необходимость предоставить клиентам возможность оплачивать дебиторскую задолженность не только банковским переводом, но и через интернет-эквайринг. Это удобно для клиентов, у которых временно заблокированы счета или которым необходимо срочно закрыть долг для возобновления отгрузок. Однако перед техническим специалистом встает сложная задача: как правильно передать данные в ОФД, нужно ли детализировать товары в чеке и как синхронизировать сайт с 1С:Управление торговлей 11.4.

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

Анализ требований законодательства (54-ФЗ) при оплате долга

Первое, с чем нам необходимо определиться — это содержание фискального чека. Бытует мнение, что при оплате долга в чеке обязательно должны присутствовать все позиции из накладных (реализаций), которые этот платеж закрывает. Рассмотрим, так ли это на самом деле.

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

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

Варианты технической реализации

Рассмотрим два основных сценария интеграции, которые обсуждались экспертами, и выделим их плюсы и минусы.

Вариант 1: Формирование чека на стороне сайта через API облачной кассы

В этом сценарии сайт выступает инициатором фискализации. Покупатель вводит сумму на сайте, платежный шлюз подтверждает транзакцию, и сайт отправляет запрос в облачный сервис (например, АТОЛ Онлайн или сервис Сбербанка) для печати чека.

Преимущества:

  1. Клиент получает чек мгновенно в момент оплаты.
  2. Минимальная задержка между списанием денег и фискализацией.

Недостатки:

  1. Сайту необходимо «знать» актуальное состояние взаиморасчетов и ИНН контрагента.
  2. Сложность синхронизации: после загрузки оплаты в 1С:УТ 11.4 необходимо программно пометить, что чек по этой операции уже пробит, чтобы избежать двойной фискализации.

Вариант 2: Формирование чека на стороне 1С после загрузки оплаты

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

Преимущества:

  1. 1С обладает полной информацией о долгах, договорах и товарах.
  2. Легко реализовать автоматическое распределение суммы по документам отгрузки (по принципу FIFO).
  3. Централизованный контроль за кассовыми операциями.

Разберем по шагам реализацию в 1С: Для автоматизации этого процесса нам потребуется настроить регламентное задание, которое будет обрабатывать загруженные с сайта оплаты. Проанализируем пример логики обработки:


// Пример логики распределения оплаты в 1С
ДокОплата = Документы.ОперацияПоПлатежнойКарте.СоздатьДокумент();
ДокОплата.Дата = ТекущаяДата();
ДокОплата.Организация = ОбъектОрганизация;
ДокОплата.Контрагент = ОбъектКонтрагент;
ДокОплата.СуммаДокумента = ОплатаС Сайта;
// Выбор варианта взаиморасчетов: по договору или по заказам/накладным
ДокОплата.ОбъектРасчетов = ОснованиеДляОплаты; 

// Если требуется распределение по документам, вызываем помощник зачета оплат
// В УТ 11.4 это делается через механизмы распределения взаиморасчетов
ДокОплата.Записать(РежимЗаписиДокумента.Проведение);

// Пробитие чека через подключаемое оборудование
ПараметрыЧека = ПодготовитьПараметрыЧека(ДокОплата);
МенеджерОборудования.ПробитьЧеККМ(ПараметрыЧека);

Как настроить содержание чека в УТ 11.4

В зависимости от настроек договора в 1С:Управление торговлей, чек будет формироваться по-разному:

  1. Взаиморасчеты по заказам: Если документ ОперацияПоПлатежнойКарте создается на основании конкретного Заказа клиента, 1С подтянет список товаров из этого заказа. В чеке будут перечислены товары с признаком способа расчета «Оплата кредита».
  2. Взаиморасчеты по договору: Если оплата идет просто по договору в целом (на произвольную сумму), в чеке будет одна строка. В настройках системы можно указать шаблон наименования, например: «Погашение задолженности по договору №...». Это полностью соответствует требованиям закона при оплате долга.

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

Рекомендация по использованию СБП

При работе с оптовыми покупателями стоит рассмотреть альтернативу классическому интернет-эквайрингу — Систему быстрых платежей (СБП). В 1С:УТ 11.4 реализована штатная интеграция с СБП.

Преимущества очевидны: комиссия составляет 0.4–0.7% против 2–3% у эквайринга, а деньги поступают на счет мгновенно. С технической точки зрения процесс схож: клиент сканирует QR-код на сайте (сгенерированный 1С или сайтом), а 1С после подтверждения транзакции автоматически фискализирует операцию.

Выводы

Для реализации оплаты произвольной суммы долга на сайте мы рекомендуем использовать следующую схему:

Такой подход минимизирует риски расхождения данных между сайтом и учетной системой и обеспечивает полное соответствие 54-ФЗ.

← На главную