SPAD — SPAD Spool Administration Transaction

SPAD is the spool administration transaction. It maintains output device definitions, device types, spool servers and the host spool access control list. Its two entry points look similar but do different things: 'Output Devices' opens the technical device master where a device's access method, host name and spool server are defined, while 'Full Administration' also exposes a request queue view that overlaps with SP01. Most confusion comes from that overlap - consultants land in SPAD looking for a stuck print job and actually need SP01 or SP02, or land in SP01 looking for why a device will not connect and actually need SPAD. SPAD is about the plumbing: which host, which access method, which server. SP01 is about the individual spool request sitting inside that plumbing.

Reached for when a printer or output device needs to be created, changed, or reassigned to a different spool server - typically after a system refresh, a new print server rollout, or a physical printer replacement. Also used when print jobs fail with a host spool access or connection error that is not a user authorization problem but a device-configuration problem. Functional consultants normally never open SPAD directly; they reference a device name in output determination configuration and expect Basis to have made that device name resolve to something printable. No interface or Fiori app replaces this layer - printer and spool server administration stays a backend, SAP GUI only task even on S/4HANA, which is why SPAD survives long after other admin transactions gain Fiori equivalents.

Open SE16 on TSP03 and filter on the device name in question; the access method and host name shown there should match exactly what SPAD's device screen displays - a mismatch usually means the device was changed through a transport that did not carry the same host value across systems. Cross-check the host value against TSP0A: if the device's host is not listed there, or is listed with a restrictive entry, printing fails with a host spool access error regardless of the requesting user's own print authorization. For consistency problems, run the check from SPAD's Administration menu rather than trying to interpret TemSe-related tables directly.

SPAD is functionally unchanged on S/4HANA. It remains a SAP GUI transaction with no Fiori replacement, because output device and spool server administration is infrastructure, not a business process a Fiori app would model. What has moved toward newer tooling is output determination and document output configuration for specific business documents, using newer output management frameworks and Adobe-based forms, but that layer still ultimately needs a device name that resolves through the same device master SPAD maintains.

Basis owns SPAD: device creation, access method selection, host spool access control, and spool server assignment. Functional consultants own which device name is referenced inside output determination configuration and should never edit SPAD themselves. A good handover includes the device name, the exact error text (with host access control detail if visible), which physical printer output is supposed to reach, and whether printing worked before a specific system event such as a refresh or network change.

SP01 and SP02 are the natural next stop once a device is confirmed correctly configured - they show the individual spool requests queued against it. SMGW matters when the device's access method relies on a gateway connection to an external host, since a gateway problem there produces the same symptom as a badly configured SPAD device. SM59 is relevant for access methods that route through an RFC destination rather than a direct operating system call. SLG1 is worth checking after running SPAD's consistency check, since detailed results and corrections sometimes only surface in the application log rather than on screen.