Skip to Content

The great thing about being technical developers is that “ours is not to reason why, ours is just to do or die” (just like the Light Brigade, come to think of it.)   And having the new-found power of implicit enhancement makes this even more true  – a functional objective can be well-conceived, mis-conceived, or ill-conceived – it doesn’t matter – it can still be accomplished by implicit enhancement, so long as you’re willing to read SAP code long enough and carefully enough. 

And therefore,  it is quite possible that sometimes, instead of being successful Bengal Lancers, implicit enhancers can wind up more like the cavalrymen of the Light Brigade, forced into the valley of “depth” because a particular functional goal cannot be achieved without setting hooks into SAP code that are perhaps, set way to deep to be really “safe”.

As a possible case in point, I want to outline a particular functional objective that was recently achieved at a  ECC 6.0 client and the implicit enhancements that were required to achieve this goal.  As a technical developer, I am not and can not pass any judgment on whether the functional objective was“good” or “bad”, but I can say that the implicit enhancements needed to accomplish this objective were extremely interesting, in the sense that they taught me more about the internals of SAP MRP (MD01/2/3) than I ever thought I’d haveto know or need to know.

So I leave it entirely up to you as readers to decide what you think – did this project bring further glory to the Implicit Enhancers, or was it an ill-conceived charge into the “Valley of Depth” – into those deeply buried nooks and crannies of SAP code where none should dare to go?

Functional Spec: 

At first glance, the functional objective seems quite simple – when SAP generates new Schedule Lines and PurchReqs during an MRP run, decide whether these are already “pegged” properly to the right “projects” (think POSKI’s), and if not, do the following: 1) if a newly-generated purchase req is not properly pegged, figure out how it should have been pegged and call a BAPI to change the bednr; 2) if a newly generated SchedLine has not been properly pegged (i.e. is attached to a SchedAgreement referencing a different project), then try to find a SchedAgreement that the line can be properly attached to – if you find one, reassign the line to that Agreement, and if you don’t, recreate the SchedLine as a PR (in either case, remove the SchedLine from the origina Agreement), 3) make sure that the create_indicator  (estkz)in the new PR or re-assigned SchedLine is set to “B” and the new “fixed” indicator  (fixkz) is not “on”;4) only do all of (1-3) when SAP has marked the PR or SchedLine “new” (aussl or oldsl = N1-N4.)

 Technical Design:

To accomplish these goals, it was necessary to examine MRP code in order to determine where to to three kinds of implicit enhancements:

First, during the SAP run itself, where to collect the MDPS lines that SAP has marked new  (Call this the Collection Point.)

Second, where to call the custom code at the end of the SAP MRP run after SAP has “dequeued” the run (this is not as simple as it first sounds, because the flows of MD01, MD02, and MD03 are different, and within MD02 and MD03, there are subflows depending on various “simulation” or “display before save” selection screen options.  (Call these points the Invocation Points.)

Third, when the custom code calls the relevant  BAPIs to reassign schedlines (i.e. create new schedlines within different agreements) or create new PRs, where to circumvent the SAP code that wants to make the create-indicator “R” and the fixed indicator “X” .  (Call these the “FakeOutSAP Points”.)

Here is where we put the Collection Point, Invocation Points, and FakeOutSAP Points.  And as I said earlier, readers can decide for themselves how wise these choices were, i.e. whether we perhaps charged a little too far into the “Valley of Depth”.

Collection Point

We put this at the end of the SAP function HINZUFUEGEN_NEW_DISPOSITION, which is always invoked in the course of MD01/2/3 invocation, and in fact, is one of the last “common” places these transactions visit.

Invocation Points

To cover all bases in MD01/MD02/MD03, we had to put our invocation points at the end of four different SAPMM61X forms:







( And of course, we had to make sure that no two of these four were ever both hit in the course of any MD01/2/3 run of any “flavor”.)


FakeOutSAP Points:


A bunch of these proved to be necessary in the MEOUT and MEREQ function groups:


Include LMEOUTP14, class lcl_instance_factory, beginning of post method

Include LMEREQF32, class lcl_r_estkz, beginning of Is_valid method

Include LMEREQF51, class lcl_r_fixkz, beginning of is_valid method

Include LMEREQF56, class lcl_r_hd_extkz, beginning of is_valid method


(So many of these were necessary, because SAP code seems to have been understandably written to enforce the following rule: “if SAP didn’t create this object, make extkx “R” (manual) and turn on “fixkz” (fixed.))

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    My vote would be too dangerous.  It seems like a lot of code to change in SAP.  And it’s doing some critical things.

    If you business decides to go a different direction – these changes are not transparent.  Of course one would hope testing would catch the problem.

    However, I think you’ll know the truth after an upgrade or a note/hotpack that changes the SAP code.  How much rework will you have?   It’s anyone’s guess.

    But – a business requirement is just that a business requirement.  Not a technical requirement.   Short of cloning the program – which would be bad too.   Or changing the business process – not an option.   This seems like a good idea.

    Long answer – but – I guess what I’m trying to say is that it is dangerous, but needed.


  2. David Halitsky
    Hi Michelle – thanks for taking the time to venture your opinion …

    Actually, there is a third alternative apart from the enhancement option and clone option.

    This is for SAP to rewrite SAP as a transparent consumer of services that are: a) decoupled as far as possible; b) transparent with respect to dependencies that can’t be decoupled.

    Perhaps it’s escaped SAP’s attention that some innocent-sounding, seemingly “unitary” transactions like MD01 are really huge “business processes” in and of themselves.

    And as such, shouldn’t they be subject to the same SOA-oriented re-engineering as overly complex business processes of SAP’s customers?

    I mean, I once wrote a whole blog post here entitled “Was dem einem recht ist, ist dem anderen billig”, and this seems to be another case where that proverb is also valid.

    (English translation: “What’s sauce for the goose is sauce for the gander” …

    1. Thorsten Franz
      Hi David,
      It’s good of you to point out the third alternative of a SOA-like refactoring/reengineering of the functionality into reusable, service-like units.
      However, I couldn’t help but notice that if they do it now, after your enhancing ride into the valley of depth, you’ll be in trouble. 😉 But it wouldn’t be your fault.
      A fourth alternative would be the introduction of release-stable explicit enhancement spots such as BAdIs by SAP. These would allow you to enhance the business process in a more reliable way. I have made the experience that SAP has often introduced BAdIs upon our request, so you could give this a try, too.
      1. David Halitsky
        Hi Thorsten – there’s a good reason why SAP may well not want to provide BAdI’s in this case.  When I was done with this project, one of the functionals commented “who needs GDP – we have you?”  Now I don’t understand anything about GDP except that the current client refused it – in particular, I don’t know whether it’s sold as a layered product on top of ECC or comes “free” within ECC.  But if it IS a layered product that must be purchased by the client, and if my enhancements do actually accomplish some substantial portion of what GDP does, then its “dollars to donuts” SAP ain’t gonna bite its own hand by handing out BAdIs to give clients an even better reason to refuse GDP. 
        1. Thorsten Franz
          Thank you for explaining – I wasn’t aware of that. In fact, I have not the slightest idea what GDP means in an SAP context, and my Google search for “SAP GDP” came up with an article titled “Mexico Violence May Sap 3% of GDP as Gangs Flourish”, which is likely not going to shed more light on the question.
          1. David Halitsky

            Also: if you google the word combination “SAP pegging GPD” (without quotes), you’ll get a host of links.

            You know – this post might interest SAP clients in GPD, but it also might interest them in ME as an alternative … heh heh heh just kidding …

            Well, not really kidding – I sent my resume in a few weeks ago to one of the SAP SolArch positions that occasionally comes open, and haven’t heard a word. 

            But I’ll bet I spec’d out my MRP enhancements as fast or faster than any current SAP SolArch (two weeks total to fix the tech design – longer to code, of course …)

            Anyway – don’t be offended – I really didn’t mean to take advantage of your response here to “toot my own horn” … well yes, I guess I did … heh heh heh

          2. David Halitsky
            Whoops – no wonder you didn’t know what “SAP GDP” was … I had a senior moment and typo’d “GDP” for “GPD” in my first post … maybe SAP is right – maybe I’m over the hill and too old to be an SAP SolArch …!!!!

Leave a Reply