Errors when you enter the decimal values in the stocktakes

[santoshkhanal12]

What went wrong? 😲

Screen.Recording.2024-01-24.at.12.49.27.mov

Expected behaviour 🤔

1. No errors should be seen when the packsize is entered in decimal.
2. Should accept decimal packsize

How to Reproduce 🔨

Steps to reproduce the behaviour:

1. Open mSupply
2. Go to Inventory->Stocktakes
3. Click on Add Item
4. Select items
5. Click on add batch
6. Enter packsize in decimal
7. Click OK or OK & Next
8. See Errors (BUG)

Your environment 🌱

• Version:
• Platform:
  • android (tablet)
  • browser (extra points if you tell us which one)
  • desktop (windows)
  • desktop (macOS)
  • server (windows)

[mark-prins]

Until we know why decimal pack sizes are possible in mSupply - we will prevent decimals in pack sizes for open mSupply.

[CarlosNZ]

Until we know why decimal pack sizes are possible in mSupply - we will prevent decimals in pack sizes for open mSupply.

In the meantime should we update the front-end to only accept integer input?

[ujwalSussol]

Think we don't require Packsize to be of decimal points. #2797 (comment)

[Chris-Petty]

Some relevant discussion in HSH because we ended up having to support decimal pack sizes after initially gunning for integer in uploaded tenders from mSupply https://github.com/msupply-foundation/health-supply-hub/issues/637

Had some discussion on whether a pack can have fractions of units, or the number of packs can be anything but a whole number. Does this even make sense? Yes and no. Some examples:

• A product is commonly in imperial units, but has since been converted to SI resulting in an odd decimal value. (1foz = 29.6mL)
• pack size 0.75L vs 750mL. Either way is currently valid in mSupply, though the latter is recommended. You can't easily change the unit without messing up stock. (If you changed from L to mL, you need to multiply all historic stock lines and trans lines in mSupply by 1000. Or a big shift to making units stored on stock lines and trans lines, which isn't a bad idea. Huge migrations needed though.)

This is probably worth of a KDD, but I think we're sort of settled. Can make a one too if desired. In fairness, it isn't too different from currency KDD. There we decided to use Float type.

The difference here is that it's absolutely expected to provide decimal currency values. Here fraction packs is debatable. But, if anything you could argue given currency does it, we're not opening up to much worse issues we aren't already exposed to? Just more of it 😉.

This will affect migration of mobile and desktop data to open mSupply as well - open mSupply will fundamentally just lose data if we migrate a store on a system using decimal values for pack size. Reiterating the second point above, things that are in litres really cannot be easily fixed by converting the decimal L values to integer mL values, it affects all stock and transaction history throwing quantities and monetary values out of whack too.

@Gwalior-84 said there were reasons, IDK if they're the ones I've mentioned here so he should add them if they don't.

While HSH didn't require a KDD for this, I think open mSupply absolutely should seeing as common sense is that pack size should be integer!

[adrianwb]

Just to point out that we're only talking about decimal pack sizes here, not decimal number of packs (although that was also an issue for HSH it seems?). Fractional number of packs is more easily avoided - e.g. repack a bottle of 100 tablets to 100 packs of 1; as @Chris-Petty has pointed out, migrating from fractional pack sizes is not so easy... However, even fractional packs can become a bigger issue if the original item unit has been defined as a multiple of the smallest possible unit e.g. if dispensing sites are only added on later after the initial implementation was designed only for warehouses.

Unfortunately, switching from integers to floats in Rust is not trivial, but I'm not sure that we can continue to restrict either of these fields to integer-only? The alternative is to enforce migration for any sites which have fractional values for either before they switch to omSupply, but that doesn't account for any fractional values that are in HSH - I don't know much about how that integrates with the rest of mSupply, but I'd imagine that the same customers who want fractional values there will also want them in omSupply?

[andreievg]

open mSupply will fundamentally just lose data if we migrate a store on a system using decimal values for pack size

Can our incoming sync code recognise fractions in pack size, set pack size to 1 and then adjust number of packs accordingly ? (if this is done for stock lines and invoice lines I think it works ¯_(ツ)_/¯ ?

For the use case where an item is defined as 1000ml at central level, and lower levels uses like 10ml, pack variants would actually work quite well (it's UI layer translations, to make it look like base unit is 10ml, and behind the scenes fractional number of packs are used)

Originally I was quite anti decimal number of packs, but it seems like the simplest solution for those real use cases, however I think fractional pack size should be avoided, unless absolutely necessary, so would vote against it in omSupply.

[adamdewey]

however I think fractional pack size should be avoided, unless absolutely necessary, so would vote against it in omSupply.

+1!

[andreievg]

In the meantime should we update the front-end to only accept integer input?

Yep, go for it! Thanks

[CarlosNZ]

Until we know why decimal pack sizes are possible in mSupply - we will prevent decimals in pack sizes for open mSupply.

In the meantime should we update the front-end to only accept integer input?

Actually, this is already done in #2794. Should we close this issue or leave it open for the wider discussion of fractional pack sizes / migrating them from mSupply?

[Chris-Petty]

@CarlosNZ I think close this, but we need a new issue for a KDD deciding what we're going to do for making legacy data with decimal pack sizes migrate-able to open mSupply.

@andreievg might want to start that off, I'd say with 1 option being move from integer to decimal type for packsize, and 2 what you're suggesting? Or I can and you can fill in your one.

[CarlosNZ]

@CarlosNZ I think close this, but we need a new issue for a KDD deciding what we're going to do for making legacy data with decimal pack sizes migrate-able to open mSupply.

Righto, have linked to #2794 so will close when that's merged :)

[andreievg]

@andreievg might want to start that off, I'd say with 1 option being move from integer to decimal type for packsize, and 2 what you're suggesting? Or I can and you can fill in your one.

Once pack variant is merged, and that alternative is can be shown

[craigdrown]

And https://github.com/msupply-foundation/org-issues/discussions/40 for where we got to 18 months ago.
I'm glad we have @louisaw123 ;-) if a user wants to enter a pack size of 2.5 Litres or 0.5 ml we need to let them.
My old person view is that we started with integers in old mSupply and changed to floats, and 20 years later you're deciding to relearn the lessons the hard way rather than accepting that it's like that for a reason (and I'm sure someone will find a comment from me saying "floats aren't needed for pack sizes in omSupply" ;-) ).
I can't see how you can migrate a site from mSupply OG to using integer packs without forcing them to change the units they use - software colonialism ;-)