AMPS 2.21 Release

Revamp Dunning Process (WFAMPS-3552)

This enhancement involves a revamp of the dunning process in AMPS to improve and enhance the functionality available in ARIA. The change will see the following dunning types being introduced in AMPS:

• "ARIA-STANDARD" – the standard dunning functionality available in ARIA.
• "ARIA-CONSOLIDATE" – the new dunning functionality consolidating the dunning per billing/dunning group. This is the functionality provided by this enhancement.
• "AMPS-INVOICE" – new dunning functionality based on dunning of the individual invoices only. Is expected to be implemented in a future sprint and is NOT included in this ticket.
• "AMPS-BALANCE" – new dunning functionality based on dunning of the balance of the billing/dunning groups. Is expected to be implemented in a future sprint and is NOT included in this ticket.

The “ARIA-STANDARD” dunning functionality is based on the standard ARIA functionality currently available. This functionality will continue to be supported going forward. This is the default applied to all existing dunning configuration in AMPS.

The “ARIA-CONSOLIDATE” dunning functionality is partially based on the standard ARIA functionality, but with additional functionality implemented in AMPS. ARIA is responsible for triggering the different dunning events, which are then captured by AMPS, consolidated, and then processed as a single billing / dunning group. This prevents multiple events being triggered per subscription that are in dunning.

As part of the dunning configuration in AMPS, it is now possible to perform the following actions in individual dunning steps:

• “NONE” – no action is performed
• “EMAIL” – send a dunning notification via email. AMPS will trigger an AMPS event (DOCUMENT/0007 – Dunning Step/Action Communication), that can be picked up by other systems which then sends out the email. Identification of the email is provided in the event.
• “CALL” – initiate an outbound call to the customer. AMPS will trigger an AMPS event (DOCUMENT/0008 – Dunning Step/Action Call), that can be picked up by other systems which then schedules the call. Identification of the call group is provided in the event.
• “SMS” – send a dunning notification via SMS. AMPS will trigger an AMPS event (DOCUMENT/0007 – Dunning Step/Action Communication), that can be picked up by other systems which then sends out the email. Identification of the SMS is provided in the event.
• “NOTICE” – send a dunning notice via the document partner (same path as invoices and credit notes). AMPS will generate the document based on information available at the time of execution. The notice is then sent to the end-customer via the document partner.
• “FINAL” – send a final dunning notice via the document partner (same path as invoices and credit notes). AMPS will generate the document based on information available at the time of execution. The dunning notice will contain not only the overdue invoices and charges, but also all issued and due invoices. The notice is then sent to the end-customer via the document partner.
•  “SUSPEND” – AMPS will suspend all subscriptions linked to the billing/dunning group. Subscriptions fully paid by other invoices and payments will also be suspended. If payment is received, the suspension will automatically be lifted (within a configurable number of days)
• “TERMINATE” – AMPS will terminate all subscriptions linked to the billing/dunning group. No credit notes or other documents will be issued due to the termination.
• “FEE” – AMPS will post a dunning fee (an order-based invoice) which is immediately billed and sent to the customer. The dunning fee will also be included in future dunning notices. The timing of the dunning charge as well as the monetary value is configured with the action.

Each dunning step can hold multiple actions from the above list. All these actions will be executed for the dunning step. Each dunning step will also trigger an AMPS event (DOCUMENT/0006 – Dunning Step/Action Executed). For EMAIL, SMS and CALL actions, there will be two AMPS events triggered. For “AMPSCONSOLIDATE” the dunning process configuration in AMPS and ARIA must match with regards to the number of steps, and to the duration of each step.

“AMPS-INVOICE” and “AMPS-BALANCE” are planned enhancements that will make additional functionality available. These changes have not yet been scheduled.

The following API’s has been modified to accommodate this enhancement:

• "Manage Dunning [TitleManageDunning]": This existing API has been modified to allow callers to oversee the overall dunning configuration in AMPS and set up dunning actions.
• "Retrieve Dunning [TitleRetrieveDunning]": This existing API has been updated to enable callers to access information regarding dunning processes, including dunning steps and actions.

Improve PRICE-MODEL handling (WFAMPS-4291)

This enhancement improves the handling of PRICE-ADJUST and PRICE-PERIOD price model plans. Before the enhancement new rates were applied several days before the next invoicing. This caused issues when updating the subscription, for example with regards to cancellation and replacement. Also, credit and reissue of invoices caused invoices to be issued with the wrong rates.

The solution has now been changed to use pending invoice functionality in ARIA. Any accounts where at least one of the subscriptions are on a price model plan will have pending invoices automatically turned on. New invoices are then created in pending, which triggers an ARIA event, which is captured by AMPS, and then checked. If required, the rates are updated, and if necessary, the pending invoice is recalculated with the new rates. If no rates were changed, then the pending invoice is automatically approved and sent to customers.

In “Manage Subscription [SubsManageSubscription]” checks have been added to ensure that the correct rates are applied before cancellations and replacement actions. “Manage Document [DocmManageDocument]” has similarly been changed to set the correct rates before issuing a new invoice. There are no changes to the JSON schemas.

Invoice Details in Recurring and Onetime payment requests (WFAMPS4369)

This enhancement to the AMPS Managed Payment Gateway functionality allows the client to send invoice lines to the external payment gateway for inclusion in statements and other documents sent by the payment gateway provider to the end-customer.

The JSON schemas for the “Collect Recurring Payment [PaymGWCollectRecurringPayment]” and “Collect Onetime Payment [PaymGWCollectOnetimePayment]” have been updated with a reference to PaymGWCollectPaymentInvoiceDetails which contains information on the invoice triggering the payment collection, including information on each invoice line.

To enable invoice details in the payment collection the payment gateway must be configured to “INCLUDE” the invoice lines. The default configuration is “EXCLUDE” which indicates the invoice lines are not included. To configure the payment gateway, the database table must be updated. To achieve this, please contact customer support.

To use this new feature the most recent JSON schema must be deployed by the client for both API’s.

Allow billing groups without dunning Process (WFAMPS- 4377)

This enhancement has been implemented to allow clients to create dunning groups without setting a dunning process. Creating the dunning group without a dunning process prevents ARIA from executing dunning on subscriptions linked to the dunning group. To prevent the dunning process from being set the configuration in “Dunning Selection [TitleDunningSelection]” must be configured accordingly. The following API’s has been modified for this enhancement:

• “Manage Subscription [SubsManageSubscription]” – when adding a new subscription, it is now possible to create the dunning group without a dunning process.
• “Manage Billing Group [AcctManageBillingGroup]” – when adding or modifying a billing / dunning group, then it is possible to prevent the dunning process from being set.
• “Manage Title Details [TitleManageDetails]” – when updating the dunning selection for a title, the API now allows the dunning process to be empty.

There are no changes to the related JSON schemas.

Attach a payment reference on refunds (WFAMPS-4395)

This enhancement has been implemented to allow clients to provide an additional note on a refund. The note is passed through AMPS and provided in the files sent to banks or other financial institutions. The note has been added to paymManageRefundInfo as refundNote, and this attribute can be provided on refund creation, or later modifications. Once the refund has been approved, the note can no longer be updated.

The refundNote has been made available in the following API’s:

• “Manage Refund [PaymManageRefund]” – allows the caller to set and update the refund note.
• “Retrieve Refund [PaymRetrieveRefund]” – allows the caller to view a previously set refund note.

To use this new feature the most recent JSON schema must be deployed by the client for both API’s.

Return invoice details when creating a subscription (WFAMPS-4408)

This enhancement has been implemented to provide details on the initial invoice created immediately as part of the subscription creation via “Manage Subscription [SubsManageSubscription]” API. If an invoice was produced by the API call, the structure subsManageSubscriptionInvoiceDetails will contain the invoice number, billing group number, billing group ID and the invoice total incl. VAT.

To use this new feature the most recent JSON schema must be deployed by the client.

Improve logging and error handling in ERP processing (WFAMPS- 4444)

This enhancement has been implemented to provide additional logging in the STAMPEN ERP process. The logging has been implemented to assist with troubleshooting and general management of the progress. Logging has been added in the following situations:

• When the process starts, showing process ID, start date, end date and optionally the account number. • When the process ends, showing process ID, start date, end date and optionally the account number. The outcome of the processing is also included.
• Immediately before deleting existing postings from staging table.
• Immediately after deleting existing postings from staging table.
• Immediately before starting the process of invoices, payments, credit notes, refunds, and unmatched payments.
• Immediately after completing the process or invoices, payments, credit notes, refunds, and unmatched payments.
• When processing invoices, payments, credit notes, refunds and unmatched payments, the process also outputs the number of objects found (invoices, payments, etc.), as well as progress messages for each 1000 objects processed.
• When producing the XML and Excel file for the generated postings, log entries are produced to indicate the progress of the production.

Expose additional MPI statuses in SubsManageSubscription (WFAMPS4451)

This enhancement has been implemented to allow clients to set the status of a subscription to several new status codes, such as “Suspended [-1]”, “Cancelled [-2]”, or “Terminated [-3]”. The API “Manage Subscription [SubsManageSubscription]” has been changed to allow the new status codes.

Note that setting status codes to “Suspended [-1]”, “Cancelled [-2]”, or “Terminated [-3]” does not create any prorated charges, credit notes, service credits or similar. The process only sets the status code of the subscription.

To use this new feature the most recent JSON schema must be deployed by the client.

SPECIFIC-DATE cancellation creates prorated-invoice for incorrect amount (WFAMPS-3887)

This application fix resolves an issue in “Manage Subscription [SubsManageSubscription]” where the user is being overcharged due to a SPECIFIC-DATE cancellation which is initiated after a PRICE-PERIOD action has been recorded in ARIA but before the next invoice is generated. The issue is remedied by applying the new rate only from the subsequent billing cycle after cancellation, aligning with the expected behavior and preventing overcharging.

There are no changes to the related JSON schemas.

Implementation of “Service Credit Status Check (WFAMPS-4213)

This application fix resolves an issue by checking the status of service credits raised in ARIA, but for some reason left unapplied, or where conversion to a credit note was not carried out. The process will check the service credits and check each one to see what action needs to be taken. The action to take is manually handled by the client.

AMPS events not sent for address holds (WFAMPS-4346)

This application fix resolves an issue where AMPS events for address holds were not sent as expected. To fix the issue a new “DISTRIBUTION/0007 – Delivery Held” has been introduced. This event is triggered when the user requests a temporary hold on newspaper delivery.

Records from BGMax Files stuck in READY (WFAMPS-4347)

This application fix resolves an issue where records received from Bankgirot for BGMax files were stuck in READY state due to other failed records. This problem has been fixed so that valid records are processed to completion and only the failed records are retained in the staging tables.

Posting of unmatched payment fails (WFAMPS-4372)

This application fix resolves an issue where approved unmatched payments are correctly posted against ARIA as payments, but they are marked in the unmatched payment database as FAILED, potentially causing the unmatched payments to be duplicated. Additional logging has been introduced to better monitor the issue.

Incorrect Credit Memo Calculation (WFAMPS-4376)

This application fix resolves an issue where products using tax-inclusive rates were not handled correctly. This problem has now been corrected and products with tax-inclusive or tax-exclusive rates are now processed and calculated correctly.

Include ALL write-off transactions (WFAMPS-4389)

This application fix resolves an issue in the “JFM ERP process” where write-off transactions having certain reason codes were not included in the ERP files. This has now been corrected, and ALL write-off transactions are now included in the ERP file for the date the write-off was raised.

Subscription update deletes Name and reference (WFAMPS-4390)

This application fix resolves an issue in “Manage Subscription [SubsManageSubscription]” where SubjectName, SubjectID, and SubjectInfo were inadvertently reset to empty fields. This problem has now been corrected, and the values remain in the supplemental fields on the subscription until specifically removed by the caller.

There are no changes to the related JSON schemas.

ERP incorrectly handles credits on tax lines (WFAMPS-4406)

This application fix resolves an issue in the “STAMPEN ERP process” where discounts were applied on taxes. This problem has now been corrected and periods and values are now correctly applied.

Cancellation event sent twice with different payload (WFAMPS-4441)

This application fix resolves an issue where the AMPS event “SUBSCRIPTION/0006 – Subscription Cancelled” was sent twice for the same cancellation, but with different values. The problem has now been resolved and only a single event will now be triggered.

Contract still in effect after removal of a Future Cancellation (WFAMPS4442)

This application fix resolves an issue in “Manage Subscription [SubsManageSubscription]” where future contracts for the cancellation were not removed even though the cancellation was removed. This problem has now been corrected and any future changes in ARIA will be removed if the future date cancellation in AMPS is removed.

There are no changes to the related JSON schemas.

Attempting to ADD new locales in AMPS (WFAMPS- 4443)

This application fix resolves an issue when adding new locales using “Manage Locales [SolmManageLocales]” when certain values were omitted. The API has been changed to allow special characters, hyphens, and blanks between words, but the fields cannot be completely empty.

There are no changes to the related JSON schemas.

Credit note postings not included in ERP as expected (WFAMPS-4446)

This application fix resolves an issue with the “POLARIS ERP Process” where credit note postings were not included in the ERP file as expected. The process has now been corrected to include all relevant credit note postings.

Tax details not found for TaxGroupID ZERO (WFAMPS-4448)

This application fix resolves an issue in “Manage Subscription [SubsManageSubscription]” when a subscription is added on a product that uses tax group “Zero VAT [ZERO]” and this tax group is not configured in AMPS. The problem has been resolved by adding the missing tax group as well as introducing a change to the API, that, in case the country code is not provided, will automatically revert to the default country code configured in system parameter “AMPSDomesticCountry”.

There are no changes to the related JSON schemas

Invoice XML document failed processing (WFAMPS-4459)

This application fix resolves an issue with the “Produce AMPS XML [DocmProduceAMPSXML]” process where surcharges did not have the supplemental field “ChargeType” set. As it is not possible to set the supplemental field for a surcharge in ARIA, a change has been introduced that automatically defaults to “CHARGE” when processing a surcharge invoice line.

No cancellation Credit note (WFAMPS-4462)

This application fix resolves an issue in “Manage Subscription [SubsManageSubscription]” where a credit note was not produced as expected. The problem was caused by an exception in the workflow. The problem has now been corrected, and credit notes are created as expected. There are no changes to the related JSON schemas.

Change in CREDIT periodization in ERP (WFAMPS-4486)

This application fix resolves an issue with the credit note periodization in “JFM ERP Process”. Previously the entire credit note was periodized based on the dates from the invoice, however for partial credit notes this was not correct. A change has therefore been introduced to periodize full credit notes and partial credit notes differently. A full credit note is still periodized over the full invoice period, while partial credit notes are now periodized over the period from the credit note date, until the end of the invoice period.

Complaint eligibility returns ineligible for all days (WFAMPS-4512)

This application fix resolves an issue with “Check Complaint Eligibility [CompCheckComplaintEligibility]” where users were unable to create complaints for past delivery days, as all days were reported as being ineligible for complaint. This has now been resolved and eligibility is correctly returned to the caller.

There are no changes to the related JSON schemas

ERP process missing check on migrated invoices (WFAMPS-4514)

This application fix resolves an issue with the “JFM ERP Process” where all migrated invoices were included in the daily ERP files. This problem has now been solved and any invoice found in AMPS that has an invoice status reason beginning with MIGRATION will not be included in the daily ERP processing.

Duplicate accounts in AcctSearchAccountV2 (WFAMPS-4517)

This application fix resolves an issue where duplicate accounts where returned by “Search Account V2 [AcctSearchAccountV2]”, when searching on attributes such as street name, postal code, email, etc. This issue has now been fixed, and the API correctly returns a single instance of each account found.

There are no changes to the related JSON schemas.

Update ERP process to reference new fields (WFAMPS- 4521)

This application fix resolves an issue with the “STAMPEN ERP Process” were exceptions were encountered under certain conditions. The problem was caused by attributes no longer being available in the ARIA API “get_invoice_details_m”. The referenced attributes had been deprecated and could no longer be used. The problem has been fixed by referencing new attributes available in the API call

ERP references wrong fields from get_invoice_details_m (WFAMPS-4522)

This application fix resolves an issue with the “POLARIS ERP Process” were exceptions were encountered under certain conditions. The problem was caused by attributes no longer being available in the ARIA API “get_invoice_details_m”. The referenced attributes had been deprecated and could no longer be used. The problem has been fixed by referencing new attributes available in the API call