In Dynamics NAV when you post any transaction to general Ledger, NAV checks and make sure that debits are equal to credits and the total transaction amount is equal to Zero. It has been a while since I have seen the error in NAV, and it’s thanks to Microsoft building automating testing tools and testing their code. I had written a tool on mibuso to help identifying the gl transaction being posted.
In a recent project working with LS Retail, I ran into the issue when posting Statements. LS Retail has solved the issue a different way. What LS Retail has done during posting, that it keeps tracking on the running total and at the end if it does not match zero, it tries to post the entry into rounding GL Account.
The user doesn’t get CONSISTENCY error and the statement gets posted but you still have the unnecessary GL entries and then have to manually move the entries to whatever account it should it.
It’s not a great solution. It’s basically the same thing as moving the dirt under the rug.
While trying to identify the issue, I had to use the Consistency code again to identify the issue.
I have updated the tool using Events in NAV 2016. This way the solution does not modify any objects and can reside in NAV.
Here is the solution.
OBJECT Codeunit 50099 Single Instance CU
Time=[ 5:18:47 PM];
IF NOT StoreToTemp THEN BEGIN
StoreToTemp := TRUE;
TempGLEntry@1000000000 : TEMPORARY Record 17;
StoreToTemp@1000000001 : Boolean;
PROCEDURE InsertGL@1000000000(VAR GLEntry@1000000000 : Record 17);
IF StoreToTemp THEN BEGIN
TempGLEntry := GLEntry;
IF NOT TempGLEntry.INSERT THEN BEGIN
As far as how to use this Code. Run the object first from development environment. Run the process that causes the consistency. after you get the error. Click ok, then run the object from development environment again and you will see the list of gl entries.