CostGuard Version 21.10 Details

Security lets you specify a pre-defined list of allowed IP addresses to restrict access to IDI web modules (Customer Care, Orders, Workflow, etc…). This helps ensure your employees or contractors are only accessing IDI environments from networks, work spaces, and computers that have proper security controls in place.

Note: The functionality will not be immediately available for all customers when version 21.10 is released at the beginning of October. The feature will be released for each customer over the first two weeks of October.

Current wireless retail functionality in the IDI system supports configuring devices (Handsets) by Technology Type. In doing so, the system enforces business rules for the expected serial number (Equipment ID) formats per the Technology Type (15 or 16 numeric characters maximum, no alpha characters allowed).

Some carriers now offer a home internet setup with wireless routers. These devices may use a different Equipment ID format that prevents them from being sold in POS as a traditional wireless equipment associated to a service.

To support the sale of such devices in POS Make Sale this enhancement lets you bypass handset Equipment ID restrictions by associating a retail product SKU with an equipment type created in the Inventory web module. For these retail products the Equipment ID can be up to 50 alphanumeric characters. In IDI Desktop Client and Customer Care you can view the device on the service.

If the product is returned the association is removed such that the serial number is available for use on another service.

As part of a larger effort to minimize duplicate Address Validation calls to CoreLogic, starting with 21.10:

• The Address Validation Log will display the Special District Codes that may be associated with a CoreLogic related Address Validation Request.
• The system will now support reviewing previous successful CoreLogic Address Validation Requests, made within an Environment, to use the previous response rather than re-issuing the same request. The system will attempt to match any new validation request against any previous request and/or response. The previous requests/responses that are eligible for matching must have been
  • completed since the 21.10 release
  • validated no older than the days configured by the setting Enhanced Address Validation Setting Re-validate age (Days).

Notes:

• A new SaaS Config setting must be enabled for this feature to take affect :’ADDRESSVALIDATIONMANAGEMENT/VALIDATION/MATCHPREVIOUSREQUEST’.
• Other enhancements related to this effort were previously deployed in version 21.9.

This enhancement integrates USAePay into the Payment Gateway Application (PGA) for full support of USAePay in Customer Care. This includes the ability to perform the following E-Pay transactions in Customer Care:

• Create new E-Pay accounts in Customer Care through USAePay
• Edit Credit Card and ACH E-Pay accounts
• Make Payments
• Issue a Credits

In PGA users can:

• Search for and view transactions that were initiated via Customer Care
• Configure a profile for USAePay that can be used in PGA APIs

The Calix Link E7 GPON ONT provisioning action was updated to be in line with Calix requirements. The updated action sends an empty intf xml node when the default port is set to None.

The following error occurred on some orders where a starting code was used: Order Placement web service unhandled fault and subsequent retries of the entire set of operations were successful. This caused a timeout.

To correct this, the wait time was updated to 2 minutes to give the system more time to complete before timing out. Also, other logic optimizations were added to help avoid timeouts.

Placeholder service line items were causing service number validation to start already active services which led to overlap errors.

This was only an issue in the Order Placement Web Service. CostGuard Client works correctly. This occured when a service was changed, but the number didn’t change.

The web service was updated such that the service number overlap check is skipped when the service is a placeholder and the service number hasn’t changed.

When attempting to add multiple Protection Plan MRCs in one order in CostGuard POS, only one MRC would actually be added. POS business rules prevent more than one instance of the same SKU.

The POS restriction is lifted when the SKU’s Product Class is Protection Plan. This lets multiple instances of the same Protection Plan MRC be added in the order, allowing you to add the device serial number to the corresponding MRC.

In OnlineBill under Account Management and view corporate accounts, the page was not displaying the second page of results accurately and preventing the export from completing. This occurred when working with large nested corporate account structures.

This page was updated to display the correct data. This also allows the export to complete successfully.

Security update to resolve a minor vulnerability in OnlineBill which may lead to an authorized user gaining elevation of privileges.

While attempting to run hotline treatments an error was received due to a caching issue.

This issue has been resolved in the Address Validation web service.

CostGuard 21.3 release, added a configurable setting (SendIndividualResponses) that directs provisioning jobs to handle service order responses on a per-service order basis as they finish during ongoing processing of other order responses. If this setting is not enabled, all responses are handled en masse at the end of the processing loop, once all of the service orders in that job’s run were finished.

An issue was encountered when this setting was enabled (opting to handle individual responses as they finish). The same logic to handle the responses was being used, which released ALL of the service orders for a given provisioning worker and provisioning company. As a result, after the first service order in a batch was handled, the rest appeared to be released to any other available worker. Workers then picked up service orders that are already being handled by one or, often, more workers.

The cumulative effect was a massive duplication of work spread amongst the workers that could have resulted in any or all of the following:

• more frequent errors
• more stuck orders
• longer per-order provisioning processing time

The handling flow of individual responses was updated to only release the orders for THAT service + worker + provisioning company, not ALL orders for that worker + and provisioning. Furthermore, the provisioning scripts were updated to show the time of a log entry including partial seconds. This facilitates troubleshooting and diagnosing issues where actions occur in very quick succession.

This applies to carriers that use IMP provisioning. The element <restriction-override> is declared for the element <oip-operator-configuration>; however, the value was not being serialized into the request.

This has been updated so the restriction-override value is passed correctly and matches the provider specification.

The XML to PDF operation was not logging or reporting an error when an operation failed due to a timeout. This caused an empty PDF to get generated and halted all subsequent XML to PDF operations.

The XML to PDF operation was updated with these three enhancements:

• Increased the default for the configurable timeout
• Added logging of operations that fail
• Allowing operations to continue when one fails due to a timeout

Some XML invoices created for corporate accounts had blank lines within the XML causing issues when invoices were sent to a third party print vendor.

The blank lines have been removed in the generation of the XML files allowing them to be processed correctly.