edit_acct_plan_queued_changes_m Sample Call and Response
This example edits two existing queued plan changes on one account in a single call: one queued change is executed immediately, and the other has its effective date changed. It is based on the plsql_m_r73.yml definition file.
This example includes every required field and a representative set of commonly used optional fields for editing specific queued changes by queue identifier; it does not cover editing all queued changes for an entire plan instance or account, or the fields that apply only to supplemental plan scenarios.
Sample call
{
"rest_call": "edit_acct_plan_queued_changes_m",
"output_format": "json",
"client_no": 100,
"auth_key": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6",
"acct_no": 3004512,
"edit_queued_changes": [
{
"queue_id": 771234,
"queue_edit_directive": 1
},
{
"queue_id": 771235,
"queue_edit_directive": 2,
"new_effective_date": "2026-09-15"
}
]
}
The rest_call and output_format fields are envelope fields added by the REST layer rather than fields documented on the method itself. The account is identified by acct_no, the Aria-assigned numeric account identifier, rather than by the alternative client-defined client_acct_id. The edit_queued_changes field is a nested, repeatable structure, so this example represents it as a JSON array with two entries, each targeting a specific queued change by queue_id rather than by the alternative plan_instance_no or client_plan_instance_id, which would instead apply the requested action to every queued change on that plan instance. The first entry uses a queue_edit_directive value of one, which executes the queued plan change immediately; the second uses a value of two, which changes the queued plan change's effective date to the accompanying new_effective_date value. A third directive value of zero, not shown here, would delete a queued plan change instead. This example omits the optional offset_months, alt_proration_start_date, auto_offset_months_option, offset_interval, and invoice_unbilled_usage fields, which apply only to supplemental plan scenarios, as well as assignment_directive, force_bill_date_reset, force_master_bill_date_reset, and the top-level do_write field, all of which are left at their documented defaults.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"queued_changes": [
{
"queue_id": 771234,
"plan_instance_no": 900215,
"edit_queued_change_status_cd": 2,
"edit_queued_change_status_label": "Executed successfully"
},
{
"queue_id": 771235,
"plan_instance_no": 900218,
"edit_queued_change_status_cd": 1,
"edit_queued_change_status_label": "Effective date modified"
}
]
}
An error_code of zero and an error_msg of "OK" indicate that Aria processed both requested edits successfully. The queued_changes array returns one entry per queued change submitted in the call, each with an edit_queued_change_status_cd confirming the outcome; a value of two means the change executed successfully and a value of one means its effective date was modified, matching the two directives sent in the call. A value of zero would confirm a deletion, and a value of three would indicate the edit failed to execute. This example omits the invoice_info, proration_details, and billing_errors output sections, since neither requested edit in this example produced new invoicing, proration, or billing errors to report, and it omits the installments_updated array because neither queued change in this example involved an installment plan. This example also omits the nonpublic third_party_errors output field.