Epicor Part Master Q&A

Q: What are some of the first things that someone should consider when setting up parts in Epicor?

A: We could have a long, harrowing conversation about part naming conventions, but arguments over part naming philosophies have ruined more friendships than heated discussions over the latest Star Wars movies—so I’m going to leave that one alone. In terms of Epicor part master setup, probably the first and most important consideration is the Non-Stock checkbox. The Non-Stock Flag is one of those “big-little” checkboxes that drive a ton of downstream behavior. This one flag will affect how a part will be handled on a sales order, a purchase order, and a job, whether as the top-level assembly or as a component material, and basically determines whether the related transaction will be processed through the system’s inventory module or processed directly in a “to-order” manner. This flag is fundamental for companies looking to operate in mixed-mode manufacturing. Most companies, even companies working in highly-engineered environments, rarely intend to manufacture all components “to-order.” Often there are economies of scale to consider, and components can be used on a broad array of higher-level assemblies. As such, some parts will be handled in a “to-order” manner, while others will follow a traditional inventory-based approach. For that reason, we have to place special consideration on the setting of the Non-Stock flag.

Q: Phantom BOMs are a topic of disagreement—do you have any recommendations on the use of Phantoms?

A: In general, a phantom is a part that carries a method of manufacture, but is not itself manufactured discretely. Rather, the part “explodes” when it belongs in a work order—the top level part disappears and is replaced by its components. Phantoms really are system-specific, for the rules for handling phantoms differ by ERP system. Within Epicor, a few general rules could be suggested when deciding if a part will be flagged Phantom BOM. Firstly, if a part is stocked, it should not and cannot be flagged Phantom BOM, as it is assumed that a phantom part not be stocked. Also, if a part is made independently from its parent, in a different place and at a different time, it should not be flagged Phantom BOM—it should be either a material or a subassembly, so its manufacture can be managed independently from its parent. When component parts are made at the same time and place as their parents, I’ve seen customers use phantoms to manage the components, to simplify production, while retaining the basic product structure defined by engineering.

Q: More specific to Epicor, the Pull-as-Assembly flag is a source of confusion and disagreement—do you have any recommendations on the use of the Pull-as-Assembly flag?

A: A Method-of-Manufacturing defined for a Part Revision can differ significantly when you pull the revision into a Job and get details. These differences are largely due to the Pull-as-Assembly flag. This flag essentially defines whether a component part will be manufactured independently from its parent part, or as part of the same Job as its parent, as a subassembly. One can suggest a few principles when choosing to flag a part as Pull-as-Assembly. If the part is stocked, do not flag the part Pull-as-Assembly, as you will be supplying the material from your on-hand inventory. If the component part in question is Non-Stock, and the intent is to supply the materials through a separate Job, uncheck the Pull-As-Assembly flag. But if you wish to supply the Non-Stock part with a subassembly, allow the Pull-as-Assembly flag to remain checked.

Q: Can you explain how the settings on the part master flow through to a bill of materials and ultimately to a work order?

A: It’s easier to explain this with a visual…

Are you looking for answers to your Epicor questions? Part Master or otherwise? Follow these links, and our ERP consultants will help you find answers:

• Learn more about Epicor security and allowing multiple sessions here.
• Get data management strategies from our Epicor consulting crew here.
• Sign up here to get a free whitepaper that covers Part Setup in more detail.
• Watch recordings of our Epicor consultants helping ERP users here.

Please fill out the form below to get a white paper on Epicor Part Setup and Best Practices sent right to your inbox!

The Role of Order Entry in ETO and CTO Environments

Epicor Engineer-to-Order environments are their own special breed. Based on an almost infinite notion of product variability, their business models are hard to shoehorn into an ERP system. I once had a job shop employee describe his product variability with ultimate pliancy: “If they want us to wrap it in toilet paper, we’ll wrap it in toilet paper.” That would be a costly proposition these days. In light of this, I often get requests from my customers for “best practices” in handling various Epicor ETO environments.

The If-Then-This-That of E10

When it comes to questions regarding Epicor Engineer-to-Order, I always preface my answers with a de facto “it depends” before diving deeper into all the variables at play. Best practice for one company might not be the same for another. Ironically enough, it is almost as if I need to configure an answer for my customer, and discussions tend to take on the following format: “If this and that and/or this or that, then do this…”

One such question came to me recently from an Epicor customer, with regard to the role of Order Entry/Customer Service employees in an Engineer-to-Order organization. The company was debating the benefits and liabilities of having their inside sales staff perform rudimentary engineering activities as part of the entry of a sales order. In such companies, product details tend to arrive comparatively late in the quote-to-cash cycle, and the folks responsible for pounding in the orders often find themselves as the purveyors of this information, as received from the customer. These changes often require tweaks to manufacturing methods for a given product, and companies struggle in determining who should own these changes.

The In-the-Know of ETO

Who do you know on your team who could best own these changes? As I’ve noted above, “It depends.” But what does it depend on? I can think of a few of the variables that you would consider when deciding whether Order Entry should handle Engineering tasks:

• Technical efficacy and product knowledge of the Order Entry team: The higher the efficacy, the more liberties you can give someone to alter MOMs when quoting. In some environments, where the estimators are highly technical, Engineering is strictly focused on new product development, and Sales owns what is sometimes called “project engineering.” In other environments, this role is staffed by folks in the engineering department.
• Complexity of the product: The higher the complexity, the less you’d want Order Entry muddling with the engineering of the product. In low-complexity job shops, I’ve seen order entry or customer service staff handle the engineering implications of order changes.
• The implementation of Epicor: There are a number of ways in Epicor to get from a Quote to a Job, and few companies in the CTO/ETO world do it exactly the same. Depending on the overall architecture, the MOMs in question might be modified through the quote module, the part master, or in the jobs themselves. This architecture will affect the processes needed to make changes: do you need to modify MOMs through the quote, or will you perform modifications to the Part Revision through the engineering workbench? Quote MOMs are much more apt to be modified by sales staff than are part master records.

In general, I have found that in most environments, Order Entry is focused on specifying product characteristics, features and options and that Engineering is responsible for defining the engineered product to satisfy these requirements. I often recommend that Engineering be the party responsible for what we normally understand to be the engineering function.

This model works well as companies sufficiently standardize their product offerings to support Epicor Configure-to-Order business models, as the delineation between features and options vs. product design are more pronounced in these environments. But there are certainly cases in which the composition of the entire sales staff, the nature of the product, and the system architecture determines that Sales is the optimal department to make these changes.

Are you a company in an Epicor Engineer-to-Order or Configure-to-Order environment? For help with your Epicor implementation or upgrade, please reach out to our team.