# Detailed Vendor Ledger Entries

`GET` _(Table: Detailed Vendor Ledg. Entry)_

```
eOne/core/v1.0/detailedVendorLedgerEntries
```

"Read-only movement detail behind the vendor ledger. Every change to an entry's balance gets a row: the initial posting, each application against it, payment discounts, exchange-rate adjustments and unapplications."

## The application pair

Two columns carry the audit trail:

- `vendorLedgerEntryNumber` is the entry this movement belongs to
- `appliedVendLedgerEntryNumber` is the entry on the other side of the application

Together they say which payment settled which invoice. That is the only place a partial or split settlement can be seen at all, because the parent feed collapses it into a single remaining amount.

`applicationNumber` groups the rows written by one application, so a payment spread across five invoices reads as one event rather than five.

## Days to pay

`postingDate` on an application row is the date the settlement happened. Subtracting the invoice's own posting date gives a real days-to-pay per invoice, which is what an average collection period should be built from.

## It is genuinely append-only

Unapplying does not edit the original row. Business Central writes a new reversing row and sets `unapplied` on the old one, so a cursor on `entryNumber` is safe here even though it is not on the parent feed. Filter out `unapplied eq true` when totalling, or you will count a reversed settlement twice.

## Exchange-rate adjustments move LCY only

An adjustment row carries an `amountLcy` with `amount` at zero. That is not bad data: the transaction-currency balance did not change, only its local-currency value did. Totalling `amount` on this feed and expecting the local-currency movement is the usual way that gets missed.

## Volume

Larger than [`vendorLedgerEntries`](https://eonesolutions.github.io/eone-bc-integration/core-vendorLedgerEntries.md), since one entry produces several rows. Filter a first load by `postingDate`.

## Detailed Vendor Ledger Entries 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 | The Business Central record id. Unique on its own, and the key this feed is written against. _(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)_ |
| `entryNumber` | Entry No. | Business Central's own entry number for this movement. _(ro)_ |
| `vendorLedgerEntryNumber` | Vendor Ledger Entry No. | The vendor ledger entry this movement belongs to. Join it to vendorLedgerEntries.entryNumber. _(ro)_ |
| `entryType` | Entry Type | What the movement was: initial entry, application, payment discount, correction of remaining amount, or an exchange rate adjustment. _(ro)_ |
| `postingDate` | Posting Date | The date the movement posted. On an application row this is the date the settlement happened, which is what a days-to-pay calculation needs. _(ro)_ |
| `documentType` | Document Type | The document type behind the movement. _(ro)_ |
| `documentNumber` | Document No. | The document behind the movement. _(ro)_ |
| `vendorNumber` | Vendor No. | The vendor the movement is for. _(ro)_ |
| `currencyCode` | Currency Code | The transaction currency of the movement. _(cur)_ |
| `amount` | Amount | The movement amount in the transaction currency. _(ro)_ |
| `amountLcy` | Amount (LCY) | The movement amount in the company local currency. An exchange-rate adjustment row moves this while leaving amount at zero. _(ro)_ |
| `debitAmount` | Debit Amount | The debit side of the movement. _(ro)_ |
| `creditAmount` | Credit Amount | The credit side of the movement. _(ro)_ |
| `debitAmountLcy` | Debit Amount (LCY) | The debit side in the company local currency. _(ro)_ |
| `creditAmountLcy` | Credit Amount (LCY) | The credit side in the company local currency. _(ro)_ |
| `appliedVendLedgerEntryNumber` | Applied Vend. Ledger Entry No. | The entry on the other side of an application. With vendorLedgerEntryNumber this says which payment settled which invoice. _(ro)_ |
| `applicationNumber` | Application No. | Groups the rows written by one application, so a payment split across several invoices can be read as one event. _(ro)_ |
| `unapplied` | Unapplied | Whether this movement has since been unapplied. An unapply writes a new reversing row rather than editing this one. _(ro)_ |
| `unappliedByEntryNumber` | Unapplied by Entry No. | The row that reversed this one. _(ro)_ |
| `initialEntryDueDate` | Initial Entry Due Date | The due date of the entry this movement belongs to, carried here so an aging can be built without joining back. _(ro)_ |
| `initialDocumentType` | Initial Document Type | The document type of the originating entry. _(ro)_ |
| `ledgerEntryAmount` | Ledger Entry Amount | Whether this row contributes to the entry amount, as opposed to being a discount or adjustment. _(ro)_ |
| `postingGroup` | Posting Group | The posting group in force for this movement. _(ro)_ |
| `genBusPostingGroup` | Gen. Bus. Posting Group | The general business posting group on the movement. _(ro)_ |
| `genProdPostingGroup` | Gen. Prod. Posting Group | The general product posting group on the movement. _(ro)_ |
| `transactionNumber` | Transaction No. | Groups every entry posted by the same transaction, across ledgers. _(ro)_ |
| `sourceCode` | Source Code | What kind of posting produced the movement. _(ro)_ |
| `lastModifiedDateTime` | SystemModifiedAt | The last date and time the record was modified. Use it as the watermark for an incremental pull. _(ro)_ |