3 Customizing Registration

This chapter describes Oracle Communications Billing and Revenue Management (BRM) customer registration options that are common to customer service representative (CSR)–based and Web-based registration.

Before reading this document, see "About Registering Customers".

Standard Registration Information

When you register customers, you collect information about them. The standard information includes:

  • The plan that the customer signs up for.

  • Contact information; for example, name, address, and telephone number.

  • Service login and Web access names and passwords.

  • Customer's language. See "Charging Customers at Registration".

  • Customer's account currency.

  • Billing information; for example:

    • The accounting type (balance forward or open item).

    • The frequency of the billing cycle.

    • The payment method (credit card, invoice, and so forth).

    • Payment information; for example, credit card number or invoice billing address.

The information required by default is the last name, address, city, and country. You can change the required fields by using the Field Validation Editor, a Configuration Center application.

If you require additional registration information, you can create custom fields. See "Creating New Registration Fields".

Limitations for Entering Account Data

BRM uses default limits for the number of characters allowed for each field of customer data. For example, security codes can include up to 30 characters.

To find the number of allowed characters, see the description of the /account storable class. For example, the description of the PIN_FLD_ACCESS_CODE1 field includes this notation: Maximum length is 30 bytes.

How BRM Uses the Customer's Language Setting

You can use the customer's language setting to deliver information to the customer in their language; for example:

  • You can send localized versions of invoices to customers based on their language.

  • Your Internet Protocol (IP) telephony gateway can play voice messages in the customer's language.

Specifying How to Validate Customer Contact Information

Use the Field Validation Editor to define the valid entry formats for customer information. For example, when a customer or CSR enters a phone number, validation ensures that the phone number includes the correct number of digits.

You can also specify whether the information is required, whether it is case sensitive, and the minimum and maximum values (for example, the maximum length of a login name).

Tip:

  • You should tell your CSRs what the valid formats are.

  • To see the default validation formats, see the Field Validation Editor in Configuration Center.

Specifying the Valid Login Name Format

To specify the valid format for login names, use the Field Validation Editor. You should include a list of words that you do not want used as login names, for example, obscenities.

The default requirement is at least 1 character but no more than 255.

For more information, see "Managing Customer Authentication".

Specifying the Valid Password Format

To specify the valid format for passwords, use the Field Validation Editor. You can create required combinations of alphabetic and numeric characters.

The default requirement is at least 1 character but no more than 255.

For more information, see "Managing Customer Authentication".

Specifying the Valid Telephone Number Format

To specify the valid format for telephone numbers, use the Field Validation Editor. BRM includes several valid formats. To add a format, you create a format mask by using regular expressions. Figure 3-1 shows how format masks are entered in the Field Validation Editor.

Specifying the US State Format

To specify the valid format for states, use the Field Validation Editor.

The default required format is two uppercase letters; for example, CA.

Specifying the ZIP Code Format

To specify the valid format for ZIP codes, use the Field Validation Editor.

The default required format is 5 digits, or 5 digits followed by a hyphen and 4 digits.

Note:

Tax calculation programs validate ZIP codes. If you use a tax calculation package, make sure that your tax calculation program can handle 9-digit ZIP codes.

Specifying the Salutation Format

To specify the valid format for salutations, such as Mr. or Ms., use the Field Validation Editor. If you include salutations on invoices, you might want to enforce the use of correct punctuation. If customers never see the salutation, punctuation is not as important.

Tip:

To standardize account names, see "Standardizing Account Names".

Specifying which Information is Required for Registration

You can specify which registration information is required. Some information, such as the customer's occupation, is usually optional.

By default, the following information is required:

  • Last name

  • Address

  • City

  • State

  • ZIP code

  • Country

  • Service logins and passwords

    Tip:

    With Web-based registration, always let your customers know which information is required.

Validating Data from Account Creation Applications

To validate account information during registration, use the PCM_OP_CUST_VALIDATE_CUSTOMER opcode. This opcode can validate partial information. For example, you can validate only part of the name and contact information.

Because the validation is performed during account creation and there is no account object yet, the input is a type-only Portal object ID (POID) instead of an account object. The input data consists of flist arrays containing zero or more of the following types of information:

  • Name information

  • Billing information

  • Payment information

  • Locale information

  • Service login and password information

  • Profile information

Each array has a flag to specify whether to validate partial information for that array. If the flag is set, PCM_OP_CUST_VALIDATE_CUSTOMER performs a partial validation. If the flag is not set, the opcode performs a complete validation.

If you provide a field that is dependent on another field for validation, you need to provide both the fields. For example, if the state, ZIP code, or phone field is provided for validation, then you must also provide the country field.

If there are no errors, PCM_OP_CUST_VALIDATE_CUSTOMER returns the results array in the output flist. If there are errors, it returns an flist with the first field that was not updated.

Important:

You need to explicitly delete the return flist after using it, by calling the PIN_FLIST_DESTROY routine.

Credit Card Validation and Charge Options

By default, BRM validates a customer's credit card during account creation. You can set up the following credit card validation options:

Specifying the Account That Records Credit Card Validations

By default, BRM logs credit card validations against the root account during registration.

If you want to use a different account, do the following:

  1. Open the Connection Manager (CM) configuration file (BRM_Home/sys/cm/pin.conf). BRM_Home is the directory in which you installed the BRM software.

  2. Change the account number in the following entry:

    - fm_pymt_pol validate_acct database_number /account 1

    where database_number is the database number of the BRM database; by default, this is 0.0.0.1.

  3. Save the file.

You do not need to restart the CM to enable this entry.

To customize this feature, use the PCM_OP_PYMT_POL_SPEC_VALIDATE policy opcode. See "Customizing the Account Used for Credit Card Validation".

Allowing Registration without a Credit Card

You can allow your customers to create accounts and sign up for services without providing a credit card number when they register. This means that you can offer your customers a number of free days of service before they have to provide a credit card number.

To implement this feature, create the accounts by using the Undefined payment method. You can use Customer Center or a custom application to change the payment method to credit card or invoice after the free period has ended. (The custom application uses the PCM_OP_CUST_SET_BILLINFO opcode to set the payment method.)

Validating Credit Cards at Registration

By default, BRM validates credit cards by checking the customer's name and address and the credit card number. You might want to turn validation off if the connection to the credit card processor is offline.

A customer can register even when:

  • The credit card transaction processing service is unavailable.

  • The ZIP code is valid but the street address is wrong.

By default, a customer cannot register if:

  • The wrong ZIP code was entered.

  • The credit card is not valid.

  • The address was not entered or could not be read by the credit card processor.

To enable or disable credit card validation, do the following:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Change the value of the cc_validate entry:

    • To enable credit card validation, enter 1.

    • To disable credit card validation, enter 0.

  3. Save the file.

You do not need to restart the CM to enable this entry.

Tip:

If you know that the connection will be down for a long time, you can edit the credit card processor Data Manager (DM) configuration file online_proto entry to avoid the delay caused by timeouts. See "Increasing Registration Speed When Paymentech Is Offline" in BRM Configuring and Collecting Payments.

Important:

The PCM_OP_CUST_COMMIT_CUSTOMER opcode first calls the PCM_OP_PYMT_VALIDATE opcode to validate credit cards. If validation is successful, the customer account is created. Then, PCM_OP_CUST_COMMIT_CUSTOMER calls the PCM_OP_PYMT_COLLECT opcode to charge the credit card. If the authorization for funds fails, the account will not be charged.

Allowing Registration without Credit Card Validation

By default, if there is no response from the credit card payment service, validation fails, resulting in registration failure because the credit card cannot be validated. To register customers without validating credit cards, do one of the following:

  • If you use Paymentech, edit the Paymentech DM configuration file. See "Increasing Registration Speed When Paymentech Is Offline" in BRM Configuring and Collecting Payments.

  • Modify the PCM_OP_PYMT_POL_VALIDATE policy opcode to map the ”no answer” result to success, so that the registration continues.

    Tip:

    If the credit card payment service is not available and you still want to register customers, you need to isolate those accounts for later credit card authorization. Modify the PCM_OP_PYMT_POL_VALIDATE policy opcode file either to save a list of permissive registrations or to send email to the system administrator. Alternatively, you can write a simple application to periodically check accounts and flag the ones that have been registered without verification.

Revalidating Credit Cards

You can specify the credit card revalidation interval. For example, you can allow an interval of one hour before a credit card needs to be revalidated. This reduces the cost of credit card validations and allows customers who use the same credit card to register for multiple accounts without having to validate the credit card more than once.

To specify the credit card revalidation interval:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Change the value of the cc_revalidation_interval entry. The default is 3600 seconds (one hour).

  3. Save the file.

You do not need to restart the CM to enable this entry.

Charging Customers at Registration

By default, BRM charges for purchase fees and the first cycle forward fees at registration. When a customer registers, BRM uses the credit card processor to authorize the payment for the fees. The next time you run billing, the pin_deposit_cc billing utility deposits the credit card payment. (You should run the pin_deposit_cc utility as part of the pin_bill_day script. See "About the Billing Utilities" in BRM Configuring and Running Billing.

Note:

The total due amount for the account is charged immediately and the payment is allocated immediately to all open bill items. Therefore, after the account is created, it will have no pending amount due and no unapplied payments. For such accounts, Customer Center displays the following account balance information in the Summary tab:

  • Amount due for all bills: 0

  • Adjustments/Payments not applied: 0

  • Due now: 0

To determine how to charge customers at registration:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Change the value of the -fm_pymt_pol cc_collect entry:

    • To enable credit card collection, enter 1.

    • To disable credit card collection, enter 0.

  3. Save the file.

You do not need to restart the CM to enable this entry.

To customize this feature, use the PCM_OP_PYMT_POL_SPEC_COLLECT policy opcode. See "Customizing whether to Charge at Registration".

Which Fees are Charged at Registration

Only products that are purchased as part of the account registration process are charged and billed immediately. All other product fees, even for those products purchased the same day as registration, are charged in the first billing cycle. For example, if a customer registers, then purchases an additional product an hour later, the additional purchase fee is charged at the end of the current billing cycle.

How General Ledger Revenue is Reported for Registration Charges

Even though charges collected at registration have been paid, the BRM general ledger (G/L) interface categorizes those charges as unbilled revenue until the first billing cycle.

Customizing whether to Charge at Registration

By default, BRM collects cycle forward and purchase fees on registration for credit card customers. Use the PCM_OP_PYMT_POL_SPEC_COLLECT policy opcode to customize whether to charge the customer immediately for all or part of the current account balances during registration or to defer the charges to a later date. You can also specify whether to validate the charges.

The only type of action that can trigger this opcode is create customer. If this is not passed in, PIN_ERR_BAD_VALUE is returned.

The PCM_OP_PYMT_POL_SPEC_COLLECT policy opcode checks all the account balance groups and specifies the amount for each bill unit.

  • The PIN_FLD_BILLINFO_OBJ field in the input flist specifies the bill unit associated with the payment.

  • The PIN_FLD_ITEMS array in the output flist specifies a list of open items to be paid.

  • If the pay type is _dd, then it determines from the pin.conf file whether to validate, and then validates the account with Paymentech.

The PCM_OP_PYMT_POL_SPEC_COLLECT policy opcode then calls the PCM_OP_PYMT_GET_ACH_INFO opcode to retrieve the Automated Clearing House (ACH) information.

Note:

PCM_OP_PYMT_GET_ACH_INFO retrieves ACH information from the /config/ach object. It uses the ACH vendor name or element ID in the input flist to determine which element in the ACH_INFO array should be used.

BRM supports direct debit transactions from checking accounts only.

You can disable the default logic for the PCM_OP_PYMT_POL_SPEC_COLLECT policy opcode by changing the value of the cc_collect or dd_collect entry in the CM pin.conf configuration file. Change the value from 1 (enabled) to 0 (disabled). See "Charging Customers at Registration".

Replacing Credit Card Numbers with Tokens at Registration

By default, credit card numbers entered during account registration are stored in the BRM database.

You can enable credit card tokenization in BRM to store tokens instead of actual credit card numbers in the BRM database. These tokens are then used for any BRM-initiated payments instead of the actual card numbers.

For more information on credit card tokenization, see the following in BRM Configuring and Collecting Payments:

Specifying Customer Account Defaults

You can set up system-wide defaults that are used by all registration methods. See the following topics:

Specifying the Default Account Currency

You can specify the default account currency for new accounts. For more information, see "Managing System and Account Currencies".

To specify default account currency for new accounts:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Enter a currency code in the currency entry.

    For a list of currency codes, see BRM_Home/include/pin_currency.h.

  3. Save the file.

The new value becomes effective immediately and applies to the next account created. You do not need to restart the CM to enable this entry.

Specifying the Default Country

You can specify the default country for new accounts.

To specify the default country for new accounts:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Change the value of the country entry:

    -  fm_cust_pol   country     USA

    Note:

    The country name must conform to the validation rules for country names set in the Field Validation Editor. See "Specifying How to Validate Customer Contact Information".

  3. Save the file.

The new value becomes effective immediately and applies to the next account created. You do not need to restart the CM to enable this entry.

Changing the Account Number Format

By default, the account number is derived automatically from the account object POID. For example, if the POID is:

0.0.0.1 /account 12225 19

The account number is:

0.0.0.1-12225

The account number does not need to include any part of the POID; you can define your own format.

To change the format of account numbers, customize the PCM_OP_CUST_POL_PREP_ACCTINFO policy opcode.

Defining Customer Email Domain Names

You can change the email domain name that your customers use in their email addresses.

To change the email domain name:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Change the value of the domain entry.

    -  fm_cust_pol   domain   isp.nz

  3. Save the file.

The new value becomes effective immediately and applies to the next account created. You do not need to restart the CM to enable this entry.

Specifying the Valid Expiration-Date Format

You can specify the valid date format for credit card and debit card expiration.

By default, BRM stores expiration dates as four-character strings in the format MMYY. The years from 00 and beyond are understood as the 2000 millennium. Valid formats are MMYY, MM/YY, M/YY, and MM/YYYY, all of which are converted to MMYY.

To change the date format, customize the PCM_OP_CUST_POL_PREP_PAYINFO policy opcode.

Specifying the Maximum Number of Months Allowed in Billing Cycles

A billing cycle defines the time period between bills, which corresponds to the billing frequency (how often a bill is generated). For example, if the billing cycle is three months, a bill is generated every three months.

If a CSR specifies an account's billing frequency that exceeds the maximum number of months allowed in billing cycles, Customer Center returns an error and the CSR must change the billing frequency.

The default maximum number of months allowed in billing cycles is 24.

To change the maximum number of months allowed in billing cycles, use the Field Validation Editor to modify the value of the bill_when field.

Allowing Accounts To Be Created with Backdated Services or Resources

By default, when you create an account, its associated services and resources must have a creation date on or after the account creation date. You can configure BRM to allow users to create accounts with the service or resource date backdated prior to the account creation date. To do so, enable the SubsDis74BackDateValidations parameter in the subscription instance of the /config/business_params object.

To allow accounts to be created with backdated services or resources:

  1. Go to BRM_Home/sys/data/config, which includes the support files used by the pin_bus_params utility.

  2. Use the following command to create an editable XML file from the business_params_subscription instance of 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 path as part of the file name.

  3. Open the bus_params_subscription.xml.out file.

  4. Search for the following line:

    <SubsDis74BackDateValidations>disabled</SubsDis74BackDateValidations>

  5. Change disabled to enabled.

    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 configurations.

  6. Save the file as bus_params_subscription.xml.

  7. Use the following command to load this updated file into the /config/business_params object:

    pin_bus_params bus_params_subscription.xml

  8. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

  9. Stop and restart the CM.

Controlling which Plans and Deals Are Available to Customers

To display plans and deals to CSRs in Customer Center, you use Pricing Center to include the plans in the following plan lists:

  • Use the CSR-new plan list to display plans when you create new accounts in Customer Center.

  • Use the CSR-addon plan list to display plans when you add a service to an existing account in Customer Center.

  • Use the default-new and default-addon plan lists when creating accounts or adding services by using Web-based registration. In most cases, you will use your own plan lists.

    Note:

    The CSR plan lists override the default plan lists. If you have a CSR plan list and a default plan list, Customer Center displays only plans in the CSR plan list.

Options for Presenting Plans and Deals

Displaying plans and deals in Customer Center is the easiest way to present information to customers because the CSR can describe each plan to the customer.

You can also present plans and deals based on customer input. For example, you can give customers a promotion code which, when entered on your Web page, displays a specific list of plans.

If you are creating a custom registration application, use the PCM_OP_CUST_POL_GET_DEALS and PCM_OP_CUST_POL_GET_PLANS policy opcodes to present plans and deals to customers.

Modifying Deals During Registration

You can modify deals during registration; for example, you can provide discounts and price overrides. For more information on modifying deals, see "Managing Customers' Services and Products".

Changing Plan and Deal Names and Descriptions

You create plan and deal names and descriptions when you create your price list in Pricing Center.

Plan and deal names and descriptions are displayed in Customer Center when creating an account and when adding services and deals.

Creating New Registration Fields

Your business might require that you collect information about customers that is not part of the BRM standard set of registration information.

You can customize the Account Creation wizard in Customer Center to collect additional information by using Customer Center SDK. See "Using Customer Center SDK" in BRM Developer's Guide.

If you register customers by using a custom registration application or over the Web, you can create your own registration fields. To do so, you need to create new fields in Storable Class Editor. You can specify validation requirements for custom fields by using the Field Validation Editor.

You can also collect nonstandard information about customers by using profiles. See "About Collecting Nonstandard Account Information".

Checking for Duplicate Registrations

You can have BRM check for duplicate customer registrations. For example, you can set up your customer validation policies to check for a duplicate name or credit card number. This allows you to prevent customers from accidentally signing up and getting billed for accounts they do not want.

This might happen when a customer loses a connection right after creating an account. Being unsure if the account was created, the customer creates a duplicate account.

Note:

While preventing customers from accidentally signing up for a duplicate account, you also run the risk of preventing customers who want two accounts from signing up for the second one.

Checking for duplicate registrations requires editing the source code of the customer validation policy opcodes. See "Customer FM Policy Opcodes" in BRM Developer's Reference.

Validating Registration Numbers

When registering customers, you can offer different plans to different customers by having customers enter registration numbers. You can also assign registration numbers to customers to track marketing information.

To specify how to validate registration numbers, edit the PCM_OP_CUST_POL_VALID_AACINFO policy opcode.

Encrypting Customer Data

Developers can customize BRM to encrypt customer data such as credit card numbers, direct debit accounts, and so on. For more information on setting up encryption, see "Encrypting Fields" in BRM Developer's Reference.

Exporting Registration Information to a Non-BRM Database

To export information to a non-BRM database, customize the PCM_OP_CUST_POL_POST_COMMIT policy opcode.

Customizing Automatic Account Creation (AAC) Information

To prepare automatic account creation (AAC) data for validation, use the PCM_OP_CUST_POL_PREP_AACINFO policy opcode. This policy opcode takes the AAC fields for an /account or /service storable object during customer registration and processes them as necessary to prepare for validation.

To validate automatic account creation data, use the PCM_OP_CUST_POL_VALID_AACINFO policy opcode.

For more information, see "About the PREP and VALID Opcodes" in BRM Developer's Reference.

Creating Hooks to External Programs

Use the following policy opcodes to implement customized registration functionality:

Adding Custom Account Creation Steps before the Account Is Committed

To run additional steps before the account is committed, use the PCM_OP_CUST_POL_PRE_COMMIT policy opcode.

The PCM_OP_CUST_POL_PRE_COMMIT policy opcode is called by the PCM_OP_CUST_COMMIT_CUSTOMER opcode just after the /account and /service storable objects have been created and initialized but before the transaction containing those operations has been committed. Therefore, the PCM_OP_CUST_POL_PRE_COMMIT policy opcode cannot alter the /account and /service storable objects, but it can cancel the registration process by returning an ebuf error. Therefore, you can include tests that the customer must pass before proceeding.

The entire registration flist is passed in the input flist so any information about the customer can be used in interacting with the external or legacy system.

No information is returned as output parameters. Unless an error is returned, registration continues as expected.

The default implementation does nothing.

Adding Custom Account Creation Steps after the Account Is Committed

To run additional steps after the account is committed, use the PCM_OP_CUST_POL_POST_COMMIT policy opcode.

The PCM_OP_CUST_POL_POST_COMMIT policy opcode is called by PCM_OP_CUST_CREATE_CUSTOMER just after the transaction containing the creation and initialization of the /account and /service storable objects has been committed.

The PCM_OP_CUST_POL_POST_COMMIT policy opcode takes the entire registration flist as its input flist so any information about the customer can be used to interact with an external or legacy system. This policy opcode cannot alter the registration data used to create the customer. Because the transaction creating the customer storable objects has already been committed, this operation cannot prevent or alter the registration process in any way. If an ebuf error is returned by the PCM_OP_CUST_POL_POST_COMMIT policy opcode, it is ignored by PCM_OP_CUST_CREATE_CUSTOMER.

No information is returned as output parameters.

Sending a Welcome Email Message

The default implementation of the PCM_OP_CUST_POL_POST_COMMIT policy opcode supports sending a welcome email message to the new customer. See "Setting Up Introductory Messages".

Sending Account Information to Your Application when an Account is Created

To send account information to your application after the account is created, use the PCM_OP_CUST_POL_GET_CONFIG policy opcode. This policy opcode is called by PCM_OP_CUST_COMMIT_CUSTOMER.

The PCM_OP_CUST_POL_GET_CONFIG policy opcode allows configuration information, such as news server address or mail server address, to be determined dynamically.

Input parameters include the POID of the account storable object that was created by the registration. Output parameters include all configuration fields and values that should be returned to the client software.

The default implementation supports different sets of configuration information based on the value of the aac_source field from the customer registration data. The list of configuration fields is stored in a text file in a configurable directory.

Sending Account Information to Your Application when an Account is Modified

To send account information to your application after a service is purchased, use the PCM_OP_CUST_POL_POST_MODIFY_CUSTOMER policy opcode. This opcode is called by the PCM_OP_CUST_MODIFY_CUSTOMER opcode.

The PCM_OP_CUST_POL_POST_MODIFY_CUSTOMER policy opcode provides a mechanism to export customer data to an external or legacy system for processing when new services have been added to existing customers.

PCM_OP_CUST_MODIFY_CUSTOMER calls the PCM_OP_CUST_POL_POST_MODIFY_CUSTOMER policy opcode just after the transaction containing the creation and initialization of the new /service storable object associated with the add-on plan has been committed. The input flist contains all of the same information as the input flist of PCM_OP_CUST_MODIFY_CUSTOMER, thereby allowing any information about the customer to be used by the external or legacy system. Because the transaction creating the customer /service storable object has already been committed, the PCM_OP_CUST_POL_POST_MODIFY_CUSTOMER policy opcode cannot alter the customer data or prevent or alter the customer modification process in any way. If an error is returned by the PCM_OP_CUST_POL_POST_MODIFY_CUSTOMER policy opcode, it is ignored by PCM_OP_CUST_MODIFY_CUSTOMER.

Returning a Point-of-Presence (POP) List

To get a registration point-of-presence (POP) list, use the PCM_OP_CUST_POL_GET_POPLIST policy opcode.

This opcode retrieves either the best POP for a registering customer to call or the entire list of POPs so the customer can choose one. Both approaches are supported because some registration models do not supply the customer phone number when retrieving the POP list, so no automatic matching can be done. If no phone number is supplied, the entire POP list is returned.

If the application requires the entire POP list, then all that is required on the input flist is the PIN_FLD_POID.

If the application is looking for the nearest POP based on location, the input flist requires the area code and prefix (or the ANI) in the PIN_FLD_ANI field and the PIN_FLD_POID field containing the database number where the POP tables reside.

The fields returned to the caller when a specific POP is needed are:

  • PIN_FLD_PHONE

  • PIN_FLD_CITY

  • PIN_FLD_STATE

  • PIN_FLD_ZIP

  • PIN_FLD_FLAGS

The PIN_FLD_FLAGS field contains two flags:

  • The POP_TOLL_FREE flag, if set, indicates whether the POP will be a toll free call for the caller.

  • The POP_DIAL_ONE flag, if set, indicates that the caller needs to dial 1 first when placing the call to the pop.

These flags are bit flags. To check if POP_DIAL_ONE is set, for example, the code would be:

if (flags & POP_DIAL_ONE) {
/*
** Action code.
*/
}

The fields returned to the caller when a list of POPs is requested is an array of POPs (PIN_FLD_POP) where each element contains fields:

  • PIN_FLD_PHONE

  • PIN_FLD_CITY

  • PIN_FLD_STATE

  • PIN_FLD_ZIP

The default implementation uses /pop storable objects in the database to determine the POP information to return. Applications are provided with BRM to load POP storable objects into the database for each POP in the network and to compute the best POP for each exchange in the U.S. based on phone call rating tables from a third party.

Creating Accounts in a Multischema System

In multischema systems, you can configure BRM to balance account loads among database schemas. See "Managing a Multischema System" in BRM System Administrator's Guide.

You can use policy opcodes to customize how to select schemas during account creation:

Getting a List of Database Schemas

To get a list of database schemas defined in a multischema environment, use the PCM_OP_CUST_POL_GET_DB_LIST policy opcode. If you have schemas that you do not want included in the list of available schemas, you can customize this opcode to prevent them from being listed.

The default implementation returns the cached list of schema distributions created by the PCM_OP_CUST_POL_GET_DB_NO policy opcode during BRM initialization. It is designed for use by Brand Manager to enable you to select which schema should be used when creating a brand and then ensure the brand is created in that schema. This is crucial because all the sub-brands and accounts in the brand must be in the same schema as the top-level brand.

When BRM is set up as a multischema environment, the output flist contains a POID and the schema distributions array. In a single-schema environment, the output flist contains only the POID.

Selecting a Database Schema

In a multischema system, the criteria for selecting a schema is set in the BRM_Home/apps/multi_db/config_dist.conf file. See "Setting Database Schema Priorities" in BRM System Administrator's Guide. During account creation, PCM_OP_CUST_COMMIT_CUSTOMER calls the PCM_OP_CUST_POL_GET_DB_LIST policy opcode to select a schema for the new account.

You can customize the selection process by customizing the PCM_OP_CUST_POL_GET_DB_NO policy opcode.

If you are not using a multischema system, this step is ignored at account creation.