Order Status

[RaggedStaff]

We need to be able to track the status of Order's across platforms.

[RaggedStaff]

A few sample Order States from Woocomerce:

Pending payment — Order received, no payment initiated. Awaiting payment (unpaid).
Failed — Payment failed or was declined (unpaid) or requires authentication (SCA). Note that this status may not show immediately and instead show as Pending until verified (e.g., PayPal).
** Processing** — Payment received (paid) and stock has been reduced; order is awaiting fulfillment. All product orders require processing, except those that only contain products which are both Virtual and Downloadable.
Completed — Order fulfilled and complete – requires no further action.
On hold — Awaiting payment – stock is reduced, but you need to confirm payment.
Cancelled — Cancelled by an admin or the customer – stock is increased, no further action required.
Please note: This status does not refund the customer.
An example use case: The merchant wants to cancel the order because the customer has become unresponsive and they do not know where to ship the product. The customer is not eligible for a refund in this case.
To issue a refund please follow the Manage refunds documentation.
Refunded — Refunded by an admin – no further action required.
Authentication required — Awaiting action by the customer to authenticate the transaction and/or complete SCA requirements.
Checkout draft — Draft order created when customers start the checkout process with WooCommerce Blocks checkout block enabled.

[RaggedStaff]

Shopify uses Order Status, Fulfilment Status & Payment Status separately... https://help.shopify.com/en/manual/orders/order-status

[RaggedStaff]

OFN have raised the point that they use a flag (at Enterprise level) to determine if an Order can be amended, after the Customer completes payment, but before the SalesSession ends.

[lecoqlibre]

See #75 (comment)

[RaggedStaff]

We also need to consider that some platforms support offline payment methods (Direct Debit, cash, direct bank payment), so there may be a delay (of several days) between submission & payment completing.... Some platforms won't really complete payment on individual orders, they will reconcile customer accounts on a periodic basis.

[RaggedStaff]

From discussions it was noted that Shopify also includes Return Status. We (I) can not (currently) envisage a scenario we would need to process a return across the network, so we're not including that in our thinking.

[RaggedStaff]

We are leaning towards the Shopify solution - adding a Payment Status and Fulfillment Status to the Order.

[mkllnk]

Open Food Network state machines

Order

• address
• delivery
• payment (if payment required)
• confirmation
• complete
• canceled
• resumed
• awaiting_return
• returned

Payment

• checkout
• pending
• processing
• requires_authorization
• failed
• completed
• void

Shipment

• pending
• ready
• shipped
• canceled

[RaggedStaff]

@Alcoz @lecoqlibre We need to finalise this asap... for the Orders integration on Shopify, we need to switch the Order's FulfilmentStatus from Scheduled to Unfuliffled when a SalesSession completes.

I'm noticing that most systems seem to have Shipment/Fulfilment states separate to Payment state.. perhaps we need to do likewise (I can think of multiple scenarios with different sequences for both states, so I think it makes sense to normalise them out).

I've asked Ooooby to confirm their states too, so we can consider those too - are there any French platforms we need to consider/review: Socleo, Mycelium?

I'd really like to agree a way forward before Thursday's call, so we can discuss & sign off there.

[sankarom]

Hi, Here are the Socleo statuses for an order:

• draft
• awaiting_payment
• validated or refused
• canceled or retracted
• invoiced
• closed

then on logistics:

• in preparation
• prepared
• shipped
• delivered

[RaggedStaff]

I've listed some proposed DFC States & attempted to map them to the states provided in this sheet .

Can people (in particular @mkllnk & @sankarom) please review & feedback, by Thursday (2nd Nov)? 🙏

[mkllnk]

OFN states for draft should also include:

• payment (indicates that it's ready for a payment)
• confirmation (indicates that the user needs to confirm to finalise)

We don't have the held state. The order can always be changed by the customer unless it's complete, canceled, returned etc. The transition to complete happens within a database transaction and is seen as atomic. If it fails, we go back to the drawing board and the user can decide to remove or add products. They may not have enough money or something is out of stock that needs to be replaced.

So we need to remove payment from the DFC order state Complete.

The payment state is a bit confusing as well. An order can have a complete payment but still be unpaid if the amount of the order is bigger than the amount of the payment. This can happen if an admin enters payments or adds products to the order.

In summary, all the DFC states make sense though and I think that it would cover everything. Our additional states are just internal to the app and facilitate the UX.

[RaggedStaff]

Thanks @mkllnk

I've updated the draft/held & complete state mappings as per your comments.

I'm a little confused about the payment states. Do you think we need to support a PartiallyPaid status, to indicate when some payments have completed but the Order isn't fully paid?

[mkllnk]

Do you think we need to support a PartiallyPaid status, to indicate when some payments have completed but the Order isn't fully paid?

No. We just treat it as unpaid.

[RaggedStaff]

This discussion is now closed. The agreed states will be incorporated into the Ontology through issue #102

[lecoqlibre]

@mklink This commit of the next branch of the data-model-uml repo should give you the ability to get this in the Ruby connector?