Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change PRICE_INCLUDES_TAX per request/order #55

Closed
jonasvp opened this issue Apr 11, 2013 · 2 comments
Closed

Change PRICE_INCLUDES_TAX per request/order #55

jonasvp opened this issue Apr 11, 2013 · 2 comments

Comments

@jonasvp
Copy link

jonasvp commented Apr 11, 2013

We're currently evaluating Plata for a multi-country shop that includes Switzerland, Germany and the US.

One thing I'm uncertain about is that US prices must include differing sales taxes depending on the location of the customer. That tax is not included in the price. In the European countries, the tax is fixed per-product and included in the price.

For our shop this means that we'd have to change PLATA_PRICE_INCLUDES_TAX per order, depending on the country version the customer is accessing. Since it's defined globally, is there a workaround for this case? I'm not very fluent in Plata yet so I might be trying to solve this the wrong way.

I thought about a pull request adding a method on "Shop" in this manner:

    def price_includes_tax(self, order=None):
        return settings.PLATA_PRICE_INCLUDES_TAX

This would recreate the current way of handling this issue. For our case, we'd return a value based on the currently set language or order.language_code. What do you think?

@matthiask
Copy link
Owner

I have been giving this issue some thought in the last days. Whether prices include tax or not is a similar question as the default currency for a given visitor and should therefore be implemented in a similar way as Shop.default_currency is.

The implementation of the US tax system is a different question. We have been discussing this issue here: #53.

Adding a method to the shop object is certainly the way to go. The shop is accessible from everywhere (plata.shop_instance()).

Maybe we also need a new boolean flag on the order saving the current state of price_includes_tax, so that order PDFs etc. can be generated correctly later?

@jonasvp
Copy link
Author

jonasvp commented Apr 15, 2013

I have been giving this issue some thought in the last days. Whether prices include tax or not is a similar question as the default currency for a given visitor and should therefore be implemented in a similar way as Shop.default_currency is.

I haven't thought about it in those terms but it sounds right. I'll get started on a pull request, hope to get it done this week. I'll close the ticket for now.

Maybe we also need a new boolean flag on the order saving the current state of price_includes_tax, so that order PDFs etc. can be generated correctly later?

Good point! I'll add a field to that effect. Incidentally, having the language_code on the order model was very helpful. It's how we're separating the different shop implementations now.

The implementation of the US tax system is a different question. We have been discussing this issue here: #53.

I don't think it's that complex, really - the US only have one tax, it's just dependent on the state of the customer. I think it'll map nicely to the current implementation.

@jonasvp jonasvp closed this as completed Apr 15, 2013
jonasvp pushed a commit to jonasundderwolf/plata that referenced this issue Apr 18, 2013
Fixes matthiask#55

This adds a new field to the Order model, you might need
to create a migration within your own app.

It also removes the ``unit_price`` property on the
PriceBase model, since there's no way for the price to
know it. You should only call unit_price on OrderItem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants