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.
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.
In Table Properties, define InfoObject as Alias Table Type and the respective InfoObject as Alias Table Name.
You can also set custom settings, for each Alias Table. In our example, it should not be possible to add or delete entries.
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.
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.
As a result, only the "Person Responsible" field is editable in the first table.
Please also notice, that is not possible to add or remove entries in this table.
In the second table, it is only possible to edit the short and medium description.
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).
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.
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.
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
APPEND VALUE #( fieldname = '/BIC/ZACCOUNT'
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
APPEND VALUE #( fieldname = '/BIC/ZACCOUNT'
sign = 'I'
option = 'EQ'
low = '200'
high = ''
)
TO c_query_post-select_options.
ENDIF.
ENDCASE.
ENDMETHOD.
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.
As a result, only revenue or costs are shown in each 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.
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.
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.
Furthermore, authorizations for the respective application and table name should also be maintained.
Please note: In general "Alias Tables" can be used in the professional and enterprise version. The shown example "Maintenance of Account Model Key Figures" uses a BAdI and therefore can only be implemented in the enterprise version of NextTables.
Which License is needed for this feature Professional ✔ | Enterprise ✔