Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Smile

Valid orders stay € 0,00 in customer overview

Recommended Posts

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?

orders.JPG

Share this post


Link to post
Share on other sites

Well seems a bug or the same misconfiguration? 🤔

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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.

wire.JPG

Share this post


Link to post
Share on other sites
Posted (edited)
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 by toplakd

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

  • Like 2
  • Thanks 3

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Posted (edited)

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 by toplakd
  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...