This chapter describes how to change account and service status in Oracle Communications Billing and Revenue Management (BRM).
It also describes how to manage deferred actions.
For more information on changing service states, see "About Triggering State Changes in Custom Service Life Cycles".
An account status can be active, inactive, or closed.
You can backdate account status changes to a date earlier than the current date. You can schedule the status change for a future date. You change account status on the Change Account/Service Status panel in Customer Center.
For more information on the procedures for changing account and service status, see Working with products, deals, discounts, and services.
When an account is active, the customer can use all active services.
When an account is inactive, the customer cannot use any service. Typically, the customer can still use Web administration forms when the account is inactive. For example, if a payment cannot be made because of a credit card verification error, the customer can use the Web administration form to update credit card and address information so the payment can be made.
Note:
Inactivating an account prevents customers from generating usage and cycle balance impacts but does not prevent the account from being charged for bills already due. See "Billing Inactive Accounts".When an account is closed, the customer cannot use any service. A closed account is normally closed permanently, but you can reactivate it in Customer Center if it was closed by mistake. Closing an account does not delete the account or its service login names and passwords from the BRM database. Because closed accounts are never deleted from the database, there is no time limit on when they can be reactivated.
Important:
Closing an account cancels all the products owned by the account.Note:
You cannot delete closed accounts from a production database, but you can reuse their login names. See "Reusing Login Names and Passwords from Closed Accounts or Canceled Services".You can customize what a customer can do when an account is closed or inactive. For example, you can allow customers to view their account status on the Web.
The only functional difference between a closed account and an inactive account is that you can enable BRM to activate and inactivate accounts automatically. BRM cannot automatically close an account or automatically activate a closed account.
Changing the status of an account also changes the status of all the account's services. Changing the status of a service affects only that service.
When you inactivate an account, all the account's services are inactivated.
When you reactivate an inactive account, all the account's services that were inactivated when the account was inactivated are reactivated. Services that were inactivated independently of the account status are not reactivated.
When you close an account, all the account's services are closed.
When you reactivate a closed account, all the account's services that were closed when the account was closed are reactivated. Services that were manually inactivated (whose status was not changed when the account was closed) remain in the inactive state when the account is re-activated.
Note:
When you close an account, all the products owned by the account are canceled. When you re-activate the account, you need to re-purchase the products.Changing the status of an account also changes the status of all the account's active products and discounts.
When you inactivate an account, all the account's products and discounts are inactivated.
Note:
In Customer Center, the inactivated products and discounts continue to be displayed on the account's Product tab.When you reactivate an inactive account, you reactivate all products and discounts that were active when the account was active. Products and discounts that were inactive when the account was active remain inactive.
When you close an account, all the account's products and discounts are canceled.
Note:
In Customer Center, the canceled products and discounts are removed from the account's Product tab.When you reactivate a closed account, the account's products and discounts are not reactivated. To regain the canceled products and discounts, the account must repurchase the deals that contain them.
Reactivating a closed account does not reinstate the canceled products and discounts. To regain the canceled products and discounts, the account must repurchase the deals that contain them.
BRM supports backdating the status change of a product, discount, service or account to a prior date.
BRM does not allow backdating the status change if:
The backdated date is prior to the G/L posting date. See "About Backdating Beyond the G/L Posting Date".
The backdated date is prior to the effective date of the account, service, product or discount. See "How Effective Time Is Used to Validate Backdating Operations".
The backdated date is prior to the date of the last status change. You can backdate any status change only up to the date the last status change happened; undoing previous status changes is not allowed.
For example, consider that you change the status of an account from active to inactive on September 1. On October 1, you cannot backdate a status change to a date prior to September 1.
When you backdate the status change, a charge or a refund is applied for the backdated period.
For example, consider that on July 1, you backdate the status of an active account to make it inactive effective from June 1. If the cycle fee is already applied for the period of June 1 to July 1, another cycle fee event is generated that calculates and refunds the charges.
You must rerate any usage events that have occurred in the backdated period to account for the status change.
To backdate a status change, enter the date to which you want to backdate the account, service, product, or discount status change in the PIN_FLD_END_T field of the applicable opcodes. For example, enter the backdated date in the PIN_FLD_ END_T field of the following opcodes:
PCM_OP_CUST_SET_STATUS: for backdating the account status change.
PCM_OP_CUST_UPDATE_SERVICES: for backdating the service status change.
PCM_OP_CUST_SET_PRODUCT_STATUS: for backdating the product status change.
PCM_OP_CUST_SET_DISCOUNT_STATUS: for backdating the discount status change.
If a product status changes from active to inactive or closed before the end of the billing cycle:
If the product includes a cycle forward rate that allows proration, the unused fee is refunded.
If the product includes a cycle arrears rate that allows proration, the used amount is charged.
When you inactivate an account, you also inactivate all its services, which prevents the customer from using the services. BRM does not charge usage and cycle fees while the account is inactive. But while the account is inactive, BRM continues to collect bills that were due before the account was inactivated.
In most cases, if a service is inactive or closed, the service is unprovisioned on the network, and no events can be generated by using that service. However, there might be occasions where a call is made even though the service has been inactivated or closed in BRM but is still provisioned on the network. In that case, BRM still rates the event.
If a service was closed because it was associated with a plan transition, its status flag value is set to PIN_STATUS_FLAG_DUE_TO_TRANSITION, and you cannot change the closed status of the service. For more information on transition rules, see "Transitioning Deals".
You can set Customer Center permissions to restrict who can change the status of accounts. See "Setting up Permissions in BRM Applications" in BRM System Administrator's Guide.
In Customer Center, you can schedule account and service status changes for a future date. You can use a daily billing utility, pin_deferred_act, to change the status automatically on the scheduled date. See "Executing Deferred Actions With the pin_deferred_act Utility" in BRM Configuring and Running Billing.
Scheduling account reactivation works differently for inactivating and closing:
When you inactivate an account or service, you can set a future date to reactivate the account or service, or you can reactivate the account or service manually.
When you close an account or service, you cannot schedule reactivation. Closed accounts and services must be reactivated manually.
Customer Center lists all deferred actions scheduled for an account. From the list, you can cancel an action or execute it immediately.
For more information, see "Managing Deferred Actions".
BRM can automatically inactivate and reactivate accounts even when no deferred action is scheduled. By default, BRM automatically inactivates accounts in the following situations:
A credit card payment fails because a nonvalid credit card is used.
A credit card validation fails, and the item is 30 or more days past due.
The account is a child account with a nonpaying bill unit, and the parent account is inactivated.
Note:
By default, account status is not changed when a credit limit is reached. However, also by default, service authorization requires that the credit limit has not been reached, so reaching a credit limit prevents a customer from using a service.To change these defaults, you must customize the following policy opcodes:
PCM_OP_PYMT_POL_COLLECT
PCM_OP_ACT_POL_SPEC_VERIFY
Note:
When you close an account or service, you cannot schedule reactivation. Closed accounts and services must be reactivated manually.By default, changing the status of a parent account changes the status of child accounts and bill units in the parent's hierarchical group in the following ways:
The status of all the parent account's bill units are changed.
The status of every subordinate bill unit in every child account is changed.
Note:
The child account's status and the status of nonsubordinate bill units in child accounts are not changed.If a subordinate bill unit in a child account is also the parent of another account's bill units, the status of the subordinate bill units in the other account is also changed.
For more information, see "How Bill Unit Status Changes Affect Hierarchies" in BRM Managing Accounts Receivable.
You cannot prevent the status of a nonpaying child bill unit from changing when its parent bill unit's status changes.
Note:
Changing the account status of a child account does not affect the status of its parent.
In a sponsor group, if the sponsor group owner account is inactive, the member accounts receive the balance impacts that normally would have been sponsored.
By default, you can not reuse the login name of a closed account or canceled service, although BRM has no restriction on reusing passwords.
To reuse login names, set up BRM to automatically modify the login name when you close an account. For example, you could have the string #CLOSED# prepended to the login name.
You can customize the PCM_OP_CUST_POL_PREP_STATUS policy opcode to automatically add characters to a login name when an account's status changes.
By default, when inactive products and discounts are reactivated, the purchase, usage, and cycle start times are changed to the current (reactivation) date. You can use the change_start_time_on_activation entry in the Connection Manager (CM) configuration file to change this behavior so that when inactive products and discounts are reactivated, the original purchase, usage, and cycle start times are kept.
This setting does not affect products whose purchase is deferred to a later date. For those products, if the product is reactivated before the purchase date, the original purchase, usage, and the cycle start times are always kept, even if this option is enabled.
Note:
The purchase and cycle start times determine the date on which the purchase and cycle charges begin to be applied to the product and discount.To keep the original purchase, usage, and cycle start times:
Open the CM configuration file (BRM_Home/sys/cm/pin.conf), where BRM_Home is the directory in which you installed the BRM software.
Add the following entry:
-fm_bill change_start_time_on_activation 0
0 keeps the original purchase, usage, and cycle start times.
1 changes the purchase start time, usage start time, and cycle start time to the reactivation date. This is the default.
Save and close the file.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
By default, inactivating an account inactivates all services owned by the account. You can use the allow_active_service_with_inactive_account CM pin.conf file entry to allow inactive accounts to have active services.
To allow active services with inactive accounts:
Open the CM configuration file (BRM_Home/sys/cm/pin.conf).
Add the following entry.
-fm_cust allow_active_service_with_inactive_account 1
where
0 prohibits active services with inactive accounts. This is the default.
1 allows inactive accounts to have active services.
Save and close the file.
Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
To set the status of a /purchased_product object owned by an account, use the PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS opcode.
PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS is called in the following cases:
When the status of an account or service is changed.
When a product status is changed. You might need to change only the product status itself if, for example, the product was purchased as inactive because of future provisioning and you activate it later.
Note:
When you change the status of a base product, the opcode automatically changes the status of any associated customized products. You cannot set the status of a customized product directly.PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS performs the following tasks:
Opens a transaction.
Retrieves the new status from the PIN_FLD_STATUSES array in the input flist. If the product status change is due to an account or service status change, PIN_STATUS_FLAG_DUE_TO_ACCOUNT is passed in the PIN_FLD_STATUS_FLAGS field of the array.
Reads the old status of the product from the database.
If PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS is not called in CALC_ONLY mode, applies the new status to the product.
If the product is inactive due to future provisioning and is now being activated, then the PCM_OP_SUBSCRIPTION_SET_PRODINFO opcode is called to modify the purchase start date and time to the date and time of reactivation. If the original cycle and usage start date is earlier than the new purchase start date, PCM_OP_SUBSCRIPTION_SET_PRODINFO also resets the cycle and usage start date and time to the new purchase start date. For more information, see "Handling Purchase, Cycle, and Usage Start and End Times".
If PCM_OP_SUBSCRIPTION_SET_PRODINFO is not called, an /au_purchased_products audit object is generated, which is used for rerating events.
If PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS is called while activating an account, sets the purchase time to NOW and sets the usage and cycle fees by calling PCM_OP_SUBSCRIPTION_SET_PRODINFO.
If the product status change is backdated, validates that:
The date to which the product status change is backdated is not prior to the G/L posting date.
The date to which the product status change is backdated is not prior to the account or service's effective date.
The date to which the product status is backdated is not prior to the last status change of the account or service. See "About Backdated Status Change".
Creates an audit log event object (/event/billing/product/action/modify/status).
Closes the transaction.
If the PCM_OP_CALC_ONLY flag is set when calling PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS, it returns the entire event flist for the events created as a result of the modification. Otherwise, it returns the event Portal object IDs (POIDs) of all event objects created as a result of the modification.
For general information about modifying a discount in a deal, see "Modifying Discount Attributes".
To set the status of a /purchased_discount object owned by an account, use the PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS opcode.
This opcode is called when the status of a discount is changed. This can occur in the following cases:
When the status of the account or service that owns the discount is changed. In this case, the discount's status is changed to the status of the account or service.
When the status of a discount is changed from inactive to active.
PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS performs the following tasks:
Validates and sets the new status. The new status cannot be the same as the old status.
Note:
When you change the status of a base product, the opcode automatically changes the status of any associated customized products. You cannot set the status of a customized product directly.Calls the PCM_OP_SUBSCRIPTION_SET_DISCOUNTINFO opcode to reset the /discount object's purchase, cycle, and usage start and end dates.
Note:
If the discount purchase, cycle, and usage start or end dates are already set to a later date, or the CM is configured to not reset dates, the dates are not reset.If the status change of the discount is backdated, this opcode validates that:
The date to which the discount status change is backdated is not prior to the general ledger (G/L) posting date.
The date to which the discount status change is backdated is not prior to the account or service effective date.
The date to which the discount status is backdated is not prior to the last status change of the account or service. See "About Backdated Status Change".
Generates an /event/billing/discount/action/modify/status event to record the status change.
If successful, PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS returns the POID of the /event/billing/discount/action/modify/status event.
For more information on changing status, see "Changing Account and Service Status".
The following opcodes are used to set account, bill unit, and service status:
PCM_OP_CUST_SET_STATUS. See "Changing the Status of an Account, Bill Unit, or Service".
Important:
Do not call this opcode directly for service status changes. Call the PCM_OP_CUST_UPDATE_SERVICES opcode instead.PCM_OP_CUST_POL_PREP_STATUS and PCM_OP_CUST_POL_VALID_STATUS. See "Customizing Status Changes".
PCM_OP_ACT_POL_EVENT_LIMIT. See "Inactivating Accounts that Exceed a Specified Limit".
The PCM_OP_CUST_SET_STATUS opcode changes and checks the status of an account, bill unit, or service. You can call the opcode directly for accounts and bill units. For service status changes, use the PCM_OP_CUST_UPDATE_SERVICES opcode, which in turn calls PCM_OP_CUST_SET_STATUS. See "Modifying Services" for more information.
In addition to changing status, PCM_OP_CUST_SET_STATUS does the following:
Triggers auto-billing if bills are still pending. See "About Auto-Triggered Billing" in BRM Configuring and Running Billing.
Calls opcodes to prorate cycle fees.
To return all the fields in the event object, set the PCM_OPFLG_READ_RESULT flag. If this flag is not set, PCM_OP_CUST_SET_STATUS returns only the POID.
If PCM_OP_CUST_SET_STATUS is called at the account level, more than one result can be returned:
One for each service owned by this account.
One for each bill unit owned by this account.
One or more for each child account and subordinate bill unit.
One for each deferred action.
To run PCM_OP_CUST_SET_STATUS without changing data in the database, use the PCM_OPFLG_CALC_ONLY flag.
If the flag is set, no fields in the database are changed and the event object is not created. The fields used to create the event object and adjustment item are returned to the caller.
If the flag is not set, the /event/customer/status storable object is created to record details of the operation.
When you use PCM_OP_CUST_SET_STATUS, set the account or bill unit status entry to one of the following field values listed in Table 12-1. See BRM_Home/include/pin_cust.h.
Table 12-1 PIN_FLD_STATUS Values
| PIN_FLD_STATUS Field | Description | Value |
|---|---|---|
|
PIN_STATUS_ACTIVE |
Account or bill unit fully functional; login is subject to credit limit check. |
10100 |
|
PIN_STATUS_INACTIVE |
Inactive account or bill unit; no logins permitted and no fees are charged. |
10102 |
|
PIN_STATUS_CLOSED |
Closes the account or bill unit, which can be reopened later. This does not activate the corresponding products. |
10103 |
|
PIN_STATUS_DEFUNCT |
Reserved for BRM. PIN_ERR_BAD_ARG is returned if you try to set a status to this value. |
0 |
The values used to further define the status for the account, bill unit, or service are listed in Table 12-2:
Table 12-2 PIN_FLD_STATUS_FLAG Values
| PIN_FLD_STATUS_FLAG Field | Description | Value |
|---|---|---|
|
PIN_STATUS_FLAG_ACTIVATE |
Sets the future activation date (accounts and bill units only). |
0x01 |
|
PIN_STATUS_FLAG_DEBT |
Displays the outstanding debt (accounts and bill units only). |
0x02 |
|
PIN_STATUS_FLAG_MANUAL |
Displays manual operations performed by the administrative operator. |
0x04 |
|
PIN_STATUS_FLAG_DUE_TO_ACCOUNT |
Closes all related services for the account or bill unit (accounts and bill units only). |
0x08 |
|
PIN_STATUS_FLAG_DUE_TO_PARENT |
Closes all child accounts if the parent account is closed (only for accounts in groups set up for billing purposes). Closes all child bill units if the parent bill unit is closed. |
0x10 |
|
PIN_STATUS_FLAG_DUE_TO_SUBSCRIPTION_SERVICE |
Changes all member services when the subscription's service status is changed. |
0x20000 |
|
PIN_STATUS_FLAG_PO_EXHAUSTED |
Obsolete. |
0x20 |
|
PIN_STATUS_FLAG_PROVISIONING |
Identifies tasks that use the provisioning system. |
0x40 |
The field values in the storable object are set as follows:
If the input status is PIN_STATUS_ACTIVE:
Flags = (Old flag AND NOT (New flag))
If the result flag is 0, new status is input status, else old status.
If the input status is PIN_STATUS_INACTIVE:
The status field is set to inactive.
The flags field is set to the OR of the old flags in the database and the new flags on the input flist.
If the input status is PIN_STATUS_CLOSED:
The status field is set to closed.
The flags field is set to the OR of the old flags and new flags.
If the status change is caused by a change to the parent account or bill unit, PIN_FLD_STATUS_FLAG_DUE_TO_PARENT is set in the new flags.
If the status change is caused by a change to an accounts receivable (AR) account or AR bill unit, PIN_FLD_STATUS_FLAG_DUE_TO_ACCOUNT is set in the new flags.
Accounts, bill units, or services marked as closed (terminated) are actually closed when the pin_deferred_act billing application is run. See "Executing Deferred Actions With the pin_deferred_act Utility" in BRM Configuring and Running Billing.
For deferred actions, the PIN_FLD_WHEN_T field is passed to indicate the date on which the status change will be made. It also creates a /schedule object to store the input flist to call PCM_OP_CUST_SET_STATUS on the specified date.
You can create, delete, execute, and modify /schedule objects using Customer Center or by calling the opcodes in Table 12-3:
Table 12-3 Opcodes used to Modify /schedule Objects
| Opcode | Function |
|---|---|
|
PCM_OP_ACT_SCHEDULE_CREATE |
Creates a schedule object. |
|
PCM_OP_ACT_SCHEDULE_DELETE |
Deletes a schedule object. |
|
PCM_OP_ACT_SCHEDULE_MODIFY |
Modifies a schedule object. |
|
PCM_OP_ACT_SCHEDULE_EXECUTE |
Executes a schedule object. |
By default, the pin_deferred_act utility, which is part of the pin_bill_day billing script, finds expired schedule objects and calls the PCM_OP_ACT_SCHEDULE_EXECUTE opcode, which in turn calls PCM_OP_CUST_SET_STATUS.
If the deferred status change is for closing an account, bill unit, or service, PCM_OP_CUST_SET_STATUS sets the PIN_FLD_CLOSE_WHEN_T field in the account, bill unit, or service to midnight on the specified date.
When setting or resetting a deferred CLOSE, PCM_OP_CUST_SET_STATUS calls a standard opcode to set the PIN_FLD_PURCHASE_END_T, PIN_FLD_CYCLE_END_T, and PIN_FLD_USAGE_END_T fields for each corresponding product and discount to the deferred CLOSE date if the old values for these fields are later than the deferred CLOSE date or if these fields are set to NEVER (”0”).
If a deferred CLOSE is canceled (the schedule object is deleted), PCM_OP_CUST_SET_STATUS calls a standard opcode to set the values of the PIN_FLD_PURCHASE_END_T, PIN_FLD_CYCLE_END_T, and PIN_FLD_USAGE_END_T fields for all corresponding products and discounts to the old values from the previous /event/billing/product/action/modify event.
You can customize status changes by using the following opcodes:
To customize the way status is changed, use the PCM_OP_CUST_POL_PREP_STATUS policy opcode. The default implementation does nothing.
To validate status changes, use the PCM_OP_CUST_POL_VALID_STATUS policy opcode. The default is to do no additional checking and to return the verified information.
For example, you can use this policy opcode to customize how customer service representatives (CSR) can set permissions on specific service types.
See "About the PREP and VALID Opcodes" in BRM Developer's Guide.
Use the PCM_OP_ACT_POL_EVENT_LIMIT policy opcode to inactivate any account or account hierarchy that exceeds a specified limit.
PCM_OP_ACT_POL_EVENT_LIMIT performs the following tasks:
Calls PCM_OP_CUST_SET_STATUS to inactivate an account or account hierarchy based on the status set in the PIN_FLD_STATUS field.
Calls the PCM_OP_ACT_POL_EVENT_NOTIFY policy opcode to notify any custom applications that a limit was reached and that an action took place.
In Customer Center, you can schedule the following types of actions to occur on a future date by:
Changing the status of an account or service.
Adding an account to a hierarchical group.
Removing an account from a hierarchical group.
Moving an account between hierarchical groups.
After an action is deferred, you can display, execute, reschedule, and cancel the deferred action.
To execute deferred actions automatically on their scheduled date, you can use a daily billing utility, pin_deferred_act. See "Executing Deferred Actions With the pin_deferred_act Utility" in BRM Configuring and Running Billing.
In Customer Center, the total number of deferred actions scheduled for an account is shown on the Summary tab in the Account Summary section. This number includes the following actions:
All actions whose execution date is in the future. The status of these actions is Pending.
Any actions that could not be executed on their scheduled date and have not been deleted from the Deferral Details table. The status of these actions is Error.
Any completed actions that have not been deleted from the Deferral Details table. The status of these actions is Done.
The number of deferred actions scheduled for each service owned by an account is shown in the Deferred Actions column of the table on the Service tab.
Use the following opcodes to handle deferred actions:
PCM_OP_ACT_SCHEDULE_CREATE. See "Scheduling Deferred Actions".
PCM_OP_ACT_SCHEDULE_MODIFY. See "Modifying Deferred Action Descriptions".
PCM_OP_ACT_SCHEDULE_DELETE. See "Deleting Deferred Actions".
PCM_OP_ACT_SCHEDULE_EXECUTE. See "Executing Deferred Actions".
PCM_OP_ACT_POL_VALIDATE_SCHEDULE. See "Performing Policy Checks before Scheduling Deferred Actions".
The PCM_OP_ACT_SCHEDULE_CREATE opcode creates /schedule objects, which schedule a single action for a predetermined date and time.
BRM supports the following deferred actions:
Account activation, deactivation, and closure.
Account parent change.
Service activation and closure.
Two optional fields, PIN_FLD_WHEN_T and PIN_FLD_DESCR, enable deferred actions in BRM. These fields are set by the input flists of the PCM_OP_ACT_POL_EVENT_NOTIFY policy opcode or the PCM_OP_BILL_GROUP_MOVE_MEMBER opcode.
PIN_FLD_DESCR describes the deferred action.
PIN_FLD_WHEN_T specifies when the deferred action occurs.
If the PIN_FLD_WHEN_T field is populated in the input flist of the calling opcode, that opcode can call PCM_OP_ACT_SCHEDULE_CREATE to create a /schedule object to hold the input flist information. The /schedule object remains active until the PIN_FLD_WHEN_T time expires and the PCM_OP_ACT_SCHEDULE_EXECUTE opcode executes the action stored in the /schedule object.
Note:
Deferred actions are always rounded off to midnight. For example, if you use PCM_OP_ACT_SCHEDULE_CREATE to schedule a deferred action on January 15 at 8:00 a.m., the schedule object is created with a scheduled time of January 15 at 00:00.The PCM_OP_ACT_SCHEDULE_MODIFY opcode modifies an existing /schedule object.
This opcode modifies the text description in PIN_FLD_DESCR field and the scheduled date in PIN_FLD_WHEN_T field.
PCM_OP_ACT_SCHEDULE_DELETE deletes existing /schedule objects.
PCM_OP_ACT_SCHEDULE_EXECUTE executes any deferred actions defined in a /schedule object. This opcode is called directly by the pin_deferred_act billing utility.
When you run the pin_deferred_act utility, it searches for any /schedule object with both an expired PIN_FLD_WHEN_T field and a PIN_FLD_STATUS field marked Pending. When it finds one, it calls PCM_OP_ACT_SCHEDULE_EXECUTE to:
Execute the action defined in the /schedule object.
Update PIN_FLD_STATUS to either Done or Error, depending on its success.
Use the PCM_OP_ACT_POL_VALIDATE_SCHEDULE policy opcode to perform custom policy checks before creating a /schedule object. For example, you can customize this opcode to verify that an account balance is zero before scheduling it for closure.