Changing UOM with existing stock but incorrect UOM

I have on hand, 4 pcs with a UOM of PCS which I’m trying to quantity adjust out, however the Part’s IUM is in EA, they’re both in the same UOM class.

I can select PCS in the quantity adjustment screen, but when i go to submit, it changes it back to EA, and does not adjust the 4 PCS. I can’t convert the IUM due to there being stock that I can’t even adjust because of the wrong UOM in the system. Kinda got a catch-22 situation here.

Any ideas on how to address this other than going through SQL and manually changing it within the db?

Is the conversion from PCS to EA 1=1?

If so, just do the Qty Adj in EA.

If the conversion is not 1 to 1, try doing it in EA with a factor on the qty.

And are you sure it’s not making the adjustments? That window can be deceiving. I think it “refreshes” using the same partnum, after the issue is completed. If you still have that form open, use the Transaction Log to print out what’s been done. If you’ve already closed it, Use PartTran History to look at it.

It’s not 1-1, PCS can have a fractional quantity, but EA is whole numbers only.

My issue is, I have a qty of 4 PCS in inventory, but my IUM is in EA, I can change the adjusted qty to PCS, but when i go to submit, it just changes it back to EA.

If EA and PCS are in the same UOM Class, there must be a defined conversion between them. Or is there more to this, like being a Part Specific UOM?

Sorry, i just checked again, yes, its actually 1-1, i’m thinking it might be something to do with the default UOM and the Quantity Adjustment screen. Whenever I try to complete a transaction in PCS, it changes and completes the transaction in EA, I need it in PCS.

If it is 1 to 1, and your adjustment is for 4 (a whole number w/o decimal places), why doyou have to do the Qty Adj in PCS??

It’s not lot or S/N tracked? I would think it can’t be as S/N tracked parts must have a IUM that does not allow decimals.

It’s not lot tracked.

I have an existing quantity of 4 PCS, but i’m trying to adjust it out of inventory. When I go to submit the transaction, even though I can select PCS as the UOM, it defaults back to EA when i hit “Adjust”

And if you try to issue 4 EA ?

And just to be certain, you’re actually doing an adjustment qty of -4 (negative to reduce the QOH), and from the Bin that has the 4 in it, right?

Yes i’m doing -4 to remove them, if i try to issue in EA, it just creates another line.

image

Both of those rows have the same bin number?

What I’m finding strange is that the grid normally shows the IUM for the UOM column.

I did a test where I have UOM Class COUNT with IUM’s of EA (which allows decimals), and EACH (which does not allow decimals). The default UOM for the class is EA

A part with the UOM Class COUNT and the IUM of EA, shows up as EA in all bins on the Qty Adj window.

image

that second row (in bin 1B) is what appears after doing a Qty Adj to 1B of +500 EACH (the UOM that doesn’t allow decimals). It still shows up as EA (and not EACH)

Anything special about that Bin? Do you have shared warehouses or anything odd like that?

IUM is set to EA, I think initially it was set to PCS, but not sure how it got converted if there was qty on hand back then.

The bin number is the same for each row, no shared warehouses, nothing special about this bin.

Try running the “Refresh PartBin QOH From PartTran”
(it is in Sys Mngmnt -> Rebuild Processes -> Mfg / Dist )

image

There is a “Report Only” option, so you can run it to see if it finds anything, without actually making any changes). Us teh the Filer tab to run it on just that part, and see what turns up.

There is also a setting on Part that will help with this, Track Multiple UOMs.
If you set that to true, then when adjusting your part in PC it will not convert to EA first, it will do the adjustment in PC.
After you clear inventory for that part, it will let you change that back to false, and everything will go back to transacting with the IUM as the base.

That worked! I figured it would be something simple but couldn’t find what it was, thank you.