Home > Aria Crescendo Documentation > Aria Release Notes > Release 22

Release 22

Overview

Enhancements and fixes to Aria functionality for this release are described below.

Release Date

Stage Future Release Date

23-May-2019

Production Release Date

13-June-2019

System Requirements

Supported Browsers

  • Chrome 63
  • Firefox 52
  • IE11
  • Safari 11 on MacOS 

Screen Resolution

1024 x 768 or higher

Release 22 Contents

Application Features

Send or Suppress Statements Based on Balance and/or Transaction Type (DEV-8741)

In your Statement Sending options, you can now specify that statements should be sent or suppressed based on whether a statement has a zero balance and/or a particular transaction type is included in the statement. 

Updates to Aria Usage Download Spreadsheet (DEV-8985)  

The Aria UI Usage Download spreadsheet (under Accounts > Usage > Usage History) now includes MPI (master plan instance) filtering and an <MPI> field. It also now includes <plan_no>, <plan_instance_no>, and <master_plan_instance_no​> ​in the usage csv (comma-separated values) data.

Enhanced Behavior for Recurring In Arrears Services (DEV-9250)

This feature introduces enhanced billing behavior for Recurring Arrears (RA) services. The "old" behavior, which Aria will retain, calculates RA charges at the beginning of the billing period, then includes them on the next invoice. This new behavior calculates RA charges at the end of the billing period, introducing the ability to:

  • charge new rates resulting from rate changes that occurred during that billing period;
  • generate immediate pro-rated invoices for plan changes or cancelation;
  • specify proration directives for all plan-related API calls;
  • immediately set a plan's status to "Canceled," rather than "Pending Cancelation," when a plan is canceled; and
  • incorporate up-to-date invoice line item data on customers' bills, such as Purchase Order numbers and product fields.

All existing Aria customers will retain the "old" behavior by default, and billing calculations for RA services will be unaffected. All new Aria customers will inherit this enhanced RA behavior by default.

Updating RA Services To Bill With Enhanced Behavior

If you currently offer RA services in your product catalog, you must explicitly request that Aria switch the backend parameter RECURRING_IN_ARREARS_INVOICING_BEHAVIOR to the new behavior. Once updated, reverting this setting to the previous behavior could result in unbilled periods.

What Happens When We Update RA Behavior?

If you are a client who is already implemented on the Aria platform, or is currently implementing on the Aria platform, and you update your Aria application instances to the new behavior:

  • all customers with RA services will be charged based on the "old" RA billing calculation through their next billing anniversary;
  • customers with RA services who have been charged and billed via the "old" RA billing calculation will subsequently be billed using the enhanced RA billing calculation; and
  • all new customers with RA services will be billed via the enhanced RA billing calculation.

Old vs. New Behavior

Use Case Event Old Behavior Enhanced Behavior
Customer has RA service at $100/month from May 1 through May 31 You increase price of RA service to $110/month on May 15 $100 on June 1 bill (Charge calculated at beginning of billing period) $110 on June 1 bill (Charge calculated on Billing Anniversary)
Customer has RA service at $100/month from May 1 through May 31 Customer cancels RA service at $100/month on May 15 during May 1 through May 31 billing period

RA plan assigned "Pending Cancelation" status.

$100 charge, $50 pro-ration credit on Billing Anniversary; plan assigned "Canceled" status

RA plan assigned "Canceled" status.

$50 pro-rated charge, with option for immediate invoice or Billing Anniversary invoice

Learn more about Recurring Arrears Services. 

Cardholder- and Merchant-Initiated Transactions Implemented in Cybersource Payment Processor for Visa (DEV-9312)

This feature enhances Aria's Worldpay ​payment processor integration by sending flags distinguishing Cardholder Initiated Transactions​ (CIT) and Merchant Initiated Transactions (MIT)​ for Visa credit card transactions​​​, to comply with Visa's Payment Card Industry Data Security Standards (PCI DSS). These standards establish a set of 12 requirements for safeguarding sensitive information and controlling data access.

This feature applies to Credit Card and Tokenized Credit Ca​rd payment methods and leverages existing API ​input <recurring_processing_model_ind> and output <proc_initial_auth_txn_id> in the following API’s:

Note: This feature has not yet been implemented for MasterCard credit card transactions. 

​Configurable Reason Codes for Write-Off Creation (DEV-9479)

You can now configure new reason codes​​ or enable the existing available reas​​on codes to use during write-off creation.  Reason codes can be configured via Finance > Reason Code in the UI.

You can specify whether CSRs (customer service representatives) can use a particular reason code by selecting/deselecting the Enable for CSRs check box which appears on the Create New Reason Code screen. APIs will then enforce your selection for Enable for CSRs when CSRs try to use write-off reason codes.

Payment Processor / Gateway Deprecation (DEV-9480)

The following Payment Gateways/Processors, which are no longer in use or supported, have been removed from the Aria UI via the Configuration > Payments > Payment Gateways > New drop-down.

  • ​First Data Paypoint
  • Global Collect
  • Merchant eSolutions
  • MercuryPay
  • TNS​​

Application Fixes 

  • The Payment Gateway setup for processor Adyen is now correctly saving the Notification HMAC value in Configuration > Payments > Payment Gateways. (TICKET-16947)
  • An alert pop up no longer displays when creating a new service via the Products > Plans > Services > Create ​New service tabs. (TICKET-17088) 
  • When you use API Live to call the record_usage_m or bulk_record_usage_m API and pass text into the <comments> field, those <comments> are now displayed correctly in the outputs of the get_usage_history_m API. (TICKET-17176) 
  • Refunds and authorization (auth) reversals are now processed with the same payment gateway that was used for the original payment/auth. This is true even if the customer involved was added to a different collection group in the timeframe between the payment/auth and the refund/auth reversal. (TICKET-17293)
  • The Plan Details Modified event is now triggered as expected when a child plan is added or removed from a parent plan. The Plan Rate Schedule Modified event is now triggered as expected when the default rate schedule is changed. (TICKET-17296)
  • The ‘State/Province’ field is no longer displayed as a text box for countries other than Australia, Canada and US. Now, for those countries, the 'State/Province’ field is hidden and the ‘Locality’ field is displayed. (TICKET-17321)
  • Your specified statement message is now displayed in any statements that contain tax line items if: (TICKET-17363)
    • the insertOrderStmtMsg replacement string is included in the statement template in use; and
    • you included a Statement Message when you created an order in the Aria application.
  • You can now ​edit an account's Plan instance description or client-defined identifier, which can contain a special character (ex. "&"), from a Plan's instance detail page via the "Instance Description" link in the Aria UI. (TICKET-17370)
  • Aria no longer assigns a "Suspended" status to plans with statuses of "Terminated" or "Canceled" when Dunning completes for active plans in their Dunning Group. (TICKET-17377)
  • The client parameters WRITE_OFF_MPI_BALANCE_ON_ACCT_DEACTIVATION and WRITE_OFF_MPI_ON_SUSPEND now behave as expected (TICKET-17383):
    • WRITE_OFF_MPI_BALANCE_ON_ACCT_DEACTIVATION writes off all invoice and balance transfer amounts for MPIs when an account is deactivated.
    • WRITE_OFF_MPI_ON_SUSPEND writes of all invoice and balance transfer amounts for MPIs set to a "Suspended" status, either via API or a Dunning process. 
  • Permission error when editing Contacts in Account Overview is no longer occurring. Dependence on the Payment tab was removed and now contacts can be edited as expected on the Contacts tab. (TICKET-17397)

API Features

get_rate_schedules_for_plan_m XML Changes (DEV-7478)

The get_rate_schedule_for_plan_m API output format has been changed to XML for better performance.

Last Arrears Bill Through Date for Recurring Arrears Services (DEV-9250)

In the API call get_acct_details_all_m, Aria now returns dates in the fields <last_arrears_bill_thru_date> in both the <master_plans_info> and <supp_plans_info> for plans with Recurring Arrears services.

You can also manipulate this date via the API call adjust_acct_plan_bill_dates_m.

New Field <auto_assign_mandatory_supp_plans> Added to create_acct_complete_m and update_acct_plan_multi_m (DEV-9431)

This feature adds a new input field: <auto_assign​_mandatory_supp_plans> to create_acct_complete_m and update_acct_plan_multi_m.  This field will default to a different ​value for each API. In create_acct_complete_m, the <auto_assign_mandatory_supp_plans> input defaults to false, ​as the API will require users to pass in all mandatory supplemental plans along with the parent plan.  If the input is true, then the mandatory supplemental plans will be auto-assigned.  In update_acct_plan_multi_m , the <auto_assign_mandatory_supp_plans> input defaults to true, as the API will auto-​assign the mandatory supplemental plans.  If the input is false, users will be required to pass in all mandatory supplemental plans along with the parent plan.​ This change allows both create_acct_complete_m and update_acct_plan_multi_m to behave similarly when assigning mandatory supplemental plans.​​​​

New Client Parameter Added: Reset MPI Status To Active After Successful Balance Collection on Form of Payment Change (DEV-9471)

A new client parameter has been added to Configuration > Payments > Payment Settings called Reset MPI Status To Active After Successful Balance Collection on Form of Payment Change.  The old parameter Reset Status To Active After Successful Balance Collection, has been deprecated. Now, when you update the electronic form of payment via API, and the collection is successful, the API will change the MPI (master plan instance) status based on your selected value for the new client parameter.​

To support the new client parameter, the allowable values have been updated for the input parameter <change_status_after_coll> in the following APIs:

The allowable values include:

  •  Value: 0  Description: 'Do not reset the MPI status to active.'
  •  Value: 1  Description: 'Reset the MPI status to active when its current status is any non-active status.'
  •  Value: 2  Description: 'Reset the MPI status to active only when its current status "Suspended" (default).'
  •  Value: 3  Description: 'Reset the MPI status to active only when its current is either "Suspended" or "Terminated".'

Additionally, when a collection fails during the dunning batch process, the dunning batch will move the MPI status to "Suspended" only when the existing MPI status is NOT in "Cancelled" or "Terminated" status.

​Configurable Reason Codes for Write-Off Creation (DEV-9479)

You can now pass the new value "Write Off" into the <type> field along with the applicable <reason_code> to create/update/obtain write-off reason codes with the following Admintools APIs:

API Fixes 

  • When updating a plan's status from non-provisionable to provisionable via update_acct_plan_m, an invoice with the expected charges is now generated. (TICKET-14645)
  • XML Exception error: Unexpected element: CDATA was being displayed in authorize_electronic_payment_m API response instead of in the correct XML format (TICKET-16091)
  • When you call the create_new_plan_m API, Aria honors the <tax_inclusive_ind> input parameter for tax exclusive services, as expected (TICKET-16348)
  • If you use CyberSource as your payment gateway, authorizations that you attempt using the update_payment_method_m API are now completed successfully. This is because the billing contact information that you passed into the API is sent to CyberSource, as expected. (TICKET-17273)
  • Refunds and authorization (auth) reversals are now processed with the same payment gateway that was used for the original payment/auth. This is true even if the customer involved was added to a different collection group in the timeframe between the payment/auth and the refund/auth reversal. (TICKET-17293)
  • Your specified statement message is now displayed in any statements that contain tax line items if: (TICKET-17363)
    • the insertOrderStmtMsg replacement string is included in the statement template in use; and
    • you passed in a <statement_message> when you called the create_order_m API.
  • Rate schedule details are now returned when calling the following APIs, even when locale is not mapped with <plan_name> or <plan_desc> fields (TICKET-17372): 
  •  <stmt_email_list_cc> and <stmt_email_list_bcc> are now being saved as intended when:
    • they are added to an account through create_acct_complete_m; and
    • you reference the <contact_idx> field (in the <contacts> array)  using the <account_contact_idx> field (in the <acct> array). (TICKET-17386)
  • When you assign more than one master plan using the update_acct_plan_multi_m API, if the generated invoices are not paid, the Invoice Fully Paid event (941) is no longer triggered. (TICKET-17387)
  • The set_usg_threshold_m API has been deprecated and replaced with the set_usage_threshold_m API. This was done to make the API consistent with the other Aria APIs by setting the field type of the <error_code> output to long. (TICKET-17417)

WSDL File Locations

Stage Current

US https://secure.current.stage.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl
EUR None
AUS https://secure.current.stage.aus.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl

Stage Future

US https://secure.future.stage.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl
EUR https://secure.future.stage.cph.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl
AUS https://secure.future.stage.aus.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl

Production

US https://secure.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl
EUR https://secure.prod.cph.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl
AUS https://secure.prod.aus.ariasystems.net/api/Advanced/wsdl/22/complete_m-doc_literal_wrapped.wsdl

Object Query WSDL Files

Stage Current

US https://secure.current.stage.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl
EUR None
AUS https://secure.current.stage.aus.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl

Stage Future

US https://secure.future.stage.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl
EUR https://secure.future.stage.cph.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl
AUS https://secure.future.stage.aus.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl

Production

US https://secure.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl
EUR https://secure.prod.cph.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl
AUS https://secure.prod.aus.ariasystems.net/api/AriaQuery/wsdl/22/integration_services_m-doc_literal_wrapped.wsdl
Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.
Powered by CXone Expert ®