Hey gang, hope everyone is doing well today.
My company is (finally) in the upgrade process from Vantage 8.03 to 10.whatever. We’re almost there. We are using the Cirrus upgrade tool from Epicor and have had great success.
We are currently stuck in our upgrade while we work out a problem we got ourselves into way back in 2007. We make pipe. We have about 5500 Parts. In Vantage, each part has 1,681 dimensions breaking the pipe down into 1/16th-inch increments. Nobody can recall why it was implemented this way. And we really don’t need it anymore - while piloting E10, we’ve found that the UoM engine is more robust out-of-the-box and we can do business just fine with it.
Here’s our problem: 5500 x 1681 gives us almost 9.3 million records in our UOMConv and PartUOM tables. UOM Class Maint takes 9 minutes to give you results when you hit the Search button.
I am curious if anyone here stepped up from Vantage to E10 and excessively used Dimensions in Vantage like we have and what you did about it.
I’ve logged a call with Epicor and while I wait, I figured I’d bounce this scenario off of you all to see if you’ve encountered it and what you did.
Thanks in advance. I attached the screenshot below that I sent to Epicor in case it helps visualize what I’m talking about with regard to UOM Class Maint.
Ouch… I dont believe that we (Epicor) ever imagined using dimensional inventory in that manner. Seem like a ton of minute accuracy, much more than most people use. Especially since MRP ignores dimensional values.
Sorry that I don’t have a great answer for you… Other than, you may need to go through some form of conversion to consolidate the dimensions.
Well you’re no help, Tim! Need to find Stephen Swed and ask him why he implemented us like this.
Thanks for the reply.
I assume there was the need to know when you had (16) pieces that were 1-1/16", vs thinking you had (1) 17" piece, or (17) 1" pieces. So it kind of sounds like a roundabout way of having a P/N for each length that any piece of pipe could be in.
We jumped straight from V8 to E10, but didn’t upgrade. We did a virgin install of E10 and then DMT’d select data from V8. We also didn’t use Dimensions in V8 (but did setup UOM’s in E10).
So I’m not familiar with how the Dims integrated with the rest of V8. Does V8 include the Dim info in transactions (particularly PartTrans)?
Did every one of your 5500 parts use all 1681 dims? And by “use”, I mean have transaction or reference to the them. Any way to pare down the combo’s in V8, prior to updating?
Probably the biggest question is what will be lost or gained in going from Dims to UOM’s? If Dims were used to track inventory by piece length, UOM’s will not do this.
UOM’s would allow you do do something like:
- UOM Class: UNIT_LEN (type: Other, allow decimals: NO)
- UOM’s for class UNIT_LEN:
- 0001 - 1/16th INCH - Make this the base UOM
- 0002 - 2/16th INCH - Conversion is (1) of 0002 = (2) of 0001
- 0003 - 3/16th INCH - Conversion is (1) of 0003 = (3) of 0001
- 1920 - 10 FT (or 1920/16th’s IN) - Conversion is (1) of 1920 = (1920) of 0001
That would let you have a base P/N for 1", Sch 40, 316L SS Pipe, and then sell or use in any length from 1/16" to 105-5/8". You could make the IUM and PUM be
1920 so it could be purchased and stocked as 10 FT lengths. But the system System would only ever report the total in 10 FT lengths. You’d have no idea if you had (2) 10 FT pieces or (240) 1 IN pieces.
Thanks for the reply. Good question regarding if each of the 1681 Dims of each of the 5500 parts had a transaction against them and the answer is absolutely NOT.
I’ve thought about this tactic of cleaning it up in Vantage first and it might be an option. Thanks for the suggestion.
12 years ago when we implemented, we probably had this feature in our old-old ERP system (“EMS”) and they wanted to have it in Vantage. That happens all the time with implementations. There were probably other ways of accomplishing what we wanted, but the consultant at the time decided to do it “this way”. Furthermore, 12 years ago we used to do Make-to-Stock jobs, but now that is zero percent of our biz and it’s all MTO.
We are piloting our processes in E10 on new parts we created in E10 using E10’s UoM features and it works for us. Everything balances out.
Can’t I do a “DROP TABLE ERP.PartUOM” in SQL to fix this problem?
Can you delete a DIM in V8 if it’s been “used”? Or does is it used in some transactions, thus making it forever part of the DB?
I’d think about removing it from V8 prior to uploading to the cloud.
Hmmmm … The following is from the E10 Help
Use the Dimension Detail sheet to set up dimensions for the part with which you are working. To track a part by dimension, select the Track Dimensions check box on the Part Detail sheet.
Important: A Part Dimension cannot be removed if the part has an on-hand balance. The Dimension Detail and Dimension List sheets will not be available in Part Maintenance if the Advanced Inventory Management license is not installed and if the part is not marked as dimension tracked.
Note: Dimensional functionality has been superceded by the Unit of Measure functionality in Release 9.05.7x and above.
I don’t even see any “Dimiension” functionality in E10. Is it part of a special module (like Adv Inventory)?
Or does the process of converting a V8 DB to E10, replace the Dims with UOM’s?
I would strongly recommend fixing the UOM issue in Vantage. Once they get to E10 your options are really limited. We went from Vantage directly to E10 and had parts in stock with different UOMs (courtesy of the data conversion) and are still fixing them!
We went from Vantage to E10 via DMT. And still managed to screw up a bunch of parts.
If I had it to do all over again. I’d have only made one UOM Class in E10, and made every UOM belong to that class.
Rick - Thanks for the tip. Fixing in Vantage seems to make the most sense.
FYI, what we ended up doing with Support’s blessing, is used DMT to back out any on-hand parts with Dimension Tracking enabled. Support provided a script (for Progress in Vantage) to mass disable all Parts with Dimension Tracking Enabled. Then we ran the Cirrus database pass, upgrading to the latest E10 ver, and then we DMT’d back in the on-hand inventory and it worked perfect.