Epicor Administration Archives - Page 2 of 3

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.

How to Update Multiple Tables in Epicor DMT

by Brad Feakes | Sep 27, 2020 | Epicor, Epicor 10, Epicor Administration, ERP Benefits & Features

Multi-table updates for Epicor implementation and beyond

As part of Epicor ERP’s overall implementation and optimization toolset, the Data Management Tool (DMT) is a fundamental aspect of a successful implementation strategy. It gives you the ability to load, update, and even remove data. These capabilities allow you to cleanly load the setup and master file data as part of an environment build activity prior to go-live. When a user imports data, DMT keeps upload and update behaviors in check so that data migration is efficient and effective.

Multiple Table Updates Data Management Tool Epicor

Epicor DMT also enables you to load live transactional records such as sales orders and purchase orders. These are essential to a successful cutover. Better yet, DMT possesses the ability to maintain records and improve the system’s data integrity long after the system is live. This allows an Epicor admin to efficiently clean up and even optimize the master file. This benefit also applies to transactional files in the live environment.

The Epicor ERP “Part” Routine

Within this context, one especially helpful capability involves the ability not only to update multiple columns of a table but to also update multiple related table records at once. For example, DMT’s “Part” routine allows for the creation and maintenance of records existing in the “Part” table. But DMT’s “Part Combined” routine allows not only for the creation of Part records. It also provides the ability to simultaneously add and/or update related Part Site (PartPlant), Part Warehouse (PartWhse), and Part Revision (PartRev) records. One could update these records individually, but Epicor provides the ability to perform multiple row updates in a single pass.

Sometimes DMT necessitates a multi-table setup in order to load and update data

For instance, the Resource table requires that you utilize the Resource Group routine to make updates to the Resource table. Let’s assume that you are the Epicor admin for your company. What if your operations manager decides to forgo using Epicor’s finite scheduling functionality? As such, you need to run an update to uncheck the Resource.Finite flag on all active resources. Should you search for a routine in DMT to update the “Resource” table, you will discover that none are available. Only the “Resource Group” load program is available:

Fortunately, you can utilize the Resource Group load program to update the Resources related to all Resource Groups. Within Epicor’s Data Management Tool, multiple table update routines utilize a specific field naming convention to differentiate the primary table from its child tables:

Primary Table: The field names are sufficient—given that the program knows the table context, the parent table (in this case, the “ResourceGroup” table).
Child Table: Epicor utilizes a [ChildTableName]#[ChildFieldName] convention when defining the fields for the child table to be utilized.

For example, should you click the “Required” fields button for the “Resource Group” load, you will discover that to update the “Resource” table, you will need a number of key Resource Group fields but also the “Resource#ResourceID” and the “Resource#ResourceDescription” fields:

multiple table updates in Epicor DMT resource group required fields

This is also evident when using the “Template Builder…” functionality to create a load template.

Given the above scenario, I opted to include the “Resource#Finite” field when creating the load template:

To perform the ResourceGroup-Resource parent-child table update to the finite-scheduling field that I had intended, I now have a load template with the following fields, named as follows:

Company
Plant
JCDept
ResourceGrpID
Description
Resource#ResourceID
Resource#Description
Resource#Finite

As is the convention with Epicor’s Data Management Tool loads, I entered my data into a spreadsheet:

Finally, by loading the spreadsheet file into DMT, I can now perform the necessary update. The file, as defined below, loads without error:

Multiple Table Updates in Epicor DMT Resource Group Finite Update

Epicor’s Data Management Tool is replete with capabilities.

However, these features that are not always well documented or communicated. But with a little foreign key fiddling and a few Epicor consulting friends, DMT can be of great assistance to your Epicor ERP implementation.

Learn about Epicor cloud

Epicor Administration & Helpful Tools of the Trade

by Brad Feakes | Aug 25, 2020 | Epicor, Epicor 10, Epicor Administration

A Day in the Life of an Epicor Admin

One of the best parts of working as an ERP consultant is the opportunity to work with so many smart people, and you’ll find many working in Epicor administration. Companies are successful for a variety of reasons, and the strengths, skills, and character of individual employees are at the core of organizational performance. The privilege of working with devoted coworkers makes it all worthwhile. As they say, iron sharpens iron — and even should a few sparks fly, I am thankful for the grind. Epicor admins come with a toolset capable of managing the application’s configuration, performance, and architecture — administration responsibilities that demand precision and prowess.

What exactly is an Epicor admin?

Of the many ERP positions I’ve encountered, none are so perplexing and nebulous as those responsible for Epicor administration. What I have come to understand is that the Epicor Administrator is as thankless a role as it is undefined. In my years as an Epicor consultant, I’ve encountered countless ERP administrators, and their skills and responsibilities extend in all directions.

For example, an average day for an Epicor admin might look something like this:

Address system errors first thing in the morning.
Perform an ad hoc backup of the production database and restore it over the test environment to give new employees a place to train.
Troubleshoot intermittent MRP issues.
Educate the engineering department on correct part setup.
Deploy yesterday’s dashboard tweaks.
Blow away some pesky personalizations that have been flummoxing a particular user.
Help the finance department with some BAQs in anticipation of the coming month’s end.
For free time, work on a chip-away-at SSRS report.
On the way out the door, kick off a DMT run to mop up some of last week’s indiscretions.

What does tomorrow bring for the Epicor administrator?

Every admin I’ve met hosts a similar blend of firefighting, process improvement, and general oversight. And in spite of the tremendous breadth that such a position demands, I have encountered many an admin whose depth of knowledge has matched their breadth. Over the years, I’ve done my best to learn from them and to document what I’ve learned. As such, here are a few Epicor administration tricks I’ve picked up along the way that you can bookmark, revisit, and share.

Need your BAQ to return more than 10,000 rows? BAQ Execution Settings help Epicor administrators get more data.

Learn about BAQ Exec

Have you wondered how to manage the multiple sessions flag in user security works?

Get multi-session tips

Do you need to enable new functionality through the admin console? Check out our post on Epicor licensing.

Enable functionality with the admin console

Looking to launch a form’s custom version from a right click or an MES button? Learn more about binding Epicor customizations using process calls and menu IDs.

Read about binding customizations

Trying to work out auto-login? Review Epicor sysconfig files and auto-login capabilities.

Work it out with auto-login

Need to relate UD tables to their parents? Learn how the SysRowID fields relate parents to children.

Relate

Are you running into the “CGCCode Mismatch” error when importing dashboards in Epicor 10? Learn how to edit a dashboard definition.

Create a dashing dashboard

Are you looking to deploy customizations in a multi-company environment?

Learn more about menu maintenance

Beyond Epicor Admin

Are you looking to go beyond administration knowledge?

Sign up for a free consultation with an Epicor consultant by chatting with us now.

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

Epicor BAQ: Returning Too Much of a Good Thing

by Brad Feakes | Jun 17, 2020 | Epicor, Epicor 10, Epicor Administration

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:

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”:

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:

Thereafter, the BAQ will return all the available rows:

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.

Epicor User Security – Allow Multiple Sessions (Video)

by Brad Feakes | May 2, 2020 | Epicor, Epicor 10, Epicor Administration

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.