Ubercart VAT Number » D7 port

Me too

+1

Subscribe

Subscribe!

I have started work on a Drupal Commerce version of this module.

We don't ask for a Drupal Commerce version. What we need is a Drupal 7 port!!!!

I tried Commerce, it doesn't do the job!!

Ubercart works fine, except that there are not enough modules that have been ported to Drupal 7.

Is there a solution anyway???

I won't be able to do (and support) a D7 port myself. But if someone wants to get started on it, post your patches here and I'll happily apply them.

Thanks,
Wim

I'd like to add my vote for D7 port, as this is a key functionality for B2B scenarios in EU. What does it take to stimulate development of this port? :)

Subscribing .. Also could possibly be interested in sponsoring.

I've created a D7 port for this module.

This port maintains most of the original code (with updates as necessary due to changes
in the Drupal API), with the following exceptions

The uc_vat_number table has been removed, since the original D6 version stores VAT numbers used for orders in uc_order.data, and seemed to not use the uc_vat_number table at all.

All settings for the module have been united in a single form, which is accessible under Store > Configuration > Taxes > VAT Number Settings.

If the store administrator checks the SOAP verification box on the configuration page and inserts their own VAT number, that number is also verified using the SOAP service.

The SOAP client has been changed to WS Client (http://drupal.org/project/wsclient) as the module used by the D6 version does not have a D7 version available.

In the original D6 version, an administrator may change the VAT number of an order on the order edit page without that number be checked against the SOAP service. This behavior has remained in the D7 version.

A dependency has been added. UC VAT (http://drupal.org/project/uc_vat) is now a required module. There's no reason to have two modules declaring which countries are European states, and it's unlikely that one module would ever be used without the other, as any European commerce site will need both.

A dependency has been added. UC VAT (http://drupal.org/project/uc_vat) is now a required module. There's no reason to have two modules declaring which countries are European states, and it's unlikely that one module would ever be used without the other, as any European commerce site will need both.

I don't think we should add a dependency unless D7 UC VAT is fully functional and tested. In its D6 version, it has had a lot of issues and I am pretty sure some European stores have decided not to use it but go for a custom module instead which deals only with the use cases of the client and not anything related to VAT like uc_vat.
Imo, it is too big of a constraint to say that ones can't use uc vat number unless he uses uc vat.

I've also committed a port to D7 of that module.
http://drupal.org/node/1006068

I agree about fully testing both, but as I wrote both of them, I'm sure they are compatible. :)

It seems to me that the validation code is working well. I am not sure, however, how the result of the validation could be used as part of a tax rule condition. In Ireland (or UK), VAT is charged if customer's country is the same as the store country, even if the customer provides a VAT number. However, if the country is different, VAT is only zero-rated, if the VAT number has been provided, and validated.

It is easy to build rules that check the country situation, but what I am not sure about is if you already provide some sort of a condition that could be plugged into the tax rule, that takes care of the country comparison *and* the outcome of the check that the VAT number has been provided, and validated. In other words, I don't understand the interaction between this module and the uc_taxes tax rules, which I understand one still has to create. What about their conditions? I could not see how I could do a Data Comparison condition on a presence or absence of a validated VAT number, as I cannot see it as a value in the selectors for order: or order:customer:.

Also, the validation SOAP call returns the address that is associated with the VAT number, if present. It would be great if you could store that returned address in the order, as a "VAT Validated Address" or so, because that is the address that should be shown on the invoices, if possible.

Finally, it would be great if you could allow for customisation of the messages (though it is possible to use String Overrides).

Once again, many thanks for the hard work.

In reference to #15, here is a new version which adds the rule condition "has a VAT number".

You may use this rule to configure your tax to be charged or not charged depending on whether or not the order has a VAT number inserted.

For validation, I have used the VIES service. This service does return the address registered for the VAT number, but I'm not sure you can expect that the customer will necessarily put that address in the order -- legally they are not obliged to and I think requiring it or even checking it doesn't necessarily serve any purpose. Many businesses may register their VAT under one address, operate out of another address, and even do their shipping / receiving from yet another.

Customization of the messages is a great feature, but I would like to see this version become an official release so that it's not just me uploading tar files to the issue queue as a development process :)

Anyway, attached is the latest version with the added Rule condition.

Thank you, I will test the new code.

Regarding the comment you made about the address being returned by VIES. It is a legal obligation of the seller to ensure that the address of the buyer is the same as the address registered with the VAT number. In other words, if the buyer provides a different address than that of the VAT registration, you are not allowed to provide a VAT-free price. In reality, not everyone checks that. However, storing this address means that for the purpose of the automatically generated VAT invoice it is easy to print that VIES returned address, and I believe this provides for best-effort compliance with the legislation, as it means the invoice would be of no use to someone who is simply "borrowing" someone else's VAT number to, effectively, avoid paying VAT.

I want to comply with the law, so I have two choices: automatically use the VIES address, or delay the purchase until a human being verifies, manually, that addresses match. Or I can take the risk of having to pay back the VAT to the authorities if, during an audit, I cannot prove that I made a best effort at verifying the address.

If you could store the address in an order field, it would be extremely useful, as I can easily use it in the invoice template.

Many thanks.

Good point then, regarding the address. In Italy as far as I know the store has no obligation to verify the address. So that's certainly something to add to the module, as well.

Again, I'd love to see this get added by the maintainer as an official release (I'm happy to be a maintainer of the D7 version, if needed) before adding more features, though, so that we're working within the git repository.

Thanks. I tried the new version of the module, and I am very happy to say that it is working well, except for one very minor niggle. Above all, thanks for creating that rule condition "uc_vat_number_condition_has_number", which I can now use as part of the uc_tax condition to decide if to charge VAT or not.

The niggle is that if you submit your own VAT number as the customer VAT number the web site generates an error, rather than some more meaningful message. I can live what that issue.

I would also consider changing the user-readable name of the new rule from "Check for a VAT number" to something more like "Order has a validated VAT number", as it would make reading the more complex rules easier, if they use your new condition.

I am also not sure what is the purpose of the "information" checkout pane.

FYI: I am sharing my actual tax condition below. component_rules_country_subject_to_irish_vat refers to the rule I shared in #1006068: Ubercart 2 VAT support » D7 port post #32, which figures out if a country is in EU, same functionality as provided by your other module. The extra role check in my below rule checks if this user has been manually pre-approved for VAT zero-rate, as is the case when, for example, there is an address mismatch between registered VAT address and the customer's address, but the customer can prove that they are the same organisation, or we know that from our previous dealings with that customer.

{ "uc_taxes_1" : {
    "LABEL" : "23% Irish VAT",
    "PLUGIN" : "and",
    "REQUIRES" : [ "rules", "uc_order", "uc_vat_number" ],
    "USES VARIABLES" : { "order" : { "label" : "Order", "type" : "uc_order" } },
    "AND" : [
      { "NOT user_has_role" : {
          "account" : [ "order:customer" ],
          "roles" : { "value" : { "9" : "9" } }
        }
      },
      { "OR" : [
          { "uc_order_condition_billing_country" : { "order" : [ "order" ], "countries" : { "value" : { "372" : "372" } } } },
          { "AND" : [
              { "component_rules_country_subject_to_irish_vat" : { "order" : [ "order" ] } },
              { "NOT uc_vat_number_condition_has_number" : { "order" : [ "order" ] } }
            ]
          }
        ]
      }
    ]
  }
}

It would be great if the previously entered VAT number got stored between visits of the user, just like the address is stored. I am not sure how doable this feature request is.

The VAT numbers are stored, and the field will autocomplete if a customer has already inserted it once.

Further, the valid state of the number is cached for a period, so once it's validated, the check will not be performed again for a period of time.

I wonder if the PDOException error, which I am getting from time to time, may be related to the caching? When testing, if I use a VAT number that has already been used with a different customer, I get this error in the log:

PDOException: SQLSTATE[23000]: Integrit y constraint violation: 1062 Duplicate entry XXX for key 'PRIMARY': INSERT INTO {uc_v at_validation} (vat_number, fetched, response) VALUES (:db_insert_placeholder_0...

It would be great, by the way, to turn this into a proper branch, as the D7 version of this module is working relatively well. It would make reporting issues a litte easier, perhaps. Thanks for doing the great work.

I have now created a bug report for this issue, see #1671178: PDO Exception Integrity constraint violation Duplicate entry When Validating a Previously Validated Number for more information including a workaround.

I've created a 7.x-1.x branch, and committed both of aacraig's patches.

Sorry it took some time, I've been keeping busy lately with other projects. If anyone is interested in becoming co-maintainer let me know.

BTW note that in 6.x-3.x I do use the uc_vat_number table to store VAT numbers, they are no longer in uc_order.data.

Hi,
I've just installed this new version, and it seems to work well, except for the tokens I try to put in the invoice template.
I get this errors:

Notice: Undefined variable: store_vat_number in include() (line 62 of /homez.441/vinffbzc/www/ecnf/sites/default/themes/ecnf/tpl/uc-order--customer.tpl.php).
Notice: Undefined variable: order_vat_number in include() (line 120 of /homez.441/vinffbzc/www/ecnf/sites/default/themes/ecnf/tpl/uc-order--customer.tpl.php).

I'm happy to continue developing the D7 branch if you want to add me as a co-maintainer.

Is anybody maintaining this module, its D7 branch?