add a property of 'supplier price' and a 'split' value

[carchrae]

our co-op, and i think many others, order cases of items from our suppliers. so, a case of 100 apples might be $50 for 100 apples. while we show the price to our members as $0.50 per apple and unit quantity (UQ) of 100, the supplier price is $50 and this is what must be communicated to the supplier when ordering.

i have written a bunch of scripts that convert the supplier price into a price per item, but this isn't ideal. i would prefer to have the original price stored and derive the co-op price from the original price / UQ.

here are some examples of the problems right now:

1. the rounding problem. so that the co-op does not lose money, i round the price up. so, if there are 66 pears in a box that costs $50, then price per pear is $0.7575757575 - or rather $0.76. now, when i compute the supplier price from my derived price of $0.76, the case cost is listed as 66 UQ * 0.76 = $50.16. the supplier may be confused at the price discrepancy. (and sure i can see how the coop can slowly get rich!).

2. if the price of the box changes, it requires more calculating to determine the food coop price. for example, say some of the fruit is spoiled/bruised, and the supplier says the box will cost $30, then we cannot update the case price, but need to do more calculating.

3. if the amount in the box is different, then we need to determine the updated cost based on the new quantity.

i propose that we add a 'case price' to the article model. this price can then be used when producing the ordering pdf/fax to the supplier. it can also be used when updating the costs of articles in a particular order.

[wvengen]

Wow, good practical cases that I recognize from other fresh-based foodcoops.
(1) Adding a case or box price would be great to solve rounding errors. Need to think how to present this clearly without clutter..
(2) and (3) perhaps this may become part of the receive screen, where differences in what was ordered and what was received are handled. Now only member amounts are taken into account, but this could also take article price into account. Since the order_article already has its own article_price, we can easily assign a new price to it (without affecting the article's price). Just need to make sure that it's clear from the UI why there may be different prices (e.g. message explaining or whatever).

[carchrae]

on 1) i'll try a few things and see what i can come up with. because i know a lot of logic depends on the current setup, i will try and keep the changes minimal.

thanks for the reminder about article_price - i will have a deeper look at the code and see how the received discrepancies are handled in the received/settling order pages.

for example, i like that you can put fractions in the amount received by a co-op member. but i would like it if i could edit the unit in that screen too - for example, 1 qty X 250g of dried mango, actual weight member receives is 272g. i can update it as 1.088 units (250*1.088=272g). i am inclined to make these kind of changes outside the model, for example, the UI allows you to computes the unit by entering a price (instead of using a calculator, like i just did)

[wvengen]

The unit is current part of the article - so changing that is not recommended (I've wondered whether that should become part of article_price or not). This can indeed be a UI-thing (the foodcoop-adam fork allows editing grams at some places, as an example.

[Nalaxon]

Hey there :)
Are there!
Any news about this?
We would highly appreciate such feature

@carchrae
How you deal with shipping costs? Would you put that in the box- price as well?
Currently we looking for a solution for that.

Thanks in advance!

[wvengen]

Hi, thanks for the question! My focus is first on getting foodsoft-shop done, then using the mechanisms decided on there to implement a toggle between piece/unit (whether to do that in Ruby or in JS+React, for example; there still is a little discussion on what way to go).
But then again, I don't find that many commits related to this, maybe foodcoop-adam@8ef46eb would be enough (too long ago to remember).

[carchrae]

you can check my fork. it supports supplier price. i would really like to find time to merge it back to master, i have many features and speed improvements to contribute back.

for shipping cost, it is a hack but you can use deposit for a fixed cost, or tax as s percent cost. i do need to make a new feature to split a shipping cost among orders. it is cumbersome to do that now. please make a new issue for that.

also agree with @wvengen. many features should be ui customization, not server changes. supplier price however does require an extra attribute.

[mischkl]

The feature for entering grams for articles that are priced in kilograms is desperately needed!

We are in the process of switching to FoodSoft and are confronted with the problem that there is no way to enter sub-1kg amounts for articles that are priced by the kg.

So far we're worked around this by setting the unit to 100g, but then the price has to be divided by 10 and gets rounded up or down in comparison to the kg-price - not good! Not only does the supplier receive an order form with prices and units that are not quite correct, but people who pick up their orders can't rely on the price as listed in FoodSoft since it always has a rounding error.

For reference I've also commented on #422, either solution would work for us. The sooner this feature can be provided the better! :)

[mischkl]

Also I see there are issues going back to 2014 related to this. foodcoop-adam#101 #209 #296

[carchrae]

@mischkl - you can set the unit to 100g and the unit quantity to 10 - then the supplier gets an order by a quantity of 1kg. on the rounding of prices, yes, you need to round up to stop your co-op from losing money slowly, and then the price to the supplier is wrong.

however, i agree that it isn't that clear to the supplier. i customised our supplier PDF to try to make it more clear to the supplier. i also added a property to store the supplier price. my version is a fork and is now out of date. i would like to merge the changes, but i have been very overloaded with my day job(s) (and then helping my coop is also a lot of work).

you are welcome to try my version, too. https://github.com/carchrae/foodsoft - if you are a programmer, it would be great to have some help merging some of the changes back in to the main project.

[mischkl]

@carchrae the problem is not that the supplier requires the units in whole kgs, we have been ordering in tenths of a kilogram for a long time. The main problem is that the price is rounded and therefore even the workaround of using smaller units is not a real solution.

[mischkl]

I am a programmer but also don't have much free time. I'd like to contribute but am honestly wondering what the solution is. It seems like with the number of partial solutions already hanging around in various forks for months or years, it should just be a matter of merging one. In my experience though this is usually up to the maintainers and not newbies to a project such as myself.

[carchrae]

yes, that was a problem for me too. that is why in my version i store the supplier price separately. if you don't want to use my version, another (painful) workaround is to edit all the prices before sending the order off.

there is another annoying rounding bug when it comes to received items. a case can often be a little less than it should be, eg, 200g less. if 1kg was ordered, that would be nicely entered as 'received 0.8' - which works fine. however, it doesn't always end up so nice, eg, 3 kg and you receive 200g less, then you have received '0.93333333333333333....' - it makes it harder to balance the order for accounting. minor, but adds up

[carchrae]

I am a programmer but also don't have much free time. I'd like to contribute but am honestly wondering what the solution is. It seems like with the number of partial solutions already hanging around in various forks for months or years, it should just be a matter of merging one. In my experience though this is usually up to the maintainers and not newbies to a project such as myself.

none of us have much free time. @wvengen has been amazing in terms of his devotion and gifting his time to this project, which @bennibu also gave a lot of time/effort to.

most open source projects have programmers using them who are employed by companies. i doubt any of us are employed by our co-ops - and indeed, it would probably make the co-op bust if they had to pay. so, i am afraid we are all DIY here.

however. i can say this is 10000x times better than the horrible ASP.net VB code that our coop had been maintaining for 15 years. there are still some big problems with this project too in terms of code/design.

so i say to you, give a little back, it is appreciated. or fork your own and then the next guy will make the same complaint as you. ;) (i am truly sorry i didn't merge all my changes back in)

[carchrae]

(i am truly sorry i didn't merge all my changes back in)

yet

[carchrae]

there are also some paid solutions; many of them ancient. i am not sure how responsive they are to feature requests, but this is actually a direction some co-ops may want to consider, eg https://www.managemy.coop/

i didn't choose that route because our co-op had a specific way of working that i wanted to support.