i am looking at ofn for our buying coop. it seems like there isn’t sufficient support for the process of consolidating BG user orders into a wholesale order, and then updating the BG user orders once the wholesale order has been placed (and later, if the wholesale order has adjustments)
here is a short example: say there are 10 apples in a case (hah), BG user 1 wanted 3 (up to 10), BG user 2 wanted 5 (up to 7). so, the BG manager decides BG user 1 gets 4 apples and BG user 2 gets 6 apples.
issues:
-
how to show how much of each case goes to each user. if the BG user order has been updated to reflect this, then their order could be used by the split team when packing their food box. right now, (in our own system) we use split sheets that show the BG manager’s decisions and generate a packing list for each member’s box.
-
if the wholesaler only delivers 5 apples. we need to able to update each BG user order based on what they received. the requirement here is that the process to update BG user orders from the wholesale order needs to be able to be run more than once (namely twice ordered and actual).
-
if they were nearly all bad apples, the wholesaler gives a credit for 80% of the apples. it would be nice to adjust the wholesale price instead of editing each BG user’s order. in the two user example, this seems trivial, but in our co-op, there are 30 members and often 30 products ordered. it could mean adjusting 30 orders.
just quickly scanning and not fully burying my head in this, just wanting to make sure you’ve got relevant links to check if is covered / discussed elsewhere . .
-
check ‘bulk order management’ - scroll down page at https://openfoodnetwork.org/user-guide/producer-set-up-guide/view-orders-2/ to see it, including video, and also check Bulk Coop Totals by Supplier report here https://openfoodnetwork.org/user-guide/producer-set-up-guide/reports/
-
i wonder if this is covered by bulk order management, or is the issue that you need to retain the info on what they ordered in the first place? You can update the orders as many times as you like, but you would have to have saved reports to keep record of previous states (as far as I know)
-
yep I’m pretty sure that’s a new case / feature
hi kirsten,
thanks for the links. i had a look, but i don’t think the bulk orders are the same thing. the issue for buying clubs is that one case is split among members. conceptually, you could think of that as one product (a case) being turned into another product (eg, individual apples). this is the crux of the difference i think. the buying club has two types of orders, one made to wholesalers, and one made by members to the club. if the club did not split cases, it would be way simpler (probably even an exact fit to current functionality)
as an aside, the stock management features in later versions spree/solidus do allow you to manage stock transfers in ordered vs received, so that would give you a record for item 2.
I’m still a bit stuck on the functionality needed here - because it seems like the buying groups I’ve set up on OFN do this. Can you post or send me a picture of the model you want to use? The ones I’ve worked with on OFN work like this:
a coordinator (the hub/club manager) sets up an order cycle listing whatever products are available from how ever many suppliers (they can use the min-max feature on OFN to facilitate ‘filling’ cases when the order is placed.) The coordinator sets whatever fees are added (if any).
in the ‘outgoing’ section of the order cycle, the coordinator creates as many different buying groups/sites as needed (could be different locations, or different products avaialble, or have different delivery/pick-up fees…)
When the order cycle closes - the platform aggregates orders from the buying groups and will automatically send emails to suppliers or not. The coordinator can then downoad the details in different reports - such as: orders for each buying club, or orders by each distributor etc. So the coordinator places the orders with the wholesaler.
After the coordinator receives the bulk packaged products, they (or the buying club coordinators) use the reports generated by OFN to split apart the cases. They could pack individual buyer orders at this stage - or they could deliver bulk buying club products and then the buying club packs individual orders. (Or members come and pick their own order…)
Can you tell me what I’m missing with your model - maybe I can help.
@MyriamBoure has set up buying clubs in France too - discussed at this link: Use case: modelizing an international buying group
i think i described it as succinctly as i could in the last message. when you split cases, you need to have more functionality. OFN may be great for the other parts of the supply chain, but it does not appear to handle splitting cases and transferring a supplier order into downstream orders.
but perhaps it is just not apparent to me how it is handled. the video that @wvengen posted is very close to our exact process. https://vimeo.com/145927538
i just figured out the min-max feature after you mentioned it. (https://openfoodnetwork.org/user-guide/advanced-features/group-buy/) - but i don’t think it is enough. we need a multiple of cases, eg we cannot order 1.2 cases. or course, for some things we can buy where don’t split, this is no problem. or if we can order a partial case, but this isn’t the norm. (EDIT: i stand corrected, see post below)
@MyriamBoure’s post is interesting too, but i think it confirms that she is not splitting cases, this is done in ‘small buying group’
@tschumilas - i see what you meant after i watched the video in the min-max feature: https://www.youtube.com/watch?v=k5dSzhGrkwo
i will try this out on my test OFN and i can see how you say this works for your buying groups.
one concern is deleting the item from the member’s order because there isn’t sufficient quantity - totally understandable from a technical point of view, but it would be nicer if it explained there was not sufficient demand or something like that. it is also quite a manual process, which is fine. the nice thing about foodsoft is they do this automagically - although i am yet to understand the rules they use to decide who gets what.
anyway, thank you for pointing me at this.
agree that deleting an order for something when there is insufficient quantities is problematic - pain to do and not great ‘service’. In one of the hubs I operate now (at my work actually) - I have to do this regularly because we are just starting and our orders are small until we get more people. So - I’d rather not have to constantly issue refunds - so I’ve set up a ‘fee’ that is ‘pay once order is confirmed’. So no one pays in advance. I adjust the order quantities as necessary and prompt OFN to re-send the invoice to the buyer. Right now there is no way in OFN for me to then automate an on-line payment after I’ve mucked with the order (at least I haven’t seen it). So - I just direct people via email at this point, or askt ehm to pay at pick-up.
in theory, spree can recompute the order total. you can issue a refund/RMA adjustment, or you can credit the member (if they are a ‘customer’). but i’m not certain how that works in the version of spree that OFN is built on.
in general, there are further issues that i alluded to in another post, like spoilage adjustments or less product arriving than ordered. this is why the typical buying club process is to invoice people after the order has arrived and any adjustments made.
@enricostn I’m sure you are also concerned by that discussion, @paroga also you might be interested to discuss.
Today there are ways to manage that in the OFN, but as you say @carchrae this needs to be improved to really meet the buying groups needs. @enricostn needs that for his Katuma project in Spain, maybe you could work together on spec? 
I think though this could work with the variant option, like if a wholesaler have a product which is Apple Case, the BG can createa variant and only propose those variants of the product to their members so sell Apple by kg.
The piece of feature missing I think is the correspondence between the variants, this is connected to that issue: Quantities "on hand" adaptating when variants are a sub-product of the main product
So we need to be able to say that a variant is a “sub-product” of a given product so that the quantity available for the product adapt, and so that you can also adapt to the buying group case here to have full cases sold.
thanks Myriam - @carchrae - I should have mentioned this - in one of the buying clubs I set up (it was only a demo, so I forgot about it) one BG wanted wholesale quantities, and the other wanted individual consumer quantities - they were linked to the same ‘coordinator’/food co-op in one order cycle. I created 2 different products: for the wholesale BC - they listed apples by the case. For the ‘retail’ BC they had apples by the kg - and with the min-max feature. Of course this meant fiddling in the backend when the orders came in. Good catch @MyriamBoure
one issue with using variants to represent apples vs cases of apples, is that inventory won’t be tracked accurately. it can still be useful to for producing invoices/etc, but you need some manual steps to link the case to the sub-product (apple) - but i see that @MyriamBoure has detailed that in the issue she linked ( Quantities “on hand” adaptating when variants are a sub-product of the main product )
there is actually a spree plugin that allows a product to be made up of other products: https://github.com/spree-contrib/spree-product-assembly - but i’m not sure how it would work here or if it is suitable. we did have some issues with it not tracking inventory as you would expect, but it was very useful for us when creating ‘packs’ of mixed products. to be clear how this could help in the “sub-product” issue, you could have an assembly (case of apples) that requires X parts (apples, or bags of apples, whatever is in the case) where X is the case size.
but i’m not sure that plugin is entirely a good fit. the use case here is quiet different: we care about determining upstream demand (cases) from downstream demand (member orders). the plugin was designed to ensure downstream orders can be filled based on upstream inventory.
i often find that being clever with how you model something gets you into trouble later. it does not stop me wanting to try that though - sometimes it works, but sometimes it won’t be perfect… and it can end up being more complicated in the end.
@carchrae - your description of upstream/downstream elements here has given me greater clarity on this - thanks for that. I see now what you mean by split sheets - and hopefully more OFN buying club work will get us there.
One thing you make me wonder though - One item on the Canada wishlist is a ‘box builder’ - that gets us closer to some CSA optimization. See Box builder
Would the product assembly plugin be this do you think? As I understand its use: As an OFN user (hub coordinator, CSA farmer) I want to be able to assemble a mixed product basket from items available in various suppliers (or just my own) product lists in a given week. As orders are placed, I want this assembly to disassemble in a way - so it can count down individual product stock. Does this plugin do this?
