2.2.31 Processing of ECA and Partial/Full Fee Liquidation

This topic describes about the detailed information on ECA processing and fee liquidation.

  • ECA request for fee liquidation is not created from ELCM where GL is chosen as settlement account
  • For fees where liquidation start month and date are opted, ECA request is triggered as below:
    • Arrears Fees – On selected month and date with amount due till that day
    • Advance fees – ECA request on facility start date with amount from facility start date till selected month and date
  • ECA request is triggered for fee liquidation events (FLIQ and PRLQ - PRLQ_REC) and not for events like FACR
  • No ECA requests are triggered for fees associated with facilities in closed, expired or inactive status
  • No ECA requests are triggered for the fees that are waived
  • You can verify fee amount for each liquidation cycle, recovered and due from ‘Facility Fee Summary’ screen
  • You can Approve/Retry the rejected ECA request from ‘ECA Queue’ screen
  • When you choose to approve, fee gets liquidated and force posted irrespective of available balance in CASA (in GESFRTRY)
  • The different ECA request are provided below:
    • P – Processed
    • E - Error
    • T – Timed Out
    • A – Approved
    • U - Unprocessed

ECA Request for Auto Liquidation

  1. As part of ELCM batch process, amount due for liquidation for a fee is sent to the DDA system for approval based on (ECA_CHECK_REQD) parameter maintained in GEDPARAM table and verify funds flag at account and contract level. Only after receiving an approval from the DDA system, the system proceeds with liquidation of the fee component.
  2. ELCM sends a consolidate request to the ECA - one for each facility contract. As the settlement account is configured for each fee component in ELCM, multiple settlement accounts for a facility is possible. ELCM for a due date groups the total amount due from each account and generate one ECA request for a facility and due date.
    1. Full Liquidation
      • Fees are liquidated if only balance is fully available
      • Example
        • Fee 1 = 100, Fee 2 = 300
        • ECA Request for = 400
        • Amount in CASA = 300
        • ECA response will be Rejected and no liquidation takes place
        • Fee 1 and 2 will be updated as due
    2. Partial Liquidation
      • Fees are liquidated to the extent of available
      • Example
        • Fee 1 = 100, Fee 2 = 300
        • ECA Request for = 400
        • Amount in CASA = 300
        • ECA response is Approved and partial liquidation takes (Fee 1 liquidated to 100 and Fee 2 liquidated to 200)
        • Fee 2 is updated as due with amount 200.
  3. The due amount when sent as part of ECA request will be in account/facility currency
  4. As part of the ECA request, ELCM module sends the following additional preferences configured at a class/facility product level
    • Partial Liquidation Allowed (PARTIAL_BLOCK_REQUIRED): If the flag is set as ‘N’, then ECA system sends a fail approval in case the total amount requested is not available in the account.
    • Partial Liquidation Allowed (PARTIAL_BLOCK_REQUIRED): If the flag is set as ‘Y’, then ECA system sends a pass approval in case the total amount requested is not available in the account. Block to the extent of available amount is put and whatever fees can be recovered (in the order sent) is recovered
  5. In case of multiple fees that are due from the customer as part of Auto Liquidation, ELCM places a ECA request based on internal order of fee maintenance in ELCM.
    • Also applicable in case of multiple facilities using the same CASA and fees falling on same liquidation date – internal sequence of facility the same used for batch process is utilized for ECA request generation.
  6. First process in ELCM batch would compute the amount due for a fee 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.
  7. Upon receipt of any response from the DDA system in the OUT queue of ELCM module, the response would be parsed by the JAVA program and update the status response status (Approved/Rejected) in GETB_ECA_REQ_MASTER and GETB_ECA_REQ_DETAIL table.
    • Single block reference is sent by UBS for all fee rules in the facility
  8. When ECA block is successfully (APPROVED) created on the accounts (Partial / Full), liquidation happens in ELCM module and perform accounting
  9. When ECA block is unsuccessfully (REJECTED) created on the accounts (Partial / Full), other activities continue and the exception is logged - Fee not liquidated
  10. ECA request for auto liquidation will not be created from ELCM where GL is chosen as settlement account. For example, for a contract having fee component and GL is chosen as a settlement account then no ECA request will be created by ELCM. However, if GL is chosen only for one of the fee component and for another a valid customer account is chosen as settlement account, then ECA request will be created only for that fee component.
  11. 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 fees that are due for a day can be processed only after Auto liquidation is processed successfully for the preceding day
    • On account of holiday processing, fees pertaining to multiple liquidation cycles getting triggered together, order of processing will be based on the order in which request sent – oldest first and latest last. Request for each liquidation date will have separate block reference.
  12. In a situation where ECA block is successful, but subsequent processing in ELCM fails auto retry mechanism will be available
  13. ECA check during auto liquidation is a batch process
    • This is applicable for advance fees as well as the fees with auto liquidations are liquidated post successful completion of GEBUTILS batch
  14. PRLQ Event for Advance fee works as is and ECA requests are generated on the day they (PRLQ_REC) is triggered and work with the explained behaviour of blocking/recovery
    • Partial Liquidation Allowed option affects the fees that needs to be collected from customer as part of PRLQ (PRLQ_REC) – fees are collected from customer based on the flag
    • If a PRLQ fee is unable to be collected (ECA REJECT or ECA APPROVE for partial), it will be marked as overdue
    • The uncollected PRLQ fee is tracked separately and retried for recovery
    • Fees for new cycle continues the normal process but should be collected only when all overdue fees are cleared
    • If an advanced fee is not collected on facility start date and the due amount increases (due to utilization), then ECA request will include the full due amount on cycle end date as part of PRLQ.
  15. Due fees (ECA response as REJECTED) is logged separately as OVERDUE and retried for recovery based on the defined frequency specified
    • Fees for new cycle continues the normal process but should be collected only when all overdue fees are cleared
  16. System allows user to Reject/Retry the Rejected ECA request from ECA Queue screen
  17. System passes the accounting entries to external system only for the authorized contract with handoff status as Y after unblocking of the amount
  18. Below scenarios depict the behaviour of fees with auto liquidation and ECA check.

    Table 2-102 Behaviour of fees with auto liquidation and ECA check.

    Scenario Fee Rules Liquidation Amt CASA Balance Verify Funds Partial Liquidation Allowed Consolidated Request to UBS Amt Liquidated Remarks
    1 Fee1 100 500 Yes Yes* Sum of all fees = 750 100 Collected
    Fee2 200 500 Yes Yes* Sum of all fees = 750 200 Collected
    Fee3 150 500 Yes Yes* Sum of all fees = 750 150 Collected
    Fee4 250 500 Yes Yes* Sum of all fees = 750 50 Partially Collected
    Fee5 50 500 Yes Yes* Sum of all fees = 750 0 Not Collected as CASA balance exhausted

    Table 2-103 Behaviour of fees with auto liquidation and ECA check.

    Scenario Fee Rules Liquidation Amt CASA Balance Verify Funds Partial Liquidation Allowed Consolidated Request to UBS Amt Liquidated Remarks
    1 Fee1 100 500 Yes No* Sum of all fees = 750 0 Not Collected
    Fee2 200 500 Yes No* Sum of all fees = 750 0 Not Collected
    Fee3 150 500 Yes No* Sum of all fees = 750 150 Not Collected
    Fee4 250 500 Yes No* Sum of all fees = 750 50 Not Collected
    Fee5 50 500 Yes No* Sum of all fees = 750 0 Not Collected
  19. When a fee is auto liquidated, verify funds (ECA check) is performed. It would depend upon maintenance for verify funds (ECA check) present at GEDPARAM, facility and account levels. Following scenarios are handled here:
    1. Scenario 1: Verify funds (ECA check) is required and verify funds response is approved.
      • For Partial Liquidation – Normal fees Liquidation – Fee liquidation as result of PRLQ
      • For Full Liquidation – Normal fees Liquidation – Fee liquidation as result of PRLQ
    2. Scenario 2: Verify funds (ECA check) is required and verify funds response is rejected
      • For Partial Liquidation – Normal fees Liquidation – Fee liquidation as result of PRLQ
      • For Full Liquidation – Normal fees Liquidation – Fee liquidation as result of PRLQ
    3. Scenario 3: Verify funds (ECA check) is not required
      • Normal fees liquidation
      • Fee Liquidation as part of PRLQ
    4. Scenario 4: Verify funds (ECA check) is required, contract is entered in unauthorized mode
      • For Partial Liquidation
      • For Full Liquidation

ECA Request for Manual Liquidation

  1. Manual Liquidation is applicable for both Advance and Arrears fees through GEDFCFPT screen
  2. Partial Liquidation Allowed option does not have any effect on fees with manual liquidation – this flag is not applicable for fees with manual liquidation
    • User can chose to enter the fee the fee that needs to be liquidated and can opt for partial if sufficient balance is not available
  3. After capturing the necessary details in GEDFCFPT screen and click Save, ELCM will place an ECA request for the amount requested for the payment
  4. System displays the success or failure message based on response received from DDA system
  5. When the ECA request is approved by the DDA system, the saved record in GEDFCFPT needs to be manually authorized.
    • ELCM will process the payment request and update the tables and post liquidation entries as part of back ground process and payment status will be in unauthorized state.
    • Authorization of payment is possible only after the liquidation process is completed and entries are posted
  6. When the ECA request is rejected by the DDA system, the saved record in GEDFCFPT needs to be manually deleted
    • When manual payment is deleted for unauthorized contract, an undo ECA should be sent to the DDA system. – Block if processed should be unblocked
    • If there are multiple fees to be manually liquidated and if for one the ECA request is rejected, user needs to manually delete the payment instruction for that fee component and proceed with the approved ones.
    • Even in the case of rejection on account of insufficient CASA balance, UBS/DDA system will indicate the amount that can be blocked in CASA
    • User can then take a call how the amount needs to be apportioned across fee components.
  7. Similarly, ELCM generates reversal entries upon reversal of record (payment reversal) in GEDFCFPT.
    • Block if processed should be unblocked.
    • In case where actual accounting to DDA system is not generated post ECA approval, ELCM generates both actual entries for liquidation with block number and its reversal.

      Table 2-104 ECA Approval

      Actions System Response
      After getting ECA response as ‘Approved’, if you try to delete the payment The system should undo ECA with the approved block number
  8. System allows you to ‘Reject/Retry’ the Rejected ECA request from ‘ECA Queue’ screen
  9. System passes the accounting entries to external system only for the authorized contract with handoff status as ‘Y’ after unblocking of the amount
  10. Below are the sample scenarios which depicts the functionality further.

    Table 2-105 Scenario 1: Behaviour of fees with auto liquidation and ECA check.

    Fee Rules Liquidation Amt CASA Balance Verify Funds Partial Liquidation Allowed Consolidated Request to UBS UBS Resp Amt Liquidated Remarks
    Fee1 100 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 100 User chooses to fully collect
    Fee2 200 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 200 User chooses to fully collect
    Fee3 150 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 150 User chooses to fully collect
    Fee4 250 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 50 User chooses to partially collect
    Fee4 50 500 Yes NA Sum of all fees = 750 User chooses to partially collect 0 User chooses not to collect. New ECA request as per new appropriation rebuilt

    Table 2-106 Scenario 2: Behaviour of fees with auto liquidation and ECA check.

    Fee Rules Liquidation Amt CASA Balance Verify Funds Partial Liquidation Allowed Consolidated Request to UBS UBS Resp Amt Liquidated Remarks
    Fee1 100 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 100 User chooses to fully collect
    Fee2 200 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 100 User chooses to partially
    Fee3 150 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 150 User chooses to fully collect
    Fee4 250 500 Yes NA Sum of all fees = 750 Rejected . Also indicates that CASA balance is 500 100 User chooses to partially collect
    Fee4 50 500 Yes NA Sum of all fees = 750 User chooses to partially collect 50 User chooses to partially collect. New ECA request as per new appropriation rebuilt
  11. When a fee is manually liquidated through GEDFCFPT screen, verify funds (ECA check) is performed. It would depend upon maintenance for verify funds (ECA check) present at GEDPARAM, facility and account levels. Following scenarios are handled here:
    1. Scenario 1: Verify funds (ECA check) is required and verify funds response is approved
      • Sub Scenario a.1: Contract is authorized – fee liquidated
        • User chooses to fully liquidate
        • User chooses to partially liquidate
    2. Scenario 2: Contract is reversed – Reverse option in GEDFCFPT
    3. Scenario 3: Verify funds (ECA check) is required and verify funds response is rejected
      • Sub Scenario c.1: CASA balance not available
      • Sub Scenario c.2: User chooses to liquidate fees partially
      • Sub Scenario c.3: User chooses to liquidate only selective fees
    4. Scenario 4: Verify funds (ECA check) is not required
    5. Scenario 5: Verify funds (ECA check) is required, contract is entered in unauthorized mode.

Parent topic: Facilities Maintenance