Handling Usage Exceptions

Summary

This article discussed how to understand and correct UDR usage Exceptions.  In the sections Below you will find the main UDR Exception error messages and troubleshooting steps. If UDR records are being imported and the error "UUIH record(s) were found, but not in proper date range." then UUIH adjustments need to be made in the database.

UDRUser = user name Unable to find rate for pattern

• Check which UDRRatePlan is attached to the user

• Check the UDRRateGroups in the UDRRatePlan

• Check that the UDRRateGroups cover the classes needed in UDRRate table

• Determine if the class depends on the Geotree for rating or has a rate on its own

• If this class depends on the GeoTree, check for missing patterns

Missing Pattern

Issue: the pattern does not exist in the Rating GeoTree. These can be new dial patterns added or mis-dialed numbers.

Resolution: If the pattern is not a mis-dialed number, the Rating GeoTree will need to be updated to include this pattern at whichever level it should be associated to.

Steps: to add a pattern, go into the GeoTree (Setup -> GeoTree), first decide where the pattern is located and go to that location in the GeoTree, i.e., select a Continent, Country, State, Category, etc. as needed until you are at the correct level. Check to see if the pattern exists in the tree, if not click the Add button at the right bottom of the page to add the pattern. After the pattern is saved, reprocess the UDR Exceptions to rate the missed records.  See the GeoTree Configuration article for more information on modifying the GeoTree. Once we are sure the pattern is not missing, we need to assure the UDRLocation for this pattern is covered with a rate

Missing Rate in UDRRate

Issue: while the corresponding pattern exists (or you just added it), the rate for this pattern is missing.

Resolution: add the rate in the corresponding rate plan/rate group.

Steps: add the missing rate in UDR Rates under the setup page. You can also check:

• If the package is attached to the user

• The Rate plan

• The Rate group

• Rates (attached to the corresponding pattern in case the GeoTree is used)

Missing Class

Issue: the class (e.g. Inbound, toll Free) may be missing the rate for the corresponding UDRRateGroup in the UDR rates table

Resolution: add the class with the corresponding UDRRateGroup and rate in the UDR rate table.

Unable to lookup UDRUser for Identifier

This message can appear for several different reasons.

User missing in the UDRUserIdentifierHistory table

Issue: the Identifier for this user is not present (or correct) in the UDR User Identifier History table.  The UUIH table links the User to its corresponding Billing identifier, start and End dates, User Service and Rate Plan owner. The  UUIH table is in the "rating and Usage" section in the "Setup" page

Resolution: check the validity of the Identifier in the UDRUserIdentifierHistory table to map calls to EngageIP Billing.  For instance is the Identifier (DID, IMSI, etc.) on multiple accounts? Ensure there is only one match.

Steps:

1. Click on Setup

2. Click on UDR User Identifier History

3. Check the UDR User Identifier History table for the Identifier mentioned in the Exception message.  If the Identifier is missing or incorrect check that:

   • the correct and valid package is attached to the user

   • the package on the user account has a valid UDR Rate Plan

   • locate the the identifier value on the user account and ensure it is valid (what the identifier field is named and where it is located depends on your configuration.  For instance it may be a profile question tied to user-packages).

   • check the start and end dates (explained below)

Wrong Date in the UDRUserIdentifierHistory table

Issue: the Start date is after usage or End Date is prior to usage

Resolution: correct the dates in the “UDRUserIdentifierHistory table

Steps:

1. Click on Setup

2. Click on UDR User Identifier History

3. In the UDR User Identifier History table listing click on the Identifier mentioned in the Exception message

4. Check the Start and End dates and compare them to the UDR date in order to correct them

UDR Date is too far in the future, this is likely an invalid record

Issue: usage date in the raw CDR is greater than today's date by 24 hours Because UDRBillers are created for each time period, a corrupted record with a date far in the future could improperly cause the creation many UDRBillers.  So EngageIP performs a sanity check on the UDR date. If the date of the UDR is too far in the future it will be rejected (a UDR exception will be generated). The default threshold is 24h. Due to timezone differences it might be possible to get a UDR with a date up to 24 hours in the future (from the servers point of view). There are no known legitimate reasons for a record to be more than 24 hours out of date (in the future), but just in case you can change the value in the Configuration table (UDRFutureDateThreshold).

Resolution: check the validity of the CDR and its date. If it is valid, process this exception at the usage date.

Could not find pcode for user name

Issue: the tax engine is not able to identify the corresponding pcode based on the user address.

Resolution: correct / add the user address and make sure the jurisdiction code is added.

Invalid format for Release time / for BroadWorks feed

Issue: this error most often occurs when the CDR type is "long Duration" and does not contain a release time (as the call is not complete yet).  Alerts are generated for these CDRs because the call exceeded the duration threshold configured on the switch.   In this instance rating is not performed and an exceptions is generated.  Once the call is complete, another record will be sent with full details.

Resolution: no action.

UDRException Table Errors

ProcessUDR:System.NullReferenceException: Object reference not set to an instance of an object.

Sometimes an error like this can occur if bucket changes have been made on an account. To resolve this, try reprocessing these. To reprocess, you'll need to run an update query as some exceptions don't show in UDR Exceptions report: update udrexception set reprocess = 1 where id = xxxxxx

Billing Canceled Usage

If you want not to bill cancelled User Usage, then that user's Owner must have OwnerParentAccountBillingType = Bill Accounts OR Bill Accounts Using Invoicer Taxes OR Owner of that user must be in Cancelled State.

See Also

• Processing Usage Exceptions