4 Settings in BDT – Business Data Toolset

The Business Data Toolset (BDT) is used to integrate new fields into the business partner UI (transaction BP).
The BDT integration involves the creation of various field groups, screens, views and sections so that the
corresponding tabs and the screens appear in transaction BP. Using BDT you can create own objects or
enhance existing standard objects.
The following aspects need to be considered when implementing application-specific enhancements in BDT
(general transaction for BDT business partner control menu is /NBUPT).
4.1 General information about naming conventions in BDT
The central part in the naming for all BDT objects is the application name (<APPL_NAME>) defined in
transaction BUS1 (example: ISOC).
All datasets, screens, sections and views are named with <APPL_NAME>number (example: ISOC01…
ISOC99).
All event function modules need to have the following naming:
APPL_NAME>_BUPA_EVENT_<EVENT_NAME> (example: ISOC_BUPA_EVENT_FCODE).
All PBO/PAI function modules need to have the following naming:
<APPL_NAME>_BUPA_PBO_<VIEW_NAME> (example: ISOC_BUPA_PBO_ISOC01)
<APPL_NAME>_BUPA_PAI_<VIEW_NAME> (example: ISOC_BUPA_PAI_ISOC01).
Rules for the use of position numbers (e.g. when assigning function modules to BDT events)
➢ The objects assigned by help of position numbers will be processed in the order of the numbering (e.g. the
views assigned to a section will be constructed in a way that the view with the lowest number is displayed first
and all higher numbers below / same for the event function modules the module with the lowest number
assigned to an event is processed first and all others later according to their number)
➢ Especially for the event function modules conflicts can occur because function modules from different
software components are delivered in the same table. For screen elements this conflict does normally not
occur because higher extensions normally create their own screen elements rather than assigning a
SAP_APPL screen element to an SAP_ABA element.
➢ In order to make sure that the same number is not used twice in different software components the
following rules apply: SAP_ABA: use position number with last 5 digits equal to 0 (e.g. 3.600.000 or 200.000)
SAP_APPL: use position number with last 4 digits equal to 0, 5 th digit from end needs to be unequal to 0 (e.g.
550.000 or 3.760.000) Industry extensions like EA-FINSERV or IS-MEDIA: Use position number with last 3
digits equal to 0, 4th digit needs to be unequal to 0 (e.g. 3.601.000 or 402.000) Further rules apply to SAP
Partners (3rd digit unequal to 0) or customers (last two digits unequal 0).
➢ Field group numbers: In order to get a field group number range to be used for the field groups of your
development please contact the BDT team (component CA-GTF-BDT, contact is Gurumoorthy H (manager of
BDT team).

4.2 Own BDT application – BUS1 or BUPT

You need to create your own BDT application(s) and assign them to your objects (views, bp views, …). Do not
add the generic CVI applications CVIC or CVIV. You can also decide to split your enhancement into different
BDT applications. The BDT application is used to hide your enhancements in the UI in case your extension is
not active. It necessary to use different BDT applications for customer and vendor enhancements.
4.3 Separate BDT datasets – BUS23 or BUPT
You need to create your own datasets. Do not use the generic CVI datasets CVIC*/CVIV*. A separate dataset
is needed at least for the differentiation between general data, company code dependent data and sales area
dependent data for each customer and vendor. However, you should split your enhancement into different
datasets according to the business context. In SAP standard usually there Cookbook – Extending SAP Business
Partner with application owned customer/vendor dataset
© Copyright SAP SE 2018 Internal only Page 9 of 31
is one dataset per table (although in special cases deviations are possible). All data belonging to one view can
only be assigned to the same dataset (because the assignment is made by the dataset assignment in the
view).
4.4 Registering tables – BUSG or BUPT
Every table that is added to CVI needs to be registered in this transaction with the corresponding attributes
(change document object, function module to get data, function module to collect data). If for the enhanced
table (or set of tables) a change document object exists, this needs to be added in the corresponding field. In
case no change document object exists, a new one needs to be created and integrated.
4.5 BDT Assignments of screen->section->view->field group->field
You should always create a new section with its own frame title. If fields fit to an already existing screen (tab),
because they are to be seen in the same business context, the new section can be assigned to an existing
screen. In this case you only need to create views and field groups in addition and assign everything (see
below). In case you have fields that do not belong to the already existing tabs you can create new tabs
(screens) and assign them to the corresponding screen sequence (transaction BUS6 – screen sequence
BUP001 for general data, screen sequence FS0001 for company code data customer and vendor, screen
sequence CVIC01 for sales data customer, screen sequence CVIV01 for sales data vendor).
4.5.1 BDT screen sequences – BUS6 or BUPT
In case you have a completely separate set of screens (tabs), you can create your own subheader-id (button in
the subheader line in transaction BP). For this, you need a new screen sequence, which can be defined here.
In addition, the relevant screens need to be assigned to the screen sequence here.
4.5.2 BDT screens – BUS5 or BUPT
In case you have fields that belong to a screen sequence, but do not fit into any of the existing tabs, you can
create a new tab (screen) and assign it to an existing screen sequence. Assign your sections to the
corresponding screens also in transaction BUS5.
When creating a new screen, it is necessary to assign the correct header section to this screen. The header
section must be the first section in the screen, which means it must have the lowest item number.
There are different header sections for general, company code, sales area and purchasing organization data
which must be assigned:
Data Segment Header Section
Customer General BUP009 Header Data (General Screens)
Customer Company Code FI0201 Header Data (Company Code-Dependent Screens)
Customer Sales Area CVIC00 Header Data (Sales Area-Dependent Screens)
Vendor General BUP009 Header Data (General Screens)
Vendor Company Code FI0201 Header Data (Company Code-Dependent Screens)
Vendor Purchasing Org. CVIV00 Vendor: Header Data (Purchasing Organization)
4.5.3 BDT sections – BUS4 or BUPT
For any new field or set of fields, you need to create a section of your own with a speaking frame title (see
column “Title” in transaction BUS4). Assign only those views to a section that fit together. If the business
meaning is different, create a new section. Assign the views to the sections here as well.
4.5.4 BDT views – BUS3
The view is the central object in BDT. It contains the connection to the SE80-screen (in a function group) where
the input fields are defined. For differentiation between the BDT elements and the SE80 elements, the German
name for the SE80-screen, dynpro, is used here. The view also contains the PBO/PAI-Cookbook – Extending
SAP Business Partner with application owned customer/vendor dataset
© Copyright SAP SE 2018 Internal only Page 10 of 31
logic as well as an assignment of application and dataset. In addition, the fields are assigned to the views via
the field groups here.
General rule should be: Do not assign too many field groups to a view. Only assign more than one field group
into one view if the fields belong to the same context. If in doubt, create different views for different field groups.
This will help you very much later in maintenance!
In addition, you need to add a PBO and PAI function module here in which the PBO and PAI logic is
processed. The coding in the PBO and PAI-modules can be mainly copied from the standard modules.
Compare for example:
• • CVIC_BUPA_PBO_CVIC01 / CVIC_BUPA_PAI_CVIC01 for general customer data
• • CVIC_BUPA_PBO_CVIC15 / CVIC_BUPA_PAI_CVIC15 for sales area customer data
• • CVIC_BUPA_PBO_CVIC30 / CVIC_BUPA_PAI_CVIC30 for company code customer data
• • CVIV_BUPA_PBO_CVIV01 / CVIV_BUPA_PAI_CVIV01 for general vendor data
• • CVIV_BUPA_PBO_CVIV30 / CVIV_BUPA_PAI_CVIV30 for company code vendor data
• • CVIV_BUPA_PBO_CVIV71 / CVIV_BUPA_PAI_CVIV71 for purchasing vendor data

All these modules are constructed in the following way: In PBO first of all the data is taken from XO memory
and transferred to the dynpro structure. After that in PAI module, the changed data is saved back to the local
table and integrated in the current memory. After that, it is transferred back to XO memory for later saving. In
addition, in PBO modules, the texts for F4-fields are also determined and in PAI modules at the end, the
validation methods from the XO memory or validation object are called to validate the changes.
In addition to the PBO and PAI function modules there are – of course – also the PBO and PAI modules in the
dynpro flow logic. Here you need to call the standard function modules provided by BDT:
BUS_PBO – to be called in a perform PBO, which in turn is called in the PBO module
BUS_PAI – to be called in a perform PAI, which in turn is called in the PAI module.
For an example, check the dynpros in function group CVI_FS_UI_CUSTOMER.
Attention: When you miss to call function modules BUS_PBO and BUS_PAI in the dynpro flow logic, there will
be problems with field modification and the behavior of the fields in dialog (e.g. fields available for input in
display mode or similar problems).
4.5.5 BDT field groups – BUS2
On field group level the fields from the dynpro are assigned.
General rule: only one field per field group! Only in exceptional cases, you should assign more than one field to
one field group. Field modifications are done on the basis of field groups and two fields that belong to the same
field group can only be set to “required“, “display“, “hidden“, “change“ or “unspecified“ together.
In addition, you need to add a function module for FMOD2 event in the field group. If you do not have any
specific field modification logic for your field groups you can add the standard FMOD-function modules here:
• • CVIC_BUPA_EVENT_FMOD2/CVIV_BUPA_EVENT_FMOD2 for general data
• • CVIC_BUPA_EVENT_FMOD2_SALES/CVIV_BUPA_EVENT_FMOD2_PORG for sales
data/purchasing org data
• • CVIC_BUPA_EVENT_FMOD2_CC / CVIV_BUPA_EVENT_FMOD2_CC for company code data.

In case you have an additional requirement for field modification setting create an own FMOD2 function module
in your BDT function group and – as a first step within your code – call the current core FMOD2 function
module at the beginning. After that enhance it by your logic. When doing so you can rely on the incoming field
status (IN_STATUS) for all general field groups and only need to add logic in case you would like your own
field groups to deviate from this. Cookbook – Extending SAP Business Partner with application owned customer/vendor
dataset
© Copyright SAP SE 2018 Internal only Page 11 of 31
4.6 BDT events – BUS7
The big majority of BDT events is handled automatically by class XO_BDT_ADAPTER and corresponding
enhancements (classes inheriting from XO_BDT_ADAPTER, see chapter 2.1), provided you have implemented
your XO-customizing correctly.
You only need to care about BDT events in case you do anything special like for example adding some
function codes (buttons) for navigating to a popup or similar. In this case you need a separate event function
module (in above example an FCODE-function module) and assign it to the corresponding event (e.g.
FCODE).
In addition, it is necessary to implement additional event function modules for displaying the change documents
for your table(s) in transaction BP. Please have a look into our standard CHGD* function modules and
implement an analogous logic for your tables
• • CVIC_BUPA_EVENT_CHGD1 / CVIV_BUPA_EVENT_CHGD1
• • CVIC_BUPA_EVENT_CHGD3 / CVIV_BUPA_EVENT_CHGD3
• • CVIC_BUPA_EVENT_CHGD4 / CVIV_BUPA_EVENT_CHGD4

For event CHGD2 no function module needs to be assigned. If your tables are correctly integrated in XO,
function module XO_GENERIC_EVENT_CHGD2 will process the necessary logic generically.
Further event function modules might be needed once you start supporting the archiving/deletion of a business
partner.
4.7 Additional functions – BUS9
You need this transaction in case you have buttons (function codes) in your application. In order to integrate a
function code in the application the following steps are necessary:
1. Enter the function on your dynpro. Naming convention: The name of the push button needs to have the
prefix “PUSH_”. Example: PUSH_BUTTON1.
2. In the screen painter details in field “FctCode”, you need to enter the name of the push button again.
3. In order to react to the selection of the button during runtime by a user you need to implement an FCODE
function module (naming convention <APPL_NAME>_BUPA_EVENT_FCODE) and implement the following
coding here

"set fcode as processed per default e_xhandle = true. case i_fcode. when
'BUTTON1'.
"implement application-specific logic here
when others. clear e_xhandle. endcase.
Please note that you need to remove the prefix “PUSH_” when catching the function code in your FCODE
function module (==> WHEN ‘BUTTON1’ and not WHEN ‘PUSH_BUTTON1’).
4. In order to make sure that the push button can be influenced using the field modification adjustments, create
a new field group (transaction BUS2) and assign the button to the field group using the “Field Group -> Fields”
sub-menu. The name of the button (including the prefix) needs to be entered in column “field name”. Column
“table” remains empty. In addition, you should assign an FMOD2-function module according to the rules
described in chapter “BDT field groups – BUS2”.
5. In addition, you have to create a separate view for the button according to the rules above in chapter “BDT
views – BUS3”. Maintain the dynpro in which the button has been implemented and assign the field group
created in “4” to the view.
6. Finally, the function code needs to be made known to the BDT. For this, it has to be defined in transaction
BUS9. The following steps need to be executed for this: a. Press button “New entries”.
b. In field “Function code”, enter the name of your function code without the prefix (“PUSH_”).
c. In field “Function text”, enter a text for your function code. You can leave field “screen sequence cat.” empty.
d. After that, you have to decide if you would like to rely the visibility of the function code on either field group or
view. Recommendation: use function “Activate using Status of

Cookbook – Extending SAP Business Partner with application owned customer/vendor dataset
© Copyright SAP SE 2018 Internal only Page 12 of 31
Field Group” and maintain visibility in section “Active per Status of Field Group” at the end of the page.

To have a reference to copy from you can have a look at the push button PUSH_CVIS_SEPA (BUS9), which is
assigned to field group 309 and view CVIS01. The corresponding FCODE function module is
CVIS_BUPA_EVENT_FCODE.
4.8 Assignments Dynpro field->DB field and DI field->DB field – BUSB and BUSB_DI
You need this transaction in case you have dynpro fields that have a different name than the corresponding
database fields. BDT needs to be able to assign the fields, otherwise for example the required-fields check will
not work.
4.9 BP_Views – BUSD
This is the technical view on the business partner roles (see views V_TB003 / V_TB003A in transaction SM30).
You may think about creating your own roles instead of enhancing the standard roles. Then you would not
need to switch your functionality.
In order to make sure that your enhanced fields are available in the corresponding roles add your datasets and
applications to the BP views. Differentiate between customer and vendor roles here.
4.10 Field modification status for blocked customer/vendor master
S/4 releases support the blocking of customer and vendor master without blocking the assigned business
partner. In such a case where an assigned customer/vendor is blocked while the business partner is not, all
users with standard authorization will not have any access to exclusive customer/vendor based data in
transaction BP. General data like names or addresses are still accessible and editable in the business partner,
but any changes to these data will no longer be synchronized with the blocked customer/vendor master.
A user with “Data Privacy Officer” (DPO) authorizations, who opens a business partner which is not blocked
itself but assigned to a blocked customer or vendor in transaction BP, has access to all customer/vendor data
fields and sections. When the DPO-user switches transaction BP to change mode, all fields you have added to
transaction BP in context of customer-vendor-integration will be editable (please note that changes to these
fields will not be transferred to the blocked customer/vendor when saving and will therefore not be saved!).
Nevertheless, this is not a consistent UI behavior and you should take the below measures to prevent the fields
to be open for change. You need to create a function module which sets the field status of your fields to
“display” in that case and assign this function module in BDT customizing, so that it is processed in FMOD1
event.
The function module should have the following naming convention:
<APPL_NAME>_BUPA_EVENT_FMOD1_DPP
Execute the following steps:
1. Make sure that SAP notes 2592806 and 2590430 are implemented in your system.
2. Create a new function module taking function module CVIS_BUPA_EVENT_FMOD1_DPP as a reference. If
you copy the code and adjust replace the name of the BDT application to your own BDT application, your field
groups will also be switched to display mode in case an assigned customer/vendor is blocked.
• 3. Afterwards register your function module in BDT: a. Open maintenance view V_TBZ3Q in SM30 and
select application object BUPA
一 b. Add a new entry with i. FGroupCrit: <APPL_NAME>000
一 ii. Description: CustVEnd Blocked -> Display
一 iii. Read function module: <Name of your function module>
一
一
一 4. Save this entry.