🎯 Что это и зачем

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

Кто работает: кассиры и бухгалтеры торговых точек и предприятий услуг, ежедневно. Документ обычно создаётся на основании реализации или счёта на оплату — тогда контрагент, договор, сумма и расшифровка подставляются автоматически.

🧭 Где найти в программе

Документ относится к подсистемам «Банк и касса» → «Банк» и «Денежные средства» (подтверждено командным интерфейсом конфигурации, релиз 3.0.72.1). Открывается из раздела «Банк и касса»; в журнале документов банка/денежных средств выбираем вид документа «Оплата от покупателя платёжной картой», новый создаём кнопкой «Создать». Чаще всего документ вводят не из журнала, а кнопкой «Создать на основании» из реализации или счёта на оплату.

👤 Часть 1. Для пользователя

Проходим по шагам: от оплаты на основании реализации до проверки погашения долга и движений документа.

Урок 1. Оплата картой на основании реализации

Когда: покупатель оплачивает картой уже оформленную реализацию товаров или услуг.

Шаг 1. Создаём документ на основании

Открываем проведённую «Реализацию ТМЗ и услуг» → «Создать на основании» → «Оплата от покупателя платёжной картой». Часть полей заполнится автоматически.

Шаг 2. Проверяем шапку

После ввода на основании проверяем: - Организация и Контрагент — перенеслись из реализации. - Вид операции — «Оплата покупателя» (значение по умолчанию). - Договор эквайринга — договор с банком-эквайрером на обслуживание терминала; выбираем, если не подставился. - При выборе договора эквайринга подтягиваются Эквайрер, Валюта документа, Договор взаиморасчётов эквайрера, Счёт учёта расчётов с эквайрером и Процент торговой уступки. - Вид оплаты — тип карты/платёжной системы (Visa, MasterCard и т. п.).

Шаг 3. Проверяем расшифровку платежа

Внизу — таблица «Расшифровка платежа». При вводе на основании в ней уже есть строка: - Договор контрагента — из основания; - Сделка — ссылка на документ-основание (реализацию), долг по которому гасится; - Сумма платежа — равна сумме документа; - Счёт учёта расчётов с контрагентом БУ и Счёт учёта расчётов по авансам — подставлены автоматически.

Шаг 4. Авторизуем платёж на терминале (если есть интеграция)

Кнопка «Оплатить картой» запускает авторизацию через подключённый POS-терминал. После успешной операции в документ попадают Номер платёжной карты (маскированный), Ссылочный номер (RRN), Номер чека ЭТ.

Шаг 5. Проводим и печатаем чек

«Провести» → при необходимости «Напечатать чек» (фискальный чек на ККМ). Чтобы проверить учёт — открываем Дт/Кт (движения документа).

Урок 2. Прямая оплата (аванс без основания)

Когда: покупатель платит картой до отгрузки — например, предоплата за услугу.

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

Урок 3. Возврат денежных средств покупателю

Когда: покупатель вернул товар, нужно вернуть деньги на карту.

1. Создаём документ (удобно — на основании «Возврата товаров от покупателя»).
2. Меняем Вид операции на «Возврат денежных средств покупателю».
3. В «Расшифровке платежа» в качестве Сделки указываем документ возврата, в Сумме платежа — сумму возврата.
4. Проводим возврат через терминал (операция «возврат»/«отмена») и проводим документ.

🛠 Часть 2. Для программиста

Источник: реальный код релиза 3.0.72.1 (Documents/ОплатаОтПокупателяПлатежнойКартой/Ext/ObjectModule.bsl), метаданные документа (*.xml), плюс разбор objects/ и business-logic/. Где данные из objects/ расходятся с кодом — это помечено как несостыковка.

Структура объекта

Ключевые реквизиты шапки. Управление эквайрингом: ВидОперации (перечисление ВидыОперацийОплатаОтПокупателяПлатежнойКартой — два значения: ОплатаПокупателя, ВозвратДенежныхСредствПокупателю), ДоговорЭквайринга, Эквайрер, ДоговорВзаиморасчетовЭквайрера, СчетУчетаРасчетовСЭквайрером, ВидОплаты, ПроцентТорговойУступки, СуммаТорговойУступки. Учётные: Организация, Контрагент, ВалютаДокумента, СуммаДокумента, СтруктурноеПодразделение, УчитыватьКПН, ВидУчетаНУ, РучнаяКорректировка. Платёжно-фискальные: НомерЧекаККМ, НомерПлатежнойКарты, СсылочныйНомер, НомерЧекаЭТ, ДанныеПереданыВБанк.

Табличная часть РасшифровкаПлатежа — детализация платежа по договорам/счетам: ДоговорКонтрагента, Сделка (гасимый документ расчётов), СуммаПлатежа, СуммаВзаиморасчетов, КурсВзаиморасчетов, КратностьВзаиморасчетов, СтавкаНДС, СуммаНДС, СтатьяДвиженияДенежныхСредств, СчетУчетаРасчетовСКонтрагентомБУ, СчетУчетаРасчетовПоАвансам, СчетНаОплату.

📌 Важная особенность метаданных. В описании метаданных документа блок <RegisterRecords> пуст, и блок <BasedOn> тоже пуст (проверено в ОплатаОтПокупателяПлатежнойКартой.xml). Это значит: (1) набор регистров-движений документа не зафиксирован декларативно — движения формируются программно через наборы записей (ПроведениеСервер + коллекция Движения); (2) список оснований ввода (ВводитсяНаОсновании) задаётся не списком в этом узле, а определяется на стороне документов-оснований / проверяется в коде через Метаданные().ВводитсяНаОсновании.Содержит(...).

Жизненный цикл (обработчики ObjectModule)

Как формируется проведение — реальный код (3.0.72.1)

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

Источник: ObjectModule.bsl, процедура ОбработкаПроведения (стр. 159):

Процедура ОбработкаПроведения(Отказ, РежимПроведения)

    // ПОДГОТОВКА ПРОВЕДЕНИЯ ПО ДАННЫМ ДОКУМЕНТА
    ПроведениеСервер.ПодготовитьНаборыЗаписейКПроведению(ЭтотОбъект);
    Если РучнаяКорректировка Тогда
        Возврат;                                    // ручное управление движениями
    КонецЕсли;

    ПараметрыПроведения = Документы.ОплатаОтПокупателяПлатежнойКартой.ПодготовитьПараметрыПроведения(Ссылка, Отказ);
    Если Отказ Тогда
        Возврат;
    КонецЕсли;

    // ПОДГОТОВКА ПО ДАННЫМ ИНФОРМАЦИОННОЙ БАЗЫ
    ТаблицаВзаиморасчеты = УправлениеВзаиморасчетамиСервер.ПодготовитьТаблицуВзаиморасчетовПогашениеЗадолженности(
        ПараметрыПроведения.РасшифровкаПлатежа, ПараметрыПроведения.Реквизиты, Отказ);

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

    // ФОРМИРОВАНИЕ ДВИЖЕНИЙ
    УправлениеВзаиморасчетамиСервер.СформироватьДвиженияПогашениеЗадолженности(ТаблицаВзаиморасчеты,
        ПараметрыПроведения.Реквизиты, Движения, Отказ);

    // Переоценка валютных остатков — ПОСЛЕ формирования проводок всеми другими механизмами
    ТаблицаПереоценка = УчетДоходовРасходов.ПодготовитьТаблицуПереоценкаВалютныхОстатковПоПроводкамДокумента(
        ПараметрыПроведения.Реквизиты, Движения, Отказ);
    УчетДоходовРасходов.СформироватьДвиженияПереоценкаВалютныхОстатков(ТаблицаПереоценка,
        ПараметрыПроведения.Реквизиты, Движения, Отказ);

    СтатусыДокументов.СформироватьДвиженияОплатаСчетов(
        ПараметрыПроведения.ОплатаСчетов, ПараметрыПроведения.Реквизиты, Движения, Отказ);

    Если Не ГрупповоеПерепроведение Тогда
        СтатусыДокументов.СформироватьДвиженияСтатусовДокументов(
            ТаблицаСтатусовСчетов, ПараметрыПроведения.Реквизиты);
    КонецЕсли;

КонецПроцедуры

Кто что формирует (вызов → смысл):

Важные детали из кода: - РучнаяКорректировка = Истина → авто-проведение полностью пропускается (Возврат сразу после подготовки наборов) — движения заполняет пользователь. - При Отказ на этапе ПодготовитьПараметрыПроведения проведение прерывается. - Поддержан режим группового перепроведения (ДополнительныеСвойства.ГрупповоеПерепроведение): в нём пропускается пересчёт статусов счетов — оптимизация массовых операций. - Порядок строгий: погашение задолженности → переоценка валюты → движения оплаты счетов → статусы документов. Переоценка валюты намеренно идёт после основных проводок (так указано комментарием в коде).

1. «Документ не проводится — ругается на сумму». Сумма строк РасшифровкаПлатежа ≠ СуммаДокумента. Это жёсткая проверка в ОбработкаПроверкиЗаполнения. Чините расшифровку, а не документ.
2. «Нет аналитики по контрагенту/договору». Счёт СчетУчетаРасчетовСЭквайрером (и счета в расшифровке) обязаны иметь аналитику по контрагентам и договорам. Настраивается в плане счетов — документ только проверяет.
3. «Где проводка на комиссию банка?». Её здесь нет — см. KZ30-PC-01. Удержание торговой уступки отражается при поступлении денег от эквайрера / по учётной политике эквайринга, а не этим документом. Логика счетов живёт в УправлениеВзаиморасчетамиСервер, УчетДоходовРасходов, СтатусыДокументов, ПроцедурыБухгалтерскогоУчета* и учётной политике — туда и смотреть при настройке у клиента.

Движения по регистрам

Поскольку <RegisterRecords> в метаданных пуст, перечень ниже собран по реальным вызовам в ОбработкаПроведения (источник истины — отчёт «Дт/Кт» и состав наборов записей на конкретной базе):

Валидации (ОбработкаПроверкиЗаполнения и построчная проверка)

Из реального кода: 1. Сумма документа = сумма расшифровки. Если НЕ РасшифровкаПлатежа.Итог("СуммаПлатежа") = СуммаДокумента → ошибка «не совпадают сумма документа и её расшифровка». 2. Аналитика счёта эквайрера. Если СчетУчетаРасчетовСЭквайрером заполнен — на нём обязан вестись учёт по контрагентам и по договорам (две отдельные проверки через ПроцедурыБухгалтерскогоУчетаВызовСервераПовтИсп.НаСчетеВедется...). 3. Построчно по РасшифровкаПлатежа (ПроверитьЗаполнениеТабличнойЧастиПострочно): СчетУчетаРасчетовСКонтрагентомБУ и (если заполнен) СчетУчетаРасчетовПоАвансам — учёт по контрагентам и по договорам; затем УправлениеВзаиморасчетамиСервер.ВозможноПроведениеВ_БУ_НУ по валютам документа/договора/регл. учёта. 4. Снятие реквизитов с проверки по функц. опциям/состоянию: - РасшифровкаПлатежа исключается из обязательной проверки, если в ней уже есть строки; - ВидУчетаНУ не проверяется, если нет необходимости отражения в НУ (НеобходимостьОтраженияВНУ = Ложь — зависит от плательщика налога на прибыль, УчитыватьКПН, временных разниц); - ДоговорВзаиморасчетовЭквайрера и РасшифровкаПлатежа.ДоговорКонтрагента исключаются, если не ведётся учёт по договорам (ВестиУчетПоДоговорам = Ложь).

Признак плательщика налога на прибыль и поддержка временных разниц берутся из ПроцедурыНалоговогоУчета на дату документа — это влияет на обязательность ВидУчетаНУ.

Зависимости (общие модули)

УправлениеДенежнымиСредствамиСервер (заполнение реквизитов расчётного документа — вызывается в ОбработкаЗаполнения и ПриКопировании), УправлениеВзаиморасчетамиСервер (погашение задолженности, проверка возможности проведения в БУ/НУ), СтатусыДокументов (движения оплаты счетов и статусов), УчетДоходовРасходов (переоценка валюты), РаботаСДоговорамиКонтрагентов (дозаполнение договоров), ПроцедурыБухгалтерскогоУчетаВызовСервераПовтИсп (проверки аналитики счетов), ПроцедурыНалоговогоУчета (признаки КПН/разниц), ПроведениеСервер, ОбщегоНазначения, ОбщегоНазначенияБККлиентСервер.

1. Снятие проведения обрабатывается в ПередЗаписью, а не в ОбработкаУдаленияПроведения. Ветка РежимЗаписи = РежимЗаписиДокумента.ОтменаПроведения И ВидОперации = ...ОплатаПокупателя: если в расшифровке есть заполненные СчетНаОплату, формируется таблица статусов и вызывается СтатусыДокументов.СформироватьДвиженияСтатусовДокументов — чтобы вернуть счетам статус «не оплачен». При доработках это легко пропустить.
2. Поддержка ГрупповоеПерепроведение. Флаг читается из ДополнительныеСвойства. В групповом режиме пропускается пересчёт статусов счетов — учитывайте при массовой обработке и при тестировании (иначе статусы счетов не обновятся ожидаемо).
3. РучнаяКорректировка = Истина → проведение пропускается сразу после ПодготовитьНаборыЗаписейКПроведению — движения заполняет пользователь.
4. Пустой <RegisterRecords> в метаданных — нормально для этого документа: набор движений динамический. Не ищите декларативный список регистров; смотрите вызовы Сформировать... в ОбработкаПроведения и фактический состав Движения на базе.
5. ПриКопировании чистит фискальные реквизиты — при копировании платежа номер карты/чека/RRN и ДанныеПереданыВБанк обнуляются. Это защита от дублей транзакций; не «чините» как баг.
6. Интеграцию с терминалом нельзя эмулировать из BSL — кнопки «Оплатить картой»/«Напечатать чек» вызывают внешние подключаемые команды и требуют оборудования или API банка. Для автотестов заполняйте НомерПлатежнойКарты/СсылочныйНомер напрямую.

🔗 Связанные разделы

• realizaciya-tmz-i-uslug — реализация, по которой принимается оплата (документ-основание)
• schet-na-oplatu-pokupatelyu — счёт на оплату; его статус обновляет этот документ
• prihodnyy-kassovyy-order — приём наличной оплаты (зеркальный сценарий)
• vozvrat-tovarov-ot-pokupatelya — основание для возврата денег на карту

🆕 Что нового