Bulk Part Creation and BOM Best Practices

Long-time listener, first-time caller…

I am new to Epicor, being introduced to it a couple of months ago, and have been silently combing through EpiUsers to help get a better grasp on what I can get out of Epicor. For the past decade, I worked primarily in Operations using Oracle’s ERP.

Looking to get some advice from the experts on a couple of things, but should probably provide a bit of context first:

I was recently hired into an operations role at a small business (< 20 employees), tasked (among other things) to increase efficiencies/productivity/other cookie cutter operations goals/etc. I was very accustomed to strong data integrity and planned to lean into that strength…That said, my initial analysis is our org implemented Epicor with someone who started setting up processes and best practices, but the implementation was never fully completed.

As the subject suggests, I am looking for help on the following:

  • Best Practices for bulk part creation
  • Best Practices for ECO groups/BOM creation

Where we are at currently - We primarily make long lead time products (3 - 14 months), consisting of thousands of parts that are mostly made in house. For our Sales Orders, we have historically used a single line item representing the finished good. Only recently, we began using multiple items representing multiple “finished” assemblies that are packaged together as a “system”. As for part numbers - we have a handful of generic ones to represent these unique finished goods (the ones with hundreds to thousands of individual parts). From what I could gather, we are not fully utilizing the engineering work bench to build BOMs/create ECO groups either. We have Epicor 10, On Prem, version 10.2.200.12.

Where I would like to get to - Using sensibly structured multi-level BOMs complete with proper subassemblies, operations, and estimated times (eventually), which should allow us to track what is moving through the floor with a much greater degree of accuracy.

Some of the biggest resistances/challenges to changing up our processes have been:

  • It would take too long to put the part numbers in (which from what I read, DMT would help with) (I also considered trying to create a form that would allow for bulk imports from excel or streamlined entries, but from what I gathered from other topics - this is not an ideal method)
  • When creating jobs, the system currently defaults to include all operations, so that we don’t need to specify which one or how long it might take
  • I do not believe anyone (besides myself) has had previous experience creating complex multi-level BOMs
  • In general, nobody seems to have a great deal of permissions beyond our contracted IT team (likely by design, but much of what I gather in the topics seems to suggest most businesses have an embedded Epicor “guru” to varying degrees)

I suspect a great deal of this is a result of lack of training, which I am hoping to slowly rectify.

If anyone can point me to any topics, or has any advice on the two main issues, I would greatly appreciate the help. Also, while hiring a consultant or someone with a background in ERP systems (ideally Epicor) would probably be a sound decision, I do not believe it’s a feasible option at the present.

Thanks in advance for any guidance!

4 Likes

Welcome Ace!
I can vouch for DMT as a method of inputting a lot of part numbers. I have done this several times, and there are a few gotchyas.

First, always test in pilot thoroughly before attempting in live. If it doesn’t work in the pilot db, it wont work in live.

Next, always look at the DMT required fields, and make sure all of them are included.

Don’t waste your time trying to make a custom form to upload parts. DMT is the tool for that. There are so many business objects/methods that get triggered when adding a new part, it is too difficult to reproduce this without very careful consideration.

Best of luck to you!

9 Likes

For longer lead items like yours, I often see users utilize the Projects module where billing can occur at different stages and not just shipments. Do you have any of the Project modules (Base, Advanced Billing, Advanced Projects Management)?

4 Likes

Hi Mark,

Though our billing does work like that in many cases, I do not believe we have a projects module. From some of the past sales orders I dug up, the lines themselves appeared to be place holders for payments (i.e. Line 1: Customer X Job Y Payment Part 1 of 4).

How we record our billing is another subject I would like to put together some best practices for. Blanket sales orders for instance are entered and processed within Epicor completely different depending on who created the sales order.

Would the Projects Module fit well even if we have a somewhat varied mix?

1 Like

Yes, probably. I don’t know your company and their procedures. It’s worth a look. The one drawback from when I used projects was shipping from stock. We made metrology lasers. They were all the same except for the software, so we made them to stock. Projects wanted us to issue them to a project job. But then we no way to show it shipped in Epicor as it was called. This was a big ask years ago - long before Epicor Idea - and I don’t know if it ever got delivered.

2 Likes

Hi and Welcome Ace! This group has saved my bacon more than once when I have ZERO clue of what I am doing! We are also a small company under 30 people and prior to Epicor, most things were accomplished by tribal knowledge – so this was definitely a culture change!

3 Likes

The tribal knowledge hurdle is always a tough one. Where I came from, we had ~38k employees, a hefty budget, and embedded teams for nearly any business need you could dream up. Funny enough, there were always processes popping up that seemed to rest solely on one individual who knew how to do it “the way they always have” haha!

I always considered it a win if I (or someone in the know) could whip up an SOP or work instructions to eliminate those instances.

3 Likes

This happens now, or it’s a desire? Because that’s not normal…

That’s you now!

4 Likes

I think it was intentionally set up to include them (certainly did not seem like normal behavior). So, I will assume it was desired. That said, I am not overly savvy on the exact way they are being created (everyone seems to have a different way of doing mostly the same things…)

This is the reality that I am slowly coming to accept :sweat_smile:

3 Likes

One Of Us GIF by BEARISH

5 Likes

Hi Ace,

We use DMT significantly to add and edit parts and methods. My favorite way to work up data files is to use a UD table to house the parts whose methods I want to mimic or edit and then a query to get the part, part plant, part rev, partmtl, and partoper data out. I would only query out the fields required and the fields you want to use. The more fields, the more the chance of it choking on import.

In case it’s helpful, here’s example of one I’ve used for getting the partrev, partopr and partmtl in for subset of parts / revs stored in UD102. These were used to make new method revisions.

Nancy




3 Likes

@NateS Sounds like selling the usage of the DMT Module was a success! Now on to how we plan to use it…

How sluggish is it when pushing large amounts of date? Our usage could be adding in 8000+ unique parts for a single “system” in one go - would this even be considered a large number of parts to enter?

Is it a run it over the weekend type tool?

2 Likes

I did about 10k parts and left it overnight. While it is relatively fast compared to hand entering, it still takes time. I find it better to process them in smaller batches of a few hundred records to help keep things clear. You can process multiple files at once this way.

2 Likes