Traumflug

But if you want more than that, you will have to alter some logic. [...] Heck, PayPal and Stripe are always limited to 2 decimals, no matter what. Yes, absolutely. That's why I mentioned this topic: number of digits shouldn't be carved in stone and may be different for distinct items or the total price. Similar situation with fuel prices: a liter diesel costs 1.109 Euros and these three digits to the right of the decimal are displayed at product presentation, kept during multiplication (9 liter = 9.981, not 9.90 or 9.99), still rounded on the bill (9 liter = 9.98), before payment gets processed.

Doesn’t uninstalling also remove the installed module files? I hope this happens one day. Having a separate 'delete' just adds confusion. PS 1.7 removed the 'delete' menu item and added a modal dialog asking whether the module should also be deleted. That's certainly even worse than what PS 1.6/30bz does.

In that case you would have to allow more decimals for the currency. Works technically, but poor appearance. Having so many digits on single items means one currently has them everywhere, even in the cart: ```none 1000 Resistor 4k7 ohms € 4.2000 2000 Resistor 1k ohms € 8.4000 1 TV set € 230.0000 2 SD card 32 MB € 15.4000 Total € 253.8400 ``` ==> "OMG, this TV has a 7-digit price!" Stores selling such stuff: about all shops selling electronic components.

I tried to do it a bit differenty and it worked. Glad to see this :thumbsup:

You obviously want to make this folder writable. It's modules/, it should have read, write and execute privileges for the webserver process. Perhaps the easiest way to find out is to compare ownership and privileges with folder log/. If there are files starting with a number inside log/, log/ has the privileges modules/ should have, too.

Hmm. Error message for this initial test is "At least one table with same prefix was already found...", while you write “Table ‘tb_access’ already exists”. So it's apparently not this initial test, but an attempt to fill the database twice.

I’m not new to prestashop by the way so please don’t write about obvious things Obviously there's something going on I've never seen. Installer is pretty much the same as with PrestaShop. This check for table tb_access happens before the table gets populated, so I wonder what might trigger this check a second time and without user interaction.

If you're going to work on this, don't forget very small amounts, which are currently almost impossible. For example, electronic resistors can cost less than half a cent, 0.0042 Euros. This results in a displayed price of 0.00, unless one raises the number of digits for all prices, even the 100-Euro ones. A great solution would format prices as you suggested, but add a digit for each zero right of the decimal for prices < 1.

But I install on an empty database, when I look in phpmyadmin the tables got created, and then this error… Doesn't sound logical. Steps for installation are: Create a database, e.g. thirtybees. Install using this database, prefix is arbitrary. This creates tables inside this database, including table tb_access (where tb_ is the prefix). Click on the "Manage Shop" button to see further instructions. Remove folder install/ as instructed. Click the link given in these instructions. Note the current URL (ignoring parameters), which ends with adminxxyyzz/, where xxyyzz is a random string. Where does your procedure differ from this and in which step shows the error message up?

Perhaps the AJAX calls this would create are too much extra overhead on a high traffic site It's certainly doable, the cart page does something very similar. But as you said, it's highly unusual.

Yes, that's how the PS guys have choosen to do things. One needs an existing, but empty database for a glitchless experience. If there's no DB at all, the installer offers to create one. Which means, just deleting the DB is fine.

what is the need to show the unit price for the t-shirt? For t-shirts one doesn't enter a unit price. Accordingly, no unit price is shown. This feature is still necessary, because thirty bees isn't limited to selling t-shirts.

One can't buy products by these units, neither is the price shown on the bill a unit price. Unit prices exist to make product comparisons easier. An example: (Picture from http://politicalcalculations.blogspot.de/2015/07/working-backwards-from-retail-to-cost.html) One yogurt costs $1.62, the other one $0.72. Which one is cheaper? Ignoring unit prices one needs a pocket calculator to find out. With unit prices it's much easier: The $1.62 yogurt is $0.05/oz, so it's cheaper than the $0.72 one with $0.12/oz! At checkout, one pays neither $0.05 nor $0.12, but the product price: $1.62. Or $4.86 if one takes three.

str_replace('Sie', 'Du', $string); FTW! No, just joking. "Geben Sie hier Ihre bevorzugte Farbe an" -> "Geben Du hier Deine bevorzugte Farbe an". Sounds like a parody on our citizens with Turkish ancestry.

"Member States may waive the obligation to indicate the unit price of products for which such indication would not be useful ..." Yes. Which means, certain products need this feature activated in some countries, but not in others. The feature its self remains the same.

And is this needed for German compliance or EU, which is two very different things Not really. Regulations are about the same, just the urge to comply with them is much higher in Germany. Like I tried to explain above.

Excellent! Marked this report as solved.

It is strange because there is two places where you can set decimals. In Preferences/General where you can set the number of decimals and in the currency itself where you can set using decimals yes or no. ... and inside templates.

I fear there's no quick fix, but I added a Github issue to not forget this: https://github.com/thirtybees/thirtybees/issues/262

@yaniv14, can you make a screenshot or two? "without decimal ‘1050’ instead of '1500.00’" sounds, uhm, odd. Another thing to look at is Smarty/HTML code producing these numbers. I've seen rounding code in some templates. Like {$price|round} or similar.

Makes it sense to compress images before we load/import them into TB/Presta? Not really. Currently even the "original" image gets rewritten on import[1], so such optimization doesn't survive the minute you add the image. If you want well optimized images, add all of them, then run this optimizer on all the images in img/p/. Like downloading this folder via FTP, then optimizing, then re-uploading the result via FTP. Thirty bees won't touch these images and serve them happily as long as they exist and as long as nobody starts a "thumbnail regeneration". Adding images later requires repeating this procedure for just the new images, of course. [1] This is known and considered to be a mis-feature, but as always, somebody has to rewrite this code section, which didn't happen, yet.

And why it isn’t part of the eu compliance which is mainly used in Austria and Germany … Blunt question, blunt answer: because nobody hacked it in, yet. There is no magic button making this happen, it needs work and work needs time and/or money. Not sure how GDPR is related to this module, though. This module is for German merchants which have choosen to not collect VAT separately and handle the VAT topic like an ordinary citizen. This choice is given to merchants with less than EUR 17.500 revenue yearly, only. As far as I can see, this module is not a general legal compliancy module, one needs Advanced EU Compliance as well.

I installed it with community-theme-default and didn't notice any incompatibilities on the first glance. Didn't have a closer look, though.

I think the best plan to get this happen is to set up a simple test shop with demo products, then tweak Backoffice -> Preferences -> SEO & URLs -> Schema of URLs until URLs match those in your current production shop. Product URLs matching those in the current shop should make SEO happy, no matter which shop software generates and handles them. That's a common setting for all products, so comparing a few typical samples should be sufficient.

Hmm. Adding such tags manually appears to work here: This last tag was even longer when entered, but after saving it got cut to 32 chars. Can you add this manually, too? If yes, it's apparently a CSV importer problem.