# Dimension Set Lines

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

```
eOne/core/v1.0/dimensionSetLines
```

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.

> **Note:** Dimensions 1 to 8 are **not** set here. Use the line's own `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.

```http
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`](https://eonesolutions.github.io/eone-bc-integration/core-distributions.md) |
| Staged expense line | [`expenseLines`](https://eonesolutions.github.io/eone-bc-integration/core-expenseLines.md) |
| Staged bank / G/L line | [`bankGLEntryLines`](https://eonesolutions.github.io/eone-bc-integration/core-bankGLEntryLines.md) |

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](https://eonesolutions.github.io/eone-bc-integration/dimensions.md) — the flat `shortcutDimension1Code`..`8Code` columns, and how they resolve
- [Distributions](https://eonesolutions.github.io/eone-bc-integration/core-distributions.md) — coding a ledger document across several accounts, which is usually what you are dimensioning

## Dimension Set Lines 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)_ |
| `parentId` | Parent Id | GUID of the document line these dimensions belong to. Stamped from the collection you POST under. _(ro)_ |
| `dimensionCode` | Dimension Code | The dimension, e.g. PROJECT. It must NOT be one of this company's eight shortcut dimensions - those are set with the line's own shortcutDimension1Code..8Code columns, and a value sent here for one of them would be ignored by the posted entry. See Dimensions. |
| `dimensionValueCode` | Dimension Value Code | The value for that dimension, e.g. TARIFF-A. It must exist as a Dimension Value under dimensionCode. |
| `lastModifiedDateTime` | SystemModifiedAt | _(ro)_ |