Dimension Set Lines
GETPOSTPATCHDELETETable: EONE Dimension Line
Put a ninth, tenth or twentieth dimension on a document line. Business Central has no limit on dimensions per entry — the eight shortcut dimensions are a fast path, not a ceiling — and this collection is how you reach the rest. A nested collection on the sales document line collections and the journal-wrapper line collections alike.
shortcutDimension1Code..8Code columns for those. Sending one of the eight to this collection is rejected, and the reason matters — see below.What this is for
Eight dimensions sounds generous until the reporting model is the reason for the integration.
A utility bucketing a period's revenue by region, tariff, service, customer class, meter type, billing cycle and revenue category has used seven before the finance team's own cost centre and project dimensions are counted. A grant-funded organisation reporting by fund, appeal, campaign, programme, restriction, funder and financial year is in the same position. Until this collection existed, the ninth dimension was inexpressible anywhere in this product — a lower ceiling than Business Central's own.
Send a dimensionCode and a dimensionValueCode. Both must exist: the value has to be a Dimension Value under that dimension.
POST /salesOrders({orderId})/salesOrderLines({lineId})/dimensionSetLines
{ "dimensionCode": "TARIFF", "dimensionValueCode": "ECO-7" }Why the eight are refused here
Business Central stores a record's dimensions two ways at once, and they are not equivalent.
The eight shortcut dimensions are real fields on the line. Everything else lives in the Dimension Set, which the shortcut fields also fold themselves into. Posting reads the fields — a posted entry's dimension columns come from Shortcut Dimension 1 Code and its siblings, not from the set.
So a value sent here for one of the eight would sit in the set, be ignored by the posted entry's own columns, and disagree with whatever the line's shortcut column says. Nobody would notice until a report came out wrong. Rejecting it and naming the column that does work is the only honest answer.
Which dimensions are the eight is a per-company choice, made in General Ledger Setup. The check reads that setup, so it is right for the company you are calling.
Where it appears
| On a | Collection is nested under |
|---|---|
| Sales document line | salesOrderLines, salesInvoiceLines, salesCreditMemoLines, salesReturnOrderLines, salesBlanketOrderLines |
| Staged ledger document line | distributions |
| Staged expense line | expenseLines |
| Staged bank / G/L line | bankGLEntryLines |
Because the same collection is reused under several parents, POST it under the line it belongs to rather than to a top-level route.
When the dimensions take effect
The two families differ here, and it is worth knowing which one you are on.
- A sales line is a live record that could be posted at any moment, so its dimension set is rebuilt the instant you write. Read the line back and the dimensions are already in place.
- A staged journal-wrapper line has not touched the ledger — that is what staging is for — so nothing is folded until the document is processed. The rows are read at that moment and merged into the journal line.
Either way the reads and writes look the same, and either way the line's own shortcutDimension1Code..8Code values are left exactly as they are.
Editing and removing
PATCH a row to change its value, DELETE it to take the dimension off the line. On a sales line the dimension set is rebuilt each time, so a delete genuinely removes the dimension rather than leaving it behind.
One row per dimension per line. A second POST for a dimension already on the line is a duplicate, not a second value — change the existing row instead.
See also
- Dimensions — the flat
shortcutDimension1Code..8Codecolumns, and how they resolve - Distributions — coding a ledger document across several accounts, which is usually what you are dimensioning