BambooInvoice Forums

Thanks Clubbers.

The rounding issue is one that I’ve tried to address for the next version, but truth is there’s so much (potentially) to calculate that I’m still not sure I got it.

When Bamboo started out it was just a tool for me, that I released publicly so the CodeIgniter/PHP community could take a look at it, beat it up and learn from it. It quickly started to get used by people, which *thrilled* me, only it was never intended for infinite currencies, infinite products, infinite quantities, and infinite taxes. Its been evolving nicely, and the next version is largely a rebuild of the whole taxing system from the ground up.

Thing is, I’m also building ExpressionEngine, and that has needed to be a priority, so 0.9 is 80% done sitting on my laptop here.

Anyhow, that is all by way of explanation that I’m aware that in some situations rounding can be off, and I’m working to address it. I don’t know of any particular easy work-around besides being vigilant for when those issues might crop up.

Welcome to Bamboo.

Derek,

Thanks for the swift reply.

Sorry to be a pain as I understand you are very busy indeed. Is there no simple fix to turn of the rounding of each individual line entry on an invoice? Is that where the problem originates?

The total price on the invoice summary page seems to be correct, the sub total on the invoice page itself seems to be correct and the VAT figure on the invoice page seems to be correct. Its just the grand total (sub total + VAT) on the actual invoice page that goes wrong….adding 1pence generally in my case but I read from others they are experiencing extremes greater than this. I guess the more lines and more calculations the greater the mis calculation becomes :-(

Guess i make it sound easy but obviously not.

Thanking you in advance and look forward to the next version then if that would be the only fix.

Also from reading for many hours the forum it would be a great shame if you were to remove the license due to the actions of a few…

Regards,

James.

I think I found a solution for the rounding problem.

Looking at the invoice listing I saw that the total amount (with tax) was correct. When I opened the invoice, the amount was’nt correct. So I searched for the routine where you calculate it. Found it in invoices_model.php.

Somewhere arround line 100 calculating the “total_with_tax” for the invoice:

$this->db->select(’(SELECT SUM(’.$this->db->dbprefix(‘invoice_items’).’.amount * ‘.$this->db->dbprefix(‘invoice_items’).’.quantity + ROUND((’.$this->db->dbprefix(‘invoice_items’).’.amount * ‘.$this->db->dbprefix(‘invoice_items’).’.quantity * (’.$this->db->dbprefix(‘invoices’).’.tax1_rate/100 + ‘.$this->db->dbprefix(‘invoices’).’.tax2_rate/100) * ‘.$this->db->dbprefix(‘invoice_items’).’.taxable), 2)) FROM ‘.$this->db->dbprefix(‘invoice_items’).’ WHERE ‘.$this->db->dbprefix(‘invoice_items’).’.invoice_id=’ . $invoice_id . ‘) AS total_with_tax’, FALSE);

Somewhere arround line 229 calculating subtotal for the invoiceslist:

$this->db->select(‘ROUND((SELECT SUM(’.$this->db->dbprefix(‘invoice_items’).’.amount * ‘.$this->db->dbprefix(‘invoice_items’).’.quantity + (’.$this->db->dbprefix(‘invoice_items’).’.amount * ‘.$this->db->dbprefix(‘invoice_items’).’.quantity * (’.$this->db->dbprefix(‘invoices’).’.tax1_rate/100 + ‘.$this->db->dbprefix(‘invoices’).’.tax2_rate/100) * ‘.$this->db->dbprefix(‘invoice_items’).’.taxable)) FROM ‘.$this->db->dbprefix(‘invoice_items’).’ WHERE ‘.$this->db->dbprefix(‘invoice_items’).’.invoice_id=’.$this->db->dbprefix(‘invoices’).’.id), 2) AS subtotal’, FALSE);

The last one works just fine. It rounds the amounts as it should. So I documented the total_with_tax rountine and pasted the subtotal routine there. Ofcourse replaced subtotal with total_with_tax in the “new” routine.

Have to test it though because I am not that familiar with your (otherwise outstanding!) program, but for now it looks okay.

Derek, I think that your the only one who can really tell if this is okay and does’nt mock up something else.

I have this problem, too. It happens on a regular basis, that I enter a payment but the invoice is still shown as open, just because the payment is one cent less than the rounded-up total in the invoice-overview.
Looking forward to the next version of bamboo invoice. Thanks!

Rich,

This sounds like an ideal solution because as you say the routine that determines the grand total in the invoice list (seems to work fine). The error is being created becasue the rounding is done per line total on the invoice instead of rounding the grand total, hence the more items you have on seperate lines the greater the error becomes.

The difference between the two routines above is where the ROUND is done in the statement so not being a coder myself I’m assuming that it shouldn’t make a difference elsewhere in the program as it is only simply changing where the rounding is done. Which should give the correct end result…

The question is though why are these two statements different in the 1st place when what is supposed to be achieved by each is the same figure???

Derek can you shed some light on this??

If you look at the way Bamboo holds the totals data in the data base you’ll see it holds the total amounts minus the tax except in the invoice_payments table. Those 2 different functions in the model are used for different purposes but their results get compared when bamboo displays a total and compares it to the total in the invoice_payments table. I very much doubt that Rich will find any problems because those 2 functions should be exactly the same so they can sync throughout the system. Because those functions both just return a result it cant cause a problem as long as they both return the same result.

clubbers - Mar 10, 2010 12:02pm

Rich,

This sounds like an ideal solution because as you say the routine that determines the grand total in the invoice list (seems to work fine). The error is being created becasue the rounding is done per line total on the invoice instead of rounding the grand total, hence the more items you have on seperate lines the greater the error becomes.

The difference between the two routines above is where the ROUND is done in the statement so not being a coder myself I’m assuming that it shouldn’t make a difference elsewhere in the program as it is only simply changing where the rounding is done. Which should give the correct end result…

The question is though why are these two statements different in the 1st place when what is supposed to be achieved by each is the same figure???

Derek can you shed some light on this??

As mentioned by Zoltarc Oct 28, 2008 07:57am:

I have removed the ROUND() functions from _getInvoices() and getSingleInvoice() and the problem seems to have disappeared.

This worked for me too, never had a rounding problem since. Derek replied that this fix would be in the next release.

To be sure the total with tax is always the exact sum of total without tax plus taxes, change the following line in invoices_model.php (function getSingleInvoice)

$this->db->select(’(SELECT SUM(’.$this->db->dbprefix(‘invoice_items’).’.amount * ‘.$this->db->dbprefix(‘invoice_items’).’.quantity + ROUND((’.$this->db->dbprefix(‘invoice_items’).’.amount * ‘.$this->db->dbprefix(‘invoice_items’).’.quantity * (’.$this->db->dbprefix(‘invoices’).’.tax1_rate/100 + ‘.$this->db->dbprefix(‘invoices’).’.tax2_rate/100) * ‘.$this->db->dbprefix(‘invoice_items’).’.taxable), 2)) FROM ‘.$this->db->dbprefix(‘invoice_items’).’ WHERE ‘.$this->db->dbprefix(‘invoice_items’).’.invoice_id=’ . $invoice_id . ‘) AS total_with_tax’, FALSE);

to this

$this->db->select(’(SELECT SUM( total_notax + total_tax1 + total_tax2 )) AS total_with_tax’, FALSE);