Implementing Financial Dimensions for D3FO - Part 4

This is part four in a four part series.

Click here to read part 1.

Click here to read part 2.
Click here to read part 3.

In parts 1-3 of this series, we’ve examined the various decision criteria around what General Ledger dimensions to implement.

Account Structures: Implementation Considerations

Now let’s look at tips for setting up the actual account structures in Dynamics 365 for Operations.

Here is a sample set of account combinations and dimensions that will work for many companies using Dynamics 365 for Operations in a manufacturing environment.

1.  Make sure each account appears in one and only one account structure

Generally, I would suggest using the ranges of contiguous accounts for each major section of your Balance Sheet and Profit & Loss accounts.  For example, all Cost of Goods Sold accounts are in the range 5xxx – 5499.  This is a good practice and it certainly streamlines reporting, makes it easier to remember numbers, etc.

If you take this approach, then make sure you leave yourself enough room to add NATURAL accounts.  The argument for not putting logic in numbering sequences is that over time they tend to get out of whack.  However, dimensions will typically minimize the numbers of accounts you’ll be creating anyway, so you should be able to stay within your logic structure if you allow even a little bit of wiggle space.

That being said, there is no hard requirement to have contiguous ranges of accounts, and if you are locked into an existing chart, or have other business reasons to have multiple ranges of accounts, AX will handle multiple ranges of main account for a dimension.

Regardless of how the accounts are numbered, each account can only be included in one active account structure at any time.  See point 2 below for more on this.  But given this, one technique that not only helps prevent duplicates but also can streamline the setup process is to export the chart of accounts to a spreadsheet, and then simply enter the proposed account structure in each row.

2.  Make sure that the active account structures are linked to the Chart of Accounts

Notice in the first image above, the status (Active or Draft) is listed next to each account structure.  When an account structure is active, it only means that that structure can be associated to any chart of accounts.  It is not actually live until that association is made.  This is done by adding the account structure to the ledger.  The system will validate that the new account does not exist on another structure, and it will not attach the new account structure if any duplicate exists.

3.  Pros and cons of inter-dimensional business logic

One of the strongest features of the Dynamics 365 for Operations implementation of General Ledger dimensions is the simplicity of setting up the business logic to validate inter-dimensional combinations.  In other words, which dimensions are valid for a dimension given an existing value in another dimension.

For example, in the example below:

• Sales posting to Business Unit 0000000001 can only be to customers in the Dairy and Grocery market segments
• Sales posting to Business Unit 0000000002 can only be to customers in the Grocery and Wholesale market segments
• Sales posting to Business Unit 0000000003 can only be to customers in the Wholesale market segment
• Sales posting to Business Unit 0000000004 can be to any customer in any group (in other words, no market segment is specified for this business unit)

Now, there are some pros and cons to this approach. The major benefit is that it will prevent erroneous data from getting into the GL, which means less reclass journal entries. The major downside is that defining the rules takes some time and energy. Personally, I think a little upfront work in a much less time-constrained window is well worth preventing errors that have to be fixed when you are crunched for time.

4.  Pros and Cons of Allowing Blanks

Another consideration is whether or not blank values should be allowed.  This simply means that the dimension is optional.  If you use inter-dimensional rules and do not allow blanks, it will block transactions if the wrong combinations are used.  This can be sticky if the transaction is, say, a sales order shipment.  While preventing bad data is a great goal, preventing a shipment from going out the door is far worse than having to do a reclass journal.

Now, I’m not saying that you shouldn’t have a rigid system, with strict rules with no blank values.  If you do, take precautions to ensure that the right combinations are defined up front.  This is a great use of workflows.  For example, setting up a new customer group can have a step to add the dimension rules.