I am always put back on my heels a bit when talking to a Prophet 21 user or system administrator when they describe a problem they are having, and when I suggest it could be solved easily with DynaChange business rules, the response is “We don’t have business rules”.
I have to constantly remind myself that DynaChange Business Rules are an add-on, and do not come standard with P21. Maybe they should be put into the baseline pricing for the system because when used properly, they are a massive benefit to your organization.
I am not sure why a company would elect not to buy the Business Rules add-on for Prophet 21. In the event you are studying the feasibility of buying it or even trying to make the case to management about why you should have it, hopefully, I can shed some light.
What are DynaChange Business Rules?
DynaChange Business Rules are a feature of P21 that allow you to inject your code into the P21 workflow. There are a few different ways that this can be done. Suffice it to say that you can trigger your custom rule code based on events such as field edits, window openings, saving a record, clicking a button, and other events. You typically cannot prevent what Prophet 21 is doing. However, it is possible to use the business rule to modify the result of P21 code execution. You can also change values in a field based on your custom business logic.
The basic premise of the DynaChange Business Rule is that you are going to extract some information or condition from the current state of P21. Then you will use that information to process your custom business logic. Finally, you then send a value back from the business rule to P21. That value can then be placed into a field on the screen. As an example, you could pull in the value of the address field, convert it to all uppercase letters in your business rule, and then send the all-caps version to P21 and put it back into the address field.
First and foremost, the majority of things you will likely do with a business rule are very simple and require minimal coding expertise. There are enough samples and examples available from Epicor. Using these, you should be able to get up and running in a short period with simple, basic rules that automate common tasks.
Examples for Rules
Here are some very basic examples of DynaChange business rules that typical power users could feasibly write on their own:
- Anytime I receive a PO, I want the “print labels” checkbox to be checked.
- Whenever we run a pick ticket scan, there are certain settings we want to use.
- The required date for an order should usually be set to 3 days in the future.
- When entering an order, round the quantity up to the nearest 10.
- When the “XYZ” popup comes up during Order Entry, always answer No.
All of the above are very easily managed with a business rule with less than 10 lines of code. Think of a business rule as getting custom functionality without altering the core of Prophet 21. For the most part, they are very survivable from version to version, and they are easy to turn on and off down to the role or user level.
As you move up the complexity ladder, business rules are only limited by a combination of imagination and coding ability. Many consultants can help you write the more complicated rules. As long as you have them properly spec’d out, the cost of developing a rule shouldn’t be outrageous. Most P21 consultants I have worked with are in the $100-150 per hour range. Some will work on a per-project fixed cost. The ultimate answer to how much it will cost is almost always “it depends,” which is fair. Even the most complex rules I have written haven’t taken more than 3 or 4 hours to put together. In every case, the business benefits have far outweighed the cost.
Summing it all up
Building DynaChange business rules for Prophet 21 is not as mystical as it may seem. Fortunately, once you have paid for the add-on, there are not any other mandatory start-up costs associated with it. The free version of Visual Studio is more than sufficient to do your coding work and create the required files. Your rules are going to be developed in either Visual Basic .NET or C#.NET, whichever you prefer.
Even if you do not have the comfort level to develop rules in-house, it is still worth having if you can get hooked up with a developer/consultant that can help you get the code written. Business rules are a key component of increasing labor productivity through automation. They are also great for implementing input validation to prevent errors and save rework. Anything you can automate in a rule is something you do not have to train people to do later.
Bottom line, if you are not using DynaChange Business Rules, chances are you probably should be. The ROI on a business rule is typically pretty high. Additionally, the payback time is usually pretty short. There is probably someone in your organization with a little coding experience…find that person and put them to work making your business run smoother!
AP
