Outgoing Payment

An Outgoing Payment records money paid to a vendor and applies it against the invoices the company owes that vendor. It is the mirror of the Incoming Payment: where the incoming payment collects from a customer and clears receivables, the outgoing payment disburses to a supplier and clears payables. Cash goes down, accounts payable goes down, and the specific vendor invoices the payment covers are marked closed.

In the Service Layer this is the OutgoingPayments service, object code oVendorPayments (46), created at /b1s/v1/VendorPayments. (SAP’s internal name for the object is Vendor Payments, which is why the object code and the create path both say “vendor” even though the UI calls it Outgoing Payment.)

Like the Incoming Payment, this document carries a business partner — but here the CardCode is the vendor being paid. The second half is again the allocation: the list of open A/P invoices the payment settles, so the money is matched to the debts it discharges.

When it is used

An Outgoing Payment is created whenever the company settles what it owes a supplier:

• Paying a vendor’s A/P invoice by bank transfer on its due date.
• Cheque runs — issuing cheques to multiple suppliers, each recorded as an outgoing payment.
• Partial payment — paying part of a large invoice now, leaving the rest open.
• Payment on account — sending money to a vendor before their invoice arrives, held against the vendor’s balance until invoices exist to apply it to.
• Refund of an overpaid customer (the document also supports rCustomer), though its primary role is vendor disbursement.

The mirror document for receiving money from a customer is the Incoming Payment (oIncomingPayments, 24). The Outgoing Payment is always the disbursement side — money going out to a vendor.

Key fields

The document has a header identifying the vendor and the money paid, plus a PaymentInvoices collection that allocates the money across specific invoices.

Header

The payment can be split across means — cash, bank transfer, cheque — each drawn from its own G/L account. The sum of these means must equal the sum applied across the invoices (plus any amount left on account).

Allocation (PaymentInvoices)

Each row points at one open A/P invoice by its DocEntry and states how much of the payment to put against it — the allocation that distinguishes a settled invoice from a bare cash disbursement.

GL and stock effect

Stock: none. A payment moves money, not goods.

Accounting: the payment debits the vendor’s accounts-payable control account (clearing the debt) and credits the cash/bank account the money left from:

DR  Accounts Payable             (amount applied — vendor balance cleared)
CR      Bank / Cash account              (amount paid out)

The debit is the A/P control account tied to the vendor’s CardCode; the credit account is the TransferAccount, CashAccount, or CheckAccount from the header. Each invoice in PaymentInvoices is reduced by its SumApplied; an invoice paid in full flips to Closed (bost_Close), while a partial payment leaves it open for the balance.

If the company paid the vendor more than it owed, or paid with no invoice named, the surplus is recorded on account — a debit balance held against the vendor, available to apply to future invoices.

Service Layer

A create payload names the vendor, the bank account and amount paid, and the invoices it settles:

POST /b1s/v1/VendorPayments
{
  "CardCode": "V10000",
  "DocType": "rSupplier",
  "TransferSum": 1170.0,
  "TransferAccount": "111000",
  "PaymentInvoices": [
    { "DocEntry": 88, "InvoiceType": "it_PurchaseInvoice", "SumApplied": 1170.0 }
  ]
}

Norma’s connector and mock use the /b1s/v1/ paths shown here; a live SAP B1 on Feature Pack 2405 or later exposes the same entity under /b1s/v2/ with identical shape.

The response returns the assigned DocEntry and DocNum, and the applied invoices reflect their reduced open balance immediately.