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

[BaerbelWinkler]

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:

MESSAGE_TYPE_X in SAPLV03R

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 -----------------------------------*
  CALL FUNCTION 'ME_READ_REQUISITION_EXT'
       EXPORTING
            i_banfn                 = exp_banfn
            i_bnfpo                 = exp_bnfpo
            i_no_account_assignment = exp_no_account_assignment
       IMPORTING
            e_eban                  = imp_db_eban
*           E_EBKN                  =
*           E_UPDKZ                 =
       EXCEPTIONS
            not_found               = 1
            OTHERS                  = 2.
  CASE sy-subrc.
    WHEN 1.
      MESSAGE x026(01) WITH 'ME_READ_REQUISITION_EXT'
                            'NOT_FOUND'.
    WHEN 2.
      MESSAGE x026(01) WITH 'ME_READ_REQUISITION_EXT'
                            'OTHERS'.
  ENDCASE.

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
      EXIT.
    ENDIF.

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 service.SAP.com but didn't have any luck thus far.

Thanks for any pointers you may have!

Cheers

Baerbel

[Caetano · Accepted solution]

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.

Regards,

Caetano

[BaerbelWinkler · Accepted solution]

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.

Cheers

Baerbel

[Jelena]

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.

[BaerbelWinkler]

Thanks, Jelena!

Running the rescheduling and MRP jobs consecutively instead of concurrently would most likely cause other issues, because the various jobs are running fairly long all told and the night might not have enoug hours to get through all of them running sequentially.

Contacting SAP via OSS is on the plate but it'll be difficult to get a response as it's a) just happening in the productive system and b) cannot easily be reproduced.

Cheers

Baerbel

[Jelena]

Sorry, mixed up "concurrently" with "consecutively", doh! What you are describing is not normal IMHO in general. You might want to check for existing SAP notes regarding performance (I believe there were plenty for MRP) and work with your Basis team to find what exactly is causing poor performance. You might need to look at the whole picture instead of 1-2 specific problems.

Edit: SAP can access your productive system and because you have a short dump it should already provide them with some information.

[BaerbelWinkler]

Yes, I know that SAP can access all of our systems if we open them up. From past experience with OSS-messages I'm however aware that one of the first things they ask for are the steps to reproduce an issue. This is something we cannot provide in this particular case as we don't really know if the ABEND will happen and if it does, if it's always the same situation with the data (most likely not). Troubleshooting an issue like this one is always lots of fun as it's such a moving target!

This lack of easy reproducability is one of the main reasons, I thought I'd try via SAP Community first to see if others have run into this type of issue before and to gather as much information as possible before putting an OSS message together.

At the moment it's really just a hunch that the two strains of processing may be interfering with each other.

Cheers

Baerbel

[Jelena]

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.

[Lakshmipathi]

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

[BaerbelWinkler]

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.

Cheers

Baerbel