Differentiation Types

Menu path: General control → Differentiation types

Description: Application data is generally dependent on the primary key of the application object. For a business partner, the primary key is the partner number. However, there can also be other attributes that must be differentiated according to other criteria. If data for an instance is only ever entered as a way of describing it as a criterion, then it would be called a differentiation type. Differentiation types are usually entered on the initial screen. The existence of an instance is also updated in dependence on the differentiation type specified.

Configure the input screens so that

Examples: Differentiation types are usually organizational units like company codes or sales areas. In addition, there can also be differentiation types that do not constitute an organizational unit. For an FI customer, the company code has to be entered on the initial screen. A large part of the data is dependent on the company code. These fields are grouped on separate screens. Because the header data in these screens also contains the value of the company code, it is obvious to the user which data can be given different characteristics on an individual company code basis. When you save, the existence of the customer in the company code entered is updated. If you create the customer in an additional company code, you must re-enter the company code on the initial screen as well as any data dependent on the company code in the data screens.

Note: The definition of one differentiation type is valid for all application objects. You decide which differentiation types are relevant for each application object (see Assigning Application Objects -> Differentiation Types).

Use: The relevant differentiation types are assigned to each application object (see Assigning Application Objects -> Differentiation Types). A differentiation type is stored for each view (see Defining Application Objects). When configuring the input screens, bear in mind that you should be able to use them later to check that only views of one differentiation type are grouped on one screen.

Activities: Check to see whether differentiation types are relevant for an application object. If this is the case and the differentiation type you need does not exist, contact the Business Partner development group, which is responsible for the central assignment of differentiation types and their associated elements within SAP. To create differentiation types for individual customer purposes, follow the steps below:

Each characteristic used to differentiate data must be entered at this point.

Differentiation types are made up of one or more elements. While a company code is made up of only one element - the company code itself -, a sales area is comprised of three elements: sales organization, distribution channel and division. Each differentiation element is normally represented by an input field on the interface.

Allocate the differentiation type’s elements to it. You still have to make an assignment even if a differentiation type has only one element.Note: The application responsible for the differentiation type determines the elements to be assigned. If an application requires a differentiation type with additional elements, do not extend the existing differentiation type - create a new one instead.

Application objects

Description: Each master data/transaction data object that uses BDT must be known. The maintenance of application objects is subdivided into the following points:

Menu path: General control → Application objects

Defining application objects

In this step, you register the new application object with the BDT and decide whether you want

Examples: Currently, there are about 15 application objects from IBU Banking, IBU Insurance, Contract Accounts Receivable and Payable and Real Estate Management. Some examples include:

Naming convention: The BDT has been released solely for the development of SAP application objects. It should not be used to develop customer application objects. To register a new application object, contact the Business Partner development group. The group keeps a central register that prevents different application objects being given the same name, which could cause problems.

Assigning application objects à differentiation types

At this point, you define whether the differentiation types already maintained are relevant for an application object. If you need a differentiation type that does not exist, you have to create it (see Differentiation Types).

Setting Transactions

The settings described in the section Dialog are maintained separately depending on the application object. If, for instance, you define a screen for application object BUPA (business partner), it will only exist within that application object.

By using setting transactions, you can easily create transactions with which the BDT control tables for your application object can be maintained. Later you also create the task menu for your application object (see Task Menu) from these transactions as well.

The following table provides an overview of current setting activities as well as which activity

Activities: Maintain a setting transaction for each setting activity. For each activity, carry out the following steps:

Procedure: Go into the ABAP Workbench menu and choose Development → Other tools → Transactions . Enter the transaction code and choose Create . Now select the Report transaction option and on the screen that follows enter BUSVIEWS in the program field next to the transaction text.

When the transaction is started, the maintenance view that is part of the control function or the view cluster for your application object is called automatically.

Task Menu

Create a separate task menu for your application object. This should contain the control transactions. When creating your menu, use the BP control sub-menu in task menu BUPT as a reference.

Note: You can maintain area menus by going into the ABAP Workbench from Development → Other tools → Area menus .

Applications

Each application that is active in the maintenance of an application object has to register itself at this point. They always develop within their own function group. There they create subscreens as well as their own function modules for BDT events.

This encapsulates the application and prepares it for delinking. Avoid grouping heterogeneous components in a single application. Any later delinking of these components that becomes necessary would only be possible with your own expenditure of time and effort - in other words, you would have to split the application and thus also the function group.

Menu path: Control <Object > → Applications

Naming convention: Name ranges Y* and Z* are reserved for customer applications, while development partners can use name range X*. SAP applications register their application with the application responsible for the application object.

The application ID plays an important role in the naming conventions for other BDT objects.