Bills

Bills
Overview
The types of Bills handled by the Banks are:
l Trade Bills (Demand Bills which are payable on demand and Usance Bills payable on a future date or after a certain number of days
from Bill-Date or Acceptance).
l Direct Bills (Drawer and Drawee are the same and with a maturity date).
l Clean Bills (Cheques).
Individual bill types and their nomenclature differ from country to country.
Irrespective of the Type of bill, the possible operations for a Bill are:
l Collecting and crediting the customer

l Using Bills as collateral to secure limits to customers
l Discounting and lending by the Bank
l The BL product handles the above operations for different types of Bill,
Bills - Release R13.00 -Page 2 of 29 - (c) Temenos Systems 2013 05/07/2013

Deal Processing
Bills Operation
Let us now see how the different Bill products are mutually exclusive operationally and at the data input level in this Module.
Bills for Collection

In T24 terms, a Bill for Collection product is understood as a Bill, which is to be sent for collection purposes only. It cannot be discounted or
attached as collateral. Once the Bill is realised it is credited to the nominated account, and if it is returned the relevant charges are debited to
the nominated account.
The Operation Key should be for “Collection”
Bills as Collateral
In T24 terms, a Bill Collateral product is understood as a type of Bill that can be given as collateral to a LIMIT fixed for the purpose of lending.
It can be for an overdraft in a current account. A third party Bill can be taken as collateral.
This product can be operated with a link to the Limits Module, Collateral Module and Past Due Module.
A LIMIT.REFERENCE is created for the Bills product and incorporated in the LIMIT.PARAMETER and the LIMIT is set (refer to the Limits
Module for details) and it is linked to a Bill Contract through COLLATERAL.RIGHT and COLLATERAL application (refer to the Collateral Mod-
ule).
This LIMIT.REFERENCE can be used for setting up an exposure limit for a customer who offers his bills as collateral for another customer.
The Operation Key in BL should be “Collateral”.
Bills for Discounting

In T24 terms, a Bill Discount product is understood as a type of Bill which can be discounted, and the DRAWER of the Bill can use the remain-
ing funds post discount till the value of the Bill is realised or Returned.
The Operation Key in BL should be “Discount”.
A Bill Register created could be discounted only if the LIABILITY.CUSTOMER and the customer of the Bill Contract are the same.
The discounted amount is based on the INTEREST.RATE defined for the total of tenor plus GRACE.DAYS defined for the bill.
The discount amount will be credited to the IRA account and amortised as per the frequency defined in BL.PARAMETER.
Maturity
When the proceeds of a Bill are realised, the BR.COLLECTION.STATUS and/or BB.COLLECTION.STATUS fields in the BL.BILL application
are updated with “CLEARED” and “RETURNED” if the Bill is dishonoured.
Before the maturity date of a Bill for all operations, the proceeds can be realised or dishonoured by changing collecting status to an appropriate
value.
For discount and collateral operations, the Bills are automatically realised on maturity date through the batch process, if the Bills collection
status is not changed before the maturity date. For collection operation, the user has to change the collection status manually as and when the
Bill is realised or dishonoured, as the batch process will not handle the maturity process.

When a Bill Contract has more than one Bill, the status of all the BL.REGISTER bills will be updated by filling the status in the OVER-
ALL.COLLECTION.STATUS field, if the status of all the Bills is the same.
If there is more than one status defined, ascertain which status has the majority and individually fill in the status of the minority in BR.CO-
LLECTION.STATUS/BB.COLLECTION.STATUS and then update the status of the majority in the OVERALL.COLLECTION.STATUS.
For example:
In a BL containing 25 BRs with 5 BRs having a status of RETURN and the remaining 20 BRs having a status of CLEARED, first individually fill
in the BR/BL.COLLECTION.STATUS fields with RETURN for the BR’s with status as RETURN and fill in the CLEARED status in the OVER-
ALL.COLLECTION.STATUS field. Whilst committing, the remaining 20 BRs will have a status of CLEARED.
Financial Information
Inte r e s t C a lc ula tion

Interest Rate can be specified either as an interest key or a flat interest rate.
Interest Rate can be specified in the Bills Contract as a key from either the PERIODIC.INTEREST or BASIC.INTEREST file. In both cases a
spread could also be specified. In case a key is specified from PERIODIC.INTEREST table, the interest rate is derived using the Interpolation
Method as done in the MONEY. MARKET application.
To specify BASIC.INTEREST, the basic interest key can be given to default the appropriate rate for that key. To specify PERIODIC.INTEREST,
the periodic interest key prefixed with “P” has to be given. To specify periodic interest key of 01, in the interest key field enter “P01”.
Irrespective of the way interest is specified, the interest rate for the Bills Contract is fixed at the time of committing the contract, and interest
related fields cannot be changed once authorised. However, when the Bill is taken to the Past-Due (PD) Module, if a floating rate key (from
BASIC.INTEREST table) is specified, that will be taken to the PD Module.
The system will determine the effective interest rate by adding the interest differential, if any, defined in the appropriate BGC record.
Inte r e s t Me thod
In the BL module, the following interest calculation methods are supported:
l Discount
l Discount to Yield
l Yield added
In DISCOUNT operation, the Bill principal amount is discounted upfront and credited to the customer account before the realisation of
Bills. The Bank collects interest upfront for the period including the grace days during the discount process. The discount amount is debited to
the Interest Liquidation account and credited to the Interest Received in Advance (IRA) category as defined in BL.PARAMETER. Interest is
received in advance and amortised as per the frequency specified in BL.PARAMETER.
The interest calculation details are:
Discount Type
In discount type of interest calculation, it uses the simple interest calculation method like the LD application.

Discount amount of USD 80.56 is collected upfront from the Interest Liquidation Account during input, and the Close of Business process
will amortise USD 2.78 daily for 29 days.
Discount to Yield
In Discount to yield type of interest calculation, the interest amount is discounted with the interest rate like net present method.
For the above example the interest calculation under Discount to yield method is:

Discount amount of USD 79.91 is collected upfront from the Interest Liquidation Account during input, and the Close of Business batch proc-
ess will amortise USD 2.76 daily for 29 days.
Yield Added
In Yield added type of interest calculation, the interest amount is discounted with the interest rate like net present method of interest cal-
culation, but yield is added back as per the frequency specified in the BL contract.
In Yield added Interest method, the frequency is mandatory. However this method does not support C and D interest basis.
* No of Days as per the frequency defined (Daily / Monthly)
# No of times based on frequency
Discount Amount = Principal Amount – PV.Amount
For the above example the interest calculation under Yield added method is:
For the above example, if the frequency is 10th of every month:

Gr a c e D a y s Inte r e s t C a lc ula tion
The number of GRACE.DAYS can be specified with a prefix of either C (for Calendar Days) or W (for Working Days). If a prefix of W is spec-
ified, the actual number of calendar days is calculated using the HOLIDAY table of the contract currency. In both cases, the Grace Period
Interest will be calculated on the total number of calendar grace days and will be recovered up front along with interest.
A c c ounting Entr ie s
The accounting entries for all operations with respect to charges, interest and contingent entries are generated during BL.BILL processing.
The accounting entries, based on the operation, are:
Operation Type Discount
Operation Type Discount – Input
Operation Type Discount –Amortization
Operation Type Discount - Amortisation
Operation Type Discount –Maturity

Operation Type Discount – Maturity
Drop forward entry that was created during new contract input
Operation Type Collateral –Input
Operation Type Collateral - Input
Operation Type Collateral-Maturity
Operation Type Collateral – Maturity
Operation Type Collection-INPUT
Operation Type Collection - Input
Operation Type Collection-MATURITY

Operation Type Collection – Maturity
Operation Type – All
Charge collection Process at Input/Maturity
Operation Type - All
C ha r ge s C a lc ula tion
Charges and Tax on charges are calculated by the system when a Bill contract is committed.
It is possible to define charges in the BTTC file for three levels of BL.REGISTER, BL.BATCH and BL.BILL. If the system uses a BTTC record to
default values (Refer to Defaulting Mechanism), then the charges defined in the BTTC record are calculated as follows:
1. The charges defined for BL.BILL level are calculated on the total Bills principal Contract amount.
2. The charges defined for BL.BATCH level are calculated on the total bill batch amount.
3. The charges defined for BL.REGISTER level are calculated for each Bill Register attached to the contract (either directly or through
Batches).
In addition, the system calculates the charges, if any, defined in individual BL.REGISTER, BL.BATCH and BL.BILL records. If a Charge Code
defined in the BTTC record for a charge level and the same charge code is used for that charged code level, then charges will be calculated only
once.
I.e. If a charge code is defined in BTTC for a BL.REGISTER charge level and the same charge code is used in an individual BL.REGISTER rec-
ord, the system will calculate the charge only once.

The calculated Charges and Tax on charges are displayed in the Bills Contract record in multi-valued fields, with the appropriate ID (of BL.BILL
or BL.BATCH or BL.REGISTER), charge code, currency, foreign and local currency amount, charge date, exchange rate, tax etc.
D e fa ulting Me c ha nis m
A defaulting mechanism is used to default values in some of the BL.REGISTER and BL.BILL fields to reduce data-entry and eliminate errors.
The default will happen only when no value has been entered in the defaulting field.
In the BL.REGISTER application, the following fields will default from the BL.TYPE file (depending on the value of BL.TYPE entered):
l Recourse
l Discount
l Collateral
l Collection
The Category code is defaulted from BL.TYPE to BL.REGISTER and BL.BILL and cannot be changed at the BR/BL level.
In BL.BILL, the following fields would be defaulted using the values defined in appropriate BTTC, BGC or BL.PARAMETER records:
GRACE.DAYS
INTEREST.KEY
INTEREST.SPREAD
INTEREST.RATE
CONSOLIDATE.ENTRY
In BL.BILL the interest basis is defaulted based on the interest basis defined for contract currency in the currency application.
Currency market for BL.BILL will be defaulted from BL.PARAMETER.
Ge ne r a l c onditions or r ule s for de fa ulting

The system will first look for an appropriate BTTC record and take the values defined therein. Then it will use the values defined in the appro-
priate BGC record for modification/override purposes. Finally it could use the values from BL.PARAMETER. It is possible that some of the
fields in BTTC or BGC records are not defined (null values). As a general rule the system will skip these fields and use the values defined at the
next level of parameter records.
If BL.TYPE of all BL.REGISTER entries attached to a Bill contract are the same, then the system will first look for a BTTC record with key
“DISCOUNT*NNNN” wherein the “NNNN” is the value of the common BL.TYPE. If there were no such records, then the system would look
for a record with the key “DISCOUNT”.
If BL TYPE of all BL REGISTER entries attached to a Bill contract were not the same, then the system would only look for a BTTC record with
the key “DISCOUNT”.
The system will first update the CONTRACT.GROUP field in Bills Contract. Then it would determine which is the first CONTRACT.GROUP
defined in the APPL.GEN.CONDITION file (Record Key:BL) which satisfies the Bill Contract conditions. If no contract group were defined
therein satisfying the Bill Contract conditions, the system would not update the CONTRACT.GROUP field in the Bills Contract.
The BGC file could have records with key values of either “C-CUSTOMER NO.” or a valid Bill CONTRACT.GROUP. In BGC the system would
first look for a record with key “C-CUSTOMER NO.”. If the record does not exist, then the system would look for a record with key equal to
the CONTRACT.GROUP field in the Bills Contract.

The values in BGC record fields could in some cases override the BTTC values or in some cases could modify the BTTC values. It is possible
that both BTTC and BGC records are not available or that the values for some fields are not defined in these records. In such cases, the values
from the BL.PARAMETER file would be used by the system to default the values.
The rules for defaulting specific fields are explained below:
Field: GRACE.DAYS
If the BGC value were defined (not null), then the BGC value would be defaulted. If the BTTC value is defined (not null) and the BGC value is
not defined (null), then the BTTC value would be defaulted. If both the BGC and BTTC values were not defined (null), then the GRACE.DAYS
defined in the BL.PARAMETER file would be defaulted.
Fields; INTEREST.KEY, INT.SPREAD and INT.RATE
These fields would be defaulted in the Bill Contract from the appropriate BTTC record if they were not null.
Fields: MAX.INT.RATE and MIN.INT.RATE
These fields are used to produce override messages in case the effective rate of interest is outside these limits. These rates are optional in
BTTC, while mandatory in BL.PARAMETER.
D e fa ult of Lia bility C us tom e r

In this Module, a default mechanism is incorporated into deciding the LIABILITY.CUSTOMER based on a set of values entered in the BL.RE-
GISTER, which is explained below.
The calculated value depends on the values entered in the fields RECOURSE, DRAWER, ACCEPTOR and DRAWEE.
If the RECOURSE is “Yes” and the DRAWER is a Customer, then DRAWER is the LIABILITY.CUSTOMER.
If the RECOURSE is “Yes”, but the DRAWER is not a Customer and the ACCEPTOR is a Customer, then the ACCEPTOR is the LIA-
BILITY.CUSTOMER.
If the RECOURSE is “Yes” and both the DRAWER and ACCEPTOR is not a Customer, but the DRAWEE is a Customer, then DRAWEE is the
LIABILITY.CUSTOMER.
If the RECOURSE is “No” and the ACCEPTOR is a Customer, then the ACCEPTOR is the LIABILITY.CUSTOMER.
If the RECOURSE is “No”, but the ACCEPTOR is not a Customer and the DRAWEE is a Customer, then the DRAWEE is the LIA-
BILITY.CUSTOMER.
In all other cases no value would be returned for LIABILITY.CUSTOMER.
When the LIABILITY.CUSTOMER is null for a BL.REGISTER , it cannot be discounted or collateralised, but even if the LIA-
BILITY.CUSTOMER is null, the BL.REGISTER can be processed for collection.
Sy s te m Ma inta ine d File s

In addition to the files maintained by the user as explained above, the system internally maintains some files for various processing purposes.

B L.MA TU R ITY
This file contains records for each MATURITY.DATE and Bill Contract combination with details of BILL.REGISTER items attached to the Bill
Contract and maturing on the MATURITY.DATE. Records in this file are created by the system whenever a Bill is authorised.
For each unique MATURITY.DATE of the attached BILL.REGISTER items in a Bill Contract, one record is created in this file with a key of
"MATURITY.DATE Bill Contract Number” (Eg.20010702.BL0109282011). The record will contain all the BILL.REGISTER items attached to
the Bill Contract and maturing on the date specified by the Key.
In the record for the MATURITY.DATE of the contract, in addition to the BILL.REGISTER items maturing on the date, an entry for the Con-
tract ID will also be included.
BL.MATURITY
B L.EN T.TOD A Y
This file contains the IDs of all BILL.REGISTER items entered in a day. The key for this file is the processing bank date.
BL.ENT.TODAY
B L.B A LA N C ES
This file contains a record for each BILL.REGISTER and stores basic accounting information such as VALUE-DATE, MATURITY-DATE, PRIN-
CIPAL, TOTAL INTEREST, ACCRUED INTEREST, GRACEDAYS INTEREST,ETC.

BL.BALANCES
B L.B ILL.B ILL.R EG

This file contains a record for each BILL.REGISTER, Batch and Bill Contract and store information about cross-references and system status.
The records in this file are created when a BILL.REGISTER, Batch or Bill Contract are committed and authorised.
BL.BILL.BILL.REG
B L.C H A R GES
This file contains a record for each BL.REGISTER, BL.BATCH and BL.BILL Id for which charges are collected. The record contains the charge
code, charge amount in local currency and foreign currency, charge date, tax code and tax with the respective Bill Ids.

BL.CHARGES
B L.B ILL.A C C OU N T
This file contains the id of the account that is given in the BL.BILL contract for drawdown, principal liquidation, charges and interest liq-
uidation account with the respective BL reference number.
BL.BILL.ACCOUNT
B L.B ILL.C U STOMER

This file contains a record for each customer as given in BL.BILL contract for limit update and contract tracking purpose with all BL.BILL con-
tracts attached to the customer irrespective of the operation.
BL.BILL.CUSTOMER

B L.C OLLA TER A L
This file contains the BL.BILL contract number and collateral code. This helps to find the collateral code to which the BL.BILL reference
number is attached for collateral linkage purpose.
BL.COLLATERAL
B L.B R .TYPE
This file has the list of BL.REGISTER reference numbers that have common BR.TYPE in their BL.REGISTER. The Id to the file is BR.TYPE.
BL.BR.TYPE
Move to History File
Based on the number of days after the maturity date to move to history as mentioned in BL.PARAMETER (days post mat), all the matured con-
tracts are moved to the respective history files. (I.E.BL.REGISTER details will be moved to BL.REGISTER.HIST.)
Records in the following applications are moved to the respective history file (.HIST).
l BL.BALANCES
l BL.BILL
l BL.REGISTER
l BL.BATCH
l BL.CHARGES

Change in Parameter
In BL.PARAMETER, we define the Profit and Loss Category for Interest Received Advance (IRA). To change the existing IRA category, give the
category code in the NEW CAT IRA field.
Similarly in BL.TYPE we define the category to which the Bill contracts are booked. To change the existing category, add a category in NEW.CA-
TEGORY.
The BL Close of Business process will handle the above static changes and pass accounting entries to the new category code.
BL-Delivery Process
The Bills module involves generation of delivery messages for sending to various parties at different stages. To handle this, we identify all pos-
sible activities in BL CONTRACT processing so that delivery messages can be generated based on BL ACTIVITY.
Default messages for activity flexibility are available to input additional messages or suppress or change the carrier / message type in the
defaulted messages.
Application Design
The types of Bills handled by the Banks are:
l Trade Bills (Demand Bills which are payable on demand and Usance Bills payable on a future date or after certain number of days from
Bill-Date or Acceptance).
l Direct Bills (Drawer and Drawee are the same and with a maturity date).
l Clean Bills (Cheques)
l Individual bill types and their nomenclature differ from country to country.
Irrespective of the Type of bill, the possible operations for a Bill are:
l Collecting and crediting the customer

l Using Bills as collateral to secure limits to customers
l Discounting and lending by the Bank
The BL product handles the above operations for different types of Bill, which is explained in detail below.
Defining Parameters
The parameters in the Bills Module are defined in the following five applications. These applications allow for the input of product char-
acteristics that are common to a group of Bills. The following are the Parameter files that are to be set up in the same sequence as arranged
below:
BL.PARAMETER (BP) (Module level Parameter File)
BL.TYPE (BT) (Bill Type Definition File)
BL.TXN.TYPE.CONDITION (BTTC) [Optional] (Parameter file for Bill Types and Transactions)
APPL.GEN.CONDITION (Record Key: BL.BILL) [optional] (Bill Contract Group Definition)
BL.GROUP.CONDITION (BGC) [Optional] (Parameter File for Customer/Bill Contract Groups Con-
ditions)
Now let us look at the individual parameter files and their contents.

B L.PA R A METER
You can specify some of the processing characteristics of Bills products using BL.PARAMETER.
This table contains records with the company Id, such as US-001-0001 that define the system parameters that control the processing of the
Bills product. This is the highest level file in the Bills Module, which must be set up before inputting any Bills Contracts along with the other
parameter files. The disbursement, repayment and amortisation transaction code along with the Interest Rate caps, Profit and Loss account for
Interest Received Advance (IRA) and grace days are defined here.
BL.PARAMETER
B L.TYPE
This table is used to define the parameters for defaulting while entering a BILL.REGISTER record. It also defines the Contract Category for var-
ious BILL.TYPE records and also determines the liability customer in case of a dishonour of a Bill for each defined Type.
Example:
BILL.TYPE 1 could be a Bill with a feature of Discounted Bill with Recourse.
BILL.TYPE 6 could be a Bill with a feature of Collateral Bill with Recourse.
BILL.TYPE 2 could be a Bill with a feature of Discounted Bill without Recourse.

BL.TYPE
B L.TXN .TYPE.C ON D ITION

This table is used to define the defaulting values for specific BL.TYPE and Bill Operation combinations.
The Bill Operation is supported by three products viz., DISCOUNT, COLLATERAL and COLLECTION. For each of the Bill operation products,
we will be able to set defaulting values different from each other. The Ids for a BTTC are such as COLLECTION, DISCOUNT or COLLATERAL.
Another option is to define the defaulting values for a variety of permutations and combinations of Bill operation products and Bill types.
For example, a BL.TYPE of 7 could be attached to the Bill operation Id COLLECTION to form a new BTTC Id of COLLECTION*7 (or
DISCOUNT*6 or COLLATERAL*1) in order to carry a different set of defaulting values for this combination.
A Charge or a Commission Code has to be defined in the FT.CHARGE.TYPE or FT.COMMISSION.TYPE conditions, to be invoked in this
application. Charge codes can be set for each charge level of BL.REGISTER, BL.BATCH and BL.BILL to be defaulted into the respective appli-
cation. This addresses the charge, commission and interest defaults that are to be set up.
For discount operations the interest rate as defined here will be used as a default, subject to the defaulting mechanism as defined later.

BL.TXN.TYPE.CONDITION
B L.GR OU P.C ON D ITION

This table is used to modify or override the values defaulted from a BTTC record. Through this application a different default of charge, com-
mission and interest can be defined for an individual customer or a group of customers as defined in APPL.GEN.CONDITION.
The Id for this application is “C-CUSTOMER NO.”(C-1002) or a “GROUP” such as (“TESTC”), (‘TESTD”).

BL.GROUP.CONDITION
It is also possible to define maximum and minimum amounts of charges, together with a discount or premium, at an individual customer level
or a group of customers.
The following fields of BL.GROUP.CONDITION define the special conditions applicable to specific groups of customers or individual cus-
tomers:
CHG.MAXIMUM.AMT defines the maximum amount to be charged for the charge type that applies.
CHG.MINIMUM.AMT defines the minimum amount to be charged for the charge type that applies.
CHG.DISCOUNT.AMT specifies the amount to be deducted from the charge amount calculated.
CHG.PREMIUM.AMT specifies the amount to be added to the charge amount calculated.
A PPL.GEN .C ON D ITION
A contract group can be defined in this application. The contract group is grouped based on the category. For example, “TESTC” belongs to cat-
egory code 30000 and “TESTD” belongs to category code 30001. The APPL.GEN.CONDITION requires a record with an Id of BL.BILL.
APPL.GEN.CONDITION
B L.STA TU S
The user can define the status on the movement of the Bill in this application. This status can be given at BR/BB level. Through a report based
on this application the status of the Bill is monitored on a daily basis.
1. Received from Customer
2. Sent to HO
3. Received at HO …..
4 Sent to Domicile Branch
7. Returned
8. Returned to the Drawer

BL.STATUS
After setting up the Parameter Files the next step is to input data and create a Bill Contract.
C r e a tion of a B ill C ontr a c t

Creation of a Bill Contract involves three stages viz.,
Creation of BL.REGISTER (BR)
Creation of BL.BATCH (BB)[Optional]
Creation of BL.BILL (BL)(also referred as Bill Contract in this User Guide)
B ill R e gis te r (B R )
Details of a Bill can be entered using the BL.REGISTER application:
The Id for this application is auto generated. The Id format is BRYYDDDNNNNN.
l The system determines the LIABILITY.CUSTOMER for the Bill (explained later).
The BL.REGISTER contains, among other information, Start Date, End Date, Currency, Amount and Charge Codes. The system will allow
reversal of a BL.REGISTER not included in a BL.BATCH and not included in a Bills Contract. (See below).
l The user could also enter dynamic particulars about the movement of a Bill, such as Bill Location, Status, etc., using this application.
The BILL.TYPE entered here will distinguish the products to which the BL.REGISTER belongs.
l A copy option is allowed in this Application.

BL.REGISTER (BR)
B ill B a tc h (B B )
A group of Bills entered using the BL.REGISTER application can be batched together using the BL.BATCH application:
The Id for this application is auto generated. The id format is BBYYDDDNNNNN.
Only authorised BL.REGISTER entries can be batched.
l A Bill can be batched only under one Batch.

l A Bill, which has already been included in a Bill contract, cannot be batched again with another batch.
l The system will validate that all the Bills attached to a batch are of the same currency. Bills of different currencies cannot be batched.
l However, it is possible to batch Bills with a different START.DATE, MATURITY.DATE, Liability Customer or BILL.TYPE under the
same Batch.
l The copy option is not allowed in this application.
l A charge code can be given to calculate charges for the batch total amount.

BL.BATCH (BB)
B L.B ILL (B L)
The Individual BR or BBs are processed and accounting entries are generated through the BL.BILL application.
The Id for this application is auto generated. The id format is BLYYDDDNNNNN.
It is possible to include both individual Bills and Bill Batches in a Bill Contract. When a BL.BATCH is included in a Bill Contract the system
will expand and display all the BL.REGISTER records attached to the Batch. Only authorised BILL.REGISTER records and BILL.BATCH rec-
ords can be included in a Bill Contract.
A BL.REGISTER or BL.BATCH already included in a Bill Contract cannot be included again in another Bill Contract.
The system will ensure that all the BL.REGISTER records attached to a Bill Contract (either directly or through batches) are of the same cur-
rency and with the same Liability Customer as specified in the contract.
l Bills of different liability customers cannot be attached in a Bill Contract.
While it is possible to attach BL.REGISTER records of a different BL.TYPE in the same batch, it is not possible to raise a contract by attaching
a different BL.TYPE. However, if the BL.TYPE is of the same product, it can be batched and the contract can be made.
The system will ensure that all the BL.REGISTER items attached to a Bill Contract (either directly or through Batches) have their
START.DATE not later than the VALUE.DATE of the Bill Contract.
It is possible to include BL.REGISTER items maturing on different dates in a Bill Contract.
It is possible to Add/Remove BL.REGISTER/BL.BATCH records to an already authorised Bill Contract (explained later).
l The copy option is not allowed in this application.

l All financial accounting is invoked only during the BL.BILL processing.

BL.BILL (BL)

Delivery
Soft Delivery in BL
To generate delivery messages at various stages of Bills based on the operation and function, through Soft delivery mechanism, the following
steps are to be followed.
l Lists of activities are identified based on the Bills operation, function, type and information source. The probable list is explained later
in the user guide.
Activity, which is identified from the above process, is defined in T24 in the EB.ACTIVITY application by giving the id as module and
activity code.
l These activity codes are internally recognised values in the BL module and Delivery applications.
EB.MESSAGE.CLASS is used to describe in detail about the message with a unique Id.
EB.ACTIVITY, EB.MESSAGE.CLASS and format of messages can be linked through EB.ADVICES.
To generate a different format for each BR.TYPE, specify the application format at the BL.TYPE and give the application format with
mapping key in EB.ADVICES.
l Based on BL operation, the activity code as defined above will get triggered and messages relating to that activity will be generated.
l The user has the flexibility to generate defaulted messages or add new messages or modify the defaulted messages at the BL Contract
processing level.
l The user can control the generation of messages by suppressing messages, change the carrier, as well as change the message date at the
Contract level by overriding the default message details.
Messages can be scheduled for a future date also by changing the Message date field in the BL.BILL application.
l The print preview function can be used to have details of the messages by clicking the preview button on the T24 Browser. Moreover
the SWIFT tag description will be available in SWIFT preview.
l The messages generated at BR/BL level can be identified with the delivery reference for future references.
Additional / adhoc messages for the BL module can be generated through the EB.FREE.MESSAGE application by giving transaction ref-
erence number and other message details.
BL Activities
The generation of messages are based on the BL ACTIVITIES. To denote an activity, we use a 4-digit number which consists of the following
components:
First digit stands for operation of Bill module:
l Collection
l Discount
l Collateral
l Acceptance
l Re-discount
(Currently we support Collection, Discount and Collateral operations only)
Second digit stands for function in Bills module:
l New (Input and authorise)

l Amend (Adding a BR/BB, Deleting BR/BB and authorise)

l Maturity (Clear/Return on or before or after due date)
l Reversal
l Tracers (To be sent on or before or after due date)
Third digit stands for type of Bills:
l Outward
l Inward
(Currently outward bill type alone supported)
Fourth digit for generation of message based on:
BL.REGISTER (All information relating to BL.REGISTER will be available in the handoff table).
BL.BILL (All information relating to BL.BILL will be available in the handoff table).
For example the 1111 activity code stands for outward collection Bill that is input and authorised and has information relating to BL.RE-
GISTER.
List BL Activity codes

The general list of activity codes for the BL module based on operation, type, function and source information are:
List BL ACTIVITY CODES

From the above activity list we can see that in the BL module, numerous activity codes are possible based on operation, function, type of Bills
and level of information (BR/BL).
l i.e.Amendment can be for adding a BR/BB or removing a BR/BB or even a change in static details in a BL module for a Bill which is
received by the Bank for Collection / Discount / Collateral. So we have to create many codes for each amendment activity.
To overcome this, flexibility is available to create a few basic activity codes based on the system generating the appropriate messages irre-
spective of operation.
For this we create an activity code based on common functions.
l Amendment–Remove BR/BBand irrespective of operation (Collection /Discount /Collateral), this code can be used instead of cre-
ating a number of activity codes for each operation.
Once that is done then we map BL.PARAMETER level class type and EB MESSAGE to enable the system to default sensible messages based
on the operation (Collection/Discount/Collateral). The user at the contract level can control these messages either by adding a message or sup-
pressing it or by changing carrier.
BL.MESSAGE.CLASS
For this purpose the messages can be classified as follows:
BL.MESSAGE.CLASS

BL Soft Delivery sample Set-up
To set up a delivery process in BL for Outward collection Bills (information at BR level) following steps are to be followed.
Required activity codes have to be added in EB.ACTIVITY by giving the @ID as application and activity code separated by dash”-“.
To define activity 1111as explained above; in EB.ACTIVITY add a record as “BL-1111” with description as Collection Bill input with info. BR
details.
In EB.MESSAGE.CLASS give the meaningful description for print or swift messages. For example MT 420 is sent for finding out fate of an
instrument. Instead of mentioning it as MT 420 as message, it can be termed as a fate advice with detailed description, which helps the user to
understand the purpose for which the message is sent.
Through the EB.ADVICES application, map an activity with the message EB.MESSAGE.CLASS and a valid message format type in DE.MA-
PPING.
In BL.PARAMETER, map the appropriate BL.MESSAGE.CLASS and EB.MESSAGE.CLASS.
To generate a different format for a particular BR.TYPE, specify the application format in BL.TYPE to get a different format for BR.TYPE 3;
specify the appropriate application format in BL.TYPE id 3.
During the input of a BL contract based on the BL activity code, appropriate message details will be defaulted.
l Additional messages can be added / suppressed or carrier, message type and message class can be changed in BL application.
BL.BILL –Delivery Details
Preview of the messages can be seen using the “Preview” button in the BL.BILL application.
To schedule a message for a future date, change the message date during contract processing, which will add a record in BL.BILL.SCHEDULE
with ID as BL reference number and scheduled message date. Bill batch processes will generate appropriate messages based on the activity
code and message class on the scheduled date.

Limits
Limit Parameter
For limits, based on the LIMIT.PARAMETER as defined for the application BL.BILL, limit reference will be populated at the BL.BILL level.
Limits Table
Operation/ Activ- Input Maturity

ity
Discount Limit is reduced to the extent of Principal Amount Limit is increased to the extent of Principal Amount
Collateral Limit is reduced to the extent to the Principal Amount Limit is increased to the extent of Principal Amount
Collection Limit is updated with the default Limit ID as specified in Limit line is dropped on the maturity
LIMIT.PARAMETER (since bank is not parting the funds)

Bills

Uploaded by

Copyright:

Available Formats

Bills

Uploaded by

Document Information

Original Description:

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

Bills

Uploaded by

Copyright:

Available Formats

Bills

l Collecting and crediting the customer

Bills - Release R13.00 -Page 2 of 29 - (c) Temenos Systems 2013 05/07/2013

Bills for Collection

The Operation Key should be for “Collection”

The Operation Key in BL should be “Collateral”.

Bills for Discounting

The Operation Key in BL should be “Discount”.

Bills - Release R13.00 -Page 3 of 29 - (c) Temenos Systems 2013 05/07/2013

Inte r e s t C a lc ula tion

The interest calculation details are:

Bills - Release R13.00 -Page 4 of 29 - (c) Temenos Systems 2013 05/07/2013

Bills - Release R13.00 -Page 5 of 29 - (c) Temenos Systems 2013 05/07/2013

* No of Days as per the frequency defined (Daily / Monthly)

# No of times based on frequency

Discount Amount = Principal Amount – PV.Amount

For the above example, if the frequency is 10th of every month:

Bills - Release R13.00 -Page 6 of 29 - (c) Temenos Systems 2013 05/07/2013

The accounting entries, based on the operation, are:

Operation Type Discount

Operation Type Discount – Input

Operation Type Discount –Amortization

Operation Type Discount - Amortisation

Operation Type Discount –Maturity

Bills - Release R13.00 -Page 7 of 29 - (c) Temenos Systems 2013 05/07/2013

Operation Type Collateral –Input

Operation Type Collateral - Input

Operation Type Collateral-Maturity

Operation Type Collateral – Maturity

Operation Type Collection-INPUT

Operation Type Collection - Input

Operation Type Collection-MATURITY

Bills - Release R13.00 -Page 8 of 29 - (c) Temenos Systems 2013 05/07/2013

Operation Type – All

Charge collection Process at Input/Maturity

Operation Type - All

Bills - Release R13.00 -Page 9 of 29 - (c) Temenos Systems 2013 05/07/2013

Currency market for BL.BILL will be defaulted from BL.PARAMETER.

Ge ne r a l c onditions or r ule s for de fa ulting

Bills - Release R13.00 -Page 10 of 29 - (c) Temenos Systems 2013 05/07/2013

The rules for defaulting specific fields are explained below:

Fields; INTEREST.KEY, INT.SPREAD and INT.RATE

Fields: MAX.INT.RATE and MIN.INT.RATE

D e fa ult of Lia bility C us tom e r

In all other cases no value would be returned for LIABILITY.CUSTOMER.

Sy s te m Ma inta ine d File s

Bills - Release R13.00 -Page 11 of 29 - (c) Temenos Systems 2013 05/07/2013

Bills - Release R13.00 -Page 12 of 29 - (c) Temenos Systems 2013 05/07/2013

B L.B ILL.B ILL.R EG

Bills - Release R13.00 -Page 13 of 29 - (c) Temenos Systems 2013 05/07/2013

B L.B ILL.C U STOMER

Bills - Release R13.00 -Page 14 of 29 - (c) Temenos Systems 2013 05/07/2013

Move to History File

Bills - Release R13.00 -Page 15 of 29 - (c) Temenos Systems 2013 05/07/2013

The types of Bills handled by the Banks are:

l Collecting and crediting the customer

BL.PARAMETER (BP) (Module level Parameter File)

BL.TYPE (BT) (Bill Type Definition File)

APPL.GEN.CONDITION (Record Key: BL.BILL) [optional] (Bill Contract Group Definition)