Brad Feakes, Author at EstesGroup

12 Days of ECHO, Second Day: SQL Licensing

by Brad Feakes | Dec 9, 2019 | Epicor, Network Administration, Prophet 21

On the First Day of ECHO, my System Admin gave to me, SQL Licensing!

You probably already know that Microsoft SQL Server is required for Epicor 10 and Prophet 21, but do you know if you are in Microsoft compliance? SQL licensing can be confusing, but in most cases, it can be broken down to either “by core” or “by user”. There is an exception for SQL Enterprise licensing on a hypervisor, but that’s a specialized case. Most smaller organizations use SQL Standard Edition, as opposed to the more expensive and capable Enterprise Edition. Likewise, most Epicor clients use the “By core” licensing model as opposed to the “by user” model.

In short, if you are running SQL In the “per core” licensing model, each 2 cores that are available to the SQL server must have the appropriate licenses – with a minimum 4 cores. If you have more than one SQL server, then you must have a minimum of 4 cores licensed PER server! Keep in mind that the SQL Engine and the SQL Reporting Services are both licensed software, and if they are split to different servers, they EACH must have appropriate licenses.

We’ve seen instances of clients who increase their SQL Server CPU core count to see if they get faster processing, but often end up violating their license agreement and creating expensive problems when Microsoft Auditors come knocking. Likewise, splitting the SQL Engine and the SSRS functions will increase your license count.

One small consolation prize – multiple instances of SQL on the same OS do not require additional licensing beyond the first instance. Therefore, you might find some benefit to running another SQL instance on the same server to split queries. (See our future blog 11th Day of ECHO: Separating OLTP and DS – detecting and avoiding deadlocks)

The downside is that all SQL licenses are on an honor system – the application does NOT keep track of licenses, so it’s your job to make sure you’re in compliance!

Till next time, keep the holiday cheer!

If you liked reading the “Second Day of ECHO” return to our main list to read all of the other “12 Days of ECHO” posts.

Do you need assistance managing your SQL licenses or database administration? Please feel free to Contact Us and see if we can help get your bits and bytes in order.

[pardot-form id=”856″ title=”Blog Forms Submission”]

12 Days of ECHO, First Day: Relating Epicor Extended Tables via SysRowID

by Brad Feakes | Dec 9, 2019 | Epicor 10, ERP, Network Administration

On the first day of ECHO, my admin gave to me, some notes about my SysRowID!

Relating Epicor Extended Tables via SysRowID

As part of an ERP implementation, it’s not uncommon for companies to find the need to store information that does not easily fit into the ERP system’s existing database schema. Fortunately, Epicor ERP offers a robust ability to extend an existing database table and add fields to store custom data, to better address the requirements of an implementing company, and The Estes Group’s Echo hosting platform completely supports these critical capabilities.

On the technical side, adding UD fields to an existing table actually creates a new table in the Epicor database, a table that is structured to relate back to the original “parent table.” While two tables exist at the database level, the data model at the application level presents the two tables as a single unified entity, which allows customers to interact with the standard and custom data through BPMs, BAQs and form customizations, as if they were working against a single table.

While this capability is of great utility, there are times when an ERP administrator may have a need to compare child and parent tables, for administrative purposes. As such, it is helpful to understand the architecture for relating standard Epicor tables to their UD children at the application and database level. The following example intends to serve this purpose.

Adding UD fields to the Epicor ERP application is done though the “User Defined Column Maintenance” form. In the following example, I added a UD field to the standard Epicor ERP Part table:

Once UD fields are added to one or more tables, the administrator needs to regenerate the data model from the Epicor Administration Console on the AppServer. In the example, I regenerated the data model as follows:

Performing the above tasks adds a “Part_UD” table to the Epicor database:

It also synchronizes the application’s data model with the database:

In the following example, I went on to query the Part UD table. Note the “ForeignSysRowID” field—as you can see, the key to a UD table is based on the SysRowID of its parent, since the records of a UD table exist in a 1-to-1 relationship with their parents:

As such, if you join the Part_UD table to its parent Part table where Erp.Part.SysRowID = Erp.Part_UD.ForeignSysRowID, you will receive results similar to the following:

Whether on premise or in a hosted solution such as ECHO by EstesGroup, Epicor’s database extension capabilities are of great use to implementation teams and end users. For ERP admins, an understanding of the underlying structure can serve to assist in managing the database and the application, should the need arise.

If you liked reading the “First Day of ECHO” return to our main list to read all of the other “12 Days of ECHO” posts.

Do you need assistance managing your data, UD or otherwise? Please feel free to Contact Us and see if we can help get your bits and bytes in order.

12 Days of ECHO: EstesGroup ERP Admin Tips and Tricks

by Brad Feakes | Dec 9, 2019 | Epicor 10, ERP, Managed IT Services, Network Administration, Network Security

This Holiday Season, EstesGroup would like to give you “12 Days of ECHO” tips and tricks for those ERP System Admins out there.

We understand this time of year there is a lot going on for companies, such as: year end preparations, budgeting for the next year, personnel changes, and company shifts, etc. So that being the case, we wanted to bring a bit of humor and help to your holiday.

The 12 Days of ECHO:

For any questions or for assistance this Holiday Season, please Contact Us or let us know below:

[pardot-form id=”856″ title=”Blog Forms Submission”]

Understanding Epicor ERP’s “Default Revenue Recognition Method” Error is Part of Company Configuration

by Brad Feakes | Dec 4, 2019 | Epicor, Epicor 10, ERP Risks and Challenges

Revenue Recognition is Everything

When I was still part of the user community, I was involved in a planned implementation of Epicor at one my company’s divisions. The division was in the construction industry, and the ERP systems of the time routinely encountered gaps in addressing the business requirements that come out of construction management environments. This was back in the days of Vantage 803, and at the time, Epicor’s construction management capabilities were rather thin.

To address this yawning void of a gap, a large customization was in the works to allow for increased revenue recognition (or “rev rec”) functionality as part of Epicor’s Project module. This functionality would eventually find its way into Epicor’s base package, but at the time, all anyone at my company could talk about was “rev rec”… “We can’t start prototyping until rev rec is ready.” “There’s no point in testing until rev rec has been implemented.” Everywhere I went, all anyone could talk about was “rev rec.” Still rather green in general and quite new to the business models of the construction industry, such shorthand was immensely confusing: Just what exactly is revenue wrecking? Isn’t revenue a good thing? I was befuddled.

I wasn’t the only one. As is the case with many of such monumental customization projects, all of these discussions were in vain, as the division never came close to going live on Epicor—though the functionality that came out of this failed attempt was pretty cool! Many years later, I’m still quite oblivious to the intricacies of the construction industry, but I have managed to get past one annoying revenue recognition error when setting up a new company in Epicor. As part of initial company configuration, I’ve encountered the following “Default Revenue Recognition” error message a number of times:

The message reads as follows: “Default Revenue Recognition Method cannot be None or Blank when not allowed to be changed per project.” Well, that’s not especially helpful, especially given that the error normally surfaces when configurating another area of the applicant, such as the Modules > Production > Job area above.

As it turns out, the cause of this error actually resides in the JCSyst.DfltRevRecMthd field, as found on the Modules > Services > Project Billing tab:

Selecting a method is normally sufficient to get past this error, though additional setup may be required, depending on the method selected. Even if you don’t intend on using revenue recognition, this step is necessary, depending on the modules licensed. So don’t let revenue rec your company configuration—set your default revenue recognition method and move on to bigger and better things… like deciding whether or not to schedule into the past! Now that conversation requires three cups of eggnog and a game of twister—so I’ll save it for another day.

Have questions about Revenue Recognition Methods or Company Configuration? Let us know below or Contact Us today.

Getting Past the “CGCCode Mismatch” Error When Importing Dashboards in Epicor 10 ERP

by Brad Feakes | Nov 26, 2019 | Epicor, Epicor 10, ERP

In work and in life, I find myself torn between two ambivalent instincts: the instinct for understanding and the instinct for action. It is often of great utility to understand as much of a given situation as possible—to be able to relate its causes and effects. I think back to my Six Sigma days, to years of enlightening multi-factor designed experiments. While this kind of understanding is summoning in itself, sometimes you simply don’t have the time to design an experiment to be in the know. Sometimes you need to go straight to action itself as knowledge.

The life of the ERP administrator is often torn between such directions of learning. The Epicor 10 ERP admins out in the user community that I’ve met over the years are some of the most knowledgeable people when it comes to navigating Epicor 10 ERP’s ins and outs, and I’ve learned much from their deep understanding of the application, from the end-user’s experience, all the way down to the application’s lower–level functionality. But admins also understand that if something needs to happen by morning, it needs to happen, and have therefore developed an appreciable measure of pragmatism as to be able to triage situations and “git er done” as needed.

One such circumstance occurs when importing dashboards, especially when the dashboard is coming from one company to another or from one version to another. In my own practice, I have a bundle of old favorite dashboards that I have developed over the years, going back to my own time in the user community. And over the years, I’ve doled these out to customers, to assist with issues that they are experiencing. In so doing, I have, on occasion, encountered the strange “CGCCode mismatch” error upon import. Here’s how it happens:

I follow the normal protocol of importing a dashboard definition:

But I receive this quarrelsome application error message in response: “There is CGCCode mismatch. Dashboard export created with CGCCode=US. Import cancelled.”

One could talk at length as to why this error occurs without coming to a specific answer.  While I don’t have a good explanation of the source of the issue, I do know how to get rid of the error, as to allow the dashboard to be imported.

Opening the dashboard definition in Notepad, I search for the “CGCCode” tag:

I locate the nearly “PropertyValue” node and discover that the value is “US”, as was specified in the above message:

I delete this value and save the definition:

Thereafter upon subsequent import, the dashboard will load successfully.  While I think it’s optimal to know a situation’s underlying causes and effects, sometimes circumstance demands simplicity.  As such, if you’re in need of getting a dashboard loaded on a timeline, and need to get functionality in front of the user community in a hurry, this little hack might be just the trick for fixing your CGCCode mismatch error in Epicor 10 ERP.

Are you having issues with, or have questions about, your Epicor 10 ERP Dashboards or Technical areas? Contact Us today.

[pardot-form id=”1302″ title=”Ask Us”]