Skip to Content

Improving Interlinking Action in VMS

Multiple elementary action can be linked together via Interlinking Actions in VMS. When an Interlinking Actions is fired all the elementary actions are executed as per the order defined in configuration.

It is a great idea to minimize turnaround time. Without leaving the main program, system is capable of performing all the actions required. With Interlinking Actions, users fire only 1 action to carry out series of tasks, which is helpful as they do not have to remember the sequence and in error will not break the sequence of operations. Also, if Interlinking Action is triggered via an External System, only one call can carry out all the actions.

However, there is a limitation of Interlinking Actions. Consider a scenario where an Interlinking Action INTA, has 3 elementary actions assigned ORD1, GORE and INIV. I am taking SAP defined elementary actions to give more clarity in the example taken. The limitation, which I’ll highlight, may not be replicated using these actions specifically.



Old Status

New Status













If action INTA runs successfully till the end, the vehicle will move from status X010 to X040 and would have created a purchase order, goods receipt and invoice verification.

But, if action INTA fails mid-way e.g. during GORE action i.e. only ORD1 has been executed. The reason for failure could be anything, posting period, object locking etc. The vehicle’s status would become X020 and Interlinking Action INTA will return an error. Vehicle will have a purchase order created and remain pending for GORE and INIV actions.

Now, if INT1 action is executed again, VMS will not allow it as to start INTA, the vehicle must be at X010 status.  User will have to execute the remaining actions one by one, which needs user to remember the action sequences for interlinking actions.

Due to this problem in past implementations, I resorted to developing a custom program to clean up such vehicles. The program would read vehicle’s status from VLCVEHICLE table and determine whether last status (as per Interlinking action’s configuration) has been achieved or not. If not, then program will carry out remaining actions using BAPI_VEHICLE_CHANGE_MULTIPLE.

An improvement in the standard design of SAP VMS for interlinking action to counter above scenario would save a custom development and time.

VMS engine already identifies upon action execution whether the fired action is an Interlinking or an Elementary action, so in case an Interlinking action fails, either system should roll back all the actions done successfully prior to failure and bring vehicle to the state where it was before firing the interlinking action (status X010 and deletion of purchase order in our case) or an Interlinking Action should be able to determine the spot from where it has to start the sequence of actions. In our example, re-firing INT1 will only carry out GORE and INIV as ORD1 is already completed.

The above options can also be made available in configuration as a choice where one can choose to either roll back or enable re-firing of an interlinking action to counter the problem.

I would like to know if anyone else has encountered similar problem and how it was resolved. Also I would like to see suggestions from other experts on how to build this functionality in a better way.

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

      I am looking for an improvement which can encounter the scenario mentioned in the post. The current working is not bad and I don't want that to alter, but an improvement to address any half way failures.

      Best regards,


      • Hi Rohit,

        1] We use lot of interlinking action but we hardly face any frequent failure between actions, if you are facing this problem very frequently then you can develop  action preparation BADI and do check in advance on data consistency that is required for all interlinking actions to be carried out which will make sure that none of the elementary action will fail if the interlinking actions is allowed. Or May be you can solve this by doing compete testing since its uncommon to have the situation you said.

        2] Concept of interlinking action is also linked with the user inputs screen in VELO, the screen is designed in such a way that all the user inputs are taken on single screen required for all subsequent actions. Hence screen and its processing is different for interlinking and elementary action. Hence processing cannot be jumped .

        3] The architecture of VMS is based on action matrix customisation which works on primary and secondary status and is basis of VMS engine. Now for every action either interlinking or elementary the action determination is carried out based on current status so if the status has changed because of halfway failure as you said the system will never determine that interlinking action again. Which is good to maintain the consistence of business process.

        I can suggest you to have  below solution for e.g you have interlinking action A which is allowed to be executed on status S1 and if executed successfully set the status  S2 with three elementary actions A1, A2 , and A3 with status like below

        S1 -> A1 -> SA1

        SA1 -> A2 -> SA2

        SA2 -> A3 -> S2

        Now this can fail in halfway at status SA1 or SA2. If it fails at SA2 its is ok since it will be covered by elementary action A3, but for process failed with SA1 you can create one more interlinking action as below

        Actions B for status e.g. SA1 -> B -> S2 which included  remaining actions to be carried on the vehicle i.e A2 and A3 ...this way for any interlinking action you can create number of actions - 2  new interlinking actions which will solve your issue

        Hope this will help you.



        • Hi,

          Thanks for taking time to respond with details.

          However regarding the point number 1, the failure scenarios not always account for data issues.  Consider the material locks occurring due to an interface feed (e.g. material master update while creating a goods movement by GORE), for such thing BAdi cant do much to prepare fail proof data.

          Next, the interlinking action may not only contain 3 elementary actions. In some cases you may end up having more actions lets say 6 or 8, in that case if we create interlinking actions as mentioned in point 3, it takes away all the essence of interlinking action functionality.

          I appreciate that you have not seen any frequent failures, but in couple of my projects I had seen them thus I was hoping for an improvement.

          Also, if you fire an Interlinking action via an incoming idoc, and it fails as per the scenario mentioned in the post, the idoc goes into error. So if we have the improvement as I pointed out, simply re-processing the idoc will solve the purpose.  That just one of the examples I am taking.

          However, I would like to discus one thing, what is the harm in having the improvement that we are discussing?


          Best Regards,


          • Hi,

            No harm as such, but it means huge cost of changing the VMS architecture. But still I feel its uncommon to have frequent failures in interlinking actions in VMS if

            if customization and everything is ok I do not see the need for additional efforts here.You can give more example of frequent failures then we can discuss the way to fix it permanently that is best way.

            For e.g frequent failures like material lock should not be issue in vehicles cases as its materials are batch managed with split valuation. Any way for material lock and performance issue while working on batch manage vehicles SAP recommends to set the flag No Update During Split Valuation on

            the Administration Data Update screen in the customizing transaction OMT0.



          • Hi,

            Yes you are right about the cost of modifying the SAP architecture. And I agree that it should be done if there are justifiable benefits to the customers.

            However, in my cases, it was just not the material locks. The vehicle object was also getting locked as number of interfaces were quite high. It was the simultaneous feeds received by SAP and triggering different processes at a time when interlinking action was in progress.

            Also, there was issues due to V1 and V2 updates to the database. And there were times, when VMS was updated and other modules' (MM in our case) database were little sluggish.

            I mean to say, there were too many reasons for why I went for a custom program to clear the failed vehicles as customizing and tightening of Z actions' function modules did not help. So, to have an inbuilt functionality, where SAP can manage the error scenarios, db updates, calls and commits etc. will help a long way. It will be an all around solution on Interlinking actions.

            Thanks, pleasure to have a good discussion with you Ganesh.

            Best Regards,


  • Hi Rohit,

      Nice document. Thanks for sharing. We faced similar issues with our client with very high number of vehicles transaction per day that too connected with lot of interfaces.

    Good solution for a client with bulk transactions and interfaces.


  • Nice document Rohit Chauhan, thanks for sharing it.

    Ganesh Sawant, Appreciate if you can share more on handling locking material while creating vehicle using OMT0. If i set this indicator i and create a vehicle while material is open in MM02 i get instant error material data is locked by my id , but if I don't set this indicator and try to execute vehicle creation i can see a processing icon for a long time no error but no success either.

    Not sure if i am doing some thing wrong, initially i though you are saying if i set this indicator , system will create vehicle even tough material master is open in MM02.

    Can you please reply.