Occam

Ich glaube, die verlinkte Info hast Du nicht richtig verstanden. Natürlich akzeptiert T-Online wie bisher auch Mails von shared IP-Domains, vorausgesetzt, der Provider hat die Domain-Authentifizierung für Deine Domain(s) korrekt konfiguriert. Mit den Google-Tools lässt sich herausfinden, ob ein SPF-Eintrag gesetzt ist. Falls nicht, hilft Dir vielleicht der folgende Beitrag: https://powerdmarc.com/de/how-to-create-an-spf-txt-record/ Oder Du fragst bei Deinem Provider nach, ob der Kundenservice das für Dich erledigt. Hab ich z.B. bei ESTUGO so gemacht und bekam folgende Antwort:

Sorry, done with that. It was just an old override to extend the display that I had not yet customized. Thanks for your hint.

The order list is displayed corrupted. I suspect a Java script error. Maybe this is due to the fact that I use PHP 7.4. I'm not able to switch back to a previous PHP version. (And please, answers like "Change your provider" are not helpful in this case.)

Versuch's mal hier: https://forum.thirtybees.com/topic/3736-tls-v12-is-not-supported-message/?tab=comments#comment-32687

I wouldn't agree. For all items that have length or volume measurements, a base price must be specified. This applies not only to Germany, but is legally required throughout the EU. Not necessarily in the product list or cart, but in product details.

Aber eigentlich sollte das Standard sein. Ich habe im Laufe der Jahre schon in PS immer mal wieder solche Erweiterungen eingebaut, entweder nur für 's BO, oder auch für die Anzeige im Template. Was z.B. in TB immer noch fehlt, obwohl inzwischen zumindest in PS 1.7 enthalten (wenn auch dort nicht richtig logisch durchdacht), sind individuelle Verfügbarkeits- und Lieferzeiten je Artikel. Dabei ist das wirklich nicht schwer zu realisieren, bedarf allerdings auch neuer Datenbankfelder.

I completely disagree with you on that. Because for us, it's customers from the Netherlands, from Italy, Spain and other EU countries, or even Japan or the USA, who use the English-language site. GB no longer plays a role since Brexit anyway. We have also canceled all suppliers from GB. It has simply become far too inconvenient and too expensive. Das mit der Übersetzung für das Feld Unit im BO ist schon ein bisschen komplizierter, denn es ist wie bei PS auch ein reines Textfeld. Das bedeutet, sowohl die Datenbanktabelle muss erweitert werden als auch der entsprechende Controller und das Template. Nemo hat, wenn ich das richtig verstehe, hier eine Lösung angeboten: http://nemops.com/prestashop-thirtybees-multi-language-product-fields/#.YZYQrKK1I1I Ausprobiert habe ich es zwar nicht, sollte aber funktionieren.

... and hope that your Prestashop theme is compatible with TB, which from my experience is rarely the case, even if it may work on the whole.

1) It makes no sense to open several topics for the same problem. 2) From your example it is not clear how much the gross amount of the shipping costs actually is. Or did you mean shipping costs tax incl. when you wrote "Gross tax is set at 4.80"? If so, the problem can be identified as a bug in tb's AEUC, because though the taxes are correctly calculated, they are computed not from the net shipping amount (4.25), but from the shipping price incl. taxes (4.80)! This bug is not new, but still unsolved. I totally forgot that this was the reason why I use my own modified AEUC in tb. Works properly without any changes in classes like Cart.php.

Of course! German invoice with mixed taxes: RE000019.pdf And please, don't try to "approve" the Cart.php. Leave the code (where it deals with AEUC) like this: 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(); } } else { // Apply tax if ($useTax && isset($carrierTax)) { $shippingCost *= 1 + ($carrierTax / 100); } } $shippingCost = round($shippingCost, _TB_PRICE_DATABASE_PRECISION_); Cache::store($cacheId, $shippingCost); return $shippingCost;

Nope, no shipping rate, just the shipping costs! Otherwise the proportional calculation wouldn't make sense.

There's a bracket missing: ... = .... get_contents_dirname(_FILE_)...

Seems to me that it was a misconfiguration. Never set a shipping tax rate when you use AEUC (hopefully my own modified release)

I wouldn't agree, because I cannot reproduce the behavior you were talking of at Github. My fix there from 2017 is currently implemented in a slightly different way to tb so that the workaround I posted is obsolete and outdated now. 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(); } } else { // Apply tax if ($useTax && isset($carrierTax)) { $shippingCost *= 1 + ($carrierTax / 100); } } In my release issue-905 from Bleeding Edge it's line 2138-2149 in /classes/Cart.php. I tested it with both the standard invoice and my own invoice (adapted to tb). Each and every figure is correct. Works fine. I guess there's else something causing your problems, provided that everything configured is properly.

Du hast völlig recht. Ich hatte übersehen, dass sich nicht nur der Feldinhalt, sondern auch die ID geändert hat.