Welcome to our blog where we share ideas, thoughts and activities.
Global Digital Community
Exploring UK E-Commerce Requirements
Think the only difference between a US and a UK e-commerce site is the currency? Think again. When taking on your first foreign commerce site, be aware of local tax regulations, language variations, different address structures, and more.
I began working on an exciting rescue project earlier this year. My mission: to help complete a Drupal-based UK web shop. The site had been mostly built by other developers, and my job was to build out a few new features and fix bugs prior to site launch. With new features came new requirements quite foreign to this Yank, so I thought the lessons learned would be fun to share with anyone going through (or about to go through) the same experience.
Requirement #1: Certain products need to be marked as either VAT included, VAT excluded, or VAT excluded with a relief declaration.
VAT tax is common in the European Union and the regulations for VAT vary from country to country. In the UK, the government stipulates that items are charged 20% for VAT, and certain items such as books, youth clothing, and food are VAT exempt, while other items are only exempt for people with valid reasons, such as those with disabilities.
Solution: VAT had already been included in the site using Drupal Commerce’s tax module (also look into the Commerce VAT module for extra functionality), and by default all products in the shop had VAT included. To allow shop editors to apply the new VAT exempt properties, I added 2 boolean fields to our Product product variation type called “VAT Exempt” and “VAT Exempt – Declaration Required.”
Next, I edited an existing rule component called Calculate VAT. This can be found at admin/config/workflow/rules/components. I added the following conditions:
Entity has field – Entity: “commerce-line-item”, Field: “commerce_product”
Entity has field – Entity: “commerce-line-item:commerce-product”, Field: “field_vat_exempt”
Entity has field – Entity: “commerce-line-item:commerce-product”, Field: “field_vat_exempt_declare”
NOT Data comparison – Selected Data: “commerce-line-item:commerce-product:field-vat-exempt”, Operator: equals, Data Value: checked, Negate: checked.
NOT Data comparison – Selected Data: “commerce-line-item:commerce-product:field-vat-exempt-declare”, Operator: equals, Data Value: checked, Negate: checked.
These conditions ensured that any product marked with either Exempt boolean did not have VAT applied.
After that, users needed to have the ability to add their exemption declaration to the order, but only if the order contained products marked as “VAT Exempt – Declaration Required”. By going to Order Settings > Manage Fields (admin/commerce/config/order/fields), I added a field group that contained a boolean checkbox labeled “I confirm that I, or the person that these items are intended for, are eligible to claim exemption from VAT” and a long text field for the declaration. Both of these were set to be required.
With the new group created, I made sure to update the Checkout settings (admin/commerce/config/checkout) and set the new field group pane to be disabled. We used Rules to enable the declaration fields’ pane, processing a change to a checkout pane when the order contained products marked as “VAT Exempt – Declaration Required.”
PRO Tip: Take a look at this tax configuration guide on drupalcommerce.org.
Requirement #2: Change “Shopping Cart” to “Shopping Basket” throughout the site. Also, our clients preferred the term “Delivery” rather than the default “Shipping” label.
Solution: In the American south, they’re buggies. In the UK, baskets. We used the String Overrides module to help us out with these colloquial requirements.
We were also required to change the default /cart URL to /basket. Initially this caused concern that changing the URL would cause functionality to break in Commerce, but using a URL alias worked well. DO NOT use a redirect for this. Bad things happen.
Requirement #3: Integrate Postcode Anywhere Capture+ into the Billing and Shipping address fields.
Solution: Postcode Anywhere (now PCA Predict) is a paid-for service that allows users in the UK to search for and validate their addresses on webforms. I had never heard of this service prior to this project, but it was super easy to integrate into the site.
After logging into the client’s PCA account, you’ll want to generate a new service for Capture+ and fill out the necessary settings. On the “On page setup” tab, turn on Activate page setup and copy the code given. Paste this code into a tpl.php that applies to your checkout pages, such as a page—checkout.tpl.php file, and then complete the on page setup. And that’s it! You can always turn the page setup back on if the address fields change.
While you may be used to using PayPal or Stripe for payment processing in the States, our UK clients opted for SagePay, “the biggest independent payment gateway provider in Europe.” Drupal integration is quite easy with the Drupal Commerce SagePay Integration module, and there is a free e-book that outlines how to install and configure SagePay.
This list is quite specific to our clients, and I’m sure there are more examples out there. What kinds of requirements have you received from global clients that seem “foreign” to you?