Inconsistencies in the G/L Entry table

VisVis Member Posts: 19
The transaction cannot be completed because it will cause inconsistencies in the G/L Entry table. Check where and how the CONSISTENT function is used in the transaction to find the reason for the error.
NAV 2016, Additional Reporting Currency active.



  • Options
    vremeni4vremeni4 Member Posts: 323
    I assume you heard of double booking keeping.
    This means if I debit £120 from account A then I have credit another account B for -£120.
    So that the total is 0.
    If this is not consistent on GL then you will get this error message.
    It means you changed posting routines and that what you are trying to post on the GL entry table does follow the rule above.
    The some of amounts for this transaction is not 0.
    THere is function called CONSISTENT that you can find in the codeunit 12 that does this check.
    If you remove it the error message will go away BUT you accounting data will be all wrong and with the time it will become unusable.
    So better do not remove but check your changes, Debug the General Journal to see if the total for a transactions re 0.

    I hope this helps

  • Options
    VisVis Member Posts: 19
    Thank you but the posting routine is not changed.
  • Options
    vremeni4vremeni4 Member Posts: 323
    Well if the posting routine was not changed, then there might be a bug in some previous customisation.
    Was the database customised at all ?

    In most cases this happens when you have rounding error, e.g. Currency exchange rates.
    In some situations if you change the numbers slightly the rounding issue will disappear and it will post.
    for example you can change the Amount from 13.33 to 13.4 this will not create rounding error during posting so it will post.

    Anyhow to resolve this issue you need to ask a developer to take a look at it and identify what is causing the difference.

    I hope this helps.
  • Options
    ricardopaivaricardopaiva Member Posts: 14
    Hi Vis!

    Consistent errors can be tricky... :)

    You didn't mention if you are posting an sales order/invoice... a Gen. Journal... please let me know!

    What I recommend is:

    Codeunit 12. Look for this line and add a breakpoint:

    This is where Nav inserts the GL entries before checking them for consistent.
    Turn the debugger on, do the posting and check how many lines are being added. Each time Nav stops in this debugger, is a new line being added to the GL Entry.
    Check the amounts to make sure that the sum of them equals 0!

    If not, check if the sum gives you something like 0,01. If so, then it seems to be a rounding problem. If is higher, then it seems there's a missing entry!

    After doing this and knowing if it is a rounding problem or not, what i would recommend is to do exactly the same posting, in a Cronus database and debug it and see how many lines are being posted and with which amounts.

    If there's any difference, make sure that difference is not related with different setups in both databases. If not, then you'll figure out which line being posted is wrong and you'll have to debug it and check how the amount is being calculated and why it is being miscalculated.

    This could be the trickiest part but since you can compare debug and compare the values in your database and in the Cronus database, it shouldn't be difficult to spot the differences.

    I believe you're not running the last Cumulative Update so you're probably missing a hotfix.

    Please let me know if I can help you further.

  • Options
    VisVis Member Posts: 19
    We disabled additional reporting currency in test environment and the posting went ok. Of course this is not a solution, only part of the diagnostic process :)
  • Options
    KishormKishorm Member Posts: 921
    With a few small changes you can get a list of the transactions that would have been posted that caused the consistency error, have a look at this post...

Sign In or Register to comment.