Occam

It's not working this simple. There is no array footer available in this tpl. Why don't you just use this invoice: https://forum.thirtybees.com/topic/1817-1817/pdf-invoice-eleazar/?tab=comments#comment-18971

Nein, das wirst du auch nicht. Es geht bei Nutzung des Niara-Themes einfacher, wenn du direkt AEUC anpasst. Dann kannst du sogar zwei Fliegen mit einer Klappe schlagen, weil der Kunde nicht mal mehr klicken muss. Öffne die Datei modules/advancedeucompliance/views/templates/hook/hookOverrideTOSDisplay.tpl Ändere Zeile 33 von <input type="checkbox" name="cgv" id="cgv" value="1" {if isset($checkedTOS) && $checkedTOS}checked="checked"{/if}/> zu <input type="checkbox" name="cgv" id="cgv" value="1" checked="checked"/> Anschließend in den AEUC-Moduleinstellungen nochmal den rechtsicheren Checkout speichern, weil thirty bees 1.1.0 etwas träge ist mit dem Aktualisieren. Das war's auch schon.

Das Hauptproblem scheint einfach die Inkompatibilität des Niara-Themes mit dem Modul Europäische Rechtssicherheit (AdvancedEUCompliance) zu sein. Möglicherweise liegt es aber auch an thirty bees 1.1.0. The main problem seems to be simply the incompatibility of the Niara theme with the AdvancedEUCompliance module. However, it may also be related to thirty bees 1.1.0. 1. thirty bees 1.1.0 without AEUC. Checkbox is visible (though without a headline): 2. thirty bees 1.1.0 with activated AEUC. Checkbox has vanished (but the headline reappears): 3. thirty bees 1.1.0 with activated AEUC and a compliant theme (Transformer). Checkbox is visible:

[FUD removed]

@Landmücke Und jetzt noch mal bitte auf Deutsch, denn - sei mir nicht böse - ich habe absolut nicht verstanden, worum es dir genau geht.

??? Whatever this means, in my view neither a checkbox (not legally required) nor this shifting makes any sense. A text field with links to terms of trade and privacy policy would be sufficient and much easier to handle.

Ik ben bang dat ik het daar niet mee eens ben, want dat is niet waar. Met een paar kleine aanpassingen kon Transformer worden aangepast naar dertig bijen 1.0.8. Voor 1.1.0, althans voor de ontwikkelaarsversie, zijn geen verdere wijzigingen nodig. Het enige probleem met 1.1.0 is dat de modules één keer handmatig moeten worden geactiveerd of gereset om de frontend te laten werken.

So at the moment, no theme, not even the Niara theme that comes with tb by default, meets the strict criteria? Not to mention the following warning concerning the Niara theme: Warning: Theme installed or enabled following modules but didn't provide hook list for them. Theme should always provide list of displayable hooks for managed modules in order to achieve consistent results. If no hooks are specified in config.xml file, module hook list will remain unchanged. If this is wanted behaviour, theme developer should make it explicit by adding manageHooks="false" into module entry Please contact theme developer and request correction of theme config.xml file Are you serious?

I'm afraid, that this does not solve the problem of theme incompatibilty with thirty bees. It is just more puzzling for merchants, incl. those (which are legion!) who don't even know what a hook is. And the results in the frontend are poor. You still need to reset most of the active modules to make the theme work properly. Non-experts would not understand that and instead complain about bugs or lack of compatibility. Hence my question again: Does thirty bees really have the market power to dictate to theme (and module) developers how to write their software? Or is this puristic approach (however justified it may be) the direct path to meaninglessness at the time being? After all, it's by no means a situation where developers are rushing to create special adaptations for thirty bees. Just for the record: if you were a merchant, you would have other burdens and would understand such challenges only as an imposition. A merchant does not want to have to care about the software. He just wants it to work for him. He is neither interested in hooks nor in disputes with a theme developer who would definitely only answer that thirty bees causes these problems because they do not occur with PrestaShop. Just my 2 cents ....

I checked it. Currently 88% of thirty bees is translated into Spanish, which means that a few thousand of items are still displayed in English. But this does not apply to the examples you gave. The sort order is completely translated. Labels like Sale or New may have to be translated in the module's section, too. The translation for the availability label, however, has to be translated for each product separately in the products section of the BO, tab Quantity. If you have many products the only way to simplify this would be a change via SQL command or the use of @musicmaster's Prestools for a global change. Currently the handling of 3rd party themes like yours is buggy. So I'd suggest to automatically import the Spanish language in locations --> translations into all themes. And to avoid the behavior you described, you should always make a backup copy of the folder themes --> <your theme> --> lang, or at least the es.php file you find there, after your own translations. Until the bugs are fixed, it is recommended to always upload this updated version to the themes default-bootstrap and Niara.

Problem is that currently just 4 languages are nearly full translated (German, Italian, Slovenian and Russian), followed by Dutch, Hebrew, Portuguese and Spanish. What is your language, and which items did you translate and were afterwards displayed in English again? You should know that custom translations for mails and modules are stored to the theme directory, not to the original files.

Trust me, I am fully aware of this difference. My choice of words was just a little exaggerated. But I have moderated the Prestashop forum long enough to know what interests the average user. He doesn't want to know how or why, he only cares that it runs out of the box without much effort.

From the programmer's point of view, this all sounds plausible and logical. For a merchant, however, only usability in practice counts. So if a lot of 3rd party themes can be installed in PrestaShop without any problems and this doesn't work in a small niche product like thrity bees, they will probably blame it on thirty bees and orientate themselves otherwise. Thirty bees just isn't big enough to tell third parties how to develop their products. And this argument doesn't help either: Therefore I strongly endorse your proposal not be so eager to enforce these API contracts and to be content for the time being with a warning notice. Because this is not about the beauty of the PHP code but only about the practicality and compatibility of the software. @Traumflug may disagree, but I doubt that Thirty bees will be able to hold its own on the market in the long term with such an absolute claim. That would probably be the best way to scare the potential users away. Because the competing shop ssystems can do it without such detours.

That's what I expected. But you must know that the configuration file of Panda and Transformer only forces the installation of the modules, not the activation. If you change the configuration file and add the module activations command to this file, thirty bees will display the modules as activated, but will further ignore the activation. The only way is either to deactivate and then activate every single module or to reset them one by one.

I am not sure if this only applies to Transformer; actually, I don't think so. Sunnytoo themes came along with own modules that sometimes replace the default ones. Sure they do, that's what I said. You missed the point. After the update my theme worked. But when I switch to one of the default themes and then switch back to Transformer, then there is the trouble I spoke off.

For me it is one of the most annoying "improvements" of 1.1.0 that 3rd party themes can only be installed very complicated. The switch from Niara to the default bootstrap and back succeeds without problems. But in order to install a theme from Sunnytoo, for example, you have to activate every single theme module after the installation. Now you may of course consider setting the installed custom modules to "enabled " in the theme's config.xml. This is not enough for thirty bees: They will then be activated, but still not displayed in the frontend, no matter if you clear cache or recompile the theme. You need to reset each and every module to make this work. This is very confusing for the normal user, because after changing the theme you see only a white page with logo in the frontend - without error message! Because thirty bees does not detect this bug as an error. In my opinion, this bug of 1.1.0 should be fixed as soon as possible, because it severely restricts compatibility. I'm not sure if it's just the strongly decimated AdminThemeController, probably there are also other changes involved. In 1.0.8 it definitely worked. (Tested with a Sunnytoo Transformer theme adapted to thirty bees.)

Yep, I must have been blind. Thank you very much. Works perfect now:

Better, but still not a perfect solution. Because the tax totals are displayed even for items that were not refunded. E.g. you refund the shipping costs and not the products, then both tax details are displayed istead of only the tax details of the shipping costs. And vice versa, I suppose. To avoid this you can use the fix I already posted on Septembre, 6. I removed this fix after severe critics by moderator @wakabayashi. Here is the zip for download again: Fix Bug Order Slip.zip And according to my logical understanding, the minus signs are superfluous, because this is always a positive amount that the customer gets refunded. For vouchers it would even be absurd. Negative amounts would only make sense if the positive amounts were also displayed and a difference would be calculated. Therefor I had included adapted tpl files to generate correct pdfs in this zip, too.

@Traumflug, this is not about rounding! The rounding works.

I can confirm that the negative signs currently may look like a bug, but this isn't the case. Provided the variables are filled correctly, it works that way. The past has shown that. Damn it, I didn't even realize that @Traumflug had "raged" like that in the HTMLTemplateOrderSlip class.

No, that wasn't meant to be rude, especially since I think @datakick is a gifted programmer. From the point of view of Merchant and customer, I only wanted to show the logical consequence of such a misbehaviour of the software in an everyday process. And just for the record: If I knew exactly where the bugs were caused, I would also have posted suggestions for a solution.

😮 Nice? Expected results? For every merchant and customer it is quite clear. Thirty bees calculates incorrectly, or more precisely: The calculation results are output incorrectly. This is damaging to the business of any shop. I really hope you're not serious.

Is there a Github issue? Problem for me is that I see the damage done but I still don't know which changes in thirty bees were responsible for a strange behavior like the following, because the issue is not alone the fact that minus signs are hardcoded in several parts of the order slip. Amounts tax incl and tax excl are confused, totals remain untouched. So I would guess multiple issues come together. Example 1 Invoice: Order slip after partial refund of one product and the shipping costs (both amounts entered like demanded from thirty bees tax incl.): Example 2 Invoice: Order slip after (partial) refund: Weird, isn't it? And absolutely not usable for live shops!

😃 Es gibt einen Status "Zahlung eingegangen". Aber den brauchst du doch gar nicht zu setzen! Und deswegen auch bei den Statuseinstellungen auch nicht anzuklicken!

Nochmals nein, das musst du nicht! Vielmehr kann die Rechnung auch für den Status "Bestellung storniert" aktiviert werden. Dazu reicht ein Mausklick auf das rote Kreuzchen in der Spalte Rechnung der Statusliste. Sobald eine Rechnung erzeugt wurde, ist auch der Button "Teilerstattung" verfügbar, über den eine Stornierung sämtlicher Posten vorgenommen werden kann. Dann lässt sich die Gutschrift erzeugen. Das ist zugebenermaßen umständlich, entspricht aber durchaus den normalen Dokumentationspflichten. Das Hauptproblem dürfte wohl eher sein, dass die Programmierer von TB ein komplettes Storno der Bestellung für unwahrscheinlich zu halten scheinen und auf den Button "Gesamterstattung", den es in PrestaShop noch gab, verzichtet haben. Deshalb muss die Stornierung jedes Einzelpostens gesondert erfasst werden. Das ist bei größerern Bestellungen umständlich und zeitraubend und sollte korrigiert werden.