AMPS 2.19 Release

Return scheduled price updates (WFAMPS-3965)

If a future price change was registered on a product, this information was not being made available to clients via the AMPS APIs. To address this, the following changes have been made:

• “Get Eligible Offerings [SubsGetEligibleOfferings]” – an existing API that is updated to return the future price changes in both the plan rate overview as well as the detail rate structures. The details returned are based on the information found in the product catalog for the product being offered.
• “Retrieve Product [ProdRetrieveProduct]” – an existing API that is updated to return the future price changes in both the plan rate overview as well as the detail rate structures. The details returned are based on the information found in the product catalog for the product being offered.

Both APIs are updated to return the future price changes in both the “plan rate overview” as well as the “detail rate structures”. In the “plan rate overview”, an array is added which for each date a price change has been registered, the total price for subscription, delivery, and other charges are returned. If price changes are registered for two different dates in the same product, then two entries will be returned by each API. In the “detail rate structure”, only a single future change is returned for each service within the product.

Refer to the “Integration Specification” for both API’s for details on the added information.

Enable AMPS Credit Card Expiry Event (WFAMPS-3996)

To support handling of credit card expiry events, AMPS has been changed to take the credit card expiry events generated by ARIA core and transform these into AMPS event “Credit Card Expiry [ACCOUNT/0006]”. The event contains details on the payment method, credit card, credit card type, etc. of the registered credit card. The event is triggered only for credit cards managed via an ARIA manage payment gateway like ADYEN. The event is by default triggered by AMPS.

Improvement of AMPS Search Account functionality (WFAMPS-4049)

To improve performance, the search function in AMPS has been updated. The API “Search Account V2 [AcctSearchAccountV2]” replaces the existing search function. Clients should move to the new API as soon as possible. Support will no longer be offered on the old version.

The search functionality now makes use of the account mapping table in AMPS. The mapping table is added and modified whenever an account is updated, for example with new phone numbers or email addresses. The use of the mapping table eliminates the need to use object queries in ARIA core, which in some cases cause performance issues. When anonymizing an account, the mapping information is also removed.

The new API allows the caller to search on the following criteria:

1. ARIA Account Number* - the unique ARIA generated identification of the account.
2. Client Account ID* - the client defined identification of the account.
3. ARIA Subscription Number* - the unique ARIA generated identification of the subscription.
4. ARIA Subscription ID* - the client or solution defined identification of the subscription.
5. ARIA Invoice Number* - the unique ARIA generated identification of an invoice.
6. ARIA Statement Number* - the unique ARIA generated identification of a statement / invoice.
7. Customer Invoice Reference* - the solution generated identification of an invoice. This is the identification provided to customers for use when registering payments. It includes any relevant check digits.
8. ARIA Creditnote Number* - the unique ARIA generated identification of a credit note.
9. ARIA Creditnote ID* - the solution generated identification of a credit note. This is the identification provided to customers. It includes any relevant check digits.
10. User ID – the client defined user id assigned to the account.
11. Migrated Customer ID – the client defined customer ID migrated from other systems.
12. First Name, Last Name, Full Name, Street Name, Street No, Postal Code, City, Phone Number, and Email Address – the account / billing group address and/or distribution addresses are searched. Wildcards can be used in these fields, and providing more than one attribute will only return accounts that fulfill all criteria used.
13. Taxpayer ID – the client defined taxpayer ID (VAT Number). Wildcard search is used.

Criteria marked with “*” will return only a single account to the caller, and the criteria cannot be combined with other criteria to restrict the search.

When deploying this version of search, a process must be run to populate the account mapping table. The process “Refresh Account Mapping [ScriptRefreshMapping]”, must be run before using the new search API. If not, the search API will not be able to find any accounts.

RESEND can RESET Dunning Step (WFAMPS-4066)

This enhancement adds the ability to control whether the “Credit and Reissue” function automatically resets dunning steps and status of a subscription. Currently the function does not reset the dunning steps, causing the ARIA to restart dunning from the step currently set, even though a new invoice has been produced.

A new global parameter "Credit and Reissue resets Dunning State [DocmCreditReissueResetDunning]" has been introduced to control whether the current functionality or the enhanced functionality is used. The following options apply:

•            “TRUE” – if set to TRUE, then the credit and reissue function will automatically reset the dunning steps.

•            “FALSE” – if set to FALSE, then the credit and reissue function will NOT reset the dunning steps. This is the current and default option.

Improve ANNIVERSARY replace action process (WFAMPS-4139)

This enhancement adds the ability for the caller to control the process when executing an ANNIVERSARY re-place¬ment. Currently the process will schedule the ANNIVERSARY replacement after the last invoice issued to the customer. The enhancement will bring the functionality more in line with the ANNIVERSARY cancellation process where the payment status of invoices controls the timing of the action.

A new global parameter “Anniversary Replacement Date Rule [SubsAnnReplaceDateRule]” has been introduced to control the AMPS behavior. The following options apply:

•            “ANY” – the ANNIVERSARY replacement will be scheduled to take place after the latest issued invoice. An example is where two invoices have been issued with the first covering 01/AUG/2023 through 31/AUG/2023 and the second covering 01/SEP/2023 through 30/SEP/2023 then the replacement will be scheduled to take place on 01/OCT/2023. This is the default option.

•            “PAID” – the ANNIVERSARY replacement will be scheduled to take place after the latest paid invoice. An example is where two invoices have been issued with the first PAID invoice covering 01/AUG/2023 through 31/AUG/2023 and the second UNPAID invoice covering 01/SEP/2023 through 30/SEP/2023, then the replacement will be scheduled to take place on 01/SEP/2023, and the second invoice covering September will be credited in full.

If required, the above parameter can be overridden by specifying the parameter ChangeOption in the “Manage Subscription [SubsManageSubscription]” call to REPLACE a product. If used, the parameter provided here overrides the global parameter. Refer to the “Integration Specification” for further details.

Add support for clean-up of unused addresses (WFAMPS-4144)

This enhancement adds the ability to clean-up and remove unused and historical addresses from AMPS. The process removes unused addresses from an account and deletes any historical addresses that are no longer relevant. To control the processing, two global parameters have been introduced, namely:

• “Remove Unused Addresses Days [DistRemoveUnusedAddrDays]” - a parameter used to determine if unused and inactive addresses older than the number of days specified are to be removed from AMPS or not. A value of 90 days would result in any unused or inactive addresses older than the current date less 90 days to be removed. 0 (zero) indicates that unused or inactive addresses are never removed. 0 (zero) is the default setting.
• “Remove Historical Address Changes Days [DistRemoveUnusedAddrDays]” - a parameter used to determine if historical address changes older than the number of days specified are to be removed from AMPS or not. A value of 90 days would result in any historical address changes older than the current date less 90 days to be removed. 0 (zero) indicates that historical address changes are never removed. Address change records that are current are NOT removed even though they have been created before the cutoff time. 0 (zero) is the default setting.

The two new responsible for removing addresses are scheduled to run monthly. The processes are:

• “Remove Historical Address Changes [DistRemoveHistoricalAddrChg]” - a process that removes all address changes registered in AMPS that are no longer active, i.e., the address change has been superseded by another address change, and the address change covered a date prior to the configured parameter.
• “Remove Unused Addresses [DistRemoveUnusedAddr]” - a process that removes all addresses registered in AMPS that are no longer in use by any address change records. The addresses would be physically removed from the system. If the address number is referenced by an address change record, it will NOT be removed.

Add card type to AcctManageBillingGroup API (WFAMPS-4150)

This enhancement adds the ability to register the type of card on a billing group. The card type can be provided when adding or modifying a billing group. The ability to register the card type applies only when the billing group is defined as a “Methods” billing group and holding a payment method, with a credit card or tokenized credit card. The ability applies only when using an ARIA managed payment gateway.

In the API “Manage Billing Group [AcctManageBillingGroup]” API a new parameter cardType to has been added to the request. This parameter will be used for ADD and MODIFY action only and will pass on card type information if provided. If the cardType attribute is not provided, then card type will not be sent to ARIA when creating the payment method and ARIA will obtain the card type from the payment gateway, if possible.

Improve Address Management APIs (WFAMPS-4165)

This enhancement adds additional information to the distribution address management in AMPS. The following attributes have been added to “Distribution Address [DistAddr]” table:

• Address Create Date – the date the address was first captured in AMPS must be stored.
• Address Status – the status of the address, for example ACTIVE or INACTIVE.
• Address Status Date – the date the address was last set as either ACTIVE or INACTIVE.
• Address Title Code – the title code used when the captured address was validated with external the external distribution partners.

The following APIs has been enhanced to use the additional information:

• “Manage Address [DistManageAddr]” – the API used to create, modify, and remove addresses in AMPS.
• “Retrieve Address [DistRetrieveAddr]” – the API used to retrieve address information from AMPS.

Refer to the respective “Integration Specification” for details on the changes to the API.

HOLD on a single subscription for RETAILER account (WFAMPS-4201)

This enhancement adds the ability to control address changes for a “Retailer” account. In this scenario, the “Stop Delivery” message sent to DIMAPS, automatically stopped delivery for all subscriptions on the retailer account, rather than just the one that was updated. The process in AMPS responsible for creating the “Stop Deliver” message to DIMAPS has been modified to correctly set the number of units for all days of the week, and only set the one being put on hold to 0 (zero).

Evaluate documents produced by SPECIFIC-DATE cancellation (WFAMPS-4210)

This enhancement adds the ability to better control the financial documents created during a SPECIFIC-DATE cancellation. Currently, if the cancellation date selected is within the billed periods, the process will credit the current invoice and any future invoices in full, and then reissue the latest prorated invoice.

A new global parameter “Specific Date Document Creation Rule [SubsSpecificDateDocumentRule]” has been introduced to control the AMPS behavior. The following options apply:

• “REISSUE” - the current method of crediting the current invoice in full, crediting any future invoices in full, adjust the anniversary date, create the proration contract, and then reissue the final prorated invoice is used. This is the default option.
• “CREDIT” - the new method of handling specific-date cancellation will see any future invoices credited in full, adjust the anniversary date, create the proration contract, and then create a credit note with the appropriate amount covering the unused portion of the current invoice period.

“Manage Subscription [SubsManageSubscription]” has been updated to use the new global parameter, and allow the caller to override the setting via the API call by specifying the parameter ChangeOption during the cancellation. The setting in the API call takes precedence over the global parameter.

Improve ANNIVERSARY cancellation process (WFAMPS-4211)

This enhancement adds the ability for the caller to control the process when executing an ANNIVERSARY cancellation. Currently the process will schedule the ANNIVERSARY replacement after the last PAID invoice issued to the customer. The enhancement will bring the functionality in line with the ANNIVERSARY replace-ment process where the payment status of invoices controls the timing of the action.

A new global parameter “Anniversary Cancellation Date Rule [SubsAnnCancelDateRule]” has been introduced to control the AMPS behavior. The following options apply:

• “ANY” – the ANNIVERSARY cancellation will be scheduled to take place after the latest issued invoice. An example is where two invoices have been issued with the first covering 01/AUG/2023 through 31/AUG/2023 and the second covering 01/SEP/2023 through 30/SEP/2023 then the cancellation will be scheduled to take place on 01/OCT/2023. Whether the invoices are paid or not is not relevant to the cancellation. 
• “PAID” – the ANNIVERSARY cancellation will be scheduled to take place after the latest paid invoice. An example is where two invoices have been issued with the first PAID invoice covering 01/AUG/2023 through 31/AUG/2023 and the second UNPAID invoice covering 01/SEP/2023 through 30/SEP/2023, then the replacement will be scheduled to take place on 01/SEP/2023, and the second invoice covering September will be credited in full. This is the default option.

If required, the above parameter can be overridden by specifying the parameter ChangeOption in the “Manage Subscription [SubsManageSubscription]” call to CANCEL a product. If used, the parameter provided overrides the global parameter. Refer to the “Integration Specification” for further details.

PaymRetrieveRefund returning inconsistent transfer date (WFAMPS-4003)

This application fix resolves an issue where “Retrieve Refund [PaymRetrieveRefund]” returned an incorrect transfer date. This bug has now been resolved.

Unable to cancel subscription with order-based invoice (WFAMPS-4024)

This application fix resolves an issue in “Manage Subscription [SubsManageSubscription]” where it was not possible to execute a SPECIFIC-DATE cancellation on a subscription where the current invoice was an ORDER invoice (campaign invoice). This bug has now been resolved, and cancellation where order invoices are present now happens as expected.

Can't search on specific amount in payment management (WFAMPS-4047)

This application fix resolves an issue in “Retrieve Unmatched Payment [PaymRetrieveUnmatchedPayment]” where it was not possible to search on the unmatched amount. This bug has now been resolved.

Existing MPIs belonging to In-Active Plan not retrieved (WFAMPS-4063)

This application fix resolves an issue where plans marked as inactive were not retrieved by “Retrieve Product [ProdRetrieveProduct]”. This bug has now been resolved, and all products in AMPS cache are now marked correctly with ACTIVE or INACTIVE, and the expected information is correctly returned.

Creditnote not included in the postings (WFAMPS-4107)

This application fix resolves an issue in the POLARIS ERP process where credit notes were not correctly included where the associated invoice has been paid in full. This bug has now been resolved, and the credit notes are now included.

Complaints Not Sent to DI (WFAMPS-4119)

This application fix resolves an issue where “IN-PROGRESS” complaints were not processed correctly. This bug has now been resolved and “Process Complaint [CompProcessComplaint]” has been updated to automatically include any complaints marked with “IN PROGRESS” ensuring they are sent to DI.

Adding PaymentOrigin to PaymManagePayment (WFAMPS-4123)

This application fix resolves an issue where paymentOrigin was not set as required. This bug has now been fixed, and “Manage Payment [PaymManagePayment]” now allows the caller to set the paymentOrigin as required. If the value is not provided it will default to “API”.

ERP includes incorrect postings (WFAMPS-4149)

This application fix resolves an issue with the POLARIS ERP where postings were not created correctly across all different posting types. This bug has now been fixed, and the postings are created as expected.

ERP process excludes paid invoices that were credited (WFAMPS-4164)

This application fix resolves an issue with the POLARIS ERP where paid invoices were excluded from the ERP files when they were credited in full. This bug has now been resolved, and the postings are included as required.

Incorrect reference in delivery address in OIOUBL (WFAMPS-4174)

This application fix resolves an issue where the OIOUBL financial document had an incorrect delivery address included in the file. This bug has now been resolved, and the delivery address active at the invoice date is now included in the OIOUBL document.

'instCreateDate' is incorrect for subscriptions with future activation (WFAMPS-4195)

This application fix resolves an issue where “Retrieve Subscription [SubsRetrieveSubscription]” returned incorrect values in instCreateDate (subscription creation date) when the subscription has a future activation date, and that date has not yet been reached. This bug has now been resolved, and instCreateDate is returned correctly either based on the activation date registered, or the future date.

Contract created for plan cancelled on next bill date (WFAMPS-4214)

This application fix resolves an issue where “Manage Subscription [SubsManageSubscription]” incorrectly created a contract for a cancellation. This bug has now been resolved by introducing a check to see if the cancellation date specified is the same as the next billing date. If so, the contract is not created as it is not required.

CampManageCampPrefCode not removing data from AMPS (WFAMPS-4223)

This application fix resolves an issue where “Manage Campaign Preference Code [CampManageCampPref-Code]” did not correctly remove existing data before adding new details. This bug has now been resolved, and the existing rows are now removed before re-adding them.

CampManageOfferDetail API not removing offer from AMPS (WFAMPS-4224)

This application fix resolves an issue where “Manage Offer Detail [CampManageOfferDetail]” incorrectly kept existing data when an offer was removed. This bug has now been resolved, and the API correctly removes the relevant data when removing an offer.

SubsVerifyCampaignEligibility returns wrong “Eligible” (WFAMPS-4255)

This application fix resolves an issue where “Verify Campaign Eligibility [SubsVerifyCampaignEligibility]” incorrectly returns “Eligible” where the customer was in fact “Ineligible”. This bug has now been resolved by check all campaigns linked to the account before returning “Eligible.

Invoice fees not credited on current invoice (WFAMPS-4257)

This application fix resolves an issue where “Manage Subscription [SubsManageSubscription]” during immediate cancellation did not credit the invoice fee. The bug applies only when crediting the invoice in full, in which case any charges with line type 9 (Surcharge) were not processed. This has now been resolved.

Autogiro collection file created with no records (WFAMPS-4281)

This application fix resolves an issue where an empty Autogiro Collection file was created. This bug has now been resolved, and if no records exist for the Autogiro Collection file, then no file will be created and sent. The check is performed for each title code in question.

Distribution: Start not created for future activations (WFAMPS-4285)

This application fix resolves an issue where AMPS did not create a “Start Delivery” message for future activated subscriptions. This bug has now been resolved, and “Start Delivery” messages are sent when the subscription is activated.

Autogiro Collection file not sent and status updated as "SENT" in AMPS (WFAMPS-4288)

This application fix resolves an issue where Autogiro Collection requests were marked as “SENT”, even though they SFTP transfer failed. This has now been resolved, and Autogiro Collection requests are now only marked with “SENT” once the SFTP file has successfully been transferred to the destination.

Include PaymentSource and PaymentOrigin in ERP file (WFAMPS-4298)

This application fix resolves an issue where it was not possible to distinguish payment sources and origins in the STAMPEN ERP file. This has now been resolved, and the ERP payment postings now include information on the paymentSource and paymentOrigin as shown below:

“Payment from Customer: paymentSource=[paymentSource]/[paymentOrigin]” where paymentSource and paymentOrigin are from the current payment transaction. 

ERP Issue with Credit Notes (WFAMPS-4299)

This application fix resolves an issue in POLARIS ERP process where the incorrect amount was used when posting a credit note. This has now been resolved, and the relevant amount is set correctly.

Immediate cancellation: Incorrect amount of Credit Note (WFAMPS-4300)

This application fix resolves an issue in POLARIS ERP process where service credits are incorrectly mapped to credit notes. This has now been resolved, and the service credits are correctly mapped to credit notes.

"Subscription was cancelled before this complaint" error (WFAMPS-4301)

This application fix resolves an issue where “Check Complaint Eligibility [CompCheckComplaintEligibility]” incorrectly handles the situation where the subscription was cancelled after the requested complaint date. This has now been resolved, and the process gets the status relevant on the complaint date.