Hans Peter Bech, former Central Europe VP of Navision Software, illustrates the the go-to-market model behind the expansion of NAV in Germany in the early 90s, the first market after Denmark where NAV was distributed.
Hope you all enjoy this reading, article is available here.
One of the new cool things about the development environment of NAV 2016 is the support of regular expressions.
The more I use, the more i like this new version! 🙂
Yesterday at Directions EMEA in Mannheim NAV 2016 has been officially announced. Many of you probably have already read since the blogosphere is in turmoil, but I still want to point out some of the features that makes me more excited about this new new major release:
A few other points:
Time to start discovering it!
In the last days I came across an issue that took a while to me be solved. An user by mistake removed the SubPage contained in a page of type List:
Afterwards it was not possible to set its visibility back because into the Customize This Page function the option FastTab was not available, contrary to when the function is called from documents pages:
Changing the main page type from List to ListPlus is the solution triggered the FastTab option to be shown:
Code fields in NAV very often store numbers: most of the people assume them to be sorted as an integer, but let’s see how NAV deals with a table having one code field as primary key:
Numbers are not in ascending order, due to how SQL handles this type of fields.
When creating a new code field in NAV, nvarchar type is used inside the SQL table structure: since it’s a string SQL Server in terms of sorting considers the position of each character, causing the problem shown above when comparing numbers whose digits are not in consistent positions.
From a SQL prospective it’s possible to pad values to a fixed length as workaround using REPLICATE clause:
But how about NAV? It’s possible to restore the (beloved) native database behavior changing the value of SQL Data Type property of the field to Variant:
This will affect the SQL field definition switching it to sql_variant, allowing to execute the correct number sorting:
But before applying this change take carefully in consideration these effects:
UPDATE: on August 20th 2014 a new cumulative update for NAV 2013 and 2013 R2 has been released and include the bugfix no. 360182 “FlowFields with mixed SQL Data type work in an unexpected way”. I will test soon this new build in order to understand the benefits.
During training sessions one of the first topics is managing filters in pages and report. Indeed master data with limited number of entries are chosen, to be make explanation more understandable. This time I accidentally picked a G/L Account with several thousands of entries so, selecting records with document type different than invoice and credit memo, meant a few seconds of wait every time an option was ticked.
At that point the course attendants started being a little skeptical, and made a point about the total time necessary to perform the query, close to 15 seconds. So, I suggested to compose the filter with the QuickFilter box, using the usual syntax, in order to speed up the filtering and drop down to 3 seconds the full execution time:
I normally avoid showing this filtering method because most of the times writing inside the box the values to select/exclude takes more time than ticking the options, but in a case like this definitely worth using the QuickFilter.
Speaking of users productivity, I noticed also that almost no one run actions shown in the role page with the mouse right-click on the task bar:
I personally find this way very fast and practical since it allows moving to a new document/page without stepping back to the main page, especially when a Role Center is well designed and the promoted actions effectively match with daily operations. Do your users act with the same behavior?
In NAV 2013 I experienced on several installations a bug in modifying the sorting on Customer Ledger Entries page. As usual, after clicking on the key list, a different one from the default used is chosen:
But nothing happen. The most common reaction – and mine too – is selecting the sorting again (guessing not to have clicked in the right area) but the effect is the same. Nothing.
The solution I found after several attempts is removing the sorting placed in “Ledger Entries” action of Customer List and Customer Card pages, and add it on Customer Ledger Entries, which doesn’t have any key specified by default. Et voilà, now it’s working again, I’m able to change the key with a different one 🙂
The identical issue occurs also on vendors and items and can be fixed with the same resolution. Meanwhile NAV 2013 R2 is not affected, due to the new sorting behavior which allow sorting by whatever field regardless of keys defined in the table.
Yes, I have to admit it. I’ve always been a blog lurker, especially after starting working with Dynamics NAV years ago. Since there are already plenty of experts writing about how to solve technical issues, best practices, tips and innovations, why another one?
Well, I thought about this question last week reading an inspiring article by Hannah Horning about blogging frustrations. I realized that I actually miss an on-board diary for keeping trace of the most puzzling problems faced, the ones causing severe headaches while trying to find a solution which is, some cases, much easier than you think.
So, now that the blank page fear is beaten with this brief introduction, let’s really get started!
PS: as Lotus supporter, I didn’t miss the chance to use in the header the same color combination as Dynamics sponsorship on Lotus F1 car 🙂
Rebu's Dynamics NAV diary 