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….
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 [email protected]
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
Configurability
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.
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.
- 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.
- 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.
- 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.
- 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:
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.
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
Here is a document provided by the SCN community
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.
