Then I guess Warranty Void Jail for all of us 
its all @Chris_Conn idea anyways
DELETE FROM Erp.UOMConv WHERE Company = '01800000' and UOMClassID = 'OtherOZ-EA' AND (UOMCode = 'GAL' OR UOMCode = 'QT' OR UOMCode = 'L' OR UOMCode = 'ML');
1 Like
I did a trace of trying to delete the conversion, and instead of indicating the the record to be deleted, by its Class and UOM, it just says “Row 3”. A query of my UOMConv table does show the record I’m trying to delete as being the 3rd row.
weird that it would do that over specifying the Class and UOM
So could the UOM conversion be stopping the delete?
A UOM Conversion is just a combination of Class and UOM (and a few other things). If no reference to a part with that Class AND UOM exists, there is no reason the conversion shouldn’t be able to be deleted.
So tell me if I’m reading this right. You created a temporary pass through UOM that you want to use to do the conversion. After the conversion you want to delete the pass through?
I don’t think Epicor will let you delete the pass through for the same reason they don’t let you convert from one class to another without the pass through. It needs the UOM’s to sit in the part tran to be able to track the conversion. If you delete the pass through, you will have a gap in you “story” of what happened to the inventory. Accounting practices won’t allow it.
1 Like
How else will we know how 26.2342 glorbnorks = 1 lb?
1 Like
Ugggh… I hate when people automatically round up when it comes to glorbnorks.
3 Likes
@ckrusen you cant blame the user, Epicor doesnt handle the 16 billion decimal places required for accurate conversions.
@Banderson - I converted from 1 UOM to another UOM, yes it was a different class. But Epicor didn’t track any conversion/historical records for those additional UOMs I had to create for the Tool to work properly.
I searched the entire SQL Database, it had a historical reference to the UOM from and UOM to between the 2 classes, but I didnt need any other UOM just Oz and EA.
I understand had they kept historical/audit/references, but they didnt and they dont - atleast according to using data compare tools and SQL Global Search.
Not even in their PartUOMConvHistory table.
I Believe they made the tool a long time ago to address UOM to UOM and then someone kept nagging them and they squeezed in UOM Class conversion as well without re-engineering the Program. #Justathought #dontKnow
3 Likes
Haso, Could running the Refresh Part Bins and Refresh Allocations processes clear out nagging links to non-existent parts?
A.
FWIW - A trace of the attempt to make a UOM Conversion inactive, shows the following in the UOM Conversion’s dataset. Of note is the
<HasBeenUsed>true</HasBeenUsed>
I wonder if you could tweak that value in a BPM.
And along the lines of @hkeric.wci 's theory, the data dict entries:
For the Active Filed
Indicates if the UOM is Active. If not Active system will no longer allow it to be used. Does NOTvalidate if it has already been used.
For the HasBeenUsed Field
This indicates that this UOM Conv has been used somewhere. Therefore we do not want to allow the associated conversion to change.
And the data dict description for the table
Parent Table: UOMCLass.
Child Tables; None.
Deletion Rule: Can?t delete if it?s the BaseUOM.
Defines the specific Units of Measures with in a UOMClass.
Establishes the following:
Valid UOM?s of a UOM Class. A UOM can be in 1 standard class, multiple non-standard classes or both.
UOM standard conversion factor. Conversions can only be made between uoms of the same class.