How to handle returns?

[wakabayashi]

2 minutes ago, colorful-ant said:

auf die schnelle nur ne komplette rückvergütung gefunden

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.

[Occam]

Allmählich verstehe ich das Problem.

a)

26 minutes ago, wakabayashi said:

Dann kreierst du im ersten Schritt aber keinen order-slip oder?

 

Das kann man beliebig oft machen. Und es wird jedesmal eine neue Gutschrift erzeugt. Aber ...

b) Die Gutschrift, die von 1.1.0 erzeugt wird, ist völlig falsch. Zwar wird, was auch richtig ist, der Stornobetrag mit einem Minuszeichen versehen. Anschließend aber passiert das in der Gutschrift auch mit dem Gesamtbetrag der Bestellung - und das ist völliger Unsinn!

Das ist schon ein heftiger Bug.

c) Wenn der Kunde das Geld gar nicht erstattet bekommt, sondern bei der nächsten Bestellungen einsetzen soll, dann wäre das ein Gutschein. Ist aber in Deutschland zumindest so nicht erlaubt.

Edited September 5, 2019 by Occam

[wakabayashi]

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

[wakabayashi]

7 minutes ago, Occam said:

c) Wenn der Kunde das Geld gar nicht erstattet bekommt, sondern bei der nächsten Bestellungen einsetzen soll, dann wäre das ein Gutschein. Ist aber in Deutschland zumindest so nicht erlaubt.

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

[Occam]

Nee, die sind natürlich nicht echt.

Ich habe das jetzt mal mit einem anderen Testshop von mir gemacht. Die berechneten Werte hierin sind übrigens PrestaShop 1.5 Standard. Da wussten die Programmierer in Paris noch, wie's geht. So sollte so eine Gutschrift eigentlich aussehen, wenn sie korrekt erzeugt wird. Der Gesamtbetrag der Bestellung hat nichts darin zu suchen!

Edited September 5, 2019 by Occam

[colorful-ant]

ich hab jetzt mal im demoshop bei mir gestet mit tb 1.1.0 - mit nur einem anstatt alle 4 artikel zurück

@wakabayashi sieht genauso schlecht aus wie bei dir mit den werten

[Occam]

To force thirty bees to create a credit slip you first need to add some code to /<Admindir>/themes/default/template/controllers/orders/helpers/view/view.tpl (after line 1207):

			<!-- START -->
			<p class="checkbox">
              <label for="generateCreditSlip">
                <input type="checkbox" id="generateCreditSlip" name="generateCreditSlip" onclick="toggleShippingCost()"/>
                    {l s='Generate a credit slip'}
                </label>
            </p>
			<!-- END added -->

Or as override the complete file saved as override/controllers/admin/templates/orders/helpers/view/view.tpl

But in any case this other bug needs to be fixed and there ought to be different methods and templates for voucher and credit slips. That would be a real improvement in comparison to PrestaShop.

Edited September 5, 2019 by Occam

[wakabayashi]

1 hour ago, Occam said:

But in any case this other bug needs to be fixed and there ought to be different methods and templates for voucher and credit slips. That would be a real improvement in comparison to PrestaShop.

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.

[Occam]

Actually, We face 2 bugs.

First a credit slip with negative amount, which may be the easiest way for a programmer but is nonsense for business purpose.

The second and more severe bug is that the total order amount including tax total amount are displayed as negative values which is totally wrong.

The first is afaik PrestaShop standard since 1.6.1x, the second is a special problem of thirty bees. Both need to be fixed.

Correct values for credit slips like the one I posted above can only be created with PrestaShop 1.5x and maybe until 1.6.0.14. Afterwards the trouble began ...

[wakabayashi]

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

[Occam]

Ok, you may give up (which is sad for a moderator of this forum) - I do not!

So, for other users who simply want the order slip to work properly, I added a fix. I made some changes to the class /pdf/HTMLTemplateOrderSlip.php and adapted all files from which the pdf is generated by removing the minus sign characters.

@wakabayashiWithout a separated order-slip.tax-tab.tpl  or a change in invoice.tax-tab.tpl  you would never achieve to remove the minus signs in the tax details breakdown.

You can apply the fix by just replacing the original files with the modified ones in the zip file. The directory path is included.

Fix Bug Order Slip.zip. (removed)

 

Edited September 7, 2019 by Occam

[Traumflug]

Mauro found two glitches in the code: https://github.com/thirtybees/thirtybees/pull/1043 Cheers to him!

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

[Occam]

3 hours ago, wakabayashi said:

AND just modify core files is in my opinion even worse than overrides.

If this fix is even worse than overrides you better do not use it. And just for the record: For me the possibility of overrides has always been one of the highlights of PrestaShop/thirty bees.

Edited September 7, 2019 by Occam

[wakabayashi]

36 minutes ago, Occam said:

If this fix is even worse than overrides you better do not use it. And just for the record: For me the possibility of overrides has always been one of the highlights of PrestaShop/thirty bees.

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?

[Occam]

I beg your pardon, it was your advice, not mine, not use overrides because they were "even worse" (eh, any reason why?)

I would ever prefer to patch with overrides which would be easy in this case. But to please you I have removed my zip file.

[lixotuka]

I've migrated my PS (1.6.0.13) to TB a few days ago and I'm really surprised to learn that refunds don't work as in PS.

When I made a partial refund in Prestashop, a credit slip was created with the parcial amount refunded, not the total of purchase. This doesn't make any sense.

Have you found any solution to solve this issue?

[Pedalman]

I had always thought that a proper pdf template for slips would do the trick. I had to edit my pdf templates during Prestashop times and migrated them to TB two years ago.

Anyway, this is not how it should be done and the core system should work flawless in this case. So, I really vote for a proper guide how to use these (old) functions a)RMA a) partial refund (that can also fully refund^^) with the relates order statuses and possible emails going out to customer with nice screenshots for dumb merchants as me.

[Briljander]

I don't think TB can handle all scenarios that a e-commerce requires. But it would be good to get a guide how its supposed to work and then find all scenarios that doesn't work and try to solve them.

Rather have a solution for that than a new backoffice theme for example.

Edited November 6, 2019 by Briljander

[Pedalman]

Moreover, crucial things like invoices and credit slips should work. If merchants notice irregualarities or even bugs I assume it'd be appropriate if a team leader shows he took notice of it and does all a fix is introduced.

Merchants use live shops and no test shops 🙂

So, I am asking for help here for a proper order-slip.total-tab.tpl

[datakick]

Can anyone point me to the github issue for this one?

[Occam]

1 hour ago, datakick said:

Can anyone point me to the github issue for this one?

Is there a Github issue? Problem for me is that I see the damage done but I still don't know which changes in thirty bees were responsible for a strange behavior like the following, because the issue is not alone the fact that minus signs are hardcoded in several parts of the order slip. Amounts tax incl and tax excl are confused, totals remain untouched. So I would guess multiple issues come together.

Example 1

Invoice:

Order slip after partial refund of one product and the shipping costs (both amounts entered like demanded from thirty bees tax incl.):

Example 2

Invoice:

 

Order slip after (partial) refund:

Weird, isn't it? And absolutely not usable for live shops!

Edited November 25, 2019 by Occam

[datakick]

I'd be happy to look into this issue, however I need to understand what's wrong first. I don't really know this domain area, so I need somebody to actually explain to me what this is supposed to do. @Occam your screenshots are nice and all, but I also need to know what the expected result are. If you could file an github issue with following:

1) reprosteps - what *exactly* one has to do to reproduce the problem. Ideally on vanilla installation with test data

2) expected results - what should the result look like

3) actual result - I guess your screenshots above should cover that

Without an actual bug report there will be no fix

[Occam]

2 hours ago, datakick said:

I don't really know this domain area, so I need somebody to actually explain to me what this is supposed to do

😮 Nice? Expected results? For every merchant and customer it is quite clear. Thirty bees calculates incorrectly, or more precisely: The calculation results are output incorrectly. This is damaging to the business of any shop. 

2 hours ago, datakick said:

Without an actual bug report there will be no fix

I really hope you're not serious.

Edited November 25, 2019 by Occam

[datakick]

3 minutes ago, Occam said:

😮 Nice? Expected results? For every merchant and customer it is quite clear. Thirty bees calculates incorrectly, or more precisely: The calculation results are output incorrectly. This is damaging to the business of any shop. 

I really hope you're not serious.

Oh, I'm. I'm supporting thirty bees out of my good heart and my good will. I'm not paid to fix bugs.

If nobody is willing to put any effort to actually describe the issue in a way stupid developer like myself can understand it, I'm not going to waste my time to fix it.