wakabayashi

Haha very funny, that yesterday I tried this 😂 Search in your theme for product-sort.tpl and add: <option value="date_add:desc"{if $orderby eq 'date_add' AND $orderway eq 'desc'} selected="selected"{/if}>{l s='Newest first'}</option> Please respond, if this works out well for you.

Nice you have the supporter logo

So I set up a token for all zones. But now I have to select a specific domain in your module. Is this correct how I am doing it? :S Edit: all clear. I just have to select a specific shop and then save...

@cprats Please search for: {if $option.unique_carrier} {foreach $option.carrier_list as $carrier} <strong>{$carrier.instance->name|escape:'htmlall':'UTF-8'}</strong> {/foreach} {if isset($carrier.instance->delay[$cookie->id_lang])} <br>{l s='Delivery time:'}&nbsp;{$carrier.instance->delay[$cookie->id_lang]|escape:'htmlall':'UTF-8'} {/if} {/if} And replace it with: {if $option.unique_carrier} {foreach $option.carrier_list as $carrier} <strong>{$carrier.instance->name|escape:'htmlall':'UTF-8'}</strong> {if isset($carrier.instance->delay[$cookie->id_lang])} <br>{l s='Delivery time:'}&nbsp;{$carrier.instance->delay[$cookie->id_lang]|escape:'htmlall':'UTF-8'} {/if} {/foreach} {/if} Please confirm, if this works.

I get your point. Ofc that would be nice, but who would be in such a team?

Yes I could solve it, but it depends on your theme. You use one page checkout right? You have to edit order-carrier.tpl and move the closing foreach a bit. You could also post your code, if you can't solve it yourself.

What do you mean with: I need to keep the design? You need to change a few lines in one file, thats all :S

There is no such team. The problem is that devs can't test this all by themself. They never have the real environment. You can never forseen all issues. I don't understand why merchants shouldn't test anything?

I would bet that it's this problem: I had it too...

@SLiCK_303 you are a hero 🙂

Yeah I thought so 🙂 But it works with multistore, right?

Nice! One question: Does this purge cache only when I manually delete cache in tb or does it also work when I upload a js file trough ftp?

It's not about the fix. It's about how you fix it. If people upload this fix, they will lose this in the next update. Why don't you propose this fix in github?

I use a PS Module: Premium Google Tag Manager v2.1.3 - from ReactionCode But tbh I don't use GA too much for now. I mean the normal informations about countries your customer come from, browser, bounce_rate and so on are helpful for me. But the ecommerce stats aren't really too useful in my opinion.

@Traumflug nice catches, but I doubt this is fixing my issues in order-slip table. @Occam To be honest, I also doubt, that your changes fix the problem at the root - as you don't respond to my screenshots, which obviously show that there are multiple issues... But as your contribution for sure improve things, why don't you submit it to github? Like that the changes aren't implemented... AND just modify core files is in my opinion even worse than overrides.

Well I invested another few hours today into returns and order-slip creation. My impression from yesterday was just reinforced. This feature can't be used often by merchants. It's output is strange and also buggy. If it would be used often, we would have seen complaints about it. Here is a screenshot form my ps_order_slip table Sometimes total_products_tax_excl is just the same as total_products_tax_incl, but not always? I have no idea when it happens. Look for example id_order 15750. I did always the same testing process. Why the hell does it sometimes work and sometimes not!? The yellow marked line is also funny. It worked for shipping calculation, but not for products calculation. Another example: You see id_order 15750. Why is there no refund column? Here you see id_order=15742 and here it works :S In general I have problems to understand the intention of all database columns of ps_order_slip. That's why I decided to give up on this topic. IMO there is no other way, than first define what merchants actually need and afterwards rewrite this completly. For people which want to use this feature now: you should change mainly order-slip.total-tab.tpl and order-slip.product-tab.tpl. There you can remove the minus signs. There you can also remove the strange $order->total_products and replace itwith something like $order_slip->total_productstax_incl. TBH: I cannot offer a fully working solution as the tax is not always right (see screenshot above).

I have tried that: But not many people were interested in it. Maybe it would help if patreon can influence, where tb is heading and what has priority. But it's anyway up to the officials of tb. If they can generate other revenue streams, it's ok too 🙂

As you said above the total should not even be in there, so is it even a bug? Or do you mean something different? I have the feeing that the minus sign is just a small issue somewhere. In the database the numbers aren't negative. In general I like your order-slip from above much more. This one makes sense to me.

Ja das ist mir klar. Dann ist die Info von Prestashop wohl einfach falsch...

@Occam Danke für deienn Beitrag. Falls das echte Kunden sind, würde ich die Namen wegmachen ^^ Edit sind wohl Testbestellungen 🙂 Wie sollte das aber korrekt funktionieren? Würde der totale Betrag angepasst (Also Total - Rückvergütungen Total = Neues Total)? Oder bedeutet Total eigentlich die Summe von allen Rückvergütungen? Oder sollte gar nichts passieren und nur das Minuszeichen ist falsch? Was mich so irritert, dass bei einem Discount was ganz anderes passiert... Kannst es ja mal machen. Dann passt sich das total nämlich an.

Danke! Bei einer kompletten Rückvergütung machen die Zahlen Sinn. Mich interessieren allerdings primär Teilvergütungen und dort scheinen die Probleme zu liegen.

Btw I found this http://doc.prestashop.com/display/PS16/Merchandise+Returns information. It says: How can a customer use a credit slip on next purchase?

Kannst du mal einen screenshot machen, wie das sein sollte? Wird bei dir total neu berechnet oder bleibt das immer der alte Betrag? Dieser Betrag hat aber sicher nicht dasselbe Vorzeichen wie die Vergütung oder?

Dann kreierst du im ersten Schritt aber keinen order-slip oder? Falls ich dich richtig verstehe nutzt du dann "partial refund" doch, um es vollständig rückzuvergüten oder?

That is an example of a partial refund, which I created today. Maybe I don't get things right, but I dont see how does this order-slip.pdf makes any sense? As Info the original total value of the order is 30,30 CHF. The original shipping cost was 8.00 CHF. And the orginal total of products was 22,30 CHF.