MULTI-COMPANY AND EXTENDED MULTI COMPANY

Introduction

The Multi company module is able to handle the business requirements to be able to produce
independent, balanced books for financial entities from the same database.

The Multi Branch module allows independent financial entities to produce independent
balanced books while sharing the same financial data files. The Multi Branch module
simplifies multi branch processing where all branches share the same data, but where each
branch is required to produce a balanced set of books. It can be set up within an existing
single or multi company environment.

A combination of the Multi Company (MC) and Multi Branch (MB) modules can together
provide extended multi company functionality.

GLOBUS supports operation of multiple companies within one system. These can operate
independently or they can share CUSTOMER files and/or certain files that contain controlling
(“static”) financial information. Companies can also share operation of Nostro accounts. SMS
maintains security of access at company level.

Transactions can take place involving accounts in different companies and appropriate entries
will be made to inter-company accounts automatically.

You can produce CRF reports for combinations of companies with currencies converted as
required.

Definitions

A single company could be described as the related data items that allow the production of a
set of balanced books for a single financial entity.

There are three possible types of company in GLOBUS.

In a combined multi company and multi branch set there are three types of company.
 Master Company
o This is the first company set up in a GLOBUS installation (normally BNK)
and it owns a complete set of data tables. The Master company can also be a
Lead company. The master company will be present in all types of GLOBUS
environment.
 Lead Company
o This is identical to a normal multi company in that it can share files with other
companies and stores all financial level data in its own set of tables. A lead
company is defined on installation by indicating that the financial tables are to
be owned by the company being created.
 Branch Company
o A branch is defined as a standard GLOBUS Company, all data except for those
tables related to company level reports and COB list processing tables will be
shared with the designated lead company. A Branch Company is defined on
installation by indicating that the financial tables are to be owned by an
existing lead company. A branch can only be linked to a Lead Company. It is
 not possible to link a branch to another branch. A branch will always share its
local currency and batch holiday table with its lead company.

The Main Differences between Multi Company and Multi Branch

The major differences between Multi Company and Multi Branch are as follows: -
 In a Multi branch setup all financial level data is held in a single database table for all
branches in the group whereas in Multi Company financial data is held in a separate
table for each company. For example if there are 20 branches all with the same lead
company then there will be only 1 account table whereas if this were set up as 20
separate lead companies there would be 20 account tables.
 In Multi Branch Close of Business processing all branches linked to the same lead
company are processed in the same job, whereas in Multi Company a separate job is
run for each company. (The exception being company level reporting jobs)
 In Multi Branch financial level data from different companies can easily be combined
in the same enquiry. This is possible using multi company but is less efficient.
 In Multi Branch a customers accounts and contracts can be easily moved from one
branch to another, without the need to close and reopen them. It is also possible to
close and merge branches within the same branch structure.
 In Multi Branch customer accounts do not have to be identified by a branch code as in
Multi Company, so it is possible for all accounts in each group of branches to follow
the same structure.
 In a Multi Company setup independent COB processing can take place using the
Global Processing product, and different local currencies can be set up. Neither is
possible within a single multi branch group.

Sharing information between companies

The files are grouped according to purpose and some of these groups may be shared with
other companies. The options are taken when setting up a company record and cannot be
changed.

GLOBUS tables can be grouped into various types some of which can be shared between
Lead companies.
A description of the various table types follows: -
 INT Installation Level
o There will only be one copy of installation level tables in a GLOBUS database
so the actual table name does not include a company mnemonic. Examples of
INT level tables include COMPANY, USER, VERSION and ENQUIRY
 CUS Customer level
o The CUSTOMER and related tables, often including the customer number in
the key. Examples include CUSTOMER.DEFAULT and LIMIT. This type of
table can be shared between lead companies.
 CST Customer tables
o Parameter tables related to customer examples include INDUSTRY and
SECTOR, together with parameter tables for limits, collateral and position
management. This type of table can be shared between lead companies.

Ref: 530680148.doc Nov 2001 Release G12

2
  FIN Financial
o There will always be one copy of a financial table per Lead Company. All
branches linked to a Lead Company will share the same financial table.
Examples include ACCOUNT, FUNDS.TRANSFER and TELLER
 FRP Financial reporting
o There will be one copy of a financial table for every company in the system,
examples include the COB job list tables and REPGEN work files like
RGP.TRANS.JOURNAL2
 FTD Financial table definitions
o Financial parameter tables that do not contain data with amounts or rates
linked to a particular local currency. Examples include the GEN.CONDITION
type tables and BASIC.INTEREST. This type of table can be shared between
lead companies.
 FTF Financial tables data
o Financial parameter tables that contain financial data, often containing local
currency amounts. Examples include GROUP.DEBIT.INT,
GENERAL.CHARGE and TAX. This type of table can be shared between lead
companies.
 CCY Currency tables
o Tables containing currency related information examples include CURRENCY
and PERIODIC.INTEREST. This type of table can be shared between lead
companies.
 NOS Nostro tables
o Tables related to NOSTRO accounts. Examples include AGENCY and
NOSTRO.ACCOUNT. This type of table can be shared between lead
companies.

NB: possibly expand this paragraph with some examples / suggestions on sharing table types.
For the parameter table levels there is a default company. For Customer Tables and for
Financial Tables there is the opportunity for file(s) to be linked to a different Company from
the default. Depending on local conditions these parameter tables may be held at Lead
company level or shared between groups of Lead companies.

COMPANY.GROUP

COMPANY.GROUP codes are used to identify the various operating companies, using the
GLOBUS system. The COMPANY.GROUP code is part of the 'GLOBUS Company' key and
as such will help in identifying a particular operating company ofe 'GLOBUS Companies' that
have been set up for it. This will help in reports etc. being grouped/combined.

Thus for each of the GLOBUS COMPANY records for the same operating company, the
COMPANY.GROUP must be the same. Therefore the same COMPANY.GROUP codes will
need to be created at each of the locations where the organisation is operating the GLOBUS
system.

The format of the Company Code is:

CC GGG LLLL

Where:

Ref: 530680148.doc Nov 2001 Release G12

3
 CC Is the Country Code
GGG Is the Company Group Code
LLLL Is Local Code

Note:
Local code must be different for each location/ branch within one country even if the
processing is run in different environments.

The COMPANY.GROUP code thus forms the centre portion of the individual COMPANY
records.

Figure 2 – Company Group Input Record

Inter Company Accounting and P&L

Both Multi Company and Multi Branch inter company accounting use the same mechanism
where the books are balanced by passing entries through internal inter company accounts.
The user must be signed in to the relevant company or branch to input a transaction. However
in Multi Branch a user can be automatically switched from one branch to another before
entering a transaction. This is controlled at Version level.
For example to post en entry from an account in company A to company B the following
entries are generated.
Company A
Debit account A Credit A to B inter company account
Company B
Debit B from A inter company account Credit account B
In EMC the subdivision code of the owning company is appended to the key of internal
accounts. This is an automatic process with no conversion of existing internal accounts
required.
A future development may be to pass inter company accounting entries via a defined single
company. This will increase the number of entries for a inter company transfer from 4 to six
with 2 additional entries in the designated company but will considerably reduce the number

Ref: 530680148.doc Nov 2001 Release G12

4
of inter company accounts required where there are large numbers of companies in the
system.
As in current multi company functionality all P&L will be booked in the company where the
transaction takes place.

Internal Account formats

The standard format of a GLOBUS internal account is as follows.

CCYCATEGNNNN where: -
 CCY a 3 alphabetic character currency code
 CATEG is a 5 numeric character category code
 NNNN is a four numeric character identifier which will be a subdivision code in the
case of inter company accounts

In a Multi Branch set up because all internal accounts for all branches are stored on the same
table there is an additional 4 numeric character subdivision code of the company that owns the
account. If passing an entry from company A to company B the inter company account in
company A has the following format: -
 CCY Currency code
 CATEGEG Inter company category code
 SUBDIV B Sub division code of the company being posted to
 SUBDIV A Subdivision code of the company being posted from

When installing a multi branch system the conversion of the existing internal accounts will be
automatic. When an entry is passed to an internal account a new internal account will be
opened, the old account will be set for closure and will be set to auto pay into the new
account.

Multi-company Parameters

The INTERCO.PARAMETER file contains the details of whether a multi-company

accounting environment is being used and if so the details of the identifying part of the
customer account number for each company. There is only one record ( SYSTEM) on this file. If
the record is missing then GLOBUS assumes that a single company accounting environment
exists. In a multi branch system the branches will always follow the rules set for their lead
company.

If you require inter-company accounting then you must input and authorise this record before
creating the second company. Before this record is authorised for an inter-company
accounting environment the record INTERCO must be present on the ACCOUNT.CLASS file.

Ref: 530680148.doc Nov 2001 Release G12

5
 Figure 3 – Intercompany Parameter Record

There must be portion of the account number from which the Lead Company can be
determined. This is called the branch code and can be used to identify the branch. Each value
that it can take must be assigned to a company as postings to accounts can only be made by
transactions of the company to which the account belongs (except for inter-company postings
for which special rules apply). If an account has a branch code which is not assigned to a
company then no postings can be made to it. If the account is in the Master Company or one
of its branches then it is not necessary to have a branch code in the account number. Normally
Master Company accounts are of a different length to those in other Lead Companies.

Combined Company Reporting Parameters

The COMPANY.CONSOL file holds the descriptions and the details of grouping of companies
for combined CRF reports.

The group number is part of the data entered at report production stage. Each record is
independent of the others and there is no hierarchical relationship between them.

The default currency for any report produced can be specified. Special currency exchange
rates can be used or the standard rates from the currency file(s) can be used.

When producing a combined report the local currency amount or the local currency equivalent
amount is converted into the reporting currency. The original currency figures are not used.
Therefore it is necessary to enter some default conditions on these records. These default
conditions are -

a) The currency file to be used, when the rates are to be taken from one file.
b) Where there are two or more currency files for the same local currency which

Ref: 530680148.doc Nov 2001 Release G12

6
 company's currency file is to be used.

Figure 4 – Company Consol Record

Special Currency Rates for Combined Reporting

The RE.RPT.CCY.RATE file holds the details of the exchange rates to be used when producing
combined reports.

The key to the records on this file is the reporting currency followed by a sequence number
allowing more than one set of rates to be loaded per reporting currency. This allows for the
case where head office reporting requires a different rate from the current market rates. When
converting to the reporting currency, the local currency amount field is the one converted, not
the foreign currency (original currency) field. This means that only rates between the
reporting currency and the local currency for each company need to be loaded.

Where two or more companies share the same local currency, then the exchange rate between
the local currency and reporting currency will be shared by all the companies with the same
local currency. It is not possible to load different rates per company.

Ref: 530680148.doc Nov 2001 Release G12

7
 Figure 5 – Reporting Currency Rates Record

Combined Company Report Requests

RE.CONSOL.REQUEST is used to produce CRF reports for combinations of companies.

The file holds details of the requests for different reports.

These requests can be run as part of the end of day processing in the batch process called
EB.CONSOL.PRINT or on-line using the V verification function for this application.

Details that are included in a request are the CRF report, the level of the report, the currency
of the report, the consolidation group and where and which exchange rates are to be used. It is
the local currency amounts, from the CRF base, that are converted into the reporting currency.
The original currency amounts are ignored for combined reporting.

For each local currency one rate is determined and is used for all the companies with that
local currency irrespective of whether there are different set of exchange rates for each
company.

The Exchange rates can be taken from the following places -

a) from a record on the RE.RPT.CCY.RATE file. This option is referred to as the SPECIAL
rates.
b) from the CURRENCY file for each local currency. If more than one currency is used as a
local currency then the one to be used is specified on the COMPANY.CONSOL record. This
option is referred to as the COMPANY level rates.
c) from one of the CURRENCY files. This file will have been specified on the
COMPANY.CONSOL record. These rates are considered to be the DEFAULT rates.

If a particular rate is missing from the level requested it is obtained using the next level down
or by using the master company's CURRENCY file and calculating cross rates where
required.

Ref: 530680148.doc Nov 2001 Release G12

8
Additional Features

CRF reporting

In a Multi Branch environment the CRF key will include the company code as the last
possible element of the key, e.g.

AC.1.TR.GBP.1001.2800.32.GB.........GB0010101
AC.1.TR.GBP.1001.2800.32.GB.........GB0010201
The above example from CONSOLIDATE.ASST.LIAB shows the same type of customer
current accounts in 2 different branches.

PL.53001.20000..10.........GB0010101
PL.53001.20000..10.........GB0010201
PL.53001.20000..10.........GB0010202
The above example from CONSOLIDATE.PRFT.LOSS shows interest accruals in three
different branches.
The CRF reporting data files where necessary include the company code in the key.
The CRF reporting is restricted to reporting at the company (branch) level unless the standard
method of consolidating company reports is used, i.e. via RE.CONSOL.REQUEST.

SMS

All SMS checks take place at the company level. In a multi branch environment the company
code of the record being process will indicate the company for which SMS checks take place.
The following conditions apply on the USER application: -
 COMPANY.CODE indicates the companies the user can sign in to.
 OTHER.BOOK.ACCESS, OTHER.BOOK.BLOCK these mutually exclusive fields
indicate the companies the user can access for inter company accounting. The
COMPANY.SMS.GROUP table can be set up to store groups of companies and the
key can be entered in the above fields. This allows new branches to be added / deleted
without having to modify individual user records.

Enquiries and Versions

In an extended multi company environment data display can be controlled as follows: -

 Restricted to an individual company (either a Lead Company or Branch)
 Restricted to all the branches linked to a particular Lead Company
 To include all companies and branches
The SMS conditions applying to individual companies will be applied so a branch user is not
automatically given access to all branches linked to a Lead Company.
A system wide default for enquiry selections across companies can be set in the
INTERCO.PARAMETER application. The default will be to restrict enquiries to the currently
logged in company. This can be changed at individual enquiry level as described above.

It is possible to determine at version level whether a user can automatically switch to another
branch linked to the same Lead Company when working in an application without having to
exit the application and log in to the other company. An example would be for a teller to close
online a customer’s account in another branch.

Ref: 530680148.doc Nov 2001 Release G12

9
It is also possible to control at VERSION level whether an application can actually be run
depending on the type of business day (see branches working on holidays).

Position Management

Position management data is stored as follows: -

 Contract Level in PM.TRAN.ACTIVITY
 At lead company level in PM.DLY.POSN.CLASS
o The key to this table is based on the following
 Position class
 Currency Market
 Dealer desk
 Position type (fixed at TR)
 Currency
 Value date
 User id
A PM enquiry will normally display information consolidated at lead company level, however
it is possible to combine information from several lead companies in the same enquiry if
configured to do so.
There is currently no standard functionality to enable a PM enquiry to display data
consolidated at the branch level, nor is it possible to drill down to data consolidated at branch
level.
Drill down to contract level data will move to the correct branch.

Close of Business (COB)

COB processing in extended multi company works as follows: -

 Application level jobs will run at lead company level, i.e. all branches linked to a
particular lead company will be processed together.
 The core batch control routine will determine the correct company to load relevant to
the record being processed.
 Reporting jobs are run separately for each company including branches.
 Global processing option is restricted to Lead Companies, i.e. all branches in the same
group are processed together but different groups of branches can be processed
separately.

Branches working on Holidays

In a multi branch system it is possible that not all branches will follow the working practices
of the Lead Company, for example the head office may not work at weekends whereas the
branches do.
It is possible to define 3 different holiday tables on the COMPANY application: -
 OFFICIAL.HOLIDAY
o The business holiday table for the local country
 BRANCH.HOLIDAY
o The business holiday table for this company
 BATCH.HOLIDAY
o The holiday table that controls which days the COB processing occurs.

Ref: 530680148.doc Nov 2001 Release G12

10
For example it is possible to set the system up to run COB processing 365 days per year, with
some branches open on weekends for restricted business activities.
If a branch is open on an official holiday then it is possible to restrict at VERSION level what
applications can be run.

Global Processing

Global Processing allows the COB processing in a Multi Company environment to be run
independently at Lead company or Lead Company group level. If the Lead Companies in a
GLOBUS data base are located in a variety of time zones then the COB processing can take
place at a convenient time for the relevant group, with the other groups in the system online.
The global processing module also provides the following functionality: -
 Full transaction management in the end of day process
 A resilient fault tolerant end of day process (the system cannot stop due to an error
with a contract)
 Use of online backups rather than traditional backup
 Global processing functionality is restricted to lead companies, i.e. all branches linked
to a Lead Company are processed together
 Ability to post accounting entries to companies that are offline from a company that is
online

Setting up a Multi-Company environment

This section outlines the steps to be taken in setting up a multi-company environment from
the start. The same steps can be followed when converting a single company to a multi-
company environment.

The description has been divided into two main sections - one covering the actions to be taken
outside GLOBUS the other covering the actions to be taken within GLOBUS.

Deciding which structure to set up

With both the MC and MB modules installed it is possible to set up a system that combines all
type of company.

 Classic Multi Company

o A set of Lead Companies which can share various data table types
 Simple Multi Branch
o A set of Branches linked to the Master Company sharing the master companies
table with the exception of financial reporting (FRP) tables
 Combined
o A set of Lead Companies, which can share various data table types where each
Lead Company may also have a set of Branch Companies liked to it if
required.

A multi branch structure should be set up if many of the companies (or branches) share the
same local currency and customer file, and there is no requirement for separate COB
processing (Global processing) for different groups of companies. This will provide a much

Ref: 530680148.doc Nov 2001 Release G12

11
more efficient system than if the same structure were set up using multi company and also
provides additional functionality.

A multi company structure set up is required if for example there is more than 1 local
currency, or if it is required to have more than 1 customer file.

Combined structures may be necessary for various reasons.

If a bank operates over a large geographical area with different time zones then it may be
necessary to install one lead company for each time zone (or group of time zones) so that
separate COB processing can take place for each group of branches, even though all branches
may be part of the same financial group and the Lead Companies would share the same
customer and currency files.

Another example of a combined set up would be where a bank operates in different countries
with different local currencies. Each country could be set up with a separate lead company
each with its own branch structure. It would be possible for each Lead Company to share the
same Customer table but have a separate Currency table.

Actions outside GLOBUS

The following must be agreed before setting up or changing to a multi-company environment:

i) Which digits of the account number are to be used for identify the company to which
the account belongs.
ii) The Category code for Inter Company accounts.
iii) The transaction codes for the Inter Company Transactions.
iv) How the Company group number and sequence number in the Company key are to be
used.
v) How the Company digits in the Account Number are to be allocated for each company.
vi) How the Sub-division code for identifying each company is to be allocated.

Action to be taken within GLOBUS

i) Add to the applications for the existing company the application code MC and MB if
branch processing is required.
ii) Run the application CREATE.MASTER.COMP.BATCH. This will reverse out all
the Batch records and create new batch records for the existing company with the
company mnemonic at the front. Note- For the batch process DATE.CHANGE the
record will not be changed to have the mnemonic at the front. This is because this
Process must be run only once and will cater for all companies in the system at the
time.
iii) Input and authorise the record INTERCO on the ACCOUNT.CLASS file. This record
contains the category code for the Inter Company Accounts.
iv) Ensure you are the only person on the system.

Ref: 530680148.doc Nov 2001 Release G12

12
 v) Input and authorise the record SYSTEM on the INTERCO.PARAMETER file.
vi) Create a record in the REVALUATION.PARAMETER file with parameters set up
for the following: ‘AL’ – Asset and Liability revaluation, ‘FX’ – Forex, ‘FX.SP’ –
Forex spot revaluation, and ‘FX.RB’ – Forex rebate revaluation
vii) Sign off from the system before proceeding further.

Setting up A New Company

This outlines the steps to be taken in setting up a new company.

The description has been divided into three main sections: -

 The first one covers the actions to be taken outside GLOBUS.

 The second section covers the steps in creating the new company record within GLOBUS.

 The third section covers the steps to be taken within GLOBUS after creating the Company
record.

Actions Outside of GLOBUS

The following information about the new company must be obtain before creating the
company record:

i) The Company Number and Mnemonic.

ii) The local currency.
iii) The financial year-end.
iv) The sub-division number.
v) The level of the files to be shared or not shared.
vi) The applications to be run under the company.
vii) The applications requiring the Auto Id function.
viii) The name and address of the company.
ix) From other company records the type of rate and tolerance data to be loaded.
x) From other company records the account number check-digit type and format.

Creation of the Company Record

i) Ensure you are the only user on the system.

ii) If necessary create new record on the COMPANY.GROUP file if the company
number contains a new group number.
iii) Check BATCH.NEW.COMPANY to see if the records IBLC.TODAY and
SYSTEM.END.OF.DAY4 are present. These are now obsolete and should be reversed.

Ref: 530680148.doc Nov 2001 Release G12

13
 Run application COMPANY.CREATE.
This runs the creation of a Company record using a special run through the Company
application with zero authorisers.
This routine will -
a) create all the required files.
b) set up the Batch records on the Unauthorised file.
c) copy to the Unauthorised file in IHLD condition the records requested on the
FILE.SETUP.DETAIL file.

Company Create application

NB: insert a screenshot of a COMPANY.CREATE record possibly 1 for a Lead Company

and 1 for a Branch.

COMPANY.CREATE is a type “W” application.

The workflow is as follows:-
 Populate the COMPANY.CREATE record
 Using the verify (“V”) function control will be passed to the COMPANY application
in installation mode where the new company record will be updated, new files and
data records will be populated and the new company record will be written.

The COMPANY.CREATE application replaces COMPANY.INS. The objective is to make

the creation of a new company simpler using the following methods: -
 Reduce the amount of data to input into the new company record
 Default as much data as possible into the new company record from an existing
company record
 Automate the creation of authorised records for the new company as much as possible.

There are basically two types of company in GLOBUS: -

 Lead Company This type of company owns a full set of financial level data and is
exactly the same as a company in a multi company environment. The master company
(usually BNK) can be defined as a lead company with some additional features not
relevant to this application. The various non-financial file types, i.e. not FIN can be
shared with other companies, usually the master company exactly as in a standard
multi company environment. A full set of data files will be created for the new
company and any data records will be created unauthorised.
 Branch Company. This type of company is linked to a Lead company and shares all
file types with it. A branch company can produce an independent set of financial
books. The only new files created for a new branch are the Financial reporting type
(FRP). This type of file is generally related to REPGEN work files. All data records
created for the new branch will be automatically authorised.

If the company to be created shares the following file type with an existing Lead Company
and is in the same Geographical time zone then it is more efficient to create a Branch:-
 INT - Installation
 CUS - Customer
 CST - Customer table

Ref: 530680148.doc Nov 2001 Release G12

14
  FIN - Financial
 FTD - Financial Table Descriptive
 FTF - Financial Table Financial
 CCY - Currency
 NOS - Nostro

When creating a new company the minimum amount of information required is input in this
application, i.e. name, address, mnemonic, and sub division code. The FINANCIAL.COM
will determine whether a Lead or a Branch company is being created. If the
FINANCIAL.COM is not the same as the @ID of the company being created then a branch
will be created, otherwise a new Lead company will be created.
The DEFAULT.COM is used to identify the company record that will provide the data to
default values into the new company record being created. When creating a new branch all
field apart from those input into this application will be taken from the lead company. When
creating a new lead company the default company can be used to reduce the amount of data
that is input into the new company record. For example if the new lead company being set up
will have similar applications and have a similar file type structure as an existing company
then the new record will be populated with data from the default and then when control is
passed to the COMPANY application the relevant fields can be modified, rather than having
to fill in all fields.

After Creation of the Company Record

When creating a new branch the relevant data records will be created in the authorised state, so
the amount of work required is restricted to setting up the users for the new branch.
The following steps are to be performed before letting other users back onto the system:

i) Modify USER records so that access to the new company is allowed.

ii) Input and Authorise the DATES record for the new company. On this record the
RUN.DATE and NEXT.WORKING.DAY must be the same as on the first company
created.
iii) Create an ABBREVIATION for changing to New Company.
iv) Update the COMPANY fields on INTERCO.PARAMETER SYSTEM record if a new
Lead Company has been created.
v) The above is done before signing onto the New Company. It will be necessary to sign
off and on again to obtain use of the modified details to the USER and
INTERCO.PARAMETER file records.
vi) Create a record in the REVALUATION.PARAMETER file with parameters set up
for the following: ‘AL’ – Asset and Liability revaluation, ‘FX’ – Forex, ‘FX.SP’ –
Forex spot revaluation, and ‘FX.RB’ – Forex rebate revaluation
vii) Input and Authorise Data on the following files (this list assumes shared Customer
and Nostro Files) if files have been created for New Lead Company. - For these files,
data will have been written to the unauthorised file.
File Name Classification and Notes
CURRENCY CCY - Only set for New Local Currency.

Ref: 530680148.doc Nov 2001 Release G12

15
 TRANSACTION FTF - Only set for New Local Currency.
TAX FTF
FT.CHARGE.TYPE FTF
FT.COMMISSION.TYPE FTF
FT.TXN.TYPE.CONDITION FTF
FT.GROUP.CONDITION
ACCOUNT.ACCRUAL INT - One record with key of Company Code.
GENERAL.CHARGE FTF
FX.TEXT
LMM.CHARGE.CONDITION
LMM.INSTALL.CONDS FIN - One record
LMM.TEXT
viii) Input and Authorise Data on the following files (this list assumes shared Customer
and Nostro Files) if files have been created for a New Lead Company. - For these
files, data must be entered
File Name Classification and Notes
PERIODIC.INTEREST CCY - Only when New Local Currency
FORWARD.RATES CCY - Only when New Local Currency
GROUP.CAPITALISATION
GROUP.DEBIT.INT
GROUP.CREDIT.INT
Other Interest and Charges tables.
ACCOUNT Default accounts in the Local currency for the
suspense accounts, etc.
DE.ADDRESS Create record for new company.
DE.PRODUCT Create record for new company.
MG.PARAMETER Create new record for new company.
HOLIDAY Set up this for the currency in
PERIODIC.INTEREST
PERIODIC.INTEREST Set up PERIODIC.INTEREST for the
currency/rate in FRA.PARAMETER
FRA.PARAMETER Create new record for new company.
LC.PARAMETERS Set up internal accounts, then a system record for
this parameter.
MD.PARAMETER Input and authorise this held record.
SC.PARAMETER Input and authorise this held record.
SC.STD.SEC.TRADE Input and authorise this held record.

Ref: 530680148.doc Nov 2001 Release G12

16
 PD.AMOUNT.TYPE Set up various types then set up the
PD.PARAMETER file below.
PD.PARAMETER Create new record for new company
CONDITION.PRIORITY Set up an ' Account ' record in this file.
RE.BASE.CCY.PARAM Set up the base currency record.
SC.STD.COUPON Create new company record ensuring fields 24-26
are populated.
SC.STD.BOND.RED Create new company record ensuring fields 24-26
are populated.
FD.PARAMETER Create new record for new company.
ix) Input and authorise the records on the BATCH file that have been created above.
x) Run AUTO.ID.START for appropriate applications.
xi) Run INSTALL.SYS.RECS for new company.
xii) Check printed output to ensure that there are no missing records.

Ref: 530680148.doc Nov 2001 Release G12

17