Q and A


Tips on transitioning your sales orders to SAP CRM 7.0: Q&A with CRM expert Michael Debevec

by Antoine Cadot-Wood

I recently hosted a moderated forum on Insider Learning Network with CRM expert Michael Debevec, SAP experts author and technical advisor. Michael took questions on moving from SD to CRM 7.0 – or not! – how to make that decision and troubleshooting configuration and performance issues. He also gave some advice on using SAP Trade Promotion Management.

Review the entire discussion on the Forum page, or read the edited transcript here:

Antoine Cadot-Wood: Welcome to today's latest forum on SAP CRM 7.0, sponsored by CRM Expert. Today we’re focusing on SD and managing sales orders in 7.0.  
I’d like to welcome consultant Michael Debevec, who will take your questions for the next hour. Mike has written articles for CRM Experts and has been a speaker at the annual SAPinsider CRM conferences. Today’s Q&A is based on his CRM 2012 session – aptly named “SD Doesn’t Go Away with Your Implementation of SAP CRM: Tips to Guarantee a Smooth Transition and Coexistence Between Systems.”
Mike, welcome, and thanks for taking these questions today!

Sara Andersson: Hello Mike,

Is there any restrictions, performance wise, on how many sales order you can have as a follow-up from a Sales contract? Or any maximum recommendation?

MichaelDebevec: As far as I know, no.  The contract to order linkage is a relationship so that if you are loading associated orders from a contract, only the header information is loaded.  On the ECC side, the relationship is via document flow and is a linked list.  There should be secondary indices to prevent massive performance issues during a search. 

Just how many orders are you talking about?

Sara Andersson: As a maximum today we have around 1000 sales order connected to one sales contracts. What we are experience is approx 5-10 minutes to open one of thoose kind of contracts. Therefore my question on any recommendation.

MichaelDebevec: This is in ECC ?  I assume that you have already queried for any performance recommendations?

SAP provides a service to analyze the bottlenecks and improve performance.  If you have not considered this option, you should do so.  In working with SAP in TPM, they have been able to analyze and offer improvements.

Performance improves can generally be gained by adding some secondary indices.  Often there is a sequential search going on that kills performance.  A second area tends to be customer exits - they often are not written with performance in mind.

From your other posting, you are using projects, dynamic item pricing and probably resource related billing - all of which are performance hogs.

Is there a different way that you can accomplish what you are doing with the contracts that can avoid the links?

Sara Andersson : We have fully replicated sales order, existing in both R/3 and CRM. Contracts ónly exists in CRM. We have and will continue to look for performance recommendations.

As you state we are using a lot of functions that we have come to understand are bottlenecks in performance like, DIP, RRB as well as we have some customer exits.

For sure we are discussing on changing our scenario on how we are today linking.

Thank you for good answers!

MichaelDebevec: One thought (since it is what I have been doing a lot of recently): If the main use of the contracts is for pricing (rather than volume commitments), consider using trade management.  You could record your special pricing and forecast your expected volumes for demand management.  However, if you are doing service and resource billing this is not a solution.

MichaelDebevec: Some other general thoughts on performance.

Using traces can identify where most of the effort is occuring.  Writing and reading from memory tends to be a performance hit - perhaps you can use static classes to save and access data rather than memory writes.

Pricing is always a big performance hit.

Keep the number of accesses small.  If you use customer hierarchies, make sure that your accesses reflect how many hierarchy levels you maintain.  If you have special pricing for classes of customers - isolate their condition types or accesses - you can use reference condition types so that your master data maintenance doesn't change but the number of accesses that you use in determine the price does change.

Check your own code - SAP has some good tools in the work bench to analyze the performance of your code.

See if you can split contracts - copy it from month to month and then have a field that links the copies together for a unified view for reporting. 

You may be able to do things in BI for reporting that allows you to not link data so closely in you execution system - this is worth analyzing and pursuing.

Antoine Cadot-Wood: Hi Mike, I have a question that came up when we were discussing this topic before. Why do you consider pricing less flexible in 7.0, and how can you avoid the problems that might cause when moving from ECC?

MichaelDebevec: Pricing in CRM in more encapsulated than in ECC - as a result, it is less flexible - or at least there is functionality in ECC that does not exist readily in CRM.  However, there are other features of CRM pricing - for example, using external data sources,  that provide significantly greater flexibility than in ECC.  In addition, you have the option of holding off group condition processing until the end of the order in CRM. This tends to provide performance improvements.

Antoine Cadot-Wood: Mike, that's interesting. Are their particular functions in ECC that simply don't exist in CRM 7.0? What sorts of things can't you do in CRM?

MichaelDebevec: Cost-based pricing is not possible in CRM without additional work - this is because Costs are not condition records and the routines pull the cost from the valuation record or from a purchase order.  You could probably use external data sourcing to overcome this but I would worry about performance.

Certain forms of the dynamic data determination also do not work well.  I would also wonder how cumulative pricing works since the SIS structures are populated in ECC and I do not think they are in CRM as well.

Sara Andersson: Mike,

1.1 What scenarios exist to run between CRM and R/3?
1.2 What scenarios are recommended to run between CRM and R/3? 

MichaelDebevec: 1 - You can choose where to enter orders and where to maintain them.  From a CRM side, the item category identifies where you would wish to do billing.  So, you can order in CRM, delivery in ECC, Bill in CRM or Bill in ECC.

1.2 - I doubt if there is a recommendation, per se (at least I wouldn't give a categorical recommendation) but there are several constraints that will push you in one direction or the other.

The things that I would consider in making your decision is driven in how you plan on using the system.  The customer service scenario is more robust in the CRM space.  So, if you are running an interaction center, then you are going to be in CRM; however, you can choose to enter the order in CRM or enter the order directly in ECC>

Do you try to do a lot of upselling?  maintain competitors' products with your equivalents? then you want use CRM order processing.

Mobile solutions are driven from the CRM side; but, again, what is your business process?

Leads are pushed to sales.  Sales can produce quotes - Quotes converted into orders.  An active sales force of this nature, I would be doing in CRM.

Dave Hannon: Mike, thanks for answering our questions. I wanted to get your thoughts on when it makes sense to set up transaction data that would be maintained in both SD and CRM? 

MichaelDebevec: I guess the main determinant is looking into who is doing the maintenance.  When it is sales - you tend to want to give them a thin client - which is delivered with WEB UI.  The SAP GUI is still cursed as a horrible user interface - again WEB UI is much friendlier.

If you are using the pre-sales functionality (activities, leads, quotes) - then you need to use CRM - so - where do you create the sales order?  If you get your orders from the customer with reference to the quote - on line - probably CRM - internet sales/service.  Via EDI - then probably ECC.

As I mentioned previously, when you have people comfortable in both systems that need to manage the same item, then you need to have it active in both places. 

I am a firm proponent of the person with the knowledge doing the task, so I would rather maintain the order in both CRM and ECC rather than have the sales force email customer service to update orders.

Sara Andersson: Mike,

2. Can billing plans be handled in CRM?

3. How to use R/3 sales order in WEB ui and what can be edited in WEB ui in this case?

- 3.1. Why and what is the use of replicating whole orders so that they can be editable in both systems?
- 3.2 Is this something that will be avoided thinking of the new scenarios yet to come and that possibly also will be further developed?

MichaelDebevec: I would have to research your questions on billing plans and projects.  Without looking into it, I would guess no.  I am assuming you are talking about Project Systems and networks?  Project Systems is more of a financial/cost collection tool and as such, has no real equivalent in CRM.  CRM links back to the FI and CO apps in ECC for accounting.

Considering your question 3.1 - the one customer that I know doing what you asked had some people that did not have SAP GUI on their machines (and they did not want to install it everywhere) and other worked on the ECC side exclusively and they were not interested in training they in CRM.

The key issue is the locking control between the two systems.  We had issues because of the filtering that was going on between the systems which lead to a lock that couldn't be removed.

MichaelDebevec: One note: An area of high interest in the CRM space is Trade Promotion Management. You should be aware of the following assumptions:

1) Like SD, promotions are sales area specific - this means that you cannot promote products in different sales areas together - you can have two promotions running in parallel; but, they cannot be on the same promotion.  If you want them on the same promotions, then you need to look at your organizational structure.

2) SAP assumes that pricing is driven at one of three levels - product, product group or product hierarchy.  Oddly enough, the product price group field from SD is not one of the dimensions that you can use in TPM.

3)  You must have both a customer dimension and a product dimension when creating a trade promotion.  There is no easy way to create a promotion for a customer where you give them a blanket 10% discount on everything you sell.  You would need to at least create a record for each top level of your product hierarchy.

4) SAP would prefer that you use CRM Rebates instead of ECC rebates - this means that you will use CRM billing to do the accrual and settlements and have to configure the interface directly into accounting.  You can still use ECC rebates - but, you would have difficulty with certain trade scenarios.  This is more a warning concerning the staffing and timing of your project. 

Antoine Cadot-Wood: Thanks to all who followed the discussion today!

A full summary of all the questions will be available here in the CRM Forum and in the CRM Group on Insider Learning Network.  

I also encourage you to join the CRM Group for ongoing information and additional resources, including tips from SAPexperts articles and SAPinsider CRM conferences, details about future live Forums, and more.

And finally, thank you again to Mike Devebec of Debevec Consulting for taking the time to answer these questions.

MichaelDebevec: You’re welcome. My email is

Antoine Cadot-Wood: For more information about SAPexperts' CRM offerings, visit our website, and subscribers can also see Mike's latest article. Thanks again for joining us.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!