The lifecycle of the overpayment process depends upon the configuration of the associated business object. The Standard Overpayment Process BO (C1-OvrpyProcStandard) has a lifecycle that is expected to be used by most implementations. The lifecycle looks very complicated when viewing all the valid state transitions. The following diagram highlights the typical “positive” flow. Refer to the business object — summary tab for this business object for the full lifecycle diagram.
After the overpayment is created in the Initial state and found to be valid, it transitions to Approval in Progress to assess if any approvals are needed.
The threshold amounts and approval roles are defined on the overpayment type. One or more approvers may be required. A user can Approve or Reject the overpayment.
Once all the required approvals have been obtained, certain actions will take place such as offset.
Assuming there is still an amount to refund, the record transitions to the Refund Approval in Progress state where it waits to be linked to a refund control.
Once the refund control is approved, a background process transitions the overpayment to Refund Approved, where the refund is issued and finally the status is Complete.
The following points highlight additional detail about the lifecycle:
Validation issues:
After the overpayment is created, it executes overpayment validation plug-ins defined on the overpayment process type. If any issues are found, they are captured and the status goes to Issues Detected. From there a user may resolve the issue and reprocess or may Reject the record.
An addition validation check may be performed after it is clear that there is an amount to refund. The refund approval in progress state is configured to call refund validation algorithms on the overpayment process type. This allows for checking for valid bank information, for example. If any issues are found at this stage, the overpayment transitions to Issues Detected. Otherwise, it waits to be linked to a refund control.
The refund approved state once again calls the refund validation plug-ins on the overpayment process type. This is to cater for the possibility that a taxpayer has updated their banking information while the refund was awaiting refund control approval. If any issues are found at this stage, the overpayment transitions to Issues Detected. Otherwise, the refund is issued appropriately.
Several conditions are checked from any state where the overpayment process may transition from one where it was sitting and waiting for some action to occur. These include On Hold, Issues Detected, Approval in Progress and Refund Approval in Progress.
The overpayment itself is running algorithms that may reduce the credit. If any of these algorithms reduce the credit to zero, the status transitions to Complete.
Write off a small amount
Offset the credit to debt on another obligation
Issue the Refund
The obligation's balance may have changed independent of the overpayment process. This condition is checked from any state where the overpayment process may transition from one where it was sitting and waiting for some action to occur. The action taken depends on the status and the change in the balance:
If the balance change is detected during the transition out of On Hold or in Issues Detected, if the balance is no longer credit, the process completes. Otherwise, the new balance is checked again against the minimum write off. If it's greater than that threshold, it continues to the approval step. (Otherwise it's written off).
The balance change may be detected during the approval process. Note that the user interface for the base Standard Overpayment Process BO displays a message if the obligation’s current balance differs from the balance captured by the overpayment. if the balance is no longer credit, the process completes. If the balance is below the minimum write off amount, the amount is written off. If the balance is less credit or if it is more credit, the action depends on if the process is in the middle of a multi-level approval process (controlled by configuration on the overpayment process type).
If there is a single approver or if the balance change is detected at the final approval of a multi-level approval, the process continues if the balance is less credit or is more credit, but still within the threshold band of the current approver. If the credit is more credit and pushes the amount into a higher threshold band, then the process requires additional approval based on the new threshold band.
If balance change is detected during a multi-level approval, where future approvers are needed, the process continues if the new balance is in the same threshold band as the previous balance. It means that the same approval hierarchy applies. However, if the new balance is in a different threshold band than the original amount, then the process adjusts the future approver list appropriate for the new balance.
If the balance change is detected during the refund approval process (after the refund control is approved), if the balance is no longer credit, the process completes. If the balance is below the minimum write off amount, the amount is written off. If the balance is still credit but is less credit than before (but still above the minimum write off amount), the assumption is that the amount is still valid and that the refund can be issued without further review. If the amount is a greater credit, it should be reviewed again by a user. It is routed back to approval in progress for the appropriate final threshold level.
Any change detected during the lifecycle to the obligation's balance where it is brought to zero or is a debit amount, the BO transitions to Completed.
A suppression may have been logged for the obligation. After each transition that occurs after a waiting period, an algorithm checks if a suppression record exists for the obligation. If so, the process transitions to On Hold. In addition, implementations may introduce other conditions that cause the overpayment to transition to On Hold.
If a process that initiated the overpayment (such as a tax form) is subsequently canceled, the overpayment may also be Canceled. This can happen even after the overpayment process is complete. Algorithms executed when entering the complete status may attempt to undo any actions that the overpayment did, such as cancel write-offs or offsets or attempt to cancel the refund, if possible.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]