Skip to Content
avatar image
Former Member

Please advice how can I schedule 2 simultaneous interlinked movement types with 1 interface file.

Hi Team,

I get a single interface file from the warehouse with the good or bad status of the returns stock. As per the standard SAP process, I need to move the returns stock to blocked and then next movement should be to scrap or unrestricted based on the material status.

My requirement is I get a file and PI should post 2 simultaneous material documents from returns to blocked and then blocked to Unrest/ Scrap.

Can we make this possible with event creation or any other advice you could give? Or is it mandatory to have 2 different interfaces to make 2 different linked movement types? The problem here is 2nd movement should happen only after 1st movement is done.

Please advice.



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • avatar image
    Former Member
    Aug 17, 2017 at 12:25 PM

    Hi Jurgen,

    It also looks a bit new to me that our 3PL partner follows a weird process.

    The indication will not be in material master. We get the indicator in inbound file 1 where we post the stock to blocked with Reason for movement as Bad or Good stock based on the indicator.

    Another 2 material movements should happen based on triggering of the first movement.

    Hi Avik,

    Technically your answer looks ok for me. Need to check if it works practically.

    Thanks for both of you for the help. Keep you posted once its working.



    Add comment
    10|10000 characters needed characters exceeded

    • Please check the same and let us know. I have implemented similar solution where we had multiple SAP system and we had to go-live in phased manner.There for e.g. O2C is still happening in old R/3 system and Supply chain is in new ECC system,so we had to replicate material movement from R/3 to ECC based on interface till whole process goes live in New ECC box.

  • Aug 14, 2017 at 04:36 PM

    this might be a very special process at your end, for me is scrapping not an automatic follow on movement after stock got moved to blocked stock. There can be months between the both movements, and there could also be special sales instead of scrapping.

    To make something happen in a system you must have an indication that tells you what the follow on activity is. What do you get from the external system based on that you can know which follow on movement needs to be carried out?

    Also I never saw that a material status was used to control whether a return goes to scrapping or back into unrestricted use. How could you know this already when creating a material master?

    Add comment
    10|10000 characters needed characters exceeded

  • Aug 14, 2017 at 07:22 PM


    already few particular questions are asked by Jurgen.

    as per your message in question ,You get the interface file from warehouse with good and bad status of material (MMSTA).

    Is it a custom status which is already set on the material master when goods are returned and goes via quality inspection at GR level inside warehouse process and then based on the outcome; warehouse prepares this file? need more info about the warehouse inbound file and the process steps. However,if based on the input file if PI(middleware) just need to push two separate movement process as
    (trusting the input file)

    1) move to blocked stock

    2) move to scrap(if bad) or move to unrestricted.(if good),then it is classic interface scenario like serialization of idoc process.

    However,this can be looked at from two perspective. if volume is not too huge,then suggestion is to go for synchronous idoc posting.

    Prepare one wrapper FM which will do the input file processing at one shot.

    use FM: IDOC_INBOUND_SINGLE to post first inbound idoc, for example with msg type MBGMCR ->with certain mvt.typ to perform action of blocking. This idoc status needs to be tracked from EDIDS table,at runtime inside FM/program of inbound idoc file processing and based on latest counter pick the latest status of 1st IDOC, if it is '53' then go for next validation,else do not proceed.

    when status is '53' ->next step ->(if bad or if good) based on that post the 2nd INBOUND MBGMCR idoc with segment populated as per different mvt. typ for scrap or unrestricted . This time,no need to post the idoc immediately,i.e synchronous. This will help in better performance. 2nd idoc will stay in '64' status.Then schedule job of program RBDAPP01 with msg typ mbgmcr which will pick the '64' idocs and finally process them.

    if volume of the input file records are huge,then a custom serialization group can be planned to be adopted to tie together two related MBGMCR idocs.



    Add comment
    10|10000 characters needed characters exceeded