sap collateral management system – pooling solution

Best_Practice_Pooling_V21.doc – 28.10.2008

Best Practice

SAP Collateral Management System –Pooling Solution

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUScustomer published

DATE VERSION

Oct-28 2008 2.1

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Design Operations SAP Collateral Management Solution

TOPIC AREA SOLUTION MANAGER AREA

Business Process Operations Data Volume Management

Best PracticeSAP Collateral Management System – Pooling Solution

© 2008 SAP AG - Best_Practice_Pooling_V21.doc page 2/11

Table of Contents1 Management Summary 3

1.1 Goal of Using this Service 31.2 Staff and Skills Requirements 31.3 Case Study or Sample Scenario 3

2 Best Practice 52.1 Executive Brief of Solution Proposal 52.2 Graphical Display of the Pooling Solution 52.3 Preconditions 62.4 Performance Improvement Within SAP CMS: Implementation Methodology 7

2.4.1 Apply Support Packages 72.4.2 Steps in Customizing 72.4.3 Results 8

3 Further Information 103.1 Limitation 10



1 Management Summary

This document gives a short introduction of how to achieve performance improvements for the central SAPCollateral Management System (CMS) transactions:

Calculation tab of CMS WorkbenchBusiness Partner Overview tab of CMS Workbench

Collateral sheet Extraction of entities along with calculated results to Business Warehouse

These transactions are affected by the long run time for calculation results when working on collateralconstellations related to large corporate customers. This document includes a step-by-step description of theimplementation of relevant notes and an introduction of the necessary customizing changes.

1.1 Goal of Using This Service

Use this service to obtain the optimal performance for the major CMS transactions.

1.2 Staff and Skills Requirements

The following requirements have to be met: Application know-how of CMS is necessary to transfer the business/application requirements into an

appropriate CMS solution. Technical/bases know-how is required to implement recommended notes.

1.3 Case Study or Sample Scenario

Following explanations are based on a concrete customer situation. Initially, memory dumps and adecreasing performance in central CMS transactions were caused by very complex collateral constellations,which were identified in the customer’s collateral portfolio. The portfolio consists of approximately 600collateral agreements, 600 collateralized receivables and M:N relations between collateral agreements andreceivables (approximately 500,000).

The basic feature of constellations like this is the ‘”Sicherungsabrede”’, working term in English “collateralsafeguard”, which is a special legal agreement in the collateral contract.1. Collateral agreement acts as primary collateral and collateralizes in 1:1 relation a receivable (narrow

declaration of purpose). In the customer’s system landscape, this link is created automatically, triggeredby pre-systems.

2. Sicherungsabrede/collateral safeguard: Collateral agreements also act as secondary collateral for allfurther receivables of the business partner ‘borrower’. This leads to a 1:N relation between the collateralagreement and several receivables (wide declaration of purpose). Link generation takes place based on amaintained rule parameter: business partner ID.

3. Finally, there are lots of collateral agreements and receivables linked M:N with each other.

This leads to very complex constellations.



Complexity is derived based on different factors:

Factor 1: Number of collateral objects, collateral agreements, receivables (financing/leasing contracts)Factor 2: Type of linkage between collateral contract and receivableFactor 3: Quality of linkage ranking, in CMS: Priority, ranking class, can be the same for all links ordifferentFactor 4: Borrower unit (Kreditnehmereinheit), which can lead to a much higher complexity of alreadycomplex constellation of one member of a borrower unit.

The more of the above mentioned factors 1-4 appear in a collateral constellation, the higher the complexityand runtime.



2 Best Practice

2.1 Executive Brief of Solution Proposal

This chapter focuses on the solution of the memory problem for very complex constellations. The plannedimprovements will also have further impact on optimization of runtime for all kind of complex constellationswith wide declaration of purpose, which leads to a 1:N or M:N relation between collateral agreement andreceivable.

Prevent huge volume of redundant data from being loaded into internal memory by loading andworking with so called “receivable sets” instead of individual receivables.

At the moment, every collateral agreement (CAG) – receivable (RBL) link is processed individually. Due towide declaration of purpose with the same business partner ID (rule parameter), a group of receivables (allreceivables of the business partner) are linked in a similar manner (via wide declaration of purpose and withsame priority and ranking class). This can be called a homogenous bundle or set of receivables.

Increase speed of distribution by distributing to these homogenous receivable sets instead ofindividual CAG-RBL links.

2.2 Graphical Display of the Pooling Solution

Figure 1 Idea of a pool

Relationship between CAGs and RBLs without pooling (1) – Links are generated by excluding the specificRBL. So, each CAG has a unique set built by excluding RBLs serviced via higher ranked charge.

After the creation of the pool, all CAGs and RBLs are linked via the pool (2)



Figure 2 How to define such a pool?

The figure above is an example of a pool created based on customer requirements.

2.3 Preconditions

The consolidation of similar or homogenous CAG-RBL links and receivables can take place based on thecollateral entity of a collateral pool. This is an already existing and delivered collateral agreement category inSAP CMS. One CAG portion to cover the receivable 1:1 as primary collateral agreement Second CAG portion to contribute as secondary collateral to the set of further receivables of the business

partner, that will be consolidated by a collateral pool Both CAG portions are defined as 100%. CAG portion 1 has ranking ratio 1, CAG portion 2 has ranking ratio 2. All receivables of the business partner (wide declaration of purpose) are bundled in the pool, every pool-

RBL link has the same priority and ranking class.

Current the following restriction in SAP Collateral Management requires the creation of two CAG portions: Only one CAG-RBL-link or one CAG-CAG link can be created per a CAG portion.

This was implemented in former releases to avoid deadlocks and prevent calculation. For instance, areceivable is collateralized by a CAG and a pool, the CAG is contributing to both, the receivable and the pool.



2.4 Performance Improvement Within SAP CMS: Implementation Methodology

Please follow the steps to gain performance improvement for the calculation of huge constellations.

2.4.1 Apply Support Packages

Apply Support Packages that include at least notes 1020884 and 1040197.

Note 1020884 creates a report that creates a new report to improve performance. This report copies remotereceivables (i.e. outside CMS) into a CMS local data store. This eliminates costly remote function calls duringconstellation extraction.

In the following Support Packages, the note is part of the software:

SAP R/3 Enterprise Financial Services: 500 SAPKGPFC16 500 SAPKGPFC17 600 SAPKGPFD09 603 SAPK-60302INEAFINSRV

Note 1040197 was created to improve performance of the Business Partner Overview and Calculation tabs ofCMS Workbench, which take a lot of time to load or execute for very big constellations with wide declarationof purpose. In cases with very huge constellations, CMS Workbench and Business Partner Overview can runinto time-outs.

In the following Support Packages, the note is part of the software:

SAP R/3 Enterprise Financial Services: 500 SAPKGPFC17 600 SAPKGPFD09 600 SAPKGPFD10 100 SAPKISC202 100 SAPKISC203

2.4.2 Steps in Customizing

You may take further steps to create a workaround to improve performance. Check if in-house businessexperts agree that this workaround using collateral pools is feasible before you proceed with the stepsdescribed in the following.

Ensure the business check from application area CMS_CAG is not an "abort" or "error" in the customizing formessage severity related to “Activities” on a CAG. Refer to IMG Node Collateral Management CollateralAgreement Process Control Define Activities. This message usually pops up as an informationmessage if there is no additional customizing done on CMS instance.



Figure 3 Process control keys

Create a unique CAG for each deal-specific clause with two portions inside CMS Workbench. Define each portion value as 100% of the CAG value. Create just one collateral pool for each unique borrower-specific clause. For instance, create just one

unique collateral pool to collateralize all receivables of business partner ABC through a wide declaration ofpurpose. Reuse this collateral pool instance in the process steps mentioned below.

Link the first portion of CAG to the deal-specific receivable(s) with a higher rank than the second portion. Link the second portion of CAG to the pool via a relationship. The second portion should have a lower

rank than the first portion (see tab Portions/Terms in CMS Workbench).

2.4.3 Results

All calculations in CMS now work without memory dumps and run much faster than a similar constellationwith conventional method of definition. In the conventional method, the number of links between M collateralagreements and N receivables was M*N. It is now reduced to ~ M+N with the modified definition suggested inthis note.



Performance can be improved by large factors for big constellations. For example, SAP recorded a decreaseby factor 30 from ~38 minutes at the beginning to ~2 minutes for the Calculation tab in CMS Workbench tolook up in a constellation with 500 objects, 500 collateral agreements and 500 receivables. The test systemspecs are 65 GB RAM on a 16 sparcv9 processor machine operating at 1350 MHz.

Constellations with up to 5,000 collateral agreements and 5,000 receivables have been successfullycalculated without any issues if implemented as a pool; whereas constellations with 1,000 collateralagreements and 1,000 receivables can (depending on the server capabilities) already run into severememory problems (memory dumps) if implemented with the conventional method. This has already beenverified in one CMS customer installation.



3 Further Information

3.1 Limitation

Actual improvement in customer deployment depends upon hardware configuration and response times withinterconnected remote receivable and business partner systems.



© Copyright 2007 SAP AG. All Rights ReservedNo part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.

sap collateral management system – pooling solution

Documents