Select Page
12 Days of ECHO, Third Day: Some Notes on Epicor ERP Auto-Login and SysConfig!

12 Days of ECHO, Third Day: Some Notes on Epicor ERP Auto-Login and SysConfig!

On the Third Day of ECHO, my sys admin gave to me, swift yet safe: Auto-Login in Epicor 10.1 and beyond.

 

Interacting with technology can become a perpetual struggle between ease-of-use and security-of-use.  The two seem at odds, such that increases in security reduce the ease-of-use, and vice versa.  I once worked for a company that increased security after a user opened an infected email attachment and blew up her computer.  Thereafter, all email attachments were cloud-scanned before anyone could open them.  Safe—but now it took an extra five minutes to view an attachment.  We used to joke to ourselves that our network admin was going over the files byte-by-byte with a pair of tweezers in one hand and a scalpel in the other.

 

That is to say, Epicor users generally like things quick and dirty, while admins like things safe and clean.  Early versions of Epicor adhered to the quick and dirty principle: In early versions of Epicor, automatically logging into Epicor, in the absence of a single sign-on setup, was relatively easy—it was as simple as plugging the user ID and password into the .sysconfig file:

<userSettings>

<!– provide values for UserID and Password to enable auto-login –>

<UserID value=”manager” />

<Password value=”manager” />

 

This capability was especially helpful for those interacting with the system via Epicor’s Manufacturing Execution System (MES) or Handheld (HH) clients.  But storing plain-text passwords in a configuration file has long been anathema to system administrators.  As such, starting in version Epicor 10.1, a number of changes were made to improve Epicor’s security architecture.  As part of this effort, the ability to store passwords as plain-text in .sysconfig files was removed.  It was replaced with a more elegant means of achieving the same ends through the application itself.  The setup requires steps from both the Epicor administrator and the end user.

 

Epicor Administrator:

 

To allow users to auto-login, perform the following steps, while logged in as a security manager:

  • Open the “Password Policy” form (located under System Setup > Security Maintenance).
  • Select the “Allow save password” checkbox and save.

Epicor End User:

 

For those who intend to utilize auto-login capability, users must save their credentials in the following manner:

  • Log into the workstation as you normally would, using your Epicor username and password.
  • From the Epicor Homepage, click the “Settings” tile:
  • Select the “Preferences” option:
  • This will open the Preferences window. Select the “Automatic sign on” checkbox and click the “OK” button to commit the changes:

The next time the user logs in, the auto-login functionality will be invoked. 

 

Note: The above user steps can only be done after the Epicor admin has performed the necessary prerequisite steps, else the user will receive the error below:

As part of our ECHO Epicor managed hosting solution, we’ve helped a number of customers migrate from Epicor’s older config file-based methodology to its current auto-login configuration.  The above configuration is a one-time “set it and forget it” activity, which allows the user to utilize the auto-login functionality without issue.  In this way, Epicor has devised a solution that improves security without impeding ease-of-use—it is swift, yet safe.

 

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

 

Do you have questions or need assistance with your Epicor system?  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, Second Day: SQL Licensing

12 Days of ECHO, Second Day: SQL Licensing

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

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

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

12 Days of ECHO: EstesGroup ERP Admin Tips and Tricks

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:

  1. Epicor ERP SysRow-ID
  2. SQL Licensing
  3. Auto-Login Epicor ERP
  4. SQL 64K Clusters
  5. Too Much RAM for Your Epicor VM
  6. IIS Log Sprawl
  7. Epicor 10 Server Disk Space
  8. SQL Transaction Log Maintenance
  9. SSRS Stealing the Show (CPU)
  10. Epicor Performance Diagnostic Tool PDT for a Sanity Check
  11. Online Transaction Processing vs. Decision Support: How to Find & Avoid Deadlocks
  12. Ransomware 2020, The Good, The Bad, The Ugly

 

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

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

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 Epicorthough 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 twisterso I’ll save it for another day. 

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