Incoming Payment

An Incoming Payment records money received from a customer and applies it against the invoices that customer owes. It is the document that turns “the customer owes us” into “the customer has paid us”: cash goes up, accounts receivable goes down, and the specific invoices the payment covers are marked closed.

In the Service Layer this is the IncomingPayments service, object code oIncomingPayments (24), created at /b1s/v1/IncomingPayments.

Unlike the inventory documents, an Incoming Payment does carry a business partner: its CardCode is the customer who paid. The other half of the document is the allocation — the list of open A/R invoices the payment is applied to, so the money is matched to the debts it settles rather than left sitting unapplied.

When it is used

An Incoming Payment is created whenever a customer settles what they owe:

• Bank transfer received against one or more open A/R invoices.
• Cash or cheque takings from a customer, banked and recorded.
• Card / online payment clearing into the company account.
• Partial payment — a customer pays part of a large invoice; the invoice stays partly open for the remainder.
• Payment on account — money received before any invoice exists, held against the customer’s balance until invoices arrive to apply it to.

The mirror document for paying a vendor is the Outgoing Payment (oVendorPayments, 46). The Incoming Payment is always the receipt side — money coming in from a customer.

Key fields

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

Header

The money can arrive by more than one means at once — a CashSum, a TransferSum, a cheque total — each routed to 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 PaymentInvoices row points at one open invoice by its DocEntry and says how much of the received money to put against it. This is the allocation that distinguishes a real payment from an untracked cash deposit.

GL and stock effect

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

Accounting: the payment debits the cash/bank account it landed in and credits the customer’s accounts-receivable control account, clearing the debt:

DR  Bank / Cash account          (amount received)
CR      Accounts Receivable              (amount applied — customer balance cleared)

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

If the customer paid more than they owe, or paid with no invoice named, the surplus is recorded on account — a credit sitting against the customer’s balance, available to apply to future invoices. Bank charges, if any, post to a separate charge account so the net cash matches the bank statement at reconciliation time.

Service Layer

A create payload names the customer, the bank account and amount received, and the invoices it settles:

POST /b1s/v1/IncomingPayments
{
  "CardCode": "C20000",
  "DocType": "rCustomer",
  "TransferSum": 1170.0,
  "TransferAccount": "111000",
  "PaymentInvoices": [
    { "DocEntry": 42, "InvoiceType": "it_Invoice", "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.