Business Data Toolset for Industry Solutions

Overview of Business Data Toolset

BDT (Business Data Tool set) allows you to customize screens so that you can modify the order of screens, the placement of sections of data and even fields that are visible to the user. BDT is most useful in Claim processing transactions which permit greater flexibility in displaying and processing data.

The BDT also provides generic services for consistently changing requirements such as occur in change document lists, field groupings, modification of screens for customer tailored applications etc.

For e.g. in Claims Management, you can enter claim in Quick Claim, Expert mode, notification mode etc. and since each of these modes will have there own requirements of data, the BDT allows displaying different views in different modes. Also if the different mode uses the same screens, the same view can be reutilized rather than creating the same screens again.

Prior to BDT, we had to search for the screen exit in the program in order to do any modifications to the screen if it is allowed, but finding a screen exit is a tedious job. The reasons that screen exist is not one of the best solutions can be cited out from the fact is SAP does not provide a screen exit for all the screens that it has given for all the modules that it has implemented. SAP has given screen changes possible for only few screens that it thought of any change where as BDT provides screen changes for almost all possible claim transaction screens. Also the screen exit is difficult to find out.

To do changes in the screens using screen exits, it requires expertise in ABAP modules like dialog programming and sub screen handling. As this is not easy for people to do who don’t have technical knowledge of ABAP Modules (e.g. Functional Consultants), screen exits are not very easy to do.

The old fashioned user exits, BADIs and screen variants help us in fulfilling this requirement partially, but they don’t always give the flexibility required. This is where business data toolset can help. Though SAP incorporated an exhaustive list of attributes required in each business application, in each SAP implementation cycle we come across requirements where customers want to add more and more attributes specific to their business. Since these attributes are so specific to their business only, it’s impossible for SAP to collect and implement all these attributes. This is more so in case of ramp-up applications like grants management where it takes few implementations to get a complete list of attributes. So what is required is a possibility to extend the standard business application without modifying any SAP standard objects.

The use of BDT makes screen changes more flexible as the screen changes can be configured within different screens based on the mode of screen and it is easy to display the same screen in different orderings, different fields in different transactions.

Looking at the Claims Management perspective, a business partner could be involved in various roles in the claims. His roles may vary like he may be a Claimant, Policy Holder, Payee, Agent, Auditor, Doctor, Agency, Financial Company, Insurance agent, Loss adjuster, property owner etc. As the roles changes his association and then in turn his role towards the Claim changes. These changes of roles require various different attributes to be needed at different associations of the business partner other than his key attributes. This led to the evolution of BDT which enables to display only those attributes which are relevant in that context of the Business

The BDT involves customizing of the standard screens, adding new fields, deleting existing fields, changing screen layout, removing an entire section like  address dependent communication etc. of the business partner from the screens. Since the Business Data Tool set lets you map and adjust individual processes at any time by configuration at the very bottom level, this tool set gives you significant freedom in changing user interfaces according customer needs.  The BDT has been introduced in the Claims Management for the first time but this tool is supposed to be the best alternative for all customer based solutions regarding creation of additional data fields, relationships and roles.

The evolvement of BDT could be taken from the times when it was realized that other than the central attributes of the business partner like name, address etc. there were other specific attributes in many remaining applications. Customers needed a facility for incorporating there own attributes into maintenance. A business partner may have several hundred fields and it becomes increasingly difficult to include these attributes in each type of maintenance. For this reason it was thought that the maintenance itself  must be divisible into parts wherein only those attributes must be seen that relevant or necessary in that business context. Since the Business partner relationship was also demanding data maintenance, it was thought of incorporating BDT in its future Industry solutions and thus decided of incorporating it in Claims Management of SAP. The most important criteria of incorporating it being extensibility. Also one of the reasons that led to the inclusion of BDT in Claims Management is that SAP was not involved in the Banking and Insurance sector in the market and so it was not competent enough in this sector compared to others. So it might have thought of developing a tool which would be more customer oriented and which could be enhanced easily as the changes occur.

The BDT is now evolving as a central tool in many SAP modules because it enhances the extensibility of SAP. The Most Latest is the Tax and revenue Management of SAP for the public sector where all master data types are built into one logical frame work.

Business Data Toolset

Tiers in Screen LayoutThe following are the tiers to the screen layout.

  1. Screen Sequence category
  2. Screen Sequence
  3. Screen
  4. Section
  6. Field groups
  7. Fields

Screen Sequence category: A screen sequence category is the highest level of BDT objects. Many screen sequence can be assigned to a screen sequence category and one of the screen sequence is selected as the standard one. A screen sequence combines the screen sequences that contain data of a specific type of data such as Sub claim data, damaged data, Loss details etc.

Screen Sequence: Screen sequence defines the order in which the screens appear. The screen sequence describes the screens and the order in which they appear. A particular screen of a screen sequence category can be used in multiple screen sequence as the requirement is.

Screen: Screens are created to hold logical group of sections. For e.g. a sub claim screen will hold sections like sub claim type, sub claim information etc.

Sections: A Section groups a particular type of views. A view could be address, phone number etc. The BDT automatically puts a frame around the section in display. The advantage with having section is views that make sense together can be grouped into one section and they will be displayed together. If at later stage if this is not required, the views can be displayed in separate block by just moving the view from the existing section to separate section.

Views: A view is grouping of field groups that logically should group related field groups. All fields that are displayed and checked together are created as a View. For eg. If a view two field groups included, all the fields from the two field groups always get displayed together. One field group can be hidden and another one can be displayed (display attribute is configurable at field group level) but if both are displayed together, i.e. you cant split fields in a view and display some in one screen and some in another screen. Technically a view is nothing but a sub screen and all the fields in the included field groups are added to this sub screen through screen painter.

Field Groups: A field group is the most granular level of the configuration in BDT. A field group is a combination of logically related groups.

The below screen shots describes the BDT screens in the analyzer.
Screen Shot of BDT Screen

The following screen is the BDT analyzer which is displayed when we type “SSEQ_DIAG” on any BDT screen.

The BDT Analyzer shows the tree hierarchy structure starting from the screen sequence category till the field groups. The Header Data, Business partner details etc are shown as different sections in the BDT analyzer as can be seen in the above screenshot. The different tab strips like Claimant, Previous claims, previous illness etc. are shown as different screens in the BDT analyzer which implies that the screen sequence category is having multiple screens within the screen sequence.

Modifying a screen sequence layout and other BDT components

Modifying an already existing screen involves copying an existing the screen element, and making changes to the copied ones. Though SAP delivered screen sequences, screens etc. may fulfill the business requirements of most of the clients, it is necessary sometimes to change the components of screen sequences according to the business needs.

To modify an already existing BDT component, the idea is to copy the already existing screen element and make changes to the customized one and attach the customized BDT component.

For e.g. we want to add a field group to the already existing screen sequence, modifying that screen sequence will be necessary. You will need to create a custom view that will hold the new field groups that you have created and then a new section to hold the custom view that you created. Once a new section is created, a new screen that houses the new section and finally a new screen sequence to hold the screen. The only thing that doesn’t change is the screen sequence category.

The last step is to add the screen sequence in the screen sequence category in the configuration
Settings to include the new screen sequence.

To Remove an element entry from the screen
There is always a requirement to remove an entry from the screen which is not needed in a screen. BDT is a very simple toolset to do this. The following steps describe the step by step procedure to remove an entry from the screen.

In this example we will modify a view ICLJ03 because it contains a field group that we don’t

Step 1
Go to transaction ICLWM and select Screen Layout -> Views
Screen Layout Click on Views

Step 2
Locate View ICLJ03 and click copy button.
Locate View ICLJ03

Step 3

a. Rename the view ICLJ03 to ZCLJ03 to keep the name as original, however changing it to a ‘Z’ view ( i.e. customize the view )
b. Select copy all
c. A message will be displayed saying all dependent entries have been copied, the implication of which is that all the field groups that belongs to the view has also been copied

Rename the view ICLJ03 to ZCLJ03

Step 4

If you don’t want one of the copied field groups, select the view that was just created and go to change mode for the field groups that belongs to the view. Delete the field group that is not required.
View Field Groups

Step 5

a. You will get a message that your selected entries have been deleted. Make sure to save to ensure the process is completed
b. Finally go back to ICLWM and select Screen Layout -> Sections. Select Section ICLJ03 and copy it. Rename the new section ZCLJ03. Follow previous step to copy all dependent views to the new section
c. This time however you will be prompted to change the item number for each section.
Selections Overview

Step 6
a. Now we need to create a new screen to hold the section. So, go to Transaction ICLWM again and select Screen Layout -> Screen
b. Select ICLC56 and copy it. Follow steps to copy the screen but replace section ICLJ03 with the new custom section ZCLJ03.
Screen Selections

Step 7

We have changed the screen now we need to modify the screen sequence CL56. Rename the screen ICLC56 to ZCLC56. This will call the custom screen and all associated views, sections, and field groups inside.
Screen Sequence Screens Overview

Step 8

Add the custom Screen sequence in the screens sequence category
Screen Sequence Category Screen Sequence

Step 9

a. Last step is to change the screen sequence for the internal claim type

b. Depending upon whether the changes affects Expert Mode, Notification mode, Quick claim mode or all, that will determine where you need to do the configuration

c. If the changes affect Expert Mode, go to Claims Management -> Claim -> Process Control (Internal Claim type) -> internal claim type: Specify Claim handler group + screen sequences. Then select the internal claim type and claim level that the screens sequence you are changing affects.

d. If the change affects the notification mode or quick claim mode, go to claims management -> Claim -> Process Control (Internal Claim type) -> internal claim type: Specify CH group screens sequence for other proc. modes.

e. Then select your internal claim type and the mode you are modifying (Notification for notification mode, over view for quick claim mode). Select node category after you have selected the internal claim type and the mode you want to modify.

To Add two custom fields to the screen

There are scenarios in real time applications where you would want to add new fields to the screens as indicator or anything else and utilize the value entered in the fields for the application.

Consider a scenario where you want to add two new fields ZPIPELINE_TO_HO and ZPIPELINE_TO_FRAUD in the claim over view screen.

Following is the step by step procedure to add two new fields to the screen

Step 1

  • Go to object navigator (SE80) and create a new function group
  • Create two new screens with two new fields that needs to be added
  • Create PBO and PAI Function Modules for the screens and call the function modules BUS_PBO and BUS_PAI in the PBO and the PAI modules respectively
  • Create two new Function Modules Z_XXX_PBO and Z_XXX_PAI for the PBO and PAI processing for the screen fields in the view
  • Create a new field group that needs to be attached to the custom view which is to be created. Create the fields that needs to be attached to the claim overview screen and save the field group

Create new field group

Create fields that needs to be created to the claim over view screen and save the field group

Here in this e.g. the field is ZZPIPFRAUD of table ICLCLAIM


Field Group Fields

Step 2

  • Create a new custom view ZCLC91 by copying the standard view ICLC91 as explained earlier.
  • Give a description and give the function pool name that is created earlier with the screen number. Also give the Function modules name in the before O/P and after O/P column.
  • Add the field group that is created in the custom view

Change VIews Views Details

A typical example of a before O/P Function module gets the values from the table and displays it in the screen field created

This Function Module ZICL_FRAUD_PBO is entered in the before O/P function Module. This Function Module gets the claim details from the current memory and assigns the field values in the current memory structure.

Business Data Toolset

This Pre O/P Function Module uses ICL_CLAIM_GET Function Module to retrieve the values form the current memory and assign it to screen fields

A typical example of entry out put Function Module Z_FRAUD_PAI

This Function Module gets the claim details from the current memory and moves the current screen fields to the structure. It then calls the standard Function Module ‘ICL_CLAIM_SET’ to set the values in the ICLCLAIM table once the claim is saved

After Entry Function Module


This Pre O/P Function Module uses ICL_CLAIM_GET Function Module to retrieve the values form the current memory and assign it to screen fields.

A typical example of entry out put Function Module Z_FRAUD_PAI


This Function Module gets the claim details from the current memory and moves the current screen fields to the structure. It then calls the standard Function Module ‘ICL_CLAIM_SET’ to set the values in the ICLCLAIM table once the claim is saved

After Entry Function Module

Selection Views


Create a new custom screen ZICL02 by copying the existing standard screen ICLC02. Add the new custom section ZICL02 created earlier

Business Data Toolset15

In the Claim Over view screen the two new fields are added as shown in the circle.

Business Data Toolset16

By Using BDT, an application object can provide functions without having to realize them itself. BDT provides several advantages, the most important of which are


Extensibility: You can extend various dialog parts without the need for modifications using down stream applications either within SAP or through development partners or customers. Extensibility is also possible in other areas, such as data maintenance without dialog or change document list.


Configurability: Screen Layout and sequence can be configured by application developers and/or customers


Divisibility: The maintenance of large objects can be broken down into smaller parts. The BDT supports two types of divisibility


  • Each object instance can take multiple parts (e.g. roles with a business partner)


  • Each object instance can take on one part (e.g. account type with a bank account )


Faster Development: Because the BDT takes control of the dialog processes, the application limit themselves to realizing business functions. The BDT also provides services in which the applications can be included. These factors reduce considerably the time needed to develop applications.

Uniformity: In all application objects that use the BDT, the online navigation takes place using the BDT and is therefore identical. Using the generic object services also contributes to certain uniformity

Use of Other Interfaces: Interfaces and program logic are separated in the BDT. The program logic for the application is contained fully in function modules that are called by BDT

at predefined times. As a result of both these factors taken together, the R/3 interface of the BDT can be replaced by a different interface

Fields on screens are only ever automatically filled with the value saved under the parameter ID of a data element if the Set Parameter/Get Parameter attributes for the corresponding fields have been explicitly set in the Screen Painter. But using set parameter is highly risky because in any part of the program the value of the field could be retrieved and modified which can lead to inconsistent data. Also with the help of BDT, authority level checks can be performed at the field group levels i.e. if a particular type of user is not allowed to view the field in the change or display mode, the fields can be hided at the field level for a particular set of users.

As regards future enhancement in BDT, there should be a provision that not only developers but also customers be given the ability to change screens according to there wishes by making the customization of screens easy something like drag and drop facility directly to screens and make available built in application programs that could be directly utilized in the screens for any fields added or removed.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: