I have a purchased part that has a min order quantity. When I try and add an entry for this part to Supplier Price List and specify a supplier UOM, something unexpected is happening with the PO suggestions that are generated.
It is rounding down the min order quantity from 8000 to 7999.999999, and then since that PO is not sufficient to bring us above minimum, it writes another, for 7999.999999.
Why is it not just writing the PO in the min Order Qty in my UOM?
What is your default for POs at the Company level?
On the Supplier Price List?
I tried unchecking Default UOM thinking that might help and got the same result.
It definitely seems like it is starting out with the correct OUR Quantity, figuring out the supplier quantity, but then for some reason it is going back from the supplier quantity and re-writing our quantity, or something like that. Frustrating.
That is weird. I would think that Default UOM would work.
Do you have any price breaks? What is the UOM there?
Or see what happens when you create a new Price List for a Supplier and you change the Supplier UOM?
No price breaks.
I really appreciate the help, but I’m not quite sure what this means.
It seems like if I use a supplier UOM that has a round conversion factor, it shakes out ok.
A conversion with a decimal, it does the thing I don’t want it to.
My conversion factor here is 1 LM = 16.5 SQFT
Start out at 16000 / 16.5 you get 969.6969696969697.
Ok cool, write the PO for that.
But it doesn’t stop there, it rounds the supplier quantity (fine) and then does the math back the other way to change our quantity.
If you set the lot multiple in part > site > planning does it change the Supplier quantity? I know it changes suggestions for us.
What is the PUM on the Part?
@hackaphreaka and I are in this problem together so I’ll answer both questions.
@gpayne, I just updated the lot multiple to 8,000 SQFT and no change.
@jkane, the purchasing UOM was SQFT, like the inventory UOM. I was using the override checkbox in supplier price list to inform the PUM, but I just ran MRP again with the PUM set to LM and no improvement. Denied!
It’s as @hackaphreaka said, it looks like it’s doing the conversion to get the supplier quantity and then turning around using that number to calculate a new “our quantity”. It only doesn’t work because the two don’t convert cleanly without a remainder. You change the number by performing the calculation.
I just submitted a ticket with Epicor to see if they can shed some specific knowledge on what’s happening in the background and whether or not this is intended behavior.
I was going to say that next. I’ve come across this before, just can’t remember the outcome.
I just saw a this KB that suggests unchecking allow decimals, but I don’t know if .5 should be allowed.
Yeah, we were discussing the possibility of removing decimals from the SQFT UOM.
However, it seemed like an overcorrection to do so, especially before we knew if there was some other problem happening.
If we do decide to turn off decimals on that UOM (or if Epicor replies), I’ll post back here with the results!
They should reword this KB to say concession rather than resolution. I wonder what we are supposed to do if turning off decimals is not really an option for us.
If you could not turn off decimals you would be forced to alter the quantity on the suggestion which can be done in POSugg.GetRowsPlant as the workbench loads them.
I guess not understanding why these are my only options are what I’m having a hard time with.
Is it because I am creating an impossible situation? I want to write a PO for exactly 8000 sqft, but the moment I want to include a supplier quantity on my PO alongside that, if the math doesn’t work out, I have to write the PO in some other quantity, not exactly what I want?
There are possibly other options, I am just quick to put in a fix and move on and not willing to explore other ways to deal with it.
Received a response from Epicor on this:
This is caused because of the conversion factor, the rounding of the UOM, and the fact the base UOM for the part is SQFT while the supplier price list is in LM.
The issue is that the requirement of 8000 cannot be divided correctly by the conversion factor to give a value in LM.
That means for example, if you were to divide 8000 (the requirement) by the conversion factor 16.4042, the exact or almost exact number to get the 8000 SQFT required, would be 487.6799843942405 which has way too many decimals for the system to calculate, trying to round the decimals to a smaller quantity will never give the exact 8000 units.
The same applies for the conversion factor, in order to have the exact conversion, the factor would need to be 16.4042000001426 which again has too many decimals for the system to handle.
There are a couple of options available here.
1- Delete the supplier price list and recreate it with the SQFT unit for the supplier, then change the PO if required.
2- Change the conversion factor to something that would give a number with not so many decimals, for example, using a factor of 16 would work, but there might be a different combination of decimals that help.
There might be other options to manage this, so I believe it would be useful to review your requirement with an EPICOR consultant, let me know if you would like me to get you incontact with a consultant and please try any of the 2 suggestions.
So I’m reading that as, the calculation must go both ways, otherwise they aren’t the same number. It’s designed this way and it only fails to work because there aren’t enough decimal places (in this case) to fully capture how one UOM translates to the other.
I believe we may reevaluate what values we are going to plug in for the conversion factor.
I was also doing some testing with allowing decimals, but only 3. This would allow us to retain that level of detail if needed, but would also force the system to round to the nearest whole number when the conversion is only off by .00000001.
