TNAPR table — TNAPR table for output processing programs

One row in TNAPR represents the technical processing definition for one combination of application area and output type: which ABAP driver program is called, which form routine inside that program is executed, and which output form (SAPscript form or Smart Form) is used to render the result. It is Customizing, not transaction data. NAST does not know how to print anything by itself; when an output record in NAST is processed, the system looks up TNAPR using the application and output type from that record to find the program and form to call. Everything a functional consultant configures on the 'Processing routines' screen in NACE for an output type ends up as a row here.

TNAPR is a cross-client Customizing table, so a row is not scoped by client the way most master data tables are; a change made through NACE in one client is visible in every client sharing the underlying table pool, which is worth knowing before assuming a fix in a development client will not show up elsewhere. The table is small, at most a few thousand rows across all applications, so a scan with only KAPPL restricted is cheap; there is rarely a reason to query it without at least KAPPL, and almost always KSCHL as well, since the KAPPL/KSCHL pair is the natural key used everywhere else that references this table.

Symptom: output type ZINV for application V3 is not producing a printed document even though NAST shows the record as processed. Select from TNAPR with KAPPL equal V3 and KSCHL equal ZINV. Check that PROGN and ROUTI are filled and that the program named in PROGN exists in the ABAP repository with that routine present in its source. If FORNAM is blank but SFORM is populated, the output is rendered via Smart Forms, not SAPscript, and looking for it in STXH will never find it.

TNAPR still exists in S/4HANA and NACE is still the transaction used to maintain it for classic, NAST-based output types. It has not been replaced by a CDS compatibility view. Certain document types in S/4HANA, notably billing and some logistics outputs, have moved to a newer output management approach built on the business rules framework rather than NAST, and those output types bypass TNAPR entirely; for anything still using classic message control, TNAPR remains the table read at processing time exactly as in ECC.

The functional consultant who owns output determination for the relevant application, typically SD, MM, or FI depending on the output type, owns the NACE configuration and therefore the content of TNAPR. ABAP development owns the print program, form routine, and form referenced by a row, and gets involved whenever the diagnosis moves past configuration into why the called object fails at runtime.

NAST holds the output records that reference TNAPR entries by application and output type. STXH and STXL hold the SAPscript form header and text content that TNAPR points to through FORNAM. NACE is the transaction consultants use to maintain TNAPR rows, and its entry lives in TSTC. The print program named in PROGN is a normal ABAP report maintained and transported through the standard development tools.