Log in Get free quote
New Dimension Correction tool in Dynamics 365 Business Central version 18
Dmitry

To be honest I’m thrilled to write about this topic. The thing is, that I started my NAV developer career by developing the Dimension Correction tool for NAV 3.7 and then supported and upgraded it till NAV2016. “Trust me” I know what I’m talking about. After I’ve written this post I realized that it ended up very big. So, I added a context:

Table of Contents

1. So, what are you are talking about?

2. Why do we need that?

3. Let the discussion begin

4. New Dimension Correction tool

– How to run Dimension Corrections?

– The Dimension Corrections screen

– The G/L Entries for dimensions corrections

5. How to change Dimension Values

– Validate Changes

– Run Changes

6. One more thing…

          – Which Analysis Views will be updated?

          – How Analysis Views will be updated?

7. Influence on the 3rd party systems

1. So, what are we talking about?

This is the definition from the Business Central 2021 release wave 1 plan release notes.

You can now correct dimensions for general ledger (G/L) entries to ensure your financial reporting gives you accurate insights without having to make notes of temporary data entry mistakes. For one or more G/L entries, you can change the dimension values, add dimensions, or remove them.

In short: you can change dimensions on posted general ledger entries.

I was surprised that some people thought of this as “you can change dimension values”, thinking about the dimension values list, so they didn’t understand what’s new here. No, it’s about changing dimensions on posted entries – g/l entries to be more specific, and it’s one of the problems, but I will talk about this later.

2. Why do we need that?

Once again, the description from the release notes:

When a data entry mistake happens, either in journal entries, document posting, or data added through APIs, it distorts the picture of the business you get from financial analyses. Often, the data is used only for financial reporting, and doesn’t necessarily need to be corrected on the source document.

In short: users make mistakes and posting credit memos or corrective journals is not always possible and easy. 

Just to give you an example from the real-life experience. When I managed the NAV support department at my NAVDesign company, 25% of the 1000 incoming support cases per month were about changing the dimensions on the posted ledger entries. We built all possible dimension checks before postings, to minimize the number of such errors, but they still happened. 

We built a Dimension Correction tool but didn’t give it to the users. We thought that if a user makes mistake and has to ask the support team to fix it, he will try to avoid mistakes in the future. I was wrong. Users still made mistakes. 

At the same time, “With great power comes great responsibility” like Peter Parker told us, and we thought that users are not ready to take it. Changing dimensions, even with a good tool, is not so a technical problem (it is for sure), but more a business problem. There are so many reports working on so many different data sources and on different date periods. Keeping the integrity between all of them is the key thing here. It was 6 years ago. Did things change now? Let’s try to figure it out. 

3. Let the discussion begin

I posted a tweet about the upcoming Dimension Correction tool –

 

 

 

And these two replies showing us two different worlds and opinions:

 

 

My current opinion is the next – the Dimension Correction tool is a great thing, but it should be built with the next considerations in mind:

  • Easy to use,
  • Respect accounting rules,
  • Leave trace,
  • Keep data integrity,
  • Possibility to undone changes.

Let’s look at the NEW Dimension Correction tool.

4. The New Dimension Correction tool

How to run Dimension Corrections? 

Way 1. General Ledger Entries. It’s the usual way. 

 

 

You can change dimensions for 1 entry or for a set of entries, just by selecting them

 

 

Way 2. G/L Registers

 

 

But only for 1 entry. It will use “From Entry No.”, “To Entry No.” as a filter for General Ledger Entries.

Way 3. Posted General Journal

 

Also, for 1 entry. It will use “Document No.” and “Posting Date” as filters for General Ledger Entries.

Way 4. Search

 

In this case, the Dimension Correction tool will not “know” for which G/L Entries you want to change dimensions. You need to select them manually.

The Dimension Corrections screen 

When you click on “Correct Dimensions” or run “Dimension Corrections” manually you see this screen “Draft Dimension Correction” –

 

 

If you run this from Way 1 – Way 3, it will come already prefilled with the Dimensions from the General Ledger Entry or set of entries, like this:

 

 

So, it’s possible to make one-to-one or many-to-one changes.

The G/L Entries for dimensions corrections

At the bottom, you see the selected G/L Entries for the dimension changes –

 

 

If you run Dimension Correction using Way 4 (search), you will see a blank “Draft Dimension Correction”. In this case, you have several options how to get G/L Entries:

  • Manual selection,
  • Using filters.

Manual selection

 

 

Interesting that with using “Manual selection” you can not select more than 1000 entries. 

 

 

You can remove selected entries from the “Draft Dimensions Correction”, in case you need that –

 

 

 

What’s more interesting, you cannot remove more than 5000 entries –

 

 

Also, there is a limit on the number of G/L Entries displayed here – 20 000. But you can change that by subscribing to the OnGetPreviewGLEntriesLimit() event.

 

 

Filter based selection

There are several options for how you can select G/L entries using filters. And I would say, they are impressive:

  • By Dimension Values,
  • By Custom Filters.

 

 

This can be useful if you want to change the dimension value A to B for all G/L entries. So you find all G/L Entries with the Dimension Value A

 

 

and then can change it (or other related dimensions) for all G/L entries –

 

By Custom Filters

 

 

Here you have all freedom of choice, how to filter your G/L Entries for the dimension corrections.

 

 

After you set Filters, you can then exclude some entries to make the G/L Entries dataset, the one you need. I remember that the common support issue was to change the dimension value for all entries starting from one date. Let say the salesperson was fired starting from 01 Feb 2020, but the system automatically included it in the transactions. You can do it here by:

  • Filtering all G/L Entries by the Salesperson Dimension value JO,
  • Filtering the G/L entries you don’t need to change (all before 31 January 2020),
  • Excluding these entries.

 

 

 

By using “Manage Selection criteria” you can see what filters you used:

 

 

And you can exclude some filtering here as well:

 

 

Add related Entries

This is the last available option to get G/L Entries to make dimension corrections. This requires at least 1 G/L Entry already to be selected, and then it adds all other G/L Entries with the same “Transaction No”. Let say I manually selected one entry from the opening balance journal.

 

 

 

 

And I get all related entries – 

 

 

First, I thought it will add related entries like Customer or Vendor Ledger Entries. But it’s not. It only adds G/L Entries in the same transaction. Btw, the action itself is called exactly as AddByTransaction. In my opinion, it’s more self-describing, than related entries.

 

 

5. How to change Dimension Values

Well, if you are here – I can congratulate you, the main fun begins now. After you got the G/L Entries for dimension correction using 7 different ways (I counted) or their combinations, you are ready to change dimensions in all selected G/L Entries in one go. Let’s take an example – Posted Purchase Invoice > G/L Entries.

 

While we are in the process of selecting what to change (or selecting the G/L entries if use Way 4) the Dimension Correction is on the status ‘Draft’.

 

 

Important! In Status = Draft the changes were NOT yet done to the G/L Entries dimensions. 

You can add here a new line with the new “Dimension Code” or change the “New Dimension Value Code” for the existing dimension, or both.

 

Or this:

 

 

From this moment you have two ways to go:

  • Validate Changes, then Run,
  • Run.

Validate Changes

This will check if it’s possible to make the dimension changes you specified. Actually, it will:

  • Check that Dimension is not included in the list of “Blocked Dimensions Setup”,
  • Check Dimension Combinations.

Check that Dimension is not included in the list of “Blocked Dimensions Setup”

Important! This is not about the “Blocked” field on the Dimension, this is about the new Page “Dimension Correction Settings”

 

 

Here you can specify the Dimensions, that cannot be changed using the “Dimension Correction Tool”.  From my point of view, this would be more practical if we can add here the Dimension Values. This could be a good extension for the Dimension Correction, but we don’t have an event. So, we need it OnAfterVerifyIfDimensionCanBeChanged() in the VerifyIfDimensionCanBeChanged procedure. 

 

 

Check Dimension Combinations

This will check that the New Dimension Values respect Dimension Combinations Setup, if we want to add new dimensions –

 

 

But we have the dimension combination rule –

 

 

You will have this error:

 

 

What is missing here?

From my experience there should be at least next checks to be added: 

  • Check if the G/L Entry posting date is inside the allowed posting dates from the “General Posting Setup”. It should be not allowed to change dimensions for the closed periods,
  • Check if the G/L Entry posting date is inside the allowed posting dates from the “User Setup” for the user who change the dimensions
  • Check if Accounting Period is not closed,
  • Check if the Dimension is not blocked (“Blocked” field on the Dimension),
  • Check if Dimension Value is allowed for G/L Account,
  • Check if Dimension Value is mandatory for G/L Account (in case of removal),
  • Check if Dimension Value is the Same as configured for G/L Account (“Same Code” check),
  • Check if Dimension is not included in the “No Code” list for the G/L Account,
  • Check if IC functionality is not used in the General Ledger Entry.

If you have any other additional check-in mind, please add it as a comment.

 

What is not intuitive here?

When the user clicks on “Validate Dimension Changes” I assume he wants to do the check immediately. But the system will run a Job. And it asks the user if he wants to run the job now or later.

 

 

Maybe it’s good if the number of selected G/L entries is huge (but we remember that is not possible to select more than 1000 entries). But for the usual situations, I think it’s not required. Because even if you click on “Run immediately” BC will close the “Draft Dimension Correction” page and the user will be lost.

 

 

And even if you immediately will click on “Correct Dimensions” (for the same selected entries for this particular Posted Purchase Invoice) you will see –

 

 

Yes – Blank “Draft Dimension Correction”. Which is weird, for me at least. To see the “Draft Dimension Correction” you worked on before you need to click on “History of Dimension Corrections”.

 

 

Find there your draft,

 

 

Open it and check the validation status.

 

 

Run Changes

 At last, from this moment we can Apply changes to the General Ledger Entry Dimensions. Use the “Run” action.

 

 

This will also be executed as a Job. The user will have to choose, how he wants to apply changes: running the job immediately or schedule it.

 

 

 

And finally, when the Job was executed –

 

 

And if we check the dimensions for G/L Entries, we will see new values:

 

 

What is not intuitive here?

I can agree that running the Job when you apply changes could make sense – but only if the dimensions were pre-validated before. We remember that users can run dimension changes without validation. In this case, the system will validate dimensions during the Run process automatically. In case of errors, the user will not be notified about them. He will need to go to the “Dimension Corrections” page from “History of Dimension Corrections” somewhere later and check if it was executed successfully or not.

6. One more thing…

I guess looking at the screenshots you noticed one interesting flag “Update Analysis Views”.

 

 

What will it do? In the tip, it says: “Specifies if the Analysis views should be updated at the end of correction.”. But which analysis views and how they will be updated? Which Analysis Views will be updated?

These will be Analysis Views, which are:

  • Not Blocked,
  • of G/L Account type,
  • Updates on posting,
  • Has dimension that was changed/removed/added.

What is missing here?

First of all, the “Posting Date” filter. The analysis view can be skipped if we want to change Dimensions for the G/L Entry which is out of Analysis View “Starting Date”.
Second, “Account Filter”. The analysis view can be skipped if we want to change Dimensions for the G/L Entry which is out of Analysis View “Account Filter”.
And I would be very happy if there will be an option “Don’t update on Dimension Correction”. This could be a good extension, but we don’t have an event for that. So, I asked to create it.

 

 

How Analysis Views will be updated?

It’s simple and scary at the same time – the analysis view entries will be deleted and created from scratch. 

Why it’s scary?

I saw many databases where Analysis views were so big, so they were updated for 10-20 hours. There could be 10+ different analysis views, with different dimensions and G/L account combinations.
Now realize that “Update Analysis Views” is a flag on the “Draft Dimension Correction” page. So, every time a user will pick this flag during the dimension correct for 1 G/L Entry or set of G/L entries the system will recreate all related Analysis Views. How do you feel now? I feel scared.
You can say that – “Ok, don’t pick the update analysis view flag”. The thing is that usually the users who are responsible for dimension changes, and the users who are responsible for system stability and productivity are two different users. And when the first will activate this flag the second will suffer (and all the other users as well).

What is missing here?

From my point of view, this should be done smarter. Let say if “Data Compression” of the “Analysis View” is “None” then update “Analysis view entries” only related to the selected G/L Entries. For the “Data Compression” equals to Day, Week, etc. mark the Analysis View as “Require Updating” or something like that, maybe with the links to the “Dimension Correction” entries. In this case, user will see that the Analysis View and Account Schedule based on this View is not UpToDate and will schedule update manually.

If you have your thoughts on this, you can leave them as the comment as well.

7. Influence on the 3rd party systems

When we change dimensions for the G/L Entry the 3 fields are updated:

  • GLEntry.”Dimension Changes Count”
  • GLEntry.”Last Dim. Correction Entry No.”
  • GLEntry.”Last Dim. Correction Node”
  • GLEntry.Modify(true)

I guess (I didn’t check) that this will also run the Webhook that the G/L Entry was changed. You can subscribe to this and pull updated data. 

And I don’t know how Power BI will be updated in this case. Maybe this is a topic for another blog… or inspiration for you to write about this.