30knees

Just to make sure we're understanding the same thing. This is not about changing the price after the order was created. This is about changing the price during order creation when there is a specific price for quantities (eg 2x = 10% off) and you're creating an order with that quantity.

Anybody else having problems since a while that Klarna authorised orders with Mollie v4.5.3 don't get their status changed to "completed" upon moving to a "shipped" state?

Thanks, @veganline. I'm looking around for ways to optimise our processes and remembered looking at Storemanager way back.

OK, those modules are not that nice, in my opinion. We want to use DeepL, which has excellent translation, to bulk translate all product descriptions. They'll be saved and indexed by search engines (I'm not sure that happens with the other type of module you used). Also, we'll be able to polish the translations of those languages we speak.

Thank you for sharing your experience. Did your module translate on the fly? Because some I looked at save the translations like in a manual entry, so I'd not expect the site to become slower.

Nope, still the same problem with 1.4. This is the standard price when I add the product in the backend in the "create new order" page: If I enter 7.245 or 9.245 and move outside the price field, the price immediately jumps back to 8.245.

Does anyone use an automatic language translation module that uses eg DeepL or Google Translate and that they can recommend (or would recommend against)? I'm interested in using such a tool to expand our customer reach. There are a couple of modules on the marketplace: https://addons.prestashop.com/en/search?search_query=deepl&compatibility=1.6.1&

I'd like to follow-up on wakabayashi's question. And regarding this question: I don't have any knowledge but I can help finance the development if this were to become the tb default.

Weiterhin mit Collmex, händisch, aber weil wir nur eine EÜR führen, können wir posten gut zusammenfassen. Das dauert nicht so lange. Dennoch wäre eine andere Lösung nett. Seid Ihr weiterhin bei JTL?

Völlig vergessen, Rückmeldung zu geben. Buchhaltungsbutler hat nicht so gut geklappt. Bestellungen von Amazon holen wir in den Shop, Buchhaltungsbutler hat die Bestellungen doppelt abgebildet. Vermutlich hätte man das irgendwie lösen können, vom Support waren wir aber auch nicht so begeistert.

Mich würde interessieren, ob jemand hier in der Zwischenzeit Erfahrungen mit solchen (WaWi-) Diensten gesammelt hat. Wir haben Billbee kurz getestet waren aber davon genervt, dass die Steuersätze vom Shop nicht eingelesen werden. Zudem bietet Billbee keine Chargenverwaltung.

Strange, I'm runnning v1.5.5. It's been out for quite a while already. I think their page isn't very current. 🙂

Just some feedback that we've not had a single spam email since we installed the module a week or so ago. We had a couple of spam emails per day before that.

Update: datakick fixed the table issue. On 1/9/2023 at 8:16 AM, Daresh said: Actually the module helped to discover a ThirtyBees bug in a customer counting function. I just got the module and received an error upon installaton. This is the error: Not unique table/alias: 'c'in file /classes/Group.php at line 437SQLSELECT COUNT(*)FROM `tb_customer` cLEFT JOIN `tb_customer` `c` ON cg.`id_customer` = c.`id_customer`WHERE (cg.`id_group` = 1 ) AND (c.`deleted` != 1) LIMIT 1 Is this the bug you mentioned? What would I need to do to fix this? I'm also getting this error log: Notice Trying to access array offset on value of type bool modules/gm_omniprice/gm_omniprice.php:464 80 Today 10.02.2023 12:57:18 Notice Trying to access array offset on value of type bool modules/gm_omniprice/gm_omniprice.php:465 80 Today 10.02.2023 12:57:18 Notice Trying to access array offset on value of type bool modules/gm_omniprice/gm_omniprice.php:535 80 Today 10.02.2023 12:57:18 Notice Trying to access array offset on value of type bool modules/gm_omniprice/gm_omniprice.php:536

Does that make sense, no invoice without a payment? It depends on your type of accounting but it feels like it shouldn't be decided by the shop.

Correct, I have a module to edit orders. 🙂 But I guess that's still independent of the issue that when one generates an invoice the system thinks the order was paid (even if you don't change the order state to a state that is paid but leave it unpaid).

I discovered that when one generates an invoice the system thinks the order was paid (even if you don't change the order state to a state that is paid but leave it unpaid). This is the order total that shows up above as 431,95. I edited the order I had generated the first invoice because the customer requested some changes. I then deleted the old invoice and generated a new one. The 431,95 was taken from the old invoice.

The reason I'm asking is because an invoice I opened shows two different totals, see below. I don't know where the price discrepancy would come from. I edited the shipping price from 20 to 18.18, but that's not the difference between the two totals.

No, no overrides. I'll check again after the update to 1.4 and report back.

Sure! This has been with thirtybees since the beginning and is still in 1.3. I have a product variant that has a specific price of -4% when a customer takes for example 5 of them. See here: Problem: The specific prices override any attempt at manually setting the price when I manually create an order in the backend using "Add new order". For example, maybe because it's a special customer, I'd like to give them a one time price of 1 Euro per item for instead of the normal price of -4% for 5pcs. So I enter a different price on the manual order page in the backend after choosing the customer and the product. However, the system doesn't accept the manual price for the 5pcs I'd like this order to have. Instead, it reverts to the the special price of -4% for 5pcs. I see that @Smile commented he has the same problem with specific prices for customer groups.

Some more specifics. One can manually set a price when editing an order (just not during creation of the order), but the price can't be 0.

Ah, good point. It's the first time I'm seeing encrypted modules. Will pay attention to this going forward.

@datakickWas this issue ever addressed, by any chance? EDIT: It's not in 1.3.

Looking forward to the update! 😄

In case someone is looking: a module that permits this: https://addons.prestashop.com/en/price-management/53088-same-price-products-and-shipping-after-vat-applied.html