Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implications of scale of order_article.units_to_order limited to 3 decimals #72

Open
twothreenine opened this issue May 26, 2024 · 1 comment
Labels
low-priority Minor issue with little consequences specification required
Milestone

Comments

@twothreenine
Copy link
Contributor

twothreenine commented May 26, 2024

from our discussion on #42:

[...] this would also result in (a) additional decimals being ignored [...]

Is that really a problem? I think we need to consider the use cases leading up to the "fax" export - I wasn't in the project when this was designed - here's what I guess:

Use case no. 1 (and the only one I can think of - do you have more?):
"As a foodsoft user I want to send the list of articles ordered by ordergroups to a supplier for them to be delivered."

We have to consider the use case of automatically sending the order to the supplier, either by end action or by clicking the button "send to supplier," but without taking a look at how the fax PDF looks like. Which means the order organizers might not be aware of such a problem.

I noticed the scale is limited to 3 decimals anyways:

t.decimal "units_to_order", precision: 8, scale: 3, default: "0.0", null: false, comment: "stored in `article_versions.supplier_order_unit`"

Suggestions:

  • add a hint (in a tooltip and/or documentation) that the collective order amount will be rounded to 3 decimals and the supplier order unit should be chosen accordingly
  • or add such a warning only for when a user tries to set a group order granularity that could result in such a case, like 0.001 x g with kg as supplier order unit, or due to conversation factor (e.g. 1 x kg with lb as supplier order unit)
    but I think that would be too much effort for that rare case
@lentschi
Copy link
Contributor

lentschi commented Jul 5, 2024

@twothreenine Good thinking. Where would you add those warnings?

It's obvious to put them in the release notes and documentation at least.

But other than that?

  • In the article master data form?
    Pro: Easy to display as a warning under some field (Which one though?). Will probably be seen.
    Con: That one administering the article data might be someone else than the one sending the PDF. 🤔
  • Tooltip on the send button?
    Pro: Right where the trouble might arise.
    Con: Who waits for the tooltip to appear?

Maybe the best solution would be turning the one-click solutions (end order, send button) into one with a preview that includes the warning, if any values had to be rounded. But that would also be the solution requiring the highest effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low-priority Minor issue with little consequences specification required
Projects
None yet
Development

No branches or pull requests

2 participants