1

How to Automate Rate Updates in a Decision Table in DSM Applies to: SAP Decision Service Management 1.0 (or BRFPlus on SAP NetWeaver 7.02 or above)

Summary

When using business rules to provide more flexible, adaptable, and provable replacements for traditional Z

tables, Decision Tables provide an easy way to hold periodic rates that change over time. Typically these

rates are updated annually, e.g. indexed by an inflation factor. The DSM / BRFPlus API provide a

convenient way to update rates automatically, avoiding data entry errors and minimizing work for rule

owners. We demonstrate how to update a Decision Table holding such rates using the DSM / BRFPlus API.

Author: Jocelyn Dart Company: SAP Australia Created on: 25 June 2015

Author Bio

Jocelyn Dart is a Platinum Consultant has worked for SAP Australia for over 20 years and

worked with over 70 organizations in both the Public and Private Sectors. For the last 3 years

she been helping customers implement business rules, and has presented at conferences and

run workshops on SAP Decision Service Management and BRFPlus.

*** Special thanks is given to Christian Lechner for his gracious assistance in developing the ABAP

coding in this example.

2

Table of Contents

Pre-Requisites .................................................................................................................................................... 3

Automate Rate Updates of a Decision Table ..................................................................................................... 3

Preparation ...................................................................................................................................................... 4 Create the Decision Table Tradesperson’s Tools Allowance ....................................................................................... 4

Optionally: Use the Decision Table as part of a Rules Function .................................................................................. 5

Gather Technical IDs ................................................................................................................................................... 5

Authorize the Executing User of the Batch Program .................................................................................................... 6

Create a Program to execute the DSM API .................................................................................................... 6 Set up the Batch Program variables including the Inflation Factor as a Parameter ..................................................... 6

Access the Decision Table Expression ........................................................................................................................ 8

Get the Properties of the Decision Table ..................................................................................................................... 8

Find the existing row that holds the rate to be inflated ................................................................................................. 8

Read the existing Legislation Period and Rate ............................................................................................................ 9

Calculate the new Legislation Period and Rate .......................................................................................................... 10

Build the new row ....................................................................................................................................................... 10

Lock the Decision Table ............................................................................................................................................. 11

Insert the row in the Decision Table ........................................................................................................................... 11

Activate, Save and Unlock the Decision Table ........................................................................................................... 11

Trigger Deployment of the Decision Table to the Managed System .......................................................................... 12

Testing the Program ......................................................................................................................................... 15

Taking the technique further ............................................................................................................................. 15

Related Content ................................................................................................................................................ 16

Copyright ........................................................................................................................................................... 17

3

Pre-Requisites SAP Decision Service Management 1.0, or BRFPlus on SAP NetWeaver 7.02 or above

o Note: This example was originally worked on a SAP Decision Service Management 1.0 SP01 (SAP NetWeaver 7.40 SP04) system. However the same principles can be used on earlier BRFPlus releases, although some code adjustments may possibly be needed on earlier releases.

Some ABAP development skills

A Rules Application created in the Business Rules (BRFPlus) workbench of SAP Decision Service Management containing:

o A Decision Table with 2 columns:

Condition column holding the Calculation Date (e.g. applicable date of legislation date) to which the rate applies

Action column holding the rate value, e.g. an Amount

For simplicity, the general approach is shown using a simple decision table of 2 columns – date and amount that are to be updated by an annual inflation factor. However it is easy to extend the technique to cover decision tables with additional columns containing other expressions and rule references, but this will not be shown in this document.

Note In the example, for simplicity the inflation factor will be passed as a parameter, and a simple -

multiplication of rate x inflation factor will be used to inflate the rate.

However it is easy (and often preferable) to extend the example to read the inflation factor from a

second decision table, and event to call an additional rule to apply the inflation factor to the rate (e.g.

where explicit rounding rules need to be applied).

Automate Rate Updates of a Decision Table A common practice in many countries is to index rates and other allowances annually to an inflation factor.

If your business rules require you to apply the rate, e.g. to calculate the expected tax you will pay, it’s useful to hold these in decision tables as part of your business rules.

While it’s possible to include an expression in a decision table column to calculate rate x inflation factor dynamically, it’s convenient to apply such inflation factors once and annually via a batch program, for the following reasons:

The decision tables holds the effective dates and rate amounts in their natural and most visible formats, and can be easily reviewed by rule owners and other stakeholders

Changes to the decision table are applied once, annually, rather than each time the table is evaluated, which is better for overall system performance

Changes can be applied automatically, which minimizes the risk of incorrect calculations

The batch update can be scheduled once the annual inflation factor is announced, as inflation factors are often provided by external government agencies

In a DSM system, any related rule functions that use the Decision Table as an expression can also be automatically deployed to the local system(s) as part of the automated batch program.

An example of such a rate is Canada’s Tradeperson’s Tools Allowance:

http://www.cra-arc.gc.ca/nwsrm/fctshts/2014/m11/fs141125-eng.html

4

We will use this rate to demonstrate how to automate updates of a decision table in DSM and BRFPlus.

The only significant difference between DSM and BRFPlus in this example, is:

In DSM we have a final step to deploy the decision table from the central Decision Service Management system where the rules are maintained, to one or more local systems(s) where the rules are executed

Whereas in BRFPlus the changes are applied to the local system immediately, but deployment to any other system must wait until the next IT transport cycle.

The central to local deployment is at the heart of good rules governance in DSM, and permits rules to be deployed rapidly in business timeframes rather than constrained IT timeframes, and deployed wherever the rule is used across the system landscape.

We provide a little background on the Tradesperson’s Tools Allowance to set the scene:

The following chart compares the indexed amounts for the 2015 and 2014 tax years. It reflects an indexation increase of 1.7% for 2015.

2015 2014

Tradesperson’s tools deduction:

Threshold amount relating to cost of eligible tools

1,146 Canadian Dollars, i.e. 1,127 * 1.017

1,127 Canadian Dollars

Canada uses two different tax years for individuals and business, one is a simple calendar year, the other runs from 1

st April to 30

th March of the following year. For the purposes of this example, as many countries

have non-calendar fiscal years, we will use the business tax year.

The steps included in this document show how to create a ABAP program that updates a Decision Table using the DSM / BRFPlus API. The following assumptions are made in the interests of simplicity:

The Decision Table that holds the rate already exists in DSM

The inflation rate will be provided as a parameter to the program

The rate can be inflated by simple multiplication, i.e. new rate = current rate x inflation factor

Rates are updated annually, i.e. new calculation date range = current date range + 1 year

Note The overarching decision service (i.e. BRFPlus function) which uses the Decision Table is not shown and is not

relevant to this technique.

Preparation

Create the Decision Table Tradesperson’s Tools Allowance

Target Decision Table for the updates is Tradesperson’s Tools Allowance

The table has a single condition column Legislation Period of type Timepoint (Date)

The table has a single result column Allowance Amount of type Amount (including Currency)

Create at least one row in the table with the existing allowance amount.

This is the rate that will be inflated by the program.

For our demonstration we’ve entered several of the previous year’s rates to give a better idea of what the content of such a table might look like over time.

5

Figure 1 – Tradeperson’s Tools Allowance decision table with prior year’s value BEFORE update program is run

Optionally: Use the Decision Table as part of a Rules Function

We’ve include a couple of example rule functions that use the decision table so that we can show how handle the deployment. The function context, rulesets and rules themselves are not relevant to this demonstration so we won’t show those.

You don’t need to create these to execute the demo.

Figure 2 - Rules Application hierarchy showing Functions and Rulesets that use the Decision Table

Gather Technical IDs

In preparation for automating decision table updates, gather the technical IDs (i.e. the Globally Unique ID also known as the GUID) from the General section of:

1. The Decision Table

o In the example: Tradesperson’s Tool Allowances

6

Authorize the Executing User of the Batch Program

Ensure the batch user id that will be used at runtime to execute the rate update program has sufficient

authorization (authorization object FDT_OBJECT) to read and update the decision table.

For example, if the rate updates are to be executed via a batch job or web service, a technical user may be

used to execute the rate updates, and that technical user must have sufficient authorization to the rule

objects.

Create a Program to execute the DSM API

To run this example, you’ll need to create an executable program in transaction SE38 on the SAP

NetWeaver (ABAP) platform where you access the DSM or BRFPlus Workbench.

Set up the Batch Program variables including the Inflation Factor as a Parameter

In the example we give the program a parameter P_FACTOR to hold the inflation factor to be applied.

We’ve included all the types, data variables and field-symbols needed.

Note One of the reasons we need field-symbols is that DSM / BRFPlus use a lot of generic and dynamic

referencing so that rule expressions such as Decision Tables can manage whatever data format or

expression reference you require.

If your ABAP is a little rusty hang in there… and maybe buddy up with someone with more recent

knowledge. Or post your questions in the ABAP forum on the SAP Community Network.

*&---------------------------------------------------------------------*

*& Report Z_DSM_BATCH_RULE_UPDATE

*&

*&---------------------------------------------------------------------*

*& Sample report to index allowances by inflation

*& ZDT_TOOLS_ALLOWANCE

*&---------------------------------------------------------------------*

REPORT z_dsm_batch_rule_update.

PARAMETERS:

* This is the incoming inflation factor

p_factor TYPE if_fdt_types=>element_number DEFAULT '1.7',

p_dest TYPE rfcdest DEFAULT 'AE1CLNT800'.

TYPES:

* We'll use this when we build the new row

ts_row_data TYPE SORTED TABLE OF if_fdt_decision_table=>s_row_data WITH UNIQUE KEY row_

no.

DATA:

* Ok well you need your decision table ID

* (You could also look it up by name...but that's for a different blog)

lv_dectable_id TYPE if_fdt_types=>id VALUE '005056AC35D91EE5858388127E81BDE7',

* Somehow sometime... you always want a timestamp

lv_timestamp TYPE if_fdt_types=>timestamp,

* lo_decisiontable holds our decision table instance

lo_decisiontable TYPE REF TO if_fdt_decision_table,

* lo_admin_data is used to get the name and text of rule objects

lo_admin_data TYPE REF TO if_fdt_admin_data,

7

lv_name TYPE if_fdt_types=>name,

lv_text TYPE if_fdt_types=>text,

* lt_columns will hold the column properties of our decision table

lt_columns TYPE if_fdt_decision_table=>ts_column,

* We'll want to know which column is which

lv_result_colno TYPE i,

lv_date_colno TYPE i,

* lt_rowdata will hold the existing row(s) of our decision table

lt_rowdata TYPE if_fdt_decision_table=>ts_row_data,

* And we'll need a generic reference lr_cell_value

* to extract the details of each cell

lr_cell_value TYPE REF TO data,

* lr_cell_range will hold the generic reference to the existing date range

lr_cell_range TYPE REF TO data,

* We'll dereference the range to lt_range so we can read the range table

lt_range TYPE if_fdt_decision_table=>ts_range,

* We'll ls_range need to get the row of the range table

* that holds the low value and high value dates

ls_range TYPE if_fdt_decision_table=>s_range,

* Ok so this gets easier...

* We'll need to get the old start date (low value date)

* and old end date (high value date)

* So we can calculate the new start date and new end date

* These need to be in BRFPlus Timepoint format

ls_old_start_date TYPE if_fdt_types=>element_timepoint,

ls_new_start_date TYPE if_fdt_types=>element_timepoint,

ls_old_end_date TYPE if_fdt_types=>element_timepoint,

ls_new_end_date TYPE if_fdt_types=>element_timepoint,

* We do the same for the rate itself

* That is we get the old rate to calculate the new rate

* These need to be in BRFPlus Amount format

ls_old_rate TYPE if_fdt_types=>element_amount,

ls_new_rate TYPE if_fdt_types=>element_amount,

* lt_usage will hold the list of rule objects that use our decision table

lt_usage TYPE if_fdt_types=>ts_usage,

lt_usage2 TYPE if_fdt_types=>ts_usage,

* We'll use a ruleset to find a function to deploy

lo_ruleset TYPE REF TO if_fdt_ruleset,

lv_function_id TYPE if_fdt_types=>id,

* lt_deploy_funcs will hold the list of functions that use our decision table

lt_deploy_funcs TYPE if_fdt_types=>t_object_id,

lt_rfcdest TYPE swftdest,

lt_comments TYPE fdt_service_docus,

lt_message TYPE if_fdt_types=>t_message.

FIELD-SYMBOLS:

* And of course we need a few field-symbols to help with

* the dereferencing of generic data

<fs_row_data> TYPE if_fdt_decision_table=>s_row_data,

<fs_cell_data> TYPE if_fdt_decision_table=>s_cell_data,

<fs_cell_value> TYPE any,

<fs_usage> TYPE if_fdt_types=>s_usage,

<fs_message> TYPE if_fdt_types=>s_message.

* We always end up wanting a timestamp for something...

GET TIME STAMP FIELD lv_timestamp.

8

Access the Decision Table Expression

The program must first access the DSM / BRFPlus API using the factory class provided for this purpose.

* Get the Business Rules factory instance ...the beginning of all business rules API

DATA(lo_factory) = cl_fdt_factory=>if_fdt_factory~get_instance( ).

Then the decision table expression itself can be retrieved.

* Get the decision table as an expression instance

lo_decisiontable =

CAST #( lo_factory->get_expression(

iv_id = lv_dectable_id

iv_expression_type_id = if_fdt_constants=>gc_exty_decision_table ) ).

It can be useful to grab the name and text description of the table so your batch program can provide a running log of what’s happening as it executes.

lo_admin_data ?= lo_decisiontable.

lv_name = lo_admin_data->get_name( iv_timestamp = lv_timestamp ).

lo_admin_data->get_texts(

EXPORTING iv_timestamp = lv_timestamp

IMPORTING ev_text = lv_text ).

WRITE: / |Automated Rate Update of Decision Table: | && lv_name.

WRITE: / |Known as: | && lv_text.

Get the Properties of the Decision Table

We need the properties of the columns so we can work can which column is which when we are doing the

updates.

* Get the column details - so we can check which column we are changing

lo_decisiontable->get_columns(

IMPORTING

ets_column = lt_columns ).

Find the existing row that holds the rate to be inflated

Now this is easier than you might think.

It’s good practice with Decision Tables to put the most likely to be used row at the top of the table.

This is because when decision tables are evaluated within rules expressions they are always evaluated

sequentially starting at the first row.

So it makes sense that you would want to put the most recent rate at the very top of the table.

In other words, the rate you want to inflate is in the 1st row of the table.

* In other words, your most recent rate is in Row Number 1

lo_decisiontable->get_rows(

EXPORTING

iv_from_row_no = 1

iv_to_row_no = 1

IMPORTING

ets_row_data = lt_rowdata ).

9

Read the existing Legislation Period and Rate

Retrieving the details of the existing row is actually one of the hardest pieces to work out unless you are very

comfortable with using generic references. This is where you might need to update your ABAP knowledge if

you haven’t been keeping current over the last few years.

LOOP AT lt_rowdata ASSIGNING <fs_row_data>.

* So now we need to evaluate each cell in the row

LOOP AT <fs_row_data>-ts_cell_data ASSIGNING <fs_cell_data>.

IF lt_columns[ col_no = <fs_cell_data>-col_no ]-is_result = abap_true.

lv_result_colno = <fs_cell_data>-col_no.

* We know the Result column holds the Rate (in amount and currency format)

lr_cell_value = REF #( <fs_cell_data>-r_value ).

ASSIGN lr_cell_value->* TO <fs_cell_value>.

ls_old_rate = CAST if_fdt_types=>element_amount( <fs_cell_value> )->*.

ELSE.

* And the Condition column should be holding the date range (but let'a check)

CHECK <fs_cell_data>-ts_range IS NOT INITIAL.

lv_date_colno = <fs_cell_data>-col_no.

* So now we need to get the details of the date range

lr_cell_range = REF #( <fs_cell_data>-ts_range ).

lt_range = CAST if_fdt_decision_table=>ts_range( lr_cell_range )->*.

ls_range = lt_range[ 1 ].

* Get the Low Value date of the date range

lr_cell_value = REF #( ls_range-r_low_value ).

ASSIGN lr_cell_value->* TO <fs_cell_value>.

ls_old_start_date = CAST if_fdt_types=>element_timepoint( <fs_cell_value> )->*.

* Clear up data

CLEAR lr_cell_value.

UNASSIGN <fs_cell_value>.

* Get the High Value date of the date range

lr_cell_value = REF #( ls_range-r_high_value ).

ASSIGN lr_cell_value->* TO <fs_cell_value>.

ls_old_end_date = CAST if_fdt_types=>element_timepoint( <fs_cell_value> )->*.

ENDIF.

* Clear up field symbols - just a good habit to get into!

UNASSIGN <fs_cell_value>.

ENDLOOP.

ENDLOOP.

10

Calculate the new Legislation Period and Rate

For simplicity, we have done this directly in the program in a very simple way.

Note One of the reasons we need field-symbols is that DSM / BRFPlus use a lot of generic and dynamic

referencing so that rule expressions such as Decision Tables can manage whatever data format or

expression reference you require.

If your ABAP is a little rusty hang in there… and maybe buddy up with someone with more recent

knowledge. Or post your questions in the ABAP forum on the SAP Community Network.

* Basic data preparation for condition column - Legislation Period * Add a year to the date period

* Ok this is really rough... better to replace this with a real date calculation

* using a BRFPlus rule

ls_new_start_date-date = ls_old_start_date-date.

ls_new_start_date-date+0(4) = ls_old_start_date-date+0(4) + 1.

ls_new_end_date-date = ls_old_end_date-date.

ls_new_end_date-date+0(4) = ls_old_end_date-date+0(4) + 1.

* Inflate the row by the specified inflation rate

ls_new_rate-currency = ls_old_rate-currency.

ls_new_rate-number = round(

val = ( ls_old_rate-number * ( 1 + p_factor / 100 ) )

dec = 2

mode = cl_abap_math=>round_half_up ).

Build the new row

Each cell of the new row needs to be filled with the correct values and using the correct format.

The condition column is filled with the legislation period range to which rate the applies.

The result column is filled with the rate amount and currency.

* Ok now we have everything we need to build the new row

DATA(lt_new_row) =

VALUE ts_row_data(

( row_no = 1

ts_cell_data = VALUE #(

"Condition column - Legislation Period

( col_no = lv_date_colno

ts_range = VALUE #(

( sign = 'I'

option = 'BT'

r_low_value = REF #( ls_new_start_date )

r_high_value = REF #( ls_new_end_date ) ) ) )

" Result column - Rate Amount & Currency

( col_no = lv_result_colno

r_value = REF #( ls_new_rate ) ) ) ) ).

11

Lock the Decision Table

The hard part is over. All we need to do now is apply the updates.

As we are going to edit the decision table, we first need to make sure we lock the decision table to prevent anyone else from trying to change it at the same time.

* Lock the table - we do this as late as possible

* so we aren't blocking others unnecessarily

lo_decisiontable->if_fdt_transaction~enqueue( ).

Insert the row in the Decision Table

As we mentioned earlier, the most recent rate should always be at the top of the table. So we just need to insert it as a new row 1. The existing row will automatically become row 2, and any other rows will be pushed down without any additional coding needed in our batch program.

* Put the new row in the table as the 1st row

* as this is now the newest latest and greatest rate

lo_decisiontable->insert_rows(

EXPORTING

iv_row_no = 1

its_row_data = lt_new_row ).

Activate, Save and Unlock the Decision Table

Activating and saving the decision table applies the updates.

Unlocking the decision table allows others to access it again.

* Activate the Decision Table

lo_decisiontable->if_fdt_transaction~activate( ).

* Save the Decision Table – if everything was ok

lo_decisiontable->if_fdt_transaction~save( ).

* Finally unlock the Decision Table

lo_decisiontable->if_fdt_transaction~dequeue( ).

At this stage the decision table has been updated in the Business Rules Workbench.

Notice that a new 1st row has been added and the existing rows have all been pushed down.

12

Figure 3 - Updated Decision Table with new row 1 holding the next legislation period and inflated rate

Note If you are only using BRFPlus, and don’t yet have DSM, then this is the end of the program. To deploy

your changes to other systems, you’ll need to set up a transport change request as usual.

Trigger Deployment of the Decision Table to the Managed System

While the decision table is now activated, in a DSM landscape, it won’t be available by calling applications until it is deployed to the local system in which the calling application is executed.

We need to find affected functions, and redeploy them to their appropriate local system(s).

We’ve kept it simple here and passed in the RFC Destination of the desired local system as a parameter.

First we need to work out which rule functions need to be redeployed. This involves reading up the where-used list hierarchy until we reach a ruleset; then we find the function associated with the ruleset.

Once we find the function we get ready to deploy it. It’s a good idea to fill in the deployment comments explaining what caused the deployment.

* Find any functions in which the decision table is used

WHILE lt_usage IS NOT INITIAL.

UNASSIGN <fs_usage>.

ASSIGN lt_usage[ 1 ] TO <fs_usage>.

CHECK <fs_usage> IS ASSIGNED.

IF <fs_usage>-object_type = if_fdt_constants=>gc_object_type_ruleset.

* The ruleset is the top of the where-used list ...

* ... so find the function associated with the ruleset

lo_ruleset =

CAST #( lo_factory->get_ruleset( iv_id = <fs_usage>-id ) ).

CLEAR lv_function_id.

lo_ruleset->get_function_restriction(

EXPORTING iv_timestamp = lv_timestamp

IMPORTING ev_function_id = lv_function_id ).

CHECK lv_function_id IS NOT INITIAL.

* We found a function to deploy!

INSERT lv_function_id INTO TABLE lt_deploy_funcs.

13

DATA(ls_comments) =

VALUE fdt_service_docu(

id = lv_function_id

docu = |Deployed Due to Automated Rate Update of Decision Table | && lv_name ).

APPEND ls_comments TO lt_comments.

ELSE.

* Read up the where-used chain

CLEAR: lt_usage2.

lo_admin_data = cl_fdt_wd_service=>get_admin_data( iv_id = <fs_usage>-id ).

lo_admin_data->get_where_used( EXPORTING iv_incl_memory = abap_false

iv_cross_version = abap_false

IMPORTING ets_usage = lt_usage2 ).

* Add the next-up rule objects to the list of usages to investigate

* for functions to deploy

INSERT LINES OF lt_usage2 INTO TABLE lt_usage.

ENDIF.

* Remove the row we have already assessed

DELETE TABLE lt_usage

WITH TABLE KEY client = <fs_usage>-client

id = <fs_usage>-id

version = <fs_usage>-version.

ENDWHILE.

UNASSIGN <fs_usage>.

Finally we redeploy the functions and provide details of the deployment success.

* Finally (re)deploy the functions which uses the Decision Table

IF lt_deploy_funcs IS NOT INITIAL.

DATA(lo_dsm) = cl_fdt_dsm=>get_instance( ).

APPEND p_dest TO lt_rfcdest.

lo_dsm->multideploy( EXPORTING it_service_id = lt_deploy_funcs

it_rfc_dest = lt_rfcdest

iv_overwrite_future = abap_false

iv_instant_activation = abap_true

it_service_docu = lt_comments

IMPORTING et_message = lt_message ).

ENDIF.

* Ok we’re finished

WRITE: / |Decision Table has been updated with new rate |

&& ls_new_rate-number DECIMALS 2,

ls_new_rate-currency.

IF lt_deploy_funcs IS INITIAL.

WRITE: / 'No functions were deployed'.

ELSE.

WRITE: / 'Related functions were deployed'.

CLEAR: lv_function_id.

LOOP AT lt_message ASSIGNING <fs_message>.

IF <fs_message>-id <> lv_function_id.

CLEAR: lv_name, lv_text.

lo_admin_data = cl_fdt_wd_service=>get_admin_data( iv_id = <fs_message>-id ).

lv_name = lo_admin_data->get_name( iv_timestamp = lv_timestamp ).

lo_admin_data->get_texts(

EXPORTING iv_timestamp = lv_timestamp

IMPORTING ev_text = lv_text ).

WRITE: / |Function: | && lv_name.

14

WRITE: / |Known as: | && lv_text.

lv_function_id = <fs_message>-id.

ENDIF.

WRITE: / <fs_message>-text.

ENDLOOP.

ENDIF.

Here’s what the resulting batch program log should look like. It’s simple but effective enough for our purposes.

Figure 4 - Log of the Automated Rate Update Batch Program

This is the real deployment log that is shown in the DSM workbench. Notice the deployment comments on the right hand side.

Figure 5 - Deployment Log in the DSM Workbench

By clicking on the hyperlink of the comments you can see the full comments text.

15

Figure 6 - See the full deployment comments via the comments hyperlink

Testing the Program Make sure the decision table is not locked by any user, including you, before running the program.

Remember that if you are in the Business Rules Workbench when you run the program, you might need to

refresh the browser window to clear the cache and see the updated decision table contents.

Taking the technique further This technique can be extended further to:

Update additional columns in the decision table

Fill other data types in the decision table cells

Create and call an additional BRFPlus rule to calculate the legislation period, e.g. if it’s not a simple

annual update

Create and call an additional BRFPlus rule to apply the inflation factor, e.g. to test and adjust the

rounding of the rate separately to running the batch program itself.

16

Related Content Ensuring Rule Modeling Guidelines with BRFplus/DSM

Handling of Applications with the BRF+ API (Part 1)

Handling of Applications with the BRF+ API (Part 2)

BRFPlus: Restrict users through Application Exit Class and Roles

17

Copyright

© 2015 SAP SE SE or an SAP SE affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE. The information contained herein may be changed without prior notice.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.

These materials are provided by SAP SE and its affiliated companies (“SAP SE Group”) for informational purposes only, without representation or warranty of any kind, and SAP SE Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP SE and other SAP SE products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries.

Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.