DensitySK

Thank you,

that is unfortunate. Would definitely be a good idea if something like this would be implemented, at least in a premium version.

For a seller who is acustomed to enter prices inclusive TAX it is very time consuming to calculate each tax exclusive price for the partiular shipping table. This obviously is not only causing exhausting work but also problems with various rounding and other related issues.

Regards
Michal

HI Shaun,

unfortunately that guide is focused more on businesses that are based in the UK.

It is not accurate for businesses registered in EU who sell to UK customers – i.e. there is no discretion of how an EU business can i.e. define a VAT rate for a certain order value ONLY for a specific country – in this case UK. If I sell to all EU countries, than naturally I must set this specific VAT rate for a certain order value ONLY for UK and no other country

Furthermore it completely misses the fact, that EU businesses usually operate in EUR currency. Hence something should be done on how the EUR to GBP exchange rate moves i.e. on a daily basis from ECB bank which can be done via free feed provided by ECB

UK HMRC has a 135 GBP threshold up to which the WEBSITE owner must collect the UK vat and keep a record of it.

If the store is operating in EUR currency, the 135 GBP on one day is valued at different EUR rate than in other days due to exchange rate.

For example on one day the 135 GBP represents 149 EUR and on the other it might represent 151 EUR. Since my website charges in EUR, and probably the snippet for the variable VAT rate for UK orders would only include a static EUR value, the website owner might and eventually will get into trouble with tax office for incorrectly reported VAT reports.

I know that this is a very specific issue, but BREXIT all together is a very weird issue for all woocommerce operated websites and since most of the changes must be implemented on the Website level already, Woocommerce should look into this further.

The very same problem that I have will definitely be experienced by hunderds of Woocommerce websites across Europe

Regards
Michal

HiRene,

thank you for the info.

If I understand it correctly (with or without the PRO version),

if I first import all orders into the staging site and then “migrate” the whole staging site content to the live site, will the complete old database content of the original LIVE site be overwritten?

My goal is to make the new website more lightweight with less plugins and I want to avoid any heavy cleaning of any remains from old plugins used on the previous version of the live website.

Regards
Michal

HI,
In the first screenshot you shared, your Calculate Tax Based On setting is incorrect:

Yes I know. If you read my original post, this is exactly what I wrote. If I set it to the correct way – i.e. calculate tax based on CUSTOMER shipping address, than EVERY SINGLE VISITOR who enters my shop see all my prices incorrectly without VAT.

but now since you’ve mentioned that I should set the default customer location – I have set it to shop base address and it solved one problem. Now when a visitor enters my shop, he/she see all my prices with VAT, unless they enter a shipping address outside of EU. In such case VAT is removed

Thank you for the tip.

However one related problem now appears.

EU based shops in most EU countries are required to list their prices including all relevant taxes – for that purpose they usually enter a suffix next to the price (i.e. incl.VAT). This works in WooCommerce in general.

BUT when a VAT-free customer logs in or enters his address on the cart page, the prices in cart correctly show without taxes and it hides the price suffix (incl.VAT) – but the shop catalog and product pages still incorrect show this suffix.

Check this screenshots:

View post on imgur.com

Do you have any tip how to hide this suffix for TAX-free customers?

Regards
Michal

Hi
thanks for checking. I understand your point, however this should not really be an issue with the way the customer writes an address.

From a legal and tax perspective in an international trade, VIES is the only international system used for validating on whether a customer has a valid VAT ID AND what his correct company details are. The data in the VIES should be correct.

If the VIES entry is different (because of the way they write their address, different language especially for bulgarian and greek businesses, etc.), then technically they should change their order to match the VIES entry. If their company details have changed or they insist on using “their way” of writing their company details, than the correct process for them is to request their local tax office to submit an update request in VIES portal. This is usually what tax offices expect.

Also from a legal standpoint in most EU countries it does matter how they submit a VAT registration especially the way the write their company name and legal entity suffix.

EXAMPLE:

Original registration: COMPANY A Limited Liability Company

Wrong way to write the company name in formal transactions:
Company A LLC
Company A Limited Liability Company
COMPANY A LLC

Even though LLC, Limited Liability Company mean the same thing, they MUST be written correctly as originally registered.

Also if company has registered their company name in CAPITAL LETTERS, then they are required by law to present them in the same way. Using Company A instead of COMPANY A is not correct.

Therefore there should be no problem with fuzzy logic or similar demanding development processes.

But of course most tax offices do not really care if a company name is in capital letters or street address has different way of writing house numbers, etc.

I was just mentioning it as a reference point – what is viewed as correct by most regulations.

But for the purpose of the original issue…maybe it would be more than enough, that the customer would have to enter at least the full company name that could be checked against VIES along with the VAT ID (and maybe ignore the capital letters and only focus on the content). Because currently the customer can enter the VAT even without checking the box “Buy as Business client”

View post on imgur.com

That would at least give one additional step for the customer to actually enter correct details – naturally it is not 100% fraud proof, but it would make it easier for businesses to prove, that they did what they can within a reason to validate the VAT entry and that the person on the other side might actually be a business client and not just some consumer wanting to buy cheaper.

But I understand if that might be troublesome to implement.

Regards
Michal

Hi,

thanks. Ticket 40171 is submitted

Regards
Michal

Is there any update on the progress?

I see that your plugin does not even saves the custom stock status if the user wants to save it individually per item – once the user clicks on save/update product, the custom status is simply not stored.

I do not think sharing a premium plugin for free is a reasonable approach. I think you would also not welcome if users would share your premium paid plugins for free. For such request it should be in the interest of the plugin developer to reach out to each other to solve such issues directly.

This should be especially important if an issue occurs between a third party plugin and an officially supported plugin (with thousands of users) by WooCommerce creators themselves.

However I was able to get a statement from Composite/Bundle plugin creator to shed some light on this issue.

//QUOTE//
WooCommerce does not natively support custom stock statuses: The only way to support custom statuses or availability strings like the “Insufficient Stock” availability displayed in Product Bundles is to filter the availability strings. Since there is no native infrastructure for custom stock statuses in core, any plugin author who attempts to do so is willingly taking a risk.

Product Bundles would require some special handling to work with any plugin that follows this approach, because the parent product manages inventory for the “bundling process” while at the same time being limited by bundled item constraints. As an example, if you are assembling PCs, you might want to limit the number of PCs that can be assembled per day to less than 10, even when all parts have enough stock. And the opposite: If a part does not have enough stock, or is on backorder, the entire container should inherit this status.

For this reason, Product Bundles override a core method and use a dedicated filter for those “special states”: https://a.cl.ly/p9u7AY4q — You could pass this information on to the author of the Custom Stock Status plugin you are using. Composite Products is not doing anything similar though, so it seems that the plugin you are using may have trouble with custom product types?

Note that the technical barrier associated with plugin compatibility issues like this can’t always be overcome in a timely/feasible/sustainable manner. A decision to introduce compatibility between two plugins often requires:

– opening a channel of communication between the two sides,
– writing code on both sides;
– maintaining a close relationship to ensure the two plugins will work together in the foreseeable future.

//UNQUOTE//