The following processes relating to the LC Module can be made automatic:
The events that are to take place automatically are triggered off during the Batch Process. The batch process is an automatic function, run as a mandatory Beginning of Day (BOD) and End of Day (EOD) process. During EOD, the batch process should be run after End of Transaction Input (EOTI) has been marked for the day, but before End of Financial Input (EOFI) has been marked for the day. The tracer generation function should be run after end-of-financial-input (EOFI) has been marked for the day.
Note
You should maintain the LC EOD function as a mandatory batch process, once as a BOD and the next as a Pre-EOC program. It is maintained in the EOC mandatory programs table of the Core Services module. The tracer generation function should also be defined as a mandatory EOD function.
The contracts that will be processed by the batch processes depend on the definition in the Branch Parameters screen.
This section contains the following details:
A set of rules that govern the LCs processed through the LC module, in a particular branch of your bank, is defined in the ‘Branch Parameters’ screen.
From the Application Browser, choose ‘Letters Of Credit’ and ‘Branch Parameters’ under it.
You can also invoke this screen by typing ‘LCDBRPRM’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button. Then, the ‘Letters of Credit - Branch Parameters’ screen will be displayed.
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. In addition, you can also specify the level at which accrual entries should be passed, for LCs in your branch.
Specifying Preferences for the Automatic Processing of LCs
You have the option to specify, that the batch process should process automatic events falling due on a holiday should.
The same can be processed on either of the following ways:
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 on the last working day, before the holiday.
If you indicate that processing has to be done only upto the System Date, then only the events scheduled for today (the last working day before the holiday) will be processed. The events falling due on the holiday are processed by the batch process, as part of the BOD process, the first working day after the holiday.
For example the current branch date is 20 March 1998. On 21 March 1998, 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 March 20, as part of the batch process run at End of Day.
System date
If you specify that the processing should be done only upto the system date, then the events scheduled for 21 March 1998, will be processed as part of the Batch Process run as part of Beginning of Day on 22 March 1998.
Indicating whether User Reference Number should be Displayed
in the Advices Generated
If you wish to display the user reference number in the advices that are generated for a contract, select the ‘Use user reference no in messages’ 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.
Specifying the Level at which Accrual Entries should be Passed
At the time of creating a product, you have specified
An LC will inherit the accrual frequency defined for the product under which it is processed.
In the Branch Parameters screen, you indicate the level at which the accrual entries have to be passed. The level can be:
If you indicate that automatic accrual should be done at the product level, a single entry for all the LCs, for which commission was accrued automatically, will be passed. This helps reduce the time taken to pass individual entries. If you indicate that the automatic commission accrual process should pass accrual entries at the contract level, accrual entries will be passed for each LC for which commission was accrued automatically.
Specifying the Discrepancy Notice Period
Discrepancies are likely to be found while processing Incoming or Outgoing bills under LCs. You can specify a period within which the discrepancy details should be added to the bills. This period will be calculated from the date of presentation of the bills (which is typically the booking date of the bill) to the issuing bank/confirming bank.
The system will display an override if the discrepancies are added to the bills (in the ‘Bills – Contract Details’ screen) after the discrepancy notice period.
For details on processing a bills contract, refer the ‘Processing Bills’ chapter of the BC (Bills and Collections) User Manual.
Validate Message Generation on Save
Specify this option to indicate Validate Message generation on contract save.
If Validate Message Generation flag is checked:
If flag is unchecked:
Message generation validation during contract save for conventional screens will be provided to the following screens:
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 this 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. Select the appropriate one. 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.
The Batch program when run as part of BOD processes the following events:
The periodic commission components of an LC will be automatically liquidated, if the commission components fall due on or before the current system date. As a part of BOD, this function liquidates the commission components of the LC contracts, whose commission liquidation date is between the last working date and the current processing date.
The commission components that are liquidated by this function are posted to the accounts specified, in the settlements screen of the LC. This may be a customer’s account or a receivable account. On liquidation of the commission components of an LC by the function:
If collected in arrears:
Role |
Role Description |
Amount Tag |
Dr/ Cr |
COMM_CUST_ACC |
Customer account |
Commission |
Dr |
CENC |
Commission Earned Not Collected |
Commission |
Cr |
If collected in advance:
Role |
Role Description |
Amount Tag |
Dr/ Cr |
COMM_CUST_ACC |
Customer account |
Accrual amount |
Dr |
COMM_RIA |
Commission Received in Advance |
Accrual amount |
Cr |
As a part of EOD, this function liquidates the commission components of all the LC contracts, for which commission liquidation date falls between the current processing date and the next working date.
If the next working day happens to fall in the next month, this function will pick up only those contracts whose commission liquidation date, falls within the current processing month.
The following reports will be generated when the commission components of the LC, are automatically liquidated:
All LC contracts, for which you had specified automatic reinstatement, will be reinstated when the batch process for the day, is run as part of BOD.
The revolving details specified for the LC, in the Contract Main screen, are used to reinstate the contracts. The reinstatement is done subject to the Maximum Liability and the Maximum LC Amount allowed for the contract. The unutilized credit is removed from the contingent entries for non-cumulative LCs.
For LCs that revolve in time, the LC Amount and the Maximum Liability Amount is reset based on the frequency of reinstatement (the value of frequency can be either Days or Months depending on the ‘Units’ you specify for the contract). In the case of an LC, which revolves in value, the LC amount is reset when the current availability under the LC is reduced to zero. Thus, the reinstatement for LCs which revolve in value is done during beginning of day on the next day. It is done after the availment that makes the current availability to zero is made.
When LCs are automatically reinstated, the necessary accounting entries and advices specified for the event code REIN (reinstatement), will be passed automatically.
As a part of the BOD process, this function reinstates all the revolving LCs (specified with automatic reinstatement), which needs to be reinstated. This is determined by two factors:
During EOD, the auto reinstatements scheduled for the next day will be done under the following conditions:
All contracts that were automatically reinstated on a day, will appear in the Activity Report for the day. The exceptions encountered during the reinstatement i.e. the contracts, which should have got reinstated, but were not, will figure in the Exception Report.
The Batch program when run as part of EOD processes the following events:
All LC contracts for which you had specified automatic closure and which are due for closure as of today, will be automatically closed when the batch processes for the day is run. The accounting entries specified for the closure will be passed.
If an LC is linked to an open insurance policy for which the option ‘Update utilization Automatically’ is checked, then on this date, the system will decrease the utilization on the policy with the LC amount.
If the ‘Auto Closure’ check box is checked at the contract level, then system will close those contracts. If the ‘Allow Partial Closure’ option is checked at the branch level, then system does the following processing as part of the Closure Batch:
For example, an LC of USD 1000 is created.
A Bill of USD 700 is created in Initial stage by linking the above LC.
The system initiates the automatic partial closure process after the expiry of the number of partial closure days specified in ‘Letters of Credit Branch Parameters Maintenance’ screen. As a part of the closure batch (if the new branch level flag is checked), the system releases the limits, OS liability and cash collateral for USD 300 by retaining USD 700 assuming that the Bill to which the LC is linked will be availed at the later stage
Once PCLS event is fired for an LC contract, system does not allow any operation on the LC other than LC Closure (CLOS). You can reopen the closed LC as existing. While reopening the LCs for which PCLS has fired earlier, the Limits will be tracked, OS Liability and Cash collateral will be increased to the extent of the amount released as part of PCLS. In the above example, Limits will be tracked for USD 300 and the OS Liability and Cash collateral will be increased for USD 300.
After PCLS is fired on the LC contract, if the Bill contract to which the LC is linked is reversed, the Limits, OS Liability and the Cash Collateral will not be released automatically. You have to manually close the LC.
System does not release the linkages to the LC automatically, as part of PCLS firing during batch. This has released manually as part of manual partial closure. The above processes are skipped for the LC contracts under the product for which the ‘Revolving’ is ‘Yes’. System manually handles the generation of MT799.
In case of a partially confirmed export LC contract, the system excludes the bill amount in the initial stage from the confirmed and unconfirmed portions.
For example consider an export LC with the following details:
LC Amount : GBP 10000
Confirmed Amount : GBP 7000
Unconfirmed Amount : GBP 3000
By linking this LC, a bill of GBP 2000 has been created at Initial stage.
During partial closure, the system releases the liability, limits and cash collateral for GBP 8000. The amount of GBP 2000 is retained as the bill to which the LC is linked may be availed at a later stage.
The system passes the following entries on PCLS:
Dr/ Cr |
Account Role Code |
Amount Tag |
LCY Amount |
LCY Amount Description |
Dr |
LC_OCU_OFFSET (Unutilized Credit Offset) |
UCNF_LIAB_OS_AMT |
3000 |
Unconfirmed LC Amount |
Cr |
LC_OCU (Outstanding Credit Unutilized) |
UCNF_LIAB_OS_AMT |
3000 |
Unconfirmed LC Amount |
Dr |
LC_CNF_OFF (Confirmation of LC Offset) |
CNF_LIAB_OS_AMT |
5000 |
Confirmed LC Amount |
Cr |
LC_CNF (Confirmation of LC) |
CNF_LIAB_OS_AMT |
5000 |
Confirmed LC Amount |
When the bill is booked in the final stage, AVAL event is triggered. The system initially considers the confirmed portion on AVAL event.
The bill amount in initial stage, GBP 2000, will be excluded from the confirmed portion. The remaining GBP 5000 will released. On the unconfirmed portion, the entire amount of GBP 3000 will be released.
During EOD operations, the status update batch automatically processes status changes of LC contracts. The batch examines the contracts for the status of the checkbox ‘Auto Status Change’. If this box is checked, the batch processes status update and derives the new status based on the defined rules. The field ‘Derived Status’ on the contract screen is updated with the new status.
Once the LC status is updated, the system posts the entries related to status processing as part of LCEOD batch. If the status processing basis is set as Branch or CIF at the branch level, the entries are posted as part of Group Level Status Change batch.
If status processing basis is set as ‘Contract’ at the branch level, the system performs one of the following actions:
For the LC 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.
When the batch process is run as part of EOD, the commission components of the active (authorized and not yet liquidated) LC contracts will be accrued. Accrual is usually performed from the last liquidation date to the current date. Since commission is calculated for rounded periods, the final accrual on the expiry date will be for the full rounded period.
When the accrual is done, the relevant accounting entries for the accrued components will be passed. The internal accounts will be updated with the accrual related details.
Typical accounting entries that are passed include:
If collected in Arrears
Role |
Role description |
Role Type |
Amount Tag |
Dr/ Cr |
CENC |
Commission earned not collected. |
Asset |
Accrual amount |
Dr |
COMM_INC |
Commission earned |
P&L |
Accrual amount |
Cr |
If collected in Advance
Role |
Role description |
Role Type |
Amount Tag |
Dr/ Cr |
COMM_RIA |
Commission received in advance. |
Asset |
Accrual amount |
Dr |
COMM_INC |
Commission earned |
P&L |
Accrual amount |
Cr |
The level at which accrual entries are passed depends on your definition of branch parameters. To recall, the accrual entries can be configured to be passed either at the contract level or the product level.
Either way, the details of accruals for each contract will be available in the Accrual Control List. The details of this report, the procedure for generation and the contents are discussed in the chapter on Reports.
The memo accrual function does not generate any accounting entries nor does it mark the contracts as accrued. It only computes the accrual amount as it would be computed for a regular accrual and reports the accrued figures, without updating the accrual and P&L accounts. The commission accrued by the function, is reported in the Memo Accrual Control report. The content of this report is the same as that of the Accrual Control report.
The accrual control report lists the LCs for which accrual entries were passed as of the current date.
You can configure this report to be triggered automatically, as part of the batch processes run at EOD. The report can also be generated at any time in the day from the Reports menu. If the report is generated as part of EOD, the report will by default list the details of the accruals that were made, as of the last accrual date.
If you generate the report from the Reports menu, you can indicate the date for which, you want details of LCs for which commission was accrued. You can also indicate the type of accrual for which you want details. The options available are:
Actual
The actual accrual report will contain details of the actual accrual entries that were passed as of the date you have indicated.
Memo
The memo accrual report just gives the details of the accruals due to an LC, as of a particular date. This will be a projected figure, without the actual accounting entries for accruals being passed. The memo accrual control report can be generated only after you run the memo accrual function.
The report options that you select while generating the report are printed at the beginning of the report. The contents of the report are discussed under the following heads:
Header
The Header carries the title of the Report, information on the user who generated the report, the branch code, the date and time and the page number of the report.
Body of the Report
The report contains the following details:
Fields |
Description |
Contract Ref No |
This is the reference number of the LC to which the accrual details are related. |
Component |
This is the commission component that has been accrued. |
CCY |
This is the currency of the commission component. |
Current accrued amount |
This is the amount that was accrued for the component, on the last accrual date. |
Amount accrued to date accrued amount |
This is the total amount that has been accrued, for the component, till date. |
For an LC, the following types of tracers can be generated:
These tracers are generated at a frequency, specified for the LC. On the day they have to be generated, the EOD processing: Tracer generation function will generate them. This function should be run after the End of Financial Input (EOFI) has been marked for the day.
This function should be run after the end-of-financial-input (EOFI) has been marked for the day. After the successful completion of the function, the tracers will be put in the ungenerated directory of the Outgoing Message Browser. You should generate them from there.
Oracle FLEXCUBE supports Straight through Processing (STP) of the following messages:
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.
The MT710 is sent by the ‘Advising Bank’ that has received a documentary credit (MT700) from the ‘Issuing Bank’. The message is sent to the ‘Advise thru Bank’ (bank advising the beneficiary) and is used to advise the receiver about the terms and conditions of a documentary credit.
You can upload the incoming MT710 as export LCs in Oracle FLEXCUBE. The following table lists the mapping that should exist between the SWIFT tags in MT710 and the fields in the LC Contract screen:
Status |
Tag value |
Description |
Oracle FLEXCUBE field value |
Remarks |
M |
27 |
Sequence of Total |
|
This field identifies whether MT711 is sent as part of MT710. |
M |
40B |
Form of Documentary Credit |
Transferable |
The different tag values for this field and the corresponding FCC field value is given in ‘Table A’. |
M |
20 |
Senders Reference |
Their Reference for party ‘ABK’ |
|
M |
21 |
Documentary Credit Number |
Their Reference for party ‘ISB’ |
|
M |
31C |
Date of issue |
Issue date and effective date |
|
M |
31D |
Date and place of expiry |
Expiry date and Expiry place |
|
M |
52A or D |
Issuing bank |
Party details of ISB |
The party details will be fetched using BIC code if 52A is present else the party details needs to be fetched using D to A converter. In case counterparty is not found then ‘Walk-in customer’ will be used. |
O |
51A or D |
Applicant bank |
Party details of APB |
The party details will be fetched using BIC code if 51A is present else the party details needs to be fetched using D to A converter. In case counterparty is not found then ‘Walk-in customer’ will be used. |
M |
50 |
Applicant |
Party details of APP |
The party details will be fetched using Name of the party. In case counterparty is not found, then ‘Walk-in customer’ will be used. |
M |
59 |
Beneficiary |
Party details of ‘BEN’ and customer details in Main screen |
The party details will to be fetched using Name of the party. In case counterparty is not found then ‘Walk-in customer’ will be used. |
M |
32B |
Currency code and amount |
LC currency and LC amount |
- |
O |
39A |
Percentage Credit Amount Tolerance |
About clause, positive and negative tolerance |
If not present then about clause should be ‘None’. If present, the about clause should be ‘About’ with positive and negative tolerance |
O |
39C |
Additional Amounts Covered |
Additional amounts covered in the ‘Others’ tab |
- |
M |
41A or D |
Available with…by… |
Credit details of LC (Type, mode and available with) |
For details, refer ‘Table B’ below. |
O |
42C |
Draft at |
Credit details |
- |
O |
42A |
Drawee |
Credit details |
- |
O |
42M |
Mixed Payment Details |
Credit details |
- |
O |
42P |
Deferred Payment Details |
Credit details |
- |
O |
43P |
Partial Shipments |
Partial shipment allowed |
If the tag value is ‘ALLOWED’, Partial Shipment will be ‘Y’. For any other value of the tag, it will be ‘N’. |
O |
43T |
Transshipment |
Trans Shipment allowed |
If the tag value is ‘ALLOWED’, FCC value will be ‘Y’. For any other value of the tag, it will be ‘N’. |
O |
44A |
Loading on board/dispatch |
Shipment From |
- |
O |
44B |
For Transportation To |
Shipment To |
- |
O |
44C |
Latest Shipment Date |
Latest Shipment Date |
- |
O |
44D |
Shipment Period |
Shipment Period |
- |
O |
45A |
Description of Goods and Services |
Goods Description |
- |
O |
46A |
Documents Required |
Document Details |
- |
O |
47A |
Additional Conditions |
FFT Information |
Tag 47A will be uploaded as FFT with FFT code as ‘UPLD_COND’ and message type as ‘ADV_THIRD_BANK’. |
O |
71B |
Charges |
Charges from Beneficiary in ‘Others’ tab. |
- |
O |
48 |
Period of Presentation |
Period for Presentation in ‘Others’ tab. |
- |
M |
49 |
Confirmation instructions |
Operation Code and May Confirm |
Refer ‘Table C’ for details. |
O |
53A or D |
Reimbursing Bank |
Party details of ‘REB’ |
The party details would be fetched using BIC code if 53A is present else the party details needs to be fetched using D to A converter. |
O |
78 |
Instructions to paying /acc/ neg bank |
FFT |
Tag 78 would be uploaded as FFT with FFT code as ‘INSTRUCTION’ and message type as ‘ADV_THIRD_BANK’. |
O |
57A or D |
Advise thru bank |
Party details of ‘ATB’ |
The party details will be fetched using BIC code if 57A is present else the party details needs to be fetched using D to A converter. |
O |
72 |
Sender to receiver info |
Internal remarks/FFT |
Tag 72 will be uploaded as FFT with FFT code as ‘SND2RECINFO’ and message type as ‘ADV_THIRD_BANK’. |
Table A
Tag value |
Transferable (Oracle FLEXCUBE value) |
IRREVOCABLE |
N |
REVOCABLE |
N |
IRREVOCABLE TRANSFERBALE |
Y |
REVOCABLE TRANSFERABLE |
Y |
Table B
Tag value |
Type (Oracle FLEXCUBE field value) |
Mode (Oracle FLEXCUBE field value) |
With (Oracle FLEXCUBE field value) |
Payment |
Straight |
Sight |
|
Acceptance |
Straight |
Acceptance |
|
Negotiation |
Negotiable |
Negotiation |
|
Def payment |
Straight |
Deferred |
|
Mixed pymt |
Straight |
Mixed |
|
Option A |
|
|
1st line |
Option D |
|
|
1st 4 lines |
Table C
Tag value |
Type (Oracle FLEXCUBE field value) |
Mode (Oracle FLEXCUBE field value) |
CONFIRM |
Advise and confirm |
N |
MAY ADD |
Advise |
Y |
WITHOUT |
Advise |
N |
During the booking of an export LC, MT711 will be considered for uploading goods description (field 45B), document details (field 46B) and additional conditions (field 47B). The existence of MT711 for MT710 will be checked from field 27 of MT710. MT711 SWIFT record will be fetched from the incoming browser using the reference number from field 20 of MT710.
The system will arrive at the queue through which MT710 should be routed using the STP rule maintenance. Based on the queue and message type, the system will identify the product for the LC contract from the product mapping maintenance where a queue is mapped to the product. The closure date of the LC will be derived from the product (expiry date in field 31D + closure days maintained in the LC product). The party details of advising bank ‘ABK’ in export LC will be derived from the sender reference number.
If all MT711 messages are not present in the incoming message browser, then the system will stop processing the corresponding MT711 and move on to process the next MT710 in the queue. Field 27 of the message will be used to identify the number of MT711 messages associated with an MT710.
The STP process will create authorized or unauthorized export LC based on the post upload status maintained in the ‘Upload Source Preferences’ screen.
Upload of MT707 triggers amendment of an export LC contract. The contract reference number on which the amendment needs to be triggered is derived primarily based on the value of field 21 in the MT707. The system fetches the contract reference number of the export LC contract using field 21. If the reference is not found, then it fetches the user reference number using field 21. If the value in field 21 is ‘NONREF’, the system will check for field 23.
If field 23 exists, then it will fetch the contract reference number using party as ‘ISB’ and the issuing bank reference number from field 23. If the contract reference is not found then the system will reject the record. If field 23 doesn’t exist then the system will fetch the contract reference number using party as ‘ISB’ and reference number of party ‘ISB’ from field 20. If the contract reference number is not found for above combination, then it will fetch the contract reference number using party as ‘ABK’ and reference number of party ‘ABK’ from field 20. If the contract reference is not found, then the system will reject the record.
The system fetches the amendment amount from field 34B. If the currency in field 34B does not match the currency of the existing contract, then system will reject the record.
The system fetches the new expiry date of the contract from field 31E. The following table lists the mapping that should exist between the SWIFT tags in MT707 and the fields in the LC Contract screen:
Status |
Tag value |
Description |
Oracle FLEXCUBE field value |
Remarks |
M |
20 |
Senders reference |
|
Not needed for amendment |
M |
21 |
Receiver reference |
Contract reference or user reference of LC contract |
|
O |
23 |
Issuing bank reference |
Their reference of party ‘ISB’ |
LC reference in issuing bank |
O |
31C |
Date of issue |
|
Not needed for amendment. |
O |
52A |
Issuing bank |
|
Not needed for amendment. |
O |
30 |
Date of amendment |
Issuing bank amendment date |
If this tag is not present then the system date should be used for issuing bank amendment date. |
O |
26E |
Number of amendment |
amendment number in others tab |
|
M |
59 |
Beneficiary |
|
Not needed for amendment |
O |
31E |
New date of expiry |
Expiry date |
|
O |
32B |
Increase of amount |
|
|
O |
33B |
Decrease of amount |
|
|
O |
34B |
New documentary credit amount after amendment |
LC amount during amendment |
|
O |
39A |
Percentage credit amount tolerance |
About clause, positive and negative tolerance |
If not present then about clause should be ‘None’. If present then the about clause should be ‘About’ with positive and negative tolerance |
|
|
|
|
|
O |
39C |
Additional amounts covered |
Additional amounts in others tab |
|
O |
44A |
Loading on board/dispatch |
Shipment from |
|
O |
44B |
For transportation to |
shipment to |
|
O |
44C |
Latest shipment date |
Latest shipment date |
|
O |
44D |
Shipment period |
Shipment period |
|
O |
72 |
Sender to receiver info |
FFT |
Tag 72 would be uploaded as FFT with FFT code as ‘SND2RECINFO’ and message type as ‘AMD_EXP_CR’’ |
The system will check for the following while processing a SWIFT upload:
If the amount after amendment is less than the availed amount, then system will reject the record. The system creates a new version of an export LC after amendment upload. The STP process creates an authorized or unauthorized amendment record based on the post upload status maintained in the ‘Upload Source Preferences’ screen.
MT799 is a free format message generated as part of internal amendment. While amending LC Contract if the Increment Amendment Number:
Note
Both financial and non-financial amendments are considered as internal amendment in LC Contract online screen (LCDTRONL) irrespective of Beneficiary confirmation.
MT730 can be generated in response to MT707 and MT710.
During LC amendment, MT730 is generated if the media is ‘SWIFT’ and message type is ‘LC_ACK_AMND’. The following table lists the mapping between the SWIFT tags in 730 and the fields in the LC Contract screen:
Status |
Tag value |
Description |
Oracle FLEXCUBE field value |
M |
20 |
Sender’s reference |
Contract reference or user reference |
M |
21 |
Receiver reference |
Their reference of party ‘ISB’ |
O |
25 |
Account identification |
Account of ISB in others tab |
M |
30 |
Date of message being acknowledged |
System date |
O |
32B |
Amount of charges |
Charge currency and charge amount of ISB in others tab |
O |
71B |
Details of charges |
Charges from ISB |
O |
72 |
Sender to receiver information |
FFT code ‘SND2RECINFO’ and message type as ‘LC_ACK_AMND’ |
MT730 is sent to the issuing bank to acknowledge the receipt of MT700. Oracle FLEXCUBE also allows you to send an acknowledgment from the advice through bank to the advising bank in order to acknowledge the receipt of MT710 (Advice of third bank).
The system marks the receiver of the message as ‘ABK’ for message types ‘LC_ACK_ADVICE’ and ‘LC_ACK_AMND’. If ‘ABK’ and ‘ISB’ parties are present for an LC contract, then the receiver of the message will be ‘ABK’. The receiver of this message will be ‘ISB’ only when ‘ABK’ is not present in the parties list. This process is applicable for the following events if the message type is ‘LC_ACK_ADVICE’:
The process is applicable for the following events if the message type is ‘LC_ACK_AMND’:
The following table lists the mapping that should exist between the SWIFT tags in MT730 and the fields in the LC Contract screen:
Status |
Tag value |
Description |
Oracle FLEXCUBE field value |
M |
20 |
Sender’s reference |
Contract reference/user reference |
M |
21 |
Receiver reference |
Their reference of party ‘ABK’ |
M |
30 |
Date of message being acknowledged |
System date |
O |
72 |
Sender to receiver information |
FFT code ‘SND2RECINFO’ and message type as ‘LC_ACK_AMD’ or ‘LC_ACK_ADVICE’ |
For the automatic generation of MT730 from an export LC, you need to link the message ‘LC_ACK_ADVICE’ to the ‘BADV’ and ‘BANC’ events at the product level. The post-upload status in the ‘Upload Source Preferences’ screen should be ‘Authorized’. The contract authorization at the time of contract upload will trigger the MT730 generation process. For manual generation of MT730 from an export LC, you need to ensure the same advice mapping to the events as mentioned for automatic generation. However, status in the ‘Upload Source Preferences’ screen should be ‘Unauthorized’. MT730 will then be generated during manual authorization of the export LC.
STP of MT740 triggers creation of an import LC with the operation code ‘Reimbursement’. The product for this import LC is fetched from the STP product mapping maintenance. The system check for the following during the STP:
The following table lists the mapping that should exist between the SWIFT tags in MT740 and the fields in the LC Contract screen:
Status |
Tag value |
Description |
Oracle FLEXCUBE field value |
Remarks |
M |
20 |
Documentary credit number |
Their reference of party ‘ISB’ |
|
O |
25 |
Account identification |
Account of Issuing bank in others tab |
|
O |
31D |
Date and place of expiry |
Expiry date and place of expiry |
|
O |
58A or D |
Negotiating bank |
Party details of ‘ABK’ |
The party details would be fetched using BIC code if 58A is present else the party details needs to be fetched using D to A converter. In case counterparty is not found then Walk in customer would be used |
O |
59 |
Beneficiary |
Party details of ‘BEN’ |
The party details would be fetched using name of the party |
M |
32B |
Credit amount |
LC currency and LC amount |
|
O |
39A |
Percentage credit tolerance |
About clause, positive and negative tolerance |
If not present then about clause should be ‘None’. If present then the about clause should be ‘About’ with positive and negative tolerance .The system should calculate Max LC amount = LC amount+ Tolerance. |
|
|
|
|
|
O |
39C |
Additional amounts covered |
Additional amounts covered in others tab |
|
M |
41A or D |
Available with. by |
Credit details of LC(Type, mode and available with) |
Refer ‘Table D’ for details. |
O |
42C |
Drafts at |
Credit details |
|
O |
42A or D |
Drawee |
Party details of ‘APP’ |
The party details would be fetched using BIC code if 42A is present else the party details needs to be fetched using D to A converter. In case counterparty is not found then Walk in customer would be used |
O |
42M |
Mixed payment details |
Credit details |
|
O |
42P |
Deferred payment details |
Credit details |
|
O |
71A |
Reimbursing bank charges |
Charges from in others tab |
Refer ‘Table E’ for the tags. If the tag is not present then charges from should be ‘OUR’. |
O |
71B |
Other charges |
FFT |
Tag 71 would be uploaded as FFT with FFT code as ‘71BCHARGES’ and message type as ‘LC_ACK_ADVICE’. |
O |
72 |
Sender to receiver info |
FFT |
Tag 72 would be uploaded as FFT with FFT code as ‘SND2RECINFO’ and message type as ‘LC_ACK_ADVICE’. |
Table D
Tag value |
Type (Oracle FLEXCUBE value) |
Mode (Oracle FLEXCUBE value) |
With (Oracle FLEXCUBE value) |
Payment |
Straight |
Sight |
|
Acceptance |
Straight |
Acceptance |
|
Negotiation |
Negotiable |
Negotiation |
|
Def payment |
Straight |
Deferred |
|
Mixed pymt |
Straight |
Mixed |
|
Option A |
|
|
1st line |
Option D |
|
|
1st 4 lines |
Table E
Tag value |
Charges From |
CLM |
Claimants |
OUR |
Ours |
The closure date is driven by the closure days maintained in the LC product. The party details of issuing bank ‘ISB’ in the import LC is derived from the header details using the BIC present in tag 1. This value corresponds to the CIF of the LC contract. The party details of claiming bank ‘CLB’ in the import LC are derived using field 41A or D. These details are updated in the ‘Parties’ tab of the import LC contract. If value in field 41D is ‘ANY BANK’, then the system will not update the party type as ‘CLB’.
The STP process creates authorized or unauthorized LC contract based on the post upload status maintained in the ‘Upload Source Preferences’ screen. The system triggers the event ‘BISS’ after the upload of MT740.
If you modify the LC amount, the undertaken amount will not be impacted. However, the non-undertaken amount will be respectively modified based on the change in LC amount.
If the checkbox ‘Undertake Entire LC on STP’ is checked on ‘Letters of Credit branch Parameters Maintenance’ screen, the system will pass the following entries on receipt of MT740:
Dr/ Cr |
Account Role Code |
Amount Tag |
Amount Tag Description |
Dr |
LC_OCU_OFFSET (Unutilized Credit Offset) |
REIM_UND_AMT |
Reimbursement Undertaking Amount |
Cr |
LC_OCU (Outstanding Credit Unutilized) |
REIM_UND_AMT |
Reimbursement Undertaking Amount |
If the checkbox ‘Undertake Entire LC on STP’ is not checked, the system will pass the following entries on receipt of MT740:
Dr/ Cr |
Account Role Code |
Amount Tag |
Amount Tag Description |
Dr |
LC_REM_NU_OFF |
REIM_NON_UND_AMT |
Reimbursement Non-undertaking Amount |
Cr |
LC_REM_NU |
REIM_NON_UND_AMT |
Reimbursement Non-undertaking Amount |
Note
While liquidating a bill under the LC, the system verifies the liquidation amount and the undertaken amount. If the liquidation amount is greater than the undertaken amount, the system displays an override message. You may choose to proceed or cancel.
You can upload MT747 as an LC amendment upload. The system fetches the contract reference number on which the amendment needs to be triggered based on field 20 of the message. It fetches the value of ‘Their reference’ field for the party ‘ISB’ using field 20. If the reference is not found then it will reject the record. The following table lists the mapping that should exist between the SWIFT tags in MT747 and the fields in the LC Contract screen:
Status |
Tag value
|
Description |
Oracle FLEXCUBE field value |
Remarks |
M |
20
|
Documentary credit number |
|
Reference Used for triggering amendment on LC contract |
O |
21 |
Reimbursing bank reference |
|
|
M |
30 |
Date of original authorization to reimburse |
|
|
O |
31E |
New date of expiry |
Expiry date |
|
O |
32B |
Amount Increase |
|
|
O |
33B |
Amount decreased |
|
|
O |
34B |
New amount after amendment |
LC amount during amend |
|
O |
39A |
Percentage credit tolerance |
About clause, positive and negative tolerance |
If not present then about clause should be ‘None’. If present then the about clause should be ‘About’ with positive and negative tolerance |
|
|
|
|
|
O |
39C |
Additional amounts covered |
Additional amounts covered in others tab |
|
O |
72 |
Sender to receiver info |
FFT |
Tag 72 would be uploaded as FFT with FFT code as ‘SND2RECINFO’ and message type as ‘LC_ACK_ADVICE’. |
O |
77A |
Narrative |
FFT |
Tag 72 would be uploaded as FFT with FFT code as ‘NARRATIVE’ and message type as ‘LC_ACK_ADVICE’. |
The STP process creates an authorized or unauthorized amendment record based on the post upload status maintained in the ‘Upload Source Preferences’ screen. The system creates a new version of the import LC after amendment upload and triggers the ‘AMND’ event. If field 21 does not have the LC contract reference, the system will reject the record. If field 34B is present, the system will check for the following:
SWIFT MT768 can be uploaded into Oracle FLEXCUBE through STP. The following table lists the mapping that should exist between the SWIFT tags in MT768 and the fields in the LC Contract screen:
Status |
Tag Value |
Description |
Oracle FLEXCUBE field value |
M |
20 |
Transaction Reference Number |
ABK’s Reference Number |
M |
21 |
Related Reference Number |
Contract reference or user reference of LC contract |
O |
25 |
Account Identification |
Account of ISB in others tab. |
M |
30 |
Date of Message being Acknowledged |
ABK’s Acknowledgment Date |
O |
32a |
Amount of Charges |
|
O |
57a |
Account with Bank |
|
O |
71B |
Details of Charges |
|
O |
72 |
Sender to Receiver Information |
FFT Information |
Values in fields 20 and 30 are updated in the LC contract screen on upload. The system triggers the event ‘ACKB’ on the uploaded LC Contract.