Total 1 penny out from Accounts package

I am integrating Opencart with 'Kashflow' accounts package and finding that the total is 1 penny out.

Take this for example a Kashflow invoice which has been generated from me sending the net ammounts + vat rate

Qty Description Rate Total VAT
1 Business Cards (Need Design - Yes, Quantity - 1500, ) 225.00 225.00 39.38
1 Parcelforce 48 15.99 15.99 2.80

Total Net Amount: £240.99
VAT @ 17.5%: £42.18
Invoice Total: £283.17

Calculate on the £240.99 total:
240.99 * 1.175 = £283.16325 which is the value OpenCart stores.

Calculate per line:
225 * 0.175 = 39.375 (39.38 rounded by Kashflow)
15.99 * 0.175 = 2.79825 (2.80 rounded by Kashflow)
240.99 + 42.18 = £283.17 which is what Kashflow stores

Any ideas? Kashflow support dont seem to be able to help much

Cheers

Hey,

I think you've just answered your own question

Kashflow is calculating per item
and OpenCart by total

Yes, I know that... is there a way to get Opencart to do the same as Kashflow?

mjo1337 wrote:Kashflow support dont seem to be able to help much

I'm not sure if this thread was posted before or after the conversation with KashFlow support. But from reviewing the ticket there seemed to be a fair amount of help there.

The suggestion was that you check the total of the invoice in KashFlow once all lines are added, against the total in OpenCart. If there's a difference then modify one of the invoice lines by the relevant number of pennies to get the totals to match

I have exactly the same problem with the XERO accounting system (similar to Kashflow). It seems like a really messy fix to be adding invoice lines etc.

Can't we mod OpenCart to calculate VAT per line?

Andrew.

No need to bump this thread. I already posted a solution for rounding down the VAT in the other thread you started.

It's also very doubtful VAT is to be calculated on a per item rather than per total basis.

I've run into this issue in the past as well.

The way I resolved it was to subtract the product total from the opencart total and add it into the tax or handling part, so that the totals matched up. It may not be the ideal solution, but it will make the grand totals match

Did you manage to integrate with Kashflow successfully? If so, any chance of adding it as a module? I would be more than happy to pay for this.

can i just state, that by law, you are allowed to be 1 penny out either way, so unless you just want to be really regimented, i wouldnt worry about it.

This is not a matter of wanting to be regimented.
We use Xero and have to reconcile each OpenCart sale with a Xero invoice. When the amount is out by a cent or two it means creating a rounding entry for every invoice.
This is a great big waste of time.
It's also unprofessional to charge the customer a different amount on the Xero invoice that doesn't match the OpenCart packing slip.
I'm surprised there is no extension for this.
It's silly that tax is calculated per sale on OpenCart and per line item on Xero (and other accounting systems).
I'm looking for a coder who can fix this problem so that OpenCart and Xero invoices total the same amount.
office@easyink.co.nz

In general, you're going to see this kind of discrepancy any time you get to a final number through two different paths involving multiplication by non-integer amounts (e.g., a tax percentage), addition, and rounding. Adding up line items, multiplying by a percentage, and rounding may easily give you a slightly different result than multiplying each line item by the percentage, rounding, and adding up the rounded numbers. You definitely want to avoid having a column of numbers added up (internally unrounded) to produce a different result than what someone would get if they manually added up the rounded numbers.

I don't know if there are any Generally Accepted Accounting Principles addressing this, but mathematically, no way is more "right" than another. If you need two different systems to produce exactly the same results, they will have to add, multiply, and round in the same sequence. If someone hasn't already done so, it might make a good Feature Request to add to OC (what sequence to use when figuring totals).

Be aware that even within an order totals page (much less, between two different systems), rounding can easily cause a sum of line totals (rounded after applying tax) to not match a subtotal of item costs with tax applied. Maybe another Feature Request could be to detect whether the cross totals don't quite match, and insert a footnote explaining why.

Add: I did open a Feature Request: viewtopic.php?f=110&t=184159

Just to mention it, and I don't know, if it will fix your Problem, but I played around with this, after
reading some Postings on it, because in my Country, 8% TAX is Part of the Sales Price, including
Shipping Cost, and OC cannot calculate this into something usable, by default. Anyway, as shown
in the image, by reducing the amount of 'numbers' after the Coma to 1-3, instead of 4 or 5, the end
result will always change in Value. Then, in addition, by use of a ROUNDING ROUTINE, possibly,
you'll find a way, to come close to, what you need.

Just an idea, I know, there is a Mod, fixing parts of my problem for european Sites, since we don't
have to 'display' the TAX Value on invoices in my Country anyway, I did not want to spend a lot of bread,
just to have it installed....
Good Luck!
Ernie

---
https://www.opencart.com/index.php?rout ... h=rounding
---