GP2.Global Processing-R13

Welcome to the “Global Processing Part II” learning unit.
In this learning unit you will

learn how to install and configure GP module in T24 multi company setup. You will
appreciate the need of GP when multiple companies in different geography running at
different time zones needs to run COB process individually.
GP2.Global Processing-R13 1
After completion of this learning unit, you will be able to,
•Create a new lead company

•Explain how to group companies
•Describe company holiday definition
•Describe COB execution in Multi-Company
The first and most important step in installing and configuring GP is to setup System
Parameter File (SPF). Multivalue field Product enter GP under Product Codes you
need to supply valid license code.
To operate in a GP mode and allow the use of independent Close of Business you
must set the GLOBAL.PROCESS flag in SPF to Y.
Independent Company COB Processes
The system will be modified so that in a Global Processing environment it will be possible to run
the COB process for each company independently without the need to take the system offline
for the remainder of the companies. The modifications required to achieve this have been
described above.
As a result it will be possible to have different groups, or individual companies running online
and different stages of the batch (on possibly different dates) and any given time.
In a Global Processing environment the batch will be initiated as follows:

The operator will launch the batch for all companies within the same company grouping by
running COB services from one of the companies within the grouping.
The batch processing for that group of companies will process all companies within the group
that are currently on the same processing date
To allow for the situation where a single company in a group is not ready to run COB, but to
prevent delay of the other companies COB, an additional flag, SEPARATE.EOD, is provided in
the COMPANY record. If set to Y the COB for the company must be run separately.
COB services will need to be initiated for each group of companies.
The batch process will cycle each company onto the next working day
No backup will be run at the start of the batch process – the system will write a check point to
the event journal???. The system will be unavailable for transaction input and authorisation in
any that is running its COB process.
On completion of the batch for a company a check point will be written to the event journal and
the operator will have the option to switch the batch online automatically or manually.
The system will manage the number of threads available to run COB processes across all
companies that are running their COB process. The number of threads available is defined in
the SPF record, field BATCH.SESSIONS.
The majority of system COB processes are run at the level of each company and
repeated for each company. This presents no problems to the proposed changes to
the COB workflow. However there are a number of processes that are run once for all
companies during the batch. These processes require review to establish the
following:
Does the process impact the processing of an individual company?
Is there a need for the process or part of the process to run as part of the COB for an
individual company?
Is there any dependency on when this process is run, e.g. must the process run before
any other or be the last to run?
The working day classification will provide an additional option to cater for companies
and branches with different holidays but to maintain the current practice of running a
single common COB process.
The system date and COB processes is now processed according to the
BATCH.HOLIDAY definition in the COMPANY application. To run a common COB all
companies will share a common holiday table, but transaction processing and date
calculations will refer to the BRANCH.HOLIDAY table which should be defined to
reflect the actual country (or region) of the company.
Using this facility will mean that a Batch Holiday table should be created to reflect
every possible working day in all the related companies. E.g. A Dutch and British
combined holiday table would be defined as Monday to Friday and only the common
holidays will be defined (i.e. Christmas Day, New Year’s Day).
A COB process will be run for each date defined as a working day in the Batch
Holiday. This will result in the system being online for a company that is actually on
holiday (as defined in the Branch Holiday). In this situation the system classifies the
day as being CLOSED, online transaction entry will be prevented for companies.
Processing in this mode will allow the traditional COB / start of day backups to be run
and may be simpler to administer a small number of companies. The system can be
amended to switch to the true Global Processing mode at any time.
Company 2 is CLOSED on Next Working Day this indicates GP must restrict COB
process for Company 2 while allowing COB process for rest of the companies.
Once user has access to the new lead company user will be able to login to the new
company US0030303
New record got created for a newly created lead company US0030303 in DATES
application.
BATCH application has batch processes created for new lead company called
US0030303
Notice the new company US0030303 is in group 3 which is defined in an application
COMPANY.GROUP.
In an implementation with several companies it is unlikely that the close of business

will be run for each company separately, instead it is likely that the close of business
will be run for groups of companies.
Companies can be grouped together by using COMPANY.GROUP field in the

company record. This holds a group number (1-999), which is based by default on the
first 3 numeric elements of the company id.
COMPANY.GROUP
A maximum of 3 characters may be entered.
Must be the key to a valid entry on the COMPANY.GROUP file.
Multi-Company Different Local Country

The ability to allow COB processes to run at different times for companies or groups of
companies requires the system to allow each company to use a different system
calendar, since different countries will have different holidays.
COMPANY.GROUP codes are used to identify the various operating companies in a
T24 installation.
When Global Processing (GP) product is installed, it is possible to run COB separately
for a group of Companies.
Format of the ID of a Company is CC-GGG-LLLL, where CC is the Country Code,

GGG is the Group ID and LLLL is the local code (sequence no.) of the Company.
A Lead Company and its Branch Companies will have the same Group ID.
The sequence no. will be unique only within a CC-GGG value.
Inter-company Group Accounting
If required inter-company accounting is allowed within the same group of companies in

a Global Processing environment. This mode of operation is identified in the
INTERCO.PARAMETER application. In this mode the system will restrict the use of
accounts from other companies belonging to different groups to the transaction.
Where inter-company accounting is required then the record SYSTEM of

INTERCO.PARAMETER must be input and authorised before creating the second
company.
Field BALANCE.INTERCOMP of INTERCO.PARAMETER Indicates in a multi

company system that multi company processing will take place.
This basically allows financial level data to be stored in a separate table for each
company.
YES indicates a Multi Company environment whereas YES in the

BALANCE.INTERDEPT field indicates that a Multi Branch (Multi-Book) environment is
set up.
An additional concept of different types of processing date will be introduced to provide
extra flexibility. The current system date for each company or branch in a multi-
company environment will be classified as follows in DATES application.
NORMAL working day

The current system date is a standard working day according to the official calendar of
the country. E.g. Monday to Friday in a standard operating environment.
RESTRICTED working day
The current system date is not an official working day but is defined as a working day
for the branch or company. E.g. a branch may open on a Saturday when normal
working is Monday to Friday
CLOSED working day
The current system date is not a working day for the branch. E.g. the system will run
COB process seven days of the week but the branch will not work on a Sunday. Also a
local branch holiday will be termed a CLOSED day.
The DATES record for a company will indicate the day type.
Processing Restriction Based on Working Day Classification
Additional restrictions can be built into the system to restrict online processing that can
take place on a system date.
NORMAL
Any standard transaction can be performed (subject to SMS)
RESTRICTED
Only transactions identified in the VERSION application that can be used on a
restricted day will be available to the user.
CLOSED
Only transactions identified in the VERSION application that can be used on a closed
day will be available to the user.
Note that Accounting Entries can be posted in a company on any of the above types of
working day.
Company Holiday Definitions
Under GP it is now possible to maintain different calendars for each company. The
working day calendar is controlled by the BATCH.HOLIDAY field in the company
record. This should contain the country and region code that comprises the first 4
characters of the HOLIDAY table. Each working day in this calendar is an operational
day for T24 with a corresponding close of business.
If GLOBAL.PROCESS is specified the value of BATCH.HOLIDAY can be different
between companies, in a non-GP environment the values must be the same between
all companies. Note that in a GROUP accounting structure the BATCH.HOLIDAY must
be the same for all companies in the same group.
In addition to the separate Batch Holiday definitions the system also provides additional flexibility in the way the system treats each working day.
OFFICIAL.HOLIDAY defines the standard working day definitions for the country or region that the company operates in. The default value will be the BATCH.HOLIDAY,
although this may be a different country or region to the BATCH.HOLIDAY.
BRANCH.HOLIDAY allows definition of a calendar that is used by the particular company. The actual working days of the branch may be different from the official holidays,
e.g. in the case of branch which opens in a shopping centre on a Saturday. The default value here is the OFFICIAL.HOLIDAY.
In default date calculations for transaction processing the BRANCH.HOLIDAY value will be used for the local country calendar.
OFFICIAL.HOLIDAY
Defines the Official business holiday table for the local country related to this company.
This field will be used to control the update of the LOCAL.COUNTRY field, which is now made no input.
Validation Rules
2 character country code, or 2 character country code appended with 00
If only 2 characters are entered then
The last 2 characters must be 00
A value must be present in this field
BRANCH.HOLIDAY
This field defines the Business holiday table used by this company (or branch).
It can be different to the OFFCIAL.HOLIDAY table.
An example would be where the Official country working days
The branch working days could be Monday to Saturday (or even all 7 days) irrespective of Official public holidays.
The CURRENT.DAY field on the DATES record for the company will indicate the type of business day.
NORMAL the branch is open on an official working day
RESTRICTED the branch is open on an official holiday, e.g. a weekend or public holiday
CLOSED the branch is closed i.e. the holiday table for the branch indicates a non working day, or the day corresponds to a value on the BRNACH.CLOSED field for the
company
It is possible to determine whether a VERSION can be run based on the value of the CURRENT.DAY, so that business activities can be restricted when a branch is open on
an official holiday.
If the BRANCH.HOLIDAY is different to the OFFICIAL.HOLIDAY then the LOCAL.COUNTRY will be blank and the BRANCH.HOLIDAY will be used to populate the
LOCAL.REGION field.
If they are the same then the first two characters of the OFFICIAL.HOLIDAY field will be used to populate the LOCAL.COUNTRY field and the LOCAL.REGION.FIELD will be
blank.
Validation Rules
Optional input, if no input is made it will default to the value of the OFFICIAL.HOLIDAY field
Must be a valid entry on the REGION table, i.e. a two character country code followed by 2 numeric characters
If only the 2 character country code is input then the field value will be appended with 00
BATCH.HOLIDAY
This field defines the holiday table that will be used to control the T24 batch cycling.
It is possible to define a BATCH.HOLIDAY value that is different to either the OFFICIAL.HOLIDAY or BRANCH.HOLIDAY.
For example the bank may decide to run a batch 365 days per year even if on some days none of the branches are open.
The holiday table defined for this field will NOT be used as a default in any date calculations made for business activities.
Validation Rules
Mandatory input for the master company, if no input is made it will default to the value of the BATCH.HOLIDAY field in the master company record
Must be a valid entry on the REGION table, i.e. a two character country code followed by 2 numeric characters
If only the 2 character country code is input then the field value will be appended with 00
Unless GLOBAL.PROCESSING is set to Y in the SPF, SYSTEM record then this field must be the same as the BATCH.HOLIDAY field of the master company record
Let’s understand OFFICIAL.HOLIDAY, BRANCH.HOLIDAY, BATCH.HOLIDAY with an
example,
OFFICIAL.HOLIDAY - Holiday record holding the Working days for a COMPANY.GROUP

BRANCH.HOLIDAY - Holiday record holding the Working days for a particular branch. This
could be common for branches of the same region.
BATCH.HOLIDAY - Holiday record holding the days when COB should be run for the
COMPANY.GROUP. This should be the same for all the companies in the COMPANY.GROUP.
You need to have this separately in order to run COB for all the companies during
RESTRICTED working days.
Following are the working days with respect to a Branch.

NORMAL - the Branch is on a normal working day i.e. both the BRANCH.HOLIDAY record and
OFFICIAL.HOLIDAY for this day are 'W'. BATCH.HOLIDAY record is 'W'.
RESTRICTED - the Branch is on a restricted working day i.e. the BRANCH.HOLIDAY record is
'W' and the OFFICIAL.HOLIDAY record is 'H'. Please note that the BATCH.HOLIDAY record
will be 'W'
CLOSED - the Branch is on a closed day i.e. the BRANCH.HOLIDAY record is 'W' and the
OFFICIAL.HOLIDAY record is 'W'. BATCH.HOLIDAY record will be 'W'
Consider the following example.
US0010001 OFFICIAL.HOLIDAY - US00

BRANCH.HOLIDAY - US01 Weekly holiday - Sunday
BATCH.HOLIDAY - US99
DE0010001 OFFICIAL.HOLIDAY - US00

BRANCH.HOLIDAY - US02 Weekly holiday - Monday
BATCH.HOLIDAY - US99
Time Differences in Different Geographic Regions
There will be one central base time for the T24 system that will be used to update the
standard audit date and time fields on the T24 application records. The time used will
be that as currently defined on the server running the application.
An additional enrichment will be provided for the user on the system DATE.TIME fields
that will show the time of the last update in the actual company where the transaction
resides. In the case of accounting entries where the transaction is originated in a
different company, the date time enrichment shown on the resulting entry will be that
of the company that owns the account.
In order to display this enrichment it is necessary to store the time difference between
the server and the individual companies on the COMPANY application.
Time Differences between Companies

The system will record the date time of transaction updates based on the server time,
the system fields DATE.TIME and AUDIT.DATE.TIME will continue to show the server
time. It can also be configured to enrich this time with the local time that the update
took place.
In order to show this enrichment the COMPANY record must be configured to define
the time in that company relative to the server. E.g. a server running in Amsterdam on
CET with a UK based company should show –1:00 as the RELATIVE.TIME in the UK
Company.
The close of business process can be launched for a group of companies or for an
individual company.
For a Group of Companies

In GP mode by default the system will run the COB for all companies, which belong to
the same group as the current company that the operator is signed into. Additionally it
will only run the process for those companies that share the same current system
date.
Therefore to initiate a COB for a group of companies you must be signed into a
company that belongs to the group you wish to process.
To launch the COB for a group of companies the TSA.SERVICE record for a group of
companies must be authorised with a key of COB-nnn where nnn is the company
group.
For an Individual Company
If an individual company needs to run it’s COB process separately from the rest of the
group this can be achieved by setting the SEPARATE.EOD flag in the COMPANY
record to Y. If this is set the COB can only be initiated for that company by launching
specifically from that company.
To return to the normal group operation mode the SEPARATE.EOD flag should be
reset.
To launch the COB for an individual company the TSA.SERVICE with a key of COB-
ccccccccc must be authorised where ccccccccc is the company code.
To launch the COB for an individual company the TSA.SERVICE with a key of COB-
ccccccccc must be authorised where ccccccccc is the company code. Notice the
record id TWO of TSA.WORKLOAD.PROFILE indicates to run COB for this lead
company number of agents required are 2.
1. To initiate a COB for a group of companies you must be signed into a company
that belongs to the group you wish to process
2. To launch the COB for a group of companies the TSA.SERVICE record for a
group of companies must be authorised with a key of COB-nnn where nnn is the
company group.
Three Lead Companies namely GB0010001, EU0010001, SG0010001 are in the

same group that is group 1 indicated by digits 001 where 1 is the valid record id of
COMPANY.GROUP application. For initiating COB for this group, the TSA.SERVICE
record, COB-001 should be used.
It can be seen that the COMPANY.GROUP (characters 3-5 of the company code) is
used to identify the region that a company belongs to.
In this example there are 9 holiday tables used corresponding to the different country
and region codes with the following holidays:
In this example there are 9 holiday tables used corresponding to the different country
and region codes with the following holidays:
The operator wishes to start the batch for the European region, times and dates are as
mentioned
The operator will initiate COB services from one of the above entities and it will:
Set CO.BATCH.STATUS for each DATES record of the above companies to turn the
company offline
Run all batch processes for all 5 companies
Assuming the process took 1 hour at the end of the process the dates will be as
mentioned.
The operator will be signed into one of London, the two Dublin companies or
Bratislava (not Amsterdam) and initiate the COB process through COB services.
Although Amsterdam is part of the European region the batch process will not run
since the current system date is different from the other companies
After completion of the COB process the situation will be as shown.
(1) Is the field in COMPANY application holds holiday record holding the working days for a
COMPANY.GROUP
a.OFFICIAL.HOLIDAY
b.BRANCH.HOLIDAY
c.BATCH.HOLIDAY
(2) Is the field in COMPANY application holds holiday record holding the working days for a
particular branch.
a.OFFICIAL.HOLIDAY
b.BRANCH.HOLIDAY
c.BATCH.HOLIDAY
(3) Is the field in COMPANY application hold holiday record holding the days when COB should
run for the COMPANY.GROUP.
a.OFFICIAL.HOLIDAY
b.BRANCH.HOLIDAY
c.BATCH.HOLIDAY
(4) If an individual company needs to run it’s COB process separately from the rest of the group
this can be achieved by setting the SEPARATE.EOD flag to Y in
a.SPF
b.DATES
c.COMPANY
d.HOLIDAY
(5) A lead company US0030303 is in group 3 this group is defined in an application.

a.COMPANY.GROUP
b.INTERCO.PARAMTER
c. COMPANY
d. DATES
(4) If an individual company needs to run it’s COB process separately from the rest of the group
this can be achieved by setting the SEPARATE.EOD flag to Y in
a.SPF
b.DATES
c.COMPANY
d.HOLIDAY
(5) A lead company US0030303 is in group 3 this group is defined in an application.

a.COMPANY.GROUP
b.INTERCO.PARAMTER
c. COMPANY
d. DATES
In this learning unit/course, you learnt to,
•Create a new lead company
•Explain how to group companies
•Describe company holiday definition
•Describe COB execution in Multi-Company
GP2.Global Processing-R13
GEN4-T24 Directory Structure and Application Classification-R08.02 38
GP2.Global Processing-R13
GEN4-T24 Directory Structure and Application Classification-R08.02 39

GP2.Global Processing-R13

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

GP2.Global Processing-R13

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GP2.Global Processing-R13

Uploaded by

Copyright:

Available Formats

Welcome to the “Global Processing Part II” learning unit.

In this learning unit you will

•Create a new lead company

In a Global Processing environment the batch will be initiated as follows:

In an implementation with several companies it is unlikely that the close of business

Companies can be grouped together by using COMPANY.GROUP field in the

Multi-Company Different Local Country

Format of the ID of a Company is CC-GGG-LLLL, where CC is the Country Code,

If required inter-company accounting is allowed within the same group of companies in

Where inter-company accounting is required then the record SYSTEM of

Field BALANCE.INTERCOMP of INTERCO.PARAMETER Indicates in a multi

YES indicates a Multi Company environment whereas YES in the

NORMAL working day

OFFICIAL.HOLIDAY - Holiday record holding the Working days for a COMPANY.GROUP

Following are the working days with respect to a Branch.

Consider the following example.

US0010001 OFFICIAL.HOLIDAY - US00

DE0010001 OFFICIAL.HOLIDAY - US00

Time Differences between Companies

For a Group of Companies

Three Lead Companies namely GB0010001, EU0010001, SG0010001 are in the

(5) A lead company US0030303 is in group 3 this group is defined in an application.

(5) A lead company US0030303 is in group 3 this group is defined in an application.

You might also like