I’m working on a set up demo for a food system in the Northern part of Ontario. Distances are vast, so transport costs matter. This is a cooperative venture - they agree that consumers should share transporation costs because small producers can’t pay it all on their own. We have set up different ‘route fees’ that can be applied to products going into a central ‘hub’ . Then there are another set of fees for products leaving the hub and going out to different communities.
IF there is one coordinator and multiple suppliers and multiple distributors (classic set up) - I can apply the transport to the centre fees in the incoming section of the order cycle. But - there is no way(that I see) to differentiate a fee by product or supplier in the outgoing section . Any fees here, apply to all products in that distributor’s shop. So the effect of this is that - products that originate in the same community where they are sold - get a transport fee tagged on when they shouldn’t. The whole point in this cooperative is to privilege local products by showing them as the most affordable.
Is there a way to attach fees to either specific products or specific suppliers in the outgoing section of the OC (ie - for a particular shop/distributor only)?
My option B is to create a separate OC for each community - so that would mean creating 8 hubs - all carrying essentially the same products. I can give them all the same coordinator and then just do this by copying the OCs I suppose - so no duplicate entry. But doing this means the suppliers get notified of orders multiple times (for each different hub/shop) when the OC closes.
The second problem (in addition to the redundant transport fees above) is that they want to share the ‘mark-up’ /admin fees between suppliers and consumers. So - easy enough to put the consumer portion into the prices, but I don’t think OFN has a way of attributing a cost to a producer. I’m asusming this has to be done at invoicing.
Am I missing something here? This has been really cool to get my head around - very complex and egalitarian system they are setting up. I’d really like them to be part of the OFN- CAN community. @sstead
I’ve never used OFN in such a complex setting but I’m fascinated by this example of how it can be used.
Aren’t products that originate in the local community already cheaper because the transport from the producer to the hub would have been cheaper? But maybe I don’t understand the setup.
Yes that would be the case if products are only sold in the community where they originated. BUT I was hoping to coordinate multiple source communities and multiple distribution communities in one cycle. It doesn’t work. Because - for example - a producer from Red Lake attaches a fee to transport his potatoes to Dryden (where all product is aggregated and then re-distributed). There are 5 different communities (distributors) with shops in the ‘outgoing’ section of the OC. Each of them can of course add their own ‘shipping’ fees/arrangements. But none of them can adjust selected fees on products in the coordinator’s list. So - if I live in Red Lake, I see the red lake potatoes in the ship, and they have a transport fee (from Red lake to the central hub in Dryden) - eventhough, in practice, those potatoes never go on a truck. (The whole point for this user is to eliminate redundant transport costs). Potatoes ordered by Red Lake buyers would just go to the Red lake hub. But - in order for a Red Lake customer to order the potatoes - they have to be in the shop - and hence have the associated fees.
After playing with this more ways than I thought possible, I now think the only option is that EACH community where produce is distributed to must have its own, independent OC. That’s what I’m trying now. Then, the Red Lake shop will not put a transport fee on potatoes from Red Lake. But they WILL put a transport fee on Potatoes from elsewhere.
It works OK - but not perfect yet.
The key problem at the moment is getting a report to detail all the fees. I’m surprised there is no existing report that does this - how do you @Oliver or @sstead isolate fees? It seems funny that no one has had to do this?
Hi @theresa, yes unfortunately this is the case.I think the fees are modeled on the way food moves in a traditional food hub model. As in, producers have a fee for delivering goods into the hub. Transport out from the hub is assumed to be done by the hub, across all products.
I think your solution of having separate order cycles may be necessary, because food isn’t moving in this traditional way. Another option would be for the distributors to use inventory, and overwrite the price to be lower for customers who are local to the farmer. The price charged to customers further afield would be higher. Would that work? You might find it easier to not use a fee at all if you use this option, and instead just have one inventory price for stock going into the hub, and another for stock delivered to local customers. Managing this setup would be easier with inventory upload.
I thought about using the inventory feature - but the price adjustment is on the producer’s price. So we didn’t think the producer’s price should be lower if they sold to their local area. We think the transport fee should be lower. And in inventory, if the local hub ‘overrides’ the price for local product, they are changing the producer price, not just the transport fee.
I’ll check the git hub issue - good to know.
@lin_d_hop@MyriamBoure@enricostn@CynthiaReynolds - would anyone else find a report that isolates fees from an OC useful? This is something high on Canada’s wish list since many of our current hubs experimenting use complex transport arrangements to get goods into the hub. I’m kind of surprised this hasn’t come up before - isn’t anyone using third party (ie: not the hub coordinator and not the producer) transport to or from hubs?
