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.
Currently, sales order entry staff do just what their title implies: they enter orders. Sure, an order might be generated from a quote, but someone must enter that first. Data entry, day after day. What if your customer could send you a purchase order and it just magically appears in Epicor?
It’s not quite magic, but pretty close. Here’s the basic operation of Epicor ERP’s Automated Sales Order Entry:
Your customer sends an email with a PO attachment to a designated email address.
Intelligent Data Collector (IDC) identifies the attachment and pulls it into DocStar.
DocStar creates a “pre-order” and automatically filters it to a workflow.
A user steps in at this point and checks for exceptions. If there are exceptions, they are corrected by the user.
The pre-order passes validations.
An order is born, demand is created, et cetera.
Oh, I see you’re starting to get the implications, so I’ll give you a moment. Okay, moment’s over.
How handy is that? Imagine how much more of your sales order processing staff’s time can be spent on value-added processes, versus mindless data entry, and how errors can be reduced through automation.
It’s not a panacea. It won’t handle parts-on-the-fly or configured parts. It will bring in sales kits, but there’s no way to edit the kit within DocStar. Still, exciting news.
Epicor has made a commitment to provide us with tools to rationalize our work processes and give us the information we need to make intelligent decisions, and we know more is coming.
In the beginning there was Epicor Vista. Then Vantage brought a new user interface. Epicor ERP incorporated a version into the name, E9, along with major changes to underlying structure on a Progress database. With E10.0.xxx, the structure was streamlined with a switch to Microsoft SQL Server, bringing huge increases in performance and a new (modern) menu, as well.
With the first major upgrade to E10, E10.1.xxx, incremental features were added, increasing ERP’s functionality. It was faster, more polished, did more. But from a user standpoint, most basic operations worked pretty well like they did in previous generations. Order entry was order entry, was order entry.
A couple of years ago we heard rumors: get ready for some new stuff.
DocStar-enabled application allows automated entry from a scanned image or email attachment of your customer’s purchase order.
Connected Factory
REST-enabled communication lets EPICOR get information directly from shop floor machines and other devices via the IoT (Internet of Things).
Lite MES
Kinetic-enabled user interface allows MES (Manufacturing Execution System) operation via touch-screen devices such as smart phones or tablets.
Scheduling Boards
Kinetic-enabled versions of Job Scheduling Board, Resource Scheduling Board, and Resource Scheduling Board make it easier to drag/drop and drill down, dynamically change timelines, and schedule jobs in “what if” mode.
Time and Expense Mobile App
Provide the capabilities to access and maintain time and expenses via smart phones and tables, including a “read-only” offline mode.
Project WBS Phases Revenue Recognition
Allows revenue recognition of WBS phases independently of the entire project.
OData 4.x and REST v2
Tools allowing communication among many sources, including Excel spreadsheets and the Internet of Things.
All right, there’s a ton of information here, but difficult to fit into a single blog post.
An ERP system is like a person or a house: without integrity, you can’t put your trust in it. 
