Upgradation to 2013-Dimension Set Entry table

DynamicUser

Hi Everyone

I am doing a upgrade from Nav 2009 R2 to Nav 2013 & I struck in Dimension Set Entry table.

Customer has data in Journal Line Dimension & Document Dimension tables & these tables have removed from new version & they build a new table called Dimension Set Entry Table.

Now the question is How to move the data from discarded tables to new tables ? & keeping in mind that discarded tables have customization also.

BardurKnudsen

Did you look into the Upgrade Tool yet? The upgrade tool does the conversion of dimensions. However, since the customer has customized code in the dimensions, you need to analyze how these can be brought forward to NAV2013, and subsequently make any necessary adjustments to the upgrade tool.

Erik_Heirbaut

I have a similar problem: In NAV 2009, we added document dimensions for a custom table in our solution (Table ID 11122600) in the NAV table 357.
When upgrading, these document dimensions are not converted to Dimension sets and the newly added "Dimension Set ID" field in our custom table remains empty.

I have been digging through the upgrade codeunits 104048, 104049 and 104050 and the error log after upgrading. The log says "The dimension table 357 and parent table 11122600 do not have matching keys." This error is registered after the function AreDimKeyAndParentKeyCompatible() in Codeunit 104049 "Upgrade Dimension Entry - SQL" exits FALSE.
Our table 11122600 has a single-field Primary key: "No." (code 20). Extending that primary key with a "Document Type" field does not solve it.

So, my question is: What do I have to do to make NAV include our table in the document dimensions conversion? I notice the same problem happens with the default NAV table 295 "Reminder Header".

drstakz

Hi everyone,
Currently solve the same problem.
I added to our table field "Dimension Set ID", but dimension upgrade for this table is with same error: "The dimension table 357 and parent table 70501 do not have matching keys."
I find same problem in function AreDimKeyAndParentKeyCompatible().

Some progress on a solution?

drstakz

So OK,
solution for me was:
Create a same primary key as is used in the table Document Dimension into our custom tables. Function "AreDimKeyAndParentKeyCompatible" validate that primary key has same variable type for tables Document Dimension and our custom tables (Option-Option, Code-Code, Integer-Integer). Our tables hasn't field "Document Type" (Option). So I copy this field from Document Dimension table into our tables and added this field to first Key (sequence of fields must be identical)
"Document Type,No." OR "Document Type,No.,Line No."
With this table update was data upgrade without problem. I get new "Dimension Set ID" to our tables.

Second solution what I tried, faster:
No tables update was necessary. I only modify codeunit 104049 Upgrade Dimension Entry - SQL. In the function "UpdateParentTable" I added our tables name to condition for "KeyOffset" set. Again after data upgrade no error was detected and I get new "Dimension Set ID"

Our tables name are Set-off Header, Set-off Line, Debt Adjustment Line, Posted Credit Line.

  IF SQLReader.HasRows THEN
    WHILE SQLReader.Read DO BEGIN
      ParentTableID2 := SQLReader.GetInt32(0);  // Parent Table ID
      Window.UPDATE(2,GetTableName(ParentTableID2));
      IF (ParentTableID2 IN [DATABASE::"Standard Sales Line",DATABASE::"Standard Purchase Line"
         ,DATABASE::"Set-off Header",DATABASE::"Set-off Line",DATABASE::"Debt Adjustment Line",DATABASE::"Posted Credit Line"]) THEN
        KeyOffset := 2
      ELSE
        KeyOffset := 1;
      GetTableKeyFieldArray(ParentTableID2,ParentTableKeyFields);
      IF HasTableField(ParentTableID2,DestDimFieldName) AND AreDimKeyAndParentKeyCompatible(KeyOffset) THEN BEGIN
        SQLCommand.CommandText := UpdateLedgerEntryTableQry(ParentTableID2,KeyOffset,DestDimFieldName);
        SQLCommand.ExecuteNonQuery;
      END ELSE
        IF NOT AreDimKeyAndParentKeyCompatible(1) THEN
          UpgradeErrorLog.SetError(STRSUBSTNO(Text001,DimTableID,ParentTableID2),DimTableID,'');
    END;

manisharma31

I am also stuck up with an issue,
We have recently upgraded a customer from version 4.03 to 2009 R2 and then in to 2013 and then into 2013 R2.

When ever a user creates a Cash Receipt Voucher or Cash Payment Voucher or a Purchase Order and in that user selects the Global Dimension 1 & Global Dimension 2 and some time even Shortcut Dimension 3 or 4 from navigate action->dimension.

After clicking ok when he tries to post that entry getting error of dimension missing as dimension are code mandatory.

When user checks again on the action->navigate->dimension, the dimension are missing.

How is it possible that the dimension are getting deleted, even after the user had selected the dimension.

This is happening in IN NAV 2013 R2.

Also asked here ->http://dynamicsuser.net/forums/t/73103.aspx

davmac1

maybe you have custom code that is over writing the dimensions.
I found that custom code to handle dimensions that worked in the old versions had to be moved to a different place in NAV 2013R2.

Asallai

The key is after upgrade: add value for the Dimension Value ID (F12) in table Dimension Value (T349). For example : make a repeat cycle, from 1 to until end of records.
Set Dimension Value ID field property AutoIncrement to False before run.