Product prices with up to 5 decimal places or more

#1

(I’m not sure if I should be going through another process before raising a specific feature request, so let me know if I should, as I’d be happy to talk more about the context that let me here)

What is the need / problem ?

Product prices are limited to two decimal places (at least in the Australian instance with AUD).

I’ve been investigating whether our bulk food cooperative would be able to function using the Open Food Network. We buy food in bulk in advance, and on distribution days people fill their own containers and pay for the exact weight (to nearest 10g) of product. As OFN cannot record quantities in decimal places (see Allow non integer quantities to be ordered), I’m considering setting up 1g products (easier to manage than 10g). Setting up 100 variants for a 1kg product seems impractical.
For example product is $4.45/kg, which is $0.00445/g. OFN will automatically round this to $0.00/g.

Who does it impact ?

Anyone attempting to sell very small ‘products’ in this way, that is, selling by weight.

What is the current impact of the problem ?

As the product price is rounded, it’s not possible to sell with the correct price.

What is the benefit of focusing on this ?

Allowing bulk food cooperatives such as ours to sell and track inventory with accuracy.

Potential solutions that will solve the problem ?

To cater for any currency, I think the general solution would be:

  • Product prices may allow any (reasonable) level of decimals
  • Order line items are always rounded to the current currency

This is my first post, so I’m guessing I leave the below sections to be filled in later.

Selection of a feature candidate

[value x ease matric if needed]

T-shirt size of our selected feature candidate

Metrics to measure if need is satisfied after feature is implemented

Feature owners

Epic/projet where you can follow implementation


Connected wishlist and discovery discussions*

[list precedent discussions]

#2

Hi @dcook !
Thanks for your suggestion :slight_smile:
I would suggest instead of proposing straight away one solution, you stick to your need and then we can start listing various possible solution and compare them to see which one would be the feature candidate in that case.
Your need is that you want to be able to adjust exactly the weight of a product received by a customer and that the price adjust accordingly. Right ?

If that is your need the good news is that it’s already possible :slight_smile:
You would then set up a product in grams, with one variant per most usual weight (ex: flour 100g, flour 500g, flour 1kg) people choose what they EXPECT to take on the reception day with their own container.
On the D-day they bring their container and take a different quantity. You can in “bulk order management” just adapt the quantity ordered with the real one and it automatically adjust the price to the g.

This is documented here : https://guide.openfoodnetwork.org/basic-features/view-orders#example-2-updating-the-final-weight-of-products

Does it help ? Else if I didn’t understand your need, please specify and when we undersdtand clearly the need let’s start brainstorming various solution to solve it :slight_smile:

#3

Hi Myriam, thanks for your idea.
I actually did consider doing this also, however this would be too much extra work for us. We actually don’t take many orders in advance, most is on the day, so it would mean a lot of time to create the order (usually with 5-15 products, all by weight), then adjust again for each product.

Ideally we would have the bulk order function when entering an order. But I’d also like to make us of inventory, which is not updated by this function. So I thought I might be better off sticking to the native product units. But of course, if it’s realistic I would would be happy to have this developed instead!

Here’s my investigation and thinking if you’re interested: https://docs.google.com/document/d/1jgIu84GfbD-1AyjG1cHzWIeE1kivyK96w42PRKvyKdU/edit?usp=drivesdk

I think our food co-op isn’t quite a good fit for OFN, but I was hoping with a little work it might be, and for other food co-ops to join.

#4

You have onsite sales only @dcook ? People don’t order online in advance ? If that is the case, then it is a POS system that you need (Point of Sale), which is not what is OFN indeed. We would like to integrate with POS but we are not a POS. I see that you considered that somehow in your analysis. But again, can you specify clearly what your need is/are ? Without starting to mention solutions. Just understand the need :slight_smile:

My guess would be : you need to record onsite sales without having to pre-determine the weight of the product sold, you want someone who take 235g of mushrooms to weight and record this so the per kg price apply and this person pay what she needs to pay.
Is that your need ? Or else what is it ? If it is that, yes, you need a POS system, eventually connected to a scale. Hopefully one day OFN will be able through integration to manage that, but we are more focusing on online pre-ordering/sale as a first step.

#5

You’re correct, although we don’t function exactly like a shop, a POS system could be a better fit.

I’ll consider other options.