Skip to Content

Frequently updated Configurations

In this blog, I like to share the SAP provided option to skip migration path for frequently used configuration tasks

like Purchase group, MRP Controller, FI period, etc.

Lets take the example of Purchase group:

Purchase group ID are assigned to Procurement individuals with some contact details, who handles Purchasing

documents. In most business cases, you may come across frequent addition/exit of buyers, changes in business

role and contact details which leads to update the Purchase group configuration most frequently.

This configuration could be done directly in PRD instead of migrating it, by activating the current setting option.

System Settings:

– Use transaction SOBJ


– Select the related object and activate the current settings

For Purchase group, choose V_024 and V_024_N for printer assignment to Purchase group;



– Select the config task following SPRO > MM > Purchasing > Create Purchasing group


– Menu > Edit > Display IMG Activity


It will provide us with a transaction which could be used to for direct updates. Also refer the below notes for details.

For those, who follows weekly migration where business have to wait for a week to get this change updated, it will

reduce the lead time quite substantially.

Helpful Notes:

OSS Notes 356483

OSS Notes 135028

You must be Logged on to comment or reply to a post.
  • We are using this option too for purchasing groups and routes, and even for payment terms.

    We have to be very careful if we maintain customizing data in production system, everyone should know about that. We had a case where a new colleague was asked to create a new purchasing group. Already cumbersome that we got asked while business does it usually itself. But he created the pruchasing group with the next number in sequence and transported it as usual for other customizing from DEV via QA to PROD and had overwritten the current settings there.

    And on the other site, I always suffer with my data migrations for new rollouts, because all the customizing directly entered in production is not maintained in our test systems

    • Hi Jurgen and Ganesh,

      I just had a similar issue where someone migrated a type of configuration that is typically done directly in production. Does anyone know of a good way to prevent this? Is it possible to block transports that contain certain table records that should not be transported?


      • Yes Brian, transport link could be deactivated or switched off as mentioned in notes 356483. It's a valid point to be considered when someone try to utilize this option.

        I agree with Jurgen, on the other risk he highlighted that other environments will not be in sync. It might be controlled by the IT process you set to overcome this.

        - Ganesh