Aria API Release 6.26

Previously, if the account preview statement was requested during bill lag days through the Aria6 UI, API, or batch process, then only the previous period’s statement could be viewed. With this enhancement, you now have the ability to request the current period’s statement preview, or to preview the previous period’s statement during bill lag days.

The create_order and update_order APIs now accept a date parameter, <fulfilled_date>, to record the fulfilled date on an order. The create_acct_complete, update_acct_complete, and create_acct_hierarchy APIs now accept parameters to specify the name or ID of the Revenue Recognition profile, which is assigned to an account. If both the name and ID are specified, then the name takes precedence over the ID.

Previously, Aria did not support the ability to make immediate plan changes and charge/credit pro-ration on the next billing day. If you wanted to immediately assign and apply pro-ration, the invoice had to be statemented immediately.

A <proration_invoice_timing> input parameter has been added to the create_new_plan and edit_plan Admintools APIs, which accepts inputs “A” or “I” to specify either Anniversary (A) or Immediately (I) options, described below.

• Anniversary – The prorated charges will be kept as open charges and will be included in the anniversary invoice.
• Immediately – The prorated charges will be billed immediately (existing behavior).

The below APIs create the open charges and credits when <proration_invoice_timing> is set to A (Anniversary):

• update_master_plan
• assign_supp_plan
• replace_supp_plan
• modify_supp_plan
• cancel_supp_plan
• assign_supp_plan_multi
• create_order_with_plans

A new get_acct_open_charges ­API has also been created to retrieve the open charges for a given account. Additionally, in the existing get_unapplied_service_credits API, the locked credit amount is returned with the new <amount_reserved_for_anniversary> output parameter.

Previously, the get_all_invoice_information API was not filtering correctly based on the <query_param> search parameter. For instance, a <query_param> of <user_id = 123ABC> and <invoice_type = P> returned all invoices that matched either of the conditions, rather than returning invoices that matched both of the conditions. This issue has been resolved to return the expected invoice matches.

Previously, the get_inventory_items and get_inventory_item_details APIs were not returning pricing details. The call has been corrected to return pricing as part of the response for these APIs.

Previously, when multiple supplemental field values were passed in the create_acct_complete API, and the first supplemental field value was blank, no supplemental field values were stored at the account level. In this scenario, the first supplemental field was a blank value, so no other supplemental fields could be validated to add at the account level. The code has been modified to validate the supplemental field values, even when the first supplemental field value is NULL. The pre-existing behavior continues to return an error message "6022- invalid supp field value" when any supplemental field value is NULL.

Previously, the delete_acct_coupon API was not cancelling a coupon from an account when the coupon code passed was in upper case. The logic has been modified to convert the coupon code to lower case before cancelling the coupon from the account.  The coupon is now cancelled from the account even when the coupon code that is passed from the delete_acct_coupon API is in upper case.