That sounds like a weird response.  Not using the smallest unit of measure can result in variances in quantity you expected to consume vs what was issued, but using a different lot because of the UOM doesn’t make much sense.  Could there have been a miscommunication with the ticket escalation?

I’d for you to undertake that process and then find out it doesn’t fix it. I’ve mapped that specific process out for someone, Lbs to Grams, it’s a pain.  

It may make sense if the system is rounding automatically as part of the issue transaction. If the error due to the tablemaker’s dilemma is high, then the system may take more or less product than predicted if the rounding only occurs on issue (and therefore overflows into a different lot). You can reduce rounding effects in some cases by increasing the decimal precision of the quantity and UOM fields for the company I think (don’t just do this though… it needs testing).

It’s also possible you could compensate for the problem with customization.

The fundamental issue is the “tablemakers dilemma”.

https://en.m.wikipedia.org/wiki/Rounding#Table-maker's_dilemma

This is why the base UOM should be the lowest common divisor. It reduces the error from the effects  of division because in most cases the lowest common UOM will divide into an integer value, and where it doesn’t the effects of rounding will be minimized.

Kerp in mind…. You need the lowest common UOM on a per product basis. So depending on the conversions, it may not always be the same UOM.

Hi @lpenrod  - were you able to find a solution for your issue? Thank you!