TSTCA table — Authorization objects checked per transaction code

One row in TSTCA represents a single pairing of a transaction code and an authorization object that must be checked before the transaction is allowed to start, in a given client. This is separate from and additional to the mandatory S_TCODE check that every dialog transaction goes through. Rows are created when a developer or Basis administrator opens the transaction in its maintenance transaction and assigns one or more authorization objects to it directly, or when such an assignment is transported between systems as part of the transaction's object. The table is intentionally small: most transactions have zero or one extra object listed here, and only a subset of transactions carry additional hard-coded object checks at the tcode-start level, as opposed to checks embedded later in the program logic itself.

Always restrict by MANDT first, then by TCD when the question is 'what does this transaction check' or by OBJECT when the question is 'which transactions are guarded by this authorization object'. The table is small enough that a full table scan is not a performance problem, but an unfiltered select still returns an unmanageable list to eyeball. When comparing systems for an authorization discrepancy, pull the TSTCA rows for the specific TCD in both systems side by side rather than trusting that a transport moved everything, since direct changes in a downstream client bypass transport comparison tools.

Symptom: a user with S_TCODE authorization for transaction XYZ still gets an authorization failure when starting it. Select TSTCA where MANDT equals the current client and TCD equals XYZ. Each OBJECT returned is a further authorization object the kernel enforces at start. Take each object and check the user's role authorization values for it via the authorization trace; the object present in TSTCA but missing or under-scoped in the user's role is the cause of the failure, not S_TCODE itself.

TSTCA carried forward into S/4HANA with the same structure and the same maintenance path through the transaction's properties screen. No compatibility view is known for it, since it is a core authorization runtime table rather than a business or reporting table. Its role in the authorization architecture is unchanged: it remains a secondary, hard-coded check layered on top of S_TCODE, distinct from the role-based authorization concept.

Changes to TSTCA content are made by whoever maintains the transaction code's technical properties, typically a developer or a Basis-adjacent security administrator, and they are transport-relevant like any other transaction code change. Interpreting the table during an incident is usually done jointly by the authorization team and the ABAP developer who knows what the program itself additionally checks.

TSTC holds the transaction code master record that TSTCA's TCD field resolves against. TSTCT supplies the transaction's descriptive text for audit reports built on top of TSTCA. Changes to TSTCA are shipped inside the transaction code's transport object, so E071 entries of type R3TR TRAN accompany any TSTCA change moved between systems.