Continued from Dynamics NAV 2013 | Dimensions (I)
So how does this Dimension Set thingy work.
Let's say you have two dimensions A and B. Dimension A has values Green and Blue and dimension B has values Black and White
This means the following possible combinations
Each combination gets a number. These combinations are stored in the new Dimension Set Entry (480). This table does not Always contain all combinations. If we add Red as value for A, the combinations get added only as they are used.
Now all we have to do at document and journal level is create a table releation with this combination table.
Since this is a 1:n relationship, one combination relates to many documents and journals we can do this with a field in the table rather than the n:1 relationship between the document table and the document dimension table in the previous version.
As we are used to in NAV, this has an implicit "Design Pattern". The fieldnumber that relates to the dimension set is Always field 480 Dimension Set ID and it Always contains the same code.
The coding is done in two places. First is creating the journal and document data, the second is moving the data during posting/archiving.
Creating the data is slightly more difficult, but since we can use code cloning it is not hard to implement.
Each table with a Dimension Set ID has this function. It was also there in the previous version but now it is changes. Let's have a look at it.
TableID := Type1;
No := No1;
"Shortcut Dimension 1 Code" := '';
"Shortcut Dimension 2 Code" := '';
OldDimSetID := "Dimension Set ID";
"Dimension Set ID" :=
DimMgt.GetDefaultDimID(TableID,No,SourceCodeSetup.Sales,"Shortcut Dimension 1 Code","Shortcut Dimension 2 Code",0,0);
We see in this code that the Dimension Set ID is calculated in codeunit Dimension Management (408). The magic that is done here wil be explained in a later post. Point here it that we just have to copy (clone) the code to make it work.
Since the data in the database is now normalised, we can no longer have a form or page that simply shows the data from the database. This has to be programmed. This is also included in the Dimension library.
"Dimension Set ID",STRSUBSTNO('%1 %2',"Document Type","No."),
"Shortcut Dimension 1 Code","Shortcut Dimension 2 Code");
All the magic is done inside the library and all we need to do is call this function. NAV will handle the hard stuff.
The page it runs (480 Edit Dimension Set Entries) uses a buffer table and the SourceTableTemporary property that I've expained in other blogs.
A frequently asked question is: "What about global dimensions, are they still there?" or "Can I filter on dimensions?". This has not changed in any way.
So what about posting? This is where it get's really cool.
Remember in previous versions we used to write this code
TempDocDim.SETRANGE("Table ID",DATABASE::"Sales Line");
TempDocDim.SETRANGE("Line No.",SalesLine."Line No.");
First moving the data into a buffer table, then moving to another buffer table which then is a parameter to the posting routine, where again it is moved from the buffer table to the destination table. Are you still with me?
This is the code in NAV 2013:
ResJnlLine."Dimension Set ID" := SalesLine."Dimension Set ID";
The complete buffer thingy is gone and no more ugly parameters to the posting routines. The only thing we need to do is move the Dimension Set ID from one table to the other table.
It's F*cking briljant.
This uses a Design Pattern that decouples the UI from the Table. Something we have discussed within PRS a couple of times. I expect more to see of this Design Pattern in the future and it opens a new way of thinking in Dynamics NAV.
To be continued...
It has been 2,5 years since my first book was published about Dynamics NAV application design.
Since then much has happened. My youngest son Daan was born, we moved to a new house which we are fixing up etc.
I also helped starting up the Dutch Dynamics Community and initiated Partner Ready Software together with Eric and Gary.
But now its time to update the book.
During the last years I have had many compliments about the book, had many "thank you's" etc.
What I want now is to hear what the book is lacking! What to you want it to change?
It's not going to be a complete rewrite. The Table of Contents will not change, I think the general structure of the book makes sense.
Off course I will implement the basics of PRS what we have been evangelising for a while and explain the design of Dimensions, Assembly, Time Sheets, etc in 2013.
What else would you like?
(Be carefull, I will moderate feedback to what I like... )
Directions EMEA 2013 has been anounced.
For those who haven't heard, it is shifted from Spring to Fall.
Fortunately not that much Fall but late summer. September 2 - 4 that is. Which leaved enough time between EMEA and USA if this coninues in end october/early november as is has always been.
More information: http://www.directionsemea.com/
Ok, this is the last I'm going to blog about Dynamics NAV 2013 and Azure.
Just got a message from MSDynamicsWorld. According to their information an "Azure-hosted solution of some sort for NAV 2013" will be shipped in Q1 of next year.
Im curious about the "of some sort" part...
Read the full article: