Repository files navigation

Now full documentation available herehttps://bizhuka.github.io/aqo

User and programmer friendly options
Create flexible application parameters with nested tables without any effort
No more headache with Z* table maintenance SM30, view clusters SE54, SM34 or range options STVARV

and then

Separation byPackage andOption ID

View change history
Integration with transport system
Editing nested catalogs (Labels & search helps)

Tables can contain checkboxes, lists, ranges, memo fields and even another tables

All you need is to describe structure(or class) in programms_opt and press F8

 TRY.        zcl_aqo_option=>create(          iv_package_id='$TMP'" Package  "#EC NOTEXT          iv_option_id='Main options'(op1)" Any text < 30 symbols          ir_data= REF #( ms_opt )" iv_repair     = abap_true        ). CATCH zcx_aqo_exceptionINTO lo_error.MESSAGE lo_error TYPE'S'DISPLAY LIKE'E'.RETURN. ENDTRY.

The main purpose of the library is to avoidmagic numbers and other"permanent data" from the code. And give the ability to user to change the"constants" in friendly interface.

Accounts by specific mask or texts in generated FI documents or range of BLART in selections are all good examples of options to maintain.

The best way to describe the library,it is something like tr. STVARV but all parameters and select-options are grouped together as in tr. SLG1, with the interface similar to SAP Fiori and displayed directly in SAP GUI via CL_GUI_HTML_VIEWER.

The maintainable data usually stored in a program structure (or in class attributes) and can contain data such as:

• ranges (SELECT-OPTION)
• parameters (any simple value as dates, time or BUKRS)
• strings (memo texts)
• any tables (structure based tables)

The first 2 are completely similar to STVARV, in strings for example you can store message templates, and tables are suitable when you need to write a large CASE that depends on a condition that can change, but creating a database table is burdensome.