Dimensions in Business Central: setting up reporting that separates your stores

Configuration · 9 min read

A multi-store retailer running one Business Central company has a reporting problem built into the design: the chart of accounts is shared, so sales, cost of goods, and expenses from every store land in the same accounts. The fix is not more accounts — it is a dimension. Dimensions tag transactions with attributes so the numbers can be analysed across more than just the chart of accounts. Set up one dimension for the store, make sure every transaction carries the right value, and the same ledger can answer "how did the north store do?" without a spreadsheet reconstruction.

This guide builds that setup end to end: the dimension and its values, the global dimension choice, the defaults that stamp the store value onto transactions automatically, the posting rules that protect it, and the priorities that decide what happens when two records disagree.

The pieces: dimensions, values, globals and shortcuts

A dimension is defined on the Dimensions page, and each dimension carries its own list of dimension values — for a store dimension, one value per store. You can define as many dimensions as the company needs, and an unlimited number of dimension values for each.

Two of those dimensions get special status. On the General Ledger Setup page you assign the two global dimensions. Global dimensions are the most accessible: they are carried on the actual ledger entries and posted document tables, they can be used as filters for general ledger entries and on all reports, and they are automatically available on entry lines and document headers as shortcut dimensions. Beyond the two globals, up to eight dimensions in total can be stored with G/L entries — the other six are shortcut dimensions, which can be assigned directly to journal, sales, or purchase lines and to master data, but are stored in separate tables rather than on the ledger entries themselves.

Dimension values can also be structured: using Begin-Total and End-Total value types and indenting the values builds a hierarchy, so a group of stores can roll up into a regional total. One constraint to respect while creating values: to set up a hierarchy, the codes must be in alphabetical order.

Setup procedure: build the STORE dimension end to end

1. Create the dimension. Search for Dimensions, choose the related link, and add a new dimension for the store concept (code STORE is the obvious choice). Keep the code short and stable — it will appear on entries for years.
2. Add one dimension value per store. Open the dimension's values and create a Standard value for each store, using codes that sort alphabetically in the order you want them to appear. If stores group naturally (by region, by format), wrap each group in a Begin-Total / End-Total pair and indent the members so reports can roll stores up into group totals.
3. Make STORE a global dimension. On the General Ledger Setup page, assign the store dimension as one of the two global dimensions. This is the step that puts the value on ledger entries and posted documents and makes it a filter everywhere. Treat the choice as long-term: changing which dimensions are global later means reprocessing posted entries, so decide before transaction volume builds up.
4. Put defaults on the records that originate transactions. Work through the default-dimension setup in the next section — locations first for a retailer, then any accounts that belong to exactly one store.
5. Set account-type defaults as the safety net. On the Dimensions page, select the dimension and choose the Account Type Default Dim action to set defaults per account type — for example, requiring the store dimension on G/L account postings where no more specific default exists.
6. Set Value Posting rules deliberately. For each default, choose how strictly the value is enforced (see the comparison table below) instead of accepting whatever the line defaults to.
7. Resolve predictable conflicts with priorities. If documents will routinely combine records that carry different store defaults, set up Default Dimension Priorities now rather than after the first confusing posting (see below).
8. Post a test transaction and check the entry. Post one sale or journal for a known store in a test company first, then open the resulting G/L entries and confirm the store value is present and correct. This is the only step that proves the other seven worked.

Default dimensions: where the store value comes from

Nobody should be typing a store code onto every line. Default dimensions are set on master records and flow down to transactions automatically: defaults can be set up for records such as customers, vendors, and items, and are copied to the journals and documents that use those records.

For store separation, the most important carrier is the location. Locations carry default dimensions, and on transfer orders the default dimensions are copied from the last location field filled in (the in-transit location is ignored). Microsoft's example makes the behaviour concrete: location EAST carries Department value ADM and location WEST carries PROD — fill in To Location WEST last and the entry takes PROD; fill in From Location EAST last and it takes ADM. Translate that to stores: give each store's location its own STORE value as a default dimension, and stock movements and location-driven transactions pick up the store tag from the location without anyone remembering to add it.

Defaults exist at two levels, and the precedence matters: a default dimension set on an individual account replaces the default assigned to its account type. Use account-type defaults (via Account Type Default Dim) for the broad rule, and account-level defaults only for genuine exceptions — a head-office cost account that must never carry a store value, or a store-specific account that always belongs to one store.

Maintaining account-level defaults is done from the account itself: for a single account use Dimensions > Dimensions-Single; to update several accounts at once, select more records and use Dimensions-Multiple.

Value Posting: the four rules compared

For a store dimension, the practical pattern is: Same Code on records that belong to exactly one store (the location, a store-specific account), so their value cannot drift; Code Mandatory with a blank value where a human must consciously pick the store; and No Code where a record must stay store-neutral. One hard warning from Microsoft: if an account is used in an Adjust Exchange Rates or Post Inventory Cost to G/L batch job, do not select Code Mandatory or Same Code for it — those batch jobs cannot use dimension codes, and the rule will break them.

When defaults collide: priorities

A single document can pull defaults from several records at once — a customer, an item, a location — and two of them may propose different values for the same dimension. Default Dimension Priorities exist to dictate which record wins. Set them up on the Default Dimension Priorities page: enter the Source Code for the entry table the priorities apply to, fill in a line for each priority, and repeat for each source code you need. One tie-breaker worth knowing before you rely on it: if two tables have the same priority for the same source code, Business Central always selects the table with the lowest table ID — deterministic, but probably not the winner you intended, so give the record that should win (for store reporting, typically the location) an explicitly higher priority.

Global or shortcut? A decision framework for the store dimension

• Will you filter the general ledger and standard reports by store? Then the store dimension must be global — global dimensions are the ones available as filters for G/L entries and on all reports, and stored on the entries themselves.
• Is store one of the two most important analysis axes in the business? There are only two global slots. For a multi-store retailer, store is almost always one of them; the second usually goes to department or an equivalent structural axis.
• Is the split only needed inside specific journals or documents? A shortcut dimension can be assigned directly to journal and document lines. If store reporting is an occasional analysis rather than the primary P&L cut, a shortcut can be enough — accepting that the values live in separate tables rather than on the ledger entries.
• Are you changing an existing setup? Changing global dimensions reprocesses posted entries and can be run with parallel processing to speed it up; the community guidance is consistent: test the change in a test environment first and expect reports built around the old global dimensions to need adjustment afterwards.

What success looks like

• The STORE dimension exists with one Standard value per store, codes in alphabetical order, and any regional groupings wrapped in Begin-Total / End-Total pairs.
• STORE is assigned as a global dimension in General Ledger Setup.
• Every store location carries its own STORE value as a default dimension with Value Posting set to Same Code.
• A test posting for a known store produces G/L entries carrying that store's value, visible when the entries are filtered by the dimension.
• Filtering the chart of accounts or a report by one store value returns only that store's activity — and the store values across all entries add back to the unfiltered total.

FAQ

Can each user get their own default store value? Not out of the box. Business Central offers no built-in way to assign default dimensions directly to users; the community workarounds are to assign the defaults to the master records the user works with (so the value flows through when the record is selected) or to build a small customisation. Design around record defaults first.

What happens to historical entries if the global dimensions change? The Change Global Dimensions process updates posted entries to the new setup — values are retained, not deleted — but reports built around the old globals may need rework, and the update can take a while on large volumes. Test in a test environment and back up first.

Can a dimension be required without forcing one store? Yes: set the default with the Dimension Value Code left blank and Value Posting set to Code Mandatory. Posting then requires some store value, chosen per transaction.

Note: Dimension setup shapes financial reporting for the whole company. This guide is general configuration information, not accounting advice — agree the dimension structure with whoever owns the company's financial reporting before changing global dimensions on a live database, and rehearse the change in a sandbox or test company first.