How to setup flexible scenarios with Tables Aliases

With version 7.0, aliases for tables are introduced, allowing to use the same table in multiple scenarios. For example, you can build a scenario where master data of a Cost Center InfoObject should be maintained by two different departments. One department may only change the Person Responsible field and the other department may only change the Business Division field. Furthermore, you can build more flexible custom logic in BAdIs. These scenarios are explained in detail in this article.

Maintenance of Cost Center Master Data

Let's assume that the master data of the Cost Center InfoObject should be maintained by different departments. For example, the person responsible should be edited by HR, while Controlling can adjust the Business Division of the respective Cost Center. All other fields should remain untouched. Furthermore, none of the departments is allowed to add new entries or delete existing ones.

This scenario can be implemented without any coding, only using the standard configuration settings and table aliases. First, we create two alias tables, which reference to the same InfoObject.

Alias tables refer to the same InfoObject

In Table Properties, define InfoObject as Alias Table Type and the respective InfoObject as Alias Table Name.

Alias Table 1 setup

Setup Alias Table 2

You can also set custom settings, for each Alias Table. In our example, it should not be possible to add or delete entries.

Disallow insert and deletion

Both Alias Tables should be assigned to different application, in order to assign respective authorizations. This way, each department can see only their Alias Table. You can assign authorizations for applications using the object /NLY/TBLS.

In Table Column Properties, it is possible to lock certain fields. In our example, all fields should be locked, except Person Responsible in the first Table Alias and Business Division in the second.

Lock edit

Entries are individually maintained for each field and alias table. You can lock text fields using field names TXTSH, TXTMD or TXTLG for short, middle and long text respectively.

Table column properties

As a result, only Person Responsible field is editable in the first table.

Only person responsible is editable

Please also notice, that is not possible to add or remove entries in this table.

Only edit allowed

In the second table, it is only possible to edit the business division.

Only Business Division editable

Maintenance of Account Model Key Figures

In this example I will demonstrate how to leverage alias tables usage in BAdI. In our example, a DSO in account model is used to maintain different key figures. One department should maintain revenue (account 100) and the other costs (account 200).

DSO Values

Using an alias table, we can separate the maintenance screens for each department, with dedicated BAdI logic to restrict the filter to a certain account. Similar to the previous example, each alias table is assigned to a different application. So you can assign the authorizations accordingly.

Two alias tables refer to the same DSO

In our example, we do not want users to be able to add new accounts via filter, so we turn global filters off in the settings of the alias table.

Global filter turned off

In the DATA Method of the Table Maintenance BAdI we implement checks for each alias table and define the filters. This way, only data matching the respective alias table is displayed. In the article “How to implement a BAdI for NextTables” you will learn how to create a BAdI.

METHOD /nly/if_editor~set_data_exit.
* This Implementation can be used if a table should be restricted by a certain field/value.
*If the user should not be able to add aditional filters, then the prefilter/gloal filter for this field should be turned off in meta data as well.
CASE i_step.
WHEN /nly/cl_table_rest_v3=>co_step_before_read.

IF i_tabname = 'ZDRACCNT_AL1'. "Not allow to change cost for this alias table
sign = 'I'
option = 'EQ'
low = '100'
high = ''
TO c_query_post-select_options.

ELSEIF i_tabname = 'ZDRACCNT_AL2'. "Not allow to change revenue for this alias table
sign = 'I'
option = 'EQ'
low = '200'
high = ''
TO c_query_post-select_options.

In the BAdI filter, both aliases are maintained, so the BAdI is executed for both and the differentiation is executed in the logic. It is also possible to create different BAdI implementations with dedicated logic.

BAdI Filter

As a result, only revenue or costs are shown in each table.

Differnt accounts

Only one account visible

How to create an Alias Table?

In order to create an Alias Table, follow the menu path CONFIG → WIZARD → Table Properties and create a new entry. Please select Alias Table (ALIASTABLE) as Table Type and define the name of your alias as Table Name. Select the type of the physical object you are referencing to in the field Alias Table Type. Afterwards, enter the technical Name of the physical object of the physical object you are referencing to in the Alias Table Name field.

You can define individual settings for your Alias Table. For example, you can make it view only and disable inserting of new values. Furthermore, you can also change properties of each field individually, just like with any other table.

Alias table settings

How to use an Alias Table in BAdIs

In order to use the Alias Table in your BAdI, you have to define it in the filter. Please define ALIASTABLE as TTYPE and the name of your respective Alias Table, e.g. ZDREXMPL_AL1 as TABNAME.

BAdI Filter for an alias table

Alias Table Authorizations

Please also note that the users will need the Alias Table authorizations in order to use Alias Tables. Please make sure the activity ALIASTABLE in the field name Table Type /NLY/TTYPE is selected.

Alias Table authorizations

Furthermore, authorizations for the respective application and table name should also be maintained.


Technical Tutorials

Do you have a question regarding NextTables?