Banking Back-Office
Processing
Guide to Setting Up
the Retail System
Copyright 2002, Unisys Corporation.
All rights reserved
Unisys is a trademark of Unisys Corporation
Release 9.000
October 2003
Printed in the UK
NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT.
Any product and related material disclosed herein are only furnished pursuant and subject to the terms and conditions of a duly executed Program Product License or Agreement to purchase or lease equipment. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such License or Agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, indirect, special or
consequential damages.
You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used.
The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions.
Correspondence regarding this publication should be forwarded to Unisys UK, Bakers Court, Bakers Road, Uxbridge, Middlesex, UB8 1RG, United Kingdom.
3937 0879-930
iii
Purpose
This guide describes the screens used to set up the Unisys Banking Back-Office Processing
product. This covers activity that follows the installation process, described in the Primary
Release Letter.
Scope
This guide describes how to implement the system, including the procedures for setting up access
security and the operational tables. Guidelines are also provided on how to set up blueprint
parameters.
Audience
This document is for all personnel who are involved in implementing and maintaining the system.
Prerequisites
Any person using this guide should have read the Product Overview and be familiar with the user
documentation. Users of this guide should have read the Starters Guide to Retail that provides
instruction in the use of the screens.
How to Use This Guide
Use this guide in conjunction with the Release Letter, particularly when dealing with the
following aspects:
•
Blueprint Parameters
About Urbis
The usage of the product name Urbis is due to be phased out as part of the Unisys re-branding
exercise. The replacement will be the generic term "Banking Back-Office Processing" solution or
"Banking Back-Office" for short. To provide continuity with existing product documentation, the
name Urbis is used within this document, but is synonymous with Banking Back-Office
Processing.
Organisation
This guide consists of the following sections and appendices:
Section 1. Access Security
This section gives an overview of security. This is followed by descriptions of the screens used to
set up security.
Section 2. Country and Currency
This section describes the screens used to set up the data associated with countries and their
currencies.
Section 3. Accounting Centre and Dates Maintenance
This section describes the screens used to set up the data associated with accounting centres and
the dates used to drive the system.
Section 4. Blueprint Parameters
This section contains a brief description of the process for setting blueprint parameters including
the screen that is used.
Section 5. Operational Data
This section describes the screens used to maintain the operational data containing details of the
system.
Section 6. Definition of Field Names
This section provides definitions of all the field names on the screens in this guide. The fields are
listed alphabetically.
3937 0879-930
v
Appendix A. Retail Blueprint Parameters
This section contains lists of the parameters that apply across the Urbis system, and describes
each of them.
Appendix B. Frequency Codes
This appendix lists the frequency codes used by the system. The frequency codes define when
and on which days certain events take place, for example, interest settlement. These codes cannot
be changed.
Appendix C. Deleting Business and Operational Tables
This appendix describes the affects of deleting key information, entered using the business and
operational tables, once installation is complete.
Appendix D. Euro Related Information
This appendix describes the main changes brought about by Economic and Monetary Union, and
the preparation necessary when converting to the euro.
Appendix E. Narrative Types and Retention Times
This appendix contains information on the General Purpose Narrative (GNARR) table types. It
also contains information on the retention times for the deletion of old data, including default
values for all retention times.
Related Product Information
Product Overview (3937 0234)
This document describes the capabilities and benefits of the system. It consists of an overview
and description of each of the modules and interfaces available. It is intended for use by senior
management.
Retail Operations Reference Card (3937 0929)
This document is a single card that provides a list of screen names and their mnemonics. The list
is organised according to the menu structure of the Graphical User Interface. The card also
describes how to log on and off, enter data, make inquiries and print reports. These instructions
are relevant to the Graphical User Interface only.
Starter’s Guide to Retail (3937 0903)
This guide describes how to enter data and make online inquiries. It includes a description and
example of commonly used data entry and inquiry screens. It also describes how to add a client
and use a workflow with examples. This guide is intended for all new and inexperienced
personnel who need to enter data and make inquiries.
Core Retail Functions and Inquiries Guide (3937 0887)
This guide describes the kernel functions that are used regularly for the maintenance of
information utilised by a number of Urbis modules. It describes the procedures for setting up and
maintaining data, such as exchange rates. It also describes the vault management facilities. It
should be used by all users.
Retail Lending Administration Guide (3937 0390)
This guide is only relevant to the retail loans module. It describes how to set up and maintain
retail loan product templates. It also details the screens needed to enter an application for a loan
and administer any loan granted as a result of an application. The screens used to record details of
collateral used to back a loan are described also. An appendix gives the calculations used by retail
loans. This guide should be used by personnel involved in loan administration.
Retail Clients and Accounts Administration Guide (3937 0895)
This guide describes the data entry and inquiry screens associated with setting up and maintaining
client details. This guide also describes the set up and maintenance of client accounts, client
account templates and automatic payments, such as standing orders. An appendix covers the
calculations used by client accounts. This should be used by personnel preparing information for
data entry.
3937 0879-930
vii
Arrears Management Administration Guide (3937 0978)
This guide describes the data entry screens associated with the Arrears Management functionality.
This allows the user to recognise when an account is in arrears, create an arrears case, and
manage the arrears case.
General Ledger Administration Guide (3937 0457)
This guide describes the data entry screens associated with General Ledger transactions. This
should be used by personnel preparing information for data entry.
Financial Transactions Reference Guide (3937 0408)
This guide is only relevant to the retail payments module. It describes the screens used to capture
data from a retail delivery system. Also covered are the back office batch entry screens and how
to set up accounting centre accounts and suspense accounts. This guide should be used by
personnel who need to identify the data items that are captured by financial transactions and for
those preparing information for data entry.
Core On-Demand Reports Guide (3937 0853)
This guide describes how to run online reports that are relevant to retail and wholesale banking
functions. Any options available when producing a report are detailed as well as any specific
calculations.
Retail On-Demand Reports Guide (3937 0846)
This guide describes retail on-demand reports in alphabetical order. Any options available when
producing a report are detailed as well as any specific calculations.
Overnight Reports Guide (3937 0861)
This guide describes how to run offline reports. This includes an overview of overnight
processing. Instructions on how to initiate reports are given. This guide should be used by all
personnel who need to understand the reports and the overnight process.
Data Dictionary (3937 0226)
This document provides details of data fields within every dataset on the database. This document
should be used by staff preparing the accounting models and writing SQL reports to inquire on
the database.
3937 0879-930
ix
About This Guide
...
iii
Section 1 Access Security
Access Security
Screen Flow
...
1–1
Access Security
Prerequisites
...
1–2
User Codes and Passwords ...
1–2
Access Groups ...
1–3
Setting up Printers and Stations
...
1–4
Terminal Printer Address (PRNTR) ...
1–4
Stations Maintenance (STNS) ...
1–5
Setting up Access Groups
...
1–6
Access Groups Maintenance (ACGRP) ...
1–7
Access Group Authorisation (ACCES) ...
1–8
Setting up Users
...
1–9
User Details ...
1–10
Users Maintenance (USERS) ...
1–11
Users Maintenance and Authorisation (USERM) ...
1–12
User Authorisation Queue (USERA) ...
1–13
Password Maintenance (PWORD) ...
1–15
Access Security Inquiries
...
1–16
Audit Inquiries
...
1–17
Audit Inquiry by Screen (AUDSQ) ...
1–18
Audit Inquiry by User (AUDUQ) ...
1–20
Audit Details Inquiry (AUDIQ) ...
1–22
Error Message Audit Inquiry (AUEMQ) ...
1–24
Access Security Reports
...
1–26
Section 2 Country and Currency
Introduction to Country and Currency
...
2–1
Country and Currency Screen Flow
...
2–2
Country and Currency Prerequisites
...
2–3
Country and Currency Screens
...
2–3
Countries (CNTRY) ...
2–4
Country Diary (CYDR) ...
2–6
Country Standard Holidays (CTRYH) ...
2–7
Country Group Maintenance (CNTGR) ...
2–9
Postal Areas by Country (CTPA) ...
2–10
Postal Area Maintenance (CTPAM) ...
2–11
Postal Group Maintenance (PSTGR) ...
2–12
Currencies (CCYS) ...
2–13
Country and Currency Reports
...
2–16
Section 3 Accounting Centre and Dates Maintenance
Introduction to Accounting Centres and Dates
Maintenance
...
3–1
System Structure ...
3–2
System Parameters ...
3–3
Accounting Centre and Dates Screen Flow
...
3–4
Accounting Centre and Dates Prerequisites
...
3–5
Accounting Centre and Dates Screens
...
3–5
System Dates (DATES) ...
3–6
Location Maintenance (LOCTM) ...
3–8
Accounting Centres Maintenance (ACNTM) ...
3–10
Profit Period Dates (PPDAT) ...
3–12
Cross Accounting Centre Rules (ACRLM) ...
3–13
System Parameters (SPMTR) ...
3–15
Indirect Costs Maintenance (PCICM) ...
3–17
Accounting Centre and Dates Maintenance Inquiries
...
3–18
Accounting Centre and Dates Maintenance Reports
...
3–18
Section 4
Blueprint Parameters
Introduction
...
4–1
Changing Blueprint Parameters
...
4–2
3937 0879-930
xi
Section 5 Operational Data
Introduction to Operational Data
...
5–1
Operational Data Screen Flow
...
5–2
Operational Data Prerequisites
...
5–4
Operational Data Screens
...
5–4
Narrative Types (TNARR) ...
5–5
General Purpose Narratives (GNARR) ...
5–6
Retention Table Maintenance (RETTM) ...
5–8
Retention Table Inquiry (RETTI) ...
5–10
Screens Maintenance (SCRNS) ...
5–11
Setting Up Operations (OPERS) ...
5–13
Reports Maintenance (REPS) ...
5–15
Report Options Details (RPOPM) ...
5–17
Report Recipients (REPRC) ...
5–18
Report Distribution (COPYA) ...
5–19
Report Distribution Maintenance (COPYM) ...
5–20
Error Messages (EMSGM) ...
5–21
Process Definition (CATDM) ...
5–22
Report Headers Maintenance (RHEAD) ...
5–23
Report Text Maintenance (RTEXT) ...
5–24
Screen Text Maintenance (STEXT) ...
5–25
Operational Data Inquiries
...
5–26
Operational Data Reports
...
5–26
Section 6
Definition of Field Names
Introduction
...
6–1
Appendix A Retail Blueprint Parameters
Blueprints for Processing Control
...
A–1
Processing Blueprints - Access Security ...
A–1
Processing Blueprints - Client and Client
Accounts ...
A–3
Processing Blueprints - Dates ...
A–5
Processing Blueprints - Financial Transactions ...
A–6
Processing Blueprints - Retail Loans ...
A–8
Processing Blueprints - Report Controls ...
A–9
Blueprints for Record Retention
...
A–11
Blueprints for Nationalisation
...
A–13
Nationalisation Blueprint Parameters - General ...
A–13
Nationalisation Blueprint Parameters - Client and
Accounts ...
A–15
Nationalisation Blueprint Parameters - Financial
Transactions ...
A–26
Nationalisation Blueprint Parameters - Retail
Loans ...
A–27
Nationalisation Blueprint Parameters - Rates ...
A–30
Nationalisation Blueprint Parameters - Urbis Text
Appendix B Frequency Codes
Introduction
...
B–1
Frequency Codes Table ...
B–1
Appendix C Deleting Business and Operational Tables
Introduction
...
C–1
Appendix D Euro Related Information
Introduction
...
D–1
Preparations for Conversion Weekend
...
D–3
Conversion Weekend ...
D–3
Introduction of Notes and Coins ...
D–3
Withdrawal of National Notes and Coins ...
D–4
Subsequent Waves on EMU ...
D–4
Testing the Conversion Weekend Procedures
...
D–5
Contingency Planning
...
D–5
Data Preparation
...
D–6
Setting Up Europe as a Country ...
D–6
Setting Up the Euro as a Currency ...
D–6
Update System Parameters ...
D–7
Setting up an Exchange Rate Group ...
D–7
Setting Up New Base Rates ...
D–7
Appendix E Narrative Types and Retention Times
Narrative Types
...
E–1
Retention Dates
...
E–6
3937 0879-930
xiii
1–1 Flow of Access Security Screens ...
1–1
1–2
Terminal Printer Addresses screen ...
1–4
1–3
Stations Maintenance screen ...
1–5
1–4
Access Groups Maintenance screen ...
1–7
1–5
Access Group Authorisation screen ...
1–8
1–6
Users Maintenance screen ...
1–11
1–7
Users Maintenance and Authorisation screen ...
1–12
1–8
Users Authorisation Queue screen ...
1–14
1–9
Password Maintenance screen ...
1–15
1–10 Audit Inquiry by Screen screen ...
1–19
1–11 Audit Inquiry by User screen ...
1–21
1–12 Audit Details Inquiry screen ...
1–23
1–13 Error Message Audit Inquiry screen ...
1–25
2–1 Screen Flow for Countries and Currencies ...
2–2
2–2
Countries screen ...
2–5
2–3
Country Diary screen ...
2–6
2–4
Country Standard Holidays screen ...
2–8
2–5
Country Group Maintenance screen ...
2–9
2–6
Postal Areas by Country screen ...
2–10
2–7
Postal Area Maintenance screen ...
2–11
2–8
Postal Group Maintenance screen ...
2–12
3–1 Structure of Urbis ...
3–2
3–2 Screen Flow for Accounting Centre and Dates ...
3–4
3–3
System Dates screen ...
3–7
3–4 Location Maintenance Screen ...
3–9
3–5
Accounting Centres Maintenance screen ...
3–11
3–6
Profit Period Dates screen ...
3–12
3–7
Cross Accounting Centre Rules screen ...
3–14
3–8 System Parameters screen ...
3–16
3–9
Indirect Costs Maintenance screen ...
3–17
4–1
Blueprint Maintenance screen ...
4–2
5–1 Screen Flow for Operational Data (Part 1) ...
5–2
5–2 Screen Flow for Operational Data (Part 2) ...
5–3
5–3
Narrative Types screen ...
5–5
5–4
General Purpose Narratives screen ...
5–7
5–5
Retention Table Maintenance screen ...
5–9
5–6
Retention Table Inquiry screen ...
5–10
5–7
Screens Maintenance screen ...
5–12
5–8
Setting Up Operations screen ...
5–14
5–9
Reports Maintenance screen ...
5–16
5–10 Report Option Details screen ...
5–17
5–11 Report Recipients screen ...
5–18
5–12 Report Distribution screen ...
5–19
5–13 Report Distribution Maintenance screen ...
5–20
5–14 Error Messages Table screen ...
5–21
5–15 Process Definition screen ...
5–22
5–16 Report Headers Maintenance screen ...
5–23
5–17 Report Text Maintenance screen ...
5–24
5–18 Screen Text Maintenance screen ...
5–25
D–1 Phases of Conversion to the EMU ...
D–2
3937 0879-930
xv
1–1
The Access Matrix ...
1–6
6–1
Definition of Field Names ...
6–1
A–1 Blueprint Parameters Used for Access Security Processing ...
A–1
A–2 Blueprint Parameters Used for Clients and Accounts Processing ...
A–3
A–3 Blueprint Parameters Used for Dates Processing ...
A–4
A–4 Blueprint Parameters Used for Financial Transaction Processing ...
A–5
A–5 Blueprint Parameters Used for Retail Loan Processing ...
A–7
A–6 Blueprint Parameters Used for Report Control Processing ...
A–8
A–7 Blueprint Parameters Used for Sleeping Report Control Processing ...
A–9
A–8 Urbis Retention Dates ...
A–10
A–9 Blueprint Parameters Used for General Nationalisation ...
A–12
A–10 Blueprint Parameters Used for Client and Accounts Nationalisation ...
A–14
A–11 Blueprint Parameters Used for Financial Transactions
Nationalisation ...
A–25
A–12 Blueprint Parameters Used for Retail Loans Nationalisation ...
A–26
A–13 Blueprint Parameters Used for Rates Nationalisation ...
A–29
A–14 Blueprint Parameters Used for Urbis Text Based Nationalisation ...
A–29
B–1
Frequency Codes ...
B–1
C–1
Deleting Business and Operational Tables ...
C–1
D–1
Phases of Conversion to the Euro ...
D–6
E–1 Retention Dates ...
E–6
3937 0879-930
1–1
Access Security
Access Security
Screen Flow
The data entry screens used to set up and maintain access security are illustrated below:
Define the printers in the network Terminal Printer Address (PRNTR)Define the user of terminals (stations) in the network Stations (STNS) Define access groups and operations allowed to members of each access group Access Group Parameters (ACGRP) Access Groups (ACCES) Define attributes for users of the
system (see "Setting Up Users") for more
information Users (USERS) Users Maintenance/ Authorisation (USERM) Dealers and Officers (DEALR)
Update the user
passwords Passwords
(PWORD)
Figure 1-1. Flow of Access Security Screens
Note
: Usage of access security screens shown in the above diagram should be restricted so that
changes may only be performed by authorised users.
Access Security
Prerequisites
There are no prerequisites to setting up printers or stations.
To set up access groups, operations and reports are supplied as standard. For systems that are
customized, they must be set up, see the Setting Up Operations (OPERS) screen and the Reports
Maintenance (REPS) screen.
To set up usercodes, accounting centres must be set up. Accounting centres are set up on the
Accounting Centres Maintenance (ACNTM) screen.
User Codes and Passwords
To use the system, each user must enter a User Code and password to log on to the system.
Passwords should be regarded as highly confidential. They should be recorded in documents that
are housed in a secure location and should be known only to supervisory staff and the user
concerned. Usercodes and passwords are held on the Users (USERS) table. Specific rules for
password expiry can be defined using the Users (USERS) screen. For example, these rules allow
temporary users of the system to be set up by entering a password expiry date and preventing
password update on expiry.
General rules regarding password maintenance can be controlled using the following blueprint
parameters:
•
BP-PWRD-DAYS: The number of days for which a password is valid before the user must
update it
•
BP-PWRD-REMIND: The number of days prior to password expiry that the user will be
prompted to update it
•
BP-PWRD-MAX: The maximum number of characters allowed in a password
•
BP-PWRD-MIN: The minimum number of characters allowed in a password
•
BP-PWRD-MAXA: The maximum number of alphabetic characters that are allowed in a
password
•
BP-PWRD-MINA: The minimum number of alphabetic characters that are allowed in a
password
•
BP-PWRD-MAXN: The maximum number of numeric characters that are allowed in a
password
•
BP-PWRD-MINN: The minimum number of numeric characters that are allowed in a
password
•
BP-PWRD-CONCR: Indicates whether groups of three characters (such as abc) can be
repeated in a password
•
BP-PWRD-USRCON: Indicates whether the first three characters of the usercode can be
used in a password
•
BP-PWRD-READS: The amount of the user's previous passwords that will be stored so that
they cannot be used again
•
BP-PWRD-DEF: The password that must be used for a new user if you want the user to be
prompted to enter a new password when they first attempt to logon to Urbis
3937 0879-930
1–3
Note
: If BP-PWRD-MAXA, BP-PWRD-MINA, BP-PWRD-MAXN and BP-PWRD-MINN are all
set to zero, then the number of alphabetic and numeric characters that make up the password is
not controlled.
User access can also be restricted to specific terminals through the use of “station passwords”.
The user must enter this password to log on to the system at the station. A record must be set up
on the Stations (STNS) table to enable a terminal to access the system.
Access Groups
Every user is assigned to an access group. Each access group defines a set of operations (or
screens) and reports that users in the group can access (see “Setting up Access Groups” later in
this section).
A single access group code can be assigned to any number of users. Consequently, it is only
necessary to define the scope of a particular access group once. When you add new users
requiring the same access capabilities, they can be entered as members of an existing access
group.
Setting up Printers and Stations
Terminal Printer Address (PRNTR)
Each terminal used by the system can be linked to a printer for printing of, for example,
confirmations and payments. The name (address) of each printer must be entered before the
facility can be used.
The Terminal Printer Address (PRNTR) screen is used to add, delete or inquire on the names of
the printers.
To delete a printer, leave the “Starting Terminal Printer Address” field blank, select the "Delete"
field next to the 'Terminal Printer Address' you want to delete and click Delete
The following figure shows an example of the Terminal Printer Address screen.
3937 0879-930
1–5
Stations Maintenance (STNS)
You must make an entry on the Stations table for each station (terminal) on which the system is
used. Details of stations are entered and maintained on the Stations Maintenance (STNS) screen.
For each station, the following items are defined on this table:
•
The station name
•
The name of an associated printer
•
The names of the default printers used for confirmations and payments
•
The station status
•
The address
•
The station password
When users log on, they must enter the station password. It is, therefore, important that you keep
a record of the station password for each station. Stations can also be enabled and disabled using
this screen.
Note
: The printer names must have been set up on the Terminal Printer Address (PRNTR) screen.
The following figure shows an example of the Stations Maintenance screen.
Setting up Access Groups
It is important that you prepare details of the access security you want before you enter them into
the system. The following procedures give one method of doing this:
1. Draw up a matrix for each department. List members of staff who will be using the system
along the top of the matrix and list the operations and reports on the left hand side (see
Table 1-1).
2. Place a cross against the operations and reports each member of staff can access (see
Table 1-1).
Table 1–1. The Access Matrix
Operation or Report A. Smith B. Brown C. Jones D. Evans
Add Client X X X X
Change Client X X
Add Client Account X Client Balance Report X X Create Product Template X
3. Compare the access requirements of each user and group those with the same requirements.
These groups form the access groups you require for the department.
The example in Table 1-1 suggests three access groups, one for A Smith, one for B Brown,
and one for C. Jones and D. Evans.
4. Assign a usercode and password to each user.
5. Assign a station password to each terminal to be used to access the system.
6. Enter
the
information.
Note
: Before you begin entry of access groups you must ensure that all reports and all the
operations (for example Add, Change) for each screen are defined. See Section 5 "Operational
Data" for full details.
Before inquiring on a report or operation number, you must identify the correct operation on the
Setting Up Operations (OPERS) screen.
There are two screens that you must complete to set up an access group:
•
Access Groups Maintenance (ACGRP)
3937 0879-930
1–7
Access Groups Maintenance (ACGRP)
Each user is assigned to an access group. The access group defines the operations and reports that
members of the group can use.
The Access Groups Maintenance (ACGRP) screen is used to select the access group that you
want to create or change. Enter the access group name, indicate whether the group is for
“Operations” or “Reports” and enter the operation or report number from which you want the
display to start. Click either the Add, Change, or Inquire button. The Access Group
Authorisation (ACCES) screen is displayed.
To delete an access group, you must first delete all users still associated with that access group.
The following figure shows an example of the Access Groups Maintenance screen.
Access Group Authorisation (ACCES)
The Access Group Authorisation screen is used to define the operations or reports that users
linked to a particular access group can use. You link users to a group on the Users Maintenance
(USERS) screen. This screen can only be accessed from the Access Groups Maintenance
(ACGRP) screen.
Each report and operation is assigned a number, during installation. All valid operations or
reports are listed on the Access Group Authorisation screen (ACCES) in numerical order. Against
each one is an authorisation indicator.
To authorise a report or operation for a user group switch 'On' the “New Authorised” field
adjacent to the report or operation and click the OK button. To stop a user group from using a
report or operation, switch 'Off' the "New Authorised Field" adjacent to the report or operation
and click the Ok button.
The following figure shows an example of the Access Group Authorisation screen.
3937 0879-930
1–9
Setting up Users
There are two separate methods in Urbis that can be used to set-up and maintain user information.
Only one of these methods can be in use at any given time. The following two methods are
available:
•
User Entry and Maintenance Without Authorisation. A user can add, change, or delete user
details; the changes made are applied straight away, and do not have to be authorised. All
changes are made on the Users Maintenance (USERS) screen.
•
User Entry and Maintenance With Authorisation. A user can add, change, or delete user
details; the changes made are not applied until authorised. All changes are made on the Users
Maintenance and Authorisation (USERM) screen. When the information is transmitted from
this screen, the change is sent to the users authorisation queue, where a user can authorise the
changes. The users authorisation queue can be seen on the User Authorisation Queue
(USERA) screen.
The following blueprints control user authorisation:
•
Blueprint BP-ATH-REQ-USERM – if set to Y, makes the authorisation queue mandatory.
The user cannot be used in the system unless authorised and cleared from the queue.
•
Blueprint BP-SAME-USER-ATH – if set to Y, enables the same user who
entered/changed/deleted the user details to authorise the same. If set to N, another staff
member who has been given authorisation permission in the system must authorise the client
details.
User Details
For each person who is to use the system, a single user must be entered which assigns a user
name and the core information that defines a user. This includes the following:
•
The usercode and password. To make the user change the password at initial logon, the
password must be left blank
•
The accounting centre to which the user belongs
•
The number of minutes after which the user is logged off if the terminal is not used
•
The access group to which the user belongs
•
The maximum value of retail loans that the user is able to authorise
•
The maximum amount of an overdraft that the user is able to authorise
•
Whether the user is able to enter retail financial transactions and if so the level of authority
they have to override errors that would prevent entry of financial transactions
•
The language in which screen formats and error messages are to be displayed to the user -
currently only English is available to users of the Graphical User Interface
•
Whether the user can reinstate deleted records. Users with the reinstatement facility can
inquire on, and make changes to, a deleted record. The following message is displayed
'INQUIRY REQUESTED - KEY DELETED'. This indicates that the record has been deleted.
Changing a deleted record results in its reinstatement. Users without the reinstatement facility
can inquire on, but not change, deleted records.
The following list shows the deleted records that can be reinstated:
Accounting Centres Maintenance (ACNTM)
Narrative Types (TNARR)
Dealers and Officers (DEALR)
Users (USERS)
Cost per Transaction Maintenance (TCDCM)
Operations (OPERS)
Currencies (CCYS)
Report Recipients (REPRC)
Client Types Maintenance (CICTM)
Reports (REPS)
Countries (CNTRY)
Stations (STNS)
General Ledger Master (GLMAM)
•
For a temporary user of the system, set a password expiry date and do not permit password
update on expiry
3937 0879-930
1–11
Users Maintenance (USERS)
This screen allows you to enter details on a user, and maintain those details. This screen is only
used for user details if the blueprint parameter BP-ATH-REQ-USERM is set to 'N'. For more
information on this blueprint parameter, and when this screen is used, see 'Setting Up and
Maintaining Users', earlier in this section.
For more information on the information that must be entered for a user, see 'User Details' earlier
in this section.
The following figure shows an example of the Users Maintenance screen.
Users Maintenance and Authorisation (USERM)
This screen allows you to enter details on a user, and maintain those details. This screen is only
used for user details if the blueprint parameter BP-ATH-REQ-USERM is set to 'Y'. For more
information on this blueprint parameter, and when this screen is used, see 'Setting Up and
Maintaining Users', earlier in this section.
When user details are entered or changed on this screen, then the database is not updated with the
changes until the change has been authorised. The changes to be authorised can be viewed on the
User Authorisation Queue (USERA) screen. When a change to be authorised is chosen from the
authorisation queue, then the user is returned to this screen to view and authorise the change. To
authorise the change, click the Authorise button. This button can only be clicked after linking to
this screen from the authorisation queue.
For more information on the information that must be entered for a user, see 'User Details' earlier
in this section.
The following figure shows an example of the Users Maintenance and Authorisation screen.
3937 0879-930
1–13
User Authorisation Queue (USERA)
This screen is allows you to authorise additions or changes to the information held on users of the
system. This screen is only used if the blueprint parameter BP-ATH-REQ-USERM is set to 'Y'.
For more information on this blueprint parameter, and when this screen is used, see 'Setting Up
and Maintaining Users', earlier in this section.
This screen provides a list of all the changes that have been made to user details. It is possible to
limit the list by entering the User Code of a specific user, and by using the 'Authorisation Status'
field to view just changes already authorised, or changes awaiting authorisation.
To Authorise a Change
To authorise a change to user information, select the change you want to authorise and click the
Authorise button. The system will link to the Users Maintenance and Authorisation (USERM)
screen to view the change and authorise the change.
To Authorise the Deletion of a User
To authorise the deletion of a user, select the deletion request to authorise and click the
Authorise Delete button. The user will be deleted from the system.
To Stop the Deletion of a User
If a user has been incorrectly deleted, then stop the deletion process and reinstate the user details
by selecting the deletion request and clicking the Remove Delete button.
The following figure shows an example of the Users Authorisation Queue screen.
3937 0879-930
1–15
Password Maintenance (PWORD)
User's passwords can be updated using the Password Maintenance (PWORD) screen under the
security menu. For security reasons the new password is not displayed when it is entered; it is
therefore necessary to enter the password twice to ensure that typing errors are not accepted by
the system. The Usercode and User’s Name are defaulted from the Users Maintenance (USERS)
screen.
The following figure shows an example of the Password Maintenance screen.
Access Security Inquiries
The following security screens have inquiry facilities, but there are no separate inquiry screens:
•
Stations Maintenance (STNS)
•
Access Groups Maintenance (ACGRP)
•
Access Groups Authorisation (ACCES)
•
Users Maintenance (USERS)
3937 0879-930
1–17
Audit Inquiries
The audit features contained in Urbis allow you to record details of how Urbis is being used.
Every time a screen is used, Urbis will record what was done on the screen and by which user.
The audit record also shows the machine time and date, not the on-line time and date. These
records can then be accessed and displayed on various audit inquiry screens. The audit inquiry
screens are shown below:
•
Audit Inquiry by Screen (AUDSQ)
•
Audit Inquiry by User (AUDUQ)
•
Audit Details Inquiry (AUDIQ)
•
Error Message Audit Inquiry (AUEMQ)
Auditing in Urbis is controlled by the blueprint parameter BP-AUDIT-REQD, described in
Appendix A, Retail Blueprint Parameters. This determines whether auditing takes place in your
system. It can be set to:
•
Yes (Y) - Allow all the auditing facilities to work in your system. This is the default value.
•
No (N) - Do not allow any of the auditing facilities to work in your system
Audit Inquiry by Screen (AUDSQ)
Use this screen to display audit records for a screen. Inquiring on a particular screen will recall all
the records of the usage of that screen. To inquire enter the date and time you want to start your
inquiry from in the Next Date and Next Time fields. Alternatively, you can enter the audit
number you want to search from using the Next Number field.
The following information is displayed for each screen:
•
Error: An asterix will be shown in this field if the particular record of usage relates to an
error. You can then link to the Error Message Audit Inquiry (AUEMQ) screen to see what the
error was.
•
Date and Time: This is the date and time the screen was called.
•
Audit Number: The number given to the record.
•
User and Username: The user who called the screen, and their username
•
Function: A record of the action performed on the screen. This is a three letter mnemonic,
for example INQ shows that an inquiry was performed on the screen.
•
Audit Type: This field contains either Send (S) or Receive (R). Send is when an audited
record involves sending information to Urbis. Receive is where information is being received
from Urbis.
If no information is displayed for a screen, then it has not been used since the audit records were
last deleted.
If you want further details on any particular usage record, these can be obtained by linking to one
of the other screens containing audit information. To do this highlight the particular screen record
you are interested in. Then click the Details or Error Message button. These take you to the
Audit Details Inquiry (AUDIQ) screen or the Error Message Audit Inquiry (AUEMQ) screen
respectively.
3937 0879-930
1–19
The following figure shows an example of the Audit Inquiry by Screen screen
Audit Inquiry by User (AUDUQ)
Use this screen to display the audit records for a user. Inquiring on a particular user will recall the
screens accessed by that user, and what was done on them. To inquire enter the date and time you
want to start your inquiry in the Next Date and Next Time fields. Alternatively, if you know the
number of the audit number you want to search from, use the Audit Number field.
The following information is displayed for each user:
•
Error: An asterix will be shown in this field if the particular usage record relates to an error.
You can then link to the Error Message Audit Inquiry (AUEMQ) screen to see what the error
was.
•
Date and Time: This is the date and time the screen was called.
•
Audit Number: The number given to the record.
•
Screen and Screen Title: The screen and screen title accessed.
•
Function: A record of the action performed on the screen. This is a three letter mnemonic,
for example INQ shows that an inquiry was performed on the screen.
•
Audit Type: This field contains either Send (S) or Receive (R). Send is when an audit
number involves sending information to Urbis. Receive is where information is being
received from Urbis.
If no information is displayed for a screen, then it has not been used since the audit records were
last deleted.
If you want further details on any particular record, link to one of the other screens containing
audit information. To do this highlight the particular screen record you are interested in. Then
click the Details or Error Message button. These take you to the Audit Details Inquiry (AUDIQ)
screen or the Error Message Audit Inquiry (AUEMQ) screen respectively.
3937 0879-930
1–21
The following figure is an example of the Audit Inquiry by User (AUDUQ) screen.
Audit Details Inquiry (AUDIQ)
This screen can only be accessed by linking from either the Audit Inquiry by User (AUDUQ)
screen or the Audit Inquiry by Screen (AUDSQ) screen, and is used to view individual audit
records in greater detail. Use this screen to view what data was entered on the screen during any
particular usage.
The following information is displayed on this screen:
•
User - The user who was logged on when the audit record was produced.
•
Screen - The screen the audit record was produced on.
•
Date and Time - The time and date that the audit record was produced.
•
Audit Number - The number of the audit record, the Audit type is displayed adjacent to this
field.
•
Function - The maintenance action performed by the user. This is a three letter mnemonic,
for example INQ shows that an inquiry was performed on the screen.
The screen shows the audit records stored under each audit number. The following information is
displayed:
•
Line - This specifies which line of a multi-row information table (for example on the General
Narrative Inquiry (GNARI) screen), was used during the audit record.
•
Field - This lists all the fields on the screen.
•
Value - This shows the values of all the fields after the user had exited the screen. Fields with
no information entered in them will have no entry in the Value field.
From this screen you can link to other audit screens:
•
Click the Error Message button to link to the Error Message Audit Inquiry (AUEMQ)
screen
•
Click the Screen button to link to the Audit Inquiry by Screen (AUDSQ) screen
•
Click the User button to link to the Audit Inquiry by User (AUDUQ) screen.
3937 0879-930
1–23
The following figure shows an example of the Audit Details Inquiry (AUDIQ) screen.
Error Message Audit Inquiry (AUEMQ)
This screen can only be accessed by linking from either the Audit Inquiry by User (AUDUQ)
screen, the Audit Inquiry by Screen (AUDSQ), or the Audit Details Inquiry (AUDIQ) screen. Use
this screen to view the details of any audit record that contains an error message.
The following information is displayed on this screen:
•
User - The user who was logged on when the error was produced.
•
Screen - The screen the error was produced on.
•
Date and Time - The time and date that the error was produced.
•
Audit Number - The number of the audit record.
The table shows the error messages stored under each audit number. The following information is
contained on the table:
•
Copy Line - This specifies which line of a multi-row information table (for example on the
General Narrative Inquiry (GNARI) screen), was used during the audit record.
•
Error Number and Message - The error number and description of the error. Error Messages
are set up on the Error Messages (EMSGM) screen, found in Section 5 - Operational Data, in
this guide.
From this screen you can link to other audit screens:
•
Click the Detail button to link to the Audit Details Inquiry (AUDIQ) screen
•
Click the Screen button to link to the Audit Inquiry by Screen (AUDSQ) screen
•
Click the User button to link to the Audit Inquiry by User (AUDUQ) screen.
3937 0879-930
1–25
The following figure is an example of the Error Message Audit Inquiry (AUEMQ) screen.
Access Security Reports
The following reports provide information related to access security:
•
REPSLST - Reports Listing
•
AUDITPURG - Purge Audit Records
•
AUDLOG - Audit Report
•
SCRNSLST - Screens Details
3937 0879-930
2–1
Country and Currency
Introduction to Country and Currency
Before attempting to set up country and currency information, you must be familiar with 'How to
Enter and Change Data' as described in the
Starters Guide to Retail.
Country and Currency Screen Flow
The data entry screens used to enter and manage country and currency data are illustrated below:
Set up countriesCountries (CNTRY)
Set up holidays for
country Country Diary (CYDR) Country Standard Holidays (CTRYH) Group countries by geographic or political areas Country Group Maintenance (CNTGR) Set up an maintain
postal areas for countries Postal Areas by Country (CTPA) Postal Area Maintenance (CTPAM)
Group countries and
postally Postal Group Maintenance (PSTGR)
Set up currencies and
limits Currencies (CCYS)
3937 0879-930
2–3
Country and Currency Prerequisites
The following list shows the mandatory items and the screens that are used to create them.
•
Area symbol, group symbol, postal group, postal region - General Purpose Narratives
(GNARR) table types AS, GS, PG, PR respectively, see Section 5.
Country and Currency Screens
The following screens are described in this section:
•
Countries (CNTRY)
•
Country Diary (CYDR)
•
Standard Default Holidays (CTRYH)
•
Country Group Maintenance (CNTGR)
•
Postal Areas by Country (CTPA)
•
Postal Area Maintenance (CTPAM)
•
Postal Group Maintenance (PSTGR)
Countries (CNTRY)
Details of countries with which your bank deals, and of the countries of residence for clients, are
held on the Countries table (CNTRY). On this table you define the following for each country:
•
The code and name of the country
•
The weekend days for the country (up to three)
When you add a country, the system creates a country diary with weekends set up 2 years ahead
and 2 years back. These values for forward weekends and back weekends are set as the blueprint
parameters BP-HOL-MONTHSFWD and BP-HOLS-MONTHSBACK, described in Appendix A,
Retail Blueprint Parameters. Once a country record has been created, the weekend days cannot be
amended.
Countries can be grouped into up to 15 geographic or political areas using the Country Group
Maintenance (CNTGR) screen.
Note:
Once installation is complete you cannot delete a country from the system.
From this screen you can link to the Country Standard Holidays (CTRYH) screen. To do this,
click the Holidays button.
3937 0879-930
2–5
The following figure shows an example of the Countries screen.
Country Diary (CYDR)
Details of the holiday dates that apply to each particular country are held in a country diary. On
this table you enter the following:
•
The country
•
The number of the year
•
The number of the month
•
The days of the month which are holidays
When you are adding a holiday date to the existing calendar, enter the holiday date in the first
"Holidays" field on the screen and click Add.
This may mean overwriting a value that is being displayed. However, overwriting an existing date
in this manner will not cause the date to be deleted. To delete a holiday date, enter that date in the
first "Holidays" field on the screen and click Delete.
Diaries and currencies are linked by way of the Country that is used on the Currencies (CCYS),
Country Standard Holidays (CTRYH), and the Country Diary (CYDR) screens.
The following figure shows an example of the Country Diary screen.
3937 0879-930
2–7
Country Standard Holidays (CTRYH)
Details of the holiday dates that occur annually and apply to a particular country are held in a
country diary. These holidays are entered and maintained on an annual basis in the Country Diary
(CYDR) screen.
This screen contains details of the standard holidays that apply to each country. On this screen
you can set standard holidays indefinitely or until a particular year end. For example, Christmas
Day in the United Kingdom is a holiday every year and can be added to the Country standard
holidays (CTRYH) screen. Enter the following on this screen:
•
The country
•
Details of each holiday
•
The date of the holiday
•
The name of the holiday
•
The final year for which the holiday applies
When you are adding a holiday to the existing calendar, enter the holiday date in the "Date" field
on the screen and click the Add button.
To delete a holiday date select the Delete checkbox adjacent to the date and click Delete.
Diaries and currencies are linked by way of the Country that is used on the Currencies (CCYS)
and the Country Diary (CYDR) screens.
The following figure shows an example of the Country Standard Holidays screen.
3937 0879-930
2–9
Country Group Maintenance (CNTGR)
This screen is used to group countries according to geographic or political areas. The area and
group codes are defined on the General Purpose Narratives (GNARR) table, types AS and GS.
To delete a country from a group switch on “Delete” next to relevant Country and click Delete.
The following figure shows an example of the Country Group Maintenance screen.
Postal Areas by Country (CTPA)
This screen is used to add postal areas to, and inquire on details associated with, a country record.
Note:
The Postal Area Maintenance (CTPAM) screen is used to change, delete or inquire on
postal areas that have already been defined on this screen.
The following figure shows an example of the Postal Areas by Country screen
3937 0879-930
2–11
Postal Area Maintenance (CTPAM)
This screen is used to maintain (change, delete or inquire on) the details of postal areas which are
associated with a country.
Postal areas are set up on the General Purpose Narratives (GNARR) screen, table type AS, and
must exist before they can be used on this screen.
Note:
The Postal Area Maintenance (CTPAM) screen is only used to change, delete or inquire on
postal areas that have been set up on the Postal Areas by Country (CTPA) screen
The following figure shows an example of the Postal Area Maintenance screen.
Postal Group Maintenance (PSTGR)
This screen is used to categorise countries and postal areas according to postal groups (for
example, geographic or economic) and regions within the groups. The postal group and region
codes are defined on the General Purpose Narratives (GNARR) table, table types PG and PR.
To delete a Country/Area from a group, select a line and click Delete.
The following figure shows an example of the Postal Group Maintenance screen.
3937 0879-930
2–13
Currencies (CCYS)
Details of the currencies in which your bank deals are held in the Currencies (CCYS) table. On
this table you define the following for each currency:
•
The mnemonic used for data entry and the full name of the currency
•
The country of the currency
•
The truncation factor determining how amounts will appear on summary reports
•
The number of decimal places for the currency
•
The type of rounding to be used for this currency. This will apply to all calculations for this
currency, and can either be rounding to the nearest amount, or rounding down. The type of
rounding suitable will depend on the currency. For example, for Japanese Yen, rounding
down is required. (Currency rounding does not apply to the Loans Administration module).
Note:
Once installation is complete you cannot delete a currency from the system.
You may also define a composite currency on this screen. To indicate a composite currency,
switch 'On' the “Group Currency” field.
You now enter the mnemonics of the currencies that form the components of the composite
currency, together with the percentage each currency contributes towards the composite currency.
Currencies forming part of the composite currency must first be defined themselves within the
system.
The EMU Phase field relates to those currencies participating in Economic and Monetary Union
(EMU). It shows what phase of conversion the currency has reached. The phase of conversion
that a currency has reached should be updated, even if you're institution is in a country not
participating in the EMU. There is more information on the EMU in Appendix D, Euro Related
Information.
The following figure shows an example of the Currencies screen.
Figure 2–9. Currencies screen
Currency Shift Factors
The currency shift factor functionality is designed to help entry of currencies with large exchange
rates compared to the base currency. Amount entry fields only allow entry of 14 figures and 3
decimal places. When a currency has an exchange rate thousands of times more than the system
base currency, then the largest enterable amount is restricted. The currency shift factor provides a
method of reducing the size of currencies with large exchange rates, by removing three
3937 0879-930
2–15
When activated the currency shift factor removes the last three figures from an amount, and shifts
the decimal point three places to the left. For example 1200300.400 would be stored as 1200.300.
This means a number a thousand time larger can be stored. As the number of figures in the
amount is reduced, information about the final three figures is lost, making it important to account
for this when entering amounts into the system. On inquiry screens and reports, amounts in
shifted currencies are displayed as unshifted amounts.
The shift factor also has an impact on exchange rate figures. With no shift factor set, the
maximum size of an exchange rate is 9999.99999999 and the minimum value is
-9999.99999999. The shift factor affects the exchange rate maximum and minimum values in the
following way:
Shift Factor Minimum Rate Maximum Rate
0 -9999.99999999 9999.99999999
Country and Currency Reports
The following reports are relevant to country and currency tables:
•
CCYSLST - Currencies Details
•
CNTRYLST - Countries List
•
CYDRYLST - Country Diary List
The above reports are documented in the
Core
On-Demand Reports Guide
.
3937 0879-930
3–1
Accounting Centre and Dates
Maintenance
Introduction to Accounting Centres and Dates
Maintenance
Before attempting to set up accounting centre or date information, you must be familiar with
'How to Enter and Change Data' as described in the
Starters Guide to Retail.
This section describes how to configure the Urbis system to represent the structure of your
institution. Also described is how to set basic parameters for the entire system, and for individual
branches.
System Structure
Urbis is structured according to a four tier hierarchy that can be used to represent a multi-branch
or multi-company environment. The following diagram shows the relationships between elements
in the structure. Each element represents a level within your organisation.
Figure 3-1. Structure of Urbis
The structure of an organisation forms one operating unit. The basic operating unit is the
accounting centre, comprising of a sector, sub-sector and profit centre. Each accounting centre is
connected to one location that can be any location. This means that sectors and sub-sectors can be
related to various locations, however each profit centre is only related to one location.
Most activities in Urbis are undertaken at accounting centre level, and even though this also
defines a location for the activity, the location is not seen. Every transaction is attributable to an
accounting centre. Every user belongs to an accounting centre and all their transactions
automatically contribute to it (this can be overridden at transaction level). In turn each accounting
centre and each user also belong to a location and all their transactions automatically contribute to
it.
Information on the activities in a system is drawn together to make reports and calculate total
balances across your institution. These calculations involve the consolidation of figures either
vertically through the system, via the accounting centre, or horizontally across the system via the
location.
Location 1
Profit Centre Profit Centre Profit Centre Profit Centre Profit Centre Profit CentreSector
Sector
Sub
-Sector
Sub
-Sector
Sub
-Sector
Key Accounting CentreLocation 2
3937 0879-930
3–3
An example of how these four definitions can interact to define an institution:
•
Sector - Could define the head office (for example, in France)
•
Sub Sector - Could define branches in different countries (for example, in China, Japan,
America and Germany)
•
Profit Centre - Could define dealers in the branches.
•
Location - Could define geographical regions for consolidation of information (for example,
Europe, Asia, North America). However, dealers from the China branch, working in Britain
could come under either the Europe or Asia location.
System Parameters
Once the structure of the Urbis system has been established, various system parameters can be set
up that cover all of or parts of that structure. For system parameters, there is a three level
hierarchy:
•
System level. This covers the entire system, any parameter set here will apply to all parts of
Urbis. Set on the System Parameters (SPMTR) screen.
•
Location Level. This covers all accounting centres linked to that location, and all parameters
applied to that location will apply to all these accounting centres. Set on the Location
Maintenance (LOCTM) screen.
•
Accounting Centre Level. This covers individual accounting centres, and all parameters
applied to an accounting centre only affect that accounting centre. Set on the Accounting
Centres Maintenance (ACNTM) screen.
While many of the parameters on these three screens only appear on one of the screens (and
therefore affect everything at that level and below), there are two that appear on more than one.
These parameters are: Currency and Exchange Rate Group.
Accounting Centre and Dates Screen Flow
Set up system datesSystem Dates (DATES) Set up locations Location Maintenance (LOCTM) Set up accounting
centres AccountingCentres
Maintenance (ACNTM)
Define irregular profit
periods Profit PeriodDates
(PPDAT) Define cross accounting centre rules Cross Accounting Centre Rules (ACRLM)
Update the basic
system parameters System Parameters
(SPMTR)
Set up indirect costs between accounting
centres
Indirect Costs Maintenance
(PCICM)
3937 0879-930
3–5
Accounting Centre and Dates Prerequisites
The following list shows mandatory items and the screens that are used to create them:
Exchange rate group, sector, sub sector, profit centre, - General Purpose Narratives (GNARR)
table types EX, SE, SS, PF, respectively, see Section 5).
•
Country - Countries (CNTRY), see Section 2
•
Currency - Currencies (CCYS), see Section 2
•
Printer - Terminal Printer Address (PRNTR), see Section 1
•
General Ledger Master - General Ledger Master (GLMAM), see the
General Ledger
Administration Guide
Accounting Centre and Dates Screens
The following screens are described in this section:
•
System Dates (DATES)
•
Location Maintenance (LOCTM)
•
Accounting Centres Maintenance (ACNTM)
•
Profit Period Dates (PPDAT)
•
Cross Accounting Centre Rules (ACRLM)
•
System Parameters (SPMTR)
System Dates (DATES)
When you first install the software and the static database, skeleton data is set up in the System
Dates table (DATES) and the System Parameters (SPMTR) table. You can add additional data,
such as the profit period dates, to the Dates table at any stage during this phase of installation, but
not thereafter.
After installation, when the installation complete indicator has been set, the System Dates table
cannot be changed. The dates are maintained automatically and you can only inquire on them.
Caution
Extreme care should be exercised when setting up or amending dates. This
will have a significant impact on the way in which the system reflects your
business.
If you manually set the “Current Profit Period Number” you must ensure that
this value is consistent with the “Period Number” on the Profit Period Dates
(PPDAT) screen.
Two entries are held on this table, one for on-line processing and one for off-line processing.
Only the change option is available with this screen.
3937 0879-930
3–7
The following figure shows an example of the System Dates screen.
Location Maintenance (LOCTM)
Use this screen to define location codes. The Location Code groups together accounting centres
into geographical regions, such as country, region or continent. Defining a default value for a
location will affect all the accounting centres associated with it. For example, setting the base
currency here will define this for all accounting centres attached to the location.
You must enter the following information on this screen:
•
Location: A mnemonic used to represent the location
•
Location Long Name: The name of the region
•
Base Currency: The currency you want to represent the location
•
Base Country: For a group of countries, this field will define the base country
•
Language: The primary language of the location
•
Exchange Rate Group: This is the exchange rate group used when reports are run at location
level (see
the Core On-Demand Reports Guide
for more information on running reports).
•
Location Address Details: Enter contact detai
