One part of my job here at SAP is to “promote” BRFplus and DSM in projects within SAP Services (Consulting). To be very clear – this does not mean to simply sell it but more or less to show the capabilities in prototypes, demos, proof-of-concepts and so on.
Another part of my job is working on / with an engineered service package officially called “Custom Code Migration Service for SAP Business Suite on HANA“. There we take care of your custom code when it comes to a migration to Suite on HANA (there are a lot of guides, tools etc. available. As I want to focus on another topic, this should be enough).
With these two different aspects of technology topics, I see BRFplus definitely as a topic in this area of custom code management. With BRFplus, you can model business (decision) logic without creating custom code in massive ways. Just let me give you some examples from different projects (anynomized, of course) to show how BRFplus can replace custom code, increase flexibility (closer to business users, easier to change) and reduce costs (e.g. in case of upgrade, migration to HANA, etc., this is no longer custom code!).
Example 1 – Goodwill (Warranty)
This project was part of a Warranty based project. The question was how to handle customers asking for goodwill for the goods they bought. Let’s assume, we are in the automotive industry and sell special cars. By law, you might be obliged to deliver warranty regarding your special car for 24 months (2 years).
But for every repair that comes after these 24 months, it is up to your company if you want to allow goodwill for our customer.
Depending on different parameters (how old is the car? what about the mileage? who is the customer? what is the damage reported?…), you should decide how much of the costs (labour, material, other) you want to cover as goodwill.
In this scenario, all of our rules were modeled within BRFplus and the custom code part was simply the integration call. This integration looks a little bit like calling a function module. By that, we were able to avoid custom code in the system and the rules could be modeled closer to the business unit, e.g. with a decision table as shown in the following picture.
In this decision table, there are only as example 3 condition columns in this screenshot, but by this it is still easy-to-understand. You can read the first row like this:
If the car was sold in Sales Region (VKORG) 1000, is 24 – 26 months old and has a mileage of 200.000 to 250.000 km, we will pay 80% of the material, labour (time) and all other costs.
In reality, there were more than 50 parameters that influenced the decision. This would have been a lot of IF/ELSE or CASE-Statements in ABAP, a lot of (Z-) customizing tables etc., but everything could be modeled in BRFplus.
Example 2 – Tax Code Determination (Purchasing)
The idea is that for each item in a purchase order, you have to determine the correct Tax Code as shown in the image. Typically, you have a some logic on your own within a function module, class/method behind the standard BADI to determine the correct behaviour of the Tax Code.
Instead of using the BADI offered here (ME_PROCESS_PO_CUST with Method PROCESS_ITEM) to put our logic in there, we simply added a call of a BRFplus function in there (<30 lines of code). All of the business logic is encapsulated in the BRFplus function and if the logic to determine the tax code changes, you simply change the BRFplus logic.
The logic within BRFplus could look like the following screenshot, where you see the real modelling workbench of BRFplus.
Here, we say that if the Plant is ‘0020’, the Tax Code should be N0 and so on. There are a lot of expressions that you can use in rules but most commonly are from my point of view decision tables and formulas as these two expression types offer almost everything you need to model business logic – and it is easy-to-understand compared to ABAP. So as last aspect, let’s have a look at a decision table to show how this might reduce your IF-ELSE / CASE-Statements massively.
In this Decision Table, we see that based on the Material Category the Tax Code is determined. Compared to a CASE-Statement, you have some advantages here: You can have several condition columns (not only the category but maybe in parallel the country, purchasing organisation (EKORG), …) and within each condition row, you can choose several values (with including or excluding conditions like: Category 01 – 10 but not 08.).
So you might see that at least I am pretty much excited about the capabilities of BRFplus / DSM.
With BRFplus you can model your logic inside a tool instead of doing it all by (custom) coding and customizing tables. Generally, you only need a few lines of code for the integration – but this interface is usually very stable. By that you reduce your amount of custom code, because you do not need FORM-routines, Function Modules, classes / methods etc. All of your logic is put into BRFplus. At the end, BRFplus is generating at runtime ABAP code, but this is not “custom code” when it comes to maintenance etc.
I really feel that if you take care of custom code management and you identify spots where you need your tailored process in the SAP system, BRFplus can be a valid alternative instead of coding.
In addition to that, the modelling tools offer the possibility to let the business experts do the modelling work in BRFplus instead of specification documents.
So how can you benefit from BRFplus? I would say: directly by simply starting the transaction “BRFplus” on your system. It is included in your NetWeaver-ABAP system. Try some small prototypes, read the official SAP press book, get involved in the BRFplus Community here in SCN, book a course…
As soon as you dive deeper into this topic, I would strongly recommend to check out DSM as Add-On. Why? Just check this post by Carsten Ziegler.