Skip to Content

User Specific Version of a decision table in BRFplus

Aug 14, 2017 at 01:31 PM


avatar image

Hello Experts

I have a rather advanced question. I am testing the use of BRFplus in ERP pricing to handle taxes. I am using the pricing date as part of a decision table key to add validity capabilities.

But I was wondering to replace via another logic, if BRF+ allows.

I saw it is possible to add versioning, but it seems I have no control over the versioning , it generates a new version every time I change the content of the table and activate.

I do NOT want this way...

Instead I would like to know if it is possible to explicitly generate versions of a decision table, defining the time stamp manually. In this case I wouldn't need to add the price date as a table key, the price date would decide which version of the table would be sought.


I create the contents of a DT called DT1 and define this table as being the version 1, valid from 15/07/2017. And let's say it has the following entry

Key1 | Key2 | Key3 | Tax rate = 5%

Then let's say there is a legal change, so that tax rates change from 01/10/2017.

I would change the rates of DT1 and generate a second version of it, valid from 01/10/2017. So the same entry above for this version would be

Key1 | Key2 | Key3 | Tax rate = 8%

So if I price a certain order on 1/9/2017 for example, it will find the tax rate of 5%. If I create an order dated of 2/10, it would bring 8% as result.

But still I would have 1 decision table, with several versions, 1 for each tax rate change

Thanks in advance for any light


10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Mike Pokraka Aug 14, 2017 at 08:17 PM

I can see your reasoning, but IMHO it's a bad idea.

You're trying to substitute time-dependency with versioning. Very different concepts for very different purposes.

It's probably possible to overwrite the version timestamp using exits or enhancements, but then you'd also have to do some fiddling at the other end to make your call execute a specific version. So you'd end up with a 'two wrongs make a right' scenario that could be hell to understand and troubleshoot.

And not to forget the idea that you may need to maintain a different version than the 'now', so you will need custom maintenance facilities.

And what if you need versioning on your time-dependent data? Not as silly as it sounds, if a customer tries to sue, you might need to track whether someone changed the rate as it was valid on the 12. Aug. There are several real-world scenarios where this kind of two-dimensional time data is relevant.

Most importantly, the versioning is also an audit trail. If there are any BRF+ rules where this is important, having modifications in the versioning system is not a good thing from a legal/audit perspective. This idea also loops back to my last point about versioning your time-dependent data.

So, while it was certainly an idea worth discussing, I wouldn't go near it. If you want to do something fancy, maybe something along the lines of copying the expression for each new validity period and having a "Validity" decision table point to the expression valid on a given date.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Copy the table for each new change (in this case I am talking about government taxes, which do not change that frequently) is out of question. This would be confusing to maintain.

Besides BRF+ has problems to sort the table with validities ;-\

And also the usage of exits is not being considered. The only thing I would accept is my idea of maintaining user-created versions.


I was just giving an example of a lateral approach to the problem, there are other ways. I still find a hack to convert versioning into time-dependency more confusing, for reasons I explained at length.

BRF+ doesn't have any problems sorting, it's a sequence of conditions not a data table. Consider date as your criteria and July is an exception to 2017. You could represent your condition column as:

1. < 01.01.2017

2. between 01.07.2017 and 31.07.2017

3. >= 01.01.2017

Sorting is irrelevant, sequence is everything.