Display of supplier order units like "Crate [of bottles]"

[twothreenine]

I'm not happy with this yet: Currently: Crate (10 l) Suggestion: Crate (20 x 0.5 l)

Or, in other cases I'd suggest:

-> Pallet (4000 x 50 g)

• if the group order unit were kilogram: Pallet (200 kg)
• if the group order unit were package: Pallet (400 x 500 g)

To summarize my suggestion: Supplier order unit name (amount x (only if piece unit follows) group order unit) amount: contained piece units' amounts multiplied down to the group order unit group order unit: if piece unit: replace unit name with its content in the first scalar unit following in ratios

[lentschi]

I'm not sure this can be generalized that way: If I read your request correctly, you want to make the display of supplier_order_unit depend on group_order_unit. However, in some parts of the application (e.g. the order pdf/csv sent to the supplier), the group order unit shouldn't matter (The supplier has nothing to do with that.)

[twothreenine]

That's what I meant, but I agree that in places like the order pdf, this could have unwanted results. Maybe just for those cases, it could be Pallet (100 x 4 x 10 x 50 g) (= all ratios defined down to the first scalar unit, regardless of the group_order_unit)? In case of very many ratios, would it break the table or just lead to line breaks?

It would definitely be more useful for the supplier to know if the food coop wants to order Crate (20 x 0.5 l) than Crate (20 x Bottle), and easier to read than Crate (10 l).

[lentschi]

Concerning the data addressed to suppliers:

Maybe just for those cases, it could be Pallet (100 x 4 x 10 x 50 g)

"100 x 4 x 10 x 50 g" does not really seem helpful to me. :thinking: Nobody would know what those factors meant.

Pallet (200000 g) is what the current logic would output and I would leave it at for those PDFs that rather than adding another algorithm, that doesn't really help anyone. What do you think? Alternatively we could omit any further details and just write "Pallet".

Of course, it would be best to have Pallet (200 kg), but unfortunately - as you know - our article unit sources don't link units by their common use. (The SI base alone usually allows for many units to convert to. We might however consider searching for the conversion to the smallest possible integer amongst those units added explicitly in our article units admin page. But that is something, we can move to post-PR, I believe.)

[twothreenine]

"100 x 4 x 10 x 50 g" does not really seem helpful to me. 🤔 Nobody would know what those factors meant.

A supplier who offers that kind of units should be able to understand it.

Pallet (200000 g) is what the current logic would output and I would leave it at for those PDFs

Pallet (200000 g) could also mean a pallet with a 200 kg big bag or 8 x 25 kg bags etc. Same with Crate (10 l), could be 10 x 1 l bottles, 20 x 0.5 l bottles etc. This should be less ambigous. I'm aware that if the supplier offers both 0.5 l and 1 l bottles, the article name has to be unique and therefore probably will reference the unit (like article name = Beer (0.5 l bottle)), but there could be cases where a coop only imports one unit option etc.

It could still be ambigous if a supplier offers e.g.

Chickpeas - 6 x 200 g can
Chickpeas - 6 x 200 g glass

Then, if a coop decides to leave out the can option and creates an article Chickpeas - Package à 6 glasses à 200 g, this will show up in the order PDF as Package (6 x 200 g) | Chickpeas, unclear whether cans or glasses are ordered. I'm not sure whether it would be worth it to always write out all units, like:

Crate (20 bottle x 0.5 l)
Pallet (100 box x 4 parcel x 10 package x 50 g)

This could lead to line breaks, but at least it would be clearer and unambigous 🤔

[lentschi]

A supplier who offers that kind of units should be able to understand it.

Then they should also understand the meaning of "Pallet of -insert random article name-" (without any further unit reference at all).

It could still be ambigous if a supplier offers e.g. "Chickpeas - 6 x 200 g can" vs. "Chickpeas - 6 x 200 g glass"

In that case foodcoops have necessarily added that extra detail about the distribution unit in the article name so far - eg. "Chickpeas, glass". With our new unit fields I still don't see a way to reliably and understandably avoid this. For what you want to achieve, we'd need yet another field in our article form: "supplier reference unit".

Or we just define that - for now - group order unit is used for that purpose as well - I guess in most cases it would be fine. (As I said initially, I find it confusing as it shouldn't have anything to do with the messages sent to the supplier, but short of adding another field, relying on the extra info in the article name or using article numbers, it's the only viable solution I can think of.)

Pallet (100 box x 4 parcel x 10 package x 50 g)

As I said, I really don't see that as a good solution. Not because of potential line breaks, but because we're sending an order for a predefined article and all everyone wants is to identify that article in their respective lists without reading a whole sermon. The best option to do so would be an article number, but short of that, the article names probably just should differ, if there's - say - pallets with different sub-containers, but carrying the same produce.

[twothreenine]

In that case foodcoops have necessarily added that extra detail about the distribution unit in the article name so far - eg. "Chickpeas, glass".

No, they might not have, if they only order glasses, as I tried to explain. Also, it is far from obvious that the package names from the ratios wouldn't be shown to the supplier, this would be something you'd need to remember when creating/editing articles. Further more, writing the packaging in the article name is redundant in terms of data if it already is in the unit name. It might even congest menus like the order menu with duplicate data (Chickpeas, glass | Glass | ...).

With our new unit fields I still don't see a way to reliably and understandably avoid this. For what you want to achieve, we'd need yet another field in our article form: "supplier reference unit".

I don't see why we should need another field. We'd just need to show the data we have. In my last suggestion (writing out all units), this would be Package (6 glass x 200 g) | Chickpeas.

Or we just define that - for now - group order unit is used for that purpose as well - I guess in most cases it would be fine.

That would mean, if the group order unit of beer is crate, it wouldn't show at all what content the crate should have? It would just show 2 crate, or if GOA is bottle, 2 crate (10 bottle) without indication which bottles.

The best option to do so would be an article number

Many small-scale suppliers don't use article numbers, we have to deal with this.

I'm really tired of suppliers misunderstanding units in orders and would strongly prefer "more information than necessary" over any ambiguity.

[lentschi]

No, they might not have, if they only order glasses, as I tried to explain.

If the supplier only sells glasses, there's no need for the disambiguation. Just send "Package | Chickpeas" then. If they do sell cans as well, but the foodcoop just doesn't have them in their copy of the article list - well then the two parties have to communicate and find a solution that avoids misunderstandings (e.g. adding the detail to the article name).

I don't see why we should need another field. We'd just need to show the data we have. In my last suggestion (writing out all units), this would be Package (6 glass x 200 g) | Chickpeas.

Yes, but applying this same logic to an article with more ratios would lead to the Pallet (100 box x 4 parcel x 10 package x 50 g) problem, which I'd really like to avoid.

Also, I'm not sure, what exact fields you were assuming for the Chickpeas sample, but I think currently it would print "Package (6 x 200 g)". So all that's missing is the "glass" part. We could easily add a flag to the formatting helper, that allows adding units to all existing factors in the brackets, if that would help? (This flag could then be passed for order fax e.g. - But does this really depend on where the unit is displayed? For the glass/can case this disambiguation might be required throughout the application, right?)

Anyhow, I think this debate between us two has gone too far - this is something we should discuss upstream - maybe everyone agrees with you, then we can still add this algorithm. :smile:

---

I declare this issue to be only about what you addressed in the very beginning of our discussion: The display of supplier order units everywhere in the application but in the data sent to suppliers.

This should be fixed as proposed by you in PR https://github.com/foodcoopsat/foodsoft_hackathon/pull/74 - please review! (The test cases there should enable you to check if this is really what you intended. Feel free to add a PR on top of this to point out edge cases/errors that I may have overlooked.)

For the remaining issue of unit formats sent to the supplier, I've created #75 as a follow-up.