The 1.x flat rate module has the ability to specify if the shipping rate amount has tax included.
This is something we need in this branch as well.

My idea was to have the shipping rate as a config entity (Profile2 style), which would have given us (apart from export / import support) a price field, with that functionality built in.
Since rates are not entities in this code, we need to think of an alternative.

Comments

rszrama’s picture

rszrama commented
Version: » 7.x-1.x-dev

Ahh, it should be easy enough to accomplish with an additional column in the flat rate service table. Even if we were using a price field, the functionality wouldn't be built in, because the Tax module only adds the option to the commerce_price field on product entities. I'll take care of it speedy quick. : )

rszrama’s picture

rszrama commented
Category: task » feature
Status: Active » Fixed

Ok, added support for this, but I'm not sure I like the user experience. Right now it shows the selection as $25 but breaks it apart in the order totals so the shipping rate only appears to be that amount less the 19.6% VAT. There's no way to really see that the VAT from the shipping got lumped into the VAT from the order. I suppose this could be solved by the administrator just making the display title be: Standard shipping (incl. VAT). Is that basically what you've been doing?

Only local images are allowed.

Commit: http://drupalcode.org/project/commerce_flat_rate.git/commitdiff/63f805c

bojanz’s picture

bojanz commented

Even if we were using a price field, the functionality wouldn't be built in, because the Tax module only adds the option to the commerce_price field on product entities.

That sounds like something that should be configurable.

My main use case for having rates as an entity is that I'd be able to attach an entityreference field pointing to a store, so that in a Marketplace scenario we can know which rate belongs to which store. We already have all the "entity-ish" code, we basically need hook_entity_info() and some massaging...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

maciej lukianski’s picture

maciej lukianski commented

It seems it would be better do display shipping as a normal line item along with other products.

PESTO3567’s picture

PESTO3567 commented
Status: Closed (fixed) » Needs work

I have products and shipping, both include VAT . But shipping is displayed without VAT and appear after the VAT in summery. Sure, the calculation isnt wrong but its not consistent with the product price and extremly confusing. I was able to change the weight and display Shipping after Subtotal, but the result is still not acceptable. The way it it's done make it impossible to build a Shop according german law.

The VAT for shipping should be displayed in seperated line because it can be 7% or 19%. If most of the products in the cart are 7% the VAT for shipping is 7% too, otherwise its 19%.

Example:
---------------------
Subtotal: 30,- €
- VAT 7%: 0,- €
- VAT 19%: 4.03 €
Shipping: 6.90 €
- VAT 19 %: 1.10 €
Total: 36.90 €

rszrama’s picture

rszrama commented
Status: Needs work » Closed (fixed)

Can you perhaps open a separate issue for display specific requirements? This particular issue was resolved by adding VAT support for flat rates, with the display workaround being to use a display title that works for non-German stores. Of course, since then I've found out about Germany's extra requirements for VAT display, but I don't think we should bring this issue back from the dead for it. It's probably going to be a non-trivial fix because of the way line item total price fields are aggregated for order totals (which is where the breakdown by subtotal / tax type comes from).

One workaround right now would be to just add a duplicate tax an alter its weight around the shipping price component types; i.e. you may have your 7% VAT that you're using for products, but just add a duplicate 7% VAT with a different machine-name / admin title that maybe even displays the same as the normal VAT or uses a different display title to indicate it was tax on the shipping. Then you'll end up with two separate price components in your order total display.

In fact, let me know if that's sufficient, and we can just document it as the solution.