NAV/BC Version Numbers

Many others have posted this information before. I’m just putting this on my own blog because I have noticed a decrease in the number of ‘old’ blogs out there and this is getting harder to find. I’m just securing the information so that I know I’ll have it for as long as I keep my blog up.

When I started as a Navision developer in March of 2000, version 2.5 had just come out. Most of the clients that I worked for were on 2.01. The version that is current today (v21 for the 2022 Wave 2 release, and v22 is just a couple of months away) directly derives from that version back in early 2000. There are earlier versions than that, and you can search for the history yourself, but I have never encountered anything older than 2.01. I just wanted to have a handy list as a quick reference.

Here They Are

  • Navision in various incarnations (Financials, Attain, Microsoft Business Solutions) 1, 1.1, 1.2, 1.3, 2, 2.01, 2.5, 2.6 (also versions with manufacturing and another with Advanced Distribution, as well as specialty versions for the first NAS 2.65 a, b, c, d, and e), 3.00, 3.01, 3.10, 3.60, 3.70, 4.0, 4.0 SP1-SP2-SP3, 5.0
  • Dynamics NAV 2009 is version 6 – also had SP1 and then R2
  • Dynamics NAV 2013 is number 7 – also had R2
  • Then there were NAV 2015 (8), 2016 (9), 2017 (10), and 2018 (11)
  • Version 12 was the first BC version, AKA Business Central 2018. For a while there (at least through BC14) was a bit of a split personality with the splash screen saying “Microsoft Dynamics NAV Connected to Dynamics 365 Business Central”, a very catchy and easy-to-remember 24-syllable name
  • From then on there is a release every 6 months:
    • 13 – October 2018
    • 14 – April 2019 (this was the last version with C/SIDE)
    • 15 – BC 2019 wave 2
    • 16 – BC 2020 wave 1
    • 17 – BC 2020 wave 2
    • 18 – BC 2021 wave 1
    • 19 – BC 2021 wave 2
    • 20 – BC 2022 wave 1
    • 21 – BC 2022 wave 2
    • and so on and so forth

update 2023-02-14: added some missing versions

Save Report Filters

Going back into the stone age, report objects have always remembered the filter values for the next time that you run the report. What I never noticed was a capability to actually save filter values (yes I now realize that it’s been in there for years now). It’s similar to saving a view of a list page, but for reports. It works a little hinky but let me try and explain.

What I Am Talking About

You may have noticed it in some (but not all) reports, processing-only or actual printed ones. Right at the top of the request page, you see a dropdown box with the words “Last used options and filters”. Click the dropdown arrow and that should show you an option to “Select from full list”.

This opens the “Select – Report Settings” page. The page actually has nothing to do with any settings, but it does show you a list of saved values for the options and filters of the report object. In my mind I am calling it a ‘view’.

I just created a bogus empty report just to show you the options, so ignore the content of the report itself. The interesting part of this page is what you can do. When you click the ellipses, you get a number of options.

  • Delete – obviously to delete the currently selected option
  • New – creates a new record, where you can give the saved value a label and you can define whether this view is for all users or not. Assigning the view to a specific user is done on the list page itself
  • Copy – creates a new record with the same values as the one that’s called “Last used options and filters”
  • Edit – This only works on custom views, and it runs the report’s request page where you can enter the options and filter values for the current view

You can assign the view to a specific user or share it with all users. If this capability is enabled for a report, you should be able to pick from the list of views right from the request page.

How To Enable This

You need to do two things to enable this capability.

  • First, you set the ‘SaveValues’ property on the report’s requestpage. If the report doesn’t have a requestpage, you can add one with just the property and no controls
  • Second, you need to run the report. When you first deploy the report with SaveValues turned on, it does not yet have a view saved. Run the report with any filter/option value and it should create this record for you
requestpage
{
    SaveValues = true;
}

A Little Hinky

To me it feels a little unfinished, like it was rushed into the system. To begin, it’s inconsistent in labeling. On the requestpage it is called “Use default values from” which is incorrect. This is about ‘saved’ values, not ‘default’ values. Then when you open the full list, it is labeled “Select – Report Settings” which again doesn’t feel right. I don’t consider filter values a ‘setting’. Then when you click ‘New’ it opens a screen that is captioned “Edit – Pick Report”… I mean come on… Finally, having to run the report in order to even get the dropdown is not very user friendly. When I first tested this I thought I had done something wrong because the dropdown would not show.

Another big drawback is that the SaveValues property is not available in Report Extensions. You’ll have to copy the standard object in order to provide the capability.

Regardless of its hinkiness and shortcomings, the feature itself is great, especially when you have periodic activities to run for different sets of filters. it’s really nice to have the ability to preconfigure sets of option/filter values. It has the potential to increase productivity and eliminate typos in entering filters. In my opinion, this feature should be enabled by default.