Inconsistency in the G/L Entry Table

santhanak

Hi all,

one of my customer trying to unapply the Customer Ledger entry, while doing so they are facing an error "Inconsistency". I found this in Mibuso forum posted by Ahamed (http://www.mibuso.com/forum/viewtopic.php?f=5&t=22748). it was not working in our Customer License which has application builder permission. somewhat i managed to code given by Ahamed and find the difference entry which as follows..


Posting Date Document No.G/L Account No. System-Created Entry Amount Additional-Currency Entry No.
6/10/2011 RZ00005184 87060 Yes -2,767.66 0 742759
6/10/2011 RZ00005184 87060 Yes 1,588.40 0 742760
6/10/2011 RZ00005184 12110 Yes 1,179.26 317.51 742761

i guess the difference here is 1179.26. so i passed the journal between these GL for the difference and searched for the main entry that customer is trying to Unapply. still it was throwing the same error as incosistency.

please provide me the solution what should i do to get rid of this error?

thanks in advance

ara3n

if you have not made any modifications, this is standard nav process. I suggest to look at partner source for hotfixes for your version or contact MS.

santhanak

thanks for your reply.

are you referring to customization? if yes, yeah that database is customized NA version . we are recently upgraded from NAV4.0 SP3 to NAV2009 SP1.

anyother clue other than going to partner or MS? thanks again!

ara3n

what I meant is that have you done any customization in un-apply area. I suggest to get a NA cronus db. Make the same transaction as in your system and then try to unapply. First see that the current record matches what is in your db. It could be upgrade related. Once you confirm that the records look exactly the same, then try to un-apply. If it works Cronus, then compare using codecoverage on where Cronus deviates from your db.

santhanak

Hi Ahamed,

tried in test DB but it doesn't work. so, finally business reversed the transaction by making another journal entry and then passed the correct journal entry and applied it.

thanks for your suggestion.

Tinius

Hi,
I'm experiencing this with both Customer and Vendor un-application; Version is 2009 - no modifications in un-application;
The inconsistency definately arise due to Additional currency amounts. And only if original enrty and applied entry are in different currencies, and one of those is set as the additional reporting currency. -Maybe that's not the case, but anything else works just fine -I get it only in this situation.

I'm looking for an error in cdu12.UnapplyCustLedgEntry;

in a loop, that loops through DtldCustLedgEntry2 there's a function named AutoEntrForDtldCustLedgEntries; It's used basically for inserting GL Entry to GLEntryTMP, by calling InitGLEntry, then InsertGLEntry for realized/unrealized gains/losses and such transactions (not Application or Initial entries of course) - determined by CASE statement;
The thing is that once InitGLEntry is called - the third parameter is always 0 - That's the Add Curr Amt.

After a DtldCustLedgEntry2 loop:
IF (TotalAmountLCY <> 0) OR (TotalAmountAddCurr <> 0) AND (GLSetup."Additional Reporting Currency" <> '') THEN
InitGLEntry(CustPostingGr."Receivables Account",TotalAmountLCY,TotalAmountAddCurr,TRUE,TRUE);
Here, the third param is the TotalAmountAddCurr, and that's exactly the difference I see in GL entires(Add Curr Field) after doing Ara3n's stuff described in (viewtopic.php?f=5&t=22748) - Thanks again - that's great.

Actually the application GL entries generated no amounts in "Add Curr Amount" field in GL entries, so I suppose those shouldn't in un-application..??? maybe setting 3rd param to 0 would do the job

TotalAmountAddCurr - is the accumulation of all DtldCVLedgEntryBuf."Additional-Currency Amount" amounts inside the loop;

That "brings" me back to the loop, and especially a part

IF GLSetup."Additional Reporting Currency" <> DtldCVLedgEntryBuf."Currency Code" THEN
DtldCVLedgEntryBuf."Additional-Currency Amount" :=
CalcAddCurrForUnapplication(DtldCVLedgEntryBuf."Posting Date",DtldCVLedgEntryBuf."Amount (LCY)")
ELSE
IF GLSetup."Additional Reporting Currency" <> '' THEN
DtldCVLedgEntryBuf."Additional-Currency Amount" := DtldCVLedgEntryBuf.Amount;

which looks suspicious to me, because I'm experiencing this only when application currencies differ, and one of those is the AddCurr in GLsetup;

In the first clause, when GLSetup."Additional Reporting Currency" <> DtldCVLedgEntryBuf."Currency Code" the DtldCVLendgBuff.AddCurrAmt is filled using conversion of the Un-application date, and Amt(LCY) of the buff
Otherwise when currency equals the one in GLSetup.AddCurr buff.Amount is taken, but it doesn't neccessarilly equals amt(LCY) converted to original AddCurrAmt, and even with other date's exch. rate than original transaction..

I'm very confused. Can anyone share their optinion on this - and what should be the correct way to fix that?

Thank you in advance, and excuse for lots of abbreviations, I wanted to make this as short as possible.

jglathe

Hi Tinius,

that's a good analysis of the problem. There are several "specialties" with the Additional Currency (ACY).

1. Customers and vendors don't have ACY, but the G/L side of the posting has. Therefore this amount will be calculated. The general rule is:

Source Currency Code of the GenJnlLine = ACY -> use Amount (FCY)
Source Currency Code of the GenJnlLine <> ACY -> calculate ACY from Amount (LCY).

2. When it comes to inserting the resulting G/L entries, this mostly happens with the flag "CalcAddCurrResiduals" set to true. So, the HandleAddCurrResidualGLEntry() function will get called, and the resulting ACY amounts will be accumulated. When the LCY amount reaches zero and the ACY is not, and a non-ACY currency code has occured on posting, then a residual G/L entry will be inserted. This would result in a corrected ACY balance and the posting will pass the consistency check.

3. The ACY calculation always occurs at the posting date, which is not always consistent with what you would expect. Mostly it should be the posting date, but in some cases it must be the posting date of the applying entry.

The combination of these leads to the observed error: Sometimes (but always with non-ACY postings, and ACY enabled) you will get consistency errors.

Easy (but not necessarily perfect) fix: At the end of the posting, initialize an empty G/L Entry (no amounts) and call HandleAddCurrResidualGLEntry(). Your ACY amounts will be wrong on some occasions, but it will post

Not so easy fix: You wold need at least to fix the CalcLCYToAddCurr() problem. I would recommend to add a new function CalcLCYToAddCurrRefDate() where you give the desired date for the calculation. You need to use this function in all PostDtld* and AutoEntrFor* functions. I went a few steps further and made the whole applying function ACY-aware. This is needed when you have Open Item G/L Entries with currency.

with best regards, HTH

Jens

MGM08

Hi,

Was any hotfix released for the issue of the additional currency as we are having the inconsistancy issue.

Thanks.

jglathe

MGM08 wrote:

Hi,

Was any hotfix released for the issue of the additional currency as we are having the inconsistancy issue.

Thanks.

Hi,

the nearest one would be KB 2479035, as it seems. But caution: the hotfix forces the code to calculate the ACY amounts more often, even if there is a valid ACY value (because Currency Code = GLSetup.ACY Code). So, the posting might go through, but it doesn't mean it's entirely accurate on the ACY side. The result would be that the unapply() would sometimes leave a residual ACY value on the Gains/Loss accounts, for example.

with best regards

Jens