Orders showing payment state as 'paid' when clicked into they change to 'pending'

[chezaorchard]

Description

Customer order shows payment state as 'paid' in order list screen, when you click into the order all looks fine, total is correct, fees and shipping are listed and payment is still displaying as 'paid'. When you click through to 'payments' you could see a Balance Due notice.

When you search for the order again, it now shows payment state as 'balance due' in order list screen.

Maybe related to #5119

Expected Behavior

If there is a balance due on and order it should display 'balance due' in order list screen

Actual Behaviour

There is no way to tell there is a balance due - the system is incorrectly displaying 'paid' until the 'payments' screen is accessed.

Screen shots for affected order below. Prom Coast Food Collective, 1965, order R826807508 - screen shots taken at 2:07pm

Screen shot of same order now; 5:51pm

Steps to Reproduce

Not able to reproduce

Workaround

Severity

Your Environment

Logged in as superadmin

• Version used:
• Browser name and version: Chrome
• Operating System and version (desktop or mobile): Desktop

[luisramos0]

I am changing this to S2, I mean, the order total has changed!
It looks like the 15 dollars different are the shipping fee.
I dont think this is related to #5119 I think this must be the aftermath of #5795
I will investigate.

[luisramos0]

I can replicate this by placing an order and afterwards changing the shipping method to a shipping method 15 dollars more expensive AND also by simply changing the shipping method of the order from 0 to 15 dollars, for example.

I tried hard to see how this could be related to #5795, but it's not because the order and the payment (without shipping fee) is from 15th of July, one week before #5795 started.

I think this is simply related to this behaviour in the edit order page: whenever a manager edits an order the shipping rates are recalculated even for completed orders, as long the order is not shipped yet.

This is what I think it happened, the order was placed on the 15th July with this shipping method, but the shipping method at the time did not have a cost (I cant verify if this is true on the DB). The order total and payment was 140aud.
Later on the 21st and then on the 28th of July (these are dates the shipping method's calculator and rate were created and last updated respectively), the manager updated the shipping method and made it have a cost with a flat rate of 15aud. DB records confirm this.
After that someone editeed the order and because the order has not been marked as shipped the shipping rates were updated and the new cost of the shipping method was picked up, so the order total was moved to 155aud.

Does this make sense? It's important to know that editing the order can change the shipping cost depending on the shipping method config)

[kirstenalarsen]

Hi @luisramos0 - I'm not sure because i haven't been following the detail - but I think the aus team have dicsovered that #5795 was occurring well before it was reported. They have gone back and been checking orders all the way back to the first V3 deploy, which I think is why orders as far back as the 15th were being checked. I would need @chezaorchard or @emilyjeanrogers to confirm that.

[luisramos0]

ok, that is one hypothesis. I dont have facts to discard it so we should consider it.
The problem introduced by #5613 in v3.1.1 deployed 21st July in AUS was causing #5795 for sure.
What we could be seeing, and I cant prove otherwise, is that 5795 was already happennig before v3.1.1 and before #5613.
The idea is that this shipping method had a feee of 15usd on the 15th of July and that fee was not charged...

One fact that makes me think it can't be the case, but it's not proof, is that clearly someone manually changed the fee on this shipping method on the 21st of July...

Do you have any other orders I can check in detail?

[emilyjeanrogers]

@luisramos0 I have a spreadsheet of over 100 orders that had some kind of issue in the last week, caused by a few different bugs at different times.... and in some cases (as above) the status of them has appeared to change over time, so it's been pretty hard to keep on top of exactly what's happening!!

Because fees were dropped off active order cycles for some enterprises, it's highly likely that they were added back manually, by either OFN or the customer as soon as this was noticed - either before or after we applied fixes. We can't be sure who did this and when.

I'm not sure what kind of orders would be most helpful, but below are some orders that we've identified as having some kind of issue, before July 21st:

Prom Coast: The following orders were not charged fees on July 15th and status is Paid
R624646775
R578773210

Prom Coast: The following orders were charged fees on July 15th and status is Credit Owed
R004400446
R221753743

Prom Coast: The following orders were not charged shipping fee or transaction fee but were charged admin fee on July 16th and 17th and status is Paid
R223614724
R658448253

North Arm Farms: The following orders were not charged admin fee on July 19th and status is paid
R481312456
R464138500

UPDATE the below two issues have been confirmed as not a problem by the Enterprise
_Distillery Food Hub: The following two orders involved an overpayment well before v3 and we are still trying to get to the bottom of how/why they happened or if they are connected:

On June 28th
R175862832 overpaid by EFT by $17.93 and now has a credit owed
R706152074 overpaid by EFT by $5.35 and now has a credit owed_

[luisramos0]

Hello!

R624646775 - R578773210 - yes, these are similar to the first order I investigated... I cant explain this except by user action.

R004400446 and R221753743 - status is not credit owned any more.

I am not sure what to do here. I am not sure it's worth going through these orders and trying to explain what happened between releases and user changes.
Can we just fix these orders manually to whatever the hub thinks is correct as a workaround and see if we get new occurrences of this in the future?