13. Automatic Processes

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 ta­ble 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.

13.1 Branch Parameters Details

This section contains the following details:

13.1.1 Maintaining Branch Parameters

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 ‘Se­quence Generation’ screen available in the Application Browser. Refer to the Core Servic­es 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.

13.1.2 Invoking LC 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 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.

13.1.3 Automatic Events Executed During Beginning of Day (BOD)

The Batch program when run as part of BOD processes the following events:

13.1.4 Automatic Liquidation of Periodic Commission

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

COM­M_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:

13.1.5 Automatic Reinstatement of LC

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.

13.1.6 Processes Run during End of Day (EOD)

The Batch program when run as part of EOD processes the following events:

13.1.7 Automatic Closure of LC

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.

13.1.8 LC Auto Closure Batch

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 (Unuti­lized Credit Offset)

UCNF_LIA­B_OS_AMT

3000

Unconfirmed LC Amount

Cr

LC_OCU (Outstanding Credit Unutilized)

UCNF_LIA­B_OS_AMT

3000

Unconfirmed LC Amount

Dr

LC_CNF_OFF (Confirmation of LC Offset)

CNF_LIA­B_OS_AMT

5000

Confirmed LC Amount

Cr

LC_CNF (Confirmation of LC)

CNF_LIA­B_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.

13.1.9 LC Automatic Status Update Batch

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:

13.1.10 Status Change Batch Processing (CSDSTBTC)

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.

13.1.11 Automatic Accrual of Commission

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 col­lected.

Asset

Accrual amount

Dr

COM­M_INC

Commission earned

P&L

Accrual amount

Cr

 

If collected in Advance

Role

Role description

Role Type

Amount Tag

Dr/ Cr

COM­M_RIA

Commission received in advance.

Asset

Accrual amount

Dr

COM­M_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.

13.1.12 Memo Accrual of Commission

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.

13.1.13 Accrual Control Report

The accrual control report lists the LCs for which accrual entries were passed as of the current date.

13.1.14 Selection Options

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.

13.1.15 Contents of Report

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 compo­nent, till date.

13.1.16 Generating Tracers

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.

13.1.17 Executing Tracer Generation Function

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.

13.1.18 Straight Through Processing of SWIFT Messages

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.

13.1.19 STP of MT710 - Advise of Third Bank’s Documentary Credit

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 Docu­mentary Credit

Transferable

The different tag values for this field and the cor­responding FCC field value is given in ‘Table A’.

M

20

Senders Ref­erence

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 con­verter. In case counter­party 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 con­verter. In case counter­party 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 coun­terparty is not found, then ‘Walk-in customer’ will be used.

M

59

Beneficiary

Party details of ‘BEN’ and cus­tomer 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 neg­ative tolerance

If not present then about clause should be ‘None’. If present, the about clause should be ‘About’ with positive and nega­tive tolerance

O

39B

Maximum Credit Amount

Liability amount

-

O

39C

Additional Amounts Cov­ered

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 Pay­ment Details

Credit details

-

O

42P

Deferred Pay­ment Details

Credit details

-

O

43P

Partial Ship­ments

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

Transship­ment

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/dis­patch

Shipment From

-

O

44B

For Transpor­tation To

Shipment To

-

O

44C

Latest Ship­ment Date

Latest Shipment Date

-

O

44D

Shipment Period

Shipment Period

-

O

45A

Description of Goods and Services

Goods Descrip­tion

-

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 mes­sage type as ‘ADV_THIRD_BANK’.

O

71B

Charges

Charges from Beneficiary in ‘Others’ tab.

-

O

48

Period of Presentation

Period for Pres­entation in ‘Oth­ers’ 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 ‘INSTRUC­TION’ 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 con­verter.

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 TRANSFER­BALE

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 pay­ment

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)

CON­FIRM

Advise and confirm

N

MAY ADD

Advise

Y

WITH­OUT

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.

13.1.20 STP of MT707 – Amendment to Documentary Credit

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 refer­ence

 

Not needed for amendment

M

21

Receiver refer­ence

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 num­ber 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 documen­tary credit amount after amendment

LC amount during amendment

 

O

39A

Percentage credit amount tolerance

About clause, posi­tive 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

39B

Maximum credit amount

Liability amount

 

O

39C

Additional amounts cov­ered

Additional amounts in others tab

 

O

44A

Loading on board/dispatch

Shipment from

 

O

44B

For transporta­tion to

shipment to

 

O

44C

Latest ship­ment 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 mes­sage type as ‘AMD_EX­P_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.

13.1.21 STP of MT799 – Amendment of LC

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.

13.1.22 STP of MT730 – Acknowledgement

MT730 can be generated in response to MT707 and MT710.

13.1.22.1 Acknowledgement of MT707

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’

13.1.22.2 Acknowledgement of MT710

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 refer­ence

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.

13.1.23 STP of MT740 - Authorization to Reimburse

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 Issu­ing bank in oth­ers 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 tol­erance

About clause, positive and negative toler­ance

If not present then about clause should be ‘None’. If present then the about clause should be ‘About’ with positive and neg­ative tolerance .The system should calcu­late Max LC amount = LC amount+ Toler­ance.

O

39B

Maximum credit amount

Liability amount

Using liability amount the liability percent­age should be calcu­lated. Maximum credit amount = Max LC amount+Liability per­centage.

O

39C

Additional amounts covered

Additional amounts cov­ered 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 pay­ment

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 (Unuti­lized Credit Offset)

REIM_UND_AMT

Reimbursement Undertak­ing Amount

Cr

LC_OCU (Outstanding Credit Unutilized)

REIM_UND_AMT

Reimbursement Undertak­ing 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 un­dertaken amount. If the liquidation amount is greater than the undertaken amount, the sys­tem displays an override message. You may choose to proceed or cancel.

13.1.24 STP of MT747 – Amendment to an Authorization to Reimburse

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 amend­ment on LC con­tract

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 nega­tive toler­ance

If not present then about clause should be ‘None’. If pres­ent then the about clause should be ‘About’ with posi­tive and negative tolerance

O

39B

Maximum credit amount

LC liability amount

 

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_AD­VICE’.

O

77A

Narrative

FFT

Tag 72 would be uploaded as FFT with FFT code as ‘NARRATIVE’ and message type as ‘LC_ACK_AD­VICE’.

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:

13.1.25 STP of MT768 - Acknowledgement of a Guarantee Message

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 Num­ber

Contract reference or user refer­ence 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 Infor­mation

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.