# Distributions _(Realtime-enabled)_ `GET` `POST` `PATCH` `DELETE` _(Table: EONE Transaction Line)_ ``` eOne/core/v1.0/distributions ``` Code a ledger document across several accounts instead of one. Each line books part of the document to an account (`accountNumber`), with its own [dimensions](https://eonesolutions.github.io/eone-bc-integration/dimensions.md) and description. A **nested collection** shared by all nine party endpoints: `customerInvoices({id})/distributions`, `customerPayments({id})/distributions`, and so on. > **Note:** The parent supplies the document key via the sub-page link and `lineNumber` is stamped for you. The URL segment is always `distributions`, whichever of the nine parents you POST under. ## What this is for A [customer invoice](https://eonesolutions.github.io/eone-bc-integration/core-customerInvoices.md) with no distributions posts two journal lines: the customer, and the header's `balancingAccountNumber`. That is the whole revenue side on one account. Distributions split it. A subscription invoice covering a plan fee, a usage overage and a one-off setup charge is three lines here, each to its own revenue account, and still **one** customer receivable. The same applies on the purchase side: an AP invoice arriving from an approval tool already coded across several expense accounts is one vendor payable and N distribution lines. Each line carries its own `shortcutDimension1Code`..`8Code`, which is the reason to reach for this rather than several documents. A document spanning two departments or two product lines cannot be dimensioned per department if the whole amount is one line. ## They may total less than the document, never more `amount` on the header stays the document total. The distributions are a ceiling under it, and on a payment or refund that ceiling covers the applications **and** the distributions together. - **Totalling the document amount** — on an invoice, no balancing line is written at all and `balancingAccountNumber` stops being required. On a payment, nothing is left on the party's account. - **Totalling less** — the difference goes where it would have gone anyway: to the balancing account on an invoice, or onto the party's account unapplied on a payment. - **Totalling more** — rejected, naming both figures. Nothing on the header funds the excess. On a payment the combined check matters more than it looks. Sixty applied plus sixty distributed against a header of a hundred would pass two separate checks and still balance, because the bank plug absorbs it — and the party would be credited sixty more than they ever paid. Amounts are sent as positive magnitudes, like everywhere else in the [journal wrappers](https://eonesolutions.github.io/eone-bc-integration/journal-wrappers.md); the endpoint derives the side each line posts to from the document type. ## Which side a line lands on depends on the parent This is the one thing to understand before using them, and it follows from what the header `amount` means. **On an invoice or credit memo** the amount *is* the party movement. The party line takes all of it, and the distributions are the offsetting side — an invoice debits the customer and credits revenue. **On a payment or refund** the amount is the cash, and the bank takes all of it. The party line takes only the part that settles something; a distribution takes another part of the *same* side. So the applications and the distributions **share** the header amount: ``` customerPayments amount 100.00 applications 60.00 settles the membership invoice distributions 40.00 donation income, account 41200 Customer credit 60.00 Donation income credit 40.00 Bank debit 100.00 ``` That is the membership-renewal-plus-donation case. Without a distribution the 40 would land on the member's account as an unapplied credit they never paid, and the donation would never be recognised as income at all. You always send a positive `amount` on the line. The engine sets the sign, exactly as it does for every other amount in the [journal wrappers](https://eonesolutions.github.io/eone-bc-integration/journal-wrappers.md). ## Accounts other than G/L `accountType` defaults to G/L Account, which is what an invoice's revenue or expense side almost always is. It also accepts Bank Account, Customer, Vendor, Employee and Fixed Asset, for the cases where a coded line genuinely belongs to a subledger rather than to the general ledger. ## Line type Distributions and applications are rows in one staging table, told apart by a line type. You never send it: this collection stamps `Distribution` on everything it creates, and the applications collections stamp `Application` on theirs. Each collection lists only its own kind, so `distributions` never shows an application and `customerPaymentApplications` never shows a distribution. ## Distributions 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)_ | | `documentId` | Transaction Id | GUID of the parent ledger document. _(ro)_ | | `documentIntegrationId` | EONE Txn Integration Id | The parent document's Integration Id (your external key), for mapping back to the header without a lookup. Filterable. _(ro)_ | | `accountType` | Account Type | The kind of account this line posts to: G/L Account (the default), Bank Account, Customer, Vendor, Employee or Fixed Asset. | | `accountNumber` | Account No. | The account this line distributes to - a G/L account unless accountType says otherwise. | | `amount` | Amount | The amount booked to the account. Positive debits it and the header's balancing account takes the credit; send a negative amount to reverse that. | | `taxAmount` | Tax Amount | Tax on this line, as your source system calculated it. Sent as a positive magnitude; Business Central posts it as its own journal line on the same side as this one and never recalculates it. Whether it sits on top of amount or inside it is the header's pricesIncludeTax. Leave it out for a line that carries no tax - a donation, a fee, an intra-group transfer. See Journal Wrappers. | | `taxAccountNumber` | Tax Account No. | G/L account the tax on this line posts to. Optional - falls back to the Default Tax Account on this endpoint's setup row. Set it per line when one document carries tax for several jurisdictions that file to different accounts. | | `description` | Description | Line description; falls back to the header description if blank. | | `comment` | Comment | Free-text note (e.g. what the fee or accrual covers); carried onto the journal line description. | | `shortcutDimension1Code` | Shortcut Dimension 1 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension2Code` | Shortcut Dimension 2 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension3Code` | Shortcut Dimension 3 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension4Code` | Shortcut Dimension 4 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension5Code` | Shortcut Dimension 5 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension6Code` | Shortcut Dimension 6 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension7Code` | Shortcut Dimension 7 Code | Dimension for this distribution line. See Dimensions. | | `shortcutDimension8Code` | Shortcut Dimension 8 Code | Dimension for this distribution line. See Dimensions. | | `integrationId` | EONE Integration Id | Your external key for the line - the id of the distribution it came from in your source system. | | `lastModifiedDateTime` | SystemModifiedAt | _(ro)_ | ## Related pages Nested under [Customer Payments](https://eonesolutions.github.io/eone-bc-integration/core-customerPayments.md) and [Customer Refunds](https://eonesolutions.github.io/eone-bc-integration/core-customerRefunds.md) and [Customer Credit Memos](https://eonesolutions.github.io/eone-bc-integration/core-customerCreditMemos.md) and [Customer Invoices](https://eonesolutions.github.io/eone-bc-integration/core-customerInvoices.md) and [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) and [Employee Payments](https://eonesolutions.github.io/eone-bc-integration/core-employeePayments.md) and [Deposits](https://eonesolutions.github.io/eone-bc-integration/core-deposits.md).