SE16XXL – New Features – Historical List - top flow Table ...

SE16XXL – New Features – Historical List

SE16XXL – New Features – Historical List of 117


May 2017 New version 3.3B which includes the following features:

- Function group for performing an SE16XXL script More …

- Jumps to a script with pseudo Set/Get parameters More …

- New file formats supported when creating a file More …

- Improved creation of server file in background More …

- New title settings for parameter transactions More …

- Spreadsheet in place takes settings into account More …

- New substitution variables for defining title lines More …

January 2017 New version 3.3A which includes the following features:

- Script short texts in different languages More …

- New function "Spreadsheet in place with template" More …-

- Optional output of the selection criteria when printing More …

- Empty background results optionally ignored More …

- Some new features for administrators More …

July 2016 New version 3.3 which includes the following features:

- New functions to add special columns to the result list More …

- The reference fields are now visible More …

- Sharing the result of a script in background More …

- Background server file sent as e-mail attachment More …

- Default ALV layouts for scripts More …

- List of DDIC tables/views used in scripts More …

- New transaction /TFTO/SE16 More …

- Improvement of the start file definition More …

- Improvement of the headings definition More …



October 2015 New version 3.2E which includes the following features:

- Script Favorites More …

- Improvements of the Script Catalog More …

- Internet path (http://) as documentation path More …

- Composite roles for scripts More …

- Special Authorization Checks supported More … April 2015 New version 3.2D which includes the following features:

- Adding descriptive texts More …

- Option for double quotes More … August 2014 New version 3.2C which includes the following features:

- Table Wizard renamed SE16XXL More …

- Direct background result list to SAP Spool More …

- Improvements of the Formula Editor More …

- Improvements of the Script Catalog More …

- Improvements of the Special Selection Screen More …

- Default Script Variants More …

- Additional Improvements More …

Mar. 30, 2014 Transport of scripts. More …

October 2013 New version 3.2 which includes the following features: - Unified list field selection popup More …

- Columns in any order in standard display mode More …

- "Freeze to column" function in all modes More …

- New option when setting a filter More …

- Virtual joins More …

- Full join More …



- Join criteria with interval selection More …

- Join criteria with prefix selection More …

- Select options with thousands of entries More …

- Global parameters More …

- Scripts performed "with reduced memory usage" More …

- New operation "Count sorted rows" More …

- New operation "Fix formula fields" More …

- New user settings introduced More …

- New function "Download to frontend file" More …

- Special calendar functions available in formulas More …

- Script editor: new function "Replace SELECT table" More …

- Additional Improvements More … April 2012 New version 3.1A which includes the following features:

- Permissions assigned via SAP authorization roles More …

- Problems with spreadsheet in place and Cyrillic solved More …

- F4 help for views More …

- Formula retained after a join More …

- Documentation restructured More …

- Direct call of the Script Catalog when saving a script More …

More historical entries …



Function group for performing an SE16XXL script This topic should be more of interest for programmers than for normal users. Up to now an SE16XXL script could be performed from an ABAP program only by calling transaction /TFTO/SE16SCRIPT. This procedure resulted in the script being performed, without the calling program having any way of getting hold of the results, which were shown to the user in the usual way. In order to overcome these problems a new function group has been implemented which enables an ABAP program to perform a script, thereby obtaining the result list in form of a reference variable. The ABAP program has thus complete control of what happens next with the result list – it can eliminate undesired rows, enhance their contents, and finally display them in any desired way, not necessarily by means of ALV. It is not even necessary to show the result – the program could instead make use of the script result to produce another list of its own. The new function group is /TFTO/TX_SFMI (SFMI stands for Script Function Module Interface). The main function module is /TFTO/TX_SFMI_CALL_SCRIPT. In order to give the programmer an idea of how to make use of this function group, the following example programs have been implemented:

- /TFTO/SFMI_CALL_SIMPLE - /TFTO/SFMI_CALL_EXAMPLE - /TFTO/SFMI_CALL_EXTRA

By taking a look at the coding of these example programs and at the individual functions of the group it should by possible for an ABAP programmer to understand how to make use of this new functionality. Since each program calls a script which for obvious reasons is not available on the actual development system of the programmer, it is recommended to make a copy of each example program and to replace the name of the involved script with one created for this purpose. The programmer can thus – with the help of the ABAP debugger – carry out tests to explore the workings of the functions. For more information please refer to Function Group SFMI. Back to the top



Jump to transaction /TFTO/SE16SCRIPT with pseudo Set/Get parameters

Up to now it was possible to define a jump to transaction /TFTO/SE16SCRIPT, thereby specifying by means of Set/Get parameter /TFTO/TX_SCRIPT the name of the script to be performed. Following a double click on the involved column the selection screen of the called script would indeed show up, but only with default selection criteria. There was no way of passing context values of the clicked row to the called script. This was a serious drawback, making this kind of jump practically useless. In order to overcome this shortcoming, a mechanism based on so-called pseudo Set/Get parameters has been implemented. It makes it possible to pass context related values to a given script, so that a meaningful jump from the result list to a script becomes feasible and practical. The only precondition is that the called script be provided with a special selection screen.

A simple example will illustrate the procedure. We start with the script to be called. It reads the material stock data (table MARD) and displays the available quantities. We suppose the script to already be provided with a special selection screen. Otherwise it would have to be defined. The next step is to assign a pseudo Set/Get parameter to the material number. This assignment is carried out in the definition of the special selection screen ( on the toolbar of the script catalog) under the tab "Restrictions":



A new column PsPID has been introduced for this purpose. In this example we assign the short form "1" which corresponds to pseudo Set/Get parameter /TFTO/TX_CRIT1. A glance at the F4 help shows values from 1 to 9, which should be more than sufficient – it means that when calling a script (in a jump definition), up to 9 context values can be passed along from the caller. On the simulated selection screen ( ) the criteria with a pseudo Set/Get parameter are shown with a little asterisk at the right side:

It is thus possible for the user to quickly see if any such assignments have been defined (the asterisk does not show up in a real dialog situation). The target side is complete. We may now transfer our attention to the calling side, i.e. to the definition of the jump. In our example we consider a script that reads customer orders. Each item contains a material number. When the user clicks on this hotspot a jump should be performed to the above described script, showing the available stock of the involved material. We start by defining the jump in the usual way:

After specifying the target transaction (/TFTO/SE16SCRIPT) and pressing ENTER we switch to the Set/Get parameters by pressing .



Here we type in the name of the target script as a literal:

This is absolutely necessary in this context, since otherwise the program has no way of identifying the involved script – it must be remembered that each script has its own pseudo Set/Get parameters, which usually have a completely different meaning from the ones of other scripts. At this point we can make use of the F4 help to choose the desired pseudo Set/Get parameter(s):

We choose /TFTO/TX_CRIT1 and assign to it the material number of the order item, thus obtaining:

In the above F4 help list the last entry is /TFTO/TX_SKIPS, a special pseudo Set/Get parameter which is provided for skipping the selection screen altogether. We choose this one too and the finished result will be:



We save the jump definition and then perform our script. On the result list we click on a material number, in order to see if our jump works as desired:

The result is:

As might be expected, it works. Back to the top



New file formats (XLSX etc.) supported when creating a file Up to now only text files with separators – of type .TXT or .CSV – were possible when downloading the result list to frontend or saving it to a server file. The same was true for background script results inserted into a server file. This restriction has now been somewhat loosened. The following file formats are now also available, even in script background processing:

- XLSX Office Open XML Workbook - XML XML Spreadsheet - MHTML Single Web Archive

These file formats can be read by a spreasheet program directly. Files of this kind created by a background script can also be sent as E-mail attachments, just like the usual text files. NOTE: the first format (XLSX) is not available on all SAP versions supported by SE16XXL. Dialog Mode In order to support these new formats, the menu structure in dialog mode has been adjusted. The previous functions have been split into two subfunctions:

and

The first subfunction corresponds to the function available up to now. The second subfunction is reserved for the newly supported file formats.



In this context a new option has been added to the user settings:

The default setting behaves in the usual way, i.e. the last used filename is proposed. If the second alternative is activated, the program generates the proposal either from the involved tables or, in case of a script, from the script name. Saving the result list to a server file When the second subfunction is chosen, the following dialog window shows up:

As may be seen, all the additional options available for text files with separators are missing, since the chosen format (file type) already tells everything. If the user chooses a different format from the dropdown list (the last one used is always proposed), the file extension is automatically adjusted:



Downloading the result list to a frontend file This subfunction behaves in a similar way. A dialog window pops up as follows:

NOTE: Unlike with the download function for a text file, no standard download popup is displayed in this case. The reason is that no explicit encoding is possible, since these new file formats are treated internally as binary files. Therefore the download can be carried out invisibly. Saving background result list in server file This option, available when scheduling a script in background, now also offers the possibility to create the server file in one of the new formats. A dropdown list to this effect has been added to the corresponding dialog window:



The user may now choose a file type different from "Text with Separators":

In this case most of the remaining options disappear from the dialog window and the file extension is adjusted accordingly:

NOTE: it is not possible to append a file with one of these new formats to an existing one, because the result would be inconsistent. Therefore only the "overwrite" option ia available. The option "use ALV formatting" regards numerical character fields (type NUMC). ALV displays these fields without leading zeroes. If the file should contain the leading zeroes, this option should not be activated. Back to the top



Creation of server file in background without use of ABAP memory

Up to now, when a script running in background created a server file, the result list was passed to the necessary software via ABAP memory (export to memory / import from memory). This mechanism works fine for moderate amounts of data, but as usually happens, reality ignores assumptions, with the result that at times the whole procedure would be abnormally terminated by the system. In order to avoid such problems, the creation of a server file is now carried out in background directly, without passing any considerable amount of data via ABAP memory. As may be imagined, there will still be a limit to the amount of data being capable of processing, but not as critical as before. Back to the top New title settings for transactions based on /TFTO/SE16PARAM Two new settings are available for parameter transactions based on transaction /TFTO/SE16PARAM, each assigned to an appropriate parameter:

Parameter Description SP_STTYP Controls the title of the selection screen

SP_RTTYP Controls the title of the result list Both parameters may assume one of the following values:

Value Meaning space Standard title i.e. as was the case up to now SN Script Name SX Script Short Text TC Transaction Code TX Transaction Short Text TT Transaction Code + Short Text

Back to the top



Spreadsheet in Place takes settings into account Up to now Spreadsheet in Place ignored any user settings regarding output formatting except the option "field name / field label" for the column headings. The field contents were always displayed in the same way.

This has now changed. The user settings in regard to conversion exits and to the mode of display (standard / ALV) are now taken into account. An example with table KLAH, where field CLINT is of type NUMC, and field MEINS is provided with a conversion exit (CUNIT), will be used to illustrate the topic. A small selection of KLAH entries may look like the following:

The user settings are as follows:

The result with Spreadsheet in Place is as follows:



We now switch to ALV with conversion exits on:

The ALV output will then be as follows:

Correspondingly, Spreadsheet in Place will match this:

NOTE: The leading zeroes of field CLINT are eliminated not owing to a conversion exit (it has none) but to the fact that its type is NUMC, which ALV treats in this way. Back to the top



New substitution variables for defining title lines Three new substitution variables have been added to the ones available for defining the title lines that are shown on the top of the result list. These new variables are particularly interesting for parameter transactions based on transaction /TFTO/SE16PARAM:

Variable Description

&SCRNAME

Name of the script – shows up even in a parameter transaction based on /TFTO/SE16PARAM. The variable &SCRIPT, which continues to be valid, is cleared under the above conditions.

&TCODE Current transaction code

&TCTEXT Short text of the current transaction code Up to now only variable &SCRIPT was available for showing the name of the currently used script, but this variable was cleared (….) when running under a parameter transaction based on /TFTO/SE16PARAM. Now the administrator can make use of &SCRNAME instead, which is never cleared and is therefore always visible. Furthermore &TCODE and &TCTEXT display information regarding the current transaction. This makes it easier to find out by which means a given result list has been produced. Back to the top



Script Short Texts in Many Languages Up to now a script only had one short text in an "undefined" language. Larger companies with employees from many parts of the world had a problem with this situation. This shortcoming has been eliminated. The script short texts may now be translated into several languages. Depending on the logon language, the appropriate short text is displayed. If no short text has been defined for the current logon language, the original short text – i.e. the one assigned at creation time – is used. The translation may occur implicitly or explicitly. Implicit Translation An implicit translation takes place when a given script is saved once again after having been enhanced (for example by adding a further join to its operations) and the current logon language differs from the original one used at creation time. A similar situation arises when the script attributes are changed under a different logon language. This implicit translation, however, is almost a fortuitous process and surely not recommended when a large number of scripts is involved. Explicit Translation The script catalog now offers the following menu function for this purpose: Selected Scripts Translate script short texts As a result a dialog similar to the following shows up:

For more information please refer to Translation of Script Short Texts. Back to the top



Spreadsheet in Place with Template It is now possible to specify a template file (and optionally a macro) when calling function "Spreadsheet in place". This new function is also to be found in the menu

Goto Spreadsheet in place w. template After the function has been chosen the following dialog window shows up:

The template file can either be a file on the frontend, or in the MIME Repository (transaction SE80). The name of a macro to be performed may also be specified. In order to give an idea the corresponding names have already been entered in the above example.

The template file makes it possible to enhance the spreadsheet with additional information, in our example with a pie chart derived from the selected data:

The specified macro must be so implemented as to be able to build the pie chart from the data passed by SE16XXL to the spreadsheet. Back to the top



Output of Selection Criteria when Printing When the result list of SE16XXL is printed, i.e. passed to SAP spool, either by making use of the Program Execute and print function on the selection screen, by choosing List Print on the result list, or by directing the result of a script in background to SAP spool, a dialog window for specifying the print parameters shows up:

By checking the option , you can specify that the involved selection criteria be added to the spool output. The spool list may then be similar to the following:

This additional information may be very useful for the recipients of the list, who can thus better understand what kind of data has been selected. The selection criteria may also be displayed in the result list by making use of the menu function List Display selection criteria. Back to the top



Empty Background Results Optionally Ignored At times it may happen that a script does not deliver any hits, i.e. it returns with the message

Obviously this can also happen when the script is scheduled in background. Normally this is not a problem.

However, if the background results are to be published for a number of subscribers, or sent as e-mail attachments to various recipients, the absence of a real result may be perceived as a nuisance by the subscribers/recipients. In order to eliminate this shortcoming, a special option has been introduced for both cases. First Case – Result Subscribers The option is to be found in the :

When this option is activated, an empty background result is not published:

- no link to the empty result is created for the subscribers - the subscribers are not informed via SAPmail



Second Case – E-Mail Attachment The option is to be found in the :

When this option is activated, an empty background result is ignored. This means that no e-mail with attachment is sent to the defined e-mail recipients. NOTE: The above described behavior is optional because sometimes it may be necessary to inform the subscribers/recipients that the result is indeed empty. Back to the top



Some new Features for Administrators The following topics are only relevant for administrators. They are cited here only to inform the normal SE16XXL user of the possible implications at his/her level. Restrictions for Function Codes The SE16XXL administrator can now restrict the availability of certain function codes for all users, for specific user groups, or for individual users. Therefore users should not be surprised if at some point one function or another is missing or deactivated. An example will best illustrate what we are talking about. The application toolbar of the SE16XXL result list looks normally like this:

If the function codes for "Edit formula" and "Full join" were not allowed for the current user, it would look as follows:

This applies also to the menus:



Authorization Objects instead of Roles In earlier versions of SAP it was not possible to define authorization objects in a customer namespace. For this reason the SE16XXL authorization checks were so far carried out by means of empty roles assigned to users. This mechanism was recommended by SAP as a substitute for a "normal" authorization check (refer to SAP note 104010). This limitation has been lifted in the more recent SAP versions. Therefore it has been possible to define a series of authorization objects in the /TFTO/ namespace which can be used in alternative (or in combination) with the hitherto existing roles. The normal user does not perceive any difference in the program behavior. Only when taking a look at his/her own user definition (transaction SU01) he or she may be surprised not to find any /TFTO/ roles assigned, while being able to make use of SE16XXL and its associated functionality. /TFTO/SE16PARAM transactions without selection screen Parameter transactions based on transaction /TFTO/SE16PARAM have long been possible. They are associated with a specific SE16XXL global script. When such a transaction is called, the selection screen of the underlying script appears, followed by the result list, if any table entries are found. This is the normal behavior. At the request of some companies it is now possible to define a parameter transaction which suppresses the selection screen – the result list appears immediately after the transaction call. Back to the top



New Functions to Add Special Columns In the SE16XXL result list new functions are now available in menu Extras. These functions make it possible to add new columns to the result list without the need of a formula, which is a problem for users unfamiliar with ABAP. They have been grouped in three subgroups: Add One Column …

The first function ("… with count of sorted rows") was already available in the previous version under the name "Count sorted rows" and has only been renamed. The remaining two functions are new. For more informations please refer to Add Sequence Number and Add Percentage.

Add Columns …

For more informations please refer to Add Columns. Clone Columns …

For more informations please refer to Clone Columns. Back to the top



Reference Fields Visible

Most of the functions mentioned in the previous topic deal with amounts (associated with a currency field) or with quantities (associated with a unit field). These associated fields are called "reference fields" and are visible in the DDIC definition of a table under the tab "Currency/Quantity Fields":

Up to now the relationship between a given amount/quantity field and its reference field was not immediately visible in the SE16XXL context. It would come indirectly to light when ALV totals and/or subtotals were added to the result list. This shortcoming has now been removed – the reference fields are now visible throughout SE16XXL in many places, like for example the detailed view of a row:

For more informations please refer to Reference Fields. Back to the top



Sharing the Result of a Script in Background Up to now the result of a global script run in the background was only available for the person that scheduled it, unless the result was written to a server file or directed to SAP spool. This shortcoming has now been removed. The result may now be made available to other chosen users, called "subscribers". This sharing functionality, however, has to be activated by the administrator. In addition, the user that wishes to share the background results must be equipped with a special authorization role. When all these prerequisites are met, the dialog window for starting a script in background shows up with an additional button:

For more informations please refer to Sharing Background Results. Back to the top



Background Server File as E-Mail Attachment It has for long been possible to save the result of a background script to a file on the application server ("server file"). The idea was that the server path would be shared upon users, making it possible to access the file as if it were a local one on the frontend. It turns out that in many companies some users have no direct access to server files. They need, however, the informations resulting from background scripts. In order to overcome this shortcoming, it is now possible to send a background server file as e-mail attachment. This functionality, however, is only available if the corresponding option has been activated by the administrator, and if the scheduling user is equipped with an appropriate authorization role. The e-mail addresses of the recipients are also subject to several restrictions. If all these prerequisites are met, the dialog window for starting a script in background exhibits an additional button:

For more informations please refer to Server File as E-Mail Attachment. Back to the top



Default ALV Layouts for Scripts The result list of a script can be modified in various ways – by choosing other output fields, by rearranging the order of the columns on the list, and also, in ALV (both List and Grid), by loading a particular ALV layout. Up to now this had to be done manually when performing the script. Obviously the script could be defined in such a way as to provide the "standard" layout automatically. This, however, implies that all users are satisfied with the same layout, which is not always the case. Therefore, in order to offer still more flexibility, it is now possible for a user to define for each script a default ALV layout – the assignment being personal, i.e. for the same global script two users may possibly assign two different ALV layouts. The assignment is also possible for the own user-specific scripts. As a consequence, each time the script is performed, the default layout, if defined, is loaded automatically. Needless to say, the assignment can be changed anytime, or again deleted. It must be noted, however, that since ALV layouts are not part of the SE16XXL add-on, but are managed by ALV itself, neither the ALV layouts themselves, nor the default assignments can be downloaded or transported together with their scripts. NOTE: There is no direct dependence of ALV layouts from scripts. ALV considers layouts as associated with reports, i.e. each report has its own layouts. This works fine with "normal" reports that produce one or more ALV lists. SE16XXL however, is not a "normal" report – it is a program that produces all kinds of lists, with all kinds of structures. If the ALV layouts would be associated with this one program, the user would have to choose between all defined ALV layouts for all possible scripts and tables. For this reason the ALV layouts are associated in SE16XXL not with the program, but with the combination of DDIC tables that constitute the result list. For example, all scripts producing a join list of VBAK plus VBAP share the same ALV layouts. If the user enhances such a result list by performing an additional join with VBUK, the new result will now be implicitly associated with the layouts pertaining to VBAK, VBAP and VBUK joined together. For more informations regarding this topic please refer to Default Layouts. Back to the top



List of DDIC Tables/Views used in Scripts At times both users and administrators have been wondering about which database tables and views are being addressed by the more or less numerous SE16XXL scripts defined on a given client. A definite answer to this question (and similar ones) was up to now very difficult to give, owing to the fact that in the script catalog only the first table of each script is explicitly visible. The ones used internally are only visible in the detailed list of the script operations, which must be produced separately for each script. A tedious and error-prone procedure. This shortcoming has now been removed. A utility program is now available which produces four different kinds of lists – all revolving around this topic. The selection screen has the following appearance:

For more specific informations please refer to List of Script Tables. Back to the top



New Transaction Code /TFTO/SE16 One of the reasons why some companies switch from standard SE16 to SE16XXL are the comprehensive authorization and permission checks available in the latter. This means, however, that the involved users get several additional features at their disposal, which, from the company's perspective, are not always desirable. For this reason a stripped-down version of SE16XXL, named /TFTO/SE16, has been made available. It offers full authorization and permission checks like SE16XXL, without the enhanced features, i.e. no scripts, no joins, no formulas etc. The selection screen is as follows:

In the result list the only "complex" feature available is the menu function

Extras Add text columns which adds explanatory texts to the original columns. Back to the top



Improvement of the Start File Definition Up to now the upper part of the start file definition screen, the one containing the columns, was fixed. If the start file consisted of more than 9 columns, the user had to scroll up and down in order to see them all. This limitation has now been removed. The two parts of the screen are now variable, the separating sash can be moved. As a default the program tries to show as many columns as possible, keeping at the same time the size of the lower part at a reasonable proportion. Example 1 – Three Columns:

Example 2 – Seventeen Columns:



Second Improvement Up to now, if the column definition prefixed to the start file contained errors, owing to faulty DDIC assignments (for example when uploading a start file produced on another system), the whole definition would be ignored:

This reaction may be a bit hard on the user, especially if the start file contains numerous and possibly complicated columns. Therefore now the program, instead of rejecting the definitions en bloc, just deactivates the faulty ones, thus offering the user the possibility to react in a reasonable way:

The column definition shows the details:

Back to the top



Improvement of the Headings Definition Among other things the screen for defining the List Headings offers the possibility to rearrange the order of the output columns. Up to now this could be performed in two ways, either by changing the ALV position using the corresponding drop-down list, or by moving the columns around with drag & drop on the lower part of the screen. Both methods are quite cumbersome. Therefore a third way has been added in order to make the whole operation easier. The button is now available on the screen – it calls the same unified selector which is used in the result list for the same purpose:

After pressing the button the field selector dialog window shows up:

…

The rest should be obvious. Back to the top



Script Favorites Script Favorites or just Favorites have been introduced in order to enable users to impart a certain structure to the scripts they most often make use of. Favorites may be employed instead of the usual F4 help to choose the script to be performed. An appropriate button has been provided to this end on the first screen of SE16XXL:

When this button is pressed, the user's favorites show up:

A representation in list form is also available:



As may be inferred from the above pictures, folders and subfolders can be inserted into the favorites, grouping in this manner the scripts according to various criteria. So-called Global Favorites may also be included. These are collections of global favorites that are maintained independently by the users responsible for the creation and maintenance of global scripts. Included global favorites are just a reference to the actual folder. When the original global favorites are changed, these changes are reflected immediately in all user-specific favorites that include them. Favorites Maintenance There are various ways to add a script to the own favorites. The most straightforward one is from the first screen of SE16XXL:

When is pressed, a dialog window shows up with the appropriate options:

For detailed informations regarding this topic please refer to Script Favorites. Back to the top



Improvements of the Script Catalog Download and Upload of Scripts with their Variants Up to now script variants had to be downloaded and uploaded separately from their scripts. This functionality ist still available. But now it is also possible, when downloading scripts in the script catalog, to download the associated script variants. This is achieved by answering with to the following prompt:

In a similar fashion, when importing scripts from a previously created download file, it is possible to import the associated variants:

Existing script variants of a target script are overwritten (including the protected ones). Existing variants without a corresponding uploaded variant are left unchanged. If the option is NOT checked any existing script variants of an existing target script are left unchanged.

IMPORTANT: Do not make use of this option if protected variants of other users should be left unchanged. Instead upload the script variants separately with the menu function Goto Script variants … on the first screen of SE16XXL.



Renaming Scripts Virtually during Upload When a backup file is uploaded, it is now possible to change the names of the contained scripts in a virtual fashion. The user has the opportunity to overwrite the names individually, or to carry out global changes, like adding a prefix or a suffix, or replacing a specified string with another one. After this the upload behaves as if the scripts on the backup file had the modified names from the start. The file itself is not changed. The changes only take place in virtual memory. In order to take advantage of this new functionality, the following option must be chosen when uploading a backup file by means of the script catalog:

As a result an appropriate dialog window pops up:

By making use of the function various global changes can be applied. For more details please refer to Renaming Scripts Virtually during Upload. Back to the top



Internet path (http://) as documentation path When specifying the path for documentation (making use of the menu function Goto Path for documentation) it is now possible also to specify an internet path in the form http://… or https:// …

NOTES:

- No existence check is carried out for internet paths. If the URL is invalid, the internet browser will issue a corresponding message when the documentation is called for.

- This kind of path applies only for the MS Internet Explorer® or Mozilla Firefox® as documentation tools. It cannot be used with Adobe Reader®.

- It may be necessary to install a PDF plug-in in Mozilla Firefox® in order for external links in the documentation to work properly.

This feature should make it easier for big companies to offer a centralized path for all users, even if they usually work with different servers and possibly in different countries. Back to the top



Composite roles for scripts In order to restrict the access to global scripts, a perform role and a maintain role may be assigned to each global script. Only users equipped with the corresponding role may either perform or maintain the script in question. This functionality has long been available, but up to now only single roles were allowed for these purposes. Starting with version 3.2E it is also possible to assign composite roles. The related F4 help has been enhanced accordingly.

denotes a single role

denotes a composite one, i.e. a role that comprises a series of single roles. The settings for script authorizations have also been changed in a similar fashion:

Back to the top



Special Authorization Checks supported This feature is something that regards more the administrator than the normal user. However, it may also be interesting for normal users to know what is going on behind the scenes, so to speak. In SE16XXL up to now the selected records could be subjected to "normal" authorization checks, i.e. certain fields, defined in the related settings (Record Level Authorizations), would be checked against associated authorization objects. Each record would be inspected independently of the others, the involved criteria being contained in the record itself. This has worked well up to now, and will keep doing so in the future. For some companies, however, these checks at record level are not sufficient – what they need are more complex authorization checks involving more than one table and more than one record. As may be imagined, it would be almost impossible to set up a table driven customizing that can account for all possible combinations of tables and fields. Such all-powerful constructions usually are able to support any situation, except unfortunately the one needed. For this reason a more practical approach has been chosen – for each envisioned Special Authorization Check, an individually coded routine is provided. The table/field combinations for which this routine is to be activated is then specified in a separate customizing. For the time being two such checks have been implemented and can be activated:

1) Allow a given record containing a customer number (KUNNR) to be displayed only if the user has an authorization for at least one of the company codes (BUKRS) contained in the KNB1 entries associated with this customer number.

2) A similar check involving the vendor number (LIFNR) and the company codes contained in the associated LFB1 records.

Normal users may not be aware of these checks. The message informing that some records were withheld does not tell what kind of authorization was carried out:

For more informations refer to the corresponding documentation (for administrators). Back to the top



Adding Descriptive Texts

It is now possible to enrich the result list with additional text columns. Suppose for example that the result list contains entries of table VBAK (Sales Document: Header Data). Among the many fields of this table let's consider VBTYP, AUART and VKORG. The contents of these fields consist mostly of a combination of letters and/or numbers which are meaningful only to technically minded users. A small portion of such a list could appear as follows:

For normal users it would be much better if these cryptic fields were accompanied by their descriptive texts, as exemplified in the following list:

This functionality is now available under Extras Add text columns. For more information please refer to Adding Descriptive Texts. Back to the top



Option for double quotes Text fields beginning with a double quote (") may cause display problems with Microsoft® Excel. In order to avoid such problems a new option has been made available when saving a result list to a server file:

The same option is also available when a result list is downloaded to a frontend file using menu function List Donwload to frontend file:

Back to the top



Table Wizard renamed SE16XXL The Table Wizard has always been called SE16XXL by most of its users, according to the main transaction code /TFTO/SE16XXL. Owing to this fact the program has now been officially renamed "SE16XXL". All occurrences of "Table Wizard" in the screens and lists as well as in the documentation have been replaced accordingly. Only the "historical New Features" part has been left unchanged. Back to the top



Direct Result of Script in Background to SAP Spool

It is now possible to direct the result list of a background script to SAP spool. The request popup has been enhanced accordingly:

Notice that an ALV layout ( ) and a spool list recipient ( ) may be specified. The latter works exactly as in the standard SAP job scheduling. When (continue) is pressed, the standard Print Parameters dialog box shows up:



Press the button to set the parameters according to your preferences:

IMPORTANT: is is not possible to print more than 255 columns. Unless you have deactivated the notification via SAPmail, a popup will appear on your screen when the script is finished:

By clicking on the SAPmail will open up immediately:



The spool request may be displayed either by making use of the menu function Document Execute (in the SAPmail) or by means of the standard transaction code SP01 (Spool Request Selection). Either way you will find your spool request:

NOTE: In case "Print out immediately" has been chosen, the print request could already have been deleted. Use the button on the application toolbar to display the result list:

Notice than none of the usual SE16XXL functions are available. Back to the top



Improvements of the Formula Editor Search function for ROW fields The row fields of the result list have always been available in the tree at the right of the editor pane:

However, searching for a particular field could still be challenging if the involved table(s) contained hundreds of fields. For this reason a search function has been implemented. NOTE: the search function works only if the row fields node has been expanded. After pressing the following dialog box appears:

You may enter a complete field name (like MTART) or just part of it. Wild card (*+) characters can be used but are not required. For example "MAT" will find MATNR, MATKL, PMATA, BMATN, MATFI and RMATP in succession (each time after the first hit the button has to be pressed).



Icons with Quickinfo supported It is now possible to define icons with a quickinfo (also called tooltip). An example will illustrate how this works:

The result may look like the following (notice the quickinfo):



CONVERT Statement allowed The ABAP statement CONVERT may now be used in an SE16XXL formula. This statement is especially useful for converting a date plus time into a UTC time stamp and vice versa (see next topic). Standard Help available for ABAP statements The standard help which is normally available in SE38 is now also at your disposal in the formula editor. All you need to do is double click on the statement of interest:

Click

The ABAP help will then show up:

Back to the top



Improvements of the Script Catalog Each line of the Script Catalog list represents one script. With each new version of SE16XXL more attributes have been assigned to scripts, so that at present it is difficult to make them all visible at once on the list. In order to overcome this difficulty the standard ALV function (Details) has been put at the disposal of the users:

A typical output for a given script could look as follows:

Notice that only the non-initial values are shown.



Parameter transactions associated with a script It has long been possible to assign a transaction code to a script. Now this kind of assignment can be made visible in the script catalog. Two new columns have been provided for this purpose: - TCode for the first or only transaction code; - More to show that more than one transaction code is assigned.

A double click on the transaction code will display its definition in detail:

A double click on will list all assigned transaction codes:

Back to the top



Improvements of the Special Selection Screen SelOpts of a Selection Block in any order When defining a special selection screen for a script, it is now possible to rearrange the order of the SelOpts of each block – putting for example the most important ones at the top of the block. An example will show how this may be carried out. The script in our example features KNA1 (customer master) joined with KNVV (customer sales data). A special selection screen has already been defined:

However, the end user of the script has signalized that the most important selection criteria are Country and Postal Code for KNA1, and Price Group and Customer Group for KNVV. Accordingly we will rearrange the SelOpts on the two blocks. We start by calling the Script Catalog and using the function on the application toolbar. The dialog for defining a Special Selection Screen opens up:



We then press the button under the KNA1 tab – the dialog box for choosing the selection criteria appears:

As we only wish to rearrange the order of the criteria, we choose the second tab

to obtain the selected ones:

This dialog box is similar to the one used to rearrange the order of the columns of the result list, and works in the same fashion.



By means of Drag & Drop we put LAND1 and PSTLZ at the top:

…..

When we return to the selection screen definition, the criteria will now appear in the new order:

By repeating the procedure for the KNVV block we will have rearranged the criteria to the satisfaction of the script end user.



Texts on Filter Blocks without Aliases Suppose in the previous example that a filter has been added at the end of the script. This filter is then added as a third block to the special selection screen. Up to now the texts associated with the filter criteria would have been prefixed by the corresponding alias. This shortcoming has now been eliminated:

Notice also the rearrangement of the filter criteria. Back to the top



Default Script Variants Script Variants are practical because they not only enable the user to choose predefined sets of selection criteria when performing a given script, but also support date, time and TVARVC variables. It is now possible to define for a given script a Default Variant, which is loaded automatically each time the script is performed. In this way the variables used on the special selection screen are automatically set to their desired values. The user, when performing the script, does not have to bother about loading the "right" variant. However, it is still possible to load any other variant, if this is desired. An example will illustrate how all this is carried out. We start from the Script Catalog with a script that reads the change documents (tables CDHDR and CDPOS):

When the script is performed ( ) the special selection screen shows up:

The next step is to create the script variant that will be declared to be the default one. This is done in the usual way by pressing on the system function bar. We create a variant named CURRENT_MONTH which makes use of a dynamic date variable for field UDATE (Date of Change):



After saving the selection screen reappears:

We now go back to the Script Catalog and after positioning the cursor on our script choose Script Features Set/Reset default script variant from the Menu. The following dialog box pops up:



We make use of the F4 help to select our variant and then conclude the operation by pressing . The result can be seen on the Script Catalog list:

Now we perform the script once more ( ) to check the result of the assignment:

Notice the message on the status bar. From this moment each time the script is performed the default variant will be automatically loaded as shown in the example above. The default assignment can be changed or reset any time by calling again the menu function Script Features Set/Reset default script variant. It is important for users to be aware of the default variant assignments. To this end several enhancements have been implemented. These will now be briefly discussed.



When a variant is chosen on the selection screen ( on the application toolbar), a list of the available script variants shows up:

The icon indicates the default variant, if any is assigned. The same icon is used by the Tool for downloading, uploading and deleting script variants, which can be reached from the first screen of SE16XXL via menu function "Goto Script variants …" :

When the default variant of a script is saved after a change, the following warning is shown to the user:

Similar warnings appear when default variants are to be deleted. Back to the top



Additional Improvements Script Editor - last used formula available after a SELECT operation The scope of a formula in a script is limited by the SELECT operation that follows it. In dialog mode, when a join is performed, the user may specify that the currently active formula be retained after the join:

Owing to the complexity of the situation, up to now this feature has been unavailable in the Script Editor. This shortcoming has now been removed as follows: If a formula is inserted or appended after such a SELECT operation, the Script Editor notices that up to this SELECT a formula was active, and consequently opens the following dialog box:

If the user answers with , the last active formula is inserted, possibly adjusted in regard to the aliases.



Script Variants – Date Variables with Plus and Minus Some of the dynamic date variables available for script variants involve an interval relating to the current date or month:

…

Up to now this interval always had to contain the current date (or month). While it was possible to define an interval from X days in the past to Y days in the future, it was not possible to specify from X days to Y days, both in the past (or both in the future). This shortcoming has now been eliminated. For example, in case the variable "current date -/+xxx, current date +/-yyy (days)" is chosen, the following dialog box will appear:

It is thus possible to choose any combination of plus and/or minus.



Start File Definition - Header Line Selection When the structure of a start file is defined, it is possible to select the header line containing the names of the involved columns by making use of the button

on the application toolbar:

Up to now only the column names were taken from the line, whereas the short and long texts remained unchanged. In the new version both the short and the long texts are also overwritten:



Script Short Text as Title (User Setting) In the User Settings it is now possible to specify that the script short text be used as title for the selection screen and/or the result list:

Example of selection screen:

Example of result list:



Improved Support of ALV Layouts Up to now, if an ALV layout was selected on the result list, the column widths were automatically optimized. This shortcoming has now been eliminated. It is now possible to define an ALV layout in which certain columns are either wider or narrower than normal. A given column may be set wider than usual to emphasize it, while another one containing very long texts may be shortened. An example will illustrate these effects. We start with a list of KNA1 entries:

The column widths have been automatically optimized by ALV. Now we load a layout that makes column KTOKD wider and STRAS narrower:

This also works if the layout is chosen beforehand on the selection screen ( ). Another improvement involves the function "Execute and print" on the selection screen. Up to now any chosen ALV layout was ignored. Now it is taken into account.



Script Documentation available in the result list Up to now the documentation of a script was only available in the Script Catalog (to be shown by means of a double click on the corresponding dot) …

… or on the selection screen by means of the button on the application toolbar:

Now the script documentation can also be reached from the result list by using the menu function Goto Script documentation. In all cases the same information is shown – as in the following example:



Spreadsheet in Place – Same Title as the Result List Up to now the "Spreadsheet in place" always used the same kind of title, indepen-dently of any user settings in regard to the result list. This shortcoming has been eliminated. The title of "Spreadsheet in place" now reflects the one of the result list:

Back to the top



Transport of Scripts It is now possible to transport scripts (and optionally their associated variants) from one system to another by means of regular transport requests. The functionality is available in the main list of the Script Catalog. Both global and user-specific scripts may be transported. The same authorizations that enable a user to change a script are sufficient for adding the script to a transport request. Only the administrator has more rights. The operation is straightforward. We start with a list of global scripts and select the ones we wish to transport:

We then choose the menu function “Selected Scripts Add to transport request”. A prompt for a workbench request shows up:

After selecting an existing transport request or creating a new one we obtain the following confirmation:

For more information, please refer to Transport of Scripts. back to the top



Unified List Field Selection Dialog Box For all three display modes (SE16 standard, ALV list and ALV grid) it is now possible to use one and the same dialog box for choosing the fields to be shown in the result list. This new dialog box replaces the old one for SE16 standard mode. In case of ALV, it is up to the user to decide – the new dialog box can be deactivated by calling the User Settings ( ) and deselecting the option:

The new dialog box can be called by pressing the button on the toolbar:

For more details please refer to Unified Selection Dialog Box. back to the top



Columns in any Order in Standard Display Mode Up to now the columns in SE16 standard mode were always displayed in the Data Dictionary order. Now it is possible to rearrange them just as in the two ALV modes. Make use of Drag & Drop on the second tab (Output Fields) of the List Field Selection Dialog Box ( ) to put the fields of the result list in the desired order:

Drag & Drop

If the new order does not please you, press the button to restore the original Data Dictionary order. For more information, refer to Unified List Field Selection. back to the top



„Freeze to column“ Function in all Display Modes Until now, only the two functions „Freeze key columns“ and „Unfreeze key columns“ were available in SE16 standard mode. This limitation has now been removed. In standard mode the function is in the menu under Settings Freeze to column In both ALV modes the menu path is: Settings Columns Freeze to column Before calling the function, select the rightmost column to be frozen:

As a result, the first three columns of the list will remain fixed when scrolling to the right:

back to the top



New Filter Option So far a filter was always defined by specifying the criteria of the rows to be kept. Thus it was very easy to make a positive choice, keeping for example all customers situated in a particular city, or all accounting documents produced in a given year. Even more complicated criteria were no problem, like keeping all materials of given types, with given units of measurement, whose master records had been changed in a given month, and so on. It wa however much more difficult to make a negative choice, like excluding from the list the materials matching the above mentioned criteria. The task could still be mastered for single criteria. Yet with more than one criterion involved, the specification could easily lead to misunderstandings and faulty criteria. To overcome these practical difficulties, the filter dialog box has been enhanced. It is now possible to always state the criteria in a positive fashion and then use these criteria either to keep or to hide the matching rows:

corresponds to the behavior up to the present version.

is the new option. back to the top



Virtual Joins It happens at times that a particular join is envisioned, which, due to the lack of adequate secondary indexes, is impossible to carry out for all practical purposes. In other similar situations, owing to the small number of rows of the table to be joined, the operation may well be performed, but with bad performance. To overcome these difficulties, „virtual“ joins have been introduced. On the surface, a virtual join behaves like an ordinary join: the results are identical. Internally, it functions in a different manner: An ordinary join makes use of the SQL clause „SELECT … FOR ALL ENTRIES“, which fetches all necessary rows (and only these) from the database, passing them along in small packets. This procedure works fine if there exists an adequate index (primary or secondary) for reading the involved rows. A virtual join on the other hand only uses the criteria specified on the intermediate selection screen (which is mandatory) to fetch the rows of the table to be joined. In such a situation only a small fraction of the rows selected may be necessary to perform the join – still this is much faster than trying to select only the relevant ones. Once the rows are available, the join is carried out as usual in memory. Virtual joins open new perspectives for the interested user. Joins that up to now were unthinkable are now an option. It may even pay off to use a vitual join in situations where the necessary index does exist – the overall performance of a particular join ultimately depends on many factors, and only by trial and error can the best result be obtained. Normally the „virtual“ option is really an option. In case of a full join it is mandatory and cannot be deactivated. NOTE: even if we have been talking all along of „joins“, all that has been described above also applies to the „Select for all entries“ operation. We will now show an example of a virtual join, just to give you an idea of what it’s all about.



Example: Suppose you have a list of entries of table VBUK, which among others contain field VBTYP (Sales Document Category). Field VBTYP is associated with domain VBTYP, which is defined in the Data Dictionary with a series of fixed values. Table DD07T contains the short texts of the fixed values of domains. However, no secondary index is defined for field DOMVALUE_L, which could be used for joining: an ideal candidate for a virtual join. Starting point – list of VBUK entries:

We mark the VBTYP column header and specify DD07T as table to be joined:

On the ensuing dialog box we check the „perform join virtually“ option:



We proceed by pressing the button – the intermediate selection screen appears:

All rows of DD07T that satisfy the selection criteria will now be fetched from the database. After the join has been performed, the result will be:

back to the top



Full Join So far, two kinds of joins were available: inner and outer. Both kinds work in an asymmetrical fashion, starting from a list of entries and joining them with the matching rows of another database table or view. On the right side of the result, only such entries that correspond to one of the entries of the original list are to be found. These joins work fine for most purposes, because usually the envisioned result list is centered on a particular table whose entries are successively enriched with additional information. However, if the goal is to determine which entries are missing on either side, a new kind of join is needed: the „full“ join. A full join has a symmetrical nature – it joins the matching entries at the right side with the ones at the left, and vice versa. While the left side of the result was always present up to now, with the right side occasionally missing in case of an outer join, entries can be missing on both sides with a full join. The best way to illustrate this behavior is to go through an example. We will join material short texts (MAKT) entries of one language with those of another, the goal being to find the missing ones on either side. This join involves the same table on both sides. However, a full join can obviously also be performed between different database tables and/or views. NOTE: when a full join is performed, it is sensible to select all involved entries, as those entries which actually have not been selected will otherwise be perceived as missing. W

e start with the list of all material short texts of language „E“:

Then we mark the MATNR column and press the button on the toolbar.



The dialog box for specifying the table to be joined pops up:

The dialog box with the join criteria comes up next:

Notice that the option is set and cannot be deactivated. Additionally, the „Continue“ button ( ) is deactivated. The only way to proceed is to press the button. To our surprise, however, the following dialog box appears instead of the intermediate selection screen:

Here we specify the name of the common fields (in this case only one) to be added to the result list in order to have a column that is always filled, even if the corresponding value is missing on either side. If such common fields were not added to the list, it wouldn’t be possible to sort it in a consistent and meaningful way.



Now the expected intermediate selection screen shows up – we enter language „DE“ as the only criterion:

Notice that even the field MATNR, which would normally be protected in a join, is available. The reason for this is that in case of a full join only the selection criteria specified on the intermediate selection screen are used for the database access. The final result may look like the following:

Notice the common field at the left. It is always filled even if one of the two sides is missing. back to the top



Join Criteria with Interval Selection Some companies keep track of the most important sales and accounting documents by updating every day special database tables similar to NRIV, which contain for each number range and date the lowest and highest number of the related documents. In this way it is easy for other programs to select the relevant documents created in a given period of time. Until now, such tables carrying interval information could not be used meaningfully with SE16XXL. Now this gap has been closed. In order to show how an interval selection might work, we will discuss an example involving a supposed customer table called ZRVNRIV, which contains the number intervals of sales documents for each number range and date, joined with standard table VBUK (Sales Document: Header Status). ZRVNRIV has the following structure (derived partially from NRIV):

We begin by selecting the entries with DOC_DATE between January and June 2013. In the resulting list we mark the lower and upper limit of the document numbers:



Our goal is to select the matching entries of table VBUK. Since we assume that the entries exist, we can safely perform an inner join ( ):

After specifying the desired table, the dialog box for the join criteria pops up:

SE16XXL doesn’t know what we are up to, so the fields on the right are empty. We enter VBELN in both fields and then press the first button to select „Lower limit“ as operator:

We do the same with the second button, this time choosing „Upper limit“.



Since the interval fields of table ZRVNRIV are much longer than the VBELN field of VBUK, we also switch the partial fields on in order to enter the appropriate offset. Our dialog box now looks like the following:

The final result is shown below – to better illustrate how the intervals have been joined, the display mode has been set to ALV list with separator lines:

NOTE: only one interval can be specified in one set of join criteria. Additionally, both the lower and the upper limit must be present. back to the top



Join Criteria with Prefix Selection Normally, when a join is performed, the complete contents of the involved fields are used as selection criteria. At times, however, it would be useful to be able to perform the join using the values as a prefix. A small example is best suited to illustrate such a situation. Suppose you have selected purchase orders (EKKO). It happens that when a customer order is entered into the system, some users type the number of the related purchase order into field VBKD-BSTKD_M (Customer PO number as matchcode field), which is 35 characters long, , followed by some kind of comment, like „4509876352 – as soon as possible“ Now a secondary index is attached to BSTKD_M – but up to now it would still be impossible with the available join criteria to perform such a join. For this reason a new join operator „as Prefix of“ has been introduced:

In our example the join criteria would be as follows:

back to the top



Select-Options with thousands of entries Up to now, if you tried to run SE16XXL with a select-option containing thousands of entries – something that can be easily achieved by copying a column of a spreadsheet to the clipboard, and then uploading the select-option entries from the clipboard – the result would have been a short dump:

This happened because an SQL statement must lie within given bounds, which in this case were exceeded. To overcome this difficulty a special processing has been implemented in SE16XXL: when a select-option contains a large number of entries, the involved SELECT statement is performed in a different way to avoid exceeding the prescribed limits. However, the following conditions must be met:

- Works only with main selection screens, not intermediate ones; - Only one select-option may contain a large number of entries; - The entries should all be single values with the operator :

If these conditions are not met, the SELECT operation is carried out in the usual way and the result will again be a short dump. back to the top



Global Parameters At times, scripts contain formulas taht are based on a constant value or a series of constants needed to perform some kind of calculation or to divide the rows into different categories. So far, if the user wished to obtain a series of results based on different constant values, the only way was to make a copy of the script for each new constant, changing the formula each time by means of the script editor – a time consuming and not particularly elegant procedure. To remove these problems, Global Parameters have been introduced. They are defined during the construction of a script and are accessible, as soon as they have been declared, to all formulas of the script, regardless of the join level. There are two kinds of global parameters: parameters proper, which can only assume one value, and select-options, which may assume a series of values, just as ordinary select-options would. Any defined global parameters are available in the formula editor on the Drag&Drop tree on the right side of the screen („Global Parameters“). In the formula coding, a global parameter is addressed by writing its name between two question marks like ?PARAM? or ?SELOPT?[ ] – assuming PARAM and SELOPT to be the respective names. Once a global parameter has been referenced in a formula, it can neither be changed nor deleted, since this would invalidate the formula. By means of the script editor it is possible to change or delete any global parameters defined in the script, but as a consequence all involved formulas must be readjusted. The last step of the whole procedure is to define a special selection screen for the script. The global parameters of the script, if any have been defined, will be available on the second block of the special selection screen. Up to ten parameters and/or select-options may be placed on this block. When the script is performed, the user enters the values of choice for the global parameters available on the special selection screen, and these are passed along to the various formulas of the script. In this fashion, one script can be used to obtain a wide variety of results. For more information, please refer to Defining Global Parameters. back to the top



Scripts performed „with Reduced Memory Usage“ Up to now, when a script was performed, all fields of the selected rows of the involved database tables and views were read, causing SE16XXL at times to go out of memory, thus ending the session with a shortdump. This behavior made it rather difficult to analyze large amounts of data, because most database tables consist of many fields, which – until now – were read even if they did not contribute to the script results. In order to mitigate these negative effects, the option „with reduced memory usage“ has been introduced for performing a script:

On the surface everything looks the same when the script is performed making use of his new option. The result list has the expected appearance: t



But if we take a look at the details of a given result line, we will find that only the relevant fields of the involved tables are available:

When the option „with reduced memory usage“ is activated, only the key fields and the fields needed to produce the result of the script are selected from the database. The memory consumption can thus be lowered considerably. The downside of this option is that, as may be seen above, only these fields are then available for the result list. However, this is not a real problem. If you wish a particular field to be present on the result list, just choose it on the selection screen by making use of the menu function Settings Choose fields for list. This is because all fields of the result list of the script are selected. NOTE: This option is also available when performing the script in background:

back to the top



New Operation „Count Sorted Rows“ Up to now, counting the rows of the result list according to some given criteria could only be accomplished by means of a formula with global scope involving STATICS variables – a rather complicated and error prone procedure. In order to offer this functionality to all users, independet of their ABAP skills, the new menu operation Extras Count sorted rows has been introduced. It is quite easy to use and can even be called more than once for the same result list, using different sort criteria, without having to care about complicated formulas. Before calling the function the result must be sorted in some way. Otherwise you get the following message:

We will now illustrate how this function is used by making an example starting with table MVKE (Sales Data for Material). Our goal is to count how many materials are defined for each combination of sales organization and distribution channel. We begin by sorting the list by VKORG and VTWEG:

After calling the menu function Extras Count sorted rows the following dialog box shows up, asking for the name of the V-field that’s going to contain the counter:

V-fields (the „V“ stands for „varied“) are a new kind of field, similar to X-fields (formula fields), and may be used for any kind of special purpose.



As soon as the counter field has been specified, the following dialog box appears – the same one that is also used by „Hide rows with duplicates“ and similar functions:

We could deselect the VTWEG field if we simply wished to count the materials per sales organization. In this example, however, we acknowledge the criteria as they are. Now the result list reappears, enhanced with a new column at the right containing the counter values:

The counter field is preceded by the pseudo alias V, just as formula fields are preceded by an X. Notice that all materials belonging to the same combination of sales organization and distribution channel carry the same counter value. In this example, the individual materials are of no particular interest to us – we only wish to get the total numbers. We hence eliminate the adjacent duplicates from the list by making use of the function (Hide adjacent duplicates). After reducing the list columns to the really relevant ones, our statistics look like the following:



We can now sort the list by V~COUNT descending to get those combinations with most materials on top:

IMPORTANT: if you wish to get a reliable result, you must make sure that you select all the involved rows, and that you have the authorization to select all rows. Otherwise your statistics will be flawed. NOTE: if the table contains a very great number of entries, first carry out the numbering using a limited number of rows, then save the whole as a script, and finally perform the script without limiting the number of hits. back to the top



New Operation „Fix formula fields“ Up to now, formula fields lived only as long as the formula that created them – additionally, if a new formula was necessary, it had to contain all desired fields. This behavior made it rather difficult to base new values on already created ones. In order to offer the user more flexibility in designing scripts, a new operation has been introduced: „Fix formula fields“. In this context, „fix“ is to be understood as „rendering the value fixed“ – i.e. independent from the formula that created it. And indeed, after this operation has been carried out, the formula is gone. The chosen formula fields are transformed into similar V-fields, possibly with a different name, but with the same characteristics are the original X-fields. The values of these V-fields are taken from the corresponding X-fields at the moment the operation is performed, and these values remain unchanged as long as the V-fields exist. V-fields survive a join – optionally. They disappear automatically only if a „Select for all entries“ operation is performed. NOTE: only the X-field values of visible list rows are copied to the corresponding V-fields – hidden rows are ignored and the V-fields assume initial values as soon as the rows are shown again. All this sounds rather abstract – an example will illustrate how this operation might be put to use. We will produce a list of accounting document segments (BSEG), each line of the list containing the amount and the percentage in relation to the total amount of the head document. The amount field (BSEG-WRBTR) references the currency of field BKPF-WAERS – for this reason we will start our example by selecting accounting headers with EUR as currency, joining them with the corresponding segments:



Since we need the total amount for each header document, we first sort the list by A~BUKRS, A~BLENR, A~GJAHR and B~BUZEI and then define a formula with a global scope to carry out the necessary computation:

After the formula has been activated, the result is as follows:

The last segment of each document contains the total amount. In order to eliminate the other rows, we change the sort order of B~BUZEI to „descending“ and then eliminate the adjacent duplicates by means of .



We strip the resulting list of all unnecessary columns:

At this point we have a little problem: we need the formula field X~TOTAL in order to calculate the percent values of the individual segments – but this means defining a new formula. Unfortunately only one formula can exist at any given time. And if we delete the current one, the total amount X~TOTAL will also disappear. Adding the new coding to the current formula is not feasible, as the original coding is based on a sorting sequence and on rows which in the meantime have been changed and partially hidden. What can we do? The solution lies in the new operation „Fix formula fields“, to be reached on the menu: Edit Formula Fix formula fields. The following dialog box pops up:

We leave the name unaltered and press to proceed. The list now contains a column V~TOTAL instead of X~TOTAL – the formula is gone:

Before going on, we discard the hidden rows to avoid carrying along rows that are no longer needed.



Since the previous formula is now gone, and since we still have the total amount necessary to calculate the percentage values, we can safely define a new formula for this purpose. Before doing this, however, we must again select the corresponding BSEG entries, since the previous ones have been partially eliminated. Accordingly, we perform the join once more. This time the dialog box for specifying the join criteria contains additional options regarding the V-field(s) present:

Since we need the V~TOTAL field, we leave the option unchanged. After sorting and adjusting the result list we obtain:

Each row contains the total amount and the segment amount. By using these two values it should be quite easy to compute the desired percentage value.



We define the formula as follows:

The final result is (we have added extra lines to separate the main documents):

Although it is not strictly necessary for the overall result, we could make use of the „Fix formula fields“ operation once more and convert X~PERCENT into V~PERCENT. back to the top



New User Settings It is difficult to find two persons that agree on every aspect of a particular topic. The same applies to the way they carry out a given task, or make use of a given instrument. For this reason, new User Settings have been introduced to SE16XXL. They allow users to personalize tha way the program reacts under certain circumstances. The User Settings can be reached by pressing the button on the toolbar of the initial screen (and likewise of the selection screen), or by making use of the menu function Settings User parameters in the result list. The ensuing dialog box now carries two tabs – the first tab (Data Browser) has remained unchanged. The new settings are situated on the second tab, titled „SE16XXL“:

The various settings will now be briefly discussed.



Use unified popup also for ALV This setting specifies that the newly introduced Unified List Field Selector is used for all display modes, including the two ALV modes (list and grid). If the option is deactivated, the standard ALV dialog boxes are used. Use script name as selection screen title Up to now, the title on top of a selection screen only told something about the database table (or view) involved, regardless of the script being performed. With the new setting, the name of the script currently performed is used instead. The setting has no effect on intermediate selection screens, because in this case any script involved is being „extended“ and thus is not in control anymore. Use script name as result list title Similarly, the title of the list resulting from performing a script may be set to contain the name of the script instead of the database table(s) and/or view(s) involved. Selection Screen – display both the field name and the field label So far, either the field name or the field label were present on any given selection screen, depending on the primary setting on the Data Browser tab:

By activating the new option both values will be visible on any selection screen (what value appears on what side depends on the primary setting):



Confirmation prompt when exiting SE16XXL Until now, no warning was issued when exiting an SE16XXL session, regardless of the join level or any other complicated operation carried out up to that moment. This could mean that a lot of work would need to be repeated if the user forgot to save and mistakenly pressed the wrong key. To avoid such inconveniences, activate this option. When leaving the session, either consciously or inadvertently, SE16XXL will issue the following prompt if any kind of operation has been carried out and not saved as a script:

The default answer is No, which means that by pressing ENTER the session will not be closed. Confirmation prompt when going back one result level This option is similar to the one discussed above, the difference being that the prompt is also issued when you leave one result level to return to the previous list (by pressing ). The prompting message in this case is as follows:

This setting has been implemented to satisfy all possible users, but in my opinion it might become a real nuisance on the long run. Practical experience will show. NOTE: Both settings have no effect when using transaction /TFTO/SE16SCRIPT or parameter transactions derived from /TFTO/SE16PARAM.



Confirmation prompt when exiting a background result list Up to now, leaving the result list of a script run in background meant deleting it. This somewhat unpleasent behavior was meant to avoid overburdening the system with useless data garbage – but the downside was that occasionally important results were deleted before being completely inspected. By activating the present setting, you can avoid such disagreeable situations. Instead of silently deleting the involved background result list, SE16XXL issues the following prompt:

You are now responsible for what happens next. NOTE: this option is also relevant when using trasaction /TFTO/SE16SCRIPT. Spreadsheet in place – take reference fields of currency fields into account Currency amount fields (type CURR) are stored in SAP as packed fields. The number of decimal places is defined in the Data Dictionary and is not stored in the field itself. Additionally, such fields are associated with a currency key field (type CUKY). In the customizing it is possible to assign to each currency key a number of decimal places that differs from the field definition. The Japanese Yen (JPY) is an example of a currency which is usually customized with zero decimals, whereas other currencies normally have two decimal places. When the spreadsheet in place is called, the amount fields are normally output with the number of decimals defined in the data dictionary. If this option is activated instead, the currency key field associated with the amount is taken into account. Example: Suppose an amount field containing the value 1234567. The normal output would be 12345,67. With the option activated it would be 1234567 (with currency key JPY). back to the top



Download to Frontend File A new function to download the contents of the result list is now available. It can be reached via menu List Download to frontend file. The main dialog box offers options similar to those available when saving to a file on the application server:

This new download function offers more flexibility than the standard ones. One option is particularly interesting:

When this option is chosen, the contents of the result list is prefixed with a definition of the Data Dictionary fields involved. SE16XXL recognizes this column definition when the frontend file is uploaded as a start file. There is no need to specify the characteristics of the columns as with ordinary files. For more information, refer to Download to a Frontend File. back to the top



Special Calendar Functions for Formulas For security reasons, calls to function modules are not allowed in formulas. However, there are basic functionalities in the SAP system which are only available as function modules. One of these involves the calendar and the factory calendar. By using ordinary statements it is possible to perform date calculations, like today’s date plus 10 days etc. Yet it is not possible to obtain information involving the week of a given date, or about whether that date is a working day for a particular factory calendar. In order to offer users this kind of functionality without putting security at risk, a series of special functions has been introduced for formulas. They can be found on the Drag&Drop tree at the right side of the formula editor screen:

More information may be obtained regarding a particular function by double-clicking on it – the ensuing documentation groups the functions that are independent of a factory calendar and the ones that are based on a factory calendar:



In order to facilitate the use of these functions, all complications of the underlying function modules of group SCAL, like „DATE_CONVERT_TO_FACTORYDATE“ etc. have been eliminated. If any kind of error occurs, the function returns an initial value. It is therefore highly advisable to check for an initial value when using these functions. Since the last three functions need a factory calendar to work properly, a special statement (FF_SET_CALENDAR) has been introduced for this purpose. The factory calendar may be specified as a literal or as a variable (or a global parameter):

In addition, useful types are available on the Drag&Drop tree to the right:

For more information, consult the examples available in the formula editor under the heading . back to the top



Script Editor – Function „Replace SELECT Table“ Until now, it was not possible to replace the database table (or view) used in a given SELECT operation of a script. However, there are situations where such a possibility would be desirable. For example, if there is a series of tables which either exhibit an identical or a similar structure, and a complicated script has been created for one of them, it might be practical to be able to copy this one script and adapt it for each of the other tables of the series. Another example would be to replace a particular table with a projection view of it, or vice versa – for whatever reason a user might come up with. In any case, this functionality has now been added to the script editor. However, as you may well assume, there are some restrictions involved:

- If the two tables have exactly the same structure, the replacement is always possible;

- If the two tables differ in their structure but have the same key fields, the replacement may be carried out, but some further adjustments of the script might possibly become necessary;

- If the key fields are not the same, all the „used“ key fields (except the client field) must be available in the new table. „Used“ means that they participate in some operation, for example as join, sort or filter criteria. The fact that a given key field is also included in the output fields of a list (operation CHOOSE_LF) is ignored in this context. If no key fields are used, the first one must match.

- In all other cases the replacement will not be possible.

If a particular key field is missing in the new table, but is being used somewhere in the script, you may try to eliminate this usage. If you succeed, the replacement will become possible. NOTE: It is even possible to replace the table of the first SELECT operation,

except in case of a start file. To illustrate what has been discussed above we will now go through a couple of examples.



Example # 1 Replacing a table with another one with the same structure We start with a script containing, among others, table KNVV:

We will now replace KNVV with ZTXKNVV, which has exactly the same structure. To achieve this, we set the cursor on the related SELECT operation and perform a right click to obtain the context menu:



The Script Editor responds by requesting the name of the new table – we enter ZTXKNVV:

The SELECT operation now exhibits the new table – KNVV has been replaced:

Since the two tables are identical in their structure, a script consistency check ( ) will result in the following message:

Just as we would expect.



Example # 2 The structures differ, but the key fields are the same We will now replace KNA1 (the table of the first SELECT operation) with view W_KNA1, which contains only some of the fields of KNA1. Both tables have the same key fields. We proceed as in the first example, selecting the function from the context menu:

As replacement we specify W_KNA1:

Subsequently, instead of immediately showing us the result, the script editor issues the following prompt:

We don’t let the script editor intimidate us and answer with .



At first, the result is as we expected:

However, if we check the script consistency ( ), we will discover that several adjustments will have to be made:

In order to obtain a workable script, we have to eliminate all these inconsistencies.



Replacement with differing key fields Several situations may arise in this context. If all used key fields of the old table are present in the new one, the replacement should be possible. If none of the key fields of the table to be replaced are in use, the first key field of the new table (ignoring the client field) must match the first key field of the table to be replaced. Otherwise the following message will be issued:

IMPORTANT: The „Replace SELECT Table“ function is a complicated one. Actually it is intended more for replacing tables with others having the same structure. The remaining situations, where the fields and/or the key fields don’t exactly match, have only been provided for convenience, but the user should always keep in mind that such replacements probably need further adjustments. Any additional features of the script, like a special selection screen, jumps etc. are then adjusted as fas as possible automatically – but may also need to be adjusted manually. To sum it up, this function should be used „with a grain of salt“. back to the top



Additional Improvements Several smaller improvements have been implemented in version 3.2 of SE16XXL. They will be discussed briefly in the following pages. STRING and XSTRING fields supported So far, fields of type STRING and XSTRING would show up neither in a result list nor in the detailed view of a single list line. Starting with version 3.2, these fields are now available as legitimate columns of result lists. Fields of type STRING can even be used as filter criteria. Selection screens are still off limits for such fields, because select-options of this type are not supported (beginning with SAP_BASIS version 700, PARAMETERS may be declared with type STRING, but not SELECT-OPTIONS). Packed fields (TYPE P) of any length on Selection Screens Up to now, fields of type P(acked) which exceeded the internal length of 8 bytes could not be used as selection criteria. The reason was that in some earlier versions of the SAP system they would occasionally cause a shortdump. But since this problem seems to have been eliminated, packed fields of any length may now appear on selection screens. New Date Variables for Script Variants The following date variables have been added to the ones available for script variants:

In addition, certain date variables are now also available for fields of type ACCP and NUMC of length 6 or 4.



„WRITE TO“ Statement available in Formulas Until now the ABAP statement „WRITE TO“ was not allowed in a formula. This restriction has now been lifted – except for the option „…USING EDIT MASK ’==CONV’„ where CONV is a conversion exit. This is not allowed for security reasons. Column Definition of a Start File can be saved as Script Up to now, when uploading a start file, it was not possible to save the definition of the columns until the result list was visible. If the task happened to take more time than expected due to a rather large number of columns, and for example the system crashed before the user was finished with the definition, the whole work had to be repeated – a tedious and not particularly rewarding activity. Now it is possible to save the definition at any moment by making use of the save button ( ) on the system function bar:

The usual dialog box for saving a script will show up. If the definition process is interrupted for any reason, it can be resumed at a later time by importing the definition by means of the button on the application toolbar.



Reference Fields of Currency Amounts Until now, when creating a server file or calling „Spreadsheet in place“, currency amounts (type CURR) were always output with the number of decimal places defined in the Data Dictionary, regardless of the currency involved. This works fine with most currencies, like EUR or USD, since they have two decimals like most of the amount fields. But if a currency, as for example the Japanese Yen (JPY), is customized with zero decimal places, the output will be 100 times smaller than expected, transforming 12345 Yen into 123.45. This situation does not occur very often, because even some Japanese companies customize the Yen to have two decimal places in order to avoid similar problems. In any case, an appropriate option is now available on the dialog box for saving a list to an application server file:

This option is also available on the dialog box of the newly introduced „Download to Frontend“ function. In case of „Spreadsheet in place“, the option is to be found in the „User parameters“ dialog box:

…



Script-specific Maximum No. of Hits It is now possible to assign an individual maximum number of hits (as default value) to a given script, provided that a special selection screen has been defined for it. An example will illustrate how this assignment is carried out. In the script catalog we press the button on the application toolbar after having positioned the cursor on the desired script. This causes the dialog for defining a pecial selection screen to show up: s

Again, we press the button to obtain a simulation of the selection creen: s

In order to assign the individual default value, we press the button at the left side of the field. The field, which is normally protected, opens up:

As can be readily imagined, the button can be used to reset the value. In display mode an at the left of the value will indicate that it has been ndividually set: i



ALV Layouts chosen on Selection Screen So far, any defined ALV layouts could only be selected on the result list itself by making use of the button on the application toolbar. Now this button is also available on the selection screen (provided the user is in one of the two ALV display modes). Thus it is possible to preselect the layout before the result list is produced. However, a couple of things must be noted in regard to this topic:

- ALV layouts are not assigned to any particular script. They only depend on the structure of the result list, i.e. on the tables or views involved in the result list.

- If the structure of the result list of a given script is changed, for example by adding a new table, the layouts involved cannot be used anymore.

- An ALV layout cannot contain any filter information because SE16XXL does not make use of the filter functionality of ALV.

The fact that ALV layouts are disconnected from scripts is based on technical reasons: ALV assumes that a layout is assigned to a particular report – the problem is that in case of an SE16XXL result list, the report is always tha same, regardless of the structure of the list. If this strategy were to be used, all layouts available, regardless of the list structure, would show up in the value help. This difficulty has been overcome by assigning each layout to a pseudo report carrying a name derived from the table (or tables) involved. Fortunately, ALV does not check if the report really exists (other programs do). However, the downside to this mechanism is that only one pseudo report can be specified when calling the ALV layout value help. If the layouts were assigned to individual scripts, only these layouts would appear, even if many other layouts would exist for the table involved. back to the top



Permissions assigned via SAP authorization roles

This is the main focus of this new version. It is more interesting for administrators than for ordinary users. Up to now, the complex table & field permissions of SE16XXL were defined mostly by means of special “access roles”. These roles had no relation to SAP authorization roles, and therefore the assignment of these roles to individual users had to be performed independently of the normal authorization management, a situation that, especially for large companies, was particularly unsatisfactory. The new version makes it possible to associate SE16XXL access roles with ordinary SAP authorization roles:

By assigning the relevant SAP roles to users, the administrator indirectly assigns the associated access roles. Additionally, the management of permissions can be carried out according to the “four-eye principle” – i.e. one person defines the roles, another person assigns them to the users. back to the top



Problems with spreadsheet in place and Cyrillic solved

The “Spreadsheet in Place” function, which is based on a standard SAP functionality, has on Unicode systems a problem with multibyte code pages, like for example Cyrillic. When a result list containing texts in Cyrillic is displayed on the spreadsheet in place, longer texts are truncated:

This problem is intrinsically connected with the implementation of the standard SAP functionality. In order to avoid the users the effort of implementing SAP notes etc., SE16XXL has been enhanced to take care of this problem from the start. Now, when the “Spreadsheet in Place” function is called in a Unicode based system, a logical copy of the rows to be exported is created, each field of character type with a length up to five times the original length. This outsmarts the standard functionality and no truncation takes place. back to the top



F4 help for views

SE16XXL has always been capable of handling database or projection views. But the standard F4 help for tables on the first screen was (and still is) restricted to database tables. This shortcoming has now been eliminated. The first screen has been enhanced to this purpose by adding a new button at the right of the table name parameter:

When this button is pressed, the following F4 help dialog box shows up:

For more information please refer to F4 help for views. back to the top



Formula retained after a join

Up to now, the scope of a formula was restricted to the result list in which it was defined. As soon as an “Inner Join” or an “Outer Join” was performed, the active formula was discarded and had, if necessary, to be redefined for the resulting join list. It is true that all recently defined formulas are available in the formula editor under the tree node (at the right side) titled “Last used active formulas”, but most users probably haven’t noticed yet – additionally, aliases must be added to the involved row fields when passing from a simple list to a join list. All these inconveniences belong to the past. Now, when performing a join, if a formula is active, a special option to this purpose is available to retain the formula after the join has been completed:

Aliases are automatically added to the involved row fields if necessary:

This option does not apply for formulas with a global scope, because they need a special sorting which is not available in the resulting join list. back to the top



Documentation restructured

The main documentation of SE16XXL has been partly rewritten to take the developments of recent years into account. Additionally, many screens and dialog boxes now carry a button for displaying specific documentation. This should make it easier for users to get the documentation they need when they need it. Moreover, all tutorials have been completely rewritten. In this manner the reader will be able to take advantage of the newer features, like for example “jumps” or customized list headings. back to the top



Direct call of the Script Catalog when saving a script

When creating a script, it is now possible to branch immediately to the Script Catalog in order to add additional features to the script, such as a special selection screen etc. The dialog box for saving has been enhanced to this purpose:

When, after specifying the necessary parameters, the button is pressed, the current session of SE16XXL is terminated and the Script Catalog opens up – the only script on the list being the one just saved:

The user can now take advantage of all functions of the Script Catalog, like editing, defining customized headings, etc. NOTE: if a script is started from the Script Catalog using the button, the dialog box for saving as script will lack the button in order to avoid a recursion:

back to the top Copyright © 2009 – 2018 – SY-TABIX GmbH

SE16XXL – New Features – Historical List - top flow Table ...

Documents

Transcript of SE16XXL – New Features – Historical List - top flow Table ...