Weight Field Decimal Places More Than 2

[scottd21]

We have been using Miva since 2018 and I would love to see the default weight field in the admin console accept numbers with more than 2 decimal places. We sell a ton of very small products (hardware, screws, bolts, etc.) that have a very small weight, less than 0.01lbs. People buy many of these at a time, so you can see why this is a big issue for us. 0.01lbs * 1000 is 10lbs, but if the product actually weighs 0.004lbs, that comes out to only 4lbs. Unfortunately we cannot use grams or oz due to our other integrated systems using lbs.

We had to pay for custom development when we went live back in 2018. This was pretty painful for us and keeps getting worse as the simple solution would have been to roll out an update that updates the datatype of the mysql db field to accept a float value and preserves the data. Then update the data validation on the admin console text field.

This is exceptionally painful for us as we now cannot get our custom weight field to pass over to Google Merchant Center using the standard live connection without paying for more development hours for a custom solution. This is actually hurting our SEO significantly.

Anyway, sorry for the rant, but I would LOVE this to be corrected in the base system so we can revert our original custom code.
--Scott

[Keifer Hunniford]

I don't know that there is a precedent for solving this problem this way. Agreed that it's a problem, and the REAL problem of doing anything non industry standard is what impact it has downstream with things like, say, Google Merchant Center but a myriad of other things. We have to make sure that we store data to the same number of decimal places as external services accept. It is true that numbers can be rounded when multiples are purchased so data can be passed to e.g. shippers in a more standard way - but guess what, if someone buys one of several different items then each one rounded up at some point is going to not work for someone. The industry has pretty much standardized into the use of using 2 decimal places of some measurement, but the actual measurement can be defined. Outside of the US they even have this thing called the Metric system and a gram to solve these issues - but let's not argue religion.

What I consider the natural product evolution for us here is improvements around measurement of weight being global. I think it would make a lot of sense for this to be improved where there is a global default but a local product override, but to make that happen requires an audit to make sure that the same flexibility can be supported downsteam without creating issues. If not, we're back to square one a little bit in that we'd have to do math to normalize all basket items into standard form, which at the end of the day is likely what your original customization did but the other way up. I think the easiest way to handle this currently is to define the global setting to the smallest measurement, then use template code to do the math to simplify that to a more appropriate display for heavier objects.

Long story short. I hear you, and it's on the radar that it's a pain point, we think your suggestion might be a solution but what we discover it's usually not as simple as things first appear.

[scottd21]

Thank you for the explanation; it makes perfect sense. The requirement for shippers to have weights at a 2-decimal standard could potentially lead to issues. It would be beneficial to calculate the total weight in Miva before rounding it and sending it to the shipper. Even if the total weight of a package gets rounded to the nearest 0.01 lb, it shouldn't be a significant problem, as shippers usually round up to the next full pound anyway.

As an engineer and lifelong data enthusiast, I'm also a strong advocate for the metric system. But yeah, let's save that discussion for another time!

--Scott

[captainboom]

A related issue we've run into is additional decimal places in price. We have an integration between Miva and Finale Inventory via a custom Filemaker middleware solution. Finale will have unit costs that have up to 6 decimal places, because many pieces in a case yields a fractional cost for the piece. As a result, it's difficult to have Miva play nice with the costs in Finale, and it introduces manual steps to update our true cost in Finale.

[Rick Wilson]

This comes up in some use cases and we fully understand the pain. As far as we can tell, there's no industry standard way this is accomplished in our market, in fact from what we can tell our competitors don't do this at all (if anyone knows of a good example, we'd love to look at how they do it).

The reason it's not a simple item to just do is that payment gateways and sales tax calculations often require you to tie the order out to the line item and so minor rounding differences can break those integrations.

We continue to look to see if there's a way we can support this all within Miva and not cause rounding issues when we need to connect to an external ERP, Payment Gateway or tax calculator.