Bug in EU Advanced Compliance with shipping taxes?



  • Hi,
    Could someone else please check that when enabled the EU Advanced Compliance module takes the shipping price and adds VAT on top of it? This is surprising for me and I don’t know whether it’s intended or not. I would expect the module to take the shipping price entered at the carrier as gross, i.e. including taxes, and not net. What would you expect?



  • It’s indeed intention! With enabled AEUC you have to be aware that shipping costs will be treated as tax included. But I can confirm this, tb treats the tax as net and adds the tax to shipping costs in checkout, really confusing. This is a bug!



  • Thanks, @Occam! That means that if I have “Proportionate tax for shipping and wrapping” enabled the shipping rate will change dependent on the contents of the cart? Is there any way to fix this? That’s really a big bug - we need to tell our customers in advance what the shipping rate is, but we can’t if it’s dynamic.



  • Yep, I guess @mdekker just wasn’t aware that AEUC treats the entered shipping fee as tax included. Which means, the calculation algorithm for the proportionate tax has to be slightly reworked.





  • You can find the bug in function getPackageShippingCost of class Cart.php
    It starts absolutely right from line 1882:

           if (Configuration::get('PS_ATCP_SHIPWRAP')) {
                // With PS_ATCP_SHIPWRAP, pre-tax price is deduced
                // from post tax price, so no $carrier_tax here
                // even though it sounds weird.
                $carrierTax = 0;
                (...)
    

    But it ends wrong from line 2003 on, because with AEUC option enabled the tax is added to the shipping costs and not deducted from this figure which would be correct:

        if (Configuration::get('PS_ATCP_SHIPWRAP')) {
            if ($useTax) {
                // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping
                // costs. This is on purpose and required in many countries in the European Union.
                $shippingCost *= (1 + $this->getAverageProductsTaxRate());
            }
    

    A workaround is quite simple. Just deactivate line 2007

        if (Configuration::get('PS_ATCP_SHIPWRAP')) {
            if ($useTax) {
                // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping
                // costs. This is on purpose and required in many countries in the European Union.
                //$shippingCost *= (1 + $this->getAverageProductsTaxRate());
            }

  • administrators

    I thought it was not that easy. I saw problems with discounts, invoice generation and some price displays after using that code. Part of the reason is, the source (prices from the carrier wizard) is internally being hacked to have a different price than chosen by the merchant. Other systems/parts of the software do not take this into account and cause random errors.

    The whole cart was designed to add taxes to all the inputted prices by default, so we might have to change this at a lower level (e.g. the Carrier class).


  • administrators

    Could you also point me at the legislation that states that this is not legal? AFAIK showing the prices in the cart dropdown should be “in advance” enough.



  • @mdekker I think generally you’re right, though in Germany the legal opinion is divided whether displaying the shipping costs directly before the “Buy now” step is enough or whether you need to show them also before.

    However, something else to take into consideration is that the link “Shipping excluded” (which should be changed to “plus shipping”) next to the price on the product page leads to the shipping cost overview page. I don’t think listing net shipping costs and explaining that the total will depend on a proportionate calculation makes sense.


  • administrators

    Yeah, we are convinced of the need to be able to define the shipping fees incl. taxes. We are working on adding that as well, but it will require more changes than shown above. You can of course apply the changes for now if you want that feature (thanks Rainer!), but be aware that cart rules and invoices might break.



  • @30knees said in Bug in EU Advanced Compliance with shipping taxes?:

    @mdekker I think generally you’re right, though in Germany the legal opinion is divided whether displaying the shipping costs directly before the “Buy now” step is enough or whether you need to show them also before.

    However, something else to take into consideration is that the link “Shipping excluded” (which should be changed to “plus shipping”) next to the price on the product page leads to the shipping cost overview page. I don’t think listing net shipping costs and explaining that the total will depend on a proportionate calculation makes sense.

    At least in Germany in my opinion it should be ok when you show the exact shipping costs during the checkout process, because AEUC provides the link to shipping costs near every product price.
    You can avoid this irritating “free shipping” in the cart (as long as the shipping costs can not be calculated) by adding a boolean condition to hide this display when $is_logged is not true.

    @mdekker There seems to be another bug in the proportianate taxes for shipping. If you have mixed taxes in the order and the quantity of products with the lower amount is greater than 1 the proportionate tax on shipping is the same as for the other tax rate, but negative.
    And btw there are problems with the invoice, too:

    1. If you entered a base price for at least one of the products, instead of tax label/tax rates the base price is shown. But this should not be considered as alternative.

      {if isset($layout.before_discount)}
      	<th class="product header small" width="{$layout.unit_price_tax_excl.width}%">{l s='Base price' pdf='true'} <br /> {l s='(Tax excl.)' pdf='true'}</th>
      {/if}
      
    2. The variable $order_detail.total_price_tax_excl_including_ecotax contains the same as $order_detail.unit_price_tax_excl_before_specific_price. It’s not the total amount!


  • administrators

    Good bug hunting! But have you tried the default invoice templates? I didn’t notice.



  • Yep, just the default one.



  • Is there a way to give eg Shipping costs a fixed tax rate regardless of the shopping cart contents until the bugs have been fixed? Ideally, the carrier prices would then always be incl. taxes of X%.



  • Yes, but it’s not an easy way. Or use a module like Presta plus. Not really cheap, but solid in programming and very useful. Works with thirty bees.



  • @occam I’m revisiting this now because I’m testing the checkout flow prior to launching the shop with thirty bees. Does the Presta plus module solve all the issues of this thread? If so, I’d get it to move on with the shop.



  • @30knees Technically yes, it should solve the bug. But as long as TB ignores overrides in this place, the clear answer is NO. It works fine with PrestaShop, but not with TB.
    Btw some of the additional features of PrestaPlus like individual delivery times (in stock and OOS) for every single product were implemented into PS 1.7 core last week.


Log in to reply
 

Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.