wakabayashi

@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.

@colorful-ant why do you need both forms in this usecase?

Seriously I have read your PDF twice and don't believe my usecases work correctly. If they do, please explain me, how it works. How would that work: He sends 1 product back, but he doesn't deserve a full refund? IMO it doesn't work cleanly with partial refund as the product is not saved as returned... And the order-slip values are very strange. All values are minus. The total stays the same. I have no idea if this is wanted, but adding a discount has a completly different impact. How can adding a discount and adding a refund (with the same value) have completly different order-slip? And I dont even start to combine this issues with ASM where you have a field like usable_quantity. Where is it good for, if not at product returns?

Ich denke, dass dieses Problem relativ klar am Theme liegt...

I am sorry to hear that and understand ofc that you stopped for the moment 😞

1. What do you mean with total refund? My interest is when a customer orders 10 products and then we have cases like: He sends 1 product back and derseves a full refund He sends 1 product back, but he doesn't deserve a full refund. 1 product is broken and he deservers a full refund for this single product 1 is a bit broken and he is fine with a partial refund 2. If you want to cancel all products, why dont you just us "cancel order" status?

Thanks for your pdf. After reading it, it still doesn't make sense to me, why we need two forms. Where is the sense of "product returns"? You could just Make a "partial" refund with full amount of product price.

Some notes during testing: The distinction between partial refund and product return doesn't make big sense. It would be better to have one form, that allow both actions. A partial refund and a discount (add_voucher button) are acting completly different. The partial refund has no impact on order total, while discount has. No idea why it is like this!? If you use partial refund the revenue on the dashboard doesn't change at all (which is IMO wrong) When using partial refund total_products_tax_excl and total_products_tax_incl are the same in ps_order_slip table -> which makes no sense. Edit: this only happens in some cases (maxbe oder_slip_type) :S The column order_slip_type in ps_order_slip is nowhere explained Not clear why we need columns total_shipping_tax_excl, total_shipping_tax_incl, shipping_cost and shipping_cost_amount in ps_order_slip_table Conclusion: This is as frustrating as Advanced Stock Managment. You know that a lot of things are wrong, but you don't even get the intention of some things. So you can't even say: hey I am gonna fix this 10 issues. So I will work with some overrides for internal usage.

Ich verstehe das Problem, weiss aber nicht was die richtige Lösung dafür ist. Bist du sicher, dass das vorher in 1.0.8 funktionierte? Hast du da auch schon das Niara Theme verwendet? @Traumflug Im Theme werden die radio inputs ausgeblendet und man sieht lediglich den css style mit :before. Muss das über js gelöst werden? Mir scheint es so, dass die echten radio inputs absichtlich weit verschoben werden.

Was ist ein Optionsfeld und was ein Auswahlfeld? Redest du von radio buttons vs select felder? Hast du zufällig ein Link?

Looking at this topic again I am still puzzled. How to handle returns correctly!? Who is using partial refund and who is using product returns? Does the order slip generation work correctly for you? I see the product there, which was returned, but the total is still the same. Also I have quite strange information in the tax box :S OK it seems that we are not the only one with this problem: https://www.prestashop.com/forums/topic/496432-return-products-subtractdiscount-amount-of-refunded-money/

@datakick It was surely not helpful to announce an inhouse solution and then still stick to patreons. But why such a huge drop can happen, is still mysterious to me.

I can only confirm what @datakick and @zen said. This is a stable version. Probably the most stable version I ever had in ps/tb universum. Unfortunately a few new issues came up. Basically due the fact, that we merchants didn't test the things 😞 If we all wait till a version is super stable, then the life for the devs is very hard. With the new core updater its super easy to test things.

@danwarrior haha this happens quite often to me too 🙂 As this topic comes up from time to time, I wish to know, how tb could improve the BO order creation? Where can it be improved?

Bleeding edge is a term from the new core updater. It basically means, that the shop will update to the point of all github commits.