SAP Transport Sequence: Import Order and Overtakers

Decision context

SAP's import queue is ordered by release time, and importing in that order is the only thing that guarantees the newest released version of an object wins. Every deviation from the order is a decision to accept that guarantee no longer holds.

The failure has a name in most Basis teams: an overtaker. Request B was released after request A, both touch the same object, and B is imported first. When A is imported later it writes its older version over B's newer one. Nothing errors. The object simply goes backwards, usually discovered in testing days later.

The check is not complicated, it is just rarely done: before a selected import, compare the object list of what you are importing against the object lists of everything you are skipping. Adranum performs that overlap check from the object and dependency graph rather than by reading request headers.

Order rules that hold in every landscape

These are properties of how transports are applied, not conventions, so they hold regardless of the release or the tooling around them.

• Importing the full queue in order is always safe with respect to overtakers. Importing a subset never is, until the overlap has been checked.
• Dictionary objects must arrive before the code and content that depend on them, which is why splitting a dictionary change and its consuming code across two requests creates an ordering constraint you now have to manage by hand.
• Customizing and workbench requests can have dependencies in both directions. Configuration that references a custom object, and custom code that reads a configuration table, are both ordinary.
• A skipped request does not disappear. It stays in the queue and will eventually be imported, at which point its versions apply. The question is only whether that is what you want.
• Re-importing a request that was already imported does not restore anything newer. It reapplies the versions inside that request.

The overlap check before a selected import

This is the whole discipline. It takes minutes and prevents the class of defect that is hardest to diagnose afterwards, because the code in the target is valid, just old.

• List the objects in the requests you intend to import.
• List the objects in every request that sits earlier in the queue and is being skipped.
• Any object appearing in both lists is an overtaker candidate. Either import the earlier request too, or accept that it must be re-transported afterwards.
• Check the same overlap against requests still open in development, because those will be released after and will win, which may or may not be the intent.
• Record the decision. An out-of-order import that nobody wrote down becomes an unexplained version regression a month later.

Unconditional modes and what they suppress

The tp unconditional modes are entered in STMS as import options and each one switches off a specific safety check. They are legitimate in specific situations and dangerous as a habit, because each suppresses a warning that exists for a reason.

Verify the exact meaning against the TMS documentation for your release before using one in production. The commonly used modes are these.

• Mode 1, import a request again even though it has already been imported into this system.
• Mode 2, overwrite objects whose original system is the target, which is how an original gets replaced by a copy from elsewhere.
• Mode 6, overwrite objects in unconfirmed repairs.
• Mode 9, ignore the fact that the system is locked against imports.
• Every one of these should appear in the change record with a reason. A team that uses unconditional modes routinely has a process problem rather than a transport problem.

What the workflow must cover

• Object overlap analysis. Compare object lists across queued, skipped, and unreleased requests to identify overtaker candidates before the import runs.
• Dependency-aware ordering. Derive the required order from observed dictionary, code, and configuration dependencies rather than from release timestamps alone.
• Recorded deviations. Keep every out-of-order import and every unconditional mode as an explicit decision with a reason and an owner.
• Downgrade detection. Flag when an import would write an older version of an object over a newer one already present in the target.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Decide whether the whole queue can be imported in order.
2. If not, list the objects in the selected requests and in everything being skipped.
3. Resolve overlaps by adding requests to the import or scheduling a re-transport.
4. Record the deviation, the reason, and any unconditional mode used.
5. Verify the resulting object versions in the target after the import.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Queue order and release timestamps
• Object lists per request
• Overlap report
• Dependency constraints
• Import decision and reason
• Unconditional modes used
• Import log and return codes
• Post-import version check

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• Overlap analysis covers the objects a request declares. Dynamic behavior and generated content can still surprise you.
• Configuration dependencies between customizing and workbench requests are frequently undeclared and depend on how the team splits requests.
• No analysis removes the need to import the skipped requests eventually.

Buyer checklist

• Is the whole queue being imported, or a subset?
• Which objects appear in both the import and the skipped requests?
• Which dictionary changes must precede which code?
• Was any unconditional mode used, and why?
• How will the skipped requests be handled?