This chapter provides an overview of registering a customer in Oracle Communications Billing and Revenue Management (BRM).
When you register a customer, you create a customer account in the BRM database. Registration typically follows this process:
The customer calls the customer service representative (CSR). See "Ways to Register Customers".
The customer chooses a plan.
The customer provides information such as name, address, and credit card number. In addition, a CSR might give discounts to the customer or collect billing information such as the name of a billing contact.
The account is created in the BRM database. At account creation, a number of events occur:
The customer information is checked by BRM to see whether it is valid and to make sure that all required information has been supplied. See "Specifying How to Validate Customer Contact Information".
If the customer entered a credit card number, it is validated by a credit card processing service. See "Credit Card Validation and Charge Options".
If there is a purchase fee, the customer is automatically charged.
A welcome message is automatically sent to the customer. See "Sending Registration Information to Customers".
You can register customers by using the following methods:
Have CSRs create accounts by using Customer Center.
Note:
In Customer Center, you can backdate the account creation to a date earlier than the current date.Give customers calling cards or voucher cards, which they use to access accounts you have already created in your BRM database.
When setting up registration, consider the following:
You can implement both types of registration: by CSRs, and by the Web.
Web-based registration takes longer to set up, but it is more cost effective.
Complex plans are best offered by a CSR, who can explain the plans.
If you use account groups, you might need a CSR to assign accounts to groups.
You can implement account access in the following ways:
Use Self-Care Manager. You can customize the appearance of the default Web pages by modifying Java Server Pages (JSPs). A programmer can add functionality by modifying Self-Care Manager's source code.
Create a Web interface by using the Portal Communications Module (PCM) library. If you use the PCM library, your Web server must run on a platform that supports BRM.
When a customer registers by phone, your CSR creates the account by using Customer Center.
See "Customizing Registration".
The CSR can perform additional account management tasks after the account is created; for example:
Add the new customer to an account group.
Give the customer additional discounts on products. See "Managing Customers' Services and Products".
Change the account status or service status.
Through a CSR, you can configure your system to automatically send your customers messages during and after registration. These messages might include:
Information about special offers.
The customer's connection settings, such as news server address and mail server address.
A list of phone numbers for dialup connections.
See "Sending Registration Information to Customers" for more information on sending messages to your customer.
Customer Center includes two different account creation methods:
Use the business account method if you are creating an account for someone who runs a business, such as an Internet service provider (ISP) or an E-Commerce business. The business account method includes billing setup information such as billing cycle and accounting type.
Use the consumer account creation method to create accounts for consumers. The consumer account creation method has fewer fields, which streamlines the account creation process.
CSRs can modify products when registering customers in Customer Center. See "Modifying Products" for more information on what you can customize.
Note:
You specify if a deal is customizable at account creation when you create the price list in Pricing Center.When adding a deal or creating an account during registration, you can specify the status of each product. For example, if using the product requires hardware setup, you can inactivate the product until the setup is complete. After the hardware setup is complete, you can activate the product by using Customer Center. The customer is not billed for the product while it is inactivated.
Note:
You cannot inactivate a product after it has been purchased. However, you can inactivate a service.The recommended opcode for creating accounts is the PCM_OP_CUST_COMMIT_CUSTOMER opcode. This is a wrapper opcode that performs all the tasks necessary to create an active and billable account in the database.
When you use PCM_OP_CUST_COMMIT_CUSTOMER, the account creation occurs within a transaction. This ensures that the account is created before sending the customer a welcome email. Using PCM_OP_CUST_COMMIT_CUSTOMER also creates a notification event that alerts Pipeline Manager to a new account.
Note:
When PCM_OP_CUST_COMMIT_CUSTOMER is called by JCA Resource Adapter in XA Transaction mode, account creation occurs within a transaction started by a global transaction manager. For details, see "PCM_OP_CUST_COMMIT_CUSTOMER" in BRM Developer's Reference.To create an account, use PCM_OP_CUST_COMMIT_CUSTOMER.
The following procedure describes the account creation process:
PCM_OP_CUST_COMMIT_CUSTOMER calls the PCM_OP_CUST_CREATE_CUSTOMER opcode.
Note:
To backdate an account's creation time, pass the backdate time in the PIN_FLD_END_T field of PCM_OP_CUST_COMMIT_CUSTOMER. The value of PIN_FLD_END_T is copied to the PIN_FLD_EFFECTIVE_T field internally and is then passed to the appropriate opcodes to complete the account creation process.PCM_OP_CUST_CREATE_CUSTOMER calls the PCM_OP_CUST_PREP_CUSTOMER opcode to validate the registration information.
PCM_OP_CUST_PREP_CUSTOMER follows all the steps for creating an account object but does not commit the object to the database:
Opens a transaction.
Creates an /account storable object.
Sets account credit limits.
Purchases a deal.
Creates a /service storable object.
If the deal purchased for the account is a required deal, the /service object's PIN_FLD_TYPE value is set to PIN_BILL_SERVICE_REQUIRED. This establishes the service as a required service in the account.
If PCM_OP_CUST_PREP_CUSTOMER is unsuccessful in any of these operations, it exits and calls a base opcode to cancel the transaction. This ensures that no changes are made to the database.
If PCM_OP_CUST_PREP_CUSTOMER successfully validates the registration data, it calls a base opcode to cancel the transaction, ensuring that the customer objects are not created, and then returns the validated registration information in the output flist to PCM_OP_CUST_CREATE_CUSTOMER.
If PCM_OP_CUST_PREP_CUSTOMER cannot open a local transaction, or a transaction is already open, the transaction is stopped and PCM_OP_CUST_PREP_CUSTOMER exits without validating the registration information.
In addition, PCM_OP_CUST_PREP_CUSTOMER calls the PCM_OP_PYMT_POL_SPEC_VALIDATE policy opcode to determine whether a customer's payment information needs to be validated during registration. If validation is required, PCM_OP_CUST_PREP_CUSTOMER calls the PCM_OP_PYMT_VALIDATE opcode to perform the operation. If validation fails, the results are transformed to be consistent with the results used to describe registration failure results and are then returned on the output flist. See "Changing How BRM Handles Paymentech Address Validation Return Codes" in BRM Configuring and Collecting Payments.
If the data is valid, PCM_OP_CUST_CREATE_CUSTOMER calls the PCM_OP_CUST_CREATE_ACCT opcode to create the /account object.
PCM_OP_CUST_CREATE_ACCT creates a generic /account object. The account is constructed in the following actions, all of which are performed inside the transaction started by PCM_OP_CUST_COMMIT_CUSTOMER or the global transaction manager:
Calls the PCM_OP_CUST_CREATE_BILLINFO opcode to create one or more /billinfo storable objects and propagates the bill unit with billing information. See "Creating /billinfo Objects" in BRM Configuring and Running Billing.
Calls the PCM_OP_CUST_CREATE_BAL_GRP opcode to create one or more /balance_group storable objects and link the balance groups to the account and the appropriate /billinfo object. See "Creating Balance Groups" in BRM Managing Accounts Receivable.
Calls the PCM_OP_CUST_CREATE_PAYINFO opcode to create a /payinfo object and link the payment information to the appropriate /billinfo object. See "Customizing Customer Payment Information".
Calls the PCM_OP_CUST_CREATE_PROFILE opcode to create a /profile object if the input flist contains profile information. See "Managing and Customizing Profiles".
Calls the PCM_OP_CUST_SET_NAMEINFO opcode to set the contact information. See "Managing Customer Contact Information".
Calls the PCM_OP_CUST_SETUP_TOPUP opcode to set up top-up information, if any, for the account. See "How BRM Sets Up Top-Up Information for an Account" in BRM Configuring and Collecting Payments.
Calls the PCM_OP_CUST_SET_STATUS opcode to set the account status to active. See "Setting Account, Service, and Bill Unit Status by Using Your Custom Application".
PCM_OP_CUST_CREATE_CUSTOMER calls the PCM_OP_SUBSCRIPTION_VALIDATE_DEAL_DEPENDENCY opcode to validate that the deals passed from the input flist do not violate any deal dependencies.
PCM_OP_CUST_CREATE_CUSTOMER calls the PCM_OP_CUST_CREATE_SERVICE opcode to create /service objects. See "Creating Services".
PCM_OP_CUST_CREATE_CUSTOMER calls the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL opcode to purchase deals. See "Purchasing Deals."
When calling PCM_OP_SUBSCRIPTION_PURCHASE_DEAL, PCM_OP_CUST_CREATE_CUSTOMER populates the PIN_FLD_DEAL_INFO field in the PCM_OP_SUBSCRIPTION_PURCHASE_DEAL input flist only when the following is true for the input flist of PCM_OP_CUST_CREATE_CUSTOMER:
At the PIN_FLD_ACCTINFO level:
PIN_FLD_DEAL_OBJ is not populated.
PIN_FLD_DEAL_INFO is populated, including the PIN_FLD_PRODUCTS array and its PIN_FLD_STATUS field.
At the PIN_FLD_SERVICES level:
PIN_FLD_DEAL_OBJ is not populated.
PIN_FLD_DEAL_INFO field is populated, including the PIN_FLD_PRODUCTS array and its PIN_FLD_STATUS field.
At the PIN_FLD_SERVICES > PIN_FLD_DEALS level:
PIN_FLD_DEAL_OBJ is not populated.
PIN_FLD_DEAL_INFO field is populated, including the PIN_FLD_PRODUCTS array and its PIN_FLD_STATUS field.
PCM_OP_CUST_COMMIT_CUSTOMER creates the customer's collections profile at the time of customer account creation. See "Creating Customer's Collections Profiles at the Time of Customer Account Creation".
Before committing the transaction, PCM_OP_CUST_COMMIT_CUSTOMER calls the PCM_OP_CUST_POL_PRE_COMMIT policy opcode. See "Adding Custom Account Creation Steps before the Account Is Committed".
After committing the transaction, PCM_OP_CUST_COMMIT_CUSTOMER calls the PCM_OP_CUST_POL_POST_COMMIT policy opcode. See "Adding Custom Account Creation Steps after the Account Is Committed".
PCM_OP_CUST_COMMIT_CUSTOMER:
Passes credit card information to PCM_OP_PYMT_VALIDATE and PCM_OP_PYMT_COLLECT, which collect any credit card payments charged at account creation and validate the credit card information returned by the payment processor.
If you use multiple schemas, creates the /uniqueness object.
Calls the PCM_OP_CUST_POL_GET_CONFIG policy opcode to get information used by client applications.
Calls the PCM_OP_CUST_SET_BAL_GRP opcode to create balance groups. See "Creating Balance Groups" in BRM Managing Accounts Receivable.
Note:
By default, BRM does not log events that do not have a balance impact. You can specify to log all account-creation events. See "Logging Non-Currency Events" in BRM System Administrator's Guide.Use the PCM_OP_CUST_COMMIT_CUSTOMER opcode to create a customer's collections profile at the time of customer account creation.
Customer Center calls this opcode when creating a customer account.
As input, this opcode takes /profile/collections_params as the Portal object ID (POID) type in the PIN_FLD_PROFILE_OBJ field and the collections parameter details in the PIN_FLD_COLLECTIONS_PARAMS array to create the collections profile. This opcode uses the PIN_FLD_BILLINFO_ID field to identify the /billinfo object in case of multiple bill units.
Sample input flist:
# PCM_OP_CUST_COMMIT_CUSTOMER input flist 0 PIN_FLD_POID POID [0] 0.0.0.1 /plan 102289 0 0 PIN_FLD_LOCALES ARRAY [1] allocated 20, used 1 1 PIN_FLD_LOCALE STR [0] "en_US" . . 0 PIN_FLD_PAYINFO ARRAY [0] allocated 20, used 5 1 PIN_FLD_NAME STR [0] "Invoice1" 0 PIN_FLD_PROFILES ARRAY [0] 1 PIN_FLD_PROFILE_OBJ POID [0] 0.0.0.1 /profile/collections_params -1 0 1 PIN_FLD_INHERITED_INFO SUBSTRUCT [0] 2 PIN_FLD_COLLECTIONS_PARAMS ARRAY [0] allocated 4, used 4 3 PIN_FLD_BILLINFO_ID STR [0]"Bill Unit(1)" #(other collections attributes fields, say VF_FLD_DD_REJECT_CODE) 3 PIN_FLD_BILLINFO_OBJ POID [0] NULL 2 PIN_FLD_COLLECTIONS_PARAMS ARRAY [1] allocated 4, used 4 3 PIN_FLD_BILLINFO_ID STR [0]"Bill Unit(2)" 3 PIN_FLD_BILLINFO_OBJ POID[0] NULL
You can create multiple BRM accounts in one transaction with JCA Resource Adapter. This is useful, for example, when a single order in Oracle Communications Order and Service Management (OSM) produces multiple new customers. It enables Oracle Application Integration Architecture (Oracle AIA) to maintain the cross-references between the OSM order and its associated BRM accounts.
For more information, see the description on JCA Resource Adapter transaction management in BRM JCA Resource Adapter.
By default, BRM does not allow accounts to be created with the services or resources creation date backdated beyond the account or service creation date.
You can create accounts with the services or resources creation date backdated beyond the account or service creation date by enabling a business parameter in the subscription instance of the /config/business_params object.
Use the pin_bus_params utility to enable the SubsDis74BackDateValidations business parameter in the subscription instance of the /config/business_params object.
To create accounts with backdated services or resources:
Go to the BRM_Home/sys/data/config directory, where BRM_Home is the directory in which you installed the BRM software.
Use the following command to create an editable XML file of the subscription instance from the /config/business_params object:
pin_bus_params -r BusParamsSubscription bus_params_subscription.xml
This command creates the XML file named bus_params_subscription.xml.out in your working directory. To place this file in a different directory, specify the full path as part of the file name.
Search the XML file for the following line:
<SubsDis74BackDateValidations>disabled</SubsDis74BackDateValidations>
Change disabled to enabled.
Caution:
BRM uses the XML in this file to overwrite the existing subscription instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM subscription configuration.Save this updated file as bus_params_subscription.xml.
Use the following command to load this change into the /config/business_params object in the BRM database.
pin_bus_params -r BusParamSubscription bus_params_subscription.xml
You should run this command from the BRM_Home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see the description for pin_bus_params in BRM System Administrator's Guide.
Read the object with the testnap utility or Object Browser to verify that all fields are correct.
For more information on reading objects by using Object Browser, see BRM Managing Customers. For instructions on using the testnap utility, see BRM Developer's Guide.
Stop and restart the Connection Manager (CM). See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in the BRM System Administrator's Guide.
When you backdate the account creation, the account becomes effective as of the new backdated date. BRM does the following:
Sets the PIN_FLD_EFFECTIVE_T field in the /account object to the backdated date.
Sets the purchase, usage, or cycle start date to the backdated date unless these dates are explicitly set to a different date.
Sets the billing day of month (DOM) to the backdated date unless the actg_dom entry in the CM configuration file (pin.conf) is used.
BRM does not allow backdating the account creation to a date prior to the general ledger (G/L) posting date. See "About Backdating Beyond the G/L Posting Date".
BRM uses the PCM_OP_SUBSCRIPTION_CYCLE_FORWARD and PCM_OP_ SUBSCRIPTION_CYCLE_ARREARS opcodes to calculate cycle forward and cycle arrears fees for the subscription operations.
When you backdate the creation of an account that has cycle forward events, the cycle forward fee is applied for the first cycle just as it would be if the account were to be created on the backdated date. The remaining cycles, until the current cycle, are charged only during the next bill run.
For example, consider that a customer places a request for an account creation on September 1, but the entry is recorded in the BRM system on November 1. So, on November 1, the entry is backdated to September 1. The account owns a product with cycle forward charges of $9.95 and the proration set to Charge based on amount used.
BRM calculates the cycle forward fees as follows:
Immediately charges the cycle forward fee for the period of September 1 to October 1.
The bill for October 1 contains a monthly cycle fee charge of $19.90 ($9.95 for the period of September 1 to October 1 and $9.95 for the period of October 1 to November 1).
The bill for November 1 contains a monthly cycle fee charge of $9.95 for the period of November 1 to December 1.
When you backdate the creation of an account that has cycle arrears events, cycle arrears fees are not generated at the time of account creation. The backdated cycles are charged during the skipped billing that gets triggered for these cycles as a result of the next bill run.
For example, consider that a customer places a request for an account creation on September 1, but the entry is recorded in BRM system on November 1. So, on November 1, the entry is backdated to September 1. The account owns a product with cycle arrears charges of $9.95 and the proration set to Charge based on amount used.
BRM calculates the cycle arrears fee as follows:
The bill for October 1 contains a monthly cycle fee charge of $9.95 for the period of September 1 to October 1.
The bill for November 1 contains a monthly cycle fee charge of $9.95 for the period of October 1 to November 1.
Important:
BRM does not prevent backdated creation, modification, or deletion of the discount sharing group and charge sharing group. However, the resource sharing is not effective from the backdated date. For example, on October 1, the group owner of a discount sharing group is modified and backdated to January 1 to include a group member account. The group member cannot enjoy discounts owned by the group owner with effect from January 1. For discounts to be effective from January 1, you must run rerating on all the accounts in the sharing group.
BRM does not support backdating the change of the billing DOM. For example, you change the DOM from 5 of every month to 1 of every month. You cannot backdate this change to an earlier date.
To modify an account, use the PCM_OP_CUST_UPDATE_CUSTOMER and PCM_OP_CUST_MODIFY_CUSTOMER opcodes.
PCM_OP_CUST_UPDATE_CUSTOMER calls other opcodes to add, modify, or delete the following data:
Contact information
Payment information: see "Changing a Bill's Payment Method".
Bill units
Top-up information
Balance groups
Profiles
Locale
PCM_OP_CUST_MODIFY_CUSTOMER adds a service by adding a deal to the account. PCM_OP_CUST_MODIFY_CUSTOMER adds a deal by calling standard opcodes to perform these operations:
If the validate_deal_dependencies entry is enabled in the CM pin.conf file, PCM_OP_CUST_MODIFY_CUSTOMER verifies that any set deal dependencies are valid. If not, the operation is disallowed. See "Defining Deal Dependencies".
Purchase the deal associated with the plan. See "Purchasing Deals".
Set the account credit limit for each resource of the added plan. See "How BRM Handles Consumption Rules and Credit Limits".
Create service objects associated with the plan.
If a service with an add-on plan is added, and the ValidateDiscountDependency flag is enabled in the /config/business_params object, PCM_OP_CUST_MODIFY_CUSTOMER checks for any mutually exclusive relationships between discounts associated with the add-on plan and any discounts already owned by the account. If any such relationship is found, the service addition is not continued.
Note:
Discount-to-discount exclusion rules are not validated. PCM_OP_CUST_MODIFY_CUSTOMER validates only plan-to-discount exclusion rules at purchase time.If a subscription service is being added, PCM_OP_CUST_MODIFY_CUSTOMER verifies that it is not a member of another subscription group.
If the account status is inactive and the provisioning flag is not set, an error value is returned and PCM_OP_CUST_MODIFY_CUSTOMER exits without modifying the account.
If a subscription member service is being created, PCM_OP_CUST_MODIFY_CUSTOMER verifies that the subscription service is not inactive or closed. If the member service requires its own balance group, PCM_OP_CUST_MODIFY_CUSTOMER creates the balance group. Otherwise, it associates the member service with the subscription service's balance group.
Optionally associate /device objects with the services. See "Managing Devices with BRM" in BRM Developer's Guide.
Create notification events to mark the beginning and end of its execution. See "About Event Notification" in BRM Developer's Guide.
You can use other opcodes to modify accounts, such as PCM_OP_CUST_MODIFY_PAYINFO and PCM_OP_CUST_MODIFY_PROFILE.
PCM_OP_CUST_MODIFY_CUSTOMER includes a hook to the PCM_OP_CUST_POL_POST_MODIFY_CUSTOMER policy opcode, which you can use to export customer data to an external or legacy system for processing. See "Customizing Registration".
Table 1-1 lists the opcodes to which PCM_OP_CUST_MODIFY_CUSTOMER passes information from arrays in its input flist. The opcodes, in turn, use the information to create or modify objects:
Table 1-1 Opcodes and Information Received to Create or Modify Objects
| This Opcode | Uses Information from This Array | To Create or Modify This Object |
|---|---|---|
|
PCM_OP_CUST_SET_NAMEINFO |
PIN_FLD_NAMEINFO PIN_FLD_PHONES (subarray) |
/account |
|
PCM_OP_CUST_SET_BAL_GRP |
PIN_FLD_ACCTINFO PIN_FLD_BAL_INFO (subarray) |
/balance_group |
|
PCM_OP_CUST_SET_BILLINFO |
PIN_FLD_BILLINFO |
/billinfo |
|
PCM_OP_CUST_SET_PAYINFO |
PIN_FLD_PAYINFO PIN_FLD_CC_INFO (subarray) PIN_FLD_DD_INFO (subarray) PIN_FLD_INV_INFO (subarray) |
/payinfo/cc /payinfo/dd /payinfo/invoice |
|
PCM_OP_SUBSCRIPTION_SERVICE_BALGRP_TRANSFER |
PIN_FLD_ACCTINFO PIN_FLD_BAL_INFO (subarray) PIN_FLD_BILLINFO |
/balance_group /billinfo |
|
PCM_OP_CUST_SET_LOCALE |
PIN_FLD_LOCALE |
/account |
|
PCM_OP_CUST_CREATE_PROFILE PCM_OP_CUST_MODIFY_PROFILE |
PIN_FLD_PROFILES |
/profile |
|
PCM_OP_CUST_SET_TOPUP |
PIN_FLD_TOPUP_INFO PIN_FLD_GROUP_TOPUP_INFO (subarray) PIN_FLD_GROUP_TOPUP_LIMITS (subarray) PIN_FLD_GROUP_TOPUP_MEMBERS (subarray) |
/topup /group/topup |
If the information is successfully updated, the opcode returns the POID of the /event storable objects created in the PIN_FLD_RESULTS array of the output flist. Otherwise, it returns the PIN_FLD_FIELDS array specifying the failing field.
If the input flist array value for PIN_FLD_NAMEINFO is set to NULL, the corresponding element ID is deleted from the NAMEINFO table in the /account object.
Use PCM_OP_CUST_UPDATE_CUSTOMER to change the payment method for an account's bill unit in the following ways:
To change an existing payment method for a bill unit, pass the POID of the /payinfo object in the PIN_FLD_ PAYINFO_OBJ field in the PIN_FLD_BILLINFO array.
For example:
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 23304551863 227
0 PIN_FLD_ACCOUNT_OBJ POID [0] 0.0.0.1 /account 23304551863 227
0 PIN_FLD_PROGRAM_NAME STR [0] "program_name"
0 PIN_FLD_BILLINFO ARRAY [0] allocated 20, used 3
1 PIN_FLD_BILLINFO_ID STR [0] "Account Bill"
1 PIN_FLD_PAY_TYPE ENUM [0] 10005
1 PIN_FLD_BILLING_SEGMENT ENUM [0] 0
1 PIN_FLD_PAYINFO_OBJ POID [0] 0.0.0.1 /payinfo/cc 4780 0
...
To add a new payment method for an existing bill unit, you can create the /payinfo object and associate it with the /billinfo object in the same call by doing the following:
Include a PIN_FLD_PAYINFO_ARRAY field (outside of the PIN_FLD_ BILLINFO array) and add an array element for the new /payinfo object.
In the PIN_FLD_BILLINFO array, include the PIN_FLD_PAY_TYPE field with the new payment method. Specify a NULL value for the PIN_FLD_PAYINFO array and make sure the array element ID matches the element ID of the new /payinfo object in the PIN_FLD_PAYINFO array that is outside the billinfo array.
For example:
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 23304551863 227 0 PIN_FLD_ACCOUNT_OBJ POID [0] 0.0.0.1 /account 23304551863 227 0 PIN_FLD_PROGRAM_NAME STR [0] "program_name" 0 PIN_FLD_BILLINFO ARRAY [0] allocated 20, used 3 1 PIN_FLD_BILLINFO_ID STR [0] "Account Bill" 1 PIN_FLD_PAY_TYPE ENUM [0] 10005 1 PIN_FLD_BILLING_SEGMENT ENUM [0] 0 1 PIN_FLD_PAYINFO ARRAY [1] NULL 0 PIN_FLD_PAYINFO ARRAY [1] allocated 20, used 20 1 PIN_FLD_POID POID [0] 0.0.0.1 /payinfo/cc -1 0 ...
In the above example, the new /payinfo object is created and associated with the /billinfo object specified in the input flist.
Note:
You must specify either the PIN_FLD_PAYINFO array or the PIN_FLD_ PAYINFO_OBJ field in the PIN_FLD_BILLINFO array. However, because these fields are mutually exclusive and you cannot specify both, they are classified as optional.To create a service object, use PCM_OP_CUST_CREATE_SERVICE.
If the PIN_FLD_SUBSCRIPTION_OBJ field in the input flist specifies the POID of a subscription's service object, the service being added to the customer's account will be a member of the subscription service's group.
PCM_OP_CUST_CREATE_SERVICE creates the service by doing the following inside a transaction:
Calls the PCM_OP_CUST_INIT_SERVICE opcode to create and initialize the /service object.
Calls the PCM_OP_CUST_SET_PASSWD opcode to encrypt and set a password (if one is supplied) in the /service object. If a password is not provided, one is generated. See "Customizing Passwords".
Stores any client-supplied inherited information in the /service object. See "Creating Customization Interfaces" in BRM Developer's Guide.
Calls the PCM_OP_CUST_SET_STATUS opcode to set the service status. See "Setting Account, Service, and Bill Unit Status by Using Your Custom Application".
Calls the PCM_OP_DEVICE_ASSOCIATE opcode to associate /device objects with the service. See "Managing Devices with BRM" in BRM Developer's Guide.
To modify a service, use the PCM_OP_CUST_UPDATE_SERVICES opcode. For most services, this wrapper opcode calls the PCM_OP_CUST_MODIFY_SERVICE opcode to set, change, or delete extended service information.
PCM_OP_CUST_UPDATE_SERVICES takes as input the POID of the /account object, the name of the calling program, and an array containing a list of services to be updated. Additional inputs depend on the type of services being updated. Services are processed in the order dictated by the element value passed in the PIN_FLD_SERVICES array.
PCM_OP_CUST_UPDATE_SERVICES performs these operations:
Creates an /event/notification/service/pre_change event.
If login or alias list information is specified, calls the PCM_OP_CUST_SET_LOGIN opcode to update the service login or alias list with the value specified.
If password information is specified, calls the PCM_OP_CUST_SET_PASSWD opcode to update the service password with the value specified.
If service status information is specified, calls the PCM_OP_CUST_SET_STATUS opcode to update the status of the service with the value specified.
If inherited fields are specified, calls PCM_OP_CUST_MODIFY_SERVICE for most services to update the values for the inherited fields.
If one or more PIN_FLD_DEVICES arrays are specified, calls the PCM_OP_DEVICE_ASSOCIATE opcode to disassociate or associate the device. Disassociations are processed before associations.
Creates an /event/notification/service/post_change event.
If successful, the PCM_OP_CUST_UPDATE_SERVICES output flist contains the following:
The POID of the /account object passed in.
A services array containing the following:
The POIDs of the /service objects modified.
A results array containing the POID of the /event objects created to record the changes. The index values returned in the PIN_FLD_RESULTS array correspond to the input flist values as shown in Table 1-2:
If an error is encountered in the service data, PCM_OP_CUST_UPDATE_SERVICES:
Continues to process all of the data, so that all erroneous data is uncovered.
Rolls back the transaction. Any updates already made to the information are undone.
Returns an error in the error buffer.
After the object is modified, PCM_OP_CUST_MODIFY_SERVICE creates the /event/notification/service event to notify listeners about the change to the /service object. The output flist contains the POID of the modified /service object. In case of an error, the error buffer is populated and the output flist can be ignored.
The input flist for PCM_OP_CUST_MODIFY_SERVICE contains the POID of the service object to be modified and a substruct of the inherited information to be stored. If the input flist for an inherited field of the service object contains a null entry, the array table entry is deleted from the object in the database.
Caution:
Do not delete accounts in a production system due to the following reasons:The opcode does not remove audit data.
The processing speed is slow, because the opcode must remove a lot of data associated with each account.
If your system supports subscription service transfers, the opcode does not delete accounts in the proper order. With subscription service transfers, the source account must be deleted prior to the destination account due to /balance_group locking. For more information, see "About Transferring a Subscription Service to Another Subscriber".
To delete accounts in a test system, use the PCM_OP_CUST_DELETE_ACCT opcode.