The following are the parameter tables that Position Management (PM) enquiries refer to produce the output according to user preferences:

PM.CALENDAR
Most enquiry records are linked to a calendar for providing time splits by which data is grouped.

- Daily for 2 weeks
- Weekly for 3 months
- Monthly for 1 year
Different calendars can be created, defining different time splits for including it in specific enquiries as appropriate.

The opening position can be displayed (if required) by setting up the first time split with the value OPE in the Period field. This includes opening account balances, and asset and liability currency positions as at the start of day.

The following special codes can be used to define splits:
CAL | Includes call contracts, value today |
TOM | Tomorrow |
SPT | Spot next two working days |
D (Days) | Number of calendar days from spot date |
W (Weeks) | Number of weeks from spot date |
M (Months) | Number of months from spot date |
Y (Years) | Number of years from spot date |
* | Remaining period |



.png)






PM.ENQ.PARAM
This file has enquiry parameters that provides input to a related Temenos Transact PM enquiry. The enquiry selection takes place against the PM.DLY.POSN.CLASS
file that is updated online.
Most enquiry records are setup using PM.DLY.POSN.CLASS
,hence, any changes to this file is effective immediately after a transaction is entered in any of the source applications.
There is no need to run a COB to make the changes in these parameters.Any changes made to records in this file are effective immediately, as the user needs to change only the selection conditions against the PM.DLY.POSN.CLASS
file and the display format of the data.
There are several options available in this application, which determines how to display the information:
- Using overnight data or online data.
- The following Enquiry records can be grouped by calendar period or date with the below features:
- PM.FX.POS
- PM.GAP
- PM.CAS
- Lines can be grouped by PM calendar period or by activity date.
- Dates formatted as calendar period.
- Enquiry data can begin at a particular calendar period for example, spot onwards as opposed to CAL.
All other Enquiry records have data grouped by activity date.
- Amount signs can be displayed as signed or unsigned.
- As ‘+’, ‘-‘, or ‘(and)’ to enclose negative amounts.
- The position classes and dealer desks are derived from a
PM.POSN.REFERENCE
record or group of position classes to be used are directly specified. - In a multi-company environment, enquiry information can be consolidated from different companies.
Different lines can be produced for the same value date or period by specifying a second group of position classes. For example, primary and secondary Nostros in the PM.NOS enquiry.
One way to test the changes made to PM.POSN.REFERENCE
position classes would be to use the record, which has been changed as an input parameter to an equivalent PM.ENQ.PARAM
record. For example, the GAP enquiry defined in PM.POSN.REFERENCE
equates to the Interest Mismatch (GAP) Position (PM.GAP) enquiry defined in PM.ENQ.PARAM
.
It is efficient to replace the enquiries setup using the PM.POSN.REFERENCE
application with those using the PM.ENQ.PARAM
application. Most of the advantages are described above.
Further advantages are as follows:
- Existing PM enquiries can be duplicated in the new system.
- PM enquiries are more flexible in terms of consolidation, particularly in relation to grouping dealer desks and position classes.
- The same basic ENQUIRY, for example, FXPOS can have different
PM.ENQ.PARAM
records associated with it, each of which can show a different view of the PM data derived from the same basic information.
It is possible to setup the following:
- Several variations of the same enquiry by using different
PM.ENQ.PARAM
records. PM.ENQ.PARAM
record which takes the GAP start activities from the GAP position classes (that is, the rates are taken from the actual contract).
For example, if financial control and trading areas want to take different views of the GAP Enquiry, then a PM.ENQ.PARAM
record can be setup to take the GAP position classes from the PM.POSN.REFERENCE
GAP record (where all start activities use the cash position classes that is, the rate is taken from the underlying account). Another record can be setup where the start activities are taken from the GAP position classes (that is, the rate is taken from the actual contract).
This can also apply to signs for assets and liabilities, or bought and sold amounts. There are four fields available to set the signs for displayed amounts.

There are two ways in which PM records may be consolidated by periods – through entry of a PM.CALENDAR record in the Calendar field on PM.ENQ.PARAM
, or by an entry into the Consol Period field.
Alternatively, in the Consol Period field, the following calendar periods can be defined:
- D (or null) data is consolidated on a daily basis.
- M data is consolidated by calendar month.
- Q data is consolidated by calendar quarter.
- S data is consolidated on a semi-annual basis.
- A data is consolidated on an annual basis.
If the Consol Period and Calendar fields are left blank, the default consolidation method takes the value as Daily.
The Consol Period field is also available on the PM.REPORTS
table to give the option of either using the PM.CALENDAR
or period method of consolidating data.
The period method of consolidation is calendar based, and it does not consider working or non-working days to calculate the end date of a period (that is, the end of the first semi-annual period will always be 30th June).

PM.POSN.REFERENCE
This is the main PMenquiry parameter application, which holds the definitions of PM enquiries and their content. Its key is the user defined position type, such as GAP for the interest gap enquiry.
The file has the following functions:
- Specifies the events to be included in the enquiry by defining position references for inclusion.
- Defines the forward periods to be displayed by specifying which PM calendar (
PM.CALENDAR
) can be used in the ENQUIRY. - Divides the position into subgroups, such as dealer or currency combinations. This function is based on the grouping of dealers defined in the
PM.GRP
table.

PM.GRP
This table helps create different groupings of DEALER.DESK
,FX.POS.TYPE
and CURRENCY.MARKET
. For example, if Spot Dealers and Money Desk need to split cash flow enquiry along with consolidation of all dealers, the IDs (setup on the DEALER.DESK
table) identifying the individual dealers are grouped together as appropriate, with a unique key to identify the group. On creating the Enquiry, it is included in the PM.POSN.REFERENCE
file of the key identifying the group that satisfies the grouping requirements.

COMPANY.CONSOL
Thistable holds the description and details of grouping of companies. The table highlights the consolidation structure of lead and branch companies. The grouping assists in combined CRF reports. Each record in the table is independent and has no hierarchical relationship between the records.
Additionally, it holds details, such as the default currency for any report to be produced for the group, consolidation details of companies,special exchange rates to be used at report production time, etc.
A sample illustration of COMPANY.CONSOL
record is as follows:
The COMPANY.CONSOL
reference mentioned in the PM.ENQ.PARAM
record of the respective enquiry in the Comp Consol field allows the data from different lead companies in the PM enquiries.

BASIC.INTEREST
This centrallystored table defines the floating rates, such as base rate, prime rate, overnight rate, and so on from where Temenos Transact applications can access as required. The interest rate type applicable for an account or contract can be fixed or floating. Ifthe interest rate type is floating, then BASIC.INTEREST
key along with the spread (if any) details are available on both transactions and PM.TRAN.ACTIV
I
TY
records. During run time, the enquiry fetches the present basic interest rate from BASIC.INTEREST
table (using the BI reference mentioned on the PM.TRAN.ACTIVITY
record) and add or reduce the spread (if any) to construct the PM enquiry.
An illustration of BASIC.INTEREST
table record is as follows:
In this topic