Customer-defined ILM conditions fields and the End-of-Purpose Check

[johannes_gilbert]

Introduction

The End-of-Purpose (EoP) check for business data / applications running on SAP NetWeaver ABAP has a strong dependency to SAP Information Lifecycle Management (ILM) for reasons described in blog post End of Purpose Check and ILM-based Archiving. Technically, SAP ILM is used to perform a determination of a so called application rule variant (aka rule variant, abbrev. ARV) for each business transaction a partner is related to.

Example: Customer 4711 is linked to customer quotation 341 as sold-to party. To determine the EoP for customer 4711 the end-of-business of customer quotation 341 is used and a waiting period is applied (see chapters 1.3 and 2.1 of the mentioned blog post). To determine the relevant waiting period(s) SAP ILM along with some indirection are used.

Business Transaction specific Waiting Periods

Chapter 2.2 of the mentioned blog post describe the necessity of business transaction specific customizing for waiting periods. This description is correct but does not tell about the technical approach.

Approach in a nutshell:

• For a single business transaction none, one or multiple ILM retention rules are determined


• Each ILM retention rule has one or none ILM rule group assigned to it.


• Each ILM rule group can be assigned to none, one or multiple application rule variants

Hence, considering a single business transaction (like customer quotation 341) none, one or multiple application rule variants might be determined.

The actual waiting periods are not defined on business transaction level but for master data ILM objects like CA_BUPA (SAP Business Partner), FI_ACCRECV (Customer), FI_ACCPAYB (Vendor), FI_ACCKNVK (Contact Person). SAP has delivered a specific audit area BUPA_DP. Residence rules defined in this audit area are considered as waiting periods by the EoP check. All master data ILM objects provide the ILM condition field APPL_RULE_VARIANT which refers to the application rule variant.

Example: For customer quotation 341 there are several ILM rules matching its condition field values. The rule groups RG1 and RG2 are determined. Moreover, application rule variant RV1 is assigned to RG1 and application rule variant RV2 is assigned to RG1. So we ended up having two application rule variants RV1 and RV2. Looking into the ILM residence rules for audit area BUPA_DP, ILM object FI_ACCRECV (Customer) all ILM rules are determined matching RV1 / RV2 as well as the other condition field values. Let's imagine there are two residence periods determined: 3 weeks and 90 days. In this case the longest residence period is considered (90 days).

Finally, the determination of the actual end-of-purpose date can be finished. Assuming customer quotation 341 has an end-of-business (EoB) date May 4th 2020 the resulting end-of-purpose date is August 2nd 2020' (EoB + 90 days).

For the actual topic of customer-defined ILM condition fields it is important to know that ILM retention rules are reused by the EoP check to determine the waiting period. Any change in the explained determination approach will have a direct impact on this determination and hence on the EoP check in general.

Behavior of ILM APIs during querying for ILM residence and retention rules

SAP Information Lifecycle Management (ILM) applies the following approach to determine ILM rules given some set of condition fields and values.

Given the following set of condition fields and values [ { C1 = A }, { C2 = B } ] the steps are:

1. Get active policies for the ILM object in question (e.g. SD_VBAK for a customer quotation) which are using at least the condition fields C1 and C2 (additional condition fields might be used in a policy).


2. Determine all applicable ILM rules by matching [ { C1 = A }, { C2 = B } ] with the customized condition values.

The critical aspect is already the first step (1). In case a customer defines a new condition field Z3 an ILM policy using Z3 will never be considered by the rule evaluation during an EoP check. An EoP check needs to consider not only SAP-defined ILM condition fields but also customer-defined ones. Otherwise, the determination might be incorrect and not working at all. As result the EoP check might leverage wrong EoP dates or even no EoP might be determined for a partner at all.

Incorporate customer-defined ILM condition fields in an End-of-Purpose Check

Fortunately, the same BAdI ILM provides for customers to define their own condition fields can be used by an EoP check. Unfortunately, the necessary code is highly complex (EoP checks are typically already very complex). The following figure shows the necessary steps along with the called BAdI-methods and ILM API.

Approach to incorporate customer-defined ILM condition fields in an EoP check (activity diagram)

1. First of all the SAP-defined condition fields must be set up along with corresponding field values for each condition field according to the business transaction currently in focus. These will be used as input later.


2. BAdI BADI_IRM_OT_FLD is used to define ILM condition fields by code (in contrast to the customizing of transaction IRM_CUST_BS). Besides SAP which uses this BAdI customers a free to provide own implementations for their specific needs.
   A BAdI instance for the respective ILM object is instantiated.


3. All BAdI implementations are queried for condition fields they define (method register_fields).


4. The definition of all condition fields is read (method get_context_f_registered_field). Here, SAP- as well as customer-defined condition fields are relevant. The definition of a condition field includes information on e.g. the value determination and the time reference determination.


5. For being able to determine field values of customer-defined ILM condition fields it is necessary to have information on the actual business transaction at hand. Within the BAdI implementation further data of the business transaction currently processed should be leveraged as condition field value. Hence, some identifier needs to be passed to the BAdI. For the ILM object Consent Record (CON_CNSNT) this would be the consent UUID. For CRM one-order based ILM objects this would be the transaction header GUID. For ILM object Sales Order (SD_VBAK) this would be the order number (VBELN).


6. For each customer-defined ILM condition field the corresponding field value(s) are determined (method get_fieldvalues).


7. Last but not least the actual call to determine matching ILM rules can be performed with all the condition fields and their values at hand.

Example implementation for the described approach

The described approach is implemented in the End-of-Purpose check at least for CRM one-order based business transactions (like service request, case, activity) as well as in the Consent Administration. For more technical details or specific coding your might have a look at:

• Class CL_CM_EOP_UTILITIES method GET_VALID_RULES as well as subsequent methods. Availability:
  
  
  
  • SAP Business Suite 6.0 EhP 8 SP 10
  
  
  • S/4HANA On Premise 1709 SP02
  
  
  
  


• Class CL_CRM_EOP_CHECK method PREPARE_ILM_RELATED_DATA as well as subsequent methods. Availability:
  
  
  
  • SAP Customer Relationship Management 7.0 EhP 3 SP 05
  
  
  • S/4HANA for Customer Management 1.0