SP02 — Own Spool Requests Display and Troubleshooting

SP02 displays the spool requests belonging to the logged-in user: print jobs, ALV or classic list output, and background job output that has been spooled rather than sent directly to a device. It is a scoped personal work list built on the same underlying spool request store that SP01 exposes for the whole system. The structural fact that explains most confusion: SP02 filters by owner and applies a default selection variant for date and status, so a spool request can exist perfectly well and still be invisible on this screen, either because it belongs to a different technical user (a background job running under a service account, for example) or because it falls outside the default date range. Users routinely report a job never produced output when the request exists under another user context entirely.

SP02 is reached when a user says a report ran but nothing printed, or a background job completed with no visible result, and the first question is whether a spool request was even created. It sits between report execution and physical output: the report finishes, writes to spool, and SP02 confirms that step happened and shows the current status before anyone touches the printer or the device configuration. It is also used to re-display, download, forward or delete a request that is sitting in the user's own queue. There is no dedicated Fiori replacement; spool administration remains a backend, GUI-based task on S/4HANA just as on ECC, so consultants keep reaching for this transaction unchanged.

Open SE16 on TSP01 and filter on the owner field for the affected user id, plus a creation date range wide enough to cover the missing job. If nothing turns up for that user, repeat the search without the owner filter to see whether the request was created under a different technical or batch user, which is the most common reason a request looks missing in SP02. Cross-check the status column against the job's own execution time to rule out a retention period that already expired and removed the request.

The spool subsystem and SP02 itself are unchanged on S/4HANA; the underlying spool request architecture carried over from ECC without redesign. There is no Fiori app that replaces this transaction; spool housekeeping remains a classic GUI task for both functional users checking their own output and Basis staff managing devices and retention. Any S/4HANA-specific difference a consultant encounters is more likely a device or printing infrastructure change at the customer, not a change to SP02 itself.

Functional consultants use SP02 to confirm output was generated and read the status, but device configuration, TemSe storage, and retention settings belong to Basis. A clean handover includes the spool request number, its owner, the exact status text shown, the output device, and the timestamp of the originating report or job run, so Basis does not have to reproduce the failure from scratch.

SP01 is the natural next stop when the request needs to be found under a different user or with elevated authorization, since it exposes the full spool store rather than just the current user's view. SPAD is where device configuration issues surfacing as spool errors actually get fixed. SM36 is relevant when the missing output traces back to a background job definition rather than the spool layer itself. SLG1 can help when the report or job wrote an application log explaining why no output was produced at all.