AMPS 3.4 Release
Overview
Enhancements and fixes to Aria Media Publishing Suite (AMPS) for this release are described below.
Release Date
16 January 2026
- Release 3.4 Contents
- Application fixes
- Incorrect amount shown in API response for Cash Credits (WFAMPS-5829, WFAMPS-5812)
- Performance optimization of the AcctRetrieveAccount API (WFAMPS-5628)
- Invoice type is shown as “Order” for dunning fee document (WFAMPS-5879)
- Handling of multiple requestSourceID in CompManageComplaintCodes (WFAMPS-5916)
- Handling of multiple requestSourceID in Compliant Compensation (WFAMPS-5920)
- AcctRetrieveBillingGroup API issue when retrieving Billing Groups Details (WFAMPS-5003)
- Handling of unapplied Service Credits During Downgrade Scenarios (WFAMPS-5933)
- Incomplete response in DistRetrieveAddrChg API (WFAMPS-5518)
- Invalid IneligibilityReasonCode for Complaint Eligibility Check (WFAMPS-5297)
- Reporting for Zephr Integration Errors (WFAMPS-5883)
- Incorrect Invoice Generated for New Subscription with Future Activation and Specific-Date Cancellation (JSA-1244, AP-46, BR-7685)
- SubsManageStatusBulk Processing Failure Due to Recursion Policy (WFAMPS-6019)
- Performance Improvement for Event Processing Status Reports (WFAMPS-5909)
- Automated Distribution Log Reporting for Operational Monitoring (WFAMPS-5071)
- Application fixes
Release 3.4 Contents
Application fixes
This version sees the following application fixes deployed:
Incorrect amount shown in API response for Cash Credits (WFAMPS-5829, WFAMPS-5812)
The processing of events and mapping has been updated to correctly calculate and return the relevant date for cash credits. The following issues have been addressed to enhance events processing and mapping within AMPS: An issue was identified with an invoice having more than one cash credit, the <refTransAmount> in the DocmRetrieveFinancialDocument API response was incorrect for the second cash credit. An mapping issue was identified when showing the original cash credit amount in the DocmRetrieveFinancialDocument API response
Performance optimization of the AcctRetrieveAccount API (WFAMPS-5628)
The AcctRetrieveAccount API was taking over 2 minutes to build the response for accounts having more than 900 billing groups. This caused significant delays in account retrieval operations for high-volume accounts. The API logic has been optimized to improve performance when handling accounts with large numbers of billing groups. After the enhancement, the response time for similar accounts has been reduced to less than a minute, ensuring faster and more efficient processing.
Invoice type is shown as “Order” for dunning fee document (WFAMPS-5879)
An issue was identified where dunning fee invoices are displayed with the InvoiceType value as "Order". FinancialDocuments XSD has been updated to include a new allowed value: DUNNINGFEE under the InvoiceType structure. This change ensures that dunning fee invoices are correctly identified and displayed with the InvoiceType value as DUNNINGFEE. Updated XSD is available on Sharepoint.
Handling of multiple requestSourceID in CompManageComplaintCodes (WFAMPS-5916)
An issue occurred when multiple request Source ID were configured for a single complaint code ID, causing CompManageComplaintCodes API to fail. The failure was due to incorrect handling of reason type validation when processing response from 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)
An issue was identified when a Compliant Code ID was configured with both CSR and WEB as request source IDs, compliant compensation was 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, system attempts to convert the same to credit memo and thereby resulting in an error. Fix has been applied to ignore service credits that are not associated with an invoice.
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. Fix has been provided by removing the validation requiring 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)
An issue was identified where, 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. Following analysis and feedback from Aria, 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. The fix involved updating the contract configuration to type 7 (Terminate service and billing and prorate final invoice). 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)
SubsManageStatusBulk tool was 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)
SolmAMPSEventsLog report to view the status of event processing was not loading due to huge data. This issue is addressed by adding indexing to the relevant table to increase loading speed. Indexing is added for both SolmAMPSEventsLog and SolmARIAEventsLog
Automated Distribution Log Reporting for Operational Monitoring (WFAMPS-5071)
The distribution team performs daily monitoring of distribution batches by cross-checking data from the DistLog and distRTStartStopRequestLog tables. Due to the large size of these tables, manual data retrieval has been time-consuming and inefficient. This issue is addressed by introducing an automated log retrieval and reporting solution. 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.