Use case: modelizing an international buying group

OK, we are simulating for a French pilote user an international buying group, CORTO. They are interested in experimenting OFN in France, if that can make them save time. It’s a consumer-run non-profit volunteer organisation that gets organic citrus fruits directly from a group of Sicilian farmers all the way to Paris. (Anselm was part of this group while living in Paris and says their fruit are just yummy!) :smile:
Here is their website for more info (translate with google):

Here is how they are organized:

Here is the process today:

Every SMALL BUYING GROUP (SBG) sends a spreadsheet with the list of products to their members, the members fill in.
The responsible of each SBG sends the aggregated spreadsheet to the manager of their BIG BUYING GROUP, who aggregate the spreadsheets from each SBG
The responsible of the IMPORT ASSO (this is CORTO, of which each final consumer is a paying member) receives and aggregates the spreadsheets (or Google docs) from each BIG BUYING GROUP and sends one single order (without sub-totals) to the EXPORT ASSO in Sicilia, who gathers the products from the producers and ships them.
The products are received in a warehouse near Paris, separated per BIG BUYING GROUP, members of which then come with a small truck to pick up the whole volume for their group and take it to their pick-up point.
Then the members of each SBG come to that pick-up point, separate out the total into the orders of the SBGs, then again into their individual orders and go home with their fresh and delicious-smelling fruit, pasta etc.
Voilà - Here we are!

We have set it up in OFN this way:

  • We create one enterprise for IMPORT ASSO: this entity will be the order cycle coordinator. This enterprise charges the import fee for shipping from Sicily to France (10cts per kg).
  • We create one enterprise for each producer and make up some products.
  • We create one enterprise for each BIG BUYING GROUP (ex: Paris South). In each of those enterprises, we create one shipping method per SBG (because we can’t add another layer of hubs here) - for example: one per neighbourhood in Paris South, so we manage them as different shipment methods, though they essentially have the same geographic pick-up point
  • In the order cycle, we propose various distributors, one per BIG BUYING GROUP. So each BIG BUYING GROUP has its own shop and sends the link to their members (would be great to have a login only shop ;-))

As a result:

  • When a member orders on the shop of his BIG BUYING GROUP, he chooses the shipping method corresponding to his SBG
  • The orders can directly be aggregated at the IMPORT ASSO level (great!) and can be dispatched easily by BIG BUYING GROUP (SBGs are a bit more problematic), so the IMPORT ASSO can send the global order to the EXPORT ASSO in Sicily via email.


We are lacking enough levels to simulate this correctly. The EXPORT ASSO in Sicily is not part of this simulation. We would like the supply chain to be transparent, so we would like to be able to add this intermediate in the chain.
While working on this use case, we realize that basically Open Food Network can only have max 4 layers: producers - coordinator - distributor - shipping method (we used the shipping method to be able to materialize the different sub-groups)

The EXPORT ASSO in Sicily is actually also selling the products to other IMPORT ASSO-type groups like the one I just described (CORTO is just the one for the Paris region, there are around a dozen other such IMPORT ASSOs in France, buying from the same group of farmers in Sicily).
Of course then they can create their own order cycle where the various IMPORT ASSOS (hubs) put the aggregated quantities, but then we have a problem with the stock management, because the stock of each producer has already been purchased at the group level, so it would be a double order for the same products…

How can we do that?

Also we have another issue with having used the shipping methods for the SBGs:
The SBGs take the total of their order at the pick-up point before separating it out to their individual members. Until now the found this total easily in the TOTALs line on their spreadsheet. But in the OFN reports, there is no way to show the aggregated quantity by products filtered by shipping method?
Actually in the “order cycle by distributor”, we have the info for dispatching what the IMPORT ASSO dispatches to the different BIG BUYING GROUPs, but in this report, in the column “shipping method” it’s only written “shipping method”… wouldn’t it be possible to display the info of which shipping method is used, which would allow then each group to filter by sub-group… I know we can use the Customer totals to see the pick-up point displayed but then there is no more aggregation per product…

How can we do that? How can we aggregate infos per products and per shipping method?

I’m not sure everything is clear, it’s a big complex. Please ask if any question.
@sstead if you have any idea on those points that would be awesome :smile:

Ping @oeoeaio, we just discussed at the global HO about this (for us to understand better) and Danielle thought you might have some input on this “4 layer” limitation (see the Question)… Did we understand properly?

Hi @MyriamBoure,

This scenario reminds me of the conversations that we had here in Australia when we first started designing the OFN! Your diagram is much clearer than any of ours though… :smile: Sadly, many other more pressing features got in the way, and so never got around to building in the ability to model complex distribution chains.

I think the approach that you have is pretty much as good as we can offer for the moment. I have a few suggestions for ways to solve your problems in better ways, but they will require new features to be built.

First Question: How to expose information about the history of a product, and how it ended up in the shopfront.
We originally had a plan to allow OFN to track actual sales of products between enterprises and then expose this information to the customers, however, I think that unless this is actually how the products are bought and sold (by every single entity in the distribution chain), the history cannot possibly reflect the true nature of distribution in the level of detail required.

Proposed solution: NOTE that this is a proposal only, and would need to be fully funded and specced before we could build it
In reality, products that end up in a shopfront have arrived there via a finite set of routes, which are probably known by the shop (hub) selling them and which do not change very often. I think my preferred solution to this problem would be to set up “Product Histories” or “Product Distributions” (sorry @RohanM), which would be scoped to a particular shop (hub) and would describe the history of how the product ended up there. I imagine this would manifest as a list of enterprises through which a given product has passed, and possibly a description of the function performed by the enterprise. Each “Product History” could then be a applied to a group of products that had the same distribution history for the given shop (so that we don’t have to enter the information more than once). We could then expose this information to the user on the shopfront. It could even be as simple as this:

Without a “Product History”, the distribution of a product looks like this:

Producer - > Big Buying Group

But if we add the intermediaries, it could look like this:

Producer -> Export ASSO -> Import ASSO -> Big Buying Group

What other information would need to be exposed to the customer?

Second Question: How to generate reports that group products sold by the shipping method selected
This should actually be relatively simple. We could add a new type of report that works exactly like the Order Cycle Totals By Distributor report, but which also splits the aggregation of products by the shipping method on the order, as you suggested. The reason that we just have “shipping method” at the moment is that for aggregated reports (by supplier or distributor) the aggregated products can have different shipping methods associated with them (because they are from multiple orders). I would estimate that we could easily set this up for you in about a day, though again, that time would need to be paid for.

I hope that is useful. Let me know what you think. :smile:

Great @oeoeaio, thank you for this detailed answer!
Thanks you for those ideas and explanations, our visions are for sure aligned :smile:
This is also connected to this discussion Product supply chain tracability and the contact I had with Provenance (ping @johba) … but anyway, as you see, we need to be able to fund that before going further, but that’s something we could emphasize in the funding applications we will make in France :smile:
I will come back to you when we are on it to ask you maybe for an estimation., I guess it’s a pretty big job…

For the report point, thanks for the info as well, and budget (one day), so if the hub we mentioned need that we know how much that will cost if they need that report, so again, I’ll come back to you when we have the budget for that :smile:

Ping @Selmo for info in your future exchanges with Jean-Marc :slight_smile: