Backdating Subscription Actions

About Backdating Subscription Actions

Subscription actions backdating lets you perform certain subscription actions so that the operations take effect on a prior date instead of the date it occurred. You can perform subscription backdating operations to rectify errors committed while performing subscription operations.

For example, you might want to backdate a subscription operation when:

A customer requests a charge offer cancellation on October 30, but the cancellation is not recorded in the BRM system until November 15. The customer is charged for the period of October 30 to November 15.
A customer requests a charge offer purchase on January 1, but the purchase date is entered in the BRM system as February 1.

BRM supports the following subscription backdating operations:

Backdated account creation.
Backdated account and service status change. See "About Backdated Status Change".
Backdated charge offer, discount offer, or bundle cancellation. See "About Backdated Charge Offer, Discount Offer, or Bundle Cancellation".
Backdated charge offer or discount offer purchase, usage, or cycle start and end date.
Backdated remaining charge discount offer purchase, cancellation, and modification if the proration options are set to Prorated discount. See the discussion of proration options in BRM Creating Product Offerings.

You can perform subscription backdating by using one of the following methods:

By using Billing Care.
By using Customer Center.
By passing the backdated date in the PIN_FLD_END_T field of the corresponding subscription opcodes.

To backdate a charge offer, discount offer, bundle, or package purchase, use the PCM_OP_SUBSCRIPTION_PURCHASE_PRODUCT opcode. See BRM Opcode Guide.

About Backdated Status Change

BRM supports backdating the status change of a charge offer, discount offer, service, or account to a prior date.

BRM does not allow backdating the status change in the following situations:

The backdated date is prior to the G/L posting date. See "About Backdating Beyond the G/L Posting Date".
The backdated date is prior to the effective date of the account, service, charge offer, or discount offer. See "How Effective Time Is Used to Validate Backdating Operations".
The backdated date is prior to the date of the last status change. You can backdate any status change only up to the date the last status change happened; undoing previous status changes is not allowed.

For example, if you change the status of an account from active to inactive on September 1, you cannot backdate a status change on October 1 to a date prior to September 1.

How Cycle Fees are Calculated for Backdated Status Change

When you backdate the status change, a charge or a refund is applied for the backdated period.

For example, consider that on July 1, you backdate the status of an active account to make it inactive effective from June 1. If the cycle fee is already applied for the period of June 1 to July 1, another cycle fee event is generated that calculates and refunds the charges.

You must rerate any usage events that have occurred in the backdated period to account for the status change.

About Backdating Beyond the G/L Posting Date

BRM does not allow backdating beyond the G/L posting date. When you post a G/L report, you prevent backdating adjustments, write-offs, or subscription transactions, prior to the last date you posted the G/L report. This maintains general ledger data integrity. After they are posted, the G/L report updates the /data/ledger_report object. This object records the date of the latest posted G/L report and controls transaction backdating.

You can run G/L reports at any time without posting data. When you do not post data, backdating is not affected.

How Effective Time Is Used to Validate Backdating Operations

BRM does not allow backdating if the date to which you want to backdate the operation on an account, service, charge offer, or discount offer is prior to the respective effective dates (creation dates).

Rerating of Events for the Backdated Period

Backdated purchase or cancellation of a charge offer or discount offer automatically triggers rerating. In these cases, BRM uses event notification to create rerate jobs that rerate the events in the charge offer or discount offer. In all other subscription backdating scenarios, you must either run rerating manually or configure BRM to created rerate jobs automatically.

For example:

You might manually need to rerate the usage events that had been rated prior to the backdating action.

For example, on October 15, a usage event for a charge offer is charged at $2.00 per minute. On November 1, a new charge offer is purchased backdated to September 1. The new charge offer has usage pricing of $1.00 per minute and has a higher priority than the first charge offer. In order for the usage that occurred on October 15 to get rated with the new charge offer, you must rerate the usage events manually.
If you backdate the cancellation of a shared discount offer, you will need to rerate the accounts or services in the group, because the accounts or services might have used the discount offer.

You can configure BRM to rerate backdated operations. See "Configuring Rerating" in BRM Rerating Events.

About Backdated Charge Offer, Discount Offer, or Bundle Cancellation

The cancellation of a charge offer can be backdated as far back as the purchase date of the charge offer.

Note:

If you backdate a discount offer purchase to a date prior to the charge offer purchase date, the discount will not be applied in the bill of the current cycle. The discount will be applied in the bill of the next cycle.
If you backdate the purchase of a discount offer on a cycle forward or cycle arrears event to a previous accounting cycle, the discount offer will be refunded only for the current accounting cycle.

BRM does not allow you to backdate the charge offer, discount offer, or bundle cancellation if:

The backdated cancellation date is prior to the G/L posting date. See "About Backdating Beyond the G/L Posting Date".
The backdated cancellation date is prior to the charge offer or discount offer's effective date. For example, a charge offer or discount offer that was purchased to be effective from January 15 cannot have any event on it backdated prior to January 15. See "How Effective Time Is Used to Validate Backdating Operations".
The backdated cancellation date is prior to the date of the last status change of the account or service.

For example, consider that you create an account on December 1. On December 10, you change the status of the account to Inactive. On December 15, you change the status of the account back to Active. You cannot backdate a charge offer cancellation prior to December 15, which is the date of the last status change.
Note:
- When you backdate the cancellation of a fold, rollover charge offer, or billing time discount, you must run rerating to apply the corrections on the events that occurred after the backdated date.
- Backdating discounts with discount offer proration options is supported only for discounts that are prorated.