"What's in My Transport?!"
- by Tom Spetnagel, Senior FI/CO Configurator, Cox Target Media
- June 15, 2004
During configuration, a transport (or change request) can pick up more changes than the configurator intended, thus causing system errors. The author explains the potential for mistakes and how to avoid them when using automatic change requests in the Change and Transport System (CTS).
Not too long ago, an experienced R/3 configurator came running over to me with a panicked look on his face and said, "All the inventory postings are suddenly going to the wrong G/L accounts in the production system! I don't know what happened. I only transported one MM account assignment change last night!" To his credit, he had indeed followed the standard configuration protocol used at most R/3 sites: make a configuration change, successfully test that change in the development and quality assurance systems, and then move it to production. So what went wrong? Two things.
First, the automatic change request generated by the Change and Transport System (CTS) picked up more than just the single account change that my colleague had made. It picked up the entire set of G/L account assignments within that area of configuration. Second, my colleague never checked the contents of his change request to ensure that it contained what he thought it should. He thus unwittingly transported other configuration changes along with his own, something that his testing did not reveal because he tested only the change he had made.
Let me show you how to avoid the situation I just described. You will learn how the CTS system works for configuration, what problems can occur when using automatic change requests, and how you can overcome these problems by displaying and editing the contents of transports (the common term used for describing change requests).
Would you like to see this full item?