2. OBCL Integration

2.1 Common Core Maintenances

The following are the common core maintenance that needs to be completed for FCUBS, Payments, and ELCM systems integration.

• Section 2.1.1, "Configuring Accounting System for Host Code"
• Section 2.1.2, "Maintaining Integration Parameters"

2.1.1 Configuring Accounting System for Host Code

You can configure the accounting system using host code in the ‘Host Parameter’ screen.

To invoke this screen, type ‘PIDHSTMT’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

 

Specify the following details

Host Code

Specify the host code.

Host Description

Specify the brief description for the host.

Accounting System Code

Specify the accounting system code.

Payment System

Specify the payment system.

ELCM System

Specify the ELCM system.

OBCL Integration System

Specify the external system. For example, OLINTSYS

2.1.2 Maintaining Integration Parameters

You have to maintain integration parameters for ‘External LOV’ and ‘ELCM/Payment/OL Utilization’. This maintenance must be done for all branches. This maintenance is done through ‘Integration Parameters Maintenance’ screen.

To invoke this screen, type ‘IFDINPRM’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

Example of Integration Parameter Maintenance screen for Payments

 

Example of Integration Parameter Maintenance screen for ELCM

 

Example of Integration Parameter Maintenance screen for OBCL

 

You can specify the following fields in this screen:

Branch Code

Select the branch code for which the parameters are to be maintained from the adjoining option list.

Description

A brief description of the branch code is displayed.

External System

Select the external system for which the parameters are to be maintained, from the adjoining option list.

Description

A brief description of the external system is displayed.

Offset Transaction Code

Select a transaction code for the offset entry from the adjoining option list. The adjoining option list displays all valid transaction codes available in the system. You can select the appropriate one

Offset Amount Tag

Select an amount tag for the offset entry from the adjoining option list. The adjoining option list displays all valid amount tag available in the system. You can select the appropriate one

Amount Block Validation

Select this check box to validate the amount block. If the amount block reference number is sent with the transaction details then the accounting will be invoked after the release of amount block.

Offset Required

Select this check box if an offset entry is required. If this check box is selected, then ISB GL will be resolved based on branch, currency, function id and external system. If the check box is not selected, then it is expected that external system sends the balanced entry

Offset Netting Required

Select this check box if offset netting entry is required. If this check box is selected, then the consolidated entries will be built. Offset amount tag is picked from the maintenances. If this check box is not selected, then individual entries are built.

Allow Force Post

Select this check box to suppress all the overrides after posting transactions.

You need to maintain the integration parameters for the following:

• External Lov – ExtLovService
• ELCM Utilization/Payments/OBCL – ELUtilizationService/PMSinglePaymentService/FCUBSCAService

External Lov

 

• External System - External system name is specified here. For example, OLELCM, INTBANKING for Payments, and OLINTSYS for OBCL.
• Service Name – The service name for which the maintenance is done. For example, ELUtilizationService for ELCM, ExtLovService for External LovExtLovService, and PMSinglePaymentService for Payments, and FCUBSCAService for OBCL.
• Communication Channel – The communication channel like REST, CUSTOM, WEB SERVICE, and so on are specified here.
• Communication Mode – The communication mode can be SYNC/ASYNC.

Note

Rest Service need not be maintained for OBCL.

• Rest Service IP – You have to maintain the IP address. For example, ELCM IP, Payment IP.
• Rest Service Port – You have to maintain port details. For example, ELCM Port, Payment Port.
• Rest Service Pattern - You have to maintain rest service pattern. For example, LovService
• Rest Service Context – You have to maintain rest service context. For example, FCJNeoWeb
• External User - ELCM/Payment/OBCL user should have access to all branches and autoauth

ELCM Utilization/Payment/OBCL

 

• External System - External system name is specified here. For example, OLELCM.
• Service Name – The service name for which the maintenance is done. For example, ELUtilizationService for ELCM, ExtLovService for External LovExtLovService and PMSinglePaymentService for Payments.
• Communication Channel – The communication channel like REST, CUSTOM, WEB SERVICE, and so on are specified here.
• Communication Mode – The communication mode can be SYNC/ASYNC.
• WS Service Name – The service name needs to be maintained here. For example, ELUtilizationService, PMSinglePaymentService, and FCUBSCAService.
• WS Endpoint URL – The WSDL of the services are maintained here. For example, ELCM utilization/Payment/CA service WSDL link
• WS User – ELCM/Payment user should have access to all branches and autoauth.
• External User - ELCM/Payment/OBCL user should have access to all branches and autoauth.

 

2.2 Oracle Lending and Loan Syndication module integra­tion with CASA

The integration of OLand LS module with CASA enables banks to do the following:

• Auto Liquidation
• Manual Liquidation
• Auto Rollover
• Manual Rollover

This chapter contains the following sections:

• Section 2.2.1, "Scope"
• Section 2.2.2, "Integration Scope with FCUBS Co-deployed with OL and LS module"
• Section 2.2.3, "Integration Scope without FCUBS Co-deployed with OL and LS module"
• Section 2.2.4, "ECA handling scenarios for Corporate Loan Liquidation"
• Section 2.2.5, "Prerequisites"
• Section 2.2.6, "Prerequisites in Oracle Lending and Loan Syndication"

2.2.1 Scope

This section describes the activities that take place in each system and its impact on the other.

This section contains the following topics:

• Section 2.2.2, "Integration Scope with FCUBS Co-deployed with OL and LS module"
• Section 2.2.3, "Integration Scope without FCUBS Co-deployed with OL and LS module"

2.2.2 Integration Scope with FCUBS Co-deployed with OL and LS module

If FCUBS is co-deployed with OL and LS module, then web service call is used to check the available balance.

2.2.3 Integration Scope without FCUBS Co-deployed with OL and LS module

The following are the integration activities that take place in Oracle Corporate Lending.

ECA Request for Auto Liquidation

 

• As part of loans batch process, amount due for liquidation for a contract must be sent to the DDA system for approval (ECA_CHECK_REQD parameter maintained in cstb_param table and verify funds flag at contract level). Only after receiving an approval from the DDA system, the system proceeds with liquidation of the schedule.
• OL and LS module should send a consolidate request to the ECA one for each contract. As the settlement account is configured for each component in Corporate Lending, multiple settlement accounts for a contract is possible. OL and LS module for a due date should group the total amount due from each account and generate one ECA request for a contract and due date.
• The due amount when sent as part of ECA request should be in account currency.
• As part of the ECA request, OL and LS module should send the following additional preferences configured at a contract / product level.
  • Partial Liquidation Allowed (PARTIAL_BLOCK_REQUIRED): If the flag is set as ‘N’, then ECA system should send a fail approval in case the total amount requested is not available in the account.

• In case of multiple schedules that are due from the customer as part of Auto Liquidation, OL and LS system should place a ECA request for the earliest schedule due from the customer. Only when the schedule is completely settled and processed in OL system, request for next schedule should be placed.
• First process in OL and LS batch would compute the amount due for a schedule as part of Auto liquidation and place the request into ECA table with the current status as ‘Unprocessed’. A Java program would constantly poll the table for any unprocessed records and transform the records into an ECA request XML and place the same into a IN queue of the external system configured.
• Upon receipt of any response from the DDA system in the OUT queue of OL and LS module, the response would be parsed by the JAVA program and update the status response status (Approved/Rejected) in OLTB_ECA_REQ_MASTER and OLTB_ECA_REQ_DETAIL table.
• When ECA block is successfully created on the accounts (Partial / Full), liquidation happens in OL and LS module and perform OL and LS accounting with handoff status as 'N'.
• ECA request for auto liquidation should not be created when future dated payment is requested for the same contract. ECA request for auto liquidation should not be created from OL and LS module where GL is chosen as settlement account. For example, for a contract having Principal and Interest as components and GL is chosen as a settlement account then no ECA request should be created by OL and LS module. However, if GL is chosen only for Interest and for Principal a valid customer account is chosen as settlement account, then ECA request should be created only for Principal component.
• When Auto Liquidation process is run for more than one day as part of EOD processing (due to holiday settings), then Auto liquidation for the schedules that are due for a day can be processed only after Auto liquidation is processed successfully for the preceding day.
• In a situation where ECA block is successful, but subsequent processing in OL and LS module fails auto retry mechanism should be available in OL and LS module.

ECA Handling during Auto Rollover

 

• For contract marked for Auto Rollover, after EOD process of Auto Liquidation, a new sub-process ‘AROLL’ is introduced to process Auto Rollover on processing date

ECA Handling for Manual liquidation

 

• After you capture the necessary payment details and click ‘Save’, OL and LS module should place an ECA request for the amount requested for the payment.
• There should be an additional field in the payment screen to display the ECA process status. This should display the status of the ECA request.
• When the ECA request is approved by the DDA system, it needs to be manually authorized. Hence, manual payment is deleted for unauthorized contract, an undo ECA should be sent to the DDA system.
• OL and LS module should process the payment request and update the cashflow tables and post liquidation entries as part of back ground process and payment status will be in unauthorized state.
• Authorisation of payment is possible only after the liquidation process is completed and entries are posted.
• Similarly OL and LS module should generate reversal entries upon reversal of loan payment. In case where actual accounting to DDA system is not generated post ECA approval, OL and LS module should generate both actual entries for liquidation with block number and its reversal.

  Actions	System Response
  After logging payment in ECA queue for approval, if you try to delete the payment before getting the response, then the status is W.	The system should undo ECA if it gets approved response (Reconcillation mecha­nism)
  After getting ECA response as ‘Approved’, if you try to delete the payment	The system should undo ECA with the approved block number

ECA Handling for Manual Rollover

 

• After you initiate the rollover (Normal/Consol/Split) through application, OL module should place an ELCM request (if any limits are linked to the contract) for the amount to be debited from customer.
• After success response from the ELCM system, the system allows you to authorize the rollover. In case where actual accounting to DDA system is not happened post ECA approval, OL and LS module should generate both actual entries for roll event with block number to release from DDA system.

Account Interface and Handoff

 

• For CASA, where debit happened excluding force debit components, have the block number in the daily log table.
• As part of accounting interface OL and LS module should hold two handoff status, one to indicate whether the customer account related entries handoff to DDA system and another to indicate GL entries handoff to GL system.
• External Account Check (EAC) is done wherever the credit happens to CASA account to avoid failure in external system side (Check for No credit, No debit,Frozen,Deceased)
• Java poller constantly polls the daily log table and pick the records which are authorized and handoff yet to be done.It then generates the accounting request with necessary details and put in IN queue.After getting successful response from external system, handoff status is changed.If anything failed while giving external handoff, external system throws a proper exception code and same has been logged in OL and LS side.

  Debit request+ <ECAREFNO>	ECA Block is released
  Debit request	Amount is debited from with­drawable balance

• Credit and Debit advice should be generated only after the feedback from the DDA system after posting entries to the customer account.
• OL and LS module should be capable to handoff the entries online by generating XML request as well as handoff entries through batch process at regular intervals during the day.

Force debit Components

Tax, Fee and charge which are associated with liquidation/rollover event is debited from the account without ECA.

Forward Liquidation

 

• As part of loans batch process, amount requested (From payment screen) for liquidation of a contract must be sent to the DDA system for approval (ECA_CHECK_REQD parameter maintained at cstb_param, Branch Param, and CASA level table and verify funds flag at contract level). Only after receiving an approval from the DDA system, the system proceeds with liquidation of the schedule.
• First process in OL and LS batch( for Fwd liquidation) ,would compute the requested amount for a contract and place the request into ECA table with the current status as ‘Unprocessed’. A Java program would constantly poll the table for any unprocessed records and transform the records into an ECA request XML and place the same into a IN queue of the external system configured.
• Upon receipt of any response from the DDA system in the OUT queue of OL and LS module, the response would be parsed by the JAVA program and update the status response status (Approved/Rejected) in OLTB_ECA_REQ_MASTER and OLTB_ECA_REQ_DETAIL table.
• When ECA block is successfully created on the accounts (Full), liquidation happens in OL module and perform OL accounting with handoff status as 'No'.
• ECA request for liquidation should not be created from OL and LS module where GL is chosen as settlement account. For example, for a contract having Principal and Interest as components and GL is chosen as a settlement account then no ECA request should be created by OL and LS module. However, if GL is chosen only for Interest and for Principal a valid customer account is chosen as settlement account, then ECA request should be created only for Principal component.
• In a situation where ECA block is successful, but subsequent processing in OL and LS module fails auto retry mechanism should be available in OL and LS module.

2.2.4 ECA handling scenarios for Corporate Loan Liquidation

This section contains the following topics:

• Section 2.2.4.1, "Single CASA Account with Full liquidation"
• Section 2.2.4.2, "Different CASA Account with Full Liquidation"
• Section 2.2.4.3, "GL Account used for Liquidation"
• Section 2.2.4.4, "One CASA and GL Account used for Liquidation"
• Section 2.2.4.5, "Single CASA Account with Partial Liquidation"
• Section 2.2.4.6, "Manual Liquidation with Single CASA or Multiple CASA Account"

2.2.4.1 Single CASA Account with Full liquidation

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	CASA1	50000
Interest	10000	CASA1	10000

2.2.4.2 Different CASA Account with Full Liquidation

In this case OL and LS module generates a single ECA request that contain details amount due from two accounts.

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	CASA1	50000
Interest	10000	CASA2	10000

2.2.4.3 GL Account used for Liquidation

In this case request is not sent to ECA system, however it is marked as approved by OL and LS module in ECA tables and it proceeds with liquidation processing.

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	GL1	50000
Interest	10000	GL2	10000

 

2.2.4.4 One CASA and GL Account used for Liquidation

In this ECA request is sent only for CASA account and the GL it is marked as approved automatically. Liquidation processing happens irrespective of whether the ECA request is successful for the CASA account.

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	CASA	50000
Interest	10000	GL1	10000

 

2.2.4.5 Single CASA Account with Partial Liquidation

In this case, the system proceeds with allocating the approved amount based on liquidation order specified at the product level.

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	CASA1	50000
Interest	10000	CASA1	10000

 

2.2.4.6 Manual Liquidation with Single CASA or Multiple CASA Account

In this case ECA request is sent with Partial allowed as ‘N’, hence the request is marked as failure if the full amount requested is not available.

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	CASA1	50000
Interest	10000	CASA1	10000

2.2.5 Prerequisites

This section contains the following topics:

• Section 2.2.6, "Prerequisites in Oracle Lending and Loan Syndication"

2.2.6 Prerequisites in Oracle Lending and Loan Syndication

The prerequisites for this integration are as follows.

2.2.6.1 Parameter Setup

• If HANDOFF_TYPE value is ‘SYNC’ in CSTB_PARAM table, then the balance check is performed using API or dynamic call.
• If HANDOFF_TYPE value is ‘ASYNC’ in CSTB_PARAM table, then the consolidated amount to be requested is logged in ECA tables. Further processing, is performed by job.
• ECA_CHECK_REQD should be 'YES' in CSTB_PARAM table for standalone system.

2.2.6.2 Maintenances

Complete the following maintenances in Oracle Banking Corporate Lending to enable the integration.

Queue Name	Purpose
ECA_REQ_OUT	Request to external system
ECA_RES_IN	Response from external system

Table Name	Purpose
COTB_ECA_QUEUE	ECA request details
COTB_ECA_QUEUE_DETAIL	ECA request components details

Note

The following data in OL and LS module must be in sync with those maintained in external system.

• Branch
• Contract Reference Number
• Account number
• Currency
• Dr/Cr

2.3 Integration Process of OL and LS module CASA

This section contains the following topics:

• Section 2.3.1, "Viewing ECA Queue Summary Details"
• Section 2.3.1, "Viewing ECA Queue Summary Details"
• Section 2.3.2, "Viewing External Accounting Log"

2.3.1 Viewing ECA Queue Summary Details

ECA Queue Summary screen contains details on the transactions between OL/LS and external system.

To invoke this screen, type PISECAQU’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

 

You can search records based on the following parameters:

• Transaction Reference No
• Network code
• ECA Amount
• Customer No
• Requested Date
• Authorization Status
• Cross Border Contract Reference Number
• Activation Date
• File Reference Number
• Payment Transaction Type
• ECA Currency
• Current Status
• Response Date
• Maker Id
• Payment Type
• Customer Service Model
• Queue Reference No
• Transaction Branch
• Module
• Response Status
• ECA System Code
• Checker Id
• Source Code

Click ‘Search’ button with or without entering any of the above search parameters. All records matching the search criteria are displayed. To view a particular record double-click on the desired record displayed in the list of records. The details pertaining to each record is displayed.

2.3.2 Viewing External Accounting Log

'External Accounting Log' screen contains OL/LS transaction details with External Accounting System linkage.

To invoke this screen, type ‘OLSEACLG’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

In this screen, you can view the request sent from OL and LS module and view the response (received for the request sent) from the External Accounting System.

 

You can search records based on the following parameters:

• External Reference Number
• Branch
• External Accounting System
• Operation Code
• Process Status
• Message Reference Number

Click ‘Search’ button with or without entering any of the above search parameters. All records matching the search criteria are displayed. To view a particular record double-click on the desired record displayed in the list of records. The details pertaining to each record is displayed.

2.4 OBCL Integration with Payments for SWIFT messages

2.4.1 The integration between Oracle Banking Corporate Lending and Oracle Banking Payments enables you to generate SWIFT messages (MT103 and MT202) for Corporate Lending through Payments module.

2.4.2 Scope

SWIFT payment message MT103 and MT202 are supported. If transfer type is ‘Customer Transfer’, then MT103 payment message is generated. If transfer type is Bank Transfer, then MT202 payment message is generated.

2.4.3 Integration Process of OBCL and Payments

For OL/LS with Payments integration, you need to perform the following:

• In Branch Parameters Details screen (OLDBRMNT), 'Generate MT103' check box needs to be selected.
• In Settlement Instructions Maintenance (LBDINSTR), 'Transfer By Pay' or 'Transfer By Recv' needs to be selected as ‘BANK’ or ‘CUSTOMER’. In case of 'BANK', MT202 SWIFT message is generated at Payments module. In case of 'CUSTOMER', MT103 SWIFT message is generated at Payments module.
• OBCL initiates web services call, that is, PMSinglePaymentService call for cross-border outgoing SWIFT transactions. These outgoing SWIFT transactions are processed by Payments module. The payment module generates MT103 and MT202/MT202Cover SWIFT messages.

In Loan Syndication, SWIFT messages are triggered based on the components like PRINCIPAL, INT_LIQD, and FEE_LIQD.

This section contains the following topics:

• Section 2.4.3.1, "Processing of Outgoing SWIFT Messages"
• Section 2.4.3.2, "Viewing Payment Integration Request/Response Messages"
• Section 2.4.3.3, "Maintaining ISB GL"

2.4.3.1 Processing of Outgoing SWIFT Messages

Steps involved in processing of outgoing SWIFT messages.

• On save of the contract, the system checks if SWIFT messages are generated and Inter System Bridge GL (ISB GL) maintenance is available.
• Instead of posting accounting entries to settlement account, the system posts accounting entries to ISB GL.
• On authorization, the system populates SWIFT related details to staging table. Job runs on the table and pick these records. These details are sent to Payments module.
• Once the request is received, Payments module sends the response with confirmation.
• Payments module sends communication to OBCL for each of these actions.
• Using same service, Payments module sends SWIFT messages ACK/NACK accordingly. Once SWIFT message is received, OBCL populates the daily out message table.
• You can view these messages in ‘Payment Outgoing Browser’ screen.

2.4.3.2 Viewing Payment Integration Request/Response Messages

You can view Oracle Lending and Loan Syndication contracts with payment integration in ‘Payment Outgoing Browser’ screen.

To invoke this screen, type ‘OLSPMTBR’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

In this screen, you can view the request sent from Oracle Lending/Loan Syndication module and view the response (received for the request sent) from the Payments module.

 

You can search records based on the following parameters:

• Queue Reference Number
• Sequence Number
• Contract Reference
• Process Status
• Value Date
• Event Code

Click ‘Search’ button with or without entering any of the above search parameters. All records matching the search criteria are displayed. To view a particular record double-click on the desired record displayed in the list of records. The details pertaining to each record is displayed.

Note

To search outgoing payment details, for LB side use DD Contract Reference Number and for LP side use Contract Reference Number

2.4.3.3 Maintaining ISB GL

You can invoke the ‘ISB GL Maintenance’ screen by typing ‘OLDISBGL’ in the field at the top right corner of the application tool bar and by clicking the adjoining arrow button.

 

You can specify the following field information in this screen. A brief description of each value updated in the fields appearing in this screen, is displayed by the system.

External System

Select the external system from the adjoining option list.

Module ID

Select a valid module code from the adjoining option list.

Transaction Currency

Select a valid currency code from the adjoining option list.

Transaction Branch

Select a valid transaction branch code from the adjoining option list

Product Code

Select a valid product code from the adjoining option list.

Function ID

Select a valid function ID from the adjoining option list.

ISB GL

Select a leaf General Ledger from the adjoining option list.

2.5 OBCL - ELCM Integration

The integration between OBCL and ELCM enables you to view the Oracle Lending and Loan Syndication contracts with ELCM linkage in a sync or async mode.

2.5.1 Scope

If you are booking a Oracle Lending and Loan Syndication contracts with ELCM linkage in a sync or async mode, the OLTB_REQ_MASTER table is updated with records. You can view these records in the External Limit Summary screen.

2.5.2 Prerequisites

OLTB_REQ_MASTER table must have value.

2.5.3 Integration Process of OL and ELCM

Forward Init

As part of loan batch process for contract marked for initiation on processing date, the system picks and processes the 'FWDINIT' on processing date.After processing ‘FWDINIT’, the system sends a request to ELCM system (if any limits are linked to contract) for Utilization of contract amount.

After success response from the ELCM system, the system authorizes the ‘FWDINIT’ process.For failure response from ELCM system, the system roll backs the ‘FWDINIT’ process (after roll back contract details are logged into exception table)

Forward VAMI

As part of loan batch process for contract marked for VAMI on processing date, the system picks and processes the ‘FWDVAMI’ on processing date. After processing FWDVAMI, the system sends a request to ELCM system (If any limits are linked to contract) for Utilization/De-Utilization of contract amount.

After success response from the ELCM system, the system authorizes the VAMI process. For failure response from ELCM system, the system roll backs the FWDVAMI process (after roll back contract details are logged into exception table)

Auto Liquidation and Forward Liquidation

As part of loan batch process for contract marked for Liqudation on processing date, the system picks and processes the liquidation on processing date. After processing the system sends a request to ELCM system (If any limits are linked to contract) for Utilization/De-Utilization of contract amount.

After success response from the ELCM system, the system completes the liquidation process. For failure response from ELCM system, the system roll backs the liquidation process (after roll back contract details are logged into exception table)

ACCRUAL

As part of loan batch process for contract marked for ‘ACCRUAL’ on processing date, the system picks and processes the ‘ACCRUAL’ process on processing date. After processing accrual process, the system sends a request to ELCM system (If any limits are linked to contract) for Utilization/De-Utilization of contract amount.

After success response from the ELCM system, the system authorizes the accrual process. For failure response from ELCM system, the system roll backs the ‘ACCRUAL’ process (after roll back contract details are logged into exception table).

 

2.5.3.1 Viewing External Limit Summary Details

External Limit Summary screen contains details of the Oracle Lending and Loan Syndication transactions with ELCM linkage.

You can approve, resend, reject, and authorize the Oracle Lending and Loan Syndication transactions using this screen.

To invoke this screen, type OLSEXLMT’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

 

You can search records based on the following parameters:

• Branch Code
• User Reference Number
• Message ID
• Process Sequence Number
• Process Status
• External Status
• Destination Source
• Request Type
• Communication Mode
• Forceprocess
• Service Code
• Logtime
• Authorization Status
• Maker ID
• Maker Date Stamp
• Checker ID
• Checker Date Stamp

Click ‘Search’ button with or without entering any of the above search parameters. All records matching the search criteria are displayed. To view a particular record double-click on the desired record displayed in the list of records. The details pertaining to each record is displayed.

2.5.3.2 Viewing Action Log of External Limit Queue

The action log screen displays the details of actions performed in the External Limit Queue screen.

To invoke this screen, type ‘OLDQAHIS’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

 

This screen displays the action log of the following fields along with ‘Message Id’ and ‘Process Sequence Number’.

• Transaction Reference Number
• Previous Status
• Current Status
• Authorization Status
• Logtime
• Maker ID
• Maker Date Stamp
• Checker ID
• Checker Date Stamp

2.5.4 Viewing Service Log Details

You can view service log using ‘View Service Log’ screen. To invoke this screen, type ‘OLDSRLOG’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.