One of the problems with automatic calculations of taxes, fees and charges for business permits (or any permits for that matter) is that the calculations are too varied and too unstructured that it doesn’t follow certain patterns. Programming it using traditional means would always fall short. Even if you get all the scenarios for all LGUs ( which is impossible by the way), there is still the possibility that new rules may crop up in the future that you have not anticipated. Our old program could pretty much handle some scenarios that were present in the cities that we have implemented. However for new rules that do not follow normal calculation patterns, we have to recode it. I wanted to come up with a better solution. My goals for this new design should be:

1. It should be easy to understand for the normal business user. It must be expressed in such a way that it “speaks” the language of the business person and not something only an IT personnel could understand.

2. It should be easy to maintain. Sometimes some rules are somewhat similar in calculations but slightly differs in some areas. The tendency is to repeat the same rule over and over even if the difference is small. If there are new lines of business added, we shouldn’t change the rule settings anymore.

3. It should be dynamic and flexible. It should be able to calculate or formulate new rules in the future without programmer intervention.

4. For all taxes, fees and charges the system should compute everything and should be fully automated. There should not be a case where an assessor needs to further select taxes that are not applicable.

After some research, I stumbled upon the use of rule engines. It looked like something I could use. Although we experimented with dynamic scripting before, like our solution for Kwarta Padala, a rule engine is quite different. Dynamic scripting still follows a predictable programming pattern only that it is compiled on the fly and great for expressing formulas, while a rule engine is great for unstructured or unpredictable patterns. How does it work? We define the rules first and register it in a rule engine. A Rule is composed of a constraint and consequence. We define the conditions in the constraint part and these indicate when a rule should execute. The action that will be triggered is indiciated in the consequence part. Defining rules is done only once or when a rule changes. To execute, we need to introduce or assert facts into it. Facts are pieces of information that will be evaluated by the rule engine. For example, it may be the type of business, location of the business, gross sales amount, etc. The result may be what tax, fee or charge is applicable and how much. Rule engines aids in decision-making and is patterned on how we humans think.

I will be talking more about the usage of rule engines in ETRACS in my next post.

Leave a Reply

You must be logged in to post a comment.