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.
Introduction
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.
Applications
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.
Events
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)
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
View
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
No comments:
Post a Comment