SAP Transport Management: The correct use of preliminary imports and final imports

Solving sequence problems using standard SAP processes

Imagine a scenario in which you want to build a house out of prefabricated parts. Construction should proceed as quickly and seamlessly as possible. You therefore engage a haulage firm to deliver the individual components in such a sequence that they can be assembled immediately - so the parts for the ground floor arrive first, followed by those for the upper floor and finally the parts for the attic and roof.

However, once you have assembled all the prefabricated components for the ground floor, the next truck to arrive is the one with the parts for the roof, as the truck with the upper floor components broke down on the highway and was overtaken. Now, you could proceed with the construction of your house, but you should be aware of the fact that something has been missed out. Should the parts for the upper floor be delivered later, this delivery must be handled in a special way. The truck with the parts for the attic overtook the truck with the components for the upper floor, meaning it is an ‘overtaker’, which is to say it did not arrive in the planned sequence. Additional adjustments may be necessary as a result of this configuration, as attaching the roof at this stage was not originally envisaged, and therefore no appropriate tests were conducted. It should also be considered that in order to fit the upper floor, the attic and the roof must first be dismantled and subsequently reassembled.

The same applies in the SAP CTS: if transport objects are imported in a specific version even though the previous version of this object has not yet been imported, caution must be exercised! In these situations, it must always be ascertained as to whether the affected objects are functionally executable without the skipped object. If the decision to ignore a missing predecessor is only taken after quality assurance, it should also be noted that an untested combination of objects would then be implemented. In this case, an additional functional test on a pre-production system is strongly advised.

In order to be able to illustrate these kinds of scenarios, the TMS differentiates between two types of imports:

1. Transport requests, which do not deviate from the intended sequence (this is generally the export sequence and therefore also the sequence of the import queue of the subsequent system) can be imported finally without further special treatment. These subsequently imported requests are marked in the import queue with a green tick.

2. Transport requests containing objects from a previously released but not yet imported request (overtakers). Such requests should always and only be imported as a preliminary import, so as to facilitate adjustments at a later stage in case of an overtaker situation. This is done by placing a “Leave transport request in queue for later import” flag (I flag). Preliminarily imported requests are marked in the import queue with a yellow triangle.

When performing imports, it should generally be noted that possible existing (previously imported) overtakers relating to the request that is to be imported must always be imported as well, in order to avoid downgrades of individual objects. If these overtaker requests concern not yet imported predecessor requests, their import must be carried out as preliminary import.

For example:

Requests A, B, C and D are in a queue to be imported. No further requests are contained in the import queue. All four requests contain objects which are also present in each of the other requests. Requests A and D should now be imported. Request A can indeed be imported, but request D overtakes B and C, which is why the import of D must be carried out as a preliminary one. Otherwise, importing the objects from requests B and C at a later stage would lead to a downgrade of the objects contained within request D. If request B is subsequently imported, in this case request D must be imported once again. When request C is finally imported, request D must in turn be imported once more. This time, both requests can be imported finally, as there are no more missing predecessors for request D.

Correct usage of preliminary imports by SAP transport managers

In order to ensure the correct import sequence even through a chain consisting of several SAP systems or clients, the functionality of the preliminary import is not just limited to setting an I flag, which -after the import- makes the request available for further re-imports. The queue entries of the transport in the subsequent systems connected by the delivery routes are likewise affected. The entries generated in these queues are indicated with a F flag. This F flag marks those requests whose position in the import queue is considered as preliminary. This has the effect of moving these requests to the last position in the import queue if a re-import is carried out into the preceding system. It is thereby ensured that the import queue of the subsequent system always corresponds to the current import sequence of the preceding system. Final imports cannot be carried out on requests marked with an F flag - they are always available for further imports, as their position in the import queue may still change. The final import in the previous system moves these requests in turn to the end of the import queue of the subsequent system and removes the F flag, as the position in the import queue is now definitively fixed.

Further information regarding the meaning of individual flags in the import queue can be found in the “Controlling the import process with flags” article in this blog.