There seems to be a bug in Attain where Consistency errors could show up when large amounts are used. This happens in Sales and Purchase Orders. For example: When an invoice is entered for an item for a quantity of 3710 at a unit cost of .60874, then 3521 are received, and then you try to invoice those 3521, you get a Consistency error. This was traced to the DivideAmount function in codeunits 80 and 90. The line is TempPurchLineForSpread.“Amount Including Tax” := TempPurchLineForSpread.“Amount Including Tax” + “Amount Including Tax” * PurchLineQty / Quantity ; This formula results in an amount that is .01 different then the amount on the order lines and causes the error. Has anyone else seen this and know how to resolve it or work around this issue? There is no way to get this to post except to change the amount. We tried different rounding statements in this line, but nothing works in all cases. Thanks.
I have seen some inconsistencies in several Navision versions, but not this one. I searched the codeunits 80/90 (Attain 3.01, 3.10, 3.6 beta, 3.6 either W1,SG or TH version). But I haven’t found the place you refer to. Which version are you using? As you say it is in CU80 and 90 I guess no modifications are done in the CU. However, I can not reproduce this error. Kind regards Walter
He’s using the US version where the tax system it’s a bit different. I remember that they’ve release some “improvements” (bug fixes packs) that will deal with the sales tax issues in 3.10 (i’m not sure on 3.60). Please, check if you’re still having your error after those improvements were applied… i think they were solved some time ago…(the problem was mostly that for the tax calculation it was using the total on the invoice rounded, but when calculating for the lines each of them was separately calculated, so the final journal lines could differ in a one/two cents… that was enough for an inconsistency error…) Regards,
Not that this will help but we have experienced a similar problem with the same error message. We have traced our problem back to our above and below minimum tax. This would actually happen when we tried to post an invoice that invoked the above minimum tax calculation and I would have to zero out the above minimum figure so the invoice would post. We have had our solution center look at it but can not find answer.
The system works fine when it comes to inconsistency unless the system has gone through changes.Inconsistency error may be due to → change in the decimal places of the amounts → change in the code in rounding the figures Where there any changes in your database in the areas i specified Keith ??
Lakshmi… trust me… the system not always work fine “out of the box”. We have found some problems in “out of the box” us versions when handling tax… the problem was caused mostly when working with tax, because the individual lines were posted one by one rounding their individual tax, and the balancing g/l line for those lines is getting the tax based in the total invoice value, so there are sometimes small differences. Example: line 1: amount with tax 3.3333333333 (rounded 3.33333) line 2: amount with tax 3.3333333333 (rounded 3.33333) line 3: amount with tax 3.3333333333 (rounded 3.33333) ------------------------------------------------ posted 9.99999 Invoice amount with tax: 9.9999999999 (rounded to 10.0000) then Inconsistency error… [:(]
This is bug in Navision, but usually I saw it happens (in 3.60) when you specify the Tax area Code on the Sales/Purchase Line and the “Tax Area Code” does not setup a “Tax Jurisdiction Code”.
Hi, When the G/L setup has the setting “Summarize G/L Entries” as TRUE, then you will get the error.(This is the bug in Navision) This error comes only when your purchase or sales order has more than one lines. Can you try one thing- In the currency table(id-4) set the “Unit Amount Rounding Precision” as 0.0001 and then try.