Just a precautionary tale, in case you ever ignore the bold warning text in field help. This particular feature is almost sure to cause more problems than it will ever solve. At least in 10.2.600 there are a myriad of issues that are breaking involving items with multiple uoms, things from demand, to allocation to pcid. Worse, if you ever use it, it’s almost an act of God to undo. Steer clear.
1 Like
To add to this.
PartAllocation location (via order or fullfilment workbench) uses the PartQty table (demand) to determine how to look for available inventory. If you dont have “available” inventory - allocation\reservation will fail obviously.
One issue is that when you disable Part.TrackDimension and have ANY demand the PartQty table is NOT updated - so the demand stays in the wrong UOM.
If you try to get fancy and force an update (in my case, change the FROM site on the OrderRel) it does add the demand using the proper UOM - BUT - it does not decrement the old (bad) demand.
Imagine a PartQty for Part A (10 each per case) as:
Site1 10 CASE
Turn off track dimensions so CASE is no longer tracked. Then manipulate the SO release that has the demand for those 10 CASEs.
Now PartQty looks like this:
Site1 10 CASE
Site1 100 EACH
Moral of the story is that one of two things needs to happen:
A) When user unchecks TrackDimension, Epicor needs to also correct the PartQty records (UOM and QTY based on conversion)
B) Epicor needs to not allow user to uncheck TrackDimension for parts that have demand (please dont do this, there are already enough hoops to jump through in this situation)
1 Like
I’m crying on the inside…My head exploded over multiple UOMs. 
A follow up for all. After working with support to get 2 PRB’s initiated, both were rejected.
Somehow, Epicor seems to think that when you uncheck TrackDimensions it is “working as intended” to leave invalid demand records that break allocation\fulfilment.
They also did not offer to send me a script to fix the issue with the data - so off the SQL DB I go…
Luckily Part.TrackDimension is an obscure feature that not many people use - and hopefully after reading this someone, somewhere has just decided against using it. Regardless, if you find yourself here, the fix in pseudo logic is this:
(Put this in place before UnTracking)
1 PostProc Part.Update, if you turned off Tracking on a certain UOM then,
2 Check for any PartQty records for that Company\Part\UOM (the one you are untracking)
3 Use the UOM conversion factors to convert that old uom qty to the IUM qty
4 Add the resulting qty to the existing Company\Part\IUM PartQty record (or create it as needed)
5 Delete the bad PartQty records from step 2
If you would like to identify all the bogus PartQty records:
cc_badPartQty.baq (45.0 KB)
1 Like