Dim. values of G/L Entry differ from Ledger Entry Dim. table

tcp_2008

Hello,

In NAV 5.00, I noticed that sometimes Dimension values in the G/L Entry table differ from the dimension values in the Ledger Entries Dimension table.

I can't reproduce this bug but the value in the field "Global dimension code" of T17 G/L Entry is different (or blank) in the field "Dimension Value Code" of the T355 Ledger Entry Dimension.

From the form 20 General Ledger Entries, I access to the form 544 Ledger Entry Dimension with Entry button -> Dimensions.

If someone have already seen this issue...

Many thanks

ara3n

I have seen this a lot. The problem is mostly related to a programming modification and how the GenJournal is created.

Standard NAV does not check that the Dimension table and gen journal Global 1 and Global 2 Matches. So when GL Entry is created it copies the values from journal, and not from Ledger Entry Dimension.

I've also seen this if you copy and paste the dimensions from one journal line to another. The fix is easy but it should be added to standard NAV to test and make sure they are the same.

tcp_2008

Hello ara3n,

You are right we also have a lot of uncorrect entries...
What did you do to fix easily this issue i.e to test and make sure the dimension match ?

Do you check Dimensions between table 81 Gen. Journal Line and table 356 Journal Line Dimension before posting ?

When you say that's "the problem is mostly related to a programming modification and how the GenJournal is created" , what kind of modification/creation is it ? Modifications from Microsoft ? Do you have examples?

Many thanks,

ara3n

You are right we also have a lot of uncorrect entries...
What did you do to fix easily this issue i.e to test and make sure the dimension match ?


Do you check Dimensions between table 81 Gen. Journal Line and table 356 Journal Line Dimension before posting ?

In CU 11 you can add code to check TempJnlDim and Journal line
What I usually do is in CU 12, when initGLEntry is called I change
GLEntry."Global Dimension 1 Code" := and instead populate it from the TempJnlLineDim Variable.

When you say that's "the problem is mostly related to a programming modification and how the GenJournal is created" , what kind of modification/creation is it ? Modifications from Microsoft ? Do you have examples?

Find out where the GL Entries are created from. And then check how the Journal line is created.
As far as code is concerned, it NSC creating modification/ loading initial Balances through dataport that miss this.


An example would be like this.

clear(GenJournal);
GenJournal.validate("Posting Date",TODAY);
GenJournal.validate("Account No.",'12000');
GenJournal.validate(Amount,100);
GenJournal.validate("Bal. Account No.",'12000');

DefaultDim.setrange("Table ID",Database::"G/L Account");
DefaultDim.setrange("No.",'1200');
if DefaultDim.findset then repeat
  //Populate TempJnlDim and insert it.
until DefaultDim.next = 0;

GenJnlPost.run(GenJournal,TempJnlDim);

tcp_2008

Thank you for your answer ara3n,

I will check that.

And you're right the only way I can reproduce this bug is when I import data (with dimension) in table 81 with a dataport. I can post the lines and I can see that's there is dimension in the G/L entries but not in table 355 Ledger entry dimension... NAV doesn't check if the table 356 Journal Line Dimension is filled in.

Many thanks,

tcp_2008

Finally there is a real bug in NAV 5.1 when using unapply function in a very specific way.

In that case global dimension codes are not correctly filled in table 355.

It's now in developpement status at Microsoft...

ara3n

I'm thinking that more NAV waits for released the next version the more stable 2009 will get business logic wise. SP1 had about 350 issues resolved, and every month there are around 100 issues that knowledge releases.