Inconsistency Problem In G/L Entry

tony123 · 2005-08-20

HI all,
Can anyone help me to solve inconsistency problem in G/L entry table? When i tried to post an invoice in PO, got error message ' transaction cannot be completed coz it ll cause inconsistencies in G/L entry table'. After that i tested database with Maximum, got same error. Then i made backup of that db n then restored in a new db.But after that still it shows inconsistency problem. i can post other invoice .How can avoid these situations in future.
thanks in advance tony

bbrown · 2005-08-20

This error means that the posting to G/L is out of balance (Debits <> Credits). Have you modified anything?

Turn on the debugger and watch the value being passed to these messages.

Marije_Brummel · 2005-08-20

Go to your g/l entry table and see if the debit amounts are the same as the credit amounts.

At first you need to make sure that at every posting date there is a balance. You can ask your Solution Centre to write a report which will write the difference to a special g/l account.

The you need to make sure this never happens again. It is either coused by customised code or by changing the g/l entries manualy with a developer license.

At last your accountant will need to have a look at the postings if everything is ok.

Greetz,

Mark Brummel

bbrown · 2005-08-20

This is not an issue with the existing entries in the G/L Entry table. It is an issue with the entries that are being posted to the table. The attempted posting is out of balance.

Does this occur for all posting attempts (any form), or is it only one type, or is it just one particular document.

Marije_Brummel · 2005-08-20

tony123 wrote:

After that i tested database with Maximum, got same error.

So my guess is the probles already is in the database.

Mark.

bbrown · 2005-08-20

During a posting to the G/L. Codeunit 12 calculates the total debits and credits that are being posted. If they do not balance an error is displayed (the one you are seeing) and the transaction is aborted.

You should set some breakpoints in codeunit 12 and walk your posting through with the debugger.

Marije_Brummel · 2005-08-20

Story:

I once had a look at a piece of code. There was this guy who, in Codeunit 80 dit, after the commit, did a manual insert to the g/l entries, without codeunit 12.

The code was structured in such a way with an if/then/else statement that if one of the posting groups was not propperly setup the g/l entry table would be inconsistent.

This is not checked by Navision.

After I saw this, my guess is: Everything can happen.

Regards,

Mark

bbrown · 2005-08-20

This error is being generated by code in codeunit 12 (Function FinishCodeunit). But the cause is probably not in codeunit 12. Look into where the General Journal Lines are being passed to codeunit 12. They must total to zero or this is the error you will get.

If any mods have been done to posting groups, or mods that create additional posted entries, you may want to look here.

tony123 · 2005-08-22

Hi,
i havent seen any entry for tat PO. Then how can I check g/l entry is balaced or not? This error came only for that particular PO.
thanks in advance tony

bbrown · 2005-08-22

You need to use the debugger. The G/L Entry records that are causing the error are not being committed to the database. They are part of the current transaction which is rolled back on the error.

Savatage · 2005-08-22

http://www.mibuso.com/forum/viewtopic.p ... onsistency

chaitali_bhattacharya · 2005-09-26

If you havent yet found the solution I would request you to give some more specifications regarding the entry that you are making.
Which is the hotfix that you are using and whether you are using the Cronus India Company etc.

You can try this.
In codeunit 12 there is a call to a function GLConsistent.Comment this call and then post the entry. this will forcefully post the entry. Credits and debits wont match. You can then anlayse where the entry is going wrong.

This is mostly a because of a bug. If you can give me the above required inputs I can try helping you.

DenSter · 2005-09-26

You know it is because of commenting out those functions that your G/L ends up corrupted. I once had a consultant comment out the CheckPositive function so a customer could post negative amounts, and that completely screwed up their ledgers.

Tony... pPlease don't comment out anything like that, that will cause more problems than it will solve. If anything, it will ADD inconsistent data to your database.

Marije_Brummel · 2005-09-26

Yes, you can realy screw up your database if you want. I once saw code which created some G/L entries directy without going throug the journal lines and posting codeunits. OUCH

awarn · 2005-09-26

Heres two ideas:

Backup / restore the database, then comment out the code and post and analyse.

In the codeunit, before it inserts to the GL Entry table, put a messagebox showing the amount. Then before the error you will be able to see the values - and figure out which one is off. Often a rounding / currency issue is the cause of an inconsistancy.

-a

chaitali_bhattacharya · 2005-09-27

My suggestion was to comment the code.It is understood that one should not do it in live database. This can be tried in a dummy database, the code commented temporarily and posted. Obviously the databasecan not be used thereafter.
Following the above process shows the exact incorrect reflection in the GL entries. There were certain localization related bugs which has resulted in the error that I had once faced and had been able to correct the error following this process. Infact once the entries get posted in th GL entry forcefully, one can see in which ledger this value is incorrect.Therefore debugging the problem will be easier.

I had specifically requested to give details of the database and the steps being followed that is being used.

bbrown · 2005-09-28

Set a breakpoint in the function 'finishcodeunit' of codeunit 12.

Turn on the debugger and loop thru the breakpoint F5.

Write down the G/L accounts and amounts.

From this information, you should be able to trace back to the posting groups and isolate the issue.

leewhite1234 · 2006-12-14

This error message is generally caused by the tax calculation. Press F9 and change the sales tax amount by manually rounding it; i.e., if the tax is 32.75347, change it to 32.75.

I spent an incredible amount of time on this error until I found that the solution was just a rounding issue.

Hope this helps.

mukesve · 2006-12-14

I would like to support Chaitali

. I believe Tony is using Indianised Version and Indian taxation is really complax. There were many bugs in the system. If you will try to analyse it using debugger then it will take hours.

I suggest Tony to take a copy of the database, comment the Consistant function and let the entry posted. Now you can see the inconsistancy in the ledger entries. you can analyze the g/l account to which the wrong entry is being posted and then it becomes easy to find out the section of code where you have to focus to find out the bug. Now umcomment the Consistant function and use the debugger to find the exact line of code that is creating problem.

I have encountered the problem in Indian database and used the same method for finding out the problem and found it easier than any other method. I really do not see any problem in commenting the code on TEST SERVER.

Mukesh Verma

Navision Certified Solution Developer 3.70
Navision Certified Solution Developer 4.00
Since 2003

themave · 2006-12-14

leewhite1234 wrote:

This error message is generally caused by the tax calculation. Press F9 and change the sales tax amount by manually rounding it; i.e., if the tax is 32.75347, change it to 32.75.

I spent an incredible amount of time on this error until I found that the solution was just a rounding issue.

Hope this helps.

This is a known issue on the sale and receivable side. the tax calculates out to multiple digits but the g/l posting doesn't. so the enter would be off if allowed to post. we get this all the time on sales credit memos. the solution is as stated Press F9 and on the invoice tab, manually change the tax to two digits.

vishesh · 2006-12-15

Hi all,

I have gone through the whole topic and I guess if you want to solve the problem temporarily then you can make changes to the amounts calculated, but the best way is to implement the hotfix.
Sorry that I dont know which is the hotfix for this problem, but someone can help there in the fourm to know the hotfix no.

Thanks and Regards.
Vishesh Singh
Technical Consultant

ssingla · 2006-12-15

Dear Friend,

A common problem with Indian Database. Actually the Indian version conatins a codeunit "Indian Sales Tax Calculate' which compares the value of desired tax amount and the actual tax amount. If the amount is not equal then it throws the G/L inconsistency error. Well the logic is that unlike the standard database it calculates it value to 2 decimal whcih cause the problem. the issue has been reported to microsoft india and there is no resolution to it till today. What you can do is modify the Indian tax Calculate codeunit where desired tax is compared with Actual tax by 0.001 to 0.1. This is a workaround and has been used by me a lot of times with sucess.

themave · 2006-12-15

vishesh wrote:

Hi all,

I have gone through the whole topic and I guess if you want to solve the problem temporarily then you can make changes to the amounts calculated, but the best way is to implement the hotfix.
Sorry that I dont know which is the hotfix for this problem, but someone can help there in the fourm to know the hotfix no.

Thanks and Regards.
Vishesh Singh
Technical Consultant

There is not a hotfix for it, Microsofts solution for use was to use the F9, go the invoice tab on the statistics and manualy change it. I would not call that a hotfix, more like a pain in the axx fix

Savatage · 2006-12-15

Sounds like the solution has been the same for 3 years
http://www.mibuso.com/forum/viewtopic.php?t=2024

Inconsistency Problem In G/L Entry

Comments

Categories