Частичные оплаты заказа

В 1С-Битрикс заказ может быть оплачен не одним платежом, а несколькими: аванс сейчас, доплата при отгрузке, часть бонусами, часть картой. За это отвечает механизм нескольких оплат (Payment) внутри одного заказа. Разберём, как это устроено на уровне модели, как контролировать недоплату и как частичные оплаты корректно отражаются в чеках по 54-ФЗ.

Модель: заказ, оплаты и коллекция Payment

С переходом на новое ядро продаж (модуль sale, пространство имён Bitrix\Sale) заказ перестал быть «плоским». Заказ (Bitrix\Sale\Order) содержит независимые коллекции: отгрузки (ShipmentCollection) и оплаты (PaymentCollection). Именно поэтому один заказ может иметь несколько платежей — каждый со своей платёжной системой, суммой и статусом.

Каждый элемент оплаты — это объект Bitrix\Sale\Payment со своими полями: SUM (сумма платежа), PAY_SYSTEM_ID (способ оплаты), PAID (флаг Y/N — оплачен или нет), DATE_PAID, PS_STATUS. Сумма заказа при этом хранится в поле заказа PRICE, а признаки оплаченности — в PAYED и SUM_PAID.

• PaymentCollection — контейнер всех оплат заказа;
• Payment::setPaid('Y') — пометка конкретной оплаты как проведённой;
• Order::isPaid() — заказ считается полностью оплаченным, только когда сумма всех проведённых оплат покрывает PRICE.

Сценарий «аванс + доплата»

Классическая схема для товаров под заказ или для крупных отгрузок: покупатель вносит аванс (например, 30%), а остаток доплачивает при готовности или отгрузке. В модели это два объекта Payment внутри одного заказа.

Создать вторую оплату можно в админке заказа (Магазин → Заказы → карточка заказа → блок «Оплата» → добавить оплату) либо программно:

• получаете коллекцию оплат: $paymentCollection = $order->getPaymentCollection();
• создаёте новый платёж: $payment = $paymentCollection->createItem($paySystem);
• задаёте сумму доплаты: $payment->setField('SUM', $rest);
• сохраняете заказ: $order->save();

Пока проведён только аванс, заказ имеет статус частично оплачен (PAYED = N, но SUM_PAID > 0). После проведения второй оплаты система суммирует их и, если покрыт весь PRICE, переводит заказ в полностью оплаченный.

Разные способы в одном заказе: бонусы + карта

Частичная оплата — это не только про время (сейчас/потом), но и про способ. Один заказ можно закрыть несколькими платёжными системами одновременно: часть — бонусами внутренней программы лояльности, остаток — банковской картой.

Для бонусов в редакциях «Бизнес» и «Энтерпрайз» есть внутренняя платёжная система Оплата бонусами (обработчик из модуля sale.paysystem). Она списывает баллы и создаёт отдельный Payment, который сразу помечается оплаченным. Оставшуюся сумму покупатель оплачивает обычной ПС — ЮKassa, Сбербанк, PayKeeper и т. п.

Логика та же: заказ закроется как оплаченный только когда обе оплаты проведены и их сумма равна PRICE. На витрине это оформляется на шаге оплаты через компонент sale.order.payment или в кастомном чекауте.

Контроль недоплаты и переплаты

Главный риск дробных оплат — рассинхрон сумм. Битрикс хранит уплаченное в SUM_PAID, а признак полной оплаты — в PAYED. Проверять состояние нужно именно по разнице, а не по числу платежей.

• Недоплата: PRICE − SUM_PAID > 0 — заказ оплачен частично, отгружать на свой риск;
• Полная оплата: SUM_PAID ≥ PRICE — заказ переводится в PAYED = Y;
• Переплата: SUM_PAID > PRICE — сигнал к возврату разницы.

Программно удобнее опираться на методы объекта, а не на «сырые» поля: $order->isPaid(), $order->getPrice(), $order->getSumPaid(). Для реакции на факт оплаты вешайте обработчик на событие OnSaleOrderPaid (или OnSalePaymentEntitySaved для отдельного платежа) — так вы не пропустите момент, когда именно последняя оплата закрыла заказ.

Чеки 54-ФЗ: предоплата и полный расчёт

Частичная оплата напрямую влияет на онлайн-кассу. По 54-ФЗ момент оплаты и момент передачи товара требуют разных чеков, а признак способа расчёта в чеке (payment_method / тег 1214) должен корректно отражать, что именно происходит.

Модуль sale формирует чеки через объект Bitrix\Sale\Cashbox\Check и подсистему касс (Магазин → Настройки → Кассы ККМ). Для дробных оплат используются разные типы чеков:

Ключевая идея: на аванс пробивается чек с признаком предоплаты, а при закрытии заказа — чек полного расчёта, в котором зачитывается ранее внесённая предоплата. Битрикс умеет это автоматически, если чеки завязаны на события оплаты (PaymentCheck) и отгрузки (ShipmentCheck) — см. соседнюю статью про связку чеков оплаты и отгрузки.

Практика внедрения и типовые грабли

Несколько рекомендаций из реальных проектов, где частичная оплата — не исключение, а норма (B2B, товары под заказ, услуги с предоплатой):

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

Отдельно — интеграция с 1С. При обмене заказами (протокол CommerceML) частичные оплаты выгружаются как отдельные документы «Оплата». Если учёт в 1С строится на одном платеже, дробные оплаты сайта нужно корректно замапить, иначе баланс взаиморасчётов «поедет».

Итог

Частичная оплата в 1С-Битрикс — это штатный механизм нескольких Payment внутри одного заказа. Он покрывает и схему «аванс + доплата», и оплату разными способами (бонусы + карта), а состояние заказа определяется не числом платежей, а разницей PRICE − SUM_PAID. Главное — не потерять контроль над недоплатой и правильно развести чеки: предоплата на аванс, полный расчёт при отгрузке.

Если нужно надёжно связать дробные оплаты, фискализацию по 54-ФЗ и обмен с 1С — мы проектируем и внедряем такие сценарии под ключ: от логики чекаута до касс ККМ и синхронизации взаиморасчётов. Поможем настроить существующий магазин или собрать оплату с нуля.