Home > Aria Crescendo Documentation > Aria Crescendo core api > update_acct_plan_multi_m Guide

update_acct_plan_multi_m Guide

Table of contents
API Specification: update_acct_plan_multi_m
Required Fields:
  • <client_no>
  • <auth_key>
  • <acct_no> or <client_acct_id>
  • <plan_updates> (array)
    • <plan_updates>
    • <plan_directive> 
Error Messages: update_acct_plan_multi_m Error Messages

Additional Guidance:

  • If you assign a Supplemental Plan at the same time as its Master Plan and provide an override bill through date, the bill through date for the Supplemental Plan is determined based on your setting for the parameter Override Bill Thru Date Supp Plan Behavior.

    To see a description of the parameter, click Configuration > Billing > Invoice Settings.
  • To determine the Master Plan's bill day when the update_acct_plan_multi_m API is called, Aria considers the following inputs in the order listed below:
    1. <override_bill_thru_date>;
    2. then whichever of these you passed in: <alt_start_date> or <alt_bill_day>; 
    3. then whichever of these you passed in: <retroactive_start_date> or <effective_date>.
  • This API performs a maximum of 100 Plan updates in a single call.

Input Fields

Field Name: Notes:
<dunning_state>
  • If you set this field to 1 (in progress), then you can specify one or more of the following dunning options available in these fields:
    • <degrade_date>;
    • <new_dunning_step>;
    • <config_dunning_late_fee_option>; and/or
    • <config_dunning_email_option>.
  • When you change the <dunning_state> to 0 (none), you should also pass in your chosen  <plan_status_cd> for the Master Plan Instance.

    Example: you may want to change the Master Plan Instance's status from
    -1 (suspended) to 1 (active).
  • If you set this field to (in progress) but the Master Plan Instance does not have a balance due, then Aria will move the Master Plan Instance out of dunning on the date on which the next dunning step begins.

    This applies to Master Plan Instances associated with either payment type: net terms or electronic.
  • In addition to self-pay Master Plan Instances, dunning input arguments can now also now be used for parent-pay Master Plan Instances. Also note that when self-pay Master Plan Instance manually enters dunning via this API, all of their parent-pay Master Plan Instances will enter dunning. This is only applicable when entering the dunning. During this special process of entering parent-pay Master Plan Instance, the “config_dunning_late_fee_option and config_dunning_email_option” will only be applicable for self-pay Master Plan Instances and NOT to the parent-pay Master Plan Instance.
  • <billing_group_no>
  • <client_billing_group_id>
  • <billing_group_idx>
This is mandatory when converting an Master Plan Instance from parent-pay to self-pay.
  • <dunning_group_no>
  • <client_dunning_group_id>
You must associate a dunning group with parent-pay Master Plan Instances. If you do not specify a dunning group, Aria will automatically create an empty dunning group (without any attributes) and assign it to that Master Plan Instance.
<alt_proration_start_date>
  • If you assign a Supplemental Plan using this API, the <alt_proration_start_date> must be between the Master Plan’s provision date and the next occurrence of a bill day.
  • The <alt_proration_start_date> can also go back more than one billing period into the past as long as it is after the Master Plan’s provision date.
  • If you replace a Master Plan using this API:
  • When the replaced Master Plan’s billing interval is the same as the new Master Plan’s, the <alt_proration_start_date> must be within the date range of the recurring billing period that was last invoiced.
  • When the replaced Master Plan’s billing interval is different from the new Master Plan’s, the <alt_proration_start_date> must be between the start date of the recurring billing period that was last invoiced and the next occurrence of a bill day.
  • If you cancel a master or Supplemental Plan using this API, the <alt_proration_start_date> must be within the date range of the recurring billing period that was last invoiced.
  • <primary_payment_method_no>
  • <primary_client_payment_method_id>
  • <primary_payment_method_idx>
  • <backup_payment_method_no>
  • <backup_client_payment_method_id>
  • <backup_payment_method_idx>
The same pay method sequence number cannot be used for a primary and secondary payment method.
<collection_group_bg_row>

Aria will use this order of precedence when selecting the payment gateway to use for processing a payment:

  1. Collection group assigned to the billing group associated with the master plan instance being invoiced;
  2. Collection group to which the customer is assigned at the account level.

Aria allows accounts to have multiple billing groups with different collection groups when using tokenized credit cards that were tokenized outside of Aria. To facilitate multiple payment methods, the billing agreement ID (token) is validated against the specific collection group. When there is no collection group specified, then the agreement ID will be validated against the account level collection group. When no collection group at account level or billing group level is specified, then the agreement ID will be validated against the last processor mapped to that client.

<new_dunning_step>

Applicable only for Master Plans, and only if the <dunning_state> is set to 1.

For more information about available dunning options, please see the <dunning state> field.

<config_dunning_late_fee_option>

Applicable only for Master Plans, and only if the <dunning_state> is set to 1.

For more information about available dunning options, please see the <dunning state> field.

If you set this field to 1, Aria will immediately charge the customer the late fee.

<config_dunning_email_option>

Applicable only for Master Plans, and only if the <dunning_state> is set to 1.

For more information about available dunning options, please see the <dunning state> field.

If you set this field to 1, Aria will immediately email the notification to the customer.

  • <resp_master_plan_instance_no>
  • <resp_client_master_plan_instance_id>
Required if the responsibility level (in the <resp_level_cd> field) is set to one of the two parent pay options.

<proc_field_override> (array)

  • <transaction_type>

This field applies to credit cards and tokenized credit cards. If you don't pass a value into this field, it will default to -1 (use client configuration settings).

The value that you pass into this field will override the Recurring Options that you set in the Aria application under:

  • Configuration > Payments > Payment Gateways > Chase Paymentech/Vantiv > Gateway Options; and
  • Configuration > Payments > Collection Groups > Chase Paymentech/Vantiv > Collection Group Options.

Currently, only Chase Paymentech and Vantiv support this field. Other payment gateways might not honor all of the allowable values for this field. You will need to check your payment gateway documentation for confirmation.
 
Aria will use this order of precedence to determine the transaction type:

  1. value passed into this field
  2. collection group configuration
  3. payment gateway configuration
  4. transaction type that you specified in the <recurring_processing_model_ind> field

Output Fields

Field Name: Notes:

<tax_details> (array)

  • <unrounded_tax_amt>
  • <carryover_from_prev_amt>
  • <before_round_adjusted_tax_amt>
  • <carryover_from_current_amt>

Assuming that the client setting Aria Internal Tax Rounding Method is set to "Per invoice."

 

Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.