An ERP system is like a person or a house: without integrity, you can’t put your trust in it.
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.
Integrity is worth the extra effort.
