Cloud API functionality common to all plans

The user interface Priority column

In the BillingCenter user interface, the Administration tab has a set of screens that list each plan. All of these list screens have a Priority column on the right side. You can use this column to modify the plans' priority values.

For the plans that are assigned implicitly (such as payment allocation plans and return premium plans), the Priority is relevant. When a new account or policy is created, BillingCenter associates it with the relevant plan with the lowest priority. (The lowest priority plan is always shown at the top of the list.)

For the plans that are assigned explicitly (all plans except for payment allocation plans and return premium plans), the Priority is typically irrelevant. This is because the user or code that creates a new account, policy, or producer can associate it with any of the active plans. The priority values do not limit which plan can be chosen.

For all plans, the Priority column also controls the order in which the plans are listed on the screen.

The planOrder field

All plans have a planOrder field, which is set to an integer that defines the plan's Priority. A plan set to 1 is shown at the top of the screen (and is the plan assigned to new entities if the plan is assigned implicitly). A plan set to 2 is shown below the plan whose planOrder is 1, and so on.

As of this release, a new plan's planOrder is always set to (1 + the current highest planOrder value). In other words, new plans are given the highest possible planOrder value (and therefore the lowest priority). You cannot specify a plan's planOrder, either when the plan is created or through a PATCH.

Viewing Test Util API information

The Test Util API is available only when the BillingCenter environment is set to ci-test. The environment can be set only during start-up. For more information on how to start BillingCenter in a given environment, refer to the Administration Guide.

Querying for plan details

Use the following endpoint to retrieve details about a specific plan:

• GET /test-util/v1/plans/{planId}

The only information included in the payload is the plan's id and its inUse field.

Marking a plan as being in use

From a technical standpoint, a plan is considered to be in use if its inUse field is set to true. The actions that can be taken on a plan vary based on whether it is in use. For example, a billing plan cannot be deleted when it is in use.

In a normal BillingCenter environment, a plan becomes in use only once it is assigned to at least one account.

The Test Util API includes the following endpoint, which can be used to explicitly mark a plan as being in use. This can simplify testing of plan functionality related to being in use as it removes the need to assign the plan to an account (and possibly to create that account as well).

• POST /test-util/v1/plans/{planId}/mark-in-use

The request requires no request body.

For example, the following request marks plan bc:101 as being in use (even if it has not been explicitly assigned to any account).

POST /test-util/v1/plans/bc:101/mark-in-use

<no request payload>

There is no endpoint to mark a plan as not being in use.