When you are new at sap developments, a brief overall description of the Transport system can be useful. The Transport system is there to move your developments (or whatever other damage you or anyone else can do in SAP) to other systems. Roughly outlining this, it can be regarded as a huge interface system, but not only for data, also for objects like programs, menu's, screens, transaction codes, authorization objects, anything you like. There's hundreds of types of objects available for transportation. Like in any interface process: a file is created, which will (eventually) be picked up by the importing system.
When addressing Transport & Correction, consider the following: changes that are done or corrections that are made need to become available in other systems. These changes can be (customizing) settings or actual objects that have been modified. Since a functional change can result in a range of technical object changes, the whole package of corrections need to be "moved" as a whole.
A serious task with serious impact and a serious suite of tools to help you get the job done...
Some carefully picked bold statements on Transports that can be helpful in understanding the concepts:
.. can help you understand the ins and outs of transports. This example adresses a method that could help you understand any transport and correction problem. Here's a problem that I came across: we build SapScript forms that represented a letter that needed to go out to the customer. For this letter, a standard text was created and included in the SapScript. The idea behind this is that this standard text can be changed in the production system, without getting in another ABAP SapScript programmer. Standard texts can be maintained with transaction SO10 or R/3 -> Tools -> Word processing -> Standard texts.
When a standard text is created, no transport request is required because standard texts are not added to the transport system by default.
The transports you will be creating will be released and "moved" through the landscape. Transports can overtake each other or left out completely (which is the start phase of an overtaking transport) if not managed properly. So what is an overtaking transport ? When a transport is released, it can be imported into each system in the landscape. If we have 2 transport requests for the same object (a report) and only the second transport is imported, the latest version of the report is made available...
Move your functionality around with SAP's transport system, across systems ? Export your transport and simply pick it up from the server, to be imported elsewhere. A brief step-by-step instruction: First of all, you will need to "do your thing", which can effectively be anything, ending in a transport. The transport needs to be released. Released transports are stored in a data file and a cofile which can be found on the server.
When (after) a transport is released, it travels through the system landscape. Sometimes fully automatically, sometimes the basis people needs to do this - after approvals are available. In the life of a transport request, it can be available in the development system and a test system, but not yet on the production system. Also transport requests can be imported, and when needed they can be re-imported. All of these actions are logged per system in a file based setup. The logs are available in 1 location and 1 location only (they are not also migrated through the landscape). From SE10 these logs can be viewed.
The article on landscape travels explains in detail what can/should happen with transport requests. It's quite hard to pinpoint where the release sequence of transports has not been followed up, which is for many Abap technical objects a clear signal something may have gone wrong. Check out the report that is ready to run for you too.
The package (previously development class) to which your development is assigned will reflect on the Transport system... Have you come across $TMP ? I'm sure you have. $TMP is the package assignment which will not lead to any transport requests being assigned. When your developments are just for a test or proof of concept, you should chose "Local object" - which will result in a package assignment to $TMP.
Transporting development objects is much about bringing your objects across the available systems, how about removing such an object. It's a common misunderstanding that deleting a report cannot be transported. After all: when you delete a program the object to be transported is no longer available. But of course a program can be deleted...