Many businesses need to capture the details of their transactions with customers within a single document. In certain industries, these documents are very large to begin with, and the documents can constantly grow over time. Common examples of this are service contracts in the utilities industry and license sales contracts in media and entertainment scenarios.

When you implement these document types in SAP CRM and need to work with large documents, system performance becomes critical. For end users, the ability to navigate through these documents, perform header- and item-level operations, make changes, save changes, and create follow-on documents becomes extremely time consuming due to slow system performance.

In this article, we discuss both standard features and tried-and-true custom solutions that can help you alleviate performance issues, thereby improving system usability and user satisfaction.

Standard features in SAP CRM include:

• Lean billing
• Lean distribution
• New pricing interface
• CRM WebClient user interface (UI) tree configuration

The custom enhancements are:

• Business Document (BDoc) decoupling
• BDoc size reduction
• Changed items logic for one-order documents
• Modifying actions configuration check

Standard Feature: Lean Billing

Prior to SAP CRM 7.0 with enhancement package 1, the billing plan items associated with the line items of a one-order transaction were designed to behave similarly to line items, and they were both stored in table CRMD_ORDERADM_I and relevant extension tables. As a result, whenever the system needed to query table CRMD_ORDERADM_I for line item details, it also queried the billing plan items. Additionally, the system executed all standard validations on both the line items and billing plan items. This resulted in significant performance issues, especially on transactions that had numerous line items, each of which had further numerous billing plan items.

With the introduction of the Lean billing concept, rather than generating a billing request item (BRI) in each settlement period as a sub-item of each billable item, the system generates one billing request line (BRL) within each item in each settlement period. These BRLs can be processed significantly faster than BRIs, mainly because they are stored in a separate table, CRMD_BILLREQ_I. Therefore, database query times on table CRMD_ORDERADM_I are significantly reduced, resulting in performance improvements.

Lean billing is primarily a technical adjustment to restructure the one-order document to achieve a desired system performance. It does not impact any of the billing-relevant processes, such as billing due list generation, billing document generation, or the transfer of billing documents to SAP ERP Central Component (ECC).

Activate the Lean Billing Feature

You can activate the lean billing feature by enabling the switch CRM_SRV_BILL_1 or CRM_FS_PERF_1. You can find these switches under the business function CRM_PERFORMANCE accessed via transaction code SFW5, as shown in Figure 1. Select the switch CRM_FS_PERF_1 and click on Activate Changes button.

Figure 1

Switch to activate lean billing feature

An item category is flagged as lean billing-relevant via the item category customizing setting (Figure 2). The value in the Scheduled Bill. field determines if an item category uses Standard Billing Request Items or Billing Request Lines. The IMG configuration path is Customer Relationship Management > Transactions > Basic Settings > Define Item Categories.

Figure 2

Scheduled Billing setting at the Item Category level

With lean billing activated, billing plan information is stored as BRLs in segment BILLREQ_I (as opposed to BRIs, which are stored in segment ORDERADM_I). This segment is currently defined only for object type BUS2000137 (service contract item) in table CRMC_OBJ_ASSI_I (Figure 3). You need to assign it to object type BUS2000176 (sales contract item) as well, as shown in Figure 4.

Figure 3

BILLREQ_I segment assigned to object BUS2000137

Figure 4

BILLREQ_I segment assigned to object BUS2000176

Intellectual Property Management Incoming Billing Engine Application (BEA) Enhancements

In the BEA for the SAP Intellectual Property Management (SAP IPM) incoming royalties scenario, you need to activate the feature LCB - Scheduled Billing Without Request Items in objects DL and BD. This feature ensures that all BEA logic relevant to lean billing becomes available for the Intellectual Property Management Incoming (IPMI) scenario. The IMG configuration path to do this is Customer Relationship Management > Industry-Specific Solutions > Intellectual Property Management > Billing and Settlement > Configure Application.

Based on your specific needs, you might require additional development efforts to extend the lean billing concept to one-order objects. One such enhancement is to use the methods of the class CL_CRM_BILLREQ_I to get the BRL information instead of using CRM_ORDER_READ (used to read BRI information).

Standard Feature: Lean Distribution

Similar to the lean billing feature, as part of SAP CRM 7.0 enhancement package 1, a new lean distribution feature is available to help address performance issues. This topic is discussed in depth in “Manage Large Contracts with Ease Using Lean Distribution” by Diana Dias.

Standard Feature: New Pricing Interface

Several new features were introduced as part of the SAP CRM update to address performance issues around the SAP Internet Pricing and Configurator (SAP IPC) pricing functionality in SAP CRM. There is a new technical interface between the business transactions and the pricing engine. Essentially, it helps to improve system response time during the editing of transactions by enabling you to define when the pricing engine is invoked. This is done by enabling the CRM_PERFORMANCE switch (using transaction code SFW5, as described above) and maintaining the transaction type for which this feature is to be enabled (Figure 5).

Figure 5

Enabling the new pricing feature by transaction type

The IMG configuration path to enable this feature is Customer Relationship Management > Basic Functions > Pricing > Pricing in the Business Transaction > Performance-Optimized Condition Processing and Pricing > Enable Performance-Optimized Condition Processing and Pricing. Some of the features of this interface are listed next.

As part of the new pricing interface, a feature is available that allows you to define specific condition fields that are pricing-relevant by object type (Figure 6). By doing this, the system invokes the pricing engine only when one of these fields is changed, not each time any field is changed. You can find the SAP-delivered default mapping following IMG path Customer Relationship Management > Basic Functions > Pricing > Pricing in the Business Transaction > Performance-Optimized Condition Processing and Pricing > Display System Default Mapping of Condition Fields.

Figure 6

SAP-delivered default mapping

In addition to the SAP-delivered default mapping, you can maintain customer-specific mappings by following IMG path Customer Relationship Management > Basic Functions > Pricing > Pricing in the Business Transaction > Performance-Optimized Condition Processing and Pricing > Define Customer-Specific Mapping of Condition Fields. The details of this are beyond the scope of this article.

Delayed Cross-Item Pricing

Using this feature, you have the ability to delay price calculations that involve aggregated cross-item data (i.e., where group conditions apply). This means that pricing calculations are not triggered when creating, editing, or deleting one-order line items. Instead, the cross-item pricing calculations are executed at the end of document processing. You can disable cross-item pricing by checking the Cross-Item Pricing field against each transaction type in the configuration setting, as shown in Figure 5.

Pricing Totals Determination

Prior to SAP CRM 7.0 enhancement package 1, pricing totals were calculated at runtime whenever you navigated through a one-order document or carried out certain steps in the CRM WebClient UI. As part of the new pricing interface, the pricing totals at the header and item levels are now directly stored in the database, not determined each time. This results in faster navigation times in the CRM WebClient UI.

Standard Feature: CRM WebClient UI Tree Configuration

Transactional documents such as license sales contracts, acquisition contracts, and master data components like installed base and intellectual property use a tree-like structure (as shown in Figure 7) at the header overview level to display the contents of the object (e.g., line items and sub-objects) in a hierarchical manner. This format allows the user to easily navigate to specific sub-nodes rather than clicking through multiple screens. However, it takes a long time for the system to load this overview page.

Figure 7

Tree structure within an SAP IPM license sales contract

Prior to SAP CRM 7.0 with enhancement package 1, all dependent underlying objects were read from the database and loaded into the UI buffers when a tree-based object was opened. This not only resulted in memory issues and timeouts, it also impacted navigation. Now, SAP provides a configuration setting to control the number of first-level nodes displayed in the tree. At present, this feature is enabled only in the SAP IPM solution, but you can enhance it to be available for other objects. Figure 8 shows this setting, and the IMG configuration path is Customer Relationship Management > Industry-Specific Solutions > Media > Intellectual Property Management > Transactions > Settings for IPM Transactions > Define Paging for Contract Tree.

Figure 8

Tree paging

Custom Enhancement: BDoc Decoupling

When a large one-order document is saved, the system updates all the changes performed to the database tables either immediately or via an update task. During this time, a BDoc is also generated that contains all the data of the document. A BDoc is basically the source of the data transfer to the connected systems in the landscape (e.g., SAP ECC and SAP NetWeaver Business Intelligence [BI]).

A potential problem with this standard behavior is that every time a minor update is made to the one-order document, a BDoc is generated with all the data, which results in long runtimes during document saves. To improve the runtime during save, the BDoc generation is decoupled from the online save and performed as a background step.

To set up BDoc decoupling, start by adding a new attribute (e.g., BDOC_DECOUPLE in this example) of the type BOOLEAN to the SAP CRM order header object (ORDERADMH) using the Application Enhancement Tool (AET). This adds a new attribute to table CRMD_ORDERADM_H.

Next, identify the event handler method behind the save button on the one-order document. Enhance the relevant Business Server Page (BSP) component and redefine the EH_ONSAVE method of the controller class. Set the attribute BDOC_DECOUPLE = X in this method. The pseudo code (i.e., informal high-level code indicating the logic you should implement) is shown in Figure 9.

Figure 9

Redefine the method

Create an implementation for the Business Add-In (BAdI) CRM_DATAEXCHG_BADI and redefine the method CRM_BDOC_SEND (Figure 10). Set the changing parameter of this method CV_BDOC_SEND to ABAP_FALSE. Be certain to add appropriate checks (e.g., by transaction type) in this method, because otherwise the system calls this BAdI every time a BDoc generation is initiated.  

Figure 10

Create an implementation

Now that the BDoc generation is decoupled, your system response is much faster. Next, create a custom program, ZV_CRM_BDOC_GENERATE, and query all the documents that have the BDOC_DECOUPLE attribute set to X (Figure 11).

Figure 11

Create a custom program

Once the documents are identified, set the BDOC_DECOUPLE attribute to ABAP_FALSE using CRM_ORDER_MAINTAIN. The code for this is shown in Figure 12.

Figure 12

Set the BDOC_DECOUPLE attribute to ABAP_FALSE

This code in turn calls the BAdI implementation for CRM_DATAEXCHG_BADI, and because the attribute BDOC_DECOUPLE is set to FALSE, the CV_BDOC_SEND attribute is set to TRUE. This starts the BDoc generation process.

Next, schedule the program ZV_CRM_BDOC_GENERATE to run at a frequency suitable to your situation. Make sure to have a validation in the code to check if the same document is processed by multiple instances of the program. You can do this by checking for the lock on the SAP CRM order header object.

Custom Enhancement: BDoc Size Reduction

When a one-order document is saved, a BDoc is generated containing all the data that is then passed to the various connected systems. The size of the BDoc is directly proportional to the size of the one-order object. For large one-order objects, BDoc processing requires excessive system resources (memory and processing power), resulting in various runtime errors. Here are some of the ABAP runtime errors seen in transaction code ST22:

• EXPORT_TOO_MUCH_DATA
• TSV_TNEW_PAGE_ALLOC_FAILED
• TSV_TNEW_BLOCKS_NO_ROLL_MEMORY

Most of these errors occur because there is a 2 GB size limit for internal tables in all SAP applications. To resolve this problem, you need to reduce the size of the BDocs without affecting the way the transaction is processed. Options to achieve this include filtering pricing conditions and BDoc segments.

Filter Pricing Conditions

Depending on the requirements and the solution you are implementing, you might need to have pricing procedures that contain numerous condition types to process the one-order documents in SAP CRM. However, for reporting and financial purposes (handled in SAP NetWeaver BI and SAP ECC, respectively), all the statistical and inactive condition types used in the pricing procedures in SAP CRM may not be required in the target systems. Thus, by identifying and filtering out such condition types during BDoc generation, you can reduce the size of the BDocs, resulting in better runtime performance.

You can implement the code in Figure 13 to filter out pricing conditions during BDoc generation. Create an implementation for the BAdI CRM_DATAEXCHG_BADI and redefine the method crm_dataexch_after_mbdoc_fill.

Figure 13

Code to filter out pricing conditions during BDoc generation

Filter BDoc Segments

Similar to the process above, you can also filter out entire segments of data from the BDoc in order to reduce its size. Again, depending on the requirements and the solution you are implementing, you may not need to have all BDoc segments (e.g., scheduling information) flow to connected systems. You can tweak the code above to filter out other BDoc segments, but these adjustments are beyond the scope of this article.  

Custom Enhancement: Changed Items Logic for One-Order Documents

In most business scenarios implemented in SAP CRM, there is a need to validate the completeness of the one-order document (both at the header and item levels) during save or prior to release. For example, in the media industry, before the license sales contract is released, an incompleteness check routine is executed on all items. This becomes a performance-intensive task for large documents that have hundreds of line items.

Ideally, there is no need to run validations on each item in the one-order document every time a document is saved. Instead, if the system can capture the items that are changed by the user in that particular session and only perform validations on those items, system performance is vastly improved.

There is a standard SAP function module, CRM_ORDERADM_I_GET_CHNGD_ITMS, that tracks the changed items in the one-order object. However, for scenarios in which there are parent-child hierarchies, if a change is made to the child item, this function module marks all the associated higher-level items as changed. This limits the ability to identify only items that are changed. You can take the following steps to address this issue.

First, create a function group called ZV_CHG_ITMS and a buffer called GT_ITEM_CHANGED, which is an internal table to store the item GUIDs. This is type CRMT_OBJECT_GUID.

Create the following function modules in the function group ZV_CHG_ITMS: 

• ZV_CHG_ITM_SET: This has an importing parameter IV_ITEM_GUID of the type CRMT_OBJECT_GUID
• ZV_CHG_ITM_GET: This has an exporting parameter ET_ITEM_GUID of the type CRMT_OBJECT_GUID
• ZV_CHG_ITM_CLEAR
• Z_V_CHG_ITM_EC: This function module is an event callback and has the signature shown in Figure 14

Figure 14

Signature for FM Z_V_CHG_ITM_EC

The function module Z_V_CHG_ITM_EC calls the function module ZV_CHG_ITM_SET. You can make any specific checks before setting the item to the global buffer.

Next, the function module ZV_CHG_ITM_SET is used to set the items to the buffer. Your code should look similar to Figure 15.

Figure 15

Function module ZV_CHG_ITM_SET

The function module ZV_CHG_ITM_GET is used to return the items in the buffer. The pseudo code for this is simply et_item_guid = gt_items_changed. Finally, use the function module ZV_CHG_ITM_CLEAR to clear the entries in the buffer GT_ITEM_CHANGED.

Once this function group is created, it has to be plugged into the one-order event callback configuration in the view cluster CRMV_EVENT_CUST. If the user changes any attribute at the item level (CUSTOMER_I), and if that item has to be tracked as a changed item, complete the configuration shown in Figure 16.

Figure 16

Event callback setting for object CUSTOMER_I

After this configuration, the event callback function module is called for any change performed on the CUSTOMER_I segment. You can potentially configure any action by the user on any object (e.g., partner functions, status, or header) to be tracked using the above configuration.

After all the scenarios are configured in Figure 16, the global buffer GT_ITEM_CHANGED  captures only the changed items. Read the changed items using the function module ZV_CHG_ITM_GET, and then you can apply the necessary business validations only to changed items.

Custom Enhancement: Modifying Actions Configuration Check

While a one-order document is saved, the system calls standard function module CRM_ORDER_SAVE_PREPARE_MULT_OW. This module triggers a number of validations via other function modules, one of which is based on SAP CRM actions (via the function module CRM_ACTION_DETERMINE_SAVE_OB). The code in this function module checks to determine if there are any actions configured to execute on a document save.

This behavior results in performance issues for large one-order documents that have numerous line items that do not have any actions configured to execute on save. A lot of redundant system time is spent executing this function module.

To address this, you can develop an implicit enhancement in the function module CRM_ORDER_SAVE_PREPARE_MULT_OW. In the example in Figure 17, we skipped the check for transaction type ZACT.

Figure 17

Develop the implicit enhancement

Performance Results

After enabling the standard SAP CRM 7.0 enhancement package 1 performance improvement features and developing additional enhancements, we noticed significant improvements in system performance. Table 1 shows some sample readings that were based on a license sales contract that contained numerous line items representing license sales over a 10-year period, each of which had a long weekly-based periodic billing plan.

Table 1

Performance results after implementing performance improvement enhancements

Nagur V. Kanna

Nagur (Vinay) Kanna is a manager at Capgemini US LLC. He has more than six years of SAP CRM and SAP ECC implementation experience in the media and entertainment, CPG, and high-tech sectors. Before moving to consulting, he was a senior SAP CRM product developer for four years at SAP Labs Bangalore, specializing in the areas of SAP CRM MDF, TPM, marketing, and territory management. His expertise includes solution design and architecture, SAP CRM-IPM, SAP CRM development (using the CRM WebClient UI, ABAP Objects, CRM Middleware, and one-order and marketing framework), performance tuning, and HANA modeling. He is SAP Certified Application Associate (Edition 2013) - SAP HANA.

You may contact the author at vinay.kanna@capgemini.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Akarsh Ravi

Akarsh Ravi is a manager at Capgemini US LLC with over eight years of experience implementing SAP CRM and SAP ECC solutions in the high-tech, manufacturing, and media and entertainment industries. His areas of expertise include SAP CRM sales, marketing, IPM, and cProjects; and he is a certified PMP and SAP CRM Sales professional.

You may contact the author at akarsh.ravi@capgemini.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.