AMPS 3.3 Release
Overview
Enhancements and fixes to Aria Media Publishing Suite (AMPS) for this release are described below.
Release Date
30 October 2025
- Release 3.3 Contents
- Application fixes
- ParseServiceCreditReport Mapping Missing (WFAMPS-5653)
- OIOUBL incorrect values (WFAMPS-5670)
- Restrict Multiple Complaints on the Same Date (WFAMPS-5620)
- ERP Write-Offs Handling More Than 100 Transactions (WFAMPS-5237)
- Family Subscription Downgrade Impact (WFAMPS-5199)
- Complaint Compensation Not Applied When Source ID Configured as “ANY” (WFAMPS-5503)
- Missing Extension ID in OIOUBL XML (WFAMPS-5672)
- Cancellation Status Not Syncing in CIM (WFAMPS-5745)
- Complaint with Invalid Characters Not Sent to DIMAPS (WFAMPS-5080)
- Future Cancellations Not Processed for Dunning Accounts (WFAMPS-5109)
- Refund Status Update for External Gateway Types (WFAMPS-4881)
- Family Sharing – Master and Member Status Synchronization (WFAMPS-5255)
- Invoice Type Missing in Financial Document APIs (WFAMPS-5301)
- Error During Service Credit Creation for Specific-Date Replacement (WFAMPS-5791)
- Payment Reference Mapping in FARPAY Processing (WFAMPS-5479)
- Handling Underpayments and Write-Offs (WFAMPS-4778)
- Cash Credit Not Displayed Under Invoice Specification (WFAMPS-5652)
- Application fixes
Release 3.3 Contents
Application fixes
This version sees the following application fixes deployed:
ParseServiceCreditReport Mapping Missing (WFAMPS-5653)
After the V8 upgrade, it was identified that the mappings for the flow ParseServiceCreditReport were lost. This flow is responsible for parsing reports generated from Aria and subsequently generating SC01 events that are sent to the BEM Data Platform. With the mappings missing, the flow is unable to correctly interpret the incoming report data, resulting in failed or incomplete event generation. The mappings were reinstated to restore the proper functionality of the service credit reporting and event creation.
OIOUBL incorrect values (WFAMPS-5670)
Several issues were identified in the OIOUBL XML mappings where multiple fields were populated incorrectly due to misconfigurations. These included the currency code, the unit code within the price tag, and incorrect mapping of postal address and name fields. As a result, FarPay was unable to process the XML tags as expected, causing integration failures. The fix corrected all mapping discrepancies, ensuring accurate generation of the XML. The OIOUBL generation process now functions correctly, producing fully compliant XML for FarPay processing.
Restrict Multiple Complaints on the Same Date (WFAMPS-5620)
It was identified that users could register multiple complaint types (with different CodeID) for the same plan and date. This behavior was not aligned with business rules, as only one complaint should be eligible per day. The issue was analyzed, and it was determined that the eligibility check logic in the AMPS API needs modification to validate complaint uniqueness based on both date and CodeID. Now in place, the system will prevent duplicate complaints from being registered on the same date, even if different complaint codes are used.
ERP Write-Offs Handling More Than 100 Transactions (WFAMPS-5237)
An issue was reported in the ERP write-off process where only the first 100 transactions were processed successfully when retrieving data. Any transactions beyond the 100-record limit were ignored, leaving unprocessed records in the system. To address this, the flow used to process write offs was enhanced to incorporate paging logic. The updated process now retrieves transactions in batches of 500 records per call, using an offset to continue until all available transactions are processed. This fix ensures stable and complete processing of large write-off datasets, eliminating missed entries in ERP reconciliation.
Family Subscription Downgrade Impact (WFAMPS-5199)
An issue was identified in the family subscription model where downgrading a master subscription to a type that does not allow sharing did not affect the child subscriptions. This caused inconsistencies between master and member subscription statuses. The implementation has now been enhanced to handle Specific-Date and Anniversary Replacement scenarios to ensure proper synchronization between parent and child subscriptions. When the master subscription is downgraded or replaced, the system now automatically validates all associated member subscriptions and updates their statuses as Cancelled accordingly. This ensures data consistency and accurate subscription hierarchy handling across family-sharing accounts.
Complaint Compensation Not Applied When Source ID Configured as “ANY” (WFAMPS-5503)
It was identified in production that when the Complaint Credit Setting was configured with the Source ID set to “ANY”, the system failed to apply compensation correctly if the incoming request contained a specific source value such as CSR or WEB. Although “ANY” should accepts all source types, the system did not interpret it correctly, resulting in complaints being created without corresponding compensation amounts.
The logic has now been updated to ensure that when the Source ID is configured as “ANY”, it is correctly recognized for all incoming source types. This fix ensures that complaint creation and compensation processing now function consistently, regardless of whether the request originates from CSR, WEB, or any other valid source.
Missing Extension ID in OIOUBL XML (WFAMPS-5672)
Several fields in the OIOUBL XML were populated incorrectly due to mapping misconfigurations. These errors affected key attributes such as currency, pricing, and address details, leading to issues in external system processing and failed integrations. The mappings have now been corrected to ensure accurate XML generation.
Cancellation Status Not Syncing in CIM (WFAMPS-5745)
It was observed that when a cancellation date was updated for a customer with an existing future cancellation, the old pending cancellation date was not being removed in AMPS. Although the update was correctly processed in Core, the outdated data caused a visual mismatch in CIM, where the subscription still appeared as pending cancellation even though it was already cancelled. The synchronization logic has now been corrected to ensure that once a cancellation date is modified, all outdated pending future changes are marked DELETED, maintaining consistent and accurate subscription status across Core, AMPS, and CIM.
Complaint with Invalid Characters Not Sent to DIMAPS (WFAMPS-5080)
An issue was identified where complaints containing illegal characters in the leader text caused API errors during transmission to DIMAPS. When such an error occurred, the complaint record still got stored in AMPS. Debugging revealed that sometimes a failure message in the response text without a standard ttError or ttAck field, and this case was not being handled. The flow was updated to scan the resultText for failure indicators even when no explicit error fields exist. If a failure is detected, the complaint is marked as failed, and the appropriate error log is created.
Future Cancellations Not Processed for Dunning Accounts (WFAMPS-5109)
In some cases, subscriptions that were in a Dunning status failed to process future cancellations correctly. The FutureCancellationsChangeStatusBatchJob was unable to update the status for such subscriptions, leaving them stuck in an intermediate state. To resolve this, additional logic was added to determine the system’s daylight saving context by comparing the current and server times. Based on this, the process now dynamically selects the correct date range when fetching records from the SubsFutureChanges table. Moreover, the restriction preventing updates for subscriptions in Dunning has been removed, allowing future cancellations to be applied consistently, regardless of payment status.
Refund Status Update for External Gateway Types (WFAMPS-4881)
When processing refunds where TitlePayOptionGatewayType is “External” and the refund method is “ORIGINAL”, the refund status and reason were not being set correctly. This caused confusion in downstream reconciliation and audit reporting. The fix ensures that whenever such a refund is approved and processed through PaymProcessRefunds, the correct status and StatusReason are assigned automatically. This guarantees proper tracking of external refunds and aligns them with AMPS refund workflows.
Family Sharing – Master and Member Status Synchronization (WFAMPS-5255)
The existing implementation for family subscriptions did not maintain proper synchronization between master and member statuses. When a master subscription was cancelled or terminated, the corresponding member subscriptions did not consistently reflect these changes. The logic has now been enhanced to correctly handle all status transitions, including Specific-Date Cancellations.
With this update, synchronization between master and member subscriptions is now as follows:
- Master Cancelled → Member Cancelled
- Master Terminated → Member Terminated
- Master Suspended → Member Active Non-Billable
Invoice Type Missing in Financial Document APIs (WFAMPS-5301)
It was observed that the invoice type field was returning as NULL in the responses of both DocmListFinancialDocument and DocmRetrieveFinancialDocument API calls. These values are meant to indicate whether an invoice is RECURRING, PRORATED, CAMPAIGN, or FINAL. Investigation revealed that the invoice type data exists in the AMPS database, but additional API calls to the core system would be required to populate it dynamically, which would impact performance. As per the integration guide, the field is optional, so for now it has been decided to defer implementation until the invoice type data is directly available in AMPS. This ensures system stability without performance degradation.
Error During Service Credit Creation for Specific-Date Replacement (WFAMPS-5791)
An error was encountered during specific-date replacements when generating service credits. The process attempts to loop through invoices and their unapplied service credits, but at the time of replacement, the newly created invoice has no unapplied credits. This results in an empty list being generated, causing an exception during credit memo creation. The logic has been updated to validate whether unapplied service credits exist then process them without matching it against invoice.
Payment Reference Mapping in FARPAY Processing (WFAMPS-5479)
When unmatched payments containing a Payment Bank Reference were matched, the corresponding entry in table did not reflect the same reference value under the PaymentReference field. This caused data inconsistencies when reconciling matched payments. The system has now been updated so that once an unmatched payment is linked to an account, the PaymentBankRef value is automatically assigned to PaymentReference in the PaymPaymentTrans table. This ensures accurate tracking of all payment references across matched and unmatched transactions.
Handling Underpayments and Write-Offs (WFAMPS-4778)
It was observed that when a customer made a partial payment within the defined underpayment threshold, AMPS automatically recorded a write-off for the remaining amount. However, during cancellation, this write-off was being voided before the Credit Memo was calculated and applied, which led to a shortfall in the credited amount since the customer had never paid the voided portion. To resolve this, the process was reviewed and adjusted to ensure that when invoices with partial write-offs are cancelled, the Credit Memo correctly covers the previously voided portion. This prevents customers from being suspended for minor unpaid balances and ensures accurate financial reconciliation across cancellations and refunds.
Cash Credit Not Displayed Under Invoice Specification (WFAMPS-5652)
An issue was identified where cash credits applied at the account level were not being reflected in the invoice specification despite successfully adjusting the account balance.
Specifically, when a cash credit was processed, it did not create a reference entry in the Financial Management table for the corresponding invoice. As a result, the DocmRetrieveFinancialDocuments API was unable to retrieve information about the applied cash credit. The issue has now been resolved. The system correctly updates the Financial Management table with references when a cash credit is applied. The DocmRetrieveFinancialDocumentRef section now populates as expected