Comments
I also have a problem with that field 'quantity rounding precision' on the item UOM page.example 1:if base UOM = PCS and the other UOM = KG and there are 6 pcs in a KG than this is the setupCODE QTY PER UOM----------------------------------PCS 1KG 6When I set the 'quantity rounding precision' to 1, and I purchase 3 KG which is 0.5 pcs (OK in know this is a bad example) than I will receive 1 pcs because of the rouding precision of 1.But it doesn't work the other way around. example 2:if base UOM = PCS and the other UOM = KG and there are 6 Kg in a piece than this is the setupCODE QTY PER UOM----------------------------------PCS 1KG 0.16667When I set the 'quantity rounding precision' to 1, because I want to purchase 96 KG which is 16.00032 pcs (OK in know this is a bad example) than I want to receive 16 pcs because of the rouding precision of 1.Or I want to purchase 97 KG which is 16.16699 pcs than I also want to receive 16 pcs because of the rouding precision of 1. But this is not possible. the field qty rounding precision only allows me to enter a 5 decimal number. 0.00001 becase 0.16667 has also 5 decimals. But I would think that this quanty rounding precision is onbly to round into the base UOM, because this is the UOM you keep inventory in. But it seems not to be the case.
This would be very useful. We have seen this requirement on two Pharma project. Pharmaceutical companies often have legal obligations to cover X months of future demand forecast as a safety stock in each month. We ended up customizing a job that creates min/max keys based on demand forecast, but it would be great if a standard solution can do this in the future.
Agreed this is a problem; it's possible to view the description within the UI but this is an impractical way to resolve errors for bulk data loads.We should be able to download failed rows with information about why each row failed in order to perform fixes in bulk. This is especially important in large loads when records may fail for more than one reason.