Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


Popular Content

Showing content with the highest reputation on 01/10/2021 in all areas

  1. 1 point
    This seemed to be also an issue that can occur due to the use of a low PHP version. For example update PHP 7.2 to 7.4.
  2. 1 point
    I thought I'd share a summary I wrote for datakick of this problem, as I believe it affects all EU countries and the UK and means thirtybees isn't 'fully compliant' in a sense: In sum there are two elements that work together to create non-compliance: 1) the tax element, 2) the consumer information element. Regarding 1) the tax element If you sell two products, one at a VAT rate of 10% and one at a VAT rate of 5%, and you charge for shipping, the VAT rate for the shipping (which is a separate service to the sale of goods) is dependent on the basket of products sold. There are two ways the shipping VAT may be calculated: a) Proportionally according to the VAT proportion in the basket. Product A costs 32.66 net / 34.95 brutto with 7% VAT. Product B costs 2.50 net / 2.98 brutto with 19% VAT. --> Shipping costs 4.95 brutto with proportional VAT. Product A represents 92.98% and Product B 7.11% of the net total. So the VAT of the shipping costs should be proportionately split: 92.14% of 4.95 = 4.56. This means 4.56 brutto are taxed with 7%, which gives us 4.26 net + 0.30 VAT (7%) = 4.56 brutto shipping 7.86% of 4.95 = 0.39. This means 0.39 brutto are taxed with 19%, which gives us 0.33 net + 0.06 VAT (19%) = 0.39 brutto shipping Net shipping costs: 4.95 brutto - 0.30 VAT - 0.06 - VAT = 4.59 net b) According to the higher value VAT rate in the basket. Product A costs 32.66 net / 34.95 brutto with 7% VAT. Product B costs 2.50 net / 2.98 brutto with 19% VAT. --> Shipping costs 4.95 brutto with 7% VAT. This is because Product A is more than 50% of the total. Regarding 2) the consumer information element The consumer needs to know the brutto shipping costs upfront. Currently, with tb, the customer can only know the net shipping costs upfront because the variable brutto is calculated from the fixed net unlike in the example above where the variable net is calculated from the fixed brutto. Sources for tax element Looking for material in English I found out that this requirement actually is European-wide one. It follows from a Court of Justice of the European Union case and a VAT directive. It's just that some countries (tax authorities) implement it stricter than others. Here is something in English: https://en.blog.taxdoo.com/umsatzsteuer-versandkosten-nebenleistungen/ Sources for information element https://europa.eu/youreurope/citizens/consumers/shopping/shipping-delivery/index_en.htm#shortcut-1 Total price is understood to be incl. taxes. But even if you argue and say that the customer sees the total shipping costs in the checkout before clicking buy, it's just not user friendly to have in the shipping costs FAQ part of your shop: Your shipping costs are 4.50 excluding tax - the exact amount including tax depends on your purchase, as the taxes depend on what you buy. 🙂
  3. 1 point
    The code is perfectly fine, there's nothing wrong here. It just adds additional table to the query that fetches orders. The problem is that your database select bad plan to execute this query. The solution is to help the database -- create index that it can use to optimally retrieve data. Something like this: CREATE INDEX mp_order_reference ON tb_mollie_payments(order_reference); With such index the query will run much faster, probably
  • Create New...