TSP01 table — Spool Request Header Table

One row in TSP01 represents a single spool request: the administrative record created every time output is generated in the system, whether by a user printing a list interactively, a background job step producing output, or an interface routine calling an output function. TSP01 stores the request's identity, who created it, when, what it was titled, its current status, how many pages it contains, and which output device it was directed to. The actual formatted content pages, the raster or list data, live elsewhere; TSP01 is purely the control record that SP01 and SP02 display when a user or administrator looks at the spool queue. A spool request can exist in TSP01 long after the job that created it has finished, and can outlive the printer or device it was originally targeted at if that device configuration has since changed.

TSP01 is client-dependent; always restrict on RQCLIENT first in any productive system that runs multiple clients, since the table accumulates spool requests from every client on the instance. RQIDENT alone is a good access path if the number is already known, but in troubleshooting the usual starting selection is RQOWNER plus a date range on RQDATE, or RQDEST plus RQDATE when the complaint is about a specific printer. The table grows continuously in an active system and reorganisation jobs periodically purge old entries, so a direct SELECT without date restriction on a long-lived production system can return an enormous result set. Reading through SP01 or SP02 is normally safer than a raw table browse, since those transactions apply the same restrictions with proper authorisation checks.

A user reports a report they ran yesterday afternoon never printed. Select TSP01 with RQOWNER equal to the user id and RQDATE equal to yesterday's date. If a row exists, RQSTATE shows whether the request is still waiting, was already printed, or ended in error, and RQDEST shows which device it was sent to, which often reveals the request went to the wrong or a disabled printer rather than disappearing.

TSP01 is unchanged in shape and purpose moving from ECC to S/4HANA. The spool subsystem architecture was not part of the S/4HANA data model simplification, so the table is read and written the same way, and there is no compatibility view replacing it. SP01 and SP02 continue to operate against it directly.

Ownership sits with Basis, specifically whoever administers the spool and output management setup. Application teams raise the symptom (a report did not print, an interface output vanished), Basis confirms the state of the request in TSP01 and traces it forward into the printer or output channel configuration.

TSP03 holds the actual spool content pages referenced by RQIDENT. TBTCO and TBTCP are the background job tables whose step results link into TSP01 when a scheduled job produces printable output. SOST and SOOD come into play when a spool request is transmitted as a fax, email, or business document rather than sent to a physical printer. SP01, SP02, and SPAD are the transactions consultants use to view, manage, and configure the objects this table represents.