Customizing Table with Texts from an Existing Table

Test Requirements

• Create a customizing table and establish a method to integrate text descriptions
• Text fields must be read-only (not ready for input)

Core Considerations and Strategy

1. Must text fields be physically included in the customizing table? – No, because the texts are already available within the database.
2. Is custom ABAP development required? – No, a maintenance view will be created for the customizing table.
3. Do we need to utilize table maintenance dialog events? – No.

Implementation Steps

Note: I have excluded popups containing warnings and package assignments from this article. All warnings encountered during this walkthrough were ignored, and the objects were assigned to the local package $TMP.

Creating the Customizing Table

Transaction SE11: Assigning Table Name

I use transaction SE11 to create the customizing table. On the initial screen, select Database Table, assign a name (Note: The name should be as self-explanatory as possible), and press the F5 key.

Delivery and Maintenance

First, provide a short description for the table and select delivery class C (Customizing table).

Fields

My table will consist of the key and data fields MANDT, WERKS, and LIFNR.

Foreign Keys

To dynamically include additional tables within a maintenance view, it is crucial that at least one field of the table establishes a foreign key relationship.

Foreign Key for WERKS

When maintaining the foreign key configuration for the plant field, SAP automatically suggests table T001W, which I accept.

In the foreign key generation popup, accept all default values and confirm by clicking Copy.

Foreign Key for LIFNR

When maintaining the foreign key configuration for the vendor account number, SAP automatically suggests table LFA1, which I accept.

In the foreign key generation popup, accept all default values and confirm by clicking Copy.

Technical Settings

To activate the table, technical settings must be defined. Save the table first and assign it to a package. For the data class, I selected APPL2 and size category 0.

Save the technical settings and navigate back to the table maintenance interface, which can now be successfully activated.

Creating the Maintenance View

Transaction SE11: Assigning View Name

I use transaction SE11 to create the view. On the initial screen, select View, assign an appropriate name, and press the F5 key.

Selecting View Type

The structural type of the view must be configured as a Maintenance View.

Description and Table Selection

Provide a short description for the view, enter the newly created customizing table under the tables section, and confirm with Enter.

By clicking the „Relationships“ button, both tables discovered via the foreign key configuration can now be seamlessly appended.

View Fields

Next, define which fields the view should expose. The field selection matrix can be accessed via the „Table Fields“ button.

Double-clicking on a table node opens its respective field structure list. Select the field „NAME1“ from both T001W and LFA1.

Additionally, ensure that the field „LIFNR“ from our base customizing table is included.

Maintenance Attribute for View Fields

To ensure both description name fields act strictly as output-only fields, set the attribute modification value to „R – View field read-only“ in the maintenance attribute column.

Prior to activating the view, it is mandatory to rename one of the duplicate fields sharing the name NAME1.

Now, activate the completed maintenance view and assign it to your target development package.

Table Maintenance Dialog

To maintain table data entries via transaction SM30, an automated table maintenance dialog must be generated.

Table Maintenance Generator

Launch the table maintenance generator directly from the maintenance view editor by navigating to Utilities → Table Maintenance Generator.

Technical Dialog Configurations

Name the function group identical to the maintenance view and assign authorization group &NC&. Set the maintenance type to one step and allocate screen number 1.

Click the create icon in the application toolbar to generate the function group modules and underlying runtime logic. Assign the development tasks to your active package.

Transport Data Specifications

After successful generation, activate the Standard Recording Routine checkbox to guarantee that data modifications within this table are captured by the transport system.

Testing the Implementation

All declarative configuration steps are now complete, allowing a runtime test to verify the automated reloading behavior.

Transaction SM30: Maintaining Customizing Entries

Execute transaction SM30 and specify your maintenance view name to launch the data maintenance workspace.

Adding a Data Record

When creating a new data entry, select a valid plant ID and vendor account number using the search help.

Confirming Entry with Enter Key

Upon pressing the Enter key, the corresponding text descriptions for both the plant and vendor are dynamically reloaded and refreshed on the UI canvas.

Deep Dive: Why No Custom Development Is Required

How does this automated data retrieval operate under the hood? I analyzed the standard framework logic to explain its inner mechanics here.

Screen Flow Logic of the Maintenance View

Since data is reloaded during user interaction, we inspect the screen's flow logic. The framework automatically implements the module „COMPLETE_ZMM_V_WERK_LIFNR“ within the PROCESS AFTER INPUT sequence. This include structure always follows the standard pattern „COMPLETE_“. Whenever you encounter these specific includes, it indicates that additional relational data is automatically fetched and refreshed on screen.

Triggering the Complementary Subprogram

Inside this generated module, the runtime engine exclusively triggers the subprogram routine „COMPLETE_EXPROFIELDS“.

Triggering the Complementary Subprogram

The routine „COMPLETE_EXPROFIELDS“ subsequently calls the specific subprogram „COMPL_ZMM_V_WERK_LIFNR“. This naming convention strictly follows the structural pattern „COMPL_“.

The Core Data Retrieval Subprogram

Within the subprogram „COMPL_ZMM_V_WERK_LIFNR“, the missing description texts are finally selected from the database via SQL. Through this automated design, SAP eliminates the need for any manual interaction logic.

Back to Blog Overview