Dispute Request

Oracle Revenue Management and Billing allows you to create a dispute request for an account. Through a dispute request, the dispute against a particular bill, bill segment, and/or adjustment is tracked and closed. While creating a dispute request, you need to specify the dispute request type using which you want to create the dispute request. It is the dispute request type which helps the system to determine:

The business object using which the dispute request should be created
Whether the dispute request must be approved before creating adjustments to settle a dispute against a bill, bill segment, or adjustment
Approval profile using which the dispute request must be approved
Whether multi-level or single-level approval is required for a dispute request
Whether debit or credit hierarchy must be used for approval when the dispute request amount is zero
Default adjustment type using which adjustments must be created

You can add completed bills, its bill segments, and adjustments in the dispute request. In other words, at present, the system enables you to resolve the dispute against a bill, bill segment, and adjustment. If the dispute is against a bill, the system, by default, sets the dispute amount and does not allow you to change the dispute amount. The dispute amount is set to the original bill amount because the original bill amount and dispute amount must be equal. However, if the original bill amount is positive, then the dispute amount is set to negative, and vice versa. If the dispute is against a bill segment or adjustment, you can change the dispute amount, if required.

Once a dispute request is created, the status of the dispute request is set to Draft. You can then edit or delete the dispute request, if required. Once you add the bills, bill segments, or adjustments in a dispute request, you can submit the dispute request. On submitting a dispute request, the system behaves in the following manner:

Dispute Against	Type of Bill	Stop Auto Pay (Yes or No)	Behavior
Bill	Fully Paid	Not applicable	The system does the following: Creates the adjustment using the specified adjustment type for the bill. Swaps the adjustment onto the next bill.
Bill	Unpaid	Yes	The system does the following: Stops the automatic payment created for the current bill. A characteristic is defined on the current bill indicating the date till when the bill should not be considered by the Overdue Monitor (C1-ADMOV) batch. Note: The above step (2) occurs when the approval is required for the dispute request. Reopens the current bill of the account. Creates the adjustment using the specified adjustment type for the bill and swaps the adjustment onto the current bill. Completes and freeze the current bill.
Bill	Unpaid	No	The system does the following: Creates the adjustment using the specified adjustment type for the bill. Swaps the adjustment onto the current or next bill depending on the value defined for the Adjustment on Next Bill parameter in an algorithm created using the C1- ENTERADJ algorithm type.
Bill	Partially Paid	Not applicable	The system does the following: Creates two adjustments using the specified adjustment type for the bill. Swaps one adjustment onto the current bill and another adjustment onto the next bill. Example: A dispute is raised against a bill (Bill Amount - 100, Dispute Amount - 100, and Unpaid Amount - 50), then one adjustment (with the adjustment amount 50) is swap on the current bill and another adjustment (with the adjustment amount 50) is swap on the next bill.
Bill Segment	Fully Paid	Not applicable	The system does the following: Creates the adjustment using the specified adjustment type for the bill segment. Swaps the adjustment onto the next bill.
Bill Segment	Unpaid	Yes	The system does the following: Stops the automatic payment created for the current bill. A characteristic is defined on the current bill indicating the date till when the bill should not be considered by the Overdue Monitor (C1-ADMOV) batch. Note: The above step (2) occurs when the approval is required for the dispute request. Reopens the current bill of the account. Creates the adjustment using the specified adjustment type for the bill segment and swaps the adjustment onto the current bill. Completes and freeze the current bill.
Bill Segment	Unpaid	No	The system does the following: Creates the adjustment using the specified adjustment type for the bill segment. Swaps the adjustment onto the current or next bill depending on the value defined for the Adjustment on Next Bill parameter in an algorithm created using the C1- ENTERADJ algorithm type.
Bill Segment	Partially Paid	Not applicable	The system does the following: Creates two adjustments using the specified adjustment type for the bill segment. Swaps one adjustment onto the current bill and another adjustment onto the next bill. Example: A dispute is raised against a bill segment (Bill Segment Amount - 100, Dispute Amount - 100, and Unpaid Bill Segment Amount - 50), then one adjustment (with the adjustment amount 50) is swap on the current bill and another adjustment (with the adjustment amount 50) is swap on the next bill.
Adjustment	Fully Paid	Not applicable	The system does the following: Creates the adjustment using the specified adjustment type for the adjustment (against which you have raised a dispute). Swaps the adjustment onto the next bill.
Adjustment	Unpaid	Yes	The system does the following: Stops the automatic payment created for the current bill. A characteristic is defined on the current bill indicating the date till when the bill should not be considered by the Overdue Monitor (C1-ADMOV) batch. Note: The above step (2) occurs when the approval is required for the dispute request. Reopens the current bill of the account. Creates the adjustment using the specified adjustment type for the adjustment (against which you have raised a dispute) and swaps the adjustment onto the current bill. Completes and freeze the current bill.
Adjustment	Unpaid	No	The system does the following: Creates the adjustment using the specified adjustment type for the adjustment (against which you have raised a dispute). Swaps the adjustment onto the current or next bill depending on the value defined for the Adjustment on Next Bill parameter in an algorithm created using the C1- ENTERADJ algorithm type.
Adjustment	Partially Paid	Not applicable	The system does the following: Creates two adjustments using the specified adjustment type for the adjustment (against which you have raised a dispute). Swaps one adjustment onto the current bill and another adjustment onto the next bill. Example: A dispute is raised against an adjustment (Adjustment Amount - 100, Dispute Amount - 100, and Unpaid Adjustment Amount - 50), then one adjustment (with the adjustment amount 50) is swap on the current bill and another adjustment (with the adjustment amount 50) is swap on the next bill.

Finally, the status of the dispute request is changed to Processed. You can optionally configure the system to use the approval workflow process for a dispute request. If the Approval Required flag is set to Yes in a dispute request type, then on submitting the respective dispute request, the approval workflow process creates a To Do for the approver to review the dispute request. Once the approver approves the dispute request, the system behaves as mentioned in the above table. The approver can approve, reject, or resubmit the dispute request. When the dispute request is resubmitted to the submitter, the submitter can edit, cancel, or submit the dispute request.

The approval process is configured through the approval profile. The approval profile allows you to define the debit and credit hierarchy. If the dispute request amount is negative, the credit hierarchy in the approval profile is used for approval. However, if the dispute request amount is positive, the debit hierarchy in the approval profile is used for approval. You can either opt to use single-level or multi-level approval for the dispute requests.

During the dispute request process, a dispute request creation goes through various statuses in its lifecycle. For more information about the dispute request statuses, see Dispute Request (Without Approval) Status Transition and Dispute Request (With Approval) Status Transition.

Note: The lifecycle of a dispute request creation is driven by the respective business object using which the request is created. The dispute request feature explained in this document is articulated based on the lifecycle and logic defined in the business objects.

For more information on how to setup the dispute request process, see Prerequisites.

Related Topics

For more information on...	See...
Dispute Request Type screen	Dispute Request Type
Dispute Request screen	Dispute Request (Used for Searching)
Dispute Request screen	Dispute Request (Used for Viewing)

Parent Topic: Oracle Revenue Management and Billing Financial Services Business Processes