30knees

I've started using https://www.magnalister.com/en/#pricing It works well and was very easy to setup. I am also testing Baselinker (https://baselinker.com/en-GB/functions/marketplace-manager/), which is also quite interesting. But I'm getting some odd issues with the import of orders from Amazon to the store. I'm still investigating.

That's quite easy. 🙂 Thank you. I've read the documentation but couldn't find anything. How does one rename the created payment method? While the new payment method has a name in the module itself "Amazon"), in the store it just reads Custom Payment Method.

I am testing a service to import Amazon orders to the store. I'd like the payment method to show "Amazon". Is there a way to add a "fake" payment method, so one in name only because there's no module behind it?

Prodded by a chat @musicmasterand I had, I think this is the problem: Prestools is assigning a VAT rate of 7% to shipping costs. The invoice shows that is assigning a VAT rate of 19% but in reality it is using the 7% calculated by Prestools. --> Prestools should be assigning a VAT rate of 19% and not 7% for this order because 19% is the VAT rate of the product that was bought. Perhaps Prestools is ignoring the Advanced EU Compliance Module feature "Proportionate tax for shipping and wrapping"? A solution might be to be able to set the tax rate for Prestools (or even better, adopt "Proportionate tax for shipping and wrapping")?

@datakickAre we misunderstanding the webp improvement for 1.4 or is something wrong?

I was hoping to upload webp files. I have a bunch and it would be nice to not convert them to jpg (and then have them reconverted). Are you able to upload webp files at all?

How does webp support work? I have these settings: But when I upload a webp image I get this error: Image format not recognized, allowed formats are: .gif, .jpg, .png How can I upload webp files as product images? p.s. I have <webp>1</webp> in the theme's config file.

Unforunately not. I am using: Prestools version 1.31j. Release date: 14-feb-2023. Changing the shipping price does not affect the taxes as shown in the invoice.

Interesting, good that you discovered that it causes problems ... but we don't use the module. 🙂

Thanks, @the.rampage.rado. And would you agree that the benefits of ASM are: Multiple warehouses Stock movement Supply orders

This is super cool and I am looking forward to using it. The information notice on the quantities page for the pack says: However, the options indicate that I can calculate pack quantities automatically without ASM and I believe it's working for me without ASM. Am I misunderstanding something or is the text in the information box incorrect? A related question: Is it generally preferable to use ASM? What are advantages/disadvantages to using it? Thank you.

Yep, but that's wrong because it should not depend on the currency but on the language. EN: 12.59 € DE: 12,59 €

OK, then the takeaway is that typically I should use a point and if it's related to the core or a native module I can file an issue. Thanks, all! One thing that is problematic with this setting below is that different languages have different standards. For example, this is the same number: EN: 12,000.59 DE: 12.000,59 But the setting below ignores language settings.

That's a screenshot of the invoice I generated from within the tb order page. What part of order-edit.php do you want to see? This is order-edit.php for the shipping costs:

Hi @musicmaster, We started using Prestools to edit orders. For one order, I needed to edit the shipping costs. That worked fine. However, the associated taxes weren't updated accordingly: You'll see that the total tax and the shipping tax are wrong. Shipping 23,36 € x 19 % = 4,44 € Total 98,36 € x 19 % = 18,69 € Is this a limitation of the module or a bug or a user mistake? Thank you.

Oh, then I'll continue to keep an eye on it and see what happens. @datakickmentioned in the last update news that they're working on a native Mollie module. Hopefully that'll fix all issues.

Some numbers in the store are displayed with a comma and some with a point, eg 20,20 or 20.20. When I enter a number, for example for a refund, I often don't know which is correct: the comma or the point. I go with what I see. So if the Stripe module shows me that the total was 70,00, I'll use a comma to enter the refund amount. When this is wrong and I should have used a point instead of a comma, like it's the case with Stripe, the number gets truncated and my refund of 5,55 becomes 5.00. Where does this mix of commas and points come from and is there anyway to fix this?

Now it's working again, perhaps a side-effect of other fixes. 🙂

Solution: The domain in the external service and the tb parameter SET SHOP URL have to match precisely. The external service said to use domain.com but in SET SHOP URL I had www.domain.com. Changing the external service entry to www.domain.com fixed the issue.

I'm not sure but how about updating to PHP 8.0?

I'm trying to link an external service but the connection attempt gives this error: This call to PrestaShop Web Services returned an unexpected HTTP status of:301 (#CON11) I activated logs for the webservice but no logs are generated. I've read https://docs.prestashop-project.org/1-6-documentation/english-documentation/developer-guide/developer-tutorials/using-the-prestashop-web-service/web-service-tutorial/chapter-2-discovery-testing-your-access-to-the-web-service-with-the-browser and tried accessing via http://[email protected]/api/. This is unsuccessful. I'm am only asked to enter the passkey again and again. The tutorial says: However, the key was associated with full permissions. How can I figure out what the problem is?

Some themes have multiple "places" where such information can be entered. It's probably in one of the modules, some block or CMS module. Take a look there.

They fixed some issues that were preventing the translation for some products. It's working fine now. I'm selling the module at half price in case anyone is interested, so 56 Euro. I'll transfer the module license via Prestashop Marketplace to you.

I think the approximate order profit overview proposed by @wakabayashi would be helpful. We do something similar in Excel. It's not about accuracy to the cent but just a rough overview. @x97wehnerWhat does your Power BI connection all do? Regarding the interesting profit discussion, I think what is key is the definition of "lost". I don't see scenario 1 as a loss of 5 Euro compared to scenario 2 because the loss you're referring to is the difference between actual and potential profit. For me, a loss in a business sense is whether I have less money on my account after the transaction than before. For me, what you're looking at is profit maximisation and not loss avoidance. :)

Is it really just me?