Can running SD-rescheduling and MRP jobs concurrently cause issues?

Hi Folks,

since activating the option to "Process stock transfer docs" in the nightly SD-rescheduling job we've run into problems with getting the following dump in a 740/SP11 system:


The dump happens in form purreq_update (include LV03RFOP) when a purchase requisition cannot be found during this FM call:

* Read original item from database -----------------------------------*
            i_banfn                 = exp_banfn
            i_bnfpo                 = exp_bnfpo
            i_no_account_assignment = exp_no_account_assignment
            e_eban                  = imp_db_eban
*           E_EBKN                  =
*           E_UPDKZ                 =
            not_found               = 1
            OTHERS                  = 2.
  CASE sy-subrc.
    WHEN 1.
    WHEN 2.

In the FM, the "NOT_FOUND" gets raised straightforwardly when a SELECT from EBAN doesn't find the entry:

*- Lesen Bestellanforderung von der Datenbank --------------------------
    SELECT SINGLE * FROM eban WHERE banfn = i_banfn
                              AND   bnfpo = i_bnfpo.
    IF sy-subrc NE 0.
      MESSAGE e101(w5) WITH i_banfn i_bnfpo RAISING not_found. "101170

We can identify the problematic BANFN in the dump and it really doesn't exist in EBAN (but, we were also able to tell that it had existed at the end of January when we did a system copy from PROD to our QA-system in which it still exists).

During our discussions to find out what could be causing this, we learned, that - under certain conditions - purchase requisitions routinely get physically deleted from EBAN during MRP-runs when the system determines that they are no longer needed. So "a missing BANFN" doesn't seem to be a problem in general.

What I'm now wondering, however, is the following:

Could it be that the long and concurrently running SD-rescheduling and MRP jobs are causing issues for each other? Could it be that the rescheduling job builds its "worklist" including stock transfer docs and the MRP job afterwards interferes with deleting some related purchase requestions from EBAN so that they've gone AWOL by the time the above mentioned FM gets called from rescheduling?

The rescheduling job doesn't seem to dump when it's run during the day with "Process stock transfer docs" and no MRP-runs are being executed at the same time. As we've thus far only tried this once, this could obviously also just be a coincidence.

What I'd like to get a better handle on - as this is quite a "moving target" - is whether or not we are at least on the right track or whether we need to look at something else instead or in addition. I already tried finding information here and in but didn't have any luck thus far.

Thanks for any pointers you may have!



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    Mar 27, 2017 at 03:12 PM

    Yes, both job running in parallel may cause problems.

    For performance reasons, MRP does not lock the planning elements and it can simply delete a purchase requisition that is not firmed. So it may happen that both jobs are trying to process the same requisition at the same time and that it gets deleted by MRP, causing the short dump.

    Therefore, I wouldn't recommend you to both jobs at the same time. Even if you don't see a short dump, the run MRP can affect the results of the SD rescheduling job, so I would always run it after the MRP run.



    Add comment
    10|10000 characters needed characters exceeded

    • Thanks for your response, Caetano!

      Through some more analysis of the nightly job runs, it really became apparent that the MRP-runs are interfering with the rescheduling (for once, we were really happy that we got a dump as expected!). We will try to change the job-scheduling to make sure that these jobs no longer run at the same time - hopefully the night will have enough hours to make this feasible. Otherwise we also may have to look at overall performance issues for this processing.



  • Mar 24, 2017 at 03:29 PM

    Not sure whether you checked the related material master data for MRP views whether all the required fields are maintained before executing this MRP run. Also, BANFN would be blank if a PO has been generated and in your case, did you check this? Normally, there were some instances where if MRP controller is blank and if you run MRP, then system would give some dump error. Also, it would be ideal if there is a gap between the two jobs say for two or three hours depending upon the volume of the data

    Add comment
    10|10000 characters needed characters exceeded

    • Thanks for your response, G Lakshmipathi!

      What I should perhaps have added to my question is, that I don't know much about the general processes of MRP runs and SD-rescheduling. I'm looking into this "bottom up" from the code and dump side of things because my colleagues from the process teams asked for help in trying to figure out why we get these dumps during the SD-rescheduling now, that more data gets taken into account.

      So, I'll collect comments made here and then discuss them with my colleagues.



  • Mar 24, 2017 at 07:11 PM

    It seems you are using "transport purchase requisitions". I'm not familiar with them, so can't comment on that process specifically.

    Running "concurrently" should not be an issue, although I'd make these steps of the same job to ensure that the first step finishes before the next one starts. If they ran simultaneously that most likely would've been a problem.

    Because the short dump occurs in standard SAP program, you can contact SAP Support about this. If it's a valid business scenario then it should not cause a short dump.

    Add comment
    10|10000 characters needed characters exceeded

    • You don't have to recreate the issue for SAP to investigate. As I said, if it's a valid scenario then it simply should not cause a short dump. Instead it should just show a plain message in the log (or do nothing at all). The information in the short dump and change logs should be sufficient to analyze what happened.

      If this is something you should be doing differently then at least you'll get an explanation. E.g. "this is a critical error because so-and-so".

      As far as I prefer not to deal with SAP Support myself, it just seems very unlikely someone on SCN had the same exact experience and they happen to check the questions posted here.

Skip to Content