End of Purpose Check Adaption For Applications Consuming SAP Business Partner in SAP S4HANA

SAP SECURITY REQUIREMENT SEC-
256 (DELETION OF PERSONAL DATA)

DEVELOPMENT HOW-TO INFORMATION
END OF PURPOSE CHECK ADAPTION FOR

APPLICATIONS CONSUMING SAP BUSINESS
PARTNER IN SAP S/4HANA
AND HOW
AND HOW TO CREATE DATA DESTRUCTION OBJECTS
Released for SAP Customers and Partners
Valid for Release

SAP S/4HANA 1610
Document Version
1.0 (July 2016)
Target Group
SAP partners and customer solutions developers in charge of compliance for security requirement SEC-256:
"SAP software shall support deletion of personal data (including personally identifiable information)".
TYPOGRAPHIC CONVENTIONS
Type style / icon Description
Quotation Words or characters quoted from the screen. These include field
names, screen titles, pushbuttons labels, menu names, menu paths,
and menu options. Cross-references to other documentation.
Emphasis Emphasized words or phrases in body text, graphic titles, and table
titles.
All names File and directory names and their paths, messages, names of
variables and parameters, source text, and names of installation,
upgrade and database tools.
User entry User entry texts are words or characters that you enter in the system
exactly as they appear in the documentation.
<Variable user entry> Angle brackets indicate that you replace these words and characters
with appropriate entries to make entries in the system.
KEY Keys on the keyboard, for example, F2 or ENTER.
Note
Caution
Example
Recommendation
DOCUMENT HISTORY
Document version Date Description
1.0 July 2016
END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 2

TABLE OF CONTENTS
1 Introduction ................................................................................................................................. 5
2 Overview of the End of Purpose (Blocking) Process .................................................................. 6
2.1 Key information about available master data blocking functionality................................... 6
2.1.1 Central Business Partner ............................................................................................... 6
2.1.2 Customer and Supplier .................................................................................................. 7
2.2 Handling of blocked master data in dependent applications ................................................ 7
2.2.1 Central Business Partner Data ....................................................................................... 7
2.2.2 Customer/supplier ......................................................................................................... 8
3 How-To COMPLETE an EoP Check Implementation ............................................................... 9
3.1 Maintenance of Application-Specific Residence and Retention Periods overview ............. 9
3.2 Purpose of application names ............................................................................................... 9
3.3 Purpose of application rule variants ................................................................................... 10
3.4 Requirements for the EoP Check Implementation ............................................................. 10
3.5 Step 1 – Collect Condition Field Values ............................................................................ 10
3.6 Step 2 – Map the Condition Field Values to the Application Rule Variants ...................... 11
3.7 Step 3 - Calculate the End of Residence Date .................................................................... 12
3.8 Step 4 - Return new SoRT data .......................................................................................... 12
3.9 Mapping of Condition Fields to Application Rule Variants using ILM Rule Groups ....... 12
3.10 Store SoRT Information before the central EoP check run ............................................ 14
4 EoP Check for Central Business Partner Data .......................................................................... 15
4.1 Registration of Applications ............................................................................................... 15
4.2 The End Of Purpose Check Interface ................................................................................. 15
4.3 The Unblocking Check Interface ........................................................................................ 17
4.4 Enterprise Service Methods ................................................................................................ 18
4.4.1 End of Purpose Check for Central Business Partners ................................................. 19
4.4.2 Block Notification for Central Business Partners ....................................................... 20
4.4.3 Interim Check Results Notification for Central Business Partners ............................. 20
4.4.4 Unblock check for Central Business Partners ............................................................. 20
4.4.5 Unblock notification for Central Business Partners .................................................... 21
4.5 Business Add-Ins (BAdIs) .................................................................................................. 21
4.5.1 Business Partner Key Mapping ................................................................................... 21
4.5.2 Restriction of Business Partner from EoP Check........................................................ 21
4.5.3 Export SoRT Details of Blocked or Unblocked Business Partners ............................ 22
4.6 Adaption by Dependent Applications................................................................................. 23
5 EoP Check for Customers and suppliers ................................................................................... 25

5.1 Registration of Applications ............................................................................................... 25
5.2 The End of purpose Check Interface .................................................................................. 25
5.2.1 Interface Methods ........................................................................................................ 26
5.2.2 Interface Attributes ...................................................................................................... 27
5.2.3 Initialize and Finalize methods ................................................................................... 27
5.2.4 EOP Check Method CHECK_PARTNERS ................................................................ 28
5.2.5 Blocking method PARTNERS_PURCMPL_EXPORT.............................................. 30
5.2.6 Blocking Process flow ................................................................................................. 31
5.3 The Unblocking Check Interface ........................................................................................ 31
5.3.1 Initialize and Finalize methods for Unblocking .......................................................... 32
5.3.2 Unblocking Methods ................................................................................................... 32
5.3.3 Unblocking process flow ............................................................................................. 33
5.4 Special Scenario: One-Time Accounts ............................................................................... 34
5.4.1 EOP Check Method CHECK_CPD_PARTNERS ...................................................... 34
5.5 Enterprise Service Methods ................................................................................................ 35
5.5.1 End of Purpose check for customer and supplier (vendor) ......................................... 36
5.5.2 Block Notification for Customer/Supplier .................................................................. 37
5.5.3 Interim Check Results Notification for Customer and Supplier ................................. 37
5.5.4 Unblock check for Customer and Supplier ................................................................. 37
5.5.5 Unblock notification for Customer and Supplier ........................................................ 37
5.6 Business Add-Ins (BAdIs) .................................................................................................. 38
5.6.1 Mapping of Master Data ID for EoP and Unblocking ................................................ 38
5.6.2 Custom Change Document Handling for EoP Check ................................................. 38
5.7 Adaption by Dependent Applications................................................................................. 38
5.7.1 Adaptation of Read Function Modules ....................................................................... 39
5.7.2 Adaptation of Check Function Modules ..................................................................... 40
5.7.3 Adaptation of Search Function Modules ..................................................................... 41
5.7.4 Adaptation of BAPI Methods/Function Modules ....................................................... 41
5.7.5 Adaptation of Enterprise Services ............................................................................... 42
6 Copyright and Disclaimer ......................................................................................................... 43

1 INTRODUCTION
Partner or customer specific applications that consume, respectively reference, business partner master
data, shall adapt to the business partner end of purpose (EoP) check functionality. This includes functionality
to determine per business partner (including linked customer/supplier data) the usage in dependent
applications, to realize blocking after end of purpose in master data including all dependent application data
and to store relevant start of retention information. In a nutshell, the blocking and deletion concept for
business partners provides the following features:
 For each business interaction, e.g. order, delivery, and invoice, it is possible to maintain different
residence and retention periods based on country- and customer specific requirements. In case
more than one residence/retention period is valid, the longest is applied.
 After expiration of the longest residence period the business partner is blocked.
 After expiration of the longest retention period the business partner and all related data is destroyed.
In consequence, the blocking of business partner master data requires the following deliverables by relevant
partner or customer specific applications:
 Application objects with a reference to the business partner master data have to provide an end of
purpose (EoP) check to enable blocking and deletion of business partners.
 Application objects with a reference to the business partner master data have to consider a blocked
business partner by preventing new business and providing display access only for authorized
users.
This document provides a technical overview of the available business partner master data blocking
functionality and the interfaces to be considered for the creation of an end of purpose check for an
application.
It includes information about the necessary adaptions in the corresponding functionality for handling blocked
business partners.
You can find more information about data protection in the product assistance for SAP S/4HANA 1610:
Product assistance for data protection
Navigation path: http://help.sap.com/s4hana_op1610/ -> Product Assistance -> Cross Components -> Data
Protection

2 OVERVIEW OF THE END OF PURPOSE (BLOCKING)
PROCESS
2.1 KEY INFORMATION ABOUT AVAILABLE MASTER DATA

BLOCKING FUNCTIONALITY
2.1.1 CENTRAL BUSINESS PARTNER
Blocking Indicator Field XPCPT in database table BUT000
Table for SoRT Info BUTSORT
Business Function BUPA_ILM_BF
ILM Object CA_BUPA
Blocking Report BUPA_PREPARE_EOP

Transaction BUPA_PRE_EOP
Unblocking Request BUPA_REQ_UNBLOCK

Transaction BUP_REQ_UNBLK
Unblocking Report BUPA_PREPARE_EOP

Transaction BUPA_PRE_EOP

2.1.2 CUSTOMER AND SUPPLIER
Blocking Indicator Field CVP_XBLCK* in database tables LFA1, LFB1, KNA1, KNB1, KNVV,
KNVK
Table for SoRT Info CVP_SORT
Business Function ERP_CVP_ILM_1
ILM Objects FI_ACCRECV,

FI_ACCPAYB,
FI_ACCKNVK
Blocking Report CVP_PREPARE_EOP

Transaction CVP_PRE_EOP
Unblocking BUPA_REQ_UNBLOCK
Request BUP_REQ_UNBLK
Transaction
Unblocking Report CVP_UNBLOCK_MD

Transaction CVP_UNBLOCK_MD
2.2 HANDLING OF BLOCKED MASTER DATA IN DEPENDENT

APPLICATIONS
2.2.1 CENTRAL BUSINESS PARTNER DATA
 Read authorization requirement

To see blocked master data, read authorization (activity 03 Display of authority object B_BUP_PCPT
Business Partner: Purpose Completed) must be assigned to the user.
 BP blocking
o To determine the blocking status of a business partner use function module
BUPA_XPCPT_GET (RFC enabled)
o To return the user authorization for a blocked business partner, use the following function
modules: BUPA_DP_AUTHCHECK
 BUPA_DP_AUTHCHECK_API
 BUPA_DP_AUTHCHECK_MASS
 Centrally-read APIs
o All centrally-read APIs include the check on the block indicators, the necessary authorization
check, and the return of no or initial data for the unchanged calls of the APIs.

2.2.2 CUSTOMER/SUPPLIER
 Read authorization requirement

To see blocked master data, read authorization (activity 03 Display) for the customized authorization
group (BEGRU) for the following authorization objects must be assigned to the user:
o F_KNA1_BED
o F_BKPF_BEK
o F_BKPF_BED
o V_KNA1_BRG
Activity 03 Display of authority object B_BUP_PCPT Business Partner: Purpose Completed is
required due to the read access for blocked address data.
 Customer, supplier, and contact person blocking
o To determine the blocking status of a customer, supplier, or contact person use function
modules:
 CVP_GET_BLOCK_STATUS_CUST
 CVP_GET_BLOCK_STATUS_VEND
 CVP_GET_BLOCK_STATUS_CONT
o To return the user authorization for a blocked customer, supplier, or contact person, use the
following function modules:
 CVP_AUTHCHECK_CUST*
 CVP_AUTHCHECK_VEND*
 CVP_AUTHCHECK_CONT*
 Centrally-read APIs
o All centrally-read APIs include the check on the block indicators, the necessary authorization
check, and the return of no or partly-initial data for the unchanged calls of the APIs.

3 HOW-TO COMPLETE AN EOP CHECK
IMPLEMENTATION
One of the central aspects of the blocking concepts of the central business partner (CBP) (the customer and
supplier) is that application-specific retention periods must be maintained twice using transaction IRMPOL for
the ILM object of the application and the assigned master data object.
The same condition fields as in the application are not available for the master data object. Therefore, the
application rule variant concept was introduced to provide a mapping possibility for customers to maintain
the same retention periods in the master data ILM object and the application object.
3.1 MAINTENANCE OF APPLICATION-SPECIFIC RESIDENCE AND

RETENTION PERIODS OVERVIEW
Master Data ILM Objects Dependent Application Object
Residence Residence periods are maintained for the Blocking and maintenance of
Periods master data ILM objects for the following: residence periods for the ILM object
of a dependent application object
 Master data itself (for example, if new master are not required.
data without usage should not be blocked too
early)
 Each dependent application object maintained
using the application name/application rule
variant concept to consider these periods
according to the master data object ID before
blocking
Retention Retention periods are maintained for the Retention periods are maintained for
Periods following: the ILM object of a dependent
application object to ensure
 Master data (for example, if master data without destruction of application data after
usage should not be destroyed too early) the end of the retention period.
 Each dependent application object maintained
using the application name/application rule
variant concept to consider the application-
specific retention period before destruction of a
particular master data object ID
3.2 PURPOSE OF APPLICATION NAMES
For the mapping of dependent applications to the relevant master data object, the application name is
provided, which groups similar application objects. It is important to know which ILM objects of the
application are relevant for which application name to understand for which application names the (double)
maintenance of retention policies and residence policies is necessary.

3.3 PURPOSE OF APPLICATION RULE VARIANTS
Application-specific retention policies in the master data ILM objects, which are maintained only for the
application name, allow the definition of only one retention period. However, depending on the scope of the
application name and the related ILM objects, there can be a requirement to define several application
object-specific retention periods. You may also be required to maintain several retention periods for a single
application object, especially if retention periods from several countries must be considered. The application-
specific ILM objects offer several condition fields, which are not all available in the master data ILM objects.
The application rule variant is provided as an additional condition field, which serves as a mapping field to
differentiate several required retention periods of an application name.
3.4 REQUIREMENTS FOR THE EOP CHECK IMPLEMENTATION
A dependent application, which needs to support the EoP check of the CBP or customer or supplier, requires
more information to find the correct values for the SoRT information to be provided to the master data.
The tasks to be fulfilled by the EoP check implementation are the following:
1. Find existing data in your application objects with relation to a given list of master data object IDs
and collect all values of the condition fields for the related application ILM object.
2. Map the condition field values to the application rule variants, which are maintained for your
application name.
3. Call the ILM method to calculate the end of residence date for each combination of application name
and application rule variant.
4. Return new SoRT data for each combination of application name and application rule variant.
3.5 STEP 1 – COLLECT CONDITION FIELD VALUES
The registered EoP check functionality of an application is called for the given application name and a list of
master data object IDs. During the creation of the EoP check, the application objects and related ILM objects
that are in scope for the implementation and the application name must be defined. If relevant the ILM
objects to be considered can be also determined at the beginning of the EoP check using method
CL_LRM_BS_RULE_EXEC=>GET_OBJECT_TYPE_FOR_BOR_OBJ by specifying the name of the business
object repository (BOR).
Existing data for the given master data object IDs must be selected from the corresponding database tables
for these ILM objects. To consider archived application data, see the Store SoRT Information before the
Central EoP Check Run chapter.
The start of retention date as aggregated result (usually the most recent date) of all relevant application-
specific time references has to be determined. The application-specific status checks for end of business
must also be done.
If no business is found for a master data object ID, this information has to be returned for the application
name as described in step 4.
If data with ongoing business is found, it should be checked if the data should be considered in the next
steps. You do not need to check then the end of residence time for data in status End of Business.
Performance is better if only the required data is processed.

3.6 STEP 2 – MAP THE CONDITION FIELD VALUES TO THE
APPLICATION RULE VARIANTS
The task in this step is to find the application rule variant values of your application name, which are
assigned to the condition fields determined in step 1.
Note:
The simple case is a 1:1 relation between a valid ILM retention rule and existing application data and
application rule variant. In more complex cases there can be several valid application rule variants
depending on the available data and the relevant ILM retention rules. Therefore, the EoP check
implementation must consider if several application rule variants are found that are valid at the same time. If
no application rule variant can be found, the processing has to continue with the application name and an
initial application rule variant value.
A basic method to find the correct application rule variants related to the collected condition field values is to
create an application-specific mapping in Customizing. Customizing should link all possible condition fields
to an application rule variant value. This is application-specific and results in one Customizing per relevant
ILM object.
The ILM rule group concept is also available. This concept uses the valid mapping for the ILM object of an
application in transaction IRMPOL for each required or defined retention rule. These retention rules can be
linked to an ILM rule group value. You can define an ILM rule group in transaction IRM_CUST_CSS. It
stores the time period information, which must be defined for each rule. It can be used to group equal
retention periods per application.
Customizing for application rule variants offers a mapping to an ILM rule group value as a 1: n relation.
Therefore, you can find which application rule variants have to be used for the following steps of the EoP
check implementation based on the assigned ILM rule groups. The following figure shows a Customizing
example for the maintenance of application rule variants for a customer/ supplier and the assignment of ILM
rule groups.
Figure 3-1 Example of Customizing for application rule variants for a customer/ supplier and the
assignment of ILM rule groups
The details for how to implement this step using ILM rule groups is explained in the Mapping of Condition
Fields to Application Rule Variants using ILM Rule Groups chapter.
To find the assigned application rule variants for your application name depends on the master data object:
 For the CBP, you can call function module BUPA_BUTEOPARV_GET with import parameters
IV_APPL_NAME (the application name) and IT_APPL_RULE_GROUP (the determined list of ILM rule
groups).
 For the customer and/or supplier, you can call method GET_BY_RULE_GROUPS of class
CVP_CL_EOPARV. The import parameters are IV_ID_TYPE (customer, supplier or contact person),
IV_APPL_NAME (the registered application name), and IT_RULE_GROUP (the determined list of ILM
rule groups).

3.7 STEP 3 - CALCULATE THE END OF RESIDENCE DATE
The result of step 2 is a list of application rule variants that are relevant for the master object ID.
It is important to separate the list by the End of Business status. The following calculation for the end of
residence period is not required for ongoing business. The information about ongoing business has to be
returned by application name and application rule variant to the blocking report as described in step 4.
For each combination of application name and application rule variant, the end of residence date has to be
calculated using method GET_RESIDENCE_RULE_F_VALUES of class CL_LRM_BS_RST_RULE_EXEC.
For the ILM objects of the business partner master data objects, you can maintain different residence
periods. The policy type to be used is the audit area name “BUPA_DP”. This is specified in the method call
with the instance origin containing the current system ID and client. You must fill all condition values in the
source fields table. This includes the application name and application rule variant for each entity and
condition fields like the business partner type (CBP: BP_TYPE), the account group (customer/ supplier:
KTOKD), or the company code (customer/ supplier: BUKRS). The technical source field values must be
provided with the corresponding table and field name.
The condition field input values and the determined input value for the time reference parameter
START_RET_DATE (CVP_SORT-ST_RET_DATE or BUTSORT-ST_RET_DATE) must be added.
3.8 STEP 4 - RETURN NEW SORT DATA
The date value returned in the variable LV_RES_TIME_END as result of the method call in step 3 holds the
end of residence date. This date should be compared to the current date. If the end of residence date is later
than today’s date, field PURPOSE_COMPLETION_STATUS is set to 2 (Business Ongoing).If the start of
retention date is earlier than today’s date, the purpose completion status field is set to 3 (Business
Completed).
If no data was found in step 1 for a master object ID, the purpose completion status field is set to 1 (no
business with BP). This information is returned for the registered application name.
It is returned in the exporting table for the SoRT data with the master data object ID and the business system
ID for each entity of application name and application rule variant. You should set a next check date (if the
end of residence date is in the future) for ongoing business.
Otherwise, the ST_RET_DATE with the highest start of retention date that was determined in step 1 is
returned.
3.9 MAPPING OF CONDITION FIELDS TO APPLICATION RULE

VARIANTS USING ILM RULE GROUPS
The ILM framework provides the method GET_VALID_RULES of class CL_LRM_API, which can be used to
find the assigned ILM rule groups according to active retention policies of transaction IRMPOL for given
condition fields as input values. The API has to be called for each application-specific ILM object and for
each set of condition parameters.
The input parameters are the following:

 IV_OBJECT_CATEGORY set with the value OT_FOR_BS
 IV_OBJECT_TYPE set with the name of the application-specific ILM object
 IV_POLICY_CATEGORY set with the value RTP for retention policies
 IT_CONDITIONS filled with the field name and value of the current set of condition parameters. The
default condition fields CLIENT = sy-mandt and SYSTEM_ID = sy-sysid have to be added.

Export parameter ET_VALID_RULES contains information about retention rules, which match the input
parameter values. Field RULE_GROUP contains information about the assigned ILM rule group. The in each
call returned ILM rule groups are used to find the assigned application rule variants for your application
name. For more information, see step 2 above.
One restriction of method GET_VALID_RULES of class CL_LRM_API is that the technical source field values
with the table and field name for method GET_RESIDENCE_RULE_F_VALUES of class
CL_LRM_BS_RST_RULE_EXEC is not used. Instead, the logical field name of the condition field is specified.
The field value must be determined especially if the indirect value determination using method
GET_FIELDVALUES of BAdIs BADI_IRM_OT_FLD or BADI_IRM_OC_SF is used for the standard condition
field.
You can find an example program to call method GET_VALID_RULES of class CL_LRM_API in the following:
REPORT zlrm_api_test_template.
PARAMETERS:
p_oc TYPE lrm_object_category DEFAULT 'OT_FOR_BS',
p_pc TYPE lrm_policy_category DEFAULT 'RTP',
p_ot TYPE lrm_object_type DEFAULT 'FLIGHT_BOOKINGS'.
DATA:
lt_valid_rules TYPE if_lrm_types=>ty_t_rules_with_policy.
DATA:
lt_re_values TYPE if_lrm_re_exec=>ty_t_field_values,
lv_carrid TYPE s_carr_id VALUE 'AA'.
FIELD-SYMBOLS:
<lv_value> TYPE any,
<ls_re_field_value> TYPE if_lrm_re_exec=>ty_s_field_value.
DATA:
lt_conditions TYPE if_lrm_types=>ty_th_field_name_and_value,
ls_condition TYPE if_lrm_types=>ty_s_field_name_and_value.
ls_condition-v_field_name = 'CARRID'.
CREATE DATA ls_condition-r_field_value TYPE s_carr_id.
ASSIGN ls_condition-r_field_value->* TO <lv_value>.
<lv_value> = lv_carrid.
INSERT ls_condition INTO TABLE lt_conditions.
CLEAR ls_condition.
ls_condition-v_field_name = 'CLIENT'.
CREATE DATA ls_condition-r_field_value TYPE sy-mandt.
<lv_value> = sy-mandt.
CLEAR ls_condition.
ls_condition-v_field_name = 'SYSTEM_ID'.
CREATE DATA ls_condition-r_field_value TYPE sy-sysid.
<lv_value> = sy-sysid .
CLEAR ls_condition.
CALL METHOD cl_lrm_api=>get_valid_rules

EXPORTING
iv_object_category = p_oc
iv_object_type = p_ot

iv_policy_category = p_pc
it_conditions = lt_conditions
IMPORTING
et_valid_rules = lt_valid_rules.
3.10 STORE SORT INFORMATION BEFORE THE CENTRAL EOP

CHECK RUN
In step 1 of the EoP check, the existing data for the given master data object IDs is selected from the
corresponding database tables. For performance reasons, a lookup of archived application data should be
avoided, even if they also can contain SoRT information that has to be considered for the destruction of the
master data object. For this reason, we recommend storing SoRT information for relevant application data
before the central EoP check run is executed. You can implement the following options:
 Use a shadow database table to store SoRT information for the application objects and consider this
data during the EoP check (in step 1)
 Store SoRT information for the related CBP (in database table BUTSORT) or customer or supplier (in
database table CVP_SORT) for the registered application name and the corresponding application
rule variants
 Use of the archive information system with the appropriate archive information structure within the
EoP check implementation to select archived data
You can use the first or second option before or during application data archiving when the end of business
for the application data is known. This option provides performance advantages during the EoP check for the
application.
The disadvantage of the first option is that an additional database table has to be used, which aggregates
existing application data and transferred into database tables BUTSORT and CVP_SORT. A separate deletion
concept is required to delete the relevant entries after the archiving of business partner master data.
The second option requires the determination of the application rule variants based on the archived data as
described in step 2 of the EoP check. You can store the SoRT data (with completion status 3 Business
Completed and a given start of retention date) for the CBP by calling function module
BUPA_SORT_CHANGE_DETAIL and for the customer or supplier using the methods of class
CVP_CL_SORT_API. A disadvantage of this approach can be, that based on this data no reference to the
application data is possible, for which the entries have been created.
The third option requires the use of the archive information system (transaction SARI). The relevant archive
information structures must be activated and filled with data before the central EoP check is run. You must
consider the negative effect on performance during the central EoP check run.

4 EOP CHECK FOR CENTRAL BUSINESS PARTNER
DATA
The following information describes how to implement an EoP check for the central business partner (CBP).
The general logic is described in the previous section, and this section concentrates on the CBP
Customizing, interfaces, BAdIs, and supporting APIs.
4.1 REGISTRATION OF APPLICATIONS
Every consuming application of the CBP that wants to enable the CBP deletion process must register its
application name. The blocking process is based on the registered applications.
1. Run transaction SPRO and choose Cross-Application Components > Data Protection > Blocking and
Unblocking of Data > Business Partner.
2. Add the application name to Customizing for Define and Store Application Names for EoP Check:
Figure 4-1 Example of Customizing of application names for the CBP
4.2 THE END OF PURPOSE CHECK INTERFACE
The next step in the ILM-enablement of business partner depending applications is the creation of the end of
purpose check function module. Every depending CBP application must create end of purpose check
function modules for their respective application.
1. Run transaction SPRO and choose then Cross-Application Components > Data Protection > Blocking
and Unblocking of Data > Business Partner.
2. Add an entry for each function module with its corresponding application name in Customizing
activity Define Application Function Modules Registered for EoP Check:
Figure 4-2 Example of Customizing of registered function modules for the EoP check of the CBP
These function modules calculate the residence period by integrating with ILM. These application-specific
end of purpose check FMs are called by the central blocking report during the blocking process. They return
the SoRT information to the blocking report, which decides whether or not to block. The CBP depending
applications decide if there is a business purpose reason for storing business partner data. If business is
complete from the application perspective, the application returns end-of-business status and the start-of-
retention time date. The following table shows the expected signature of the end of purpose check function
module:

Parameter Type Associated Type Description
IT_PARTNERS_GUID TYPE BUP_PARTNER_GUID_T Table type with a list of

(import) (not optional) BPs, which need to be
checked for purpose
completion
TYPE BUPA_PARTNER_TYPE_T Table type for partner

IT_PARTNERS_TYPE number and partner type
(import) to provide input for end-
of-residence time
calculation
IV_APPL TYPE BU_APPL_NAME Registered application

(import) name
ET_PUR_CMPLT_PARTNERS TYPE BU_SORT_LOCAL_T Returns a table of BP

(export) (PARTNER data with purpose
PARTNER_GUID completion status and
BUSINESS_SYSTEM SoRT
APPL_NAME
APPL_RULE_VARIANT
ST_RET_DATE
NEXTCHKDT
PUR_CMPL_STATUS
STATUS)
ET_MESSAGES TYPE BUSLOCALMSG_T Message table

(export) (local partner ID, local partner
GUID, application name, and fields
of structure BAPIRET2)
The end of purpose signature has two import parameters: IT_PARTNERS_GUID and IV_APPL. The
blocking report uses the IT_PARTNERS_GUID parameter to pass the list of business partners to be checked
with a partner ID and partner GUID. The applications can use either of these unique identifiers. Using the
IV_APPL parameter, the application name is passed to the end of purpose check module and is used in the
end of purpose check module logic.
The end of purpose signature has one export parameter: ET_PUR_CMPLT_PARTNERS. The blocking report
stores the returned data in central table BUTSORT for each business partner to be checked. The following
fields are included:
 BUSINESS_SYSTEM is the system where the end of purpose module has been executed for
residence rule calculation, which is important in the remote run of the blocking report where the
same partner’s end of purpose must be calculated in a distributed environment. The logical name of
the local system is returned, which can be determined as follows:
DATA: l_own_logical_system type logsys,
call function 'OWN_LOGICAL_SYSTEM_GET'
importing
own_logical_system = l_own_logical_system
exceptions
own_logical_system_not_defined = 1
others = 2.
if sy-subrc <> 0.
l_own_logical_system = sy-sysid.
endif.

 APPLICATION_NAME is required for the partner consumption information for each application.
Import parameter IV_APPL provides the application name for which the registered function module
was called.
If there are many sub-applications for which the end of purpose must be calculated, the applications
can use the application rule variant concept to get more granularities. For example, if there are
application rule variants for an application, the SoRT information is needed for each rule variant of
that application that is relevant based on Customizing for a checked business partner.
 The purpose completion code is returned in field PUR_CMPL_STATUS. The application must fill the
purpose completion code with one of the following options:
o 1 = n/a (no business with BP)
o 2 = no (business is ongoing with BP)
o 3 = yes (business is complete with BP and residence time is over)
 If the residence date is met during the calculation by ILM, the START_OF_RETENTION date must be
filled and returned to the blocking report r with PUR_CMPL_STATUS = 3 (business is complete with
BP and residence time is over).
 NEXTCHKDT – Next Check Date is used for optimization. For example, 1000 partners are checked
for end of purpose and only 500 partners have reached end of purpose successfully. The remaining
500 partners state that there are open business transactions being run by the consuming
applications. Applications that return a status of Business Ongoing in the structure field
PUR_CMPL_STATUS for these partners must send a date later than the current date, which is the
next end of purpose check date for this partner.
If no Next Check Date value is returned, the central blocking report defaults the next check date
based on central Customizing and the following logic:
If the next check date is not returned, the report reads the value maintained in table BUTNXTCHK. In
Customizing, you can maintain a value for a time period, which is used to determine the default next
check date after the current date. The calculated next check date is stored in the SoRT data
returned by the corresponding application. If the application returns a check date that is later than
the calculated default next check date due to Customizing, the check date set by the application is
overwritten with the calculated default next check date. This avoids long periods between the next
end of purpose check for the corresponding business partner.
 STATUS field in structure BU_SORT_LOCAL should not be filled by the application-specific end of
purpose check modules. It is filled by the central blocking report.
4.3 THE UNBLOCKING CHECK INTERFACE
You can request the unblocking of a central business partner (CBP) with transaction BUP_REQ_UNBLK. If the
unblocking request is approved in transaction BUPA_PRE_EOP, an additional consistency check by
dependent applications is possible. Every consuming application of the CBP can create an unblocking check
function module for their respective application.
1. To register these function modules in Customizing, run transaction SPRO and choose Cross-
Application Components > Data Protection > Blocking and Unblocking of Data > Business Partner.
2. In Customizing activity Define Registered Function Modules for Unblock BP, add an entry for each
function module with its corresponding application name.
Figure 4-3 Example of Customizing of function modules registered for unblocking check of the CBP

The application-specific unblocking check FMs are called sequentially after the approval of an unblocking
request and before the blocking information of a business partner is removed from the database. They return
an unblocking status for each business partner, which is verified before the unblocking process continues.
The following table lists the expected signature of the unblocking check function module from the consuming
applications:
IT_PARTNERS_GUID TYPE BUP_PARTNER_GUID_T

(import) (mandatory) Table type with a
list of BPs, which
should be checked
for unblocking
IV_APPL TYPE BU_APPL_NAME

(import) BP-consuming
application
ET_UNBLK_STATUS TYPE BUPARTNER_UNBLK_STATUSREMOTE_T

(export) Returns a table of
BP data with the
unblocking check
result
ET_MESSAGES TYPE BUSLOCALMSG_T

(export) (local partner ID, local partner GUID, Message table
application name, and fields of structure
BAPIRET2)
The unblocking check signature has two import parameters: IT_PARTNERS_GUID and IV_APPL. The
unblocking report uses the IT_PARTNERS_GUID parameter to pass the list of business partners to be
checked by partner ID and partner GUID. The applications can use either of these unique identifiers. The
IV_APPL parameter passes the application name to the unblocking check module as optional information.
The end of purpose signature has one export parameter: ET_UNBLK_STATUS. For each business partner for
which unblocking is allowed, the unblocking report expects the business partner key information in the
PARTNER field and the value X in the UNBLK_STATUS field to allow unblocking.
4.4 ENTERPRISE SERVICE METHODS
To integrate external applications and systems (non-ABAP systems) into the blocking and unblocking
reports, the following Web services are provided:
 A service is called in the blocking report during the following:
o During the EoP check to collect EoP results from registered service providers
o After blocking a business partner to notify registered service providers about a successful
blocking
o During the execution of the blocking report in a dependent system with interim mode to
notify a registered service provider (leading system) with the interim EoP check results
 A service is called in the unblocking report during the following:
o During the unblocking check to report permission from registered service providers
o After unblocking a business partner to notify registered service providers about a successful
unblock

The blocking and unblocking functions of the central business partner (CBP) provide the following service
methods in the namespace http://sap.com/xi/ABA:
Service Consumer Service Provider Purpose
ABABusinessPartnerEOPRemoteOut ABABusinessPartnerEOPRemoteIn Integrate the EoP
check with
dependent
systems
ABABusinessPartnerEOPInterimOut ABABusinessPartnerEOPInterimIn Notify the master
system about
local EoP check
interim results
from a dependent
system
ABABusinessPartnerEOPComplout ABABusinessPartnerEOPComplIn Notify dependent
systems about
blocked business
partners with
corresponding
SoRT information
ABABusinessPartnerEOPUnblkOut ABABusinessPartnerEOPUnblkIn Integrate the
unblocking check
with dependent
systems
ABABusinessPartnerEOPResetOut ABABusinessPartnerEOPResetIn Notify dependent
systems about
unblocked
business partners
If the corresponding service configuration is available, all registered service providers are executed in the
receiving systems. The listed service providers can be used in ABAP-based systems (starting with SAP
NetWeaver 7.40) for the integration of the blocking and unblocking functions between business partners
stored in master and dependent systems. Other systems can create service providers in their own
namespace with the same interface as the service consumers. Therefore, you can implement the integration
for the CBP EoP check function with non-ABAP systems. For the integration of external systems, the
following use cases must be supported:
 The blocking report was started in the leading system to collect EoP information from dependent
systems and notify after successful blocking
 The interim mode of the blocking report that is called in a dependent system to notify the master
system about the recent EoP information
 The unblocking report that is used to unblock requested business partners.
The unblocking report can be started in the leading system. During unblocking, a service calls
the connected system to verify if the unblocking is allowed and another service is called after a
successful unblocking in the master system.
4.4.1 END OF PURPOSE CHECK FOR CENTRAL BUSINESS

PARTNERS
The enterprise service for the end of purpose (EoP) check is a synchronous query response service for the
central business partner (CBP).
The query sends the business partner ID and GUID (PARTNER and PARTNER_GUID) in table element
PartnerRemote and the business partner type (PARTNER_TYPE) and mapping information about the
correct business partner ID in a target system as set in a possible implementation of BAdI
BUP_PARTNER_KEYMAP (TARGET_SYSTEM, RECEIVER_PARTNER, RECEIVER_PARTNER_GUID).
The query contains the following elements to determine the processing conditions:

Parameter Description
CHECK_ALL_APP The value is X, when despite ongoing processes, all other

registered EoP checks have to be executed in the called
system
TESTRUN The value is X when called in test mode
The response expects to receive a set of EoP results for each level of data. The EoP results are returned in
table element BusinessPartnerRemote. The contained elements are the same as the export parameter
ET_PUR_CMPLT_PARTNERS in the end of purpose check interface as previously described.
There is also a log table (BusinessPartnerRemoteMsg) that returns messages.
4.4.2 BLOCK NOTIFICATION FOR CENTRAL BUSINESS

PARTNERS
At the end of the blocking run, a notification is sent out to all registered service providers of blocked data.
The message contains table element Partnercomplete, which contains collected SoRT information for
the new blocked business partners. The contained elements are the similar to the export parameter
ET_PUR_CMPLT_PARTNERS of the end of purpose check interface as previously described.
4.4.3 INTERIM CHECK RESULTS NOTIFICATION FOR CENTRAL

BUSINESS PARTNERS
Each connected (registered) dependent system is allowed to proactively provide SoRT information to the
master system. The interim results must be provided in the same structure as the response of the EoP
check; however, there is no log information. The message contains table element Partnercomplete,
which includes all collected SoRT information. The contained elements are the same as the export
parameter ET_PUR_CMPLT_PARTNERS of the end of purpose check interface as previously described.
The master system takes over the role of service provider.
4.4.4 UNBLOCK CHECK FOR CENTRAL BUSINESS PARTNERS
The unblocking check service is a query response service. The service is called for the central business
partner (CBP) for dependent systems to confirm that unblocking the business partner is allowed.
The query sends the business partner ID and GUID (PARTNER and PARTNER_GUID), the business partner
type (PARTNER_TYPE), and mapping information about the correct business partner ID from table element
IT_PARTNERS to a target system based on a possible implementation of BAdI BUP_PARTNER_KEYMAP
(TARGET_SYSTEM, RECEIVER_PARTNER, RECEIVER_PARTNER_GUID).
When permission to unblock is granted for each business partner, the response expects to receive the value
X in table element ET_UNBLK_STATUS in element UNBLK_STATUS,.
Log table element ET_MESSAGES records return messages.

4.4.5 UNBLOCK NOTIFICATION FOR CENTRAL BUSINESS
PARTNERS
At the end of the unblocking run, a notification is sent out to all registered service providers of all unblocked
data. The message includes table element PartnerReset, which contains information for the unblocked
business partners in elements PARTNER and PARTNER_GUID.
4.5 BUSINESS ADD-INS (BADIS)
4.5.1 BUSINESS PARTNER KEY MAPPING
The Business Add-In (BAdI) BUP_PARTNER_KEYMAP is used to find out the business partner ID and GUID of
the target system. This BAdI is called before the remote function call (RFC) or Web service call to registered
dependent systems is called for the following:
 EoP check before blocking
 Check before unblocking
 Unblocking notification
The BAdI includes the method GET_PARTNER_ID.
CT_KEYMAP Changing BUKMAP_T Table for

business
partner key
mapping
When the business partner GUID is not unique for business partners in the same landscape, you can
enhance the changing parameter CT_KEYMAP with an additional entry for each target system. The
information about the business partner ID in the local system is provided in the components PARTNER and
PARTNER_GUID. You can add information about the target system in components RECEIVER_PARTNER
and RECEIVER_PARTNER_GUID with the corresponding name of the target system in component
TARGET_SYSTEM.
4.5.2 RESTRICTION OF BUSINESS PARTNER FROM EOP CHECK
The Business Add-In (BAdI) BUP_PARTNER_EXLIST is used to restrict business partners from going
through the EoP check. The restriction is carried out when the blocking report removes the partners from the
list that is included in the check. The BAdI is used as an optimization measure.

The BAdI includes the method PARTNER_EXCLIST.
Import Variant
IV_FLT_VAL BUS_DA_SELECT_VARIANT BAdI filter for
selection of
data
IV_DIFFERENTIATION Import CHAR20
CT_PARTNER_EXCLIST Changing BU_PARTNER_T Table of

business
partner
numbers
Import parameters IV_FLT_VAL and IV_DIFFERENTIATION provide filter information from the selection
screen of blocking report BUPA_PREPARE_EOP to implement the BAdI accordingly to these values and to
exclude certain business partners. The changing parameter CT_PARTNER_EXCLIST contains the list of
business partner IDs based on the selection criteria from blocking report BUPA_PREPARE_EOP.
4.5.3 EXPORT SORT DETAILS OF BLOCKED OR UNBLOCKED

BUSINESS PARTNERS
The Business Add-In (BAdI) BUPA_PURPOSE_EXPORT is used to export SoRT details of a blocked or
unblocked business partner to application-specific memory. The BAdI is called when the blocking indicator
(field XPCPT in database table BUT000) is set or reset. The BAdI is not called for a partner when business is
ongoing.
BAdI method BUPA_PURCOMPL_EXPORT is called in the blocking report and the RFC function module
BUPA_PURPOSE_COMPLETE to replicate the unblocking information to registered dependent systems. A
dependent application can use the method to set additional blocking indicators, which should be set in
addition to the blocking indicator of the business partner.
Import UTC time

IV_TIMESTAMP_BUS TIMESTAMP stamp
IV_CHECKMODE Import BOOLE_D
IT_BUTSORT Import BU_BUTSORT_T Table type for

BUTSORT
CT_RETURN Changing BUS_BAPIRET2_T Business

partner: table
type for
BAPIRET2
Import parameter IV_TIMESTAMP_BUS is set with the current UTC time stamp. If the external data or
memory handling in Financial Services is active, import parameter IV_CHECKMODE has a value of X.. The
parameter is only relevant for the delivered implementation of this application. Import parameter
IT_BUTSORT contains all SoRT information for business partners for which the blocking indicator is set.

Changing parameter CT_RETURN provides an option to report errors that occur during the execution of the
BAdI implementation.
The BAdI method BUPA_PURERESET_EXPORT is called in the unblocking report and the RFC function
module BUPA_PURPOSE_RESET to replicate the unblocking information to registered dependent systems. A
dependent application can use the method to reset additional blocking indicators, which were set in addition
to the blocking indicator of the business partner.
Import UTC time

IV_TIMESTAMP_BUS TIMESTAMP stamp
IV_CHECKMODE Import BOOLE_D
IT_PARTNERS Import BU_PARTNER_T Table of

unblocked
business
partners
CT_RETURN Changing BUS_BAPIRET2_T Business

partner: table
type for
BAPIRET2
Import parameters IV_TIMESTAMP_BUS and IV_CHECKMODE and changing parameter CT_RETURN have
the same use as in BAdI method BUPA_PURCOMPL_EXPORT. Import parameter IT_PARTNERS contains the
list of partners for which the blocking indicator is reset.
4.6 ADAPTION BY DEPENDENT APPLICATIONS
A blocked business partner should not be changed or displayed by an unauthorized user. Authorized users
can display the details of a blocked business partner but should not be able to change the partner details.
Internal change and read function modules of the central business partner, which are consumed by the
dependent applications, are enhanced with the optional import parameter IV_REQ_BLK_MSG. If consuming
applications want to receive an error message or exception during unauthorized access to the blocked
business partner, you must set this parameter value to X while calling the central business partner function
modules. If the parameter is not set and the partner status is blocked, no message and no data are returned.
The central business partner (CBP) function modules (FM) do not return the error message or an exception
blindly due to possible disruptions in the consuming applications flow. The consuming applications are
requested to adapt their calls to the CBP modules so that the necessary calls to the CBP modules are
executed when necessary by setting optional parameter IV_REQ_BLK_MSG to X and handling the error
message or exception.
Some examples of these function modules are as follows:

 BUA_ADDRESS_DESCRIPTION_GET
 BUA_ADDRESS_GET
 BUA_ADDRESS_GET_ALL
 BUA_ADDRESS_READ
 BUA_ADDRESS_READ_ALL
 BUP_BANK_DESCRIPTION_GET
 BUP_BANK_GET
 BUP_BANK_GET_ALL

 BUP_CCARD_DESCRIPTION_GET
 BUP_CCARD_GET
 BUP_CCARD_GET_ALL
 BUP_PARTNER_DESCRIPTION_GET
 BUP_PARTNER_F4_INT_TABLE
 BUP_PARTNER_GET
 BUP_PARTNER_ROLES_GET
In difference to this are the changes to function modules, which are used for example within the BAPI
methods of the following business objects:
 BUS1006 Business partner
 BUS1006001 Business partner employee
 BUS1006002 Business partner contact person relationship
 BUS1006003 Business partner employee relationship
 BUS1006004 Business partner group hierarchy
 BUS1006006 Business partner shareholder relationship
These function modules have also been authorization enabled to check for the unauthorized access to a
blocked business partner. But the difference is that there is no new import parameter IV_REQ_BLK_MSG.
Instead for a blocked business partner an error message appears in the Return table, which refers to the
structure BAPIRET2.
Examples of these function modules are the following:

 BUPA_ADDRESSES_GET
 BUPA_ADDRESS_ADD
 BUPA_BANKDETAILS_GET
 BUPA_BANKDETAIL_ADD
 BUPA_CENTRAL_CHANGE
 BUPA_CENTRAL_GET_DETAIL
 BUPA_DESCRIPTION_GET
 BUPA_EXISTENCE_CHECK
 BUPA_IDENTIFICATIONDETAILS_GET
 BUPA_IDENTIFICATION_ADD
 BUPA_NUMBERS_GET
 BUPA_PARTNER_GET_BY_IDNUMBER
 BUPA_PCARD_ADD
 BUPA_PCARD_GETDETAIL
 BUPA_RELATIONSHIPS_GET
 BUPA_ROLES_GET
 BUPA_ROLE_EXISTENCE_CHECK_2
 BUPA_SEARCH

5 EOP CHECK FOR CUSTOMERS AND SUPPLIERS
The following sections describe how to implement an end of purpose (EoP) check for customers and
suppliers. The general logic is described in the How-To of an EoP Check Implementation section.. This
section describes customer and supplier customizing, interfaces, BAdIs, and supporting APIs.
5.1 REGISTRATION OF APPLICATIONS
Every consuming application of the customer and supplier that wants to enable ILM for the business partner
deletion process must first register its application name. The blocking process is based on the registered
applications.
1. For the registration, run transaction CVP_CUST or SPRO and choose Logistics - General > Business
Partner > Deletion of Customer and Supplier Master Data.
2. In Customizing activity Define and Store Application Names for EoP Check, add the application
name.
Make sure to add an entry for each ID type.
Figure 5-1 Example of Customizing for application names of customers and suppliers
5.2 THE END OF PURPOSE CHECK INTERFACE
The customer and supplier blocking functionality enables registered applications to execute different actions
during the end of purpose (EoP) check during the unblocking process of customers or supplier s. The
CVP_IF_APPL_EOP_CHECK class interface is delivered for this purpose. Each application must develop a
class to implement this interface and must register the class in Customizing.
1. Run transaction CVP_CUST or SPRO and choose Logistics - General > Business Partner > Deletion
of Customer and Supplier Master Data.
2. In Customizing activity Define Application Classes Registered for EoP Check, add the application
class name.
Make sure you add an entry for the previously defined application name and each ID type. Select the
organizational level (General or Company Code) for which the EoP check can be done in the
application.

Figure 5-1 Example of Customizing for application classes registered for EoP check for cvi
customers and suppliers
5.2.1 INTERFACE METHODS
Interface CVP_IF_APPL_EOP_CHECK defines several instance methods. The instantiation of the

implementation class is done at the start of the EoP check. The same instance is used until the end of the
process; therefore, applications can rely on their instance data (buffering).
The interface methods used in the end of purpose check are the following:
Method Name Level Description
INITIALIZE Instance Initialize EoP check to get execution parameters

method
CHECK_PARTNERS Instance EoP check partner

method
CHECK_CPD_PARTNERS Instance EoP check one-time account partner

method
PARTNERS_PURCMPL_EXPORT Instance Store application-specific blocking information

method
FINALIZE Instance Finalize EoP check for cleanup and dequeue

method handling

5.2.2 INTERFACE ATTRIBUTES
Interface CVP_IF_APPL_EOP_CHECK provides constant attributes to avoid problems from wrong hardcoded
values. Some examples of these attributes are the following:
Attribute Type Description
GC_TYPE_CUSTOMER CVP_ID_TYPE Customer type
GC_TYPE_VENDOR CVP_ID_TYPE Supplier type
GC_TYPE_CONTACT CVP_ID_TYPE Contact person type
GC_CPD_TYPE_CUSTOMER CVP_ID_TYPE_CUSTVEND One-time account customer type
GC_CPD_TYPE_VENDOR CVP_ID_TYPE_CUSTVEND One-time account supplier type
GC_PUR_COMPL_NA CVP_PUR_COMPL_STATUS Not applicable; no business with partner
GC_PUR_COMPL_NO CVP_PUR_COMPL_STATUS No; business is ongoing with partner
GC_PUR_COMPL_YES CVP_PUR_COMPL_STATUS Yes; business is complete with partner and

residence time is over
5.2.3 INITIALIZE AND FINALIZE METHODS
INITIALIZE Method
Registered applications may need to be initialized and know the current parameters of the blocking report.
The INITIALIZE method is called after instantiation of the registered application class.
Import Application
IV_APPL CVP_APPL_NAME name
IV_EOP_RUN_MODE Import CVP_EOP_RUN_MODE Execution

mode for
EoP check
IV_TEST_MODE Import CVP_TEST_MODE Test mode
IV_VALIDATE_NXTCHK_DATE Import CVP_VALIDATE_NXTCHK_DATE Validate next

check date
during EoP
check

IV_CHECK_PUR_COMPL_STATUS Import CVP_CHECK_PUR_COMPL_STATUS Check for
purpose
completion
status
IV_PROT_OUTPUT Import CVP_PROT_OUTPUT EoP check

output of
object logs
IV_DETAIL_LOG Import CVP_DETAIL_LOG EoP check:

detail log
FINALIZE Method
Registered application classes may need to perform some cleanup and dequeue activities. The FINALIZE
method is called before destructing the class instance.
It provides the tables, which are used during the calling of EoP methods CHECK_PARTNERS and
CHECK_CPD_PARTNERS
Parameter Type Associated Type Descriptio

n
IT_EOP_CHECK_PARTNERS Import CVP_TT_EOP_CHECK_PARTNERS Master data

IDs for
blocking
IT_EOP_CHECK_PARTNERS_CPD Import CVP_TT_EOP_CHECK_PARTNERS_CPD Master data

IDs one-
time
account for
blocking
5.2.4 EOP CHECK METHOD CHECK_PARTNERS
The system informs applications about the partners to be checked for end of purpose in the entries in the
IT_EOP_CHECK_PARTNERS import parameter. In export parameter ET_SORT_RESULT_PARTNERS,
applications return their check results. Errors and information messages are returned in table
ET_MESSAGES.
Import Application
Import Master data

IT_EOP_CHECK_PARTNERS CVP_TT_EOP_CHECK_PARTNERS IDs for
blocking

Export SoRT
ET_SORT_RESULT_PARTNERS CVP_TT_SORT_RESULT information
after EoP
check
Export Result log

ET_MESSAGES CVP_TT_EOP_CHECK_MESSAGES messages
after EoP
check
Import parameter IV_APPL contains the registered application name based on Customizing settings. It is
required for checks and to enable reuse of the implementation for other applications names too.
Import parameter IT_EOP_CHECK_PARTNERS contains a list of customer, supplier, and contact person IDs
for which the EoP check must be executed. The partner entries are differentiated by the value in the
ID_TYPE (1 = customer master data, 2 = supplier master data, 3 = contact person) field. The BUKRS field
contains the company code for which a selected customer or supplier is to be checked for the EoP for
application data related to this company code. The VKORG field is not used and has a value of initial. The
ACCOUNT_GROUP field contains the account group for which the customer or supplier is created and is
required as the input value for the end of residence period calculation during the EoP check.
Entries in the IT_EOP_CHECK_PARTNERS import parameter depend on the execution mode of the
CVP_PREPARE_EOP blocking report. You can run the report for customers or suppliers but not for both at the
same time. The import parameter contains entries for either customers or suppliers and their related contact
persons. Further entries depend on the Data to be processed selection parameter. You can select the data
to be processed based on the following:
 Process all data levels
The blocking report selects data for customers or suppliers on the general level (corresponding to
database table KNA1/LFA1 and existing contact persons (KNVK).
 Process only company code specific data
The blocking report selects data for customers or suppliers at the company code level (KNB1/LFB1).
 Process only contact persons
The blocking report selects data for contact persons of customers or suppliers (KNVK).
Entries in the IT_EOP_CHECK_PARTNERS import parameter depend on the registration of the EoP check
class for the application name in Customizing. It is based on the ID type and organizational levels (general
and company code).
The end of purpose signature has one export parameter: ET_PUR_CMPLT_PARTNERS. The blocking report
stores to the returned data in the CVP_SORT central table for each entry in IT_EOP_CHECK_PARTNERS
import parameter based on the ID, ID_TYPE, and BUKRS key information fields. Other field types are
described as follows:
 BUSINESS_SYSTEM is the system where the end of purpose check has been executed for residence
rule calculation. It is used in the remote run of the blocking report where the same partner’s end of
purpose must be calculated in a distributed environment. The logical name of the local system is
returned, which can be determined as follows:
DATA: l_own_logical_system type logsys,
call function 'OWN_LOGICAL_SYSTEM_GET'
importing
own_logical_system = l_own_logical_system
exceptions
own_logical_system_not_defined = 1
others = 2.
if sy-subrc <> 0.
l_own_logical_system = sy-sysid.
endif.

 APPLICATION_NAME is used to find the partner consumption information for each application. The
IV_APPL import parameter provides the application name for which the registered function module
was called.
If there are many sub applications for which the end of purpose must be calculated, the applications
can use the application rule variant for more granularity. For example, if there are application rule
variants for an application, the SoRT information is required for each rule variant of that application
that is relevant based on Customizing for a checked business partner.
 The purpose completion code should be returned in the PUR_CMPL_STATUS field. The application
must fill the purpose completion code with one of the following values:
o 1 = N/A (no business with BP
o 2 = no (business with BP is ongoing)
o 3 = yes (business with BP is complete and residence time is over)
 If the residence date is reached during the calculation by ILM, the ST_RET_DATE in date format
must be filled and returned to the blocking report with PUR_CMPL_STATUS = 3 (business with BP is
complete and residence time is over).
 NEXTCHKDT – Next Check Date is used for optimization. For example, 1000 partners are checked
for end of purpose and only 500 partners have reached end of purpose successfully. The remaining
500 partners state that there are open business transactions being run by the consuming
applications. Applications that return a status of Business Ongoing in the structure field
PUR_CMPL_STATUS for these partners must send a date later than the current date, which is the
next end of purpose check date for this partner.
If no Next Check Date value is returned, the central blocking report defaults the next check date
based on central Customizing and the following logic:
If the next check date is not returned, the report reads the value maintained in the CVP_NXTCHK
table. In Customizing, you can maintain a value for a time period, which is used to determine the
default next check date after the current date. The calculated next check date is stored in the SoRT
data returned by the corresponding application. If the application returns a check date that is later
than the calculated default next check date due to Customizing, the check date set by the application
is overwritten with the calculated default next check date. This avoids long periods between the next
end of purpose check for the corresponding business partner.
5.2.5 BLOCKING METHOD PARTNERS_PURCMPL_EXPORT
After the EoP check is run, the calling report may block some data. This method provides the list of data that
will be blocked in the IT_EOP_PARTNER_PURCMPL_EXP parameter to the registered applications.
Applications can use this data to set further application-specific blocking indicators. Errors that occur during
updates in the application are returned in table ET_MESSAGES.
Parameters Type Associated Type Description
IT_EOP_PARTNER_PURCMPL_EX Import CVP_TT_EOP_PARTNER_PURCMPL_ Master data

P EXP IDs for
blocking
export
interface
ET_MESSAGES Export CVP_TT_EOP_CHECK_MESSAGES Result log

messages
after EoP
check

5.2.6 BLOCKING PROCESS FLOW
The following process flow describes how the blocking report runs and at which time and for which purpose
calls to registered applications are done.
Blocking Report starts
Loop for all registered applications
Method INITIALIZE
Provides info about the parameters of the blocking report. Applications can implement their
own initialization.
Endloop
Method CHECK_PARTNERS
Application to perform EoP checks for normal customer and suppliers
Method CHECK_CPD_PARTNERS
Application to perform EoP checks for one-time customer and suppliers
Endloop
Method PARTNERS_PURCMPL_EXPORT
Provides information to application about partners to be blocked
Endloop
Method FINALIZE
Application to release their own objects (enqueue, memory)
Endloop
Blocking report ends
5.3 THE UNBLOCKING CHECK INTERFACE
Customer and supplier blocking also supports the unblocking of partners. Applications may need to run a
consistency check before unblocking is allowed or unblock some of their blocked data with unblocked
partners. Several interface methods in the CVP_IF_APPL_EOP_CHECK interface are available for this
unblocking process:
Method Name Level Description
Initialize unblocking to get execution

INITIALIZE_UNBLOCK Instance parameters
method
Prepare unblock partners: applications

PARTNERS_PREP_PURCMPL_RESET Instance confirm
method
Unblock partners: applications get informed

PARTNERS_PURCMPL_RESET Instance
method
Finalize unblocking for cleanup and dequeue

FINALIZE_UNBLOCK Instance handling
method

5.3.1 INITIALIZE AND FINALIZE METHODS FOR UNBLOCKING
INITIALIZE_UNBLOCK
Registered applications may need to perform some initialization and need to know what the current
parameters of the unblocking report are. This method will be called after instantiation of the registered
application class.
Import Application
IV_PROCESS_DIRECTION Import CVP_SPECIFIC_PROCESS_DIRECTIO Specific

N process
direction
IV_PROT_OUTPUT Import CVP_PROT_OUTPUT EoP check:

output of
object logs
IV_DETAIL_LOG Import CVP_DETAIL_LOG EoP check:

detail log
FINALIZE_UNBLOCK
Registered application classes may need to perform some cleanup and dequeue activities. This method is
called before destructing the class instance.
IT_PARTNERS Import CVP_TT_EOP_PARTNER_PURCMPL_EXP Unblocked partners
5.3.2 UNBLOCKING METHODS
PARTNERS_PREP_PURCMPL_RESET
This is the preparation method. Applications are informed about the partners that are requested to be
unblocked. Applications may refuse to unblock a partner by adding corresponding entries returned in table
ET_PARTNERS. The reason and explanation are written to the ET_MESSAGES table.
IT_PARTNERS Import CVP_TT_EOP_PARTNER_PURCMPL_EXP Partners to be

unblocked

ET_PARTNERS Export CVP_TT_UNBLOCK_STATUS Partners status
for unblocking
ET_MESSAGES Export CVP_TT_EOP_CHECK_MESSAGES Result log

messages
after unblocking
preparation
PARTNERS_PURPCMPL_RESET
This method provides information to applications about the partners to be unblocked in table IT_PARTNERS.
Errors that occur during updates in the application are returned in table ET_MESSAGES.
IT_PARTNERS Import CVP_TT_EOP_PARTNER_PURCMPL_EXP Partners to be unblocked
ET_MESSAGES Export CVP_TT_EOP_CHECK_MESSAGES Result log messages after EoP

check
5.3.3 UNBLOCKING PROCESS FLOW
The following process flow describes how the unblocking report runs and how it calls registered applications.
Unblocking report starts
Method INITIALIZE_UNBLOCKED: Provides info about the parameters of the unblocking
report. Applications can implement their own initialization.
Endloop
Method PARTNERS_PREP_PURPCMPL_RESET: Application checks if partners can be unblocked.
Endloop
Method PARTNERS_PURCMPL_RESET: Provides information to application about
partners to be unblocked
Endloop
Method FINALIZE_UNBLOCK: Application to release objects (enqueue, memory )
Endloop
Unblocking report ends

5.4 SPECIAL SCENARIO: ONE-TIME ACCOUNTS
Some account groups are one-time accounts (CPD functionality). These are accounts that have a business
transaction with you only once or rarely. One-time accounts require no master records because you do not
need this master record after the business transaction. You create collective master records for one-time
customers and one-time suppliers where certain data (such as address and bank details) is not entered in
the master record but in the actual document.
Example
You create a collective master record for a dummy customer that includes data for all customers in a certain
region. This collective master record can include the following fields: master record name, language,
currency, and sales office processing the data.
If a one-time customer from this region orders goods from your company, you use the customer number of
the collective master record when processing the sales order. You enter the address and other data that is
not in the collective master record in the sales order.
Consequences of the EoP Check

The EoP check and the blocking of an application object created for a one-time-account is triggered by the
central blocking report. This provides a central entry point to block these application objects (the template
master data cannot be blocked). You do not have to use residence rules that are different from a normal
customer or supplier.
Each application object must block its own data at the end of its residence period. Therefore, you cannot
indicate the blocking status with the master data. Instead, each application must introduce its own blocking
indicator, which is set in the central blocking report. You can set this in the application-specific EoP check
(but not in active test mode). A differentiation between overall or interim check modes does not apply since
the data is blocked locally.
5.4.1 EOP CHECK METHOD CHECK_CPD_PARTNERS
This end-of-purpose check method is called for master records that are selected as one-time accounts.
Applications are given the partners for the end-of-purpose check in table IT_EOP_CHECK_PARTNERS_CPD.
Errors and success messages are returned in table ET_MESSAGES.
IV_APPL Import CVP_APPL_NAME Application

name
IT_EOP_CHECK_PARTNERS_CPD Import CVP_TT_EOP_CHECK_PARTNER Master data

S IDs for
blocking
ET_MESSAGES Export CVP_TT_EOP_CHECK_MESSAGE Result log

S messages
after EoP
check

5.5 ENTERPRISE SERVICE METHODS
To integrate external applications and non-ABAP systems into the blocking and unblocking reports, the
following enterprise services are provided:
 Services are called in the blocking report during the following:
o During the EoP check to collect EoP results from registered service providers
o After blocking a business partner to notify registered service providers about a successful
blocking
o During the execution of the blocking report in a dependent system with interim mode to
notify a registered service provider (leading system) with the interim EoP check results
o A service is called in the unblocking report during the following:
o During the unblocking check to report permission from registered service providers
o After unblocking a business partner to notify registered service providers about a successful
unblock
The blocking and unblocking functionality of the customer provides the following service methods in the
http://sap.com/xi/APPL/Global2 namespace:
CustomerERPEndOfPurposeChe CustomerERPEndOfPurposeCh Integration of the EoP check
ckQueryResponse_Out eckQueryResponse_In with dependent systems
CustomerERPEndOfPurposeInt CustomerERPEndOfPurposeIn Notify master system about
erimCheckNotification_Out terimCheckNotification_In local EoP check interim results
from a dependent system
CustomerERPEndOfPurposeBlo CustomerERPEndOfPurposeBl Notify dependent systems
ckNotification_Out ockNotification_In about blocked customers with
corresponding SoRT
information
CustomerERPEndOfPurposeUnb CustomerERPEndOfPurposeUn Integration of the unblocking
lockCheckQueryResponse_Out blockCheckQueryResponse_I check with dependent systems
n
CustomerERPEndOfPurposeUnb CustomerERPEndOfPurposeUn Notify dependent systems
lockNotification_Out blockNotification_In about unblocked customers
The blocking and unblocking functionality of the supplier (vendor) provides the following service methods in
the http://sap.com/xi/APPL/Global2 namespace:
SupplierERPEndOfPurposeChe SupplierERPEndOfPurposeCh Integration of the EoP check
ckQueryResponse_Out eckQueryResponse_In with dependent systems
SupplierERPEndOfPurposeInt SupplierERPEndOfPurposeIn Notify master system about
erimCheckNotification_Out terimCheckNotification_In local EoP check interim results
from a dependent system
SupplierERPEndOfPurposeBlo SupplierERPEndOfPurposeBl Notify dependent systems
ckNotification_Out ockNotification_In about blocked suppliers with
corresponding SoRT
information
SupplierERPEndOfPurposeUnb SupplierERPEndOfPurposeUn Integration of the unblocking
lockCheckQueryResponse_Out blockCheckQueryResponse_I check with dependent systems
n
SupplierERPEndOfPurposeUnb SupplierERPEndOfPurposeUn Notify dependent systems
lockNotification_Out blockNotification_In about unblocked suppliers
The blocking and unblocking functionality of the customer and supplier uses the listed service consumer
methods. If the corresponding service configuration is available, registered service providers are executed in
the receiving systems. You can use the above service providers in ABAP-based systems (starting with SAP
ERP 6.0 EhP7 SP06) for the integration of the blocking and unblocking functionality between customers and
suppliers stored in master and dependent systems. Systems can create service providers in their own
namespace with the same interface as the service consumers. Therefore, you can also implement the

integration of the customer and supplier EoP check functionality with non-ABAP systems. For the integration
of external systems, the following use cases must be supported:
 The blocking report was started in the leading system to collect EoP information from dependent
systems and notify after successful blocking
 The interim mode of the blocking report that is called in a dependent system to notify the master
system about the recent EoP information
 The unblocking report that is used to unblock requested business partners.
The unblocking report can be started in the leading system. During unblocking, a service calls
the connected system to verify if the unblocking is allowed and another service is called after a
successful unblocking in the master system.
5.5.1 END OF PURPOSE CHECK FOR CUSTOMER AND

SUPPLIER (VENDOR)
The enterprise service for the end of purpose (EoP) check is a synchronous query-response service
supporting customer and supplier-integrated into the customer and supplier business object.
The query part sends the customer and supplier (InternalID) on the general level with an indicator
(CheckCustomerIndicator; CheckSupplierIndicator) noting if a check on general level is
requested. The company code (ID) information and relationship, which contains the contact person
(InternalID; ContactPersonInternalID) information to be checked, is available one level down.
The query part contains a processing condition segment (ProcessingConditions). The
ProcessingConditions parameters are as follows:
TestModeIndicator true when called in test mode
FinalIndicator true when called in final mode;
false indicates that the run is an interim check
SkipWhenOngoingBusinessIndicator true when the first occurrence of the ongoing process
hasn’t lead to no further checks
ValidateNextCheckDateIndicator true to skip further application checks when a future date is
available or determined
CreateApplicationLogIndicator true when the creation of the application log is requested
LogDetailLevelCode Values as listed in listID 11105 in global data type
Catalog (1 = no details; 3 = abortions; 5 = abortions and
errors; 7 = Abortions, errors, and warnings; 9 = all details)
The response part expects to receive a set of EoP results for each level of data. The EoP results are as
follows:
ApplicationName Name of the application returning the result information
(mandatory)
RuleVariantName Name of the ILM rule variant is used to calculate the dates
PurposeCompletionCode Value as listed in the global data type catalog (1 = n/a (no
business); 2 = No (business is ongoing); 3 = yes (business
is complete and residence time is over)
(mandatory)
StartOfRetentionDate Start of retention date
NextCheckDate Data after which the next EoP check is allowed
A log segment to which messages are returned in case of complications is available on the same level as
the EoP check results.

5.5.2 BLOCK NOTIFICATION FOR CUSTOMER/SUPPLIER
At the end of the blocking run, a notification is sent to the registered service providers of all blocked data. On
each level (customer and supplier, contact person, company code), an indicator is selected when the data is
blocked.
5.5.3 INTERIM CHECK RESULTS NOTIFICATION FOR

CUSTOMER AND SUPPLIER
Each connected (registered) dependent system is allowed to provide SoRT information to the master
system. These interim results must be provided in the same structure as the response of the EoP check;
however, there is no log information.
The master system takes over the role of service provider.
5.5.4 UNBLOCK CHECK FOR CUSTOMER AND SUPPLIER
The unblock check service is a query response service. The service is called for customers and supplier to
let dependent systems can confirm that the unblocking of the given customer or supplier and contact person
is allowed.
The query sends the customer or supplier (InternalID) with an indicator (CheckCustomerIndicator;
CheckSupplierIndicator) that specifies whether or not a check on the general level is requested.
Information one level below the company code (ID) and the relationship that contains the contact person
(ID; ContactPersonInternalID) must be checked.
This query contains a processing condition segment (ProcessingConditions) to influence general
behavior.
The ProcessingConditions parameters are as follows:
TestModeIndicator The value is true when called in test mode
CreateApplicationLogIndicator The value is true when the creation of the application log is
requested
LogDetailLevelCode Values as listed in listID 11105 in global data type catalog
(1 = no details; 3 = abortions; 5 = abortions and
errors; 7 = abortions, errors, and warnings; 9 = all details)
The response expects to receive the EndOfPurposeUnblockPermitIndicator indicator on each level

of data, which is set to true when permission to unblock is granted. A log segment is available on the same
level as the ID and the EndOfPurposeUnblockPermitIndicator indicator, which returns messages
when there are complications.
5.5.5 UNBLOCK NOTIFICATION FOR CUSTOMER AND SUPPLIER
At the end of the unblocking run, a notification is sent to the registered service providers of unblocked data.
The EndOfPurposeUnblockIndicator indicator is provided on each level (customer and supplier,
contact person, company code) and is true when the data is blocked.

5.6 BUSINESS ADD-INS (BADIS)
5.6.1 MAPPING OF MASTER DATA ID FOR EOP AND

UNBLOCKING
Business Add-In (BAdI) CVP_EOP_MAP_REMOTE_PARTNERS is used to map local customer and

supplier master data IDs from the master system to remote customer and supplier master data IDs in
dependent systems.
The BAdI provides methods that are called during the EoP preparation check or during master data
unblocking. There are separate methods called from the master system or dependent system by the RFC
interface functionality. This allows mapping to the IDs of the connected system as specified in the
IV_MASTER_SYSTEM respectively IV_DEPENDENT_SYSTEM import parameter in the system where the
mapping information is available. The implementation changes the IDs in the changing parameters to the IDs
in the called system. They are changed back to the original IDs of the calling system after execution so that
the processing can continue with the results of the called systems.
5.6.2 CUSTOM CHANGE DOCUMENT HANDLING FOR EOP

CHECK
Business Add-In (BAdI) CVP_CHG_DOC is called during the execution of the end of purpose check for the
ERP_CUST or ERP_VEND registered application names. During this process ERP_CUST or ERP_VEND
determines the last change date of the customer or supplier master data based on the stored change
documents. The BAdI can be used handle custom-based change documents.
5.7 ADAPTION BY DEPENDENT APPLICATIONS
Blocked customer and supplier master data should not be changed and should be not displayed by an
unauthorized user. To simplify the adaption by dependent applications, all internal read function modules are
enhanced. The default behavior of adapted read function modules is as follows:
 Return the block indicator if available
 Initialize personal and private data
 Do not touch technical fields
Most of the adapted read function modules have new import parameter IV_BEHAVIOR to set for a specific
call one of the following behavior modes:
 ' ' = use global default behavior
 1 = block indicator is returned; personal and private data are initialized
 2 = (only for single-read API) raise a new exception when the data is blocked and the user is not
authorized
 3 = return data as if the data privacy enhancement was not active (like before)
 4 = (only for mass-read API) filter blocked data
For some applications there is the need to set a different default behavior without changing the call of each
read function module. You may need to set a global behavior or have a leveled behavior for the application.
To support leveled default and global behavior, static class CVP_CL_READ_API_DEFLT_BEHAVIOR is
available to manipulate the default behavior as a stack. For example, a leveled stack behavior could look like
the following:
 Start application
Default behavior is 1
o CVP_CL_READ_API_DEFLT_BEHAVIOR=>PUSH behavior 2

From now on, the default behavior is 2.
o …
Go deeper in the application
 Default behavior is still 2
…
 V_KNA1_SINGLE_READ
…
 Go deeper
 CVP_CL_READ_API_DEFLT_BEHAVIOR=>PUSH behavior 3
Default behavior is now 3
 …
 V_KNA1_SINGLE_READ
 …
 CVP_CL_READ_API_DEFLT_BEHAVIOR=>PULL
Default Behavior is back to 2
 …
 V_KNA1_SINGLE_READ
 …
o CVP_CL_READ_API_DEFLT_BEHAVIOR=>PULL
As the behavior stack is initial, the system is back to default behavior 1.
 End application
The IV_BEHAVIOR as specified in a call of an adapted read function module has priority compared to the
default behavior.
5.7.1 ADAPTATION OF READ FUNCTION MODULES
Import parameters
The new optional import parameter IV_BEHAVIOR type CVP_API_BEHAVIOR is provided.
Export/changing/table parameters
If the corresponding returned data relates to a table where a block indicator is available, the returned data
structures are extended with the block indicator (for example, the returned structure contains KNA1 data but
CVP_XBLCK was not available).
The block indicator in the export or changing parameter of read function modules can be set with the
following t values:
 ‘’
Not blocked
 X
Blocked; data masked or initialized, or special behavior according to optional parameter
CVP_API_BEHAVIOR.
 A
Blocked but data is unmasked because current user is allowed to display blocked data.
The Domain CVP_XBLOCK will still be untouched (only values ‘ ‘ and ‘X’ allowed), because the database will
only support these 2 values.
5.7.1.1 Specific for Single Read Function Modules
Behavior mode 4 to filter out table entries for blocked data is not supported for single read function modules.
Single read function modules have to support behavior mode 2 to raise a new exception when the data is
blocked and the user is not authorized. If behavior 2 is active, a new exception is raised. If the functionality
already has exceptions, a new exception like KUNNR_BLOCKED is added.
Some examples of these function modules are:

 V_KNA1_SINGLE_READ

 LFA1_READ_SINGLE
 LFB1_READ_SINGLE
 KNB1_READ_SINGLE
 KNVK_SINGLE_READ
 KNA1_SINGLE_READER
 KNB1_SINGLE_READ
 KNVV_SINGLE_READ
 LFM1_SINGLE_READ
 LFM2_SINGLE_READ
5.7.1.2 Specific for Mass Read Function Modules
Mass read function modules cannot support behavior mode 2.

 V_KNA1_ARRAY_READ
 WY_KNVK_ARRAY_READ
 WY_LFA1_ARRAY_READ
 KNA1VV_GENERIC_READ_CUSTOMER
 KNVV_GENERIC_READER_CUSTOMER
 LFM1_GENERIC_READ_LIFNR
 LFM2_GENERIC_READ_LIFNR
5.7.2 ADAPTATION OF CHECK FUNCTION MODULES
Function modules that check the existence of master data can raise exception errors and/or return error
messages. When the checked functionality deals with blocked data, an error or new exception is returned.
Import parameters
A new optional import parameter IV_BEHAVIOR, type CVP_API_BEHAVIOR is provided. It allows behavior
mode 3. Mode 1 and 2 has the same meaning for this kind of function modules; an exception is raised for
both modes. If the functionality already has already, a new exception like KUNNR_BLOCKED is added.
If the function module does not have exceptions, behavior mode 2 has an adapted behavior.

 BAPI_CUSTOMER_EXISTENCECHECK
 CUSTOMER_EXISTS
 MM_PARTNER_ROLE_CHECK
 BAPI_VENDOR_EXISTENCECHECK

5.7.3 ADAPTATION OF SEARCH FUNCTION MODULES
The default behavior for search function modules is to not return blocked data.
Import parameters
A new optional importing parameter IV_BEHAVIOR, type CVP_API_BEHAVIOR is provided. It allows
behavior mode 3. Mode 1 and 2 has the same meaning for this kind of function module.

 CUSTOMER_SEARCH
 VENDOR_SEARCH
5.7.4 ADAPTATION OF BAPI METHODS/FUNCTION MODULES
No interface changes are done for function modules used in BAPI methods.
The behavior mode is based on from where the function module is called:
 If the function module is called from the same system (normal call or destination NONE), it has to
behave like a read function module as described above.
 If the function module is called from the outside, the behavior can be set beforehand. In this case,
the behavior mode is used as described above. If no behavior was set, the following is true:
o For a single read or an existence check function module, an error is returned if the data is
blocked. Therefore, behavior mode 2 is used.
o The blocked data is filtered by default for a search function module. Therefore, behavior
mode 4 is used.

 BAPI_CUSTOMER_EXISTENCECHECK
 BAPI_CUSTOMER_FIND
 BAPI_CUSTOMER_GETDETAIL2
 BAPI_CUSTOMER_GETLIST
 BAPI_CUSTOMER_GETCONTACTLIST
 BAPI_BUSPARTNEREMPLOYE_GETLIST
 BAPI_VENDOR_EXISTENCECHECK
 BAPI_VENDOR_FIND
 BAPI_VENDOR_GETDETAIL
 BAPI_CUSTOMER_GETDETAIL
 BAPI_CUSTOMER_GETDETAIL1
 BAPI_CUSTOMER_SEARCH

5.7.5 ADAPTATION OF ENTERPRISE SERVICES
No interface changes are done for the adaption of enterprise services. The following behavior has been
implemented:
 Read services raise an error for blocked data
 Find services will filter results
 Other services consider blocked data. For example, an updated or changed data service must not
be able to change blocked data.
Examples of enterprise services are:
Web Service Service Interface

ECC_CUSTOMERIDQR CustomerERPByIDQueryResponse_In
ECC_CUSTBASICDATABYIDQR_ CustomerERPBasicDataByIDQueryResponse_In_V1
V1
ECC_CUSTOMERBANKDETAILSI CustomerERPBankDetailsByIDQueryResponse_In
DQR
ECC_CUSTOMCONTACTPERSONQ CustomerERPRelationshipContactPersonByIDAndContactPe
R rsonInternalIDQueryResponse_In
ECC_CUSTBASICDATABYIDQR_ CustomerERPBasicDataByIDQueryResponse_In_V2
V2
ECC_CUSTOMERERPSIMPLEBYI CustomerERPSimpleByIDQueryResponse_In
DQR
ECC_CUSTERPUNLDPT001QR CustomerERPUnloadingPointNameByIDQueryResponse_In
ECC_CUSTERPRCVGPT001QR CustomerERPReceivingPointPartyByIDQueryResponse_In
ECC_SALESARRANGEMENTIEQR SalesArrangementERPByIdentifyingElementsQueryRespons
e_In
ECC_SALESARRANGEMENTSBCQ SalesArrangementSimpleByCustomerIDQueryResponse_In
R
ECC_SUPPLIERSNAQR SupplierSimpleByNameAndAddressQueryResponse_In
ECC_CUSTOMERERPSE001QR CustomerERPBasicDataUpdateRequestConfirmation_In

6 COPYRIGHT AND DISCLAIMER
© Copyright 2011 SAP AG. All rights reserved. These materials are subject to change without notice. These
No part of this publication may be reproduced or transmitted in materials are provided by SAP AG and its affiliated companies
any form or for any purpose without the express permission of ("SAP Group") for informational purposes only, without
SAP AG. The information contained herein may be changed representation or warranty of any kind, and SAP Group shall not
without prior notice. be liable for errors or omissions with respect to the materials.
Some software products marketed by SAP AG and its The only warranties for SAP Group products and services are
distributors contain proprietary software components of other those that are set forth in the express warranty statements
software vendors. accompanying such products and services, if any. Nothing
Microsoft, Windows, Outlook, and PowerPoint are registered herein should be construed as constituting an additional
trademarks of Microsoft Corporation. warranty.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, These materials are provided “as is” without a warranty of any
MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, kind, either express or implied, including but not limited to, the
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, implied warranties of merchantability, fitness for a particular
WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, purpose, or non-infringement.
POWER5, OpenPower and PowerPC are trademarks or SAP shall not be liable for damages of any kind including without
registered trademarks of IBM Corporation. limitation direct, special, indirect, or consequential damages that
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are may result from the use of these materials.
either trademarks or registered trademarks of Adobe Systems SAP does not warrant the accuracy or completeness of the
Incorporated in the United States and/or other countries. information, text, graphics, links or other items contained within
Oracle is a registered trademark of Oracle Corporation. these materials. SAP has no control over the information that
UNIX, X/Open, OSF/1, and Motif are registered trademarks of you may access through the use of hot links contained in these
the Open Group. materials and does not endorse your use of third party web
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, pages nor provide any warranty whatsoever relating to third
VideoFrame, and MultiWin are trademarks or registered party web pages.
trademarks of Citrix Systems, Inc. Any software coding and/or code lines / strings (“Code”) included
HTML, XML, XHTML and W3C are trademarks or registered in this documentation are only examples and are not intended to
trademarks of W3C®, World Wide Web Consortium, be used in a productive system environment. The Code is only
Massachusetts Institute of Technology. intended better explain and visualize the syntax and phrasing
Java is a registered trademark of Sun Microsystems, Inc. rules of certain coding. SAP does not warrant the correctness
JavaScript is a registered trademark of Sun Microsystems, Inc., and completeness of the Code given herein, and SAP shall not
used under license for technology invented and implemented by be liable for errors or damages caused by the usage of the
Netscape. Code, except if such damages were caused by SAP intentionally
MaxDB is a trademark of MySQL AB, Sweden. or grossly negligent.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Disclaimer
and other SAP products and services mentioned herein as well Some components of this product are based on Java™. Any
as their respective logos are trademarks or registered code change in these components may cause unpredictable and
trademarks of SAP AG in Germany and in several other severe malfunctions and is therefore expressively prohibited, as
countries all over the world. All other product and service names is any decompilation of these components.
mentioned are the trademarks of their respective companies. Any Java™ Source Code delivered with this product is only to be
Data contained in this document serves informational purposes used by SAP’s Support Services and may not be modified or
only. National product specifications may vary. altered in any way.

End of Purpose Check Adaption For Applications Consuming SAP Business Partner in SAP S4HANA

Uploaded by

Copyright:

Available Formats

End of Purpose Check Adaption For Applications Consuming SAP Business Partner in SAP S4HANA

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

End of Purpose Check Adaption For Applications Consuming SAP Business Partner in SAP S4HANA

Uploaded by

Copyright:

Available Formats

SAP SECURITY REQUIREMENT SEC-

256 (DELETION OF PERSONAL DATA)

END OF PURPOSE CHECK ADAPTION FOR

AND HOW TO CREATE DATA DESTRUCTION OBJECTS

Released for SAP Customers and Partners

Valid for Release

1.0 July 2016

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 2

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 3

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 4

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 5

2.1 KEY INFORMATION ABOUT AVAILABLE MASTER DATA

2.1.1 CENTRAL BUSINESS PARTNER

Blocking Indicator Field XPCPT in database table BUT000

Table for SoRT Info BUTSORT

Business Function BUPA_ILM_BF

ILM Object CA_BUPA

Blocking Report BUPA_PREPARE_EOP

Unblocking Request BUPA_REQ_UNBLOCK

Unblocking Report BUPA_PREPARE_EOP

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 6

Table for SoRT Info CVP_SORT

Business Function ERP_CVP_ILM_1

ILM Objects FI_ACCRECV,

Blocking Report CVP_PREPARE_EOP

Unblocking Report CVP_UNBLOCK_MD

2.2 HANDLING OF BLOCKED MASTER DATA IN DEPENDENT

2.2.1 CENTRAL BUSINESS PARTNER DATA

 Read authorization requirement

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 7

 Read authorization requirement

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 8

3.1 MAINTENANCE OF APPLICATION-SPECIFIC RESIDENCE AND

Master Data ILM Objects Dependent Application Object

3.2 PURPOSE OF APPLICATION NAMES

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 9

3.4 REQUIREMENTS FOR THE EOP CHECK IMPLEMENTATION

3.5 STEP 1 – COLLECT CONDITION FIELD VALUES

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 10

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 11

3.8 STEP 4 - RETURN NEW SORT DATA

3.9 MAPPING OF CONDITION FIELDS TO APPLICATION RULE

The input parameters are the following:

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 12

CALL METHOD cl_lrm_api=>get_valid_rules

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 13

3.10 STORE SORT INFORMATION BEFORE THE CENTRAL EOP

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 14

4.1 REGISTRATION OF APPLICATIONS

Figure 4-1 Example of Customizing of application names for the CBP

4.2 THE END OF PURPOSE CHECK INTERFACE

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 15

IT_PARTNERS_GUID TYPE BUP_PARTNER_GUID_T Table type with a list of

TYPE BUPA_PARTNER_TYPE_T Table type for partner

IV_APPL TYPE BU_APPL_NAME Registered application

ET_PUR_CMPLT_PARTNERS TYPE BU_SORT_LOCAL_T Returns a table of BP

ET_MESSAGES TYPE BUSLOCALMSG_T Message table

END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 16

4.3 THE UNBLOCKING CHECK INTERFACE