Open twothreenine opened 1 year ago
Da wir heute darüber gesprochen haben: Stimmt, wenn man die Lager-Bestellung nutzt um eine Lager-Entnahme selbst direkt einzutragen, braucht es keine Unterscheidung zwischen supplier order unit
, billing unit
und Allow orders per ...
, da man die Entnahme in der Entnahme-Einheit eintragen würde. Supplier order unit
sollte umbenannt werden, da es ja keine Bestellung beim Supplier ist, sondern eine Entnahme vom Lager. Collection unit
vielleicht? Oder billing unit
, das könnte aber zu Verwirrung führen.
Eine Lager-Bestellung kann jedoch auch dem Usecase dienen, dass die Lagerartikel bestellt & in eine Kiste zum Abholen vorbereitet werden. Ich weiß nicht, ob es FoodCoops gibt, die das so handhaben, aber dafür wäre die Lager-Bestellung eigentlich passender. Dafür wäre die Unterscheidung schon wichtig (nur für minimum order quantity
sehe ich auch da keine Notwendigkeit) und supplier order unit
würde ich dann stock order unit
nennen.
Fixed by 67c0e3812b632aa14e5d55eec5b9fd8bd0cbf28c
Sorry, I think we do need Allow orders per ...
for stock articles.
I tried to create a stock article Rice which you should be able to "order" in 0.001 kg. I can't specify the group order unit though. I can't "deliver" a total amount of 24.5 kg as only full units are allowed, and after opening a stock order, I can only enter in full kg.
I think Allow orders per ...
should be set to 0.001 by default when a scalar unit is selected. It could get a bit tedious having to always enter 0.001 for every stock article you create and you could forget it easily.
An alternative could be to always allow stock articles with scalar units to be "ordered" in decimals (like 0.001 or even finer).
I'm not sure whether we'd need Allow orders per ...
then. Only if you want to allow orders like 0.5 pieces (example Bread) but then you'd probably switch to kg, or if you'd create a stock article Beer in crates unit with ratios and then want to set Allow orders per 1 bottle
. That would make creating stock articles out of existing articles easier. But it isn't really necessary.
@twothreenine
Sorry, I think we do need Allow orders per ... for stock articles.
I can see the use case for this, yes. But this isn't something that's supported upstream either, right? (There's no unit_quantity
field for stock articles - only unit
)
If so, I'd vote for moving this feature request to a separate issue for the Post merge milestone.
What's still missing in the scope of this issue however (to mirror the upstream behavior), is the limitation that ordergroups may not "order" more than what's in stock.
But this isn't something that's supported upstream either, right?
It isn't. However, I'd regard loose orders of stock articles as the no. 1 use case for any loose orders and it would be confusing for many users why this feature is omitted especially for stock articles (at first). I remember during the hackathon we agreed this should be included. And we would have the chance to test this in a public beta test. Of course, it's down to you to decide.
Note: In stock
/ available
amounts have to be changed to decimals/floats.
Unit-unrelated notes: I don't see why origin
and manufacturer
are omitted in stock articles. Also I'd replace the ban on price changes with a warning.
I remember during the hackathon we agreed this should be included.
Could be. However, I have to try and avoid implementing new features in this fork, sorry. (As discussed, this has already gotten out of hand :sweat_smile: )
So I'm leaving the issue open, but will be moving it to the Post-merge milestone (It includes things that will not be included in the initial PRs to upstream, but might still be included in the next foodsoft release by implementing them in separate PRs later on.)
For now, I've implemented some bugfixes for stock articles and the whole stock logic should at least work as before. (I've simply removed the number input fields in the group article form, so we don't have issues with decimals.)
Wenn die Logik passt, sollte sie auch für Lagerartikel übernommen werden.