Skip to Content

Can SDN Mentors Serve a Useful Role as Ombudsmen/women between SAP and Customers?

I have just hit the oddest case that I’ve ever hit of a problem with code written in an X function group.

As many of you know, the Purchase Requisition transactions ME5xN have a function group XM02 which can be used to do whatever you want on the customer data tab provided by SAP in ME5xN.

So, suppose a client writes code in XM02 to add three new sub-tabs on a tabsrip that’s placed on the customer data tab (by using the PBO and PAI modules for screen 0111 – the subscreen that’s provided by SAP in XM02 for customers to “do their thing”. 

Furthermore, suppose that the customer has written code to hide/display certain fields on certain customer sub-tabs according to certain business rule logic.

And finally, suppose that during testing, the customer experiences the following:

a) the code for hiding/displaying custom fields on a custom sub-tab works perfectly in ME52n (change mode) and ME53n (display mode);

b) this code also works perfectly in ME51n (create mode), so long as a new purchase requisition is created from scratch.

c) this code does not work in ME51n when the customer tries to create a new purchase record by using the “adopt” feature of Document Overview;

d) even worse, the problem can not be duplicated in debug mode – if you are in debug mode, the hide/display code works just as well in “adopt” create mode as in “create from scratch” mode.

To me, the fact that the problem can’t be duplicated in debug mode means that it’s more than likely either a timing problem and/or a problem deep inside the “automation queue”.

But if a customer were to message SAP with this problem, you all know what the response would be.

And therefore, I’m thinking that maybe if SAP Mentors were willing to review such cases, SAP might be willing to listen if a certain number of mentors agreed that the problem was probably on SAP’s side, even though the problem only shows up when customer-written code is executing.

Personally, I would be happy to review a certain number of such cases per year because:

a) it’s usually very easy to tell right away if the customer is really at fault;

b) if the customer doesn’t seem to be at fault, then the problem is probably an interesting one that’s worth anyone’s time to look at.

You must be Logged on to comment or reply to a post.
  • Its an interesting thought. The problem comes when, as is inevitable, the notion seeps outside the problems associated purely with code. I think you’d need some very clear params around which to make this a viable proposition. Having said that, I really like the thinking (as a buy side guy, that is.)
    • Dennis –

      Glad you see potential in it.

      Regarding “purpose creep” – yeah, that’s always a danger.  It wouldn’t make sense and it wouldn’t be a good idea to have SAP Mentors testifying on whether SAP-delivered functionality does or doesn’t cover all bases.


      • “SAP-delivered functionality does or doesn’t cover all bases.” I see business opportunities there, for SAP to improve its products, for partners to improve SAP products and for customers to know more what they really can get. Interacting with people SAP inside, SAP Mentors could be a critical piece of this. Thanks David, one more time your blogs are debate triggering focused.
        • Thanks for the kind words, Ignacio.

          I see your point, but I think that with Sapphire and the UG’s etc, there is a lot of machinery in place for what you’re talking about.

          But since I’m not on the functional side of the fence, maybe I’m not qualified to assess the validity of what you’re saying.

          Best as always

  • Unless SAP lets you into a customer’s system, and assumes the security risk – this is hard to put in practice.

    Also, I am not sure if SAP would like to be in a position where their support says it is a customer problem and an indpendent expert says it is SAP’s problem.

    • Hey Vijay –

      I think that a lot of times – most times – evaluation of the salient issues would not require invasive presence.

      Regarding your second point – I think it misses the point.  As a company that must husband its development resources carefully, SAP must stake out an “absolutist” initial position that it does not do “free” investigations of any situation arising from use of a customer exit.

      But SAP is far too intelligent a company to mistake a position which it adopts for purely practical purposes with the actual truth in any given situation.

      And that’s where the mentors come in – to provide neutral third-party expert opinion on whether SAP code is performing as it should, and if not, whether the misfire is important enough for SAP to devote some resources to.

      In any event, thanks for taking the time to respond.


      • I am probably missing the point.

        Most people any way don’t take SAP’s “NO” for an answer if it comes from L1 support. Also, if the customer can prove logically that it is SAP’s fault – I am sure SAP will fix it in most cases.

        Are you saying that SAP mentors can help those customers who cannot logically prove this for themselves?

        • No, Vijay.

          First, in the cases where the customer has a valid point that SAP should probably be concerned with (because there’s an inconsistency in SAP codee), I’m saying that if SAP Mentors are willing to serve as “buffers” or “filters”, then it’s a win-win all around, because customers AND SAP support personnel don’t have to go thru the dreary round of emails required for escalation.

          Second, I see the mentors as providing a firewall for SAP as well as tunnels through it.  There are customers (not my present client) who have naively hired consultants and given them access keys to do horrendous things to bring projects in “on or below budget”. 

          And oddly enough, having burned their own toast, this kind of customer is quite likely to pester SAP for “free” evaluations because they don’t want to admit that a project came in on time/on budget due to short-cuts that should never have been taken in the first place.

          Again, thanks for taking the time to tease this one out.


          • Hey Vijay –

            Glad the point has been clarified and amplified – thanks for your help.

            No – I don’t tend to hit SAP over the head with these 2×4’s – I’ve found that if anyone surfaces a good idea at SDN and there’s some community support for it, then there are “hidden hands” behind SDN that see to it that the ideas get to the right places.

            Actually, the hands aren’t so hidden.  They belong to Mark F and Craig and Marilyn, as everybody knows.

  • I’m a developer at a client site.  I can see where this would be a huge help.   For instance, at one point a co-worker of mine had to prove to SAP support that the problem was not with the code she had added for scheduling a line on a sales order.  She literally found the mistake – corrected the SAP code and then had to have SAP fix it, as we require high level approval if we change SAP code.   It might have gone a lot quicker if we could have had a mentor as someone to help.   As far as security – this problem could have been tested on any 4.6C system.  Great Idea!


  • Hi David,

    as the support person I actually am I don’t agree with your idea nor with the arguments of this discussion.

    First of all your assumptions are wrong:

    “a) it’s usually very easy to tell right away if the customer is really at fault;”

    Most of the messages where there is a dispute about weather it’s SAPs fault or the fault of the customer are NOT easy to decide. Very often it’s difficult to figure out where the expectation of the customer about a certain functionality differs from what is actually delivered and why.

    For the few easy cases – well the SDN forum is already an option to put How To questions to.

    “b) if the customer doesn’t seem to be at fault, then the problem is probably an interesting one that’s worth anyone’s time to look at.”

    That one is true – if there is a bug somewhere that is unavoidable to hit and that affects the functionality/stability of the product implementation – than it does make sense to actually fix it.
    If a problem arises that happens due to very unusual usage of the technology (that is: close on the edge of doing things plain wrong), than it may be the better choice not to change the platform but the way it is used.

    In general in the SAP support landscape there are so many ways to raise the importance of a message, reopen it, escalate it etc.
    If a customer does want to have its problem checked over again to get a second opinion – he will always have it.
    Also on the “inside” of the SAP support there are many options located already on primary support level to ensure that product errors are analyzed and fixed correctly.

    I really don’t see how just another way to urge a message will do any good for customers.

    On the other hand, the Mentors are in a good position to answer How-To questions and give hints on how to proceed with problems and questions. They can also provide general feedback to development and support if they realize systematic problems or opportunities to enhance things.

    But as you may have noticed – many of the SAP Mentors work for the same company: SAP. They will be just as objective as anybody at SAP.


    • Hi Lars –

      Thanks so much for taking the time to reply.  Perspective from 180-degrees is always useful as well as interesting.

      There are three things I would like to say in response.

      First, the real problem lies in time and effort it currently takes to get SAP support to actually take the critical step of logging in to the client system and seeing a problem “first-hand”.

      And why is this so? It’s because the “First Principle” is that if SAP Support has to traverse user exit code in the debugger, then SAP Support is not going to log in to the client system for free without a whole lot of what you call “urging”.

      So to me, the advantage of the mentors as intermediates is to provide an honest broker that both sides can trust.  If a mentor tells SAP Support that it’s probably a good idea to log in for free, that’s a lot different than a client saying the same thing.

      Second, “how to’s” have NOTHING to do with this topic, and I’m surprised you brought it up.  We’re talking about situations in which folks not only know exactly what they’re doing, but have also taken pains to write their enhancements “by the book” – without resorting to access keys or access to memory structures that SAP happens to have accidentally made available. 

      For example, here’s a case of the kind I think you’re talking about (pushing the envelope.) Last year I made use of the fact that in its PM notification exits, SAP will actually accept changes that a customer makes to crtiical structures which SAP passes to the customer.  I had to do this because time was short, but I didn’t like it.  I would have preferred to update custom fields in the BAdI, rather than taking advantage of the fact that SAP will update wiht my changes in its own task.

      Your point about the cases being more hard to decide than easy to decide – it’s kind of similar to the point Dennis Howlett made, and I don’t think it’s valid the way you say it either.

      Neither SAP nor a mentor should ever get involved in an issue which involves issues like “desirable screen navigation” or “how much data should be on an SAP-delivered tab”.  The SAP product is what is, and customers should go thru the user-group wishlist process to get changes that don’t involve actual errors.

      Once you factor out the customers who are trying to use the support process to change the product, I have to say again that I think the cases are easy to decide.

      Anyway, it’s great to have the ooportunity to bat these issues around with you.


  • Before the advent of products like ShareView, the question of how to let “foreigners” into your system was much more serious.

    With the advent of such products, an SAP mentor could safely watch a debugging session and get all the information he or she needs for an evaluation of the problem.

    Hey – I think there might be something here for SAP to think about in general.  Kind of a “freebie preview” thing, if the customer is OK with it.

  • Hi,

    There a couple of reasons why this idea is not feasible:
    – mentorship is still a case of volunteers who are doing things – in my case – in their scarce free time and I don’t see an additional task with high responsibility feasible.
    – volunteership -> is not paid whereas as the support – customer relationship is commercial. I don’t how things can be mixed
    – there might be conflict of interest. Who’s side will a mentor choose in a situation where both parties feel that they’re right? A independent ombudsman is needed
    – the mentor is not always the correct person to judge on things. He doesn’t know the customer’s situation and maybe he doesn’t know the product that good
    – mentorship concerns SCN and is general purpose based whereas ombudsman task are customer case based
    – …


    • Hi Eddy –

      Thanks for taking the time to reply. 

      On the one hand, I think your objections are all at least partly valid.

      But on the other, I think they point the way toward structuring this idea so that it CAN work.

      The key her is ShareView – or any other product that does the same thing.

      Suppose that SAP Support agrees in certain cases to a ShareView session, so that they can see what’s going on at the client site without getting access and logging in.

      Then when such a session is scheduled with a particular SAP support person, the SAP support person COULD post a notice of the upcoming session somewhere at SDN, so that any mentor with expertise in the given area could join the session.  The SAP support person wouldn’t HAVE to do this – if he or she wanted to get a mentor in on the session, then that’s fine.  If not, that’s fine also.

      Same way with the mentors -completely voluntary.
      Even if they have expertise, they don’t HAVE to join an upcoming session – it’s up to them.

      So there are two ideas here:

      1) incorporating ShareView sessions into the SAP support escalation chain;l

      2) getting mentors involved if SAP Support personnel would like them involved.

      Note that in regard to idea (2), it would be a very cost-effective way for SAP to “add” expertise to the consideration of any given problem.

      As always, best regards

      • How can you rely on mentors when you let the option open if they can join session or not? At the other hand you kinda make it a moral duty for mentors to help out, otherwise the customer will look down on them. And I’m sure that they want some commitment too. I think one can’t demand this from a mentor, since it is not his task.
        Sure it’s cost effecttive, since the mentors are not paid. I think that SAP customers pay enough for the products and support and can expect some decent support in return and not have to rely on the goodwill of a mentor.
        • Eddy –

          You know all the talk we always hear about “software engineers” being professionals like doctors, lawyers, engineers, and CPA’s.

          Well, if so, then software engineers should be expected to do “pro bono” work for the good of some community, just like other professionals.

          Plus, many large software and consulting companies already make some minimum time available for charitable work if an employee chooses to do it – like work on Habitat for Humanity houses, etc.  So they could easily make the same kind of time available for mentor work in the SDN community, if that’s the kind of “charity” the mentor chooses to do.

          So I have to say I disagree – I think there should be a little bit of a “moral” burden on mentors to “pitch-in” (even when there’s no chance of “fun in the sun” at TechEd’s or Sapphire’s – heh heh heh.)

  • I’m sorry but there is one big point that speaks against your thesis. Security. I saw that lots of mentors are NOT from SAP. Do you really expect a customer to transmit information about the usage of a specific customer exit in your SAP system to anyone who is registered as a SAP mentor that may even come from another rival company? And to analyze if a problem is an SAP problem or a customer problem is not a task you can perform within an hour of watching a debug session.
    I saw lots of problems I opened a customer meaasge for (after a detailed analysis of the problem) that came out as self made problems.
    And I guess SAP will not charge any costs for analyzing the problem to the customer if the problem is finally a problem within the software (doesn’t even need to be SAP, the DB, the office products or other software can cause the problem too).
    I have seen a lot of customer messages from customers who were asking for support for an SAP error even if there were errors in their coding or customizing. I’ve even solved a lot of these problems. But I also remember customer messages with sentences like “You don’t need to analyze the customizing, we had two experts from <…> doing this.”
    If SAP was really strict about this there would be many more customer messages flagged remote consulting. If you have a problem like this and you really want SAP to find a solution you could agree that you take over the costs if the error is in your coding. Otherwise you have a case where the software was running before your modification but didn’t run afterwards. Most people would automatically assume that it was the programmers fault, not SAPs. So it’s your choice if you’re willing to pay if SAP proves you wrong.

    BTW if in the above example (that I cannot really evaluate) the problem is solved by a breakpoint and you think that it’s a timing issue, did you try to built in a “WAIT FOR 1 SECOND” statement?

    • Actually, Dirk, I think that a lot of the problems would go away if SAP would just make use of ShareView sessions in the “escalation process”.  If this thread has been of any use at all, it may be because it at least surfaced that idea.  A lot of information can be gotten from a ShareView session, without all the overhead of a system login, etc.

      I also like your idea of getting an evaluation QUICKLY if the customer is willing to pay for the evaluation time if SAP proves it’s not an SAP problem.

      Regarding the WAIT – of course I thought about it.  I’ve had to do this in a QM custom exit because the SAP internal tables were not getting refreshed quickly enough, and also in a MIGO exit.

      But even if this “fixes” the problem, it doesn’t fix it for real.  Because there is no reason why the behavior of SAP code should differ between an ME51n “create from scratch” and an ME51n “create via adopt”.

      In the meantime, I will talk to the client here about your idea of asking for an evaluation and paying later if and only if the problem is not SAP’s.

      Thanks for taking the time to respond –