Vendor Payment Applications Realtime-enabled

The AP-side counterpart of Customer Payment Applications. Each row applies part of a payable document to one posted document, a purchase invoice for a payment and a purchase credit memo for a refund. A nested collection addressed under a parent: vendorPayments({id})/vendorPaymentApplications, reused by vendorPayments, vendorCreditMemos, vendorInvoices, and vendorRefunds.

Settle by appliesToInvoiceNumber or by appliesToInvoiceIntegrationId (a resolver that finds the posted document by your own key).

The parent decides which document class your key is looked up in, exactly as on the customer side. A payment resolves against posted purchase invoices, a refund against posted purchase credit memos. A refund naming a posted credit memo resolves when you POST the line. The document must belong to the parent's own vendor, and another vendor's document is rejected as you POST rather than at processing time.

Invoices and credit memos this API raised itself count too. A vendor invoice or vendor credit memo posts through the general journal, so no posted purchase document exists for it; the key still resolves, from the Processed Documents history, to the document number its ledger entry carries.

A line with no target is the on-account line

Same as the customer side: a line with neither appliesToInvoiceNumber nor appliesToInvoiceIntegrationId posts against the vendor unapplied, and is how you park part of a payment on their account with a comment of your own. When the applications total less than the parent amount, the engine adds exactly that line for the shortfall.

Rows that do name an invoice are settled together, as one vendor ledger entry for the applied total. A comment therefore reaches the journal line description only on an unapplied row, or on a payment settling a single invoice. Every comment is kept against the processed document in the eOne Processed Documents history.

Application targets must be open

The open-entry rules are the same on this side, read from the vendor ledger: a closed purchase invoice is rejected as closed rather than parked as Awaiting Invoice, and an applied total above what remains on the target is rejected naming the document, its remainder and your total. The Payment Applications page offers only the payee's open entries with their remaining amounts.