What are BTE and BDT Enhancements – Part 2

Were back with Tim’s next installment of this blog to teach us about two little known SAP Enhancement techniques, BTE’s and BDT’s Here is a little bit about Tim….

BTE BDT

Tim Moore is the president of 4 Ever Moore Enterprises, L.L.C., located outside of Charlotte, North Carolina.  Tim has over 15 years of experience with SAP including ERP, SRM, CRM, SCM, BI and XI. He has technical middleware experience as well as functional knowledge in many different industry solutions, such as FI, CO, MM, PP, SD, PS, HCM. He has Solutions Architect experience as well as expertise in SAP Business Workflow, ABAP and Form development.  He made his way into programming as an MM functional SME who grew tired of laying out technical requirements for developers, so he decided to teach himself to code ABAP. Since then, he has taken courses in ABAP, expanded to Web programming languages, and learned XML to help with integration points with SAP.  Prior to programming, Tim was a Business School graduate and served as a manufacturing manager for a company who implemented SAP. He continues to build his professional skills by expanding his business and technical knowledge in new areas.  You can reach him at sapcodemonkey@gmail.com

Enhancements: BTE and BDT

There are many options for enhancements in SAP. This blog will touch on two little known but very powerful options, BTEs and BDTs. We will discuss what they are and how they may be leveraged.

To begin, we must keep in mind every SAP implementation is different. That is because every business is different in the details related to their individual business processes and/or master data. Even within the same company or entity, there can be slight or major differences in a business process or master data based on an enterprise slice. Some parts of the organization perform business one way, while another performs business another. While this is a challenge during implementations, SAP has delivered many different enhancement options. These may be leveraged by the design and development teams to meet the needs of the organization.  Enhancement options are always preferable to core modifications when possible.

The acronym BTE stands for Business Transaction Events. This type of enhancement is typically leveraged in FI and SD transaction objects for process modification. To get a better understanding of BTE’s and how they work, take a look at last month’s blog What are BTE and BDT Enhancements – Part 1.

This month we will look at BDT’s. So lets get started!

The acronym BDT stands for Business Data Tool-set. This type of enhancement can offer exits in the Master Data maintenance for certain objects.

BDTs – What are they?

BDTs are Business Data Toolsets and are central control tools for maintaining SAP dialog programs for Master Data Objects. They enable enhancement spots in standard maintenance transactions for certain master data objects. The BDT Toolset supports maintenance via the use of dialog techniques, direct input and/or function modules.

Here is a short history of how the BDT evolved……

The Business Data Toolset originated in the Central Business Partner project back in the 1990’s. The following demands on the technical aspect of data entry played an important role in the development of the BDT:

Extensibility

Although the Business Partner project group had realized the central attributes of a business partner, (such as name components, addresses and bank details) there were other specific attributes in many of the remaining applications. Development partners and customers needed a facility for incorporating their own attributes into maintenance. In master data for accounts receivable and accounts payable, you had to make modifications to do this. Because it is impossible to collect and implement all these different attributes in one project group, maintenance for downstream enhancements had to be extensible without the need for modifications.

Configurability

Because mid-sized customers in particular tend to suppress most of the standard SAP data fields, dialog maintenance becomes tedious when you still have to go through screen after screen on which only one or two fields are relevant. Switching screens often slows down data entry considerably.  As a result, it was decided to make screens configurable in order for customers to both tailor entry screens to their individual needs and keep the number of screens to a minimum.

Divisibility

If you were to count up all the attributes in the SAP system that are relevant for a business partner, you would have several hundred fields. Since it is impossible to include all these attributes in each type of maintenance, the maintenance itself must be divisible into parts wherein only those attributes are visible which are relevant in the current business context. These parts are called roles in Business Partner. The necessary technology was first developed in a common program with application data for Business Partner. However, it soon became apparent that the second part of this project – i.e., the business partner relationships – were placing the same technical demands on data maintenance.

The requirements listed above were also applicable to other business objects.

As SAP restructured with a new industry orientation, extensibility assumed a greater importance for development. Many of the IBUs wanted to extend or enhance application objects from the standard system.

As a consequence, the Business Partner project group decided to separate the technical part from the application data and then make this technology available to other application objects. This technical part, which was called BP control or master data control for a long time, is now known as the Business Data Toolset, or BDT.

Transaction Code BUPT is the starting point for all BDT enhancements.  It contains a list of all registered application objects as well as the configuration transactions for each of these objects. Later in this blog I will provide you links so you can see a Build & use case, along with some good documentation.

BDTs – Why do we use them?

– To add new custom fields
– To hide standard fields
– To modify screens
– To add new menu options
– To add custom validations

So for example, if the requirement is to add new fields, shift fields from one tab to another tab, add field groups, create views, and create sections in a screen, then the BDT helps you to do that.

  1. Field Group – Field grouping is a way to group list of fields. Fields that co-exists all the time can be grouped into one Field group. Display attributes like hiding fields or making fields optional or mandatory or display only is set at field group level for ease of maintenance. For example, if a transaction has two fields named start date and end date, its likely that these two fields always co-exists i.e. either both of the fields get displayed or both of them hidden but never one field is displayed and other is hidden so these two fields can be created under same field group.
  2. View – One or more field groups constitute a view. All fields that are displayed and checked together are created as view. For ex, 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 can be displayed (display attribute is configurable at field group level) but if both are displayed, they will be displayed together i.e. you can’t split fields in a view and display some in one screen and another 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.
  3. Section – One or more views can be grouped into a section. 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 this is not required, the views can be displayed in separate block by just moving the view from the existing section to separate section.
  4. Screen – One or more sections can be grouped into a screen. Screen is the biggest unit in the screen layout. Each screen will be displayed as a tab in the final transaction.

But not all transactions will be BDT enabled in SAP. For example, Business partner is a BDT enabled transaction in SAP. New custom fields can be created; existing fields can be moved or deleted.  For each BDT enabled transaction a separate area menu will be available.

 

BDTs – When do we use them?

Typically, these are used when standard SAP master data and organizational process requirements are not consistent. The fact that these are requirements and not ‘nice to haves’, implies that some modification must be made to support business processes, otherwise those processes will not pass integration or user acceptance testing. When this occurs, enhancement requests are generated and enhancements begin.

BDT extensions, or enhancements, can be created over multiple levels.  As a rule application development in ECC has a maximum of five levels:

Application Basis (no BDT)
Standard Applications (BDT can be used)
Industry Solutions (BDT is often used)
Development Partners (BDT can be used)
Customers ( BDT can be used)

OK, so I can hear you asking… How can I find out if my transaction has above BDT modification technique available?

Here are a set of steps you can use to try and determine if your object is BDT capable.

BDT Tip

1)  Once you have identified a candidate for enhancement via BDT (i.e. – no SAP-provided dialog/screen  exits), how do you find out what the application object is so that you can determine if it is an object  registered for the BDT?
 2) All BDT-enabled applications call function module “BDT_TBZ0A_GET” to find out specifically what,  if anything, has been enhanced.
 3) Put a break-point in the function module.
4) Execute the transaction that you are hoping to enhance.
5) When your break-point is hit, look at the value assigned to variable IV_OBJAP.  This is your application object.
6) If the break-point is not hit, chances are that your application doesn’t use the BDT.

 

Want to find ALL the Tcodes in SAP that use BDTs? OK, to find SAP Transaction that use the BDT Framework, execute SE93 and search on transactions with the short description of “*BDT*”

 

 BDTs – More information:

I typically don’t like re-inventing the wheel, so I’m going to provide links to some additional documentation already created and provided by SAP

First here is a Developers Guide for BDT’s

BDT

 

Here is a document provided by the SCN community

BDT

 

 

 

Summary and some final thoughts…

BDT was meant to extend the BP model, User interface, APIs, etc. from a central perspective. let’s remember the user interface when BDT was designed was based on the SAP GUI, and as we all know SAP CRM has evolved since then, and the entire user framework was replaced by the Web UI, its tools, and methodology.

So, what now? Well some BDT’s were replaced by BADI’s and  Enhancement points and some others…well weren’t, so the BDT events are still working in some scenarios, for example during the maintenance of the BP relationships.

So in summary, we have discussed what BDT’s are, why to use them, and how. I also provided useful links to existing SAP documentation for a step by step Build and use case.

ITP logo

If you enjoyed this blog, What are BTE and BDT Enhancements – Part 2, please fill out the form below to sign up for our newsletter. We deliver SAP Technical tips & tricks, SAP news, and the current month’s BLOG right to your inbox!

Related Posts

Pin It on Pinterest

Share This

If you enjoyed this post, why not share it with your friends!