AMPS 3.4 Release

Incorrect amount shown in API response for Cash Credits (WFAMPS-5829, WFAMPS-5812)

Events processing and mapping has been updated to correctly calculate and return the relevant date for Cash Credits. Previously, an issue was identified with invoices that had more than one cash credit where the <refTransAmount> in the DocmRetrieveFinancialDocument API response was incorrect for the second cash credit. A mapping issue was identified when showing the original cash credit amount in the DocmRetrieveFinancialDocument API response. These errors have both been corrected.

Performance optimization of the AcctRetrieveAccount API (WFAMPS-5628)

The AcctRetrieveAccount API previously took a lengthy amount of time to build the response for accounts that had more than 900 billing groups causing significant delays in account retrieval operations for high-volume accounts. The AcctRetrieveAccount API logic has been optimized to improve performance when handling accounts with large numbers of billing groups. After the enhancement, the response time for these high-volume accounts has been significantly reduced, ensuring faster and more efficient processing.

Invoice type is shown as “Order” for dunning fee document (WFAMPS-5879)

The FinancialDocuments XSD has been updated to include a new <DUNNINGFEE> value under the <InvoiceType> structure. This change ensures that dunning fee invoices are correctly identified and displayed with the <InvoiceType> value as <DUNNINGFEE> correcting a previous issue where dunning fee invoices were displayed with the <InvoiceType> value as "Order".

Handling of multiple requestSourceID in CompManageComplaintCodes (WFAMPS-5916)

Previously, an issue occurred when multiple request Source ID were configured for a single complaint code ID. These requests caused the CompManageComplaintCodes API to fail. The failure was due to incorrect handling of reason type validation when processing responses from the get_all_reason_codes_m API. The logic has been updated to process and validate the reason types.

Handling of multiple requestSourceID in Compliant Compensation (WFAMPS-5920)

Previously, when a Compliant Code ID was configured with both CSR and WEB as request source IDs, an error occurred leading to compliant compensation not being created for requests originating from CSR. This occurred due to incorrect handling of multiple request source IDs during the compensation creation process. The logic for compliant compensation creation has been updated to handle multiple source ID.

AcctRetrieveBillingGroup API issue when retrieving Billing Groups Details (WFAMPS-5003)

An issue was identified where billing group details were not retrieved correctly for accounts with multiple billing group configurations. In certain cases, the agreement ID for a Method-based billing group was incorrectly populated using data intended for Term-based billing groups. This issue has been resolved by correcting the mapping logic.

Handling of unapplied Service Credits During Downgrade Scenarios (WFAMPS-5933)

During replacement, system automatically converts service-credits from proration to credit memo. In cases where unapplied service credits exists due to compensation, the system attempts to convert the same to credit memo which would previously result in an error. A solution has been applied to ignore service credits that are not associated with an invoice, correcting the issue.

Incomplete response in DistRetrieveAddrChg API (WFAMPS-5518)

The API DistRetrieveAddrChg does not return address changes for all the titles when no title codes are provided, contrary to the documented behavior. Instead, it returns "Data not found" unless specific title codes are supplied. This behavior has been corrected by removing the validation that requires at least one title code. Now, when the <distRetrieveAddrChgTitleCodeList> array is empty, the service correctly returns address changes for all eligible titles.

Invalid IneligibilityReasonCode for Complaint Eligibility Check (WFAMPS-5297)

When performing a complaint eligibility check for an MPI where delivery had not yet started, the system was incorrectly returning ineligibilityReasonCode = 5. This caused a misleading error message stating that “the customer had requested a stop in delivery for the complaint date”, which did not apply to this scenario. The logic has now been corrected so that when delivery has not yet started, the eligibility check returns the most appropriate ineligibilityReasonCode = 3, indicating that the subscription does not offer delivery on the complaint date.

Reporting for Zephr Integration Errors (WFAMPS-5883)

Monitoring alerts were being triggered due to Zephr integration failures during <AccAccessListDist> event processing. When Zephr returned service errors such as 404 or 409, the corresponding events were previously marked as ERROR in the <SolmAriaEventLog> table, resulting in unnecessary alerts on the monitoring dashboard. To address this, the same events are logged in another new table within the Access Management module. In the original <SolmAriaEventLog> table, these events are now marked as COMPLETE, preventing unnecessary monitoring alerts. The detailed error information is captured in a new table under AccessManagement > AccessIntegrationErrors.

Incorrect Invoice Generated for New Subscription with Future Activation and Specific-Date Cancellation (JSA-1244, AP-46, BR-7685)

Previously, when a new subscription was created with a future start date and a specific-date cancellation was added on the same day, the system generated and sent a full-period invoice to the customer instead of a prorated invoice for the actual usage period once the account gets activated. This resulted in customers being billed beyond the intended cancellation date.

It was determined that the issue was caused by an incorrect contract type value. The contract type was previously set to type 6, which does not support prorated final invoicing in this scenario. By updating the contract configuration to type 7 (Terminate service and billing and prorate final invoice) this issue was resolved. With this change in place, the system now correctly generates a prorated invoice covering only the period from the subscription start date up to the specific cancellation date, ensuring accurate and fair billing.

SubsManageStatusBulk Processing Failure Due to Recursion Policy (WFAMPS-6019)

The SubsManageStatusBulk tool was previousy not processing all selected records. Investigation of the execution logs showed that the process was failing partway through due to a recursion policy violation. This issue has been resolved by updating the configuration of the internal flow to explicitly allow controlled recursion(“Allow Flow Start Recursion” is set to true), ensuring that the SubsManageStatusBulk tool now processes all records as expected without interruption.

Performance Improvement for Event Processing Status Reports (WFAMPS-5909)

Indexing has been added for both <SolmAMPSEventsLog> and <SolmARIAEventsLog> to correct an issue leading to the <SolmAMPSEventsLog> report to view the status of event processing not loading due to the large amount of data being processed. This issue was addressed by adding indexing to the relevant tables to increase loading speed.

Automated Distribution Log Reporting for Operational Monitoring (WFAMPS-5071)

An automated log retrieval and reporting solution has been introduced to address the large size of the data tables and their monitoring. Previously, the distribution team performed daily monitoring of distribution batches by cross-checking data from the <DistLog> and <distRTStartStopRequestLog> tables. This manual data retrieval was time-consuming and inefficient.

A scheduled report-sending flow has been implemented, driven by a configurable truth table that defines recipient email addresses and other required parameters. The scheduled job includes an Enabled/Disabled configuration option to control execution.