update_acct_complete_m Sample Call and Response
This example shows a client making a broad, single-call update to an existing account, based on the update_acct_complete_m method defined in plsql_m_r73.yml. The example changes account contact details and status, reassigns an existing master plan instance to a new dunning group, billing group, and rate schedule, applies a coupon, and updates the statement contact and payment method on one billing group.
This example covers account identity and contact fields, one master plan instance reassignment, one account-level coupon, one master plan-level coupon, one billing group array entry, and one payment method array entry. It does not cover every section this method supports, such as functional and collection account group reassignment, account supplemental fields, surcharges, custom rate overrides, plan instance product fields, additional contacts, e-invoicing fields, revenue recognition profile changes, or fraud control fields, all of which this method also accepts.
Sample call
{
"rest_call": "update_acct_complete_m",
"output_format": "json",
"client_no": 4471,
"auth_key": "b92f6e1c8a3d4f0e9b7c2a1d5e6f8091",
"acct_no": 100381,
"client_receipt_id": "ACCT-UPD-20260724-14",
"email": "jordan.mercer@example.com",
"phone": "415-555-0188",
"status_cd": 1,
"acct_coupons": [
{
"acct_coupon_cd": "SUMMER26"
}
],
"master_plan_instance_no": 3391027,
"dunning_group_no": 5521,
"mp_billing_group_no": 8842,
"alt_rate_schedule_no": 771,
"master_plan_assign_directive": 2,
"mp_coupons": [
{
"mp_coupon_cd": "PLAN10OFF",
"assignment_scope": 1
}
],
"billing_groups_array": [
{
"billing_group_no": 8842,
"billing_group_directive": 2,
"stmt_first_name": "Dana",
"stmt_last_name": "Whitfield",
"stmt_email": "dana.whitfield@example.com",
"stmt_city": "San Francisco",
"stmt_state_prov": "CA",
"stmt_country": "US",
"stmt_postal_cd": "94105"
}
],
"payment_methods_array": [
{
"payment_method_no": 90071,
"payment_method_directive": 2,
"pay_method_name": "Corporate Visa",
"pay_method_type": 1,
"cc_num": "4111111111111111",
"cc_expire_mm": 9,
"cc_expire_yyyy": 2029,
"cvv": "321"
}
]
}
The rest_call and output_format fields form the envelope added by the REST layer; they are not part of the method's own argument list in the yml. This example identifies the account using acct_no rather than the alternative client_acct_id. The status_cd value of one keeps the account active; other allowable values include zero for deactivated and negative ninety-nine for archived. Unlike create_acct_complete_m, this method does not wrap the account in a single acct object or repeat billing_group, payment_method, and dunning_group as separate array sections tied to each other by index; instead, dunning_group_no, mp_billing_group_no, and alt_rate_schedule_no are single scalar fields that apply directly to the one master plan instance identified by master_plan_instance_no, while billing_groups_array and payment_methods_array are separate top-level arrays used to update billing group and payment method details. The master_plan_assign_directive value of two means Aria performs the reassignment immediately, honoring the client's pre-configured universal rule on whether to prorate. Within billing_groups_array, billing_group_directive is set to two, meaning update the existing billing group; within payment_methods_array, payment_method_directive is likewise set to two, meaning update the existing payment method, both as opposed to a value of one, which would create a new billing group or payment method instead. The mp_coupons entry uses an assignment_scope of one, meaning the coupon is assigned at the master plan instance stack level, as opposed to a specific plan instance level. This example leaves out several deprecated fields entirely, including alt_msg_template_no, cn_alt_msg_template_no, client_alt_msg_template_id, and client_cn_alt_msg_template_id, all of which carry a deprecate_version of seventy-three, and parent_master_plan_inst_no, which carries a deprecate_version of twenty-eight.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"error_details": [],
"master_plan_instance_id": 3391027,
"out_master_plan_no": 4021,
"master_plan_proration_amount": 12.50,
"master_plan_proration_tax_amount": 1.03,
"out_invoice_no": 771045,
"out_billing_group_no": 8842,
"proc_cvv_response": "M",
"proc_avs_response": "Y",
"proc_status_code": "000",
"proc_status_text": "Approved",
"proc_auth_code": "AUTH556677"
}
An error_code of zero with an error_msg of "OK" indicates the overall update succeeded. The master_plan_instance_id and out_master_plan_no fields echo back the master plan instance and master plan that were reassigned, while master_plan_proration_amount and master_plan_proration_tax_amount report the charge and tax generated by the mid-period rate schedule change, and out_invoice_no identifies the resulting invoice. The proc_cvv_response, proc_avs_response, proc_status_code, proc_status_text, and proc_auth_code fields report the results of validating and authorizing the updated payment method. This example leaves out collection_error_code, collection_error_msg, parent_child_sync_error_code, parent_child_sync_error_msg, master_plan_error_code, and master_plan_error_msg, since these fields are populated only when a collection attempt, a parent-child billing date synchronization, or the master plan update itself encounters a problem, none of which occurred in this successful example. The error_details array is left empty because no errors occurred.