A report is a formatted and organized presentation of data.

Axional Studio can be used to generate several type of reports. This software allows you to easily create both financial and operational reports with a look and feel you already know. It also provides complete drill down functionality within any custom report.

1 Definition

Reports are a type of object instance. In addition to the common components that it shares with the rest of the objects, which are defined through the object instance, it is necessary to access the reports tab to define the rest of the components.

The common components are:

  • Identification and additional info
  • Input query, variables and metaquery.
  • Object help documentation.
  • Control data

For further information on object instance definition, consult The Object Instance section.

1.1 Report tab definition

After defining the object instance and declaring it as a report type, it is necessary to access the Report tab and continue defining the report instance wic_obj_report.

  1. Settings:
    • Cache: this flag enabled indicates to save on the cache to avoid to execute it again. When the flag is disabled, the report will always force its execution, that is, it will not use the system cache.
    • Full output: indicates whether the object is fully issued without considering the limits of its database connection group (wic_conf: wic_dbms_users). These limits are the maximum number of readable records (usr_maxqrows) and the maximum number of records in printing processes through XSK Formattin Objects (usr_maxfrows).
    • Autorefresh (seconds)*: seconds for data autorefresh within the navigator (default value 0). Use it when working with critical data to frequently execute the object. When automatically executed, it retrieves data from DB, never the browser cache.
  2. Order by criteria:
    • Sort: the output order will be considered as the ORDER BY clause of the SQL statement of the object, hence it is not necessary to indicate it in the SQL syntax.
  3. Report tabs:
    • SQL Statement: The SQL statements of the object consist of the syntax of the query that the system will perform to the database, in the object execution time. The syntax of the statement can be expressed in XML or in standard SQL language, without limitation of lines of text or fragments of instructions.
    • Output: this chart maintains the association and the attributes among the fields of the SQL sentence that generates an output report and its correspondences with columns of the metadata dictionary. For further information see Output tab on following sections.
    • Styles: the style tab allows modifying the text style to be displayed or to show icons. It includes options like font type, size, underline type, effects, alignment, text and background color, width and height, border, etc...
    • Links:
  4. Project and notes: it is recommended to use these fields to document this function.
  5. Control data
    • Created by and data created: user who has created the report and when
    • Modified by and data updated: user who has updated the report and when
    • CRC: or checksum is an error detection code.
    • Rows
    • Size
  6. RCS Delta changes:
  7. Buffer edition:

    Axional Studio has the option to edit reports in Buffer mode, just by pressing the Buffer edition button. During buffer mode, the report can be modified and saved several times without the need to document the delta. Use Buffer revert button to discard changes or Buffer commit button to accept them. After commit is performed, it is mandatory to document delta.


    During buffer mode edition, all saved changes will be executed by all users.

1.2 The Output fields tab

Through this option we access to the definition of the report output fields. If the user has the required authorizations, it is possible to create, modify and delete such definitions.

In this chart, in addition to recording the output fields corresponding to the columns of the SQL statement of an object, a whole series of properties and their characteristics are also defined, both from a presentation and functional point of view.

The system performs a permanent synchronization between the columns involved in the last SELECT clause of an object and the values reported in the output fields of the same each time it is executed, so when developing objects, if the output fields are not reported, the first execution of the same will be filled in automatically.

It should be noted that an essential condition for this synchronization to take place is that the main table in the last SELECT clause of the object is not a temporary table.

Even with this system characteristic, it is recommended when creating an object to review the output columns after the first execution, since this mechanism may not be able to define hidden columns, break groups, columns that add ... subjects that are under the responsibility of the object's programmer.

In view of the possibilities provided by the definition and registration of the output fields of an object, It would be very important to pay close attention to each of the utilities previously exposed.


When a database is defined in the system configuration database ( wic_conf ) exploitation, among other data to report, there are the repositories databases that will be used.

These repository databases contain column dictionaries. Therefore, when output fields are registered in an object, these columns do not necessarily have to be defined in the column dictionaries of the database to which the object belongs.

The system performs a permanent synchronization between the columns involved in the last SELECT clause of an object and the values reported in the fields of output every time it is executed, taking into account the following considerations:

  • No column is registered: all output columns are registered in the same order in which the last SELECT clause of the object is expressed. The table name for the output columns is the name of the main table of the mentioned SELECT clause.
  • The number of columns registered is DIFFERENT than the number of columns in the SELECT clause: the system will carry out the verification process.
  • The number of columns registered is EQUAL to the number of columns in the SELECT clause: for each column registered in the output, it is checked if it matches the position in the SELECT clause.

    If everything matches, the system considers it good.

    If any does not coincide, it can be for two reasons:
    1. They are poorly ordered. The system will carry out the verification process.
    2. Some of them do not coincide. The system will carry out the verification process.

1.2.1 Order

Order of presentation (from left to right) of the columns in the report. The order indicated here must coincide with the order that the columns follow within the SQL statement, since in reports in which there are groups of breaks, if they did not coincide, it would give rise to irregularities in the output format of the resulting information.

1.2.2 Table and Column

Name of the table to which the column to be registered as the output field belongs.

The table reported here should be defined in the wic_jdic_tabdata table dictionary, and in combination with the column to register, in the wic_jdic_coldata column dictionary.

The fact that they are registered in this last dictionary is important because it will depend on the system showing the descriptions abbreviated from the dictionary, such as column titles.


It should be borne in mind that when the system detects any character of the type in the table name: ¡!""#$%&'`´()*+,-.¨·/:;<=>¿?^@|\\[{}, the system will replace it with a _ (underlined) , since these characters are not allowed as valid for the name of a table.

1.2.3 Real column


This section is incomplete and will be concluded as soon as possible.

1.2.4 Tooltip


This section is incomplete and will be concluded as soon as possible.

1.2.5 Group

Break groups for an object are used and defined when you want to make breaks within a report. The order of the breaks should be consistent with the order of presentation of the fields; otherwise there may be poorly readable formats in the reports.

Break groups are most often used when you want to obtain subtotals for certain items in the report. The fields through which you want to make a break must be assigned the same group number.

For a better view of the report, for each break group that appears in the object, the system will show it with colors of different shades, based on the palette assigned to the functional group of the object.

Important aspects to consider when defining break groups in an object:

  • Both the number of groups to establish per object, as well as the output fields that can be part of each one, are unlimited.
  • The groups of breaks to be defined must start with the value 1 , and if there is more than one group in the object, they must be correlative in their numbering; that is, jumps will not be accepted. Otherwise, the system will take notice of this circumstance and stop the execution of the object.
  • The reason for this verification is so that the color tones of the different breaks follow a predefined scale and are not disproportionate to each other.

1.2.6 Headers

The groups of headers in an object allow to make groupings of columns under the same title. The utility in the use of this type of groups is to provide the user with a more didactic and intelligible presentation of a report.

The grouping criteria of the columns responds to the existence of a common link between them, which can be of a very different nature: administrative area (purchasing, sales, logistics, etc.), type of documents (orders, delivery notes, invoices, etc.), temporary periods, etc.

The output fields that are going to belong to the same grouping must be assigned the same header group.

The header groups to be used on an object must be defined in the corresponding master for the object in question.

1.2.7 Aggregate

For those cases in which you are interested, you can indicate to the system by which output fields you want to make totals and subtotals, as well as accumulated carried forward.

The possible indicator values are as follows:

  • No . This value would be the one used for those columns in which you do not want to obtain or make any total or summation. This is the default value displayed by the system.
  • Yes . This value is the one that will be indicated for those numeric columns, for which you want to obtain a total of the column, as well as subtotals in the cases in which the object has break groups.
    If the object had no break groups, it would simply present a Grand Total at the end of the report.
    If the output field consists of a column of type percentage, the system will also calculate the percentage of totals and subtotals, as long as the columns involved in the calculation of the same (dividend and divisor), also get totals.
  • Accumulated . This value will be reported in those cases in which you want to drag an accumulated value for each record that is displayed.
    If the object had breaks, in the columns in which this value was reported, the total of the break will coincide with the amount accumulated until the break.


An example of a very typical report for this type of totalizer is that of an account statement. This report shows accounting notes of an account with the following amounts:

Cumulative Type Totalizer
Account Description Entry Debit Credit Accumulated balance
5700 Cash 1 1000 0 1000
2 500 0 1500
3 0 300 1200
Grand Total 1500 300 1200

1.2.8 Decimals

By means of this parameter, we indicate to the system the number of decimal places of precision that we want to show us in a numerical field.

When you want the system to display the same number of decimals as that of the field's own physical definition within the table to which it belongs, then we will indicate the value Auto here. This value is the one presented by the default system. In fact, for those fields that are alphanumeric it will be the value used, regardless of the one that has been reported.

If the physical definition of the field does not support decimals, the system will not display decimals even if it is prompted to do so. For this it would be necessary to vary the physical definition of the field itself.

1.2.9 Color palette

The report outputs can colorize data cells depending on its content, generally to emphasize the importance of a cell amoung a group of cells or to classify the dataset when it contains numeric values.

Just by indicating the color rule definition rule_code in the out_palette field is enough. Use the Table Colorizer tool and you will make easier to analyze reports at a glance.

1.3 Additional information

The Process type execution that made transactions and performed a report, has been replaced by a Report instance without cache and a Full Output (without query confirmation).

Review pending