30knees

One of the changes brought about the Omnibus Directive (only relevant for European traders) is about the display of price reductions in stores. The provision will become applicable 28 May 2022. It's still a while to go, but I thought it would make sense to already have it in mind for future tb development:

Indeed, thank you. I guess she just must not have noticed it. Very odd. Thanks!

I just spent a while on the phone with a customer who mistakenly put the zip code in the city field and vice versa (as is the common order in Germany). She didn't spot the mistake right away. Would it be possible to highlight the fields that are wrong?

Could you share more information how you discovered this?

That reminds me of a feature an old software I used had. When switching order status, for one or multiple orders, you could send along a message to each order individually. I used that for messages like: "It's Friday - have a great weekend", "Did you see the football game yesterday? Amazing!". "Happy Easter!" etc. It added a personal touch that customers really appreciated. Would this be easily possible in tb? Would anybody else be interested in funding this?

Thanks, they fixed everything and now it's working well. Your suggestion put them right on track! Hurray for datakick, so nice you're on board. 🙂

And the new 4.2.1 incorporates datakick's fix. 🙂

I think your calculation is wrong 🙂 https://www.mehrwertsteuerrechner.de/ You can enter 13% and check. 🙂 It's 17.70.

It was thinking more that emails might be blocked by the server administrator, if that's possible in your case.

Might there be some type of permission, whitelist, etc you have to set on your server? I had that once.

Here it : https://github.com/vblanch/cryptocurrency_ps_module The underscores made the ps into italics and messed up the URL. 🙂 Would you mind sharing how your attempts at a new module go? Coingate is such an idiotic company I'd also prefer to go a different route. But they have so many different currencies. Lots of potential there.

I just noticed that now after reinstalling the module it's no longer hooked in displayPaymentEU. Why can't I transplant it in 'positions'? The module references displayPaymentEU in line 172 https://github.com/coingate/prestashop-plugin/blob/master/modules/coingate/coingate.php

Nope, I disabled megamenu and the payment method still doesn't show in the checkout. It did originally show - just during one of the updates it stopped showing.

Somehow I missed this earlier. Sorry! I uninstalled the app and reinstalled it (all via the backend). I had to re-enter the API settings, but it didn't change that the module still isn't being shown, unfortunately. It did fix the consistency check error, though!

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.