Changes in the Information System (SAP Library

Show TOC

Changes in the Information System

Scope of Functions

1. New entry screens for definition of forms, reports and planning layouts.

In the transactions for defining forms, reports and planning layouts, choose the required object before actually editing. Previously, the system displayed an initial screen with an entry field, in which the user would choose a value using F4 possible entries. The system then displayed the actual editing screen.

In Release 4.6C, a screen structure has been introduced, in which two area are represented next to one another. On the left, a tree structure displays the forms, reports and planning layouts. On the right, the detail screen of the transaction is displayed. This is where editing is carried out. The user can move the dividing line between the two halves of the screen, so increasing one half and reducing the other. There is also a button with which the user can hide/display the navigation area.

When you run reports, the navigation area also takes report variants into account. If variants exist for a report, these are displayed under the report name. You can use these variants to start the report, without having to go to the selection screen.

There are 3 possibilities for executing functions in the navigation area:
a) If you double-click on an entry, the system executes a standard function, which is transaction-specific. For example, if you double-click a report in KE30 (run report), the system will run the report. If you double-click on the same report in transaction KE32 (change report), the system will change the report.
b) If you double-click on the right-hand mouse button, a context menu appears. This menu offers different functions, depending on whether your cursor is positioned on the operating concer, a report or a variant.
c) You can select an entry in the navigation area and choose a function from the menu.

The system takes account of user parameters. For example, if you have run a report and then call up the same transaction again, the tree will already be expanded, and the report in question selected.

2. Saving inactive forms

Previously, when you saved a form, the system performed a consistency check, to ensure that the form could be used without difficulty in the report. The disadvantage of this procedure what that it was not always possible to save the form, as the system would ask you to make certain changes before saving. This created the risk, especially when working under time pressure, that the system would crash, and that work would be lost.

Im Release 4.6C, the system still informs you if forms are inconsistent. However, it is now possible to save the form despite this. A form saved in this way is classed as inactive for internal processing. You can therefore ensure that this form is not used in reports, provided that you do not save it. When you change reports, however, this form will be offered when you choose F4 possible entries, so allowing you to complete the form at a later point in time.

3. Definition of variables

Variable type "hierarchy node / characteristic value"
A new variable type "hierarchy node / characteristic value" (variable type 6) has been introduced for defining global variables. This is a combination of variables for hierarchy nodes (variable type 2) and variables for characteristic values (variable type 1), with a selectoption for the variable for characteristic values. When you run the report, you can enter either a hierarchy node or several characteristic values. When you run the report, this variable will be displayed over two line on the "report selections" screen, for example:
Profit center group
or values
In this example, "profit center group" is the name of the global variable, and the text "or values" is automatically inserted in the second line. You can either enter a hierarchy node under "profit center group" or enter one or more characteristic values under "other values".
Note the following: When defining variables or reports, a default value for this variable can be entered for a hierarchy node, but not for characteristic values.

4. Default values for global variables entered by the user

A number of replacment types are available for defining global variables. In particular, you must decide whether the value of a variable is defined by the user, or whether this value is entered automatically by the system. The user will see variables entered by users on the selection screen. If, on the other hand, you choose automatic replacement (for example, period to be entered in accordance with the system date) the user who is running the report will not see this variable on the selection screen. This type of variable helps to simplify administration. The person who defines the reports does not have to think about making changes in the report definition, for example at the beginning of a new month or period.

This functionality already existed in earlier Releases. However, it did not cover the following requirement: The user often needs to change entry values, but needs to do this in a logical manner. Even if the user can display several periods, it should be possible to set the current period as the default period, as this is the required period in 80 % of cases. Previously, the possbilities for the user to define this period were very limited. Now, in Release 4.6C, various methods have have been introduced for setting the default value:

a) SAP Exit
b) User Exit
c) Fixed value from a table
d) Set/Get Parameters

Note: This functionality is only available for global variables, and is not available for local variables defined in the form.

5. Report output

Column width in the lead column
Previously, if you define the display of the lead column in Settings -> Characteristic Display by, for example, choosing to display a characteristic's key and short text, the width of these two components was fixed in accordance with the setting made in the repository. Now, you can set the column width independently in a dialog box. If you know, for example, that the width in the repository is 10, but that you only need 5 spaces for the column, you can make the display look better by overwriting the default value and setting the width to 5. If you wish to change back the default value, you can do so at any time with the 'standard width' function.

Special symbols
When displaying a report, you might want to display undefined values. This is most commonly a division by 0. A special symbol is available for this purpose. From Release 4.6C, you can control the display of undefined values using the user parameter SYMBOLTYPE . If you enter ' ' (space or no entry) the system will display the preset default sysmbol. If you enter '1', the system will display '?'. if you enter '2', the system will display a space.

Graphical report output
1. You can now export the entire report list in HTML format.
2. User-specific color settings in the GUI are now reproduced in all areas of the report.
3. Users can save their individual graphic settings (color, graphic types etc.).
4. In the navigation area, you can use the arrows to scroll through all characteristic values.

6. Calling up reports with variant from the report tree

You can now call up drilldown reports with variants from the report tree. For this purpose, the user has to define the variant as well as the report name when creating or changing the report tree (transaction SERP). This makes it possible to place a report with various entry parameters in the report tree more than once.

7. Report/report interface

Influencing the transformation of selection data

You can use the report/report interface to call up receiver reports (ABAP reports, transactions, ABAP queries, Report Writer reports, drilldown reports) from a sender report. The sender selection data is reproduces in the receiver selection data. The system performs the following steps to reproduce the senders fields in the receiver fields:

1. Firstly, the system performs transformation by data element equivalence. If the sender fields and the receiver fields have the same data element, and no other sender or receiver fields have the same data element (uniqueness), the sender value is taken over in the receiver field.

2. If transformation by data elements is not possible, the system carries out transformation in the same way by domain equivalence.

3. If the system has still not found a sender value for a receiver field, it performs transformation by semantically equivalent domains. The domains in the sender and receiver fields which have not yet been transformed are replaced by equivalent domains, and processing is started as in 2.

Example of 3.: The characteristics cost element (KSTAR) and general ledger account (SAKNR) are semantically equivalent, although they possess different data elements.

You can influence how steps 2 and 3 are performed. In step 2, you can user virtual domains in place of the real domains. In table TVIRTDOM, you can assign a virtual domain to a data element, using transaction SE16. In some applications, for example, various data elements are used for the characteristic period. For this reason, table TVIRTDOM contains entries with the virtual domain PERDE for the various data elements.

In table TEQUIVDOM, you can specify semantically equivalent domains using transaction SE16. In this way, you can influence step 3.

Entries in table TVIRTDOM are not client-specific. As a result, changes which you make here will not take effect in all applications which use the report/report interface.

A typical example could be if you want to transform two characteristics - A and B - which refer to different data elements - DA and DB. Normal transformation between A und B fails. You therefore have two possible ways of performingn transformation. You can either enter a shared virtual domains for data elements DA and DB in table TVIRTDOM, or you can assign the domain from B to the domain from A in table TEQUIVDOM.

Calling up reports with variants

You can use the report/report interface to call up ABAP reports, ABAP queries and drilldown reports from many applications with variants. When assigning the report, both the name of the report and the required variant have to be entered. The system previously sent on the sender selection data to the receiver report and fills the entry fields automatically, meaning that you did not normally have to make any entries yourself on the selection screen for the receiver report. Now, when you call up a receiver report with a variant, the system takes account of both the sender selection data and the variant values of the receiver. The relationship between the sender selection data and the variant values of the receiver is decided as follows:

1. The sender selection data normally overwrites the variant values.

2. Entry fields which are marked as "protected" in the variant definition are an exception to this rule. Consequently, they are not overwritten.

3. If the entry field was marked as a "mandatory field" when the variant was defined, the system will also treat this field as a mandatory field when it is called up with the report/report interface. This means that if neither a sender value nor a variant value exist for this field, the system will display the selection screen and require the user to make entries here.

This new functionality allows you to reproduce sender selection data on receiver entry fields. In particular, you can check the display of the receiver selection screen to a large extent:

1. However, if the receiver report contains more entry variables than the sender report, the selection screen is not displayed, as the variables are filled with variable values.

2. Previously, if the receiver report had two variables with the same data element, it was not possible to assign a sender value to the variables, as the system requires data element equivalence between the sender and receiver report when making the assignment. Now, however, it is possible to mark a variable as protected in the variant definition. In this way, the variable is removed from the assignment, and it is possible again to assign a unique sender value.

Transformation of global variables

In a drilldown report, it is possible to define more than one variable for the same characteristic. In two columns of a form, for example, the variables PER1 and PER2 could be defined for the characteristic "period" to represent a start period and an end period. Previously, if you used the report/report interface to call up a report which uses this type of form, variables PER1 and PER2 could not be filled with sender values, as data equivalence exists between the sender and receiver selection data, but not uniqueness (see influencing the transformation of selection data). For this reason, transformation for global variables has now been introduced.

If transformation using data elements and domains is not successful, the system performs transformation using global variables. Sender variables are reproduced in receiver variables, if they both have the same global variable name. For example, if the sender report has global variable PER1, the receiver variable is entered as PER1. If the sender report still has global variable PER2, PER2 is also entered in the receiver report.

Calling up reports from other systems

The report/report interface now also lets you call up reports (ABAP reports, transactions, ABAP query, Report Writer reports and drilldown reports) from other systems.

For this purpose, the button 'Insert external report' has been added to the report assignment screen. Once you have entered a destination (see the documentation for transaction SM59), the system takes you to the receiver system. Here, you choose receiver reports, and can transfer the assignment to the original system using the 'transfer' button.

You can also assign and call up queries from a BW system. To do this, however, BW-ADD-ON must be installed in the sender system. It is possible to carry out transformation between the sender selection data and the receiver selection data from the BW system, provided that the data in the corresponding BW InfoCube originates from the sender system.

1. Generating all reports

When a new Release comes out, changes normally occur in the repository, with the result that all reports have to be regenerated. As soon as a user attempts to work with a report (run, change etc.) the system recognizes this situation and automatically regenerates the reports. However, this process takes a long time.
It is now possible to plan this generating process centrally as a background job through an administrator, so that end users will not be confronted with an unfamiliar situation and to prevent idle time in the system. The report RKD_REGENERATE_ALL_REPORTS is provided for this purpose. You can call up this report using the monitor (transaction KEMO in CO-PA, Goto -> Generate All Reports) or directly from the ABAP editor (transaction SE38).