Omk

Was your trial successful and did you get what you needed?

I can't believe that this is the situation! Prestashop has all the bells and whistles, but not a monthly sales report? Not tax report? Not product mix report? Seriously? What a retarded system is this?

Yes, a good analysis of the situation - it seems to be like that. Several of the issues you mentioned were also encountered by us.

Do NOT EVER use this method in a live system. I used it on our shop deleting our test orders before we launched the store, and it seemed to work fine. BUT: It deletes only the master orders table, but leaves all the others, where the invoice data is kept intact, causing ghost products appearing in invoices, tax calculations get completely wrong, ordered products listings get messed from the actual shopping cart and what was paid etc. So this happened to us after we launched the store. Huge mess! So using "deleteorder" via the URL results in total chaos and hell of work manually editing the DB tables and tracking down all messed up records across the different order related tables.

Thanks. This is a solution. Once done, how can we contribute the fixes to the bankwire module?

Ok we made the code change. But I feel this is such a trivial thing - many people are asking for it, so it should be made a configurable option in the preferences.

Vekia, I guess this fix that you gave above deals with the module name, but it will be universal for all languages. I would need to make the name appear in all languages, translated. Such as: Bank transfer (EN) Girering (SE) Überweisung (DE) Bankoverførsel (DA) Overschrijving (NL) Is there a way to do this, or does one have to accept that it will be in only one language?

Well, in Japan they translate everything into Japanese. In Japan, for instance, they have Makudonaldo instead of McDonald's.

Hmm, testing this further: Is there some feature in Presta which automatically detects the country where the visitor is, and auto-selects the correct shipping method based on this detected location? Is there a way to fool this location detection to test whether it works right?

Sale of 2nd hand goods is a special case, and the practice seems to vary from country to country. Some countries are more liberal in application of VAT regulations than others. In Netherlands it seems that 2nd hand goods that a company has bought from a consumer, who has already paid the VAT, as is shown in his purchase receipt and sells it further, obviously without VAT, as the individual consumer is not VAT registered. When the company buys 2nd hand goods from a consumer say for 100 euros, the 100 € price is VAT 0%. When the company sells the material for 120 €, then it depends on the local application of VAT law how it is dealed with by the tax authorities. In Netherlads, if Hozballs is right, VAT is only paid from the margin (from 20€). In Finland VAT is paid for the whole amount (120€), unless the merchant is registered with the tax office in the marginal tax policy register, which is the usual practice for all 2nd hand shops and antquariates. I am not sure whether this all fully correct or not. But surely, the VAT of 2nd hand goods is a special case.

In the store that I am setting up there is shipping to the whole world. I have configured the carriers using the default Prestashop carrier module. We are mainly shipping to other EU countries, but also locally using the national carrier. I need to set up the shipping so that by default the EU shipping price is shown in the cart. The national rate is cheaper than the EU rate. The national rate should be shown to the customer only after registering to the store with their address. If I enable the national rate for all users, all visitors from all over the world are shown the very low national shipping rate, which of course is incorrect for all other users except for those few local customers who can use the national shipping rate. So I tried disabling the national rate for all visitors, and thought that the next available rate will be shown - the EU rate. But no, now it shows "Free shipping!" in the cart. And this is of course totally wrong and it is even illegal to show such false information there, and then suddenly charge for the shipping after customer has entered their address. So for the time being, I disabled the national carrier, and now the prices for the rest of the EU are shown correctly. What kind of solutions have you implemented for this problem?

Ok thanks. Shouldn't that be a configurable option?

I mean the built-in sitemap: index.php?controller=sitemap&id_lang=1

Can these items be removed from the sitemap?

Or is there a way to add new styles to the presta text editor? I would like to add style "Lead" in the drop-down menu for available styles (Paragraph, Adress, Pre, Header 1, Header 2, etc). The fact that it does not already exist is quite strange, as it is used quite often in documents and product descriptions.