The Balance daemon operates in a similar manner to the History daemon. It builds the supplier and customer balance and movement data and history files.

The Balance daemon updates the supplier and customer history tables each time a movement is created on an invoice.

As with the History daemon, you can set a parameter in the Balance configuration file to periodically attempt to restart daemons that have stopped unexpectedly. For more information, see Restarting Daemons Automatically.

The Batch daemon is used to update exchange rates from third-party exchange rate providers on a daily basis. The providers are integrated with the system and at a specific time each day, the exchange rate sets from each provider are processed and updated.

Batch Daemon Configure (36.14.16.19.1) enables you to configure the daemon. For example, you can specify the number of records for the daemon to process in one batch. The Batch Daemon Monitor (36.14.16.19.3) displays the current daemon status, whether there are records queued for processing, and the results of any processing. For more information on exchange rate provider integration, see QAD Financials User Guide.

The Budget daemon allocates postings and commitments to the appropriate budget topics. All postings are processed, including those in the transient and management layers.

Budgets are composed of budget topics, and each topic is linked to a level in the chart of accounts (COA) and to specific values for that COA level. The Budget daemon inspects all budget definition tables, and updates the actuals for the relevant budget topics.

The Budget daemon should be active when allocations are executed because the allocation functionality uses the same tables. The Budget daemon ensures that the most current values are available for an allocation run. For more information on allocations, see QAD Financials User Guide.

The Cross-Company daemon processes automatic cross-company postings that cannot be performed manually in the UI. The daemon is used to perform calculations and postings to spread the transaction load on the CPU.

The Cross-Company daemon handles transactions related to invoices and banking entries. These can occur in the following activities:

The Cross-Company daemon processes transactions in the official layer only, and completes the linking fields in both the source and target posting line.

Posting occurs in the source entity using the Cross-Company Control account for the target entity. The system creates a request for the Cross-Company daemon, and posting and request creation occur within a single transaction. The daemon processes the request and creates the posting and the movement in the sub-ledger of the target entity.

The Cube daemon builds data for report cubes used in Financial Report Writer, and is fed by the History daemon. Therefore, if the History daemon stops, the Cube daemon does not receive any queue requests.

You must stop the Cube daemon before you can rebuild report cubes in Financial Report Writer. You do not need to stop the History daemon; the Cube daemon catches up with missed updates when it restarts.

If the system finds errors during the update process (for example, missing exchange rates or missing COA cross references), these are logged in the Cube Build Log and you can view the errors using Cube Build Log Browse.

When the system finds an error in cube data, the cube is assigned the status Needs Rebuild and the daemon stops further updates for that cube. You must determine the root cause of the error and rebuild the cube using Cube Generation so that the cube status becomes Operational again.

For more information on Financial Report Writer, see QAD Financials User Guide.

The Event Daemon publishes Financials business events, such as record creation events, as XML messages. The Event daemon publishes the messages in its queue to a preconfigured destination, which can be a directory on a server or a QXtend server. Event publishing lets you export data updates to other Financials instances, without the need to extract the data from the database. See Event Daemon.

The History daemon populates the database with condensed GL transaction data, and updates GL and SAF balances for each period. Detailed transaction data is accumulated in tables to increase performance in, for example, drill downs and reporting. All GL postings, including those in the transient and management layers, are processed.

The History daemon generates historical data grouped by a number of criteria, such as the posting period, the account, sub-account, project, cost center, period mark, daybook, and the entity used in the transactions.

The data fields in the history tables include the period movements, balances, and year-to-date values and are provided in the base, transaction, and management currencies. In addition, the quantity field is included.

You can use the History daemon to perform tasks outside of its normal actions by customizing the empty method BHistoryDaemonProcessor:PerformWorkItemSpecific().

First, create a request for the daemon with SPECIFIC-ACTION as the request reference. Then, when the daemon processes this request, it skips the normal actions and executes BHistoryDaemonProcessor:PerformWorkItemSpecific().

Sometimes, a daemon that should be running stops unexpectedly. This can cause a backlog of requests that affects other daemons, particularly the History and Balance daemons.

You can configure the History and Balance daemons to periodically attempt to restart stopped daemons. Each daemon has a configuration file of the form <DaemonName>.config in the PROPATH of the Financials appserver. Add the following property to the relevant configuration file:

You can specify the interval at which an attempt to restart the daemons is made by including the following line in the relevant configuration file:

The default value for this property is 1200 seconds, and the minimum value that you can set this property to is 60 seconds; lower values result in the default value being applied.

The Replication daemon makes domain shared set data available to the operational functions, and replicates the data to the appropriate operational domain.

During implementation of the system and setup of the domains, you can continue to modify the data associated with a domain for as long as you require and then confirm the setup when you are satisfied that it meets your business requirements. Until the setup of a domain is confirmed, it is not available to your operational functions.

The availability of domain data to the operational functions is controlled by the Setup Complete field in the Domain function. When you select the Setup Complete field, the Replication daemon creates request queue records for each shared set. After the data has been reproduced, you cannot change the shared sets and base currency of the domain. In addition, you cannot link any of the entities linked to the domain to a different domain; the relationship is now permanent.

For more information on domains, see QAD Financials User Guide.

The data made available to the operational functions includes daybooks; GL accounts, sub-accounts, and cost centers; suppliers, customers, and exchange rates.

The system creates a single Replication daemon request for a maximum of 90 records. Each request contains:

If any of records in a replication request fails to be replicated, all other records in the request fail also. Failed replication records remain in the daemon queue and have the status Processed-Error.

The user ID specified for the Replication Daemon login must have access to all domains and entities in the system.

Financial reports developed using Crystal Reports can be printed to screen or to a printer directly, or can be batch printed from a report queue. You can schedule batch reports, output them to files, or e-mail them to addresses or roles. The Report daemon processes these batch reporting requests. See Report Daemon.

The Scan Daemon lets you configure the system to monitor a directory for documents to be attached to new records in the QAD application database. You configure the daemon by instructing it what to do when it finds a document.

For example, you can set up the daemon to monitor a directory for incoming supplier invoices. The Scan daemon processes documents located in entity-specific scan directories. The daemon creates a draft instance of the supplier invoice, attaches the scanned document, and sends the draft instance to the inbox of any user with access to the relevant domain and entity and a role with access to the Supplier Invoice Create activity. The original scanned documents are renamed in the scan directory to prevent a document from being processed multiple times.

Supplier invoice is the most common type of document to scan, but you can also use this feature to scan documents related to any components that support the save-as-draft feature. For example, you could scan new customer profiles and send them to the inbox of those responsible for creating customer records.

You can attach documents of any file type, but you should ensure that your users have the correct applications to open the file. Typical files to attach are .pdf, .doc, .txt, and .jpg.

The Configure activity for the Scan daemon includes an additional grid where you specify the scan directory associated with each entity. See Configuring the Scan Daemon for details.

You can configure a user time-out setting defined in Security Control (36.3.24). This feature lets system administrators automatically terminate inactive user sessions, therefore reducing system load and improving performance for active users. Time out is defined as a number of minutes a logged in user can be inactive.

For more information on security settings, see QAD Security and Controls User Guide.

If you want to use the time-out feature, in addition to the setting in Security Control, you must ensure that the Time Out daemon is also running. This daemon ensures that the system is aware of component-based activities that have being started and resets the time-out period whenever a user initiates an activity.

If the daemon is not running, the system is only aware of the execution of standard programs and may terminate users running component activities.

The XML daemon processes external data in XML format, by parsing XML document headers and calling the relevant software component to process the document. See XML Daemon.