A report is a formatted and organized presentation of data.

Axional Studio can be used to generate several types 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 SQL conditions.
  • 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 executing 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.
    • 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: hyperlinks to other objects (target) defined in repository databases, which provide information related to some concept of the source object.
    • Page links: create links to move easily between reports.
    • PDF Confing: cofigure the PDF of the report with a different look than the same report on screen.
  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: all changes in the Report definition will be registered. Use the opportunity to properly document each modification.
  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 SQL Statement

The data displayed in the report is configured via the SQL Statement text area box. The statement may consist of a SQL query or an XSQL-Script returning a result set.

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.

Each SQL statement may include the following injections:

  1. $0: this injection allows the user to configure and filter the report by selecting values.

    The list of values will be injected in the $0 clause. Therefore, when value filters are enabled, the WHERE clause must follow this format: [name_of_column] IN $0.

  2. $METAQCOND: this injection allows the user to filter the report. Permitted filters will be defined in the SQL Condition box.

  3. $GROUP: this injections allows the management of dynamic groups, so the user can reorder columns, by the drag and drop mode and instantly, if they are defined as break groups. For further information see Dynamic groups in next chapter.

1.3 The Output fields

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.3.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.3.2 Table and Column

Name of the table to which the column to be registered as the output field belongs. When the column has an alias, this has to be reported in this field.

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.

Three colored circles appear next to the table name. Each circle is a link to an option of the table or column. If this circle is shown in gray, that option does not exist and the link is not available.

  • ⬤ Red: link to the physical schema of the table.

  • ⬤ Magenta: link to the attributes of the column.

  • ⬤ Purple: link to the column dictionary of the table.

  • ⬤ Grey: no link is available.

1.3.3 Real column

The real column corresponds to the real name of a column when it uses an alias in the output column field.

For example, when the select obtains columns from several tables, there is a possibility that some of the columns share the same name. Because they are primary keys, in these cases it is mandatory to define an alias for them, which is the one that we will insert in the output column field. Then the real name of the column must be put in the Real column field.

1.3.4 Tooltip

A tooltip is a message that appears when the cursor is positioned over a row. To define it, it is necessary to indicate the name of the column in the tooltip field.

1.3.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.


Dynamic groups

This new functionality allows the user to modify, through the simple use of drag and drop, the order of the columns that will be used to make break groups.

This allows the user to create different reports from a single object, and consequently, to reduce to one the number of reports necessary to obtain all the combinations that this new report provides itself. The functionality also allows you to hide the group columns, which will not appear in the report; and to sort data by these groups. The dynamic groups do not appear in the Column concealment option or the Sort option of the Report setting menu.

The user interaction with the dynamic groups will be done through the QBE screen or the in the Group menu (hiding and moving). This last menu also allows data sorting by dynamic group.

The break groups turn into dynamic groups when they are activated using the $GROUP injection in the report statement.


  • Define break groups in the group field as explained in the previous chapter.
  • Add $GROUP to the SQL Statement.


In the sort field of the report, it is not necessary to put $GROUP, nor make reference to any column of the group: these are set automatically. If it is defined a sort column, it will be added after the grouping columns.

It is important not to use numbers in the ORDER BY or GROUP BY clauses. Since the columns will be dynamic, the use of numbers may refer to incorrect columns.


1.3.6 Headers

The groups of headers in an object allow making 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.

Insert in the headers field the label code from the wic_jdic_lbldata, so that it will use the idiomatic descriptions of the label in the header group.

1.3.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:

  • N. No aggregate: 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.
  • Sum. 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 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.
  • AVG. Takes an arithmetic mean of the values.
  • Count. Counts the number of values in that field that aren't blank.
  • Count (Distinct). . Counts the number of different values in that field.

1.3.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.3.9 Color palette

The report outputs can colorize data cells depending on its content, generally to emphasize the importance of a cell among 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.4 The Style


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

This tab determines the style to be applied to the report. This style is defined thought the wic_jrep_form_styles:

Menu path:
Objects / Auxiliaries / Form styles
  • Identification: unique identifier for the style and brief description.
  • Options for the cells of the box:
  • Text:
  • Font:
  • Padding:
  • Border:
  • FO:

1.4.1 Expression of style activation

The use of the expression is optional. The result of its evaluation determines whether the style should be applied. The condition is written in javascript.

Examples of expressions

Evaluate the locale column to compare with the value en

'#locale' == 'en'

Evaluate the locale column to compare with the value en and also the tabname column is different from mytable

'#locale'=='es' && '#tabname'!='mytable'

1.5 The Links

Review pending

A hyperlink represents a way or resource to connect a certain report with the universe of possible queries related to any of the existing concepts in the report.

The definition of hyperlinks in objects will be what allows us to deepen into the information of a database both horizontally (drill across) as vertically (drill down).

Any hyperlink that is defined in an object must be assigned to one of the output fields of the object itself, regardless of the field in question.

Generally, the object behind the hyperlink will provide related information with the output field in which it has been defined. In principle, there is no limitation on the number of hyperlinks that can be defined for an output field.

When the system detects that an object has associated hyperlinks, when displaying the result in HTML format, they will appear reflected in the field in which they have been defined.


When the hyperlink target object contains query variables, to which you can pass some value from the source report or some value from one of the source variables, it will be convenient to define it through the variable assignment, where the equivalences between the source values and the variables of the target object will be defined.

If such equivalences are not defined, when executing the target object of the hyperlink, the system will request the values of those variables to be reported. Using these definitions prevents you from requesting them and the object is directly executed.

1.5.1 The Order

It is possible to place more than one hyperlink to a field, so with the order, we define the system the position in which we want to place this hyperlink.

This order will be in which the hyperlinks will be presented in a certain output field; hence, for each field it is a new numbering.

1.5.2 The column

Name of the column where you want to define the hyperlink. The column indicated here must correspond to one of the output fields of the object; otherwise it could not carry out the definition of the hyperlink.

1.5.3 Apply to

This field only allows two options:

  • Cell: applies the link to the indicated cell.
  • Cell (stars with): applies the link to those cells that starts with expression indicated here. This is used when the cells to apply the link are dynamic and we cannot know specifically in which they will have to be applied.

1.5.4 Enabled Expression

When a hyperlink is defined in a certain field, by default, this hyperlink will always be active and capable of being executed.

Now, the system allows the possibility of activating hyperlinks based on certain pre-established conditions.

This option is very useful, since in many occasions it will be interesting to activate a hyperlink when certain conditions exist, since in any other case its execution is not interesting, or even make no sense.

When this happens, in this field you can establish the conditions that must be met for the hyperlink to be active; that is, available for execution. The syntax of these conditions must be expressed in Javascript language.

When the hyperlink is of type alarm, in addition to activating the hyperlink, this will appear reflected on the screen in a blinking manner.


The activation conditions established must always be related to the information resulting from the object itself; that is, to the fields included in it.

To refer to a certain field, it must be done through the name of the field itself, prefixing it with the term #; in other words: #field. If it were an alphanumeric field, it must be enclosed in quotes: ''.

Compound condition

A hyperlink activation condition could be a compound condition; that is, that more than one field of the object intervened in it.

When this happens, as it is a Javascript language, the logical operators to use would be: && for the equivalent of SQL AND and || for the equivalent of OR.


Example 1

As mentioned previously, the conditions established must refer to the information of the object itself; that is, to the values of the fields included in the object.

Suppose that in a sales report broken down by months we define a hyperlink in each of the periods in order to obtain the detail of sales by clients.

In this case it could happen that in a certain period the sales were 0, therefore the execution of the hyperlink would not make sense since it would not provide any information.

For this case we could establish the following condition in the hyperlink of each of the objects: #month!=0; where month would be the name of the field that would correspond to the sales of each one of the periods.

Another example could be a report that obtained a summary of invoices issued and received from a third party. (person external to the company serving as customer and supplier at the same time).

Assuming that there is a record of invoices issued and another of invoices received, if you want to establish a detailed query of each invoice by accessing the registry of each one, it would be necessary to define two hyperlinks for the invoice number field, so that one would go to obtain the detail of the received invoices (accessing the received invoices register) and another for those issued (accessing the register of issued invoices).

In this case, in each hyperlink a condition would have to be established, so that only one of them would appear active, depending on whether the invoice is issued or received.

Assuming that the source object has a field (tipfac) that indicates if the invoice is issued or received, For the hyperlink to access the register of issued invoices, the following condition should be established: '#tipfac'=='E' and for the hyperlink to access the invoice register received: '#tipfac'=='R'.

With these conditions, when it was an invoice issued, the hyperlink to access the issued invoices would appear active and that of the received invoices deactivated. If it were a received invoice the same would happen but in reverse.

1.5.5 Modal mode

There are four different possibilities of opening links:

  • Default: opens report link on the same window.
  • New window: opens report link on a new window.
  • Modal window: opens report link on a modal window, but does not refresh data after closing it.
    A modal window creates a mode that disables the main window but keeps it visible, with the modal window as a child window in front of it. Users must interact with the modal window before they can return to the parent application. This avoids interrupting the workflow on the main window.
  • Modal and refresh: opens report link on a modal window and refreshes data after modal window closes.

1.5.6 The Object code

The object to link or target consists of an object that will provide information related to the source or with any of the concepts involved in it.

The name of the object to be linked must be an object that has the physical name of a table in the database as code.

This object can be one of the existing ones in the object definitions of the repository database that we are defining, or it could also be an object contained in the object definitions of another repository database. For the latter to be viable, it is necessary that, in the system configuration database ( wic_conf ), the operating database is assigned as repository database, all those that contain object definitions that may be involved in the hyperlink definitions.

Otherwise, the system would not be able to locate the definition of the hyperlink destination object, which would prevent its execution.

1.5.7 The Object condition

The ultimate goal of defining a hyperlink is to obtain, it directly and instantly, information related to the source object thereof; that is, with concepts contemplated in the source object.

For the purpose of the information obtained to be related to the information of the source object, it is necessary that the destination object of the hyperlink is aware of some data corresponding to the source object.

Precisely, by means of the condition that is established here, it will transmit to the target object the information that is desired to obtain with respect to the source object. If this condition is not established, executing the hyperlink would be equivalent to execute the target object of the hyperlink individually and independently.

The link condition of a hyperlink consists of an SQL statement. Compared to previous versions and to improve security, the url does not show the link condition, instead it will show a reference to the link that will be executed by the server on the object.

In fact, this link condition, that will be executed with the hyperlink, would be equivalent to executing the target object of the hyperlink independently, but informing you of a selection criterion equivalent to the established hyperlink condition.

The definition of this SQL statement will largely depend on the definition of the source and destination object of the hyperlink, with regard to input fields and variables query.

Based on this, the cases that can occur will be the following:

  • A. Both the source and destination object of the hyperlink, they only have input fields.
    This case would be the simplest. In it, it is normal for the SQL statement of the link condition to refer to one or more fields in the source report, preceded by the term # and enclosed in quotation marks '' if alphanumeric, and include all source object selection criteria using the AND $0 operator.
    In order to include the source selection criteria, it is essential that the tables in the FROM clause of the target object include the tables in the input fields of the source object, otherwise it will give SQL errors.
  • B. The source object contains input fields and variables, while the destination only contains input fields.
    Here, as in the previous case, the SQL statement will include some or some fields of the source report and as far as possible the selection criteria. What it should always include would be the variables of the source object, as long as it has not already been considered as a field.
    If the variables are not included, the information resulting from the hyperlink may not be consistent with the source information.
  • C. If the source and destination object contain input fields and query variables.
    First of all, the first thing to achieve is to be able to transfer to the variables of the target object the necessary and coherent value for the hyperlink, that in some cases will be a field of the own report origin and in others will have to be some of the variables of the object origin.
    This is accomplished through the variable assignment associated with a hyperlink. In case of not being able to transfer some data to any of the variables, it would not be any problem, because when executing the hyperlink, the system would request it automatically.
  • D. There are only input fields in the source object and there are input fields and variables in the destination.
    As in the previous case, the first thing to do is define the variable assignments, so that as far as possible none are left unreported.
    Subsequently, it will be possible to define the SQL statement so that those particularities that the variables do not cover are contemplated. If it were not necessary to define it, it would be left blank or reported (1 = 1) in case the SQL statement of the target object contained the operator AND $0 .
  • E. Both the source object and the destination have only query variables.
    In this case, the only thing that can be done is to define variable assignments, and those that could not be reported will be requested by the system in the execution of the hyperlink.
    Nothing will be reported as an SQL statement or (1 = 1) if the target object is contained in your SQL statement the AND $ 0 operator.


1.5.8 Variable

It is very easy to define the link to variables of a target object. It will only be necessary to define two fields: Variable name and Value.

The field name corresponds to the name of the variable in the target object, without further symbols (neither #, nor $, nor anything). The value field can be a UEL expression that will give us the value of the variable based on the data in the corresponding row. Then, you can put a UEL expression to refer to fields in the ${colname} report, or the syntax to refer to variables $VARNAME.


1.6 The Page links

The page links allows easily changing the view between various reports. The developer only has to define the linked reports in the Page links section.

In addition, the developer can determine the SQL conditions of the reports and the variables.


  • Define each report as an independent object.
  • Access the Link page of one of them.
  • Object code*: add all reports to be linked (included this one).
  • Send query: check this indicator to propagate the parameters of a query from one report to another. This way, the target object will show the result with the same query condition that used in the first report.
  • Condition: optionally, define a SQL condition to execute each report.
  • Variable: you can access the definition of input variables, which are propagated from the main report to the linked report.

In this example, the user can toggle between the Annual report, Monthly report and Daily report by just selecting one of them in the drop-down menu.


1.7 The PDF Configuration

It is possible to generate a PDF of the report with a different look than the same report on screen. This allows the developer to bring a professional and modern style to the reports generated in PDF, without losing efficiency during on-screen display.

Access the PFD configuration throuth the PDF CONFIG tab. Here the configuration code must contain a Javascript function called config, which receives the parameters rs and config.


Javascript Function

function config(rs, config) {

	// configuration parameters


The printing parameters for this example are:

Name Description Placeholder
setTitle Text to be shown in title section "FINANCIAL STATEMENTS"
setFootTex Text to be shown in footer section "Acme Inc"
setGroupCompression Forces groups to be rendered on a single line instead of as part of the row they belongs true
setGroupHeadingRepeat Repeates field headings in each group False
setGroupComprerssionIndentWidth Width for the left indentation of compressed data 0.5
setPrintNewLineAfterGroup Adds an empty line after groups true
setPrintNewLineAfterTotal Adds an empty line after totals true
setPrintCompressedGroupColumnsInNewLine Determines if compressed groups are placed in a separated line true
setGroupColor Define group color (groupId, backgroundColor, foregoundColor) 1, 0x192e54, 0xFFFFFF
setTableHeadBackgroundColor Header background and foreground color (backgroundColor, foregroundColor) 0x192e54, 0xFFFFFF

For further infomation, see Axional JS Script Library/ResulSet/Report.

2 Additional information

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

Review pending