The Standard Overpayment Process base business object supports a “hand shaking” process with the base Direct Deposit bank event business object to support retrying a rejected refund attempt. the following points highlight the supported process:
If the overpayment process has a direct deposit refund method and is configured to create a bank event, the Refund Approved state will create a bank event. The bank event will refer to the overpayment process in its log as the “created by” process and the overpayment process log will indicate that it created the bank event.
If the bank event is rejected, an algorithm will create a new overpayment to try to issue the refund again. Some configuration allows an implementation to control some of the business rules:
The overpayment process to create is configured on the bank event type. An implementation may choose to configure a simple overpayment process type that doesn’t include any rules for calculating interest or approval or performing offsets, etc.
The refund method to use is configured on the bank event type. Some implementations may revert to mailing a paper check if a bank direct deposit failed. Other implementations may want to try to issue a direct deposit to a different bank. Note that the product does not provide any mechanism for determining a different bank. If business rules require contacting the taxpayer or making other attempts to find a different bank, custom algorithms are required. If the retry refund method is also direct deposit, the “retry” overpayment process creates another bank event. Note that it’s possible that this bank event will also be rejected causing yet another “retry” overpayment process.
The maximum number of retries may be configured on the bank event type. This is mainly applicable for implementations that want to continue to try to issue bank deposits. The bank event rejection algorithm checks the maximum number before creating an overpayment. Each “retry” overpayment process indicates its “retry attempt number” which is used by the bank event algorithm to compare against the maximum.
The “retry” overpayment process may not require an individual approval. However, it is still expected to be included in a Refund Control before issuing the refund.
A “retry” overpayment process is stamped with the ID of the overpayment process that created the bank event. Note that if the original overpayment process is canceled, it will attempt to cancel any related “retry” overpayment processes. For example, if a tax form causes an overpayment to be created and then the overpayment creates a bank event that is extracted to the bank. If the bank event is rejected, a new overpayment process is created. If the tax form is reversed at this point, the overpayment process it created will be canceled. That in turn will attempt to cancel the Bank Event (which is not eligible for cancellation) and the related retry overpayment process.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]