Skip to Content
Author's profile photo Former Member

Data-driven rules

Vijay asked me a follow-up question about my recent Business rules on a full stomach. He had asked about the challenge possed by the fact that rules act on master data  and master data sits in ERP. I had said that the data should stay in the ERP system and the rules should just act on it but he had another question:

Let me request you to expand on point 2 above, lets say we have a rule that affects customers and products. If customer = C1 and product = P1, discount = 10%. If customer = C2 and product = P2, discount = 20%. And so on.

Here, C1,C2 ..and P1 P2 etc sit on ERP. Rule sits outside ERP. When you have several customers and products, you cannot write if..then..else for each of them. Rather, we would look up in a table. Where does the table sit? If table sits outside ERP, then there should be a mechanism to make sure that keys of this table have valid cutomers and products that exist in ERP. That is what I refered to as keeping them in sync. There is no update of data with the rules – just that the data that rule references, should be updated and kept in sync with ERP. This is not easy as volume increases.

This is an interesting area. First things first – if these are really the only discount rules you have and you are sure you will never have any kind of discount that is not determined purely by the product and the customer then you should probably just use a look up table. In reality, however, most companies can make no such guarantee and have discount rules that they would like to vary. They might, for instance, want to have a discount for a particular product for a particular customer but only if the total order exceeded a certain amount. Or they might have discounts that are linked to performance criteria in specific contracts and so on. This drives you to rules.

When you are building rules in a decision table inside SAP you can constrain the values being selected in the various condition. Clearly in this case you could and should constrain the rule editing environment to ensure that customers, products and other elements being used in the rules do in fact exist. As you built the discount rules in a decision table or other editor you would be restricted to valid customers, valid products and this would ensure that your rules would work. What most rules enviroments do, and I believe this is also what SAP does, is allow you to query tables to get the list of valid items.

What most companies do in these circumstances is use both rules and a table. The discounts themselves might be stored in a table and a rules approach is used to see which discounts should be applied to the particular customer. If we decide, for instance, that we want to have a set of discounts for each product from which each customer/order selects then we might store product id, discount id and discount amount in a table. This guarantees we don’t offer a discount that makes a product unprofitable, for instance. The rules then use information about customers and orders to determine which discounts to apply and then look up the discount % in the table (obviously there are lots of ways to do this but let’s stay with this example). This allows rules to be specified that use more information and use it in combination to calculate the discount. These rules are not in the database, they are in the rules system, but they use the database to manage some of the information they need.

Regardless of how much of the rules complexity you store in the database and how much you store in the rules environment, the applications that need to know the discount MUST stop looking it up in the database and instead must call a Decision Service, a discount engine in this case, to get the discount. This decouples the calling application or component from the implementation of the discount, allowing you more agility and flexibility in changing how you do discounts.

Hope that helped.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Thanks for taking time to explain, James.
      That did help.