Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
B2B payment должен быть связан со счетом и складом
Оптовая сумма без invoice id, контрагента и warehouse reserve не помогает понять, какой заказ можно отгружать.
В дистрибуции и оптовой торговле платеж редко закрывает простой интернет-заказ. Он относится к контрагенту, договору, invoice, order lines, warehouse reserve, delivery route and accounting document. Если payment link отправляется как общая сумма, склад и бухгалтерия закрывают операции вручную.
Практичная модель создает payment request из CRM/ERP: customer id, invoice id, order id, warehouse reserve id, amount, currency, due date and expiration фиксируются до оплаты. Отгрузка запускается только после verified payment и выполнения бизнес-правил.
- связывать payment request с B2B invoice id;
- хранить customer id, order id и warehouse reserve id;
- не отгружать товар по скриншоту или return URL;
- показывать складу только verified/approved статусы.
Partial payments и credit limit требуют бизнес-правил
Предоплата, остаток, кредитный лимит и отсрочка платежа не должны смешиваться с техническим payment status.
Оптовый клиент может платить предоплату, остаток перед отгрузкой, несколько частичных платежей или работать по внутреннему credit limit. Эти правила относятся к бизнес-политике компании, а не к самому платежному провайдеру.
Backend должен различать payment verified, business approved, reserve released, shipped and accounting closed. Credit limit или отсрочка требуют правил договора, ответственного менеджера и audit trail. Если payment status pending, склад не должен считать заказ полностью готовым.
- разделять prepayment, balance due и overpayment;
- credit limit хранить как business rule, не как payment status;
- release warehouse reserve только после verified/approved события;
- manual override должен иметь actor, reason и timestamp.
Доставка, возвраты и ERP-сверка должны быть событиями
Частичная отгрузка, возврат товара, refund и переплата должны сохранять историю счета, а не перезаписывать ее.
Оптовый заказ часто отгружается партиями, меняется по наличию на складе или частично возвращается. Платежная история должна хранить original payment, partial shipment, return, refund, overpayment and adjustment events отдельно.
Ежедневная сверка сравнивает provider report, B2B invoices, warehouse reserves, delivery notes, returns, refunds and ERP/accounting export. Так менеджер видит, какие счета закрыты, где есть долг, где переплата, а где нужен ручной review.
- не удалять original payment при возврате товара;
- связывать delivery batch с invoice/payment context;
- overpayment хранить отдельным ledger event;
- сверять provider reference с ERP document id.
FAQ
Можно ли принимать оплату оптового счета по ссылке?
Да, если ссылка связана с B2B invoice id, customer id, order lines, суммой, валютой и сроком действия, а статус подтверждается сервером.
Как учитывать частичную оплату оптового заказа?
Хранить prepayment, balance due и overpayment как отдельные ledger events, связанные с одним invoice/order context.
Когда можно отпускать складской резерв?
После verified payment и выполнения бизнес-правил компании: например approval менеджера, кредитного лимита или полного закрытия суммы.
