Release 35

Geo Code Support for Sovos Tax Engine (DEV-9854)

 

This feature enhances Aria's integration with the Sovos tax engine, implementing the Geo code support to calculate taxes for accounts' Ship To, Bill To, Ship From, and Bill From addresses instead of the full addresses.

Unlike traditional postal codes, such as a ZIP code, a Geo Code is not a subjective descriptor, but a series of letters and/or numbers based on the physical location, or latitude and longitude coordinates, of a business, residence, or even point of interest. A Geo Code can provide every location in the world with an internationally unique and permanent "address." Beyond supplying a physical address to residents and businesses located in countries without addressing systems, a common Geo Code standard can greatly facilitate international communications and transactions.

For the Ship From, Bill From, Ship To and Bill To address types, Aria will send the Geo Codes/addresses to the Sovos tax engine in the following order:

• The Geo Code of the respective Ship From, BIll From, Ship To and Bill To addresses
• The respective Ship From, BIll From, Ship To and Bill To addresses
• The Geo Code of the account's taxable address
• The account's taxable address

The following outputs on the API calls listed below denote the tax address method code used to generate the geocode of the address:

API	Output Parameters
get_acct_billing_group_details_m	<bill_addr_method_cd> <stmt_addr_method_cd>
get_acct_contacts_m	<addr_method_cd> <bill_addr_method_cd> <bkup_addr_method_cd> <stat_addr_method_cd> <other_addr_method_cd>
get_acct_details_all_m	<addr_method_cd> <bill_addr_method_cd> <stmt_addr_method_cd>
get_acct_hierarchy_details_m	<addr_method_cd> <bill_addr_method_cd> <stmt_addr_method_cd>
get_acct_payment_methods_and_terms_m	<bill_addr_method_cd>
refresh_token_from_pmt_processor_m	<bill_addr_method_cd>

For more information on creating a taxation configuration, please click here.

---

Aria has enhanced dunning for Payment Terms (Net Terms) Billing (DEV-10104)

The new feature "Dun Plan For Non-Electronic Payment Terms Using Cumulative Past Due Balance" introduces an optional, alternate way to dun plan instances based on the cumulative past due balance of all late statements for Payment Terms (Net Terms). You can enable this behavior by setting a new parameter "Dun Plan For Non-Electronic Payment Terms Using Cumulative Past Due Balance" to True. Cumulative past due balance is evaluated by billing group.

---

New Objects for Data Streaming Web Service (DEV-10174, DEV-10198, DEV-10227)

Aria’s latest iteration of the Data Feed Web Service includes the Discount Rule object and Chart of Accounts object. In addition, the Non-Subscription Offering (NSO) object reference has been updated to include the <client_sku> field. See the Data Feed Logical Object Model for details.

---

Application Fixes 

• The status of your Billing Manager batch process (under Configuration > Audit Logs > Batch Processes > Billing Manager) is now correctly reflected, regardless of any collection failure. This means that the status of the Billing Manager batch process will be "OK (without errors)" even if a collection failed, because the collection attempt still ran successfully. (TICKET-18343)
• If two or more statements are generated for an account’s Master Plan Instance (MPI) and one late statement payment initiates a dunning process, the dunning fee(s) is(are) now calculated against the MPI on its past due balance from all late statement(s) and not all account statements. This applies when the Net Terms payment type is associated with the affected billing group. (TICKET-18382)
• When an account is as follows:
  • Two MPIs belong to two different Billing Groups (with Net Terms as the payment method for each)
  • Both MPIs are in dunning
  • A partial payment is made on the last late statement keeping the balance above the dunning threshold
  For the conditions listed above, the MPIs will now remain in dunning and the dunning steps will not be reset. (TICKET-18384)

---

Verify Usage Uploads with the get_usage_history_information_m API (DEV-9995)

Aria has created a new Object Query API named get_usage_history_information_m to retrieve all recently uploaded usage for an account. This new API allows you to verify that usage was successfully recorded in Aria.

---

<client_acct_id> Input Field Added to APIs as Alternative to <acct_no> (DEV-10091)

This feature deprecates the send_arc_threshold_email_m API call, and adds the field <client_acct_id> input as an alternate input for "acct_no" on the following API calls:

update_acct_notify_method_m get_acct_notify_method_m get_acct_plan_notify_method_m update_acct_credentials_m toggle_test_account_m acct_plan_install_complete_m get_acct_status_history_m get_child_accts_m get_user_id_from_acct_no_m

get_all_acct_receipt_ids_m get_all_actions_by_receipt_id_m send_acct_statement_email_m get_acct_message_m get_acct_message_size_m get_statement_content_m get_statement_content_size_m set_payment_responsibility_m

---

Total and Remaining Discount Uses for get_acct_coupon_details_m API (DEV-10106)

The get_acct_coupon_details_m API now returns two new output parameters (under the <discount_rules> array):

Parameter	Description
<total_discount_uses>	This displays the total uses of a discount rule applied to a specific master plan instance (MPI) or a specific account OR an MPI and account depending on how the coupon is applied.
<remaining_discount_uses>	This displays the number of remaining coupon uses for the specified account and/or MPI under the discount array details for both discount rule/bundle or credit-template-based coupons.

---

Usage Record Uniqueness Enforcement (DEV-10125)

This feature introduces a mechanism to enforce uniqueness of the combination of <client_record_id> and <usage_type_code> on non-discarded usage records loaded via the API call record_usage_m or bulk_record_usage_m. A new Aria client parameter "Unique Client Usage ID," in Configuration > Client Settings > Miscellaneous Settings, defines this uniqueness, and can be set to:

• "None" (no uniqueness enforced),
• "Uniqueness on client record id" (client_record_id value must be unused in a usage load), or
• "Uniqueness on client record id and Usage Type Code" (combined values of client_record_id and usage_type_code must be unused in a usage load).

---

Use the edit_plan_m API to Schedule Service Changes (DEV-10138)

You can now schedule service changes by using the new <service_changes> input in the edit_plan_m API. When you call edit_plan_m, you can specify when to apply the addition or removal of services for both new and existing accounts. The change can be applied on a specific date, before the next batch billing run (for new subscriptions), or on the billing anniversary date (for existing subscriptions).

---

Enhanced Information In Returns for Several APIs (DEV-10200)      

 

API Calls	Output Field Changes
create_order_m create_order_with_plan_m	<nso_rate_schedule_no>, <nso_client_rate_schedule_id> Deprecated <rate_schedule_no>, <client_rate_schedule_id> Added
create_order_m create_order_with_plan_m update_order_m	<line_type> Added
get_invoice_details_m	<line_type> Numeric Returns 7–9 Added, Orders Now Specified as 8

create_order_m, update_order_m

This feature enhances the create_order_m and update_order_m API calls to more accurately return rate schedule information. The output fields <nso_rate_schedule_no> and <nso_client_rate_schedule_id> have been deprecated; the output fields <rate_schedule_no> and <client_rate_schedule_id> have been added in the <cart_invoice_line_items> array to identify the rate schedule number of surcharges and NSOs (<rate_schedule_no>) and the client id of the rate schedule for NSOs (<client_rate_schedule_id>).

create_order_m, create_order_with_plan_m, update_order_m, get_invoice_details_m

In addition, the API calls create_order_m, update_order_m, and create_order_with_plan_m API calls have been enhanced with the output field <line_type>. This new field will be an object in the <cart_invoice_line_items> array in the outputs of create_order_m and update_order_m; and an object in the <cart_inv_line_items> array in the output of create_order_with_plan_m.

Additional values (7–9 below) for <line_type> will also be returned in the API call get_invoice_details_m.

The field <line_type> has the following numeric values corresponding to line types as follows:

1. Recurring charge
2. Tax charge
3. Service credit
4. Coupon credit
5. Activation charge
6. Usage charge
7. Recurring arrears charge
8. Order charge
9. Surcharge

---

Plan Instance Contract Detail Mapping for get_all_acct_contracts_m (DEV-10209)

This feature adds the following non-mandatory input parameters to the get_all_acct_contracts_m API:

Parameter	Description
<plan_instance_no>	The plan instance number to which a contract has been assigned.
<client_plan_instance_id>	The client-assigned ID associated with the plan instance to which a contract has been assigned.

---

API Fixes 

• When updating account data via the update_acct_status_m API, comment text describing the update now appears only once at the Account Overview tab. (TICKET-16434)
• Statement emails are now being sent based on the billing group's notify method when updating the plan instance via update_acct_plan_multi_m as expected. (TICKET-18135)
• When you increase a customer's plan units using the update_acct_complete_m API, the prorated credits are now generated correctly. (TICKET-18247)
•  When adjusting bill date via adjust_acct_plan_billing_dates_m API the supplemental plan bill date, provision, and terminate dates will remain in sync with the Master Plan's bill date.. (TICKET-18306)
• When using update_acct_plan_multi_m the billing dates of recurring arrears charges are now pushed to the next billing cycle. (TICKET-18316)
• When you call the get_invoice_details_m API to obtain information about an invoice that includes an order, the output contains the <client_rate_schedule_id> field for order line item, as expected. (TICKET-18336)
• The performance of the replace_acct_plan_m API has been improved. (TICKET--18381)
• The performance of the update_acct_plan_status_m API has been improved. (TICKET-18392)