ERP Consulting Archives - Page 12 of 17

Epicor Process Set Maintenance: Bundle Up

by Brad Feakes | Jan 6, 2021 | Epicor, Epicor 10, Epicor Administration, ERP Consulting

Scheduling ERP Processes

Batch processes have been with us since the inception of business computing. You can complete a batch of tasks as a single process for sake of efficiency. The benefits of such processes are clearly time-saving for an Epicor administrator. Batch processing allows for the automation of many tasks that would take an actual user an immense amount of time and effort to perform in order to accomplish the required manual tasks and calculations. In ERP software, the Materials Requirements Planning (or MRP) process is probably the most well known of such processes. As ERP systems have become more advanced, the need to group multiple processes to operate in harmony has become increasingly important.

Female using cloud technology on a mobile workstation

Epicor Process Bundling

In an Epicor context, there are many processes that you might want to sequentially bundle, such as following up an MRP regeneration by running the production planning and the shop schedule load graph processes, such that you can see the implication of the MRP run on material shortages and shop load respectively.

Sounds simple enough, but the problem with this scenario comes with the fact that such processes often run in the wee hours of the night, and only the most zealous members of the ERP fandom would wish to set their alarms for 3:00 AM so they can manually kick off a few ancillary processes once the MRP regen completes.

Enter Epicor’s Process Set Maintenance. Epicor process sets allow Epicor admins to bundle process runs into a single event. This allows you to sequentially run a suite of Epicor processes automatically, without human intervention. Process sets can include various differences:

processes
reports
executive queries

Once a process set is defined, and then attached to a system agent schedule, the related tasks are automatically processed according to the timing defined by the system agent.

Let’s look at a common issue, one that surfaces frequently for an Epicor admin. At times, you may wish to run processes in a manner that filters the actual processing. For instance, you may wish to run MRP by site, or PO suggestions according to a handful of part classes. Confusion is commonplace in handling process sets when the processes involved possess filtered activities. I’ll give you an example of the problem and an explanation of the actual behavior an Epicor admin can expect to experience when setting up and executing a process set.

Epicor Process Set Maintenance With Process Filters Enabled

Creating a process set occurs through the Process Set Maintenance screen. Once a process set is defined, individual processes can be assigned to a process set. In the example below, I created a process set:

Next, I opened the PO Suggestion screen and configured its process parameters. Of those parameters, I set a site-specific filter:

Epicor Generating Purchase Suggestions Screenshot

Then I clicked the icon below to save the PO Suggestion process to the process set I previously created:

Returning to my original process set, I now see that the PO Suggestions process has been attached to the process set. Were I to go through the same actions with other processes, I could add multiple processes to this process set, and then use the “Move Up” and “Move Down” buttons to order them appropriately. But one point of confusion exists here. If I were to double-click on the process that I just added, to review its properties, the filter that I previous defined is no longer visible:

As we will see, this cosmetic issue is not detrimental to the actual execution of the processes themselves. To complete the setup of a process set, you need to assign it to a System Agent Schedule. This is accomplished through the Schedule Process Set screen. From this screen, you can select the Process Set:

Allowing the System Agent schedule to run according to its next run time, I can see in the Epicor System Monitor that the underlying process ran successfully:

Looking at the Log File related to the PO Suggestions run, I can see that the PO Suggestions process ran according to the filter that I had initially set. As you can see, the log file indicates the Epicor site that I had defined:

Epicor Admin Automation

In summary, while it may appear that an Epicor process loses its configured filters when added to a process set, in actuality, these parameters are retained, allowing the Epicor Admin great flexibility in automating a variety of ERP system activities.

Epicor Consulting? Epicor Managed Hosting?

Get advice from an ERP consultant or managed IT specialist. Chat with us to get a free ERP consultation or technology assessment.

Epicor Server File Download: Serving the Process Server

by Brad Feakes | Jan 3, 2021 | Epicor, Epicor 10, Epicor Administration, ERP, ERP Consulting

The Pandora’s Box of ERP

Epicor processes can be a Pandora’s box of complexity. Rumbling under the surface, these processes perform innumerable tasks that allow an ERP system to function effectively. But when these processes fail to deliver the expected functionality, understanding the logic of these subaltern beasts can be problematic.

Happy distribution warehouse manager holding a cloud-enabled mobile tablet

Was it a problem with network connectivity?
With master file setup?
With company configuration?
Was it a bug?

Accessing Log Files Through Epicor Server File Download

One can spend an immense amount of time trying to troubleshoot these processes, especially given the timing required to perform trial-and-error with back-end processes. Such repetition gives ERP wheel-spinning a new meaning.

Fortunately, Epicor has a means of slowing the wheel, if not breaking it altogether. It is a general best practice when designing and developing complex programs and processes to include some form of logging. This provides the end user, or Epicor admin in this case, an opportunity to divine the logic of the program in question. This can help you troubleshoot process issues quickly.

In the past, gaining access to these logs to anyone but an Epicor administrator has been problematic. But in recent versions, Epicor added functionality to allow an end user to access server-side log files: Server File Download.

Epicor Server File Download provides the ability for a given user to look up various types of log files and save them to a local location. This allows you to retrieve and review log files. It does not require access to the server locations where they are stored.

Let’s assume that I kicked off a PO Suggestions process and enabled logging, specifying both the logging level and the log file name:

Epicor Server Download Generate Purchasing

As the process runs, it writes a log file to the server. The log file can be retrieved using the following method:

Open the “Server File Download” screen, which has the following menu location: System Management/Schedule Processes/Server File Download.
Choose the Directory Type. User: These logs normally refer to the user-specific logs. Company: Company type files are the most common logging methods and logs for processes such as MRP or PO Suggestions normally land here. Reports: This area holds XML files related to Crystal Reports.
Use the “Select File…” button to identify the file you wish to retrieve.
Use the “Client Path…” button to define the location to which you want the file saved.

Clicking the “Select File…” button allows you to search for and select the file in question. In the example below, I located the file that I had named previously, when I kicked off PO Suggestions:

Clicking the “Client Path…” button allows you to specify the location to which you intend to download the file:

Epicor Server File Download Browse For Folder Screen

Once the source file and the destination location have been defined, select the OK button. This will kick off the download activity:

Once the download has completed, the system will raise a download status message:

Once downloaded, you can navigate to the specified path and access and review the log file to better understand the details of the process itself:

ERP system troubles? Check the log…

Navigating the workings of an ERP system’s back-end server processes can feel at first like an exploration into the Eleusinian Mysteries. Fortunately, Epicor’s Server File Download toolset allows you to unearth the hermetic actions of Epicor’s darker processes, hiding in the process server’s chthonic cave, bringing them into the platonic light of your client folder and making them visible for all to see.

Never miss an ERP step. Learn about our private cloud hosting solutions.

BEGIN A CONVERSATION WITH OUR CLOUD CONSULTANTS

ERP Implementation Best Practices: Closing the Gaps

by Brad Feakes | Dec 3, 2020 | Epicor 10, ERP Consulting, ERP Implementation, ERP Selection

ERP Implementation Challenges

Bridging functionality gaps in ERP is one of the great challenges in an Epicor implementation, or of any enterprise resource planning project. There are often visible gaps between a company’s business requirements and the system’s ability to address them. In a perfect world, the needs of the company perfectly match the capabilities of the system they are implementing. In practice, the gaps between an organization and its ERP application can be significant, and closing these gaps can take significant effort. The inability to successfully close these gaps is a leading cause of project failure. This guide will help you understand a few ERP implementation best practices to help address the great challenge of closing the gaps.

ERP Customization

Find creative ways to use the system’s standard configurations to address the needs of your business.
Adjust your business processes to conform to the system’s recommended best practices.
Tailor the software in one form or another to provide needed functionality.
Combine the above methods to achieve a hybrid solution.

So why do businesses feel the need to tailor the applications they implement? ERP software customization is a means of closing gaps. Sometimes, it is the preferred means of addressing challenges before they start. Often, gap closure will involve some form of customization. The overall level of ERP project complexity will expand with increasing challenges and risks. In general, the different types of obstacles encountered in an ERP project can be grouped under one of a few headings. Customizing an ERP application allows you to do a number of things and to circumvent a number of issues:

Automate tasks. The standard system is too transactional and user-intensive.
Prevent errors. The standard system allows for too many points of failure as a function of user entry.
Integrate with third-party systems. The standard system does not provide specific functionality, necessitating a tertiary application. Similarly, the standard system does not integrate with the third-party module in question.
Extract and display data. The standard system’s out-of-the-box reports do not present the necessary information needed by the business.
Add business logic. The standard system does not possess logic needed by the implementing company.

The Total Cost of Ownership of an ERP Solution

The rule of thumb that came out of the first generation of ERP systems was simple: avoid customizing the ERP system at all costs. Fit the business to the software, not the software to the business. Considering the comparatively rigid systems of the era, this recommendation seemed valid. Earlier-generation ERP systems contained limited toolsets for tailoring the application to meet the needs of the implementing organization. As such, customization essentially implied a source code modification, and such changes were detrimental to the long-term maintainability of the systems involved.

ERP Implementation Best Practices Evolving

Next-generation ERP systems contained improved toolsets to provide non-source-code customizations that were upgradable and maintainable, but the disruptive effects of customization on the implementation projects nevertheless continued unabated. Why do ERP customizations continue to create challenges to organizations?

Customizations are disruptive—they introduce logic to the application that is not native to the core system. They may also behave in ways that are unlike the rest of the system, and tend to be less comprehensive than the source code that they are layered upon.

As they are developed and refined, they often contain bugs. For example, the custom business logic may be invoked at times when it isn’t expected, or may not be invoked in all cases that require it. Working though these bugs can be challenging. Moreover, when customizations run into bugs or undocumented features of the core application, an abundance of unexpected behaviors can result.

ERP Toolsets & Project Success

Everything said, how do companies successfully leverage the customization toolsets available? How do they provide the necessary functionality to their organizations without compromising project success? Consider the following observations:

On one hand, we’ve seen companies significantly customize their application in an organized and methodical fashion. Therefore, the customizations produced a limited disruption to the implementation.
On the other hand, we’ve encountered other companies that only modestly customized their application. The modest number of customizations significantly disrupted the implementation. Why?

Organize to Optimize Your ERP Software

The level of customization and the level of organization of a project are closely tied. Therefore, companies that organize their customization efforts carefully are much less likely to experience problems caused by customizations. Conversely, poorly organized customization efforts will create additional issues that will add complexity and disruption to an implementation that is already, by its very nature, complicated.

Quantifying the impact of these two variables (customization and organization) can be difficult, but a simple mathematical model might help to model their interaction.

Assume that a project’s level of disorganization can be scored on a scale from 1 to 10, with 1 being highly organized and 10 being highly disorganized.
Similarly, assume that a project’s level of customization can be scored on a scale from 1 to 10, with 1 being lightly customized and 10 being highly customized.
Additionally, assume that a project’s success can be scored on a scale of 1 to 100, and anything over a score of 20 is a bad thing. For example, the project could be over budget, behind schedule, or low in scope or quality. In this context, a score of 30 might imply a project that went live late, or had to cut scope, or exceeded the budget, while a ruination score of 100 might represent a project that is years late, millions over budget, and so poorly designed that it will fail to go live.

A score of 1 (very low customization, very low disorganization) represents a very low risk score and a score of 100 (very high customization, very high disorganization) represents immense and catastrophic risk to your ERP and to your business:

The simple lesson to be learned here is that an organization can perform reasonable amounts of customization to their ERP application without destroying an implementation. A company needs to take steps to utilize an organized approach to customizing their application.

ERP Risks

A challenge with this dilemma is the reality that most companies do not launch an ERP implementation project believing that they will customize the application significantly. As a result, when these change requests surface, they are normally ill-equipped to handle them, and things soon spin out of control. As such, many customers come to us asking the simple question: What does it mean when one’s customization methodology is highly organized?

ERP Project Risk Management

There are a number of characteristics that an organized implementation possesses. They include the following:

First and foremost, governance is in place, to control when customizations occur. Governance is the best way to keep the degree of customization from spinning out of control.
Solutions are tracked. The implementing company understands which modules have been customized and which reports have been altered. They have identified all truly custom entry screens, reports, and dashboards. This information is put to use whenever an ERP upgrade occurs or a new site goes live.
Business requirements and functional specifications are developed as solutions are developed, and these solutions are constructed using these specifications.
Guidelines are defined ahead of time. These are conventions that describe how custom solutions are to be constructed, organized, and named.
Solutions go through careful testing. They receive a unit test to ensure that the basic requirements have been met, and then a regression test, to ensure that they function appropriately within the overall application, and don’t break anything else.
Solutions go through careful deployments to the production environment. When old solutions replace new solutions, the old solutions are removed from the environment as part of the deployment, to prevent the environment from getting cluttered with old, inactive solutions.
When an ERP module is customized, the developers take into account the full suite of new and pre-existing customizations, as to ensure that new elements are optimized to efficiently work in concert with existing custom solutions.
Environments are constructed as to segment various activities such as functional design, custom solution development, and upgrade verification. When these activities overlap, conflicts invariably arise, and these can slow down the progress of a project and create needless confusion.

The Goal of an ERP Implementation is Twofold

How do you implement a system that satisfies the needs of your business? How do you stay scalable and maintainable and also support the future requirements of your organization?

The future of your business is always unknown, and often unpredictable. Therefore, cutover will surely present new unknowns. Heavy system customization often results in the achievement of the goals of business needs. Unfortunately, this can risk the long-term maintainability of your ERP system. An organized and methodical approach to system customization supports a more successful implementation. Moreover, it provides easier long-term maintenance of your application. Likewise, it holds the ability to support the business requirements of the future.

After the ERP Vendor, the Software

Are you trying to improve your manufacturing processes? Do you need user training to empower your ERP project team? Are you looking for the competitive advantage that cloud ERP offers? Do you need help with data migration to an ERP hosting environment for a complex enterprise resource planning software like Prophet 21, E10, or Sage? We have experts for everything ERP, whether you need Epicor consulting assistance or QuickBooks hosting guidance.

For 17 years, EstesGroup has served clients at every step of the ERP implementation process. We offer real-time support 24/7/365 for your implementation team. We optimize your technology, and we lighten the burden on the precious human resources that make your company unique. Your team can work according to their talents, while we do the routine work involved in managing your ERP software and the technology that supports it.

Learn More About ERP Implementation Best Practices for Cloud

A good ERP balances your budget, opens your resources to new possibilities and opportunities, and improves everything from customer relationship management to industry-specific compliance and cybersecurity. ERP cloud hosting provides an ideal platform for your work. Request an ECHO demo today to see how EstesCloud managed services can help your business.

Epicor System Monitor: Canceling a Hung Task

by Brad Feakes | Oct 24, 2020 | Epicor, Epicor 10, Epicor Administration, ERP Consulting

Epicor’s System Monitor is a handy ERP tool that can be used for one of many purposes in working with the background processes and reports that Epicor’s Task Agent orchestrates. The Epicor Task Agent handles all server-side tasks for a given application server. These can be scheduled tasks or “immediate run requests” that are triggered by end users. Additionally, these can be SSRS reports or long-running processes like MRP or PO Suggestions. Whatever the tasks may be, the Epicor System Monitor is the perfect tool for viewing their status as they run, and their history once they complete.

Chalkboard Sketch of Planning Steps Including Tasks

On occasion, a task may hang or get stuck such that it prevents further processing. Imagine that a process such as PO Suggestions hangs up and stops processing, for one of many reasons. Tasks are stored in Epicor’s SysTask table, and if an active task such as PO suggestions is stuck in the System Monitor, it will prevent any subsequent attempts to run PO Suggestions. This can be a great problem to a company that needs to get new suggestions in the hands of its purchasing department.

Epicor System Monitor Generate PO Suggestions

Fortunately, there are a number of steps one can take to cancel or complete a stuck task.

When troubleshooting a stuck task in Epicor, look to address it in the following order:

Cancel the task in the System monitor
Bounce the Task Agent
Bounce the AppServer instance
Update the rogue SysTask record directly in SQL

Cancel the Task in the Epicor System Monitor

The simplest way to kill a task is using the Epicor System Monitor itself. This can be done by navigating to the “Active Tasks” tab, selecting the task you intend to cancel and clicking the delete (“X”) icon. If successful, this task will fall out of the “Active Tasks” queue and fall into the “History Tasks” queue as a task with a status of “Cancelled”:

Bounce the Task Agent

If the task will not cancel through the System Monitor, you can try to bounce the Task Agent itself, which may free up the task and allow it to cancel. This is a relatively noninvasive method and will generally go unnoticed by the user community. From the AppServer, launch the Epicor Administration console, and from the Admin console, launch the Task Agent Configuration utility. Select the task agent you wish to cancel and from the “Actions” menu, select “Stop Agent…”:

Bounce the AppServer Instance

If a Task Agent bounce is ineffective, bouncing the AppServer itself may work. This is a much more invasive solution, so it should be done when the user load is low, or else at a prescribed time such that the user community will be prepared. From the Admin Console, navigate to the server you wish to bounce, right-click the server node and select “Stop Application Pool.” Once stopped, right-click it again and select “Start Application Pool.” In my experience, this will normally shake loose the stuck task:

Epicor System Monitor Admin Console to Stop a Hung Task

Update the rogue SysTask record directly in SQL

If all else fails, your last recourse is to update the SysTask record through SQL Server. Opening an instance of SQL Server Management Studio, navigate to the Database in question and create a new query. Enter the script below, adjusting the SysTaskNum to reflect the specific task number as found in the System Monitor. Run the query to update the record. While I am never a fan of direct SQL updates, this is one case in which such an update may be necessary.

update ice.SysTask set EndedOn = GetDate(), TaskStatus = ‘Complete’, History = 1 where SysTaskNum = 55228
delete ice.SysTaskKill where SysTaskNum = 55228

The Epicor System Monitor Lets You View, Manage and Cancel Tasks

At times, Epicor tasks need to be stopped. Hopefully, this article helped you understand the steps to take when trying to kill a task. This Epicor screen shows you which tasks are active, and it enables the initial steps for task resolution. You might even use this ERP feature daily. Due to its usefulness, the System Monitor is a classic. If your ERP system is a labyrinth, then your Epicor System Monitor is a golden thread, helping you navigate the maze and kill the wrongful task. As I’ve always said, it’s better to monitor than to minotaur…

For more ERP tricks from our Epicor consulting team, ask us for a case study on CTO and ETO implementations.

Or click here to watch our Epicor Summit to learn about Planning Workbench, SQL Server Administration, and SSRS Reports.

Epicor ERP Event: EstesGroup Fall Summit 2020 (Video)

by EstesCloud | Sep 15, 2020 | Epicor, Epicor 10, ERP Consulting

An Epicor ERP Event to Begin a New Season

Are you ready for change? In June, we gathered friends and strangers together at an Epicor user event covering everything from master file setup to security to embedded customization. To further support this ERP community, we’re meeting again on October 7th for another Epicor event that will raise awareness of new techniques for manufacturers and distributors using ERP software solutions. This fall summit will serve to assist Epicor users with customization and optimization steps that are often overlooked by ERP project teams.

Epicor is a large and complex application and can be configured in a multitude of ways. Depending on how you’ve configured your application, different capabilities and different issues present themselves, and understanding how other Epicor customers have addressed these issues is often a great way to add perspective to your own challenges. On the technical front, the tools available for super users often span the skillsets of multiple roles, so for those of you who wear multiple hats by necessity, a better understanding of some of Epicor’s key technical foundations can assist in better maintaining and optimizing your installation. If you’ve experienced work culture shifts because of the pandemic, you might benefit from new Epicor consulting techniques that can address challenging project checkpoints (like conducting an Epicor CRP remotely, for example).

Making the Most of the Planning Workbench

Job management and scheduling are critical to any ERP implementation, but no two companies manage the work orders passing though their factories in quite the same way. Not surprisingly, Epicor offers a number of planning and scheduling tools that often go underutilized. Epicor’s Planning Workbench is one such tool, and integrating it into your suite of management tools can take a little fiddling, and its tendrils extend into Epicor’s part master setup, into its Time Phase and MRP programs, and even into Epicor’s underlying PartDtl table. In this session, we’ll be working though the logic underlying the Planning Workbench and demonstrating how it can be leveraged to keep ahead of quantity and timing issues on your shop floor.

SQL Server: Tips and Tricks For the Epicor Administrator

For those in the user community with Epicor experience that dates back to the days of 905 and earlier, the challenges of working with Epicor’s legacy backend are long remembered, like bad memories from another place and time. With the advent of Epicor’s E10 application, Epicor moved to an entirely Microsoft-centric stack, resulting in a much more stable, robust and scalable platform. And now that Epicor’s E10 ERP platform is built upon Microsoft’s SQL Server database engine, there are many new tricks and techniques that can be applied to best leverage the capabilities of the SQL Server RDBMS, while avoiding the common pitfalls of SQL Server administration. Understanding the principles of configuration, tuning and optimization at the database level can have a significant positive impact on your Epicor application’s performance and stability. In this SQL Server session, we’ll provide key insights to keeping your database server running smoothly.

SSRS Reporting: Modifying Standard Reports

Speaking further along the lines of Epicor’s Microsoft-centric stack, Epicor’s use of Microsoft’s SQL Server Reporting Services (SSRS) as its primary reporting platform allowed for tighter integration across the different elements of the application. But the move from Crystal Reports to SSRS was a significant one, given that SSRS differs significantly from Crystal in its fit, form, and function. For users unfamiliar with the paradigms underlying SSRS, simple things like adding a logo or a field to an existing report, in order to address the needs of a given company, are not always self-evident. In this SSRS Reporting session, we’ll provide some steps that will allow you to make basic modifications to standard reports to help fit them effectively into your business.

Watch this ERP event

Watch the Epicor summit recording

Watch our Epicor ERP fall event preview to begin a new season of ERP solutions.

Planning Workbench

Presented by Brad Feakes

SQL Server

Presented by Daryl Sirota

SSRS Reporting

Presented by Joe Trent

How to Manage Epicor Part Replacement

by Brad Feakes | Sep 9, 2020 | Business Consulting, Epicor, Epicor 10, ERP Consulting

One area of Epicor consulting that we frequently get asked about spins around engineering change orders. Engineering updates to the part master once the company is live has been likened to working on a car’s engine while speeding down the freeway. This is especially true when creating new parts to replace existing parts in existing Bills of Materials. It would be an understatement to say that parts are rather important to ERP systems—even novice Epicor consultants know that parts are one of the foundational building blocks upon which everything else rests.

How to Introduce Engineering Change Order

Shake-ups to the part structure invariably have tremor effects on the upper decks, so you would want to minimize these by following a careful approach to introducing engineering change order. Such an approach involves two steps: carefully understanding the exposure of the legacy parts to be replaced and planning the update accordingly, and then systematically executing the necessary updates to pull off the switch. In one case you might be renaming a part or a number of parts, to ensure consistency across your part master. But such changes affect a number of areas, so the steps to execute such changes need to be well planned out and executed. The following is a guide to do just that—planning and executing Epicor part replacement within your business system.

Planning and Review: Steps for Replacing Parts in Epicor

Before making changes, it is a good idea to plan through the changes you wish to make and ensure that all areas of the system that might be affected by these part changes will be addressed. The following tasks should be performed before a change is implemented:

Review any cases where the part exists on an open sales order and review any related allocations.
Review any cases where the part exists on an open purchase order or purchase order suggestion.
Review any cases where the part exists as a job material—this might include open firm jobs and unfirm jobs.
Review any cases where the part exists as the part to be made on a job header— this might include open firm jobs, unfirm jobs, and even part suggestions in the planning workbench.
Review the cases where the part exists in the BOM of another part.
Review the cases where the part is located in a Part Bin as on-hand inventory.

Execution of Part Replacement in Epicor

Once ready to execute the changes, care should be taken to ensure the proper steps are done, and in the proper order:

Create the new parts, revisions, MOMs, part costs, etc.
Run an update to replace the material parts in any part Bills of Materials.
Remove any Sales Order Allocations. Run an update to replace the parts in any Sales Order Lines.
Run an update to replace the material parts in any open, firm Jobs’ Bills of Materials. Delete any unfirm Jobs that contain the legacy parts as materials.
Run an update to replace the Job Header parts in any open, firm Jobs. Delete any unfirm Jobs for the legacy part. Delete any Part Suggestions for the legacy part.
Run an update to replace the parts on any open purchase order lines. Delete any PO Suggestions for the legacy part number.
Run a quantity adjustment update to remove the on-hand quantities of the legacy parts. Run a quantity adjustment update to add the on-hand quantities of the new parts, using the legacy part quantities that were previously on-hand.
Inactivate the legacy part.

Playing the Part in Epicor Part Replacement

Above all, care should be taken to make sure that sufficient communication has been made across the organization, beginning with your designated Epicor consulting team and extending throughout your entire company’s infrastructure. As you can see, such a change affects multiple modules, so you can anticipate that many people and departments will likely be affected by such a change in Epicor. As such, make sure to communicate accordingly. Following the proper steps, you can help keep your part master clean, and your business system running smoothly.

Looking for more tips from our Epicor consulting team?

Read our white paper on Epicor Part Setup.