AMPS 2.20 Release

Manage Billing Group for Non-billable plans (WFAMPS-1888)

This enhancement has been implemented to allow non-billable subscriptions to be applied against a dedicated billing / dunning group that cannot be used for billable plans. This resolves an issue where non-billable plans are marked as suspended due to dunning on other billable subscriptions.

To meet the requirements, changes were made to allow the new non-billable billing and dunning group to be created and used in relevant situations. The non-billable billing and dunning group should not be returned as a valid billing group to use, even though validation is in place to ensure that only non-billable subscriptions can be assigned to it. When retrieving billing group information, the caller will not see the special non-billable billing group. Instead a flag is returned indicating if the billing group is found or not.

To support the creation of a special non-billable billing and dunning group, a number of configuration items must be put in place. The use of these configuration items will be fixed in the various processes in AMPS and will be used to ensure that no bills can be produced and issued. The following configuration items are required:

• Payment Term – a special payment term to be used with the non-billable billing group must be created in ARIA Core. The payment term must also be defined in AMPS. Note that the EAN number and EAN requisition numbers are NOT mandatory for the payment term. The payment term will be defined as follows (other attributes are set with default values):
  • Payment Term Name – must use the word “NONBILLABLE” to reflect the purpose
  • Payment Term ID – must use the word “NONBILLABLE” to reflect the purpose
  • Payment Term Description – suggest using “Non-billable Payment Term” to reflect the purpose
• Payment Option – a special payment option and variant must be created in AMPS to handle the non-billable billing group. The payment option and variant should be prevented from being selected by the end-user, i.e. it should not be available for selection for a title. The payment option and variant will be defined as follows (other attributes are set with default values):
  • Payment Option ID – the identification of the payment option to be assigned to the non-billable billing and dunning group. Must use the word “NONBILLABLE” as to reflect the purpose
  • Payment Option Variant – the identification of the payment option variant to be assigned to the non-billable billing and dunning group. Must use the word “NONBILLABLE” as to reflect the purpose.
  • Payment Option Name – the name association with the payment option. Suggest using “Non-billable Payment Option” to reflect the purpose
  • Payment Option Variant Name – the name associated with the payment option variant. Suggest using “Non-billable Payment Variant” to reflect the purpose.

To enable the functionality described in this enhancement new AMPS parameter has been introduced. The parameter “AMPS Enable Non-billable Groups” must be set to enable the creation and support of the AMPS non-billable billing and dunning group. If the functionality is disabled, the special non-billable groups are NOT created.

The following API’s have been changed to accommodate this enhancement:

• “Create Account [AcctCreateAccount]” – has been updated to allow the caller use the non-billable billing and dunning group. If enabled, the API will automatically create the non-billable billing and dunning group and assign the special plan to the non-billable billing and dunning group.
• “Retrieve Account [AcctRetrieveAccount]” – has been updated to, if enabled, automatically remove the non-billable billing and dunning group from the result listing billing groups. The result returned will instead show an indicator showing if the non-billable billing and dunning group are enabled or not.
• “Manage Billing Group [AcctManageBillingGroup] – has been updated to support, if enabled, the non-billable billing and dunning group. The following actions must be changed:
  • "ADD" – is prevented from adding a new non-billable billing and dunning group, i.e. a billing group using the same name and ID.
  • "MODIFY" – is prevented from modifying the designated non-billable billing and dunning group, of non-billable subscriptions.
  • "REMOVE" – is prevented from removing the designated non-billable billing and dunning group, of non-billable subscriptions.
• “Retrieve Billing Group [AcctRetrieveBillingGroup]” – has been changed to prevent, if enabled, the non-billable billing and dunning group from being returned in the result set, and therefore prevent it from being assigned by mistake.
• “Manage Subscription [SubsManageSubscription]” – has been modified to allow caller to handle the non-billable billing and dunning group, with regards to subscriptions. The following actions must be changed:
  • "ADD" - when adding a new subscription, the API allows the caller to indicate whether the new subscription should be assigned to the non-billable billing and dunning group. If the flag is not set, the caller must specify the billing and dunning group for the subscription to be assigned to. If the flag is set, the plan can only be assigned if it has an initial plan status of "ACTIVE NON-BILLABLE" or "ACTIVE TRIAL". Other statuses are not allowed.
  • "ASSIGN" - when assign an existing subscription to another billing and dunning group, a flag allows the caller to indicate whether the plan instance should be assigned to the non-billable billing and dunning group. The plan can only be re-assigned if the subscription being moved has a status of "ACTIVE NON-BILLABLE" or "ACTIVE TRIAL". Other statuses are not allowed. If the flag is not set, the identification of the billing and dunning group to assign the subscription to must be provided.
  • "REPLACE" - a subscription assigned to the special billing and dunning group can only be replaced with another plan that has an initial status of "ACTIVE NON-BILLABLE" or "ACTIVE TRIAL". As part of the REPLACE action, it will be possible to specify a new billing and dunning group to be assigned during the process. Other statuses are not allowed.
• “Retrieve Subscription [SubsRetrieveSubscription]” – has been modified to ensure, if enabled, that the special plan and associated non-billable billing and dunning group are not returned. When returning a subscription that is linked to the non-billable billing and dunning group, then a flag is returned to indicate this. No references to the non-billable billing and dunning group will be returned.
• “Manage Invite [SubsManageInvite] – has been modified to link, if enabled, the sharer member sub­scrip­tion to the non-billable billing group. If the customer decides to upgrade the member subscription to a paid subscription, then a new billing group must be assigned and the plan on the subscription will be replaced with a billable plan.

During migrations, the migration process is also changed to allow for the creation of the non-billable billing and dunning groups. The same restrictions as described above apply.

If the use of non-billable billing and dunning groups are to be enabled, then contact your client representative, as a migration step is required. The step will go through all accounts defined and create the necessary non-billable billing and dunning group and assign non-billable plans such as the special account plan to this billing group. Once turned on, it cannot be removed again.

Improve Performance of Retrieve Documents API (WFAMPS-2828)

To improve on the performance issues found in “Retrieve Document [DocmRetrieveDocument]” two new APIs have been implemented, namely:

• “List Financial Document [DocmListFinanialDocument]” – a new API that returns a list of financial documents / transactions. To improve performance the API is based on the information found in “AMPS Financial Transaction Detail [FinmAMPSTransDetail]” table avoiding the need to integrate with ARIA core using object query APIs. The API also allows the caller to manage paging of the returned result set, if it exceeds the configured limit.
• “Retrieve Financial Document [DocmRetrieveFinancialDocument]” – a new API that returns detailed information about a single invoice or credit note. The details include all details on payments on invoices, credits applied, credit notes applied as well as individual line items.

A new global parameter “Default Page Size Documents [DocmDfltPageSizeDocuments]” has been introduced to control the AMPS behavior. The following options apply:

• A parameter used to hold the default size of response sets returned by API’s in the “Document Management” component. The default is set at 100 documents in the result set.

This enhancement makes the following API’s obsolete and deprecated. Use of the API’s should be removed as soon as possible:

• “Retrieve Documents [DocmRetrieveDocuments]” – an API that returns financial transaction information based on transactions in ARIA. The API used object-query ARIA API calls which are not performance optimised.
• “Retrieve Documents Lite [DocmRetrieveDocumentsLite]” – a simplified version of the “Retrieve Documents [DocmRetrieveDocuments]” API.

Client defined Credit Memo ID (WFAMPS-4084)

This enhancement provides the ability to track and manage credit notes produced in AMPS, including providing a unique sequential reference to the credit note. The enhancement provides the following:

• Storage of all credit note details and credit note lines in AMPS. “Creditnote Details [Docm­Creditnote­Details]” contains an entry for each credit note produced, while “Creditnote Line Details [DocmCredit­noteLines]” contains a row for each credit note line item.
• Generation of unique sequential credit note ID. If required, the solution now allows the client to configure a number-series for use with credit notes, for example configuring a range like “CMnnnnnnn” where “nnnn” is the sequential number. Please work with your TAM to have this configured. If the sequen­tial credit note ID is not configured, ARIA will continue to generate an internal number identical to the credit note number.

When a credit note is raised in AMPS, then AMPS will populate the above tables, and capture the credit note ID generated by ARIA. When producing the XML for credit notes, the newly generated credit note ID is also added to the financial document in the “CreditNoteHeaderInfo” structure. The ID is also made available in relevant credit note AMPS events.

Credit note information is available in the following AMPS API calls:

• “List Financial Document [DocmListFinancialDocument]” – an API used to retrieve a list of financial documents created for an account, including credit notes.
• “Retrieve Financial Document [DocmRetrieveFinancialDocument]” – an API used to retrieve details on a financial document, including credit notes. The information returned contains general information on the credit note and as well as all the line items in the credit note.

Complaints and Redelivery File Processing stuck (WFAMPS-4102)

This application fix resolves an issue where the complaint file process gets stuck without completing successfully. The issue has been resolved by adding more logging to the process to allow better analysis of the problem going forward.

Improve performance of AccRetrieveAccessList (WFAMPS-4277)

This application fix resolves an issue with performance in “Retrieve Access List [AccRetrieveAccessList]”. The API returns the current set of access rights to the caller and involves traversing the full set of subscriptions on an account. The issue has been resolved by caching additional information in memory, and return that information when required.

Error in returning order invoices (WFAMPS-4282)

This application fix resolves an issue where one-time invoices are returned by “Retrieve Documents [DocmRetrieveDocumentsLite]” API in the incorrect. The issue has been resolved and the invoices are now returned in the correct order.

Note: The “Retrieve Documents [DocmRetrieveDocumentsLite]” has been deprecated and replaced with the API’s made available in “Improve Performance of Retrieve Documents API [WFAMPS-2828]”.

Incorrect MPI status returned for SPECIFIC-DATE cancellation (WFAMPS-4283)

This application fix resolves an issue where “Retrieve Subscription [SubsRetrieveSubscription]” returned a status of “ACTIVE” even though a SPECIFIC-DATE cancellation was in effect on the subscription.  Though this is a correct status to return, it does not provide a good customer experience. Therefore the API has been updated to returned the status text of “PENDING-CANCELLATION”, while the status is still returned as “1”.

Future changes in AMPS are not removed correctly (WFAMPS-4284)

This application fix resolves an issue where “Manage Subscription [SubsManageSubscription]” retained certain future changes and deleted others. This has now been resolved, and the API only removes the future changes directly related to the “CANCEL” or “REPLACE” being updated or added.

ADD action does not support 4 weekly billing (WFAMPS-4289)

This application fix resolves an issue where “Manage Subscription [SubsManageSubscription]” adding new subscriptions did not correctly handle the daily and weekly billing. This has now been resolved and new subscriptions using daily or weekly billing can be added.

“Invoice does not exist” error message when canceling a subscription (WFAMPS-4297)

This application fix resolves an issue where “Manage Subscription [SubsManageSubscription]” reported an error when generating the next invoice during a cancellation process. The ARIA API call returned error code 3004 which indicates that no invoice exists. However, this error should not be considered a failure, and should report an error. This issue has now been resolved.

Improving index for API Retrieve Titles (WFAMPS-4302)

This application fix resolves an issue with performance on “Retrieve Titles [TitleRetrieveTitles]” when all titles are returned. In this case, up to 60-70 records are attempted to be retrieved for each title and this takes time. Additional checks has been added to only execute the fetch statements where information does exist.

Duplicate complaint/compensation (WFAMPS-4304)

This application fix resolves an issue with “Manage Complaint [CompManageComplaint]” where it was allowed to create multiple complaints on the same subscription and title and day. This issue has now been resolved, and the caller is prevented from creating duplicate complaints on the same day. It is no longer possible to create complaints having the same complaint code on the same day.

Complaint date to be added to the Service Credit displayed on invoice (WFAMPS-4308)

This application fix resolves an issue where details on the complaint date was not included when creating a service/cash credit giving compensation to the customer. This issue has now been resolved, and the complaint date are now made available in the financial document for invoices.

Country Code not set when loading tax details (WFAMPS-4309)

This application fix resolves an issue where country code not set when loading tax details. This fix introduces enhancements to the “Load Tax Details [taxmLoadTaxDetails]” function to address specific changes required when adding new tax details based on the report received from ARIA core.

STAMPEN ERP – Handling of compensation credits (WFAMPS-4310)

This application fix resolves an issue where compensation credits were not handled correctly when producing the periodization postings for ERP. The issue was caused by the incorrect handling of taxation, which caused issued when attempting to find the service and associated tax group. This issue has now been resolved.

STAMPEN / JFM ERP – Surcharges are incorrect when payment term has been updated (WFAMPS-4312)

This application fix resolves an issue where ERP postings of surcharges are incorrect. The issue was caused by incorrect handling of the taxation of surcharges. This issue has now been resolved.

Error when cancelling subscriptions (WFAMPS-4327)

This application fix resolves an issue where the cancel action of the "Manage Subscription [SubsManage­Sub­scription]" API when the subscription is currently active on a campaign. This issue has now been resolved and the cancellation of subscriptions while on a campaign is now handled correctly.

POLARIS ERP – Incorrect "posting desc" (WFAMPS-4328)

This application fix resolves an issue where the posting description did not allow the client to differentiate between normal purchases, discounts, compensations, transport cost and surcharges. This has now been resolved, and the posting description now holds additional information representing the type of charge being processed.

Plan units not considered when calculating compensation (WFAMPS-4331)

This application fix resolves an issue where “Manage Complaint [CompManageComplaint]” did not consider the number of units purchased for a given subscription. The API allows applied a single compensation without taking the number of units into consideration. This has now been resolved.

Invoices failing to generate (WFAMPS-4335)

This application fix resolves an issue where ARIA events 1042 and 948 were failing. The issue was caused by the recent upgrade of the WSDL version for the ARIA API’s to a newer version. The “Produce AMPS XML [DocmProduceAMPSXML]” has been updated to correctly handle the change in API calls.

Subscription active in CIM but no start sent to Dimaps (WFAMPS-4337)

This application fix resolves an issue where the event date and time was changed during the processing of the 734 ARIA event. This has been resolved by ensuring that the correct status date is utilized.

AMPS Auto Write-Off Process Exception Handling (WFAMPS-4339)

This application fix resolves an issue where the “AMPS Process Auto Write-off [SubsProcessAutoWriteoff]” encountered code exceptions when processing a file. This has now been resolved by adding additional checks and controls.

Discounts with decimal values displayed incorrectly (WFAMPS-4344)

This application fix resolves an issue related to discounts with decimal values in the “Discount Details [DiscDetails]” table. The discount process has been corrected to accurately handle decimal values. This ensures that discounts with decimal precision are now correctly represented, providing users with an accurate view of discount details.

JFM ERP – Retailer accounts not to be included in ERP (WFAMPS-4350)

This application fix resolves an issue where “Retailer” invoices produced in ARIA and AMPS were included in the ERP file. This has now been resolved, and all invoices issued for accounts defined as “Retailer” accounts are omitted from the ERP processing.

Incorrect complaint compensation values recorded (WFAMPS-4355)

This application fix resolves a specific issue related to the compensation flow, particularly when the compensation type AUTO is utilized. The compensation flow has been enhanced to include title code as a criterion when determining the compensation value for the DEFAULT action. This ensures that the correct record is selected based on a more comprehensive set of criteria, preventing the defaulting on the first record and resolving inaccuracies in compensation amounts.

POLARIS ERP – Discount posted wrong in postings (WFAMPS-4361)

This application fix resolves an issue where credits created due to discounts, coupons, etc. are to be periodized over the full billing period, while credits created due to compensations must be periodized fully in the current period. This has now been resolved.

Incorrect ERP Postings – Missing glAcctNo (WFAMPS-4364)

This application fix resolves an issue with missing GL Account Number. If the glAcctNo could not be determined earlier in the processing it will be set to default value of 11700. This change handles scenarios where a discount service credit does not reference a specific service (i.e., service_no is NULL or 0).

Errors when attempting to change Payment Frequency (WFAMPS-4367)

This application fix resolves an issue in "Manage Subscription [SubsManageSubscription]" related to handling “IMMEDIATE” replacement. In cases where the changeDate / cutoffDate is not available (as is the case for IMMEDIATE), the current date is set to facilitate proper processing.

Unexplained Bill Date Changes (WFAMPS-4368)

This application fix resolves an issue in "Manage Subscription [SubsManageSubscription]" related to handling SPECIFIC-DATE cancellations. If the cancellation date is greater than the current anniversary date, the system now correctly sets the anniversary date to the next billing date.

STAMPEN ERP - Invoice Fee Posted to Reminder Fee Account (WFAMPS-4370)

This application fix resolves an issue where invoice fees were posted against the GL account for reminder fees. The problem occurred when a change in payment terms was applied to the billing group between the issuances of the invoice and the production of the ERP file. This has now been resolved.

POLARIS ERP – incorrect handling of service credits & discounts (WFAMPS-4371)

This application fix resolves an issue where the handling of service credits and discounts were not correct in the POLARIS ERP processing. This has now been resolved.