E070 table — Transport Request and Task Header Table

One row in E070 represents a single transport request or transport task, identified by TRKORR. A request created through SE09/SE10 gets its own header row, and every task released under it (one per developer working inside that request) gets its own separate header row too, linked back to the request through STRKORR. The row records what kind of request it is, its lifecycle status at the moment the table was last read, who owns it, when it was created or last touched, and the free-text description entered when the request was opened. E070 says nothing about which repository objects or customizing entries are inside the request, and nothing about whether the request has actually been imported into any downstream system. Those facts live elsewhere.

E070 has no client field, transport requests are cross-client objects that belong to the transport layer, not to a single client. There is no cheap way to scan it usefully without restricting on something: use TRFUNCTION plus TRSTATUS together to isolate open workbench requests versus released customizing requests, and use AS4DATE range plus AS4USER to bound a search to a specific incident window. The system-ID prefix inside TRKORR is a decent filter when hunting for requests created on a specific development system feeding a particular transport route. Full unrestricted reads against E070 in an old, heavily used landscape can return hundreds of thousands of rows and are rarely what the question actually needs.

Symptom: a developer insists a change was released and should be in the target system by now. Select E070 where TRKORR equals the request number quoted, check TRFUNCTION and TRSTATUS. If TRSTATUS shows released, that only proves release from the source client, not import. Next join to E071 on TRKORR to confirm the specific object the developer changed is actually listed inside that request, not accidentally left in a different open task under the same parent.

E070 is part of the Change and Transport System, which sits below the application layer and is essentially unchanged in structure between ECC and S/4HANA. The same header fields and the same request/task model apply on S/4HANA, including on-premise and typical private cloud editions. There is no compatibility view layer over E070 in the way many application tables gained CDS-based replacements, because CTS is Basis infrastructure, not a business object being modernized.

Basis and transport management own E070 and the transport landscape it describes. ABAP developers query it during troubleshooting to check status or ownership of their own requests. Functional consultants almost never query it directly; if a customizing change appears missing after go-live, the first move is to hand the request number to Basis and ask for the import log, not to open E070 in SE16.

E071 carries the object list for each request or task and is the table to check when a request's status looks fine but the change is still missing. E071K carries the key-level content for customizing and table entries, needed when the question is about actual data captured, not just object names. E070C carries additional attributes on the request header. SE01, SE09, SE10 and SE03 are the standard transactions that create and maintain these rows, direct table maintenance against E070 is not a supported path.