Valid orders stay € 0,00 in customer overview

[Smile]

Apparently I changed something a year ago in statuses and because of that the total amount of €.... sentence is not calculating right. Also the value at the end of a finished order is not showing the order value.

It seems the only thing making a difference here is the "Consider the associated order as validated" I removed it form payment accepted as we like to check the order and make change before it goes to processing. 

Order processing does have "Consider the associated order as validated" thicked thoug, as do all the following order stages....

 

What is happening here?

[30knees]

I have something similar.

[Smile]

Well seems a bug or the same misconfiguration? 🤔

[Chandra]

This is always zero for COD/Bankwire orders in my case. Online payments show correctly. 

As @toplakd mentioned in this thread, you may need to update payment on each order for manual payments. I have not tried it yet myself.

 

[Smile]

I see indeed that it is only the case for bankwire. Not sure how to add a payment and not sure we like to do that manual 😉 When status changes to payment accepted you would expect it to change automatically.

[toplakd]

1 hour ago, Smile said:

When status changes to payment accepted you would expect it to change automatically.

I strongly suggest to open "payment accepted" status, and you will see where your problem is coming from.

As you have set it to not close payment automatically once changing status to payment accepted.

Edited March 18, 2020 by toplakd

[30knees]

On 3/18/2020 at 11:21 AM, toplakd said:

I strongly suggest to open "payment accepted" status, and you will see where your problem is coming from.

As you have set it to not close payment automatically once changing status to payment accepted.

I'm not sure. We have the status "paid" that follows "awaiting payment" and in "paid" the option "set the order as paid" is ticked. Or did you mean something else?

[datakick]

I think this issue is directly related to the one fixed recently - https://github.com/thirtybees/thirtybees/issues/1153. You can forward to bleeding edge and test it.

Note that the code change will NOT have any effect on already existing orders, as the data are already corrupted in the database. But new orders should display correct payments

[toplakd]

As datakick said, upgrade to bleeding edge and test it on new orders.

As said before, create backup instance of your live shop for testing purposes, and than you can play in testing environment with creating orders, changing statuses etc.

But as said, it will also affect only new orders.

[datakick]

I did some investigation, and this area is pretty fuc*ed up. 

There is a column total_paid_real in order table that tracks how much money was actually paid. This column has been deprecated for a very long time, because this information is primarily stored inside tb_order_payment table. 

However, for backwards compatibility reasons, this column is still there, and thirtybees tries to keep it in sync with records in tb_order_payment table. Needless to say, it does this very poorly.

The issue I've mentioned in my previous post is just one problem. There are others, for example currency issues. Some code expects this column to be in shop currency, other code expects it to be in order currency, and this can lead to totally wrong amounts (apples and oranges added together)

We need to fix this.

The first item is to remove all *read* usages of this column from core. Core code should always use data retrieved from tb_order_payment, and not use this deprecated column at all.

Then, we should fix all *write* usages, so modules that depends on this column continues to work.

Unfortunately, even with all of these, we will still have consistency issues, only not so frequently. It's just not really possible to keep things in sync. For this, we should have some scheduled task that automatically fix the data. 

https://github.com/thirtybees/thirtybees/issues/1161

 

[30knees]

5 hours ago, datakick said:

I think this issue is directly related to the one fixed recently - https://github.com/thirtybees/thirtybees/issues/1153. You can forward to bleeding edge and test it.

Note that the code change will NOT have any effect on already existing orders, as the data are already corrupted in the database. But new orders should display correct payments

Indeed, I think that resolves it. Nice job and thank you!

[toplakd]

You can also try the todays latest commit which @datakick just posted on github.

I just put some tests through it and made few orders, adding products and payments, same with removing.

And it all works well so  Updated live site to it already

Edited March 21, 2020 by toplakd

[Smile]

Great guys, I will see the update in a next version thanks!