Exceptions Screen

Last verified with: 10.8.6.0

Overview #

The Exceptions screen is used to review usage records that could not be rated successfully. When mediated usage reaches the rating process and the system cannot complete rating, the usage is grouped by exception type and displayed here for operational review.

This screen helps administrators understand what kind of rating issue occurred, how many records are affected, and whether the issue should be reprocessed or reported on. After the underlying cause of the exception has been addressed, the exception records can be scheduled for reprocessing from this screen.

Selecting an exception type displays the exception description and a summarized list of affected records on the right.

Prerequisites #

Usage must be mediated before it can be rated. If mediation is not occurring successfully, there will be no usage available to rate and therefore no rating exceptions to review here.

UDR Exceptions Panel #

The UDR Exceptions Panel on the left lists the available exception types together with the number of current records in each type. This panel is used to identify which rating problems are currently occurring most often and to open the related exception summary on the right.

Selecting a row with a count greater than zero loads the related exception summary into the Edit UDR Exception Panel.

Actions #

Icon	Description
	reloads the exception list and clears the current screen filter
	Opens the scheduling dialog used to queue exception records for reprocessing or deletion after the underlying issue has been reviewed.
	Opens the report dialog used to regenerate a CSV report for the selected exception type

Edit UDR Exception Panel #

The Edit UDR Exception Panel shows additional information for the currently selected exception type. This area is used to understand what the exception means and to review a summarized breakdown of the affected records.

If the selected exception type currently has no exception rows, the screen displays an empty-state message instead of the exception grid.

Fields #

• Description: explains what the selected exception type means and what kind of rating problem caused the usage to be placed in exception.

Exceptions Tab #

The Exceptions tab displays a summarized list of exception activity for the selected exception type. This tab helps users identify which accounts and dates are contributing to the exception count before drilling into the detailed exception records.

Each row in the grid represents a summarized exception grouping and can be opened to view the individual exception records behind it.

Grid Fields #

• Date: shows the usage date associated with the summarized exception group.
• Account: shows the related account when the exception can be associated to a specific account. If the exception is not linked to an account, the grid shows N/A.
• Count: shows how many exception records are included in the summarized row.
• Details: opens the detailed exception view for the selected row.

Opening Exception Details #

Select a row in the Exceptions tab and open its details when you need to review the specific records that failed rating.

The detail view is used to inspect the individual exception items behind the summarized row, including values such as account, usage identifier, created date, last rating attempt, and exception-specific messages.

The detail screen also includes a Back To Exceptions option so you can return to the exception summary screen after reviewing the detailed records.

Reprocessing Exceptions #

Use Reprocess after the root cause of the rating issue has been corrected.

The scheduling dialog allows you to control how the exception records should be handled and when the request should run.

The dialog supports filtering the reprocessing request by one of the following scopes:

• Account: limits the reprocessing request to a specific account.
• Rate Plan: limits the request to exceptions associated with a specific usage rate plan.
• Usage Identifiers: limits the request to one or more specific usage identifiers.

The dialog can also be used to define:

• Schedule Start: when the reprocessing job should begin.
• Start Date: the beginning of the exception date range to include.
• End Date: the end of the exception date range to include.

After submission, the system queues the request for processing at the scheduled time.

Generating An Exception Report #

Use Generate Report when you need a downloadable CSV of the current exception set for investigation, operational review, or sharing with another team.

The report request can be filtered by:

• Exception Type: the selected exception category.
• Start Date and End Date: the date range of exception activity to include.

When the request is accepted, the report is generated through the reporting system and made available as an on-demand CSV output.

Usage exception types #

This reference lists the usage rating exception types available in LogiSense Billing and explains the most common reasons they occur.

Exception Type	Description	Common Reasons This Can Happen
Identifier Not Found	The usage identifier does not exist in the system.	The usage record references an identifier that is not attached to an active account service. This often happens when the identifier has not been provisioned, was entered incorrectly, or does not match the value sent by the upstream source system.
Identifier outside of Date Range	The usage identifier was found, but the usage date does not fall within an active service period.	This can happen when usage arrives before service activation, after service cancellation, or during a gap caused by an effective-date change.
Rate Not Found	A matching rate could not be found or applied to the usage record.	The required rate may be missing, inactive, expired, or not aligned with the usage class, unit type, tier, or other rating conditions required for the record.
Rate Group Not Found	A matching rate group could not be resolved for the usage record.	Common causes include a currency mismatch, date mismatch, unresolved rate-group condition, or missing group configuration for the account or service being rated.
Rate Plan Not Found	A usage rate plan could not be resolved for the record.	This usually points to missing rate-plan assignment on the account package or service, missing product configuration, or a date/context mismatch that prevents the plan from being selected.
Identifier Found for cancelled service	The identifier exists, but it belongs to a cancelled service.	This can happen when usage continues to arrive after the service has been cancelled, or when cancellation dates do not line up with the dates on the incoming usage.
Data Load Error	Required data was not available when rating was attempted.	Supporting rating data may be incomplete, missing, or temporarily unavailable. This can include related setup records or dependencies needed to evaluate the usage correctly.
Unable to Rate due to misconfiguration	The usage could not be rated because related setup is not configured correctly.	This may be caused by incomplete or conflicting configuration, missing required values, or unsupported combinations of rating setup.
Data Load Caching Error	Required cached data was not available or could not be resolved correctly.	This is similar to a data load error, but is related to cached configuration or lookup data. It can happen when configuration changes are not reflected in the data available to the rating process.
No Dynamic Usage Class Rule for Mediated Usage Class Type	The mediated usage class type does not match any configured dynamic usage class rule.	The incoming usage class type may be valid, but there is no rule that maps it to the expected dynamic usage class.
Missing Mediated Custom Field for Dynamic Usage Class	The usage record is missing the mediated custom field required for dynamic usage class processing.	This usually means the import or mediation process did not populate a custom field that the dynamic usage class rules depend on.
No Dynamic Usage Class Rule for Mediated Custom Field value	The mediated custom field value does not match any configured dynamic usage class rule.	The custom field exists, but its value is not represented in the current rule set. This can happen when a new or unexpected value is received from the source system.
UDR Terminating Identifier not in Geo Tree	The terminating identifier could not be matched to the GeoTree.	This usually means the terminating number or identifier does not match any configured GeoTree pattern, location, or location group.
No Class Dynamic Rule matching the Location Group	A location group was resolved, but no dynamic usage class rule matched it.	The location information may be valid, but the related rule set does not include a matching rule for the resolved location group.
Cannot Resolve Tax Code	A tax code could not be determined for the account service.	This is often caused by missing or incomplete tax setup, such as missing account tax category, service tax category, or tax-code mappings.
UDR Tax resolving to Multiple Tax Vendors	More than one tax vendor matched the same usage record.	This can happen when tax configuration overlaps or when the account and service setup allow multiple vendor paths where only one should apply.
Tax Configuration Issue	The usage record could not be taxed because tax configuration is incomplete or invalid.	This may involve missing vendor setup, missing jurisdiction resolution, missing categories, or invalid tax mappings needed for usage taxation.
Missing or Invalid Identifiers	The identifiers needed for tax processing are missing or invalid.	This can include originating or terminating identifiers, address-related values, or other tax-driving fields required to determine the correct tax treatment.
Future Dated UDR.	The usage record is dated in the future and cannot be processed yet.	This usually means the source system sent a future-dated usage record, the record timestamp is incorrect, or date and time handling caused the usage to appear later than expected.