9. Automatic Processes

This far we have seen the procedures involved in creating products and process bills. While processing a bill, you were provided with automatic options. The events that are to take place automatically are triggered off during the Batch Process. The Batch process is an automatic program, which is run as a mandatory Beginning of Day (BOD) and End of Day (EOD) process.

The Batch processes that are initiated either at the Beginning of Day (BOD) or End of Day (EOD) execute certain events on the days they fall due. To recall, while entering the details of a bill you were provided with the following automatic options:

The Batch program when run as part of the BOD, processes the automatic events that fall due today. It also processes the automatic events for a holiday previous to today (this however depends on the preferences stated in the Branch Parameters screen).

The Batch program when run as part of the EOD processes the automatic events that fall due today and the automatic events that should be processed for a holiday which falls on the next day (this, however depends on the preferences stated in the Branch Parameters screen).

Note

You should maintain EOD to be a mandatory batch process both as a BOD and a Pre-EOC program in the EOC mandatory program of the Core Services module of Oracle FLEX­CUBE.

This chapter contains the following sections:

9.1 Mandatory Batch Program Maintenance

This section contains the following topic:

9.1.1 Maintaining Bills Batch Process

Batches are run automatically. In the mandatory programs, all batches whichever are required will be maintained in sequence and that is triggered automatically as based on the maintenance in the ‘Mandatory Batch Program Maintenance’ screen.

You can invoke the ‘Mandatory Batch Program Maintenance’ screen by typing ‘EIDMANPE’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Module

Choose the module code from the adjoining option list.

Function Identification

Choose the function ID of batch that you wish to run. The adjoining option list displays all batch processes available for the module.

You can configure the batch to be run at various stages of day like EOD, EOTI etc.

For further details about this screen, refer the chapter ‘Setting- up Mandatory Programs for EOD’ in the AEOD User Manual.

 

9.2 Bills and Collections Branch Parameter Maintenance

This section contains the following topics:

9.2.1 Maintaining Branch Parameters

A set of rules that governs the processing of bills in a particular branch of your bank is defined in the ‘Bills & Collections Branch Parameter Maintenance’ screen.

You can invoke the ‘Bills & Collections Branch Parameter Maintenance’ screen by typing ‘BCDBRPRM’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

9.2.1.1 Specifying the Branch Details

Branch

Select the branch code from the option list provided. You can maintain branch parameters only from the respective branches. At the head office level you can alter branch parameters of other branches also.

Description

When you select branch code from the option list, the description of the same is defaulted here.

9.2.1.2 Specifying Batch Processing Preferences

The events, for which you had indicated automatic processing, are triggered off during the Batch Process. You can specify preferences for the automatic events that fall on a holiday in the Branch Parameters screen.

You can capture the following preferences here.

Process Till Next Working Day

If you indicate that the processing has to be done upto the next working day - 1, all the automatic events falling due on the holiday will be processed by the batch process as part of the EOD.

The batch process should process automatic events falling due on a holiday, on either of the following dates:

If you indicate that processing has to be done only upto the System Date by unchecking ‘Process Till Next Working Day’, then only the events scheduled for today (the last working day before the holiday) will be processed. The events of the holiday are processed by the batch process as part of the BOD process on the next working day.

For example, the current branch date is 20, October 1999. On 21, October 1999, which is a holiday, the following automatic events fall due:

Next working day - 1

If you specify that the processing should be done on the last working day - 1, the above events will be processed on 20 October as part of the batch process run at EOD.

System date

If you specify that the processing should be done only upto the system date by unchecking ‘Process Till Next Working Day, then the events scheduled for 21 October1999, will be processed as part of the Batch Process run as part of Beginning of Day on 22 October 1999.

Use User Reference No in Messages

If you wish to display the user reference number in the advices that are generated for a contract, select this option. All the advices generated at your branch will display the appropriate user reference number.

Note

You can specify a format for the generation of the User Reference Number in the ‘Se­quence Generation’ screen available in the Application Browser. Refer to the Core Servic­es User Manual for details on maintaining a sequence format.

Use Ultimate Parent User Reference for Child Contracts

If you wish to display the user reference number of the ultimate parent in the advices generated for child contracts, select this option. If this box is unchecked, the user reference number of the child is displayed for the child contracts.

Accrual Level

At the time of creating a product, you specified the following:

A bill will inherit the accrual frequency defined for the product associated with the contract. For bills, which are to be automatically liquidated, you can indicate the level up to which they should be accrued. The options available are:

If you indicate that automatic accrual should be done at the product level, a single entry for all contracts will be passed. However, if these contracts have moved into different user defined status, the accrual entries will be passed at the product level and for each user-defined status. This helps reduce the time taken to pass each entry. If you indicate that the automatic interest accrual process should pass accrual entries at the contract level, accrual entries will be passed for each of the contracts for which interest was accrued automatically.

For example, you have created a product - INB1 to cater to incoming bills.

The product has the following characteristics:

The accounting entries during interest accrual (defined for the event ACCR) are as follows:

Accounting Role

Accounting Head

Amount Item

Dr/Cr

INTEREST_RIA

INTLI01

Interest

Dr

INTEREST_INC

INTINC01

Interest

Cr

You have entered the following contracts using the product INB1:

The interest calculation method is 360/365

Contract

Tenor

Interest

Contract 1

3 months

US $300

Contract 2

6 months

US $500

Contract 3

12 months

US $1000

The accounts, into which the accrual entries should be passed, for each of these contracts, are the same as they are linked to the same product.

Accrual entries level - Product

If you indicate that the automatic interest accrual process should pass accrual entries at the product level, a single accrual entry for all the contracts will be passed.

Accrual entries level - Contract

If you indicate that the automatic interest accrual process should pass accrual entries at the contract level, three accounting entries for the contracts will be passed. You can view details of the individual accrual entries that were automatically passed by invoking the Accrual control journal report.

9.2.2 Specifying the User Defined Fields

You can link the User Defined Fields with Branch Parameters Maintenance screen using Function field mapping screen which can be invoked from the Application Browser by selecting User defined fields, and then Function field mapping.

The value for these fields can be specified in the Branch Parameters Maintenance screen. Value for UDF can be made mandatory or non mandatory as maintained in the Field description screen.

9.3 Processes Run during Beginning of Day (BOD)

This section contains the following topics:

9.3.1 Automatic Liquidation of Bills

The auto-liquidation function liquidates all the outstanding components of a Bill contract on the liquidation date specified for the bill. To recall, the liquidation date is calculated in the following manner:

Maturity Date = Base Date + tenor + transit days

This function will liquidate only active bills for which you have specified the liquidation method as automatic. The pertinent details of the bill with respect to tax, limits, interest and charges will be updated to indicate that the bill has been liquidated and authorized.

When run as part of the BOD process, the function automatically liquidates all the bills that have a liquidation date between the last working date and the current processing date.

When run as part of EOD the function liquidates those bills that was processed during the day and need to be liquidated as on the current day. If the next working day is a holiday, and you specified that in the branch parameters screen that holiday processing should be done upto the last working day - 1 such bills will be liquidated as part of the BOD run on the previous day.

If the option ‘Verify Funds’ is checked for the product, the system uses the debit settlement account to get the available balance including the OD limits during automatic liquidation of bills.

In case of reimbursement bills, if the funds in the account are insufficient for liquidation, the system triggers LIQF event and generates a message for the claiming bank and the issuing bank. This message needs to be configured for the LIQF event.

The system triggers the LIQF events as many times as the number specified in ’Auto Liquidation Retry Count’ in the ‘Product Preferences’ screen. When LIQF event is generated for the first time, MTN99 advice message is generated to issuing and claiming banks. During subsequent attempts, the system does not generate MTN99 to issuing and claiming banks.

On successful automatic liquidation of a bill, the system generates MT202 and MT900/MT940 to the issuing banks, if this has been configured at the product level.

In case of non-reimbursement bills, if the funds in the account are insufficient, the system does not process automatic liquidation. The system will attempt to liquidate the bill during the subsequent batches.

The bills falling due for liquidation on a holiday will be processed during End of Day on the last working day before the holiday.

9.3.1.1 Accounting Entries that are Passed

When a bill is automatically liquidated by the function the necessary accounting entries specified for the liquidation event (LIQD) will be booked and automatically authorized.

9.3.1.2 Accounting Entries Passed for a Status Change

If the liquidation of the bill involves a status change, the accounting entries defined for the status change event (STCH) of the bill will be automatically passed when the bill moves from one status to another. Further, if you have indicated the following:

9.3.1.3 Advices

The advices specified for the liquidation event (LIQD) for the product associated in the bill will be automatically generated.

9.3.1.4 Holiday Processing

If the liquidation of a bill falls due on a holiday, the liquidation will be done as per your holiday handling specifications for automatic processes, in the Branch Parameters screen.

9.3.1.5 Creation of Loan during Auto Liquidation

The system creates loans for the shortfall amount during auto liquidation of a bill contract. For such loan creation, the statuses of the following checkboxes are considered:

If you have checked the options ‘Advance by Loan’ and ‘Settle Available Amount’, the bill contract is liquidated as given below:

If you have checked the option ‘Liquidate Using Collateral’ along with ‘Advance by Loan’ and ‘Settle Available Amount’, the bills contract is liquidated as given below.

If you have checked the options ‘Liquidate Using Collateral’ and ‘Advance by Loan’ and not checked the option ‘Settle Available Amount’, the bill contract is liquidated as given below:

Now, suppose that you have checked the option ‘Advance by Loan’. At the same time, the options ‘Settle Available Amount’ and ‘Liquidate Using Collateral’ are not checked. In that case the system creates a loan for the entire bill outstanding amount without checking any of the available balances.

For example, consider a bill for an amount of GBP 10000. The following checkboxes are checked.

The properties of the collateral and the customer account balance are given below:

Collateral : GBP 3000

Customer Account Balance : GBP 4000

While liquidating, initially, the system recovers GBP 3000 from the collateral. Further GBP 4000 is debited from the customer account. These amounts together settle GBP 7000 of the total bill amount of GBP 10000. For the remaining GBP 3000, the system creates a loan.

The system passes the following accounting entries on liquidation:

Account

Debit/Credit

Amount

Collateral A/c

Dr

3000

Nostro A/c

Cr

3000

Customer A/c

Dr

4000

Nostro A/c

Cr

4000

Loan Bridge GL

Dr

3000

Nostro A/c

Cr

3000

9.3.2 Tracer Generation

You specified the tracers that should be generated for a bill in the Bills - Contract Exceptions screen. This function triggers the generation of tracers specified for active authorized bills on the day they fall due. Tracers can be triggered for generation as part of BOD, EOD or can be invoked at any time during the day. This function is available in the Application Browser through Bills & Collections and Batch under it. The date on which a tracer should be generated for a bill is determined by the entries you made to the fields of the Contract Exceptions screen.

The following tracers will be generated by the function:

9.3.2.1 Advices

An advice of fate of the bill is generated whenever the corresponding tracer for the exception is generated.

9.3.3 Automatic Accrual of Interest

While defining interest components for a bill product in the Product, ICCF details screen, you specified whether accruals need to be done for the accruable interest components. For a product, accruals should be done, then the frequency of accrual should also be specified for a product (through the Product Preferences screen, at the time of product definition).

This function when run as part of the batch process run at EOD, calculates the accrual amount and passes accrual accounting entries for the accruable tenor based interest components of a bill.

The Automatic Accrual function will pick up bills for processing on the following criterion:

The date on which accrual is due for a bill is calculated based on the accrual date and accrual frequency defined for the product associated with the bill.

When the function automatically accrues the interest components of a bill, is done the accounting entries defined for the accrual event (ACCR) will be passed and the internal accounts will be updated with the accrual related details.

If the accrual date of a bill falls on a holiday, the accruals are done as per your holiday handling specifications for automatic processes, in the Branch Parameters screen.

The list of bills whose commission components were accrued will be printed in the Accrual Control report.

Note

This function will not accrue interest for bills that have moved into a user defined status for which accruals have been stopped.

9.3.4 Automatic Status Changes

A bill that is yet to reach its repayment date is considered as having an Active status. When repayment against the bill is not made on the due date, you may want to do an aging analysis of the bill.

A forward status change is one in which a bill moves from a given user defined status to another in the forward direction.

A reverse status change is one in which the status of a bill changes from a given status to the previous status defined for the bill. Such a situation arises when a payment is made on a bill whose status is not active.

This function will automatically pickup and move bills from one user defined status to another (either forward or reverse) only if the bill matches the following criterion:

If you specify that forward or reverse status changes have to be carried out automatically, the status changes will be carried out automatically when the Contract Status Change Processing function is run either as part of BOD or EOD on the day the status change falls due.

9.3.4.1 Accounting Entries that are Passed

The accounting entries defined for the status change event (STCH) of the bill will be automatically passed when the bill moves from one status to another. Further, if you have indicated:

9.3.4.2 Advices that are Generated

The advices will be automatically triggered for generation to notify the customer about the status change. They would possible urge the party to pay the amount due and liquidate the aging components of the bill.

9.3.4.3 Holiday Processing

If the day on which the forward or reverse status change is due happens to be a holiday, then, the processing of such bills will depend on your specifications in the Branch Parameters screen.

If you specify that the forward or reverse changes should not be carried out automatically, the status remains unchanged (even if repayment is made on the bill) till you specifically change it for a bill. You can manually change the status of a bill through the Bills - Contract Details screen.

9.3.5 Floating Rate Change

While defining Floating Rates, you have the option of indicating whether the floating rates should automatically be applied to the bill every time they change, in the Product ICCF screen.

The Automatic Floating Rate Change function can be run as part of EOD. It can also be invoked from the Application Browser at any time during the day. This function is available in the Application Browser under Bills & Collections and Batch under it.

This function will pick up:

Every time the Floating rates change, the new rates will be applied for the number of days for which they remained unchanged in the rate table.

This is indicated in the example below.

The rates in the floating rate table change in the following manner:

Effective Date

Rate

1 October 1999

12%

12 October 1999

11.5%

25 October 1999

11%

15 October 1999

12%

30 October 1999

12.5%

The rates will be applied for the number of days for which they remain unchanged in the rate table, as follows:

From

To

Rate

1 October 1999

11 October 1999

12%

12 October 1999

24 October 1999

11.5%

25 October 1999

31 October 1999

11%

You have entered a bill, which has a Base Date as 1 October 1999 and matures on 30 November 1999. The interest accrual frequency is to be monthly. The bill has been linked to a floating interest rate.

If the first interest accrual is to be done on 31 October, all the rate changes between 1 October and 31 October will be considered automatically.

9.4 Status Change Batch

This section contains the following topics:

9.4.1 Processing Status Change Batch (CSDSTBTC)

For the BC module the Status change batch will be run along with the customer/Group and apply worst status change for the customer. This batch will use the status change events.

You can trigger the batches to run before the Common Status Change batch (CSDSTBTC). The following given batches can be run in any order:

If ‘Status Processing’ is at Individual Contract Level, then system will trigger status change based on the Customer Credit rating for the customer of the Contract /Account booked. The other contracts of the customers in the same Group will not be impacted. However if the ‘Status Processing’ is at CIF/Group level individual module (LC,CL, CI, MO, CA, IA and BC) batches will be updating common storage with the derived status of each contract and CIF/Group level status will be triggered by the common status change batch. The common status change batch will call the individual module function for status change processing.

9.4.2 Changing from Acceptance to Advance Automatically

To recall, while defining preferences for a product, you have the option to indicate whether the movement of a bill from acceptance to advance should be done automatically or manually. This preference that you state for a product will be inherited by all the bills linked to the product.

The Automatic Change from Acceptance to Advance function can be run as part of EOD or can be invoked from the Application Browser at any time in the day. This function is available in the Application Browser under Bills & Collections and Batch under it.

This function, will pick up for processing, only bills which are:

On moving a bill from acceptance to advance, the accounting entries passed for the event Change from Acceptance to Advance (BADV) will be automatically passed.

9.4.3 Generating Advices Automatically

In this screen, you can indicate whether reimbursement claims should be generated for the bills.

You can automatically generate a Reimbursement Claim (MT 742) for export bills under LCs (with deferred payment). To achieve this, you must specify the ‘Reimbursement Days’ for a bill in the Contract Online screen. The Reimbursement Claim for the bill will be automatically generated depending on the ‘Reimbursement Days’ prior to the Maturity Date.

For example, the Maturity Date of a bill is 23 March 2001. You specify the Reimbursement Days as ‘2’. Two working days prior to the Maturity Date (that is, 21 March 2001), as part of the BOD process, the Reimbursement Claim (MT 742) for the bill will be automatically generated.

9.5 Straight through Processing of SWIFT Messages

This section contains the following topics:

9.5.1 STP SWIFT Messages

The SWIFT messages that you receive are either uploaded into Oracle FLEXCUBE as new BC contracts or they trigger changes (events) to the existing BC contracts. The message upload process takes one message at a time and applies a sequence of logical steps to derive information required to derive the BC contract upload tables.

Refer the ‘STP’ chapter of the ‘Funds Transfer’ User Manual for more information on maintenances required for straight through processing of SWIFT messages.

The various SWIFT messages supported in Oracle FLEXCUBE are listed below:

The Straight Through Processing (STP) of each of the above messages is discussed in the following sections.

As part of STP processing, for some of the messages, Generated Reference Number needs to be updated in the Incoming message data source with Contract Reference Number. They are:

For MT202 the value in tag 21 is updated as Generated reference Number.

The Generated Reference Number is not updated automatically for the following messages:

Note

If the above messages are processed successfully, then the processed contract reference number is updated as Generated Reference Number.

9.5.2 STP of MT202 and MT203

As part of STP for MT202, if you check ‘Liquidate Bill on Incoming MT202’ option in the ‘Bills and Collections Branch Parameter Maintenance’ screen, system will do a validation to check if any Export Bill Contract exists for the reference number in the field 21 in 202. System checks the value in field 21 against the Contract Reference Number first. In case the Contract Reference Number does not exist, system will check the User Reference Number.

If a contract exists, which is already liquidated, the ‘Status’ & the ‘Process Status’ will be updated with ‘Repair’. If a contract exists and not liquidated and if the Bill amount matches with the amount in the message, system will try to liquidate the Bill Contract. In case of failure, system displays an appropriate error message and the ‘Status’ will be updated to ‘L’ (Pending Liquidation) while the ‘Process Status’ will be updated as ‘R’ (Repair). If the Bill is liquidated successfully, then system updates the ‘Status’ and the ‘Process Status’ as ‘P’. The Generated Ref No is updated with the Bill Contract Ref No. You can view the status and the generated reference number in ‘Incoming Message Browser’ screen for the respective DCN.

For further information on ‘Incoming Message Browser’ screen, refer ‘Manual Processing of Incoming Messages’ section in the ‘Processing Incoming Messages‘ chapter in the ‘Messaging System’ User Manual.

Once the Bill is liquidated successfully and the status of the message is marked as ‘P’, any change in the contract like deletion or cancellation will not impact the message that triggered the Liquidation.

System checks the following mismatch between the Bill amount and the amount in the message:

If the Bill is liquidated successfully, if the flag ‘Auto Authorize liquidated bill’ in the ‘Bills and Collections Branch Parameter Maintenance’ screen is ‘Yes’, then the liquidation will be authorized automatically otherwise, post liquidation, the contract will be in Unauthorized status.

For further information on ‘Bills and Collections Branch Parameter Maintenance’ screen, refer ‘Maintaining Branch Parameters for Bills and Collections’ section in the ‘Maintenance‘ chapter in the ‘Bills and Collections’ User Manual.

If the Bill liquidation process is failed and if the status is ‘L’, then you will have to liquidate the Bill manually by suppressing the message. As part of Bill liquidation, the Value date (32A) will be considered for the Credit Value date & Debit Value date of the contract.

System picks up the records with ‘R’ (Repair) in ‘Process Status’ and tries reprocessing the same. In case of Trade Related MT202 message (where the ‘Status’ is ‘L’), then system will not check again if it is a Trade Related MTM202. System will directly try liquidating the underlying Bill contract.

System creates multiple 202 messages on receiving MT203. The above validation is done for all the MT202 messages created out of single MT203.

9.5.3 STP of MT754 - Advice of Payment/Acceptance/Negotiation

Using the bills upload utility, the system automatically books an import bill under payment. The relevant product is derived based on the mapping maintained for the message type and product combination in the ‘Product Mapping Detailed’ screen in order to process the import bill created as a result of the incoming MT754 (Advice of Payment/Acceptance/Negotiation). The bills contract that is generated inherits the following details from the underlying LC:

Tenor Details for the Bill

The system picks the following tenor details for the bills contract, from the product maintenance:

Document Related Details for the Bill

The following details will be blank for the bills contract:

Nostro Account for the Bill

The system uses the SWIFT tags 53, 57 and 58 to derive the Nostro account in the following manner:

The system checks for the following during STP:

The system creates an authorized or unauthorized contract based on the ‘Post Upload Status’ maintained through the ‘Upload Source Preferences’ screen.

You need to maintain the following entries for INIT (initiation) event in order to pass accounting entries for ‘Their Charges’:

Dr/Cr

Accounting Role

Amount Tag

Netting

Dr

BC CUSTOMER

THEIR_CHG

Yes

Cr

NOSTRO ACCOUNT

THEIR_CH­G_EQUIV

 

Dr

NOSTRO ACCOUNT

BILL_AMOUNT

 

Cr

BC CUSTOMER

BILL_ AMT_EQUIV

Yes

The system maps the SWIFT tags in MT754 and the fields in BC contract as depicted below:

Status

Tag

Description

Oracle FLEXCUBE Fields

Remarks

M

20

Senders reference

Their LC refer­ence

 

M

21

Related reference

Our LC reference

 

M

32A or B

Principal Paid/Accepted/Negotiated

Bill Amount

This amount is deducted from out­standing bal­ance of LC.

O

33B

Additional amounts

FFT

 

O

71B

Charges deducted

FFT

 

O

73

Charges added

FFT

 

O

34A or B

Total amount claimed

Their charges

Difference of 34 and 32

O

53A, B or D

Reimbursing bank

 

 

O

57A, B or D

Account with bank

 

 

O

58A or D

Beneficiary bank

 

 

O

72

Sender to receiver informa­tion

FFT

 

O

77A

Narrative

FFT

 

9.5.4 STP of MT400 – Advice of Payment

STP of MT400 results in liquidation of the sight/usance bill (only for collections). The system derives the contract reference number in the following manner:

The system rejects the incoming record in the following cases:

The following mappings are maintained between SWIFT tags in MT400 and the fields in BC contracts:

Status

Tag

Description

Fields of Export Bill

Remarks

M

20

Sender’s reference

-

 

M

21

Related reference

Contract reference

 

M

32A,B or K

Amount collected

Liquidation Bill Amt

 

M

33A

Proceeds remitted

Their charges

Difference of 32 and 33

O

52A or D

Ordering bank

 

 

O

53A,B or D

Sender’s correspondent

 

 

O

54A,B or D

Receiver’s correspondent

 

 

O

57A or D

Account with bank

 

 

O

58A,B or D

Beneficiary bank

 

 

O

71B

Details of charges (Deduc­tions)

FFT

 

O

72

Sender to receiver information

FFT

 

O

73

Details of amount added

FFT

 

As a result of the STP of the incoming MT400, the system creates a new version of the bills contract and also triggers the liquidation event (LIQD) for the contract. All the information in the following fields is stored as Free Format Text as under:

Field

FFT Code

Advice

72

SNDRRCVRINFO

PAYMENT_ADVICE

71B

71CHGTOBEDED

PAYMENT_ADVICE

73

73CHGTOBEADD

PAYMENT_ADVICE

The system updates the following fields in the BC contract based on Field 72:

72 Field Value

BC Contract

ALCHAREF

Our charges refused and Their charges refused should be checked

OUCHAREF

Our charges refused should be checked

UCHAREF

Their charges refused should be checked

9.5.4.1 Deriving the Debit Account

System utilizes the following SWIFT tags to derive the debit account from the settlement instructions sequentially:

In case the system does not find any of the three tags, it derives the debit account from the BIC of the sender of the message. The system then updates the tags 52, 53, 54, 57 and 58 in the settlement subsystem maintained for the Nostro account.

STP of MT400 results in authorized or unauthorized liquidation record based on the post upload status you have maintained in the ‘Upload Source Preferences’ screen.

When an MT400 message is being uploaded, the system checks for the following:

9.5.5 STP of MT410 (Acknowledgement Received)

SWIFT upload of MT410 records acknowledgement details in the contract screen. Note that acknowledgement is supported only for collections. The system fetches the contract reference number of the bill contract from field 21 of the message. If the contract reference number is not found, the system will look for the user reference number in field 21. If field 21 has the value ‘NONREF’ then the system will fetch the bill reference using their reference (field 20) from the ‘Bills and Collections Contract Input - Parties’ details. The BIC of the sender will be used for identifying the party for which their reference needs to be fetched. If the customer number for the BIC is null then the system will check whether the party type is collecting bank. If both contract reference number and user reference number are not found, the system will fetch the value in ‘Our LC Reference’ in field 21.

The system will reject the record if any one of the following is true:

If the message has got a repetitive sequence and the same reference number is mentioned in both tag 21 then the message will be sent to repair.

The system creates a new version of a bills contract from an incoming MT410. During STP of MT410, the system checks the ‘Acknowledgement Received’ box in the ‘Bills and Collections Contract Input’ screen. It updates the application date in the field ‘Acknowledgement Date’ and then triggers the event ‘ACKB’.

The system stores the information in field 72 as Free Format Text with the FFT code ‘SNDRRCVRINFO’ for the message type ‘ACKNOWLEDGEMENT’.

STP of MT410 creates an authorized or unauthorized amendment record based on the post upload status maintained in the ‘Upload Source Preferences’ screen.

When an MT410 message is being uploaded, the system triggers the ‘ACKB’ event and checks the following:

9.5.6 STP of MT430 – Amendment of Instructions

MT430 is sent by the remitting bank to the collecting bank or by the collection bank to any other collection bank. Upload of MT430 triggers amendment of the bill contract. Note that upload is supported only for collections. In order to derive the contract reference number on which action needs to be triggered, the system first fetches the contract reference number of the bill contract using field 21 of the message. If the reference is not found, then the system will fetch the bill reference using the user reference number in field 21. If the reference too is not found, then the system will fetch the bill reference using our LC reference in field 21. If field 21 has the value ‘NONREF’, the system will fetch the bill reference using the ‘Their reference’ (field 20) from the ‘Bills and Collections Contract Input – Parties’ screen. The BIC of the sender will be used for identifying the party for which their reference needs to be fetched. If the reference is not found, then the system will fetch the bill reference using their LC reference (field 21). The new maturity date and bill amount are fetched from fields 33A or 33K. The value date of the amendment is always the application date.

The system will reject the record if any one of the following is true:

If the message has got a repetitive sequence and the same reference number is mentioned in both tag 21 then the message will be sent to repair.

All the information in the following fields is stored as Free Format Text as under:

Field

FFT Code

Advice

72

SNDRRCVRINFO

AMNDMNT_OF_INS

74

INSTRUCTIONS

AMNDMNT_OF_INS

The system creates a new version of bill after amendment upload.

During STP processing of MT430 if the underlying contract is in Initial stage then amendment of the bill is done as normal and if it is in Final stage then the rebate amount is populated.

STP of MT430 results in authorized or unauthorized liquidation record based on the post upload status you have maintained in the ‘Upload Source Preferences’ screen.

9.5.7 STP of MT742 – Reimbursement Claim

While processing MT742, initially, the system picks up Tag 21 of MT742 and checks if a valid LC contract is maintained. The LC contract is created only if the corresponding MT740 has been received. An MT742 received before MT740 and one received after MT740 are processed differently.

The system verifies whether the claim amount in MT742 is greater than the available amount in the underlying LC contract. If the amount is greater, the message will be placed in ‘Pending Auth Receipt’ status with the repair reason ‘BC-FUND-NA’.

STP of MT742 generates bills contract in the ‘FINAL’ stage with the following attributes:

While booking the import bill from an incoming MT742, the following details are inherited from the underlying LC as per (field 21):

The tenor details of the bills contract are picked up as shown below:

Values from the above mentioned fields are updated in the settlement message details of the Nostro account leg having the amount tag ‘BILL_AMOUNT’ or ‘BILL_AMT_EQIV’. Value of field 33B is stored as an FFT with FFT code ‘33ADDAMTCLMD’ under the message type ‘REIM_PAY_ADV’.

The system checks for the following during STP of MT742:

In case MT742 is received before MT740, the underlying LC contract will not be available in the system. In such instances, the system will place the MT742 in ‘Pending Auth Receipt’ status.

The STP process creates an authorized or unauthorized import bill based on the post upload status maintained in the ‘Upload Source Preferences’ screen.

9.5.8 Deriving Maturity Date of Bills

If the LC value date is not available in the incoming MT742, the system automatically computes the maturity date based on the parameter days maintained in ‘Bills and Collections Product Preference’ screen. The message MT742 is considered to be received as of the branch date. The system will then add the number of parameter days to the receipt date and derive the maturity date of the Bill.

If the value date is available in MT742, the system extracts it from 34A and considers that as the maturity date of the Bill. In case Bill is marked for auto liquidation, system uses the maturity date as the liquidation date as well. However, you can modify the liquidation date of the Bill.

Once a bill is created successfully, the system generates REIM_PRE_ADV as part of INIT event.

If the value date mentioned in MT742 is the current system date or a date in the past, automatic liquidation will not take place. The Bill will be liquidated as part of EOD processes. However, you can manually liquidate the Bill if required.

In case of manual input of Bills contract for MT742 received through any media, you need to manually choose the LC contract from the system. If the LC is not available in the system, you have to manually generate MTN99 for claiming and issuing banks.

During manual liquidation of a bills contract, if the funds are insufficient, the system displays an override based on which the system user has to decide whether to go ahead with liquidation or not.

9.6 Receivable Liquidation (LQ) EOD Batch

This section contains the following topic:

9.6.1 Processing LQ EOD Batch

In case of Receivable Liquidation (LQ) EOD batch, system checks for the following: