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 FLEXCUBE.
This chapter contains the following sections:
This section contains the following topic:
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.
This section contains the following topics:
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.
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.
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 ‘Sequence Generation’ screen available in the Application Browser. Refer to the Core Services 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.
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.
This section contains the following topics:
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.
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.
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:
The advices specified for the liquidation event (LIQD) for the product associated in the bill will be automatically generated.
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.
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 |
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:
An advice of fate of the bill is generated whenever the corresponding tracer for the exception is generated.
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.
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.
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 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.
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.
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.
This section contains the following topics:
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.
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.
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.
This section contains the following topics:
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.
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.
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_CHG_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 reference |
|
M |
21 |
Related reference |
Our LC reference |
|
M |
32A or B |
Principal Paid/Accepted/Negotiated |
Bill Amount |
This amount is deducted from outstanding balance 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 information |
FFT |
|
O |
77A |
Narrative |
FFT |
|
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 (Deductions) |
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 |
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:
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:
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.
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.
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.
This section contains the following topic:
In case of Receivable Liquidation (LQ) EOD batch, system checks for the following: