Occam
-
Posts
303 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by Occam
-
-
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.)
-
-
9 hours ago, timHa said:
Germany has a law for many things but I don't know one either for this issue.
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.
-
7 hours ago, nickz said:
Das bringt höchst selten etwas. Welcher Engländer kauft bei einem Shop der in D sitzt oder Vice versa?
Besser sie zu trennen und für die Englische Seite eine LTD nehmen.
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
-
-
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_)...
-
1
-
-
1 hour ago, 30knees said:
Would you mind commenting whether this configuration is correct:
1. Disable AEUC. YES, otherwise you cannot disable the tax rate
2. Set tax rate for shipping. NO, delete it.
3. Add shipping rate.NO
4. Enable AEUC. YES
5. Activate proportional calculation. YES
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.
-
1
-
-
On 6/26/2020 at 12:47 PM, Traumflug said:
Das ist kein Fehler, sondern völlig richtig so.
Da braucht man auch nichts "reaktivieren". Steigt die Mehrwertsteuer wieder, wird der Steuersatz erneut kopiert, alles ist prima. Keinerlei Grund, in der Datenbank herum zu fummeln.
Du hast völlig recht. Ich hatte übersehen, dass sich nicht nur der Feldinhalt, sondern auch die ID geändert hat.
-
On 6/23/2020 at 12:46 AM, Traumflug said:
Ich habe jetzt auch mal ein wenig probiert.
Wenn man einen bestehenden Mehrwertsteuersatz ändert, wird da nicht einfach die Prozentzahl geändert, sondern es wird eine Kopie mit dem neuen Satz angelegt. Das heisst, die alten Rechnungen und Bestellungen behalten den vorherigen Steuersatz, die im Shop angezeigten Preise ändern sich. Entsprechend rutscht der Steuersatz auch in der Liste ganz nach hinten, falls den jemand nach der Änderung vermisst.
Ja und Nein. Hier ist der gleiche Fehler drin wie auch in PrestaShop 1.6. Es wird zwar ein neuer Datensatz angelegt, aber der alte verschwindet ganz, weil er in der Datenbank als deleted geflagt wird, aber noch aktiv ist. Er lässt sich aber übers Back Office nicht mehr reaktivieren, sondern nur durch Eingriff in die Datenbank selbst.
Und ganz übel wird die MwSt-Umstellung, wenn man Varianten und Grundpreisangaben hat. Der "floating"-Grundpreis wird völlig unverständlich. Bevor du dich vorzeitig über die zugegeben nicht immer glückliche Diskussion im Prestaforum mokierst, solltest du dich vielleicht selbst mal auf Fehlersuche begeben. Wenn es wenigstens wieder so klappen würde wie in PrestaShop 1.5, so wäre das schon ein Riesenvorteil. Näheres s. im Bitrag eines Users im besagten Topic: https://forum.thirtybees.com/topic/4197-mehrwertsteuer-umstellung/?do=findComment&comment=36241
-
Did you recompile the theme afterwards?
-
On 4/13/2020 at 1:39 PM, datakick said:
Lately I was feeling like I was the only one pushing this project forward.
I believe this is exactly what happened in actual practice. You've really spent a lot of time on this, and you've pushed this project a huge step forward. Your decision has my utmost respect and is also very reasonable for me. This said, I'm afraid this is just another step towards the burial of tb. And I really hope I'm wrong.
-
Maybe it helps to rename all instances of $dir to $dirX.
-
2 hours ago, datakick said:
Oh, but there were no demands on third party developers.
😊 You don't have to, this wasn't meant personally.
2 hours ago, toplakd said:Regarding prestashop making demands, i'm pretty sure they don't demand anything, if developer does not update his module, it will just not work on updated version as it should.
Yep, and this means the developer will loose money if he or she doesn't adapt his module. But what does he loose when he refuses to adapt his module to thirty bees?
2 hours ago, toplakd said:Also Panda does not state that Bleeding edge is compatible with their theme
But Bleeding Edge states that Panda isn't compatible.
However, Sunnytoo's Transformer theme works properly with thirty bees 1.1.1.
EDIT: Sorry, obviously it wasn't the current release of bleeding edge. After running the Core Updater Transformer stopped working, too. You have to manually reset each and every module though all are displayed as active in the back office. Is this what compatibility and being free of bugs looks like? It is not sufficient if just the two custom templates are working properly!
-
On 3/4/2020 at 5:00 PM, datakick said:
Without it, I assume the problem is in third party module(s) itself.
All this may be true, but your argument still doesn't work. If thirty bees were a widespread and correspondingly potent shop system, you could require third party modules and themes to be adapted by their developers to each new version. But this is not the case. If users report that cache still worked with 1.1.0, but not with 1.1.1, then it may of course be due to the programming of the panda theme and its modules. Maybe you are right. I guess you are.
But that won't help you. thirty bees is not in the position to impose conditions on third parties. Instead, in order to survive and secure some small market shares, thirty bees must guarantee full compatibility - and not the other way around. Almost nobody develops themes or modules specifically for thirty bees, and this is the big difference to Prestashop. They can afford to make such demands. I'm afraid, you cannot.-
1
-
-
14 hours ago, Traumflug said:
Well, "Number of decimals" rounds to the given decimals, but also doesn't display additional ones.
This is not what a shop system should do. However, I guess you can use a Smarty statement In the product.tpl to format the price:
{$price|string_format:"%.2f"}
Or use number_format
{$price|number_format:2} will output 10,00 (EU standards) {$price|number_format:2:",":"."} will output 10.00 (US standards)
-
1 hour ago, led24ee said:
Could this this error message help solve the problem ?
Definitely not! It's not an error, just a warning of PHP 7, only displayed in debug mode. To avoid this you can change those issues for PHP 7.0 to 7.2 to:
if (is_array($thisvariable) || $thisvariable instanceof Countable)
or
is_array($thisvariable) && count($thisvariable)
If your server uses a newer PHP release like PHP 7.3, change the statement count() just to is_countable().
-
That's not something you need to apologize for, though. Your own health should always be given priority over professional goals and entrepreneurial visions. I wish you strength and all the best for your surgery and your hopefully well recovery. God bless you.
-
1
-
-
On 12/30/2019 at 3:34 PM, Briljander said:
Doesn't seem so.
For those interested, here is Prestashops thoughts about he future:
https://build.prestashop.com/news/prestashop-in-2019-and-beyond-part-3-the-future-architecture/
You mean this chief programmer, whose visions of a tabula rasa in strange denial of reality are based on the assumption that hundreds of IT companies or freelancers who develop modules or themes for Prestashop will enthusiastically change their developments completely and follow their new leader unconditionally. Dream on!
This is what the real world looks like when you don't view it from the Prestashop ivory tower:
QuoteAlmost all official modules are written by people who do not use Prestashop guidelines.. UPS, DHL, Paypal. All those try hard to use their frameworks instead of Prestashop ones.
(https://gitter.im/PrestaShop/General?at=5df21d010616d6515e268af9)
What we see currently, after more than 4 years of new development, is clumsy, split into thousands and thousands of files, more confusing than ever and constantly generating new problems and bugs. Borowicz himself does not dare to predict when the development will come to an end. And if he doesn't leave Prestashop prematurely like all his predecessors, the last annoyed user will probably have turned to a different shop system before the visions could be realized.
My goodness, this is a shop software and not an isolated special design to control the next Mars expedition.-
2
-
Zustellungsprobleme für Emails via Shared-IP an T-Online
in Deutsches Forum - Generelle Fragen
Posted
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: