[:(] “This transaction cannot be completed because it will cause an inconsistancies 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. Contact your ssytem manager if you need assistance. Parts of teh program mark tables and inconsistent…etc.” Above is the error a lot of our customers are getting while attempting to post Purchaes Orders: Invoicing and/or Receiving. Sometimes we can get around it by either populating or deleting the “Sales Tax” related fields. Other times we cannot get around the problem and are required to enter a whole new PO. Circumstances surrounding the error vary so no one circumstance is EXACTLY like the other. We can enter the Order details the same exact way we always have then poof… the error pops up. Even though the order prior to this one was exactly the same… same items, everything. Navision will not help unless I give a “specific” example. Anyone else encounter this error? Any suggestions?
Topic moved from “Open Business Subject” to “Navision Development” forum.
Desiree: Just a thought but have you checked the UOM, costing, or currency conversion for the purchase order items? Best Rgds, Owen
hi This error can arise due to various reasons. This is due to the fact that while posting if the total debit amount and the total credit amount of the transcation is not same then the posting cannot be completed. One of the common reason for this is the improper use of rounding precision. If it is not used correctly the amount varies by a very minute amount like .001 or so. Since u have said that in ur case it is rectified by populating or deleting the sales tax field, so plz check the code written on the validate of sales Tax field and check the rounding of the amount. I guess this will solve your problem.[:D] Hari
Contact Navision support. I got a ‘fix’ for codeunit 80 and 90. It mostly worked. It will handle one tax jurisdiction just fine without expensed taxes. Basically the tax is being calculated on a line-by-line basis. One part of the posting routine is rounding each line’s tax amount and another part of the routine is rounding the total of each line’s tax amount. This can result in a 1 cent difference and suddenly you can’t post the document. Django
Originally posted by dez17 Above is the error a lot of our customers are getting while attempting to post Purchaes Orders: Invoicing and/or Receiving. Sometimes we can get around it by either populating or deleting the “Sales Tax” related fields. Other times we cannot get around the problem and are required to enter a whole new PO. Circumstances surrounding the error vary so no one circumstance is EXACTLY like the other. We can enter the Order details the same exact way we always have then poof… the error pops up. Even though the order prior to this one was exactly the same… same items, everything. Navision will not help unless I give a “specific” example. Anyone else encounter this error? Any suggestions?
My first question is what version are you on? Next, to try to get around the issue without having to reenter a whole purchase order, try turning off the taxes on the line and having the person enter the amount for the taxes on a separate line of type Account (G/L). This usually gets around it. Hari is quite correct about the use of rounding, but it isn’t the whole problem. Django’s resolution to find a fix is half right. Depending on what version is being run, a fix does exist. However, the error shouldn’t occur in any databases v3.10 or later, I thought.
My first question is what version are you on?
Our clients are on 3.10B with improvements up to 8 installed. I haven’t tested with 3.60 yet - where I’m told this has been fixed. We are dealing with this issue in Sales & Receivables as I write this so adding GL lines won’t help here. [:(] We’re waiting to see if Navision has a response (other than upgrade to 3.60) to see who will be fixing this issue (me or Navision). Django
It is still there in 3.6.
The error is due to how Navision 3.10 and 3.60 (not 3.01) allows manual Tax and/or VAT rounding. With VAT it seems to work fine, but not with US tax. You should be able to identify the issue by analyzing an order that won’t post. Look at the tax amount on the last line, and do the math for the whole order, you will find that the totals do not balance, and will be out by one penny. I have found two work arounds that generally help. 1/ Create the last line as type Account, you don’t need a number, just the type. In many cases it will now post. The reason is that Navision tries to round the last line on an order, and if it is a comment it is filtered from one of the calculations that performs the check. … arrrggghhhhh… (guess how long it took me to find that one). 2/ If the last item line has tax, and you have multiple tax rates on the order, try to change the amounts on the last two lines, up down by one penny, untill you get the sam totals in the Header Amount flow field, and the Total on the Stats form. Of course this does not look good on the final invoice. This fixes most of the errors. Also applying service packs to 3.10 helps most of the cases. In 3.60 most of the errors were fixed. PS an important note. This is NOT one error, it is a number of different issues, so just because you solve one, does not mean that your client will not have a similar (but different) issue tomorrow.
UPDATE!! Navision is currently working on a fix. Basically this is occuring when my customer (on V3.1 or 3.6) receives/invoices for a different amount than what is in the original “Quantity” field! The “tax related” fixes mentioned above helped about 50% of the time. The other 50% were issues that we just could not get around, when contacting Navision and sending them a copy of the database for an example they’d indicated was due to receiving/invoicing different qty than original Order was. They were already aware of situation and are in the middle of fixing it. [;)] Thank you VERY much for all your input and ideas!
I have just been getting the same error on a PO today. When I run the test report one of the lines says "Warning! A dimension Code ised in Purch. Recpt. Line has not been used in Purchase Line. I don’t know how this is possible. I hope the tax fix also helps us out on this one too.
Desiree Schiff was exactly right. I got the same exact problem. After post received, reopen, add another line ex. acct type, shipping charge. And post Invoice, then this error message sometimes will appear. I am in 3.10b
This is sometimes just a setup Issue where a G/L VAT or TAX Account has a “VAT Prod. Posting Group”, when it is validated it tries to Take Apply VAT or TAX on the VAT or Tax Amount. This can cause Inconsistant error messages!
Just a Note to the Developers. If you can recreate the problem in Cronus or a backup of the database, you can with your developers licence do the following, In the codeunit G/L Post-Line you will find a line GLEntry.CONSISTANT := (Blah)and(Blah) etc: Remark this and enter GLEntry.CONSISTANT := TRUE; Post the Offending Order or Journal and look at the posted G/L Entries to find what has caused the Inconsistant records, this may be caused by Reverse VAT Posting, then “DESTROY THE DATABASE”. Never do this on a live database as you will not be able to backup and restore the data as consistant is tested when the data is recreated! Have fun and keep taking the Nurofen (Headache Tablets) :-}!