SM31 — Direct table maintenance transaction

SM31 calls the same underlying generated maintenance dialog mechanism as SM30, but goes straight to the table or view once its name is typed in, skipping the customizing overview screen SM30 presents. The structural fact that explains most confusion: SM31 does not create the maintenance logic itself, it only invokes it. If the table or view has never had a table maintenance generator run against it, SM31 will either refuse entry or prompt to generate a maintenance dialog on the fly, which is a development action, not a configuration one, and it can pull the table into a transport request unexpectedly. SM31 also does not enforce the same view-based field validation that a properly built maintenance view does, since it can be pointed straight at a base table.

Consultants reach for SM31 when SM30 throws an error such as the table not being found in the view catalog, when the object needed is a plain table rather than a registered customizing view, or when a quick technical fix is needed on a table that has no IMG node or Fiori app exposing it. It also gets used during data corrections in test or development systems where the exact table name is already known from debugging, and there is no interest in navigating SM30's selection dialog. For business users and standard customizing work, SM30 or the relevant IMG activity or Fiori app is the correct entry point; SM31 is a technical shortcut, not a replacement for those.

Use SE16 on DBTABLOG, filter by table name and the date and time window of the suspected change, to see who changed what and when if table logging is active for that table. If the table instead uses formal change documents, filter CDHDR by object class and date, then join to CDPOS on the change document number to see field-level old and new values. If neither logging mechanism is active, there is no audit trail for the SM31 change, and the only proof available is comparing the current table content against a transport or backup.

SM31 continues to exist on S/4HANA as the same direct-entry technical transaction; nothing about its mechanics changed. SM30 remains the recommended entry point for anything with a proper view or IMG activity behind it. There is no dedicated Fiori app for SM31 itself, since it is generic technical tooling rather than a business process; some customizing content has migrated to self-service configuration apps, but the underlying table maintenance generator mechanism SM31 relies on is unchanged.

Ownership depends on who owns the table: functional consultants own customizing content, ABAP developers own the maintenance dialog generation and any custom logic behind it, and Basis owns transport routing and authorization object assignment. A clean handover names the exact table, the entries changed, whether a transport request was involved, and whether the maintenance dialog was generated fresh or already existed.

Read SM30 first, since it is the standard entry point and SM31 is best understood as its stripped-down sibling. SE54 covers how the table maintenance generator that both transactions rely on is actually built and regenerated. SE16 is the tool for confirming what a save actually wrote to the table. SE09 and SE10 matter whenever an SM31 save unexpectedly triggers a transport request that needs to be tracked or released. SE18 and SE19 are relevant only if the table's change tracking is implemented through BAdI-based change documents rather than plain table logging.