Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
At almost all S/4HANA preparation projects the question comes up, how the BP transaction works together with BDT. In this Blog I would like to give a short introduction and share some knowledge of understanding BDT.

Sources are the very old CRM course CR590 and my experience in this area.

This blog is relevant for all releases working with Business Partner, meaning ECC 6.0 onwards. Main focus is SAP S/4HANAon-premise and private cloud edition, which is the most relevant working with Business Partner.


What is the BDT?

BDT stands for "Business Data Toolset" and is a central tool for maintaining master data and simple transactional data. In this context I will focus on Business Partner transaction and Business Partner Relationship.

BDT has following key design targets:

  1. Extensibility
    modification-free extension of various dialog parts, for example screen layout, screen sequence, program logic, menu, field grouping, etc. via several layers.

  2. Configurability
    application developers (maintenance of the control tables of the BDT) can adapt screen layout and screen sequence

  3. Divisibility
    the maintenance of larger object parts can be split into smaller sections

  4. Quicker development
    the dialog control is carried out via the BDT. The business functions are realized by the applications. In addition the BDT provides several services in which the applications can include themselves

  5. Generic Object Services
    direct input, transfer mode, field control, etc

BDT - Business Data Toolset

Access BDT menu

  1. /n (to get back into main menu)

  2. transaction BUPT (call BDT-Menu)


BDT Objects

BDT Processing Logic

Fixed program logic is reading control tables from customizing.


Program Logic

The program logic of the BDT is static (fixed). Events call dynamically customized Function Modules and Screens.


Every object of master data and document data, which could be maintained using BDT, is defined as an Application Object

BUP    – General Business Partner

BUB    – Business Partner Relationship

BUA    – Addresses

CVIC – Customer Link

CVIV – Vendor Link

Applications can be switched on or off separately.


Application data is kept in memory objects instead of structures. To access data you have to read data from memory objects into local structures. After changing data these data have to write back into memory objects. Foundation for saving data to the database are memory objects.

From Development perspective each application is clustered in a separate Function Group. In this context all applications are decoupled. The communication between applications is using GET- and COLLECT function modules or GET and SET methods.

Screens (type subscreen), PBO and PAI modules and function modules for events (for each application, table and view) are created in the function group.

The PBO module calls only the service function module BUS_PBO for executing the field status.

The PAI module calls only the service function module BUS_PAI for getting the cursor position.


Program logic:

  • Events for each application (read data, check data, save data)

  • Events for tables (communication between applications / function groups

  • Events per view

    • PBC Event for preparing tables (sorting, etc)

    • PBO Event prior to data entry Reading of texts from Customizing tables, formatting of the date etc.

    • PAI Event following data entry. Checking of the entry values. Conversion of the date

Note: The same coding is carried out in the maintenance mode without dialog (e.g. direct input). There is no redundant coding.



The BDT uses fixed events within the dialog flow. All applications are able to extend the object by their own program logic. The BDT calls application-specific function modules dynamically. The most important events are displayed below

ISSTA - Initialization

ISDAT - Read data from DB

ISDST - Distribute data to participating application

FCODE - Process own function code

XCHNG - Check whether data changed

DCHCK - Check data

DSAVB - Collect data from owning app.

DTAKE - Note data in global memory

DSAVC - Complete data (internal number)

DSAVE - Save data on DB

DLVE1 - Initialize current memory

DLVE2 - Initialize global memory


Screen Layout (OK-Code: bdt_analyzer)

A description how to use BDT Analyzer can be found at my blog

SAP S/4HANA Business Partner BDT Analyzer usage


BP transaction dialog has a hierarchical structure built based on following elements which are set up in BDT.

  • Screen Sequence

  • Screen

  • Section

  • View

  • Field Group

  • Field


Screen Sequence (transaction BUS6)

A Screen Sequence represents the number of shown tabs and contains one or more screens


Screen (transaction BUS5)

A Screen represents a tab and contains one or more Sections


Section (transaction BUS4)

A Section represents a screen area and contains one or more Views


View (transaction BUS3)

A View represents a technical screen (Dynpro) and contains one or more Field Groups


Field Groups (transaction BUS2)

A Field Group contains one or more Fields



The View is one of the most important elements at the BDT. It is the connection between configuration (Customizing Objects) and Workbench Objects like PBO/PAI Function Modules.



View Definition

Fields a collected at one View if the:

  • Content has the same context

  • Checks are the same


Fields at a View are located at a Subscreen and each View is assinged to a technical subscreen. The View is assigned to an Application and contains Field Groups. A View can be used in multipple Objects (BP Roles).


View Attributes

Function Modules of Events

  • Before Output (PBO): e.g. select and show texts

  • After Input (PAI): Field checks

  • Before Screen Callup (PBC): sort tables, display of 1st entry


Show View only if

  • Application of View is active

  • View is assigned to objects which are going to maintain


Flow Logic of Subscreen

  • Call Function Module BUS_PBO in PBO (field modification, messages)

  • Call Function Module BUS_PAI in PAI (determine cursor position)


Special importance of Data Set

An another interesting point is how the connection between the roles and the technical elements are handled. Remember to BP transaction, each selected role is shown with a different screen layout (visible tabs). How the system is managing this?


Each View is assigned to a Data Set in View definition. Selected Data Sets are assigned to so called BP-Views (transaction BUSD). Remember, at view definition Data Set BUP010 is assigned to view BUP240 (Organization: Legal Form).


If you have a look at BP-View FLCU01 (Customer/Vendor Integration: Customer) you will find Data Set BUP010 (Central Data).



At Role Definition in Customizing you will find the assignment of BP-View to BP-Role.

Customizing: Cross-Application Components->SAP Business Partner->Business Partner->Basic Settings->Business Partner Roles->Define BP Roles


As you can see, BP-View FLCU01 is assigned to BP Role FLCU01.

Whenever you choose role FLCU01 in BP transaction, BP-View FLCU01 is called with all assigned Data Sets and Views with fields.



This full bunch of field groups is now controlled by field modification (display/mandatory/hide/optional) from Customizing. At this customizing step you will find again Data Sets (unfortunately a bit hidden).

e.g. Customizing: Customizing: Cross-Application Components->SAP Business Partner->Business Partner->Basic Settings->Field Groupings->Configure Field Attributes per BP Role



By the way, all this information can be captured from BDT_Analyzer as well.

And another feature is the navigation into customizing settings directly from BDT Analyzer by clicking on specific Screen name, View Name, Section Name, ......


Field Group

Field Groups are representing a collection of fields which are in a strong relation. Keep in mind, field modification is based on field group. That means if a field group is set as mandatory the all fields which are part of this field group are mandatory (similar to field modification based on Account Group).

Function Module CVIV_BUPA_EVENT_FMOD2_ENH is responsible for field status determination (hidden, optional, mandatory). With pushing the button you can navigate into Function Module coding.

With double-click on 'Field Group -> Fields' you can navigate into field assignment.

You can see 3 fields assigned to field group 3379:

  • SPERQ_TXT - Text field for field value description

  • GS_LFA1-SPERQ - technical screen field (Input Field)
    with navigating into screen painter of view CVIV60 you can see technical screen fields (see next picture)

  • LFA1-SPERQ - technical table field

I hope this blog post was helpful for you. If so, click on “like” or “share”. Please explore the links below for any further clarification.

Helpful links: