I just need to get this off my chest – so bear with me.
First off, I’ve been doing sysadmin work for scores of years now, and the idea of backups, business continuity, and “bad guys” isn’t new. However, this week it was brought to a new and interesting head for one small business.
Rewind the clock two years and we were in the conversation with this business about where they host their “golden nuggets” of their business, what servers did what, where were the users, how did the backups fare, state of malware, web filtering protection, etc. You know, all the “normal” stuff any qualified IT provider would ask a prospective customer. “We’re fine” was the answer – they had an in-house IT guru watching all that stuff. However, they did make a (wise) decision to host their ERP solution with us.
Last week, our monitoring went suspiciously quiet, it looked like the company went on vacation, or they had fallen asleep at the keyboard. I reached out to the company, and was informed that they had been the victim of the latest ransomware attack, and all their documents were encrypted and unusable. Thankfully, since they were hosting their ERP system with us, that was safe from the attack. All their ERP data was secure but everything else they controlled was locked. Backups proved unreliable or inaccessible, so the ransom was paid. The company got lucky and the recovery key worked and they got their documents back. What they didn’t get back was Active Directory. Ouch! Nobody could login, even though their documents were back on a server, nobody could access them.
A week later, a new domain, and new profiles on everyone’s desktop, new shares, new permissions, and they were back up and running. After everything, the company is back to doing business, but it could have been a much worse situation. A critical note: the ERP system was never at risk and no ERP data was lost since that was safely stored elsewhere.
Moral of the story:
Test your backups. Not just documents, but the whole server. How long does it take to get it back? It should not be more than a few hours.
Just because you can restore files doesn’t mean you can go out, buy a new server and restore your existing workload onto a new server.
If you can’t live without it, and you don’t have the in-house expertise to manage it – outsource it! Let the pros handle the critical IT while you do what you do best: making essential product and making your business grow.
Whether you’re a user, a seasoned Consultant, or a new Consultant, you know that setting up ID codes in Epicor ERP is critical to the basic setup and configuration to all applications in the system. You may also know, that once an ID Code is created, it becomes a Primary Key field in the database, for mapping purposes. The code is also a way to filter and group large amounts of data, for reporting. The frustration comes when there is a transaction against this, and you find out very quickly that it cannot be changed.
This is the primary reason why setting up these codes should involve some thought and planning. In Epicor ERP, you are limited to eight characters.
Part Numbering Schemes
Consultants and clients alike, typically use one of the following types of ID Code schemes:
Non-intelligent – Also referred to as “non-significant.” The ID code is generic and does not provide any information about the group. Non-significant ID Codes are typically created in a series, (typically in numerical order), regardless of the group or reference. Using this ID Code system, a code could be assigned an ID Code – T100.
Intelligent – Also referred to as “significant.” The ID code contains descriptive and informative details that provide significant information about the group. With this type of scheme, an ID Code is generated for a Part Class, might be “RES” where “RES” stands for resistors.
Which scheme should you use?
In any manufacturing organization, establishing an ID Code should be an efficient and accurate process. Consider your current and future operations when selecting which type to use. Here are some pros and cons of each:
Advantages of Non-Intelligent ID Codes:
Using this type of scheme will save your organization time upfront. You can ramp new employees quickly, avoid relying too heavily on any one person and maintain the system without much overhead. Here’s how:
Time savings: It takes little to no time to pull a sequential ID Code for a group. Moreover, most of the setup is complete before cutover, and any additional setups are added on an as needed basis. Assigning an ID Code can happen fast. You do not have to put much thought into what the code should be as it is completely generic.
Little training needed: If the organization hires new employees, they will not need to learn how to define an ID Code and can focus their attention on other tasks. Assigning a new ID Code can happen with little training.
No single point of failure: To rely on a single person who knows and understands the coding schema, which was established in the past, means you sometimes must wait to assign a new ID Code. With non-significant ID Codes, you can easily have multiple people create them. NOTE: Since this is part of “Setup” in all application of Epicor ERP, Security group settings and rules should apply.
No “back-tracking” or having to redo setup and configuration: Since the ID Code is non-intelligent, and since you cannot change an ID Code once it has been established, you can always reuse the code for a different group by simply changing the description. This also avoids the dreaded “DO NOT USE” definition description when ID codes are created and cannot be deleted.
Simple maintenance: It is easy to maintain this type of scheme, as it’s essentially a sequential list. You will not have to decide where and how a new ID Code fits into the scheme.
Disadvantages of Non-Intelligent ID Codes
Using a non-significant ID Code scheme isn’t completely error-proof; mistakes can happen, especially if data entry is involved, and managing similar parts can be difficult. Here’s why:
Potential for errors: Because it doesn’t have meaning, a non-significant ID Code does not provide any cues to help a user evaluate a group. If a ID Code is manually created, even an experienced person may fail to spot a data entry error. ID Code E100 could inadvertently be entered as E001, with no frame of reference for a user to determine if the ID Code makes sense in the context of other data, the error will likely go unnoticed.
Difficulty managing ID Codes: Without common prefixes, this type of ID Code scheme may require more work to maintain. You’ll need to track additional metadata (descriptions) to define your codes and then use that information for grouping or searching (and for reporting) since the ID Codes do not provide identifying information.
An ERP system is like a person or a house: without integrity, you can’t put your trust in it.
One of the great things about Epicor ERP is its openness to customization. That feature can also be a source of trouble. It’s all in how you use the power.
Strictly speaking, you can’t directly modify Epicor’s software without a special Software Development Kit. Changing the base software opens the proverbial can of worms and has lots of ramifications we won’t discuss here, so what we’ll be talking about is the traditional “customization layer” the 99% uses.
Terms to Remember:
Business Object (BO). Data manipulation is governed by Business Objects. You hand the BO a dataset and let it figure out how to care for the data’s integrity, rather than writing directly to all the tables in the dataset.
There is a “Part” business object, for instance, that governs the Part table and its dependent tables. It won’t let you change the base unit of measure for a part if there is any activity like transactions, open orders, or open job materials for a particular part so you don’t, for example, make an material’s on-hand quantity of 10 Each suddenly 10 Gallons, or orphan transaction history by deleting the part.
Embedded Customization. Also known as a “screen customization” or just “customization” (client side) that sits on top of a form such as Part Maintenance. You can add a new field on the screen and attach it to a data source or use C# code to add and modify events happening inside the form to suit your business practices.
Personalization. Similar to the customization, the personalization is a user-made modification that sits on top of the form/screen customization (that sits on the base software). They’re mostly used to modify field placement, grid layout, etc. to let the user see and arrange things in a way useful to them.
BPM. Business Process Management Method and Data Directives (server side) modify data actions triggered by events on the form. They are typically accessed in record updates, new record creation, and so on. The Part BO has many methods like add, update, and delete, so you can say, “when this thing happens to the data also do this other thing,” or “when we create a new record add this thing to it.”
In generic terms, a typical Epicor ERP session works something like this:
An Epicor form loads with standard (out of the box) data views, operations, etc.
Epicor then looks for a screen customization and applies it on top of the standard form.
Epicor looks for a personalization for the current user to layer over the form and over the customization, if any.
The form displays and allows the user to do things.
BPM – Method and Data Directives (server side) hang around and wait for the appropriate signal to take action, say, when you click the save button.
This is what I’m calling the customization layer–the places Epicor gives us to add in/change functionality.
So, where’s the danger? Here’s an example.
When we store data changes through Epicor’s Business Objects, we trust the BO to keep us out of bad trouble. But the data is stored in a SQL Server database, and it’s possible to go outside of Epicor and write directly to that part table or delete records via SQL commands without checking any dependencies. It can be much faster, in the same way ignoring the speed limit in your car can get you home sooner. Maybe you won’t corrupt your data. Maybe you’ll make that turn on four wheels.
There are occasions and circumstances when it’s okay to skirt the rules.
Rarely, something gets stuck and the BO won’t let you correct it, so a SQL fix is in order. Since directly using SQL commands on your database can invalidate your Epicor service agreement, I’d recommend doing it with one of Epicor’s folks on the phone.
Some simple tables and some fields don’t have dependencies that the BO cares about. It’s possible to take a more direct approach within Epicor—when you know what those are.
This topic comes up periodically when we developers talk amongst ourselves. In our company, the standard is to operate from within the Business Object unless there’s a compelling reason for something different.
I just need to get this off my chest – so bear with me. 
I just need to get this off my chest – so bear with me. 
