[DFC] Orders Part 1: Create order from OFN via DFC

[mkllnk]

:information_source: Funded Feature. Please track ALL ASSOCIATED WORK under the associated tracking code #11678 DFC Orders

• Time spent in Australia
• Time spent in Global
• Estimate: 36 days = 252 hours
• Total on 2024-09-26: 195 + 5 = 200 hours
• Total on 2024-10-11: 223 + 5 = 228 hours
• Total on 2024-10-11: 255 + 5 = 260 hours
• Added estimates for extension tasks: 36 + 8 days = 44 days = 308 hours
• Total on 2024-11-01: 273 + 5 = 278 hours
• 30 hours = 4.2 days left

What is the problem we are solving

The UK project Food Data Collaboration (FDC) aims to connect Shopify and OFN via the Data Food Consortium (DFC) standard.

With DFC products completed, products can exist within OFN and be linked to products another platform. An OFN Hub can add these products to their shopfront. When a shopper buys these products the order must be placed on the originating platform. The orders from different customers on a Hub order cycle must be aggregated into a single wholesale order.

In Part 1 the minimum requirement is only implementing sending orders from OFN to another Platform. Orders from the other platform back to OFN are currently out of scope. Stock is also out of scope in this case.

Success factors = expected outcome

• OFN customer adds products to the cart which correspond to DFC products in another platform. The OFN products are created manually and linked to DFC products via an additional URL associated to the OFN Spree::Variant. Estimate: 3 days
• After checkout, a new DFC order is placed containing the DFC products. OFN customer details are not forwarded. The buying agent is the OFN shop. The DFC endpoint to place an order will be a hard-coded URL in the first iteration. 3 days
• If previous orders within the same order cycle created a DFC order already, we update that one instead of creating a new order. The supplier wants only one wholesale order instead of many small orders. Due to limitations within Shopify, we need to delete the old order and create a new one. 2 days
• One product may be offered in several variants, a retail and a wholesale variant with different quantities per item. For example, flour may be sold in 1kg and in 20kg bags. When updating an existing DFC order, quantities should be aggregated and wholesale items should be ordered where possible. 3 days
• The Shopify app needs to be notified at the end of the order cycle to finalise the order. Order states are not defined in DFC yet and we don't know how the endpoint will look like but it's probably some kind of DFC order update. 3 days

Ignoring for now:

• Stock levels.
• The OFN order cycle will be the sale session to associate orders to even though that's not correct.

Useful information for inception

• Initial scoping and estimates.

Link to the "Product Development - Backlog" item in Discourse

[RaggedStaff]

Further to discussion on slack... yes, we will need to use OIDC authentication for this. We'll need a token refresh method implementing in OFN, I didn't realise that wasn't already included in the Product work.

[lin-d-hop]

I feel confused that this issue is referencing Shopify. Does this change the spec from integrating with the DFC? If so then I would suggest the spec might be out.

Would anyone mind if I reframed this to not specifically talk about SHopify?

[RaggedStaff]

Would anyone mind if I reframed this to not specifically talk about SHopify?

Go for it - we can refer to Producer platform (Shopify) and Hub platform (OFN) if that's easier?

[RaggedStaff]

Just a note from conversations with @lin-d-hop around Shopify work... we need to track any partial sold whoelsale cases/product across Sales Sessions (Order Cycles).

For example: A hub received a retail order for 8 cans of beans They order 1 case of 12 cans of beans, so have 4 remaining in stock at the end of the order cycle We need to ensure these 4 are sold in the next Order Cycle, before ordering any further cases

I think we can probably use existing OFN inventory functionality, is that right @lin-d-hop ?

[mkllnk]

O#%&$... I was hoping not to worry about stock in part 1. I thought that in the first order cycle, we would only order wholesale items if we actually reach the number. Otherwise we fall back to retail items to not have spare stock.

This is a whole new functionality not implemented anywhere. But I think you are hinting at the DFC order being like a backorder. So we draw local stock first, allow going over because they are backorderable (this term is in our code, comes from Spree) and then place an aggregated backorder with wholesale items at the end of the order cycle.

But OFN removed this whole backorder concept. When an order is "backorderable" it just means we don't care about stock and don't adjust the level. Stock levels can't go negative at the moment. So we can't use a model of a customer order drawing stock into negative and that negative level being used to place the DFC wholesale order. To make this work, the OFN customer order shouldn't adjust the stock level and the DFC order aggregation draws from stock first then increases the quantity on wholesale line items. This may get really hacky to start with.

[mkllnk]

Example:

• OFN has 0 cans of beans.
• Customer order is placed for 4 cans.
• DFC wholesale order is placed for a slab of 12 cans.
• OFN stock is adjusted to 8.
• Customer order is placed for 6 cans.
• OFN stock is adjusted to 2.
• Customer order is placed for 11 cans.
• DFC wholesale order is updated to 2 slabs (adding one).
• OFN stock is increased by 1 to 3.

This is a bit crazy because the wholesale order is only a draft at this point. But we hope to reserve stock in the future, right? So then it would be fair to count that. I just don't know how we work with our existing data structure otherwise.

[RaggedStaff]

O#%&$... I was hoping not to worry about stock in part 1. I thought that in the first order cycle, we would only order wholesale items if we actually reach the number. Otherwise we fall back to retail items to not have spare stock.

There is an option we've implemented in Shopify: Order Partially Sold Cases which allows the Hub to determine whether to order a wholesale case when the first one is ordered, or the last one, but we may drop that (and it's not in scope for the intial OFN work) as it has the potential to be confusing & lead to orders going unfulfilled.

This isn't directly related... this is the part where:

• In Order Cycle 1, a hub orders 2 slabs of beans (24 cans), having orders for 16,
• So have 8 left to sell in Order Cycle 2...
• Then if they get 14 ordered in OC2, they only need to order 1 case (and will have 6 cans left for OC3).

Does that make sense?

There are 2 ways I see this could be done:

1. The backorderable thing you mention (sounds complex) :sweat:

2. We track how many items have been ordered within the Order Cycle (we need to do that anyway, right... in order to tell when to amend the wholesale order), and persist that value between Order Cycles.

Maybe we should have a quick chat about this? I'm around in the am, if you want to book a call.

[lin-d-hop]

I'd like to be in on any call you have please :pray:

@mkllnk I think this might be overcomplicated a bit. Core priority - The stock only needs to be checked before an order is created with the wholesaler. Secondary - After the wholesaler order is made any excess stock is added. This is the thing OFN doesn't currently do. For the initial implementation we can get away with the user having to update stock after the wholesale order. This isnt ideal and could be a nice to have if there is budget left.

The supplier side does most of the work with stock levels so we don't need to do the complexity you describe. @RaggedStaff #2 is more realistic.

[mkllnk]

We track how many items have been ordered within the Order Cycle (we need to do that anyway, right... in order to tell when to amend the wholesale order), and persist that value between Order Cycles.

I was hoping for a simpler solution that works just on the fly:

• Customer order comes in.
• We check if a corresponding DFC order exists.
• If not: create a wholesale order.
• If yes: update the existing order by just adding quantities.
• If there's another variant of the same product with a higher quantity per item and we reached that quantity then shift to bulk item.

In this version, all state needed would be persisted in the DFC wholesale order and OFN wouldn't need to store anything. But if I understand you correctly then we don't want to order any retail packs in the wholesale order and we order enough bulk items to cover all retail orders even if we have left-over stock. Then we need to adjust stock accordingly.

I think that my solution I described as "crazy" is workable. At this point I prefer that over adding more data structures to the OFN database to track stock over order cycles separately.

This week is really busy. We could try to chat next week. Maybe Thursday?

[lin-d-hop]

At this point I prefer that over adding more data structures to the OFN database to track stock over order cycles separately. I don't see how we would need to add anything to OFN data structures. OFN already tracks stock.

In the case that the product is linking to cases of 12, I see it as:

• OFN has 0 cans of beans.
• Customer order is placed for 4 cans.
• DFC wholesale order is placed for 4 cans
• Customer order is placed for 6 cans.
• DFC wholesale order is updated to 10 cans
• Customer order is placed for 11 cans.
• DFC wholesale order is updated 21 cans.
• DFC order completes at 2 cases
• OFN stock is increased to 3.

Or when OFN has some stock:

• OFN has 2 cans of beans.
• Customer order is placed for 4 cans.
• OFN is deducted to 0 cans of beans. DFC wholesale order is placed for 2 cans
• Customer order is placed for 6 cans.
• DFC wholesale order is updated to 8 cans
• DFC order completes at 1 case
• OFN stock is increased to 4.

The Shopify integration handles this and this seems like a straight forward way for OFN to best handle this. ping @RaggedStaff @mkllnk

I'll be in touch via Slack for a call

[mkllnk]

Yes, that sounds doable.