Как организовать сверку оплат по СБП и эквайрингу в 1С при разном времени зачисления денег

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

В этой статье мы подробно разберем, как автоматизировать процесс сверки 140 и более магазинов, исключить ошибки продавцов и правильно настроить учет в 1С.

Анализ проблемы: почему «едет» сверка?

Проанализируем классическую ситуацию: вчера магазин продал товар на 35 000 рублей (22 000 — эквайринг, 13 000 — СБП). В учетной системе (например, Управление торговлей 10.3) созданы документы реализации на всю сумму. Однако:

1. СБП: 13 000 рублей упали на счет вчера в течение дня. Чтобы их увидеть, нужно было снимать выписку вчера вечером.
2. Эквайринг: 22 000 рублей пришли сегодня утром.

Если менеджер снимает выписку сегодня утром, он видит только 22 000. Это создает путаницу, особенно при большом количестве торговых точек, где продавцы могут ошибочно нажать не ту кнопку оплаты на кассе (вместо СБП выбрать эквайринг и наоборот).

Решение 1: Использование банковского API для запросов за произвольный период

Рассмотрим наиболее эффективный технический способ решения — переход от ручного скачивания файлов выписок к автоматизированным запросам через API банка. Вместо того чтобы привязываться к календарному дню выписки, мы можем запрашивать реестр операций за период кассовой смены (например, с 09:00 вчерашнего дня до 09:00 сегодняшнего).

Для реализации этого метода в 1С следует использовать механизм DirectBank или написать расширение/обработку, которая будет:

• Авторизовываться в личном кабинете банка по API.
• Запрашивать список всех транзакций с признаком «СБП» и «Эквайринг».
• Сопоставлять полученные данные с документами ОтчетОРозничныхПродажах или ОплатаОтПокупателяПлатежнойКартой.

Решение 2: Настройка видов оплат и комиссий в 1С:Бухгалтерия

Если учет ведется в современных версиях программ (например, БП 3.0.123 и выше), проблему можно решить через правильную настройку справочников. Разберем по шагам:

1. Разделение видов оплат: Создадим два разных элемента в справочнике Виды оплат. Один назовем «Эквайринг (Карты)», другой — «Оплата по СБП».
2. Идентификация по наименованию: В новых релизах 1С умеет автоматически разделять операции, если в наименовании вида оплаты присутствует текст «СБП».
3. Учет комиссии: По эквайрингу комиссия обычно удерживается банком сразу (деньги приходят за минусом процента). По СБП банк часто зачисляет полную сумму, а комиссию списывает отдельным платежным поручением. В 1С это настраивается через разные договоры эквайринга: для СБП указываем способ списания комиссии «Отдельным документом».

Решение 3: Автоматизация кассового узла (интеграция терминалов)

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

Если вы работаете через RDP (удаленный рабочий стол) и используете драйверы АТОЛ 10-й версии, рассмотрим правильную схему подключения:

Вместо проброса COM-портов (которых ограничено 255 штук) следует использовать Web-сервер АТОЛ или службу RPC. Это позволит кассе и терминалу работать по протоколу TCP/IP. Рассмотрим пример настройки службы:

// Пример запуска драйвера с поддержкой удаленного подключения
// В параметрах запуска службы АТОЛ указываем:
/WithWEB - для запуска веб-сервера;
/WithRPC - для сервера удаленного подключения;

При такой схеме 1С отправляет команду на оплату, и терминал сам понимает, какая сумма должна пройти. После успешной транзакции 1С получает уникальный номер операции (RRN), который записывается в документ. Это делает сверку мгновенной и автоматической.

Решение 4: Организационный подход «СБП = Наличные»

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

• Платежи по СБП в торговой базе приравниваются к мгновенным поступлениям (аналог ПКО).
• Для бухгалтерии они проходят по счету 51 (или 57 для удобства сверки), но менеджеры в торговой системе видят их как закрытые оплаты текущего дня.
• Сверка проводится не по выписке «за вчера», а по «Z-отчету» терминала, где СБП и карты разделены в итогах дня.

Технические нюансы для разработчика

Если вы дорабатываете систему на базе УТ 10.3 или используете собственные приложения на Delphi/других языках, обратите внимание на следующие моменты:

Работа с DualConnect: Большинство современных банковских терминалов поддерживают протокол DualConnect, который позволяет по одному USB/Ethernet каналу передавать данные и для кассы, и для банковского ПО. Изучите документацию поставщика эквайринга для интеграции этой библиотеки в вашу HTTP-прослойку.

Особенности 10-го драйвера АТОЛ: Помните, что платформа 5 (новые кассы) не требует второго COM-порта для связи с ОФД, всё идет через один канал. Это освобождает ресурсы сервера при большом количестве магазинов.

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