In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   Cloud ERP  |   Home  |   qad.com



  •     QAD Glossary

  • Reporting Framework Changes
    The following summarizes Reporting Framework changes for this version of the QAD .NET UI.
    Additional Bar Code Types (Including 2D)
    Previously, the only bar code field supported for reports was limited to handling only nine types of 1D bar codes and no 2D bar codes. Furthermore, it had little support for parameters for these types. In this release, two new bar code fields have been added to the Report Resource Designer program:
    Linear Bar Code field
    Supports 34 types of 1D bar codes
    Exposes extensive sets of parameters to fully control the bar code settings
    2D Barcode field
    Supports 3 popular types of 2D bar codes (DataMatrix, PDF-417, and QR Code)
    Exposes extensive sets of parameters to fully control the bar code settings
    Note: The original Bar Code field is still supported for back compatibility.
    Dynamic Layout Selection by Data Source
    You can now have a report dynamically determine which page layout to use. Optionally, the user can choose the layout.
    If a report has more than one page layout design created for it (each giving different visualizations of the same data), you can have the data source program logic select a particular layout at run-time. For example, if a report needed to output one type of form for data where a customer is in Germany and another output form if the customer is in Brazil, then the data source logic could choose the proper form layout automatically.
    In the normal case where the data source program does not attempt to control the layout selection, the list of available layouts (displayed when the user clicks the Layouts tool button in the report viewer) is still available for users to choose before running the report. However, when the data source program asserts control over the layout, the Layouts tool button is disabled to prevent users from overriding the layout selection. It is also possible for the data source logic to allow the user to choose any desired subset of the layouts, if a manual override is deemed allowable, by displaying those options as a search field with a list of allowed layouts.
    Specifying Dynamically Selected Layouts
    1
    Create multiple layouts in the Report Resource Designer, all for the same report code (RRO code).
    2
    To have your data source program choose the layout, include a table in your business data set called DataSourceReportSettings, with a char field called sys_default_report_definition.
    3
    Put the choice of layout name into this field, and the QAD .NET UI client uses this for rendering. The layout name is the value entered in the Report Definition Name field when saving the definition from the Report Resource Designer (stored in rptresd_det.rptresd_name after being saved).
    4
    Specify metadata for the DataSourceReportSettings.sys_default_report_definition field. This causes the report viewer program to disable the Layouts tool button (which normally would be active and confusing due to the existence of multiple layouts).
    You have a choice of whether to make this field searchable. If you want to give the user no control over the layout, make this field non-searchable. If you want to allow the user some control over which layout to use, make it searchable. You can provide a value list for this field in the metadata, which controls the list of layouts that the user can choose from in the search panel. If you make this searchable, you should get the user-entered value from the filter conditions and use it when populating the DataSourceReportSettings.sys_default_report_definition field in the code described in step 2.
    Note: When running this report from the menu, the above logic applies. However, when running the report from Report Resource Designer | Preview, the layout used is always the layout that is currently in memory in the designer; the data source’s choice is always ignored. This is to keep true to the designer’s underlying philosophy that the preview should always run what is in there, which might not even have been saved to the database yet. Therefore, to test the actual data source logic, it is necessary to run from the menu (perhaps requiring a temporary test menu item if the real menu item does not exist in the test system yet).
    Dynamic Currency Formats
    Currency Rounding functions are now available in the Report Resource Designer as part of the QAD_NumberUtil script object. These new VBScript functions provide rounding based on the data maintained by the Rounding Method menu items in the system. These functions can be invoked from within the Report Resource Designer program’s VBScript hook points to provide standard rounding methods for any desired fields.
    As described in the Reporting Framework User Guide’s section Using .NET Script Objects , .NET script objects make it possible to expand the functionality available in the report designer to go beyond VBScript logic. In this release, the following script objects have been included to support dynamic currency formats.
    QAD_NumberUtil.RoundNumber(currency, number)
    Rounds a number based on the given currency’s rounding method (rounding unit and threshold).

    QAD_NumberUtil.RoundNumber(currency, number) Parameters
     
    Name
    Input/Output
    Data Type
    Description
    currency
    Input
    String
    Currency upon which to base the rounding method.
    number
    Input
    Object
    Number to be rounded.
     
    Return Value
    Object
    Returns the rounded amount.
    QAD_NumberUtil.RoundNumberBaseCurrency(number)
    Rounds a number based on the base currency’s rounding method.

    QAD_NumberUtil.RoundNumberBaseCurrency(number) Parameters
     
    Name
    Input/Output
    Data Type
    Description
    number
    Input
    Object
    Number to be rounded.
     
    Return Value
    Object
    Returns the rounded amount.
    QAD_NumberUtil.ConvertFormat(currency, format, useZeros)
    Converts the given number format string to one which properly matches the rounding method of the given currency. The useZeros variable controls whether additional decimal places are formatted with zeros (.000) or pound signs (.###).

    QAD_NumberUtil.ConvertFormat(currency, format, useZeros) Parameters
     
    Name
    Input/Output
    Data Type
    Description
    currency
    Input
    String
    Currency upon which to base the conversion.
    format
    Input
    String
    Existing numeric field format.
    useZeros
    Input
    Boolean
    Specifies whether additional places are formatted with zeros or pound signs.
     
    Return Value
    Object
    Returns a format that properly matches the rounding method of the currency.
    QAD_NumberUtil.ConvertFormatBaseCurrency(format, useZeros)
    Converts the given number format string to one that properly matches the rounding method of the base currency.

    QAD_NumberUtil.ConvertFormatBaseCurrency(currency, format, useZeros) Parameters
     
    Name
    Input/Output
    Data Type
    Description
    format
    Input
    String
    Existing numeric field format.
    useZeros
    Input
    Boolean
    Specifies whether additional places are formatted with zeros or pound signs.
     
    Return Value
    Object
    Returns a format that properly matches the rounding method of the currency.
    QAD_NumberUtil.GetThreshold(currency)
    Gets the rounding method’s threshold for the given currency.

    QAD_NumberUtil.GetThreshold(currency) Parameters
     
    Name
    Input/Output
    Data Type
    Description
    currency
    Input
    String
    Specifies the currency.
     
    Return Value
    Object
    Returns the rounding method’s threshold for the specified currency.
    QAD_NumberUtil.GetThresholdBaseCurrency()
    Gets the rounding method’s threshold for the base currency.

    QAD_NumberUtil.GetThresholdBaseCurrency() Parameters
     
    Name
    Input/Output
    Data Type
    Description
     
    Return Value
    Object
    Returns the rounding method’s threshold for the base currency.
    QAD_NumberUtil.GetRoundingUnit(currency)
    Gets the rounding method’s unit for the given currency.

    QAD_NumberUtil.GetRoundingUnit(currency) Parameters
     
    Name
    Input/Output
    Data Type
    Description
    currency
    Input
    String
    Specifies the currency.
     
    Return Value
    Object
    Returns the rounding method’s unit for the specified currency.
    QAD_NumberUtil.GetRoundingUnitBaseCurrency()
    Gets the rounding method’s unit for the base currency.

    QAD_NumberUtil.GetRoundingUnitBaseCurrency() Parameters
     
    Name
    Input/Output
    Data Type
    Description
     
    Return Value
    Object
    Returns the rounding method’s unit for the base currency.
    New Immediate Service Report Server Mode
    The original report server operated in scheduled batch mode: at scheduled times the server process would start and process the desired batch of reports (for example, every night at midnight, or at end of month). A new, additional report server mode is now available: a continuously running process that runs reports as soon as they are scheduled with a special batch ID (a virtual batch named QADSVC, representing the QAD service).
    This new service is called the QAD Reporting Framework Service. The service is especially useful to support cases where the application that needs to run a report is not running in a QAD .NET UI process (for example, a Progress program running on a Linux box, or an application running on a mobile device). This new service is also essential to the infrastructure of the new report bursting capability (see Report Bursting with Dynamic Output Routing).
    The new immediate service mode runs as a Windows Service on one or more Windows computers. Its architecture is similar to that of the original batch server mode: multiple server processes can be run on any number of machines for scalability and failover.
    Note: Reports can be scheduled to the virtual QADSVC batch either from a program (using the Scheduled Report .NET or Progress APIs) or from the Report Viewer screen in the QAD .NET UI. By default, the Report Viewer screen does not list the QADSVC batch as one of the possible batch IDs; if this is desired, then define the QADSVC using Batch ID Maintenance.
    Support for Progress Character Mode Programs to Launch Reports
    Previously, there were limitations in the ability for a Progress program to be able to automatically launch a QAD Reporting Framework report. The fundamental issue was that the report must be rendered in a QAD .NET UI process on a Windows machine, and Progress programs are not run in this environment. The Scheduled Report API (introduced in the QAD 2010.1 EE release) first opened the door to this possibility, allowing the Progress program to call the API to allow the report to be scheduled to run on a (Windows) report server in batch. This approach still had major limitations: a time delay between the time at which the report is scheduled and when it later gets run on the server, and also a limited ability for the user of the Progress program to have access to the report output.
    The new immediate report server mode (see “New Immediate Service Report Server Mode”) provides the basis for a solution of the time delay: by scheduling the report to be run in the virtual immediate batch ID, the report is run typically within a matter of seconds from the time it was scheduled.
    Furthermore, a new mechanism was introduced into the QAD .NET UI such that if the Progress program is initiated from a .NET UI session, it can now invoke the launching of a new .NET UI tab containing a report viewer that displays the report output to the user. The viewer runs in a mode where it polls the report server for the output of the scheduled report. Once the report has completed on the server, the viewer then automatically displays it for the user.
    Note: If the Progress program is not launched from within the QAD .NET UI (for example, on a terminal), then the user can still launch the report but cannot view the output. However, the report output can still be saved on the web server and/or sent to printer.
    Note: This capability relies on the Scheduled Report Progress API, which requires a component called the Service Interface Layer. The Service Interface Layer is not included with QAD Standard Edition but can be acquired by contacting QAD Services.
    Configurable Output File Naming and Location
    Reports scheduled to be run on a report server previously had no flexibility regarding the file name and folder path of the output file stored on the server. This not only restricted the possibilities for organizing report output, but also reduced flexibility of implementing security authorization on the web repository in which these output files are stored.
    In this release, it is now possible for administrators to configure flexible, dynamic routing rules to control report output file names and path. The rules can be set up with defaults to handle most general types of reports, as well as specific alternatives based on the report type and layout. For example, a certain type of report containing sensitive data could be funneled to a special folder that has web access disallowed.
    In addition to configuring such report routing rules on a system-wide basis, administrators can also override the file name and path rules for any specific scheduling of a report. For example, for a certain report that gets run every month in batch, a special naming convention and folder path can be assigned for that per-month batch run of that report, overriding any general rules that may have been configured for the same report type.
    Report Bursting with Dynamic Output Routing
    This release contains new infrastructure to facilitate the mass-running and distribution of reports: report bursting. A report burst is a special way that a report can be run that involves the following aspects:
    A report burst can be configured to automatically split a large report into many smaller reports, relieving end users of the burden of manually running numerous reports. Any field in the top-level table of the report’s data set can be chosen as the split field (for example, a report could be split to output one report per customer ID, or one report per item number).
    A report burst can be configured to dynamically route each of the split output reports to different e-mail, file, and printer destinations. The logic can be based on data values; for example, the customer ID in each of the output reports could be mapped to an e-mail address for that customer to send the report t..
    The report bursting mechanism is a general capability that can be used with any report developed using the QAD Reporting Framework, but not for any other type of report. In addition to dynamic setting of output destination, the infrastructure allows for most of the report settings to be set dynamically based on the data; this includes such settings as language for translated labels, date and number formats for internationalization, output file type (PDF, Excel, RTF, and so on), and layout type (for example, different form page layouts of the same data).
    Report bursts internally schedule each of the split output reports to be asynchronously (but immediately) run by a report server using the QAD Reporting Framework Service (see New Immediate Service Report Server Mode). This leverages the many benefits of the report server architecture such as robustness, scalability, and failover.
    Because there are no Reporting Framework reports included with the QAD 2013 SE release there is no out-of-the-box scenario where this feature can be used. You can, however, create your own reports and use them in bursting scenarios using the following mechanisms:
    The Scheduled Report API can be used to write programs to schedule report bursts to be run on the server at desired times. Special burst settings are used to configure the burst run. These programs can be written in the Progress or .NET languages. They could be either simple script-like utility programs for administrators to run, or could be fronted by user-interface logic to expose the functionality to end users if desired.
    Note: The Scheduled Report Progress API requires a component called the Service Interface Layer. The Service Interface Layer is not included with QAD Standard Edition but can be acquired by contacting QAD Services.
    Administrators can use a new Burst Settings tool button from the report viewer program to run an immediate ad-hoc burst of that report, and also to choose settings and then schedule the report to be run as a burst in batch on a report server.
    The logic that controls the dynamic routing settings is completely configurable. However, this release contains no default routing logic. It is therefore necessary to first codify the desired rules using the Progress programming language in a special dynamic-routing program that is invoked during report bursts. Future QAD releases may contain out-of-the-box sets of configurable rules for dynamic settings.
    If assistance is desired with creating report burst programs or setting up the desired routing rules, please consult QAD Services.
    Report API Enhancements
    Application Programming Interfaces (APIs) allow one program to invoke functionality in another. Before this release, the only API for the QAD Reporting Framework was the Scheduled Report API, which allows programs to schedule reports to be run asynchronously on a report server. This API is implemented as a Progress program that gets called on an application server and is callable from Progress and .NET programs.
    Note: The Scheduled Report Progress API requires a component called the Service Interface Layer. The Service Interface Layer is not included with QAD Standard Edition but can be acquired by contacting QAD Services. The .NET APIs do not require this and can be used in Standard Edition installations.
    This release enhances the reporting framework APIs in several ways:
    A native .NET version of the Scheduled Report API has been added. This allows .NET applications to invoke the Scheduled Report API in a more simple fashion: a simple direct .NET object can be constructed and called to schedule a report. This encapsulates the inner details of the remote proxy networking, hiding it from the application programmer.
    A .NET Run Report API has been created. This allows any .NET program running under QAD .NET UI to be able to invoke a report to be run synchronously in the same process (instead of asynchronously on a server).
    A new capability has been added to the Scheduled Report API (both .NET and original Progress versions): the ability to pass the report data set into the request, instead of having the report run a data query at run-time. This is useful in scenarios where the data has already been queried and just needs to be passed to the report for rendering. For example, an application can use this if it needs to rerun a report with the exact same data as the previous run.
    Note: This data input option is also available on the synchronous .NET Run Report API.
    These API enhancements greatly increase the options and possibilities for leveraging the QAD Reporting Framework in custom programs and system automation.
    Scheduled Report Default Printer
    You can now choose the default printer for the Schedule Report screen from Tools | Options. The list of printers displayed in the Options window is the same as the list in the Schedule Report screen—the list specified in the client-session.xml file. If no default is chosen, the printer field is initially blank when you schedule a report; however, you can still manually choose a printer.
    Administrators can also specify a default printer that applies for all users. This can be done by setting default="true" for one of the printers in the client-session.xml file, as shown in the example below:
    <Printer default="true">
    <UNCPath>\\server_name\printer_name</UNCPath>
    <Description>My Default Printer</Description>
    </Printer>
    Note: If a system-wide default printer is specified, users still are able to override this with their own choice of default printer (including no default) by using Tools | Options.