AdvancePay Rating and Billing: Grant Discount Engine

Following are some explanations of the grant discount engine logic for AdvancePay.

Discount Instance vs Discount Allocations

Discount Instance = NonUsgSvc

Discount Allocation = Shared Grant

• One time grant discounts have one SharedGrant record

• Recurring grant discounts may have multiple SharedGrant records.

Start and End Date vs Available and Expiration Date

The NonUsgSvc.StartDate is the date given to the instance of the discount assigned to the service/customer.

The NonUsgSvc.EndDate is given to the instance of the discount when it is disconnected.

• When NonUsgSvc.StartDate is equal to NonUsgSvc.EndDate (ignoring timestamps), the discount is considered inactive.

  SharedGrant.AvailableDate is the beginning date that usage can be applied to the allocated discount.

  SharedGrant.ExpirationDate is the final date that usage can be applied to the allocated discount.

• ExpirationDate is not inclusive; it means up to, not including.

Determining the SharedGrant.AvailableDate

For One Time Discounts:

• the AvailableDate is the same NonUsgSvc.StartDate

  For Recurring Discounts:

• if NonUsgSvc.StartDate is within the current bill period, AvailableDate is the same as NonUsgSvc.StartDate

• if NonUsgSvc.StartDate is before the current bill period start date, AvailableDate is the Bill Period start date

Determining the SharedGrant.ExpirationDate

One Time and Recurring are the same and based on the discount configuration in the product catalog

• Never Expires means Expiration Date = NULL

• Number of days means Expiration Date = Available Date (before grace is applied) + number of configured days (or overridden value)

• End of Bill Period means Expiration Date = Bill Period End Date

Calculating the Allocation Amount

The amount granted is determined by the discount configuration (or the discount instance overrides). It will be the amount specified unless Proportional Allocation is enabled in the configuration.

Proportional Allocation (prorating the allocation amount) only applies to recurring discounts that have a fixed (not unlimited) amount and expire at the end of the bill period. The formula to calculate the granted amount is as follows:

Granted Amount = Configured Amount * ((Expiration Date - Available Date) / (Bill Period End Date - Bill Period Start Date))

The granted amount is then rounded to whole number for minutes and occurrences and two decimal places for currency discounts.

Note

During a billing cycle change, the amount is always prorated, regardless of the configuration, to use proportional allocation.

Adding Grace Days

Grace time is added after the initial creation of Available and Expiration and the granted amount.

If the NonUsgSvc.StartDate and UsgSvc.EffectiveDate fall within the bill period, the SharedGrant.AvailableDate has the configured Start Grace days applied.

If the NonUsgSvc.EndDate and UsgSvc.DisconnectDate fall within the bill period, the SharedGrant.ExpirationDate has the configured End Grace days applied.

• The addition of Grace Days may make discount allocations appear to have a lifetime longer than what is configured in the Product Catalog

Expiring Units

There are two methods to expire units on an allocated discount amount, either

• expire units on disconnect or

• not expire units on disconnect.

  These are based on the configurable Expire Units on Disconnect option in the discount configuration.

  Expire Units on Disconnect

  • If a discount is marked as expire units on disconnect then remaining minutes not used before the disconnect date of the discount instance are considered expired.

  • The unit balance's expiration date will remain the same, but the units will get an expiration ledger row that has a post date equal to the disconnect date of the instance.

  • Leaving the expiration date as originally calculated allows for any POS return logic to correctly determine the amount of money to refund the customer.

  Do not Expire Units on Disconnect

  • If the units are NOT designated to expire on disconnect, they are still valid until their expiration date is reached.

  • Regardless of the option utilized, the minutes may still be prorated based on the configuration of the discount, which may cause changes to the Unit Balance.

  • Expire Units on Disconnect may be overridden on the discount instance level

  • Expire Units on Disconnect overrides the amount of end grace added if the discount is disconnected before the expiration date has occurred.

Initialization

The following rules are used when deciding what discounts need to be processed:

• Recurring discounts active within the bill period

• One time discounts not previously allocated that start before the end date of the bill period

• Unit balance adjustments made before the end of the bill period

• Unit balances that expire after the start date of the bill period from a previous period

Saving Results

The Grant Discount Engine saves data to the following tables.

Notes on how GDE saves its results:

• No rows for future bill periods are created

• Units Used and Units Expired are represented in different rows due to different post dates and Unit Change

SharedGrantTransaction

SharedGrantTransaction is a table in the Core database that is used by both Orders and Unit Balancing. Orders place rows into SharedGrantTransaction as a temporary way to provide unit balance with accurate information.

For example, adding a new discount to a customer will cause an Allocate row to be added to SharedGrantTransaction. This will immediately show on the Unit Balance GUI providing the customer with accurate, up-to-date information.

SharedGrantTransaction can handle the following actions:

• Allocate

• Extend

• Expire

• Adjust

  When the GDE processes a customer's usage, it will also process the SharedGrantTransaction data and "post" it. Except for Adjustments, SharedGrantTransaction provides estimates only and may not be the same as what the GDE generates.

  Credit adjustments are positive unit change values and Debit adjustments are negative unit change.

See also:

About AdvancePay