# Vendor Payment Applications _(Realtime-enabled)_

`GET` `POST` `PATCH` `DELETE` _(Table: EONE Transaction Line)_

```
eOne/core/v1.0/vendorPaymentApplications
```

The AP-side counterpart of [Customer Payment Applications](https://eonesolutions.github.io/eone-bc-integration/core-customerPaymentApplications.md). Each row applies part of a payable document to one posted document, a [purchase invoice](https://eonesolutions.github.io/eone-bc-integration/core-postedPurchaseInvoices.md) for a payment and a [purchase credit memo](https://eonesolutions.github.io/eone-bc-integration/core-postedPurchaseCreditMemos.md) for a refund. A **nested collection** addressed under a parent: `vendorPayments({id})/vendorPaymentApplications`, reused by [vendorPayments](https://eonesolutions.github.io/eone-bc-integration/core-vendorPayments.md), [vendorCreditMemos](https://eonesolutions.github.io/eone-bc-integration/core-vendorCreditMemos.md), vendorInvoices, and vendorRefunds.

Settle by `appliesToInvoiceNumber` or by `appliesToInvoiceIntegrationId` (a [resolver](https://eonesolutions.github.io/eone-bc-integration/resolvers.md) 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](https://eonesolutions.github.io/eone-bc-integration/core-postedPurchaseInvoices.md), a refund against posted [purchase credit memos](https://eonesolutions.github.io/eone-bc-integration/core-postedPurchaseCreditMemos.md). 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](https://eonesolutions.github.io/eone-bc-integration/core-vendorInvoices.md) or [vendor credit memo](https://eonesolutions.github.io/eone-bc-integration/core-vendorCreditMemos.md) posts through the general journal, so no posted purchase document exists for it; the key still resolves, from the [Processed Documents](https://eonesolutions.github.io/eone-bc-integration/core-processedDocuments.md) history, to the document number its ledger entry carries.

> **Note:** Same before-post behaviour as the customer side: if the invoice has not posted and the endpoint allows it, the payment waits in staging and applies once it posts, otherwise it errors. The parent supplies the payment key; `lineNumber` is stamped automatically.

## A line with no target is the on-account line

Same as [the customer side](https://eonesolutions.github.io/eone-bc-integration/core-customerPaymentApplications.md): 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](https://eonesolutions.github.io/eone-bc-integration/core-customerPaymentApplications.md) 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.

## Vendor Payment Applications fields

_API column → BC field._

**Legend**

- _(req)_ required on create
- _(res)_ resolver
- _(cur)_ currency-translated
- _(ro)_ read-only
- _(ext)_ added to this endpoint by another extension (BC field name shown; its API column name is not known here)

| API | BC field | Notes |
| --- | --- | --- |
| `id` | SystemId | BC record GUID. _(ro)_ |
| `bcCompanyId` | bcCompanyId | The company this row belongs to - the same GUID that appears in the request URL. Present on every endpoint so a store pooling several companies can keep them apart without relying on which URL it called. _(ro)_ |
| `bcCompanyName` | bcCompanyName | The name of the company this row belongs to. _(ro)_ |
| `lineNumber` | Line No. | Stamped automatically on insert. _(ro)_ |
| `paymentId` | Transaction Id | GUID of the parent payment. _(ro)_ |
| `paymentIntegrationId` | EONE Txn Integration Id | The parent payment's Integration Id (your external key), for mapping back to the payment without a lookup. Filterable. _(ro)_ |
| `appliesToInvoiceNumber` | Applies-to Doc. No. | No. of the posted purchase document this line settles - an invoice under vendorPayments, a credit memo under vendorRefunds. |
| `appliesToInvoiceIntegrationId` | Applies-to Inv. Integration Id | Settles the posted document with this integrationId - a posted purchase invoice for a payment, a posted purchase credit memo for a refund, including one raised through vendorInvoices or vendorCreditMemos, which posts through the general journal. The document must belong to this vendor and still be open. If it has not posted yet and the environment allows it, the payment waits in staging and is applied once it posts. _(res)_ |
| `amount` | Amount | Portion of the document amount applied to this posted document. |
| `comment` | Comment | Free-text note for when no invoice number/Integration Id is available; carried onto the journal line description. Applications that do settle a document share one journal line, so their notes stay in the processed-document history instead. |
| `integrationId` | EONE Integration Id | Your external key. |
| `lastModifiedDateTime` | SystemModifiedAt | _(ro)_ |

## Related pages

Nested under [Vendor Payments](https://eonesolutions.github.io/eone-bc-integration/core-vendorPayments.md) and [Vendor Refunds](https://eonesolutions.github.io/eone-bc-integration/core-vendorRefunds.md) and [Vendor Credit Memos](https://eonesolutions.github.io/eone-bc-integration/core-vendorCreditMemos.md) and [Vendor Invoices](https://eonesolutions.github.io/eone-bc-integration/core-vendorInvoices.md).