Inception session: delivery note


First inception session regarding icebox item: Make OFN invoices legally compliant

A- What are the problems/needs

  • Jane orders things to Mary
    • Jane doesn’t see clearly the difference between what she orders and what was invoiced for.
    • Mary cannot issue a legally valid invoice to Jane in OFN
  • Mary orders things to Fred
    • Today this doesn’t happen through a real order tracked with an order number in the system, it is only managed by an automatic email sent (“notify producer” button).
    • Also Mary cannot see clearly the difference between what she orders and what was invoiced for.
    • Fred cannot issue a legally valid invoice to Mary in OFN
  • Jane orders things to Fred directly
    • Jane doesn’t see clearly the difference between what she orders and received / paid for.
    • Fred cannot issue a legally valid invoice to Jane in OFN
  • Jane orders things to Fred through Mary
    • Today this is not possible as the hub needs to collect the orders and make the aggregated order to the producers. No other process (like cart is split in one order per customer) is possible. There is only one type of order cycle, this would require another type of OC.
    • This would also require another invoicing system where Jane received invoices from Freds and not Mary. Not possible today.

B- What is the workflow

C- What are the possible differences between order and delivery note?


D- Two types of Order Cycle: what do we want at product level?

Today only OC type 1 exists.
To make it clear OC type 2 is: Mary organizes an OC that aggregates offers from various Freds, but transactions are directly from each Fred to each Jane, Mary is only a facilitator and charges directly Fred and/or Jane for her services. Mary doesn’t make any order to Fred, she only “notify” Freds of what have been ordered to them.

Some people have expressed the need for OC type 2, some even believe it might be the most common case.
We need to open a conversation within the community and really investigate if we want to support: only OC type 1, only OC type 2, or both.
This will have implication on the work to be done for delivery note, among other things.

In order to move forward we propose you to investigate in your own instance the need for one or both of those OC. @Kirsten @sstead @tschumilas @nick @lin_d_hop @CynthiaReynolds @Rachel @rbarreca @KatTheFarmer @sauloperez @enricostn

E- Next steps

1- Each instance curator investigate the need for both OC and share views on that.
2- Meanwhile we can already move forward on a first story which is “create the delivery note for an order”. Because whatever type of OC we choose, we will need that story to happen and we can already start with the existing OC1 case. This implies UX work (views on how users fill in the info on product received). I create an epic so that @Rachel and others can start working on UX.

F- Notes for later

In the workflow we will introduce a new type of order which is the BtoB one (Mary to Fred). We need to build a workflow around it, and need to see how we manage Fred’s order cycles to enable Mary to order the aggregated amount to him. For instance when OC closes Mary could receive an email with “OC closed, do you want to send your order to the producers? See / Send”.
If we decide to enable OC type 2, at OC level Mary should be able to say if it’s an OC type 1 or 2, so that the orders are made accordingly (issuer and recipient change) and of course we need to imagine the worfflow, like when OC closes, Mary receives email “OC closes, do you want to notify producers?” and producers receive info of aggregated orders made directly to them + can see details if needed.

Make info on quantity ordered/delivered/invoiced/voided/paid accurate and improve packing operation efficiency
Suppliers can easily invoice resellers for what they deliver
Trace order amendments through invoice lines and generate legally compliant invoices

Just making sure I understand @MyriamBoure - is it fair to say that in Option 2 - Mary is a ‘broker’? In other words Mary does not ‘take posession’ of the product, and does not take money for the product that Jane buys. She facilitaties/brokers the sale beteen Jane and Fred. So mary’s payment is for this brokerage service.

If I’m correct - I think it is powerful if OFN can offer both option 1 and 2. Modification for brokerages opens up a whole new potential user group in OFN-CAN where this model happens frequently.

To your question - right now, all our users use Option 1 because that is the only option. BUt, I know of at least 5 potential users, who would have become users if Option 2 had been available.

I also want to say though, that for me, Option 2 is really only useful if we open up the potential for Mary to facilitate shipping/delivery from Fred to Jane. Without this - Mary still needs to physically aggregate (take posession of) the product - doesn’t she?


We can say that @tschumilas, yes. And yes in option 2 Mary still has a role of organizing logistics for Fred and Jane, I don’t know if that is include in a broker role but that’s what happen in real life for option 2 Marys, they both organize sales AND logistics, so in that sense she is a hub. I always define a hub as he entity that organize sales and logistics between producers and consumers.


Been thinking about this a lot - so I think there is a key difference between an invoice and delivery note issued by Fred to Mary; and the invoice and delivery note issued by Mary to Jane.

The delivery note from Fred to Mary reflects the products from a single supplier. Fred includes his business details… and he includes which of his products he actuallly delivered. So he notes if he deviated from what was ordered. On that delivery note there is a single supplier and multiple products (some preordered, and some potentially not preordered)

In comparision when Mary prepares a delivery note and invoice to Jane - Mary needs to list multiple products from multiple suppliers. In Canada, these suppliers are usually identified. The legal requirements for an invoice state that the invoice must describe the products in a way that the buyer understands what they bought. So, in Mary’s food hub - it could be that multiple suppliers supply the same product (ie carrots). So the delivery note from Mary to Jane must list the name of the supplier and not just the products - because to be legally compliant, the buyer must be able to identify each product on the invoice. They can’t do that without the suppliers names. See my point?

I know we have lots of inception around this still - but I wanted to make sure I document this concern for when we do.


Should we have an Inception sub category in Product development @danielle @MyriamBoure ?


I’m not sure the “product development” section is still relevant in discourse, as implementation is in Github. We need to refine the process here before we decide what we do with it.


Yep I agree. I was thinking it’s nice to have one place to find all information about a feature in development like this one [FEAT] Product Import. But I guess we can cover all that in the GH Epic template?


The workflow in B seems actually wrong as invoice might not be directly connected to a delivery note, as some items might have been invoiced before delivery happens, other not, and orders / delivery notes / invoices have with one another many to many relationships, etc. Will explain later on, but wanted to alert.