ERP Archives - Page 14 of 22

Epicor DMT: Data Management Tool Tips & Tricks

by Brad Feakes | Jul 30, 2020 | Epicor 10, Epicor Administration, ERP

The Magic of Epicor DMT Licensing

A common user challenge over the years with Epicor’s Data Management Tool (DMT) relates to the licensing of the actual module. Epicor DMT came from a very different evolutionary thread than the main application, and when trying to bind these threads, things often become tangled.

Licensing can be especially twisted, and more than a few us have felt the frustration of figuring out just who to send the license request to. Then remembering that we needed to cull the list of Company IDs from the database to be licensed. Then anxiously waiting for the returned file to arrive, hoping that we weren’t going to receive, by accident, a license file configured for a manufacturer of manure spreaders, headquartered in Glasgow.

But fear not, dear users. Epicor provides us a DMT remedy. For versions less than 10.02.5xx, you will still need to send Epicor a list of your Company IDs so that they can generate the appropriate license file for your use. But for versions 10.02.5xx and above, the DMT license is now included as part of your E10 license and is no longer reliant on your Company IDs.

As you can see below, DMT can now be licensed through Epicor’s standard license, which removes the need to drop individual DMT license files in user client folders. This greatly simplifies the deployment of the Epicor DMT application.

Epicor DMT Data Management Tool Tips and Tricks

That said, there are a couple of related tricks that can help you separate the forks from the sporks in your Epicor kitchen. One way to identify your DMT licensing from the DMT application itself is to utilize the settings icon at the bottom of the application and open the “DMT License Info”:

This will raise a properties window, providing details about the DMT license:

DMT is a client-based application. Therefore, much of the magic behind the DMT module is to be found in the application’s client folder. This includes licensing. Going back to our talk about license, it’s important to understand that for a DMT client to function correctly, one of the following must be the case:

• DMT must be licensed in Epicor’s Standard License file, which is installed on the application server.
• A traditional DMT .lic file must be deployed in the user’s client folder, where the DMT application normally resides.

Let us, as an example, assume we’re in a situation in which DMT is not licensed through the Admin Console license file. In lieu of the main license, a DMT-specific .lic file will need to reside in the client folder:

Were I to remove the .lic file from the client folder…

…upon my attempt to log into DMT, I will receive a licensing error:

As such, if you don’t have the DMT module licensed through the Admin Console, you’ll need to make sure you’re still planting the company-specific license file in the appropriate client folders. If you think about it in the sense of a cooking motif, you can think of it as a situation in which the pantry is emptier than Mother Hubbard’s cupboard, the grocery store delivery is still a day out, and your mask is at the bottom of the laundry basket. Sometimes you need to cook with only what’s already in your house. Just like your dinner occasionally falls together as a tasty combination of tomato soup and wanton noodles, you’ll sometimes need to get a company-configured license file and stick it in your client folder. With these steps, you can get the Epicor DMT program to run.

DMT is great in an E10 Upgrade.

Learn more

Part Master Best Practices? Ask Brad

by Brad Feakes | Jun 9, 2020 | Epicor, Epicor 10, ERP

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:

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

Get an Epicor ERP Part Setup & Manufacturing Best Practices Whitepaper Today

Epicor Engineer-to-Order at Your Service

by Brad Feakes | Jun 4, 2020 | Epicor, Epicor 10, ERP

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.

An End User’s ERP History – from Baan IV to E10

by Brad Feakes | May 21, 2020 | Epicor 10, ERP, ERP Implementation, ERP Selection

Back when I still worked for a manufacturing company, in a magnificent sprawl of factory and office buildings, I had a reputation for being a fast walker.  I’d bustle through the labyrinthine hallways of the office and scale the grand aisles of the factory. With my head down in a shoegazer’s stride, I’d often come into near collisions with whiteboards or drill presses.  At the time, I was shaped roughly like a college linebacker, and my coworkers would clear the path when they saw me coming.  “Slow mind, fast feet,” one of my supervisors once remarked.  When people asked why I walked so fast, I replied, “It’s hard to hit a moving target.”  In a company that had a reputation for random layoffs, this was a sufficient answer — an insider’s aphorism.

ERP systems are rarely a moving target.  A stationary target is usually either a soon-to-be-victim or a roadside misfortune.  When I first entered the business world, my company was replacing its mishmash of homegrown systems with Baan’s flagship ERP solution, Baan IV, well before the panic of Y2K. New to the company, and still learning what I could do to get by, it was no big deal to me.  But to my wiser, more experienced coworkers, it was an all-out affront to their sensibilities.  These were folks accustomed to the keyword-laden world of green screens and shortcuts, for whom the art of the double-click was still a work in process.  So, the transition took a while, in spite of the new software being pretty solid.

Baan, as the company proper, went into a tailspin shortly thereafter, and its software was absorbed into countless versions of other applications. I once sat down with a veteran consultant who had been with SSA Global and then with Infor during these transitions. He gave me the entire evolutionary history of the Baan product over a burger and fries.  It was quite a mouthful coming from one of the application’s dedicants.

When it came time to replace our own ERP system, the manufacturing company I was with opted to move to Epicor’s Vantage ERP system.  Compared to Baan’s Unix-based architecture, Vantage’s look and feel seemed pretty modern and user-friendly, especially in the mid-to-late 2000s.  Now, Epicor’s manufacturing ERP product had its own special evolutionary history, and we happened to hitch a ride to its moving train while it was plowing forward at full speed, but still halfway from its destination.  Vantage had originally been architected using the Progress 4GL business language, both at an application and database level.  But as Microsoft became the dominant application platform, the company opted to begin a migration process to a fully Microsoft-centric stack. And a long strange trip it’s been.

From my own starting point, I’ve been able to watch other customers navigate the challenges of simplicity and performance vs. currency and maintainability, all the way through to the challenges of new functionality vs. platform stability. 

Brad Feakes

SVP, ERP & Professional Services, EstesGroup

Epicor’s Vantage 8.0 version was the first step in this evolution.  Being a client-server application, they replaced the Progress client with a Windows-based client, while retaining the Progress business logic layer on the server.  Better still, they now provided the option for a SQL Server database.  The initial results were… bumpy.  One can imagine why combining so many architectural layers would certainly be a veritable middleware nightmare. Earnest effort went into remedying these issues, and the result was Vantage 8.03, a more stable version of 8.0.

A major functionality uplift had been teased for a number of years, under the guise of “Version 9.” While still possessing the same basic backend architecture, the features and capabilities of the new version were to be a real advance from the current release.  The first installment of this promise was Epicor version 9.04, and the results were less than optimal.  Sure, the functionality was there, but the performance was abysmal.  At my own company, we never got so far as to implement 9.04, given that 9.05 was released on its tail in short order and addressed some of the issues that plagued its antecedent. But at some point, it became known that 905 itself was going to be the last major release on the current architecture, that the next major release would be devoid of the Progress-based 4GL backend, and that in its place would reside an entirely Microsoft-centric server-side stack.

This finally came to fruition with Epicor’s version 10.  And the challenges experienced by the user community were similar to the previous versions.  In moving to E10, Epicor essentially rewrote much of the application’s backend, turning those in the end-user community on the bleeding edge essentially into beta testers. The challenges of working through the kinks involved were significant.  Now a consultant and no longer a customer, I experienced the application from a new perspective as I tried to confirm just which of the legacy version’s features could and could not be supported by the new version.  Working in some of the more complex areas of the application, such as product configuration and MRP, I’ve encountered many show-stopping issues that put customer implementations in holding patterns.  As with 904, a relatively small subset of Epicor customers went live on 10.0, many opting to wait until 10.1’s more stable version was released.  Since 10.1, the version has been remarkably stable, with each new version offering more and more capabilities without undermining previous functionality.

My ERP journey over the past 20 years has been a long, strange trip indeed. From my own starting point, I’ve been able to watch other customers navigate the challenges of simplicity and performance vs. currency and maintainability, all the way through to the challenges of new functionality vs. platform stability.  Looking back, I’ve wondered if I’ve learned anything from my IT travels.  Though I won’t scribe any hard-and-fast rules into marble, there are a few things that are worth mentioning:

Software goes through cycles. The stability, capabilities, and performance of an application all vary over time.  Understand this and plan accordingly.
A company’s success with an ERP implementation varies according the point in the cycle where they enter the fray. Entering on a stable version might not give you all the bells and whistles you desire but will likely make for a more successful implementation.
Stability applies to an ERP vendor as much as it does to their software. When you engage an ERP vendor, it’s good to understand the company’s stability.
An unstable vendor may quickly devolve into an unstable platform or, worse, into an unsupported platform.
When upgrading an application to a more recent version, be leery of the “bleeding edge” syndrome. All other things being equal, it’s good to let the major version of an application settle down before taking it on.  Premature adoption can lead to catastrophic implementation.

Interested in having us help your business?

Epicor ERP Upgrade Considerations for Data Dailies

by Brad Feakes | Apr 14, 2020 | Epicor, Epicor 10, ERP, ERP Implementation

The further away you get from the “new release” of a software, the more challenging an upgrade becomes, and this is especially true for Epicor ERP upgrade customers. If you’re coming from a Progress 4GL business logic-based version, which would include anything earlier than version 10, such as Epicor’s 905 and 803 platforms, you might feel a little lost in all your options. The need to move beyond Epicor’s legacy platform is obvious—the analog film of the old version is deteriorating on the reels. But the move to Epicor’s E10 platform is more of an epic picture than it is an opening trailer. Thus, it is important to storyboard the flow of the narrative from the old to the new, before the cameras roll, knowing that your plot armor will only take you through the first act of your Epicor ERP upgrade.

Two Epicor ERP Upgrade Paths

The hero’s journey in any good film starts with a call to action, with a road diverged in a wood where the protagonist must choose one of two paths. In general, you can consider any move from a legacy version of a software to an updated version to be an upgrade. But there are two distinct paths for moving from your legacy version to E10, and these greatly affect the nature of the final implementation.

Path 1. A straight, utility-driven upgrade from the legacy to the current version: In a straight upgrade, a utility converts the data from the legacy version, generating an E10 database that adheres to the structure of version 10 schema.

Path 2. A reimplementation: This is an alternative method for moving to E10 from the legacy version, but this method does not actually upgrade the legacy data to make the E10 database. Rather, the upgrading company reimplements the application in E10, normally using the legacy data—filtered, scrubbed and reworked—as the starting point.

Data as the Villain… or the Hero?

Regardless of your opening scene, one of the most important considerations in any Epicor ERP upgrade is what to do with your data. Companies can have one of many data challenges as they anticipate an Epicor upgrade. It is not uncommon for a company’s current Epicor implementation, along with all its legacy data, to be handed down from a previous administration. A lot of staff changes over ten years, for example, can leave a company with a system that has a setup and configuration at odds with their current orientation. In such cases, a given company may wish to have another shot at configuring the application—to undo some of the decisions of the past.

Some companies unfortunately inherit a legacy system with data that has been carelessly maintained and is thus dirty beyond recognition. In these cases, customers may look to either clean up the data or cut it entirely. In other cases, significant changes to the business may have led to an inordinate number of part, customer, or supplier records that are obsolete. While these might have historical value, they may also unduly clutter the database and place the company in a no-win situation. In extreme cases, the company may even have a company and site structure that has evolved to be radically different from what is depicted in the Epicor application.

The data of an ERP system can be broken up into a number of classes:

Setup data: This refers to the foundational data that underlies the setup of subsequent master file records. Examples of setup data might include part classes, product groups, buyers, sales persons, etc.
Master file data: This normally refers to the three core master files in any ERP system—the part master, the supplier master, and the customer master. Subsequent master files may also need to be set up that relate to the extension or relation of these master file records, such as supplier or customer part price lists.
Live transactional data: This refers to the open transactions in your system, such as purchase orders, sales orders, jobs, and invoices. The decision as to whether to reimplement or upgrade greatly affects how these are to be handled, given that in an Epicor ERP upgrade they come along as part of the ride, whereas in a reimplementation they would need to be loaded in the style of a new install.
Historical data: Historical data refers to all of the transactions that have been processed in the past and are no longer active, and would include purchase orders, sales orders, jobs, and invoices that have long since been closed.

From Classic to New Release

In a straight Epicor upgrade, the data from the legacy version is updated and fine-tuned to fit into the version 10 schema. In such a situation, limited changes can be made to setup and master file data—you get what you had in the legacy version, only now it’s in version 10. Tweaks can be made—new setup files can be defined and new parts, customers, and suppliers can be defined that replace or supplement their legacy analogues. But any data that has been transacted against remains in the database. It can be inactivated, but it’s still there, and some customers have a problem with this much clutter. Depending on the degree of the issues noted above, this may or may not be a big deal. Also, one of the upsides of a straight ERP upgrade is the ability to retain historical data with minimal effort.

Given the potential issues with data that a company may face, reimplementation offers the ability to cleanly address these challenges. It is common for businesses to transform significantly after their original implementations. They may have a number of legacy companies, sites and warehouses that are no longer needed and may even burden the database and create confusion internally. Customers may also wish to make radical changes to their company or site structures as a function of the upgrade. In these cases, consideration should be made to performing a reimplementation in lieu of an E10 upgrade.

Typecasting your Data Forecasting

When you perform a straight Epicor upgrade, you are accepting that you will take all of your past performances with you, and this may create challenges that impede your future state aspirations. Conversely, dumping your legacy database also involves leaving behind the historical data that amounts to the history of your business. Epicor’s E10 ERP software is a big step up from its 905 and 803 antecedents, and with each point release, the gap between the new and legacy versions widens further. Legacy Epicor customers looking to move their businesses forward will need to transition to a modern ERP platform, and Epicor’s E10 application provides a compelling case. And when making this critical Epicor ERP upgrade rewrite, customers will do well to consider their data dailies.

Looking for a good storyline for your Epicor upgrade? Learn more about E10 from our Epicor ERP team.

Epicor Functionality in the Admin Console, Unwrapped

by Brad Feakes | Mar 31, 2020 | Epicor, Epicor 10, Epicor Administration, ERP

New User Access, New E10 Functionality

Managing the Epicor functionality available to the user community is one key role of an Epicor Administrator. In this light, it’s not uncommon for customers using the Epicor application to continue to add new modules. An understanding of Epicor 10’s functionality develops over time, as administrators and users learn the full capabilities of E10 and how ERP can help run a business. Once new E10 modules are licensed, and once the license is installed, users will need to have an administrator enable access through the Epicor Admin Console in order to allow users to make use of this new Epicor functionality.

Let’s walk through the steps you need to know to effectively manage newly installed Epicor modules.

In order to enable a new module, you will first need to be logged into the application server, which is the box where your Epicor application is installed.

Once on the application server, open the “Epicor Administration Console”:

Once the Epicor Admin Console is open, perform the following steps to enable the desired module:

Open the “Server Management” node in the left tree view and locate the Epicor instance in which you wish to enable the new module. In the example below, it is the “Demo” instance.
Open up the E10 instance node and click on the “Licensing” node beneath it—this will display the license file in the panel to the right of the tree view.
Double-click the license file. This will raise a little properties window.
Navigate to the “Modules” tab. Sort by module name and locate the module you wish to enable. Check the “Enabled” box to enable the module in question.
Click the “OK” button to commit the change:

Once that is accomplished, a user who has just logged into the Epicor application should see the new module available in the menu:

If your team is making suboptimal use of your Epicor application, you can easily enable some new functionality through the Epicor Admin Console, and they’ll be licensed to thrive. There are several ancillary modules that can help extend the benefits of the Epicor application throughout your business. Epicor has plenty of goodies in the basket. The Epicor Admin Console is the tool for unwrapping these bonbons, enabling delectable Epicor functionality. Bonbon appétit!

Not sure what specific Epicor functionality to enable? EstesGroup specializes in Epicor ERP, and our consultants can help your users make the most of your Epicor License.