Order gets reopened when in Status "closed".

[azngeek]

When i create an order and the order-status is "completed", any other change in the payment status will reopen an existing order. This is a behaviour where an implicit dependency exists between two different state machines.

Is this an expected behaviour?

[boxblinkracer]

i havent heard about that is it possible to reproduce it, can i have the step-by-step instructions?

in addition to this, just today a new PR was merged that handles wrong order transactions and how they are shown and handled in the administration. maybe that has to do with it

[azngeek]

We were not able to reproduce this in the Test-Environment but only live.

Step 1. Create an order

• Create any order with a payment type with an autorized state, like Klarna Pay Later.
• The order should now be in the status "in progress"
• The payment state should now be in the status "authorized".
• Now manually set the order to the state "closed" - Just ignore, why we are doing this - it is just to reproduce the behaviour.

Step 2. Wait until the payment gets confirmed

1. The payment state should now be in the status "paid".
2. The former closed order is now reopened.

What i find interesting is, that in fact we have three different state machines which should not have a dependency. Instead of that there is an dependency between the payment-state-machine and the order-state-machine. How or why would the state of the payment-state-machine affect the other one?

[boxblinkracer]

Hi

thank you for this, but may I ask what you mean with "closing" it? there is no close on my side, only "done" which is a "positive" end result, and paid would also lead to this.

for me it seems as if you "close" and order (because its forbidden/cancelled), but the payment process was successful....so I would find it rather bad if the plugin wouldnt mark it as successfully completed?

regarding the dependency...the plugin only updates the payment status. if you however set a order status mapping in the plugin configuration, it will also update the order status in addition to this. maybe you have a "open" status mapped to "paid" there?

the hard dependency on the shipping has been removed (it still exists as automatic-shipping in the plugin config). the rest of the depdencies are no dependencies but business flows that are triggered...such as a shipping in Mollie leads to a payment and thus to a paid transition thru a webhook

so I think you would need to explain the "closing" a bit more, so that I see how your business process should be (also in private if you want)

thank you

[azngeek]

Yes, a closed order is an order in status "done", you are right.

• There is no flow in the flow-builder which reopens a process if an authorized payment is set to "paid".
• We do have order-status Mapping enabled, but this should only trigger it the order is created. There might be an issue with that setting.

[boxblinkracer]

Hi why do you think it should be triggered if created? thats not what this feature does. your configuration says, once a transaction is "paid" which happens after a while with pay later (due to the authorization first), then the order should have "In Bearbeitung".

this mapping is the reason why the plugin transitions it...

why cant you just set that to "done" in the mapping for "paid"...because it seems as if paid payments should lead to an order "done" in your case?

[azngeek]

• Thanks for the clarification. I guess this is something which i just expect to work the way.
• We do have several other states which need to be processed in a given order, so directly setting it to done ist not an option for us.

I am still curious about, how a transition from "done" to "in progress" is possible as the following transitions must be done:

1. done to open
2. open to in progress

So the current implementation can automatically traverse through all possible transitions for any state and chooses the right one which will then lead to "in progress"?

[boxblinkracer]

the plugin takes care of doing in-between transitions because of the restrictions of the shopware states so if you want "paid" orders to be "in progress", then molie might insert a "open" in between, so you get what you configured :) i wouldnt says "traverse through all"...i think its just "use open", but dont know it by heart

i once had a conversation with someone who told me that at a specific state, he doesnt want mollie to touch it again. so like a "final locking order status"....would that be something that could help you?

so once its "closed", no more transitions will be done...even though webhooks come in

[azngeek]

Yes exactly. Symfony has a nice feature which is used to "guard" certain transitions. Basically exactly what you said:(https://symfony.com/doc/current/workflow.html#guard-events).

I now understand the logic behind that feature but i also assume that other customer will face the same situation. I guess sometimes you just expect certain conditions instead of exactly reading the description. :)

[Bernardus]

We see this behaviour in our return process.

To generate a creditnote in shopware, we need to edit the order itself. This results in an open orderstatus. After a creditnote is generated we refund the order through the mollie extension and manually set the orderstatus to done.

The refund takes two hours, and after these two hours mollie updates the payment status to refunded or partially refunded. But after a while the orderstatus is switched to open again . This leads to reservation of the stock.

[boxblinkracer]

Hi there just released the "Final Order Status" feature with v2.2.2 that should fix it right? heres the guide: https://github.com/mollie/Shopware6/wiki/Order-state-automation