This has now been requested by a new UK user. Low priority but we might start to think about it so getting conversation rolling…
It would be nice for producers/hubs to be able to set a minimum order on their shop/products.
In it’s most simple incarnation a user would be restricted from checking out until a minimum value on the order has been reached.
Producers will more likely want hubs to reach a minimum order through them before they will deliver. This will need to feed into the ‘Notify Producers’ emails such that the email is not sent if the producer minimum order value is not reached. And this will need to be configurable at the hub and producer level.
I can also imagine certain products having a minimum on them.
The group buy functionality provides a clever way for users to circumnavigate this to a degree already. But the group buy functionality applies only to products.
@NickWeir is this a feature Audcious Veg actually want? Or just something they found and wish they could use?
Audacious Veg wanted to use it but they are not putting any money up and they are happy to wait so it is definitely not a priority for them. I think it will be very useful for Stroudco wholesale but I will leave it for @Oliver to comment on how he would use it
I can certainly see the benefits. For example a wholesale customer may be asked to order a minimum of £x / x kg. Even on a normal hub activity it could be useful, if we don’t want to set up a customer box for a marginal amount of income. Equally I could think of uses for having a maximum order level on individual products, so to allow each member only a certain amount of a limited availability item.
We have also a case in France of a hub who want the customer to buy for a minimum total of x€. I imagine that, as you say, as a set up at the hub level to tell if there is a minimum amount require for the order, and if not reached when the customer click on checkout, a pop-up tell that the minimum order amount of X has not been reached yet (text should be translated/adapted by the instance on transifex)
For the producer case, I feel a bit uncomfortable of having an automated process through the notify producers button, as I guess it could be a discussion with the producer, who might expect an order, so just not sending the email might be a bit rude. I guess if a producer has set up a minimum order amount and it’s not reached in the order cycle, he could receive the email from the “notify producer” button (NB: for the moment we don’t use it in Norway and France, we don’t find it clear enough, I will open a seperate conversation on it), but he should have the option to decline the order. I’m not sure until where this can/should be automated… as then it means that all the orders need to be modified and recalculted, some voids may need to be done, etc.
Just wondering if there is any further thought on this - seems like you @MyriamBoure@Oliver@lin_d_hop have had the request - but not a priority. This request has come up from a number of hubs in CAnada and I am putting it on the Canadian wishlist. It seems like here, it is the smaller scaled hubs (maybe only 20-30 buyers and 5 suppliers) who are most interested in OFN (larger hubs tend to have proprietary software in place already) - and it is these smaller hubs that are asking if they can set order minimums. So where a consumer must order $30 worth of goods or else there is an added fee for delivery (for example). So they don’t want to stop the order - the just want to reflect the added costs of small orders. Has your thinking progressed on this? Is it still a ‘nice to have’ but not essential for you?
@tschumilas you can already do what you say thanks to the calculator’s option when setting up an “shipping method” fee I think you can vary the amount of the delivery depending on the total of the order So you can say that below x$ there is a fee, and 0 above
But the “minimum orders” feature that remains needed is : if you order less than x, you get an error message saying “you need to order at least for x for you order to be processed”, or something like that, that certain hubs want.
yes - the price sack. So here I am having a problem - I have used price sac as a shipping method - so it shows at checkout - not in the shop. So if a customer buys an order under $25 (for example) there is a $10 delivery fee, if they order more, there is no delivery fee. This is good.
But my question is about suppliers delivering goods into the shop.
If I add a delivery/shipping fee to a supplier at incoming - it shows up to the buyer at checkout. Because all delivery/shipping fees show up at checkout versus in the shop (I think.) BUT - the price sac calculation applies separately for each individual customer’s order (versus the collective order that Garden Party has to deliver to the hub.
AND if I use a E2E ‘transport’ fee at incoming (shown below) - then the price sac ‘normal’ amount shows up in the pie with each of the supplier’s products (because the cost of each product is under the minimum order amount).
So - the only solution I see is for a supplier to calculate a E2E transport fee as a percentage - and have it attached to all products, regardless of the total size of their delivery to the hub that week.
Hum, yes, I get your point @tschumilas , the producer needs to deliver enough quantity for the transport to be covered.
As you say ther are different ways to see that.
1- The producer can say that below a total order of X he doesn’t want to worry about it, not interesting (even if transport is paid, because he has job to prepare the order on his side and maybe if it’s a super small order it takes more time than the money he gets anyway). This is a feature that is also asked by some potential big users in France. I was thinking it would be possible to add on the producer profile a field where the producer can say what minimum amount of order from the hub he would accept… so if the OC doesn’t reach the threshold the hub manager can be notified for example. But I guess this can be then handled in the relationship with the hub, if the hub ask a producer 2kg carrots, the producer says no, the hub can just cancel the product in bulk order management and adjust the order total amounts accordingly for the orders impacted.
2- The producer can include a % covering the transport in his product price that applies to all products. Ideally for transparency the % won’t be directly in the price but the hub who pays for it would add a % in the incoming section, like 10% for example to cover transport cost. Maybe the producer has a fix cost for transport, in that cas I would suggest the hub estimate the sales and apply a % on the products so that he spread the cost on all the buyers. That’s what I have been doing when running my buying group in Oslo.
3- Or the hub can manage the transport fees more globally for his hub, and depending on his margin, charge if he wants a different transport fee depending on the total amount of the order. Like instead of applying 10% transport fee on the producer, the hub can apply 5% to all products for transport fee to cover the transport cost. The hub can decide to charge transport fee “real”, so if a producer is further the products gets more transport fee. Or he can consider that more isolated producers should not be too penalized by being so far and “spread” the transport fee on all products…
So for me the transport cost needs to be discussed by the hub with every producer but then it’s the hub who needs to include that in th price and pay the producer for the transport, I guess… Or the producer sells the products including transport and integrate it in the price.
But I’ll be happy to hear other voices on that and learn from others
Maybe @sstead would have interesting inputs on that?
@tschumilas I think the price sac on shipping solves half of your problem. Regarding supplier transport fees, I agree with Myriam’s suggestions above.
Regarding your comment “If I add a delivery/shipping fee to a supplier at incoming…” Yes, remember fees applied at the Incoming section still apply to the customer’s order. There are no fees in OFN charged from a producer to a hub, they are always calculated and applied at the customer’s order
I can’t imagine a perfect feature which would automatically apply a shipping fee up until the hub’s total order reached a certain dollar value (the free shipping threshold). In this case, the first few customers in the order cycle would all be charged the shipping fee. The fee would get smaller and smaller as it is spread over more customers. Then when the bulk threshold was reached, future customers would not pay this fee. The early customers would need to be reimbursed. ? is there another way to achieve what you need?
I tend to think manually managing these decisions of whether to source from a supplier when the hub hasn’t reached the free shipping threshold is better (the hub can make the judgement call of whether to order a little more, or not order, or cop the shipping fee). Also small hubs here often plan to have fewer suppliers, specifically so they can reach the free shipping level. Caveat, I don’t run a hub so could be wrong.
thanks @sstead and @MyriamBoure for your help. After some experimentation I was just going to get back to this hub today and tell them pretty much what you’ve said. There are several ways that OFN can be set up to have buyers/consumers ‘share’ in the transport costs to the hub - and make their contributions transparent, but OFN doesn’t handle ‘pre-hub’ fees directly. This hub is a producer-consumer cooperative - so they want the shipping costs shared by both. But I think they need to handle the producer transport costs outside of OFN. This would be easy if they could isolate the transport fees that the consumers (collectively) paid in a given cycle.
But I can’t find a report that does that? But maybe I don’t have enough ‘fake’ reports there to see how it would work. Are there reports (could there be reports) that identify E2E fees in a cycle?, then they could just lift those costs out to invoice producers
This would be a big help to them. Basically they are a hub that uses FoodSource now (the evolution of the Oklahoma software), and they are a real opinion leader among other hubs, they cover all of Northern Ontario - big distances (actually the size of France @MyriamBoure - sorry we Canadians can’t resist a little ‘bragging’ about our vast geography - helps us forget our challenges.)
I’m on a panel at a co-op conference with them in March. On this panel we will take their ‘case’ and look at how 3 different platforms handle it. So they are presenting how FoodSource handles it, I’ll show how OFN handles it, and I’m not sure, but the third is a pretty new proprietary package that I don’t know much about.
I’ve made it sound like a ‘competition’ and that is wrong - their spirit and ethics are totally on program with us. They are thinking of shifting to OFN because they like our global reach, and they think it is easier for new food hubs to get started using OFN. So - if we could solve their issue (producers and consumers sharing the delivery to hub costs) - with a report that isolates EtoE fees - I think they have money to contribute to the development. The other features they would like (that we don’t have)…
CSV upload of product lists
possibility to calculate fees based on km distance (same problem as above - how to distribute that evenly in the shop’s list)
smoother interface with other accounting package (I think they use quickbooks)
split payments
(any of which they would be paying to have developed now anyway - and it is appealing if their devleopment dollars are leveraged by our global arrangements)
So - this is why I’m working closely with them (plus if I learn their complexities in OFN - I’ll truly be worthy of the ‘super-admin’ title
@Theresa I’ve just had a look and you’re right, there is no report which itemises Enterprise Fees. If a hub has a single enterprise fee applied in the OC and a shipping fee, the ORder Cycle Customer Totals report could be used to extract the total fees paid, split out as Enterprise Fees and Shipping Fees. However, if there are >1 enterprise fees applied, this report will only give them a single total figure of enterprise fees, making it hard to know who is owed what. I’m a bit surprised no one has bought this up yet…but I think Enterprise Fees are usually applied by the coordinator to themselves, so detailed tracking of the fees hasn’t been necessary yet.
Note that from my non-dev understanding, reports aren’t super complex to develop… might be 2-4 days of dev time, making it relatively affordable (depending on how you define affordable :))
Here’s what I know about the other features you mentioned… CSV upload of product lists - This is a priority feature for the UK and is in the pipeline to be delivered in the next 6 months (by my understanding). It’s already been speced by Lyn, have a chat to UK for an update. Possibility to calculate fees based on km distance (same problem as above - how to distribute that evenly in the shop’s list) - As far as I know this isn’t in the pipeline. Smoother interface with other accounting package (I think they use quickbooks) - The Xero report offers a basic ‘integration’ with the Xero accounting package. If this is the level of integration they want it would not be super difficult to achieve (again 2-3 days for a report once the devs have a clear spec of what the report needs to display). The Xero report essentially allows a hub to upload their customer’s (not suppliers) invoices into the Xero accounting package so that their accounts receivable department can follow up on payments from Xero not OFN. It doesn’t handle ‘accounts payable’ invoices owed to suppliers. Split payments - This is a priority for many people. Mangopay is the tool that can accommodate split payments. It may be funded through a French project, but this is not confirmed (we’ll have a better idea by April). MangoPay service Europe, but not Australia. Would need to check if they service Canada. In summary, this tool is likely to be added, but when this happens will depend on funding, and whether MangoPay is supported in Canada is uncertain.
The panel sounds really interesting! Let us know how it goes, I’d love to hear how we stack up against others for different kinds of users
