Future Enhancements 
Future Enhancements
For Release 4.6
Various enhancements to the BDT are planned for Release 4.6. These will be partially replicated at a later time in the development systems of those IBUs that use the BDT but do not develop in Release 4.6. Any questions you might have should be directed to the Business Partner development group. The most important developments in Release 4.6 are:
There are numerous ways of creating time dependency, including planned change documents and extending a table key by one or more date fields. It is left up to applications that use the BDT to decide whether and what kind of time dependency they want to use.
The BDT supports the use of planned change documents with two service function modules, which are called by the applications at certain times.
A BDT function module uses the database status which contains the current data as a basis for calculating the status at any date in the past or future. As a part of this procedure, the BDT reads the planned (future changes) or actual (changes in the past) change documents.
Based on the database status, the BDT function module determines the various data statuses in the past or future and then displays the date intervals with the data status valid for each.
The application writes the planned change documents during the event that saves the data (DSAVE).
If you choose the option of extending the table key by one or more date fields, most of the work is left to the applications. The BDT only provides a function module that uses pre-existing date intervals as well as the current change date and the action to be carried out to determine the new date intervals.
This program deletes test data prior to production startup. Data should only be archived in production operation (see below). The BDT takes control in the deletion program and uses two events to provide the applications the option to
The ADK (Archive Development Kit) is used for archiving. As in the deletion program, the applications can use events to intervene in the archiving process.
An employee may sometimes need an overview of all the transactions a company had or is having with a business partner. Ideally, you would be able to include all or only selected areas of a company in this kind of list.
Because this service has also been requested for other application objects, the BDT has developed an infrastructure for it. Its various uses are displayed in a user-defined tree structure. Each application can add its own nodes to the tree.
The application decides which form of data retention is required on an individual basis for each node.
The application stores the name of the function module in the BDT with which data can be imported. The advantage of this method is that redundant data need not be retained.
For each application object there is a usage table in which the applications can update their usage at the same time as the operative tables. At runtime, the where-used list extracts the data from this table. This type of data retention generally has a better runtime and should be used for usage from external systems.
There are also two options for display:
The BDT can display the usages within one of the configurable trees belonging to an application. Customers can create partial views of this display to see only the usages that they specify. One partial view can be stored as standard for each user group. You can navigate to the maintenance and/or display transaction of an application.
The ABAP List Viewer (ALV) can be used to create flexible evaluations of the application data. The BDT takes over control based on the extensibility requested at this point. The applications have the option of integrating their own data into the evaluation within just a few events.
After Release 4.6
You will be able to maintain an unlimited number of default variants so that they can be used as a reference when creating a new instance. You will be able to include default values from other sources using a separate event. By using a field grouping, you will be able to decide whether a default value can be overwritten by a user at a later time.
Like customers (see section 4.6.1), developers will also be able to configure their screens with VCT and drag&drop.
Large parts of the function modules to be created by the applications will be developed according to the specifications of the BDT. The important thing is to complete the actions defined for an event within that event. The application code will be generated according to the specifications of the developer responsible. This code can be supplemented and/or replaced by the developer’s own programs, thereby accelerating overall development.