Skip to Content

There are some situations where we need to restrict the values of a decision table based on the login Business user, Roles and Authorizations to fulfill the business requirement.

Example: A manufacturing company allowed its dealers to maintain their own discounts for specific brands which are specified by the company. Each dealer login into the system and can maintain the discounts % for their allowed brands. Each dealer should only see/change their own allowed brands, they should not see another dealer’s discounts. This requirement can be implemented by using  below decision table has discount % for all different brands based on the Dealer but the challenge is to dynamically filter the values based login dealer.

Dealer ID

Brand

Discount

DL1

Pepe

30%

DL1

Nike

10%

DL1

American Eagle

30%

DL1

Adidas

30%

DL2

Levis

15%

DL2

Polo Ralph Lauren

20%

DL2

Abercrombie & Fitch

30%

DL2

True Religion

40%

Usually Application exist class can be considered for any kind of custom logic in the DSM/BRFPlus. The application exist class can be used several enhancements like control access of workbench objects, change/active notifications, F4 help for data objects …etc. However, it can’t be used to apply dynamic filters on a decision table.

We can achieve this functionality by enhancing the standard Decision Table WebDynpro Component.

     Decision Table.jpg

Decision Table (Figure 1.1)

Step 1 – Identify the Decision Table WD ABAP technical component name & View:

Right click on the decision table and select the Technical Help context option to know the component name. FDT_WD_DECISON_TABLE is the component and ALTERNATE_VIEW is the view of Decision table.

Identify WD Component Name & View.jpg

Identify WD Component Name & View (Figure 1.2)

Step 2 – Add ABAP code to filter the Decision Table:

Enhance the Modifyview (with POST-Exit) method of alternate view. Dynamic table filter logic need to be added by using API. Thecurrent Decision Table instance can be obtained by using wd_comp_controller->mo_model_cl->mo_dcsn_table attribute.


Decision Table After Dynamic Filter.jpg

Decision Table After Dynamic Filter (Figure 1.3)

Make sure this filter is applying only for the decision table that we wanted to filter. We should check condition by the decision table ID. Then it will not effect to the other Decision Tables.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Wolfgang Schaper

    What you describe may cause issues when it comes to the order of lines of the decision table, as any end user only sees parts of it. And a dealer may add entries for other dealers.

    Is it only about changing existing values? Or may users add or delete lines, and reorder lines?

    Here are two alternative approaches you may consider:

    1. setup separate decision tables for each dealer. By doing so you can grant each dealer access authorization only to their specific decision table.

    2. Let the dealers maintain their discounts through a separate UI. Then update the decision table using the API. This makes sure they only change values, but do not mess up the structure of the decision table. And you can make sure that activation is being performed after each update.

    (0) 

Leave a Reply