Smile Posted March 16, 2020 Share Posted March 16, 2020 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? Link to comment Share on other sites More sharing options...
30knees Posted March 16, 2020 Share Posted March 16, 2020 I have something similar. Link to comment Share on other sites More sharing options...
Smile Posted March 16, 2020 Author Share Posted March 16, 2020 Well seems a bug or the same misconfiguration? 🤔 Link to comment Share on other sites More sharing options...
Chandra Posted March 18, 2020 Share Posted March 18, 2020 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. Link to comment Share on other sites More sharing options...
Smile Posted March 18, 2020 Author Share Posted March 18, 2020 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. Link to comment Share on other sites More sharing options...
toplakd Posted March 18, 2020 Share Posted March 18, 2020 (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 March 18, 2020 by toplakd Link to comment Share on other sites More sharing options...
30knees Posted March 21, 2020 Share Posted March 21, 2020 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? Link to comment Share on other sites More sharing options...
datakick Posted March 21, 2020 Share Posted March 21, 2020 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 2 Link to comment Share on other sites More sharing options...
toplakd Posted March 21, 2020 Share Posted March 21, 2020 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. Link to comment Share on other sites More sharing options...
datakick Posted March 21, 2020 Share Posted March 21, 2020 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 2 3 Link to comment Share on other sites More sharing options...
30knees Posted March 21, 2020 Share Posted March 21, 2020 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! Link to comment Share on other sites More sharing options...
toplakd Posted March 21, 2020 Share Posted March 21, 2020 (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 March 21, 2020 by toplakd 1 Link to comment Share on other sites More sharing options...
Smile Posted March 26, 2020 Author Share Posted March 26, 2020 Great guys, I will see the update in a next version thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now