Glossary of Terms

Database Terms

Class

Use classes to group entities in the database, such as suppliers, customers, branches, transactions. Each entity is called an object, against which you will record information about it's common characteristics. For example, each supplier has the following common attributes:

name
address
telephone numbers
contact person

Each supplier object has references to other classes, such as branches and transactions.

Each class contains instances, if each instance represents something that belongs to the class.

Subclass

A subclass is a group of objects within a class that has a unique sets of common characteristics. For example, Transactions is a class which has these subclasses to represent different types of transactions: Invoices, Payments, and Receipts. Subclasses inherit the common characteristics for the class they belong to.

If you are accessing the transaction class, but only want to report on a specific type of transaction, such as AR Invoices, you must limit your database view to a subclass so you can see properties that are specific to that type of transaction.

Instance

Instances are held within classes, and equate to the concept of records in a file. For example, in the APInvoice class, there is multiple instances of invoices.

Attribute

Attributes represent detailed information that is held for a class. For example, name, address, and telephone number are attributes associated with the Customer class.

Reference

A reference is a link between classes that specifies an instance within another class. It is identified by an Object ID (OID), which is a specific reference containing the class number, and the instance in the Class. The format for an OID is <integer>.<integer>, for example, 1234.564.

You will not see OIDs when you use the Report Writer. References can be identified because they are always pre-fixed with a my and they are attached to a class. For example, in the Company class, references include myCurrency, myCountryCode, and the like.

In this example, the myCurrency reference enables you to access the currency code that is specifically assigned to any supplier in the Supplier class. A reference is always a one-to-one relationship — for example, only one currency code can be assigned to each supplier. Where multiple things can be for a single supplier, a collection is used.

Collection

A collection is a group of references. For example, in the Supplier class there is a collection called allAPInvoices which contains information about all the invoices that have been processed for a supplier.

A collection is always prefixed with all — for example, allChildrenAccounts, allOutstandingPOs, and the like. A collection is used if there is a one-to-many relationship between classes. For example, one supplier can have multiple invoices for it.

Method

Methods are used throughout Greentree Desktop to retrieve database values or return collections when the value/collection is not actually stored in the database. Methods are pre-defined by Greentree Desktop. developers, and are like mini forms that can receive input data and subsequently return the result.

It is more efficient to determine a value based on real-time inputs, than it is to actually maintain that value in the database. For example, the overdue amount for a customer is not a fixed value — it changes as invoices are entered for the customer.

In this situation, a method is used to calculate the overdue amount for the customer as it is required. Several methods have been developed specifically for use in the Report Writer. Use them to access information you could not find any other way.

Trees

Trees are used to assist with grouping, analysing and reporting on masterfiles, such as GL Accounts, Customers, Inventory Items, and the like. You can use trees as an advanced filtering tool, which offers almost limitless potential in terms of managing the output of reports.

Report Writer Terms

Parameters

Parameters are used to add output filtering options to reports. When you run the report, you can enter specific parameters to filter database information. Parameters may be specific, or based on a range.

For example, you can add a specific true/false parameter to exclude zero values from the report, or a range to represent Start date and End date as appropriate to the report. Parameters can be alphanumeric (for example, to represent a customer, supplier or inventory code range), decimal, date, or true/false types. Parameters are set at a report level and are not specific to any section.

You must set up a query or queries to complement report parameters, so Greentree Desktop knows the rules by which it should filter information using the value of parameters. For example, if you create Customer Code From and Customer Code To parameters for a report, you must also create a query that tells Greentree Desktop you only want to include customers with a code greater than or equal to the Customer Code From and less than or equal to the Customer Code To parameters.

Calculations

You can set up user-defined calculations to add as fields to specific sections, depending on your report requirements. For example, to output a customer's Overdue4 (four periods overdue) value as a % of their total outstanding balance, you can set up a calculation to do this. Calculations determine values that are not actually stored in the database.

Queries

Queries can be defined for specific sections to limit the report output based on specific criteria. This feature differs from using parameters in that queries are attached internally to the report section and are not specified by the user when the report runs. In addition, a single query can have multiple and/or criteria for it.

When you define a query, you specify the selection criteria you want use with each database property you add to the query. For example, you can specify that you only want Greentree Desktop to find items whose totalHoldAmount attribute value is greater than zero if you are designing a report to view customer held balances).

You can also use pre-defined parameters within queries, most commonly if parameters have been set up to represent a range and you want the query to recognise the value of these parameters when filtering the report output.

Profiles

Profiles can be used to set up to multiple sort orders for a report, and/or multiple query options. When sort orders and queries are defined for a report, they are defined at a profile level, and is attached to the profile that is selected as the report is being edited.

When you run the report, the user can select a profile if more than one is defined. When the report runs, the sorting and query options attached to the selected profile takes effect.

Repeating Section

A repeating section is one that contains a database collection. This contains the main body of information that prints on the report. Repeating sections can be imbedded within repeating sections, so that a hierarchy structure can be established to control the order in which information is output to the report.

Report Header

This section of the report is pre-defined as a static section. Any data included in this section prints only once at the top of the first page of the report. It is used for the report name, printed date, and the like.

Page Header

This is a pre-defined section that will repeat at the top of each page (following the report header, if one exists). It will most commonly be used for column headings.

Report Body

This section represents the main body of the report, which contains the workings of the report. It will most commonly consist of collections/repeating sections, and have queries, sort orders and calculations for it. The report body is multi-layered if more than one collection is being referenced.

Page Footer

This is a pre-defined section that displays at the foot of each page. It will most commonly be used for page numbering.

Report Footer

This section of the report is pre-defined as a static section. Any data included in this section prints only once at the end of the last page of the report (following the page footer if one exists).