Not sure if further arguments are considered, but I'll try. Effectively, this decision means that products with low ADU in some period, cannot fully be covered by the functionality, since, as in example above, the ADU my be overestimated by a factor of 10, with is a huge error factor. This does not only affect products with stable low demand, but also seasonal items with low demand at any period of the year: You'll have to manually adjust min, max and reorder points for those products at those periods of the year - which means a lot of manual control and overriding in general, contradicting the logic of automating the min/max/reorder calculation based on the current and predicted sales.The idea is not to have decimals on min/max/reorder for items with integer units of measures (those have to be integer, or whatever is defined on the UoM), but to have proper precision on the calculatory value of ADU. That is exactly how calculation of Safety Stock is implemented: Decimal values for "Average issues per month" and "Standard deviation of issues per month", but then rounded to the proper decimal precision for the suggested minimum values.