The G/L Entry already exists error.

jversusj · 2009-08-05

hello all. i searched the forum for this error and while i found a lot of similar errors, nothing directly relating to this, nor how to resolve.

I have a single Purchase Order that will not Post Invoice. The receipt was already posted, and now A/P is trying to invoice the receipt.

When you attempt to invoice (or receive and invoice), you get an error:

Microsoft Dynamics NAV
The G/L Entry already exists.Identification fields and values:Entry No.='XXXXXXXX'
OK

If you attempt to post again, you get the same error, alhtough the entry no. changes. We have a lot of mods in our system, but nothing was recently changed in the posting objects and this only seems to be impacting this one purchase order. any ideas on where i can start looking?

I ran with debugger active (no breakpoints) and found that it is stopping in Codeunit 12 Gen. Jnl.-Post Line\FinishCodeunit() at this point:

FinishCodeunit()
WITH GenJnlLine DO BEGIN
  IF GLEntryTmp.FIND('-') THEN BEGIN
    REPEAT
      GLEntry := GLEntryTmp;
      IF GLSetup."Additional Reporting Currency" = '' THEN
        GLEntry."Additional-Currency Amount" := 0;
      GLEntry.INSERT;

Initially, i was able to find an existing G/L Entry (so it really was attempting to use an entry no. that existed), but the last few times i tried to post it, it has been throwing entry nos. that do not yet exist (say, several nos. higher than the highest G/L Entry no.).

as i mentioned - no recent changes and so far only this PO is impacted. the last thing i can think to do is watch the entire posting through debugger - which users will not like as i lock them out.

we are on NAV 3.7b with 5.0 clients sitting on a SQL db. Thanks in advance for any suggestions on where to look.

jversusj · 2009-08-05

more info -
i found why the no. seems to exceed the highest G/L entry no., in the process discovering which
PO line is the culprit.

The PO has 4 lines, and the 3rd line is the one causing the fault. the first two lines appear to create 3 g/l entry (NextEntryNo is called 3 times before the error anyhow).

i guess i have a place to start looking now.. InitCodeUnit from CU 12...

David_Singleton · 2009-08-05

I have seen this before. Some time ago, it was due to two lines that were identical and the way that the posting buffer merged them, (not sure if it was purchase or sales, but I think sales). It related some where to a modification, the client was using eShip and Warehouse management, and it was a mod to one of them that did it. Basically a filter or something was not doing what it should have.

Sorry it was a number of years ago and if I remember correctly we couldn't fix it, and in the end just inserted a new line for 1 penny in between the two lines, and had to play around (in a test db) with posting different lines in different sequences till it posted. Then a lot of adjustments to make it work.

Basically try posting one line at a time (set qty to invoice to zero on all but one line) and get it out of the system and move on.

ara3n · 2009-08-05

this usually is related to mod.
The mod uses a different variable for CU 12 instead of using the same variable in CU 80 or 90.
This causes an entry to posted inbetween the entries and Std variable is not aware since it keep the EntryNo as variable.

I suggest to look and see if there is any mode that post to GL using CU 12 that is a new variable.

jversusj · 2009-08-05

we do have eShip.

the first line is an item line. the second line is a resource line. the third line is an item. it seems like it never gets a nextentry no between the second and third line. i learned what i have so far by stepping through debugger and getting lambasted by the users for locking everyone out. i guess i'll see if i can recreate this in my development environment.

thanks for the input! i will take your suggestion (posting 1 line at a time) as a last resort if i cannot find the culprit.

jversusj · 2009-08-05

i will add that the resource line has a job assigned to it.

i dummied up the PO in my development system (minus the job no) and was able to post it, so i wonder if the job impacts it somehow?

test that next...

David_Singleton · 2009-08-05

If I remember correctly 3.70 did not allow posting job lines on purchase orders, so it would seem you have mods made in that area, so that looks like the right place to check.

I think though just post the resource line on its own delete the line then post the rest of the order.

jversusj · 2009-08-05

thanks - like i said, lots of mods in our system... :shock:

i just stepped through a recreated error scenario.
for the first line, the system loops through the inventory posting buffer twice, creating two GL Entries. It then leaves this loop. CU 90 then calls CU 202 which calls report 1214 and the Post Job WIP Value to G/L code is fired. i saw it generate another 2 G/L entries (incrementing properly). code then started posting for 3rd line and when it returned to CU 12, i saw that the NextEntryNo was the value last incremented during the posting of the first item - the resource line must call a different instance of the CU 12 and incremented "outside" of the transaction in a sense.

i know accounting would prefer to post the invoice as received from the vendor, so i am going to dig deeper and try to find how it can be corrected.

thanks again!

The G/L Entry already exists error.

Comments

Categories