Performance Tuning in Pricing: Guidelines for Better System Performance By Matthias Liebich, MLI Solutions , LLC Editor's Note: As any good SAP® consultant will tell you, the line between functional and technical SAP issues gets pretty blurry sometimes. Unfortunately, there are sometimes tradeoffs between SAP functional enhancements and SAP system performance. As SAP Pricing Expert Matthias Liebich has seen firsthand, there are certainly such tradeoffs when it comes to the tricky but critical issue of SAP pricing. So we asked Matthias to write a white paper that explains how to make sure your company's pricing functionality doesn't bog down your system performance. Using screen shots and project examples, Matthias loaded this article with pricing tips that should have a very positive impact on your SAP system's performance.
Introduction It is the first week after a new implementation. A new division has just joined several others on SAP. But strangely, whenever they try to add a new line item on an order or try to save the order, a little annoying hourglass appears (or perhaps the drum or dinosaur appears instead , depending on how much fun they had with their pointer settings). And that's not all: the nightly billing job that usually ran for 60 minutes is still churning away upon return to the office the next morning . What happened? Something dramatically changed when the new configuration and code went into production that brought the system to its knees . The scenario I've just described is not uncommon . More than once, on implementations I have been involved with, the results of the Basis staffs system logs and traces, as well as SAP's own post-implementation performance reviews , show that pricing can be a main contributor to SAP performance issues. This article will give you suggestions on how you can structure your pricing design and configuration while minimizing the impact on performance. I'm not suggesting that the following recommendations will eliminate all of your performance issues, but they will certainly reduce unnecessary strain on the system . Note that the recommendations in this article are based on the 4.6 R/3 system , but many of them will be effective for all releases , 3.1 and up. In one case , I have noted a significant pricing variation for pre-3 .1 versions for readers on those systems to keep in mind. General Pricing Performance Guidelines Not all industries are affected by pricing in the same way. The more line items on an order or invoice, the bigger the effect the following suggestions will have on system performance. In companies with complex pricing models, the extensive use of the condition technique increases the time needed to process documents. This is true especially in the consumer products industry, where orders and invoices containing up to hundreds of line items are common. Avoiding performance issues starts during the design of your pricing model. Time well spent in the analysis and design phase will prevent headaches after go-live. There is no magic formula that will fit for each situation , but the tips in this article should help pave the way to a successful, performance-friendly system . In general , the following standard measures can be taken to increase performance:
Copyright© 2004 by Klee Associates, Inc. www.SAPtips.com
Page 1
VERSATA EXHIBIT 2088 SAP v. VERSATA CASE CBM2012-00001
Performance Tuning in Pricing: Guidelines for Better System Performance •
Remove unnecessary condition types from pricing procedures (i.e., if the types will not be used anymore). This avoids having the system look for records that don’t exist.
•
Limit the use of pricing requirements and formulas. These little pieces of code get called several times during document processing and also at save time. The less they are used, the less performance is impacted.
•
Limit the use of pricing user exits.
•
Limit the use of group conditions. A group condition has to take all line items into account to determine scale values. SAP recommends not having more than three group conditions per pricing procedure. This is a double-edged sword. On the one hand, SAP requires you to mark conditions as group conditions to accomplish certain functionality (such as allowing zero dollar values on condition records); on the other hand, this affects performance. Each company has to weigh the importance between functionality (design) and performance.
•
Avoid having redundant fields in condition tables. Having sales district and customer in the same key combination does not make sense, since the customer number is unique within the sales district.
These general pricing recommendations might work better for some companies than for others. I’m not suggesting limiting functionality that is needed to accomplish business requirements or standard industry practices. However, you should be aware of the impact on performance based on these design decisions. The following more specific suggestions can be implemented regardless of the volume of transactions or the size of the sales documents. Structuring Pricing Procedures If possible, don’t attempt to have one monster pricing procedure that incorporates all condition types used by different business units or customers. If a specific customer segment (domestic, export, etc.) or business unit has unique pricing requirements, keep them in separate pricing procedures instead of combining them into one. Consider this example: Domestic customers get charged a base price PR00 and receive a potential of three discounts: ZDAA, ZDBB, and ZDCC. Export customers also get charged a base price PR00, but receive a different set of discounts: ZDDD, ZDEE, and ZDFF. Instead of combining all condition types into one pricing procedure, ZVA001, create two pricing procedures: (1) ZVA001 (containing PR00, ZDAA, ZDBB, and ZDCC) and (2) ZVA002 (containing PR00, ZDDD, ZDEE, and ZDFF) and point them to the respective customers in pricing procedure determination. If only one pricing procedure would have been utilized instead of two, each line item for a domestic customer would have unsuccessfully searched for ZDDD, ZDEE, and ZDFF discounts, in the process using valuable system resources.
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 2
Performance Tuning in Pricing: Guidelines for Better System Performance One disadvantage of having multiple pricing procedures is that if some common calculation changes, e.g., the basis for the cash discount, it will have to be changed for each pricing procedure. In addition, always remove conditions that are no longer used by the business, such as discontinued discounts. If a condition type is rarely used, consider whether an access sequence is needed to determine it, or if the order entry person can add the condition manually on an as needed basis. Configuring Access Sequences When creating a new access sequence (AS) or copying and changing standard delivered ones, make sure that the “Exclusive” indicator is selected for each condition table in the AS, as shown in Figure 1. This will prevent unnecessary condition record searches once a condition record is found. Not selecting this flag will cause the system to search for each condition record and apply the last found one.
Figure 1: Exclusion Indicator on Access Sequence Structuring Access Sequences SAP recommends not having more than 50 accesses per pricing procedure. Some companies with complex pricing models easily exceed this number, but there are still ways to lessen the strain on performance. One good practice: don’t combine condition tables for different condition types in one access sequence and attach this AS to multiple condition types. Split the access sequence into separate
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 3
Performance Tuning in Pricing: Guidelines for Better System Performance ones and only have the applicable condition tables attached to it. This involves more configurations up front, but it will greatly reduce the number of accesses in the long run. Example: Condition type ZAAA uses condition table A900, A905, and A911. Condition type ZBBB uses condition table A900, A907, and A912. Condition type ZCCC uses condition table A903, A909, and A911. Instead of using one access sequence incorporating all tables (A900, A903, A905, A907, A909, A911, and A912), create three separate AS containing only the applicable tables (as listed in the example above). If all tables would apply in one access sequence, the reads on tables A907, A903, A909, and A911 for condition type ZAAA would always be unsuccessful (given that no condition record was previously found). If you multiply these four accesses with 100 line items on an order, you have 400 unnecessary condition record reads. And this number is for just one condition type! Add ZBBB and ZCCC into the mix and you have 1200 unnecessary reads. You get the picture. Optimize Condition Access with Condition Pre-Steps Another way to reduce the number of accesses is to use the condition pre-step. The standard configuration task “Optimize Access,” which is often overlooked or misunderstood, will reduce the number of accesses carried out in a pricing procedure. Tip: activating the condition pre-step will not influence the pricing model or the results of pricing. Transaction OVU0, or IMG path “SDÎBasic functionsÎPricingÎPricing ControlÎDefine Access sequencesÎOptimize access” lets you define the condition tables by condition type for which you want to carry out a condition pre-step. Enter the condition type and the access number for which you want to carry out a condition prestep. (Based on the example in Figure 1, access 10 is for condition table 5.) The configuration in Figure 2 defines that for pricing condition PR00, a preliminary step is to be executed for access number 10 (Customer/Material).
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 4
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 2: Configuration of Condition Pre-Step What does the condition pre-step accomplish? It basically looks for valid condition records using document header data first before using line item data. For example, if you have a key combination by customer and material, the pre-step checks if there are any condition records for that condition type and customer. If there are none, the system does not check for the material number. In addition, it does not check condition records for that condition table again in the subsequent document line items. (There is no need for that since the system already determined that there are no records for that customer.) The material numbers are therefore irrelevant. The more line items are on a document, the more the effect if the pre-step increases. Displaying the analysis on the item pricing screen shows the effect of the condition pre-step (see Figure 3).
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 5
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 3: Condition Pre-Step for PR00, Access 10 The next condition access (20) for price list type, currency, and material shows a full access since this condition table was not defined as a condition pre-step in Figure 2. The reason might be by design, since the price list type can differ between header and item(s), and condition records should therefore be read for each line item. However, if by design, the price list type remains the same for each item of a document, it is advisable to add this access to the pre-step configuration. As a result, this access would not be searched for subsequent line items if there are no PR00 records for price list type 02, as shown in Figure 4.
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 6
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 4: No Condition Pre-Step for PR00, Access 20 De-Activate Group Condition Processing for Each New Line Item Starting with R/3 Release 3.0D, the processing of group conditions in standard SAP has changed. Each time a new line item is entered, the system executes the group condition routines to display the correct price, allowance, or charge based on the specified scale bracket or allocation rule. Prior to 3.0D, these routines were only processed when a document was saved or when the condition was displayed on the document header. If the user does not need to see the final condition value after entering each line item, deactivating the group condition processing will avoid increased runtimes during pricing and the extra system load that occurs. How can this be accomplished? Since we are trying to circumvent standard SAP, we will need a condition value formula that is supported by OSS note 63070 (see Figure 5). Customers using a release prior to 3.1G will need to implement additional code changes as described in this note. The one line of code turns off the standard group condition processing after each line item. The correct values for each line item then get calculated at save time or after accessing the header condition screen.
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 7
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 5: Condition Value Formula to Turn Off Group Condition Processing for Each Line Item After the routine is created, attach it to a condition type at the beginning of the respective pricing procedure, preferably the one that is mandatory to ensure that the routine gets executed (see Figure 6).
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 8
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 6: Assigning Condition Value Routine to Pricing Procedure Re-Pricing at Invoice Time The pricing rule for order or delivery-related item categories is assigned in copy control for invoices (VTFL and VTFA). Ask the functional team if it is always necessary to re-price at invoice time. I have had clients who re-priced invoices, in order to apply the most current price at invoice time. In case the invoice price differed from the price on the order, the invoice was put on hold for review (obviously a custom check). After researching how these issues were resolved, it was discovered that the customer always received the original price from the order anyway by manually changing the invoice price to the order price. To avoid this manual step, the price rule was changed to “copy unchanged” from the order and performance was significantly improved. There are several different price rules that let you re-price only certain conditions such as taxes or freight (see Figure 7).
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 9
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 7: Pricing Rules in Copy Control Indexing I had a situation once where after implementing the shipment cost functionality for a client, the billing due list processing time increased by 40% without adding volume in the number of transactions. The calculated freight cost on the shipment document was transferred to the invoice based on standard configuration. After researching OSS for a solution, note 376296 suggested building an index for the shipment cost item table that vastly improved performance at invoice time. Granted, updating indexes for a transaction has an effect on performance as well, but the performance benefits in other areas were far greater. Again, the decision to implement changes like that depends on the volume of transactions that has to be processed. See Figure 8 for an example of the Data Dictionary definition of an index.
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 10
Performance Tuning in Pricing: Guidelines for Better System Performance
Figure 8: Index for Shipment Cost Item Table VFKP
Conclusion As you can see, improving system performance for pricing might be related to changes in business processes, configuration, code, or a combination of all of the above. Each company’s requirements are unique, but implementing some of the changes in this article should prevent you from seeing those hourglasses, drums, or dinosaurs. Matthias Liebich, MLI Solutions, LLC. Matthias has over 12 years of SAP SD consulting experience, acquired during numerous full life cycle implementations in the US and Germany. He is SD certified and has extensive hands-on experience in new implementations, upgrades, mergers, divestitures and bolt-on integration. Beyond the core SD functionality, Matthias is an expert in the areas of Pricing, Contracts and Rebates. In addition to his cross-module functional knowledge, he is also proficient in ABAP, enabling him to play a leading role as link between functional and technical teams. He can be reached at
[email protected].
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 11
Performance Tuning in Pricing: Guidelines for Better System Performance
The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned by Klee Associates, Inc. NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy or use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensure accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc. reserves the right to make changes without prior notice. NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG. SAP AG software referenced on this site is furnished under license agreements between SAP AG and its customers and can be used only within the terms of such agreements. SAP AG and mySAP are registered trademarks of SAP AG. All other company and product names used herein may be trademarks or registered trademarks of their respective owners.
Copyright © 2004 by Klee Associates, Inc. www.SAPtips.com
Page 12
