A refund control is an object that groups together a list of overpayments that are ready for refunds to be issued. The refund control allows an implementation to review the total amount for all the overpayments in the list and ensure that there are enough funds in the bank to cover the payments out to the taxpayers.
The following topics highlight refund control functionality.
Refund controls are created based on an implementation's business practice. The product provides support for the following ways of creating refund controls:
Manual creation with criteria provided. An implementation may opt to let the refund control users create the appropriate refund controls each day, providing criteria such as tax type, overpayment process type and maximum amount. Once created, the user allows the record to be processed by the deferred monitor where an algorithm uses this criteria to select overpayments that match the criteria and link them to the refund control.
Creation via an interface. An implementation may opt to use an external reporting or analysis tool to select an explicit list of overpayments. In this case, the implementation must configure an interface to create the refund control and link the overpayments. Once the refund control is created, the deferred monitor processes it in the background to validate the list of linked overpayments.
The overpayments that are ready to be refunded are in a status of Refund Control Approval in Progress and remain in that state until the refund control is approved. There is another status, referred to as the Link Status that identifies the status of a particular overpayment to a particular refund control. The following points highlight the status values.
When an overpayment is initially linked it has a link status of Active. Only overpayments linked as active are considered eligible for refund.
An overpayment's link status may change to Skipped by the validation if the algorithm detects that the overpayment is no longer the status Refund Control Approval in Progress . For example, maybe the status of the overpayment is now Rejected because a user has rejected the overpayment process. Note that this option is only possible for the case where IDs are provided from an external source. The "criteria provided" option selects the overpayments in the validation step and would only select overpayments in the correct status. The background process that issues the refunds for overpayments in an approved refund control may also detect this situation.
An overpayment's link status may change to Removed at any time after it is linked. There are two ways that this can happen:
A user may explicitly remove an overpayment when reviewing the refund control for approval. This may occur when it is determined that there are not enough funds to cover the total amount and some overpayments are removed to reduce the total amount to one that is appropriate. Refer to Common Refund Control Procedures for more information.
A change could occur in an individual overpayment after it is linked to the refund control and the refund control is approved but before the amount is refunded. For example, perhaps a different financial transaction has occurred that brought the balance to zero or to a debit balance. This is checked at the time the overpayment attempts to transition itself.
Once the refund control and its list of overpayments are validated, the system determines if approval is required. If so, the record transitions to Approval in Progress and a To Do entry is created to alert the appropriate user(s). Note the following with respect to refund control approval:
The refund control type defines appropriate user groups for approval based on the total of the refund amounts for all the active overpayments.
The refund control type defines whether multiple levels of approval are required or if only a single approval is needed.
The refund control validates that an approver cannot be the same user that created the record nor the same user that performed a previous approval (for multiple approval levels).
When a refund control is found to have no overpayments linked as active, the refund control transitions to Approval in Progress even though there is nothing to approve. This allows a user to review the refund control to determine what happened to cause this situation. The user should then Reject the record.
Once a user approves a refund control, a batch process processes the linked overpayments to issue the refunds for each individual overpayment. The following are some points to note about this step:
The expectation is that this process is part of the nightly batch cycle because it creates financial transactions and subsequent background processes to interface the refund information to the accounts payable system or the bank interface are also required. As such there may be a delay from the time that a refund control is approved to the time its related overpayments are refunded.
Because of the time delay, it is possible that one or more individual overpayments are no longer eligible for refund once they are processed. As mentioned in the Overpayment Link Status section above, these overpayments are marked as Removed.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]