Current Status

User

The first user of the BDT is SAP Business Partner (see Introduction to the BDT - What is the BDT? ). Business Partner’s purpose is to integrate all partner solutions that currently exist in the SAP system. In the first step, the following new applications build on this development:

  • Contract Accounts Receivable and Payable

  • IBU Banking

  • IBU Insurance

  • IBU Utilities

  • IBU Telecommunications

The integration of the Treasury business partner is currently in process and should be complete by R/3 Release 5.0.

In the meantime, other application objects have already taken advantage of the BDT. The following application objects are currently being realized or developed in conjunction with the BDT:

  • Central Business Partner

    • Partner maintenance

    • Relationship maintenance

  • Contract Accounts Receivable and Payable

    • Contract account

  • IBU Banking

    • Bank account

    • Standing order

    • Financial product

    • Financial conditions

    • Risk object

    • Variable transactions

  • IBU Insurance

    • Insurance: Claims

    • Insurance: Loss event

    • Commissions: Remuneration agreements

  • Real Estate

    • Real estate contract

    • Tenant information

    • Cost efficiency analysis

Advantages

Similar technical demands are often placed on the development of application objects. By using the BDT, an application object can provide functions without having to realize them itself. The essential advantages of using the BDT are:

  • Extensibility

    You can extend various dialog parts without the need for modifications using downstream applications either within SAP or through development partners or customers. This applies to

    • Screen Layout

    • Screen sequence

    • Program Logic

    • Menu

    • Search Helps

    • Field Modification

    • Authorization checks

      Extensibility is also possible in other areas, such as data maintenance without dialog or change document lists.

      Extensions, or enhancements, can be created over multiple levels. As a rule, application development in ERP currently recognizes a maximum of five levels:

    • Application basis

    • Standard applications

    • Industry applications

    • Development partners

    • Customers

  • Configurability

    Screen layout and sequence can be configured by application developers and/or customers. While developers use BDT control tables to modify screens, customers can take advantage of a configuration tool developed using Visual Basic for changing standard SAP screen layout and sequence with the drag&drop method.

  • Divisibility

    The maintenance of large objects can be broken down into smaller parts. You use control tables to define which attributes can be maintained in an object part. The term object part can be replaced by a more suitable term for any given application object. The BDT supports two types of divisibility:

    • Each object instance can take on multiple parts (example: roles with a business partner)

    • Each object instance can take on just one part (example: account type with a bank account)

  • Decoupling

    Each application always develop within its own function group. The individual applications are thereby decoupled.

  • Use of Other Interfaces

    Interface and program logic are separate in the BDT. The program logic for the applications is contained fully in function modules that are called by the BDT at predefined times. As a result of both of these factors taken together, the SAP interface of the BDT can be replaced by a different interface.

  • Faster Development

    Because the BDT takes control of dialog processes, the applications 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, online navigation takes place using the BDT and is therefore identical. Using the generic object services also contributes to a certain uniformity.

Functionality

The following provides you with an overview of functions that have already been realized.

  • Dialog Maintenance

    • Existing tables can be extended by downstream applications using the APPEND structure technique from Basis. These new table fields as well as completely new tables can be integrated seamlessly into a dialog by SAP applications, development partners or customers.

    • Screen layout and sequence can be extended and configured using control tables (without the need for modification). Customers can adapt standard SAP screens to their needs with drag&drop within customizing. Using the Visual Configuration Tool (VCT), customers can change

      • screen layout - or also group several screens together

      • screen sequence

      • screen titles

      • frame titles

    • Program logic can be extended by SAP applications, development partners or customers using event function modules In this way, each application can

      • read its tables

      • check its fields

      • carry out additional checks for fields in other applications

      • save its tables

    • The screen title is composed by the BDT in accordance with SAP ergonomic guidelines. Its elements are

      • the title of the application object ( business partner )

      • the activity ( change )

      • the title of the current screen ( address )

        In this example, the BDT created the screen title Change Business Partner: Address .

        You can change the title created by the BDT with event DTITL.

    • The menu is defined by the application that owns the application object. The central functions, such as Cancel, Exit, Save and Back, provided by the BDT are part of the menu. You can use control tables to define when a menu option is to be active depending on the:

      • maintenance mode (save or transfer mode)

      • activity (create, change, display)

      • views on the current screen

        Example: The menu option Delete Bank Details should only be active in the Create or Change activity and when the view of the bank details is on the current screen.

    • Field groupings can be made using criteria of your choosing. The BDT supports the application when creating a maintenance transaction for one criterion and links settings for various criteria to the runtime using predefined rules.

    • Using a control table, applications can add any number of other elementary search help functions to fields related to search help . Starting in Release 4.6A, this service will be provided by Basis in the form of APPEND search help functions.

    • You can include notes easily on a screen and, like any other dialog part, place them wherever you like.

    • Authorization checks can be carried out between the initial screen and the first data screen as well as prior to saving. The BDT provides some of the recurring authorization checks that can be used by application objects.

      • Authorization for field groups

        Example: Only user A may maintain names and addresses of business partners, while all users can maintain any remaining fields.

      • Authorization for field values of any field

        Example: Authorizations for a business partner are to be granted using the ‘Last Name’ field

        User A may only maintain those business partners whose last names begin with A-K

        User B may only maintain those business partners whose last names begin with L-Z

        Every application can also carry out any other authorization checks.

    • Change documents are written by each application when saving data itself; the BDT provides evaluations. The following evaluation types are available:

      • Field changes (display changes to a field of an instance)

      • Account changes (display changes to all fields of an instance)

      • Display changes to multiple/all instances

    • Transfer mode: The maintenance dialog is called from the maintenance of another object. The data is saved together with the calling object.

      Example: Maintaining a contract requires you specify both parties to the contract - two business partners. You should be able to create and/or change both business partners from contract maintenance. The contract data and the business partner involved are to be saved together. In order to do this, business partner maintenance must be called from the contract in transfer mode. When you exit business partner maintenance, the data entered is flagged but not yet saved in the database. Once the contract has been saved, the flagged business partner data is written to the database.

    • External interfaces can be realized for application objects that were developed with the BDT. In this case, the external maintenance transaction only takes over the structuring of the interface and forwards the field contents entered on to the BDT. BDT function modules are called to carry out program logic such as reading, checking and saving data. They trigger the events that call the event functions modules in the applications.

  • Maintenance Without Dialog

    • Direct Input (DI)

      Using the DI tools developed in EIS, data is read from a file and transferred to the BDT. The BDT then forwards that data on to the applications within events DINP1 (header data) and DINP2 (data). Finally, the same events are processed in this type of maintenance transaction as in a dialog. Most of the program logic developed by the applications can be reused.

    • Maintenance Using Function Modules

      In contrast to DI, the data in this case is transferred in the interface of a function module instead of being read from a file. Once the data has been transferred to the BDT, the process is the same as that for DI.