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.

30knees

Members
  • Content Count

    948
  • Joined

  • Last visited

  • Days Won

    7

30knees last won the day on January 10

30knees had the most liked content!

Community Reputation

108 Excellent

About 30knees

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good thinking! It shows: Module coingate registered hook displayPaymentEU but does not implement hook handler It also shows this for a bunch of other modules. The 'auto fix' is to delete the module hook from the database. Should I do that, ie will it automatically reregister the hook after that?
  2. Have you checked whether states are required for the country you're shipping to and disabling the requirement?
  3. I'm wondering what retail sectors / industries we all represent here. I think that would be helpful for the new thirtybees team to know. But also for us merchants to get together and perhaps crowdfund modules, etc. If your sector isn't listed, please post and I will add the sector to the poll. DON'T vote before I add your sector. You won't be able to vote again.
  4. Is there anything obvious to check if a payment module isn't showing up in the checkout, especially after one of the latest bleeding edge updates? I don't think it's the hooks. They're set like this:
  5. I am looking for someone to help fix this problem: The fix is to use the relevant code in the old PS classes/cart.php in the new classes/cart.php, see below post. However, that will also require to find all the usages of this particular cart code. Every code that calls Cart.php in order to determine price needs to be re-evaluated and potentially fixed. Ideally, this would be done under the guidance of @datakickand @Smileand flow into the core.
  6. Mollie replied, there already is an index. So it must be something else. Anyways, thanks for your help! It's so weird that that the page takes a couple of seconds to load, also when filtering by status. Only after the first load does it load quickly for a while.
  7. 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. 🙂
  8. Super, thanks! I shared that with Mollie and asked where I'd put it. I'll share the answer here, as I know some other users also use Mollie.
  9. The latest Mollie payment module for PS 1.6 makes orders.php load very slowly. Someone reported a similar problem with PS 1.7 and the Mollie module. He wrote: If I found the right code section in the Mollie module in this file https://github.com/mollie/PrestaShop/blob/master/mollie.php this is what the code looks like. Does anyone see at a quick glance what the problem might be / how to edit it? public function hookActionAdminOrdersListingFieldsModifier($params) { if (isset($params['select'])) { $params['select'] = rtrim($params['select'], ' ,') . ' ,mol.`transaction_id`'; } if (isset($params['join'])) { $params['join'] .= ' LEFT JOIN `' . _DB_PREFIX_ . 'mollie_payments` mol ON mol.`order_reference` = a.`reference`'; } $params['fields']['order_id'] = [ 'title' => $this->l('Resend payment link'), 'align' => 'text-center', 'class' => 'fixed-width-xs', 'orderby' => false, 'search' => false, 'remove_onclick' => true, 'callback_object' => 'mollie', 'callback' => 'resendOrderPaymentLink' ]; }
  10. An update Reverting to PS 1.6 cart.php leads to errors elsewhere, eg a wrong shipping price is displayed during the checkout. So one would need to audit the whole code and it's not clear how much effort that would take. Unfortunately, this means that invoices with products that have mixed tax rates will remain non-compliant in Germany. Or you have compliant invoices but you can't tell the customer the gross shipping price in advance because the shipping price is calculated based on the net price and the 'proportional taxes' depend on the exact mix of tax rates resulting from the products in the shopping cart.
  11. Gladly. What part do you need to know more about?
  12. I am sorry to see you go, @wakabayashi, but I understand disappointment with the announcement post lacking a plan etc. You have been a pillar in the community and it's a pity your ideas and suggestions weren't appreciated more. I hope the “50$ VIP Club” will be picked up. I think it's a good idea to get to have a say in the development of the platform. Either way: Thank you for all you've done and all the best for your shop!
×
×
  • Create New...