Knowing when to customize SAP

When should you customize SAP® core functionality?

Almost never, according to this blog post by Lawrence Matusek of our partner eLogic Group entitled “GO NATIVE! Mind the Gap!”.

That’s sage advice for SAP® shops who want to keep their implementation costs, and upgrade paths, as clean and simple as possible.  But every so often, you come across a blue moon that forces your hand.  Today’s post is written by Corevist’s Nathan Leach and describes an experience he had in the eleventh hour of our implementation of Bell and Howell’s new SAP® Integrated Parts and Supplies eCommerce website.

In his “Go Native!” post, Lawrence offers three simple rules of thumb he uses to evaluate custom enhancements to native functionality:

1. “How many lines of code and how many lines of comments?”
2. “How many database queries versus API calls?”
3. “Does it stay “between the lines”?

I used Lawrence’s rules of thumb to evaluate Nathan’s customization effort and was real happy to see that he passed with flying colors.  His answers to the above questions are:

1. <20
2. 0 database calls
3. Absolutely

I’ll let Nathan’s tell you the story.

Sam

---

The 11th hour isn’t the time to uncover show-stopping issues with your new SAP®-integrated, B2B, web portal implementation…or any implementation, for that matter. Unfortunately, it does happen, even in the very successful, Corevist, agile, project methodology.

Recently, one of our clients uncovered such a problem based on a seldom-used scenario.

A few of their customers have contracts in place that set a discount amount for particular items. These contracts typically indicate 100% discounts for this customer and material combination, because the customer has paid in advance for certain maintenance items. This was NOT the usual “create with reference” scenario that most SAP® users are familiar with, but an automated determination of contract pricing based on customer, material, and contract validity dates.  While SAP®’s sales document create transaction (VA01) handled this scenario properly, the SAP®-standard function module, that handles order creation behind the scenes for system integration like ours, didn’t.  We were surprised, because our integration very closely mirrors the interaction that an online user takes with SAP® and rarely has these sorts of problems.

After spending some time searching for the usual culprits…web application configuration, parameter values in the Remote Function Call (RFC), or customer-specific enhancements done as part of the project, and searching for notes in SAP® Service…still no luck. The next step was searching SAP® Service for any notes related to the topic and then debugging the SAP® transaction itself. As anyone who has spent time doing it can attest, debugging SAP® transaction code can be a tedious, time-consuming, and often fruitless adventure. In this case, we weren’t able to locate the offending code.

So, we pulled together a meeting of the most-relevant functional and technical resources at Corevist and our client. Walking through the transaction, debugging into the depths of SAP®, and running various scenarios eventually turned up the culprit.  SAP® had specifically disabled this piece of functionality when called via a function module.

Since our application integration relies on RFC to work, we were shut down.

As we frequently tell people who ask “why” SAP® does certain things…we have no idea. All we can tell you is what they are doing and how. Then, we can tell you how to change it or work around it. In this case, allowing the feature to work during our RFC required a registered modification of SAP® code, something that we go to great lengths to avoid. The enhanced code only allows SAP®’s exclusion of the feature if the current user is not the pre-configured value representing our system calls.  (See code snippet in attached image.)

However, in this case the benefits, a B2B, web portal with real-time SAP® integration, outweighed the complications introduced by modifying SAP® standard code. Since the modification is within an SAP® enhancement spot, future upgrades should be relatively painless. So, aside from a reasonable investment in regression testing, our client should have smooth, e-commerce sailing ahead.

Nathan Leach