AMPS 2.7 Release

Improve overall parameter handling in AMPS (WFAMPS-1715)

This enhancement sees the introduction of an improved parameter handling in AMPS. The improved parameter handling will allow the client to manage and set parameters in AMPS directly via an API call, rather than via a change request for the AMPS configuration. The supported parameters are described in "AMPS Solution Design – AMPS Parameter Definition" document that can be made available to clients on request. New para-meters will be added to this document when introduced. From the outset, no parameters are currently present, but this will evolve over time.

To handle the parameter configuration two new APIs are introduced:

• Manage Parameter Configuration [SolmManageParamConfig] – This API will allow client to MODIFY or REMOVE any configuration as per parameter type and valid values. Removing a parameter will not physically delete the parameter, but instead revert it to the default setting.
• Retrieve Parameter Configuration [SolmRetrieveParamConfig] – This API will return configuration details to the caller.

A general function has also been added to allow workflows to retrieve the parameter configuration when needed. The subflow AMPS Parameter Retrieve [SolmAMPSParamRetrieve] is used for that purpose.

Distinguish between scheduled events and executed events (WFAMPS-1886)

This enhancement sees the introduction of an additional attribute (planChangeExecution) in the AMPSSubscriptionAction structure of all subscription events. The attribute contains "SCHEDULED" when the event is first registered, but will be completed later, i.e. at the requested date. The attribute contains "EXECUTED" when the change has been executed by AMPS (and/or ARIA). This means that for some changes, AMPS will trigger two events for requested action, namely:

1. When the action is first requested, an event with "SCHEDULED" will be sent. PlanChangeDate contains the date the action is scheduled to take place.
2. When the action is executed, an event with "EXECUTED" will be sent. PlanChangeDate contains the current date in these situations.

Capture & Return Customer Interaction Source (WFAMPS-1969)

This enhancement sees the introduction of an audit trail functionality that can capture the identification of the user who made the change and the system that initiated the change. It is the responsibility of the calling application to ensure that the information is provided. Otherwise no details are captured. Note that not all APIs are ready to capture the information, and where the API is not ready, the details provided will be ignored.

The user and system identification are provided in the userID field of the msgAuthDetails structure found in each API call into ARIA. As only a single field is available to transport the information, the formatting of the userID field must follow certain rules. The userID and sourceID must be separated with a "|" (pipe) character. If not, all information received is used as the userID. An example of userID could be as follows:

• "user|WEB" – "user" will be used as the userID and "WEB" will be used as the sourceID.
• "user@ariasystems.com|ECOMMERCE" – "user@ariasystems.com" will be used as the userID and "ECOMMERCE" will be used as the sourceID.
• "user@ariasystems.com" – "user@ariasystems.com" will be used as the userID. sourceID will be set to blank as it is not provided.

There are no restrictions on the content or character set of the userID field except that it cannot contain a JSON structure.

The following APIs have been updated

• Create Account [AcctCreateAccount]
• Manage Account [AcctManageAccount] – All options
• Manage Subscription [SubsManageSubscription] – All options including future dated actions
• Manage Address [DistManageAddr]
• Change Address [DistChangeAddr]
• Manage Complaint [CompManageComplaint]

All relevant events will have an audit trail object added. For events where the audit trail has not yet been enabled, the structure will be empty. The new audit trail structure is added to the AMPSEventIdent structure of the event.

Add AMPS events for subscriptions going in and out of dunning (WFAMPS-2267)

This enhancement sees the introduction of AMPS events when a subscription goes in and/or out of dunning. The event "SUBSCRIPTION/0016 – Subscription Dunning Changed" is generated for each subscription that is affected by the change. It is possible for multiple subscriptions to go in or out of dunning at the same time, and an event is generated for each subscription. The AMPS event is triggered by ARIA event "743 – Dunning state changed".

Enrich ARIA core events with Audit Trail Information (WFAMPS-2325)

This enhancement sees the introduction of AMPS events when a subscription goes in and/or out of dunning. The event "SUBSCRIPTION/0016 – Subscription Dunning Changed" is generated for each subscription that is affected by the change. It is possible for multiple subscriptions to go in or out of dunning at the same time, and an event is generated for each subscription. The AMPS event is triggered by ARIA event "743 – Dunning state changed".

• This enhancement sees the introduction of AMPS events when a subscription goes in and/or out of dunning. The event "SUBSCRIPTION/0016 – Subscription Dunning Changed" is generated for each subscription that is affected by the change. It is possible for multiple subscriptions to go in or out of dunning at the same time, and an event is generated for each subscription. The AMPS event is triggered by ARIA event "743 – Dunning state changed".
• If the event is one of the following events 718, 719, 720, 721, 722, 723, 724, 725, 726, 727, 728, 729, 730, 731, 732, 733, 734, or 735, then the latest audit record for SUBSCRIPTION type is sent for each master plan instance in the event.

If no audit records are found, then the structure will be empty.

STOP/START-process (WFAMPS-1897)

This application fix resolves an issue where the wrong title calendar was used. To resolve this issue the distribution scheduler has been updated to get title calendar data to support the fix and ensure the least amount of database operations.

During replace of plan future invoices are not cancelled / credited (WFAMPS-2015)

This application fix resolves an issue where the subscription cancellation process did not credit future invoices as required. Only the current invoices were credited with the appropriate credits. The process has been updated to ensure that any future invoices are also credited.

Process dunning events in batch (WFAMPS-2076)

In some situations the processing of dunning events would overtake the other event, and cause issues as the relevant documents could not be retrieved.

To solve this issue, a batch process has been introduced to process all relevant dunning events with regular intervals. Currently the interval is set to daily, but this can be changed if required. When the batch is run, the risk of having situations where the relevant document cannot be found is greatly reduced.

TitleRetrieveTitles API not returning correct titleDistNextExecution value (WFAMPS-2077)

This application fix solves a situation where the titleDistNextExecution date and time was not returned correctly. This was caused by an issue with the format being used to create the date and time. This has now been corrected so the API returns the correct date and time.

DistManageAddr API returns inconsistent responses (WFAMPS-2092)

This application fix solves a situation where the response returned by the API in some cases was inconsistent. This has now been resolved.

Unable to retrieve details of sharer plan and available for shares for a subscription (WFAMPS-2104)

This application fix sees the introduction of additional attributes related to sharing in the response to "Retrieve Subscription [SubsRetrieveSubscription]" for each subscription returned.

In the subsRetrieveSubscriptionResponseList structure the following attributes has been added:

• eligibleForSharing – a boolean attribute indicating if the current subscription is eligible for sharing among customers. TRUE indicates that sharing is available, while FALSE indicate that sharing is not possible.

In the SubsRetrieveSubscriptionSharingDetails structure the following attributes has been added:

• SharingMaxShares – an integer attribute that contains the maximum number of customer with which the plan can be shared. Contains zero if sharing is not allowed, or if the subscription belongs to a member.
• SharingCurrentShares – an integer attribute that contains the number of available invites that can be issued to members. Contains zero if sharing is not allowed, or if the subscription belongs to a member. For owners, a value of zero indicates that no more shares are available.

Mismatching instance dates on subscription with campaign (WFAMPS-2124)

This application fix resolves a situation where the "Retrieve Subscription [SubsRetrieveSubscription]" returned incorrect instance dates. The processing to set the instance dates has now been updated to check the presence of current and future paid or open invoices as well as campaign invoices. The setting depends on the date the API is executed.

Comparing current date with service credit creation date fails due to Time zone issues (WFAMPS-2232)

This application fix resolves an issue where checks against service credits being processed in the creation of credit notes was not correct and caused errors. The processes have now been updated to always use the correct time zone for all processing and thereby align with the dates used in ARIA.

IMMEDIATE replacement of plan from COMBO to DIGITAL with the last invoice having Service Credit failing (WFAMPS-2260)

This application fix resolves an issue when replacing the plan (product) on an existing subscription with another plan failed as service credits was not correctly handled. The process has been updated to correctly distribute the service credit on the relevant line charges and thereby ensuring that the credit note is correctly created and posted.

Update recursion policy when processing FIK/Nordea File payments (WFAMPS-2264)

This application fix resolves issues where payment processing failed when processing incoming files. The problem occurred when the number of records in the input file was larger than 20000. This has now been fixed in all processes handling inbound payment files.

STOPs not sent to 3rd party after subscription is cancelled (WFAMPS-2269)

This application fix resolves issues where AMPS had not sent STOP requests to 3rd party systems (such as DIMAPS) after the subscription was cancelled. The following situations are now handled correctly:

• For subscriptions cancelled during the time when distribution is running are fixed.
• Appropriate alerts are generated for subscriptions cancelled on dates for which Title Calendar is not populated.
• Exception/Error handling to ensure that if subscription is cancelled, STOP will be created.

PaymGWCallbackStatus can't Match GatewayExternalID for MobilePay (WFAMPS-2275)

This application fix resolves an issue where it was not possible for AMPS to match a payment request received in the AMPS gateway callback process with the original request. This has now been temporarily corrected. A new more reliant fix is in the pipeline.

Payment Origin is empty for credit card payments (WFAMPS-2278)

This application fix resolves an issue where the payment origin was not set correctly when handling MOBILEPAY and NETS DK payments. The following changes has been made:

• For MOBILEPAY payments, the paymentSource will be set to CREDITCARD and paymentOrigin will be set to MOBILEPAY (the ID of the AMPS payment gateway)
• For CREDITCARD payments collected through ARIA, the paymentSource will be set to CREDITCARD and paymentOrigin will be set to ARIA-GATEWAY
• For FIK payments, the paymentSource will be set to BANK and paymentOrigin will be set to FIK
• For PBS payments, the paymentSource will be set to BANK and paymentOrigin will be set to PBS

This change brings the use of paymentSource and paymentOrigin in line with other payment options and methods.

When unmatched payments fail, payment update date is wrong (WFAMPS-2279)

This application fix resolves an issue where the payment update date is not set correctly. The situation occurs when the unmatched payment is approved and posted against ARIA. In this case the payment update date on the unmatched payment is not set as expected. This has now been resolved.

"Retrieve Subscription [SubsRetrieveSubscription]" API not returning discounts for all subscription (WFAMPS-2283)

This application fix resolves an issue where the API did not return all relevant discounts applied to a subscription. The problem has been resolved by changing the ARIA API call to retrieve the information.

Enable support for billerEnrollmentStatus = "P" (WFAMPS-2337)

This application fix resolves an issue where the handling of NETS eFaktura agreement files were using the wrong specification of the received file. In the previous version there was no supported for billerEnrollment-Status "P". This has now been added.

The following changes has been made:

• If billerEnrollmentStatus = P is received from EnrollmentADD then new EFAKTURA agreement is created. If it is received in EnrollmentCHANGE then on the basis of customer found and current payment option, the eFaktura agreement will be created or updated.

ERP does not find correct title when handling invoice fees (WFAMPS-2365)

This application fix resolves an issue where the ERP process for a specific customer used the wrong title code when retrieving title details. This has now been resolved.