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...
To be continued...
I think there should be an 8 possible combinations:
5 green -
6 blue -
7 - black
8 - white
What do you think about this ?