Select Page
Epicor BAQ: Returning Too Much of a Good Thing

Epicor BAQ: Returning Too Much of a Good Thing

Epicor BAQ

The Epicor BAQ (Business Activity Query) toolset allows you to leverage the mounds of data that your system generates. But the problem with mounds of data is its volume—when we say mounds, we mean… mounds. As such, Epicor has built in a feature to its BAQ designer to limit the number of rows returned.

 

This feature prevents a “runaway query” from tanking a company’s performance. This functionality was especially helpful when I first delved into queries, as it prevented me from needlessly tanking my environment. Looking back at some of my early queries, they certainly were tank-worthy.

 

But for experienced Epicor users working with large datasets, this limitation can be… well, limiting. When a query generates a dataset that is more than 10,000 rows, the following warning message displays:

 

Severity: Warning, Table: , Field: , RowID: , Text: Test results are forcibly limited to 10000 rows to prevent the application server memory overload:

 

Activity Query Epicor BAQ

 

This can be immensely frustrating to Epicor super-users, for there are cases when the entire dataset needs to be returned, to gauge the efficacy of a given BAQ. In the past, the workaround to this limitation was to embed the BAQ in a dashboard, as the 10K row limitation disappeared when the BAQ was part of a dashboard.

 

But such an additional step seemed like an unnecessary contrivance—scaling the fire escape when all you needed was a step ladder.

 

Fortunately, Epicor modified the BAQ designer to allow the person creating the BAQ to modify the Execution setting that limited the number of returned rows. The steps to make this possible are below.

 

From the Actions menu, select “Execution Settings”:

 

Activity Query BAQ Execution

 

Click the new icon to create the new execution setting.

 

This creates a new execution setting that needs to be defined. Then you can perform the following additional steps:

  • For the “Setting Name” select “RemoveTestRowLimit”
  • Set the Setting Value to “True”
  • Check “Persist In Query”
  • Click OK:
BAQ Query Test Execution

 

Thereafter, the BAQ will return all the available rows:

 

Epicor Activity Query Designer

 

The execution setting needs to be defined for each query for which you wish to return more than the default number of rows. Make sure to save the query after the execution setting has been defined.

 

Ready for a quintessential query?

 

Successfully navigating the Epicor application is rarely a matter of taking one great leap forward. More often than not, it is a series of small, incremental steps. With Epicor BAQ, your goal is to take your data and turn it into information—without getting lost in the volume.

 

 

To learn more about Epicor management and administration, please watch our video on cloud ERP by clicking here.

 

 

 

Are you lost in the volume of IT and ERP news available online? Sign up for one of our monthly newsletters, and we’ll bring you the highlights.

 

 

Part Master Best Practices? Ask Brad

Part Master Best Practices? Ask Brad

Part Master Questions

 

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…

 

Part Master Flow
Epicor Engineer-to-Order at Your Service

Epicor Engineer-to-Order at Your Service

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.

 

Epicor Engineer-To-Order

 

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 join us on June 17th for our virtual EstesGroup Epicor User Summit.

 

EstesGroup Epicor Summit: Click here to register via our website

June 17th, 2020, 10 am to 3 pm (Central Time)

  • 10:00-11:00 – Epicor Security: Make It or Break It (Daryl Sirota)
  • 11:00-12:00 – Leveraging Epicor Data Through Business Intelligence (Mark Herman)
  • 12:00-1:00 – Manufactured Parts Setup: Best Practices (Brad Feakes)
  • 1:00-2:00 – Embedded Customization: Custom Pop-ups and Other Tricks (Joe Trent)
  • 2:00-3:00 – Ask a Consultant: Professional Services Round Table

 

 

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

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

ERP

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.

old computer

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.

product management erp module

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 User Security – Allow Multiple Sessions (Video)

Epicor User Security – Allow Multiple Sessions (Video)

Your Epicor Application is In Session

 

Over the years, we’ve worked with a number of fledgling ERP administrators on resolving Epicor user security and user account maintenance issues.  One common quirk with Epicor user account maintenance relates to the flag that allows multiple concurrent sessions (in the database: UserFile.AllowMultipleSessions).  This is a powerful checkbox, significantly affecting a user’s experience of the application.  The best way to deal with Epicor user security troubles is to understand the functionality of the application, and our hope is that in this example, we can show you one way to avoid ERP administration headaches.

The multiple concurrent sessions flag itself is set via the Epicor User Account Maintenance screen:

 

The “Allow Multiple Sessions” checkbox defines whether a user can launch multiple sessions of the Epicor application.  This lets the user log in multiple times and interact with the environment and with the system from either session.  This can be helpful in performance-constrained environments, where a form might “hang” for a number of minutes and necessitate the use of a second session for subsequent parallel activities.  But none of this is possible if the checkbox is not set.  In practice, the setting of the “Allow Multiple Sessions” flag has two primary effects for a general user.

 

For customers working in multi-company or multi-site environments, when this flag is not set, a change to a user’s current company and/or site will force all open forms to be closed.  This does not occur when the flag is set:

 

 

 

If this checkbox is not selected, a user can only have one instance of the Epicor ERP application open at a time.  If they log into a new session while already logged into the system, the older session is deleted.

 

 

Once logged into the second session, the user will receive an error from the prior session, with a warning that the session has been cancelled:

 

 

Gaming the System

 

It’s surprising how significant the influence of enterprise systems is on manufacturing and distribution companies.  The configurations of these systems frequently determine the rules of the game that companies and their users have to follow.  Because of this, you have to choose your systems carefully and work to understand the rules by which they play.  

 

In an Epicor application context, dialing in the system to support the needs of your end user community is a key step in both the implementation and the ongoing maintenance of your Epicor installation.  In addition, it is important to understand how a company’s security involves more than just firewalls and endpoints.  Within a company’s domain, and within its core applications, it is important to understand what users should and shouldn’t be able to do.  In Epicor, many of these IT security permissions are defined through the User Account Maintenance screen.

 

Whatever your enterprise system of choice, make sure to leverage its security permissions to empower optimal user productivity, while also minimizing risk.  Beyond the bounds of Epicor user security, make sure to draw in all of your resources to create protective guidelines for your user community. 

 

Are you having issues with, or have questions about, your Epicor 10 ERP Application area? Contact us today.

Epicor Multi-Site Migration:  A Moving Guide

Epicor Multi-Site Migration: A Moving Guide

Out of Epicor Multi-Site, Out of Mind

 

An Epicor multi-site implementation, whether moving from a single site to multiple sites, or vice versa, is a common phenomenon in the manufacturing and distribution world.  Companies and sites in Epicor are rarely in a “set it and forget it” proposition.  As companies evolve, the need to further break out or combine business units can become necessary.  As your business grows, you might wonder if your satellite facility should be considered part of your main site or if it should be a site of its own.  Or, in a similar Epicor multi-site configuration puzzle, you might wonder how to map out the consolidation of a two-company environment into a single-company installation.

 

Assume, for example, that a company has four sites (A, B, C, D) split across two companies (1 and 2) in the following manner:

  • Company 1:  Sites A, B, C
  • Company 2:  Site D

And the company desires to combine operations under a single operating unit, such that the lone site under company 2 would be absorbed under the operations of company 1:

  • Company 1:  Site A, B, C, D

Such a change may seem like simply a matter of converting existing data—of pointing all records from the old company and site to the new company and sites.  Alas, systems are often less than accommodating in allowing for historical transactions to be modified in this manner.

 

Epicor Multi-Site Implementation Recommended

 

Epicor offers no toolsets to “move” a site across companies.  No toolset currently exists that provides the ability to change the company context of all records in a single instance, as to point them to another company context.  Historical transactions don’t like having their keys modified, and such revisionist history is fraught with potential challenges, and thus not recommended.

 

The recommended best practice in such an Epicor multi-site implementation scenario is to reimplement site 2-D in Company 1.  This would involve the setup and configuration of the site and the transfer of setup, master file, and open transaction data into the new site, and the continuance of business operations from within this new site.  This would not include the loading of historical transactions—it would essentially be an act of starting fresh in the new company, as if the site were converted from a legacy system and not from Epicor.

 

To achieve Epicor site consolidation, as described above, a four-stage process can create the desired infrastructure:

  • Plan:  The planning stage finalizes scope and organization through assessment, planning, resource organization, scheduling, etc.  The resolution of conflicts in data, customization, or configuration will occur as part of the testing phase.  Scripts will be developed for the movement of data and customizations.
  • Architect:  The architect stage involves the setup and testing of an environment that would represent the future state deployment, and the elicitation and resolution of any gaps, issues, or conflicts that would come from the planned deployment.  Key activities are the development of the test environment, testing of new site deployment, and gap/issue resolution.
  • Validate:  The validate stage is used to verify that we can successfully execute a cutover and run the business as intended, as if we were in a live environment.
  • Stabilize:  This is the final, successful deployment of a new site at cutover.

 

To address the scenario described above, the following environment map would be recommended:

  • Test Environment:  The initial environment used to model the construction of the new site.
  • Pilot Environment:  The environment in which conference room pilot (CRP) validation occurs.
  • Live Environment:  The existing Live environment, which will be updated at the cutover of the new site.

 

In a traditional Epicor implementation, we go through a five-stage process:  Plan, Educate, Architect, Validate, Stabilize.  This conventional waterfall approach to implementing an ERP application does not adequately address a scenario where training is not required, and prototyping is centered less on the use of the system than it is on properly implementing and integrating an existing Epicor process into a different Epicor company.  As such, the methodology is somewhat simplified, considering the team is already well-versed in the application.

 

The environmental build, relative to the four-stage model described above, would be as follows:

 

Architect:

Initial Live Environment Setup:

  • Extract Setup information from 2-D.
  • Create New Site D in company 1.
  • Update Site configuration in 1-D.
  • Update Company configuration in company 1, as needed.

Test Environment Setup:

  • Build Test environment from copy of production.
  • Extract master file records from Company 2 (Live) and load into Company 1 (Test) and reconcile Conflicts as needed.
  • Extract open transaction records from Company 2 (Live) and load into Company 1 (Test) and reconcile conflicts as needed.
  • Extract open balances and open AR & AP from Company 2 (Live) and load into Company 1 (Pilot).
  • Perform user testing to verify functionality in Site 1-D and the effect of adding 1-D on sites 1-A, 1-B, and 1-C.

Verify:

Pilot Environment:

  • Build Pilot environment from copy of production.
  • Extract master file records from Company 2 (Live) and load into Company 1 (Pilot).
  • Extract open transaction records from Company 2 (Live) and load into Company 1 (Pilot).
  • Extract open balances and open AR & AP from Company 2 (Live) and load into Company 1 (Pilot).
  • Perform conference room pilot (CRP) event to verify functionality in Site 1-D and the effect of adding 1-D on sites 1-A, 1-B, and 1-C.

Stabilize:

Live Environment-Cutover:

  • Extract master file records from Company 2 (Live) and load into Company 1 (Live).
  • Extract open transaction records from Company 2 (Live) and load into Company 1 (Live).
  • Extract open balances and open AR & AP from Company 2 (Live) and load into Company 1 (Live).
  • Perform any ancillary cutover activities as required.
  • Resume operation in new environment.

 

Considerations

 

As with any project, there are a number of considerations that should be clarified at the onset of an Epicor multi-site migration.  The following assumptions have been made:

  • There are always minor data transformations needed when loading data into a new Company and Site, such as the new Company and Site IDs.  You should give consideration to any transformations above and beyond these basic adjustments:
    • Are there data transformations that will need to occur beyond the necessary changes to allow the data to function correctly and without conflict in the new company?
    • Are there changes to setup tables that will need to be mapped when loading master files and open transactions?
  • There is a necessity to identify who will be building test case scripts and who will be performing the necessary testing and validation—and this validation is twofold:
    • Validate the functionality of the new site within the existing company.
    • Confirm that the addition of the new site does not introduce any processing issues with any of the existing sites.
  • It is critical to identify a process for resolving conflicts—the addition of a new site may introduce conflicts with the existing Epicor implementation, and a resolution strategy should be devised at the project’s onset.

 

Conflicts and Conflict Resolution

 

Potential conflicts may exist between Company 1 and Company 2, and these may surface as a function of the “move” of Site 2-D into Company 1.  These may include the following:

  • Company configurations in Company 1 may not be in agreement with those of Company 2.
  • Security and menu settings in Company 1 may not be in agreement with those of Company 2.
  • Conflicts between customizations and/or reports may exist between Companies 1 and 2.
  • System Agent configuration conflicts may exist between Companies 1 and 2.
  • Setup Table conflicts may exist between Companies 1 and 2.
  • GL structure conflicts may exist between Companies 1 and 2.
  • Master File conflicts may exist between Companies 1 and 2.

 

Historical Data Access and Epicor Multi-Site Design

 

With any such migration, questions exist as to how historical data will be accessed.  As noted above, our recommended approach does not include the loading of historical transactional data.  In the current situation, the historical data from site D in Company 2 will continue to reside in the database, but the ability to modify the data will be removed at cutover.  Read-only access and report access could still be permitted, to provide access to historical data.  Additionally, the utilization of cross-company BAQs could be applied for reporting from Company 1 and consolidating datasets between the legacy site 2-D and the new site 1-D.

 

As companies expand, it’s common for new physical facilities to be spun up and incorporated into the existing Epicor application in some form or fashion.  In other cases, companies manage parallel business within the same space, and may decide they need to better break these out, as to keep their operating interests independent of one another.  In all possible scenarios, Epicor multi-site implementation can be tricky, demanding a thorough migration plan.

 

 

Looking to tweak your company/site configuration as part of an Epicor upgrade?  Learn more about multi-company and multi-site upgrades here.