Traumflug

Ich habe versucht, das nachzustellen: https://github.com/thirtybees/thirtybees/issues/869 Es kommen jedoch die korrekten Zahlen im Front Office heraus (nicht über die drei Stellen hinter dem Komma wundern, das ist bei mir gerade so eingestellt). Könntest Du mal die Schritte anschauen um zu sehen, was Du anders gemacht hast? Ansonsten käme auch noch eine Gruppenreduzierung in Frage. Unter Back office -> Customers -> Groups kann man jeder Gruppe einen Nachlass gewähren. Den kann Back Office in der Vorschau natürlich nicht kennen und damit nicht anzeigen.

Thanks for the heads up. Here's a preview version with this fix applied (which will go into v2.2.1 of this module): vatnumber-master.zip

Enabled catalog mode, perhaps? Back office -> Preferences -> Products, right the first switch.

To fix an issue we'd need the required steps to reproduce this issue. As if one would explain it to a child: click here, do that, ...

Back office -> Preferences -> General -> Use HTMLPurifier Library Turning this off might help.

This synchronization currently happens for releases, only. Doing it, let's say weekly, has the additional challenge that it needs to keep older strings for a while.

Uhm. Core Updater is not made to update developer installations, just like tbupdater wasn't. Branch markus is where I push my current work. Often intentionally broken stuff, to test/improve Travis CI. Workflow goes like this: http://jump-ing.com/traumflugs/github_best_practices#avoid_broken_code_on_the_main_branch

Removing usage of mbstring would also remove support for kyrillic characters, which is probably not what you want 🙂 Accordingly, filed a bug for this: https://github.com/thirtybees/thirtybees/issues/857

Well, if you're capable of stepping through the database, totals are in table tb_order; lines (one product * quantity) are in table tb_order_details. Yes, there's some redundant information. Price with tax, price without tax and price ... which is the one which was shown to the customer and matches one of the other two. Also a couple of values which are recorded for (I assume) statistics. One can look up these tables to see whether there are zero'd prices. If you're also capable of reading PHP code, look at this: https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/order/OrderDetail.php#L701-L708 it literally sets prices not validating to '', which means 0.000000. Payment modules should not be involved. While orders are indeed created from a cart at the end of the payment process (class PaymentModule), they'd have to override that whole method.

Running the updater should correct this. If not, Core Updater needs improvement. And yes, I'm dreaming of consistency checks as well. Probably happens not before v1.2.0, though.

Black irony is, some of the old PS code would simply set prices to zero in case there are too many digits behind the decimal. And this happens easily, think of periodic numbers like 3.12121212... Code introduced in 2014. While this gets corrected with the current price calculation audit (an exception is certainly better in such a case, proper rounding to avoid it first place even more), the quick fix is to look up method isPrice() in classes/Validate.php and make it return always true.

Not that I can confirm this, but I've filed a Github issue: https://github.com/thirtybees/thirtybees/issues/849

The module assumes forward slashes, that's true.

Put it onto the TODO list for the 1.1.0 release.

Bleeding Edge isn't supposed to be marked as stable. It's the current state of development. That said, thirty bees takes great care that every single commit in the repository gives a working installation. Which means, big failures when updating to a random Git commit are unlikely. Regarding your question I'm not sure what you want. If an update to current 1.0.x works, what's the problem? Software doesn't get better if it receives a big STABLE stamp.

I had a talk to Lesley, thirty bees will keep this kludge for a while.

For tweaking default behavior there's the well established hooks mechanism.

Maybe it's disappointing to some of you, but thirty bees is going to make running a shop easier, not harder.

Those who want to run a shop and sell goods rather than wrestle with technical details of the shop software.

It'd be better to advance the implementation rather than adding more pain to merchants. Setting up a shop with thirty bees* is pretty complex already and burdening merchants with even more complexity, like additional switches to consider, is counterproductive. * This probably applies to our fellow competitors as well, thirty bees should be better than these.

Which "TB updater"? Module tbupdater or module Core Updater? Neither of them should do anything on their own, much less install additional packages.

What's the point of this switch? It's hardly imaginable a merchant does not want SEO fields.

Guess: one of the products in the pack has zero quantity.

See https://duckduckgo.com/?q=prestashop+dual+price+display Remember, all PS 1.6 modules still work on thirty bees.

Yes, that's what I meant and how I understood the question. Glad to see you answered this as well, so @simon can pick what he actually needs.