silvershop-core

silvershop-core copied to clipboard

Is it possible to only apply tax to some products in the catalog? Which modifier should i look at using for that?

GST in Australia does not apply to food items for eg.

You can write your own Modifier for that. I guess you'd have to add some sort of Type field to a product to determine whether or not tax (or which rate) should be applied.

oh. ok thanks.

Hi @asecondwill

I have made a gist here doing somewhat like that: https://gist.github.com/hpeide/fee33737ad5efa5806396e5f6a91b87c

It do not work that well combined with the Discount module, so if you stumble on a good solution for that, please post! :-)

hi @hpeide - thanks for this. very helpful.

I think the discount module issue is because you are going back to the product and calculating the price.

Maybe if we can somehow use the attribute on the product to influence the $incoming value directly just for tax it won't mess up anything else.

I don't think you need to rely on the $incoming value. Just ignore it and calculate tax based on order contents (accessible via $this->Order())

ok. does $this->Order() contain shipping and discount stuff, or just product line items?

answer: no. so how to avoid losing the shipping and discount calculations. tricky.

actually. we need to consider what the discount has been applied to.

There is some abandonware that has some crossover.

https://github.com/burnbright/silverstripe-shop-taxframework

@jedateach - do you have any advice on this topic?

https://github.com/burnbright/silverstripe-shop-taxframework/pull/7

made an attempt at getting tax Framework to work in 3.5

That module you linked to doesn't do things differently than I suggested. It doesn't take discounts into consideration either…

The architecture with Order-Modifiers only works well for certain scenarios. Ideally, an order-modifier is a self-contained entity that can perform its task without knowledge of other modifiers. As soon as you have modifiers that operate on the same items as others do, without knowledge of the changes made by another modifier, then you'll run into problems.

So the scenario where you have a tax per product-type combined with coupons can get problematic (because your tax doesn't operate on an incoming total, but calculates from base-prices instead).

If you have a good idea for a better architecture, I'm all ears. I think this should be some sort of RFC-style document/issue where the new architecture can be discussed.

That module you linked to doesn't do things differently than I suggested. It doesn't take discounts into consideration either…

Yep. i realise that. good base though to build on.

As soon as you have modifiers that operate on the same items as others do, without knowledge of the changes made by another modifier, then you'll run into problems.

Agreed. That's discounts for you. i'm not even sure i can get my head round exactly what i'd want to happen. possibly it changes depending on the law / type of discount etc. it's probably epicly hard.

If you have a good idea for a better architecture, I'm all ears

i'm not that clever. I didn't mean to imply i thought it was all wrong. sorry if my ticket came off as rude.

I'm reopening this, so that this discussion isn't getting lost and can be considered when there are architectural changes about to happen.

@asecondwill You might still be able to make it work by rolling your own Tax-Modifier. If you install the discounts-module, there are several ways to figure out the discounted amount (either per product, or total). You would then have to incorporate these amounts into your tax-calculation. I guess in the end it really depends on what kind of discounts you need.

there are several ways to figure out the discounted amount (per product)

Any further hints there? this is the bit im struggling with.

Also, how can i get the shipping amount after discount?