A first iteration on product chain logic enabling full transparency

Software improvement 4-In delivery
,
1

Continuing discussion from Discovery Session: Networks (WIP)

I wanted to share with you some thoughts on how we could build a model that ensure full product chain and transparency. I don’t know why, but I thought if this is really the core of our model, should we keep that discussion a bit private? We don’t know who is watching us :slight_smile: Maybe there is no need, in that case feel free to change category.

1- The model and logic behind it

erdplus-diagram%20(1)
erdplus-diagram%20(1)1185×489 32.8 KB

File in png and original ERD file can be downloaded here.

a- In order to be able to allow hubs to create their own “conditionning” of the original product (like split 100kg into 1kg bags) we need to separate in the model the Product and its Conditionning.
b- Each combition of Product and Conditionning is a unique Product Reference
c- If a hub has permission to distribute producer products, a new Product Reference is created automatically with the distributor as a owner, and connected to the original Product Reference from the producer by the formula New Product = 1 x Origin Product. That will allow the hub to use his own product reference.
d- Product References are connected to one another via formulas. If one formula is set up the reverse one is automatically calculated by the system. This will be useful when we start talking about stock.
e- Pricing happens in the “offer” table only, with a very refined model enabling lots of flexibility on how hubs set up prices (will need to think deeper with the various calculator’s options). This doesn’t include “fees” that hub takes on suppliers for instance for some logistics services (see proposal for fees here) neither “discounts” that they might offer to some customers (see proposal for discounts here).
f- If Products (source) is modified it doesn’t change the Product Reference hub has created based on this Product and the system should ask the hub if they want to apply this change to its Product Reference, keep original or create another product reference (as hub may have some stock of the previous version of the product).
f- This new logic have various impacts on permissions: More thoughts on permissions here.

2- Instantiation

I instantiated that model and did a lot of back and forth between both to end up here. So please have a look at that document if you want to have a detailed example and how that beautifully works on all product chain tracability and product depacking/repacking stuff :slight_smile:

3- Impact on inventory and order cycle

  • There is no need for inventory anymore, or said differently, every enterprise manage his product catalog through inventory and only inventory. The connexion with producers catalog is done only through inventory, not anymore in the order cycle. Stock is not in the scope of that reflexion but will be managed accordingly to the the above proposal.
  • The good point it that should simplify the order cycle logic: first iteration on order cycle redesign here.

Of course this model description doesn’t includes the UX part, how and when we ask users to fill in which information. That should come stage 2.

@Kirsten @sauloperez @enricostn @oeoeaio @maikel @lin_d_hop happy to read year feedback on that first iteration :slight_smile:
I think when we have this kind of thing (a version we agree upon) then it will be easier to list the things we need to do in dedicated epics.
Do we need to plan an inception session on this “product chain and pricing” focus to go forward together and list next step?

2

Do we want this model to enable a hub that sells “carrots” to be able to source his carrots from multiple producers? So it would mean we wouldn’t be able to show from the shopfront just one producer but a list of multiple producer (and that will have impacts on stock management but that’s another issue)

3

Sounds nice, but is not essential. At the market are often two boxes like “carrots from Gippsland” and “carrots from Macedon” (fictional). We can do that in the shop as well. Buyers may have a preference and it’s makes everything a lot easier to keep it separate.

4

This is possible, but could also be very difficult to implement. We really need to think about which information has to be saved. Do we just tell that something has changed? Do we tell what exactly has changed? What if the producer changes something and then changes it back to the original? How do we know what the original was?

Do you have any example how these problems have been solved by other systems?

1 Like
5

changed category @MyriamBoure - to make this accessible to others I want to be able to read it at the moment :slight_smile:

6

I think being able to show that the same product is sourced from multiple producers is important. I can’t say if its important as a first step - but we should plan with it clearly in mind. Use cases of this are already common in Canada: a specialty grain distributor draws from hundreds of producers in order to aggregate a large enough quantity for sales to a specialty mill, or to food hubs… This is the case for any products that are pooled now - and this is big in NA. The ability to pool same product, but keep it traceable is a game changing innovation for small scale growers. So - we should definately do it. Second use case - food box programs and multi-farm CSAs (also big here and getting bigger). These are basically large (1000 buyers) hubs that fill their box orders from multiple growers. Right now - they limit to LARGE growers who can supply their large demand. If they could pool specific products (eg. 20 lbs carrots from Fred, 10 lbs from Theresa, 30 lbs from…) and keep transparency, this is a huge benefit for small scale growers. (I also note that none of the proprietary programs I’ve looked at own this space at the moment because they are not focused on helping small scale growers. )