NAST table — NAST Output and Message Status Table

One row in NAST represents a single output request created by the output determination procedure attached to a business document. When a sales order is saved, a purchase order is released, or a billing document is created, the system evaluates condition records for output types and, for each match, writes a NAST entry recording which output type applies, which partner it goes to, by which medium (print, fax, EDI, email), in which language, and whether it should fire immediately or on a collective run. NAST does not hold the printed form, the IDoc payload, or the email body. It holds the instruction and the outcome of executing that instruction. The actual content is generated at processing time by a form, a Smart Form, an IDoc, or an XML mapping, driven by the processing routine assigned to the output type.

NAST is client-dependent and grows continuously in any live system, so a query without MANDT and at least KAPPL plus OBJKY restriction will scan a large fraction of the table. The safe pattern is to always know the business document number first, convert it to the OBJKY format used by that application (padding, leading zeros, or concatenation varies by KAPPL), then select on KAPPL plus OBJKY, optionally narrowing by KSCHL if the output type is known. Restricting only on KSCHL across all applications is a common way to accidentally pull unrelated documents, because the same output type code can be reused with different meanings under different KAPPL values.

Symptom: a billing clerk reports the invoice print never came out for billing document 90001234. Select NAST where KAPPL equals the billing application code and OBJKY equals the billing document number, ordered by ERDAT and ERUHR descending. If no row exists, output determination never triggered for that document, meaning the condition record is missing or the requirement routine did not fire. If a row exists with VSTAT indicating an error, the processing program ran and failed, which is a different fix entirely.

NAST still exists in S/4HANA and continues to carry output status for processes that remain on classic output determination, including much of purchasing and parts of sales and distribution that have not been migrated. S/4HANA introduced a newer output management framework built on BRFplus-based determination for several document types, notably billing and outbound delivery in many implementations, which bypasses NAST entirely for those flows. The practical consequence is that the same SAP system can have some document types writing to NAST and others writing to the newer output log, so the first check on any output issue in S/4HANA is which framework that specific document type actually uses.

The functional consultant for the module that owns the document (SD for sales and billing output, MM for purchasing output) owns the condition record and output determination configuration. Basis or the interfaces team owns spool, printer, fax gateway, and EDI subsystem failures once NAST shows the processing program ran. A developer gets involved only when the processing routine or form logic itself is at fault.

TNAPR resolves which program and form logic runs for a given KAPPL and KSCHL combination, and is the next stop after confirming a NAST row's status. STXH and STXL hold the actual text content when the output uses stored SAPscript or Smart Form texts. Reprocessing and monitoring of NAST entries is typically done through the output-related transactions for the owning document type (billing, delivery, purchasing output lists), and through IDoc monitoring transactions when the medium is EDI.