SysAdmin AG v2015EE

QAD Enterprise Applications
Enterprise Edition
Administration Guide
QAD System Administration
Introduction to System Administration

Domain Constants
System Interface
Printers
Batch Processing and Daemons
System Control
CIM Interface
Database Management
Reports and Utilities
Customizing Business Logic
Customizing Specific Business Components
UI Customization
Installing Electronic Bank File Formats
70-3184-2015EE
QAD Enterprise Applications 2015
Enterprise Edition
March 2015
This document contains proprietary information that is protected by copyright and other intellectual
property laws. No part of this document may be reproduced, translated, or modified without the
prior written consent of QAD Inc. The information contained in this document is subject to change
without notice.
QAD Inc. provides this material as is and makes no warranty of any kind, expressed or implied,
including, but not limited to, the implied warranties of merchantability and fitness for a particular
purpose. QAD Inc. shall not be liable for errors contained herein or for incidental or consequential
damages (including lost profits) in connection with the furnishing, performance, or use of this
material whether based on warranty, contract, or other legal theory.
QAD and MFG/PRO are registered trademarks of QAD Inc. The QAD logo is a trademark of QAD
Inc.
Designations used by other companies to distinguish their products are often claimed as
trademarks. In this document, the product names appear in initial capital or all capital letters.
Contact the appropriate companies for more information regarding trademarks and registration.
Copyright 2015 by QAD Inc.
SysAdmin_AG_v2015.pdf/ymg/ofs
QAD Inc.
100 Innovation Place
Santa Barbara, California 93108
Phone (805) 566-6000
http://www.qad.com
Contents
System Administration
Change Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1 Introduction to System Administration . . . . . . . . . . . . . . .1

System Administration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Types of Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Domain Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
System Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Batch Processing and Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
System Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
CIM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Reports and Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Customizing Component-Based Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2 Domain Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Overview of Domain Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Maintaining Holiday and Shop Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Calendar Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Holiday Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Using Generalized Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Field Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Generalized Codes Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Using Reason Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Managing Number Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
NRM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Sequence Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
NRM Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Setting Up Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Setting Sequence Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Defining Sequences for Sales Orders . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Viewing Sequence Number History . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Deleting and Archiving Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tracking Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
iv QAD System Administration User Guide
Change Tracking Implementation Overview . . . . . . . . . . . . . . . . . . . . . 27

Defining Change Tracking Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 28
Activating Change Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Specifying Fields to Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 3 System Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Overview of User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Using Multiple Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Multiple Languages and Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting Up Multiple Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Language Detail Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Report Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Customizing Menu Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Executing Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Menu Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Menus and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Menu System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Setting Up Menu Substitutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Defining Program Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Viewing Business Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Modifying Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Creating and Managing Browses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Maintaining Drill Downs and Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 48
Creating Access to Other Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Managing Stored Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Defining Browse URL Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating Browses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Creating Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Defining User Menu and Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
User Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Executing Programs in Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
User Function Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Using Field and Program Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Adding User Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Printing Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Setting User Telnet Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Configuring Telnet Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Define the Login Sequence Script Lines . . . . . . . . . . . . . . . . . . . . . . . . 68
Configure Telnet Connection Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Verify the Login Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Modifying Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Building an E-Mail System Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Setting Up E-Mail System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Contents v
Using Text E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

E-Mailing Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
E-Mail Definition Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
E-Mail Command Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Customizing Appearance of HTML E-Mail . . . . . . . . . . . . . . . . . . . . . 74
Configuring E-Mail Notification for Components . . . . . . . . . . . . . . . . 74
Using Advanced Reporting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
QAD-Provided Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Custom Reports and Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Monitoring User Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Chapter 4 Printers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Introduction to Printer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Defining Printer Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Setting Up Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Defining a Printer for Use with QAD .NET UI . . . . . . . . . . . . . . . . . . . 84
Setting Default Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Defining Document Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Chapter 5 Batch Processing and Daemons . . . . . . . . . . . . . . . . . . .87

Introduction to Batch Processes and Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Batch Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Define Batch IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Review Batch Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Process Batch Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Invoke Batch Processing from CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Overview of Daemon Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Daemon User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Types of Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Daemon Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Daemon Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Event Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Report Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
XML Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Queue View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Queue Correct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Queue Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Running Daemons on the Command Line . . . . . . . . . . . . . . . . . . . . . . 120
Integrating XML Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Planning the Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Identifying Business Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
vi QAD System Administration User Guide
Business Component Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Tables and Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Component Schema and Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . 125
Creating the XML File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Integrating Multiple Records in an XML Document . . . . . . . . . . . . . . 130
Processing the XML File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Bulk Data Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapter 6 System Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

System Control Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Database Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Maintain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Synchronize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
View System Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
System Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Set Debug Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
View CT Logfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
server.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Configuring System and User Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
System Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
User Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Making UI Caching Configurable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configuring Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Managing Draft Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Chapter 7 CIM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

Introduction to CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Using the CIM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
CIM Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Input File Formatting Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Input Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Determining Data for the Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
CIM Data Input File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Creating a CIM Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Deleting Records through CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Creating Input Files to Delete Records . . . . . . . . . . . . . . . . . . . . . . . . 163
Example of CIM Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Running Multiple CIM Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Killing CIM Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Contents vii
Chapter 8 Database Management . . . . . . . . . . . . . . . . . . . . . . . . . .165

Managing Database Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Determining Disk Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Freeing Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Dumping and Loading Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Dump/Load Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Deleting and Archiving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Audit Detail Delete/Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Restoring Archive Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Integrity Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Registering Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Licensing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
License Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
License Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Managing Database Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Initializing Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Maintaining Sequences Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Maintaining Sequences Using CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Maintaining Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Maintaining Sequences in Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Component Record Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Setting Up Multiple Time Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Multiple Time Zones Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Multiple Time Zone Load Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Setting a Default Time Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Domain Time Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
UTC and Transactions Outside Domains . . . . . . . . . . . . . . . . . . . . . . 190
Chapter 9 Reports and Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . .193

Generating Auditing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Other Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Using System Cross-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Table, Field, and Menu Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Using Program Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Updating the Cross-Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Setting Up Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Progress AppServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Defining the AppServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Example: Using an AppServer to Run MRP . . . . . . . . . . . . . . . . . . . . 200
Using Operating System Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Using Delete/Archive Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
viii QAD System Administration User Guide
Audit Detail Delete/Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

GL Transaction Delete/Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Statutory-Currency Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Choosing the Best Time to Run the Utility . . . . . . . . . . . . . . . . . . . . . 205
Running the Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Command Line Application Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Chapter 10 Customizing Business Logic . . . . . . . . . . . . . . . . . . . . .211

Introduction to Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Customization Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Supporting Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Elements of Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Accessing Generalized Codes and Master Comments . . . . . . . . . . . . . . . . . . . 216
Generalized Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Master Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Database Access and Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Identifying Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Sample Code for Non-Intrusive Customization . . . . . . . . . . . . . . . . . . 222
Creating Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Writing Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Compiling Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Updating Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Running Other Business Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Examples of Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Chapter 11 Customizing Specific Business Components . . . . . . .227

Customizing Process Incoming Bank Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Customer Payments in Bank File Import Lines . . . . . . . . . . . . . . . . . . 228
Setting Up Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Enabling and Disabling the Customizable Matching Logic . . . . . . . . 237
Customizing the Validation of Tax IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Validation Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Customization Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Chapter 12 UI Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Contents ix
Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Settings that Affect Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Starting Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Working in Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Customize Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Delete Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Exporting Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Importing Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
User-Defined Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Create a User-Defined Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
UDFs and Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Modifying UDFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Adding Fields to Financials QRF Reports . . . . . . . . . . . . . . . . . . . . . . 261
User-Defined Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Elements of User-Defined Component Implementation . . . . . . . . . . . 265
User-Defined Components Maintain . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Example of User-Defined Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Non-Intrusive Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Creating a New Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Financial Text Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Chapter 13 Installing Electronic Bank File Formats . . . . . . . . . . . .283

Introduction to Electronic Banking Format Installation . . . . . . . . . . . . . . . . . . 284
Setting up EDI eCommerce to Use Imported Bank Formats . . . . . . . . . . . . . . 284
Using Bank File Format Import to Install the Format . . . . . . . . . . . . . . . . . . . 287
Default Directory Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Product Information Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
x QAD System Administration User Guide
System Administration
Change Summary
The following table summarizes significant differences between this document and previous
versions.
Date/Version Description Reference
March 2015/2015 EE Added new section on Customer Invoice Numbering page 23
Updated the Batch Processing and Daemons chapter to reflect changes page 87
to daemon functionality.
Made minor change to the description of the Payment Selection page 141
Confirm Batch Size field in System Maintain
Added new section on Bulk Data Load functionality page 131
Added new section on Financial Text Translation page 281
March 2014/2014 EE Added section on server.xml page 148
Miscellaneous minor changes
September 2013/2013.1 EE Added new section on the Statutory-Currency Utility page 205
Miscellaneous minor changes --
March 2013/2013 EE Added section on Adding Another URL for the Same Browse page 54
Updated the Primary Key Fields section page 130
Updated System Maintain section for new fields page 139
Added section on Determining the Optimal Payment Selection Confirm page 142
Batch Size
Added section on Adding Fields to Financials QRF Reports page 261
September 2012/2012.1 EE Rebranded for QAD 2012.1 EE --
March 2012/2012 EE Added new section on Generalized Code Group page 13
Added description for new Cube daemon page 93
Added descriptions for four new fields in System Maintain page 139
Removed reference to Master Data Audit Detail report, which was page 194
removed from the menu
September 2011/2011.1 EE Rebranded for QAD 2011.1 EE --
Updated sentence that refers to default settings --
Updated the introduction to Exporting Customizations to list the page 256
filenames to which customizations are exported
Updated screenshot and field descriptions to show new Folder Name page 256
field in Export UI Customization
Updated screenshot and field descriptions to show new Folder Name page 257
field in Import UI Customization
xii QAD System Administration User Guide
Chapter 1
Introduction to System
Administration
System Administration Overview 2
Discusses required setup tasks and common administrative tasks.
Types of Functions 3
Explains which functions are included with the system.
Domain Constants 3
Discusses programs on the Domain Constants menu.
System Interface 3
Discusses programs on the System Interface menu.
Printers 3
Discusses programs on the Printer Management menu.
Batch Processing and Daemons 4
Discusses programs on the Batch Processing/Daemon menu.
System Control 4
Discusses programs on the System Control menu.
CIM Interface 4
Discusses how CIM can be used.
Database Management 4
Explains how the system allows database management functions to be performed.
Reports and Utilities 4
Discusses reports and utilities available on the System Administration menu.
Customizing Component-Based Functions 5
Explains how to customize component-based functions.
2 QAD System Administration User Guide
System Administration Overview

As part of any initial implementation, you must perform a number of setup tasks, including the
following:
Set up system-wide data such as generalized codes, printers, batch queues, menus, messages,
and language code.
Define users and security. For more information on users and security, see QAD Security and
Controls User Guide.
Set up the basic corporate structure that forms the basis for all business activities. This setup
includes shared address data; domains, which are sets of related business entities that share a
common base currency and chart of accounts; entities; and other shared data. For more
information on the corporate structure setup, see QAD Financials User Guide.
Note Shared Services Domain is a separately licensed module. Unless you purchase
appropriate licenses, the system prevents you from having more than one active domain per
database.
Define base data such as items, sites, and locations. For more information on items, sites, and
locations, see QAD Master Data User Guide.
This book covers the first topic, setting up system-wide data, as well as common administrative
tasks that are required in a running system. It is divided into two sections, reflecting these distinct
activities:
Database Setup, which includes domain constants, system interface, printers, batch processing
and daemons, and configuring database settings.
Database Administration, which includes the CIM interface, database management, and
reports and utilities.
The System Administration menu includes tasks typically performed by system administrators.
Most functions located on this menu (36) are discussed in this volume. However, a few areas are
discussed in other volumes:
Corporate Structure Setup (36.1). For more information on the corporate structure setup, see
QAD Financials User Guide.
Operational Accounting Controls (36.9) are described in the various user guides for the
functional areas they affect.
System Security (36.3) and Enhanced Controls (36.12). For more information on security and
enhanced controls, see QAD Security and Controls User Guide.
Configured Messaging (36.4.6.13) applies only to scheduled orders. For more information on
Configured Messaging, see QAD Scheduled Order Management User Guide.
Options on the External Interfaces menu (36.5) are discussed in the user documentation for the
appropriate product area.
This volume does not cover the various utilities on the System Administration menus numbered
above 24. For documentation of these programs, see the procedure help or the opening program
screen of each utility.
Questions? Visit community.qad.com

Introduction to System Administration 3
Types of Functions
The system includes both standard Progress programs and component-based functions. The
component-based technology extends features of the user interface. These activities can be
executed only from the .NET UI.
Because of differences in the underlying technology of the two types of programs, some
administrative functions apply to one or the other, and some apply to both. For example, you set up
menu locations for standard programs and component-based functions using Menu System
Maintenance. However, batch setup applies only to standard programs and daemon setup applies
only to component-based functions.
The type of program affected by an area of system administration is pointed out in the discussion
of each system administration feature.
Domain Constants
The programs on the Domain Constants menu (36.2) control calendars and codes used throughout
the system. These include shop and holiday calendars, reason and generalized codes, and rounding
methods. See Domain Constants on page 7 for details.
In addition, you can set up number sequences using number range management (NRM) functions,
which support regulatory controlled document numbering. NRM controls the content and
sequencing of a numeric series, as well as preventing gaps in a series.
Finally, you can specify fields in tables for detailed change tracking and reporting.
System Interface
The System Interface menu contains programs that control menus, screen labels, messages, multi-
language installations, and help. You can set up user function keys, define your e-mail system, and
specify login scripts.
System interface functions include programs for creating browses and associating them with fields
and programs, and managing stored browse data. In addition, you can also define alternate
programs to execute when menu items are selected and specify programs to be run from other
programs.
To meet specialized needs, you can set up user-defined fields for both standard programs and
component-based functions.
See System Interface on page 31 for details.
Printers
The Printer Management menu contains programs for setting up system printers, specifying
default printers for a single user or all users, and creating batch print requests.
See Printers on page 79 for details.
Comments? Go to goo.gl/MfwKHm

Use programs from the Batch Processing/Daemon menu to set up background jobs and manage
and monitor daemon processes, which run in the background and perform required utility tasks
when the system is being used.
See Batch Processing and Daemons on page 87 for details.
System Control
The System Control menu contains critical control programs that must be set up before the system
is used, that affect all users, domains, and entities.
See System Control on page 137.
CIM Interface
CIM (computer integrated manufacturing) is one way to load legacy or non-Progress data into the
QAD database. Using CIM, data can be added using standard program validation.
See CIM Interface on page 155 for details.
Database Management
The system provides utilities for monitoring database size, performing dumps and loads, reloading
archive files, and managing database sequences. Delete/archive followed by dump/load is the
standard means of controlling database size and fragmentation in Progress databases.
User licensing utilities and programs for managing time zones are also included in database
management.
See Database Management on page 165 for details.

A number of system-wide reports and utilities are provided on the System Administration menu.
The system cross-reference programs display information about field, program, and table
relationships in your database. If you customize your implementation, this is an essential set of
programs.
The system can use a Progress application server (AppServer) to run applications remotely. The
AppServer must be defined first to make it available.
See Reports and Utilities on page 193 for details.

Introduction to System Administration 5
Customizing Component-Based Functions

In addition to using such tools as Design Mode and user-defined fields to modify the way
component-based QAD applications work, you also can customize business component code for
an installed application using a standard Progress 4GL editor.
See Customizing Component-Based Functions on page 5.

Chapter 2
Domain Constants
The programs on the Domain Constants menu control calendars and codes used by various
functions within a domain.
Overview of Domain Constants 8
Lists the programs on the Domain Constants menu.
Maintaining Holiday and Shop Calendars 8
Explains how to use Calendar Maintenance and Holiday Maintenance.
Using Generalized Codes 10
Discusses which conditions can be controlled with generalized codes, gives information on
prerequisite field validation, and explains how to use generalized code groups.
Using Reason Codes 15
Explains how to use Reason Codes Maintenance.
Managing Number Ranges 15
Gives an overview of NRM, discusses number segment types, the sequence life cycle, NRM
sequences, setting up sequences, setting sequence values, defining sequences for sales orders,
viewing sequence number history, and deleting and archiving sequences.
Tracking Changes 27
Explains how to use Change Tracking Maintenance, gives an overview of change tracking
implementation, and explains how to define change tracking reason codes, activate change
tracking, and specify fields to track.
Overview of Domain Constants

Domain constants provide basic data used by many system functions. All codes defined by the
functions listed in Table 2.1 are domain specific. Since a domain represents a distinct business
operation, codes can be quite different between domains. If you need to use the same code in more
than one domain, you must set it up for each domain that requires it.
Table 2.1
Domain Constants Menu (36.2)
Number Menu Label Program
36.2.1 Holiday Maintenance mghdmt.p
36.2.2 Holiday Browse mgbr017.p
36.2.5 Calendar Maintenance mgscmt.p
36.2.6 Calendar Inquiry mgsciq.p
36.2.13 Generalized Codes Maintenance mgcodemt.p
36.2.14 Generalized Codes Browse mgbr004.p
36.2.15 Generalized Codes Validation Rpt mggencrp.p
36.2.17 Reason Codes Maintenance mgrnmt.p
36.2.18 Reason Codes Browse mgbr007.p
36.2.19 Reason Codes Report mgrnrp.p
36.2.21 Number Ranges Menu ...
36.2.21.1 Number Range Maintenance nrsqmt.p
36.2.21.2 Sequence Browse nrbr001.p
36.2.21.5 Sequence Number Maintenance nrnxmt.p
36.2.21.13 Sequence Number History Report nrsqrp.p
36.2.21.23 Sequence Delete/Archive nrsqup.p
36.2.22 Change Tracking Maintenance mgtblcmt.p
36.2.23 Change Tracking Browse mgbr223.p
Maintaining Holiday and Shop Calendars

The shop calendar is required for planning, manufacturing, and distribution modules. The calendar
indicates what days the plant is open and how many hours are worked each day. This information
is used:
To schedule start and due dates for MRP planned orders, master schedule orders, and work
orders
To schedule operations for work orders and repetitive schedules
To schedule the procurement or shipment of materials through association with suppliers and
customers
Use Calendar Maintenance (36.2.5) and Holiday Maintenance (36.2.1) to maintain the calendars.

Domain Constants 9
Calendar Maintenance
Use Calendar Maintenance (36.2.5) to specify normal work days and normal work hours for each
site and its work centers. You create shop calendars for manufacturing using Calendar
Maintenance, but you use Customer Calendar Maintenance (7.3.1) to create customer calendars.
At least one calendar must exist.
You can create unique shop calendars by specifying some fields while leaving others blank. A
default shop calendar has a blank site, work center, and machine. The system searches for a shop
calendar in the following order:
For the specific site, work center, and machine combination
For site and work center with a blank machine
For site with both work center and machine blank
If shift patterns vary because of overtime, increased or reduced shifts, or plant shutdowns, enter
exception hours. Set up exceptions for a date range by specifying the number of hours that are
added to or subtracted from normal work hours.
Fig. 2.1
Calendar Maintenance (36.2.5)
In a calendar, the check box is selected for each work day and is deselected for each non-work day.
Manufacturing order due dates are scheduled only on work days. Each work day has a production
capacity in hours. This should exclude breaks and nonproductive time. Manufacturing operations
can be scheduled only up to the production capacity of the day.
Shop calendars are typically defined in this order:
1 Create a system calendar by leaving site and work center blank.
2 Create a calendar for each site with blank work centers. CRP uses this calendar to calculate
capacity, including holidays.
3 Create work center calendars with site and work center filled in.
The system searches for a calendar from the most specific to the least specificspecific site, work
center, and machine combination first and blank site, work center, and machine last.
You can specify exceptions, such as overtime or machine downtime for preventive maintenance.
The system uses exception information only when preparing operation schedules, but not when
calculating manufacturing order due dates.
Example On April 2, two hours of overtime are scheduled at site 10000. Enter OVERTIME as
the reference code, April 2 as both start and end dates, and +2 as Daily Hours.
If an exception occurs on a day that is not part of the standard work week, add that exception to an
existing day rather than changing the standard work week. Many scheduling programs assume that
the work week has a certain number of days. Adding a day to the standard work week can result in
inaccurate schedules.
Holiday Maintenance
Use Holiday Maintenance (36.2.1) to schedule holidays and other nonwork days that apply to an
entire site.
Fig. 2.2
Holiday Maintenance (36.2.1)
Holidays are days that no one works; the plant is shut down and no production is scheduled.
Manufacturing orders are never due and operations are not scheduled on a holiday.
Using Generalized Codes

When you install a new QAD database, a number of system and reference fields accept any kind of
data, as long as it does not exceed the field length. You can customize the user interface by adding
generalized codes and lookups.
Before implementing a module or particular functional area, the implementation team should
determine which fields should have generalized codes and lookups.
Generalized codes are domain specific since these codes may vary widely based on the type and
location of the business operation. For example, customer types, sales distribution channels, and
buyer/planner codes could differ between a domain representing a business in England and one in
Germany.
Important Some programs that update system-wide data such as User Maintenance (36.3.1)
reference generalized codes. These generalized codes must exist in all domains or you may
encounter errors editing a user record depending on what your current working domain is.
When using generalized codes, you can control four different conditions:
What the acceptable values in a field are. Define these values in Generalized Codes
Maintenance (36.2.13).
Whether a list of acceptable values displays in a lookup browse on the field. Specify this in
Drill-Down/Lookup Maintenance (36.4.8.1).

Domain Constants 11
Whether the codes you have created are the only acceptable codes (that is, whether the list is
validated). This may require you to add a validation expression to the data dictionary. See
Adding Validation on page 12.
Which users have permission to add, delete, and change generalized codes. If you decide to
use generalized codes groups, you can set permissions to edit generalized codes at a more
granular level. See Generalized Codes Groups on page 13.
Field Validation
Before entering a list of generalized codes for a field, you must know the fields name and size. In
the character interface, the field name displays in a pop-up window when you press Ctrl+F with
your cursor in the field. If the pop-up window indicates generalized codes validation, the system
automatically verifies data entered in the field against the list of generalized codes.
You can also use Generalized Codes Validation Report (36.2.15) to view a list of all fields in the
database that have schema validation assigned. This is the preferred method in the QAD .NET UI.
Note The system performs validation only when generalized codes have been defined for a field.
Example You have divided your customers into regions. The cm_region in the customer master
is updated in Customer Data Maintenance (2.1.1). As part of the implementation process, you
assign each customer to one of two regions. To ensure that only standard region codes are used,
define them as generalized codes. Specify cm_region for the field name, the values US and X-US
for the two regions.
Adding Generalized Codes
Figure 2.3 illustrates Generalized Codes Maintenance (36.2.13).

Fig. 2.3
Generalized Codes Maintenance (36.2.13)
Field Name. Specify a field name.
Value. Enter a valid value. Values cannot exceed the length of the field.
Comments. Enter a comment. The comment displays next to the value in the lookup.
Group. If you have permission, specify the generalized codes group that this generalized code
belongs to. The group the field is currently assigned to is displayed in this field. This field is
only relevant if you are using generalized codes groups.
Adding a Lookup
To set up a lookup to display generalized codes, use Drill-Down/Lookup Maintenance (36.4.8.1).

Enter the field name where you want the lookup and gplu072.p as the procedure to execute. See
Maintaining Drill Downs and Lookups on page 48.
This program creates the lookup with values from the assigned field. If the lookup should only be
accessed from a particular screen, enter that program name as the calling procedure.
Fig. 2.4
Drill-Down/Lookup Maintenance (36.4.8.1)
The description defaults from the data dictionary, but can be changed here. If no description exists,
the field name is a local variable. The description displays as the title of the lookup.
Note If you have not defined codes in Generalized Codes Maintenance for a field with
generalized codes validation, a lookup icon is displayed next to the field in the QAD .NET UI. If
you then define codes for the field, the lookup icon is changed to a drop-down list in which the
new codes are selectable. This change is visible when you log out and back in to the system, or
when you switch domains.
Adding Validation
Generalized code validation, like field security, requires a special validation expression in the
database dictionary that references the file gpcode.v.
Some fields already reference gpcode.v. These display in the Generalized Codes Validation
Report. If you want to activate generalized code validation for other fields, you must change the
data dictionary.
You can do this directly using full Progress or, if you have encrypted source, you can use the utility
utdbfx70.p. Once you have added a validation expression, you must recompile the affected
programs. For instructions on how to do this, refer to the Progress Programming Handbook.
To add validation for a local variable, you must insert the validation directly in the source code.
Important If you change the data dictionary, keep careful records and be prepared to repeat the
change when new product versions that update the data dictionary are installed.

Domain Constants 13
Generalized Codes Groups

Using generalized codes groups, you can extend security access to Generalized Codes
Maintenance beyond the system level down to the job functional level. This enables you to limit
the generalized codes fields that a user can edit.
Example A buyer needs access to item generalized codes but does not need access to
manufacturing codes.
By default, all generalized codes are assigned to one of two groups, SYSTEM or APP
(Application). Generalized codes associated with system-supplied fields are assigned to the
SYSTEM group. Generalized codes that are not part of the SYSTEM group are assigned to the
APP group. Although the administrator can modify access for any role, all roles with Generalized
Codes Maintenance access are automatically members of the APP group. Therefore, if you do not
want to use generalized codes groups, no action is necessary and the system continues to function
as expected.
Note It is recommended that the system administrator enable administrator access to the
SYSTEM group.
Before you use generalized codes groups, decide which groups you need, the fields to associate
with each group, and which roles have access to each group. Next, follow these steps to establish
generalized codes groups:
1 Create the groups in Generalized Codes Group Maint (36.2.10).
Note Enter a meaningful group name that contains a maximum of 24 characters.
Fig. 2.5
Generalized Codes Group Maint (36.2.10)
2 If necessary, use Role Create (36.3.6.1) to create the roles you want to associate with these
groups.
3 Ensure the role has access to Generalized Codes Maintenance under Secured items on menu in
Role Permissions Maintain (36.3.6.5).
4 Associate roles with the generalized codes groups in Secured items not on menu under
Generalized Code Groups.
Note If a role has access to all existing groups, the role is automatically assigned access to
each new group. When the administrator removes access to any group for a given role, the
administrator must manually grant access for each subsequent group added for that role.
5 Assign each field to its new group in Generalized Codes Maintenance (36.2.13).
Note A field can only belong to one group.
Working with Generalized Codes Groups
If you have implemented generalized codes groups in your system and associated the groups with
specific roles, role members can assign a new code to any field belonging to a group they have
access to. If a role member tries to assign a code to a field the role has no access to, an error
message is displayed.
An administrator can move fields from one group to another in Generalized Codes Maintenance,
provided the administrator has access to both groups. If a user with that role is not associated with
a generalized codes group and attempts to add or modify a code associated with that group in
Generalized Codes Maintenance, an error message is displayed.
Fig. 2.6
Generalized Codes Maintenance (36.2.13)
If you want to delete a generalized codes group, you must make sure it is not associated with any
generalized codes fields. If you try to delete a group tied to one or more fields, an error message is
displayed. A generalized codes group associated with generalized codes can be synchronized to
other domains and databases using QXtend. See QAD QXtend User Guide.
Browsing Generalized Codes Group Security
All users can browse generalized codes group security to identify which generalized codes fields
they have access to and to determine who has access if they do not. Based on a user search, the
Generalized Codes Sec. Browse (36.2.11) displays generalized codes groups and the domain
values for each group. The Role Resources Browse tab displays all roles that have permissions for
a generalized codes group. The Generalized Codes Field Browse tab displays all fields that belong
to a group.

Domain Constants 15
Using Reason Codes

Reason codes are used in security functions, sales quotes, sales order maintenance, purchase order
returns, shop floor reporting, repetitive reporting, and the Product Change Control (PCC) module.
They are also used if you have enabled change tracking and in several optional modules, such as
WIP Lot Trace, Electronic Signatures, and Shipment Performance. Add other custom uses as
needed.
Fig. 2.7
Reason Codes Maintenance (36.2.17)
Use codes of type User_Act for the Active Reason field in User Maintenance (36.3.1) and the
Auto-Deactivation Reason field in Security Control (36.3.24).
Use codes of type ESIG to indicate why a user is authorizing the data in an e-signature enabled
program.
Use codes of type QUOTE in the Reason Lost field of sales quotations.
Use codes of type CORRINV to specify why an invoice must be corrected in Sales Order
Use codes of type DOWN or DOWNTIME in the Reason field of labor feedback programs
(16.20.1 through 16.20.4).
Use codes of type ORD_CHG to associate changes made in Sales Order Maintenance to order
detail, such as a change to the order line quantity or due date. See Tracking Changes on
page 27.
Use codes of type DOWN, DOWNTIME, REJECT, REWORK, ADJUST, and SCRAP for
reporting in Repetitive and Advanced Repetitive programs. Use these same codes with the
optional manufacturing WIP Lot Trace module.
Use codes of type SCRAP with Advanced Repetitive subcontract shipping programs and
Scrap Transaction Maintenance (3.14). For more information on subcontract shipping
programs, see QAD Sales User Guide.
Use codes of type SHIPQTY and SHIPTIME with the Shipment Performance module.
Use codes of type RTV (return to vendor) to define reasons entered in Purchase Order Returns
(5.13.7).
Note Codes used in the PCC module are user-defined. They specify severity levels related to
approval of change documents.
Managing Number Ranges

Some countries impose sequencing requirements related to tax filings or statutory reporting. In
many countries, companies are legally required to prevent gaps in the numbering of official
documents.
Additionally, certain business practices require different business units within the same
corporation to maintain separate sequencing for similar documents such as purchase orders, sales
orders, and supplier invoices.
Example In Italy, the number of an official document is strictly related to the date the document
was printed, and it is a common practice to have multiple number ranges for shipment and invoice
documents. In Brazil, the number of an official document is related to a specific physical site,
requiring multiple number ranges with a prefix identifying a site code.
Number range management (NRM) supports varied sequencing requirements on a global scale.
Features include gap control and multiple number ranges for the same document type.
NRM Overview
NRM generates sequence numbers built from one or more segments, each with its own set of
characteristics and behavior.
You can add or remove segments during sequence definition, but once a sequence has been used to
generate or validate numbers, you cannot change its structure.
Figure 2.8 illustrates a sample sequence with five segments: three fixed-value segments (NY and
two dashes), one incrementing integer segment (1234), and one date-driven segment (06:15:07).
Fig. 2.8
Example Sequence Number
NY-1234-06:15:07
Segment 1
Segment 2
Segment 3
Segment 4
Segment 5
l b f

Domain Constants 17
Table 2.2 describes the three segment types.

Table 2.2
Number Segment Types
Segment Type Description Required
Incrementing A range of values, with a lower bound, an Yes. Each sequence
Integer upper bound, initial, and reset value. number must have one
and only one
incrementing integer
segment.
Date-Driven A value that depends on the transaction No. Each sequence can
effective date or the fiscal period that have one date-driven
corresponds to the effective date. segment.
The format is a compound string that allows
the optional display of date components
such as year, month, week, day, including
delimiters between components.
Delimiters separate the individual
components of a segment. For example,
06:15:07 uses colons as delimiters.
Fixed-Value Any printable character except a comma. No.
For example, NY may be a fixed-value
segment assigned by a client in New York.
A fixed-value segment is not changed in any
way during sequence number generation.
Sequence Number Generation
To update a sequence number, the system examines each segment separately. Only date-driven or
incrementing integer segment types are modified. A fixed-value segment is never changed.
Control Segments
You can set up a date-driven segment as a control segment. In this case, changing its value causes
the incrementing integer segment to reset to its assigned reset value. When a control segment does
not exist or does not change, the incrementing integer segment is incremented.
Sequence Parameters
Create sequence numbers and define sequence parameters using Number Range Maintenance
(36.2.21.1). A distinct segment editor defines the format and parameters of each segment type.
Internal and External Sequences
There are two types of sequence number: internal and external.

Internal sequences automatically generate numbers in ascending order as needed. NRM examines
each segment in the sequence to determine whether to update its value. A fixed-value segment
remains unchanged during sequence number generation.
External sequences accept a sequence number entered externally and validate it against a sequence
definition. NRM verifies that the number belongs to the set defined by the sequence and that it has
not yet been used. The system parses the number into segments and validates each segment against
the corresponding segment in the sequence definition.
Sequence Life Cycle

Figure 2.9 illustrates the life cycle of a sequence.
Fig. 2.9
Sequence Life Cycle
Create
Createthe
thesequence.
sequence.
NRM-enabled
NRM-enabledprogram
programuses
uses
sequence
sequencetotogenerate
generateoror
validate numbers.
validate numbers.
Define
Definesequence
sequenceparameters.
parameters.
Manually
Manuallymaintain
maintainsequence
sequence
numbers,
numbers,ififallowed.
allowed.
Add
Addsegments,
segments,as
asneeded.
needed.
Delete/archive
Delete/archiveobsolete
obsolete
sequences.
sequences.
Save
Savethe
thesequence.
sequence.
To set up a sequence, create an ID, define general parameters, and add appropriate segments. Once
a sequence is defined, a system program uses it either to obtain a new number or validate user-
entered numbers. Programs must be specially designed to use NRM sequence numbers.
If you attempt to discard or void a number, the system checks the sequence definition to ensure
that this is allowed.
You can delete and archive unneeded sequences.
NRM Sequences
Programs must be specifically enabled to use NRM. Currently, NRM sequences are used in several
system functions:
Fixed Assets
An optional NRM sequence number can be specified in Fixed Asset Control (32.24) for
automatically generating fixed asset ID numbers.
For more information on Fixed Asset Control, see QAD Fixed Assets User Guide.
General Ledger Daybooks
GL daybooks let you group and report GL transactions. Unposted transactions include the
daybook code and daybook entry number. NRM generates entry numbers based on the ID of the
daybook.

Domain Constants 19
Note When the Daybook Control type is Operational, you can configure Number Range
Maintenance for four customer invoice and credit note daybook types. See Configuring a
Customer Invoice Number Range on page 23.
Logistics Accounting
If you are using the optional Logistics Accounting module, two NRM sequences must be defined
in Logistics Accounting Control (2.15.24) for distribution order shipments and sales order
shipments.
For more information on Logistics Accounting, see QAD Master Data User Guide.
In addition, if you use PO Shipper/Invoice Maintenance (5.13.14) to receive goods into a transit
location, shipper/invoices use a unique NRM generated number.
Shipping
Many countries legally require businesses to maintain strict control when assigning numbers to
shipping documents. This is also true when multiple number ranges are assigned to the same type
of shipping document. To meet this need, NRM is required for all shipper functionality.
For more information on shipping documents, see QAD Sales User Guide.
WIP Lot Trace
An optional NRM sequence number can be specified in WIP Lot Trace Control (3.22.13.24) for
generating WIP lot and serial numbers in the various functions that trace them.
For more information on WIP Lot Trace Control, see QAD Manufacturing User Guide.
Kanban
If you use dispatch lists to communicate kanban card authorizations to your suppliers, you must
specify an NRM sequence in Kanban Control (17.24). The system uses the sequence to generate an
ID number during dispatch list processing.
For more information on Kanban Control, see QAD Lean Manufacturing User Guide.
Legal Documents
In some countries, the transportation of merchandise requires a document to prove legality and
possession of the inventory being moved. Typically, the legal document includes such elements as
the document number, ship-from address, ship-to address, item number and description, quantity,
and so on.
When you assign a legal document sequence ID with a ship-from address or document format, the
system uses that sequence to generate numbers for legal documents created during shipping
transactions.
For more information on legal documents, see QAD Sales User Guide.
Note The current release only supports issuing transactions. Receiving legal documents will be
supported in a later release.
Sales Order Numbers
You can set up optional NRM sequences to generate numbers for new orders entered in Sales
Order Maintenance (7.1.1) and Pending Invoice Maintenance (7.13.1). See Defining Sequences
for Sales Orders on page 26 for information.
Setting Up Sequences
Create sequences and define sequence parameters using Number Range Maintenance (36.2.21.1).
NRM uses a unique sequence ID to retrieve data and generate new numbers. Use Sequence
Browse (36.2.21.2) to view the defined structure of a sequence.
Fig. 2.10
Number Range Maintenance (36.2.21.1)
Sequence ID. Enter a code uniquely identifying a sequence. Create a new sequence or use
Next/Previous to retrieve an existing sequence.
Description. Enter a description of this sequence, up to 40 characters.
Target Dataset. Enter the dataset identifier associated with this sequence. The target dataset
can indicate who owns the sequence or where its numbers are used. A sequence owner can be
a process, a document, or any other entity that the client program can recognize.
Note The target dataset could be the name of the principal database field where numbers
from the sequence are used.
You cannot create a new sequence that intersects an existing sequence with the same target
datasetcreating two sequences that could generate the same sequence number for the same
target field.
For example, if sequences A and B both target field so_nbr, they cannot have a common
element that could cause conflicts.
The following three target datasets are used with shippers:
abs_id.shipper is used for sales order shippers.
abs_id.preship is used by sales order pre-shippers.
abs_id.mbol is used by master bills of lading.
For Fixed Assets, specify dataset fa_id.
For Logistics Accounting, specify:
la_so_ship_id for sales order shipments
la_do_ship_id for distribution order shipments

Domain Constants 21
For shipper/invoices, specify dataset abs_id.poshipper.

For Kanban, specify dataset knbd.dispatch_id.
For legal documents, specify dataset abs_id.LegalDoc.
For sales orders, specify a dataset that begins with so_nbr.
Note Additional language detail setup is required to use NRM to generate sales order
numbers. See Defining Sequences for Sales Orders on page 26.
Internal. Specify whether the sequence numbers are supplied by an external source or
automatically generated by NRM. Select the check box if numbers are generated by NRM.
Allow Discarding. Using a number causes it to be registered. This field determines whether a
registered number can be discarded, leaving a gap in the sequence.
Clear (the default): Gaps are not allowed and numbers cannot be discarded from this sequence.
Selected: You can discard previously registered numbers from this sequence by reversing the
register operation. NRM then erases all record of the sequence number, and the discarded
number is replaced by a gap.
Allow Voiding. Determines whether you can mark a registered number as void.
Clear: Numbers in this sequence cannot be voided. This is the default.
Selected: You can void numbers and specify a brief description why. Voiding is recorded as a
separate event in the sequence history.
Effective Date. Indicates the earliest date when this sequence can be used.
Expiration Date. Indicates the latest date when this sequence can be used.
Segment List
After you define the initial parameters for a sequence, Segment List and Editor frames display. The
segment list shows the type and settings for each segment defined in the sequence. Segments
display in ascending order, based on segment number.
Fig. 2.11
Number Range Maintenance (36.2.21.1), Segment List Frame
Segment Editors
The segment editor used depends on the type of segment being defined. Use the editor to create or
modify the segment format definition and assign a new segment number. There are four types of
segment editors.
Fixed segment editor for fixed value segments
Integer segment editor for incrementing integer segments
Date segment editor for date-driven segments
Fiscal segment editor for date-driven segments, relative to fiscal periods
Fixed Segment Editor
Use the fixed segment editor to establish a fixed string value. You can use any printable character
except a comma.
Fig. 2.12
Fixed Segment Editor
Integer Segment Editor
Use the integer segment editor to specify the initial, reset, minimum, and maximum values for a
segment.
Fig. 2.13
Integer Segment Editor
Date Segment Editor
Use the date segment editor to tell NRM how to display a date component of a sequence number.
Specify codes representing date components such as year, month, day. You can add components in
any order, with optional delimiters. In the date segment 07/02, a forward slash is the delimiter. You
can use any printable character except a comma or another date component as a delimiter.
You can indicate if this segment is a control segment. Changing the value of a control segment
causes the incrementing integer segment to reset to its assigned reset value. The new value in the
control segment ensures that the sequence numbers generated after resetting are unique within the
target dataset.
Fig. 2.14
Date Segment Editor

Domain Constants 23
Fiscal Segment Editor
Use the fiscal segment editor to tell NRM how to display a fiscal date component of a sequence
number.You can add fiscal segments only if the sequence has an expiration date. Codes represent a
component of a fiscal period. Otherwise, this editor is exactly the same as the date segment editor.
Fig. 2.15
Fiscal Segment Editor
Configuring a Customer Invoice Number Range
When the Daybook Control type is Operational, you can configure Number Range Maintenance
for four customer invoice and credit note daybook types. They are:
Customer invoice
Customer credit note
Customer invoice correction
Customer credit note corrections
This feature provides companies with the flexibility to configure the invoice number range format
and the invoice number length. It also addresses business requirements for companies that want to
configure their own customer invoice number range or want to reduce the length of the default
customer invoice number range. In addition to specifying the invoice number length and format,
you can specify whether the invoice numbering sequence must be continuous over subsequent GL
calendar years or whether the sequence must restart each year.
Important For manually created Financial invoices, the numbering format is not configurable,
uses the format year/daybook/voucher number, and is fixed at 22 digits.
The process to configure customer invoice number ranges includes several steps.
Fig. 2.16
Configuring a Customer Invoice Number Range
SalesOrder
DaybookCreate Maintenance
NumberRange
SalesOrderShipment
Maintenance
AssignDaybookto
CustomerDefault InvoicePostandPrint
DaybookSet
1 Create a new daybook code in Daybook Create (25.8.1.1). Specify a daybook type of
Customer Invoice and a daybook control of Operational.
2 Go to Number Range Maintenance to configure the number range for the daybook.
Fig. 2.17
Number Range Maintenance
You must specify one FISCAL segment, at least one FIXED type segment, and one INT
segment for the invoice number range:
The FISCAL type segment denotes the GL calendar year. The default format for the Fiscal
Format field is Y, which displays the year as four digits. If, for example, you want the year
segment to only show two digits, update the fiscal format to Y2.
A FIXED type segment for the daybook.
If you modify an existing customer invoice number range, the range may have a
second FIXED segment containing /.
You can delete the FIXED segment of /, or add another FIXED segment, but you
cannot delete the FIXED segment that contains the daybook code.
If you modify an existing number sequence, you can reduce the number of characters
for the daybook code specified for the FIXED segment. For example, if the previous
code was ARINV, you can change this to IV. However, the new FIXED segment code
must be unique; that is, it must not be used for any other customer invoice number
range.
The INT (integer) type segment denotes the sequence number.
See Customer Invoice Numbering Restrictions on page 25 for specific restrictions that
apply.
3 To ensure that new customer invoices follow this defined format, assign the daybook code to
the default customer daybook set in Daybook Set Maintenance (25.8.7) or Daybook Set by
Site Maintenance (25.8.10).
4 To use the new invoice numbering, create an order in Sales Order Maintenance (7.1.1).
5 Ship the order in Sales Order Shipments (7.9.15).

Domain Constants 25
6 Run Invoice Post and Print (7.13.4) to create a new operational customer invoice. The new
invoice number range format is applied.
Customer Invoice Numbering Restrictions
Customer invoice numbers are subject to validations in Number Range Maintenance. You cannot:
Delete year, daybook, or sequence segments.
Edit the expiry date.
Modify segments of type INT during the GL calendar year.
However, you can:

Modify the length of the segment.
Change the segment order.
Insert other segments of type FIXED.
Delete a segment of type FIXED that initially contained the value /.
Change the daybook code for a segment of type FIXED.
As with the number range sequences for Financial daybooks, clear the Allow Discarding and
Allow Voiding fields in Number Range Maintenance for customer invoice number ranges.
For more information on customer invoices, see QAD Financials User Guide.
Setting Sequence Values

Use Sequence Number Maintenance (36.2.21.5) to set the next value for an existing sequence,
when:
The sequence is internal.
Allow Discarding is selected.
The default in Sequence Value is the last number that was used. If you update it, the system
validates the new value against the segment order and settings. It then increments the new value
the next time the sequence is used.
Fig. 2.18
Sequence Number Maintenance (36.2.21.5)
Defining Sequences for Sales Orders

You can define NRM sequences that assign numbers to sales orders in Sales Order Maintenance
(7.1.1) and Pending Invoice Maintenance (7.13.1).
1 In Language Detail Maintenance (36.4.2), for Data Set so_seq_id and Field Name seq_type,
create one or more mnemonics, assigned to Numeric Code 6 or higher.
Note Lower numbers are reserved for future functionality enhancements.
2 In Number Range Maintenance, create a new sequence ID and assign it to a dataset with the
following value:
so_nbr.mnemonic
Where mnemonic comes from the language detail record defined in step 1.
You can define multiple sequences as needed if you want to assign order numbers based on site or
some other criterion.
When any sequence definition is assigned to a dataset beginning with so_nbr, navigation changes
in Sales Order Maintenance and Pending Invoice Maintenance during order entry. The system
displays an additional Sequence ID field before assigning an order number. The look-up browse
displays only IDs that have a dataset value beginning with so_nbr.
If you select a value, the system uses NRM to generate an order number based on the associated
definition. If you leave Sequence ID blank, the system uses Sales Order Control (7.1.24) to
determine the next order number.
Viewing Sequence Number History

When a client program uses a sequence to dispense or validate numbers, the system creates history
records. Use Sequence Number History Report (36.2.21.13) to view history data on internal and
external sequences.
You can view the sequence definition, which sequence numbers have been used, and which
sequence numbers have not been used, including gaps. This report helps you to identify missing
documents by reporting numbers that are not recorded in the sequence history.
Deleting and Archiving Sequences

Use Sequence Delete/Archive (36.2.21.23) to delete sequences and associated history. You can
optionally archive information to an external file and later restore it using Archive File Reload
(36.16.5).
Once sequence history is deleted, it no longer appears on the Sequence History Report.

Domain Constants 27
Fig. 2.19
Sequence Delete/Archive (36.2.21.23)
Specifies whether to delete historical If selected, copies each selected record

information (selected) or review to the file displayed in Archive File.
without deleting (deselected).
Tracking Changes
Use Change Tracking Maintenance (36.2.22) to mark sales order detail fields for change tracking.
For line detail information in discrete sales orders, you can:
Specify which field to track.
Activate or deactivate tracking.
Delete any records for fields that no longer require tracking.
Allow users to enter a reason code and comments when the value of a marked field changes.
Print the changes, reason codes that explain the changes, and any associated comments on a
Booking Transaction Report (7.15.14). For more information on Booking Transaction Report,
see QAD Sales User Guide.
Change Tracking Implementation Overview

When implementing change tracking, you work with different programs to set up codes, activate
change tracking, specify what to track, then view results. Figure 2.20 illustrates the basic change
tracking implementation flow.
Fig. 2.20
Change Tracking Implementation Flow
Define
Definereason
reasoncodes
codesforfor
ord_chg
ord_chgreason
reasontype.
type.
Enter
Enterreason
reasoncodes
codesand
and
comments
commentswhen
whenfield
fieldvalues
values
change.
change.
Activate
Activatechange
changetracking.
tracking.
View
Viewchanges,
changes,reason
reasoncodes,
codes,
and
andcomments.
comments.
Specify
Specifyandandactivate
activatethe
thetable
table
and
andfield
fieldtototrack.
track.
Defining Change Tracking Reason Codes

You must define reason codes that explain changes to sales order detail in Reason Codes
Maintenance (36.2.17). You specify ord_chg as the reason type. You must define at least one
reason code for the ord_chg type to implement change tracking.
Create reason codes that fit your companys most common reasons for changes to sales order
details. For example, you can create a Delete reason code for deleted orders. See Using Reason
Codes on page 15.
Activating Change Tracking

Activate change tracking by selecting Keep Booking History in Sales Order Control (7.1.24).
Specifying Fields to Track

Use Change Tracking Maintenance (36.2.22) to:
Specify which table contains the fields you want to track.
Specify which fields to track.
Delete any records for fields that no longer require tracking.
Fig. 2.21
Change Tracking Maintenance (36.2.22)
Table. Enter the database table that contains the field that is being tracked for changes.
Currently, Change Tracking Maintenance tracks only the sales order detail (sod_det) table.
Description. Enter a brief description (24 characters) of the database table.
Active. Select to track changes for the database table you specified. Clear to deactivate
tracking. The default is clear.
You must select Active for both the table and the field before change tracking begins.
Delete. Select to display the reason code pop-up in Sales Order Maintenance when the user
deletes an entire sales order line. Clear if you do not want the reason code pop-up to display.
The default is clear.
Note You must select Active and specify a field to track.
Once you complete these fields and click Next, the following frame appears.

Domain Constants 29
Fig. 2.22
Change Tracking Maintenance, Field Frame
Field. Enter the field to track. Currently, you can only track fields belonging to the sales order
detail (sod_det) table.
Note To find the field name in the character interface, press Ctrl+F while your cursor is
located in the field. In the QAD .NET UI, the field name displays as a field tip when your
cursor moves over a field.
Description. Enter a brief description (24 characters) of the field.
Active. Select to activate tracking for the field you specified. Deselect to deactivate tracking
(the default).
Review the tables and fields you specify and their active or delete status using Change Tracking
Browse (36.2.23).
Reason Code Pop-Up
After you activate change tracking and specify a table and field to track, when the user changes or
deletes the value of the field, a reason code pop-up displays. Currently, only the sales order detail
table can be tracked; therefore, the reason code pop-up displays in Sales Order Maintenance
(7.1.1).
Select a code that indicates the reason you are changing the value of the field or deleting the line.
The reason type associated with the code must be ord_chg.
Even though you can track multiple fields, you are only prompted once with the reason code pop-
up. Use the comment screen to explain multiple changes you made to the sales order line.
Viewing Changes
To view changes you tracked, use Booking Transaction Report (7.15.14). The report displays the
reason and comments related to a discrete sales order line change.
To display the changes:
Set Summary/Detail to Detail.
Select Include Reason/Comments.
Fig. 2.23
Booking Transaction Report (7.15.14)

Chapter 3
System Interface
The System Interface menu contains programs that control menus, messages, multi-language
installations, browses, and help.
Languages, menus, messages, user functions, help, labels, and e-mail definitions are all system-
wide data and apply to all domains in a database.
Overview of User Interface 33
Describes the system interface menu.
Using Multiple Languages 37
Discusses how to use multiple languages and Unicode, set up multiple languages, Language Detail
Maintenance, and report translation.
Customizing Menu Information 41
Explains how to customize menu information by executing menu items, and describes the menu
structure, menus and security, Menu System Maintenance. Also discusses how to set up menu
substitutions, define program information, and view business components.
Modifying Messages 47
Explains how to use Message Maintenance.
Creating and Managing Browses 48
Explains how to maintain drill downs and lookups, create access to other programs, manage stored
searches, define browse URL links, create browses, and create views.
Defining User Menu and Function Keys 65
Explains how to use the user menu, execute programs in sequence, and use User Function
Maintenance.
Using Field and Program Help 66
Explains how to add user help and print help documents.
Setting User Telnet Options 67
Explains how to configure telnet server settings, define the login sequence script lines, configure
telnet connection settings, and verify the login sequence.
Modifying Labels 71
Explains how to use Label Master Maintenance.
Building an E-Mail System Interface 72

Explains how to set up e-mail system inquiries, use text e-mail, e-mail attachments, use E-mail
Definition Maintenance, modify e-mail command parameters, customize the appearance of HTML
e-mail, and configure e-mail notification for components.
Using Advanced Reporting Tools 75
Explains how to use the Report Setup Menu, QAD-provided dashboards, and custom reports and
dashboards.
Monitoring User Sessions 76
Explains how to use Session Master Maintenance.

System Interface 33
Overview of User Interface

QAD application functions can be used in two ways:
All functions are available in a .NET-based graphical user interface (UI).
A subset of functions can be used in a simplified character interface.
For programs that run in the .NET UI, some present simple HTML screens; other use an advanced
component-based technology that supports tabbed navigation and other technologies that are not
available with standard programs.
The functions on the System Interfaces menu let you manage different aspects of information that
display on the UI and that affect how users interact with the system. Some of these functions apply
only to the character UI, some to .NET UI, some to component-based functions, and some to all
functions.
Table 3.1 lists all the menu items on the System Interface Menu. The Program column indicates if
this is a standard Progress program (.p) or a component with activities. The UI column indicates
which user interface the program can be run from. Some programssuch as the component
activitiescan only be opened in the .NET UI; others can be used in both character and the .NET
UI. The column labeled Affects indicates which programs the System Interface program affects:
All programs, including standard Progress programs in the character UI, Progress programs
running as HTML screens in .NET UI, and component-based functions in the .NET UI
Standard programs in both character and .NET UI
Standard programs in character only
Standard programs in .NET UI only
Component-based activities in .NET UI only
Note While it may be possible to execute a program from both the .NET UI and the character UI,
the effect of the program may be seen in only one UI. For example, you can set up menu URLs
from the character UI or the .NET UI, but the links are only active in browses run from the .NET;
they cannot be executed from character browses.
Table 3.1
System Interface Menu
Menu No. Menu Description Program UI Affects
36.4.1 Language Maintenance Component .NET All programs
36.4.1.1 Language Create Activity
36.4.1.2 Language Modify Activity
36.4.1.3 Language View Activity
36.4.1.3 Language Delete Activity
36.4.2 Language Detail mglngumt.p Both Standard programs
Maintenance in either UI
Table 3.1 System Interface Menu (Page 1 of 4)

36.4.3 Report Translation Component .NET Component-based
Maintenance reports
36.4.3.1 Report Translation Activity
Create
Modify
36.4.3.3 Report Translation View Activity
Delete
36.4.4 Menu System Menu
36.4.4.1 Menu System mgmemt.p Both All programs
Maintenance
36.4.4.2 Menu System Report mgmerp.p Both All programs
36.4.4.7 Menu Substitution mgmsmt.p Both Standard programs
Maintenance in character UI
36.4.4.8 Menu Substitution mgbr013.p Both Standard programs
Browse in character UI
36.4.4.13 Program Information mgpgmimt.p Both Standard programs
36.4.4.14 Program Information mgbr060.p Both Standard programs
Browse in either UI
36.4.4.15 Program Information mgpgmiut.p Both Standard programs
Update in either UI
36.4.4.22 Business Component Activity .NET View only
View
36.4.6 Message Menu
36.4.6.1 Message Maintenance mgmsgmt.p Both Standard programs
in either UI
36.4.6.2 Message Browse mgbr006.p Both Standard programs
in either UI
36.4.6.3 Message Report mgmsgrp.p Both Standard programs
in either UI
36.4.6.13 Configured Message mgcfmmt.p Both Standard programs
36.4.6.14 Config Msg Verif Report rcrp14.p Both Standard programs
in either UI
36.4.8 Browse Menu
36.4.8.1 Drill-Down/Lookup mgdlfhmt.p Both Standard programs
36.4.8.2 Drill-Down Browse mgbr001.p Both Standard programs
in either UI
36.4.8.3 Lookup Browse mgbr005.p Both Standard programs
in either UI
36.4.8.5 User Tool Maintenance mgtoolmt.p Both Standard programs .
in .NET UI only

System Interface 35

36.4.8.7 Stored Search Component .NET Component-based
Maintenance browses in .NET UI
36.4.8.7.1 Stored Search View Activity
36.4.8.7.2 Stored Search Export Activity
Browse Defaults
36.4.8.7.3 Stored Search Delete Activity
36.4.8.9 Browse URL mgburlmt.p Both Standard browses in
Maintenance .NET UI
36.4.8.10 Browse URL Browse mgbr221.p Both Standard browses in
.NET UI
36.4.8.13 Browse Maintenance mgbwmt.p Both Standard programs
in either UI
36.4.8.14 Browse Master Browse mgbr003.p Both Standard programs
in either UI
36.4.8.15 Browse Detail by Field mgbr040.p Both Standard programs
in either UI
36.4.8.18 View Maintenance mgvwmt.p Both Standard programs
in either UI
36.4.8.19 View Browse mgbr020.p Both Standard programs
in either UI
36.4.10 User Function mgufmt.p Both Standard programs
Maintenance in character UI
36.4.11 User Function Browse mgbr008.p Both Standard programs
in character UI
36.4.12 User-Defined Field Maintenance
36.4.12.1 User-Defined Field Activity .NET Component-based
Create activities.
36.4.12.2 User-Defined Field Activity Chapter 12, UI
Modify Customization, on
36.4.12.3 User-Defined Field View Activity page 241.
36.4.12.4 User-Defined Field Activity

Delete
36.4.13 Field Help Menu
36.4.13.1 Field Help Maintenance mgflhusr.p Both Standard programs
in either UI
36.4.13.2 Field Help Report mgflhdrp.p Both Standard programs
in either UI
36.4.13.3 Field Help Book Report mgflbook.p Both Standard programs
in either UI
36.4.13.4 Procedure Help Report mgflprrp.p Both Standard programs
in either UI
36.4.13.13 Field Help Dump mgfldmp.p Both Standard programs
in either UI
36.4.13.14 Field Help Load mgflld.p Both Standard programs
in either UI

36.4.14 User Option Telnet mgusrtmt.p Both Standard programs
Maintenance in .NET UI
36.4.15 User Option Report mgusrrp.p Both Standard programs
in .NET UI
36.4.17 Label Menu
36.4.17.1 Label Master gplblmt.p Both Standard programs
36.4.17.2 Label Master Browse gpbr405.p Both Standard programs
in either UI
36.4.17.5 Label Detail gplbldmt.p Both Standard programs
36.4.17.6 Label Detail Browse by gpbr406.p Both Standard programs
Field in either UI
36.4.17.7 Label Detail Browse by gpbr407.p Both Standard programs
Program in either UI
36.4.17.24 Label Control gplblpm.p Both Standard programs
in either UI
36.4.18 Customization Export Activity .NET Component-based
functions in .NET
36.4.19 Customization Delete Activity .NET Component-based
functions in .NET
36.4.20 E-mail Definition mgemmt.p Both Standard programs
36.4.21 Report Setup Menu
36.4.21.1 Report Maintenance rprprsmt.p Both Standard programs
in either UI
36.4.21.2 Report Synchronization rprpsync.p Both Standard programs
in either UI
36.4.21.3 Report Parameter rprpptmt.p Both Standard programs
36.4.21.4 Report Parameter rpptsync.p Both Standard programs
Synchronization in either UI
36.4.21.13 Admin User Variant rpuvmt01.p Both Standard programs
36.4.21.14 Personal User Variant rpuvmt02.p Both Standard programs
36.4.21.21 Report Resource Import rprroim.p Both Standard programs
in either UI
36.4.21.22 Report Resource Export rprroex.p Both Standard programs
in either UI
36.4.21.24 Report Control rppm.p Both Standard programs
in either UI
36.4.22 Session Master mgsessmt.p Both All programs
Maintenance

System Interface 37
Using Multiple Languages

A single QAD database can be set up with multiple domains, each with a distinct language. With a
Unicode database, languages with different code pages can be supported in the same database.
Defining a Unicode database is an installation option described in the relevant installation guide
for your system.
Unicode is a data storage and display protocolessentially a combination of a code page and
collation table. The QAD Unicode database uses the UTF-8 code page, which includes all
characters from all languages; the collation table sets the sort order for those characters for display
or reporting. The advantage of Unicode is that one database can contain as many languages as you
require. Without Unicode, a single database can include only languages that share the same code
pagesuch as French, German, and Spanishor languages with compatible code pagessuch as
English and Chinese.
Each user is also assigned a language. A user logging in through the .NET UI can access any
domain in a Unicode database regardless of their associated language. The character client,
however, does not support Unicode. A user logging in through the character UI must log in to a
domain with a code page that is compatible with the language they are assigned, as defined in
Domain Create (36.1.1.1.1). For more information on domains, see QAD Financials User Guide.
Example A database includes three domains: French, Chinese, and English. John is assigned the
Chinese language. John can log in to all three domains in the .NET UI. When using the character
UI, John cannot log in to the French domain; an error displays if he tries to do this.
Multi-language capabilities are used in two areas:
Screens and screen elements such as labels and messages are displayed in multiple languages.
Data is stored and displayed in multiple languages.
All single set of r-code can be used with all supported languages. Language-specific data is loaded
during installation. Based on the language associated with the user, screen labels, menus,
messages, and field help is displayed in the appropriate language.
Labels, menus, and messages are stored in the production database. Field help is in the field help
database, mfghelp.db.To retrieve data in multiple languages, each of these types of information
is stored once in each language.
Most orders include comments, which often must be in multiple languages. These can be stored in
multiple languages and retrieved by language ID. You can also customize menus and messages
and assign a language ID so the system knows which entry to display.
Standard programs support only a limited amount of data that is stored and displayed by language
ID. This data is defined in Language Detail Maintenance (36.4.2). However, component-based
functions provide extended translation features. You can provide your own language translations
for descriptions of shared data such as accounts, sub-accounts, and cost centers. For more
information on the Translation Option, see Introduction to QAD Enterprise Applications User
Guide.
You can also provide translations for custom labels assigned to component-based reports.
Multiple Languages and Unicode

.NET UI clients are fully Unicode compliant; a user logged in through the .NET UI can access any
domain, regardless of its defined code page.
Character clients do not support Unicode and must log in to a domain with a compatible code
page, as defined in Domain Create. This is to prevent the possibility of data corruption when
characters cannot be interpreted correctly. Once logged in through the character UI, users are
limited in which domains that they can switch to.
However, some domain switching can happen behind the scenes when processes such as
Distribution Requirements Planning (DRP) are being used. In a Unicode database, these processes
should be run from batch to prevent code page issues.
If your implementation includes a Unicode database and you have some users executing functions
from character clients, you should be aware of the following restrictions.
Creating Sites
When you create a site in one domain, connection records for that site are optionally created in
other domains in the database. This is to support cross-domain features such as Distributed
Requirements Planning (DRP).
If any of the domains in the database have incompatible code pages, creating site connection
records is not possible from the character UI. If you need to create these records, you must use Site
Maintenance (1.1.13) from the .NET UI.
Running Batch Jobs
If you routinely run batch jobs across multiple domains in a Unicode database, you should set up
scripts with the correct Unicode startup parameters to avoid code page issues. See Invoke Batch
Processing from CIM on page 90.
Running DRP and MRP
DRP is one of the areas where the system may need to change to a different domain based on the
sourcing relationships for items that you have set up. If you have set up relationships between sites
in domains that have incompatible code pages, this switching cannot be done when DRP is run
from a character client. This is true of stand-alone DRP using programs on 12.13, or running
Materials Requirements Planning (MRP) when the DRP/MRP Combined field is selected in DRP
Control (12.13.24).
If the system detects that the domains are incompatible, an error is generated and DRP will not
complete its execution.
To avoid errors, run DRP or MRP in batch mode with a Unicode database; for example, use the
following parameters with your Progress batch command to use the UTF-8 code page:
-cpinternal utf-8 -cpcstream utf-8
For details on setting up the batch job, see Invoke Batch Processing from CIM on page 90.

System Interface 39
Setting Up Multiple Languages

A base set of language codes is supplied with the system. System-defined languages cannot be
changed or deleted.
Use the Language Maintenance activities (36.4.1) to view all records, create new ones, modify
user-defined records, or delete user-defined records. For more information on language activities,
see QAD Financials User Guide.
To implement multiple languages in a database, you must:
1 Load the appropriate language data, either during initial system implementation or later.
Loading translated labels marks the language as installed so that it is available to be associated
with users.
2 Create countries for users in Country Create (36.1.3.1.1). Each country to be associated with a
user must have an ISO country code specified in the Alternate Code field in Country Code
Data Maintenance (2.14.1). Regional display defaults are determined by the ISO country, such
as date and number formats.
3 Designate the default language and country code for each user in User Maintenance (36.3.1).
This ensures that when the user logs on, the system displays data in that persons language
with the correct regional formatting. For more information on User Maintenance, see QAD
Security and Controls User Guide.
If the language is the same for all users but multiple language comments are required for orders,
you only need to define the separate language codes using the Language function. A number of
codes for supported languages are already defined.
Language Detail Maintenance

Some program options appear on the screen using alphabetic codes or words. Internally, these
options are controlled by numeric codes. Mnemonics and labels provided in English are not
always appropriate in other languages. Use Language Detail Maintenance (36.4.2) to change, add,
and delete mnemonic codes and labels.
Fig. 3.1
Language Detail Maintenance (36.4.2)
Data Set. Enter the program name, a database table name, or an abbreviation of the
functionality for a field.
Field. Enter the field name associated with the data set.
Numeric Codes. These are the values used by the programs. A mnemonic code can be
assigned for each numeric code. Codes cannot be added or edited.
Mnemonic. Mnemonic codes are already assigned for each field with several system-specified
options. These codes can be changed, added, or deleted using this program.
Label. Default labels already exist for the different mnemonic codes. These labels can be
changed, added, or deleted using this program.
Report Translation
The Report Translation activities (36.4.3) let you create, view, modify, and delete custom labels
used in component-based reporting functions.
Using these activities, you can modify the standard QAD translations or create new translations.
Labels are grouped by business component and, then, by report. The labels that are common to all
reports of a business component are stored with a blank report name. The labels that are specific to
one report reference the report name.
The report labels are stored in the database and are retrieved at run-time (report execution) in the
correct language and sent to the Crystal reports viewer. This viewer receives the report data and
labels from the application and formats them according to the layout in the .rpt file.
For standard QAD labels, the QAD Standard check box is selected and the Report Translation
Code cannot be changed.
If you want to add a new label to a component and make it available to all reports for that
component, ensure that the label is defined in the .rpt file with the correct Report Translation
Code.
Fig. 3.2
Report Translation Create (36.4.3)
Report Translation Code. Specify the Report Translation Code to use on reports and to which
the translation is linked.
Business Component. Specify the business component to which the report belongs.
Report Name. Specify the report to which the translation applies.
QAD Standard. Select to indicate if the translation is a standard QAD translation.
Text. Type the translated text.

System Interface 41
Customizing Menu Information

Menus are loaded as part of initial system implementation. Both standard Progress programs and
component-based functions are set up in the menu system.
A standard Progress program is generally accessed from the menu, although you can add links
from one program to another. See Creating Access to Other Programs on page 51 for details
on linking programs.
Activities associated with components can be selected from the menu; they can also be
accessed from a right-click menu in the component view; see Figure 3.3.
Fig. 3.3
Right-Click Menu in Component View
Executing Menu Items

From the .NET UI, you can execute standard programs and component activities in these ways:
Type enough of the menu number or menu label in the search box to uniquely identify the
program and press Enter.
For standard programs only, type the program name, such as mgmemt.p, in the Search box and
press Enter.
Double-click the menu item in the menu listing.
Choose a program or activity from the Go To menu from in an open program screen.
In the character UI, you can execute only standard programs and only in these ways:
Type the program name, such as mgmemt.p, or number, such as 36.4.4.1, at any menu prompt.
Note If you are currently on another branch of the menu tree (for example the 1.4 menu),
enter a period before the menu number (.36.4.4.1). Type a partial number from a submenu,
such as 4.4 while located at menu 36.
Press a function key that is assigned to this program or select the program from the User
Menu. See Defining User Menu and Function Keys on page 65 for details.
Menu Structure
The menu system controls what displays when a user logs in. It is designed like a product
structure, recorded as single-level relationships between a parent menu item and a child item. At
the top level in the character UI, the parent item is the Main Menu (Menu 0).
Note The menu groups represented by the folders in the .NET UI are referenced through the letter
A. For example A.1 is Sales, A.2 is Manufacturing and so on.
At lower levels, the parent item is a submenu such as the Call Management Menu (11.1) or an
executable function.
Menus are stored in a table indexed by language ID. Each user has a default language. When a user
logs on, the system determines the user language and displays menu text in that language.
As a user moves through menus and makes selections, the Execution File specified in Menu
System Maintenance controls the function or submenu that displays. Selecting 2. Addresses from
the Main Menu sets the Execution File to 2, telling the system to access Menu 2. Selecting 12 from
Menu 2 sets the Execution File to admgmt06.p, telling the system to run Company Address
Maintenance.
QAD applications are delivered with all offered menus and functions. You can remove menus for
programs that you do not use by either taking them off the menu or controlling them with menu
security.
Note It is easier to update your software releases if menus are not modified. Instead, use menu
security for functions you do not use. In the character UI, you can set up User Menus for
commonly used menus and functions. In the .NET UI, each user can use the Favorites feature to
define a personal menu subsystem of commonly used functions.
Menus and Security

Users can only see functions they have been given access to, based on their role membership.
Menu items are assigned to roles in Role Permissions Maintain (36.3.6.5). Each user is assigned to
one or more roles in Role Membership Maintain (36.3.6.6) in the context of specific domains and
entities.
When a user logs in, the system builds the menu for that user based on the login domain and entity
(workspace in the .NET UI) and the set of roles assigned to the user. The menus represent the
combination of all functions the user has access to in that domain and entity.
Note When logging in through the character UI, a user must have access to the primary entity of
the selected domain; in the .NET UI, the workspace represents any valid domain/entity
combination for which the user has been granted access.
When you add an item to the menu, access must be explicitly granted before anyone can see that
menu item and run the function, including yourself. You must use Role Permissions Maintain to
add the menu item to the appropriate roles.
Note Users cannot run any program that is not on the menu. If you want users to be able to run
custom programs or utilities from an application session, you must add the program to the menu
and give the appropriate user roles access to it.
For more information on roles, see QAD Security and Controls User Guide.

System Interface 43
Menu System Maintenance

Use Menu System Maintenance (36.4.4.1) to assign menu labels and execution files to menu
numbers.
In the QAD .NET UI, the interface to Menu System Maintenance has been enhanced to make it
easier to use. For more information on Menu System Maintenance, see QAD .NET UI
Administration Guide.
You can control the menu numbers and the names associated with programs in several ways.
Move menu items.
Change menu names.
Create shortcut names for menu items.
Note If you make these changes, they may be lost during software updates when menus are
reloaded.
Important Menus are cached in memory when you log in to the system. You must log out and log
in again to see any changes made with this program. In addition, if you add menu items, you must
grant access to them before anyone can see them. See the previous section on menus and security.
Fig. 3.4
Menu System Maintenance (36.4.4.1)
The Name field lets you call programs using keywords. For a program buried deep in the menu
structure, you can add a name and then execute the program by typing that name on any menu
command line.
Example Many of your users create sales orders. Enter SO in the Name field for 7.1.1. Users can
then type SO at the menu prompt or Search box and Sales Order Maintenance (7.1.1) displays.
The execution procedure can be:
A menu number such as 1.1
A Progress program such as sosomt.p
A component-based activity specified in the form of a uniform resource name (URN) such as
urn:cbf:BCreditor.Modify
A process map specified in the form of an URN such as
urn:pmap:IndustryProcessLevel1
A browse collection specified in the form of an URN such as urn:collection:fcb4af10-
e778-4db5-9461-766f5b7e2891
Setting Up Menu Substitutions

Use Menu Substitution Maintenance (36.4.4.7) to set up a link between two standard programs so
that when users select one from a menu, the other program displays. This is useful for substituting
custom versions of existing programs.
Menu substitution affects standard programs in the character UI in these ways:
Replaces browses with inquiry programs
Replaces standard programs with custom versions
Note This program applies to standard Progress programs in the character environment only; you
cannot use it with component-based functions and it does not affect the menu in the .NET UI. In
the .NET UI, standard programs and browses always display.
In the character interface, which program is invoked for a particular user depends on whether
menu substitution is enabled in the user record in User Maintenance (36.3.1).
Fig. 3.5
Menu Substitution Maintenance (36.4.4.7)
1 Enter the program name in Execution File. Users selecting this program from a menu will
actually be running the one entered into the New Execution File field.
2 Enter the substitute program name in New Execution File. This is the name of the program to
replace the one entered in Execution File. Users will run this program when they select the one
entered in the Execution File field. You can use wildcards. For example, if you want to replace
all inquiry programs with the browse versions, you enter *iq* in the Execution File field and
*br* here.
3 Enter a label term in Selection Label Term. The long label contained in this term appears in the
title bar and menu list of the substituted program.
Defining Program Information

The program information table contains a record for each standard menu-level program, defining
characteristics that affect the way it runs. Each standard program in the .NET UI must have a
record both in Menu System Maintenance and in Program Information Maintenance (36.3.21.1).
Note Component activities are defined in Menu System Maintenance, but not in Program
Information Maintenance.
In addition to menu-level programs, lookups must be defined in order for the lookup icon to
display next to a field in an HTML screen.

System Interface 45
Program information records are loaded with other default data during system installation and can
be viewed in Program Information Maintenance or Program Information Browse (36.4.4.14). You
must manually create records for any custom programs that you want users to be able to access as
HTML programs from the .NET UI. Otherwise, they will open in Terminal mode.
Note Terminal mode lets you run programs with a character-mode UI, using a telnet session. The
system must be configured to support telnet sessions for the program to display. See Setting User
Telnet Options on page 67 for details on defining telnet settings.
The following table lists the default settings for different program types.
Table 3.2
Default Display Settings in .NET UI
Web Logic
Program Type Implemented Type
Browses, lookups Selected Blank
Special HTML programs such as Browse Selected Blank
Maintenance and Kanban workbenches
HTML reports and inquiries Clear Desktop
HTML maintenance programs Clear Desktop
Terminal-mode utilities Clear Blank
The Multi Domain field indicates a standard program that updates data that applies to all domains
in a database. When this is selected:
In the .NET UI, the string All Domains displays in the Menu Properties window for the
associated menu program. Otherwise, the domain name displays.
In the character UI, the string All Domains displays in the menu title bar when Header Display
Mode is set to 2 or 3 in Security Control (36.3.24).
Appropriate default settings for the Multi Domain field are set during installation. For example,
generalized codes apply to each domain separately so Multi Domain is not selected by default for
mgcodemt.p. Country code data applies to the database as a whole so Multi Domain is selected
by default for adctrymt.p.
Important You can update the setting for your custom programs or change it if you want the
current working domain to continue to display even when a user is updating a table that applies
across domains. This change affects what displays on the UI only. The program continues to
update data for all domains.
Adding Records
To execute a program with an HTML display from the .NET UI menus, add a record to Program
Information Maintenance for each custom program. When a record does not exist for a program,
the system assumes that it should run in Terminal mode.
See page 46 for details.
If you want to create records for a number of programs at once, use Program Information Update
(36.4.4.15) to scan them and automatically create records.
Fig. 3.6
Program Information Maintenance (36.4.4.13)
To create program information records:

1 Enter a custom program name.
2 Indicate if this program updates data for all domains in the database.
3 Click Next to continue.
4 Select the Web Logic Implemented check box if this is a browse written according to QAD
standards. Clear the Web Logic Implemented check box if this is a maintenance program,
report, or inquiry that you want to display in HTML.
5 Leave the Type field blank for a browse. Specify Desktop for an HTML maintenance program,
report, or inquiry.
Program Information Update
Use Program Information Update to automatically add records for custom programs to Program
Information Maintenance. Use this utility as an alternative to adding records manually. It is
especially useful for initially populating records with referenced tables.
Fig. 3.7
Program Information Update (36.4.4.14)
Viewing Business Components

Use Business Component View to view a list of the business components in the system. Not all
business components are represented by activities in the system, so this gives you a complete view
as well as displaying the technical name of the component. This might be needed in
troubleshooting as well as developing API calls to the component.

System Interface 47
Fig. 3.8
Business Component View (36.4.4.22)
Modifying Messages
The system has three kinds of messages:
Validation messages stored in the data dictionary. These display when the contents of the field
do not match its specifications.
Application messages for standard Progress programs stored in the database.
Application messages for component-based programs stored in external resource files.
Note Numbered Progress error messages sometimes display when a Progress instruction fails.
Most of these messages are handled by the system, and a system message is substituted, so this
should occur rarely.
You can modify standard messages in Message Maintenance (36.4.6.1). One reason for changing
messages is multiple language requirements. If a message seems unclear to some end users, an
administrator can clarify its meaning. You can also add your own messages for custom code.
Fig. 3.9
Message Maintenance (36.4.6.1)
Changing messages can create the same version control problems that occur when menus are
changed. Be careful to use message numbers not likely to be used in a later product version.
Messages in the ranges 90009999 and 9000099999 are reserved for customer use.
Creating and Managing Browses

You can use system features to define browses that display selected data in the form of a table. For
more information on browse features, see QAD .NET UI Administration Guide.
Component-based functions have browses that support extended configuration features. For more
information on component-based browses, see Introduction to QAD Enterprise Applications User
Guide.
Standard browses can display data from one table or from several tables joined into a specific view
of the data. Use the functions on the Browse Menu (36.4.8) to manage browses:
Use Drill-Down/Lookup Maintenance (36.4.8.1) to attach browses to program fields.
Use User Tool Maintenance (36.4.8.5) to create links from one program to another.
Use Stored Search Maintenance (36.4.8.7) to manage default browse information for
component-based views.
Use Browse URL Maintenance (36.4.8.9) to create links to other resources that can be
accessed from a browse.
Use Browse Maintenance (36.4.8.13) to create your own browses or modify system supplied
browses.
Use View Maintenance (36.4.8.18) to join information from more than one table to be used in
a custom browse.
Maintaining Drill Downs and Lookups

Two types of browses are available in standard Progress programs:
Lookup browses return the value you select to the active field in the calling program.
Drill-down browses are more complex. They include more information and can display, filter,
graph, or print data.
The field values in the browse can come from a table or a view. A view is a table that has selected
values from one table or several joined tables.
Use Drill-Down/Lookup Maintenance (36.4.8.1) to assign drill-downs or lookups to fields that do
not have a browse, to replace a browse, or to delete one.
See Adding a Lookup on page 12.
One of the most common uses of this program is to display generalized codes associated with a
field. You can also assign lookups to any field that acts as an index to a maintenance screen. You
may, however, need to write your own custom browse to find and display the data.
Most programs attached to a function with Drill-Down/Lookup Maintenance display values in a
database table. But this is simply a convention. You can attach any Progress function to a field, and
this program executes when the user selects Help. For example, you can attach the program
calculat.p to field pt_avg_int to display a calculator.
Before you can use Drill-Down/Lookup Maintenance, you need to know:

The name of the field where you want the browse to display.
The name of the program using the field.

System Interface 49
The program name of the browse to attach. If a lookup is missing for a particular field but
exists for a similar one, use Lookup Browse (36.4.8.3) to determine the program that displays
appropriate field values. Then use Drill-Down/Lookup Maintenance to specify the same
program for the similar field. See Creating Browses on page 58 for details on creating
browses.
Determining the name of the program and field depends on the user interface.
In the character interface, run the program. Note the program name in the upper left corner of
the screen. Then place your cursor in the field where you want to attach the browse. Press
Ctrl+F and note the field name.
In the QAD .NET UI, find the program in the Application menu area, right-click on the
program name, and select Properties. A screen displays program information, including the
program name. To identify the field name, place your cursor over the field where you want to
attach the browse on the program screen. The field name displays.
Fig. 3.10
Drill-Down/Lookup Maintenance (36.4.8.1)
You can assign more than one drill-down to the same field. A menu of drill-downs appears when
you request the drill-down. Only one lookup can be attached to a given combination of field and
program name.
You can attach browses to fields in any program, including another browse. Drill-downs can be
nested. A field can call a browse that can call another browse that can call another browse, and so
on.
Follow these steps to use Drill-Down/Lookup Maintenance to associate a drill-down with a field or
program:
1 Select Drill Down in the Drill Down/Lookup field.
2 Enter a field name to associate with the browse in Field Name. Leave it blank to associate it
with all fields.
3 Enter the program containing the field in Calling Procedure. Leave it blank to attach the
browse to all programs using the specified field.
4 Enter the browse name in Procedure to Execute.
5 Optionally, enter a label term in Description Term. The long label contained in this term is
displayed as the title in the browse. The default is the browse description term defined in
Browse Maintenance. See Creating Browses on page 58.
You access drill-downs differently in the two UIs:

In the character UI, Select Drill Down from the Help menu or use Alt-Tab.
In the .NET UI, click the underlined link that indicates a drill-down. When more than one
drill-down is associated with a field, right-click to see a menu listing drill-down options or
URLs.
Follow these steps to associate a lookup with a field:
1 Select Lookup in the Drill Down/Lookup field.
2 Enter a field name to associate with the browse in Field Name.
3 Enter the program containing the field in Calling Procedure. Leave it blank to attach the
browse to all programs using the specified field.
4 Enter the browse name in Procedure to Execute.
5 Optionally, enter a description for the lookup. This description is for reference only and is not
displayed in the lookup.
6 Enter the starting row and the number of lines to display in the lookup.
Wildcards in Drill-Down/Lookup Maintenance
Use wildcards to attach browses to fields in multiple programs. For example, pp*.p attaches the
drill down to the specified field in all programs starting with pp and ending with a .p extension.
The table displays the possible entries to Drill-Down/Lookup Maintenance:
Field ad_addr ad_addr ad_addr
Calling Procedure * so* soivmt.p
Procedure to Execute adbrad.p adbrcs.p arbrbl.p
When you drill down on ad_addr in soivmt.p, a menu shows all three browses: adbrad.p,
adbrcs.p, arbrbl.p. When you drill down on ad_addr in a program other than soivmt.p but
beginning with the letters so, a menu shows two browses: adbrad.p and adbrcs.p. When you
drill down on ad_addr anywhere else, the browse adbrad.p opens.
Fig. 3.11
Wildcards in Drill- Down/Lookup Maintenance
Drilling Down on Drill-Downs
You can nest drill-downs. In other words, one drill-down can call another, which can call another,
and so on. After creating the first drill-down, you can assign the others to the same field. Enter the
name of the first drill-down as the calling procedure for the nested drill-down.

System Interface 51
Fig. 3.12
Nested Drill Downs
First
drill
down
Nested (subsequent) drill down Enter the name of the first drill down as the
calling procedure for the nested drill down.
Planning for Upgrades
When you update your product version, be careful when loading flh_mstr. This table contains the
records created by Drill-Down/Lookup Maintenance. If you have customized it, make sure that the
new version does not overwrite your customization.
Creating Access to Other Programs

User Tool Maintenance (36.4.8.5) lets you specify programs that can be run from other programs
in the .NET User Interface. This makes it easier for you to run frequently used programs.
Note The relationships you define in User Tool Maintenance do not apply to any programs in the
character interface and they do not apply to browses.
Use the Add Link command on the Go To menu from any HTML program in the .NET UI to
access User Tool Maintenance. The links you define also display under the Go To menu. When
you click a link, the linked program opens in a new tab.
Note You can also add links by accessing User Tool Maintenance directly from the menu. When
you access it from a program in the .NET UI, the User ID and Program fields are filled in already.
User Tool Maintenance
Figure 3.13 illustrates the User Tool Maintenance screen.

Fig. 3.13
User Tool Maintenance (36.4.8.5)
1 Enter a user ID or leave the field blank to assign the link to all users.
2 Enter the name of the program where you want the link to display. Leave Program blank to add
the link to all programs that do not already have a user-specific record. Click Next to continue.
Note You can also use wildcards to specify where the links appear. Specifying pp* places the
links in all programs beginning with pp.
3 In the Exec fields, enter the program names (for example, adbr001) for the links to launch.
4 In the Label field, specify a text string to appear in the link area. If you leave this field blank,
the standard menu description from Menu System Maintenance is used.
5 Leave the Image field blank. Images do not apply in the .NET UI.
Displaying Links
You can assign programs to all users (blank user ID) or a specific user. You can also assign
programs to a specific program or using wildcards. However, only one set of records displays
when a user accesses a program. The system searches for the appropriate links to display in this
order:
1 Specific user ID and specific program name
2 Specific user ID and program name with wildcards
3 Blank user ID and specific program name
4 Blank user ID and program name with wildcards

System Interface 53
Managing Stored Searches

Use the Stored Search activities (36.4.8.7) to manage stored searches created by users from various
component-based browses Each user can create stored searches so that they can quickly find
records they want to view or update. Depending on the users access, searches can be saved at
three levels:
For the individual user
For all users assigned to a role
For all users in the system
For more information on stored searches, see Introduction to QAD Enterprise Applications User
Guide.
From the system administrative point of view, you can use the maintenance functions to:
View stored search records that have been created by users.
Delete stored search results. This might be necessary if a user leaves the company or a role is
made obsolete.
Note Exporting stored search values is not currently implemented.
The system loads search and browse defaults during installation. Factory defaults display as a type
of stored search, along with the last used customized settings. Use Export Browse Defaults to
export default search and display settings into a FactoryDefaults.xml file. The system saves
the file in the same folder that contains other QAD financial business logic.
Defining Browse URL Links

Use Browse URL Maintenance (36.4.8.9) to create URL links that users can activate from .NET
browses. When a browse cell contains a URL link, double-clicking it launches a new browser
window and displays the intranet or Internet resource associated with the URL. You can use these
URLs in two ways:
Create links to external Web sites that users can activate from .NET browses, such as a
supplier Web site associated with a supplier ID.
Create links to other programs and pass specific data values to the programs. This lets you use
browses as a means of navigating directly to maintenance programs.
You can access links to other programs only from drill-down browses, not lookups. Drill-down
browses are typically available directly on the menu, but can also be associated with program
fields in Drill-Down/Lookup Maintenance (36.4.8.1). See Maintaining Drill Downs and
Lookups on page 48.
Defining URLs to External Web Pages
Use Browse URL Maintenance to create links to external URLs with information that is related to
items in the browse, as in the following example.
Example You want to establish a URL link in the Purchase Order Browse from supplier ID
GS10100 to the corresponding suppliers company Web site, located at
http://www.generalsupplies.com. To do this, enter the values in listed here in Browse URL
Maintenance.
Table 3.3
Sample Field Entries for Browse URL Links
Field Name Value
Browse pobr006.p
User ID *
Field Name so_vend
Value gs10100
URL http://www.generalsupplies.com
Description General Supplies Web Site
Primary Selected
URLs can contain special strings that are automatically replaced by field values in the browse.
Selecting a link containing this type of string automatically replaces that string with the
corresponding field value in the row.
Follow these steps to define this type of special string in a URL:
1 Enter #b# to indicate the beginning of the string.
2 After the #b#, enter a field name associated with the specified browse.
3 Enter #e# to indicate the end of the string.
Example The Web site for one of your primary suppliers contains a catalog of items. Entering an
items identifier at this Web site accesses the catalog entry for that item, containing information
such as item cost, quantity available, and ship weight. To create links from the internal supplier
item numbers to their corresponding catalog entries at the suppliers Web site, create the following
URL:
http://www.generalsupplies.com/catalog/#b#vp_vend_part#e#
Then, associate it with the Supplier Item column in the Supplier Item Browse. After you establish
this link, selecting a supplier item number in the Supplier Item Browse automatically inserts the
selected field value.
For example, selecting supplier item 10-1005 creates this URL:
http://www.generalsupplies.com/10-1005
The system then launches a Web browser to display the relevant catalog information for that item
located at that URL address.
Adding Another URL for the Same Browse
After you create a browse URL, you can use Browse URL Maintenance to create subsequent URL
records for the same browse.
1 In the Browse field, choose the browse to which you want to add another URL.
2 Click Next twice.
3 Clear the URL field.
Important To trigger the creation of a new record, you must start with an empty URL field.

System Interface 55
4 You can enter the new URL manually or use the HTTP Parameters pop-up. See HTTP
Parameters Pop-Up on page 57.
To enter the URL manually, specify the new URL in the cleared URL field.
To build the URL using the HTTP Parameters pop-up, leave the URL field blank.
5 Click Next to display the HTTP Parameters pop-up.
6 In the pop-up, enter the values required to build the URL.
The system builds the URL, including the run_html setting, using the values you supply.
If you have already entered the URL manually, the pop-up displays the constituent values for
the URL.
7 When you have completed your updates, click Next.
The system displays a Modify Existing Record prompt.
8 Choose the relevant action:
Click No to create a new browse record.
Click Yes to update the current record.
Defining Links to Other Programs
Use Browse URL Maintenance to create links to other system programs, as in the following
example.
You can set up links in an item browse to directly access Item Master Maintenance (1.4.1), passing
the current item number to the maintenance program, and executing the Next command any
number of times. When a user clicks the link, Item Master Maintenance displays in a separate tab.
Multiple columns of data in a browse can contain links so that you can access maintenance
programs for any data related to a record. However, data for only one field can be passed to each
program.
To support this kind of URL link, use the run_html setting to indicate that you want to build a URL
for system programs. The string must include the beginning and ending indicators required for
other strings in URLs:
1 Enter #b# to indicate the beginning of the string.
2 Enter #e# to indicate the end of the string.
Then specify values that determine:
The name of the program to be executed when a user clicks the link
The field in the designated program to which you want to supply a value
The value to be passed to the specified field
The number of times the Next command should be executed in order to reach the field
To make it easy to build the URL, leave the URL and URL Script fields blank and click Next to
display a pop-up that prompts you for the values required to build the URL. In this case, the
system builds the URL including the run_html setting using the values you supply.
Table 3.4
Sample Field Entries for Browse Program Links
Field Name Value
Browse sobr009.p
User ID *
Field Name sod_part
Value *
URL Leave Blank
Description Link to Item Master Maint.
Program Name ppptmt
Field pt_part
Value sod_part
Index 2
The URL that the system builds based on these input values looks like the following example:
#b#run_html#e#?id=ppptmt.p&f=pt_part&v=#b#sod_part#e#&x=2
When the user clicks item 01053 in the sobr009.p browse, Item Master Maintenance displays
with 01053 entered in the Item Number field and the active cursor focus is in the Name field below
it.
Using Browse URL Maintenance
The following figure illustrates Browse URL Maintenance.

Fig. 3.14
Browse URL Maintenance (36.4.8.9)
Use the following field descriptions to configure Browse URL Maintenance settings for your
environment:
Browse. Enter the name of the browse program to contain the specified URL link.
Entering an asterisk (*) in this field allows the specified URL to be associated with any browse
in the system.

System Interface 57
Example To associate a specific URL with the sales order number column in all .NET
browses, enter an asterisk in this field and specify the sales order columns corresponding field
name (so_nbr) in Field.
User ID. Enter a user ID to associate with the specified URL link. To associate all users in the
system with that link, enter an asterisk (*) in this field.
Field Name. Designate the browse column in which you want to establish a URL link by
entering the database field name associated with that column. The lookup associated with this
field displays fields from the previously entered browse.
This field cannot be left blank.
Value. Specifying a value in this field associates the designated URL with every browse cell
that contains that value and belongs to the browse column indicated in Field Name. Enter an
asterisk (*) to associate the URL with every cell in the column.
Description. Optionally enter a description to display when this URL is selected.
Primary. Select to indicate that the specified URL is the primary URL for a cell.
When you right-click a browse cell containing multiple URLs, a list displays for selection. The
primary link displays at the top of the list in bold font and is the default link for the cell.
Note The value of Primary has effect only if no drill-downs are also associated with the cell.
Drill-downs always take precedence over URLs and are listed first when you right-click.
This value applies to defined (non-scripted) URLs only.
URL. Specify a URL referring to an Internet or intranet location (maximum 132 characters).
Leave blank to create a link to another program.
URL Script. To associate the specified user, browse, column, field value, or combination of
these with a custom URL script, enter the full path to the directory containing the custom
script. You cannot specify both a URL and a URL script. Scripts should be based on the
supplied template urltempl.p, located in the source code directory, /src/urltempl.p.
Determine. Select this check box to have the system run the specified custom URL script upon
selection of the associated cell or column to determine whether that cell or column has an
associated URL.
When this field is clear, the script is not run and the designated column or cell is defaulted to
having a URL.
HTTP Parameters Pop-Up
This pop-up displays when both URL and URL Script are blank and lets you specify a set of
values used to access another program.
Fig. 3.15
Browse URL Maintenance, HTTP Parameters
Program Name. Enter the name of the program to launch when a user clicks this link. You can
include or omit the .p extension. For example, specify adcsmt or adcsmt.p.
Field. Enter the field in the program that you want to pass a value to from the browse; for
example, enter cm_addr to pass a value to the Customer Address field in Customer
Maintenance. Only one field can be specified.
Value. Enter the field in the browse that contains the value that you want to pass to the named
field. Use the beginning and ending delimiters for this value. For example, to pass the value of
the sod_part field in the Sales Order Browse (7.1.2) to the pt_part field in Item Master
Maintenance, enter #b#sod_part#e#.
Index. Enter the number of times you want the system to execute a Next command when it
invokes the program specified for Program Name. To access the first frame in a maintenance
program, set this value to 1. If you set this to more than 1, all validations are executed before
processing the Next command. If appropriate values do not exist for all required fields, an
error is generated when you click the link.
Creating Browses
Use Browse Maintenance (36.4.8.13) to create custom browses or modify system-supplied
browses.
When you create a browse, it is saved in your working directory as a source-code file. The source-
code name is the first two characters of the name you entered, then the letters br or lu (depending
on whether you selected power or look up), then any remaining numbers from the name you
specified, then the extension .p.
Example You create a power browse and name it ap010; the system names the code
apbr010.p. If you selected both power and lookup browses, the system generates two source-
code files: apbr010.p and aplu010.p.
Although you do not need to compile the source code of the browse, you should for better
performance. If other users on your network want to use your browse, you must compile it and
move it to the network directory. Use the Progress editor to compile the browse.
Note You can access the Progress editor only if your PROPATH is correctly set up to access
source files.

System Interface 59
Browse Maintenance has some special features that are not available in the character UI and that
are not like other HTML programs. This section illustrates the program in the .NET UI.
Fig. 3.16
Browse Maintenance (36.4.8.13)
To create or modify a browse:

1 Select or enter a name for the browse. To name the browse, enter two letters and click Next.
Use the existing QAD module mnemonics or make up your own. The system gives the browse
a name that increments by one the number in the file name of the last browse created.
2 Click Next or click the second tab, Browse Data, to continue.
Fig. 3.17
Browse Maintenance, Browse Data
3 Enter a label term in Description Term. The long label contained in this term is displayed as
the title in the browse window.
4 Indicate whether this is a power browse, lookup browse, or both.
5 In View, enter the name of an existing view or a primary table whose data the browse displays.
You can see only those views you have access to. If a view exists for a table and the view name
is the same as the table name, you have access to only those fields that are available in the
view. See Creating Views on page 62.
Note The view name you enter in View must already be defined in View Maintenance, or you
must enter a primary table name.
6 In the Filter field, type the selection criteria (optional) to limit the browses search to records
that meet a certain condition. Do not put a period (.) at the end of the criteria, because the
system adds a no-lock no-error statement to the criteria.
The Preview function, accessed with a button in the character user interface, is accessed by
clicking one of the Test links next to the Lookup Browse and Power Browse check boxes. This
displays the currently edited browse in a new tab. For existing browses, you can preview the
browse before changing it.
Use the Field Select tab to select fields to be included in the browse and specify the display order.
Fig. 3.18
Browse Maintenance, Field Select
7 Fields from the view or primary table entered in the Browse Data frame display in Available
Fields. Include up to 20 fields in your new browse.
In the .NET UI, move fields from one list to another by clicking the field to select it and
clicking the arrow that indicates the appropriate direction. Multiple fields can be selected
by holding down the Shift key and clicking. Use the Move Up and Move Down buttons to
arrange the fields in the Selected Fields list.
In character mode, select a field to include in your browse by using the Up and Down keys
to locate it and then press Enter. Multiple fields can be selected. Use the Tab key to choose
the Add, Field Help, or Done buttons or to navigate between the Available Fields list and
the Selected Fields list.
8 In the .NET UI, to specify sort columnsfor look-up browses onlyselect one or more fields
in the Selected column and click the right arrow to move them to the Sort Order column. You
can use the up and down arrows to reorder the fields in the Sort Order list. The look-up browse
sorts the records on the first column you enter in the Sort Order field.
In the character UI, use the Sort Columns field to enter the columns you want to have available
for sorting. Enter the columns as a comma-delimited list of up to seven numbers. The first
field name in the Selected Fields list is column 1, the second is column 2, and so on.
9 When you have arranged the fields in the order you want, click Next to display the Details tab.

System Interface 61
Fig. 3.19
Browse Maintenance, Details
10 Enter the column number to take the field values from in Value-Returned Column (optional).
The default is the first column of the browse.
11 To view the details related to a specific field, select it from the drop-down list in the Detail
field.
12 If needed, you can change the default field label and format. To control the display length of a
label, enter a Max Length value. Click Back if you want to view or modify data for other
fields. Otherwise, click Next to display the browse history.
Fig. 3.20
Browse Maintenance, History
13 The program automatically creates a revision history line containing a revision number, the
user name (or logon ID), and current date. You can modify this as needed. The revision history
is also saved in the source code.
Note The Procedure field offers other choices; only History is currently implemented.
14 Click Next to generate the browse.
Creating Views
A view is a display of some or all of the fields from one or more tables. You join two or more
tables for a view by specifying the relationships between fields in different tables and choosing the
type of join to use.
Views are used in browses, which display the fields gathered using views. By choosing which
fields to include or exclude in a view, you control which fields are available for a browse to
display. By putting security on the view, you can allow users to modify browses, knowing that they
can access only those fields that you have authorized.
Use View Maintenance (36.4.8.18) to create or modify views.
Using Progress Syntax
You use some Progress syntax in creating or modifying views. You must also understand database
table and field relationships.
To create or modify a view:
1 Select the table or tables to include in the view.
2 For sequences after the first, specify the type of join to use: inner or outer.
3 Join the tables using Progress logic.
4 Select fields from the tables.
5 Save the view.
Figure 3.21 illustrates how to create a view of selected fields from one table.
Fig. 3.21
Creating a View from One Table
Fields to Display in View (Phone List View)
Emp ID Emp Name Dept Phone Start Date
(Table emp_mstr)
Figure 3.22 illustrates how to create a view of selected fields from two tables.

System Interface 63
Fig. 3.22
Creating a View by Joining Two Tables
Fields to Display in View
(Department Capacity
per Employee View)
Dept Emp ID Labor Emp ID Dept Phone Start Date

Capacity
(Table dpt_mstr) (Table emp_mstr)

Indexed Join
Using Join Types
When a view includes data from more than one table, you can choose from two types of joins
when creating a view:
An inner join returns the records selected for the first table combined with related records
selected from the second table. If a record does not exist in the second table, no records are
returned. Only related records selected from both sides of the relationship display in the view.
An outer join returns the records found by an inner join. However, in addition, for each value
in the first table, it returns unknown values from the second table when no related record is
found. As a result, all matching records from the first table are preserved for unmatched
records in the second table.
The default join type is inner. Using the outer join can give you more flexibility in displaying
information.
Example An inner join between customers and sales orders displays only customers with sales
orders. An outer join includes all customers, even those who do not have orders.
Using View Maintenance
Figure 3.23 illustrates View Maintenance (36.4.8.18).

Fig. 3.23
View Maintenance (36.4.8.18)
1 Select or enter a view name.

2 Enter a label term in Description Term. The long label contained in this term is displayed as
the view label.
3 In User IDs/Roles, enter one or more user IDs or roles to limit user access to the view
(optional). Enter multiple user IDs or roles by separating them with commas.
4 Click Next to continue.
Fig. 3.24
View Maintenance, Table Selection
5 The number you enter in Sequence controls the order in which the table defined in Table is
joined to the view.
6 Enter a table name.
7 If the sequence is not 1, specify the type of join, either inner or outer. The Join Type field is
only enabled when the sequence number is greater than 1.
8 Enter or edit the phrase to join the tables. Use proper Progress syntax. Do not include a Where
verb. Join phrases express the field relationships between tables (see Figure 3.22). For a faster
display of fields, use indexed fields in the Join Phrase.
9 Click Back.
Fig. 3.25
View Maintenance, View Field Data
10 In Field Name, enter a field from one of the tables in the view or enter a local variable. When
entering a local variable, name it local-varnn, where nn is a number incremented by one
from the last defined variable.

System Interface 65
For example, you see from the lookup browse that the last local variable was local-var05;
you name your local variable local-var06. Use local variables when you want to return a
value resulting from an operation on two fields; for example, the quantity required minus the
quantity open. Define the operation in Expression.
11 If you entered a local variable in Field Name, enter its Label Term, Format, and Data Type.
Note Search for a label term by entering a portion of a label, then use Next/Previous to
display available records.
12 If Field Name is a local variable, you can enter Progress syntax in Expression to define the
local variable. Valid expressions include:
field1 + field2 (computation, where field1 and field2 are fields within the
record)
>, <, >= (operands that perform comparisons)
Progress functions, such as substring (field1,1,4) or round (field1,1)
Note Incorrect syntax terminates your session if you attempt to use the view.
Defining User Menu and Function Keys

User menu and function keys are available in the character UI. In the .NET UI, users set up
personalized menus with the Favorites functionality.
Assigning function keys to frequently used menu items is another way to execute programs
quickly in the character user interface. Keys can be established for all users or individually
customized. Up to 999 function keys can be defined. In addition, you can change the standard label
for a menu item to customize menu labels for each user.
Note Function keys apply only to the character interface.
Example A user entering a sales order may need to check on the available-to-promise (ATP)
quantities for an item before indicating a due date. By setting up a function key for the Master
Schedule Summary Inquiry (22.18), the order clerk can review an items ATP quantity without
leaving Sales Order Maintenance (7.1.1).
Note Do not use function keys or the function menu to access a maintenance screen in the
character environment. Progress only completes transactions initiated with function keys after the
initial transaction is completed. If, for example, you are in sales orders, you start an order, then
perform an inventory transaction using a function key, and then cancel the sales order, the
inventory transaction is also canceled.
Access programs associated with a function key by selecting that function key. Function keys F1
through F12 are reserved for system use, so the assigned key must be F13 or higher. Since many
keyboards do not handle that number of function keys, this option is used less frequently.
User Menu
Access the User Menu by pressing F6. A list of menu items set up for your user ID appears.
Choose the one you want by highlighting it and pressing Enter or F1. Press Tab to sort the list by
menu number or function name. Press F4 to display the user menu items defined without a user ID.
Note There is no relationship between the order of items on the User Menu and the function key
assigned, and the function key is not shown. Menus sort lexically, so that 13 appears before 2 if
you are in the Menu Selection column.
Different environments have different function key uses and limitations. Set up your system
according to your environment. For example, if your system is limited to only 12 function keys, do
not attempt to use the function keys as a quick method to launch programs. Instead, use the User
Menu.
Executing Programs in Sequence

In the character interface, you can make several programs execute in sequence by assigning them
to the same function key and giving each a different sequence number. When you press that
function key, the first function in the sequence executes. When that function is finished, the next
one in sequence is called automatically.
Important All transactions in the sequence must be completed before data is updated in the
database.
User Function Maintenance

Set up user menus and function keys in User Function Maintenance. Each selection on the user
menu should have a different function key reference, from 13 to 40, and a zero or blank sequence
number. The function key reference must be 13 or greater, even if your keyboard supports fewer
function keys or you plan to access selections through the User Menu.
Note To set up function keys, terminals must be compatible with the Progress protermcap file.
Using Field and Program Help

The system provides two types of online help: program (also called procedure) and field help.
Program help explains what the current function or program you are working within does. Field
help describes particular fields.
You can view these help records in either HTML or character format. The content of the HTML
and character help files is identical. You can add your own information to the help; it displays
under a heading of User Help in both character and .NET UI.
Note QAD .NET UI displays the character help data in an HTML format. Any changes you make
to character help are also visible in the QAD .NET UI.
In the QAD .NET UI, view field and program help by pressing F1. In the character interface, view
field help by pressing F2 with the cursor in the field. Press F2 a second time and program help
displays. No keyword searches or hypertext links are available in character help.

System Interface 67
Adding User Help

Use Field Help Maintenance (36.4 13.1) to add to the character-format help delivered with your
system.
Fig. 3.26
Field Help Maintenance (36.4.13.1)
Custom text entered in Field Help Maintenance appears at the top of the help record.
Printing Help
You can print out portions of the field and program help to supplement your user guide set. Printed
field help is available through Field Help Report (36.4.13.2). The Procedure Help Report
(36.4.13.4) prints program help in alphanumeric ranges by program name.
The Field Help Book Report (36.4.13.3) enables you to print a book containing all field help.
Choose units as small as one field and as large as an entire module.
Local Vars. Clear this option to exclude local variables. These are field names created within a
program, not drawn from the data dictionary. In reports, the From and To fields are often local
variables. Usually, help for local variables is not as significant as database fields.
Update Only. Select this option to limit output to fields that can be changed.
Where-Used, Maximum. Disable the Where-Used option to keep the system from printing a
where-used list after each help item. Some database fields are used throughout the database,
and a complete where-used list can be very long. If selected, limit the length of the where-used
list by entering a value in Maximum.
Setting User Telnet Options

As part of system installation, telnet setup scripts are configured for use by the Connection
Manager for managing HTML programs running under the .NET UI. Create additional telnet
scripts for running terminal sessions within the QAD .NET UI with User Option Telnet
The QAD .NET UI also reads other settings in this program, including the port value defined in
this program to determine which port to use to connect to the server for terminal programs.
Configuring the settings in User Option Telnet Maintenance consists of the following tasks:
Specifying telnet server settings
Defining the login sequence
Configuring the telnet connection settings
Verifying the script login sequence
Configuring Telnet Server Settings

Figure 3.27 depicts the User Option Telnet Maintenance (36.4.14).
Fig. 3.27
User Option Telnet Maintenance, Telnet Options (36.4.1.4)
Use the following instructions to configure telnet server settings:

1 In User Option Telnet Maintenance, create a record that applies to all users by entering an
asterisk (*) in the User ID field; then click Next.
2 Enter values in the following fields
Host. Enter the fully qualified machine name or IP address of the telnet server. The script uses
this information to establish the telnet connection.
Host O/S. Enter UNIX for UNIX systems. Enter NT for Windows systems.
Port. Enter the port number for the telnet server. The default value is 23. This is the value you
would normally use, unless you are using SSH under the .NET UI. In this case, the port value
is 22.
Image. Leave this field blank; it is not currently used.
Script Timeout. Enter the number of seconds (1999) the system waits for the telnet login
script to execute. If this value is exceeded, a time-out message displays and the session closes.
Idle Timeout. Enter the number of seconds (1999) the system waits after a telnet session
begins for a program to execute.
Note Idle timeout is not used in the QAD .NET UI.
Define the Login Sequence Script Lines

For users to be able to log in to and begin a telnet session on the telnet server, you must provide the
sequence of telnet server login prompts and responses. The last value in the sequence specifies the
script you created during system installation.

System Interface 69
Terminal mode supports either operating-system level or script user credentials based on the
setting of TerminalAuthentication in qaduiConfig.xml, located in:
TomcatInstallDir/webapps/qadhome/client/configs
When this is set to ShellUser (the default), the user ID and password used to login to the .NET
UI are used for the terminal login, regardless of what is set in this program.
When this is set to ScriptUser, the user ID and password defined in User Option Telnet
Maintenance is used.
When defining paths for scripts used in the .NET UI, avoid using relative paths since each users
access may be different.
Fig. 3.28
User Option Telnet Maintenance, Login Script Line
1 Specify the telnet login sequence number in the Script Lines frame. For each telnet command,
enter a sequence number beginning with 1, and click Next. In the next frame, enter the
following:
Script Pattern. Enter the prompt generated by the telnet server when a telnet login occurs. The
values in this field must be identical to the prompts the telnet server displays when users log
in.
Script Value. Enter the response to the telnet login prompt defined in Script Pattern.
Script Status. Optionally enter a description of the prompt and response; for example, Logging
In.
If you have tracing enabled and the Java console is displayed, the description in the Script
Status field displays in the Java console on the client when an error occurs during the
execution of the prompt and response. You can use these descriptions as an aid in
troubleshooting telnet session issues.
Note Script sequence 2 has special validation for suppressing password display. When you
enter a password as a script value, only blanks display. When you click Next at the end of the
sequence, you are asked to confirm the password.
2 Click Next after entering the sequence values. You return to the Sequence field to enter the
next sequence number and values.
Fig. 3.29
User Option Telnet Maintenance, Second Login Script Line
3 After entering the final sequence, click Next to return to the Sequence field. Then click Back
to move to the Telnet Connections fields.
Configure Telnet Connection Settings

Once you configure and verify your telnet login sequence, access the Telnet Connections frame
and specify telnet connection settings. These settings define the maximum and minimum number
of telnet connections available to the associated user.
Recommended settings are 10 or more for Maximum; 1 for Minimum.
Fig. 3.30
User Option Telnet Maintenance, Telnet Connections
Maximum. This value specifies:

The maximum number of concurrent embedded telnet screen connections this user can
have open per session.
The maximum number of running HTML programs allowed for the user. If a specific
record does not exist for a user with this setting defined, that user can continue opening
programs until the maximum number of sessions allowed for the entire pool is reached.
Valid values are:
Unlimited: The associated user can have an unlimited number of concurrent telnet
connections open.
Disabled: The associated user cannot log in through .NET UI. Until you create a login
script to initiate telnet sessions for this user, you cannot set this field to any value other
than Disabled.
Any numerical value between 1 and 99.
Note Setting this to 0 is the same as disabled.
This setting applies separately to HTML telnet sessions and terminal sessions in the .NET UI.
For example, if Maximum Telnet Settings is 5, a user can have 5 HTML maintenance
programs running and 5 telnet programs running in one session before an error displays.

System Interface 71
Minimum. Enter a value between 0 and 9 to indicate the minimum number of telnet
connections to be available to the associated user at all times.
Set this value to the number of telnet programs the user is likely to run simultaneously.
Specifying a value here can dramatically reduce the wait time for these programs to display.
However, setting this value too high depletes system resources.
QAD recommends that you set Minimum to 0 (zero) for most users, including the generic
userdefined with an asterisk (*). If users access terminal maintenance programs extensively,
set Minimum to 2.
Verify the Login Sequence

To verify the login sequence, from a remote machine attempt to log in to the telnet server using the
login sequence you configured in the system. Login is successful if the system displays a blank
telnet screen after the telnet connection script is launched.
Modifying Labels
The system dynamically reads the label master table to determine the appropriate labels to display
on screens and reports. For the system to display labels from the label master, Translate Frames
must be selected in Label Control (36.4.17.24). Otherwise, screens and reports display field labels
statically from the source code.
You can modify how labels display in Label Master Maintenance (36.4.17.1). You may want to
modify labels in order to meet specific company needs or to improve definitions of non-English
labels.
Fig. 3.31
Label Master Maintenance (36.4.17.1)
The system validates the language code and accesses the term. The term is the key that links labels
to fields, allowing the system to determine which labels to display. The term remains the same
regardless of the language selected.
Terms display in all uppercase with underscores; for example, CALCULATE_DUE_DATE is the
term for Calculate Due Date when the language code is US (American English).
Use Label Detail Maintenance (36.4.17.5) to assign terms and labels defined in Label Master
Maintenance to fields generically or to fields in specified programs.
Warning Because terms can be assigned to fields accessed by many programs, label
modifications and new term assignments should be made with extreme caution.
Building an E-Mail System Interface

Some functions can be configured to send e-mail messages to designated users. For example,
optional e-mail messaging is used in System Security, Product Change Control, Supplier
Performance, and the Global Requisition System. Additionally, you can have the system send
report output in an e-mail message and you can send links to programs using e-mail.
Note Certain component activities also send preconfigured e-mail. This is discussed in
Configuring E-Mail Notification for Components on page 74.
To take advantage of this feature, the e-mail system must be defined and addresses specified. The
e-mail interface is built around an operating-system command that communicates with the users
e-mail system. This command tells the e-mail system how to construct and address messages.
Setting Up E-Mail System Interfaces

There are two ways to set up e-mail:
Use text e-mails.
Convert documents to HTML and e-mail them as mail attachments.
The following topics discuss these methods.
Using Text E-Mail

With text e-mail, you cannot inform e-mail clients, such as MS Outlook or Lotus Notes, in which
code page the data resides. So, for Unicode or non-English environments, the e-mail client
determines the code page of the text. In most cases, if the text does not display correctly, you can
right-click within the e-mail to access the code page; for example, in MS Outlook, you can right
click to select Other Actions, then Encoding, then select the character set to access. In Lotus Notes,
you can right click to select Encoding, then Other, then select the character set.
E-Mailing Attachments
You can convert the text to HTML, then convert to UTF-8 to make an attachment. When you open
the e-mail attachment in your Web browser, the attachment displays correctly.
Note The UTF-8 code page is part of the Unicode standard. See Using Multiple Languages on
page 37 for details.
To use HTML e-mail, you must use an e-mail command that supports attachments, like the
command for attachments for the Mutt e-mail client. Mutt is a free, text-based program for reading
electronic mail under the UNIX or Linux operating systems. Mutt provides a -a option for
attachments.
If you want HTML e-mails as an attachment, you must add the -a option to the Mutt
configuration file. Once the command is added to the configuration file, you can send text e-mails
with an attachment by pressing the less than (<) key.

System Interface 73
E-Mail Definition Maintenance

Set up a command line in E-Mail Definition Maintenance (36.4.20) for each system you want to
access. Then, in User Maintenance (36.3.1), specify an e-mail definition and address for each user.
The system uses the address as the sender of e-mail messages.
Be sure that an output device is defined in Printer Setup Maintenance (36.13.2) that has
Destination Type set to Email. This is described in Setting Up Printers on page 82. When you
select the associated device in the Output field in programs throughout the system, the resulting
report is sent to specified e-mail addresses.
Before you implement E-Mail Definition Maintenance (36.4.20), refer to the e-mail application
documentation or consult with your e-mail system administrator to determine if the application
you are using provides an operating-system command interface. If it does not, various shareware
products provide e-mail command-line interfaces.
Fig. 3.32
E-Mail Definition Maintenance (36.4.20)
E-Mail System. Enter an alphanumeric code that identifies an e-mail system your company
uses. This can be a number or a shortened version of the application name. You can use the
same code for more than one record to give users access to multiple systems. For example, you
can define both a UNIX system and a Windows system with the same code so that a user can
log on to either system with the same user ID.
Operating System. Enter the name of the operating system on the users computer. This is not
necessarily the same operating system as the computer where the QAD databases reside. Valid
values are UNIX and WIN32.
Start Effective. Optionally enter the first date this system is available for use.
Description. Enter a brief description of this system.
Path and Program Name. Enter the complete path to the executable e-mail application file; for
instance:
F:\apps\shared\email\blat.exe
End Effective. Enter the last date this system is available for use. This is an optional field.
E-Mail Command Parameters

Command line parameter fields can store parameters or arguments to identify the type of data
being passed to the command. The parameter is a prefix, which is followed by the type of data.
The UNIX mailx command, for instance, requires that the subject of the message have a -s
prefix, as in the following example:
mailx -s test message
E-Mail Definition Maintenance defines four parameters: Sender, Recipient, Subject, and Message
Text File (or Message Text String). Use the message parameters required by your e-mail system.
You can use either a text file or string or both, as needed.
The Sequence fields control the order in which the Sender, Recipient, Subject, and Message Text
parameters appear in the command line. Some e-mail systems require these parameters in a
specific order. If your system does not use one of the parameters, leaving both the Parameter and
Sequence fields blank omits that parameter from the command line.
If you enter a parameter without a sequence, the parameter is not included on the command line. If
you enter a sequence without a parameter, the system skips this parameter and creates the
command.
The E-Mail Command field displays the system-built Path and Program Name, Parameters, and
Sequence.
When you complete the setup for your e-mail system, you are prompted to send a test message.
The default addressee is your log-on user ID. If you have not yet entered your e-mail address in
User Maintenance, the system prompts you for an address.
Customizing Appearance of HTML E-Mail

If you are receiving e-mail in the form of standard MIME attachments, you can customize the
appearance of HTML-based messages by modifying the style tag in the email.css cascading
style sheet. This file is located in the InstallDir\src directory. You should move the file so
that it can be found in the PROPATH.
You can modify color and font by updating the following values:
<style>
BODY { margin: 0; COLOR: #000000; FONT-FAMILY: Courier, Arial, Geneva,
sans-serif; BACKGROUND-COLOR: #FFFFFE }
PRE { COLOR: #000000; FONT-FAMILY: Courier, Arial, Geneva, sans-serif;
BACKGROUND-COLOR: #ffffee }
</style>
Configuring E-Mail Notification for Components

You can configure the system to send notification e-mails to recipients with the relevant roles
when customer, supplier, employee, or end-user records are created.
Note This same e-mail configuration is used for sending work items to recipients if you are using
the optional workflow. See Configuring Workflow on page 153 for details about enabling
workflow.

System Interface 75
The system notifies users of an event when they have the appropriate role and belong to the same
domain as the item being created. In the case of supplier, customer and end users components, this
is extended to include all users for each domain associated with the shared set referenced by the
component. A user configured to receive an e-mail notification receives an e-mail for each domain
in which the component is replicated.
Users receive separate e-mail notifications for each event for which they have the relevant role.
For example, if two employee records are created, users with an employee notification role receive
two separate e-mailsone for each of the new records.
Users who are to receive notifications must belong to the roles listed in the following table.
Table 3.5
Events and Corresponding Roles
Event Role
Creation of new employee record EmployeeNotify
Creation of new supplier record SupplierNotify
Creation of new customer record CustomerNotify
Creation of new end-user record EndUserNotify
To use e-mail notification, a running SMTP (e-mail) server must exist. The location of the SMTP
server is specified in the server.xml file. A sample configuration is shown below:
[SMTP]
SmtpServer=smtp.qad.com
SmtpPort=25
SmtpSender=financials@company.com
It is not necessary to specify the values for SmtpPort and SmtpSender. The SMTP port defaults to
25 (standard port for SMTP service) and the SMTP sender defaults to mfgpro@qad.com (this is
primarily for having a default sender for development environments). Generated e-mail
notifications are sent as though they originate from the specified SMTP sender. The e-mail address
specified for the sender need not be a valid e-mail address.
If the e-mail (SMTP) server used to process the e-mail notifications is not available, the e-mails
cannot be sent and the system returns a notification message to the user creating the component.
The system uses the e-mail address specified in User Maintenance (36.3.1) for the users that are
members of the role to receive notification. If this address is invalid, the user does not receive any
notification e-mails and no error is generated.
If the e-mail server used for notification is not available, the e-mails are not sent and are not
queued for later delivery. In this case, a message is returned to the user creating the component to
make them aware of the problem.
Using Advanced Reporting Tools

Use programs on the Report Setup Menu (36.4.21) to support advanced reports and dashboards
designed using the Cognos reporting tool. Additionally, several QAD-designed dashboards are
available with QAD Business Intelligence 2.5 and higher. See QAD Business Intelligence User
Guide for detailed information on these programs.
Dashboards add an interactive element to reports. They let you:
Drill up and down to see higher and lower levels of detail.

Include multiple charts derived from different data sources in a single report.
Important Although the setup menu is also available in the character UI, you can only view the
resulting reports and dashboards through the QAD .NET UI.
QAD-Provided Dashboards
If you have purchased QAD Business Intelligence 2.5 or higher and the appropriate supporting
elements, you can implement several QAD-provided dashboards. See QAD Business Intelligence
User Guide for detailed requirements and procedures.
Custom Reports and Dashboards

You can implement custom reports and dashboards without using QAD Business Intelligence, as
long as you have installed the following components:
QAD .NET User Interface
QAD ReportNet Bundle, delivered with the QAD .NET UI
Cognos 8.2
Use the following workflow to implement custom reports and dashboards.

1 Set up the QAD report server after installing Cognos 8.2.
2 Create reports and dashboards using Cognos Report Studio. See Cognos BI 8 Report Studio
User Guide for details.
3 Configure report settings and perform report synchronization using programs on the Report
Setup Menu:
a Use Report Control (36.4.21.24) to configure report server settings and view or modify
URL parameters.
b Use Report Synchronization (36.4.21.2) to synchronize reports between the system and
the report server.
c Use Report Parameter Synchronization (36.4.21.4) to synchronize report parameters in the
system with the report server.
4 Create menu entries for the new reports using Menu System Maintenance (36.4.4.1).
Monitoring User Sessions

Use Session Master Maintenance (36.4.22) to view information about users who are currently
logged in to the system through the .NET UI. This information displays in the form of session
records, each identified by a unique session ID that is generated by the system. A session record is
automatically created when a user successfully logs in to the system from the .NET UI and is
deleted when the user logs out.
Session times are recorded and displayed in Universal Time, Coordinated (UTC).

System Interface 77
Fig. 3.33
Session Master Maintenance (36.4.22)
Only some of the settings displayed on this screen apply to .NET UI sessions. You can ignore the
following: Active Web, Number of Records, Security Profile, Active Telnet, Menu Substitution,
and Context ID.
The session context detail displays information about the current workspace (domain). One user
session can be associated with multiple contexts if programs have been activated in more than one
workspace.
You can also monitor the status of sessions for HTML maintenance programs, reports, and
inquiries using Connection Manager, which is described in detail in the installation guide for your
system.

Chapter 4
Printers
This section describes how to set up and use printers.
Introduction to Printer Management 80
Introduces the Printer Management menu.
Defining Printer Types 80
Explains how to use Printer Type Maintenance.
Setting Up Printers 82
Explains how to use Printer Setup Maintenance and define a printer for use with the QAD .NET
UI.
Setting Default Printers 84
Explains how to use Printer Default Maintenance.
Defining Document Formats 84
Explains how to define document formats.
Introduction to Printer Management

You can send reports, inquiries, and browses to a variety of printersboth local and network. The
Printer Management menu (36.13) contains programs for setting up system printers and default
printers by user or group. Printers apply to all domains in a database.
Defining Printer Types

Before setting up printers, define printer types using Printer Type Maintenance (36.13.1).
Fig. 4.1
Printer Type Maintenance (36.13.1)
Printer Type. Select your printer type from the list of predefined types. If your printer type is
not in the list, use a similar printer type or define a new one.
To define a new printer type, you specify a series of programming sequences to control printer
characteristics and behavior in the following situations:
80-character-width print jobs
132-character-width print jobs
Barcode print jobs
Hardware initialize and reset
Using control characters, you define how your printer performs such tasks as modifying fonts,
changing page orientations, producing multiple copies, and so forth. Your printer manual is the
best resource for control code definitions.
Note Without correct control codes, the related aspect of printer control will not work.
Use normal ASCII characters in the control fields. For nonprinting characters, also called control
characters, use a slash and the three-digit ASCII number for the character. Table 4.1 lists
characters frequently used in control sequences.

Printers 81
Table 4.1
Control Characters
Control Character ASCII

Backspace /008
Tab /009
Linefeed /010
Form Feed /012
Carriage Return /013
Escape /027
Default system data includes correct control sequences for some commonly used printers.
Note One of the default printers is terminal. Use terminal in a character interface and page in the
QAD .NET UI.
Table 4.2
Sample Printer Control Codes
Code Function
/X27E Printer reset
/X27&l3A Folio paper format
/X27&lXO Portrait orientation
/X27&l1O Landscape orientation
/X27&l1S Long edge binding (prints on both sides)
/X27&l66F Bottom margin is 66 lines from top
/X27(sXp16.67h8.5vXsXbXT Pitch 16.67, height 8.5, default style, thickness, font
/X27&l7X89C Adjusts vertical index in steps of 1/48 inch
/X27(sXp16.67hXs3b4X99T Pitch 16.67, height default, bold, courier (4X99)
Setting Up Printers
After you have defined printer types, use Printer Setup Maintenance (36.13.2) to set up printers
and other output devices.
Fig. 4.2
Printer Setup Maintenance (36.13.2)
Defined
in 36.13.1
Printer Control Codes
Output To. Assign a unique name to each printer or other output device. This name displays in
the Output field of reports and inquiries. The QAD demo databases use printer and terminal
for the most commonly used printers. However, you can use any name.
You can set up more than one record for the same printer, as long as you use different names in
Output To. For example, this lets you access the same printer from both character and
Windows clients.
Destination Type. Enter the type of device represented by this printer definition. Valid values
are:
Default. This is a server printer, a terminal display, a Windows display, or output to page.
In Language Detail Maintenance (36.4.2), this mnemonic is assigned to value 0 (zero).
EMail. This printer definition sends the report output to an e-mail message. For this to
work properly, you must have an e-mail system that accepts a command-line interface.
The e-mail system must be set up in E-mail Definition Maintenance, and the User
Maintenance record for each user must include an e-mail definition and e-mail address. In
Language Detail Maintenance, this mnemonic is assigned to value 1. See Building an E-
Mail System Interface on page 72.
Printer Type. Optionally enter a printer type defined in Printer Type Maintenance. If you
specify a type, the characteristics assigned to that type are copied into this printer setup record.
You can modify them as required.
Description. Enter a description of the output device. Describing the physical location of a
printer can be helpful.

Printers 83
Lines/Page. Enter the maximum number of lines to appear on a page. If you set up a printer to
accept a maximum of 6 pages at 72 lines to a page, the printer prints only the first 432 lines of
output, exclusive of the trailer.
Max Pages. Enter the number of pages a device can accept. If zero, no page limit applies.
Important System administrators should use Printer Setup Maintenance (36.13.2) to set a
page limit of 1000 on the Output to Page option for reports. If you output a report of more than
1000 pages to Page, the retrieval of the data puts a burden on client resources and can cause
system instability.
Note If you try to print checks, forms, and similar items on a device with a maximum page
limit, an error message is displayed.
Scroll Output. Select this option to have the system accept a maximum of 3,000. Otherwise,
the Max Pages limit applies.
Suppress Trailer. Specify whether this device suppresses the last page of the program output
report.
No: The output report includes the last page, which includes such report trailer information as
the selection criteria.
Yes: The output report stops after the last line of report data. Report trailer information is not
included.
Device Pathname. Specify the operating system command or path name that enables you to
output to this printer. A device path name is normally not required for a terminal. However, if
you are setting up a slave printer or a terminal window under X-windows, you may need to
enter a path name. Table 4.3 lists examples of device path names.
Table 4.3
Sample Device Path Names
Operating
Device Path Name System Effect
//arnt01/supjet1 Windows Prints to network printer, shared as
supjet1 off the arnt01 print server.
printer Windows Prints to Windows captured default printer.
lp -d supjet1 UNIX Passes UNIX -lp command to operating
system, causing printing at destination
supjet1. Spooler must be selected.
Spooler. Indicate if this is a spooled device. This field only applies to UNIX systems.
Initialize Ctrl/Reset Ctrl. A slave printer is one connected to a local PC printer port or the
printer port of a dumb terminal. To transfer printer output to the proper port, you may need to
specify control codes for these fields. The initialize control string passes output from the
terminal to the print device. The last section of the Reset control string returns output to
terminal. Set up control strings for each printer. In UNIX, the slave printer device path name
is:
/device/tty
Defining a Printer for Use with QAD .NET UI

If users generate reports from the QAD .NET UI and want to view them immediately, they should
choose the Page output device rather than terminal. Output to terminal is not formatted to display
correctly in a browser.
The Page output device should be defined with the following settings:
Max pages is 0.
Destination type and printer type are blank.
Lines per page is 66.
Scroll output is selected.
Spooler is not selected.
Setting Default Printers

Use Printer Default Maintenance (36.13.4) to assign default output devices to users.This is only
the default; you can change it to any valid device when you run the program.You can apply a
record to all users by entering an asterisk (*) in the User ID field.
Note Default output devices apply only to reports; the default device for inquiries is always
terminal.
You can specify devices for a user ID or a combination of user ID and menu selection. This can be
useful for specialized tasks such as sending checks to a check printer; the same user can have
different default output devices for different programs.
The default does not necessarily have to be a physical printer; you can also choose to send output
to the terminal, page, a window (GUI only), or an e-mail recipient.
Defining Document Formats

Some programs let you specify alternative formats for printed documents in addition to the
system-defined default formats. For example, an Italian customer may require a different sales
order layout than a US customer. In that case, you can specify a predefined alternate format in the
Form Code field of Sales Order Print (7.1.3).
You do not use a menu-level program to define alternate document formats. Instead, you must
create a Progress program to generate them. Use the following steps to do this.
1 Create a Progress program to format the document as required.
2 Name the new program file appropriately so it can be located by the print program. The file
name is typically created by removing the first two characters of the print program name and
appending a two-character form code.
3 Modify the applicable print function to consider the new form code as valid.

Printers 85
Example You create two new sales order formats, identified with form codes AA and 2. The
program name for Sales Order Print is sosorp05.p and the default sales order layout is defined
by sorp0501.p. Use program file sorp05AA.p to store sales order form code AA and program
file sorp0502.p to store form code 2. Be sure to include the zero preceding the 2. Then, modify
sosorp05.p to define the two new formats as valid.

Chapter 5

This section describes how to set up and use background processes, including batch jobs and
daemons.
Introduction to Batch Processes and Daemons 88
Explains the programs used by the Batch Processing/Daemon menu.
Batch Processes 88
Explains how to define batch IDs, review batch jobs, process batch requests, and invoke batch
processing from CIM.
Daemons 91
Introduces daemon processes, and discusses daemon users, types of daemons, and daemon
functions, including how to use the event, report, and XML daemons, queue views, queue correct
functions, and queue delete functions. Also discusses running daemons on the command line.
Integrating XML Documents 120
Explains how to plan XML integration and identify business components; discusses business
component structures, tables and mandatory fields, component schema and sample files; describes
how to create XML files, integrate multiple records in an XML document, and process the XML
file.
Bulk Data Load 131
Describes how to use Bulk Data Load to add many types of financial data to your QAD system at
once by uploading multiple CSV files. Bulk Data Load is useful for setting up a QAD
implementation, because it lets you import very large amounts of data efficiently.
Introduction to Batch Processes and Daemons

The Batch Processing/Daemon (36.14) menu includes two types of programs:
Programs for creating and monitoring batch requests. These functions let system
administrators edit and process batch jobs from multiple domains without having to switch the
current working domain associated with their user IDs.
Programs for configuring and managing daemon processes that run in the background
whenever your database is active.
Batch Processes
A batch process is a group of processes run simultaneously. You can use batch functions to defer
processing and report printing for reasons such as the following:
A printer is busy or broken.
Users want to be able to continue working without having to wait for lengthy reports to finish.
Reports need to be run in a sequence, regardless of how they are submitted.
You want to balance system load by running CPU-intensive programs when system load is
low, perhaps at night.
Note Batch reporting for Financial reports is handled by the Report Daemon and .Net Report
Service. See Report Daemon on page 112.
Define Batch IDs

To set up a batch process, system administrators first create batch IDs in Batch ID Maintenance
(36.14.1). Use ID names that are descriptive and easy to remember, such as Paycheck, Monthly, or
After5. You also assign the batch a priority that determines when it will run. Requests with the
highest priority are run first.
Users then submit reports or programs that can be run in batch mode and specify the batch ID.
Note Batch IDs are domain specific. You must set up a separate set of IDs for each domain. You
can, however, manage batch processes from multiple domains in the batch processing programs.
Fig. 5.1
Batch Processes
Report
Report
Request
Request 11
Batch Queue
(Batch Request Detail)
Batch
Batch
Report
Report Batch
BatchID
ID 1/2/
1/2/
/n
/n Request
Request
Request
Request 22 Table
Table Processor
Processor
.
.
.
Reports
Reports
Report
Report Reports
Reports
Request Reports
Reports
Request nn

Review Batch Jobs

Usually the system administrator reviews batch requests prior to batch processing. Use Batch
Request Detail Maintenance (36.14.3) to view reports and programs submitted to any batch. You
can eliminate duplicate or unnecessary requests, prioritize requests, and redirect output as needed.
You must specify the domain associated with the batch requests you want to modify. You must
have access to any domain you specify in User Domain/Entity Access Maintain.
Fig. 5.2
Batch Request Detail Maintenance (36.14.3)
As each request is executed, its status is updated to reflect whether it completed normally. Statuses
include:
Failed (incomplete)
Complete
Running
When a batch does not complete normally, use Batch Request Detail Maintenance (36.14.3) to
select the Process field and restart Batch Request Processor.
Process Batch Request

Use Batch Request Processor (36.14.13) to run reports and/or programs submitted by users with a
batch ID. You can process up to 10 batch IDs in a single run. Each batch ID can be associated with
a different domain. This lets you manage batch requests for multiple domains within one database
without having to change your current working domain.
Fig. 5.3
Batch Request Processor (36.14.13)
When you run a batch process, the system executes all items queued for a given batch ID in the
requested order. You control the batch order by assigning a priority to each batch ID.
Invoke Batch Processing from CIM

In UNIX or Windows, you can create a batch file that invokes batch processing. You can then
schedule when to run the script of the batch file. The scheduling capability of the operating system
lets you run the batch processing at a time that is most convenient for you.
Note This is especially important if you have a Unicode database with domains that have
incompatible code pages. This lets you run batch jobs that bypass the restrictions on a character
client session. See Multiple Languages and Unicode on page 38 for details about restrictions in a
Unicode database.
To set up a batch script, follow these steps.
1 Prepare a file that anticipates all data entry to Batch Request Processor (36.14.13).
The file should use CIM format. The first line provides login information:
<User_Name> <Password> <Login_Domain>
mgbatch.p
<Domain> <Batch_ID>
- - - - - - - - - - - - - - - - - -
<Is_Repeat>
-
.
.
Y
In the script, mgbatch.p is the program name for Batch Request Processor. Domain and
Batch_ID identify the batch requests to process. The line Is_Repeat indicates that requests
for multiple domains can be included in the script. A hyphen (-) indicates to tab through a
field; the two dots are exits, and Y confirms the exit from your session.
See Chapter 7, CIM Interface, on page 155 for more details on CIM load processing.
2 Create a .p file of following format. Replace Input_File with the path of the file that you
prepared in the previous step.
Note If you are working in UNIX instead of Windows, the first statement in the following
script is unnecessary.
Assign PROPATH = <Propath>.
Input From <Input_File>.
Output To <Output_File>.

Run mf.p.
Input Close.
Output Close.
3 Set up a batch file. The batch file is a .sh file that can be scheduled using the UNIX crontab
command or a .bat file that, in Windows, you can add to Scheduled Tasks in Control Panel.
To set up the batch file, use the Progress command mpro (UNIX) or prowin32.exe
(Windows) to invoke the .p program that you created in step 2.
In UNIX, the .sh file has the following structure:
TERM = <Term>;
DLC = <DLC>;
PATH = <Path>;
PROPATH = <Propath>;
mpro <DB_Parameters> -p <Progress_Program> <Startup_Parameters>
In Windows, the .bat file has the following structure:
SET DLC = <DLC>
SET PATH = <Path>
prowin32.exe <DB_Parameters> -p <Progress_Program> <Startup_Parameters>
The table describes the variables used in the scripts.
Table 5.1
Variables in Batch File
Parameter Description
DLC Specify the value of the DLC system variable.
PATH Specify the value of the PATH system variable.
TERM For UNIX only, specify a terminal type.
PROPATH Specify the value of the Progress PROPATH variable.
DB_Parameters Specify the parameters to connect to the database. For
more information, see Progress help.
Progress Program Specify the path of the .p program that you created in the
previous step.
Startup Specify other parameters for mpro or prowin32.exe
Parameters to start. For more information, see Progress help.
If you are using OpenEdge 10.1A or above, you can
specify the database connection to support Unicode with
the following setting:
-cpinternal utf-8
-cpcoll icu-uca
You need Unicode support if the batch processing you

execute will access more than one domain in a database,
and the domains store language data that have
incompatible code pages.
Daemons
Daemons are server-based processes that let you run background tasks. The user has no direct
input with the daemon processes.
Daemon processes apply only to component-based functions. They can be run on the same
application server as QAD Financials, or you can specify a different appserver for each daemon.
You should define the appservers to be used for daemon processing during system implementation.
Important Some daemon processes must be running to ensure the integrity of your application.
You should ensure that these processes are configured to start when the database is started.
Overview of Daemon Processing

In general, tasks for the daemon are stored in a queue in a dedicated database table. The daemon
regularly checks its queue for tasks and then processes them. If no more tasks remain in the queue,
the daemon enters a period of inactivity known as sleep mode. After a predefined period, the
daemon exits sleep mode and check its queue for new requests.
The behavior of each daemon and its request queue are controlled and monitored using specific
maintenance programs. You can start multiple instances of a daemon if the workload requires this.
The system has the following daemons:
Balance daemon
Budget daemon
Cube daemon
Cross-Company daemon
Event daemon
History daemon
Replication daemon
Report daemon
Scan daemon
Time Out daemon
XML daemon
All daemons, except the XML daemon and Report daemon, share the same control activities. The
XML daemon differs from the others in that it creates its own requests by importing files from a
specific directory on the file system. Otherwise, the XML daemon behaves like the other daemons.
The Event daemon publishes Financials events as XML messages that can be exported to other
application instances or external Financial applications using QXtend.
Requests to the Report daemon are handled by the .NET Report Service, which is a separate server
installation. You also use the Report Service to stop and start the Report daemon, and can monitor
Service activity using the daemon Monitor function.
The Replication daemon is only used during the creation of new domains to propagate shared set
data.

Fig. 5.4
Daemon Architecture
.NET UI Client
Configure
daemons using
UI
C# Open Client
Server
AppServer server.xml
Daemon
Instance
Daemon
1 Instance
Daemon
2 Instance
3
Daemon User
Each daemon must log in to the system to perform its updates, and you specify the user login ID
and password to associate with each daemon when you configure it. The recommended practice is
to use the same user ID for all of the daemons, to make maintenance easier.
The user you specify must have access to all activities in Role Permissions Maintain and all
domains and entities.
Important Whenever you create a new domain or entity, you should assign access to this system
user. When you create a new domain and confirm it, the replication will fail if the Replication
daemon user does not have access to the new domain.
Types of Daemon
Balance Daemon
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.
Note If queue records are waiting to be processed by the Balance daemon, the supplier and
customer balances may be inaccurate.
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 on page 95.
Budget Daemon
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.
Cross-Company Daemon
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:
Customer invoices and credit notes
Supplier invoices and credit notes
Banking entry
Payment selection
Payment documents
Open item adjustment
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.
Cube Daemon
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.
Event Daemon
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 on page 109.
History 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.
Using the History Daemon to Perform Different Tasks
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().
Restarting Daemons Automatically
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:
AutoRecoverDaemons=TRUE
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:
AutoRecoverDaemonsIntervalSec=900
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.
Replication Daemon
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:
The shared set code
The ID of the primary entity of the domain
A list with the IDs of the records that need to be replicated
A priority that indicates the order in which each request should be processed
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.
Important You must grant the daemon user ID access to a new domain before confirmation or the
replication process will fail.
Report Daemon
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 on page 112.
Scan 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.

Note In order to use the Scan daemon, you must enable workflow, since the scanned documents
are associated with draft objects and sent to user inboxes for completion. See Configuring
Workflow on page 153 for details.
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 on page 107 for details.
Time Out Daemon
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.
Note If you decide to implement this setting, it can result in loss of data if users have partially
completed input in a program.
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.
XML Daemon
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 on
page 115.
Daemon Permissions
With the exception of the XML daemon, none of the daemons have any security requirements.
Therefore, you can set them up without any specific permissions. First, create a role named
daemon with no security rights. Then, create a user named daemon that has access to all entities
and is linked to the role daemon in all entities.
The XML daemon is a special case because it can be used for many different activities. For
example, an xml message to create a customer invoice means that the daemon user must have
access to the activity Customer Invoice Create. Therefore, for the XML daemon, you must create a
specific role, or roles, depending on what you are using the daemon to do.
Daemon Functions
Use the following activities to maintain and control daemons:
Configure
Start
Stop
Clear Queue
Monitor
Note Separate to this Monitor activity for each daemon, the Daemon Monitor menu option
allows you to monitor all daemons from a single screen. The Daemon Monitor also allows you
to view the log file and set debug levels for a daemon, and to start and stop all daemons at
once. See Monitoring Daemons Collectively on page 105 for more information.
These activities are the same for all of the daemons, except the XML daemon, which is described
on page 115, and the Report daemon, which is described on page 112. In addition, the Scan
daemon has an extra grid, described on page 107.
Both the Configure and Monitor activities check the status of the daemon and correct it before
displaying. For example, if the daemon status is set to Running but no daemon process is detected
on the QAD Financials appserver, the status is reset to Inactive before the Configure or Monitor
screens display.
Note You configure, clear queues, and monitor the Report daemon in the same way as for other
daemons. However, the Report daemon is stopped and started from within the .Net Report Service.
Configure
The Configure activity lets you configure maintenance information for the daemon, such as the
login ID and password, in addition to the log file and start directory. For security reasons, you
should use a dedicated daemon user name. The user name must have access to all domains and
entities have role permissions to all component activities in the database.
Note The activities controlled by the daemon must be included in the list of activities for the role
assigned to the daemon user name.
The Configure activity also lets you define the time interval before the daemon checks its queue
for new requests, indicate whether to record processed items for audit purposes, and set the
number of records that the daemon should process in each run.

Fig. 5.5
Event Daemon, Configure (36.14.16.1.1)
Field Descriptions
Daemon Name. Displays the daemon name.
# Instances. Enter the maximum number of instances that can be started for this daemon. It is
possible to enter 0, meaning that the daemon is not configured for use in the system setup.
Interval (Sec). Specify the time interval in seconds before the daemon checks its queue for
new requests.
Keep Processed Items. Select the field to record processed items for audit purposes. When
you clear the field, the system deletes all successfully processed requests from the Monitor
screen. See Monitor on page 101.
Note It is recommended to clear this field for any daemons that process a high number of
requests so that you can easily see requests processed with errors.
Number Treated in One Run. Specify the number of requests that the daemon should process
in a single run. Note that during a run, the daemon does not react to Stop commands. If you set
this number too high, the response time to a Stop command increases accordingly.
Login ID for this Daemon. Specify the ID of a valid active user that is assigned a role that
grants permission to all activities and access to all domains and entities. To ensure proper
security is enforced, the daemon process accesses the database by logging in with this name.
Note The login details you specify are used by the Report daemon to determine the From
address when you e-mail a report.
Password for this Daemon. Specify the password for the user ID in the previous field.
Important If the password of this user is changed in User Maintenance, the change is not
automatically reflected here. You must ensure that the passwords are updated in both places, or
the Daemon process will fail on login.
Daemon Log File. Specify the full path of the log file in which the system records the
daemons actions.
By default, the system uses the Environment Root variable $ENVROOT to specify the location
of the daemon log file. The $ENVROOT variable takes its value from the serverXML file for
the application environment, and ensures that the financial database can be copied between
environments without the need to reconfigure the daemons.
The log file path by default is:
$ENVROOT/logs/<daemon name>.log
You do not normally need to modify this default.
To troubleshoot daemon activity, you can modify how messages are generated to the daemon
log file by setting the debug level in the daemon configuration file. Each daemon has a
configuration file of the form <DaemonName>.config in the PROPATH of the Financials
appserver.
Example To increase the message detail for the History daemon, modify the debug level in
HistoryDaemon.config.
Daemon Start Directory. Specify the directory on the file system where the physical daemon
process is started. Progress keeps its internal and temporary files related to the daemon process
in this location.
The system also uses the Environment Root variable $ENVROOT to specify the location of the
daemon start directory.
The start directory path by default is:
$ENVROOT/daemons/<daemon name>/
You do not normally need to modify this default.
OS Command String. Enter the physical command used to run an instance of the daemon. A
part of this command string is determined by the application itself, and is referenced by using
<DaemonExecutable>, and differs between operating systems. You can add parameters to
the command, but should include the <DaemonExecutable> tag to refer to the actual
executable.
Appserver URL. Enter the connection URL for the application server on which this daemon is
to be run. You can optionally use a different server than the main application server.
Important It is recommended that you define a different appserver connection for the Report
daemon. This ensures that the batch processing of report requests does not have an impact on
overall server performance.
Start Date of Last Daemon Run. This field displays the last time the daemon started.
End Date of Last Daemon Run. This field displays the last time the daemon stopped.
Daemon Status. This field displays the daemon status. Valid values are Inactive, Running, and
Stopping. The Start and Stop activities control the status changes.
Number of Running Processes for this Date. Displays the number of instances of the daemon
that are currently running. This value is zero when the daemon is inactive.
Start
The Start activity starts the daemon. The system displays a message that indicates that the daemon
has started successfully.

Stop
The Stop activity stops the daemon.

The daemon stops after it completes its current task. Depending on the type of daemon and the
amount of time it takes to complete an operation, some time may pass before the daemon detects
the stop request and shuts down.
The system displays a message that indicates that the daemon has stopped successfully.
Note The Start and Stop activities are not available for the Report daemon, which is managed by
the .Net Report Service.
Clear Queue
Use the Clear Queue menu option to manage daemon queue requests. The records you select are
immediately removed from the daemon queue.
Important Only qualified and trained personnel should clear queues because this action can
potentially destroy valuable information or interfere with critical application processes.
Fig. 5.6
XML Daemon Clear Queue (36.14.16.6.2)
Field Descriptions
Remove Waiting Records. Select the field to remove records that are waiting to be processed
from the daemon queue.
Remove in Process Records. Select the field to remove in-process records from the daemon
queue.
Remove Successfully Processed Records. Select the field to remove successfully processed
records from the daemon queue.
Remove Failed Records. Select the field to remove failed records from the daemon queue.
Monitor
There are two methods of monitoring daemons:

Individually, using the Monitor menu option for the particular daemon.
Collectively, using Daemon Monitor (36.14.16.25).
Monitoring Daemons Individually
The Monitor screen for a particular daemon lets you view the start and stop dates for the daemon
and the requests that are processed, waiting, in progress, or incorrectly processed.
To access the monitor screen for a particular daemon, launch <daemon name> Daemon Monitor,
where <daemon name> is the daemon name. Figure 5.7 displays the Event Daemon Monitor
screen. The screen is composed of a header area and two grids.
The header area contains fields that display the daemon name, the start and end times, and the
daemon status. The header also contains fields that let you choose the type of requests to include in
the view.
The center grid of the Monitor displays:
The start and end time of the request currently processing.
A description of the request.
The status of the request. The valid values are PROCESSED-OK, PROCESSED-ERR,
WAITING, and IN-PROCESS.
Additionally, if you set a specific start date and time for the request, the center grid also displays
this data. It is only possible to set a specific request date and time for the XML daemon.
The lower grid displays the error information for each request line, if any.
The view does not store correctly processed records after the next refresh unless the Keep
Processed Items field is selected in the Configure screen.
Fig. 5.7
Event Daemon Monitor (36.14.16.1.3)

Note If a request does not process successfully, then the daemon automatically resubmits the
request after a delay of 30 seconds. This resubmission can happen only three times per request. If
the request is not processed successfully after three resubmissions, it will be marked as
PROCESSED-ERR.
Field Descriptions
Daemon Name. Displays the daemon name.
Interval (Sec). Displays the time interval in seconds before the daemon checks its queue for
new requests. You can update this value using the Configure screen.
Include Waiting. Select the field to include waiting requests in the view.
Include Successfully Processed. Select the field to include correctly processed requests in the
view.
Include in Process. Select the field to include requests that are in progress in the view.
Include Failed. Select this field to include incorrectly processed requests in the view.
Last Start Date (UTC). This field displays the last time the daemon started.
Last End Date (UTC). This field displays the last time the daemon stopped.
Daemon Status. This field displays the daemon status. The valid values are Inactive, Running,
Starting, and Stopping. The Start and Stop activities control the status changes.
Running Processes. This field displays the number of instances of the daemon that are
currently running. This value is 0 when the daemon is inactive.
Appserver URL. This field displays the URL of the appserver on which this daemon is
running. The field is blank when the daemon is running on the main appserver.
Daemon Start Directory. This field displays the location of the daemon start directory, which
the system retrieves from the daemon configuration.
# Waiting Requests/Number of waiting queues. Displays the number of records in the daemon
queue that have the status Waiting.
Number of queue records. Displays the number of records in the daemon queue. This field
displays in the Balance, Budget, Cross-Company, Cube, History, and Replication Daemon
Monitor screens only.
Status Grid
Daemon Request Start Date. This field displays the date on which the daemon request was
submitted.
Start Time. This field displays the time at which the daemon request was submitted.
Ref Description. This field displays an abbreviated description of the request type.
Ref. Request number.
Daemon Request Status. This field displays the status of the request. The possible statuses
are: WAITING, IN-PROCESS, PROCESSED-OK, and PROCESSED-ERR.
Daemon Request End Date. This field displays the date on which the request was processed.
End Time. This field displays the time at which the daemon finished processing the request.
Locked Process. This field displays the ID of the process that is running the request. Some
daemons can be run several times at once. Every time a daemon is started, a new physical
Progress process is started.
Daemon Request Log. This field displays the date and time of the error together with the type
of error.
Sequence. This field displays the order in which the requests should be handled.
Requested Start Date of Daemon. This field displays the requested start date for the daemon
request.
If no start date is requested, the request will be processed as soon as possible.
Req Start Time. This field displays the requested start time for the daemon request.
If no requested start time or start date is specified, the daemon processes the request
immediately. If no start time is specified, but the start date is, the request will be processed as
early as possible on the requested date.
The Monitor screen for the Report daemon has two additional fields:
Socket Port. This field displays the server port on which the .Net Report Service is listening
for requests.
Socket Server. This field displays the server on which the .Net Report Service is running.
These fields display values when the .Net report Service is running successfully. If the .Net
Report Service is interrupted, these fields are blank. Errors in the .Net Report Service are
displayed as Windows log events on the server on which the service is installed.
Note To improve response times, the Monitor screen center grid for the History daemon differs
from that of the other daemons. You can choose the default behavior, where one line appears in the
grid for each request, or you can display multiple requests in a single line. To display multiple
requests in a single line, set the Number Treated in One Run property of the History daemon
configuration file to 999999. The CT log file for these grid lines contains less information than the
CT log file for grid lines that appear in this screen during the default screen behavior.
Error Grid
Daemon Request Log. Displays the date and time of the error together with the type of error.
Field Label. Displays the label of the field that initiated the error.
Field Name. Displays the name of the field that initiated the error.
Field Value. Displays the value in the field that initiated the error.
Accompanying Error Message. Displays the message associated with the error.
Error Severity. Displays the severity level of the error.
Error Type. Displays E for error, I for informational, and W for warning.

Monitoring Daemons Collectively
The Daemon Monitor screen (36.14.16.25) lets you monitor all daemons at once.
The screen is a browse with search criteria and a results grid. When the menu option opens, all
daemons are displayed by default; use the search criteria to refine the results.
Fig. 5.8
Daemon Monitor (36.14.16.25)
Search Criteria
By default, one search field displays. You can add more fields and use the drop-down menu in the
search field to specify further criteria. The search criteria correspond to the column headings in the
results grid.
Results Grid Columns
Daemon Name, Name, Status. The translated name, name, and status of the daemon. Possible
statuses are Inactive, Starting, Running, and Stopped.
Last Started, Last Started (UTC), Last Stopped, Last Stopped (UTC). The date and time that
the daemon was most recently started and stopped.
Last Started By, Last Stopped By. The user who most recently started and stopped the
daemon. If the daemon started or stopped as a result of an operating system script, then this
information appears in the column as <system>.
# Instances. The number of instances of the daemon that are currently running. This value is
zero when the daemon is inactive. This column corresponds to the Daemon Monitor search
criteria # Instances and Running Processes.
Processes. For running processes, this column displays the name of the server that the
daemon process is running on and the process ID. If multiple processes are running for the
daemon, then this column displays a list of server names and process IDs.
# Failed, # Waiting, # Processed 1h, # Processed 24h. These columns display the number of
instances of the daemon that have failed, are currently waiting in the daemon queue, were
processed within the last hour, and were processed within the last 24 hours, respectively.
Daemon Log File. Displays the path to the log file for the daemon.
Daemon Log Level. This column displays information about the debugging options that are
activated for the daemon. You can set these options in the Daemon - Set Debug Level screen,
which is accessed by right-clicking a row in the status grid and choosing Set Debug Level.
The value of Daemon Log Level is initially 0, and increases by 1 when the first field in the
Daemon - Set Debug Level screen is selected. It increases by 2 when the second field is
selected, by 4 when the third field is selected, by 8 when the fourth field is selected, and by 16
when the fifth field is selected. For example, when the first and fourth fields in the Daemon -
Set Debug Level screen are selected, then Daemon Log Level is 9.
Daemon Start Directory. The location of the daemon start directory, which the system retrieves
from the daemon configuration.
Daemon Login. The user ID that the daemon used when logging in.
OS Command String. This column corresponds to the OS Command String field in the
Configure screen for the daemon.
No in One Run. The value of the Number Treated in One Run field in the Configure screen for
the daemon.
Keep OK. This column displays yes when the Keep Processed Items field in the Configure
screen for the daemon is selected. Otherwise, this field displays no.
Interval. The time interval in seconds before the daemon checks its queue for new requests.
You can update this value using the Configure screen.
Appserver URL. This column displays the URL of the appserver on which this daemon is
running. The field is blank when the daemon is running on the main appserver.
To perform an activity on a daemon, select the daemon in the grid and right-click to see the
following options:
Monitor
Start
Stop
Configure
View Log File
Clear Queue
Set Debug Level
Start All
Stop All
The Monitor, Start, Stop, Configure, and Clear Queue activities are described earlier in this
section, Daemon Functions.
The View Log File option displays the log file for the selected daemon. For more information on
the log file, see View CT Logfile on page 147.

Fig. 5.9
View Log File
The Set Debug Level option lets you state the level of CT-logging that you want for the daemon.
Selecting this option displays the Daemon - Set Debug Level screen. This screen is similar to the
Set Debug Level screen described in Set Debug Level on page 145, but it contains an extra
Database updates details option.
Fig. 5.10
Daemon - Set Debug Level
Configuring the Scan Daemon
The Scan Daemon Configure activity contains an additional grid for specifying the business
component to be associated with a scanned document, the directory the daemon should monitor for
documents, and the entity the scanned documents should be associated with.
Fig. 5.11
Scan Daemon, Configure (36.14.16.4.1)
Field Descriptions
Component Code. Choose the name of the business component that the scanned document
should be associated with. You can select only components that support the Save as Draft
feature. Currently, this includes the following components:
Banking Entry
Business Relation
Customer
Customer Finance Charge
Customer Invoice
Journal Entry
Petty Cash
Supplier Invoice
Supplier
Example You specify BCInvoice, the technical name for a supplier invoice. The Scan
daemon runs the Supplier Invoice Create activity when it detects a document to scan.
Documents for each scanned component must be located in a separate directory. The
component description displays in the Component Label column.
Location on The File System. Enter the full path to the directory on the Financials appserver
where documents to be scanned and associated with the specified component are located.
Important Make sure the directory is on the correct server or it will not be found.
Entity Code. Specify the entity associated with the scanned documents.

Event Daemon
The Event daemon processes Financials business events and publishes them to a defined
destination. The system publishes events to a directory on the application server or to the QXtend
Server for replication to other Financials instances or to third-party financial applications.
A business event in this case can be any modification to a Financials business object, such as an
update to customer or supplier base data. By publishing the event, the system ensures that the
update is replicated to other instances and so eliminates the need to extract the data directly from
the database. The event consists of complete object data with context information that is published
in XML format.
The Financials application uses a buffer queue within the running transaction to prepare messages
before they are sent out. This ensures that no events are lost during system down-time and that no
disruption of service occurs. Events are then published in XML format using a daemon process
which routes the message to the specified destination.
Event publishing has three components:
Event Destination
Create an Event Destination to define the name of the event and the type and details of the
server connections.
Event Configuration
Use Event Configuration to activate the publishing mechanism, configure which components
and status transitions will trigger eventsfor example, supplier invoice creationand
indicate the destination queue of the event.
Event Daemon
The Event daemon processes the events in its queue and displays the event message status.
Event Destination
Use Event Destination Create (36.14.16.14.1) to define the name of the event and the type of
messages it will contain. When you are using QXtend to export the events, you specify the
connection to the appserver instance of QXtend Out (QXO) as the destination.
Fig. 5.12
Event Destination Create
Field Descriptions
Destination Name. Specify a destination name (maximum of 40 characters).
Destination Type. Select a destination type:

Direct Appserver. The events are published to an application server. When you select this
type, the Directory field becomes unavailable.
To Directory. The events are published to a server directory.
Appserver Connection. Specify an application server connection. The protocol for the server
path is:
appserver://<hostname>:<nameserver port>/<application service name>
The default nameserver port for a daemon running on the main application server is 5162.
Appserver Procedure. Specify a procedure to be applied to the event.
This is the procedure that is called on the appserver. For QXO (QXtend Out) this typically is
qad/qra/si/RPCRequestService.p
Directory. Specify a server directory. This field is available when you select a To Directory
destination type.
Event Configuration
Use Event Configuration Create (36.14.16.15.1) to perform the following activities:

Activate the publishing mechanism.
Configure which components and status transitions will trigger events; for example, an update
to Supplier base data.
Select the destination of the event.
Fig. 5.13
Event Configuration Create
Field Descriptions
Component Label. Choose the business component that will trigger an event.
Publish Any Update. Select this field if any type of update to the business component is to
trigger an event. Selecting this field makes the Object Status field unavailable.

Object Status. Choose the object status of the business component upon which the system
will trigger an event.
Destination Name. Choose the name of a queue to which the event will be sent.
Lock Object. Select the field to lock the object for update after it has been published.
Active. Indicate if this is an active record.
Header Only. Select this field to publish event header details only.
Suppress Empty Fields. Select this field to exclude empty database fields from event
publishing.
Suppress Fields with Default Value. Select this field to suppress all fields that contain the
default value for that field as defined in the dataset.
If the default value of a numeric field is zero, all zero values are removed. If the default value
of a Boolean field is False, all False values are removed. If the default value of a field is not
null, fields with null values are not removed.
Force Publish
The Force Publish option is a right-click feature available on Enterprise Financials browses, which
publishes a business event for the selected record. By publishing the event, the system ensures that
the update is passed to the QXtend Outbound database and replicated to other instances of
Financials or third-party applications. This facility eliminates the need for the other applications to
extract the data directly from the Financials database.
In order to publish an event for a component, you must first define an event for the component
using Event Configuration Create (36.14.16.15.1). In Event Configuration Create, you select the
Publish Any Update field to ensure that all data updates for the business object for which you
defined the event are published to QXtend.
Event Daemon
The Event daemon reads event messages in its queue, and processes them according to the event
configuration. You configure and monitor the Event daemon in the same way as other daemons.
Fig. 5.14
Event Daemon Monitor
Report Daemon
You can output a report directly to screen, in which case the system retrieves the report template
and processes the report on the application client.
You can also:
Schedule the report to be processed (printed, mailed or saved) at a later date.
Schedule the report to be pre-processed at predefined intervals (daily, weekly, monthly, or
yearly).
Save the report in file format.
E-mail the report to systems users or roles.
Combine some or all of these options.
Note You select these options in the server output processing section of the report screen. For
more information on generating reports, see QAD Financials User Guide.
When you select one or all of these options, the report request is sent to the report request queue
and is then handled as a server-side activity by the Report daemon.
The Report daemon handles all batch report requests for reports developed using Crystal Reports,
including scheduled reports, e-mailed reports, and reports to be saved to file format or sent to a
printer. The Report daemon is managed by the .Net Report Service, which is installed as an
additional service on the application server.
The Report daemon:
Monitors the report request queue
Calls the .Net Report Service and passes the report details
Receives the result of the report and issues a confirmation that the report has been successfully
generated

.Net Report Service
The .Net Report Service is responsible for starting, monitoring, and when necessary, restarting the
Report daemon.
The .Net Report Service communicates with the Report daemon through the server socket port
defined during the service configuration. Once the daemon is started, the report service:
Runs the report business logic and resolves the e-mail addresses from roles and user names
Retrieves a list of printers installed on the server and passes this list to the appserver for report
printing
Checks that the report templates stored on the server are up-to-date
Updates the server socket port and socket host information on the Report Daemon monitor
screen
When a report request is received from the Report daemon, the Report Service then:
Passes the request details and report template to Crystal Reports
Executes the report options by generating the report at the scheduled time, saving the report as
a file, printing the report on a local printer, or e-mailing the report to a user or role
Sends a confirmation request or error message to the daemon
Receives a confirmation from the daemon and updates the daemon report log accordingly
Fig. 5.15
Report Daemon Architecture
.NET UI Client
Complete report
details and submit
report request
C# Open Client
Application Server
AppServer Progress run
Report Daemon Report Daemon

Queue Processor
via
Sockets
.Net Report Service

.Net Framework
.Net Report Service Crystal Reports
Configuring and Monitoring the .Net Report Service
The .Net Report Service is configured by defining service settings in the

QAD.CBFReportingService.exe.config file, which is located in the service installation
directory.
Define the following settings in the <applicationSettings> section of the file:
The SMTP Server for e-mailing reports
The folder in which to save reports in file format
The check interval in seconds for the report daemon
The TCP socket port on which the service listens for report requests
The user login ID and password for the servicenormally your application login and
password
Example
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="qad.appserver" type="QAD.AppServer.ASConfigHandler, QAD.AppServer"
/>
<sectionGroup name="applicationSettings" type=
"System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=
neutral, PublicKeyToken=b77a5c561934e089" >
<section name="QAD.CBFReportingService.Properties.Settings" type=
"System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<qad.appserver url="appserver://localhost:5162/devcbf93ui">
</qad.appserver>
<applicationSettings>
<QAD.CBFReportingService.Properties.Settings>
<setting name="SMTPServer" serializeAs="String">
<value>server01.company.com</value>
</setting>
<setting name="ReportFolder" serializeAs="String">
<value>reports</value>
</setting>
<setting name="DaemonCheckInterval" serializeAs="String">
<value>5000</value>
</setting>
<setting name="TCPPort" serializeAs="String">
<value>4331</value>
</setting>
<setting name="LoginUsr" serializeAs="String">
<value>user</value>
</setting>
<setting name="LoginPasswd" serializeAs="String">
<value>password</value>
</setting>
</QAD.CBFReportingService.Properties.Settings>
</applicationSettings>
</configuration>
The .Net Report Service is automatically started when you log in to the application.
The service can also be started with an alternative configuration file location, using the -
configfile configfilename startup option.

Errors in Report Processing
The Report Daemon monitor lists the report requests and status, and indicates if a report has not
been processed correctly.
Processing error details are displayed on the .Net Report Service monitor screen. This monitor is
launched using the QAD.CBFReportingServiceMonitor.exe file, which is contained in the
.Net Report service installation folder.
XML Daemon
The XML daemon processes external data in the form of XML files; for example, invoices are
received in electronic form from a supplier. You store the files in a specific directory on the server
and the daemon reads and processes them.
The XML daemon differs from the other daemons in that it creates its own requests.
Fig. 5.16
XML Daemon Architecture
.NET UI Client
Configure
daemons using
UI
C# Open Client
Server
AppServer
XML
Daemon
Instance
The daemon parses the header of an XML document and decides which software component to
call to process the data. It then creates the appropriate request. The daemon reads each XML file
once.
The XML daemon processes one supplier invoice for each XML file. If you attempt to use the
XML daemon to process an XML file with two or more invoices, the system displays an error
message.
The XML daemon can process XML files only. You must convert other text formats to XML
according to the QAD-defined XSDs before importing them.
You can generate well-formed schema as a starting point for entering your own data by accessing
the program that creates a component and selecting Properties from the component menu. The
Properties dialog includes a Dump XML button that lets you generate schema to a designated
directory.
Important The XML daemon can process a maximum of 500 XML files in one iteration.
XML Daemon Actions
The XML daemon reads each XML file to determine what action it must take and how it should
handle invalid data.
The XML daemon supports the following activities:
Save. The daemon validates the object and tries to save it. If the validation returns an error, the
daemon does not save the object. You can use the Monitor screen to view the error message.
When using the Save action, XML files can contain data for multiple objects.
Save/Create Draft. This activity is similar to Save. However, if the validation returns an error,
the XML daemon saves the object as a draft, without validation. In both cases, the queue entry
is marked as processed correctly. You can use the Monitor screen to view the status.
When using the Save/Create Draft action, XML files cannot contain data for multiple objects.
Create Draft. The XML daemon does not validate data, and saves the objects as drafts.
When using the Create Draft action, XML files cannot contain data for multiple objects.
Validate. The XML daemon validates the objects and displays the results in the Monitor
screen. It does not save data. When the input data is incorrect, the daemon displays the error
and marks the queue entry as processed with errors.
When using the Validate action, XML files can contain data for multiple objects.
Note For the Create Draft feature to work, the object being created must support Save as Draft.
Only a subset of business components can be saved as drafts: Banking Entry, Business Relation,
Customer, Customer Finance Charge, Customer Invoice, Journal Entry, Petty Cash, Supplier,
Supplier Invoice. Also the use of drafts must be enabled in System Settings.
Use the Action to be Performed field in the Daemon Configure screen to specify the next action for
the daemon to perform.
The action applies to all XML files and overrules the action defined in the file if you select the
Overrule XML Action field in the XML Daemon, Configure screen.
Configure
The XML Daemon Configure screen lets you configure the XML daemon and differs from the
Maintain screen of the other daemons.
The settings in XML Daemon Configure instruct the daemon to convert an XML file into a
daemon request and how to process it. Only the settings that are unique to the XML Daemon are
described here; the others are the same as the general settings discussed with the History Daemon
Configure screen on page 99.

Fig. 5.17
XML Daemon, Configure (36.14.16.6.1)
Field Descriptions
Input Directory for XML Files. Specify the directory that the daemon scans for XML files.
Note You must specify an input directory to enable the daemon process.
Action to be Performed. Optionally, choose the action that the XML daemon must perform on
the data in the XML file. If not specified, the action is read from the XML file.
Overrule XML Action. Select this field to overrule the action specified in the XML file with the
action defined in the Action to be Performed field.
Overrule Originator Action. Select the field to overrule the action based on the originator and
according to the rules defined in the grid.
The Originator field is part of the header section of the XML file and indicates the origin of the
file; for example, a source application or external party.
Originator. Specify the originator for which to perform the overrule action.
Activity. Select the default activity to perform on loaded XML files. The options are:
Save
Save/Create Draft
Create Draft
Validate
Overrule XML. Select the field to overrule the action specified in the XML file with the action
defined in the Activity field.
Queue View
XML Daemon Queue View (36.14.16.7.1) lets you view the results of the daemon activity since
the last time the queue was cleared. When you open the window, a browse displays where you can
enter criteria to refine your search.
Fig. 5.18
XML Daemon Queue Browse
Double-click on a queue record to view it in more detail.

Fig. 5.19
XML Daemon Queue View
Queue Correct
XML Daemon Queue Correct (36.14.16.7.3) lets you correct object errors in queue requests.
When you open the window, a browse displays where you can enter criteria to refine your search.
Double-click on a queue record to open it in XML Daemon Queue Correct.

Fig. 5.20
XML Daemon Queue Correct
Click on Dump XML to export a copy of the XML file that was submitted to the daemon.
Click on Resubmit XML to relaunch corrected objects to the daemon queue.
Queue Delete
Use XML Daemon Delete Queue (36.14.16.6.7) to delete individual queue entries for the XML
daemon. When you open the window, a browse displays where you can enter criteria to refine your
search. Double-click on a queue record to open it in the XML Daemon Delete Queue screen.
Click on the Delete button at the bottom of the screen to delete the queue request.
Fig. 5.21
XML Daemon Delete Queue
Running Daemons on the Command Line

The application control program, applicationcontrol.p, can be used to start and stop system
daemons on the command line, without launching the application interface. Use daemon-specific
parameters to start and stop daemons, and display limited daemon status.
Integrating XML Documents

Data can be imported into QAD Enterprise Edition from an external customer system in a number
of ways:
Using DatasSync. DataSync synchronizes static data such as item master data among multiple,
distributed databases. The data fields and the specific records to be updated are specified in a
synchronization profile. DataSync does not synchronize transaction data or entire databases.
The data, as documents, is exported from and imported to each database using Q/LinQ. See
External Interface Guide: Q/LinQ for a complete discussion of importing and exporting
documents with Q/LinQ.
In Excel files, using the Excel integration function available for many components. This
function is mainly used for static components, such as GL accounts or cost centers (but can
also be used for journal entries).
The Excel integration function lets you export existing static components to an Excel
spreadsheet. You use the spreadsheet as a template in which to enter new data, and re-import
the data as new data objects. For more information on Excel integration, see Introduction to
QAD Enterprise Applications User Guide.
As XML files, using the XML Daemon or QXtend Inbound functions. This technique is
mainly used for dynamic components, such as transactions.
The Excel and XML-based functions convert the imported file to an Enterprise Application
business object, such as a business relation or customer invoice, which can then be processed by
standard Enterprise Financials applications. The imported file must contain essential data and
conform to a set file structure in order to be processed successfully as a Financials business object.
Each component has an XML schema file, which describes the structure of its data. The structure
of XML documents must conform to the schema file of the business component to which they will
be converted. You must therefore prepare your document carefully before beginning the
integration process.
Planning the Integration

There are a number of scenarios in which a customer uses XML to migrate their data into the
Financials application. For example:
The customer is using an add-on product (for example, a payroll system) and needs to process
payroll transactions using Financials functions.
The customer is using an add-on product (for example, a separate order entry system) and
needs to process orders as Customer Invoices.
In these situations, the original data must be converted to XML in order to be integrated into the
Financials system.

Before you begin the integration process, you must identify key information:
Which Financials business component will be used to process the data?
How is the component structured, and what are its dependant components?
Which tables are updated by this component and what are its mandatory fields?
Which component schema files and sample files do you require?
What are the editing guidelines for creating an XML file from your data?
Which Enterprise Edition tools do you use to complete the integration?
Identifying Business Components

When you have decided on the purpose of the integration (to create a customer or supplier opening
balance, to complete banking entries for posted transactions, or to complete AR or AP payment
cycles), you then identify the business components you want to be use to process the imported
data.
For example, you may want to process payroll transactions for wages already paid as banking
entries. You need to import both the transaction data and the employee data, and may want to
import the employee data to be used as Financials system Employees. The components you will
need are Banking Entry and Employee, and the data you import must comply with the schema files
for these components.
To identify the name of the business component you need:
1 Right-click on the menu item.
2 Choose Properties.
3 Check the URI field.
For Financials objects, the name is typically in the format
urn:cbf:<businessComponent>.<Activity>.
(for example, BBusinessRelation.Modify)
You can now view the HTML documentation for this component. See Tables and Mandatory
Fields on page 123.
You normally use the Business Relations component when importing customer or supplier address
and contact information. Business relations contain location and contact information for all
addresses defined in the system. They also contain tax details that are directly referenced or used
as defaults for customers and suppliers. Therefore, when converting your data to a dataset that can
be processed as a Financials component, you should be aware of the component structure.
Identifying Components for Customer and Supplier Invoices
Posted customer and supplier invoices differ from other components in that the invoice can consist
of two parts:
The invoice posting
The related journal entry postings
A standard Financials supplier or customer invoice posted to the official layer automatically
contains all the required posting data. If you are integrating invoices that match the standard
posted Financials invoice in every respect, you can therefore generate an XML dump from a
Financials invoice to use as a template for integration. The components you need in this case are
BDInvoice and BCInvoice.
If, however, you are integrating invoices that use different posting rules (for example, different
expense or tax accounts, or different allocation), you should be aware that your integrated file must
contain both the customer invoice data and the related journal entry data. In this case, the
components you need for a posted customer invoice are BDInvoice and BCJournalEntry, and
for a posted supplier invoice, BDInvoice and two BJournalEntry components (containing SI
Posting data and Matching Posting data respectively).
When you have modified the field values with your data, you then combine the files into one.
Schema files are available for a posted customer invoice (BDInvoiceJournalEntry) and
posted supplier invoice (BCInvoiceJournalEntry), and you must rename the tags in your
combined files to conform with these schemas.
Business Component Structures

Each business component dataset contains data tables. Static components, such as SAF concepts,
contain master or parent data tables only, whereas complex components such as transactions
contain both parent and child data tables.
For example, the BJournalEntry component contains the tPosting table, a tPostingLine
table for each posting line in the transaction, the tax tables tPostingVAT for tax postings, and
optionally, the SAF posting table tPostingSAF.
The component tables also contain fields. In the case of tPostingLine, GL account, currency,
amount, sub-account, and other accounting fields are defined for each posting line. Each posting
line can also optionally have tax tables and SAF tables (when SAFs have been defined for cost
centers or projects).

Fig. 5.22
Journal Entry Component Structure
Posting
Posting
(tPosting)
(tPosting)
Posting
PostingLine
Line11 GL
GLAccount
Account
(tPostingLIne)
(tPostingLIne)
Currency
Currency
Posting
PostingLine
Linenn
(tPostingLine) Amount
Amount
(tPostingLine)
Sub-Account
Sub-Account
Quantity
Quantity
Intercompany
Intercompany
Cost
CostCenter
Center
Project
Project
tPostingVAT
tPostingVAT
tPostingVATDelay
tPostingVATDelay
tPostingSAF
tPostingSAF
tPostingSAF
tPostingSAF
When creating an XML file to be processed as a Financials journal entry, therefore, it is important
to identify the fields, tables, and table relations of the BJournalEntry component. The XML file
you import into Financials must contain the same fields and tables as the component you intend to
use. This information is defined in the component schema file.
The schema files for each Financials business component are located in the
<installdir>\qadfin\components\progress\xml\*.xsd directory.
Tables and Mandatory Fields

Each component contains mandatory fields, which must be given values in order for the
component to be validated. Information on these fields, and on the component tables, is contained
in the component API documentation.
API documentation is provided in HTML format with each QAD Enterprise Financials release. It
is stored in the HTMLdocumentation folder in your installation directory in a file called
QADFIN_Documentation.zip.
The API documentation provided for each Financials business component consists of HTML
pages with information about Financials projects, and the components used in projects. The main
index.htm file for the project lists each component by business area, and you click the link for
the specific component to display its own index page.
The component index page is divided into the following areas:
Public data items
API queries
API methods
Other methods
Activities
Click the class dataset link in the public data items area to display the component dataset
attributes.
Figure 5.23 displays the class dataset for BSafConcept.
Fig. 5.23
BSafConcept Dataset
This component contains the table tSafConcept, and contains the following mandatory fields:
SafConcept_ID
SafConceptCode
SafConceptDescription
SafConceptIsActive
SafConceptIsSystem
tc_Rowid
Note Although the field SafConcept_ID is defined as mandatory in the documentation, you
must leave _ID fields blank in the XML file to be imported.
The SAF Concept component is a static component, containing a single table. Complex
components, such as BJournalEntry, contain multiple tables, which are linked by parent-child
relations. The API component documentation lists the component fields and describes them by
name, description, datatype and mandatory status. The documentation also lists the component
tables, but not the parent-child table relations, which are contained in the tc_rowid and
tc_parentrowid fields in the component schema file, and described in detail in the component
API documentation.

Component Schema and Sample Files

Each QAD Enterprise Edition calling program is associated with an XML schema file. The
schema file provides the definition of the component structure.
The XML schema for a calling program such as Supplier Invoice (BCInvoice.XSD) contains all
possible data entry fields in the component, and details the component tables. It also includes the
information required to start data iterations and information on the calling procedure.
The tc_Rowid and tc_Parentrowid fields in each table section indicate the parent or child
table relations.
Sample values for these fields are displayed in the component sample file.
Supported Components
The following table lists the components that you can import using Excel, QXtend Inbound (QXI),
or the XML Daemon:
Table 5.2
Component Schema File
s
bbudgetgroup bcashgroup bcdocument bcinvoicejournalentry

bcurrency bddocument bdebtorcreditrating bdebtorenduser
bdebtorshipto bdebtortype bdinvoice bdinvoicejournalentry
bdomain bemployee bexchangerate.xsd bexchangeratetype
bgl bglcalendar bglmask bjournalentry
blanguage blayer bmirroringgl bmirroringjournal
bpaymentcondition bpaymentformat bpaymentgroup bperiod
bprofile bproject bprojectgroup bprojectstatus
bpurchasetype breason broundingmethod brole.xsd
bsaf bsafconcept bsafstructure bsafstructurelink
bsettings.xsd bsharedset bstate buser.xsd
buserrole bvat bvatbox bvatgroup
bvatperiod byearclosing
Sample XML Files
You can create a sample XML file for all components using the right-click Dump XML option
available in browse results screens. The XML dump file is stored on the application server.
Fig. 5.24
Journal Entry View, Dump XML
The Dump XML feature has two options:

Dump All Fields (QAD XML export format). This option dumps every field in the browse to
XML.
Only dump fields for import (QAD XML Import Format). This option dumps only the fields you
require if you are using the dump XML file to import external data into the application. The
system removes the following non-essential fields from the XML dump:
tContextInfo.tcInvolvedCompanyCodes
tContextInfo.tcCorrelationId
tContextInfo.tcObjectIdentifier
*_ID fields for each table in the XML document/dataset
tc_status fields for each table in the XML document/dataset
The XML files created with this option conform with the schema file for the component, and
provide sample values for all fields and table relations for that record. The data contained in
the dump XML file is specific to the records you selected.
Creating the XML File

The following section describes rules and editing guidelines for XML file content.
tContextInfo Table
Each component schema file contains a tContextInfo table, which must be included in the
XML file to be processed. This table is necessary for the system to process the XML file correctly.
tContextInfo contains the following fields:
tcCompanyCode
The tcCompanyCode field is mandatory, and indicates the code for the entity in which the
data will be processed. If you do not specify the company code, the company code of the
current XML daemon process is used, which can lead to data conflict. The daemon does not
give an error if this code is not specified.
tcAction

The tcAction field is optional. The value of tcAction will only be taken into account if the
XML daemon is configured so that the default action specified in the daemon configuration
can be overridden by the tcAction specified in the XML file.
The possible values for tcAction are:
save
The data is passed to the back end, and the system attempts to validate and save it. If this is
not successful, the load of the XML document fails.
store
The data is passed to the back end. The system does not validate it, but saves the data as a
draft object.
validate
The data is passed to the back end and the system tries to validate it without saving to the
database.
savestore
The data is passed to the back end, and the system tries to validate it. If the data validates,
it is saved to the database. If it does not validate, the data is saved as a draft object. In
Create mode it means that the object is not available as a real object in the system yet, and
needs to be completed. In Modify mode the modification of the object is incomplete, and it
can be completed only by completing the draft object.
tcOriginator
The tcOriginator field is optional. (XML daemon only). It can be used by the external
party to specify the origin of the data. This can refer to an originator defined within the
configuration of the XML daemon, and can indicate if the default action for the originator can
be overridden by the value in the XML file.
tiPriority
The tiPriority field is optional. (XML daemon only). It can be used to indicate the priority
of the XML document. The XML documents in the queue are processed in order of the lowest
value set in tiPriority.
ttRequestStartDate
The ttRequestStartDate field is optional. (XML daemon only). It can be used to indicate
that the object in the XML document can only be processed after a certain date.
tiRequestStartDate
The tiRequestStartDate field is optional. (XML daemon only). It is useful in
combination with ttRequestStartDate to specify an integer value for the time before
which the XML document will not be processed.
tcComment
The tcComment field can be used to specify extra comments for the XML document in the
queue. (XML daemon only). It can be viewed in the XML daemon monitor.
Note The tcComment field can also include:
PartialUpdate=<true/yes>
PartialUpdateExceptionList=t<table>.<field>
These fields exist as separate configurable fields in later releases and are described in
tlPartialUpdate on page 128.
tcCBFVersion
The tcCBFVersion field is mandatory and should contain the expected Component Builder
version number. This field defines the way in which the XML document is constructed. (XML
daemon only). The current version is 9.2.
tcActivityCode
The tcActivityCode field is not mandatory, but is used to indicate the activity that needs to
be executed for the data inside the XML document. If the tcActivityCode field is not
specified, or left blank, the system decides the activity. If it cannot find the object based on the
alternate key, it assumes the object must be created, and assumes that the activitycode is
Create. If it finds the object, it assumes the activitycode is Modify. Possible values are:
Modify
The object is taken in Modify mode. If this is specified, the validation will return an error
if the object does not exist (based on the alternate key field search).
Create
The object is taken in Create mode. If this is specified, the validation will return an error if
the object already exists (based on the alternate key field search).
Delete
The object is taken in Delete mode. The system tries to find the object, and deletes it.
tlPartialUpdate
The tlPartialUpdate field is optional. It can be used to indicate how the system should
treat the data that is passed to it. By default the value of this field is false; this means that the
data supplied in the XML document is assumed to be complete. This is typical for a Create
activity. For a Modify activity, however, tlPartialUpdate is useful in preventing the need
to pass the complete component with all fields. This can be difficult when components have
records in multiple class tables.
If tlPartialUpdate is set to true, the data supplied in the XML document is assumed to be
incomplete. This allows for the situation in which there may be missing tables or fields. The
system then performs a partial update, and does not try to assign default empty values to these
fields, or delete child records.
However, you also have the option to identify records to be deleted. By assigning the
tc_Status field of a child record to D, you indicate to the system that this record is to be
deleted.
In this way, you can use the PartialUpdate option to supply only relevant field data for
integration instead having to supply the complete dataset. PartialUpdate not only
disregards fields that were missing in the input, but also disregards fields that are passed with
an unknown value.
tcPartialUpdateExceptionList
The tcPartialUpdateExceptionList field is not mandatory, and is only read by the
system when the tlPartialUpdate field is set to true.
When a field has an unknown value, the system assumes that this field does not need to be
updated. Use the tcPartialUpdateExceptionList field to specify a comma-separated
list of fields that must be updated in the database, even if their value is unknown.
The syntax for the exception list field names is t<table-name>.<field-name>.
Example tBusinessRelation.BusinessRelationName1

Rowid Fields
The values of the rowid fields in the XML document are used to map the parent-child
relationships between tables. You can assign any values to these fields, while ensuring that the
tc_parentrowid of the child record matches the tc_rowid of the parent. When the system
processes the XML files, it uses this matching to map the tables, then assigns its own values to the
rowids in the database.
Important The tc_rowid value must be unique within the records of the same table in one XML
document.
Example An XML file containing business relation data contains the tables
tBusinessRelation and two tAddress tables, one of which contains a tContact table.
To map these tables, you set the value of the tc_rowid of the tBusinessRelation record to -1.
The tc_parentrowid values of the tAddress child records are therefore also set to -1.
The tc_rowid values of the tAddress tables are set to -2 and -3.
The tContact table is the child of the tAddress table whose tc_rowid is -3. Its
tc_parentrowid is therefore set to -3, and its tc_rowid to -4.
Fig. 5.25
Parent/Child Relations
You must specify the rowid fields if you have multiple record requests in your XML request.
Custom Fields
Most tables contain custom fields (for example, <CustomShort0/>, <CustomShort1/> ).

Unless you have used these fields for customization, you can remove them from your document.
All components have also tCustomTable0, tCustomTable1 and tCustomTable2 tables in
their schema file. These are not mandatory and can also be used for customization of the business
component. If defined, you may want to keep this fields in your document.
Last Modified Fields
These fields are generated by the system and can be removed from your document. For example:
<LastModifiedDate>2009-01-15</LastModifiedDate>
<LastModifiedTime>9874</LastModifiedTime>
<LastModifiedUser>mfg</LastModifiedUser>
ID Fields
ID fields are not necessary for XML integration. These fields are generated by the Financials
component when the file is processed.
You can remove these fields automatically using the Only Dump Fields for Import option in the
Dump XML feature (see Sample XML Files on page 125). For XML files that have not been
created using this option, you can remove the ID fields manually.
For example, in the following section of a supplier invoice sample XML file, you remove the
CInvoice_ID, Company_ID, Period_ID, Creditor_ID, Division_ID, and Journal_ID
fields, but retain the CInvoiceType and CInvoiceVoucher fields:
<CInvoice_ID>738175</CInvoice_ID>
<Company_ID>9144</Company_ID>
<Period_ID>16683</Period_ID>
<Creditor_ID>173655</Creditor_ID>
<Division_ID>11438</Division_ID>
<Journal_ID>271904</Journal_ID>
<CInvoiceType>INVOICE</CInvoiceType>
<CInvoiceVoucher>0</CInvoiceVoucher>
Primary Key Fields
Primary key fields are a combination of fields that combine to uniquely identify the object in the
system.
For example, the primary keys for Supplier Invoice and Journal Entry are a combination of Entity,
Posting Year, Daybook, and Voucher. The Entity, Posting Year, and Daybook require values in an
XML file to be integrated. The Voucher field is generated by the system.
When you modify or delete a record, the <AddressLogicKeyString> key field is also required.
You can view the field by dumping the XML for a particular business object using Actions|
Properties and then Dump XML. You can also query the AddressLogicKeyString key field
using a Progress editor.
Note You cannot view the <AddressLogicKeyString> field in the user interface.
Integrating Multiple Records in an XML Document

You must apply the XML document guidelines described in this chapter to all the records you want
to integrate, and you include all records of the same type (for example, all Employee records) in a
single XML document.
Processing the XML File

The completed XML file can be processed in one of two ways:

Using the XML daemon to collect the file and process it.
The XML daemon processes external XML data. You store the XML file to be processed in a
specified directory on the server. The daemon then reads and processes the file. See XML
Daemon on page 115.
Using QXtend to convert the XML file to a QDoc to be processed by the QXInbound engine.
QXtend Inbound delivers inbound data to business component programs in QAD Enterprise
Edition. The inbound data is in the form of XML data documents, called QDocs, delivered in
either a proprietary XML format or, for a select few programs, as direct code APIs. QXtend
Inbound operates over SOAP (Simple Object Access Protocol), and XML documents must be
contained in a SOAP envelope in order to be processed.
For more information on QXtend Inbound and QDocs, see QAD QXtend User Guide.
Bulk Data Load

The Excel Integration menu activity is available for a number of business components in
Enterprise Financials. For more information on Excel integration, see Introduction to QAD
Enterprise Applications User Guide. However, when importing very large amounts of data to the
system, Bulk Data Load (36.24.8) is a more efficient utility. It is useful when setting up an
implementation.
Bulk Data Load lets you import multiple .csv files into the system at once. It processes the
contents of these files in batches, so that an error in one batch does not cause the entire import
process to fail. You can use Bulk Data Load to import various types of information, as listed in
Table 5.3.
Table 5.3
Information Imported by Bulk Data Load
Business relations Daybooks Projects
COA cross references Employees SAF codes
Cost center masks End Users Sub accounts
Cost centers Exchange Rates Sub-account masks
Customer bank numbers GL Accounts Supplier bank numbers
Customer opening balances Journal Entry Supplier opening balances
Customer Ship To addresses Project Masks Suppliers
Customers
The order of files in the grid determines the order in which the files are imported, with the first file
in the list processed first. To prevent errors, follow the recommended order for importing shown in
Table 5.4.
Table 5.4
Recommended Data Import Sequence
Import Group Sequence File Contents
1 1 SAF Codes
1 2 Business Relations
1 3 Daybooks
1 4 GL Accounts
1 5 Sub-Account Mask
Import Group Sequence File Contents

1 6 Sub-Accounts
1 7 Cost Center Mask
1 8 Cost Centers
1 9 Project Mask
1 10 Projects
1 11 COA Cross Reference
1 12 Exchange Rates
2 1 Customers
2 2 Customer ship-tos
2 3 Customer Bank Number
2 4 End Users
2 5 Customer Opening Balance
3 1 Suppliers
3 2 Supplier Bank Number
3 3 Employee
3 4 Supplier Opening Balance
4 1 Journal Entries
The .csv files for Bulk Data Load have the same column headings as the .csv files used with the
Excel integration feature. You can use the Export to Excel for Maintenance option available in the
Excel Integration menu options to get a template for the file that you want to add in Bulk Data
Load. For more information on Excel integration, see Introduction to QAD Enterprise
Applications User Guide. For example, to see the template for Cost Center Mask, open Cost
Center Mask Excel Integration (25.3.9.2.6), right-click in the grid, and choose Export to Excel for
Maintenance.
Apart from Customer Opening Balance and Supplier Opening Balance, all of the files in Table 5.4
have an equivalent Excel integration facility. To save a template of these two files, open Customer
Opening Balance Create (27.1.10) and Supplier Balance Create (28.1.15), right-click in the
resulting grids, and choose Export to Excel for Maintenance.
Bulk Data Load consists of a Settings section and a grid that lists the files for importing.

Fig. 5.26
Bulk Data Load
The Settings section contains a number of fields:

Field Separator, Decimal Separator, Date Format, Date Separator. These fields contain
information on the formatting of the .csv file contents. The default values for these fields
derive from your computer settings. If the values of these fields do not match the formatting of
the files in the grid, then an error displays. You can modify the contents of these fields to
accommodate the file or files that you want to import.
Note The field separator and decimal separator cannot be the same character.
Batch Size. Specify the number of rows, between 1 and 1000, to include in each batch
processed by Bulk Data Load.
Note Larger batches may sometimes result in faster processing, but can also result in a
connection time-out if the batch size is too large. If an error occurs when processing a batch,
then the entire batch is rejected. The recommended batch size is less than 500.
The Grid section displays the files that you wish to load into the system. There are two methods of
adding files to the grid:
Drag files from an Explorer window and drop in the grid. This option lets you add multiple
files at once.
Right-click on the grid, choose Insert a New Row from the resulting menu, and then select one
or more files using the lookup icon in the File Name field.
There are a number of columns in the grid:
File Name. The name of the file that you are importing. Use the lookup to specify the file, or
drag the file into the grid from an Explorer window.
File Contents. This field displays the type of data that the file contains. The system
automatically detects the type of content in the file and updates this field accordingly.
Status. There are four possible statuses:
Waiting
Cancelled
Complete
Errors
Error Log. If there is an error with the import, then the details of the error are stored in a file
called
<FILE-NAME>-errors.txt
where <FILE-NAME> is the name of the file that you added to the grid for import.
To access the file, click the link in this field.
Unprocessed Data.
If the import does not fully complete, then the lines that are not processed are stored in a file
called
<FILE-NAME>-failed.csv
where <FILE-NAME> is the name of the file that was not fully imported.
To access the file, click the link in this field.
To import the files in the grid, click Import Data. A progress bar appears at the bottom of the
screen to show the files being imported. The name of the file being processed, including the full
path, appears above the progress bar.
Fig. 5.27
Bulk Data Load with Progress Bar
When the import begins, one or more log files are created with information on the progress of the
import. A log file with the name
QAD-Bulk-Data-Load-Logging.txt
is stored in each folder that contains a file to be imported. The file contains information about the
import of files stored in the folder, including the batches processed, and whether the import
completed successfully.

To cancel the import process, click Cancel. The import process stops after the current batch is
processed. Unprocessed lines are stored in a file accessible from the link in the Unprocessed Data
column for the corresponding row in the grid.

Chapter 6
System Control
This chapter describes essential configuration tasks and administrative options.
System Control Overview 138
Explains the functions of the System Control menu.
Database Control 138
Explains how to use Database Control.
System Maintenance 139
Explains how to manage system settings using System Maintain, System Synchronize, System
View System Codes, System Monitor, the Set Debug Level option, and the CT log file. It also
covers server.xml.
Configuring System and User Settings 148
Discusses system and user settings and how to change them.
Making UI Caching Configurable 152
Explains how to configure the system to prevent the UI from automatically caching the result of
method calls.
Configuring Workflow 153
Explains how to configure and change the workflow.
Managing Draft Objects 153
Explains how to use Draft Object Modify.
System Control Overview

The functions on the System Control Menu (36.24) let you configure and manage settings at the
database level. The System Administration function lets you perform the administration tasks
required to configure and monitor QAD Financials. These include tasks to:
Define database control settings.
Configure system and user settings.
Set up workflow.
Database Control
Use Database Control (36.24.1) to set the time zone of the database server and to register a code
for defining unique record identifiers. You should do this before defining users since the time zone
specified here defaults when new user records are created.
Fig. 6.1
Database Control (36.24.1)
OID Generator Code. The OID Generator Code in Database Control is used to assign unique
object identifiers (OIDs) to database records for auditing purposes. The code is assigned
during system implementation.
Based on the OID generator code, the OID fields in the database are populated using an
algorithm that ensures uniqueness across all records, tables, and QAD databases within the
company. The value stored in the OID field for each record has the following decimal format:
<date><seq_value>.<registration_id>
Where:
<date> is the server date with format yyymmdd.
<seq_value> is obtained from a Progress database sequence.
<registration_id> identifies the origin of the OID value.
The registration ID is derived from the OID generator code by reversing the digits of the
generator code value and placing the decimal point in front of the result.
Use Users Time Zone for Default Domain. The Use Users Time Zone for Default Domain
field in Database Control (36.24.1) affects the time stamping of transactions you create in the
default domain. If the Use Users Time Zone for Default Domain field is selected, all
transactions you create in the default domain are dated and time stamped according to the user
time zone specified in User Maintenance (36.3.1), even if a different time zone is defined for
the domain in the Domain record.

System Control 139
If the Use Users Time Zone for Default Domain field is deselected in Database Control
(36.24.1), all transactions you create in the default domain use the time zone defined in the
Domain record. The Use Users Time Zone for Default Domain field is deselected by default.
A users default domain is set in User Domain/Entity Access Maintain. (36.3.4).
Important If you are using the optional Service/Support Management module and the
Multiple Time Zone option is activated in Service Management Control (11.24) for any
domain in the database, you should not activate this field.
System Maintenance
You can use the following activities to manage system settings:
Use Maintain to configure the main system setup definitions.
Use Synchronize during initial system installation and to enable new features after a software
update.
Use View System Codes to display the list of values for fields that display valid values in
drop-down lists.
Maintain
The System Maintain activity lets you configure the system setup, and describes the system-level
values that are applied to all domains and entities.
Note The system settings must be defined before you create domains and entities.
Fig. 6.2
System Maintain (36.24.3.1)
Field Descriptions
Database Language. Choose the system language from the drop-down list. The system
language is used to determine the language of UI elements if a user logs in and no UI strings
are found in the language associated with their user record.
Domain. Enter the code that identifies the system domain. By default this is set to QAD. The
system domain includes default data that is copied to new domains that are created, including
control program settings, default accounts, and generalized codes. The system domain is used
as a template for new domains.
Since the system domain is used as a template, you can add data to it or tailor defaults before
creating new domains based on it. For more information on the system domain, see QAD
Financials User Guide.
System Admin Login. Specify a user ID to be used for system startup activities that can be run
from a shortcut or as a scheduled task in Windows. These activities include system integrity
checking, synchronize, starting the application, and starting the daemons. A valid user ID is
required to ensure that a session can be created. By default this is set to the initial user, mfg.
System Admin Password. Specify the password for the system administration user ID.
Application ID. Specify an ID for this instance of the application (maximum 24 characters).
Reporting Currency. Specify the reporting currency to use for this database.
Important Make sure you specify a reporting currency before you initiate any transactions in
the database; it cannot be modified once GL transactions exist.
Budget Enabled. Select the field to enable budgeting. If you clear the field, the Budgeting
function is disabled, and you cannot create new budgets or modify existing ones.
If your organization does not use budgeting, you should deactivate it to improve system
performance.
Important If you disable the Budgeting module, you also disable to ability to create
allocation transactions based on WBS topics.
Check Budgets on Overlap. Select this field to verify that the same combination of budget
elements (GL accounts, sub-accounts, cost centers, projects, and SAFs) is not being used in
different budget topics or in different budgets. This setting is only applicable for budgets that
also overlap in time; for example, overlapping budget periods. When the field is selected, the
system generates an error message when a conflict occurs.
This verification process adds considerably to the length of time taken to save and run a
budget.
OL Check for Budgets. Select the field to enable the online budget check.
Each time a linked budget account is specified in banking entry, journal entry, customer and
supplier invoices, open item adjustment, or petty cash activities, the system determines if the
new transaction causes the budget amounts to be overrun.
Specific SI Approval. Select the field if the task of approving supplier invoices is assigned to a
specific user role.

System Control 141
After you select the Specific SI Approval field, create a role that corresponds to the approvers
user name; for example, SIAxxxxxx, where xxxxxx is the user name of the approver. Link
the new role to the approvers user name.
Choose the SIAxxxxxx role as approver when you create supplier invoices. When you save
the supplier invoices, the system sends them to the Workflow Inbox of user xxxxxx for
approval. See Configuring Workflow on page 153 for information on setting up the
Workflow Inbox.
Note The Role field displays in supplier invoice activities only if you customize the screen to
add it. See Chapter 12, UI Customization, on page 241.
Business Relations By Domain. Select this field to enable the restriction of business relations
to domains. When you select this field, the Domain Restricted field is selected by default on
each new business relation you create. When a business relation is restricted to a domain, it
can only be viewed and accessed within the domain in which it was created. You can over-ride
this setting by clearing the Domain Restricted field in Business Relation Create. For more
information on business relations, see QAD Financials User Guide.
Invoice Certificate. This field displays QADs shipment and invoice certification number,
assigned by the local government, where applicable. This field is updated using System
Synchronize.
For more information on invoice certification, see QAD Financials User Guide. For more
information on shipment certification, see QAD Sales User Guide.
Version. This field displays the version number of the public and private keys. This field is
updated using System Synchronize.
Public Key. This field displays the invoice certification public key created by QAD. This field
is updated using System Synchronize.
Open SSL Directory. Specify the OpenSSL bin directory. OpenSSL is used to generate the
private and public keys.
This field is mandatory. You cannot enable invoice certification if you have not specified the
OpenSSL bin directory.
Bank File Batch Size. Specify a value between 0 and 200 for the number of lines that you can
include in a batch imported using Process Incoming Bank Files (31.1.6). The default value is
100.
Payment Selection Confirm Batch Size. Specify the maximum number of invoices that you
can include in a batch processed using Supplier Payment Selection Confirm (28.9.4.5) or
Supplier Payment Selection Unconfirm (28.9.4.8). The default is 1000.
See Determining the Optimal Payment Selection Confirm Batch Size for guidelines on
setting the most appropriate batch size for your system.
Note Some batches can be less than the batch size specified in System Maintain. This
situation occurs because the system avoids splitting payments for the same supplier into
separate batches.
For more information on electronic banking and on supplier payment selections, see QAD
Determining the Optimal Payment Selection Confirm Batch Size
The optimal batch size for Supplier Payment Selection Confirm depends on your system
configuration and hardware. The recommended approach is to determine the best batch size for
your system using trial and error. However, you must consider the guidelines in this section.
If you set a batch size that is too high, you incur the risk that one batch cannot be completed
successfully due to system constraints and concurring load conditions.
QAD tests have shown that a batch size of 1000 easily fits within the constraints for most systems.
Therefore, 1000 is the default payment selection batch size. Starting from 1000, you can
experiment and increase the batch size, for example, by 200 at a time and measure the time taken
to process the batch. You can determine the time taken by monitoring the progress bar in Supplier
Payment Selection Confirm.
If a batch of 1200 is processed successfully, try to process a batch of 1400, and repeat this process
until you find the optimal batch size for your system.
Important Tests have shown that a batch size of 1500 is close to the maximum limit on some
systems.
Synchronize
The Synchronize activity is used to initialize a new system and to activate new features following
a software upgrade. It can also be used to update the data in the system such as loading translated
strings.
The system uses a number of database tables that must be current for the software version. Some
components contain a method that updates the system tables. The Synchronize activity calls and
runs these update methods.
Synchronize is typically run directly by the QAD Deployment Tool. You might need to run it for
specific updates, such as installing a new language.
Note If you install a new language, you must synchronize both Translations and Areas, Classes,
and Activities.
See the release documentation to determine if you must synchronize after you install a new
software version. The synchronization must be performed once only.

System Control 143
Fig. 6.3
System Synchronize (36.24.3.2)
Field Descriptions
Selected. Select the areas to synchronize.

Selecting specific areas removes the need to synchronize the entire system, and decreases the
synchronization time.
Update Information. When the synchronization is complete, this column displays the update
status of the area.
View System Codes

The View System Codes activity lets you view the list of values for fields that are validated using a
drop-down list. When an integration is set up with an external system, consult this list to ensure
that the data sent over by that system is valid.
Fig. 6.4
System View System Codes (36.24.3.3)
Field Descriptions
Business Component. Choose the business component for which you want to view the list of
values for fields. The name of the business area is displayed in parentheses beside the business
component in the drop-down list.
Name. Displays the object name in the format:
t<table name>.<field name>
t indicates that the data type is text.
Column Label. Displays the field name as it is used in reporting lookups.
Side Label. Displays the field name as it appears in the UI.
Display Value. Displays the value that appears in the drop-down list in the UI.
Data Value. Displays the system code as it is stored in the database. Use this value when
interfacing from external systems.
System Monitor
Use the System Monitor function to view information about the application. Two sets of
information can be viewed: client settings and application server settings. Click on the various tabs
to see additional details.
Use this information to monitor activity and help in troubleshooting.

System Control 145
Fig. 6.5
System Monitor, Client Settings (36.24.3.4)
Set Debug Level

The Set Debug Level (36.24.3.5) option lets you set the level of detail displayed in the ctlog file.
You can display full business code, including parameter values and database queries. You can use
the ctlog file to run a full trace on component methods and procedures.
Note To run the system log, you must first close all other application screens.
When logging is enabled, you can run the function you want to customize, and then display the
execution flow in ctlog. The log displays the business methods used in the function and how they
are implemented.
The path and filename for the ctlog file are set in the server.xml file and you can view the
filename in the Business Logging entry of the Appserver section of System Monitor (36.24.3.4).
Set the debug parameters and select Save to enable the logging.
Fig. 6.6
Set Debugging Level
Field Descriptions
Limited Business Code Logging. Select this field to log the start and end of all entry-level
business methods. Entry-level methods are called from outside the business logic.
Full Business Code Logging. Select this field to log the start and end of all methods and
procedures, internal and external.
When Full Business Code Logging is enabled, the CT Logfile also traces the execution of
customized code.
Include Parameter Values. Select this field to include parameter values. This field is only
available when you select Limited or Full Business Code Logging.
All Database Access. Select this field to include all read or update database queries. The read
access logs the executed query statement and the number of records read. The update access
logs the action and the rowid of updated records.
Database Update Details. Select this field to include details of all database updates (create,
modify, or delete). The log entry contains the complete updated record.
Unit Testing. Select this field to log possible memory leaks. This logging checks for:
Instances that have not been deleted
Programs that have multiple instances running persistently
Dynamic objects (datasets + temp-tables + queries + buffers) that have not been deleted
Connected appservers
Connected sockets
This logging also lists all persistent procedures and a total count of all database read access
events.
UI Debugging. Click to display the View Performance Results screen and enable UI
debugging.
UI Debugging
The UI debugging option lets you log UI methods and procedures. Select the Enable UI Logging
field to begin logging, and click Refresh to view UI activity. Click Export to export the currently
displayed information to a text file for analysis.
Server-side calls are indicated in red, and UI calls are indicated in blue. Darker red and blue lines
indicate calls that take longer than 500 milliseconds. Each running thread is represented by a node
in the tree view, and every browse or lookup activated creates a new node. You can add user
comments (displayed in orange) to the log.
The Export button allow you to export the log details to a text file
Note UI debugging is activated in system memory, and for performance reasons, you should not
enable the option permanently. Enable UI debugging for specific UI activities, export the thread
for analysis, and then disable the option.

System Control 147
Fig. 6.7
View Performance Results
View CT Logfile
Use this option to view the Code Trace (CT) Log. The CT Log performs a trace on the business
methods used in a function, and is a valuable troubleshooting utility. The location of the log is set
in the server.xml file:
<logging><LoggingDirectory>Directory on the AppServer host</LoggingDirectory></logging>
Note When Full Business Code Logging is enabled, the CT Logfile also traces the execution of
customized code.
Fig. 6.8
View CT Logfile
Field Descriptions
Location of CT Log file. Enter the location of the CT Log file. This file location is specified in
the server.xml file <logging> parameter. With the lookup button you can open a log file
from any location you choose. The Business Logging entry in the Appserver area of System
Monitor details the location of the log file for your current session.
Load. Click to load the file.
Clear Log. Clears the CT Log file during an ongoing session for which the debug level is set.
As a result, the system logs the business logic trace information.
When you click the Clear Log button, the viewer screen is cleared.
Location on the appserver. This field displays the appserver location when you load the file.
The client and appserver may have different mappings to the same location. This is especially
true when you use a UNIX server.
Bottleneck Time (ms). Set a time in milliseconds after which an active business function is
highlighted as a bottleneck. This lets you identify business functions that take a long time to
complete and so may pose performance issues in the application.
Apply. Click to apply this bottleneck period to the log.
Search. Use this text search field to search the file for a text reference.
Images. Log entries are identified by the following types: OK, Warning, Error, Query, Missing
Info.
server.xml
The server.xml file contains the configuration of the business layer of the application. All
configurable settings are included in this file. In this file, you can configure:
The number of components that get cached on the appserver
How to connect to the application databases
The mail server to use
Report settings
Transaction settings
Backend logging
State storage settings
Default data settings
The appserver to start daemon instances
Configuring System and User Settings

The system and user settings defined in these functions apply only to component-based programs;
they do not affect standard Progress programs.
Note When you have changed settings at system or user level, to enable the changes you must
then clear the client cache and re-start the Enterprise Financials appserver.
System Settings
The System Settings function lets you modify system-wide settings that affect the areas of security,
customization, and workflows related to component-based functions.

System Control 149
A subset of the settings can also be modified by users, but only if they are enabled system wide. If
the setting is disabled, users cannot enable it.
The following settings are enabled by default: UI Customization and Automatic Save of Grid
Settings. The others are disabled by default.
Enabling some of the features controlled here may affect system performance.
Fig. 6.9
Change System Settings, (36.24.5.1)
Field Descriptions
Allow Save of Grid Settings. Disable this if you do not want users to be able to choose to save
grid settings. When this is disabled, the Save Current Grid Settings option does not display
when users right-click in a grid. When this is selected, the option does display.
Enable this if you want grid settings saved only when a user specifies.
This setting interacts with the Automatic Save of Grid Settings. When grid settings are
automatically saved, the Allow Save of Grid Settings has no effect.
The following figure shows the right-click grid menu when Allow Save of Grid Settings is
enabled.
Fig. 6.10
Change System Settings, Right-Click Grid Menu
When this option is enabled, individual users can disable it in User Settings if they have
permissions. When this option is disabled system-wide, it applies to all users.
Automatic Save of Grid Settings. Select if you want the system to automatically save grid
settings and reload them the next time users access that function.
Automatic Save of Last Used Browse Settings. Select if you want the system to automatically
save each users last used browse and lookup settings and reload them the next time the user
accesses that function.
When the Automatic Save of Last Used Browse Settings option is enabled, individual users
can disable it in User Settings if they have permissions. When this option is disabled system-
wide, it applies to all users.
Note If you clear the Automatic Save of Last Used Browse Settings field, changes to browse
settings are not saved automatically. However, any changes you make to a browse before you
clear the Automatic Save of Last Used Browse Settings field are saved. If you want to reset the
browse settings to the factory default or customer default, use Stored Search Delete to delete
user-level stored searches. Browse settings are also stored in memory cache; therefore, it is
recommended that you log off the application and log on again after you make changes to the
browse defaults.
Business Logic Version Checking. Select to ensure that all business components register their
versions in the application database. When a component is activated, the system checks the
client version against the server-side version registered in the database. Any inconsistencies
are reported.
Enabling this setting can be useful in ensuring system integrity. For example, if you have
multiple application servers, a patch may be installed on one server and not another. When the
client runs the updated component, its version number is registered. Later, if the other server is
used where the patch is not installed, the system detects that an older version of the component
exists and displays an error preventing the component from being run.
Draft Instances. Select to enable the support of draft instancesrecords saved without
validationin all functions that support Save as Draft. If you clear the field, the Save as Draft
and Browse Draft activities are disabled.
Currently, the Save as Draft feature applies only to the following functions:
Banking Entry
Business Relation
Customer
Customer Finance Charge
Customer Invoice
Journal Entry
Petty Cash
Supplier Invoice
Supplier
Field Security. Select if you want to activate the ability to set permissions and access to
individual fields in the UI. When this setting is selected, the Field Security Maintain activity
displays on the menu; otherwise, it does not. For more information on field security, see QAD
User Interface Customization. Select to enable users with the relevant roles to customize the
UI. See Chapter 12, UI Customization, on page 241.
This option is enabled by default. When this option is enabled, individual users can disable it
in User Settings if they have permissions. When this option is disabled system-wide, it applies
to all users.

System Control 151
Important This option also controls whether browse and grid savings can be saved. When
this field is disabled, the browse and grid settings have no effect, since they are considered to
be a form of UI customization.
User-Defined Fields. Select to enable users with access to customizing the UI to add user-
defined fields (UDF) to customized activities. UDFs can only be added to the UI when the
User Interface Customization field is selected.
Workflow. Select to enable ad-hoc workflow. When the field is cleared, the Workflow choice
on the Tools menu of component activities is disabled.
Selecting this field is typically combined with selecting the Workflow Inbox. However, you
can also notify the recipients of work items through e-mail rather an application Inbox.
For more information on creating and receiving workflow items, see Introduction to QAD
Enterprise Applications User Guide. See Configuring Workflow on page 153 for more
details on setting up workflow.
Enabling workflow adds load to the system, which can degrade performance since the system
must continually poll for new Inbox objects. To reduce this load, have users that will not be
receiving objects in their Inbox disable the feature in User Settings.
Workflow Inbox. Select to activate the Workflow Inbox. When activated, an Inbox area is
displayed on the right-hand side of the .NET UI screen. The system polls for new work items
sent to a logged-in users role and displays them in the Inbox. The polling frequency is defined
in a client configuration file.
Automatic Save of Last Used Stored Search. Select if you want the system to automatically
remember the stored search that was last used in a browse and display it with this search
loaded the next time the user accesses that function.
Enable Persistent Cache. This option caches menu and browse settings from the current
session and re-loads them in the next session. Caching stores static data on the client and
improves performance. You can also set this option for individual users in Change User
Settings (36.24.5.2). If set at the system level, the setting applies to all users. If not set at the
system level, the individual user setting is enabled.
Note Use the Reset Client Cache (36.24.3.7) menu option to clear the persistent cache.
Use Language Specific Object Description. Select this option to display translated
descriptions in the language associated with a users ID in User Maintenance, provided that
descriptions are loaded or entered for this language. The Description fields for most
component-based records support a translation option.
If you select the Use Language Specific Object Description field, the system also retrieves
translated descriptions when the user runs API queries.
If you clear this field, this option is disabled in Change User Settings. If the Use Language
Specific Object Description system setting is selected, the corresponding user setting is
selected by default, but you can clear the setting in Change User Settings.
User Settings
The User Settings function lets each user configure a subset of settings that are defined at the
system level. The settings are effective for the current user only. Users can only modify these
settings if they have been enabled system wide.
Disabling UI Customization can enhance performance for a user.
Fig. 6.11
Change User Settings, (36.24.5.2)
Field Descriptions
Each user can modify a subset of the system settings when they are enabled:
Automatic Save of Last Used Browse Settings. See Automatic Save of Last Used Browse
Settings on page 149.
Automatic Save of Grid Settings. See Automatic Save of Grid Settings on page 149.
Use Language Specific Object Description. See Use Language Specific Object Description
on page 151.
User Interface Customization. See User Interface Customization on page 150.
Enable Persistent Cache. See System Settings on page 148.
Making UI Caching Configurable

You can configure the system to prevent the UI from automatically caching the result of method
calls that are executed in the business logic to retrieve metadata for screens and browses. It may be
important to suppress caching in some situations; for example, if a method is customized, and does
not return the same data in all cases.
You can suppress automatic caching using the CachingExceptions setting in the client-
session.xml template, and homeserver.config.template. Typically, the
CachingExceptions setting contains a list of components or query names that are normally
included in the cache. You can then use the CachingExceptions setting to indicate that the
system must suppress caching for calls to a particular component or query. For example, the
following setting suppresses caching for all method calls and query calls to the component BSaf,
and for the query BGL.SelectGL:
CachingExceptions = BSaf,BGL.SelectGL.

System Control 153
The CachingExceptions setting is processed by the code that implements the caching
mechanism. If the CachingExceptions setting applies for a particular component or query,
the system does not write data to the cache for that query or methods called on that component.
The next time the method for the component or the query is run, the cache will be empty, and this
forces the method or query to be re-executed.
Configuring Workflow
The embedded internal workflow lets users forward or route work items to another role or person
in the organization for completion or validation. It serves as a built-in automated approval process
that can be applied to any record or document created in the system by forwarding work to the
appropriate role. It must be specifically enabled before it can be used.
The workflow is a generic function that can be started from the Tools menu of an individual
screen. The user must have a role that has been given access to create workflows in Role
Permissions Maintain (36.3.6.5) in order to initiate a workflow.
Workflow is also used with the Scan daemon. See for details.
The record attached to the workflow is assigned to a role. All users that belong to that role receive
a notification as an entry in their Inbox. Optionally, when the E-mail Notification check box is
selected, users also receive an e-mail notification. The e-mail address is taken from the user record
in User Maintenance (36.3.1).
You can display the Workflow Inbox as follows:
1 In Change System Settings, select the Workflow and Workflow Inbox fields. See System
Settings on page 148.
2 In Change User Settings, select the Workflow Inbox field. See Set Debug Level on
page 145.
3 Log off from the QAD application; shut down the AppServer.
4 Restart the AppServer.
5 Log in to your QAD application.
An Inbox icon should now display in the upper-right area of the screen. Roll your cursor over
the icon to display the contents; click the icon to open the Inbox.
A system administrator can monitor workflow objects that have been created and never acted on.
In some circumstances these objects may need to be removed from the system, for example, when
an employee has left the company.
Managing Draft Objects

Enabling the Save as Draft and Browse Drafts options in Change System Settings lets users create
draft instances of a subset of components.
System administrators may need to monitor these draft records to ensure that none are left
unattended in the system.
You can use the Draft Object activities (36.24.9) to view, modify, delete, or complete draft objects.
When you modify a draft object, you can assign it to a new owner, change the name by which it is
referenced, or modify whether the object can be viewed by others.
After selecting an object in the view, choose Modify from the right-click menu.
Fig. 6.12
Draft Object Modify (36.24.9.3)
Owner. Specify a new owner for this draft instance if needed. The new owner can modify and
complete the draft instance.
Reference. Modify the name of the draft instance if needed.
Shared. Select this field if you want this draft instance to be visible to others.

Chapter 7
CIM Interface
This chapter describes how to use database utilities to manage the movement and storage of data in
a database.
Introduction to CIM 156
Explains how CIM is used.
Using the CIM Interface 156
Explains the CIM data load and format, and describes the input file formatting rules, input data
types, and data for the input file. Gives a CIM data input file example, and discusses creating a
CIM input file and error handling.
Deleting Records through CIM 162
Explains how to create input files to delete records and gives an example of CIM delete.
Running Multiple CIM Sessions 163
Explains how to run multiple sessions.
Killing CIM Sessions 163
Explains the best way to stop a CIM session.
Introduction to CIM
Transferring data can save disk space, increase disk access speeds by compacting fragmented data,
and integrate legacy or otherwise noncompatible data with QAD data. There are three basic ways
to transfer data into and out of your QAD database:
Dump or load data files.
Archive and delete or reload data files.
CIM load data files.
The first two options are discussed in Chapter 8. This chapter discusses CIM data load, which lets
you load data into your QAD database from any source, as long as the data is formatted to match
the QAD database schema. See page 165.
CIM is typically used to add or modify records in a database. In certain cases, it can also be used to
delete records. Only some functions support this feature. See Deleting Records through CIM on
page 162.
Unlike direct data loads, CIM checks load data for errors and saves unloaded records in an error
file for correction and reloading. CIM loads can be run in either batch or continuous mode.
Note CIM must be executed against character-based programs; it is not supported in the QAD
.NET UI. Additionally, component-based functions in the .NET UI offer different integration
approaches, such as Excel integration, along with the XML and Event daemons.
Using the CIM Interface

The CIM interface loads data through online maintenance programs. All data validation used in
these programs during normal data entry is available during a CIM load. Imported data is then
made available to other programs.
Most of the data loaded through CIM is loaded into a specific domain. The domain used is the one
the user executing the CIM function is currently logged into. If you have access to multiple
domains, make sure you are logged into the correct one before beginning the load.
In UNIX, you can use an external load program to load data continuously. These programs can
accept input from devices such as barcode readers.
If data is loaded directly into tables using dump/load programs or Progress loads, some tables may
not be updated correctly.
Load data into your QAD database using functions on the CIM Interface Menu (36.15). Imported
data can come from:
Any ASCII file that follows the correct conventions.
The output of programs that run in multiprocessing environments such as UNIX.
See CIM Data Format on page 158.

To load a product structure, for example, construct a file that matches the record structure in the
product structure master (ps_mstr), then load data into that table. The CIM interface enables you to
construct a file of input values for Product Structure Maintenance (13.5), and then validates all the
data.

CIM Interface 157
Internally, the CIM Interface operates in two stages:

1 CIM Data Load (36.15.1) loads the external data you specify into batch load data tables
(bdl_mstr and bdld_det) in the database.
2 CIM Data Load Processor (36.15.2) sends data stored in CIM database tables through the
appropriate input screen.
Both the data load and the data processor can be executed as a Progress background session.
Use other functions on the CIM menu to:
Use CIM Data Load Process Monitor to monitor the load process, as needed.
Use CIM Data Load Report/Delete to review processing errors and delete processed data, as
needed.
Fig. 7.1
CIM Data Load
Database
Externally
Externally
Generated,
Generated, CIM
CIM CIM
CIM
CIM
CIM Data
Data
Formatted
Formatted Data
DataLoad
Load Data
DataLoad
Load
Data
Data
Application
Application Standard
Standard
Data
Data Program
Program
When CIM Data Load reads a data load group, it creates a record in the batch data load master
table and assigns it a unique group ID. This integer record contains the name of the program to
receive the data, and the date and time when the record was added. CIM Data Load then creates a
record in the batch load detail table for each line of input data from the data load group. See CIM
Data Format on page 158 for details.
Input from a file can be from either a disk file or a device-character file such as a serial port. If
Input File/Continuous Process is selected, CIM Data Load executes the external program named in
the Continuous Process Name field. The program controls and formats incoming data and sends its
output back to CIM Data Load.
Fig. 7.2
Continuous Data Input
System Formatted Data

Raw Data Formatted Data
Pre-
Pre- Data
Data
Shop
ShopFloor
Floor CIM
CIM
processor
processor Control
Control Database
Database
Device
Device Data
DataLoad
Load
Device
Device Program
Program
System Formatted Data

Raw Data
Data
Data
Shop
ShopFloor
Floor CIM
CIM
Control
Control Database
Database
Device
Device Data
DataLoad
Load
Program
Program
Warning When acquiring external data in real time, run CIM Data Load at the highest possible
dispatch priority to ensure that data loss does not occur as a result of competition with other system
processes.
CIM Data Format

Each program takes in data in groups. A group typically consists of input fields within a frame.
When using a program interactively, you must click Next to move from one group to another. See
Determining Data for the Input File on page 159.
Data going into the CIM load must use the rules described in this section.
The @@BATCHLOAD key word signals the beginning of the data-load group, consisting of one or
more lines. Program name is the system program that will process the input data. For example, if
item data is being loaded, the program name would be ppptmt04.p (Item Data Maintenance,
1.4.3). See CIM Data Input File Example on page 160.
All input data contained between each @@BATCHLOAD and @@END is one group, regardless of how
many transactions are specified in the data section.
Limit the number of transactions to 50. Each transaction entry can involve the creation of many
records. The more transactions in a transaction group, the more system resources are required for
processing, and the greater the likelihood of errors.
An error in one transaction can put all transactions in a group out of sequence and prevent the
system from processing that group. In cases where maintaining data integrity is vital and re-
creating data difficult, you might limit the number of transactions to one.
Input File Formatting Rules

When creating your CIM input file, follow these formatting rules:
Use a single line of data for each input request.
To treat two consecutive input lines as a single line, place a tilde (~) at the end of the first line.
The tilde (~) is not required if you create the CIM file in an editor. Place no characters,
including spaces, after the tilde.
Surround character fields with quotation marks.
At the end of each input group, use a line feed. The end of an input line performs the same
function as clicking Next (F1 in character UI). Fields for which there are no data and that come
at the end of an input sequence do not require hyphens.
Type all characters in lowercase, taking care to spell correctly.
Use a hyphen (-) to Tab through a field, retaining the default or existing value. For example, to
accept default data for fields 1, 2, 3, 5, and 7, and enter Yes, 12, and 01/01/02 for fields 4, 6,
and 8, enter the following:
--- yes - 12 - 01/01/02
Format data as it is entered.
Use a period on a line by itself to indicate End or End-Error.
For repeated input (that is, multilevel), use the period to go back one level. This executes the
End command.
Use slashes (/) where needed. These are not required.
Make sure the date format in the CIM file matches the date format specified in the Progress
session startup parameters (-d parameter).
Use a caret (^) to indicate a null value.

CIM Interface 159
Input Data Types

Input data is information that you would normally enter from your terminal. The manner in which
you enter information in an input file depends on the type of information the field is set up to
handle. There are four types of input data:
Character fields can be alphabetic or numeric but have no mathematical operations applied to
them. Descriptions (alphabetic) and customer codes (numeric) are examples of character
fields. Surround descriptions with double quotation marks ( ). The description is accepted
without quotation marks, but may be interpreted as more than one input. If there is a space in
the description, you must use quotation marks.
Fields used in mathematical operations are numeric values. They can contain a decimal point
(.) or a negative sign (), but no other symbols, including commas (,) and dollar signs ($) are
allowed. Do not use quotation marks for numeric values.
Logical fields use Yes/No values and do not require quotation marks.
Format date fields the way they are formatted in the source field.
Determining Data for the Input File

Each program contains one or more entry groups. Each entry group consists of one or more data
entry fields in which data can be entered before clicking Next.
Example In Site Maintenance (1.1.13) there are four entry groups, corresponding to the number
of times you must click Next. Although direct correspondence between entry groups and frames is
normal, it is not required. The four entry groups are:
Key field groupsite code
Site data
Selection option
Domain data
Each entry group corresponds to one line in a CIM file.

While navigating a program to determine field groupings, use the Tab key to move from field to
field, rather than the Return key. The Return key works like the Tab key in all fields except the last
field in an entry group, where it executes the Next command. This can be misleading in
determining which fields belong to an entry group.
CIM Data Input File Example

/* wocimp.p */
/* Program to create CIM input data file for Work Order Receipt Backflush */
DEFINE VARIABLE wonbr LIKE wo_nbr.
DEFINE VARIABLE wolot LIKE wo_lot.
DEFINE VARIABLE woqty LIKE wo_qty_comp.
DEFINE VARIABLE woyes AS LOGICAL INITIAL yes.
DEFINE VARIABLE wono AS LOGICAL INITIAL no.
DEFINE STREAM bf.
OUTPUT STREAM bf TO batchloa.d.
REPEAT:
PROMPT FOR wonbr wolot woqty.
wonbr = INPUT wonbr.
wolot = INPUT wolot.
woqty = INPUT woqty.
/* See if work order exists in system. */
FIND FIRST wo_mstr WHERE wo_nbr=wonbr AND wo_lot= wolot NO-LOCK NO-ERROR.
IF AVAILABLE wo_mstr THEN DO:
/*Identify beginning of record & program used.*/
PUT STREAM bf @@batchload wowoisrc.p SKIP.
/*The work order number and ID.*/
EXPORT STREAM bf wonbr wolot.
/*qty comp., issue alloc-yes, issue pick-yes*/
EXPORT STREAM bf woqty woyes woyes.
/*Component issue - yes.*/
PUT STREAM bf . SKIP.
/*Display items being issued - no.*/
PUT STREAM bf ..
/*Is all information correct - yes. */
EXPORT STREAM bf woyes.
/* Qty complete. */
EXPORT STREAM bf woqty.
/* Remarks - no. */
PUT STREAM bf - SKIP.
/*Display item and lot/serial detail - no. */
EXPORT STREAM bf wono.
/*Is all information correct - yes. */
/* Please confirm update - yes. */
/* Identify end of record. */
PUT STREAM bf @@end SKIP.
END.
END.
OUTPUT STREAM bf CLOSE.
Creating a CIM Input File

To create a data input file, first determine the program to be used and fields to be updated. The
basic steps are as follows:
1 Run the program that is to receive the data and determine the program name. You can also run
Menu System Report (36.4.4.2).
a In the character interface, use the Ctrl+F key combination to display the program context,
including name.
b In the .NET UI, right-click on the option in the menus and choose Properties to display
program details.
2 Determine the programs key fields. These are typically the first fields, and always let you
advance to the next field by pressing Next.
A good test is to position the cursor in a field, and click Next. Note where the cursor goes.
Reposition the cursor in the field, and press Return. If the cursor moves to the same place as it
did when using Next, embed Next (Carriage Return) in your CIM file. If the cursor went
elsewhere, embed a Return. You could still embed Next if this new cursor position did not lead
to any field you want to populate.

CIM Interface 161
An input file must contain values for key fields, each on a line by itself. This allows the Next
command to apply to the appropriate field.
Note which fields are validated or secured. Do this by typing any character (for example, x)
and pressing Enter. If a warning displays, the field is validated or otherwise constrained. Your
input file must conform to valid choices for the field. Use the lookup browse for a list of valid
entries.
3 Choose non-key fields you want to populate and in what sequence. Note whether Next or
Return is required after each entry.
Not all fields have labels. For example, a two-line description can consist of two separate
fields. To determine which lines correspond to which fields, place the cursor in each line and
press Ctrl+F to display their field names. You must populate each field with a separate entry in
a CIM file.
Note In the QAD .NET UI, field names display as field tips.
4 Record a template of the CIM input file entries for the first frame.
The following is an example template for Item Master Maintenance (1.4.1):
@@BATCHLOAD ppptmt04.p
10-10000
EA Oasis Cooling System Home/Indust Model
Remember, all CIM files start with @@BATCHLOAD <Program Name>. The Item Number (10-
10000) is a key field and is required. It must be on its own line. The second line represents the
next three fields in the entry group.
Follow Item Number with Next. The next line fills in the UM and Description fields. Note that
Description is shown as two entries, one populating the first line, one populating the second.
Note There are a few cases where CIM load does not work, such as costing data in Item Master
Maintenance (1.4.1). In this case, costing data has to be CIM loaded through Item Element Cost
Batch Load (1.4.15); see Figure 7.3.
Fig. 7.3
Item Element Cost Batch Load (1.4.15)
Use the following code to load this data.

@@batchload ppptmt04.p
10-10000
Ea Oasis(TM) Cooling System Home/Indust Model
1000 5/28/1992 Config AC DISCRETE 10-10000 AB
.
@@end
Error Handling
When the CIM load is completed, CIM Data Load Processor (36.15.2) creates a report showing the
groups successfully processed and any processing errors. Groups containing an error are not
processed. Troubleshoot errors using the following guidelines:
Are the values appropriate?
Is there a line reading: @@batchload?
Is there a line reading: @@end?
Are the data in the correct order?
Are there any blank lines?
Are there any misplaced spaces?
Is there an end-of-line for each data set?
Does it complete the record?
Did the first error cause all the others?
Deleting Records through CIM

You can use CIM to delete records created with any of the programs listed in Table 7.1. In each of
these programs, an updateable, single-character field, batchdelete, exists at the end of the
header- and detail-record key frames. This field can be updated only when the program is accessed
through a batch process, that is, when batchrun = true.
Note In the character UI, when you press Ctrl+F in a field of a program with batchdelete enabled,
a pop-up window appears, indicating that you can use batch delete.
Table 7.1
Programs with batchdelete Functionality
Menu Label Program Name
Customer Item Maintenance ppcpmt.p
Generalized Codes Maintenance mgcodemt.p
Site Maintenance icsimt.p
Price List Maintenance pppimt.p
Price List Maintenance pppcmt.p
Item Master Maintenance ppptmt.p
Installed Base Item Maintenance fsisbmt.p
Because the batchdelete value exists at the end of key frames, it does not affect existing CIM
input files and can be omitted from these files when not used. Since it is only one character,
unlabeled, and hidden, the field also does not change the visible interface.

CIM Interface 163
Creating Input Files to Delete Records

Use these guidelines when creating input files that include deletes:
1 To determine if batchdelete is enabled in a particular program, check the list in Table 7.1.
2 To invoke the batch delete functionality, place an x at the end of the header- or detail-record
key frame line in the input file.
3 Follow the key frame with a blank line consisting of a single hyphen so that the program
executes the code that would be executed if an F5 or Ctrl+D has been pressed in the first frame
after the key frame.
4 Enter a subsequent line containing the string yes as an answer to the Please Confirm Delete
prompt displayed for online deletes.
Example of CIM Delete

This sample CIM input file deletes a Site Maintenance record:
@@BATCHLOAD icsimt.p
mysite
--
x
-
yes
@@END
Running Multiple CIM Sessions

Any number of CIM sessions can be run at one time. However, two load sessions cannot be
opened for a single file. To run two sessions, divide the file.
When running multiple sessions, use CIM Data Load Process Monitor (36.15.4). The monitor
shows the state of all existing CIM sessions. Type and Process Session are indexes to the sessions.
Enter Process in Type and use (/) to first see all the Process sessions, followed by the Load
sessions. If you select Next at the Session field, the current status of the processes displays
continuously. The display shows startup time, last transaction time, and selection criteria used
when the session was started.
Killing CIM Sessions

Although a CIM session runs under the operating system and can be stopped using operating
system commands, this is not advised. When the operating system kills a session, your QAD
application is not notified and a record of the session may still display in the CIM Data Load
Process Monitor (36.15.4).
The best way to kill a CIM session is to use the Process Monitor. To kill a session, identify the
session using the Type and Session fields then press the F5 key in the Session field. A prompt asks
you to confirm that you want to delete this record.
If the session was invoked with a low-dispatch priority, your monitor may still display a session
after it has been stopped, with a status of Killed. To erase the session from the system, delete it
again by putting the cursor on the Session field and pressing F5.

Chapter 8
Database Management
This material covers utilities for monitoring database size, performing dumps and loads, reloading
archive files, managing database sequences, registering applications, and monitoring license
compliance.
Managing Database Size 166
Explains how to determine disk usage and free disk space.
Dumping and Loading Data 167
Discusses dump/load procedures.
Deleting and Archiving Data 168
Lists transactions that can be deleted or archived. Provides information on Audit Detail
Delete/Archive and on restoring archive files.
Integrity Logging 170
Explains how to use the Corrupt Logging function.
Registering Licenses 171
Gives a licensing overview; explains how to use License Registration and run license reporting.
Managing Database Sequences 180
Explains how to initialize sequences, maintain sequences manually, maintain sequences using
CIM, maintain audit trails, and maintain sequences in Oracle.
Component Record Numbering 185
Explains how to use Record Number Maintain.
Setting Up Multiple Time Zones 186
Explains how to use Multiple Time Zones Maintenance, use Multiple Time Zone Load Utility, and
set a default time zone.
Managing Database Size

You can use system utilities for managing the size of your database.
Determining Disk Usage

Use Database Table Size Inquiry (36.16.1) to dump selected tables and review their sizes. The
program requires adequate free disk space to run. Reported table sizes may be understated since
indexing overhead is not taken into account.
Use Disk Space Inquiry (36.22.13) to display free space for each available disk, in blocks. For
most UNIX environments, a block is typically 1024 bytes. For Windows environments, blocks
range from 1024 to 8192 bytes. Consult your hardware manuals for exact specifications.
Note These programs must be run from a character user interface.
Fig. 8.1
Disk Space Inquiry (36.22.13)
/ (/dev/vx/dsk/rootvol): 956656 blocks 464665 files
/proc (/proc ): 0 blocks 4453 files
/dev/fd (fd ): 0 blocks 0 files
/tmp (swap ): 7823264 blocks 381700 files
/opt2 (/dev/vx/dsk/crsu03_dg/vol04): 2757000 blocks 948168 files
/dr01 (/dev/vx/dsk/crsu03_dg/vol01):46291736 blocks 12355240 files
/dr02 (/dev/vx/dsk/crsu03_dg/vol02):48571390 blocks 12427225 files
/dr03 (/dev/vx/dsk/crsu03_dg/vol05): 9841572 blocks 2461436 files
/opt.new (/dev/vx/dsk/crsu03_dg/vol03): 8622328 blocks 2448537 files
/users/cmb (qcrhp01:/disks/drive2/d7/users/cmb): 654480 blocks -1
files
/users/dzn (qcrhp06:/dr4/users/dzn): 422860 blocks -1 files
/users/svc (ohhp04:/home/u3/svc): 1401846 blocks -1 files
/users/fxd (ohhp04:/home/u3/fxd): 1401846 blocks -1 files
/users/pzd (ohhp04:/home/u3/pzd): 1401846 blocks -1 files
/users/byd (qcrhp01:/disks/drive2/d7/users/byd): 654480 blocks -1
files
/users/rbe (qcrhp01:/disks/drive2/d7/users/rbe): 654480 blocks -1
files
/qad/mfgpro/85db/etfdb(ohhp40:/dr01/85db/etfdb): 9285970 blocks -1 files
/users/svb (ohhp04:/home/u3/svb): 1401846 blocks -1 files
/users/ncr (ohhp04:/home/u3/ncr): 1401846 blocks -1 files
/users/scq (qcrhp06:/dr5/users/scq): 3373932 blocks -1 files
Freeing Disk Space

There are three ways to reduce the size of a Progress database:
Use dump/load programs to compact your data. Compacting data can increase disk access
speeds significantly. To do this, dump all data from your database, and reload it into an empty
database. You need free disk space amounting to about 70% of the total size of your data (.d)
files. Progress recommends that you dump/load once a year.
Use delete/archive programs to create free database space. Typically, the largest tables in a
database contain history, sales order, and purchase order data. The amount of disk space may
decrease if you store the archived data on the same disk. See Deleting and Archiving Data
on page 168.
Use both dump/load and archive/delete programs. To do this, remove records from the
database, dump the remaining data, and reload it into an empty database. You need plenty of
free disk space to do this.

Dumping and Loading Data

Dump/load programs move the contents of database tables into or out of ASCII files. The dump
procedure reads a database table, puts quotation marks around the data value of each field, and
places those values in an ASCII file.
Example A record in the user master table (usr_mstr) consists of the following entries:
usr_lang FR
usr_site 1000
usr_user1
usr_user2
usr_user pxr
One line in the dump file would read:

FR 1000 pxr
You can use dump files as input to other programs after converting the files to CIM input-file
format. You can also take output from other programs, convert it to CIM input-file format, and
load it into the database. This assumes the data has the correct form, based on the screen flow and
format the CIM input is duplicating. The Database Definitions book contains details on specific
table formats. See Using the CIM Interface on page 156 for details.
Dump/load procedures are located at 36.16.4 for Windows clients and at 36.16.3 for UNIX
environments. Load procedures do not overwrite existing records. You must delete the old data
first.
Note Progress and Oracle each provide dump/load and import/export programs, but these
programs do not maintain the integrity of data in the QAD database. See the Progress user
manuals.
Dump/Load Procedures
To dump/load data:
1 Back up the existing database.
2 Check available disk space. A full dump/load requires free space equaling approximately 70%
of existing database size. See Determining Disk Usage on page 166.
3 Log in to your QAD system in single-user mode. You can speed up the dump/load by running
multiple sessions of Database Table Dump/Load from multiple terminals.
4 Execute Database Table Dump/Load for the correct range of tables.
If there is enough free space, select all tables. If there is not, archive the dumped files to a tape,
then erase them from the database. Repeat this step as needed.
5 When the dump is finished, copy the standard, empty QAD database (mfg) onto your old
database.
6 Load the dumped files back into the database using Database Table Dump/Load.
Data files (.d files) reloaded into databases containing data do not overwrite existing records.
Files to be loaded must be in a directory specified in your PROPATH. A Progress bulk load is
usually faster than a dump/load, but can require an index rebuild.
The system lists load errors in a .e file located in the directory you ran the process from.
Deleting and Archiving Data

Delete/archive programs remove selected records from the database, letting you archive them to
tape or other media. Each delete/archive screen looks similar to a report criteria input screen. You
choose records based on selection criteria. Criteria can include date ranges, document numbers,
employee names, and so on.
Table 8.1 lists data that can be deleted and archived.
Table 8.1
Transactions that Can Be Deleted/Archived
Audit Detail Bulk Pick History Call/Quote History
Closed Cumulative Orders Closed Intersite Demand Closed PO Shippers
Closed Projects Closed Purchase Orders Closed Purchase Receipts
Closed Purchase Closed Service Requests Comment Cross-References
Requisitions
Containers Contract Revenue Contracts
Correction Invoices Cumulative Orders Customer Schedules
Deferred/Accrued Detail Forecasts Distribution Order Shippers
Revenue
Electronic Sig Failures Electronic Signatures Empty Bulk Picks
Engine History Expired Call Quotes Expired Sales Quotes
Expired Warehouse Holds Family Hierarchies Field Notifications
Flow Schedules GL Transactions Inbound EDI Documents
Inspection History Installed Base History Intersite Requests
Intrastat History Inventory Consumption Inventory Transactions
Inventory Transactions Invoice History Kanban Transactions
Logistics Charges Logon History Lot Masters
Master Bills of Lading Operation History Operation Plan Simulations
Operation Plans Outbound EDI Documents Pending Calls
Performance Data Physical Inventory Tags Product Change Orders
Product Change Requests Product Structures Purchase Order Shippers
Q/LinQ Documents Quality Orders Quality Test Results
Requisitions Retired Fixed Assets Routings
Sales Analysis Sales Order Shippers Self Bills
Sequence (NRM) Service Contracts Service Requests
Service/Repair Orders Shippers Subcontract Shippers
Supplier Performance Data Supplier Schedules Tracked Documents
Transaction History Turnaround Data Uninvoiced Receipts

Verbosity Data WIP Lots Work Orders

Zero Inventory Balances
Audit Detail Delete/Archive

Use Audit Detail Delete/Archive (36.23.1) to delete/archive audit detail information. Unlike other
delete/archive programs, this program does not delete each record specified. Instead, for each
unique combination of user ID, table, and field, it keeps the latest record and deletes/archives the
rest.
To delete and/or archive tables:
1 Back up your database and .df files.
1 To safeguard against data archived from a previous product version that has different schema,
back up the current database definitions (.df) file with each archive/delete run. This lets you
reconstruct a corresponding database for data retrieval.
2 Verify record selection.
Run the delete/archive program without deleting or archiving records. This generates a report
showing selected records. Review the report and if records selected for deletion are correct,
proceed with the actual archive/delete.
3 Run appropriate historical reports such as Invoice History Delete/Archive (7.13.23).
4 Determine selection criteria for the records being deleted, and run the delete/archive program,
selecting both Delete and Archive.
The program creates a xxyymmdd.hst file in the default directory where xx is the record
identifier, such as iv for invoices and yymmdd is the archive date.
5 Verify deletion of records from the database.
6 Verify the contents of the .hst file using the appropriate operating system command.
7 Back up the .hst file to storage media and delete from system.
The delete/archive program does not reduce database size. To reduce database size, use a
dump/load program.
Restoring Archive Files

Use Archive File Reload (36.16.5) to reload an archive file after restoring the file from backup
media to the system disk.
Fig. 8.2
Archive File Reload (36.16.5)
The reload process puts data from the archive file back into the database exactly as it was when
you deleted it. However, if base data has changed, you may encounter errors.
Example You are reloading accounts receivable history for a customer that has been deleted.
Select Allow Errors to continue processing when errors occur. The system lists load errors in a .e
file located in the directory you ran the process from.
Important Date and time in the stored data are formatted based on the country code associated
with the user who archived the data. If a user with a different date and time format reloads the data,
load errors and corrupted data can occur.
To avoid these problems, use the same user settings when archiving and reloading the data. Before
loading data, use User Maintenance (36.3.1) to temporarily change your country code to match
that of the user who archived the data. For more information on User Maintenance, see QAD
Integrity Logging
The Corrupt Logging function identifies referential integrity problems in the database tables
related to component activities, and stores results in a file.
Corrupt Logging Maintenance (36.16.7) has the following activities:
Mark as Reported: Marks the list of current logs as reported. Previously reported logs are not
displayed the next time.
View: Displays the current list of corrupt logs. Select a row to display detailed information on
the log.
Delete: Clears the logs.
Fig. 8.3
Corrupt Logging, View (36.16.7.1)
Field Descriptions
Report Date-Time. Displays the date and time at which the error was detected.
Table. Displays the name of the table in which the error occurred.
Key. Displays the key field of the record that must be corrected.
Description. Displays a description of the error.

Reported. Indicates whether the error or issue has previously been marked as reported.
Login. Displays the ID of the user who encountered or generated the error.
Business Method. Displays the business component method in which the error occurred.
Registering Licenses
When you receive your QAD software, you also receive license codes for the foundation product
and other separately licensed applications.
The license codes identify the license type, version, expiration date and number of days remaining,
and number of users, sessions, or transactions for which your site is licensed. Before you can use
the system, you must register the license codes.
License registration programs are provided under the License Registration menu (36.16.10). Use
the license registration programs to:
Register newly installed software.
Upgrade software to add new users or sessions.
Maintain and report historical license data.
Report detailed and summary license violations.
Report license usage and user activity for QAD-conducted audits.
Licensing Overview
QAD licenses software to its customers for use by a predetermined number of users, sessions, or
transactions.
The following sections describe concepts associated with license types, license violations,
violation types, violation messages, and registration interaction with other QAD modules.
You can use User Monitor Inquiry (36.16.12) or other license-related reports to monitor user
activities and application use.
Licensing updates and data, such as user counts and violations, are recorded in Universal Time,
Coordinated (UTC). See UTC and Transactions Outside Domains on page 190.
License Types
Two license types apply to users:

Named User. Each unique user ID defined in User Maintenance (36.3.1) is counted as a user.
There is no limit on the number of sessions each defined user can run simultaneously. Multiple
sessions for the same user ID are counted as one user.
Concurrent Session. Each concurrent login is counted as a session. If a single user logs into
multiple sessions simultaneously, each login is counted. See Violation Types on page 172.
User Counts
License usage is monitored regardless of your user interface type, database type (Progress or
Oracle), or license type.
For concurrent session license types, the system counts the number of active sessions when you
log in and compares the count to the number of licensed sessions stipulated by the license
agreement.
If you change to a domain in another database, this process is repeated because changing databases
is exiting the current database and starting a new session. Whenever you switch databases, the
system stores the logout date and time. The time is recorded using UTC.
Note If you use the QAD .NET UI, each time you run a program and detach it in a separate
window, each window counts as an individual session.
For named user license types, the software counts users when system administrators create new
users in User Maintenance (36.3.1) or activate user access to applications in License Registration
(36.16.10.1). See Violation Messages on page 173.
License Violations
When the number of users or sessions exceeds the number stipulated by your license agreement,
license violations occur.
The system stores all license violation occurrences in the database. System administrators and
QAD auditors can run reports to view the violation data. See License Reporting on page 176.
The system responds to license violations with either violation errors or violation warnings. With
errors, messages display and the system prevents additional users or sessions. With warnings,
messages display, but additional users or sessions can exist and users can still log in to QAD
applications.
System administrators can implement enforcement of license agreements by selecting the Enforce
Licensed User Count field in Security Control (36.3.24). Setting this field determines whether
errors or warnings display and what action the system takes. For more information on Security
Control, see QAD Security and Controls User Guide.
Important The first time a warning displays, you can continue log in to complete transactions or
other processing. If you receive repeated warnings, contact your QAD sales representative or
distributor to upgrade your license.
The system prevents users from logging in if the license registration record does not exist for the
foundation product in License Registration (36.16.10.1).
Violation Types
The system records the violation types listed in Table 8.2.

Table 8.2
License Violation Types
Violation Type Description
Date Expiry Displays information about violations that occur when an
applications license registration expires. Only evaluation, demo,
or temporary licenses have expiration dates.
Application Usage Displays information about violations that occur when users do
not have access to an application.
License Count Displays information about violations that occur when the
number of users or sessions exceeds the amount stipulated by the
license agreement.
Non-Licensed Displays information about violations that occur when users
Product attempt to run applications that are not registered.
Violation Messages
Table 8.3 lists error messages that display when license violations occur.
Table 8.3
License Violation Error Messages
Message Explanation and Solution
Expired license code The license code expiration date for this application has
passed.
Contact your QAD sales representative or distributor to
obtain a new license code. Register new code in License
Registration (36.16.10.1).
Product registration is not The licence code data in your environment has been
valid corrupted or is missing.
obtain the correct license code; register correct code in
License Registration.
Application not available in Your environment license data has been corrupted or is
licensed application master missing.
Contact customer support to reload valid license data.
Licensed user limit exceed This message displays in User Maintenance and License
Registration when the number of users exceeds the number
specified by the license.
System administrators can deactive some users; otherwise,
contact your QAD representative or distributor to upgrade
your license agreement.
Customer is not licensed to You selected a menu item that is not covered by registered
execute this license codes.
module/product: # Contact your system administrator to determine the correct
menu items for you to access.
System administrators should contact their QAD
representative or distributor if the license code is not
correct or if they wish to purchase this additional module.
User not authorized to run You have not been authorized to run this product.
this application: # System administrators authorize users to use products in
User Maintenance or License Registration.
Message Explanation and Solution

This product expires in # The license code for this application expires in the number
days on # of days indicated.
obtain a new license code; register correct code in License
Registration.
Concurrent session limit The application you are attempting to access has a
exceeded concurrent session license type and the maximum number
of active sessions for this application has been reached.
If this error displays during login, you cannot log in unless
another currently logged-in user logs out.
Interaction with Other System Data
The license registration programs use data from other programs to process, maintain, and report
license data.
System administrators maintain defined named users and a list of registered software applications
that users are authorized to access in User Maintenance (36.3.1). License registration software
uses this information to prevent more active users than the license allows.
User Maintenance also includes information that more clearly defines the user. The system ships
with a default set of user types predefined in Language Detail Maintenance (36.4.2). The set
includes the employee, customer, and QAD user types. It is important for user count and system
monitoring purposes that users are correctly identified in User Maintenance before complete
license registration functionality can be used. See Language Detail Maintenance on page 39.
License Registration
Use License Registration (36.16.10.1) to:
Add a new license code for the foundation QAD software or separately licensed QAD
modules.
Upgrade license codes to add sessions or users.
Remove license codes.
Fig. 8.4
License Registration (36.16.10.1)

The system requests licensing information after you install your base QAD application or
separately sold modules and when you attempt to log in with an expired license.
Use the Tab key to select a license code task:
Add. The Add Product frame displays. Enter the license code for the foundation product or a
separately licensed module; then choose OK.
The application name, description, version, license type, and number of licensed users display.
When you add a license code, you are prompted to enter the IDs of users who can access the
application. A list of users who can access the product displays once you enter a user ID. See
Granting Users Access to Registered Software on page 175.
If you try to add an application that is already registered, the following message displays:
Product already installed
Edit. The Edit Product frame displays. Use this frame to upgrade your license to increase users
or sessions.You must obtain the new number from your QAD representative or distributor.
After you enter the code and choose OK, you are prompted to enter the IDs of users who can
access the application.
Remove. The Remove Product frame displays. Enter the license code for the application you
want to remove from registration. A prompt displays, asking you to confirm the license
removal. If you select Yes, the system records the removal date and time. The application is no
longer registered, and users cannot execute any programs that are a part of it. If you remove
the MFG/PRO license code, you will be logged out of the system, and users cannot log in.
Granting Users Access to Registered Software
You must grant users access to registered software. If a user who does not have access tries to start
an application, either an error or warning message displays depending on the value of Enforce
Licensed User Count in Security Control (36.3.24).
Access to applications is granted in one of two ways:
1 Assign access to individual users by selecting registered applications in the Application List
frame in User Maintenance (36.3.1). For more information on User Maintenance, see QAD
2 Activate users for a newly registered application in License Registration (36.16.10.1).
After you successfully enter a license code in the Add Product or Edit Product frames, the system
displays the Add Authorized Users frame. You can specify a user ID to display a list of users
starting with this ID or enter the word All. When you enter All, the list displays with all users
selected, as indicted by an asterisk. You can deselect any that you do not want to include.
Note If the total number of users exceeds the number allowed by the application license, the
system makes the first users in the list active. For example, if there are 100 user IDs displayed, but
the license agreement for the application is for 50 users, the first 50 users are made active for the
application.
If you need to authorize more users than your license allows, system administrators can add users
through User Maintenance (36.3.1); however, the software records a violation of your license
when you add more users.
License Reporting
Various reports let you monitor application use, the number of logged-in users and sessions, the
programs in use, and license violations. You can use the application usage and user count reports
to be informed about potential license violations.
In addition to license reporting, you can use User Access by Application Inquiry (36.3.22) to
display a list of applications, user access status (active or inactive), and access activation date.
Licensed Application Report
Use Licensed Application Report (36.16.10.3) to display a list of software applications registered
in the database.
You can select a range of applications to display. Selecting Show Only Active Licenses displays
the current license code for an application. Clearing this field displays information on current and
expired license codes for applications. Records display in descending order of the registration date.
If there are multiple records for one application, the record with the latest registration date displays
first.
The report includes the application description and version, license code and type, number of
licensed users, registration and expiration date, user ID of the person who registered the
application, audit date information, and any changes to license information.
Audit date information is recorded and displayed in Universal Time, Coordinated (UTC).
Fig. 8.5
Licensed Application Report (36.16.10.3)
Application Usage Profile Report
After you install and register an application, the software keeps statistics about your application
use. The statistics include:
Licensed application name
Menu item executable program name
Number of times the menu item is accessed
Percentage of the application in use at the time of reporting
You can use Application Usage Profile Report (36.16.10.8) to display the recorded information for
each licensed application.

Fig. 8.6
Application Usage Profile Report (36.16.10.8)
You can generate the report in summary or detail format. Summary reports display only the
module, access count, and percentage of application use. Detail reports display all recorded
information about application usage.
Detailed License Violation Report
Use Detailed License Violation Report (36.16.10.13) to display information about license
violations, including:
Violation date, time, and error message. The time and date are printed in UTC.
User ID and name of the person who is in violation
Violation type (for example, application usage or license count exceeded). See Violation
Types on page 172.
The total number of sessions and users logged in at the time of violation
Session ID at the time of violation
Percentage of the application in use at the time of violation
Detailed license violation reports let you select a range of registered applications, dates, user IDs,
or violation types on which to report.
Fig. 8.7
Detailed License Violation Report (36.16.10.13)
Summary License Violation Report
Use Summary License Violation Report (36.16.10.14) to display:

Application name, version, and license type
Violation date
Total number of violations
Total number of violations by violation type

Maximum number of licensed users logged on during a period or the high water mark
Total number of licensed users
Summary license violation reports let you specify the application and the period you want the
report to cover.
Fig. 8.8
Summary License Violation Report (36.16.10.14)
If you do not specify an application, all violations for all applications display. If you specify an
application, but no dates, all violations for that application display.
If you run either report and there are no violations to report, the following message displays:
No violation observed.
Audit Reporting
Use User Count Audit Process Report (36.16.10.16) to generate a set of files that can be used by
QAD personnel when they perform a user count audit to evaluate compliance with license
agreements.
Optionally, you can archive previously reported audit data to an external history file and delete it
from your system, or delete without archiving. You can also have the program delete unneeded
user records from the system while generating the audit records.
Fig. 8.9
User Count Audit Process Report (36.16.10.16)
Customer Number. Enter the customer or end user number that QAD has assigned to your
product installation.
The system uses this number as part of the identifier information in the generated files.
If you do not know your customer number, contact your QAD representative or QAD Support.
Historical Audit Data. Specify the way you want the system to manage historical audit data
after generating the audit files:

Archive: The system creates an additional dated subdirectory (archive_YYYY-MM-DD)

under the specified Output Directory. That subdirectory includes an archive file using the
naming convention <customer number>-UCA-<logical db name>-yyyymmdd-<time>.hst.
The file contains audit data that is more than 400 days old.
After archiving the records, the system deletes them from the database. If required, you can
restore records from an archive file to your system using Archive File Reload.
Note that the archive directory may include a second file. lvYYYMMDD.hst contains the
audit records that were used by the original audit module. User Count Audit Process Report
has replaced that legacy functionality.
Delete: The system deletes audit data that is more than 400 days old from the database. Note
that no archive file is created. If you want to maintain historical data outside your system, you
should set this field to Archive.
Retain: The system does not delete or archive historical audit data.
Delete Inactive Users. Enter Yes to delete User Master records for any user IDs that have
never been used to log in to the system.
You can use this option to clean up unneeded user IDs that may otherwise be included in
license counts.
Note The system selects records based on the Active field in the Application List frame of
User Maintenance. For each user where that field is No for application MFG/PRO and the user
ID has never been used to log in, the system deletes the user record.
Output Directory. Enter the path to the directory where the system will create the files to be
used for user count audits. If the directory does not exist, the system prompts you to attempt to
create it from within the program.
When you execute the program, the system places the files in a subdirectory named in the
format qad_YYYY-MM-DD.
If you select Archive in the Historical Audit Data field, the system also creates the
archive_YYYY-MM-DD subdirectory.
User Monitor Inquiry
User Monitor Inquiry (36.16.12) displays users currently logged in, along with the:
License type and count for the application
Program names and menu numbers they are currently executing
Session ID and user interface type for the session
Time since they started the current program or menu. The time is recorded and displayed in
Universal Time, Coordinated (UTC).
Amount of time they have been idle if no program is selected
This inquiry represents a single point in time, not a continuous system record or audit trail.
By monitoring user and program activity, the system administrator can identify users in violation
of license agreements and minimize unnecessary overhead during peak system usage.
You can enter a combination of login time and users, applications, or menu selections to view
details of a specific login scenario.
Fig. 8.10
User Monitor Inquiry (36.16.12)
Application. Enter the application name for which you want information to display. You can
enter a range of applications by specifying the first application to display in this field and the
last application to display in the To field.
Menu Selection. Enter the menu selection for which you want details to display. Leave blank
to begin with the first menu matching the other selection criteria.
Login Time. Enter the login time for which you want details to display.
Enter the time based on a 24-hour clock in HH:MM format. For example, enter 1:30 pm as
13:30.
User ID. Enter the ID of the user for whom you want details to display. Leave blank to begin
with the first user ID matching the other selection criteria.
Sort Option. Enter the number that corresponds to the way you want to arrange information in
the User Monitor Inquiry. You can sort by:
User ID, which sorts the data in alphabetical order by user ID.
Idle Time, which sorts the data by the length of time a user has remained on a menu. The
user with the longest idle time displays first.
Program time, which sorts the data by the length of time a user has remained in a program.
The user with the longest program time displays first.
Managing Database Sequences

When a unique identifier is needed by a system function program, the system often uses a control
field to store the last number used. The system also supports the use of a special schema element
called a sequence.
A sequence is a database element used to generate a stream of sequential values for assigning
unique identifiers to records. Sequences allow fast, accurate numbering, and reduce the amount of
time the system spends validating uniqueness.
Note Because the sequence is generated at the database level, records viewed from within a
domain may appear to have gaps.
Use Sequence Report (36.16.15) to display a list of sequences defined in the database. The
sequence description indicates the database table and field that is updated by the sequence. For
example, the description of sequence cmt_sq01 is cmt_det.cmt_indx.

Sequences have the important advantage of speed and reducing the possibility of record locking
and contention. However, each sequence is a separate database element, distinct from the table to
which it applies. This means that sequences must be initialized correctly whenever you use
Database Table Dump/Load.
If sequences are not initialized correctly, Duplicate Unique Key errors may occur when users
attempt to create transactions.
If dumping and loading are done as part of installing a software upgrade, sequence initialization is
automatically performed by the installation utilities. However, if you perform a dump/load to
consolidate tables or increase database size, you must initialize sequences yourself. This is true
also if you consolidate data from two different databases.
Use Database Sequence Initialization (36.16.17) to reset sequences to the highest value plus 1
after loading data.This program works with both Progress and Oracle databases.
Use Sequence Maintenance (36.16.13) to manually reset a sequence number to a specific
value in a Progress database.
Use Sequence Inquiry (36.16.14) or Sequence Report (36.16.15) to view sequence
information.
To guarantee database integrity, perform sequence maintenance:
In single-user mode sessions only
As a required part of your standard database maintenance
Note To avoid accidental update to sequence structures, use menu security to protect sequence
maintenance functions.
Initializing Sequences
Database Sequence Initialization reads each table that uses sequences and sets the sequence
number value to the highest number plus 1. This ensures that each new record created has a unique
number. This utility initializes sequences correctly in both Progress and Oracle databases.
Fig. 8.11
Database Sequence Initialization (36.16.17)
Maintaining Sequences Manually

Maintain sequences manually or through the CIM interface. Maintenance includes:
Dumpingoutputting the current sequence value to a file
Loadingreading a sequence value from a file
Updatingmanually updating a single sequence
See Maintaining Sequences in Oracle on page 184.

Maintain sequences in Sequence Maintenance (36.16.13). Sequence Maintenance works with
Progress Relational Database Management System (RDBMS) only. Oracle dataservers are not
currently supported.
Log File Name. The name of the error log file.
Directory. The operating system (OS) directory where you want to store the file.
After you enter the log file name and directory and click Next, a second Sequence Maintenance
frame displays. Enter data for the following fields in this frame:
Sequence Name. Specify the sequence or set of sequences to be maintained. Leave blank to
specify all sequences.
Note A time stamp is added to the log at the beginning of each session, so session history can
accumulate. After a maintenance session, check the log for errors.
Maintenance Activity. Specify the maintenance activity to be applied to the specified sequence
sets. Valid values are:
1 to dump. Outputs the current sequence value to an OS file.
2 to load. Reads the sequence value from the OS file.
3 to manually update. This activity can only be performed when a single sequence is
specified. When a set of sequences is to be manually updated, the manual update activity
is called once for each.
Activity Directory. For a dump or load, specify the OS directory where the sequence files are
located. The direction of the data flow is determined by the activity.
Files are named using the name of the sequence with the file extension .d. For example, the
sequence tr_sq01 is dumped to a file named tr_sq01.d.
When you specify manual update, the system displays the Manual Update frame. Specify the
following in the frame:
Original Sequence Value. This field displays the value of the sequence before the users
update was applied.
Current Sequence Value. This field displays the current sequence value.
Note Sequence Maintenance generates a report listing current values of all sequences in the
database. It can be run at any time and does not impact the content of sequence structures.
User Input. Enter any sequence value within the valid range. The valid range is determined by
the system and is part of the schema. An error displays when the value entered is not within the
valid range.

Maintaining Sequences Using CIM

Sequences can be maintained using the CIM interface. The content of a sequence represents the
last value applied to the sequence by a call from a a system function. This value is not available for
processing, since it was consumed by another process. See Using the CIM Interface on
page 156.
Values used to update a sequence are validated against a range of acceptable values for the
sequence, as established in the database schema. The value of the sequence can be within and
including the boundary values. You receive an error message when the range is exceeded.
Limitations of CIM
Some limitations to maintaining sequences through the CIM interface are:

Sequence maintenance must be performed in a single-user mode Progress session. The
integrity of the sequence value is not guaranteed if maintenance is done in multiple-user mode.
Destructive updates are not permitted. A CIM update cannot overwrite previously created
files. Data dumping does not proceed if any elements in the set of sequences conflict with an
existing OS file.
You cannot manually update from CIM. CIM is an automatic process.
Any error causes the sequence maintenance to fail. When you suspect a sequence maintenance
activity failed while processing, you must repeat the entire process. This guarantees that the
sequence values are valid.
Sample CIM File Format
A typical CIM file might look like the following illustration:

Line 1: <log file> <log directory>
Line 2: <sequence name>
Line 3: <action>
Line 4: <input-output OS directory>
<log file>. The name of the file receiving the output log. When an existing log file is specified,
the current CIM output is appended to the end of the existing log. The default value is the
value of the mfguser variable. This has the format of TMP9999 where 9999 is a four-digit
number that uniquely identifies the CIM session. If the mfguser value is NULL (), the log
file is named mgsqmt03.
<log directory>. The location where the log file is stored. The blank value NULL () is
specified as the default. When a <log directory> is not specified, the <log file> is
placed in the PROPATH.
<sequence name>. Specifies the set of sequences to be maintained. You can specify a single
sequence or the entire set. The default value is NULL (), indicating all sequences will be
maintained.
<action>. Specifies the activity to be performed, either (1) dumping or (2) loading. The default
activity is dumping (1).
<input-output OS directory>. The directory in which the sequence files are maintained. The
default value is the local directory.
A time stamp is issued to the log file at the beginning of each session. This permits the same log
file to accumulate a history of the session logs. All log files have the .log suffix.
Example The following is an example of a working CIM file:
@@batchload mgsqmt01.p
sq_err.log /qad
-
2
/qad/backup
@@end
This file outputs the error log to the directory /qad with the name sq_err.log. All sequences
are maintained. The hyphen () indicates that the default value, in this case all sequences, is
accepted. Number two (2) indicates that the sequences are loaded. The directory in which the
sequence files are maintained is /qad/backup.
Note Only sequences currently implemented can be maintained using CIM.
Maintaining Audit Trails

The system maintains audit trail for all updates made to sequences using sequence maintenance
routines. Each sequence has a separate set of audit entries.
For each updated sequence, the audit trail records original and final values. If the current value is
the same as the original value, the system creates only one record.
Maintaining Sequences in Oracle

Normally, you use Database Sequence Initialization to set the starting sequence values in an
Oracle database. The following information is provided if you need to manually maintain
sequence values in Oracle, which cannot be done using Sequence Maintenance.
The standard sequence definition in Oracle is:
CREATE SEQUENCE <sequence name> START WITH <initial value>
INCREMENT BY 1 CACHE 75
Where <sequence name> is the same as defined in the Progress df and <initial value> is
the starting value specified by the customer.
The initial value of a sequence is set to the highest value found in the field related to the sequence.
The content of a sequence is the last value applied by a system function. See Maintaining
Sequences Manually on page 182.
Example In a database with no user transaction processing, the maximum value of
tr_hist.tr_trnbr is 1010. This value is used as the starting value of the sequence.
As user qad, you would enter the following SQL:

DROP SEQUENCE tr_sq01;
CREATE SEQUENCE tr_sq01 START WITH 1010 INCREMENT BY 1
CACHE 75;

Component Record Numbering

The Record Numbering function lets you set a starting number for a specific business component,
for example, numbers for printed checks. Numbers are always generated by financial year and by
entity.
Usually, the number is reset to one at the beginning of a new fiscal year, but you can also set it to a
certain value during the accounting year. To add a new number, right-click in the grid and choose
Add New Row.
Note It is recommended that only experienced system administrators use this feature. Changes to
the numbering system are logged for audit, and unauthorized changes could lead to issues of
accounting legality where gaps in the numbering sequence result.
For external daybooks, sequence numbers are generated by the external transaction. However, the
numbering function still generates a number series, which will be unused. The system also
validates duplicates when numbers are passed from an external application. For transactions
originating externally, the Record Number function is only used if a sequence number is not
passed from the external system.
The Record Number function supports a single activity, Maintain, which lets you modify the
numbering system. You cannot modify an existing number, but you can right-click and add a new
row, to reset the sequence for a numbering type.
Fig. 8.12
Record Number Maintain (36.16.21.2)
Field Descriptions
Status. Displays the status of the number. When creating a number record, the field is
automatically filled with the status Free.
The numbering statuses are as follows:
Free: The number is being used for the first time.
Claimed: The system selects the lowest available number in the series with the status Free or
Released. If the transaction has not been saved, the system assigns the status Claimed to the
number. When the transaction is saved, the system removes the number from the list of
available numbers. If the transaction is not saved, the system assigns the status Released to the
number.
Claimed numbers are currently being used by a running transaction.
Example Numbers 18 and 19 are claimed by running transactions. The transaction that
claimed sequence number 18 is abandoned and 18 is released. Sequence number 18 then
becomes the next available number, even though 19 is already used.
The Claimed status is also required because, in a client-server environment, if the connection
is lost, the number will remain claimed on the client side. This is repaired the next time the
server is started and system housekeeping takes place.
Released: The number was used previously for a transaction that was not saved. The system
releases the number again for use for the next transaction.
Draft: The number is used in a draft object. If the object is deleted, the system sets the number
status to Released. The system removes the number from the list of available numbers when
the user saves the draft object.
Year. Specify the accounting year for which you want to create a numbering sequence. The
combination of the number year and type must be unique within the entity.
Type. Specify the accounting daybook or number series for which to create the number series.
The combination of the number year and type must be unique within the entity.
Number. Specify the first number in the numbering sequence. If you do not specify an initial
value, the system starts with 1. Each value in the sequence is incremented by one.
Setting Up Multiple Time Zones

Accommodating variations in local time is a special global business challenge. The Multiple Time
Zones Setup menu (36.16.22) lets you create and maintain time zone data.
Use Multiple Time Zones Maintenance (36.16.22.1) to define and maintain multiple time
zones, including the changes required by daylight savings time.
Use Multiple Time Zones Inquiry (36.16.22.2) and Multiple Time Zones Report (36.16.22.3)
to display and report time zone information.
Use Multiple Time Zones Load Utility (36.16.22.13) to load sample time zone data.
Use Domain Create (36.1.1.1.1) or Domain Modify (36.1.1.1.2) to specify the time zone that
applies to a particular domain.
You should restrict access to these programs, with the possible exception of the report and inquiry.
Do not change time zone information without carefully evaluating the impact.
Multiple Time Zones Maintenance

Use Multiple Time Zones Maintenance (36.16.22.1) to define and modify time zones.
Note The Multiple Time Zones Load Utility lets you load your own time zone data.

This program supports two ways of setting up a time zone:

In the simplest format, you can base a time zone on an offset from GMT.
The system can also track daylight savings time adjustments from a baseline you set.
If you choose the second approach, you must specify when the change in time occurs. You can also
use effective dates with time zone information, if the start and end points for daylight savings time
only apply for a range of years.
After you define the time zones, you can generate reports with Multiple Time Zones Report
(36.16.22.3). Figure 8.13 illustrates Multiple Time Zones Maintenance.
Fig. 8.13
Multiple Time Zones Maintenance (36.16.22.1)
Time Zone. Enter an eight-character label identifying a time zone.
Description. Enter up to 40 characters describing this time zone. The description appears in the
time zone lookup.
Auto Period Adjust. This field indicates whether the system should adjust the time zone you
are defining for a given periodusually daylight savings time or its equivalent.
Selected: Define the period to be adjusted in the subsequent detail frame.
Clear: Time Period defaults to STD (standard). You cannot change it.
Time Period. This field is editable if Auto Period Adjust is selected. Valid choices are STD for
standard time, Day for daylight-saving time, and Sum for summer time. You can define details
for two periods: a standard period, and a special adjusted period for daylight savings or its
equivalent. This field determines which of the detail fields are required.
Note Set up values for time period as language details to reflect the terms you use.
Start Year. Enter the beginning year of the range associated with this time zone definition. In
some countries, the implementation of time zones varies from year to year. Using start and end
dates, you can set up multiple records effective at different periods of time.
End Year. Enter the ending year of the range associated with this time zone definition. If you
do not know when the current definition ceases to be effective, use an end year such as 9999.
GMT Offset. Enter the actual offset in hours and minutes from Greenwich mean time (GMT)
for this time zone. Enter this number with either a plus sign (+) or minus sign () indicating the
direction of the offset.
GMT is the base for establishing the relationships among time zones and is never affected by
daylight-saving time adjustments.
Month. Specify the month in which daylight savings starts or ends. The month is expressed as
a numerical value between 1 and 12. For January, enter 1; for February, enter 2, and so on.
This field is mandatory.
Weekday. When Auto Period Adjust is selected, enter a number from 0 to 7 indicating the day
of the week when the time change occurs. In the U.S., time changes always occur on Sunday
(1).
Enter 0 if the change occurs on the date in the Start Date field, regardless of the day of the
week on which it falls.
Enter a number in the range 1-7 corresponding to Sunday through Saturday if the change
occurs on a certain day of the week.
Week. Specify the week in the month in which daylight savings starts or ends. The week is
expressed numerically and must be a value between 1 and 5, where 5 indicates the last week in
the month. You can only use this field if you also specify a value in the Weekday field.
Note The Week field only takes effect if the Weekday field contains a non-zero value.
You can use this field and the Month and Weekday fields to define cases where daylight
savings time begins on a particular weekday in a month, rather than on a set date every year.
For example, in the US, daylight savings time begins on the second Sunday of March and ends
on the first Sunday of November.
Day. Specify the particular day in a month on which daylight savings starts or ends. The day is
expressed numerically and must be a value between 1 and 31. You can only specify a value in
this field if the Weekday field is set to 0.
You can use this field and the Month field to define situations where daylight savings time
begins on a particular date in the year. For example, in Honduras, daylight savings time began
on 7 May, 2010.
Time. When Auto Period Adjust is selected, enter the exact time of day, using a 24-hour clock,
when the time change occurs. Enter this time in standard time.
In the United States, enter 02:00 when switching from standard time to daylight-saving time,
but 01:00 when switching from daylight savings time back to standard.
Multiple Time Zone Load Utility

Use the Multiple Time Zone Load Utility (36.16.22.13) to load your own set of time zone data.
QADs default time zone data is loaded automatically during the installation process. You need
only use the Multiple Time Zone Load Utility if you want to load your own time zone data. QADs
default time zone data is located in the $QAD_EE_INST_DIR/db/mfg directory.
After you load your time zone data, verify that the time zones are valid and appropriate for your
business practices. Use Multiple Time Zones Report (36.16.22.2) or Inquiry (36.16.22.3) to review
definitions and ensure they conform to your requirements. Each organization is responsible for
maintaining and updating time zone data to correspond to changing realities and business
requirements.
If needed, you can delete existing time zone data and reload your time zone data.

Figure 8.14 illustrates the Multiple Time Zone Load Utility.

Fig. 8.14
Multiple Time Zone Load Utility (36.16.22.13)
Load Time Zone Data. Select this field to indicate that you want the system to load your own
time zone data.
After loading, verify that the time zones are valid and appropriate for your business. Use
Multiple Time Zone Report or Inquiry to ensure the definitions conform to your requirements.
Delete Existing TZ Data. The system considers this field only when Load Time Zone Data is
selected. If you are loading time zone data, you can also delete current time zone definitions.
Use this feature if you want to reinitialize the sample data.
Time Zone Data Directory. Specify the directory from which to load the time zone data.
If you select the Load Time Zone Data field, this field is mandatory and cannot be blank.
Setting a Default Time Zone

The Use Users Time Zone for Default Domain field in Database Control (36.24.1) affects the time
stamping of transactions you create in your default domain. See Database Control on page 138.
Important If you are using the optional Service/Support Management module and the Multiple
Time Zone option is activated in Service Management Control (11.24) for any domain in the
database, you should not activate the Use Users Time Zone for Default Domain field.
Domain Time Zone

Each domain can be associated with a time zone, and all transactions in the domain are assigned
system dates and times based on that time zone. Use the Time Zone field in the Domain record to
specify the time zone that applies to a particular domain.
When using your QAD application, if you change to another domain with a different time zone,
that time zone now applies and any transactions you create in that domain are assigned dates and
times relative to the time zone you have switched to. When calculating the time zone offset, the
system also determines whether daylight savings time is in effect for that time zone, and adjusts
accordingly.
If the Use Users Time Zone for Default Domain field is activated in Database Control (36.24.1),
your default time zone from User Maintenance (36.3.1) is used when you switch to your default
domain. The Use Users Time Zone for Default Domain field is deactivated by default. See
Setting a Default Time Zone on page 189.
UTC and Transactions Outside Domains

Any transactions you perform before you log into a domain are recorded in Universal Time,
Coordinated (UTC).
UTC was formerly known as Greenwich Mean Time (GMT), and uses a 24-hour system of time
notation, where 1:00 am in UTC is expressed as 0100. The use of UTC time ensures that
administrators can easily compare times and dates across multiple time zones.
Any transactions that are not tied to a particular domain are also recorded in UTC; for example,
session master, user monitor, user logon date, license violation, and product registration record
updates.
The following table lists the database tables and programs that timestamp updates in UTC:
Table 8.4
Functions that Use UTC
Table Date Field Time Field Programs
sess_mstr sess_date sess_time Web program that
sets/resets context when
launching (mfwb02.p)
Session Context Manager
(mfsessmg.p)
Appserver Session
Manager Program
(mfsemstr.p)
Login program to check the
user ID and starting session
context (mflg01.p)
usr_mstr usr_last_date usr_last_time User Inquiry (mguriq.p)
usr_logon_date usr_logon_time Force Password Change
Utility (utfrcpsw.p)
User password library
(mgurlib.p)
User Maintenance
(mgurmt.p)
User Password
Maintenance (mgurmtp.p)
Session Initialization
Procedure Library
(mfinitpl.p)
mon_mstr mon_login_date mon_login_time Displayed Sorted License
Monitor Output
mon_date_start mon_time_start
(lvmoninq.i)
mon_idle_time User Count and Licensing
(lvgenpl.p)
User Monitor Inquiry
(lvmon.p)

Table Date Field Time Field Programs

cnt_mstr cnt_date cnt_time User Count and Licensing
(lvgenpl.p)
User Count (lvcount.p)
Lock Session and Monitor
Records (lvlock.p
lvr_det lvr_date lvr_time Summary License Violation
Report (lvlvsrp.p)
Detailed License Violation
Report (lvlvdrp.p)
User Count and Licensing
(lvgenpl.p)
pin_mstr pin_inst_date pin_inst_time Dialog for Entering PIN
Numbers (lvpin.p)
pin_aud_date
pin_aud_ddate (lvreg.p)
pin_mod_date Licensed Application
Report (lvlarrpa.p)
pex_mstr pex_inst_date pex_inst_time Dialog for Entering PIN
Numbers (lvpin.p)
pex_aud_date
pex_aud_ddate (lvreg.p)
pex_mod_date Licensed Application
Report (lvlarrpa.p)
hwm_det hwm_date hwm_time Summary License Violation
Report (lvlvsrp.p)
User Count and Licensing
(lvgenpl.p)
uslh_hist uslh_hist uslh_time Session Initialization
Procedure Library
(mfinitpl.p)
Appserver for the API
Procedure Library
(mfaspl.p)
Logon Attempt Report
(mgurpsrp.p)
lua_det lua_in_date lua_in_time User Count and Licensing
(lvgenpl.p)
lua_out_date lua_out_time
License Violation
usg_det usg_date Delete/Archive (lvldup.p)

Chapter 9

This chapter includes information on master table audit reports, system cross-references, which let
you identify how and where fields and tables are used, application server definitions, operating
system commands, and delete/archive utilities. The Statutory-Currency Utility is also described.
Generating Auditing Reports 194
Discusses auditing and other reports.
Using System Cross-References 194
Explains how to use the System Cross-Reference menu, with background information and
information on table, field, and menu reports, using program reports, and updating cross-
references.
Setting Up Application Servers 198
Discusses the process AppServer, including how to define one, and gives an example of using the
AppServer to run MRP.
Using Operating System Commands 204
Describes different operating system commands and how to use them.
Using Delete/Archive Utilities 204
Explains how to use Audit Detail Delete/Archive and GL Transaction Delete/Archive.
Statutory-Currency Utility 205
Describes how you can use a utility to change the statutory currency of a domain, even after
transactions have been posted.
Command Line Application Control 207
Explains how to use the application control program.
Generating Auditing Reports

You can review modifications to tracked master tables using Master Data Audit Report (36.17.1),
which prints changed records in master tables. The report includes the database table name, current
version of the changed record, user ID of the person who made the change, and date.
The system offers other auditing functions:
Auditing information for unposted general ledger (GL) transactions is maintained when GL
Transaction Audit Trail is selected in GL Operational Transaction Control (36.9.13). When
selected, any changes made in Unposted GL Trans Correction (25.13.16) are logged.
GL Trans Correction Audit Report (25.13.17) shows changes made to unposted GL
transactions (accounts, sub-accounts, cost centers, and projects) using Unposted GL Trans
Correction
Use Change Tracking Maintenance (36.2.22) to track changes to sales order detail fields. See
Tracking Changes on page 27.
Other Reports
Use Master Comments Report (36.17.5) to print the text of master comments selected by a range
of references and by type and language.
Use Control Tables Report (36.17.6) to generate a report listing the current values defined for all
control tables in the system. This report is especially important during implementation. It enables
you to verify that settings are appropriate for your business environment.
Using System Cross-References

The System Cross-Reference menu (36.18) contains programs that identify how and where fields
and tables are used within standard Progress programs.
Note These functions do not report any information about component-based functions.
System cross-reference activities can be customized to reflect your system setup. This lets you
update cross-references when you add or change menu items. If you do not customize the system,
you can use the cross-reference as it is.
The cross-reference database requires about 50 MB of disk space, and consists of a set of reports
summarizing database relationships such as:
Which X and Y are used by this Z? X, Y, and Z can be tables, fields, menu items, or programs.
Used can mean referenced, updated, or called.
Which database tables are referenced or updated by this menu item?
Which menu items call this field?
Which program source files use this include file?
You construct a cross-reference in two steps:

1 Compile the entire system.
2 Build a bill of material from the menu structure.

The end result is a bill of material for each program, in which all programs called by the initial
program are components, as well as fields called or updated by those programs.
Cross-reference reports provide different ways of organizing the bill of material.
Background
The core modules of QAD Enterprise Applications consists of approximately 6200 programs that
call some 10,000 fields. The programs consist of normal, executable Progress programs (.p files)
and include files (.i files), which can be called from many different .p files.
The menu system calls approximately 1400 of those 6200 programs. These called programs call
numerous other .p and .i files. Progress programs can be nested, enabling you to place .i files
within .i files, and so on.
These Progress programs read or change information in database tables, such as the item master
(pt_mstr) or the printer master (pr_mstr). The database tables consist of records containing entries
in a group of fields.
When Progress is compiled, the list of programs called and the tables and fields read or potentially
updated by those programs can be output. This output, along with other utility information, is the
source of the cross-reference.
Table, Field, and Menu Reports

The eight cross-reference reports answer such questions as What does this table, field, message,
menu item, or program do? The syntax is XYZ. For example, the Tables/Fields by Menu Report
tells you what tables X and/or fields Y are called by or updated by menu item Z. Similarly, Menu
Item by Message Report tells you which menu items X/Y call a particular message Z.
Table 9.1
Table, Field, and Menu Reports
Program Name Description
Tables/Fields by Menu Shows what tables or fields are referenced or updated by
Report (36.18.1) programs called by a top-level menu. Limit searches further by
execution file, database table, and field. Report includes the
type of actions performed by the selected programs on each
table or field listed. Action types are create, search, update,
delete, and access.
Tables/Fields by Similar to 36.18.1, but not limited to menu-level programs.
Program Report Shows what tables or fields are referenced or updated by the
(36.18.2) named Progress program.
Before running this report for a top-level program, first use
Program Source File Report (36.18.16) to generate a list of
subprograms called by the program. Then, run Tables/Fields by
Program Report for each relevant subprogram.
Menu Items by Shows which menu items call a field or range of fields. Further
Field Report (36.18.4) limit searches by execution file and database table. Shows field
name and table, calling menu item, and kind of action
performed. Action types are create, search, update, delete, and
access.

Menu Items by Similar to 36.18.4, but limited to a database table or range of
Table Report (36.18.5) tables, rather than fields. Shows which menu items call a table
or range of tables. Further limit searches by execution file and
menu item. Shows table name, menu item, execution file, and
kind of action performed. Action types are create, search,
update, delete, and access.
Menu Items by Shows which menu items call a particular message or range of
Message Report messages. Further limit searches by menu and execution file.
(36.18.6) Shows message numbers and message text.
Messages by Menu Shows all the messages called by a particular menu item.
Item Report (36.18.8) Further limit searches by menu and execution file. Shows
message numbers and message text.
For all reports, the top-level selection is the first one searched. To speed up processing, enter
values in the top level.
Using Program Reports

Program reports list all programs.i files and .p filescalled by a menu item.
Table 9.2
Program Reports
Programs by Field Shows all programs that call a particular field or range of fields.
Report (36.18.13) Further limit searches by table name and program name. The
report includes the following:
The name of the database table to which each selected field
belongs.
The names of the programs and subprograms that reference
each selected field.
The types of actions performed on selected fields by each
program or subprogram listed. Action types are create,
search, update, delete, and access.
This program may be useful when a field characteristic has
been changed and the programmer wants to know what
programs are affected.
When you generate a report on programs that reference a
specific field such as pt_part, programs using phrases like
where so_part=pt_part are not included in the report.
Programs by Table Similar to 36.18.13. Shows all programs that call a particular
Report (36.18.14) database table or range of tables. Further limit searches by
program name. Useful when a table has changed.
Program Source File Creates a list of program components, or bill of material, for a
Report (36.18.16) specified program or range of programs. Shows all component
parts, including nested executable files and include (.i) files,
that are directly called by the specified programs.


Program Run Report Creates a multilevel list of components, or bill of material, for a
(36.18.17) specified program or range of programs. Shows all component
parts, including nested executable files and include (.i) files,
that are either:
Directly called by the specified parent program
Indirectly called by subprograms or include files that are, in
turn, called by the specified parent program
Use the Levels field to specify the number of levels to include
in the report. For example, set Levels to 1 to list only the
subprograms and include files directly called from the parent
program.
Source File Where- Shows which executable files use a specified source (.p) or
Used Summary include (.i) file or range of files. Useful if you change an
(36.18.19) include file and want to see the executable files affected.
This program does not list intermediate include files. Use
Source File Where-Used Detail (36.18.20) to generate a report
on intermediate include files as well as top-level program files.
Source File Where- Similar to 36.18.19. Shows which executable files use a
Used Detail (36.18.20) specified source or include file; also shows intermediate
include files.
in the report. For example, set Levels to 1 to list only the
executable files that directly call the specified source or include
files.
Run Program Where- Shows which source (.p) and include files (.i) reference a
Used Detail (36.18.21) specified subprogram. Lists both top-level source files and
intermediate include files. Useful if a called program has
changed, and you want to check the behavior of the calling
programs.
in the report. For example, set Levels to 1 to list only the files
that directly call the specified subprograms.
Program Summary Bill Creates a list of components, or bill of material, for a specified
File Create (36.18.23) program or subprogram, showing all files in the order in which
they are called. List includes all subprograms called by the
specified parent program, as well as fields updated by those
subprograms. Can include multiple calls of the same file.
Report output is placed in an ASCII file, where you can
manage it using operating system tools.
For example, if you change the name of a called program, use
Program Summary Bill File Create to make sure you change
each instance of it in the source code.
Updating the Cross-Reference

The cross-reference is built by compiling programs, then checking the compiled programs against
the menu. If you change menus or change programs, rebuild the cross-reference using Cross-
Reference Update Menu (36.18.24).
Rebuild cross-references as follows:
1 If the source has changed, run Cross-Reference Update from Source (36.18.24.1).
2 Run Missing Component Program (36.18.24.15), Missing Menu Execution File (36.18.24.16),
and Programs with No Menu Exec (36.18.24.18) reports.
These reports show any errors in menu or program listings. Missing Menu Execution File
Report, for instance, shows names of programs called by the menu that do not exist.
3 After making corrections, add parent-component relationships not included in step 1. Missing
parent-components are supplied by the cross-reference.
4 Run Menu Item Cross-Reference Create (36.18.24.3) to link all cross-reference items with the
menu.
5 Delete obsolete cross-reference items.
Setting Up Application Servers
Progress AppServer
The Progress Open Application Server, or AppServer, is a brokered collection of 4GL engines that
can execute Progress programs on the server in response to remote client requests. Each
AppServer instance is identified by a unique name, and contains a broker that manages a pool of
4GL engine processes, each of which is available for processing client requests. See the Progress
documentation for more information on setting up and using AppServers.
The client connects to an AppServer indirectly through the Progress Name Server. This provides
for location transparency (and also provides the logical basis for load balancing and failover) since
the clients do not need to know the host and port of the AppServer broker. The client only needs to
know the unique name of the AppServer broker, which is used by the Name Server to determine
the brokers host and port.
Each AppServer instance can be configured to have its own set of parameter values, such as the
PROPATH, database connections, startup/shutdown procedures, and log files. These parameter
values are specified in the ubroker.properties file, located in the DLC\properties
directory, where DLC is the Progress installation directory.
One extremely useful example of the AppServer is to improve the throughput speed of the
processing-intensive task of running material requirements planning (MRP). The AppServer can
distribute processing load across multiple threads, dramatically improving performance. For more
information on MRP, see QAD Manufacturing User Guide.
As an example of how an AppServer can be used, this chapter includes instructions for setting up
an AppServer to support enhanced MRP performance. See Example: Using an AppServer to Run
MRP on page 200.

Before you can run applications using a Progress AppServer, the AppServer instance must be
defined in AppServer Service Maintenance (36.19.1).
Defining the AppServer

Use AppServer Service Maintenance (36.19.1) to define the information needed to connect to a
Progress AppServer.
You can specify a set of standard connection parameters used to connect to this server. Optionally,
you can also define server-specific parameters required by the AppServer.
Note The example shown in Figure 9.1 includes the data you would enter to define an AppServer
used to improve MRP performance. See page 200.
Fig. 9.1
AppServer Service Maintenance (36.19.1)
Service Name. Enter a name to identify this application server.
Description. Optionally enter a description of the application server.
Application Service. Enter the name of the Application Server defined in the
ubroker.properties file during configuration of the AppServer.
IP Address or Host Name. Enter the IP address or host name used as the -H parameter when
connecting to this application server. This is the IP address or host name of the machine on
which the application server is running. If the AppServer is running on the same machine as
your QAD database, enter localhost.
Port Number. Enter the port number used when connecting to this application server.
If you are running a Progress name server, enter the name server port number. The default
value is 5162.
Otherwise, enter the port number on which the AppServer is running.
Parameters. Optionally enter any other parameters required when connecting to this
application server.
E-mail User ID and E-mail Level. These fields are not implemented and have no effect on
processing.
Example: Using an AppServer to Run MRP

This section shows a practical example of how to set up an AppServer to dramatically improve the
performance of MRP.
To use the MRP AppServer, you need to perform three main tasks:
Modify the ubroker.properties file for the AppServer instance.
Configure the AppServer.
Start and stop the AppServer as required.
For more information on MRP, see QAD Manufacturing User Guide.
Modify the Properties File
To set up an AppServer to support MRP processing, you must add a set of parameters to the
Progress ubroker.properties file to identify information about the AppServer instance.
You can modify ubroker.properties in two ways:
Manually edit the file.
Use the Progress Explorer tool to change parameters through a graphical user interface. The
Explorer tool is available only on Windows.
Progress Explorer can also be used to start and stop the AppServer, and for remote administration.
1 Choose Start|Programs|Progress|Progress Explorer Tool.
2 Choose File|Connect.
3 Specify the host name and Admin Server port of the machine you want to administer remotely.
4 Enter a valid user ID for the remote machine and a password, if required.
Configuring the AppServer
Improved MRP performance requires a single AppServer with multiple threads, which is used to
execute the programs that process planning data when you run MRP. Use the following
instructions to configure that AppServer.
All QAD Installations
Use this procedure to configure an AppServer instance for all QAD installations. If you have an
Oracle installation, additional configuration tasks are required. See Additional Oracle Tasks on
page 202.
In the Progress example shown below, the name for the AppServer instance is mt-mrppro.
However, you can use any name, as long as all references to the name are consistent.
Add an entry for the required AppServer instance to the ubroker.properties file in the
DLC\properties directory. You can copy the following text into the file. Be sure to change the
parameters to match your environment. Parameter changes are described after the sample text.
Note Separate examples are provided for Progress and Oracle environments.

Progress Example
[UBroker.AS.mt-mrppro]
appserviceNameList=mt-mrppro
brokerLogFile=$WRKDIR/mt-mrppro.broker.log
controllingNameServer=NS1
initialSrvrInstance=12
maxSrvrInstance=20
minSrvrInstance=12
operatingMode=State-reset
portNumber=50000
PROPATH=/dr05/mfgpro/pro/qad:/dr05/mfgpro/pro/qad/us/bbi:
${PROPATH}${WRKDIR}
srvrLogFile=$WRKDIR/mt-mrppro.server.log
srvrMaxPort=50202
srvrMinPort=50002
srvrStartupParam=-db /dr05/mfgpro/pro/qad/db/mfgprod -ld qaddb
-znotrim -trig triggers -db /dr05/mfgpro/pro/qad/db/hlpprod -ld qadhelp -db
/dr05/mfgpro/pro/qad/db/admprod -ld qadadm -d mdy
-yy 1920 -Bt 3500 -c 30 -D 100 -mmax 6000 -nb 200 -s 63 -noshvarfix
uuid=fdf73fbf039907:6ce891fc:ec7f530e95:-7eed
Oracle Example
[Environment.mt-mrpora]
ORACLE_BASE=/dr02/apps/oracle/
ORACLE_HOME=/dr02/apps/oracle/8.1.7
ORACLE_SID=mrp
[UBroker.AS.mt-mrpora]
appserviceNameList=mt-mrpora
brokerLogFile=$WRKDIR/mt-mrpora.broker.log
controllingNameServer=NS1
environment=mt-mrpora
initialSrvrInstance=12
maxSrvrInstance=20
operatingMode=State-reset
portNumber=54000
PROPATH=
.:/dr05/mfgpro/qad:/dr05/mfgpro/qad/us/bbi:${PROPATH}:${WRKDIR}
srvrLogFile=$WRKDIR/mt-mrpora.server.log
srvrMaxPort=54202
srvrMinPort=54002
srvrStartupParam=-db /dr05/mfgpro/qad/db/oraprod -RO -znotrim
-trig triggers -db /dr05/mfgpro/qad/db/mrp -dt ORACLE -U qad
-P qad -c 250 -d mdy -yy 1920 -Bt 350 -c 30 -D 100 -mmax 3000
-nb 200 -s 63 -noshvarfix
uuid=59fdf73fbf039907:6302bfc1:ec513ed2fd:-6fd7
The parameters of interest are described below. Parameters not listed should generally not be
changed from the values given in the example.
Important The first line of the entry specifies the name of the AppServer instance. If this is
changed from the name in the example, be sure to change all other occurrences of this name in the
other parameters.
BrokerLogFile and srvrLogFile are the two log files for the AppServer instance. They
should be appropriately named and located in a convenient directory of your choice.
PROPATH is the Progress path used to locate code to run. This should reference the r-code
directory where your QAD software was installed.
uuid is a global unique identifier value associated with this AppServer instance. The Progress
tool genuuid should be used to generate a value. This tool can be run from the command line
and is found in the Progress DLC\bin directory.
Note If you use the Progress Explorer tool to create the AppServer definition, the uuid will
be generated automatically.
appServiceNameList should match the AppServer instance name that you have chosen,
which is listed in the first line of the properties entry.
portNumber is the port number for the AppServer broker for this instance. Its value can be an
arbitrary integer, as long as it does not conflict with any port assignments of other applications
running on this machine, including other AppServer instances.
srvrMinPort and srvrMaxPort specify a range of port values to use for the 4GL engines
spawned by the AppServer instance. The range should be large enough to accommodate the
maximum number of 4GL engines that can be spawnedspecified by the maxSrvrInstance
parameterand should not have any conflicts with ports used by other applications, including
other AppServer instances.
srvrStartupParam specifies the Progress startup parameters to be used by each 4GL engine
that is spawned. The specific DB, host, and service names should match the values that
correspond to your
QAD database installation.
Other values should remain as specified in the examples.
controllingNameServer specifies the Progress Name Server instance with which the
AppServer broker will register its name. The Progress default is NS1.
Since the AppServer broker mt_mrppro is used internally by the QAD software, you must use
AppServer Service Maintenance (36.19.1) to define an application server connection master
record. See Defining the AppServer on page 199.
Additional Oracle Tasks
If you have an Oracle installation, you must perform the following additional task:
Add an Environment entry like the example below to the ubroker.properties file:
[Environment.MRP_ORACLE]
ORACLE_HOME=/Oracle/OracleAppServer
ORACLE_SID=YourSystemIdentifier
ORACLE_BASE=/Oracle
Where:
/Oracle/OracleAppServer is the directory where the Progress AppServer for Oracle
has been installed; for example, /dr01/app/oracle/product/8.1.7
YourSystemIdentifier is the Oracle system ID (SID) for your system
/Oracle is the base Oracle directory, which contains version-specific subdirectories; for
example, /dr01/app/oracle
See the Progress AppServer documentation.
Starting and Stopping the AppServers
The AppServer instance configured in the example on page 200 can be administered using the
asbman command (located in DLC\bin), which can be invoked from the command line of a DOS
window. Click Start|Programs|Command Prompt to launch a DOS window.The DLC\bin directory

must be in your PATH environment variable in order to run these commands; alternatively, you can
change directories to the DLC\bin directory to run them. On UNIX, these commands are located
in the DLC/bin directory, and the user must have Progress administrative privileges to execute
them.
Important Make sure that all databases to be connected to the AppServer are running before you
start the AppServer.
The command usage is as follows:
To start an AppServer instance:
asbman -i appServerInstanceName -start
To stop an AppServer instance:
asbman -i appServerInstanceName -stop
To check the status of an AppServer instance:
asbman -i appServerInstanceName -query
Example To start the agents for the AppServer name used in the sample ubroker.properties
file shown on page 201, type the command:
asbman -i mt-mrppro -start
After starting an AppServer, use the query option to check its status, and do not proceed until all
of the AppServers are in the available state.
For troubleshooting, verify that the databases that the AppServer connects to are running. Do this
by running a Progress client session and trying to connect to the same database servers.
Note For the AppServer instance to run properly, the Progress Name Server must be running. In
turn, for the Name Server to run properly, the Progress Admin Server must be running. Although
the Name Server and Admin Server are usually configured by default to start up automatically at
boot time, it may be necessary to administer them manually. On Windows, these commands are
located in the DLC\bin directory, and should be run from a DOS window. On UNIX, these
commands are located in the DLC/bin directory, and the user must have Progress administrative
privileges to execute them.
To start, stop, or query the Progress Admin Server, use the appropriate command:
proadsv -start
proadsv -stop
proadsv -query
Note In a Windows environment, it is recommended that you use Start|Settings|Control Panel|

Services to start and stop the Admin Server.
The Progress Name Server will be started automatically during the successful startup of the Admin
Server. If it is necessary to start, stop, or query the Progress Name Server (assuming the default
NS1 name is used for the Name Server), use the following commands:
nsman -i NS1 -start
nsman -i NS1 -stop
nsman -i NS1 -query
Using Operating System Commands

The Operating System Commands menu provides four ways to access the operating system and
execute commands directly from your QAD application. Use them as a convenient way of viewing
and manipulating information.
Use Exit to Operating System (36.22.1) to invoke a UNIX or Windows command session. To
return to your QAD application, enter Exit.
Use Program/Text File Display (36.22.4) to display the content of an ASCII file, such as a
program or print file. If the file is not in the current directory, specify the path. Add this
function to the User Menu so that users can generate reports to a file and quickly review the
content.
Use Disk Space Inquiry (36.22.13) to execute an operating system command to display
statistics regarding the current database file size.
Using Delete/Archive Utilities
Audit Detail Delete/Archive

To delete data from an audit log, use Audit Detail Delete/Archive (36.23.1). This program works
differently from other system delete/archive functions. It does not delete each record specified.
Instead, for each unique combination of user ID, table, and field, it keeps the latest record and
deletes/archives the rest.
Use this function to produce a report of records before deleting them. See Audit Detail
Delete/Archive on page 169 for an exact procedure.
GL Transaction Delete/Archive
General ledger transactions created in operational functions such as purchasing, inventory control,
manufacturing, and fixed assets are stored in the unposted transaction table until they are posted.
Review unposted transactions using Unposted Transaction Inquiry (25.13.13).
You can delete and archive transactions created in these operational modules using GL Transaction
Delete/Archive (36.23.2). Use this program when:
1 You are not using QAD Financials.
2 You implemented other modules prior to implementing Financials. Before implementing
General Ledger, delete the GL transactions in the unposted transaction table since these are
already reflected in the beginning balances you enter.
For a standard implementation, GL Transaction Delete/Archive is used only during early stages of
implementation. After transactions of a particular type (PO, IC, WO, or FA) have been posted to
the general ledger, no further transactions of that type can be deleted or reloaded.

Statutory-Currency Utility
Use the Statutory-Currency Utility (36.25.90) to change the statutory currency code of a domain to
a different currency, even after transactions have been posted in the domain. The utility
reinitializes the statutory currency amount fields for all transactions in the domain.
The utility uses Statutory exchange rates, if available, to convert all transactions in the domain to
statutory currency. To perform this process, ensure that exchange rates exist from all the
transaction currencies to the statutory currency for all dates for which there are transactions in the
domain. This process is resource intensive so the timing must be carefully planned. The new
statutory currency values are equivalent to the transaction currency amounts converted using the
Statutory exchange rate valid on the posting date of the transaction. If the system cannot find a
statutory exchange rate that is valid for that date, it reverts to using the Accounting exchange rate,
if the Fallback to Accounting field in Exchange Rate Type Create (26.3.1) is selected for the
statutory exchange rate. For more information on currencies and exchange rates, see QAD
Before you run the Statutory-Currency Utility, stop the History daemon and the Balance daemon.
It is also recommended that you increase the time-out parameter in the homeserver.config file,
so that the UI does not time out and disconnect during the session. This recommendation displays
on screen when you start the statutory currency conversion. See Figure 9.3 on page 207.
Choosing the Best Time to Run the Utility

In principle, you can run the Statutory-Currency Utility at any time. However, if you run the utility
in the middle of the financial year, there will be some unresolved issues:
The exchange gains and losses on historical transactions are not recalculated in the utility, and
are translated from the base currency to the statutory currency. This translation occurs because,
for exchange gains and losses, the transaction currency is the base currency. This situation
means that the realized statutory currency exchange gains and losses that result from the
conversion utility are not the real gains and losses.
Historical year closing postings are translated from the transaction currency closing and
reopening balances to the statutory currency. If the Statutory exchange rates in the system for
the year closing posting date are not consistent, the closing and opening postings can become
unbalanced. Therefore, make a one-time manual journal entry adjustment in statutory currency
after you run the utility to obtain the desired statutory currency opening balances.
For the reasons listed in the previous two points, it is recommended that you implement statutory
currency at the beginning of a new accounting year.
Running the Utility

Use the Statutory-Currency Utility to update statutory currency values for a domain.
Fig. 9.2
Statutory-Currency Utility
Domain. Specify the domain for which for want to run the statutory currency conversion.
You can only run the Statutory-Currency Utility for a single domain at a time.
Base Currency. This field displays the base currency of the domain and is read only.
Statutory Currency. Specify the new statutory currency value that you want to convert to. The
default value for this field is the current statutory currency for the domain.
Is Statutory. Manually update the field to reflect the situation that will exist after the statutory
currency conversion is run.
Select this field if the base currency will not be the same as the statutory currency after
conversion.
Clear this field if the base currency will be the same as the statutory currency after conversion.
Note The statutory currency becomes active if it is different than the base currency.
Therefore, this field acts as an additional validation to remind you that you are activating or
deactivating a second domain-level currency.
Force Update. Select this field if you do not want to change the current statutory currency, but
you want the system to recalculate the statutory currency amounts.
When you click Execute to run the statutory currency conversion, the system displays a Processing
Confirmation window. Click Yes if you are sure that you want to proceed with the conversion. To
cancel the conversion, click No.

Fig. 9.3
Statutory-Currency Utility, Processing Confirmation
Important When you are finished running the Statutory-Currency Utility, log off QAD Enterprise
Applications and log back on to the updated domain before you can see the changed currency
setting. This step is required because some domain-level parameters are cached in the session
memory.
When the Statutory-Currency Utility is finished, you can restart the History daemon and the
Balance daemon, but the daemons will take time to rebuild the balance totals, including the new
statutory currency balances. Reports that use the summarized transaction history table
(PostingHist) to display GL account balances are only accurate when the History daemon has
processed all records in its queue. Use the History Daemon Monitor (36.14.16.1.3) and the
Balance Daemon Monitor (36.14.16.2.3) screens to check the status of the daemons.
Restrictions
The Statutory-Currency Utility does not use the Inventory exchange rate, even if this rate is
defined for the dates of all posted transactions in the domain. This restriction means that, if
Inventory exchange rates are used, you must revalue the inventory balances so that the statutory
currency balance is equal to the base currency balance multiplied by the Inventory exchange rate.
You may also need to restate purchase order price variances for the same reason.
Note Running the Statutory-Currency Utility is an intrusive operation, and it is recommended
that you run the utility in a test environment first. It is also recommended that you make a backup
of the database before running the utility.
Command Line Application Control

The application control program, applicationcontrol.p, can be used to start and stop
applications and daemons (except the Report daemon), and to perform a command-line
synchronization. This program lets you perform application maintenance from the command line,
without launching the application interface.
The application options include the ability to start the application with or without housekeeping,
which deletes inactive data from the database. The Synchronize options include the ability to
synchronize all or specific application components
The command line syntax for applicationcontrol.p is:
_progres -p applicationcontrol.p -param <options> -b > <LogFile>
where <options> is a string to pass options to the program, and has the format -<option>
[<value] [-<option> [<value]].
You can configure the following options:

URL
Specify the appserver URL with the following syntax:
appserver://<HostName>:<NameServerPort>/<AppServiceName
PROPATH
Indicate the propath to be used by the _progres session in cases where the logic is run in the
process itself rather than on the central appserver. You indicate the propath when you have not
specified an appserver URL.
ACTION
Specify an action to be performed. The <value> string can be one of the following:
StartApplication
StartApplication_no_housekeeping
StopApplication
StopApplication_no_wait
StartDaemon [<DaemonName>]
Use this option to start a new instance of the named daemon. If you do not specify a
daemon, the system starts all configured daemons.
StopDaemon <DaemonName>
This option sends a stop request for all instances of the named daemon.
DaemonStatus [<DaemonName>]
This returns status information for the named daemon, for example:
Daemon Name: XmlDaemon
[Status] Status: Active
[Status] #Running instances: 2
[Status] Proces Ids: 1884, 4856
[Status] Start date of daemon:04/12/2007
[Config] Log file: /users/xyz/logs/xmldaemon.log
[Config] Startup folder: /users/xyz/daemons/xmldaemon
[Config] Daemon login: user
[Config] XML input folder: /users/xyz/daemons/
xmldaemon/input
ResetDaemonConfiguration [<DaemonName>]
Note If the daemon is not specified, the system returns the status of all defined daemons in
the system
ResetDaemonConfiguration [<DaemonName>]
By default, this resets all daemons, but by specifying a Daemon name as an extra
parameter, it can be limited to one daemon only.

Use ResetDaemonConfiguration when you are copying an application database from

one environment to another. This ensures that daemon configurations are reset to initial
values, and prevents daemons from using previous.
By default, this resets all daemons, but you can limit the reset to a single daemon by
specifying the daemon name as an extra parameter.
Synchronize [Full|Limited|Topic<XX>]
This performs a full or limited synchronization, or for specified topics.
Each topic is represented by a topic number, as listed in Table 9.3. The Synchronization
Type column indicates if the topic is automatically included in limited or full
synchronizations if you do not specify it by number.
Table 9.3
Synchronization Topic List
Topic
Synchronization Topic Number Synchronization Type
Languages 1 LIMITED
Areas, Classes, and Activities 2 FULL
Default Activities 3 FULL
Shared Set Types 4 LIMITED
Stored Searches Defaults 5 FULL
Superuser Role 6 FULL
Report Strings 7 FULL
Daemons 8 FULL
Settings Configuration 9 FULL
Users 10 LIMITED
Default Entity 11 FULL
Translations 12 FULL
System 14 FULL
Resources 15 FULL
Default Roles 16 FULL
GL Types 101 LIMITED
Daybook Types 102 LIMITED
Profile Types 103 LIMITED
Exchange Rate Types 104 LIMITED
Address Types 106 LIMITED
GL System Types 107 LIMITED
Currencies 108 FULL
Business Relations 109 FULL
SAF Concept 110 LIMITED
Countries 111 FULL
Rounding Methods 112 FULL
Domains 113 FULL
China Accounting Interface Reports 114 FULL
China Accounting Interface Filter 115 FULL
Topic
Synchronization Topic Number Synchronization Type
Bank Account Validations 116 LIMITED
Non Taxable Tax Group 117 LIMITED
Example Use the following command to run the application installed to the directory C:\qad2008
and to check the status of the XML daemon running on this server. You must include the \lib and
Progress procedure library directories in the propath. The command displays the command results
in the log file vek.log.
_progres -p applicationcontrol.p -param "-PROPATH
C:\qad2008\fin\lib,C:\qad2008\fin\qadfin.pl -ACTION DaemonStatus[xmldaemon]" -b >
vek.log

Chapter 10
Customizing Business Logic

This chapter describes the principles and techniques for customizing the business logic of a
component-based QAD application.
Introduction to Customization 212
Gives a customization overview.
Elements of Customization 213
Discusses parameters, datasets, error handling, database access and updates, inheritance, and
identifying events.
Accessing Generalized Codes and Master Comments 216
Describes how to access generalized codes and master comments from the customized code.
Creating Customizations 223
Explains how to write customizations, compile customizations, update customizations, and run
other business methods, and gives examples of customization.
Introduction to Customization
You can customize component-based QAD applications after installation in a number of ways:
By using the Design Mode feature to customize the user interface during run-time
By creating user-defined fields and adding them to the interface
By customizing business component code using a standard Progress editor
These first two options let the user or developer add fields and modify forms in the current UI. You
can also use built-in .NET features to customize components such as searches, browses, and
reports. These options are described in Chapter 12, UI Customization, on page 241. For more
information on browses and stored searches, see Introduction to QAD Enterprise Applications
User Guide.
See Chapter 11, Customizing Specific Business Components, on page 227 for information on
customizing the matching logic for Processing Incoming Bank Files and customizing tax ID
validation.
This appendix describes how to customize business component code for an installed application
using a standard Progress 4GL editor.
Customization Overview
QAD application component code is based on a standard code template, and you can create
customizations for the following standard application activities:
Creating an object
Modifying an object
Deleting an object
Browsing an object
Generating a report
Retrieving data for a field into the object form
Retrieving related activities for an activity
You customize any of these activities by writing code that is activated with a publish-subscribe
mechanism, in which a customized event is published before or after the component code. A code
template (BComponent.p) is provided for each business component, which contains the
procedure definitions for every before or after event that can be customized, and which you use to
implement the customization. The template code is commented, and to hook the event code into
the component process, you uncomment the event and add the necessary component code. This
process is called non-intrusive customization, because the customized code is added before or after
the standard code, but does not intrude on the standard code itself. Template code does not contain
any application framework code, but does contain descriptions of methods and method parameters.
Each component-based application also contains a customization controller class
CustomizationController. This class controls the available customization pieces and their
implementation, and ensures that the correct customized code is executed in the right order for the
different processes.

Customizing Business Logic 213
Fig. 10.1
Component Customization
Standard UI logic Standard business logic
Customization
Customization
Business
BaseForm Customization
Component
Class
Base
ProcessObject Customization
Customization
Controller
Controller
Base Database
ComponentForm
Adapter Component BComponent
BComponent
Customization
Customization
Component
ProcessObject
Component BComponent
Adapter Component
UI
UI
Customization
Customization
Storage
Persistence
Application
database
Customizations are run on the same appserver as the internal code, and are portable from one
application instance to another. You can also call standard methods and queries from within
customized code.
Supporting Documentation
When customizing, you can refer to the QAD Financials API documentation for information on
activities, queries, and methods for components.
The API documentation is provided in HTML format with each QAD Enterprise Financials
release. It is stored in the HTMLdocumentation folder in your installation directory in a file
called QADFIN_Documentation.zip.
The API documentation represents the documented class model for the application business layer,
and is written by QAD developers.
See Tables and Mandatory Fields on page 123 for more information. In addition, the API
documentation is described in detail in the Best Practices for Customization training course.
Elements of Customization
The following section describes the code elements used in non-intrusive customization.
Parameters
The parameters of all business methods are stored in the temporary table t_Parameter. To access
a parameter, you use the field of the same name in t_Parameter table. The t_Parameter table
always contains exactly one available record, which means that you do not need to use find or
for each when using the table. When you assign a value to a field in the table, this value is
retrieved at runtime by the standard business code.
You typically assign a value to an input parameter in a before event, and assign a value to an output
parameter in an after event. A value assigned to an output parameter in an before event can be
overwritten by the standard business logic.
Example The following example uses the input parameter icPkeys.
/**/
PROCEDURE BItem.DataLoad.before:
if t_Parameter.icPkeys <> ""
then t_Parameter.icPkeys = t_Parameter.icPkeys + chr(4) + "MyKey".
/* load something extra */
END PROCEDURE.
/**/
Datasets
All datasets available to the standard business logic are also available to the customization code.
These are not just copies of these datasets, but are direct bindings, which means that any dataset
changes you make go directly to the standard business logic.
Class Datasets
Each business component has a set of class tables grouped in a class dataset. These tables are used
to update the application database. Database updates are first prepared in the class tables, then
validated, and when correct, are written to the application database.
Each business component has three class datasets:
<classname>O (tables t_o<databasetablename>)
Records in this dataset are updated by the business logic. These values are written to the
application database.
<classname>I (tables t_i<databasetablename>)
Records in this dataset represent values read from the database (used for optimistic lock
checking), and must not be modified.
<classname>S (tables t_s<databasetablename>)
Records in this dataset represent the input data of business functions that use the class dataset
for input parameters (for example, SetPublicTables). These records are first validated and,
when correct, are copied into the <classname>O dataset. This means that all business
validation rules are written to use this dataset.
A buffer t<databasetablename> is available in all components that represents the
t_o<databasetablename>. This makes programming easier and more readable. Since the code
is working with the t_o data in most methods, it can be used in most cases, except for the
Validate* methods, in which the t_s data is worked on.
Class Tables
Each class table contains the fields tc_Rowid and tc_ParentRowid. They are used to define a
generic relation between tables of the class dataset:

<childtable>.tc_ParentRowid = <parenttable>.tc_Rowid.
Important You must not change the value of these fields. Check the documentation of each
business component individually to establish the relations between class tables.
Each class table also contains the field tc_Status. The value of this field defines the kind of
update that is performed on the database, and can be one of the following:
(empty)
The record is identical to the record in the database. It is ignored when the database is updated.
If you do make changes to the record but forget to set the value of tc_Status, your changes
are not written to the database.
'N' (new)
Records with this status are created in the database. Do not use a create statement to add
records in the class dataset. Instead, use the business function AddDetailLine which assigns
correct default values to the newly created record.
'C' (change)
Records with this status are updated in the database. The record to update is retrieved using the
value of tc_Rowid, instead of the primary key fields. This does not mean that primary key
fields can be modified, as these fields may be copied into related tables, and by modifying
them, you break the link to those tables.
'D' (delete)
Records with this status are deleted in the database. The record to delete is retrieved using the
value of tc_Rowid. If the table is the parent of table relations with delete constraint
'cascaded', related records are deleted as well.
Class Data Items
Each class also contains a set of data items, which are used in the internal business logic of the
component. You can examine and update these data items using the generic
Get<DataType>Item and Set<DataType>Item methods, where <DataType> is one of the
following:
Character
Decimal
Integer
Int64
Logical
Memptr
Longchar
Raw
Recid
Rowid
Handle
ComHandle
These methods are only generated when at least one class data item of the respective data type is
defined for the component.
The logic includes a preprocessor variable called &USEDDATAITEMS, which is available to all
code. This preprocessor is a comma-separated list of data item names, and is passed in the include
file reference definition/<component include file name> in the custom code program.
For example:
{definition/bsaf.i &USEDDATAITEMS = viDataItem}
It is the responsibility of the custom code developer to populate the &USEDDATAITEMS variable
with custom code. Data items not added to the preprocessor will not be available in the custom
code.
The following conditional code defines a variable to mirror a data item:
&IF LOOKUP("viDataItem","{&USEDDATAITEMS}") > 0
&THEN
DEFINE VARIABLE viDataItem AS INTEGER NO-UNDO.
&ENDIF
The following conditional code calls the setDataItem and getDataItem methods:
Procedure GetDataItems:
Define variable vc as character no-undo.
&THEN
Run GetIntegerItem (input viDataItem, output viDataItem).
&ENDIF
End procedure.
Procedure SetDataItems:
Define variable vc as character no-undo.
&THEN
Run SetIntegerItem (input viDataItem, input viDataItem).
&ENDIF
End procedure.
Accessing Generalized Codes and Master Comments
Generalized Codes
You can define user-defined fields with a lookup or value list based on generalized codes. See
Create a User-Defined Field on page 258.
You can also use non-intrusive customization to add a lookup to a field based on generalized
codes.
Example
procedure bbusinessrelation.getbusinessfields.after:
find tBusinessFields where
tBusinessFields.tcFcFieldName = "tAddress.AddressZip"
no-error.
if available tBusinessFields
then assign tBusinessFields.tcLookupQuery =
"BMfgGeneralizedCodeSAO.SelectGeneralizedCode"
tBusinessFields.tcLookupFilterField = "tcode_mstr.code_value"
tBusinessFields.tcLookupReturnField = "tqSelectGeneralizedCode.tccode_value"
tBusinessFields.tcRelatedObject = "<Generalized Code you need>".
end procedure.

Master Comments
You can access master comments from the customized code using the GetComment method,
included in every business component. The GetComment method queries the cd_det table or
the cmt_det table, or both, depending on the parameters you specify.
Error Handling
Application Errors
Error messages to the end-user can be created by running the SetMessage procedure in
combination with the parameter oiReturnStatus.
An error condition is raised when you assign a negative value to
t_Parameter.oiReturnStatus. When this occurs, standard business logic stops executing
and passes the return status to the client that runs the business logic.
Note The ValidateComponent and ValidateBC methods are exceptions to this behavior.
When the return value for oiReturnStatus is negative, these methods continue to execute and
attempt to validate the component.
The possible values for oiReturnStatus are:
-1 Validation error
The input for the operation was incorrect. The operation could not proceed.
-3 Run-time error
The operation did not proceed because of a run-time error in the operation code.
-5 Fatal error
The operation did not proceed because of a permanent error. The application is shut down.
System Errors
System errors are triggered by Progress run-time when a Progress statement without the no-
error option fails to execute. System errors are handled by the standard business logic using the
new try-catch mechanism of OpenEdge 10. You must then ensure that any sub-transaction block
(for example, a do transaction, for, or repeat block) in your code includes the on error
undo, throw option.
System errors are reported using oiReturnStatus -98.

You can also add a finally block at the end of a customization event procedure. Code in a
finally block is always executed before the procedure ends. It is also run when a system error
occurs during the execution of a procedure or if the code is interrupted with an explicit return
statement.
Database Access and Updates

There are no rules or restrictions on database access and updates. Each event is a transaction on its
own and all updates to it are committed when the event ends. The exceptions to this are the events
on the business method DataSaveWorker and the sub-methods PreSave and PostSave (see
Identifying Events on page 218). These methods are typically contained in larger transactions,
and updates to them are not implemented if the larger transactions fail.
Inheritance
When you implement an event on a business component that has descendant business components,
the event is also implemented for all the descendants, except descendants that override the
standard business logic for that specific method.
Example
Fig. 10.2
Inheritance Structure
Business
Database
bbasedaemon
breportdaemon breportdaemon
Any customization event implemented on bbasedaemon is active when running the component
bxmldaemon, breportdaemon or any other daemon.
Identifying Events
To view the execution flow in full detail, use the system logging functions. Set Debug Level
(36.24.3.5) lets you set the level of detail displayed in the system ctlog file. You can display full
business code, including parameter values and database queries.
When logging is enabled, you can run the function you want to customize, and then display the
execution flow in ctlog. The log displays the business methods used in the function and how they
are implemented.
See Set Debug Level on page 145.
The following business logic flows illustrate the call stack of some of the most used business
functions.

Instantiate a Maintenance Form in Create Mode
Fig. 10.3
Create Call Stack
Client Business Component Transaction
InitInstance
LoadSystemSettings
AddInstance
ReadSessionValues
GetBusinessFields
DataNewGetPublicTables
DataNew
ClearData
Calculate
Instantiate a Maintenance Form in Update mode
Fig. 10.4
Update Call Stack
Client Business Component Transaction
InitInstance
LoadSystemSettings
AddInstance
ReadSessionValues
GetBusinessFields
DataLoadGetPublicTables
DataLoad
ClearData
Calculate
Save Data in a Maintenance Form (Create and Update)
The following diagrams illustrate the call stack for saving data in a maintenance form.
Fig. 10.5
Save Call Stack
Client Business Component beventdaemonqueue
SetPublicTablesDataSave
SetPublicTables
ValidateComponent
ValidateFieldSecurity
ValueChanged
ValidateActivityCode
ApiActivityIsAllowed
ValidateCustomFields
AdditionalUpdates
InitInstance
ClearData
ObjectStatusUpdate
PublishEvent
CreateEvent
AddDetailLine
InitialValues
ValidateBC
ValidateComponent ...
AdditionalUpdates ...
DataSave
UpdateLastModified
EventPublishing
EventPublishingLookForUpdates
PublishEvent
CreateEvent

create_update.emf

Fig. 10.6
Save Call Stack (contd.)
Client Business Component beventdaemonqueue beventdaemonqueue beventdaemonqueue
UpdateWorkObject
InitInstance

UpdateWorkObjectStatus
DataLoadByObjectID
DataLoad
ValidateBC
ValidateComponent
AdditionalUpdates
DataSave
DataSave
Commit Transaction
DataSaveWorker
PreSave
PostSave
DataSaveWorker
PreSave
PostSave DataSaveWorker
PreSave
PostSave
UpdateStatus
PostTransaction
UpdateStatus
PostTransaction UpdateStatus
PostTransaction
ExitInstance
ExitInstance
create_update.emf ExitInstance
Deleting an Object in a Maintenance Form
Fig. 10.7
Delete Call Stack
Client Business Component
DataDelete
SetPublicTables
DataSave
DataSaveWorker
PreSave
PostSave
UpdateStatus
PostTransaction
ExitInstance
Importing Data using the XML Daemon
Fig. 10.8
Import Using XML Call Stack
Client Business Component
InitInstance
SetSTables
MaintainByDataset
DataLoadByInput
DataDelete
SetPublicTables
OR
ValidateUI
ValidateComponent
AdditionalUpdates
DataSave
DataSaveWorker
PreSave
PostSave
UpdateStatus
PostTransaction
OR
StoreState
ExitInstance
Sample Code for Non-Intrusive Customization

The following code illustrates the GetBusinessFields, InitialValues, and
ValidateComponent methods contained in the customization template file BLanguage.p.
/*
Procedure: GetBusinessFields
Description:
Return a list of public business fields of a business class.
Parameters:
input icReference
(business class or (query) method name)
output dataset tBusinessFields
(business fields)
output dataset tCustomRelation
()
output oiReturnStatus
(Return status of the method.)
*/
/**
PROCEDURE BLanguage.GetBusinessFields.before:
END PROCEDURE.
**/

/**
PROCEDURE BLanguage.GetBusinessFields.after:
END PROCEDURE.
**/
/*
Procedure: InitialValues
Description:
Add code here to initialize the calculated fields of a 'new' record (= a record that must
be created in the application database) in a class temp-table.
Parameters:
input icTableName
(Name of the database table of which a record is created in the class temp-table.)
()
*/
/**
PROCEDURE BLanguage.InitialValues.before:
END PROCEDURE.
**/
/**
PROCEDURE BLanguage.InitialValues.after:
END PROCEDURE.
**/
/*
Procedure: ValidateComponent
Description:
Write here all tests on database update (new / modify / delete) that cannot be coded with a
validation mask.
The type of update can be found in tc_status (N/C/D).
If you find incorrect data, you must write an entry in tFcMessages (using SetMessage) and
set the return status of this method to either +1 or -1.
Return status +1 = data will still be accepted.
Return status -1 = data will not be accepted.
This method is run from SetPublicTables, before transferring the received data into the class
temp-tables.
Parameters:
()
*/
/**
PROCEDURE BLanguage.ValidateComponent.before:
END PROCEDURE.
**/
/**
PROCEDURE BLanguage.ValidateComponent.after:
END PROCEDURE.
**/
Creating Customizations
Before and After events are provided for every method of the business component, and each event
header describes the business method and its parameters. To customize the event, you uncomment
the event you want to implement and add code into the internal procedure.
The Customization folder in the application root contains two sub-folders:
Definition
This folder contains an include file for each business component.
Template
This folder contains the .p program file for each business component. This program contains
the Before and After event code for the component.
Note You must include the Template folder in the PROPATH of each progress session used
for compiling the customized component code. This ensures that the system can detect code
version mis-matches during an application upgrade.
Writing Customizations
Use the following steps for every component that you want to customize.
1 Copy the file in the template folder to a local source code folder.
You must always code in a locally stored copy of the template file, and not in the original file.
You can store this copy anywhere on your local drive, but you must ensure that you copy only
those template files that you are modifying. Ensure that the local folder you use is contained in
the PROPATH for compilation.
You also copy the include file from the definition folder to the local folder. This file is needed
for compilation, and must not be modified.
2 Use a Progress 4GL editor to uncomment the events in the template file to be customized, and
to add related code.
Compiling Customizations
Compile all program files in your local source code folder into a folder named customcode.
This customcode folder is placed in a folder that is part of the PROPATH of the appserver
running the business logic.
Once the folder is included in the PROPATH, the application automatically runs the customization
when the appserver is restarted or all agents are trimmed.
Updating Customizations
Whenever a new version of the application is installed, the customized programs in your local
source code folder must be updated to the new version. In most cases, you can update the version
number in the header of the program (&scoped-define class-version xx.yy) to the
version number displayed in the new template folder. If the template file has undergone many
changes since the previous version, it may be more useful to copy the template file and add your
customizations again.
When you have reinstalled the application, you must compare the methods in your customizations
with those contained in the new template files, because methods may change with every new
version.
You must also evaluate the method descriptions and parameters, because parameters can also be
removed between installations. You must resolve any differences before you continue with
customization. Use a standard file diff tool to make your comparisons.

Running Other Business Methods

You can run any customizable procedure from within the customization, using a standard run
statement.
The procedure itself can be customized or standard. The procedure is run within the standard
business component through procedure overloading.
Example In this example, you run the method GetCustomFieldList from within a
customization of BItem.ValidateCustomFields:
/**/
PROCEDURE BItem.ValidateCustomFields.before:
define variable vcList as character no-undo.
define variable viReturn as integer no-undo.
run GetCustomFieldList (output vcList, output viReturn).
END PROCEDURE.
/**/
Examples of Customization
This section describes some sample customizations.
Example Customize the default value for GLExchangeMethod when creating a G/L account:
/**/
PROCEDURE BGL.InitialValues.after:
/* tgl is a shared buffer on table t_ogl */

if t_Parameter.icTableName = "gl"
then assign tgl.GLExchangeMethod = "USERDEFINED".
END PROCEDURE.
/**/
Example Add default values for SAF codes when creating a G/L account:
/**/
PROCEDURE BGL.InitialValues.after:
define variable viReturn as integer no-undo.
if t_Parameter.icTableName = "gl"
then do:
/* AddDetailLine will create a record in tGLSafDefault */
run AddDetaiLLine (input "GLSafDefault",
input tgl.tc_Rowid,
output viReturn).
/* parent rowid */
/* error handling */
if viReturn < 0
then assign t_Parameter.oiReturnStatus = viReturn.
else assign tGLSafDefault.GL_ID = tgl.GL_ID
tGLSafDefault.tcSafConceptCode = "<CustomValue>"
tGLSafDefault.tcSafCode = "<CustomValue>".
end.
END PROCEDURE.
/**/
Example Add a custom table to a report dataset:

/* define the custom table */
define temp-table glhistoryCustomData no-undo
field MyCustomCode as character
field MyCustomValue as character
index ip is primary unique MyCustomCode.
/* create custom data */

PROCEDURE BGLReport.GLHistory.after:
create glhistoryCustomData.
assign glhistoryCustomData.MyCustomCode = "demo-code"
glhistoryCustomData.MyCustomValue = "demo-value".
END PROCEDURE.
/**/
/* publish the custom data */

PROCEDURE BGLReport.ApiProcessReportLogic.after:
if t_Parameter.icReportName = "glhistory"
then t_Parameter.ozReportData:add-buffer(temp-table glhistoryCustomData:default-
buffer-handle).
END PROCEDURE.
/**/

Chapter 11
Customizing Specific Business

Components
This chapter describes how to customize the standard matching logic in Process Incoming Bank
Files and to implement validation for tax IDs using non-intrusive customization.
Customizing Process Incoming Bank Files 228
Introduces the concept of customizable matching logic for Process Incoming Bank Files. Uses
flows and sequence diagrams to illustrate how the matching logic in Process Incoming Bank Files
can be customized.
Customizing the Validation of Tax IDs 237
Describes how to use non-intrusive customization to implement the validation of federal and state
tax IDs.
Customizing Process Incoming Bank Files

You can use the Process Incoming Bank Files function (31.1.6) to import bank payment files from
your bank, and to generate and allocate customer and supplier payments and banking entries in the
system using the transaction messages contained in the files.
The Enhanced Lockbox module exposes the standard matching logic for the Process Incoming
Bank Files function. This matching logic is used to match customer and supplier payments in the
imported bank files to open items on the system.
The customizable matching logic uses the following customizable methods:
BankImpLine.GetInvoicesByBankImpLine.Before
BankImpLine.GetInvoicesByBankImpLine.After
BankImpLine.GetInvoicesByBankImpLineXref.Before
BankImpLine.GetInvoicesByBankImpLineXref.After
BankImpLine.GetCDocumentByBankImpLine.Before
BankImpLine.GetCDocumentByBankImpLine.After
BankImpLine.GetDDocumentByBankImpLine.Before
BankImpLine.GetDDocumentByBankImpLine.After
BankImpLine.GetCreditorByBankImpLine.Before
BankImpLine.GetDebtorByBankImpLine.Before
The customizable matching logic is similar to the standard matching logic, and can be enabled and
disabled using the customization template file, bbankimpline.p.
Customer Payments in Bank File Import Lines

This section contains flows and sequence diagrams to indicate how Process Incoming Bank Files
processes customer payments. It also describes the variable you use to activate the customizable
matching logic.
Figure 11.1 shows the customer payments flow and indicates the point at which the matching logic
is used.

Customizing Specific Business Components 229
Fig. 11.1
Customer Payments, Main Flow
Init
GetDebtor
GetCurrency
Cannot retrieve bank file

Get PaymentFormat based
format <XXXX>. Please define
on own bank number and
it In Bank File Format
bank file format
Maintenance.
Create payment in Initial

status GetInvoicesByBankImpLine()
Use Custom Matching Logic? No
Yes
Standard Matching Custom Matching
Invoice(s) found?
Allocate payment
document to invoices and
change status to Collected
Should the payment

be changed
to Paid status?
No
Yes
Change payment status

to Paid
No
End
Fig. 11.2
Customer Payments FlowSequence Diagram
BBankImpLine BDocument
CreateDDocument
GetDebtorByBankImpLine
GetCurrencyByBankImpLine
ClearInstance
CreateDDocumentHeader
GetInvoicesByBankImpLine.Before
GetInvoicesByBankImpLine
GetInvoicesByBankImpLine.After
AllocateInvoices
ChangeStatus
ValidateBCandAdditionalUpdates
DataSave
CloseInstance
BankImpLine.GetInvoicesByBankImpLine.Before()
In order to use the customizable matching logic instead of the standard matching logic, set the
vlUseCustomMatching variable to Yes in the GetInvoicesByBankImpLine.Before
method. To disable the customizable matching logic, set the variable to No.
In the non-intrusive framework, a standard method variable cannot be shared with its .Before or
.After method. Therefore, the vlUseCustomMatching variable is defined at class level, and
the program calls the SetPublicData and GetPublicData methods to store and retrieve class
variables.
PROCEDURE BBankImportLine.GetInvoicesByBankImpLine.before:
DEFINE VARIABLE viReturn AS INTEGER NO-UNDO.
DEFINE VARIABLE vcCustom AS CHARACTER NO-UNDO.
DEFINE VARIABLE vlUseCustomMatching AS LOGICAL NO-UNDO.
/* ================================================================================ */
/* if using custom matching logic, return directly without executing standard matching logic.
*/
/* ================================================================================ */
ASSIGN vlUseCustomMatching = YES.
ASSIGN vcCustom = IF vlUseCustomMatching THEN "true":U ELSE "false":U.
RUN SetPublicData(INPUT "vlUseCustomMatching", INPUT vcCustom, OUTPUT viReturn).
END PROCEDURE.

BankImpLine.GetInvoicesByBankImpLine()
The BankImpLine.GetInvoicesByBankImpLine()method stores the standard matching

logic. If the vlUseCustomMatching method variable is set to Yes, the program does not execute
the standard logic in the method, and continues to execute the .After method.
BankImpLine.GetInvoiceByBankImpLine.After()
If the vlUseCustomMatching method variable is set to Yes, the program executes the
customizable matching logic in the .After method and its sub method
BBankImpLine.GetInvoicesByBankImpLineXref.
Fig. 11.3
GetInvoices, Main Flow
Init
Get Invoices based on Invoice Reference
Get all open invoices based on

Debtor_ID, BankNumber_ID, and
Company _ID (if the Include All Entities
option is unselected)
Invoice found where

BankImpLineDet .InvRefList
yes
matches voucher and
JournalCode ?
Invoice found where

BankImpLineDet .InvRefList yes
matches voucher ? Create InvoiceXref
for each matched
invoice
Invoice found where Create InvoiceXref

BankImpLineDet .InvRefList yes for each matched
matches InvoiceDIText? invoice
Create InvoiceXref
for each matched
invoice
no
Accumulated InvoiceXref
no Not Matching Error
Amount = BankImpLineAmount ?
yes
Create InvoiceXref
for each matched
invoice
Get invoice based on open

amount of Bank Import
Line(InvoiceBankToPay =
BankImpLineAmount )
Get invoices of debtor. Try to

calculate open amount from oldest
invoice to match paid amount
End

BankImpLine.GetInvoicesByBankImpLineXref
The BBankImpLine.GetInvoicesByBankImpLineXref method creates invoice cross-

references used to allocate invoices to payments. This method has a similar customization
structure to the BBankImpLine.GetInvoicesByBankImpLine.Before and
BBankImpLine.GetInvoicesByBankImpLine.After methods.
Fig. 11.4
GetInvoicesByBankImpLineXref, Main Flow
GetInvoicesByBankImpLineXref
Create tInvoiceXref.
Assign tInvoiceXref .tdInvoiceRefDiscTC = vdDiscountAmount + (tqDInvoiceByDebtorRef.tdDInvoiceBankToPayTC / vdInvoiceBalance )
tInvoiceXref.tdInvoiceRefAllocTC = vdInvoicePaymentAmount + (tqDInvoiceByDebtorRef.tdDInvoiceBankToPayTC / vdInvoiceBalance).
Debtor INV:
tInvoiceXref.tdInvoiceRefAllocTC < tBankImpLineDet.BankImpLineAmountTC.
Debtor CN:
tInvoiceXref.tdInvoiceRefAllocTC > tBankImpLineDet.BankImpLineAmountTC
yes
Assign tInvoiceXref.tdInvoiceRefDiscTC = 0
tInvoiceXref.tdInvoiceRefAllocTC = vdBankImpLineAmountTC.
no
The BBankImpLine.GetInvoicesByBankImpLineXref method also controls the allocation

of partial customer payments. If partial payments are enabled and if the bank file contains a
customer open item with a matching daybook and voucher reference, and the bank file import
amount is less than or equal to the open invoice amount, the bank import line payment amount is
applied against the open item.
You can disable partial allocation by commenting out the following code:
/* if tDInvoiceByDebtorRef.tdDInvoiceOriginalDebitTC -
tDInvoiceByDebtorRef.tdDInvoiceOriginalCreditTC > 0
then do:
if tBankImpLineDet.BankImpLineAmountTC - tInvoiceXref.tdInvoiceRefAlloTC < 0
then do:
assign tInvoiceXref.tdInvoiceRefDiscTC = 0
tInvoiceXref.tdInvoiceRefAlloTC = tBankImpLineDet.BankImpLineAmountTC
tInvoiceXref.tdInvoiceRefAlloTC = dynamic-
function("RoundAmount",tInvoiceXref.tdInvoiceRefAlloTC, ?,
tDInvoiceByDebtorRef.tcCurrencyCode).
end.
end.
else if tDInvoiceByDebtorRef.tdDInvoiceOriginalDebitTC -
tDInvoiceByDebtorRef.tdDInvoiceOriginalCreditTC < 0
then do:
if tBankImpLineDet.BankImpLineAmountTC + tInvoiceXref.tdInvoiceRefAlloTC > 0
then do:
assign tInvoiceXref.tdInvoiceRefDiscTC = 0
tInvoiceXref.tdInvoiceRefAlloTC = - tBankImpLineDet.BankImpLineAmountTC
tInvoiceXref.tdInvoiceRefAlloTC = dynamic-
function("RoundAmount",tInvoiceXref.tdInvoiceRefAlloTC, ?,
tDInvoiceByDebtorRef.tcCurrencyCode).
end.
end.
assign tInvoiceXref.tdInvoiceRefAlloTC = tInvoiceXref.tdInvoiceRefAlloTC+
tInvoiceXref.tdInvoiceRefDiscTC. */
Changing the Customer Payment Status to Paid
If you want to change the status of a customer payment to Paid, the application calls the
GetDDocumentByBankImpLine method to search the DDocument table, which then matches the
banking import line.
The GetDDocumentByBankImpLine method has the same customization structure as
GetInvoicesByBankImpLine.
Fig. 11.5
GetDDocumentByBankImpLine, Sequence Diagram
BBankImprtLine BDDocument BCDocument
ProcessBankImpLineAction
ProcessBankImpLineDDocumentPaid
OpenInstance
GetDDcoumentByBankImpLine
Change Status
ValidateBCAndAdditionalUpdate
ProcessBankImpLine .CDocumentPaid
Open Instance
GetCDocumentByBankImpLine
Change Status
ValidateBCandAdditionalUpdates

Fig. 11.6
GetDDocument, Main Flow
Init
Ddocument already
Document
selected
found ?
(Ddocument _ID exists)
No
Yes
Get Ddocument by Document

Payment Number found ?
No
Yes
Get Ddocument by Document

Payment Reference found ?
No
Yes
Get DDocument by Document

Debtor and Amount found ?
No
Yes
Return DDocument ID,

Raise Error : Customer
Year, Type, and
payment not found
Number
End
Changing the Supplier Payment Status to Paid
The GetCDocumentByBankImpLine method is similar to the GetDDocumentByBankImpLine

method, and is used to set supplier payments to Paid.
Get Debtor
Figure 11.7 illustrates the process used to locate the customer code (debtor code) value in the
GetDebtorByBankImpLine method.
Fig. 11.7
GetDebtorByBankImpLine, Main Flow
Init
GetDebtor By Code
Debtor found ?
(BankImpLineDebtorCode )
No
Yes
Get Debtor by bank

Debtor found ?
account
No
Yes
Get Debtor by
business relation
Debtor found ?
remittance address (by
code and name )
No
Yes
Get Debtor by invoice

Debtor found ?
payment reference
No
Yes
Get Debtor by name

Debtor found ?
and address
No
Yes
Get Debtor by name Debtor found ?
No
Yes
Raise Error : Cannot find Store Debtor to

Debtor with Code XXX BankImpLine
End
Get Creditor
The Get Creditor method functions in the same way as Get Debtor, but is used to retrieve the
supplier code (creditor code).

Setting Up Customization
Complete the following steps to install the customizable matching logic.
1 Unzip the CustomMatching.zip file (containing bbankimpline.i, bbankimpline.p, and
build.p), and add the unzipped files to the customization folder on the c:\ drive.
2 Add the c:\customization folder to the PROPATH.

3 Start your QAD application and open System Monitor (36.24.3.4).
4 Click Customization and ensure that the customization logic includes the following six
.Before methods and the following four .After methods:
BBankImpLine.GetInvoicesByBankImpLine.Before()
BBankImpLine.GetInvoicesByBankImpLine.After()
BankImpLine.GetInvoicesByBankImpLineXref.Before()
BankImpLine.GetInvoicesByBankImpLineXref.After()
BBankImpLine.GetCDocumentByBankImpLine.Before()
BBankImpLine.GetCDocumentByBankImpLine.After()
BBankImpLine.GetDDocumentByBankImpLine.Before()
BBankImpLine.GetDDocumentByBankImpLine.After()
BBankImpLine.GetCreditorByBankImpLine.Before()
BBankImpLine.GetDebtorByBankImpLine.Before()
5 The src folder contains the source code. Open compile.p with the Progress Editor, and
press F2 to compile the program. The system adds the generated .r file directly into the
c:\customization\customcode folder.
6 Trim the appserver. The application then loads the updated .r file.
Enabling and Disabling the Customizable Matching Logic

When the customizable matching logic is installed, the application uses the customizable matching
logic by default, and not the standard matching logic.
If you want to disable the customizable matching logic, look for the assign
vcUseCustomMatching = yes. variable in the bbankimpline.p file and replace this with
assign vcUseCustomMatching = no. in the six .Before methods. Do not change the
.After methods.
Customizing the Validation of Tax IDs

This section describes how to use non-intrusive customization to implement the validation of
federal and state tax IDs according to the requirements of your local tax authority.
You must customize the BFormatSet component to implement your custom tax ID validation.
BFormatSet validates tax IDs entered in the following fields:
Federal Tax ID field in the Business Relation record
State Tax ID field in the Business Relation record
Federal Tax ID field in the Supplier record
State Tax ID field in the Supplier record

Federal Tax ID field in the Customer record
State Tax ID field in the Customer record
In addition, the BFormatSet component contains a pre-populated method used to validate the
fiscal code used in withholding tax.
Note Withholding tax will be available in a forthcoming QAD release.
The system passes regional details from the business relation, such as the country code, state, and
address type, to the validation component, and these details can be used in the customized tax ID
validation.
Validation Component
The validation component, BFormatSet, holds logic for validating tax IDs and fiscal codes. The
component is blank, except for the fiscal code validation child method, and exposes the
ValidateFormatTaxID method, which you can adapt to implement custom tax validations.
Note In later QAD releases, you will be able to customize BFormatSet to validate other
numbers and IDs.
Fig. 11.8
BFormatSet
class BFormatSet
DatabaseComponent
BFormatSet
+ ValidateFormat (ValueToValidate : char , FormatType: char, TableName: char , FieldName: char, FieldValue: char, CountryCode : char , StateCode : char, AddressType : char , ErrorType: char ): void
+ ValidateFormatFiscalCode (): void
+ ValidateFormatTaxID (FormatType: char , TableName : char , FieldName: char , FieldValue : char , CountryCode : char , StateCode : char ): void
BFormatSet includes the following methods:

ValidateFormat
The parent method for the validations.
Future QAD releases will let you customize the ValidateFormat method to validate
codes, numbers, or IDs.
ValidateFormatFiscalCode
ValidateFormatFiscalCode is a child method that validates the fiscal code used in
withholding tax. Withholding tax will be available in a forthcoming QAD release.
ValidateFormatTaxID
ValidateFormatTaxID is a child method that validates tax IDs. The method is blank in
order for you to customize it and add your own tax validation functionality.

Errors and Warnings

The Financials code denotes the type of message (Error or Warning) to raise if the tax ID entered
by a user fails to validate. This message type is treated as the default by the tax ID customization
method, ValidateFormatTaxID. However, you can override the default message type using
non-intrusive customization.
For example, if the default value is that the system generates an Error message type if the tax ID
fails to validate, you can change the message type to Warning using the customization method,
even though Error is the default
Customization Sample Code

The code in this section uses the example of a fictional tax ID validation for the Czech Republic,
implemented using non-intrusive customization. In this example, the tax ID cannot be less than
two characters.
The icValueToValidate parameter supplies the code, number, or ID to be validated. The
icTableName and icFieldName parameters can be used to distinguish between the records
to be validated, that is, business relation tax details, supplier tax details, or customer tax details.
The icFieldName parameter can be used to distinguish between different types of tax ID for the
same country, for example, federal or state tax IDs.
/* Customization code for component BFormatSet */

&scoped-define class-version 0.0
{ definition/bformatset.i }
/*
Procedure: ValidateFormatTaxId
Description:
This method can be used for validation of correct format of the Tax ID.
- instance less method
Parameters:
input icValueToValidate
(Code/Number/ID to be validated)
input icTableName
()
input icFieldName
()
input icCountryCode
()
input icStateCode
()
input icAddressType
(Address type.)
input icErrorType
(Type of error if the format does not comply with the format. (Error/Warning).)
(Return status of the method.)
*/
PROCEDURE BFormatSet.ValidateFormatTaxId.after:
define variable viLocalReturn as integer init 0.

define variable viDummy as integer.
assign t_parameter.oiReturnStatus = -98.
MAIN_BLOCK:
do on error undo, leave:
/* CZECH TAX ID VALIDATION */
if t_parameter.icCountryCode = "CZE" and
t_parameter.icAddressType = {&ADDRESSTYPECODESYSTEM-HEADOFFICE}
then do:
/* If not entered - is OK */
if t_parameter.icValueToValidate = '':U or
t_parameter.icValueToValidate = ?
then leave MAIN_BLOCK.
/* First two letters have to be CZ so length cannot be less than 2 characters */

if length(t_parameter.icValueToValidate, "CHARACTER") < 2
then do:
run SetMessage (
input 'Czech Tax ID cannot be shorter than 2 characters.',
/* icMessage */
input '':U, /* icArguments */
input t_parameter.icTableName + '.':U + t_parameter.icFieldName,
/* icFieldName */
input t_parameter.icValueToValidate, /* icFieldValue */
input t_parameter.icErrorType, /* icType */
input 3, /* iiSeverity */
input '':U, /* icRowid */
input 'CUSTOM-001':U, /* icFcMsgNumber */
input '':U, /* icFcExplanation */
input '':U, /* icFcIdentification */
input '':U, /* icFcContext */
output viDummy).
assign viLocalReturn = (if t_parameter.icErrorType = 'E':U then -1 else 1).
leave MAIN_BLOCK.
end.
/* Other validations */
end. /* if t_parameter.icCountryCode = "CZE" and */

end. /* MAIN_BLOCK */
assign t_parameter.oiReturnStatus = viLocalReturn.

END PROCEDURE.

Chapter 12
UI Customization
This following topics describe how to customize the appearance of screens and add user-defined
fields.
Overview 242
Introduces UI customization concepts.
Design Mode 242
Use Design Mode to add, move, or remove fields and tabs, and modify field properties.
User-Defined Fields 257
Customize predefined fields to store data specific to your business requirements.
User-Defined Components 264
Define your own business components.
Financial Text Translation 281
Explains how to use the Financial Translation Maintenance program to maintain text strings.
Overview
The component-based user interface supports many ways that users and administrators can tailor it
based on your organizational requirements, including the following:
Customize the user interface using the Design Mode feature.
Create your own user-defined fields and add them to the user interface using the User-Defined
Fields (UDFs) feature.
In addition to the customization of component-based functions, you can modify other aspects of
the UI. Which features a particular user can access depends on system and user settings as well as
user permissions. See Configuring System and User Settings on page 148 for a discussion of
settings. For more information on permissions, see QAD Security and Controls User Guide.
You can modify browse settings and search results to configure them for your particular needs.
The Search options in component functions let you filter your search results in a number of ways,
and save customized search settings for reuse. This feature is called a stored search. In addition,
you can make a number of modifications to the search results to configure them for your particular
needs, such as customizing the column layout. For more information on browses and searching,
see Introduction to QAD Enterprise Applications User Guide.
You can customize reports in a number of ways by:
Updating the settings that influence the selection criteria and report output
Saving specific report settings as a report variant, and reloading them as required, saving time
Modifying the report layout and saving it as a Crystal Report .rpt file that you and other
users can reload and use as required.
For more information on reports, see QAD Financials User Guide.
There are many other ways to customize the UI that apply in general, not just to component-based
functions. For more information, see QAD .NET UI Administration Guide.
Design Mode
Design mode lets you add, move, or remove fields and tabs, and modify field properties. In
addition, you can create predefined column views for screens that contain grids.
The customizations you create can apply to yourself, all users with the same default role, or to all
users in the system. You are prompted to specify the customization level when you start and save
the customization.
You access design mode by selecting Design Mode in the Tools menu in the screen that you want
to customize.
Settings that Affect Design Mode

Two types of settings affect the operation of design mode:
Security settings
System and user settings

UI Customization 243
Security Settings
To use design mode, you must be assigned permission to the Customization activity at either the
user, role, or general level. If none of these three activities is linked to any of your roles, the
Design Mode option is not available in the Tools menu.
For more information on setting up role permissions, see QAD Security and Controls User Guide.
The specific customization activities you have access to determine how you can save your screen
customizations. For example, if you have access to all three activities, then you can choose to save
your changes at the user, role, or general level. If you have access to user level customization only,
then you must save your customizations for yourself.
When customizations are saved at the role level, the system uses the default role assigned in Role
Permissions Maintain. This is required since each user can have multiple roles active.
When a user accesses a function with multiple customizations, the system applies the most specific
customization in the order:
User customizations
Customizations for the users role
General customizations
If customizations exist for a function on multiple levels, the system does not merge the
customizations. It applies the most specific one it finds.
System and User Settings
Checking for the existence of a screen customization before displaying each screen requires
additional system resources and processing time. If you are not using customizations or some users
are not using them, this check can be disabled using a setting that can be defined at both the system
and user level.
A system administrator can clear the User Interface Customization setting in Change System
Settings (36.24.5.1) to prevent the system from ever looking for existing UI customizations.
Users can still use design modeif design mode activities are linked to their roles, but
customized screens are not displayed.
If User Interface Customization is enabled at the system level, each user can clear the User
Interface Customization setting in Change User Settings (36.24.5.2) to disable the check for
existing UI customizations for themselves. The user can still use design modeif design
mode activities are linked to their role, but customized screens are not displayed.
Note If customization is disabled at the system level, individual users cannot enable it.
Starting Design Mode

When you select Design Mode, the system prompts you to choose a customization level.
Fig. 12.1
Set Design Mode
1 Choose the level for the customizations:

General. The customizations are effective for all users.
Role. The customizations are effective for all users who have the selected role as their default
role.
User. The customizations are effective for you only.
Note The choices that display are based on the customization access you have been assigned.
See Security Settings on page 243.
2 If you chose the Role customization level, select the role for which the customizations apply.
You can only select from roles that are assigned to your user ID.
3 Select the component activity for which the customization applies; for example, Create,
Modify, or Delete. This feature lets you, for example, create a different screen layout for
viewing or approving transactions than the screen layout for creating or modifying
transactions.
4 Click Continue to confirm.
Note When you save a customization for a role other than your own role, a warning message
is displayed to inform you that the customization is only visible for users with that role.
Fig. 12.2
Sub-Account Create in Design Mode
Screen title
indicates
design
mode
Field being
customized
Field
properties

In design mode, a gray border is displayed around all fields. When you select a field, its border
color changes to red. By selecting the border, you can drag and drop a field or modify its
properties.
Field Properties
The Field list/properties window displays the properties that control the appearance of the selected
field.
The window contains two tabs, Properties and Events.
Properties Tab
Fig. 12.3
Field List/
Properties, Properties Tab
Field Descriptions
BackColor. Specify the color schema for the field. The system applies any color modifications
you make to the field border, and not the actual input zone.
Modify the numeric red, green, and blue properties of the field, or select a color from the drop-
down list.
Fig. 12.4
Color Palette
Field Name. This read-only technical field name is used by data binding information for the
control (internal use only).
Height. Specify the height of the field (label and input zone) in pixels.
Left. Specify the field position in pixels, relative to the left of the screen.
Max Length. Specify the maximum length of the field.
ScAppearanceName. Specify a user-defined setting from the Appearances.xml file to

apply to the field. The Appearances.xml file is a Cascaded Style Sheet, and contains
settings for color, shadowing, and alignment.
To create a new setting, add a new section to the Appearances.xml file, as follows:
<NewAppearSett>
<ImageHAlign>Center</ImageHAlign>
<ImageVAlign>Middle</ImageVAlign>
</NewAppearSett>
To apply the new setting to a field, specify the section that contains the settings in the
ScAppearanceName field; in this example, NewAppearSett.
The path to Appearances.xml is set in the QAD.Plugin.Financials.dll.config file.
ScChecked. Specify the initial value for check box fields.
ScEnabled. Specify True or False to enable or disable the field.

If you set the property to False, the field continues to display on the screen, but it is no longer
accessible in the UI. The field becomes read only, and cannot be tabbed to and its value cannot
be copied.
ScInitialValue. Specify the initial value of the field. You can use this setting to encourage the
use of a particular convention when entering data. For example, you can set the initial value of
the Cost Center field to ADMIN for a user who mainly creates transactions for the cost center
Admin. The user can overwrite the initial value of the field.
Note The initial value cannot be used for the Daybook field because, when you select a
daybook from a lookup, the system also retrieves a voucher number. If you used the
ScInitialValue field to set an initial value for a daybook, the system would not retrieve the
corresponding voucher number. However, you can use the Daybook Set functionality to set an
initial value for invoice daybooks for both AR and AP invoices.
ScLabelSize. Specify the amount of space in pixels (width; height) to allocate to the field
label.
ScLabelText. Specify the label text for the field.
Important The ability to change standard labels is very useful, but can create inconsistencies
between screens, and could also create confusion when communicating with the QAD Support
helpdesks.
ScReadOnly. Select True or False from the drop-down list to indicate whether the field is read-
only or editable. When set to True, the field cannot be updated, but can be tabbed to and its
contents can be selected and copied.
Top. Specify the field position in pixels, relative to the upper left corner of the screen.
Visible. Select True from the drop-down list to make the field visible on the UI. Select False to
hide the field (including the label).
You can also select a field and drag it into the BusinessFieldLabel section to remove it from
the UI window. You can also drag fields back from the BusinessFieldLabel section to the UI to
make them visible again.

Note Fields that are hidden from the UI are listed in the BusinessFieldLabel section of the
design window.
Width. Specify the width of the field (label and input zone) in pixels.
BusinessFieldLabel. This section of the design window lists fields that have been hidden on
the UI or user-defined fields that have been defined but not yet placed on the UI.
Use the two buttons as follows:
Reset to Initial Settings resets the properties of the field to the initial settings shipped with the
application. The system prompts you to confirm the reset operation.
Copy Settings copies the properties of the current customizations to another customization
level. You can choose the level and the role or user, if applicable.
Fig. 12.5
Copy Customization Settings
Event Tabs
The Events tab lets you use the events and properties of UI controls to add basic UI customization
code to UI elements. Examples of events include the following:
Enter, which controls the behavior of a field when it gets focus.
Leave, which controls the behavior of a field when the field loses focus.
You can select an event from a list of available exposed events for each field or control on the
screen for which you are using Design Mode. For any event you select, you can alter the properties
of other fields and controls, and specify conditions under which the properties must be altered.
Fig. 12.6
Field/List Properties, Events Tab
In the Events tab, the list of events is sorted alphabetically. When you select an event, a button
appears to the right of the event in the Code column. Click this button to open an editor in which
you can build a condition and an action (in the case of True or False values).
In the Custom Code for Event editor, you can customize the code using non-intrusive
customization. You must add custom code between the //Custom Code Start and //Custom
Code End lines. Any changes you make to the generated code outside of these lines are not saved
by the system.
Fig. 12.7
Custom Code for Event Form
In the Custom Code for Event editor, click OK to save and compile your customized C# code. If
the compiler finds errors, it displays the errors and the system cancels the saving of the customized
code.
Any C# code added using the Events tab becomes part of the UI customization data, and is stored
in the bcontrolproperty component. You can also export and import code customized in the
Custom Code for Event editor using Export UI Customization and Import UI Customization. See
Exporting Customizations on page 256 and Importing Customizations on page 257.
Event information is stored in XML format in the PropertyValue field. For events, the
PropertyName is always formatted as: EVENT:<eventname>.
Communicating with the Business Logic
When adding customized code using the Events tab, you can interact with the backend business
logic code using a generic method called UICustomization. The UICustomization method is
defined at business component level, and is available from every adapter in the system.
Note All methods defined on the adapter can be used to communicate with the backend business
logic code.
In the standard code, the UICustomization method does not hold any code, and must be
extended using non-intrusive customization on the backend.
The UICustomization method has three input parameters: controlname, eventname, and an
input dataset. The method also has one output dataset. These datasets contain identically structured
temporary tables. The temporary tables have three fields: control name, property name, and

value. The input parameter dataset contains control property values passed from the UI. The
output dataset must be interpreted by the custom code developer and property values must be
set accordingly.
Example
In this example, the UICustomization method has been used to customize the Search field
on the Business Relation record. If a user enters the value 1000 in the Search field and then
leaves the field, a user-defined field with the sc_tBusinessRelation_CustomShort1
identifier is enabled on the Business Relation screen. See User-Defined Fields on page 257.
PROCEDURE BBusinessRelation.UICustomization.after:
EMPTY TEMP-TABLE tUIOutput.
IF icControlName = "BusinessRelationSearchTextBox" AND
icEventName = "Leave"
THEN DO:
FIND FIRST tUIInput WHERE
tUIInput.tcControlName = "BusinessRelationSearchTextBox" AND
tUIInput.tcPropertyName = "Value" NO-ERROR.
IF AVAILABLE tUIInput AND tUIInput.tcValue = "1000"
THEN DO:
CREATE tUIOutput.
ASSIGN tUIOutput.tcControlName = "sc_tBusinessRelation_CustomShort1"
tUIOutput.tcPropertyName = "Enabled"
tUIOutput.tcValue = "false".
END.
END.
END PROCEDURE.
Working in Design Mode

You can remove a field from the UI by clicking on the field to activate it and setting the Visible
property to False.
The field is then stored in the BusinessFieldLabel pane of the design fame. To return the field
to the UI, click on it and drag it from the BusinessFieldLabel pane to the screen.
You can move a field within the UI by dragging it to its new location or by modifying the
position properties. You cannot drag a field from one tab to another. To reposition a field to a
new tab:
1 Set the Visible property to False. The field now displays in the business field area of the
Field List window.
2 Select the target tab to activate it.
3 Drag the field from the storage area to its new location.
Tab Sequence
The tab sequence of fields is automatically defined using the following rules:
The reference point is the upper left corner of the field in pixel coordinates.
The system tabs from left to right and from top to bottom.
Therefore, fields that seem to be on the same row can produce an unexpected tab sequence if the
second field on the row is positioned a pixel higher than the first. Refer to the field properties to
review and modify the field location.
Adding Tab Controls
Right-click on a blank area of the current form and select Add TabControl to add one new
customizable tab control to the current form.
Fig. 12.8
Add Tab Control
Adding Tabs and Text Fields
You can add new tabs to the current form. Right-click an existing tab header and select Add Tab
Page.
Fig. 12.9
Add Tab Page
The new tab is positioned at the end of the list of tabs and you can customize this tab as you do
existing tabs.
To add a new text control to the form, right-click an open area of the screen (not an existing tab
header) and select Add Text.
Fig. 12.10
Add Text Control
The new text control is placed at the top left of the form and can be customized and repositioned.

Adding Grids
When you have created a custom table, you can use drag and drop to add the table to the form as a
new grid.
Every business component has three available custom tables. They can be used on the UI, and also
in the back-end custom code.
A custom table can be put on a screen as a grid, or columns of the table can be put on a screen as
input fields, depending on the relation of the tables to the main table of the business component.
Using custom tables also requires non-intrusive customization of the business logic on the server.
This step ensures that the data is validated, saved in the database, and read when the object is
called again later.
If you want to add new fields to the UI, it is recommended to use User Defined Fields. These fields
are available for each component, and you can add them without customizing the business logic.
See User-Defined Fields on page 257.
Repositioning Fields on the User Interface
You can reposition any field by selecting it on the user interface and dragging it to the correct
position or by modifying the Left and Top properties of the field in the design window.
Fig. 12.11
Layout Section of Field Properties
To apply save customizations to the UI, choose Tools and clear the Design Mode field.
The system prompts you to confirm the changes and lets you select other activities for the business
component to which to apply the customizations.
Fig. 12.12
Save Customization
Field Descriptions
Customization Level. Select the level at which the customization applies.
General. The customizations are effective for all users.

Role. In the Role Name grid, select the roles for which the customizations apply.
User. The customizations are effective for you only.
Activity. The Save Customization screen lets you apply your customizations to other screens
related to the function you customized. This varies depending on the activities defined for each
component, but you can typically apply your customizations to the following screen types:
Create: Select to apply your layout customizations when the screen is used to create a new
record.
View: Select to apply your layout customizations when using the screen to view a record.
Modify: Select to include your layout customizations when using the screen to modify a
record.
Delete: Select to include your layout customizations when using the screen to delete a record.
Role Name. Select the roles for which the customizations apply. These fields are activated
when you select Role in the Customization Level field.
Click Yes to apply the changes to the selected activities. Click No to close the screen without
applying the changes.
Customize Views
Data grids are a common element in component-based functions. You can enable or disable the
data fields on the grid lines, or reposition them using generic UI features. The next time you access
the function, the grid displays with your modifications. For more information on browses and
grids, see Introduction to QAD Enterprise Applications User Guide.
Note Whether changes to grid settings are preserved from session to session is determined by
system and user settings discussed in Configuring System and User Settings on page 148.
You can also make more extensive customizations to the grid layout using design mode. If a grid
contains a large number of data fields, you can predefine column views using design mode.
You can also add custom tables to the form as a new grid.
The example in this section creates two views for the Banking tab of the Supplier screen: an
extended view containing all data and a condensed view with key data only.
1 Open the Supplier Modify screen.
2 Click the Banking tab.
3 Choose Design Mode from the Tools menu.
The Set Design Mode screen is displayed.
4 Choose the General customization level.

Fig. 12.13
Set Design Mode
5 Click in the grid to activate it for customization.

6 Right-click the column headings in the grid and choose Maintain Views.
Fig. 12.14
Right-Click Menu
7 In the Maintain Views screen, create two views by right-clicking and selecting Insert a New
Row.
Fig. 12.15
Maintain Views
8 Enter the name of the views in each row.

Fig. 12.16
New View
9 Click Save to create the view.

After creating the view, the design window shows an additional property for the grid:
ScViewsComboVisible.
Fig. 12.17
ScViewsCombo
Visible Property Field
ScViewsComboVisible,
set to True
10 Set the ScViewsComboVisible property to True.

An additional drop-down list is displayed in the Banking grid.
11 Select the Limited view from the new drop-down list.
Fig. 12.18
Banking Grid, New View
12 Right-click in the grid and select Columns.

The Column screen opens, listing all possible columns for the Banking grid.

Fig. 12.19
Columns
13 Deselect the columns that are not required for the condensed view.
14 Click OK to confirm.
15 Choose Tools and Design Mode to exit design mode.
16 In the Save Customization screen, select the save option and click Yes to save.
The customized grid now has the two views available in the combo-box at the end. The
columns displayed change as you move from one view to the other.
Delete Customizations
Use Customization Delete (36.4.19) to delete customizations to the UI. If a customization has been
applied to a business component, you can view it in the Customization Delete screen.
Fig. 12.20
Customization Delete
Field Descriptions
Component. Select the business component for which you want to view customizations.
Select. Click this check box to indicate that you want to remove the customization.
Activity. Select the activity from the drop-down list. This list of activities available depends on
the selected component. The default value is All.
Layer Number. Select the customization level (user, role, system).
Layer Value. If you selected User or Role in Layer Number field, use this lookup to select a
specific user or role.
Click Apply to populate the result grid. Select the customizations you want to delete and click
Delete to remove them.
Exporting Customizations
Use Export UI Customization (36.4.26) to export customizations for business component activities
including:
Customizations created in Design Mode, which are exported to BControlProperty.xml.
Saved grid settings, which are exported to BControlProperty.xml. To define grid settings,
right-click on the header of any grid and choose the Columns option.
User-defined field definitions, which are exported to BCustomField.xml.
User-defined component definitions, which are exported to BUDCConfiguration.xml.
Stored searches, which are exported to BStoredSearch.xml.
Report variants, which are exported to BReportVariant.xml.
Fig. 12.21
Export UI Customization
Business Component. Select the business component for which to export customizations.
You can also select the All option to export customizations for all business components.
Activity. Specify the business component activity for which to export customizations; for
example, Create, Modify, View, Delete, Monitor, Configure, or Maintain.
You can select any activity for the business component you select in the Business Component
field. You can also select the All option to export customizations for all activities for the
selected business component.
The Activity field is not available if you select the All option in the Business Component field.
Customization Level. Select the customization level for which to export customizations for the
business component and activity. The options are:
All. Select this option to export all customizations for the business component activity.
Role. Select this option to export all customizations for the business component activity
created by users with a particular role. If you select Role, you must specify the role for which
you want to export customizations.
System. Select this option to export all customizations for the business component activity that
were created using the General option. These customizations are at system level, and are not
tied to a particular role or user.

User. Select this option to export all customizations for the business component activity that
were created by a particular user. If you select User, you must specify the user for which you
want to export customizations.
Role. Specify the role to export all customizations for the business component activity that
were created by users with this role. The Role field becomes available if you select the Role
option in the Customization Level field.
User. Specify the user to export all customizations for the business component activity created
by this user. The User field becomes available if you select the User option in the
Customization Level field.
You can also select the All option to export customizations for all users.
Folder Name (on Appserver). Specify the full path of the folder to which you want to export
the customizations. This field is mandatory.
Importing Customizations
Use Import UI Customization (36.4.27) to import customizations for business component
activities.
Fig. 12.22
Import UI Customization
Folder Name (on Appserver). Specify the full path of the folder from which you want to
import UI customizations. This field is mandatory.
User-Defined Fields
User-Defined Fields (UDFs) are predefined fields in the database tables and can be customized to
store additional information specific to your business requirements.
Use User Defined Field Create to activate a UDF before you can add it to the UI.
When activated, a UDF can be designated as a filter field in the Search Criteria and can be added
to the Search Criteria Result Grid. UDFs are also available for Excel integration, if this
functionality is available for the component you have customized.
To include a UDF in the selection criteria for a report or in the report itself, you have to create a
non-intrusive customization in order to adapt the selection and the report logic.
UDFs are available for all business components, both on master data, such as business relations
and suppliers, and for transactional components, such as customer invoices and supplier invoices.
The following UDFs are available for each category of field:
Table 12.1
UDF Types
Type Number Validation
Combo 10 User-defined value list
Date 5 Valid date
Decimal 5 Valid decimal
Integer 5 Valid (signed) integer
Short 10 Free text (maximum 20 characters) or value retrieved
through lookup
Long 2 Free text (maximum 255 characters) or value retrieved
through lookup
Note 1 Free text (maximum 2000 characters)
QAD Reserved 4 These fields are reserved for use by QAD only.
There are four types of QAD reserved field:
QADCO1: Free text (maximum 20 characters) or
value retrieved through lookup
QADCO2: Free text (maximum 255 characters) or
value retrieved through lookup
QADT01: Valid date
QADD01: Valid decimal
Create a User-Defined Field

Use the User-Defined Field activities (36.4.12.) to create, modify, view, and delete UDFs.
Fig. 12.23
User-Defined Field Create
Field Descriptions
Business Component. Select the business component for which you want to create a UDF.
The drop-down list displays the components that have predefined UDFs.

Field Name. Select the field that you want to customize. Note that for components that have
subcomponent tables, the UDFs of the subcomponent appear in the list also. For example, the
Business Relation component has the subcomponents Address, Contact, and Tax Number.
When you select a business component, the custom fields available for the business
component are displayed in the field name drop-down list.
Description. Enter a brief description (maximum 40 characters) of the new UDF.
Side Label. Enter the field label that you want to display next to the UDF on the UI. The side
label is a translatable string.
Column Label. Enter the translatable string to appear in lookup and report column headers.
Display Format. This field displays the format of the field.
Display Length. This field displays the length in characters of the fields input or display zone.
The system displays a default value, depending on the field type, which you can overwrite.
Decimal Precision. Specify the number of decimal places allowed in the new UDF. This field
is enabled for UDFs of type decimal. The maximum number of decimal places is 10.
Mandatory. Select to make it mandatory for users to populate data in the new UDF.
Lookup. Select the type of lookup to associate with the new field. The Lookup field is enabled
if you select a CustomShort, CustomLong, or CustomCombo type field in the Field Name
field in the header.
The possible values are:
None: If you select the None option, the Lookup Reference, Stored Search, and Return
Field are disabled.
Stored Search: If you select the Stored Search option, you must use the Lookup Reference
and Stored Search fields to identify the stored search.
Browse: If you select the Browse option, the Stored Search field is updated to display the
label Browse and the Lookup Reference field becomes read-only. You then use the
Browse field to specify the relevant browse definition.
Generalized Code: If you select Generalized Code, the Lookup Reference field lets you
select values from the Generalized Codes (code_mstr) table. If you select the Generalized
Code option for a CustomCombo type field, the Value List tab is disabled in the User-
Defined Field screen.
Other: If you select Other, you can define a custom query in the Lookup Reference field.
The Stored Search and Return Field fields are disabled.
If you are creating a CustomCombo field, you can only select the values None or Generalized
Code.
Lookup Reference. Click the lookup to select a query from the list of predefined queries. This
field lets you specify a standard lookup to associate with the user-defined field. Users can then
select a value from the lookup. For example, you can add a UDF to the Customer Invoice
object and give it the name Supplier Code, and specify the Supplier lookup as the Lookup
Reference. When users create customer invoices, the Supplier Code UDF appears in Customer
Invoice Create, and there is a lookup button next to that field listing all supplier codes.
The Lookup Reference field is enabled when you select a field of type CustomShort or
CustomLong in the Field Name field.
Stored Search. This field is automatically populated when you enter a value in the Lookup
Reference field. This value can be FACTORYDEFAULT for system-installed searches or a
user-defined name for stored searches.
The lookup attributes are controlled through these defaults, such as columns and display order.
Return Field. If a query returns multiple values, select the one with which the UDF value list
must be populated.
Note To prevent a user from overwriting the value selected from the return list, set the
ScReadOnly property of that field to True.
Value List Tab
Use the Value List tab to define the list of values for a drop-down list UDF. Right-click and choose
Insert a New Row to specify a specific value.
Fig. 12.24
User-Defined Field. Value List Tab
UDFs and Design Mode

Use design mode to add UDFs to the appropriate screen. When you create a UDF for a component,
it is stored in the BusinessFieldLabel pane of the design window.
To add a UDF to a screen, select it and drag it from the Business Field Label section to its new
position on the screen.

Fig. 12.25
Field Properties Tab with UDF
User-Defined
Field
Modifying UDFs
The range of UDF properties you can modify depends on whether the field has been used. A UDF
is considered used if it appears on the UI and at least one value has been stored for it in the
database.
If the UDF is used, you can still modify the following properties:
Description
Side Label
Column Label
Value list (for Combo type UDFs only)
Lookup Reference, Stored Search, Stored Search Return (for Short and Long type UDFs only)
If a UDF is not used, you can modify the following additional properties:
Mandatory
Display Length
Decimal Precision (for decimal type UDFs only)
You can delete a UDF if it has not been used.
Adding Fields to Financials QRF Reports

Use the following process to add user-defined fields to Financials reports developed using the
QAD Reporting Framework (QRF):
1 Create the user-defined field. See Creating the New Field on page 262.
2 Link the new field to the QRF report, and specify the report resultset field that will display
data for the new user-defined field. See Linking the UDF to the Report on page 262.
3 Use Report Resource Designer (36.4.21.30) to add the resultset field to the report. See
Adding the Resultset Field to a Report on page 264.
Creating the New Field
To add a user-defined field to a QRF report, determine the component for which you want to add
the field, and add the field to a component that is part of the reports dataset. For example, to
customize the Supplier Check Print report, you can add fields to the Supplier component or to the
Supplier Invoice component.
Define the field using the User-Defined Field function. See Create a User-Defined Field on
page 258 for detailed information.
Fig. 12.26
User-Defined Field Modify
Important After you define the field, add the field to the UI using design mode so that the field
can become usable and receive data that can be displayed on the report. See UDFs and Design
Mode on page 260
Linking the UDF to the Report
Use User-Defined Fields on Report Maintain (36.25.92) to associate user-defined fields with
reports developed using QRF. When you open User-Defined Fields on Report Maintain, a browse
displays a list of all Financials reports developed using QRF.
Fig. 12.27
User-Defined Fields on Report Maintain Browse

In the browse, select the report to which you want to add the user-defined field. Then, right-click
and select Maintain UDF.
Fig. 12.28
User-Defined Fields on Report Maintain Browse, Context Menu
When User-Defined Fields on Report Maintain opens for the report you selected, the grid lists the
user-defined fields that have been created for components in the reports dataset. Locate the field
you want to add to the report, and, in the Resultset Field column, specify the report field in which
you want to display data. Save your changes.
Fig. 12.29
User-Defined Fields on Report Maintain
Report. Displays the name of the data source for the report.
End User Field. Displays the database field name for the user-defined fields that have been
created for components in the reports dataset.
End User Field Description. Displays a description of the user-defined field, as defined in
User-Defined Field Create.
Resultset Field. Select the report field in which you want to display data for the user-defined
field. Select a resultset field of the same type as the user-defined field. For example, if the
user-defined field is a date field, select a resultset date type field.
Adding the Resultset Field to a Report
To add the user-defined field to a QRF report, open the report in Report Resource Designer. Add
the report resultset column that you linked to the user-defined field to the report design and then
save your changes.
Fig. 12.30
Report Resource Designer, Supplier Check Print Report
For more information on QRF reports and on Report Resource Designer, see QAD Reporting
Framework User Guide.
User-Defined Components
The User-Defined Components option lets you define your own business component for use in the
application.
You implement this option by customizing a generic back-end business component, and deploying
generic business classes that are designed specifically for customization. You then use non-
intrusive customization techniques to implement data loading and saving for the new component.
These techniques are described in Chapter 10, Customizing Business Logic, on page 211.
You can create the following types of user-defined components:
Create/Modify/View/Delete. This component type is used to create, modify, view and delete
records in the usual way. This is the standard program type, and only one instance of the
component is displayed on the form at one time. Examples of this program type include
Country Create and Cost Center Create.

Maintain. This component type is used to maintain existing records. Maintenance programs
display multiple instances of the component in a maintenance grid on the form, and are most
useful for components for which there are not a great number of records. An example of a
maintenance program is Payment Format Maintenance, in which all the records are displayed
in the form grid, and you can create, modify, and delete records in the same form.
You can create components of one type or the other, but you cannot assign both
Create/Modify/View/Delete activities and the Maintain activity to the same component.
The following sections describe the code elements required to implement a new business
component, and also a sample implementation of the procedure.
Elements of User-Defined Component Implementation

The following component and classes are designed for use with user-defined components:
BCustom, the generic customizable business component
Customform.cs, the generic form used for all user-defined components
CustomAdapter.cs, the generic adapter class
CustomProcessObject.cs, the generic process object
BCustom
This is the generic component used for customization.

The BCustom object dataset contains three custom tables only:
tCustomTable0
tCustomTable1
tCustomTable2
You must devise the data loading and saving mechanisms by writing custom code for the DataNew
and DataLoad methods using non-intrusive customization techniques.
Activities
BCustom has the following related activities:

Create
Modify
View
Delete
Maintain
The Create, Modify, View and Delete activities handle single instances of the component. The
Maintain activity handles multiple instances, and requires a different DataLoad implementation.
You can implement either the Create, Modify, View, and Delete activities or the Maintain activity
for the component, but you cannot implement both.
The implemented activity is named and displayed in the menu in the usual way, using the syntax:
urn:cbf:BCustom[<user-defined component name>].<activity>
For example, the Create activity for a newly defined Province component is displayed as follows:
Example: urn:cbf:BCustom[Province].Create
vcCustomComponent Variable
The vcCustomComponent variable is defined for BCustom and is set at the instantiation of the
component. This variable contains the name of the custom component, which is taken from the
URN specified for the menu item. This variable must be set before any other method on the
component can be run.
The system loads customizations for standard components by checking the /customcode folder
for customized .p files. In the same way, the system also checks the /customcode folder for
bcustom[<vcCustomComponent>].p files for customizations of the custom component you
have created.
Select Query
You can add a select query to the custom component for use with Modify, View, and Delete
activities. You implement the query using non-intrusive customization techniques. See page 270
for details on coding a select query.
CustomForm.cs
CustomForm.cs is inherited from ScForm and is used for all user-defined components. It does
not contain any controls (except for the standard buttons on every form). You customize this form
using non-intrusive customization, and use the form in combination with the adapter
CustomAdapter.cs and process object CustomProcessObject.cs.
The constructor of this form has an extra input parameter for the user-defined component name
that is set on the process object. This parameter takes its value from the component name defined
between the square brackets in the menu URN (for example, Province from
urn:cbf:BCustom[Province]. The parameter is passed to the GetProcessObject method
on the custom adapter, which then passes it to the business layer when instantiating the custom
business component.
CustomAdapter.cs
CustomAdapter.cs is the generic custom adapter class, and is inherited from ScAdapter.cs.
This custom adapter communicates with BCustom on the back end.
CustomProcessObject.cs
This is the generic process object class, and is inherited from ScProcessObject.
CustomProcessObject.cs holds data for CustomForm. It contains the property
ComponentName, which holds the name of the custom component in use.
User-Defined Components Maintain

Use the User-Defined Components Maintain (36.4.12.1.1) option to maintain user-defined
components.

Fig. 12.31
The grid displays existing user-defined components.

When you have coded a new component, insert a new row in the grid and complete the fields.
User-Defined Component Code. Enter the code that identifies the component. This must
match the code you use in the URN for the menu item. For example, when the URN for a
newly defined component is urn:cbf:BCustom[Province], the code you enter in the field
must match the code between the square brackets (Province).
User-Defined Component Label. Enter a label for the component which identifies it in the
system.
Create/Modify/View/Delete. Select the activities you have defined for this component. When
you select one or a combination of these activities, the Maintain activity is unavailable.
Maintain. Select this field when you have created a maintenance component only. When you
select this field, the other activities are unavailable.
Example of User-Defined Component

In this example, you create a Province program (similar to the Country or State programs), which
you can use to create, modify, view, and delete provinces. The example includes a description of
how to create a lookup for the existing Country component, which you select in order to identify
the country to which the province belongs. You use the non-intrusive customization method to
deploy the customized code in the baseline.
Non-Intrusive Customization
When coding a user-defined component, you use non-intrusive customization techniques. QAD
application component code is based on a standard code template. You can customize any of the
standard activities (for example, Create, Modify, or Delete) by writing code that is activated with a
publish-subscribe mechanism, in which a customized event is published before or after the
component code. A code template (BComponent.p) is provided for each business component.
The template code is commented, and to hook the event code into the component process, you
uncomment the event and add the necessary component code. This process is called non-intrusive
customization, because the customized code is added before or after the standard code, but does
not intrude on the standard code itself. This technique is described in Chapter 10, Customizing
Business Logic, on page 211.
Creating a New Component

The procedure for creating a new component can be divided into three parts:
Preparing the component data
Creating the customized code

Deploying the new component in the application
Preparing the Component Data
Use the following steps to prepare the data for the new component:
1 Create a new database.
When you create a new component, it is recommended that you create a new database in
which to store the data. This avoids data loss or conflict when you upgrade your application.
You should ensure that the new database starts and stops at the same time as your application
database.
2 Update the server.xml file for the appserver to include an entry for your new database. This
ensures that it is automatically connected when you run the application:
<database>
<name>C:\Work\Foundation\mycustomizations\db\mycustom</name>
<parameters></parameters>
</database>
3 Create the necessary tables and fields (and indexes) to store the data in.
For this example, create the following Province table:
Table: Province
FIELD SUMMARY
Flags: <c>ase sensitive, <i>ndex component, <m>andatory, <v>iew component
Order Field Name Data Type Flags

----- ---------------------------- ----------- ----
5 Province_ID inte i
10 ProvinceCode char i
20 ProvinceDescription char
30 CountryCode char
Field Name Format

-------------------------------- -----------------------------
Province_ID ->,>>>,>>9
ProvinceCode x(20)
ProvinceDescription x(40)
CountryCode x(20)
Field Name Initial

----------------------------- -----------------------------
Province_ID 0
ProvinceCode
ProvinceDescription
CountryCode
Field Name Label Column Label

----------------------- ---------- ----------
Province_ID ? ?
ProvinceCode ? ?
ProvinceDescription ? ?
CountryCode ? ?
INDEX SUMMARY
Flags: <p>rimary, <u>nique, <w>ord, <a>bbreviated, <i>nactive, + asc, - desc
Flags Index Name Cnt Field Name

--- ------------------------ --- ------------
u Code 1 + ProvinceCode
pu prim 1 + Province_ID
The Province_ID column is not strictly necessary, but some constructions in the framework
depend on having an ID column.
Creating the Customized Code
1 Review the non-intrusive customization techniques described in Chapter 10, Customizing

Business Logic, on page 211.
2 Copy bcustom.p from the template directory to your work directory and rename it
bcustom[province].p.
The code name between the square brackets needs to match the name of your user-defined
component, which will be created later in the procedure.
The custom component has three tables you can use to contain your data: tCustomTable0,
tCustomTable1, and tCustomTable2. You must use at least one of these tables. In this
example, only one table is required:
3 Uncomment the BCustom.DefineCustomRelations.before method and add the
following code:
create tCustomRelation.
assign tCustomRelation.tcParentTable = ""

tCustomRelation.tcChildTable = "tCustomTable0"
tCustomRelation.tcChildTableDescription = "Province"
tCustomRelation.tlIsOneToOne = true.
Because this is the main table, you do not complete the tcParentTable field.
When creating a component that uses the Create/Modify/Delete/View activities, you require a
Select query to run in the browse for the Modify, Delete, and View activities:
4 Uncomment the BCustom.ApiSelectCustom.after method and adding the following
code:
define variable vhBuffer as handle no-undo.
define variable vhProvince as handle no-undo.
if not t_Parameter.ilCountOnly
then do:
create temp-table vhProvince.
vhProvince:create-like(buffer Province:handle).
vhProvince:add-new-field("tc_rowid", "character").
vhProvince:add-new-field("tiCustom[Province]_ID", "integer").
vhProvince:temp-table-prepare("tqApiSelectCustom").
vhBuffer = vhProvince:default-buffer-handle.
end.
for each Province no-lock:

if t_Parameter.ilCountOnly
then assign t_Parameter.oiCount = t_Parameter.oiCount + 1.
else do:
vhBuffer:buffer-create().
vhBuffer:buffer-copy(buffer Province:handle).
vhBuffer:buffer-field("tiCustom[Province]_ID"):buffer-value = Province.Province_ID.
vhBuffer:buffer-field("tc_rowid"):buffer-value = string(rowid(Province)).
end.
end.
if not t_Parameter.ilCountOnly
then t_Parameter.ozApiSelectCustom:set-buffers(vhBuffer).
assign t_Parameter.olEndOfQuery = true.

This creates a dynamic temp-table similar to the database table. Two fields are added:
tc_rowid (required to make the framework work correctly) and tiCustom[Province]_ID
(required to make the browse work correctly). Again, the code name between the square
brackets needs to match the name of your custom component.
You also need to ensure that you have business field definitions for the fields used in the query:
5 Uncomment BCustom.GetBusinessFields.after and add the following code:
if t_Parameter.icReference = "ApiSelectCustom"
then do:
create tBusinessFields.
assign tBusinessFields.tcSideLabel = "Province Code"
tBusinessFields.tcColumnLabel = "Province"
tBusinessFields.tcControlType = "TextBox":U
tBusinessFields.tcFcFieldType = "F":U
tBusinessFields.tcDataType = "c":U
tBusinessFields.tcDisplayFormat = "x(20)"
tBusinessFields.tcLookupFilterField = ""
tBusinessFields.tcLookupQuery = ""
tBusinessFields.tcLookupReturnField = ""
tBusinessFields.tcRelatedObject = ""
tBusinessFields.tcFilterOperators = "":U
tBusinessFields.tcFcFieldName = "tCustomTable0.tcCustomShort0".
assign tBusinessFields.tcSideLabel = "Province Description"
tBusinessFields.tcColumnLabel = "Description"
tBusinessFields.tcControlType = "TextBox":U
tBusinessFields.tcLookupFilterField = ""

tBusinessFields.tcLookupQuery = ""
tBusinessFields.tcLookupReturnField = ""
tBusinessFields.tcFilterOperators = "":U
tBusinessFields.tcFcFieldName = "tCustomTable0.tcCustomLong0".
assign tBusinessFields.tcSideLabel = "Country Code"
tBusinessFields.tcColumnLabel = "Country"
tBusinessFields.tcControlType = "TextBox"
tBusinessFields.tcLookupFilterField = "tCountry.CountryCode"
tBusinessFields.tcLookupQuery ="BCountrySAO.SelectCountry"
tBusinessFields.tcLookupReturnField = "tqSelectCountry.tcCountryCode"
tBusinessFields.tcFilterOperators = ""
tBusinessFields.tcFcFieldName = "tCustomTable0.tcCustomShort1".
assign tBusinessFields.tcSideLabel = "Province Code"
tBusinessFields.tcColumnLabel = "Province"
tBusinessFields.tcFcFieldName = "tqApiSelectCustom.ProvinceCode"
tBusinessFields.tcFcFieldType = "B"
tBusinessFields.tiSequence = 0
tBusinessFields.tcDataType = "c"
tBusinessFields.tcDisplayFormat = "x(20)".
assign tBusinessFields.tcSideLabel = "Province Description"
tBusinessFields.tcColumnLabel = "Description"
tBusinessFields.tcFcFieldName ="tqApiSelectCustom.ProvinceDescription"
assign tBusinessFields.tcSideLabel = "Country Code"
tBusinessFields.tcColumnLabel = "Country"
tBusinessFields.tcFcFieldName = "tqApiSelectCustom.CountryCode"
end.
Notice that some business fields have tcFcFieldType set to F. These fields appear in the
filter of the browse. It is important to ensure that the tcFcFieldName field matches the name
defined for the fields in the custom table you are using. Note also that the lookup fields are
completed for the Country Code filter field. Here we reuse the existing lookup for Countries so
the user can select a country on which to filter.
You can also notice that some business fields have tcFcFieldType set to B. These fields
appear in the results grid of the browse. Use the tiSequence field to define the initial order
of the columns in the grid. You can use any value for the tcFcFieldName field, providing it
begins with tqApiSelectCustom and does not contain more that one ..
You now create code to load data from the new database into the custom table:
6 Uncomment the BCustom.DataLoad.after method and add the following code:
define variable viA as integer no-undo.
if t_Parameter.icPKeys <> "" and

t_Parameter.icPKeys <> ?
then do viA = num-entries(t_Parameter.icPKeys, chr(4)) to 1 by -1:
find Province where
Province.Province_ID = int(entry(viA, t_Parameter.icPKeys, chr(4)))
no-lock no-error.
if not available Province

then do:
run SetMessage(
input "Province with ID $1 not found.",
input entry(viA, t_Parameter.icPKeys, chr(4)),
input "",
input "",
input "E",
input 3,
input "",
input "PROVINCE-6",
input "",
input "",
input "",
output t_Parameter.oiReturnStatus).
assign t_Parameter.oiReturnStatus = -1.

return.
end.
create tCustomTable0.
create t_iCustomTable0.
assign tCustomTable0.tiCustomInteger0 = Province.Province_ID

tCustomTable0.tcCustomShort0 = Province.ProvinceCode
tCustomTable0.tcCustomLong0 = Province.ProvinceDescription
tCustomTable0.tcCustomShort1 = Province.CountryCode
tCustomTable0.tc_Rowid = string(rowid(Province)).
buffer-copy tCustomTable0 to t_iCustomTable0.

end.
if t_Parameter.icRowids <> "" and

t_Parameter.icRowids <> ?
then do viA = num-entries(t_Parameter.icRowids) to 1 by -1:
find Province where
rowid(Province) = to-rowid (entry(viA, t_Parameter.icRowids))
no-lock no-error.

then do:
run SetMessage(
input "Province with RowID $1 not found.",
input entry(viA, t_Parameter.icRowids),
input "",
input "",
input "E",
input 3,
input "",
input "PROVINCE-7",
input "",
input "",
input "",

return.
end.
create tCustomTable0.
create t_iCustomTable0.
assign tCustomTable0.tiCustomInteger0 = Province.Province_ID

tCustomTable0.tcCustomShort0 = Province.ProvinceCode

tCustomTable0.tcCustomLong0 = Province.ProvinceDescription
tCustomTable0.tcCustomShort1 = Province.CountryCode
tCustomTable0.tc_Rowid = string(rowid(Province)).
buffer-copy tCustomTable0 to t_iCustomTable0.

end.
Note that the fields tiCustomInteger0, tcCustomShort0, tcCustomLong0, and

tcCustomShort1 are used to store new data. You later define those fields as user-defined fields
for the Province component, in the same way as you define user-defined fields for any component.
You now write the code required to create a new Province.
7 Uncomment the BCustom.DataNew.after method and add the following code:
define variable vhPersistence as handle no-undo.
run AddDetailLine(
"CustomTable0",
"",
run StartPersistence(output vhPersistence, output t_Parameter.oiReturnStatus).
if t_Parameter.oiReturnStatus < 0
then return.
assign tCustomTable0.tiCustomInteger0 = dynamic-function("GetNextValue" in vhPersistence,

"ObjectNumber").
The standard mechanism is used to assign a new value to the Province_ID

(tiCustomInteger0) field.
You now write the code required to validate the data entered by the user:
8 Uncomment the BCustom.ValidateComponent.after method and add the following
code:
for each t_sCustomTable0 where
t_sCustomTable0.tc_Status = "N" or
t_sCustomTable0.tc_Status = "C":
if t_sCustomTable0.tc_Status = "C"
then do:
find t_iCustomTable0 where
t_iCustomTable0.tc_Rowid = t_sCustomTable0.tc_Rowid
no-error.
if not available t_iCustomTable0

then do:
run SetMessage(
input "t_iCustomTable0 with rowid " + t_sCustomTable0.tc_Rowid + " not
found.",
input "",
input "",
input "",
input "E",
input 3,
input t_sCustomTable0.tc_Rowid,
input "PROVINCE-1",
input "",
input "",
input "",

return.
end.
if t_sCustomTable0.tcCustomShort0 <> t_iCustomTable0.tcCustomShort0

then do:
run SetMessage(
input "It is not allowed to change the Province Code of an existing
Province.",
input "",
input "tCustomTable0.tcCustomShort0",
input t_sCustomTable0.tcCustomShort0,
input "E",
input 3,
input "PROVINCE-2",
input "",
input "",
input "",

end.
end.
else
if can-find(first Province where
Province.ProvinceCode = t_sCustomTable0.tcCustomShort0)
then do:
run SetMessage(
input "Province already exists.",
input "",
input "E",
input 3,
input "PROVINCE-3",
input "",
input "",
input "",

end.
if t_sCustomTable0.tcCustomShort1 <> "" and

(t_sCustomTable0.tc_Status = "N" or
t_sCustomTable0.tc_Status = "C" and
t_sCustomTable0.tcCustomShort1 <> t_iCustomTable0.tcCustomShort1)
then do:
if not can-find(first Country where Country.CountryCode =
t_sCustomTable0.tcCustomShort1)
then do:
run SetMessage(
input "Invalid country code.",
input "",
input "E",
input 3,
input "PROVINCE-4",
input "",
input "",
input "",

end.
end.
end.
You finally require code to store the new and modified data in the database.

9 Uncomment the BCustom.DataSave.after method and add the following code:

for each tCustomTable0 where
tCustomTable0.tc_Status <> "":
if tCustomTable0.tc_Status = "C" or
tCustomTable0.tc_Status = "D"
then do:
find Province where
Province.Province_ID = tCustomTable0.tiCustomInteger0
exclusive-lock no-error.

then do:
run SetMessage(
input "Province $1 not found.",
input tCustomTable0.tcCustomShort0,
input "",
input "",
input "E",
input 3,
input "",
input "PROVINCE-5",
input "",
input "",
input "",

return.
end.
if tCustomTable0.tc_Status = "D"
then do:
delete Province.
next.
end.
end.
else do:
create Province.
assign Province.Province_ID = tCustomTable0.tiCustomInteger0.
end.
assign Province.ProvinceCode = tCustomTable0.tcCustomShort0

Province.ProvinceDescription = tCustomTable0.tcCustomLong0
Province.CountryCode = tCustomTable0.tcCustomShort1.
end.
Important In order to compile this code, the application database and your custom database (if
you created one) must be connected.
10 Compile the custom code by executing the build.p.
Make sure the build.p contains the following line:
compile value("bcustom[province].p") save into
C:\Work\Foundation\mycustomizations\customcode.
The folder you save the code into must be the folder where your custom compiled code is
located.
11 Trim the Financials appserver to make sure the customization controller picks up the changed
file.
Deploying the New Component in the Application.
1 Run the application.

2 Run the User-Defined Components Maintain menu option and do the following:
a Insert a new row in the grid.
b Complete the necessary fields. Make sure that the User-Defined Component Code
matches the code name used in the URN (see Elements of User-Defined Component
Implementation on page 265).
c Click on the Save button to save the definition of your user-defined component.
Fig. 12.32
3 Use User-Defined Field Create to create a user-defined field for each field you used in your
custom code.
In this example, you need a field for tCustomTable0.tcCustomShort0,
tCustomTable0.tcCustomLong0 and tCustomTable0.tcCustomShort1.
Note You do not define a field for tCustomTable.tiCustomInteger0. This field in the
code contains the Province_ID, which should not be visible in the interface.
Fig. 12.33
User-Defined Field, Province

Fig. 12.34
User-Defined Field, Province Description
Fig. 12.35
User-Defined Field, Province Country
Because the existing country lookup is linked to the country code field, the user can select a
country instead of typing an existing country code.
4 Create menu items for the activities using Menu System Maintenance.
Fig. 12.36
Menu System Maintenance
Again, the code name between the square brackets in the Exec Procedure field must match the
code of your custom component exactly.
Do the same for the Modify, View and Delete activities.
5 In Role Permissions Maintain, double-click on each role that requires permissions for the
Province activities and link those activities to the role.
Fig. 12.37
Role Permissions Maintain
6 Log out of the application and back in again to ensure the new menu items are deployed.
7 Run Province Create.

Fig. 12.38
Province Create
An empty form is displayed. You must still design the layout of the form.
8 Click on Tools/Design Mode.
Fig. 12.39
Design Mode, Customization Level
9 Select General as the Customization Level.

This ensures that your design can be used by all users that have rights to execute Province
Create.
The Field List/Properties dialog is displayed. Collapse or expand the fields of the Province
table by clicking the icon.
Fig. 12.40
Field List/Properties Dialog
You can choose to drag and drop the entire Province table to your form. However, this results
in a grid, which is more normally used in maintenance components. Because you are using the
Create/Modify/View/Delete activities, you drag and drop each field individually to your form.
Fig. 12.41
Customized Province Form
When you close the design form, you are prompted to save your changes.
Fig. 12.42
Province Form Save Changes
You normally use the same form layout for the View, Modify, and Delete activities.
10 Select the Save field for these activities and click to save the new form design.
11 Test all activities for the Province program in the application.

Financial Text Translation

You can maintain label and message translations in the financial programs by using Financial
Translation Maintenance (36.24.10).
This program enables you to:
Search for financial translations using different filters.
Edit current translations while keeping a record of the original.
The program also marks a record as updated when it is modified and records the last modified user
ID and date.
Note When you run System Synchronize (36.24.3.2), it does not overwrite records that you have
changed. Also, although Financial Translation Maintenance does not maintain report text directly,
the report text does refer to the financial translations. Therefore, if you run System Synchronize
with report text, the report text copies the values in the financial translations.
Fig. 12.43
Financial Translation Maintenance
There are two ways to update current strings:

In the grid, in the Current Text column, type the new text and click Save. This approach is
generally best when you want to edit one string.
In the New Text For Selected Rows field, type the new text and select the row or rows to
display the new text, and click Apply. To keep your changes, click Save. This approach is best
when you want to update multiple strings with the same text.
The fields in the program have the following function:
Language. Specify the language code for the text you want to search for. This field is
mandatory.
Text Number. Enter the string number of the text you want to search for. This field is useful
because there are many translation records with the same meaning but with unique string
numbers. If you do not enter a text number, you must enter either the current text or the
original string.
Current Text. Enter the current translated text as it appears in the interface. If you do not enter
the current text, you must enter either the text number or the original string. This field accepts
wild cards.
Original Text. Enter the original string as supplied by QAD. The original text is stored in the
system permanently with its initial values. If you do not enter the original string, you must
enter either the text number or the current text. This field accepts wild cards.
When you click Search, the grid populates with the matching text strings. Most of the fields in the
grid are read only.
However, you can select the Selected field to indicate a string to apply changes to or to be saved.
To change the text of a current string, you can also edit the text in the Current Text column directly.
When you edit the current text, the row is automatically selected. If you clear a selected row, any
changes are discarded and the row reverts to the previous text.
Note Some strings contain placeholders such as '&1', '&2', which are replaced by the relevant
program. You cannot change these placeholders, and if you try, an error message is displayed.
However, you can edit other parts of the string.
The original text is still saved in the system, and is displayed in the Original Text column, as
displayed in Figure 12.44. The other columns are Language, Label, Last Updated Date, Last
Updated Time, and Last Updated User. Three additional columnsComponent Code, Component
Category, and Projectare hidden by default.
Fig. 12.44
Financial Translation - Original Text
New Text For Selected Rows. You can change multiple rows simultaneously by using this
field. Select the rows that are to contain the updated text and then type the text in this field.
When you click Apply, the Current Text field in the grid is updated.
Make sure you click Save so that your changes take effect. You can view your changes when the
next system trim takes place. The frequency of a system trim depends on organization policy. If
you perform a second search before saving your changes, the changes are lost and the grid
populates with the new data.

Chapter 13
Installing Electronic Bank File

Formats
This chapter describes the procedure for installing a custom bank file format for use in electronic
banking.
Introduction to Electronic Banking Format Installation 284
Explains how electronic banking functions are used by Enterprise Financials.
Setting up EDI eCommerce to Use Imported Bank Formats 284
Explains how to set up EDI eCommerce to use imported bank formats.
Using Bank File Format Import to Install the Format 287
Explains how to use Bank File Format Import to install formats.
Default Directory Settings 289
Discusses default directory settings.
Introduction to Electronic Banking Format Installation

To use the electronic banking functions in Enterprise Financials, you must complete the setup
steps for bank accounts and payment formats. Each electronic transaction requires a payment
format appropriate for the type of payment, which is then linked to the dedicated bank account for
the customer or supplier. For more information on setting up electronic banking, see QAD
For many electronic payment files, you must import predefined formats that are customized for the
banks individual requirements. The imported formats are then displayed in the list of available
payment formats and can then be linked to the bank accounts used for the payments.
To configure and install these predefined formats, you use a number of EDI eCommerce functions
to create a definition for the specific bank file format. You then use the Bank File Format Import
(31.23) program to import the file into the Financials application. You can link the dedicated file
format to the customer or supplier bank account.
Setting up EDI eCommerce to Use Imported Bank

Formats
Before importing the bank file formats, you must define the following information in EDI
eCommerce:
The file names and number range sequences for the banking files that will be produced using
this format.
The default data input and output eCommerce directory locations.
The number counters for both the banking files and for the eCommerce application itself.
A cross-reference between the users QAD domain and the eCommerce processing domain.
Use the following procedure to complete this setup.

Installing Electronic Bank File Formats 285
Create Number Range Sequences in EC Number Range Maintenance (35.21.1).
Fig. 13.1
EC Number Range Maintenance
1 Create five number range sequences; for example, using the sequence IDs ecFin1, ecFin2,
ecFin3, ecFin4, ecFin5.
2 For each sequence, ensure that the Target Dataset fields Internal, Allow Discarding, and Allow
Voiding are selected.
3 Each sequence must contain two segments: a Fixed segment in which you specify the Fixed
part of the format filename, and an Integer segment in which you specify the numeric part of
the format filename. For example, when you specify edi as Fixed, and a number range of 0 to
999999999, you ensure that the bank files you produce using this format will be named
edi00000001.*
The file extensions for these files are defined in EC Subsystem Definition Maintenance
(35.13.1).
The five sequences you create are later used to specify counters in eCommerce Control. See
Assign Number Sequences to EDI Documents on page 286.
Note You complete these steps for the first installation of bank format files onlyyou do not
need to complete the process the next time you install an additional bank file format or when
installing an update of an existing bank format.
View the EDI Control File in eCommerce Control (35.13.24)
Fig. 13.2
eCommerce Control, Default Directories
The EDI Control File displays the default server directories for data import and export, and for
the EDI functions and process log.
You must ensure that the application users have read/write permissions for these folders, and
that the server path name is displayed in full for each directory.
The Functions path name must also be included in the Appserver Propath to ensure that EDI
functions execute correctly.
Assign Number Sequences to EDI Documents
Fig. 13.3
eCommerce Control, Number Sequences
4 Click Next on the eCommerce Control screen to display the Counter fields.
5 Select the number sequences created previously for each of the five fields.

Assign Number Sequences to the EDI application
6 Click Next to display the Application frame.

Fig. 13.4
eCommerce Control, Applications Frame
7 Select the EDI application in the Application lookup (the default application).
8 Select the number sequences created previously for each of the five fields.
Note For more information on the eCommerce Control fields, see QAD EDI eCommerce User
Guide.
Create a Domain Cross-Reference
9 Use Domain Cross-reference Maintain (35.11.1) to create a cross-reference between the EDI
eCommerce users log-in domain and the domain used in eCommerce processing.
Fig. 13.5
Domain Cross-Reference Maintain
By defining cross-references, you can let users log in to their usual domain, but still process EDI
eCommerce imports and exports in a different domain.
A QAD eCommerce processing domain is provided by default.
Using Bank File Format Import to Install the Format

Each imported format file is specific to an individual bank and contains the payment information
and attributes required for that bank.
The format definition files are usually delivered by the bank in zipped XML format. You unzip the
files to a server directory and then load the files into the system using Bank File Format Import
(31.23).
This program creates mapping records that let the system process incoming files correctly, using
the configuration you defined in EDI eCommerce. It also generates the outbound files that meet
the requirements of the receiving bank. Additionally, it updates a set of financial setup tables that
define the payment format for each bank.
Fig. 13.6
Bank File Format Import
1 Specify the Input Directory in which the unzipped XML files are stored.
2 Select Some, All, or a single bank XML file.
The eCommerce domain is a read-only field indicating the domain that the trading partner
information will be loaded into. If the definition needs to be loaded into a different eCommerce
domain, you must exit this screen, change to a different eCommerce domain and re-open this menu
option. An eCommerce domain is associated with one or many QAD domains. During export
processing, the QAD domain is used to determine the eCommerce domain in which to process
under.
Note For more information on domains, see QAD EDI eCommerce User Guide. Bank File
Format Import is described in detail in QAD Financials User Guide.
Some .NET UI installations do not display a scroll bar on this screen for the list of XML files
available for import. If a great many XML files are listed, you can change the Bank File Format
Import program to display in Terminal mode, by selecting the menu Properties and changing the
Open With value to Terminal. Close the program and start it again. When in Terminal mode, you
can use the keyboard to scroll through the list of available XML files.
3 Review the library import log for any errors or warnings.

A typical warning is that the function directory does not exist or that a particular user-defined
function will not compile. The log file is named library-import-<today's date>-
(nnnnnn).log. The value nnnnnn is incremented each time an import occurs during the day,
which prevents the overwriting of an existing log file. This log file can be found in the work
directory of Progress (appserver) on the server.
Note For outbound definitions, you should verify the Transmission Group Destination directory
and File Name Counter. This can be accessed through Transmission Group Maintenance
(35.13.13). A Transmission Group defines the destination of the bank file being exported and what
counter definition is used to generate the file name. The outbound destination directory is where
the bank drivers create the bank files, and where you retrieve the files before sending them to the
bank for processing.
Default Directory Settings

When loading a bank driver, the default settings for the various directories and number ranges will
be retrieved from the eCommerce Control setup as described in this chapter. If the control record
does not exist, the system uses the directories and number ranges specified in the
eCommerceDefaultSettings.xml and creates a eCommerce Control setup on-the-fly.
If both the eCommerce Control record and the XML file are not available, the system creates an
eCommerce Control record on-the-fly, and sets all directories set to the value ., which points to
the work directory for Progress (appserver) on the server.
The following is an example of the eCommerceDefaultSettings.xml file layout:
<?xml version="1.0" encoding="utf-8"?>
<eCommerceSettings>
<ControlFileSetting>
<Domain></Domain>
<ImportInputDirectory>/dr01//ec/in</ImportInputDirectory>
<ImportArchiveDirectory>/dr01//ec/arch</ImportArchiveDirectory>
<ImportErrorDirectory>/dr01//ec/err</ImportErrorDirectory>
<ExportInputDirectory>/dr01//ec/in</ExportInputDirectory>
<ExportArchiveDirectory>/dr01//ec/arch</ExportArchiveDirectory>
<ExportErrorDirectory>/dr01//ec/err</ExportErrorDirectory>
<FunctionDirectory>dr01//ec/func</FunctionDirectory>
<InboundExchangeCounter>eComNrm</InboundExchangeCounter>
<OutboundExchangeCounter>eComNrm</OutboundExchangeCounter>
<InboundApplicationCounter>eComNrm</InboundApplicationCounter>
<OutboundApplicationCounter>eComNrm</OutboundApplicationCounter>
<ErrorCounter>eComNrm</ErrorCounter>
</ControlFileSetting>
</eCommerceSettings>

Product Information Resources
QAD offers a number of online resources to help you get more information about using QAD
products.
QAD Forums (community.qad.com)
Ask questions and share information with other members of the user community, including
QAD experts.
QAD Knowledgebase (knowledgebase.qad.com)*
Search for answers, tips, or solutions related to any QAD product or topic.
QAD Document Library (www.qad.com/documentlibrary)
Get browser-based access to user guides, release notes, training guides, and so on; use
powerful search features to find the document you want, then read online, or download and
print PDF.
QAD Learning Center (learning.qad.com)*
Visit QADs one-stop destination for all courses and training materials.
*Log-in required

Index
Numerics 36.16.12 179

2.13.13 204 36.16.13 182
7.15.14 29 36.16.17 181
11.21.22.24 188 36.16.22 186
17.17 15 36.16.22.1 186
36.2.1 10 36.16.22.2 188
36.2.5 8 36.16.22.13 188
36.2.13 11 36.17.5 194
36.2.17 15 36.17.6 194
36.2.21.1 17 36.19.1 199
36.2.21.5 25 36.20.10.11 53
36.2.21.13 26 36.20.10.15 76
36.2.21.23 26 36.20.18 62
36.2.22 27 36.22.1 204
36.3.21.23.18 46 36.22.4 204
36.3.22 176 36.22.13 166
36.4.2 39 36.23.1 169, 204
36.4.3 40 36.23.2 204
36.4.4.1 43 36.24.1 138
36.4.6.1 47 36.24.13 204
36.4.8.5 51 36.24.8 131
36.4.8.13 58 36.25.90 205
36.4.8.18 63 36.4.4.7 44
36.4.13.1 67
36.4.13.2 67 A
36.4.13.3 67 All Domains display 45
36.4.13.4 67 application server 198
36.4.14 67 Application Usage Profile Report 176
36.4.17.1 71 applicationcontrol.p 207
36.4.17.5 71 applications, displaying registered 176
36.4.17.24 71 AppServer Service Maintenance 199
36.4.21 75 Archive File Reload 169
36.13.1 80 archive/delete
36.13.2 82 audit detail 204
36.13.4 84 GL transactions 204
36.14.1 88 NRM sequences 26
36.14.3 89 programs 168
36.14.13 89 records from database 168
36.14.16.25 105 ASCII data 167
36.15.1 157 Audit Detail Delete/Archive 169, 204
36.15.2 157
36.15.4 163 B
36.16.1 166 Balance daemon 93
36.16.5 169 bank driver installation
36.16.10 171, 174 default directory settings 289
36.16.10.3 176 Bank File Format Import 287
36.16.10.8 176 Batch ID Maintenance 88
36.16.10.13 177 batch processes 88
36.16.10.14 177 Batch Request Detail Maintenance 89
36.16.10.16 178 Batch Request Processor 89
36.16.11 177 batchdelete field 162
Booking Transaction Report 29 D

Browse Maintenance 58 Daemon Monitor 105
Browse URL Maintenance 53 daemons 91119
browses architecture 93
creating 48, 58 configure 98, 107
creating views for 62 log file 99
lookups 48 monitor 102
Budget daemon 93 monitor all 105
Bulk Data Load 131 start 100
Business Component View 46 stop 101
users for 93
C dashboards 75
calculat.p 48 data dictionary
Calendar Maintenance 8 changing 12
calendars, shop 8 generalized codes 12
change tracking Database Control 138
activating 28 Database File Size Inquiry 166
specifying fields to track 28 Database Sequence Initialization 181
Change Tracking Maintenance 27 database sequences 180184
CIM Data Load 157 Database Table Dump/Load 167, 181
CIM Data Load Process Monitor 163 databases
CIM Data Load Processor 157 dumping data 167
CIM interface 155164 loading data 167
creating input file 160 multiple languages 37
database sequences 183 size management 166
deleting records 162 daybooks 18
error handling 162 daylight savings time 187
input data format 158 default directory settings
invoking in batch 90 for bank driver installation 289
killing sessions of 163 delete/archive
multiple sessions 163 audit detail 169, 204
sample input 160 GL transactions 204
command line application control 207 NRM sequences 26
comments programs 168
multiple languages 39 restoring data 169
reporting master 194 deleting records through CIM 162
components design mode 242
customizing UI 150 Detailed License Violation Report 177
e-mail notification for 74 disk space
viewing 46 determining usage 166
concurrent session license 171 freeing 166
control programs Disk Space Inquiry 166, 204
database 138 Distribution Requirements Planning (DRP) 38
Label Control 71 document formats, creating 84
System Maintain 139 domain cross reference
System Settings 148 and bank driver installation 287
user settings 152 Down Time by Reason Report 15
Control Tables Report 194 draft, saved objects 153
Corrupt Logging 170 drill-down browses 48
Cross-Company daemon 94 associating with field 49
cross-reference, system 194 creating 48, 58
CT log drilling down on 50
viewing 147 wildcards with 50
Cube daemon 94 Drill-Down/Lookup Maintenance 48
customers, shop calendar 8 generalized codes 10, 12
customization dumping data 167
Process Incoming Bank Files 228
Customization Delete 255 E
customizing 242264 EC Number Range Maintenance 285
enabling component UI 150 eCommerce Control 286
field help 67 editor, segment 22
function keys 65 e-mail 7275
E-Mail Definition Maintenance 73
Enforce Licensed User Count field 172
Index 295
error messages 47 L
error messages, license violations 173 Label Control 71
event configuration 110 Label Detail Maintenance 71
Event daemon 109 Label Master Maintenance 71
event destination 109 Language Detail Maintenance 39
executing menu items 41 languages
Exit to Operating System 204 defining 39
detail setup 39
F implementing multiple 39
field help 66 limitations 37
adding to 67 multiple 37
book function 67 translating reports 40
printing 67 Unicode restrictions 38
Field Help Book Report 67 License Registration Menu 171, 174
Field Help Maintenance 67 License Violation Report 177
Field Help Report 67 Licensed Application Report 176
fields licenses
tracking changes 27 concurrent session 171
Form Code field 84 displaying recorded license data 176
function keys displaying registered applications 176
assigning menu items to 65 enforcing agreement 172
calling programs with 41 granting access to licensed applications 175
limitations 65 location 171
named user 171
G removing 175
general ledger (GL) daybooks, number range types 171
management 18 upgrading 175
generalized code groups 13 violation reports 177
APP 13 violation types 172
synchronizing 14 licensing
SYSTEM 13 overview 171
generalized codes recording high water mark 178
displaying list of 10, 48 links
example 11 Browse URL Maintenance 53
validation 11 external Web page 53, 54
Generalized Codes Group Maint 13 other programs 55
Generalized Codes Maintenance 11, 13 loading data 167
Generalized Codes Sec. Browse 14 loading time zones 188
Generalized Codes Validation Report 11, 12 location license 171
GL Op Transaction Control 194 logging, database integrity 170
GL Transaction Delete/Archive 204 Lookup Browse 49
GMT Offset field 187 lookup browses 48
GMT. See Greenwich Mean Time (GMT) associating with field 50
gpcode.v 12 creating 48, 58
Greenwich Mean Time (GMT) 188 for generalized codes 12
H M
help 66 manufacturing calendar. See shop calendar
printing 67 Master Comments Report 194
user 67 master production scheduling (MPS)
high water mark, licensing 178 work orders, shop calendars 8
History daemon 95 material requirements planning (MRP)
Holiday Maintenance 10 performance improvement 15
shop calendar 8
I menu assignments 42
Inbox for Workflow 151 Menu Items by Field Report 195
Menu Items by Message Report 196
J Menu Items by Table Report 196
join types for views 63 Menu Substitution Maintenance 44
Menu System Maintenance 43
K menus 41
killing CIM sessions 163 assigning execution files 43
changing 43
cross-reference reports 195
security 42 Program Summary Bill File Create 197

structure 42 Program/Text File Display 204
Message Maintenance 47 Programs by Field Report 196
messages Programs by Table Report 196
license violations 173 Progress
modifying 47 application server 198
Progress 47 document formats, creating with 84
translating 47 function key limitations 65
Messages by Menu Item Report 196 messages 47
mnemonic codes, changing 39 multiple languages 37
monitoring users 179 syntax for browses 62
Multiple Time Zone Load Utility 188 protermcap, function keys 66
Multiple Time Zone Menu 186
Multiple Time Zones Maintenance 186 Q
Multiple Time Zones Report 188 qaduiConfig.xml 69
N R
named user license 171 reason codes
Number Range Maintenance 17 for change tracking 28
number range management 18 Sales Order Maintenance 15, 29
number range management (NRM) 1527 sales quotes and 15
segment editors 22 shipment performance 15
segment types 17 shop floor control 15
sequence definition 20 Reason Codes Maintenance 15
number range sequences registration, product 174
for bank drivers 285 removing licenses 175
Numbering function 185 renewing licenses 175
numbers Replication daemon 96
control segments 17 Report daemon 112
segment types 17 Report Resource Designer 261
sequences 17 Report Setup Menu 75
Report Translation 40
O reporting licensing data 176
OID generator code 138 reports, violations of license agreement 177
operating system restoring archived files 169
e-mail 73 Role Create 13
multiple e-mail systems 73 Role Membership Maintain 42
Operating System Commands menu 204 Role Permissions Maintain 13, 42
Oracle database sequences 184 Run Program Where-Used Detail 197
P S
planned work orders 8 Sales Order Maintenance 125
planning, change tracking 27 sales quotes, reason lost 15
Printer Default Maintenance 84 sample data, time zones 189
Printer Setup Maintenance 82 Save as Draft
Printer Type Maintenance 80 draft objects 153
printers enabling 150
control codes 81 XML daemon 116
default 84 Scan daemon 96
max pages 83 configure 107
setup 82 Secured items not on menu 13
terminal 81 Secured items on menu 13
type definition 80 security, menu 42
Windows/Unix setup 84 segment editors 22
printing help 67 Sequence Delete/Archive 26
procedure help 66 Sequence Maintenance 182
Procedure Help Report 67 Sequence Number History Report 26
Process Incoming Bank Files Sequence Number Maintenance 25
customizable matching logic 228 sequences
Program Information Browse 45 database 180184
Program Information Maintenance 44 number range management (NRM) 16
Program Information Update 46 server time zone 138
Program Run Report 197 server.xml 148
Program Source File Report 196 Session Master Maintenance 76
Index 297
set debug level 145 Unposted GL Transaction Correction 194

settings, user 152 Unposted Transaction Inquiry 204
shipping, number range management 19 upgrading licenses 175
shop calendar 8 URN. See uniform resource name
setting up 9 User Access by Application Inquiry 176
system search order 9 User Count Audit Process Report 178
shop floor control, reason codes 15 user interface
Source File Where-Used Detail 197 .NET UI 33, 41
Source File Where-Used Summary 197 character 11, 33, 37, 38, 41
Statutory-Currency Utility 205 component functions 33
Summary License Violation Report 177 customization 212, 242
suppliers, shop calendar 8 delete 255
system codes 143 design mode 242
system constants user-defined fields 257
calendars 8 User Maintenance
change tracking 27 e-mail definition 73
generalized codes 10 language 39
holidays 8 User Menu 41, 65
number sequences 15 User Monitor Inquiry 179
reason codes 15 User Option Telnet Maintenance 67, 70
system cross-reference 194, 195 User Tool Maintenance 51
customizing 194 user-defined fields 257
rebuilding procedure 198 adding fields to QRF reports 261
updating 198 User-Defined Fields on Report Maintain 262
System Maintain 139 users
System Monitor 144 daemon 93
System Settings 148 deactivating access to applications 175
System Synchronize 142 function keys 65
granting access to licensed applications 175
T language 39
Tables/Fields by Menu Report 195 menu 41
Tables/Fields by Program Report 195 monitoring 179
telnet server settings for 152
connection settings, configuring 70 sys admin login 140
login sequence, configuring 68 telnet login 68
port number 68 utdbfx70.p 12
setting up 67
verifying on UNIX 71 V
terminal mode 45 validating user input 12
Time Out daemon 97 View CT log 147
time zones View Maintenance 62, 63
based on offset from GMT 187 View System Codes 143
creating 186 views 62
defining 187 violations of license agreement 172
deleting 188
loading sample data 188, 189 W
reloading 188 warning messages, license violations 173
server 138 wildcards, assigning browses 50
tracking daylight savings time 187 work center calendars 9
tracking changes 27 work day calendars 9
translation activities report 40 workflow
delete 153
U enabling 151
Unicode inbox 151
batch processing 90 setting up 153
restrictions 38
Unicode database, multiple languages 37 X
uniform resource locators (URLs), browse links 53 XML daemon 115
uniform resource name (URN) 43 Configure 116

SysAdmin AG v2015EE

Uploaded by

Copyright:

Available Formats

SysAdmin AG v2015EE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SysAdmin AG v2015EE

Uploaded by

Copyright:

Available Formats

QAD Enterprise Applications

Introduction to System Administration

Copyright 2015 by QAD Inc.

Chapter 1 Introduction to System Administration . . . . . . . . . . . . . . .1

Chapter 2 Domain Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Change Tracking Implementation Overview . . . . . . . . . . . . . . . . . . . . . 27

Chapter 3 System Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Using Text E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Chapter 4 Printers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Chapter 5 Batch Processing and Daemons . . . . . . . . . . . . . . . . . . .87

Business Component Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 6 System Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

Chapter 7 CIM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

Chapter 8 Database Management . . . . . . . . . . . . . . . . . . . . . . . . . .165

Chapter 9 Reports and Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . .193

Audit Detail Delete/Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Chapter 10 Customizing Business Logic . . . . . . . . . . . . . . . . . . . . .211

Chapter 11 Customizing Specific Business Components . . . . . . .227

Chapter 12 UI Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241

Design Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Chapter 13 Installing Electronic Bank File Formats . . . . . . . . . . . .283

Product Information Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291

System Administration Overview

Questions? Visit community.qad.com

Batch Processing and Daemons

Reports and Utilities

Questions? Visit community.qad.com

Customizing Component-Based Functions

Questions? Visit community.qad.com

Overview of Domain Constants

Maintaining Holiday and Shop Calendars

Questions? Visit community.qad.com

Using Generalized Codes

Questions? Visit community.qad.com

Adding Generalized Codes

Figure 2.3 illustrates Generalized Codes Maintenance (36.2.13).

Field Name. Specify a field name.

To set up a lookup to display generalized codes, use Drill-Down/Lookup Maintenance (36.4.8.1).

Questions? Visit community.qad.com

Generalized Codes Groups

Working with Generalized Codes Groups

Browsing Generalized Codes Group Security

Questions? Visit community.qad.com

Using Reason Codes

Managing Number Ranges

Questions? Visit community.qad.com

Table 2.2 describes the three segment types.

Sequence Number Generation

Internal and External Sequences

There are two types of sequence number: internal and external.

Sequence Life Cycle

General Ledger Daybooks

Questions? Visit community.qad.com

WIP Lot Trace

Sales Order Numbers

Questions? Visit community.qad.com

For shipper/invoices, specify dataset abs_id.poshipper.

Fixed Segment Editor

Integer Segment Editor

Date Segment Editor