How to debug a consistent error?

AlishaAlisha Member Posts: 217

I get a consistent error when trying to register an invoice, but if I comment the code where the Consistent function is called, the invoice is registered and the amounts are correct in G/L Entry.

How can I find what's wrong?


  • Options
    ara3nara3n Member Posts: 9,256
    in CU 12 there is a function called

    after the following line



    Message(GLEntry."G/L Account No." + format(GLEntry.Amount));

    Post the order and write down the message and see what is missing.
    Ahmed Rashed Amini
    Independent Consultant/Developer

    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    girish.joshigirish.joshi Member Posts: 407
    Rashed's advice is good. But you might also want to check out these posts

    Containing general advice on how to debug this sort of error (more or less what Rashed said)


    refering to a common consistency error when posting Invoices regarding sales tax (you should probably check to see if this is your problem)
  • Options
    AlishaAlisha Member Posts: 217
    Thanks for your suggestion, but the problem remains.. the problem is not that the amounts are not correct, or not balanced. They are, because if I comment the part where the consistent function is called in codeunit 12, I can post the invoice, navigate and see the g/l entries, and all the amounts are balanced.

    I've tried to put the message on the FinishCodeunit, but I see the amounts being posted until the consistent error appears.. nothing else. Everything seems correct.

    I have another DB (4.00 without SP1), with the same code on codeunits 12 and 80, and everything works fine. If I put the message on FinishCodeunit on this DB, I see exactly the same messages that on SP1 DB, but the invoice is correctly posted.

    I don't know what to do with this...
  • Options
    girish.joshigirish.joshi Member Posts: 407

    It might be true that cu80 and cu12's code is the same for both databases, but I can guarantee you this: If its posting in one, but not posting in the other, the code that it is running is NOT the same. One option would be running code coverage while posting on both systems. You could see where the code differs, and that would help isolate your problem.

    I would double check the what's getting posted, and make absolutely sure it balances. make sure there are no rounding errors.
  • Options
    I had similar problems: Amounts were correct, but I had inconsistency errors.

    I discovered this was due to the fact that Navision would check for consistency when a codeunit 12 is finished , more exactly when its GL Entry record is out of scope (garbage collected, cleared... not sure how to call it).

    For example:

    I coded into cu 80 a routine that called my custom codeunit were some postings were done with cu 12. In my custom codeunit there was a local variable cu 12 which did the postings. When my custom codeunit was done it cleared this local cu12 and reported inconsistency error although there was no COMMIT yet at this time.

    So this is a matter of variable scope.

    There were to solutions to my problem:

    1. I could move my custom code into cu 80 and use its cu12 variable. I didn't like that cause I tend to keep standard code clean as possible and do everything with escape points to my custom code.

    2. Add a reference parameter to my function which passed the cu80's instance of cu12 to my custom codeunit. My custom codeunit was in effect using the same instance of cu12 as Sales Post.

    both solutions solved the inconsistency problem for me.

    To summarize, I gather that consistency is not checked upon commit, but rather when the corresponding table is out of scope.

    I hope this makes at least some sense. :)
  • Options
    girish.joshigirish.joshi Member Posts: 407
    Look carefully at codeunit 12. Its is checked when the transaction that first called cu12 finishes. In the meantime, records that are inserted are put into an array and its this array that is ultimately checked for consistency.
  • Options
    Alex_ChowAlex_Chow Member Posts: 5,063
    The amounts on the G/L Entry might be correct, but have you checked the other ledgers affected? One main culprit is the VAT Entry, check to see if everything in there is balanced.
Sign In or Register to comment.