Cookbook For Enhancing The SAP Business Partner With Additional Customer/vendor Fields
Cookbook For Enhancing The SAP Business Partner With Additional Customer/vendor Fields
Cookbook For Enhancing The SAP Business Partner With Additional Customer/vendor Fields
Source
The source of this document is SAP note 2309153. Please check this note regularly to get the latest
version of this document.
The example coding used in this cookbook is provided by SAP note 2295823. It might be necessary to
implement this note to have this coding available in your system.
Change History
Version 1.15 (July 13th, 2021)
- Chapter 3.5.5 – BDT Field Groups – BUS2
--> Correct description how to enhance existing FMOD2 function modules with own logic
1 General Information
In SAP Business Suite (ERP 600 and Enhancement Packages), customer master data and vendor
master data transactions such as FD01, FD02, FD03, XD01, XD02, XD03, FK01, FK02, FK03, XK01,
XK02 and XK03 have been enhanced by customers with additional fields using the Business Add-In
(BAdI) technology. In the customer and vendor master dialog transactions, these fields were
integrated by adding additional sub-screens to the existing screens.
Moving to a SAP S4HANA release, traditional customer/vendor master transactions are made
obsolete and replaced by the business partner transaction BP. Because of this, all extension-specific
fields have to be integrated into the business partner.
This document provides a guideline how customers can transfer the enhancements they have made in
the customer/vendor transactions to transaction BP, so that a maintenance of these fields remains
possible after the upgrade to a S4HANA release.
Important
There are three different scenarios, which have to be considered differently:
*Scenario C is not in scope of this document. New requirements with the goal to enhance master data
in S4 releases with own fields should be developed completely within the SAP Business Partner.
Please refer to the guidelines for enhancing the SAP Business Partner:
Please find document links to these topics in reference table in chapter 1.3.
For mass processing the “Central API” is available. This interface provides the functionality for creating
and updating master data including both core and application data.
Topic Reference
Help Portal
Easy Enhancement Workbench (EEW) Link to SAP Documentation
Help Portal
Business Partner Extensibility Link to SAP Documentation
→ Functions → Extensibility
Table of Contents
1 General Information ____________________________________________________ 2
1.1 Used tools and frameworks ____________________________________________________ 3
1.2 Idea in a nutshell ____________________________________________________________ 3
1.3 Document references _________________________________________________________ 3
2 General integration overview ____________________________________________ 5
2.1 BDT Integration ____________________________________________________________ 5
2.2 XO overview ________________________________________________________________ 6
2.2.1 Scenario A – Integration of own tables in customer namespace ______________________ 6
2.2.2 Scenario B – Integration of core table appends __________________________________ 6
2.3 Saving data to the database____________________________________________________ 6
2.3.1 Scenario A – Saving data in own tables ________________________________________ 6
2.3.2 Scenario B – Saving data in core table appends __________________________________ 6
3 Settings in BDT – Business Data Toolset ___________________________________ 7
3.1 General information about naming conventions in BDT _______________________________ 7
3.2 Own BDT application – Transaction BUS1 _________________________________________ 7
3.3 Separate BDT datasets – Transaction BUS23 ______________________________________ 7
3.4 Registering tables – Transaction BUSG ___________________________________________ 8
3.5 BDT Assignments of screen->section->view->field group->field – Transaction BUS4 ________ 8
3.5.1 BDT screen sequences – Transaction BUS6 ____________________________________ 8
3.5.2 BDT screens – Transaction BUS5 ____________________________________________ 8
3.5.3 BDT sections – Transaction BUS4 ____________________________________________ 8
3.5.4 BDT views – Transaction BUS3 ______________________________________________ 8
3.5.5 BDT field groups – BUS2 ___________________________________________________ 9
3.6 BDT events – BUS7 __________________________________________________________ 9
3.7 Additional functions – BUS9 ___________________________________________________ 10
3.8 Assignments Dynpro field->DB field and DI field->DB field – BUSB and BUSB_DI _________ 11
3.9 BP_Views – BUSD __________________________________________________________ 11
4 XO Framework – Extensible Objects _____________________________________ 12
4.1 Scenario A – Integration of own tables in your namespace ___________________________ 12
4.1.1 Create Memory Object (MO) class ___________________________________________ 12
4.1.2 Create Persistence Object (PO) class _________________________________________ 12
4.1.3 XO Customizing _________________________________________________________ 13
4.2 Scenario B – Integration of core table appends ____________________________________ 15
4.2.1 Create Validation Object (VO) classes ________________________________________ 15
4.2.2 XO Customizing _________________________________________________________ 18
5 CVI – Saving data to database ___________________________________________ 19
5.1 Scenario A – Saving data in own tables in your namespace __________________________ 20
5.2 Scenario B – Saving data in core table appends ___________________________________ 22
5.2.1 Foreign key checks of appended fields ________________________________________ 22
6 Mass Data Processing – Central API _____________________________________ 24
6.1 Scenario A – Processing data of non-core tables __________________________________ 24
6.2 Scenario B – Processing data in core table appends ________________________________ 24
6.3 Data validation _____________________________________________________________ 24
6.4 Committing changes and error handling__________________________________________ 25
7 Debugging___________________________________________________________ 26
The purpose of this chapter is to provide an overview over the necessary activities using the
tools/frameworks mentioned in chapter 1.1. In chapters 3, 4 and 5 the detailed steps to be executed
per tool/framework are described. The relation between the overview chapter and the detail chapters
is as follows:
The integration of XO into BDT has been implemented in a generic way. The major part of the integration
is implemented generically. All further new datasets or core table appends that are integrated into BDT
using XO do not need to care about this part. If the integration is done as described below, the framework
will take care of the generic logic automatically. Especially most of the BDT events are treated
generically by the so-called BDT-adapter. The generic implementation is provided by class
Within the BDT adapter classes you find methods (generic_*; e.g. GENERIC_ISDAT or
GENERIC_ISSTA), that are called by the BDT event function modules (XO_GENERIC_EVENT_* in
transaction BUS7). These methods are generically responsible for processing the corresponding
events for all Financial Services and CVI datasets. For these events, no individual implementation is
necessary.
In addition, there are BDT settings that need to be implemented individually. For example in the
corresponding view in BDT, a PBO and a PAI module need to be registered for every view. Within
these two function modules the selection of data for this dataset from XO memory as well as the
saving of the changed data into XO memory later on are implemented. Further individual BDT settings
that need to be considered are for example a new BDT application per extension (separate for
customer and vendor enhancements), and of course the complete screen construction (screens,
sections, views, field groups, datasets).
In addition dynpros (SE80-screens) need to be implemented in transaction SE80 including PBO and
PAI logic within the BDT function group that is responsible for the corresponding BDT application. The
already mentioned PBO- and PAI-function modules need to be implemented there as well.
You can find more details including a precise step-by-step description about the BDT implementation
in chapter 3 below.
2.2 XO overview
In this sub-chapter, a rough overview of the XO implementation is provided. For more details have a
look into chapter 4.
Within every memory object class, you need to make sure that:
➢ for every field for which a validation check is needed a separate method
VALIDATE_<FIELD_NAME> is created. Of course you can also create validation methods with
combined field checks like: If field1 is not initial -> verify field2 is not initial
Additionally a persistence object is needed to retrieve data from the database including a reference
class representing the persistence object. A persistence object needs to be assigned to every memory
object according to the following logic:
➢ If your table uses KUNNR or LIFNR as key field you can refer to one of the existing persistence
objects CUSTOMER for table key KUNNR or VENDOR for table key LIFNR.
➢ If the key field in your table is a different one you have to create a new persistence object referring
to a new class, which has to inherit from either CVI_PO_CUSTOMER or CVI_PO_VENDOR.
The following aspects need to be considered, when implementing enhancements in BDT (the general
transaction for starting the BDT business partner control menu is /NBUPT).
All datasets, screens, sections and views are named with <APPL_NAME>number
(example: ZCUS01…ZCUS99).
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. Function modules from SAP and
function modules from in customer name space are maintained and delivered in the same table.
As the position number is the main key field of this table it is essential that customers use a
position number that cannot be overwritten by SAP customizing. This is especially critical in case
you have to add one or more event function modules in transaction BUS7.
➢ In order to make sure that customer-specific entries are not overwritten by SAP customizing
delivery please stick to the following rule:
Use a position number where one of the last two digits are unequal to 0. All other digits of the
position number can then be freely chosen.
➢ Example: If you would like to register a new FCODE-function module (e.g.
ZCUS_BUPA_EVENT_FCODE) you can use one of the following position 3.600.010 or 4.000.001.
In the normal use case, it is essential that the SAP standard modules are processed before, so
please use position numbers that are higher than the ones of SAP-standard modules that are
already registered in this event in transaction BUS7.
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:
The 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.
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:
All these modules are constructed in the following way: In PBO the data is read from the XO memory
and transferred to the dynpro structure. In PAI module, the changed data is saved back into the 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 BPO, 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).
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:
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.
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 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.
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.
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.
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.
XO customizing
For adaption, the XO customizing transaction SE80 is used. The relevant business object type for all
customer/vendor data is BUSINESS_PARTNER.
Validation
In the new class, it is necessary to create separate validation methods (static methods with public
visibility) for every table field that needs to be validated. You can also create methods to perform
combined validations using multiple fields. However, it is strongly recommended to have a low
granularity when creating the methods.
In addition, method VALIDATE_INTERN must be redefined. Within the redefinition first of all method
VALIDATE_INTERN of the super-class has to be called, before all new validation methods within this
redefinition are processed. You can compare for example the implementation in method
CVI_MO_KNA1->VALIDATE_INTERN. Method VALIDATE_INTERN is called in an overall check on
saving the business partner or when you explicitly press button “check” in business partner
maintenance.
In addition, the created validation methods must be called in the corresponding PAI function modules
for dialog input validation.
Class examples
CVI_MO_KNA1, CVI_MO_KNB1, CVI_MO_LFA1, CVI_MO_LFB1
If the key field of your table is not KUNNR or LIFNR you have to create a separate persistence object
class. The new class has to inherit from CVI_PO_CUSTOMER or CVI_PO_VENDOR. Now perform the
following steps:
4.1.3 XO Customizing
Execute the following steps to maintain the XO customizing for your objects:
a) Persistence Object
This step is only needed when you have created an own persistence object in chapter 4.1.2. If you use
one of the standard persistence objects CUSTOMER or VENDOR, you can skip this step.
b) Memory Object
Open tree node “Memory Objects”. Switch to change mode and create a new memory object entry.
Selected Persistence Object = CUSTOMER or VENDOR when your table uses KUNNR or LIFNR
or name of your own persistence object from last step
The correct segment object depends on the customer/vendor segment to which your table belongs:
1. Use the correct table type of the customer/vendor table for these variables
3. If you need further data from other memory objects (database tables) have a look at section
“Further data needed…” in the example method above:
2. Use the correct table type of the customer/vendor table for these variables
4. The example code calls three static methods VALIDATE_KNA1_FIELD1/2/3 for performing
the field validations. If possible, it is recommended to implement one single method for each
appended field to be validated.
Example code:
0. Adjust all parameters and used variables accordingly to the appended core table
1. Implement your validation logic here and set lv_error = true in error case
2. Append error message to <result>-message
Example code:
The created single static validation methods from step 4. shall be called in your PAI modules for the on
screen validation within the BP dialogue when data is entered by the user.
Please also have look at SAP note 2293713 if want to integrate foreign key checks provided by classes
CMD_EI_API_CHECK and VMD_EI_API_CHECK.
Attention Make sure that your implementation does not contain any BDT specific logic, like calling
methods from class CVI_BDT_ADAPTER ADAPTER or calling function module
BUS_MESSAGE_STORE to process an error message!
Validation Objects are also processed in mass processes (Central API), so that BDT-
specific coding could lead to a short-dump during runtime.
4.2.2 XO Customizing
In the XO customizing (transaction XO80) open business object type BUSINESS_PARTNER.
Open tree node “Validation Objects” and create a new validation object referring to your validation
class.
Open the corresponding segment object (for KNA1 this is CUSTOMER_GENERAL) and
add the created validation object.
The correct segment object depends on the customer/vendor segment to which the memory object of
the appended table is assigned:
These enhancement spots contain several BAdI definitions, which provide initialize, validate and save
functionality.
CUSTOMER_EXTENSION VENDOR_EXTENSION
CUSTOMER_EXTENSION_AUTH_CHECK VENDOR_EXTENSION_AUTH_CHECK
CUSTOMER_EXTENSION_CHECK VENDOR_EXTENSION_CHECK
CUSTOMER_EXTENSION_COMPLETE VENDOR_EXTENSION_COMPLETE
BAdI
CUSTOMER_EXTENSION_INITIALIZE VENDOR_EXTENSION_INITIALIZE
CUSTOMER_EXTENSION_OUTBOUND VENDOR_EXTENSION_OUTBOUND
CUSTOMER_EXTENSION_UPDATE VENDOR_EXTENSION_UPDATE
How-to recommendation
It is necessary to create one enhancement implementation only for each enhancement spot. Each of
these two enhancement implementations should use only one single implementing class containing
implementations for all BAdIs that are marked in red in the above table. So in case you integrate both
customer and vendor data in your application you will have only two enhancement implementations and
only two implementing classes after finishing the implementation.
Both classes must contain at least one public static attribute to store KUNNR / LIFNR.
.
Example
A created enhancement implementation containing all three BAdIs should look like this:
Remark: This BAdI will be called multiple time in case of simultaneous changes on different
data segments (KNA1, KNB1, KNVV …). But only in the first call you can rely on a
filled KNA1 / LFA1 segment containing the needed KUNNR / LIFNR.
Therefore the check that KUNNR / LIFNR is not initial is needed here.
1. Use the table type of your own table for these variables
The provided example coding will determine which entries have to be inserted, updated or deleted
from the database.
Remark
With implementation of SAP note 2295823 class CVI_FS_ENH_CUSTOMER_BADI_SCENB might be
available in your system delivered. This was needed for an earlier enhancement concept supporting a
constellation where appended fields are not added to the complex structure CVIS_EI_EXTERN. Since
this concept is no longer recommended, this example coding is not needed any more.
CVI_CUSTOM_MAPPER_ENH
Map customer relevant foreign key
MAP_CUSTOMER_FOREIGN_KEY_TABLE
BAdI check data
Method Map vendor relevant foreign key check
MAP_VENDOR_FOREIGN_KEY_TABLE
data
Requirement
Industry specific CVI enhancements need to perform a foreign key check at the PAI level for the fields
of their application. There is no public method available which executes the foreign key check.
Solution
For processing generic foreign key checks in each of the two classes VMD_EI_API_CHECK and
CMD_EI_API_CHECK for vendor master and customer master the following two methods have been
introduced:
STRUC_FOREIGN_KEY_CHECK_EXTRNL and FOREIGN_KEY_CHECK_EXTERNAL.
• The transferred data of application owned tables will be automatically saved in the XO
memory and can be retrieved in the update BADI later on as described in section 5.1.
CUSTOMER_EXTENSION VENDOR_EXTENSION
CUSTOMER_EXTENSION_AUTH_CHECK VENDOR_EXTENSION_AUTH_CHECK
CUSTOMER_EXTENSION_CHECK VENDOR_EXTENSION_CHECK
CUSTOMER_EXTENSION_COMPLETE VENDOR_EXTENSION_COMPLETE
BAdI
CUSTOMER_EXTENSION_INITIALIZE VENDOR_EXTENSION_INITIALIZE
CUSTOMER_EXTENSION_OUTBOUND VENDOR_EXTENSION_OUTBOUND
CUSTOMER_EXTENSION_UPDATE VENDOR_EXTENSION_UPDATE
Call your validation methods within your implementation to validate your data that are passed in
parameter IS_CUSTOMER_EXT. In case of an error, fill the returning parameter CS_ERROR
accordingly with the error indicator and the error message(s) to be returned.
Please also have look at SAP note 2293713 if want to integrate foreign key checks provided by classes
CMD_EI_API_CHECK and VMD_EI_API_CHECK.
In case PPO is active, you can call method CL_MD_BP_MAINTAIN-> GET_PPO_MESSAGES after
function module BAPI_TRANSACTION_COMMIT has been executed. This method will return all logged
PPO entries of the current LUW in parameter E_RETURN.
7 Debugging
Places to have a look in debugger, when problems occur: