Pin_rerate Generates Duplicate Recurring Charges

(Doc ID 1546274.1)

Last updated on AUGUST 24, 2016

Applies to:

Oracle Communications Billing and Revenue Management - Version 7.4.0.1.0 to 7.5.0.0.0 [Release 7.4.0 to 7.5.0]
Information in this document applies to any platform.

Symptoms

If pin_rerate is used to rerate events which have been provisioned, it creates new recurring charges without adjusting the old recurring charge.

Replication Steps

---------------------


1. Set PVT to Jan 4th 2013.
2. Change the following parameters in cm's pin.conf file before replicating the issue.

- fm_bill calc_cycle_from_cycle_start_t 1
- fm_subscription rate_change 1
- fm_bill delay_cycle_fees 1


3. Provision a new account/service/deal/product with start date Nov 1st 2012 and DOM 4.
4. Assuming the product is $200/month. This will create 3x$200 MRCs for the 3 months Nov 4->Feb 4 plus a prorated MRC for the period Nov 1->Nov 4.
5. Advance PVT to Feb 4th 2013
6. Run billing. This will create a further 1x$200 MRC for Feb 4->Mar 4.
7. Use Customer Center to disconnect the deal with effective date of Feb 1. This create $200CR MRC credit for Feb 4->Mar 4 plus prorated MRC credit for $19.35CR for the period Feb 1->Feb 4.
8. Run pin_rerate for the period Feb 4 through Mar 4 for this product with 'pin_rerate -t 02/04/2013 -p products.txt -r'.

Amount due 819.35, Bill in-progress of 219.35 and adjustment of -$200
Here only an event of $200CR is applied for rerating but $200DR which was supposed to happen is not applied.

pin_rerate will create an shadow adjustment for $200CR for the event for the period Feb 4->Mar 4.
However, pin_rerate does not create a shadow adjustment for $200DR for the disconnection event for the period Feb 4->Mar 4 as the end_t for this event is Feb 1 (which is prior to the cutoff date for pin_rerate).

We know that if pin_rerate was run with a cutoff date of 02/01/2012 we would avoid this problem - but this is not an acceptable restriction. pin_rerate should always generate new and old charges for the same period regardless of the date chosen for the pin_rerate tool.

In a large billing system there will always be some events that have back-dated disconnections where the disconnect date is less than the cutoff date but a charge which has been credited has an earned start date after the cutoff date.



Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms