Skip to main content
Aria Knowledge Central

assign_acct_plan_m Guide

Assigns a new master or supplemental plan to the specified account.

When you assign a new plan to an account, you can assign the following:

  • Billing group
  • Notification method and template
  • Payment methods
  • Contact information for billing, statements, and payment methods
  • Dunning information
  • Start date and proration options
  • Balance forward
  • Relationship to other plans (parent, child, etc.)
  • Rate schedules
  • Coupons, promotion codes and surcharges
  • NSO and SKU information
API Specification:

assign_acct_plan_m

Required Fields:
  • <client_no>
  • <auth_key>
  • <acct_no> or <client_acct_id>
  • <new_plan_no> or <new_client_plan_id>
Error Messages: assign_acct_plan_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 is determined based on your setting for the parameter Override Bill Thru Date SuppPlanBehavior.

To see a description of the parameter in the Aria UI, click Configuration > Billing > Invoice Settings.

Input Fields
 
Field Name: Notes:
<existing_primary_payment_method_no> The same pay method sequence number cannot be used for the primary and secondary payment method.
<existing_client_primary_payment_method_id> The same pay method sequence number cannot be used for the primary and secondary payment method.
<existing_backup_payment_method_no> The same pay method sequence number cannot be used for the primary and secondary payment method.
<existing_client_backup_payment_method_id> The same pay method sequence number cannot be used for the primary and secondary payment method.
<existing_dunning_group_no> You must associate Dunning Groups with parent-pay Master Plan Instance. If you do not specify a Dunning Group when assigning an Master Plan Instance, the system will create an empty Dunning Group (i.e., without any values in the attributes) and assign it to that Master Plan Instance automatically, without issuing an error or warning.
<existing_client_def_dunning_group_id> You must associate Dunning Groups with parent-pay Master Plan Instances. If you do not specify a Dunning Group when assigning a Master Plan Instance, the system will create an empty Dunning Group (i.e., without any values in the attributes) and assign it to that Master Plan Instance automatically, without issuing an error or warning.
<resp_level_cd>

To specify the responsible Master Plan Instance for the assigned Plan, pass in a <resp_master_plan_instance_no> and/or <resp_client_master_plan_instance_id>.

See Parent-child Account Best Practices for more information.

<offset_months> This API does not support the use of the <offset_months> input with an anniversary <assignment_directive>. Instead, you can use the <offset_interval> field with an anniversary <assignment_directive> to delay the addition of a Plan with a daily, weekly, or any other billing interval.
<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.
<collection_group_bg_row> (array)
  • 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.
  • Only one collection group can be assigned to each billing group.
  • 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.
<bill_lag_days> Bill lag days are the number of days prior to (negative) or after (positive) an account billing date at which an invoice should be generated for your specified Master Plan Instance. See Bill Lag Days for more information.

<proc_field_override> (array)

  • <transaction_type> (field)

If you use the Chase Paymentech or Vantiv Payment Gateway, this field allows you to tell that payment gateway which transaction type is involved (examples: single or recurring transaction) when you process a customer's payment information.

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
<resp_master_plan_instance_no> Required if the responsibility level (in the <resp_level_cd> field) is set to one of the two parent pay options.
<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.
<alt_proration_end_date>

Example: If you are assigning a daily or weekly Plan, you can pass a date into this field to align the next bill date of the new Plan with that of the customer's other daily or weekly Plan(s).

The start date of the next full invoice will be the day after your specified <alt_proration_end_date>.

Allowable Values:

Input Fields

Field Name: Notes:
notify_method

How the client communicates with the account holder. If a notification method is not provided, this value defaults to "1" (HTML email).  

Allowable values:
primary_pay_method_type

This is the method_id corresponding to a payment method such as credit card, Electronic Check, Pre-Paid, Net Terms, etc.

Allowable values:

Values Description
-1 External Payment
1 Credit card
2 Electronic Check (ACH)
3 Pre-paid
4 Net terms 30
5 Net terms 10
6 Net terms 15
7 Net terms 60
8 Click&Buy
9 Net Terms 0
10 PayByCash
11 PayPal Express Checkout
12 Net Terms 45
13 Tokenized Credit Card
14 Purchase Power
15 Net Terms 35
16 Net Terms 75
17 Net Terms 90
18 Net Terms 120
19 Net Terms 25
20 NETS
26 Direct Debit
37 Tokenized Direct Debit
48 Tokenized ACH
status_until_alt_start

Status of the Master Plan Instance prior to alt_start_date or alt_bill_day. If the alt_start_date or alt_bill_day field is used, this field is required and defaults to 0 (inactive) if no value is provided. If an alternate starting date or alternate bill day is provided, the Master Plan Instance remains in this status until its start date arrives. This only applies if a prorated invoice is not created. If a prorated invoice is created, this field is ignored.

Allowable values:

Values Description
1 Active
2 Cancellation Pending
3 Termination Pending
31 Installation Pending
32 Registered Pending Activation
41 Active Trial
61 Active Non-billable
-1 Suspended
-2 Cancelled
-3 Terminated
invoicing_option

Indicator for performing full invoicing, and Perform Prorated Invoicing or client-defined on this account as part of this call.

Allowable values:

Values Description
1 Perform full invoicing
2 Perform prorated invoicing
3 Use client default
4 None
resp_level_cd

The responsibility level code. These are values 1 through 3 as described in the legend for this argument. 

To specify the responsible Master Plan Instance for the assigned Plan, pass in a <resp_master_plan_instance_no> and/or <resp_client_master_plan_instance_id> as described below.

Please see Parent-child Account Best Practices for more information.

Allowable values:

Values Description
1 Standard Self-Pay: default
2 Parent Pay: Usage accrues under self, invoices are generated per self's plan rules but are presented for payment against parent account
3 Parent Usage & Pay: Usage accrues under parent and applied only to parent's plan rules and presented to parent for payment
plan_status

Updates thePlanstatus for thePlanInstance.

Allowable values:

Values Description
1 Active
2 Pending Cancellation
3 Pending Termination
31 Pending Installation
32 Pending Activation
41 Trial
61 Active Non-billable
0 Inactive
-1 Suspended
-2 Cancelled
-3 Terminated
assignment_directive

The rule to be applied to this assignment request, governing the proration rule is applied. Default behavior is to make thePlanchange(assign/deassign aPlanto an account, change units on an existing Plan, etc.) immediately based on client-defined default proration rule, resulting in appropriate prorated charge and credit. This field is only honored for a Supplemental Plan, and not for Master Plans.

Allowable values:

Values Description
1 (Default) Perform the requestedPlanchange on the account's next scheduled billing anniversary date. The account does receive service under
thisPlan(forPlanassignments) or have it removed (for de-assignments) until that date. If aPlanis being assigned, initial billing for a full period of the givenPlanis performed on the account's next scheduled anniversary date. No charge or credit proration effect. No new recurring charges or credits are generated when no proration occurs.
2 Perform the requestedPlanchange immediately, honoring the client's pre-configured universal rule for performing or not performing proration as a result of a mid-billing-periodPlanassignment or de-assignment. No new recurring charges or credits are generated when no proration occurs.
3 Perform the requestedPlanchange immediately, ignoring the client's pre-configured universal rule for performing or not performing proration and forcing NO PRORATION. No new recurring charges or credits are generated when no proration occurs.
4 Perform the requestedPlanchange immediately, ignoring the client's pre-configured universal rule for performing or not performing proration and forcing PRORATION.
5 Perform the requestedPlanchange immediately, ignoring the client's pre-configured universal rule for performing or not performing proration and forcing PRORATION FOR CHARGES ONLY. NOTE: This value is not permitted when cancelling Supplemental Plans.
7 Perform the requestedPlanchange on the specified effective_date, honoring the client's pre-configured universal rule for performing or not performing proration as a result of a mid-billing-periodPlanassignment or de-assignment. No new recurring charges or credits are generated when no proration occurs.
8 Perform the requestedPlanchange on the specified effective_date, ignoring the client's pre-configured universal rule for performing or not performing proration and forcing NO PRORATION. No new recurring charges or credits are generated when no proration occurs.
9 Perform the requestedPlanchange on the specified effective_date, ignoring the client's pre-configured universal rule for performing or not performing proration and forcing PRORATION.
10 Perform the requestedPlanchange on the specified effective_date, ignoring the client's pre-configured universal rule for performing or not performing proration and forcing PRORATION FOR CHARGES ONLY. NOTE: This value is not permitted when cancelling a Supplemental Plan.
do_write

Boolean indicator that specifies whether to actually perform the requested operation. If 'false' is passed in this field, Aria calculates, if applicable, any potential effects from this call such as proration, Planassignments, etc. and return all relevant data without actually performing the requested operation or making any changes to the account. This is useful to interfaces that want to present the user with a 'confirmation page' informing them of the potential effects of the requested operation prior to actually performing it. Do_write defaults to 'true'

Allowable values:

Values Description
true true
false false
auto_offset_months_option

Automatically set the offset for the billing anniversary month.

Allowable values:

Values Description
1 sync to Master Plan recurring bill thru date
usage_pooling

Indicates whether usage pooling is enabled for this Plan instance.

Allowable values:

Values Description
true Usage pooling is enabled for this Plan instance
false Usage pooling is not enabled for this Plan instance (default)
usage_threshold_applicability

Usage tracking options on the Plans in the account

Allowable values:

Values Description
UT Usage Type
UP Usage Pool
nso_bill_immediately

Indicates whether to bill the NSO items immediately or if not set bill on next billing anniversary date.

Allowable values:

Values Description
0 Fulfill immediately. Bill on next anniversary (default)
1 Fulfill immediately. Bill immediately.
2 Order held.
3 Fulfill on fulfillment date. Bill on the next anniversary bill after the fulfillment date. Note that if the fulfilled date is in the past/current day, then the fulfillment will happen in API itself as in nso_bill_immediately = 0
4 Fulfill on fulfillment date. Bill on the fulfillment date. Note that if the fulfilled date is in the past/current day, then the fulfillment and billing will happen in API itself as in
nso_bill_immediately = 1.
5 Fulfill on fulfillment date. Bill on the next anniversary bill that bills arrears services through the fulfillment date. Note that if the fulfilled date is in the past/current day, then the fulfillment will happen in API itself as in nso_bill_immediately = 0.
proration_invoices_timing

Determines whether to create a separate invoice for prorated charges immediately, or defer to the next anniversary date. Note that this will override the Proration Invoice Timing configuration saved with thePlanin the product catalog.

Allowable values:

Values Description
Null(default) Honor Proration Invoice Timing configuration saved with thePlanin the product catalog
0 Indicates to generate the invoice immediately for the pro-rated charges
1 Indicates to generate the invoice to the next anniversary date for the pro-rated charges
cc_id

A numeric code indicating the type of credit card.

Allowable values:

Values Description
1 VIsa
2 Mastercard
3 American Express
4 Discover
5 Diners Club/Carte Blanche
6 Maestro
7 JCB
8 Laser
9 Dankort
combine_invoices

Indicator for combining invoices when retroactive start dates, negative bill lag days, orPlanchanges just prior to the next billing date would otherwise have generated multiple invoices. The allowable values are 1, 2, or 3.

Allowable values:

Values Description
1 Combine Invoices (long cycle)
2 Do Not Combine Invoices (short cycle)
3 Use client default configuration setting
force_master_bill_date_reset

Overrides the "Sync_mstr_bill_dates_on_1st_supp" client-level setting that determines whether or not no-charge Master Plan billing dates should be reset when assigning a new Supplemental Plan or when the Supplemental Plan instance status is updated to a billable status. If this value is left empty, the client-level setting will take effect.

Allowable values:

Values Description
  If this value is left empty, the client-level setting
(Sync_mstr_bill_dates_on_1st_supp) will take effect.
1 Do not reset Master Plan billing dates.
2 Reset Master Plan billing dates if Master Plan is "free", the account has no "billable" Supplemental Plans, and the newly-assigned Supplemental Plan is "billable.
3 Reset Master Plan billing dates if Master Plan is "free" and the account has no active Supplemental Plans.
recurring_process_model_ind

Defines a recurring payment type for Credit Card and Tokenized Credit Cards.

Allowable values:

Values Description
0 Cardholder-Initiated Transaction – Credentials on File: a credit card transaction initiated by the cardholder for a new order or aPlanupgrade that uses a credit card that is currently stored in Aria. (Default)
1 Cardholder-Initiated Transaction: a credit card transaction initiated by the cardholder for a new account or creating an order that uses an alternate credit card that is not currently stored in Aria.
2 Merchant-Initiated Transaction – Standing Instruction – Recurring: a credit card transaction initiated by Aria’s clients for a recurring charge that uses a credit card that is currently stored in Aria.
3 Merchant-Initiated Transaction –Unscheduled Credentials on File: a credit card transaction initiated by Aria’s clients for a non-recurring charge (one-time order orPlanupgrade) that uses a credit card that is currently stored in Aria.
usage_accumulation_reset_months_renewal_option

Determines whether the usage accumulation reset months will automatically reset to same value at the end of the current period or will expire at end of current period.

Allowable values:

Values Description
NULL or 1 Recurring / Auto Renew (Default)
2 Single Use.
transaction_type

Allowable values:

Values Description
-1 Use client configuration settings for "Send Transaction Type as Recurring for Initial Request Where Possible" or "Send Transaction Type as Recurring for Subsequent Request" as applicable. (default)
1 (Chase) Single transaction mail/telephone order (MOTO) - Designates a transaction where the accountholder is not present at a merchant location and completes the sale over the phone or through the mail. The transaction is not for recurring services or products and does not include sales that are processed via an installment Plan.
2 (Chase) Recurring Transaction -Designates a transaction that represents an arrangement between an accountholder and the merchant where transactions are going to occur on a periodic basis.
3 (Chase) Installment Transaction -Designates a group of transactions that originated from a single purchase where the merchant agrees to bill the accountholder in installments.
4 (Chase) Deferred Transaction -Designates a transaction that represents an order with a payment delayed for a specified amount of time.
5 (Chase) Secure Electronic Commerce Transaction - Designates a transaction completed via the Internet at a 3-D Secure capable merchant and in which the accountholder was fully authenticated. (examples: 3-D Secure includes Verified by Visa, Mastercard Identity Check, American Express SafeKey and Discover ProtectBuy.)
6 (Chase) Non-Authenticated Electronic Commerce Transaction -Designates a transaction completed via the Internet at a 3-D Secure capable merchant that attempted to authenticate the accountholder using 3-D Secure (examples: 3-D Secure includes Verified by Visa and Mastercard Identity Check.) Verified by Visa, Mastercard Identity Check, American Express SafeKey and Discover ProtectBuy transactions in the event of: * A non-participating issuer * A non-participating accountholder of a participating issuer * A participating issuer, but the authentication server is not available
7 (Chase) Channel Encrypted Transaction - Designates a transaction between an accountholder and a merchant completed via the Internet where the transaction includes the use of transaction encryption such as SSL (Secure Sockets Layer), but authentication was not performed. The accountholder payment data was protected with a form of Internet security, such as SSL, but authentication was not performed. For Discover, indicates an e-commerce Card Transaction with data protection in which ProtectBuy for Cardholder authentication was not used.
8 (Chase) Non-Secure Electronic Commerce Transaction - Designates a transaction between an accoutholder and a merchant completed via the Internet where: * The transaction does not include the use of any transaction encryption such as SSL * Authentication is not performed * An accountholder certificate is not managed.
I (Chase) IVR Transaction (PINless Debit only) -Designates a transaction where the accountholder completes the sale via an interactive voice response (IVR) system.
R (Chase) Retail Transaction -Designates a transaction where the accountholder was present at a merchant location.
telephone (Vantiv) The transaction is for a single telephone order.
mailorder (Vantiv) The transaction is for a single mail-order transaction.
bank_acct_type

The type of bank account being used (for primary_pay_method_type 2).

Allowable values:

Values Description
savings savings
checking checking
business business

Output Field

Field Name: Notes:
line_type

Specifies the type of charge or credit associated with this line item.

Allowable values:

Values Description
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
  • Was this article helpful?