To enable this functionality the following configuration tasks are needed:
Determine if your implementation wants to define an overpayment source to indicate what caused the overpayment process to be created. This is an optional field and is defined using the extendable lookup Overpayment Process Source. The values are meant to record the reasons that the obligation is in credit, for example “overpayment” or “benefit payment” or “liability adjustment”. Implementations that wish to use this field must provide appropriate logic to set the value, for example, using a pre-processing algorithm on the business object.
Various adjustments are used for calculating interest, write off and offset for the overpayment process, if applicable based on business rules. For each of these actions, a suitable adjustment type is required.
If you wish to specify a minimum amount threshold for the overpayment process, you will need to define a non-calculated adjustment type for the minimum amount write-off.
If your implementation rules specify that interest should be calculated and the interest is calculated using a rate, you will need to define the following:
A calculated adjustment type for offset-able interest, or a calculated adjustment type for non offset-able interest.
An associated rate schedule that includes a RQ rule for calculating number of days
If your implementation rules specify that interest should be calculated and the interest is calculated using a rate factor, you will need to define the following:
A non-calculated adjustment type for offset-able interest, or a non-calculated adjustment type for non offset-able interest.
An associated rate factor.
If your implementation allows offset, then a non-calculated adjustment type needs to be defined for the offset.
To allow refunds via a check, an A/P adjustment type needs to be defined.
Make sure the adjustment types are defined on an associated adjustment profile that is linked to any obligation types that are going to be covered by the overpayment process.
If approvals are required as part of the overpayment process, a To Do type is needed. The base product is supplied with a To Do type called C1-OVAPP that should be used as the basis for approval To Do type.
In addition, your implementation should determine if the overpayment process should alert a user if it is in this state for too long. If so, an appropriate monitor algorithm should be configured. Refer to the detailed description of the Approval in Progress status in the metadata for this base business object for more information.If you wish to have a To Do created when issues are detected during the validation of the overpayment process, you will need a To Do type. Note that the base-package is supplied with a To Do type called C1-OVISS that should be used as a basis.
For each To Do type that you wish to use, you will need appropriate To Do roles.
The system has been currently configured to calculate non offset-able interest using a rate factor. If you wish to change this you will need to inactivate the base-package algorithm by adding an appropriate inactivation option to the business object. You will then need to plug in a different algorithm based on the logic you wish to implement.
Review the overpayment and refund validation rules required for your overpayment processes to determine if existing algorithms are applicable or if additional algorithms are needed.
Define an overpayment process type for the business object C1-OvrpyProcTypeAutoCredRef.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]