Error msg "You cannot reverse Cust. Ledger Entry..."

BGR

I try to reverse Customer ledger entries and get an error message "You cannot reverse Cust. Ledger Entry No. 871 because the entry has an associated Realized Gain/Loss entry". How to solve this issue? Is there any way to reverse the payment if it is in foreign currency?

jglathe

Hi,

yes this is a bug. Microsoft has documented this with a hotfix: KB2525776. The objects to change are R595, CU226 and CU227. Just yesterday I applied this fix to a customer database.

with best regards

Jens

jglathe

Hi BGR,

I see you're probably on NAV2013, this got me thinking again... this KB is fixed in NAV2013. Regarding reversals, however... yes that's an issue. But resolvable, IMO. A dig in CU12 in our OpenItems AddOn shows this:

Function Reverse()
...
        //OS014s os.jgl
        //reverse the detailed G/L entries
        DtldGLEntry2.SETCURRENTKEY("G/L Entry No.");
        DtldGLEntry2.SETRANGE("G/L Entry No.",GLEntry2."Entry No.");
        DtldGLEntry2.SETRANGE(Unapplied,FALSE);
        DtldGLEntry2.FINDSET;
        //This might look inconsequential... a loop where only one initial entry should exist. This code is
        //as inconsequential as the standard code for the customer and vendor entries. However, it is "prepared" for the
        //event that the adjustments on the entry don't block a reversal.
        REPEAT
          DtldGLEntry2.TESTFIELD("Entry Type",DtldGLEntry."Entry Type"::"Initial Entry");
...

And this is true. The adjustments on a customer or vendor entry have several sources:

1. Realized gains/losses, discounts, rounding due to application. These entries have the transaction no. of the application. Also, reversal of unrealized gains/losses can occur, when the entry has been subject to the "Adjust Exchange Rates" batch.

2. "Adjust Exchange Rates" generates unrealized gains/losses. These have a separate transaction no. and document no. from the adjusted entry, and usually a different date (valuation date).

The unapply function also posts reversals to all adjustments affected by the application, and marks the new detailed entries as unapplied. That's good.

For a reversal the following conditions must be met:

1. The entry must be completely open.
2. It must not be adjusted ba "Adjust Exchange Rates".

The second condition is due to the "inconsequential" code in the Reverse() function: the unrealized adjustments usually have a different posting date than the initial entry or the application(s). To reverse these as well (which must be done, since you're reversing the initial entry) you would need to handle the generation of corresponding G/L entries to reflect the reversal correctly in the G/L. For all the unapplied entries the resulting balances by date (and account) already amount to zero from the unapplication. So you can cut a corner and ignore them completely - no use in generating a set of reversing entries for a set of entries that amount to zero by account and by date. But not for the adjustments generated by "Adjust Exchange Rates". The easy way out is to prohibit this case from being reversed.

So, this should be checked before the Reverse() function in CU12 gets called. But there is a bug.

In T179 Reversal entry, there are functions to check these conditions:

CheckDtldCustLedgEntry(CustLedgEntry : Record "Cust. Ledger Entry") : Boolean
DtldCustLedgEntry.SETCURRENTKEY("Cust. Ledger Entry No.","Entry Type");
DtldCustLedgEntry.SETRANGE("Cust. Ledger Entry No.",CustLedgEntry."Entry No.");
DtldCustLedgEntry.SETFILTER("Entry Type",'<>%1',DtldCustLedgEntry."Entry Type"::"Initial Entry");
DtldCustLedgEntry.SETRANGE(Unapplied,FALSE);
IF NOT DtldCustLedgEntry.ISEMPTY THEN
  ERROR(ReversalErrorForChangedEntry(CustLedgEntry.TABLECAPTION,CustLedgEntry."Entry No."));

DtldCustLedgEntry.SETRANGE(Unapplied);
DtldCustLedgEntry.SETFILTER("Entry Type",'%1|%2',
  DtldCustLedgEntry."Entry Type"::"Realized Gain",DtldCustLedgEntry."Entry Type"::"Realized Loss");
IF NOT DtldCustLedgEntry.ISEMPTY THEN
  ERROR(Text013,CustLedgEntry.TABLECAPTION,CustLedgEntry."Entry No.");

The second part generates your error. It will "always" generate an error for a correctly unapplied entry in a foreign currency. The first check already covers the "Adjust Exchange Rates" case. Removing the second check leads to an IMO correct check as explained above, and allows the reversal of a completely unapplied payment in foreign currency. This would be my proposal to fix it:

CheckDtldCustLedgEntry(CustLedgEntry : Record "Cust. Ledger Entry") : Boolean
DtldCustLedgEntry.SETCURRENTKEY("Cust. Ledger Entry No.","Entry Type");
DtldCustLedgEntry.SETRANGE("Cust. Ledger Entry No.",CustLedgEntry."Entry No.");
DtldCustLedgEntry.SETFILTER("Entry Type",'<>%1',DtldCustLedgEntry."Entry Type"::"Initial Entry");
DtldCustLedgEntry.SETRANGE(Unapplied,FALSE);
IF NOT DtldCustLedgEntry.ISEMPTY THEN
  ERROR(ReversalErrorForChangedEntry(CustLedgEntry.TABLECAPTION,CustLedgEntry."Entry No."));
//second check is removed completely.

The same should be done for the vendor side. This should solve your issue, or at least lead you to the next error message There are many conditions that can lead to a failure on a reversal posting. Be careful when testing this out, I would recommend to do it in a copy of the live database.

with best regards

Jens

krola

Hi Jens,
It has been a while since your post. I am struggling in NAV2018 with an issue described by you in previous post.
I have posted customer payment (together with an application). Then I've un-applied enties and trying to reverse transaction. I am getting know error: "You cannot reverse Cust. Ledager Entry No. because the entry has an associated Realized Gain/Loss entry."

I would like to ask you whether have you reported issue to MS? Did you get any feedback?

Best regards,
Katarzyna Rola

vremeni4

I got the same error message in NAV 2018 CU8

This seems to be triggered when Journal is used to processes invoices.

Jens is right, but I still think it is too much to remove the whole check.
I changed the code like this and so far it seems to be fine
DtldCustLedgEntry.RESET;
DtldCustLedgEntry.SETCURRENTKEY("Transaction No.","Customer No.","Entry Type");
//DtldCustLedgEntry.SETRANGE("Transaction No.",CustLedgEntry."Transaction No.");
DtldCustLedgEntry.SETRANGE("Customer No.",CustLedgEntry."Customer No.");
DtldCustLedgEntry.SETFILTER("Entry Type",'%1|%2',
DtldCustLedgEntry."Entry Type"::"Realized Gain",DtldCustLedgEntry."Entry Type"::"Realized Loss");
//Fix B
// orginal code IF NOT DtldCustLedgEntry.ISEMPTY THEN
// orginal code ERROR(Text013,CustLedgEntry.TABLECAPTION,CustLedgEntry."Entry No.");
DtldCustLedgEntry.SETRANGE("Document No.", CustLedgEntry."Document No.");
IF NOT DtldCustLedgEntry.ISEMPTY THEN BEGIN
DtldCustLedgEntry.CALCSUMS(Amount,"Amount (LCY)");
IF (DtldCustLedgEntry.Amount <> 0) OR (DtldCustLedgEntry."Amount (LCY)" <> 0) THEN
ERROR(Text013,CustLedgEntry.TABLECAPTION,CustLedgEntry."Entry No.");
END;
//Fix E

rocopsa

I got the same problem today and viewed this post.

vremeni4's codes works perfect, but, my client has a strange habit to input another transactions with same voucher no. for other purposes. So, I cannot use "Document No." as the filter. Instead, I am thinking to use "Cust. Ledger Entry No.", but I am afraid of any potential problem. Any comments?

=====================

DtldCustLedgEntry.RESET;
DtldCustLedgEntry.SETCURRENTKEY("Transaction No.","Customer No.","Entry Type");
//***1:>>>
//Void original:  DtldCustLedgEntry.SETRANGE("Transaction No.",CustLedgEntry."Transaction No.");
DtldCustLedgEntry.SETRANGE("Cust. Ledger Entry No.",CustLedgEntry."Entry No.");
//***1:<<<
DtldCustLedgEntry.SETRANGE("Customer No.",CustLedgEntry."Customer No.");
DtldCustLedgEntry.SETFILTER("Entry Type",'%1|%2',
  DtldCustLedgEntry."Entry Type"::"Realized Gain",DtldCustLedgEntry."Entry Type"::"Realized Loss");
IF NOT DtldCustLedgEntry.ISEMPTY THEN
//***1:>>>
BEGIN
  DtldCustLedgEntry.CALCSUMS(Amount,"Amount (LCY)");
  IF (DtldCustLedgEntry.Amount <> 0) OR (DtldCustLedgEntry."Amount (LCY)"<>0) THEN
//***1:<<<
  ERROR(Text013,CustLedgEntry.TABLECAPTION,CustLedgEntry."Entry No.");
END;  //***1

=====================

jglathe

Hi there,

having faced the same issue (but in its "clean" incarnation, open entry that is exchange rate adjusted) in NAV2018 CU32 now, I stand by my original assessment. The additional check for "realized gains/losses on the entry equal zero" is overly cautios IMO, this should be the case for a fully unapplied entry (the only case where the first check passes with realized gains/losses present). However, a better error message would be nice. we changed our Text000 to "You cannot reverse %1 No. %2 because the item has been either cleared or currency settled.\When the entry is fully open, you can only create a reversal manually including application."
This should take the user in the right direction to resolve this.

with best regards

Jens