Skip to main content
Knowledge Central
Aria Knowledge Central

Release 6.50

  1. Last updated
  2. Save as PDF

Overview

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

Release Date

12/6/2016

System Requirements

Supported Browsers

  • Firefox 39
  • Chrome 44
  • Internet Explorer 9, 10, 11

Java Settings

Java 7.0​​

Screen Resolution

1024 x 768 or higher

Application

Features

Fixes

API

Features

Fixes

Application Features

Future Plan Changes (DEV-6103)

This feature allows you to queue plan changes so they occur at a specified future date. Types of plan changes that you can queue are:

  • Assign a plan (which creates a plan instance)
  • Remove a plan (which cancels the plan instance)
  • Replace a plan
  • Change the number of plan units
  • Change the plan instance status
  • Change the rate schedule on the plan instance (API only. See Future Plan Changes - API (DEV-6103) for details)

A new UI tab, Future Plan Changes, has been added to the Plan information available for each account. This tab displays plan changes that are queued, and plan changes that have been executed. See View Queued Plan Changes, below, for detailed information on this tab.

Note: The API portion of this change is implemented as part of Future Plan Changes - API (DEV-6103).

Schedule a Plan Change for the Future

You can schedule a future plan change from several places within the Aria user interface. The following screens now have the fields to specify a future date when the plan is added to or removed from the account. These fields are available when performing any of the functions listed below:

  • Assign a plan (which creates a plan instance)
  • Remove a plan (which cancels the plan instance)
  • Replace a plan
  • Change the number of plan units
  • Change the plan instance status

The following screen shows a future plan assignment when you add additional plan units to an account.

Getting Here: Click Accounts > Select an account > Plans > Select a plan > Change Plan Units

Plan changes can take effect immediately, on a specified future date, or on the anniversary date of the master plan. Options for the effective date can vary depending on the action you are performing, and are as follows:

  • On Anniversary: The plan change takes effect on the account's anniversary date. This option is not available when assigning a master plan to an account.
  • Immediately: The plan change takes effect immediately.
  • In Future: You can select a date when the plan change is effective. When you select this option the Effective Date field displays. Click the calendar icon to select the date of the change.

Note: When changing the status of a plan instance, this option is replaced by Days Until Status Change, and allows you to enter the number of days until the change becomes effective.

When you save your changes, the plan change is queued to become effective on the date you specify.

View Queued Plan Changes

Getting Here: Click Accounts > Select an account > Plans > Future Plan Changes

After you have a plan change to take effect in the future, all the queued changes are listed in the queue on this screen. Depending on the type of plan change queued, and the effective date of the change, you can make the following selections on this screen.

  • Plan Instance ID: Click this field to display the detailed plan information for the queued plan change.
  • Parent Plan Instance ID: If the queued plan is a supplemental plan, this selection is available. Click it to display detailed plan information for queued plan instance's parent plan.
  • Options: Actions you can perform on the queued plans. Different types of plan changes have different options available.
    • Execute: Implements the plan change immediately. Available for plans that have been queued with a specific date. Not available for plans that have been scheduled to change on their anniversary date, or for plan status changes.
      • Assume today's date is 2/1, and you queue a master plan to be assigned on 2/22. Then, a child supplemental plan is queued, so the effective date of the child plan must be on or after 2/22.
      • If you then queue a child supplemental plan to be added with an effective date of 2/22, you can queue a grandchild supplemental plan, with an effective date that must be on or after 2/22.
      • The Execute link initially is available only for the top-most plan assignment (in this case the master plan). Only after the master plan assignment is executed (on the scheduled date or if done immediately) is the Execute link available on the child supplemental plan. Because of this restriction, there are cases where the Execute link is not displayed for child / grandchild / etc. queued plan changes. For example, if the supplemental plan is assigned on the master plan's anniversary date, or the supplemental plan is assigned to a master plan that is scheduled to be active at a future date.
    • Change Date: Revises the date that the plan change takes effect. Available for plans that have been queued with a specific date. Not available for plans that have been queued on their anniversary date. If you change the date on a supplemental plan, the date must be on or after the active date for the parent plan.
    • Delete: Prevents the future plan change from occurring. Available for all plan changes. Deleting a queued plan assignment automatically deletes all child, grandchild, etc. plan assignments under the one being deleted.

View Changed Plans

After plan changes are executed, or deleted, either by the system or manually, you can see the changes on this screen. The following example shows the above plan changes after they are complete.

Queuing Restrictions

Future plan changes are subject to the following restrictions.

  • If multiple queue requests exist for one plan or plan instance, they are processed chronologically by effective date.
  • Plans and plan instances that have a status of "Suspended", "Terminated" or "Canceled" cannot be queued for addition, replacement, or deletion.
  • Supplemental plans can only be queued for dates when a valid master plan is available.
  • If a child instance is also a parent plan instance to another plan, the effective date of a queued plan or plan instance assignment on a child plan instance must be on or after the effective date of the queued plan assignment on a parent plan instance or an error results.
  • If a parent plan or plan instance's status is "Suspended", "Terminated" or "Canceled", then its child plans cannot be queued.
  • If you schedule a supplemental plan or plan instance, but at the time of the effective date, the parent plan will have a status of "Suspended", "Terminated" or "Canceled", then the supplemental plan change does not take effect. In this case, at the time you schedule the supplemental plan, you receive a warning message telling you that the change cannot be implemented, and asking if you want to proceed. If you choose to proceed, the scheduled changes for the supplemental plan instance and all of its child plans are deleted from the queue.
  • Plans and plan instances cannot be replaced if their dunning state is currently either "In Progress" or "Completed", or if the plan will be in that state at the time of the effective date.

Invoicing Interactions

When queuing future plan changes, be aware of the following interactions that describe how the effective date interacts with the invoice for the plan.

  • Negative Bill Lag Days: If you are changing a plan with negative bill lag days, and the effective date occurs after the invoice is generated, but before the billing period is finished, then the full invoice for the period is voided, and a prorated invoice is generated for the new plan that covers the time from the effective date to the end of the billing period.
  • Once plan changes are executed, all queued changes executed for all plan instances associated with the same billing group, based on their master plan instance, appear on the same invoice.
  • Discounts, surcharges, credits, tax and payment surcharges are applied after plan changes execute.
  • If queue requests exist for multiple plan instances with different anniversaries within one billing group, the invoice generated after the changes execute is prorated for each master plan instance.

Combine Invoices on One Bill (DEV-7038)

This feature allows you to combine multiple invoices on one bill. This is most typically used for "catch-up" billing, which can be necessary when account creation interacts with Bill Lag Days to cause multiple invoices to be sent over a short period of time. Refer to Create a Collection Billing Group for information on Bill Lag days.

A future enhancement will allow combining invoices when BOTH 1) a retroactive start date is used and is 2) combined with a plan rollover.  This will be addressed in a future release, but combining invoices in that particular scenario should be avoided if possible until then.

Note: The API portion of this change was implemented as part of Combine Invoices on One Bill - API (DEV-7038).

Permitting Combined Invoices

Getting Here: Click Configuration > Billing > Invoice Settings > Combine Invoices

 

This setting allows you to create a bill on an account that contains multiple invoices. Allowable values are as follows:

  • True: Combine multiple invoices on one bill
  • False: Do not combine multiple invoices on one bill

Creating an Invoice that Covers Multiple Billing Cycles

If the Combine Invoices setting is True, and an account's master plan instance qualifies for combined invoices, you can choose to combine invoices when you generate an invoice. A plan qualifies for combined invoices if no invoices have been created for more than one previous billing cycle.

Getting Here: Click Accounts > select an account > Statements & Invoices > Invoices > Generate Invoice

  1. Select Master Plan Instance.
  2. Select the master plan instance for which you want combined invoices.
  3. Select Immediate Invoice.
  4. Select one of the following options under Combine Invoices (If Applicable).
  • Short Cycle (Multiple Invoices): Create one invoice per billing period (default)
  • Long Cycle (Combine Invoices): Create a combined invoice that covers multiple billing periods

Note: If a plan instance has a pending plan rollover, contract rollover, or other future plan change, a long cycle invoice is not available and this selection generates an error message.

User Interactions on Payment Screen Updated (DEV-6742)

This feature updates the user interface when making electronic or check payments to improve usability. Changes include simplifying option labels and consolidating redundant links. These changes do not impact the way payments are made or applied, but only the design of the interface. See below for a few examples of these enhancements.

Getting Here: Click Accounts > Search for and select an account > Payments & Credits

Previously, two links were provided to Collect Payment Electronically or Record Payment Received. These links have been consolidated to a single Make a Payment link which takes you to a single interactive form to make the electronic payment.

After clicking Make a Payment, the Payments form opens. Depending on your Payment Option selection of either Net Terms or Payment Method, you see a different set of fields in the Payments form. Note that Receive Payment(s) Based on Net Terms option label has been simplified to Net Terms.

The fields that display are specific to the Payment Option and to additional selections made in the form. For example, if you select Payment Method and an Alternate One-Time payment method of Credit Card, fields to input the credit card information display.

In addition, an Apply Against selection has been added when the Payment Option is Payment Method (ex. Credit Card, ACH, etc). You can choose to charge per the standard First In First Out Method (FIFO), or to select a specific invoice or service to apply the payment to.

Note:  When choosing from the options below, the current balance option is not supported when early payment discounting is used and will not display. Instead, use the full balance option or apply the payment to individual invoices or services.

New Design with Precise Access Control for Creating a Role (DEV-7862)

This feature enables precise access for roles (for example: enabling or denying read, create, or delete access to batch processes) and control of the contents in the navigation pane. The user experience has been enhanced by providing intuitive menus and simplified steps.

Note that access to a certain module may include the ability to interact with other modules to which the user has not been granted explicit access. For example, a user with only "Create Plan" access can create new services within the Plans module when creating a new plan. However, this same user does not have access to the Services module in the navigation pane, and thus cannot create services within the Services module.

Creating a Role

Getting Here: Click Configuration > Security > Roles > New

Note: Depending on the functions configured within your Aria instance, the options that appear in the following Roles screen may differ. If you have questions regarding one of these modules, refer to User Documentation for that module.

  1. Enter a Role Name. Be specific as this name allows you to easily identify the role. For example, Business Analyst with API Live Access.
  2. Enter a Client Defined Identifier. A unique ID for reference within your organization. A Client Defined Identifier is an Aria-generated ID that may be updated to meet your needs.
  3. Set the access for the Manage Authorization Keys setting.
  • Yes: Automatically selects Read for the Configuration > Integrations > Web Service API page. The Configuration > Integrations > Web Service API page is enabled in the navigation bar and includes the ability to generate, enable or delete authorization keys.
  • No: The user does not have access to enable or delete authorization keys within the Web Service API page.

Note: If Read access for Configuration > Integrations > Web Service API page is deselected, the Manage Authorization Keys setting automatically reverts to No.

  1. Set the access for the listed modules.
  • Yes: The module appears in the navigation pane for users with this role. All functions within the module are available for the user.
  • No: The module is not displayed in the navigation pane, and the user cannot access any of the functions.
  1. Click the drop-down arrow to view the module's access options.

    For example, Analytics & Reporting presents options to grant access to various dashboards and reports. Marking the star designates the dashboard as the default.

    The Access to Account Groups section displays each available Functional Account Group with a check box. Selecting a checkbox enables the role access to that Functional Account Group. If you do not have Account Groups configured, this section does not display.

    For some modules, such as Configuration, specific access can be granted to individual sub-pages for the module. If no checkboxes for a sub-page are checked, the sub-page or features (for example, a create New button) of the sub-page do not display for a user with the role.

    • To grant access to all of Configuration, use the top-level checkboxes for Read, Create, Edit or Delete (i.e. there is no need to expand the accordion.)
    • To deny access to all of Configuration, do not select any checkboxes. Once the role is saved and assigned to a user, Configuration does not display in the navigation pane for the user.  

Note: In some cases, higher-level access includes lower-level access. This is denoted automatically as you select the checkboxes. For example, a user with Create, Edit or Delete access automatically has Read access. 
 

  1. Click Save. The role can now be assigned to a user.

Assign a Retroactive Start Date for Supplemental Plans (DEV-7187)

This feature enables adding a supplemental plan with a retroactive start date under an existing master plan instance. Once the supplemental plan(s) has been added, one or more invoices for the past period(s) is immediately generated to account for the billing period up to the current bill date. You are able to bill the charges for any number of periods retrospectively, restricted by parent plan start date, either as individual bills or as a single consolidated bill of the retrospective periods. Subsequently, the supplemental plan is incorporated into the invoice for the current billing period and for all future periods.

To enable this functionality, the existing Alternate Proration Start Date field has been enhanced to allow assignment prior to the current bill cycle. To implement this functionality, you must configure the new Use alternate proration start date as plan assignment date for retroactive additions client parameter under Invoice Settings.

Note: The API portion of this change was implemented as part of Assign a Retroactive Start Date for Supplemental Plans - API (DEV-7187).

Enable Client Parameter

Getting Here: Click Configuration > Billing > Invoice Settings

  1. Navigate to the Use alternate proration start date as plan assignment date for retroactive additions parameter. 
  1. Confirm the parameter is set to True.

    If the parameter is set to False, click the parameter to open the configurations screen. Select True from the drop-down, and click Save.

Specify a Retroactive Bill Start Date for a Supplemental Plan

The Alternate Proration Start Date field when adding a supplemental plan has been enhanced to support dates in the past. However, this date is limited to the start date of the parent plan instance under which the supplemental plan is being added.

A date in the future is also supported, but is limited to the next bill through date.

Getting Here: Click Accounts > Search for and select an account > Plans > Add New Plan button

  1. At a minimum, select a Master Plan from the drop-down.
  2. Click Add Supplemental Plan.
  3. Choose a Parent Plan, and a Supplemental Plan.
  4. Input the number of Supplemental Plan Units.
  5. Choose Assign Immediately.
  6. Enter an Alternate Proration Start Date. This date is used as the start date of the prorated period rather than the current date.

    The Alternate Proration Start Date can be a date in the past.

Additional Sorting and Viewing Capability (DEV-5881, DEV-5883, DEV-5885)

The Promotional Plan Sets, Coupons, and Discount Rules screens now provide the ability to sort each column, filter certain columns, and to show and hide columns.

The revised screens now have the following features:

  • Sort By Column: By clicking the up/down arrows by each column name, you can sort the display by the values in that column.
  • Search a Column: You can use the search box just below each column name to find values within that column.
  • Filter Columns:  Certain columns allow you to filter the displayed data by the values in this column. Click the up/down arrows in the box below the column name to see the values you can use to filter the list, or enter text into the text box to filter the list by the text entered.
  • Show/hide columns: The Show/hide columns menu in the upper right corner allows you add and remove columns from the display by checking or unchecking the column name in the menu.

Configure Negative Bill Lag Days in Excess of One Bill Cycle (DEV-7039)

This feature allows you to specify an optional configurable parameter that allows negative bill lag days to exceed one bill cycle. This allows invoicing to occur for more than one billing cycle in advance of the billing period.

Getting Here: Click Configuration > Billing > Invoice Settings > Allow Negative Bill Lag Days to Extend Beyond One Bill Cycle

Allowable values are as follows:

  • False: Bill lag days cannot exceed the billing cycle days (default)
  • True: Bill lag days can exceed the billing cycle

Allowing a CSR to Change Bill Lag Days at the Master Plan Instance Level

There is a new setting that makes this feature available. Allow Negative Bill Lag Days to Extend Beyond One Bill Cycle must be set to True to use this feature.

Getting Here: Click Configuration > Security > Account Access > Plans > Pages

  1. Select the lowest CSR level that you want to allow to change bill lag days at the master plan instance level.
  2. Click On to make the Bill Lag Days tab visible for that CSR level when viewing an account.

Changing Bill Lag Days at the Master Plan Instance Level

To change the number of bill lag days on an individual master plan instance, use the following steps:

Getting Here: Click Accounts > search for and select an account > Plans > select a plan instance

  1. Select Bill Lag Days from the right side of the screen, or select the Bill Lag Days tab at the top of the screen.
  2. Enter the number of bill lag days you want to assign to the master plan instance. Note that the number of days in the help text next to the Bill Lag Days field changes depending on the value of the Allow Negative Bill Lag Days to Extend Beyond One Bill Cycle client parameter setting.

Precedence of Bill Lag Days Settings

Bill lag days can be specified in several places within the Aria. The following is the order of precedence for the settings:

  1. Master Plan Instance
  2. Collection Group
  3. Payment Method/Payment Terms
  4. Client Configuration Settings

First Data Payeezy Payment Processor (DEV-6970)

This feature adds First Data Payeezy as an available payment processor. Supported payment methods include:

  • Credit Card
    • Visa, MasterCard, American Express, Discover, JCB, Diners Club
  • Tokenized Credit Card

Getting Here: Click Configuration > Payments > Payment Gateways > New > First Data Payeezy

Fields you must configure to set up this payment processor are as below. You must work with First Data Payeezy to obtain this information:

  • JS Secret Key: JavaScript Secret Key used to identify the merchant.
  • Merchant Token: The token value assigned to the merchant.
  • Merchant API URL: The API URL endpoint that is used to communicate with Payeezy.
  • API Secret: The API Secret is used for authorization and helps provide better security.
  • API Key: A unique value that is assigned to an authorized user of this service.

Enhanced Payment Terms (DEV-7151)

This feature adds several features to Payment Terms. You can now perform the following functions:

  • Assign European Article Numbers or Global Location Numbers (EAN/GLN)
  • Specify additional options for invoicing
  • Set payment reminder dates for a specific payment term
  • Specify the type of address used for taxation purposes
  • Assign a surcharge to a payment term

Note: The API portion of this change was implemented as part of Enhanced Payment Terms - API (DEV-7151).

Additional Fields and Payment Reminders

The following fields have been added to the Payment Terms screen.

Getting Here: Click Finance > Payment Terms > Select or create a payment term

EAN or GLN: This field indicates if this payment term is used with European Article Numbers or Global Location Numbers (EAN/GLN). These numbers are required when sending invoices in certain European countries, and are a widely used format throughout Europe. If this box is checked for this payment term, then fields for these values display when you apply this payment term to an account or master plan instance. If the fields are displayed, they are required.

Days Until Due: This field now has options that allow the user to choose whether the Days Until Due is based on the Invoice Date plus nn days or based on the end of the current month plus nn days. For electronic payments, this determines which day the electronic collection is attempted. Allowable values are:

  • Apply After the Invoice Date: days are calculated based on the invoice date (default)
  • Apply at the End of the Month: days are calculated based on the end of the current month.

Bill Lag Days: Enter the number of days prior to (negative) or after (positive) an account billing date at which an invoice is generated. The Bill Lag Days setting in the Collection Group screen overrides the Bill Lag Days setting in the Payment Terms screen, and the Bill Lag Days setting in the Payment Terms screen overrides the Bill Lag Days setting in the Billing Recurring Interval screen.

Surcharge: This field allows you to associate a surcharge with the payment term. Select a surcharge from the drop-down menu to be associated with this payment term.

Auto Bill Orders: Check this box to bill orders immediately upon generation. This can be overridden by the order creation process.

Send Payment Reminder Notifications: Check this box to send reminders to a statement, administrative, or billing contact as the due date approaches.

To set up payment reminders, use the following steps:

  1. Click the checkbox to select Send Payment Reminder Notification. If there are email templates assigned to Payment Reminders 01, 02, and 03, a list of Payment Reminder options displays.
  2. Optionally, you can select Send Reminder for Active Accounts Only, to limit payment reminders to Active accounts.
  3. For each payment reminder, enter the following information:
  • Days Until Payment Reminder: The number of days the system waits to send a payment reminder notification when an invoice goes unpaid. Payment reminder emails can be configured in the Email Templates section of the application, and can be overridden at the Payment Terms, Functional Account Group, and individual account levels.

Note: The following two fields do not display until after you enter a value in the Days Until Payment Reminder field.

  • Default Payment Reminder Template: Select the payment reminder email template as the default for this payment term. This template can be overridden on the Notification Template Group associated with a Functional Account Group, or at the individual account level under 'Notification Method' in the Account Overview. The payment reminders specified here share the same email templates used for payment reminders at the account level.
  • Notification Recipients: Select the account contact to receive the payment reminder email.
    • Default: Account's default contact option
    • Administrative: Account's administrative contact
    • Billing: Billing contact
    • All: Sends the notification to all contacts
  1. Click Save when you are done.

Taxable Address Configuration Setting

Payment terms are now included under the existing configuration setting Account Taxable Address To Use. This configuration setting has been updated to allow you to choose the order in which account, billing, and statement contacts are used to determine a taxable address.

Getting Here: Click Configuration > Billing > Taxation Settings > Account Taxable Address To Use

Select the option that reflects your preferred order to use the addresses for tax purposes. The drop-down menu provides several combinations of the following three contacts:

  • Account Contact
  • Billing Contact
  • Statement Contact

If any of the contacts do not have information associated with them, the next contact in your selected order is checked until a valid tax address is available.

Associate an EAN/GLN with an account

You can associate an EAN/GLN with an account when you select a payment term for the account that has an EAN/GLN associated with it.

Getting Here: Click Accounts > Create New Account

Select a Master Plan and then scroll to the Payment Options section of the screen and select a payment term associated with an EAN/GLN.

The following two fields display. Enter the appropriate values for each:

  • EAN or GLN Number Method
  • EAN or GLN Requisition Number

If these fields are displayed, they are required.

Associate an EAN/GLN with a billing group

When you create an account using Payment Terms or Net Terms and the Term selected has a payment type of EAN/GLN, you can associate the account's billing group with an EAN or GLN. If these fields are displayed, they are required.

Getting Here: Click Accounts > select an account > Plans > Billing Groups > select a billing group

Payment Terms Surcharge

This feature allows you to associate a surcharge with a payment term. You can choose to add a surcharge to a payment term to cover additional processing fees or to provide an incentive for customers to use another means of payment, such as a credit card or electronic payment.

Getting Here: Click Products > Surcharges > New or select an existing surcharge > Application

Payment Term is now an available option in the Scope drop-down menu.

Enhanced Payment Methods (DEV-7182)

This feature has added options when specifying the Days Until Due for the payment method and when specifying how the taxable address is determined. This section also describes how payment reminders work for payment methods.

Getting Here: Click Configuration > Payments > Payment Methods > Select or create a payment method

The following field has been modified on the Payment Method screen:

Days Until Due: This field now has options that allow the user to choose whether the Days Until Due is based on the Invoice Date plus nn days or based on the end of the current month plus nn days. For electronic payment methods, this determines which day the electronic collection is attempted. Allowable values are:

  • Apply After the Invoice Date: Days are calculated based on the invoice date (default)
  • Apply at the End of the Month: Days are calculated based on the end of the current month.

Send Payment Reminder Notifications: Check this box to send reminders to a statement, administrative, or billing contact as the due date approaches.

To set up payment reminders, use the following steps:

  1. Click the checkbox to select Send Payment Reminder Notification. If there are email templates assigned to Payment Reminders 01, 02, and 03, a list of Payment Reminder options displays.
  2. Optionally, you can select Send Reminder for Active Accounts Only, to limit payment reminders to Active accounts.
  3. For each payment reminder, enter the following information:
  • Days Until Payment Reminder: The number of days the system waits to send a payment reminder notification when an invoice goes unpaid. Payment reminder emails can be configured in the Email Templates section of the application, and can be overridden at the Payment Method, Functional Account Group, and individual account levels.

Note: The following two fields do not display until after you enter a value in the Days Until Payment Reminder field.

  • Default Payment Reminder Template: Select the payment reminder email template as the default for this payment method. This template can be overridden on the Notification Template Group associated with a Functional Account Group, or at the individual account level under 'Notification Method' in the Account Overview. The payment reminders specified here share the same email templates used for payment reminders at the account level.
  • Notification Recipients: Select the account contact to receive the payment reminder email.
    • Default: Account's default contact option
    • Administrative: Account's administrative contact
    • Billing: Billing contact
    • All: Sends the notification to all contacts
  1. Click Save when you are done.

Taxable Address Configuration Setting

Payment methods continue to be included under the existing configuration setting Account Taxable Address To Use. This configuration setting has been updated to allow you to choose the order in which account, billing, and statement contacts are used to determine a taxable address.

Getting Here: Click Configuration > Billing > Taxation Settings > Account Taxable Address To Use

Select the option that reflects your preferred order to use the addresses for tax purposes. The drop-down menu provides several combinations of the following three contacts:

  • Account Contact
  • Billing Contact
  • Statement Contact

If any of the contacts do not have information associated with them, the next contact in your selected order is checked until a valid tax address is available.

Credit Memo/Rebills (DEV-6906)

This feature enables you to create credit memos and apply them to qualifying invoices. Credit memos allow the whole or partial crediting of original invoice lines. They are then followed by an adjusted rebill. The ability to re-invoice for a past period in a recurring billing cycle is essential for error and dispute processing at many business-to-business companies.

Note: The API portion of this change was implemented as part of Credit Memo/Rebills - API (DEV-6906).

Credit memos take precedence over existing payments and credits, which are removed, if necessary, from any line item where a credit memo is applied. The amount of the payment or credit that is removed equals the amount of the credit memo for that line.

Note: You cannot void an invoice that has a credit memo associated with it. You must void all associated credit memos before voiding an invoice.

Getting Here: Click Accounts > select an account > Statements & Invoices > Credit Memos > New

  1. Select an invoice to which you want to apply a credit memo. 

    The following types of invoices are not displayed on the list:

    • Fully paid invoices (including disputed invoices which make an invoice appear to be fully paid)
    • Invoices that have any refund-related reversals
    • Invoices that have already been rebilled
    • Invoices that have already been voided
    • Child invoices, when account hierarchies are used with the parent pay option
    • Invoices with no lines upon which the credit memo can be applied
    • Pending invoices

    A list of line items on the invoice displays.

  1. Select a Reason Code for the credit memo. This field is required. Note that only Reason Codes defined with a type of Credit Memo display in this drop-down menu.
  2. Enter a comment to explain the reason for issuing the credit memo. This field is required.
  3. Enter the credit amount for each line item. This amount must be greater than 0. Note that the maximum amount equals the original line item amount minus any previously applied credits and credit memos.

Note: After you enter an amount, the client tax engine calculates the tax amount that must be credited. Entering the full amount of the line item may not result in a zero invoice balance due to tax calculations.

  1. Click the pencil icon to optionally add a comment for any line items.
  2. Click Next to continue. The details for the credit memo display, including any credit for taxes.
  3. Click Save to create the credit memo. Confirm that you want to save the credit memo. The credit memo displays on the Credit Memos tab for the account.
  • You can click the Credit Memo Number to see the detail for the credit memo.
  • You can click Void to cancel the credit memo.

Credit Memo Events

Two new events have been added to the Financial Transactions Notifications class:

  • 948 - Credit Memo
  • 949 - Credit Memo Voided

The order of precedence for where these notifications are sent is below. The system checks for a contact in the following order and sends it to the first one with valid information.

  1. Statement contact
  2. Billing contact
  3. Account contact

Credit Memo Numbering

A new configuration setting allows you to specify whether credit memos have a prefix or suffix added to the system-generated number of the credit memo. The value of this string is set up by Aria Customer Support.

Customer Support also sets the initial value of the credit memo sequence number, and the number of digits in the number. You can work with Customer Support to specify these values.

Getting Here: Click Configuration > Billing > Invoice Settings > Credit Memo Sequence Append Option

Allowable values are:

  • Prefix: Attach the string before the system-generated credit memo number (default).
  • Suffix: Attach the string after the system-generated credit memo number.

Credit Memo Template

A new template class, Credit memo, has been created. A standard credit memo template is provided as part of this feature. You can also select the credit memo template when performing the following functions:

  • Creating an account
  • Creating/editing a plan
  • Adding a plan to an account
  • Creating/editing a billing group

When you create an account template, you can now specify if a credit memo template is required, and what the default value is. If an account has "cc" or "bcc" settings, a credit memo is also sent to those events.

Rebilling an Invoice

When you rebill an invoice, you create a modified copy of an original invoice with adjusted charge amounts for various line items.

You cannot rebill any of the following types of invoices:

  • Fully paid invoices (excluding disputed invoices)
  • Invoices that have any refund-related reversals
  • Invoices that have already been voided
  • Child invoices
  • Pending invoices

If any master plan instance on the original invoice has been removed from the billing group that it was in on the original invoice, the invoice cannot be rebilled.

If either a full or pro-rated invoice are in the current billing cycle, the invoice cannot be rebilled.

Rebills only include non-tax charge lines of the original invoice.

When you rebill, you can adjust the rate to an amount other than the original charge. Rebilling an invoice automatically generates a credit memo on the invoice that is for the difference between the original amount and the rebilled amount.

The rebill uses the current payment method assigned to the billing group. If the billing group has changed since the initial invoice was created, any refunds go to the current payment method.

Note: A rebill can be voided, however you cannot rebill that invoice again. The best practice when it is necessary to rebill a previously rebilled invoice is to rebill it again, not to void it.

Getting Here: Click Accounts > search for and select an account > Statements & Invoices > Invoices > select an invoice to rebill

  1. Click Rebill from the invoice detail screen.
  2. Click the transaction number you want to rebill. The Rebill screen displays.
  3. Select a Reason Code for the rebill. This field is required. Note that only Reason Codes defined with a type of Rebill display in this drop-down menu.
  4. Enter a comment to explain the reason for the rebill. This field is required.
  5. You can optionally change the service by clicking Change, if the service is not order-based or usage-based. You are limited to services with the same type as the one you are changing.
  6. You can optionally override the units and the rate for each line item. When you are rebilling a charge that is not usage, the unit must be a whole number. The maximum rate amount cannot exceed the amount of the line item.
  7. Click the pencil icon to optionally add or change the purchase order number or the tax addresses for the line item. Note that changing the tax address can change the tax calculation for the rebill.
  8. Click Next to continue. The details of the rebill are displayed.
  9. Click Save to continue. The rebill is saved, and a credit memo for the rebill amount is visible in the Credit Memos tab for the account.

Automatic Collection on Rebill

A new configuration setting allows you automatically collect from an account when a rebill is applied to an account's invoice.

Getting Here: Click Configuration > Billing > Invoice Settings > Autocollect on Rebill

Allowable values are:

  • True: Automatically collect when an invoice is rebilled.
  • False: Do not automatically collect when an invoice is rebilled.

Rebill Numbering

A new configuration setting allows you to specify whether rebills have a prefix or suffix added to the system-generated number of the rebill. The value of this string is set up by Aria Customer Support. You can work with Customer Support to set the length of the sequence ID, and its initial starting value. The sequence ID is maintained at the client level only.

Getting Here: Click Configuration > Billing > Invoice Settings > Rebill Sequence Append Option

Allowable values are:

  • Prefix: Attach the string before the system-generated rebill number (default).
  • Suffix: Attach the string after the system-generated rebill number.

Rebills and Dunning

A new configuration setting allows you to specify whether you use the original invoice date or the rebill date for dunning purposes. Rebill dates can be in the past, and this provides customers the option of using the rebill date or not.

Getting Here: Click Configuration > Billing > Invoice Settings > Use Original Invoice due date for rebill

Allowable values are:

  • True: Use the original due date on the rebill invoice (default).
  • False: Aria calculates a new due date for this rebill.

Rebilling Template

A new template class, Rebill, has been created. A standard rebill template is provided as part of this feature. You can also select the rebill template when performing the following functions:

  • Creating an account
  • Creating/editing a plan
  • Adding a plan to an account
  • Creating/editing a billing group

The order of precedence for the recipient of a rebill is:

  • Statement contact
  • Billing contact
  • Account contact

If cc and bcc addresses are set for invoices and statements, then rebills are sent to these addresses also. You can override the recipient if you use the gen_rb_m API.

Locale Settings

Two fields have been added to Locale Settings to support credit memos.

Getting Here: Click Configuration > Client Settings > Locale Settings > New or edit an existing locale

The new fields are:

  • Credit Memo Line
  • Voided Credit Memo Line

Display Data for Statements at the Plan Instance Level (DEV-7575)

This feature introduces two loops to display statement information at the plan instance level. The first loop displays account charges grouped by each plan instance from a specified period, and the second loop displays this information with individual tax jurisdiction information and values. New replacement strings have been added to implement this feature.

Enhance Service Credit Reason Codes (DEV-7627)

This feature allows a Finance user to establish a service credit reason code that immediately recognizes the liability when the service credit is created.

Note: The API portion of this change was implemented as part of Enhance Service Credit Reason Codes - API (DEV-7627).

Getting Here: Click Finance > Reason Code > New or select an existing service credit reason code

When a reason code is to be applied to a service credit, the following radio buttons appear:

  • Reduce revenue when service credit is applied: The amount of the service credit reduces the value of charge lines when it is applied to an invoice (default).
  • Record liability immediately: The amount of the service credit becomes a liability when it is applied to an invoice, even if it is not yet applied to the account's balance.

When you choose this option the following four required fields display. Enter the appropriate general ledger account information for each:

  • Expense GL Account: Indicates the charge account when the service credit is immediately accounted at issuance.
  • Unapplied Service Credit GL Account: Indicates the credit account when the service credit is immediately accounted at issuance.
  • Canceled Service Credit GL Account: Indicates the credit account if the unapplied service credit is canceled.
  • Expired Service Credit GL Account: Indicates the credit account if the unapplied service credit expires.

If you want to allow CSRs to be able use this reason code when creating service credits, you can check Enable for CSRs.

If you enable the reason code for CSRs, you see the following options:

  • Allow time-based restrictions
  • Allow plan or service scope restrictions

If you check either of these boxes, you see options to limit how this reason code is applied at the time you apply it to an account.

Updated Calculation for NETS Refunds to Display Total Amount Paid (DEV-7255)

Note: You must Enable NETS refunds for this functionality.

When using an API to issue an account refund to a NETS account (e.g. with the issue_refund_to_acct_m API), the logic used to calculate the total paid amount for an invoice has been modified. Refunds processed through NETS are now correctly applied to the total amount paid for an invoice.

Account Overview View-Only CSR Level Access Updated (DEV-7862)

Previously, the View-only CSR level access allowed edit access to certain areas of the Account Overview module. The View-only CSR level has been updated to remove any edit access, and now only allows view access to the Account Overview section.

For more information about roles, refer to Security.

Mountain Time Zone (MDT/MST) Addition (DEV-7552)

This feature allows Mountain Time to be set as the client's time zone. Previously, the available time zone for this region of the United States was Phoenix time, which does not use daylight savings time. Mountain time follows daylight savings time.

The time zone for your company is set by Customer Support. This enhancement affects Audit Log entries, which can now show a timestamp coordinated with Mountain time.

Update Default Locale with Additional Values (DEV-7535)

This feature allows you to add additional values when specifying a locale. When adding or editing a locale within the Aria application, there are various system-defined fields that can be translated into the locale’s default language. Two fields were added to this configuration page so that they can be displayed in the appropriate language on statements and in other areas of the application.

Getting Here: Click Configuration > Client Settings > Locale Settings > New or edit an existing locale

The new fields on this screen are:

  • Invoice credit applied to charge lines
  • Voided invoice credit applied to charge lines

Additional Support for Negative Usage (DEV-7411)

This feature adds support for negative usage units on invoices. The support varies based on other usage features being enabled (e.g., tiers, usage accumulation, usage pooling, etc.). Previously, only positive usage amounts were supported on invoices. Negative usage amounts provide an additional client tool to provide a usage-based alternative to a service or cash credit toward a client account.

Invoice Activation Fee Now Invoiced When Adding Multiple Plan Instances (DEV-7728)

This feature adds support for activation fees when adding multiple plan instances to an account. Previously, the activation charges were not supported for additional plan instances if the first invoice was a prorated invoice.

To enable this support, there is a new client parameter, Charge Activation Fee on Master Plan Assignment After Proration Event.

Getting Here: Click Configuration > Billing > Invoice Settings > Charge Activation Fee on Master Plan Assignment After Proration Event

This setting ensures that when additional instances of a master plan instance are assigned to an account during the first invoice period, and the master plan instance has an activation fee associated with it, the activation fee for the additional master plans is charged on the first invoice. Allowable values are as follows:

  • True: Charge an activation fee, if applicable, for additional master plan instances added during the first invoice period.
  • False: (Default) Do not charge an activation fee for additional master plan instances added during the first invoice period.

Display Card Type for Tokenized Credit Cards (DEV-7771)

This feature adds support for display of the card type (Visa, MasterCard, American Express, etc.) on the Account Overview Payment Methods tab and in the Payment Method detail screen when the payment type is Tokenized Credit Card.

Note: The API portion of this change was implemented as part of Display Card Type for Tokenized Credit Cards - API (DEV-7771).

Getting here: Click Accounts > Select an account > Payment Methods

Getting here: Click Accounts > Select an account > Payment Methods > Edit a payment method that uses a tokenized credit card

Change Account Data to the Account's Locale Language in User Profile (DEV-7407)

This feature adds the option to change the language in which you view the account data to the locale defined by the account. By default, this option is selected. Previously, it was not possible to revert to this option once another locale was selected.

Getting Here: From any screen within the Aria UI

  1. Click your user name in the upper right of the UI.
  2. Select Locale defined by the account from the View Account Data In drop-down.
  3. Click Save. The account data is shown in the language of the locale defined by the account.

Application Fixes

  • Internal Error: ORA-01403: no data found error message displayed when creating cash credit from invoice (TICKET-12120)
  • Various issues in Countries & States drop-down boxes (TICKET-12187)
  • Internal server error was returned while saving data in Smart Rec > Options screen (TICKET-12472)
  • Proration service credit was not generated as expected for two plan replacements on the same day (TICKET-12559)
  • XML template_class was incorrect for generic XML templates (TICKET-12596)
  • Dunning "Percentage Fee" did not honor decimal values (TICKET-12644)
  • Statement sending configurations were not honored when creating a new account (TICKET-12689)
  • When reassigning plans on a billing group, contact info was not populated (TICKET-12753)
  • Events name displayed twice for same line item (TICKET-12757)
  • Internal Error: ORA-01422 when assigning a child account to current account (TICKET-12790)
  • Editing plan instance fields under some plans returned unexpected error (TICKET-12822)
  • Status change to "Account Service Plan Contract Expired" was not occurring when a contract completed (TICKET-12864)
  • Billing Contact country was changing to Account Country when adding tokenized credit card in the user interface (TICKET-12910)

API Features

Future Plan Changes - API (DEV-6103)

This feature adds and modifies several APIs to support future plan changes.

The following are new APIs:

get_acct_plan_queued_changes_m - Retrieves all queued plan changes for a given plan instance, including plan assignments, removals, replacements and rollovers, as well as changes to plan units, plan instance status, and rate schedules for both master plans and supplemental plans.

edit_acct_plan_queued_changes_m - Modifies an existing queued plan change for a given plan instance. Supported actions include immediately executing a queued plan change, deleting a queued plan change, or modifying the effective date of a queued plan change.

Queuing Restrictions

Future plan changes are subject to the following restrictions.

  • If multiple queue requests exist for one plan or plan instance, the one with the latest effective date is processed.
  • Plans and plan instances, that have a status of "Suspended", "Terminated" or "Cancelled" cannot be queued for addition, replacement, or deletion.
  • The effective date of a queued plan or plan instance assignment on a child plan instance must be on or after the effective date of the queued plan assignment on a parent plan instance or an error results.
  • If a parent plan or plan instance's status is "Suspended", "Terminated" or "Cancelled", then its child plans cannot be queued.
  • If a supplemental plan or plan instance is queued, but at the time of the effective date the parent plan has a status of "Suspended", "Terminated" or "Cancelled", then the supplemental plan change does not take effect. This plan status change causes all child plan instances (i.e., under this plan in the hierarchy) for this account to no longer be provisioned. Additionally, all queued plan changes for this plan instance and all child plan instances are automatically deleted from the queue.
  • Plans and plan instances cannot be replaced if their dunning state is currently either "In Progress" or "Completed", or if the plan will be in that state at the time of the effective date. However, if the replacement plan is already queued when the master plan instance goes into dunning, then the change is executed.

Invoicing Interactions

When queuing future plan changes, be aware of the following interactions that describe how the effective date interacts with the invoice for the plan.

  • Negative Bill Lag Days: If you are changing a plan with negative bill lag days, and the effective date occurs after the invoice is generated, but before the billing period is finished, then the full invoice for the period is voided, and a prorated invoice is generated for the new plan that covers the time from the effective date to the end of the billing period.
  • Once plan changes are executed, all queued changes executed for all plan instances associated with the same billing group, based on their master plan instance, appear on the same invoice.
  • Discounts, surcharges, credits, tax and payment surcharges are applied after plan changes execute.
  • If queue requests exist for multiple plan instances with different anniversaries within one billing group, the invoice generated after the changes execute is prorated for each master plan instance.

The following API has been deprecated:

cancel_queued_acct_plan_change_m is deprecated as that functionality is now covered by the edit_acct_plan_queued_changes_m API.

Credit Memo/Rebills - API (DEV-6906)

This feature has several new and modified APIs to support credit memos and rebilling.

Credit Memos

The following APIs have been added to support credit memos:

  • create_cm_m - Create a credit memo
  • void_credit_memo_m - Void a credit memo
  • get_cm_details_m - Get credit memo details
  • get_invoice_cm_details_m - Get allowable credit memo line values for a given invoice. The API returns non-tax charge lines from the invoice.

The following APIs have a new input field to support credit memos:

  • create_acct_complete_m
  • update_acct_complete_m
  • update_acct_plan_multi_m
  • create_acct_billing_group_
  • update_acct_billing_group_m
  • assign_acct_plan_m

An input field, <cm_template_no> has been added which you can use to specify a credit memo template number.

The following APIs have a new output parameter to support credit memos:

  • get_acct_details_all_m
  • get_acct_hierarchy_detail_m
  • get_acct_billing_group_m

An output parameter, <cm_template>, has been added to show the credit memo template name.

Rebill

The following API has been added to support rebills:

  • gen_rb_m - Rebill an invoice

The following API has been modified to support rebills:

  • get_invoice_history_m

New input

  • <rb_option> - Filters the return results of the API call
    • 0 or null - the account history provided includes all invoices including rebilled ones
    • 1 - the account history provided includes only original invoices and does not return rebill invoices
    • 2 - for those invoices that have been rebilled, the account history provided includes only the rebilled ones.  If an invoice has been rebilled multiple times, this selection provides all of the rebills.

New Outputs

  • <orig_invoice_no> - Aria-generated unique number of the original invoice
  • <rb_no> - The Aria-generated unique number of the rebill invoice
  • <rb_reason_cd> - The client-defined reason code for the rebill
  • <rb_flag> - Indicates if the current invoice is a rebill invoice
    • 1 - This invoice is a rebill invoice
    • 0 or null - This invoice is not a rebill invoice
  • <rb_status> - Indicates if the current invoice has been rebilled
    • 1 - This invoice has been rebilled
    • 0 or null - This invoice has not been rebilled
  • get_invoice_details_m

New Outputs

  • <rb_status> - Indicates if the current invoice has been rebilled
    • 1 - This invoice has been rebilled
    • 0 or null - This invoice has not been rebilled
  • <orig_invoice_no> - Original invoice number (for a rebilled invoice). The orig invoice number is the predecessor invoice, which could be a rebill.
  • <rb_excluded> - Indicates that the original invoice line was not rebilled
  • <rb_line_comments> - Comments introduced on the rebill line
  • void_invoice_m

    Added an error message when an invoice can't be voided due to an associated credit memo.

  • create_acct_complete_m, update_acct_complete_m, update_acct_plan_multi_m, create_acct_billing_group_m,  update_acct_billing_group_m,  assign_acct_plan_m

New Input

  • <rb_template> - Rebill template number
  • <credit_memo_template> - Credit memo template number
  • get_acct_details_all_m, get_acct_hierarchy_detail_m, get_acct_billing_group_m

New Output

  • <rb_template> - Rebill template number

The following APIs have been modified to support both credit memos and rebilling

  • create_new_plan_m, edit_new_plan_m,

New Inputs

  • <credit_memo_template> - Associates a credit memo template with the plan
  • <rebill_template_no> - Associates a rebill template to the plan

Combine Invoices on One Bill - API (DEV-7038)

This feature has several modified APIs to support combining multiple invoices on one bill.

The following APIs have a new input parameter:

  • create_acct_complete_m
  • update_acct_complete_m
  • gen_invoice_m
  • assign_acct_plan_m
  • replace_acct_plan_m
  • update_acct_plan_m
  • update_acct_plan_multi_m
  • cancel_acct_plan_m
  • modify_acct_plan_unit_instances_m

    New Input

    <combine_invoices> - Indicator for combining invoices when retroactive start dates, negative bill lag days, or plan changes just prior to the next billing date would otherwise have generated multiple invoices. Allowable values are:

  • 1 - Combine Invoices (long cycle). If a plan instance has a pending plan rollover, contract rollover, or other future plan change, a long cycle invoice is not available and this value generates an error message.
  • 2 - Do Not Combine Invoices (short cycle)
  • 3 - Use client default configuration setting

The following APIs have been modified to return invoice line items that span more than one recurring interval if invoices generated as a result of “1” (True/Long Cycle) setting.

  • get_invoice_history_m
  • get_invoice_details_m
  • get_all_invoice_information_m (object API)
  • get_invoice_information_m (object API)

Assign a Retroactive Start Date for Supplemental Plans - API (DEV-7187)

The following input parameters have been modified or created to allow retroactive dates.

Input Parameter Description
<alt_proration_start_date> The date, in YYYY-MM-DD format, from which proration calculation begins. This date may not be earlier than the date the parent plan was assigned.

<invoicing_option>

(new)

 Used when alt_proration_start_date is populated with a date in a previous bill cycle. Enter a value of 1 to generate a single consolidated catch-up bill and 2 to generate individual bills corresponding with the billing periods.

These input parameters are used in the following APIs to support retroactively added supplemental plans to an existing master plan instance:

API Enhancement
create_acct_complete_m Ensures that the newly assigned supplemental plan is added with the same retroactive start date as the parent master plan instance. There is no requirement to alter the start date of the supplemental plan to a different date during account creation.
update_acct_plan_multi_m Validates that the <alt_proration_start_date> input parameter does not precede the start date of the parent plan.
assign_acct_plan_m Validates that the <alt_proration_start_date> does not precede the start date of the parent plan instance.

Enhanced Payment Terms - API (DEV-7151)

This feature has several modified APIs to support enhancements to payment methods.

The following APIs allow the assignment of Payment Terms in lieu of Payment Methods, and a Payment Term or Payment Method is now required for a given Billing Group.

  • create_acct_complete_m
  • create_acct_billing_group_m
  • update_acct_complete_m
  • update_acct_billing_group_m
  • update_acct_plan_multi_m

The following parameters are added to the billing group array for each of these APIs:

  • <billing_group_row> - This array contains information about the account's billing groups. A billing group defines the statement configuration, payment methods (primary and/or backup) or payment terms for one or more master plan instances
  • <payment_option> - This is a choice for the user to select payment methods or payment terms when creating or modifying a billing group. Allowable values are “Methods” or “Terms”.
  • <client_payment_term_id> - Client-defined identifier for the billing group's payment term.
  • <ean_gln_num> - This is the European Article Number (EAN) or Global Location Number (GLN) that is a required field if a payment option is terms AND client payment term id matches a term in which the payment term type equals EAN/GLN.  This number should be provided by Aria’s clients’ customers and is unique to each customer (account).
  • <ean_gln_requisition_num> - This is the European Article Number (EAN) requisition number or Global Location Number (GLN) requisition number that is a required field if a payment option is terms, and the client payment term ID matches a term in which the payment term type equals EAN/GLN. This number should be provided by Aria’s clients’ customers and is used to track their individual projects similarly to a purchase order. This number is generated by the individual customer (account) and is not provided by any other party.

The create_payment_terms_m API has been modified and now includes the following inputs:

  • <client_pmt_term_id> - Client-defined identifier for the billing group's payment term. If no value is present, default to pmt_terms_name value.
  • <days_until_due_method> - This allows the user to choose whether the Days Until Due is based on the Invoice Date plus nn days or based on the end of the current month plus nn days. Allowable values are:
    • invoice - Days are calculated based on the invoice date (default)
    • current month - Days are calculated based on the end of the current month.
      • If the account is invoiced monthly, the Days Until Due = 10, and the current date is March 15th, then the Due Date is March 25th.
      • If the “Based on end of current month + 10 days” is selected, the due date is April 10th.
      • Note that any day in March with “Based on end of current month + 10 days” selected all bills on April 10th.
  • <pmt_terms_type> - This defines whether or not the Payment Terms are “Net Terms” (default) or “EAN/GLN”, which is a standard for location based services/barcodes that require additional fields to be captured. The allowable values are 0: Net Terms and 1: EAN/GLN.
  • <bill_lag_days> - The number of days prior to (negative) or after (positive) a Master Plan Instance’s billing date at which an invoice should be generated. The Bill Lag Days setting for a given account’s Master Plan Instance overrides all other Bill Lag Days settings. The Bill Lag Days setting in the Collections Group level overrides the Bill Lag Days setting at the Payment Method/Payment Terms level, and the Bill Lag Days setting at the Payment Method/Payment Terms level  overrides the Bill Lag Days setting in the Billing Recurring Interval level.
  • <surcharge_applicable> - Identifier to determine if a surcharge is applicable. Allowable Values are True or False.
  • <surcharge_no> - Surcharge Number that is applicable to a surcharge mapped to Payment Terms only. This value is ignored if “surcharge_applicable” is set to false.
  • <auto_bill_orders> - Governs whether orders are immediately billed upon generation. This can be overridden by the order creation process. Allowable values are True or False.
  • <pmt_reminder> - Governs whether to send a payment reminder notification to the account holder when their invoice goes unpaid longer than the number of days specified in the <pmt_reminder_days_until_notification> field. Payment reminder emails can be set in the Email Templates section of the UI, and can be overridden at the Functional Account Group and individual account levels. Allowable values are True and False.
  • <pmt_reminder_active_accts_only> - If pmt_reminder is set to True and this value is set to False, the system sends the payment reminders after the specified number of days have elapsed without payment, regardless of account status. If pmt_reminder set to True and this value is set to True, the system sends payment reminders only when the account status indicates that the account is active, billable, and not currently within the dunning process. This prevents the system from sending payment reminders to accounts that are suspended or in dunning.
  • <pmt_reminder_row> - This determines each of the days until a payment reminder email is sent, the template to use, and notification recipients for each template class. If the pmt_reminder is set to False, these values are ignored.
  • <pmt_reminder_tmplt_no> - The Payment Reminder Template Number that is associated to the Payment Reminder Class of email templates.
  • <pmt_reminder_days_until_notification> - The number of days the system waits after the account’s bill date before sending the payment reminder email to the account holder. It is recommended that this value be less than the “Days Until Due” value set in the days_until_due field, as these emails are never sent while the account/master plan instance is in the dunning process.
  • <default_pmt_reminder_template> - The payment reminder email template that is the default for this payment term.  This template can be overridden on the Notification Template Group associated with a Functional Account Group, or at the individual account level under ‘Notification Method’ in the Account Overview.
  • <pmt_reminder_notification_list> - This governs the account contact to which the payment reminder is sent via email.  Allowable values are Default, Administrative, Statement, and Both.

The delete_payment_terms_m (admintools) API has been created to support the removal of payment terms only if the payment terms have never been assigned to any account's billing group. It has the following inputs:

  • <pmt_terms_name> or <client_pmt_term_id> or <pmt_terms_no> - The Aria-defined or client-defined name of the payment terms, or the Aria-generated ID for the payment terms.

The following APIs have additional outputs to support retrieval of Payment Terms and Payment Methods details when billing groups are included in the return.

  • get_acct_details_all_m
  • get_acct_billing_group_m
  • get_payments_on_invoice_m

New outputs are:

  • <payment_option> - Governs whether billing group is using “Methods” or “Terms”.
  • <primary_ payment _method_name> - Pay Method Name from Pay Methods configuration.
  • <primary_ payment _method_no> - Pay Method Number from Pay Methods configuration.
  • <backup_payment_method_name> - Backup Pay Method Name from Pay Methods configuration.
  • <backup_ payment _method_no> - Backup Pay Method Number from Pay Methods configuration.
  • <client_payment_term_id> - Client Payment Term ID from Payment Terms configuration.
  • <pmt_terms_name> - Payment Terms Name from Payment Terms configuration.
  • <payment_terms_no> - Payment Terms Number from Payment Terms configuration.
  • <pmt_terms_type> - Payment Terms Type from Payment Terms configuration.
  • <ean_gln_num> - EAN or GLN Number from a billing group that is only applicable if payment_option=”Terms” and pmt_terms_type=”EAN/GLN”.
  • <ean_gln_requisition_num> - EAN or GLN Requisition Number from billing group that is only applicable if payment_option=”Terms” and pmt_terms_type=”EAN/GLN”.

The get_acct_payments_m API has been deprecated. It has been replaced with get_acct_payment_methods_and_terms, which has all the input and output fields of get_acct_payments_m plus the following input field:

  • <payments_returned> - Specifies if payment terms or payment methods are returned by the API.
    • 1 - Return only payment terms array information.
    • 2 -  Return only payment methods array information.
    • 3 -  Return both payment terms and payment methods arrays (default).

The get_payment_terms_m API has additional outputs to support retrieval of payment terms:

  • <pmt_terms_type> - Payment Terms Type from Payment Terms configuration.
  • <days_until_due_method> - Days Until Due method from Payment Terms configuration.
  • <bill_lag_days> - Bill Lag Days from Payment Terms configuration. This value can be overridden at the Master Plan Instance level.
  • <surcharge_applicable> - Surcharge applicable value from Payment Terms configuration.
  • <surcharge_no> - Surcharge Number from Payment Terms configuration.
  • <auto_bill_orders> - Auto Bill Orders value from Payment Terms configuration.
  • <pmt_reminder> - Payment Reminder value from Payment Terms configuration.
  • <pmt_reminder_active_accts_only> - Payment Reminder Active Accounts Only value from Payment Terms configuration.
  • <pmt_reminder_row> - Array(s) of Payment Reminders including templates from Payment Terms configuration.
  • <pmt_reminder_tmplt_no> - Payment Reminder Template Number (or Class) from Payment Terms configuration.
  • <pmt_reminder_days_until_notifcation> - Payment Reminder Days Until Notification from Payment Terms configuration.
  • <default_pmt_reminder_template> - Default Payment Reminder Template from Payment Terms configuration.
  • <pmt_reminder_notification_list> - Payment Reminder Notification List from Payment Terms configuration.

Support Sending CVV Only Through create_order_m API (DEV-7140)

For recurring transactions with a credit card payment method, the create_order_m API supports sending only the CVV number (without the credit card number) to the Vantiv (Litle) payment processor for collection.  A new input parameter named <existing_pay_method_cvv> has been added to the create_order_m API to send the CVV number of an existing credit card on the account to the payment processor.

If the account’s current form of payment for recurring transactions is a credit card, the create_order_m API passes the <existing_pay_method_cvv> (if entered) to Aria and then Aria passes the account’s current credit card and details of the CVV to the payment processor to complete the order.

If the alt_pay_method_m API is used, the <existing_pay_method_cvv> input parameter is ignored and the CVV field provided in the alt_pay_method_m is used.

Enhance Service Credit Reason Codes - API (DEV-7627)

This feature has several modified APIs to support enhancements to reason codes.

The create_reason_code_m and update_reason_code_m APIs have the following new inputs:

  • <record_liability> - Indicates if the service credit becomes a liability when it is created, even if it is not yet applied to an invoice. When updating a reason code, this field cannot be changed once the reason code being updated has been used to create a service credit.
    • 0 or null - false
    • 1 - true
  • <expense_gl_code> - Mandatory when the <record_liability> parameter equals 1. Indicates the charge account when the service credit is immediately accounted at issuance. This field is ignored if <record_liability> is set to 0 or is null.
  • <unapplied_sc_gl_code> - Mandatory when the <record_liability> parameter equals 1. Indicates the credit account when the service credit is immediately accounted at issuance. This field is ignored if <record_liability> is set to 0 or is null.
  • <unapplied_sc_gl_code> - Mandatory when the <record_liability> parameter equals 1. Indicates the credit account when the unapplied service credit is cancelled. This field is ignored if <record_liability> is set to 0 or is null.
  • <expired_sc_gl_code> - Mandatory when the <record_liability> parameter equals 1. Indicates the credit account when the unapplied service credit expires. This field is ignored if <record_liability> is set to 0 or is null.

The get_reason_codes_m API has the following new outputs:

  • <record_liability> - Indicates if the service credit becomes a liability when it is created, even if it is not yet applied to an invoice.
    • 0 or null - false
    • 1 - true
  • <expense_gl_code> - Indicates the charge account when the service credit is immediately accounted at issuance. This field is ignored if <record_liability> is set to 0 or is null.
  • <unapplied_sc_gl_code> - Indicates the credit account when the service credit is immediately accounted at issuance. This field is ignored if <record_liability> is set to 0 or is null.
  • <unapplied_sc_gl_code> - Indicates the credit account when the unapplied service credit is cancelled. This field is ignored if <record_liability> is set to 0 or is null.
  • <expired_sc_gl_code> - Indicates the credit account when the unapplied service credit expires. This field is ignored if <record_liability> is set to 0 or is null.

Additional Support for Negative Usage - API (DEV-7411)

The following APIs have been modified to support negative usage. They allow the <billable_unit, usage_unit>, <rate>, and <amt> fields to accept negative values:
  • record_usage_m
  • bulk_record_usage_m

The following restrictions are in effect when entering negative usage values for these APIs:

  • Negative usage is not allowed for usage-based services in which Usage Pooling is enabled unless the service is pre-rated.
  • <rate> field cannot be negative if <amt, billable_units>, or <usage_units> are negative values.
  • <amt> field cannot be positive if the billable/usage unit is negative.

When using the gen_Invoice_m API, negative charge line items are not permitted.

Display Card Type for Tokenized Credit Cards - API (DEV-7771)

This feature enhances support for entering the card type (Visa, Mastercard, American Express, etc.) on the following APIs that have <cc_id> as an input parameter.
  • create_acct_complete_m
  • update_acct_complete_m
  • create_acct_billing_group_m
  • update_acct_billing_group_m
  • update_payment_method_m
  • assign_acct_plan_m

When <pay_method> = 13 (tokenized credit card), the following occurs:

  • The <cc_id> input value is accepted even if it is not configured as mandatory for the account’s payment processor.
  • When an invalid <cc_id> is passed, the API returns an error (error code: 4022, error msg: 'invalid cc id').
  • If the <cc_id> is configured as mandatory for a payment processor and the input is empty, then it returns an error (error code: '4032',  error msg: 'Missing required cc id').

Dynamic Soft Descriptor for PayPal PayFlow Pro and Express Checkout (DEV-7479)

This feature adds support for entering dynamic Soft Descriptor information for the PayPal PayFlow Pro and PayPal Express Checkout payment processors. A credit card soft descriptor is text rendered on a cardholder’s statement. It describes a particular product or service purchased by the cardholder. Descriptors are intended to help the cardholder identify the products or services purchased.

The following APIs have a new input parameter:

  • create_order_m
  • create_order_with_plans_m
  • collect_from_account_m
  • settle_account_balance_m

The new input parameter is as follows:

<soft_descriptor> - Transaction description shown on the buyer's statement.

API Fixes

  • Error message received when using override bill dates in assign_acct_plan_m (TICKET -12780)
  • Get_acct_details_all_m returns an error for a terminated account (TICKET-12556)
  • Get_acct_details_all_m did not return a purchase order number at the master plan level (TICKET-12690)
  • set_usg_threshold_m was not working in API Live (TICKET-12742)
  • Array fields were missing in get_acct_plans_all_m and documentation for this API was updated to remove <all_plan_service_rates> parameter (TICKET-12932)
  • ‘Unexpected error’ message was returned in assign_acct_plan_m when invoice_approval_required was set to ‘True’ (TICKET-13385)

WSDL File Locations

Stage Current

US

https://secure.current.stage.ariasystems.net/api/Advanced/wsdl/6.50/complete_m-doc_literal_wrapped.wsdl
EUR None

Stage Future

US https://secure.future.stage.ariasyst...l_wrapped.wsdl
EUR

https://secure.future.stage.cph.ariasystems.net/api/Advanced/wsdl/6.50/complete_m-doc_literal_wrapped.wsdl

Production

US https://secure.ariasystems.net/api/A...l_wrapped.wsdl
EUR

https://secure.prod.cph.ariasystems.net/api/Advanced/wsdl/6.50/complete_m-doc_literal_wrapped.wsdl

Object Query WSDL Files

Stage Current

US https://secure.current.stage.ariasys...l_wrapped.wsdl
EUR None

Stage Future

US https://secure.future.stage.ariasyst...l_wrapped.wsdl
EUR

https://secure.future.stage.cph.ariasystems.net/api/AriaQuery/wsdl/6.49.1/integration_services_m-doc_literal_wrapped.wsdl

Production

US https://secure.ariasystems.net/api/A...l_wrapped.wsdl
EUR

https://secure.prod.cph.ariasystems.net/api/AriaQuery/wsdl/6.49.1/integration_services_m-doc_literal_wrapped.wsdl
  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Page type
    Topic
  2. Tags
    This page has no tags.