30knees

What datakick suggested here:

Yes, it is. Also for countries and carriers.

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?

Bump. 🙂

Have you checked whether states are required for the country you're shipping to and disabling the requirement?

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.

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:

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.

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.

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. 🙂

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.

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' ]; }

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.

Gladly. What part do you need to know more about?

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!

Thank you, @Smile. It's great that @datakickis on board. I sincerely wish that everything works out nicely! Looking forward to more information and a roadmap soon. I guess you've had quite some time to think about all that already. 🙂 Do you know when you'll have all this information ready to present? I think if you want to get people to support thirtybees, it would be important to have this information out there as soon as you can and not wait until the end of February.

tb can look beautiful! You just need someone good to work on it. 🙂

I think the problem staying with tb or PS 1.6 is that oftentimes modules for third party services need to be updated or they stop working and that more and more developers are dropping PS 1.6 support. p.s. modified shop is the stupid name of a decent system: https://www.modified-shop.org/ It's not a modified version of tb. 🙂

Reading the future of thirtybees thread, it looks like quite a few merchants are thinking about alternatives should the handover not workout. Which shop system would you switch to if thirtybees isn't continued? I'd probably switch to PS 1.7, simply because it's the easiest to switch to. JTL Shop or Shopware would be interesting, too. EDIT: modified shop is the stupid name of a decent system: https://www.modified-shop.org/ It's not a modified version of tb. 🙂

My opinion hasn't changed since then. I'm undecided. I like thirtybees and I like the community. But I am concerned about the viability of the project longterm because of recent experiences, such as people not responding to direct messages even after having 'engaged' their paid services (though I give them the benefit of the doubt that it's because they're overworked), or replying by primarily complaining about other forum members instead of going into the substance of the issue. At this stage, I need to invest in certain modules that are outdated and no longer work with the third-party services they connect to. Being left in the dark about thirtybees, it seems like it would make more sense to switch eg to PS 1.7 and get the modules for that platform. I did the crowdfunding early on and never 'used' any of the benefits. I donated once when I felt that the crowdfunding amount was 'used up'. That was shortly before the project was officially put on hold. Since then, I've been holding my breath. I'll wait until the end of the year, even though it's bothersome because of the new modules. Ideally, I'd have gotten them already early December. My decision will depend on the statement made by the new team, be it a fork or thirtybees. Either way, I'm grateful for thirtybees.

I'd like to add a tracking code / paramater to URLs eg ?fromForum123 so that I place somewhere so I can see the conversions. Currently, the ways I see to do this would be: to use an affiliate / referral module and misuse that for this purpose. setup Matomo or similar. Is this correct or might there be another way? Thank you.

Thank you, @Traumflug. But what is the behavior shown on PS 1.6 cart.php if not what I’m looking for? I’d be happy for an explanation instead of a dismissal. 🙂

Thank you for the (fun) reply. 🙂 I’m having trouble finding someone who would take the paid time to properly transpose the proper element from the PS cart.php to the tb cart.php. It’s an important element for me - more than just a ‘check engine light’. 😅

1. Agree with you - but I think they're separate issues (apart from the German language post), ie can I simply swap the cart.php files? 2. True, I meant gross shipping costs. I updated to clarify that. Thank you for the pointer. I'm not sure it's a bug in tb's AEUC, though. With PS cart.php everything works. In my opinion, this is OK. The customer should know the gross shipping cost in advance, i.e. 4.80. The taxes for the shipping cost will depend on what's in the shopping cart. The display of the net or gross shipping price in the invoice is a different matter. Mind sharing?

Die Lösung: