END OF PURPOSE CHECK ADAPTION FOR APPLICATIONS CONSUMING SAP BUSINESS PARTNER IN SAP S/4HANA

Transcription

1 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)".

2 TYPOGRAPHIC CONVENTIONS Type style / icon Description Quotation Emphasis All names User entry <Variable user entry> KEY 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. Emphasized words or phrases in body text, graphic titles, and table titles. 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 texts are words or characters that you enter in the system exactly as they appear in the documentation. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. 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

3 TABLE OF CONTENTS 1 Introduction Overview of the End of Purpose (Blocking) Process Key information about available master data blocking functionality Central Business Partner Customer and Supplier Handling of blocked master data in dependent applications Central Business Partner Data Customer/supplier How-To COMPLETE an EoP Check Implementation Maintenance of Application-Specific Residence and Retention Periods overview Purpose of application names Purpose of application rule variants Requirements for the EoP Check Implementation Step 1 Collect Condition Field Values Step 2 Map the Condition Field Values to the Application Rule Variants Step 3 - Calculate the End of Residence Date Step 4 - Return new SoRT data Mapping of Condition Fields to Application Rule Variants using ILM Rule Groups Store SoRT Information before the central EoP check run EoP Check for Central Business Partner Data Registration of Applications The End Of Purpose Check Interface The Unblocking Check Interface Enterprise Service Methods End of Purpose Check for Central Business Partners Block Notification for Central Business Partners Interim Check Results Notification for Central Business Partners Unblock check for Central Business Partners Unblock notification for Central Business Partners Business Add-Ins (BAdIs) Business Partner Key Mapping Restriction of Business Partner from EoP Check Export SoRT Details of Blocked or Unblocked Business Partners Adaption by Dependent Applications EoP Check for Customers and suppliers END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 3

4 5.1 Registration of Applications The End of purpose Check Interface Interface Methods Interface Attributes Initialize and Finalize methods EOP Check Method CHECK_PARTNERS Blocking method PARTNERS_PURCMPL_EXPORT Blocking Process flow The Unblocking Check Interface Initialize and Finalize methods for Unblocking Unblocking Methods Unblocking process flow Special Scenario: One-Time Accounts EOP Check Method CHECK_CPD_PARTNERS Enterprise Service Methods End of Purpose check for customer and supplier (vendor) Block Notification for Customer/Supplier Interim Check Results Notification for Customer and Supplier Unblock check for Customer and Supplier Unblock notification for Customer and Supplier Business Add-Ins (BAdIs) Mapping of Master Data ID for EoP and Unblocking Custom Change Document Handling for EoP Check Adaption by Dependent Applications Adaptation of Read Function Modules Adaptation of Check Function Modules Adaptation of Search Function Modules Adaptation of BAPI Methods/Function Modules Adaptation of Enterprise Services Copyright and Disclaimer END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 4

5 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: -> Product Assistance -> Cross Components -> Data Protection END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 5

6 2 OVERVIEW OF THE END OF PURPOSE (BLOCKING) PROCESS 2.1 KEY INFORMATION ABOUT AVAILABLE MASTER DATA BLOCKING FUNCTIONALITY 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 Transaction BUPA_PREPARE_EOP BUPA_PRE_EOP Unblocking Request Transaction BUPA_REQ_UNBLOCK BUP_REQ_UNBLK Unblocking Report Transaction BUPA_PREPARE_EOP BUPA_PRE_EOP END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 6

7 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 Transaction CVP_PREPARE_EOP CVP_PRE_EOP Unblocking Request Transaction BUPA_REQ_UNBLOCK BUP_REQ_UNBLK Unblocking Report Transaction CVP_UNBLOCK_MD CVP_UNBLOCK_MD 2.2 HANDLING OF BLOCKED MASTER DATA IN DEPENDENT APPLICATIONS 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 7

8 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 8

9 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 Periods Residence periods are maintained for the master data ILM objects for the following: Master data itself (for example, if new master 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 Blocking and maintenance of residence periods for the ILM object of a dependent application object are not required. Retention Periods Retention periods are maintained for the following: Master data (for example, if master data without usage should not be destroyed too early) Each dependent application object maintained using the application name/application rule variant concept to consider the applicationspecific retention period before destruction of a particular master data object ID Retention periods are maintained for the ILM object of a dependent application object to ensure destruction of application data after the end of the retention period. 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 9

10 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 applicationspecific 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 applicationspecific 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 10

11 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). END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 11

12 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 12

13 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. ASSIGN ls_condition-r_field_value->* TO <lv_value>. <lv_value> = sy-mandt. INSERT ls_condition INTO TABLE lt_conditions. CLEAR ls_condition. ls_condition-v_field_name = 'SYSTEM_ID'. CREATE DATA ls_condition-r_field_value TYPE sy-sysid. ASSIGN ls_condition-r_field_value->* TO <lv_value>. <lv_value> = sy-sysid. INSERT ls_condition INTO TABLE lt_conditions. CLEAR ls_condition. CALL METHOD cl_lrm_api=>get_valid_rules EXPORTING iv_object_category = p_oc iv_object_type = p_ot END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 13

14 iv_policy_category = p_pc it_conditions = lt_conditions IMPORTING et_valid_rules = lt_valid_rules 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 14

15 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-ofretention time date. The following table shows the expected signature of the end of purpose check function module: END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 15

16 Parameter Type Associated Type Description IT_PARTNERS_GUID (import) TYPE BUP_PARTNER_GUID_T (not optional) Table type with a list of BPs, which need to be checked for purpose completion IT_PARTNERS_TYPE (import) TYPE BUPA_PARTNER_TYPE_T Table type for partner number and partner type to provide input for endof-residence time calculation IV_APPL (import) TYPE BU_APPL_NAME Registered application name ET_PUR_CMPLT_PARTNERS (export) TYPE BU_SORT_LOCAL_T (PARTNER PARTNER_GUID BUSINESS_SYSTEM APPL_NAME APPL_RULE_VARIANT ST_RET_DATE NEXTCHKDT PUR_CMPL_STATUS STATUS) Returns a table of BP data with purpose completion status and SoRT ET_MESSAGES (export) TYPE BUSLOCALMSG_T (local partner ID, local partner GUID, application name, and fields of structure BAPIRET2) Message table 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 16

17 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 END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 17

18 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: Parameter Type Associated Type Description IT_PARTNERS_GUID (import) TYPE BUP_PARTNER_GUID_T (mandatory) Table type with a list of BPs, which should be checked for unblocking IV_APPL (import) TYPE BU_APPL_NAME BP-consuming application ET_UNBLK_STATUS (export) TYPE BUPARTNER_UNBLK_STATUSREMOTE_T Returns a table of BP data with the unblocking check result ET_MESSAGES (export) TYPE BUSLOCALMSG_T (local partner ID, local partner GUID, application name, and fields of structure BAPIRET2) Message table 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 END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 18

19 The blocking and unblocking functions of the central business partner (CBP) provide the following service methods in the namespace 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 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: END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 19

20 Parameter CHECK_ALL_APP TESTRUN Description The value is X, when despite ongoing processes, all other registered EoP checks have to be executed in the called system 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 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 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 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 20

21 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) 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. Parameter Type Associated Type Description 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 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 21

22 The BAdI includes the method PARTNER_EXCLIST. Parameter Type Associated Type Description IV_FLT_VAL Import BUS_DA_SELECT_VARIANT 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 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. Parameter Type Associated Type Description IV_TIMESTAMP_BUS Import TIMESTAMP UTC time 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 22

23 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. Parameter Type Associated Type Description IV_TIMESTAMP_BUS Import TIMESTAMP UTC time 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 END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 23

24 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 BUS Business partner employee BUS Business partner contact person relationship BUS Business partner employee relationship BUS Business partner group hierarchy BUS 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 END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 24

25 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. END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 25

26 Figure 5-1 Example of Customizing for application classes registered for EoP check for cvi customers and suppliers 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 method Initialize EoP check to get execution parameters CHECK_PARTNERS Instance method EoP check partner CHECK_CPD_PARTNERS Instance method EoP check one-time account partner PARTNERS_PURCMPL_EXPORT Instance method Store application-specific blocking information FINALIZE Instance method Finalize EoP check for cleanup and dequeue handling END OF PURPOSE ADAPTION FOR BUSINESS PARTNER CONSUMING APPLICATIONS Page 26