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 @NickWeir @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.