Hello Ryan,

thank you very much for taking care for this topic! Just a few short thoughts on this topic. The flowchart is really good, probably just missing the difference between professional and private customers, but there I am now also not sure.

VAT contrib: IMO there is missing that just professional customers have to provide their VAT number, so the additional condition should be if the customer fills the Company field. This one I still was not in, so more I can't tell ATM.

IMO this should be definitely also the way for Australia, Canada and probably others.

zmoves uc_taxes_alter is a good starting point to achieve most of the things on a module base, but it is far from being complete.

A module's base should be 2 main configurations:
- Are taxes calculated on per order base (like it is) or on per product base (like e.g. the EU needs). This is a rounding issue and just 3 lines somewhere in uc_taxes need to be packed in a if/else statement.
- Display taxes: Show taxes just on checkout or always? I mean really always, e.g. products, teasers, cart, order pages, invoice template, shipping, ... all displayed incl. VAT.
The rest can work through Workflow-ng (and that a "Display Tax" module checks theses settings)

I am looking forward to contribute whatever is useful from the code I produced up to now, best regards,

Al

Hi,

I'm very happy to see that the European case will be a major point for the next Ubercart releases . I spent a lot of time to think about the best way to implement the European needs and I think, now, I have a pretty strong opinion about the question.

As Ryan said, and I'm totally agree, it's not just a VAT number concern. Provide a Store VAT number (set up in the store setting) and a customer VAT number (set up in the checkout page via a checkout pane) as my VAT contrib do is just anecdotic. There is a price display issue too.

So the ideal "European Friendly" module would merge 2 modules : VAT contrib and Add tax to product price contrib but ATM, this 2 modules need a lot of work to be usable by most users.

See below what the module should do in a perfect world :

The VAT module

This module have to know 2 informations about the user :

• His status (individual or professionnel)
• His country (in European Union or not)

If the status is professionnal and the country is in European Union, the store have to show a required VAT number field. To make these conditions, I think workflow is a good solution. As the module already provide a "check the customer delivery address", it would provide a "check the customer billing address". In addition, the country select list is multiple, so it's easy to check all european countries in one rules.

I would add that, for usability, that the VAT number should not be in a separate pane. It should be in the customer billing information pane, and appear or disapear if the customer change his country for an european country or not. As you have to use javascript to make the condition (because the country is not asked before the checkout pane) I think it can be done using javascript too. (see the screenshot 1)

For the condition about the user status, I think the best way to dissociate an individual customer than a professionnal is to create 2 different roles in drupal, it's what I done for my Kalys gastronomie website There are a lot of advantages to make it via roles :

See in my screenshot that the company field become required if the user role is professionnal, so it means the core can provide optional/required field depending on user role

• Its drupal core, so there are a lot of modules that extend functionnalities (example, ask different information depending on the role on registration, separate individual and professionnal statistics in google analytics, create coupons just for a selected role etc...)
• Its easy to add a condition in workflow to check the user role, some actions to gives roles etc...
• more, more, more...

And the module would provide 2 token for the invoice :

• One to show the store VAT number
• One to display the customer VAT number

One cool feature would be to check if the VAT number is correct on a European database, I know it's doable because there is one module for osCommerce that do it. the store admin would be able to choose if he want this option or not

The display price module

In an european store, all individual (all over the world) have to pay the VAT. For professionnals, only the professionnal of the country of the store pay the VAT, the others don't pay it. So you need to know 2 informations about your customer when showing price

• His status (professionnal or individual)
• His country (the same than the store or not)

As it's impossible to know the country of the customer before the checkout page, you cannot check the second condition on a product page but you can show both prices (with a bigger price includng VAT, because it's the more important). A cool feature would be to let the choice to the user, to show single price or both. If single price is checked, the store show price including VAT to individuals and price excluding VAT to professionnal.

The "including VAT" or "excluding VAT" have to be specified near the price to not confuse the user, so the module have to implement a kind of suffix after all prices.

In addition, the prices have to be managed excluding prices, because all calculation on product (example discount) are made on excluding price. Adding the tax to the price is only for display.

So to resume, in europe, it's better to show prices including prices to the user, but you have to manage them excluding price. One problem I encounter when I developped the add tax to product price contrib was that Ubercart calculate the subtotal by adding, for each product, the product price * quantity. So, as I wanted a subtotal excluding tax, I had to make a reverse calculation te remove the tax I added on sell price on the checkout page, which could bring some rounding problems. I think core have to change some things (don't know what) to make that more extensible.

Another things is that, the subtotal have to be displayed like that on the invoice :
- Subtotal excluding tax
- Shipping quote excluding tax
- Discount (if one) applied on the subtotal excluding price
- Total excluding price
- Tax
- Total including price

But this is already possible with the Lyle addition to show the Total excluding price before the tax if a tax is displayed (Thank you Lyle )

Voilà, I wish my post is complete enough.

About my work on that module, I'm not opposed to that, but maybe not as the main maintainer. Maybe as a co-maintainer or a consultate, because It's not my work, I'm not sponsored to only work on that so I don't often have the time for that. I could work on the 2 modules I develop because it was a need of a customer, now it's done, I'm on another project that don't need it ATM so I don't have much time to spend on it (and on my free time I'm developping a website for my eve online corporation ^^).

So maybe as a co maintainer or a consultate, I'm ok.

We've been working on the same problem, but threw in another one that seemed to be somewhat related: Different prices.

It seems a requirement/wish for a lot of customers to be able to have different prices depending on different criteria, some examples:

Role based prices for setting custom prices for 'Gold customers'.

Currency based prices, as pure rate based conversions isn't satisfactory for some customers.

Our, work in progress, solution moves prices out into a generalised module that allows add on modules to define hooks into the price finding process. In the finding process each hook can either change the price or add another 'price' as a property. An example of the latter could be a VAT calculating module that stores the VAT with the price without changing the price as such. The theming function can then decide whether to show the price with or without VAT, or with VAT as a separate item.

The idea is that a shop system (not limited to Ubercart) requests the price for an object (often node, though other types can be implemented), and uses the theme function to display it (by telling the theme function where the price is to be shown, which allows the themer to variate the display depending on context), and an 'getter' function for getting the price that should be ultimately charged for this object (allowing for more hooks).

Also the price object contains the currency of the price, which allows for both exchange rate based modifiers as well as add-on modules that store prices for different currencies.

This allows for considerable control over how prices and their display.

Hmm I would precise that, even if you only sell to private customers, you have to show your shop VAT number in the invoice, so it's equally important that the Tax price display issue.

I agree that the tax should be calculated per item basis, or we will have rounding issue on the checkout page (as I have on my shop). The problem is that we have to store the price excluding tax somewhere because this is the base of all discount calculation.

The major problem with tax is that the tax have to be calculated at the very end in the invoice (and checkout page) but, at the same time, each product must be showed including tax.

And the way ubercart calculate the subtotal ATM make this not possible.

@xen.dk@drupal.org: How far are you? This development sounds very interesting to me.

My opinion about what we really need to display taxes:

1. First issue is about rounding on a per product/item base, so this means in uc_taxes_workflow.inc 3 if/else statements. That simple if you know where it happens. To get an idea what about it should look like see the attached patch
2. Next is for discussion: To get the taxed Subtotal for the checkout process I added 3 lines in uc_cart_checkout_pane.inc. Target is to collect the subtotal where I already have the values taxed (through my module) and save it in a $_SESSION['taxed_subtotal']. This works now already 2 or 3 weeks without any issues for me. Maybe this could be done by a module also, but not in 3 lines.
3. Probably not a much bigger thing, but I still didn't have time to look into it how it could be done: In the order we need for every product and every line-item the tax rate(s) at time the order was submitted. Tax rates are no diamonds, so this is needed to get old orders displayed right if tax rates changed.
4. Where I am totally lost are the 2 Javascripts on /checkout: Both should save the values without tax (as is), but call Workflow-ng for the tax rules and then display the taxed values. This any solution will need. If someone has a better relationship with JS than me and wants to help out - you are warmly welcome!!!
5. If we talk about Europe I would like to mention that currencies still are a very big issue, so my +1 for xen.dk@drupal.org's efforts or I start in a couple of weeks a thread about "opening uc_currency_formt()".

To get things finally started independent on which module base this are the basic requirements. More core support or a more sophisticated approach would make our life easier for keeping our module up to date, but only the above things are the real show stoppers.

Ok, from whatever reason the second patch doesn't generate, so inline. Sorry. Base is uc_taxes_workflow.inc, v 1.1.2.5 2008/04/23 19:38:13

line 89

line 101

line 107