mibuso.com

Dear all,

Iam getting a inconsistency error while posting the Sales invoice. while am searching for inconsistence error in mibuso , i was able to find the post done by Mr. ara3n "How to see why you are getting CONSISTENCY Error?". But there he has mentioned it for capturing inconsistence error in Code unit (12). Butg am getting eror in Sales Post codeunit.

Can i affix the same solution that he has given with Single instance codeunit and Finishcodeunit function in the Codeunit("Sales -Post"-80).

Please suggests.

Mohana Can u please Suggest in my Problem?

"inconsistency error while posting Sales invoice "

So have you done any modification in CU80 by adding CONSISTENT function?

I never tried..but it should work..

Till now i had not done any changes in codeunit 80. It is defualt.

Search with CONSISTENT word in CU 80..
How do you know that error is from CU80?

while posting invoice it inconsistence error hits in Codeunit 80. i found it out by activating debugger. Just now i spoke to my senoir His soultion is seems to be vague , he simply asked me to cancel that invoice.He wants me to create a new invoice and post it .. There is no other way to solve this. I just want to understand what is trhe actual problem.

Can show us the code where the debugger has stopped..

InsertValueEntryRelation;

IF NOT InvtPickPutaway THEN
COMMIT;
CLEAR(WhsePostRcpt);
CLEAR(WhsePostShpt);
CLEAR(GenJnlPostLine);
CLEAR(ResJnlPostLine);
CLEAR(JobPostLine);
CLEAR(ItemJnlPostLine);
CLEAR(WhseJnlPostLine);
CLEAR(InvtAdjmt);
Window.CLOSE;

Find the code for " InsertValueEntryRelation;", u will find it in CU80. am getting error at the time of "COMMIT"

Does the sales invoice in question have a line with a negative quantity? Some folks will go to extreme lengths to avoid issuing a credit memo. I ran into some consistency error issues a while back (NAV 3.7). This "user improvisation" - in combination with regular lines and sales tax calculation rounding - set up a situation where the system came up with tax amounts that were out of balance by a penny.

I used the code that ara3n provided. It pops up a window showing the contents of the journal line it is trying to post. This data is normally lost once the error is encountered. It allowed me to quickly see that problem was the imporvised credit memo replacement. The fix your In those cases, the sales documents were Sales Orders (not invoices) that were being invoiced, so they had already been received. The end result (customizations made things less than straightforward) was to make a new invoice without the negative sales quantities and then remove the bad invoice.

When you post a sales invoice, it is going to hit the G/L and that means it is going to be calling CU 12. - Did you try running ara3n's code as suggested in his post?

When we see that error it's usually due to a rounding problem.

Say the Cost goes out 4 digits and then the line also has a line discount % of something.

By rounding the offending number up it usually solves the problem

ex. Cost = 3.4568

we'll keep rounding untill it works
3.457
3.46

The error is still coming from CU 12 and not 80. That is how CONSISTENT function works. At the time of Commit it checks whether the G/L Entries created is equal to zero (debit = credit).
Follow the method of single instance CU or you can also have a simple message displaying the G/L Account and Amount field in function "InitGLEntry" in CU 12, note the accounts and then assess which entry is the culprit.

Meanwhile can you mention which version and localization you are using? In Indian version the consistency problem was more or less removed with NAV 4.0 SP3 HF6.

Be sure, that you check all Knowledge articles regarding this. May be there is already solution...

Yes it will work in your case. This is one of the best down loads on this site, personally it has saved me hours upon hours of debugging time.

Just install it exactly as Rashed explains in CU12 and it will capture the error in sales posting. In fact most of the times I have used it was to find sales tax and vat rounding errors in sales posting. (all errors in standard Navision )

You could probably have resolved this by putting a zero value sales line between the positive and negative lines, eg. to a GL rounding account qty 1 amount 0. This is because of the way that Navision carries rounding from line to line progressively through the sales lines till the last line to minimize the total round amount.