Issues rounding total & subtotal on taxation of items

[t2thec]

Hey, thanks for the awesome package! Great work.

I'm not sure if it is something I am doing or not, but I think there may be an issue with the rounding of the totals.

I have item prices in the DB without tax.

The item price should be 10.00 with tax included - in my DB it is 8.33 with 0.2 set as tax (20%).

$cart = LaraCart::add('sku', 'product name', 1, 8.33, [], true);

LaraCart::total($format = false, $withDiscount = true, $withTax = true, $withFees = true)
// 10.00

However if I then add two items

$cart = LaraCart::add('sku', 'product name', 2, 8.33, [], true);

LaraCart::total($format = false, $withDiscount = true, $withTax = true, $withFees = true)
// 19.99

The latter example should obviously be 20.00.

Am I doing something wrong?

Thanks

[lukepolo]

Ill write a test to do these conditions, then i can look into why iuts broken.

[t2thec]

Wow! Now that is some awesome support for a open source project! Thanks again. Legend!

[lukepolo]

No problem! I love this package!

[lukepolo]

wrote the test, having some other issues but should be up soon

[lukepolo]

Ok so

The reason for this is 8.33 + 1.666 = 9.996

9.996 * 2 = 19.992 , so it sounds like i need to total each item separately to calculate tax

[lukepolo]

@t2thec i need to look to see at some ecmmerece standards to check if taxation happes at the total level, or per item level .

If you find some references for this we can move forward and change the behavior.

[t2thec]

I have found a few examples of both to be honest. The reason I love this package so much is because you can add tax to an item.

Here in the UK, most products have 20% tax. Some products are reduced tax at 5% and others and 0%.

To me it would make sense on an item level for circumstances like this. I don' think it is uncommon.

If you bought one item in a bricks and mortar shop, it would have its tax applied, it isn't applied at the checkout globally.

Cartalyst approach here uses their Conditions package to add tax. Although this example targets the subtotal, it is also possible to target the item which surely is the right option. If you see lower in the page, you can see item level examples.
https://cartalyst.com/manual/cart/2.0#conditions

This is another alternative https://github.com/darryldecode/laravelshoppingcart#conditions again, the example is the subtotal is the target, and again, you can target the item level. If you look lower down the page you will see the example applying to the item.

It would be great to have the flexibility to do both. Personally, if there was only one choice, the I'd item level has to be the 'proper' way to do it.

What do you think?

[lukepolo]

I think I like it at the item level, cause i can see cases where you may be buying things at a diff tax level , which could happen . Ill look into a way to make this change. Its a biggie though.

[t2thec]

Sweet. While you are in there, it would be really nice if at an item level we could have the following:

$item->item_tax; // The tax per item (Not the sum of all items)
$item->price_ex_tax; // The price per item excluding tax
$item->price_inc_tax; // The price per item including tax
$item->subtotal;  // Subtotal of all items items excluding tax
$item->tax; // The total tax for items by qty
$item->total; // The total of everything to do with this item

I've currently made added these myself, which is not bother if you don't want to implement them.

On a separate note, I'd love to contribute where I can. I've noticed that the docs are missing a few bits here and there. Would it be any help if I went through them and added what I can? Or is there anything else you need looking at?

Thanks Luke - Keep up the good work. Its the best Laravel cart out there!

[lukepolo]

http://money.stackexchange.com/questions/15051/sales-tax-rounded-then-totaled-or-totaled-then-rounded

So it seems the solution is complicated. We could just always round up to solve this. I may have to make this configurable

[t2thec]

Its so frustrating when there is no clear, defined way to accomplish something like this. So many mixed opinions would suggest that it varies state-wide in the US and globally too.

A nice approach I have used in the past is Cartalyst's Conditions: https://cartalyst.com/manual/conditions/2.0 which would accomplish whats needed I guess.

For the time being, I think I will need to hack something together as we are hoping to launch quite soon. I'll post up what I produce and you are free to take what you want from it. I'm clearly not as familiar with the src code as your good self however.

[lukepolo]

I started working on it, and doesn't seem that difficult , just need to finish it up , and want to make it configurable

[t2thec]

Sweet. That is awesome. Thank you. Let me know if there is anything I can help with.

Cheers

[lukepolo]

Just an update : haven't been able to get around to it, hoping in the next couple of days

[t2thec]

You sir, are a legend. Thank you. Looking forward to playing with it.

[it-can]

Hey @lukepolo any news on this?

[lukepolo]

i got kinda stuck , its half implemented. ill push what i have tonight

[lukepolo]

Ok so, i worked on this and endted up breaking more than it fixed. Sorry for the delay

[lukepolo]

Sorry didnt mean to close~

[it-can]

Maybe something like this could help? https://github.com/moneyphp/money

[lukepolo]

No cause its not a rounding issue, its a taxation issue , but i plan on adding that into V2 (whenever i get to that)

[lukepolo]

good news :-), i got it! pushing it up here in a few

[lukepolo]

This has been released : 1.3.1

[t2thec]

Yay! Nice one Lukepolo. Awesome work. Thanks again for all your efforts.