This chapter describes the basic concepts of Oracle Communications Billing and Revenue Management (BRM) billing.
See "About Corrective Billing" for information on generating new bills based on corrections performed against a past billed period.
BRM billing is based on monthly cycles. Each account's bill unit has a billing day of month (DOM), which is typically the day of month on which the account is created. For example, if an account is created on May 7, all of its bill units, by default, would have the seventh day of the month as their billing DOM. If the account is billed monthly, its bills are generated on June 7, July 7, August 7, and so on. Most customer accounts are billed monthly, but you can bill accounts at any monthly interval; for example, bimonthly, quarterly, semiannually, or annually.
Note:By default, all bill units in an account have the same billing DOM and billing frequency, but you can modify each bill unit to have a different billing DOM and billing frequency.
To bill customers, you run a set of billing applications. A bill is produced for every bill unit. One billing application, pin_bill_accts, finds every bill unit that has a billing date of the previous day (or earlier if you do not run the billing applications daily). After finding the bill units, BRM does the following to them:
Performs monthly accounting. BRM compiles the total amount of balance impacts that have occurred in the past month. This can include usage fees and subscription fees. This monthly accounting occurs at the end of each accounting cycle.
Finalizes the bill. To finalize a bill, BRM changes the status of all the bill items associated with the bill from pending to open so that they stop accumulating charges and so that payments can be applied to them. In addition, a payment due date is added to the bill. The time period during which charges accumulate in an account before a bill is finalized is called the billing cycle. Typically, a bill is finalized monthly, at the end of each accounting cycle. However, you can bill in any multiple of one month; for example, every two months, quarterly, or yearly. A finalized bill includes balance impacts from each accounting cycle in the billing cycle.
Requests a payment. BRM supports two types of payments:
You process BRM-initiated payments by automatically requesting payments from a credit card or debit card processor.
You process externally initiated payments by sending invoices, receiving the payments, and processing the payments in batches.
An invoice lists the events that were charged for, and the customer's total balance for that bill.
When a payment is recorded in the BRM database, the customer's account balances are updated automatically.
Figure 1-1 shows how BRM compiles bills and requests payments from customers:
For information about the billing opcodes, see "How BRM Creates a Bill".
Billing is performed in cycles. There are two types of cycles:
The accounting cycle compiles all of a customer's balance impacts and stores them in bill items. The accounting cycle is always monthly.
The billing cycle defines how often to request a payment for the balance impacts contained in the bill items. You can request payments every month, or in any number of complete months; for example, quarterly. Therefore, the accounting cycle and the billing cycle always start on the same date, but they can be different lengths.
Accounting cycles and billing cycles are different in other important ways:
Customer impact. The accounting cycle is an internal cycle; that is, it does not affect a customer in any way other than adjusting the account balance. The billing cycle is an external cycle. After you run billing, your customers receive an invoice or receive a credit card or debit card transaction.
When activity occurs. For accounting cycles, activities, such as recording balance impacts into usage items, occur during the accounting cycle. For billing cycles, activity occurs only at the end of the billing cycle when BRM finalizes a bill and requests a payment from the customer.
A cycle forward fee incurred at registration is included in the cycle forward item. Therefore, the first bill includes two cycle forward fees, as shown in Figure 1-2.
The first cycle forward fee affects other aspects of billing:
How revenue is reported in general ledger reports. See "About Unbilled/Unearned Cycle Forward Fees" in BRM Collecting General Ledger Data.
By default, an accounting cycle always ends at midnight, specifically at 23:59:59, and the next accounting cycle always begins at 00:00:00. BRM performs various tasks at the end of one accounting cycle and the beginning of the next accounting cycle:
At the end of an accounting cycle, BRM performs these tasks:
Applies balance impacts from deferred cycle forward events.
Applies balance impacts from cycle discount events.
Applies balance impacts for fold events. For example, if a product uses fold events to remove unused free hours, the fold events are rated and the balance impacts are applied at the end of the accounting cycle.
Creates one or more cycle forward items, one for each service that the customer owns. The cycle forward items include any cycle forward balance impacts that apply to the following month. The cycle forward items have a status of pending.
Applies balance impacts from cycle rollover events.
Calculates deferred taxes, if any, and applies them as balance impacts. See "Choosing When to Calculate Taxes" in BRM Calculating Taxes.
Applies balance impacts from cycle arrears events to the current usage item.
Applies balance impacts from cycle forward arrears events to the next cycle's cycle forward arrears item.
At the beginning of a new accounting cycle, BRM performs these tasks:
Creates a usage item. Balance impacts from usage fees, cancel fees, and purchase fees are added as they occur. The usage item has a status of pending.
Creates pre-created items for each service that is specified in the /config/item_tags and /config/item_types storable objects. These items have a status of pending.
If the account uses a multimonth billing cycle, new cycle forward and usage items are created every month, resulting in multiple cycle forward and usage items.
By default, an accounting cycle begins on the day of the month that the customer registers. In BRM, this day is called the accounting day of month (DOM).
For example, if the customer registers on the 15th, the accounting cycle starts on the 15th day of the month. The end of the accounting cycle will depend on when the accounting cycle began. If the accounting cycle began on a date that is common to all months, it will end on the same date. If the customer registers on the 29th, 30th, or 31st of the month, for months that do not have the date, the accounting cycle will end on the first day of the month following the next month. For example, if the customer registers on January 31, the accounting cycle will begin on January 31. Because February does not have 31 days, the accounting cycle will end on March 1 by default.
Although an accounting cycle is always one month long, the length of the accounting cycle changes from month to month. For example, if an accounting cycle starts on the 15th day of the month, there are more days between January 15 and February 15 than there are between February 15 and March 15.
You can change the default accounting cycle date for all accounts to a single date, but that can result in an excessive load on the BRM system. See "Setting the Default Accounting Day of Month (DOM)".
To assign an account to an accounting DOM other than the default, see "About Managing Billing Cycles".
Billing cycles consist of a billing DOM and a billing frequency:
The billing DOM specifies the date on which BRM finalizes a bill and requests payment from the customer. The billing DOM is determined by the bill unit's billing segment, the DOM of the account's other bill units, the default setting in the Connection Manager (CM) configuration file, or the current date. For information, see "How BRM Sets the Billing DOM".
The billing frequency specifies how often to finalize a bill and request payments from customers. The billing cycle length is any whole multiple of the accounting cycle. For example, a monthly billing cycle corresponds to one accounting cycle, and a quarterly billing cycle corresponds to three accounting cycles (Figure 1-3). To change the default billing cycle length, see "Setting the Default Billing-Cycle Length".
The billing DOM and billing frequency are set at the bill unit (/billinfo object) level. Accounts with multiple bill units can have different billing cycle settings for each bill. For example, an account with two bill units can have:
One bill unit with a billing DOM of 5 and a monthly billing frequency.
One bill unit with a billing DOM of 15 and a quarterly billing frequency.
Note:Child bill units must have the same billing DOM and billing frequency as their parent bill unit.
BRM sets a bill unit's billing DOM based on the following order of priority:
The DOM assigned to the billing segment. BRM assigns the DOM set for the billing segment in the /config/billing_segment object. For more information, see "Assigning DOM Based on the Billing Segment".
Note:To customize how BRM assigns the DOM according to the billing segment, see "Customizing the DOM Assignment Process".
The DOM used by the first bill unit in the account. If a DOM is not assigned to the billing segment, BRM sets the DOM to that of the first bill unit in the account.
Default setting in the CM pin.conf file. If a DOM is not assigned to the billing segment nor is available from another bill unit, the DOM is set to the value assigned in the actg_dom entry in the CM configuration file (BRM_home/sys/cm/pin.conf, where BRM_Home is the directory in which BRM components are installed). To set the default value, see "Setting the Default Accounting Day of Month (DOM)".
The current date. If a DOM is not available from the billing segment, other bill units, or the CM pin.conf file, BRM assigns the DOM to the current date.
For example, if an account was created with two bill units, BU1 that has an assigned DOM and BU2 that does not have a DOM assigned, BRM would assign a DOM to BU2 as follows:
If BU2 is the second bill unit in the account, BRM sets the DOM to that of BU1.
If BU2 is the first bill unit in the account, BRM sets the DOM to the value in the CM pin.conf file. If a value is not set in the CM pin.conf file, the DOM is set to the current date.
Typically, at the end of a billing cycle, BRM performs the following:
Changes the status of the bill items associated with each bill unit to open. Therefore, no further balance impacts are added to those items, and BRM can request payments for those items.
Finalizes a bill for each bill unit in the BRM database. A bill includes balance impacts from the bill items. If the billing cycle includes more than one accounting cycle, the bill includes balance impacts from multiple bill items. For example, a quarterly bill includes balance impacts from three usage items and at least three cycle forward items.
Depending on the payment method, either requests a BRM-initiated payment (either credit card or direct debit) or creates an invoice for the bill. For some payment methods, such as Undefined, BRM makes no payment request. See "About Payment Methods" in BRM Configuring and Collecting Payments.
Collecting payments does not occur automatically at the end of a billing cycle. You must set up billing applications that automatically request payments at the end of an account's billing cycle. See "About the Billing Utilities".
By default, auto-triggered billing is always enabled.
Note:If you use delayed billing, auto-triggered billing is always enabled for the delay period. And by default, it is also enabled for the last two days only of each bill unit's accounting cycle. For more information about auto-triggered billing during delayed billing, see "About Delayed Billing".
When auto-triggered billing is enabled, BRM automatically triggers billing when an event occurs after the billing date but before billing is run. For example:
An account's billing date is May 15, and billing will be run for the account on May 15 at 02:00:00.
On May 15 at 01:00:00: one hour after the end of the previous billing cycle but one hour before that billing is run: a usage event associated with the account occurs. This usage event belongs to the next billing cycle.
To ensure that the usage event is recorded in the correct billing period, BRM immediately performs the billing processes: for example, changes item status to open: and finalizes a bill for the account.
The event that triggered billing is included in the items for the next bill.
Note:Auto-triggered billing performs only the operations that the pin_bill_accts utility normally performs. It does not do any payment requests; those are done when you run the pin_collect utility.
Events that trigger billing include the following:
Purchasing a product
Changing account status
Canceling a product
Rating a usage event
Note:The event does not need to have a balance impact to trigger billing.
You can disable auto-triggered billing when, for example, you might want to run billing only by running the billing application (pin_bill_accts). See "Disabling Auto-Triggered Billing".
You can set up BRM to delay billing for accounts after the end of a billing cycle. This is called delayed billing. Delayed billing essentially extends a billing cycle by the delay interval. You use delayed billing to bill for events that occur within a billing cycle but are not recorded during that cycle.
For example, if you put events in batches to be recorded later but do not process those batches until after the end of the billing cycle, you delay billing until all events in the batch are recorded in the BRM database. When you use delayed billing, billing for all the accounts in your BRM system is delayed for the same amount of time.
Figure 1-4 shows that with delayed billing, the billing date occurs after the original billing date, during the next accounting cycle.
Important:The length of the delay interval must be shorter one accounting cycle.
For information about setting up delayed billing, see "Setting Up Delayed Billing".
When your system is set up to use delayed billing, an account is created with two pending bills: one for the current cycle and one for the next cycle: which are combined in the Customer Center Balance tab. The combined pending bill includes separate items for the previous accounting cycle and for the next accounting cycle. When the bill for the current cycle is finalized at the end of the delay interval, the system makes the bill for the next cycle to be the current bill and creates a new bill for the next cycle.
When delayed billing is used, the /billinfo object might be billed twice, once during the delay interval and again after the delay interval.
The BRM system automatically triggers billing inside the delay interval when it detects that a new event has occurred for the next billing cycle. When billing is triggered during the delayed-billing period, the bill for the previous cycle is only partially processed (partial billing), but the bill is not finalized. BRM performs partial billing to enable the new event to be rated and applied to the correct billing period. Partial billing ensures that new events impact bill items of the next billing cycle and old events impact bill items of the previous billing cycle. BRM maintains an internal list of bill items for the previous and next bill cycles. The bill for the previous cycle is finalized (final billing) after the delay interval.
During partial billing, BRM does the following:
Applies deferred cycle forward fees to the next billing cycle.
Applies cycle arrears fees to the previous billing cycle.
Applies cycle forward fees.
Applies cycle rollovers.
During final billing, BRM does the following:
Applies cycle discounts (billing time discounts).
Applies cycle folds.
Applies cycle taxes.
Calculates a /bill object for the previous billing cycle.
Initializes the next billing cycle.
Creates a new empty /bill object for the next billing cycle with default and pre-created items.
The following example is illustrated in Figure 1-5:
An account's billing date is January 1 and the billing delay interval is five days.
On January 2, a new usage event for the account occurs for the next billing cycle.
To ensure that the new usage event impacts items in the next billing period (B2), BRM performs partial billing.
On January 6, final billing is run for the previous billing cycle (B1) by running the billing utility: the status of all the bill items for the previous bill is changed to open so that they stop accumulating charges.
When you use delayed billing, auto-triggered billing is disabled for all but the delay interval and only the last two days of each bill unit's accounting cycle.
When a bill-triggering event occurs during the delayed-billing period, BRM auto-triggers partial billing and, if final billing has not occurred before the last two days of the next billing cycle, BRM auto-triggers final billing. This ensures previous billing is run before the next billing run occurs.
An event for the next billing cycle is recorded after the billing delay interval on January 7.
The BRM system detects that the delay period is over but final billing for the previous billing cycle has not occurred yet.
If auto-triggered billing is disabled (the default when delayed billing is configured), BRM does not run final billing on January 7. In this case, the delay interval is virtually extended until final billing is performed by running the billing utility or auto-triggered during the last two days of the next accounting cycle.
If auto-triggered billing is enabled, BRM auto-triggers final billing for the previous billing cycle on January 7.
You can change auto-triggered billing to be always enabled when delayed billing is used by setting the auto_triggering_limit parameter to 0. See "Specifying Auto-Triggered Billing for Delayed Billing".
You can also change the number of days auto-triggered billing is enabled at the end of each accounting cycle. See "Specifying Auto-Triggered Billing for Delayed Billing".
For more information, see:
If you change a customer's billing DOM during the delayed billing period, BRM defers the DOM change until after the delay interval ends. This ensures that the change to the billing DOM occurs in the future billing cycle. For example, assume that a customer's billing DOM is 1 and the delay interval is 5, making the billing date for the first three months of the year to be January 1, February 1, and March 1. If on January 3 the customer changes the billing DOM to 15, BRM defers making the change until January 6 (January 1 plus 5 days). This changes the billing date for the first three months to January 1, February 1, and March 15.
Note:To have the billing DOM change deferred until after the delay interval, auto-triggered billing must be disabled; otherwise, the billing DOM change occurs immediately. For example, changing the billing DOM to 15 on January 3 would change the billing date to February 15. See "About Auto-Triggered Billing".
Usually, you bill a customer at the end of the customer's billing cycle. However, you can bill a customer immediately for a purchase, even if the customer's billing cycle has not ended. To perform on-demand billing, you create a deal or plan and flag it for on-demand billing. A bill for purchase fees only is created and finalized as soon as the plan or deal is purchased.
If the purchase is for a parent /billinfo, a /bill object is created with just that parent's purchase total. If the purchase is for a subordinate /billinfo, the parent receives the bill, but it includes only the subordinate /billinfo total.
Important:An on-demand bill includes only purchase fees. To create a bill that includes all the customer's pending charges, use the Bill Now feature in Customer Center. See "About Bill Now" for more information.
See the following related topics:
For information about the opcodes used for on-demand billing, see "How On-Demand Billing Works".
For information about configuring on-demand billing in a price list, see "Using Deals to Bill Your Customers on Demand" and "Using Plans to Bill Your Customers on Demand" in BRM Setting Up Pricing and Rating.
For information about using on-demand billing in Pricing Center, see the discussion about enabling on-demand billing in the Pricing Center online help.
By default, the Bill Now feature in Customer Center generates a bill that includes all pending items, and any cycle arrears and cycle forward arrears fees for an account or a specified bill unit. Therefore, for both open item accounting and balance forward accounting types, Bill Now adds the previous total amount to the current total. For example, an account with open item accounting bill type has a previous total of $20 and it's current total is $10. When Bill Now is run, the account is billed for $30.
When an account has multiple bill units (/billinfo), only one parent bill unit can be processed at a time.
For example, consider the following bill hierarchy:
Parent Account | -- Bill 1 (nonsubordinate bill unit) | -- Child Account 1 (subordinate bill unit) -- Bill 2 (nonsubordinate bill unit) | -- Child Account 2 (subordinate bill unit)
Bill 1 and Bill 2 are parent bill units. To generate the bills for both bill units, run Bill Now sequentially to process one bill unit at a time. You can select items that belong to either Bill 1 or Bill 2. If you select items that belong to different parent bill units, Bill Now reports an error.
Important:If you run Bill Now on a subordinate /billinfo, a bill is created for the parent /billinfo that includes only the subordinate /billinfo items. If you run Bill Now on a parent /billinfo, a bill is created that contains a total of the items from both the parent and any subordinate /billinfo objects.
You can also choose to bill all pending items or select specific items. When a bill is generated for specific items, it does not include the cycle arrears and cycle forward arrears fees. Unbilled items will continue to be displayed under Bill in Progress until they are billed.
To customize which pending items are included during billing, edit the search parameters in the PCM_OP_BILL_POL_GET_PENDING_ITEMS policy opcode. Optionally, you can also include billing-time discounts and folds in the bill. For more information, see "Customizing Bill Now" and "Applying Discounts and Folds with Bill Now".
Important:If you run Bill Now on a subordinate /billinfo and select specific pending bill items, a bill is created for the parent /billinfo that includes only the selected pending items from the subordinate /billinfo items. If you run Bill Now on a parent /billinfo and select specific pending bill items, a bill is created that contains the selected pending items from both the parent and any subordinate /billinfo objects.
In your customer relationship management (CRM) tool, you can use Bill Now to bill for a specified service. See "Running Bill Now for a Service" and PCM_OP_BILL_CREATE_SPONSORED_ITEMS.
If you use delayed billing, you can use Bill Now to create two bills using your CRM tool during the delayed billing period. See "Creating Two Bills during the Delayed Billing Period".
For more information on Bill Now, see the following:
About Billing upon Subscription Service Cancellation in BRM Managing Customers
BRM bills include the charges incurred during the current billing cycle and, optionally, any unpaid charges from previous billing cycles. You control whether BRM bills include charges from previous billing cycles by setting the accounting type:
With open item accounting, a customer is billed only for charges from the bill items in the current bill. If a customer does not pay a bill, the next bill does not include charges for the bill that the customer did not pay.
You typically use open item accounting for non-credit card accounts, where a customer receives an invoice. Each invoice includes the items that apply to a single billing cycle. If a customer does not pay a bill, the customer still has the invoice for the old bill when the customer receives the next invoice.
With balance forward accounting, a customer's bill includes all the charges that a customer owes, including those from previous billing cycles. If a customer does not pay a bill, the next bill includes the charges from the previous bill.
Accounts for customers who pay by credit card should always use balance forward accounting. Balance forward accounting is the default.
Accounting types are set at the bill unit (/billinfo object) level rather than at the account level. This enables accounts with multiple bill units to have different accounting type settings for each bill. For example, an account with two bill units can have one bill unit with an open item accounting type and another bill unit with a balance forward accounting type.
BRM determines a bill unit's accounting type by reading and using the following accounting type settings in the order shown below:
Customer Center or opcode flist setting. You can specify a bill unit's accounting type when you create or modify an account in Customer Center.
If you use a custom client application, you can specify a bill unit's accounting type by passing it in the PIN_FLD_ACTG_TYPE input flist field of the following opcodes:
Default setting in the Connection Manager (CM) configuration file. You can specify a default accounting type by using the actg_type entry in the CM configuration file (BRM_Home/sys/cm/pin.conf). BRM uses this setting during account creation for all accounts and bill units only if an accounting type is not passed in the input flist. To set the default value, see "Setting the Default Accounting Type".
System wide accounting type. If an accounting type is not specified using any of the above settings, BRM automatically sets the bill unit's accounting type to balance forward accounting.
A bill unit's accounting type can be changed at any time. However, BRM does not validate the change nor take any actions other than changing the accounting type in the next billing cycle. You must ensure that the impact of any accounting type changes do not confuse your customers. For example:
If the accounting type is changed from open item accounting to balance forward accounting, the customer's next bill would include all open and unpaid items. Your customer should be informed that the bill now includes any past due charges from previous billing cycles.
If the accounting type is changed from balance forward accounting to open item accounting, the customer's next bill would not include any unpaid items. Your customer should be informed that charges from previous bills are still past due, even though they do not appear on the current bill.
Storing information in bill items enables you to make adjustments to the customer's balance due.
BRM tracks accounts receivable in these types of bill items:
Cycle forward items track the accounts receivable for cycle forward fees. See "About Cycle Forward Events" in BRM Setting Up Pricing and Rating for more information about the events that these items represent.
Cycle arrears items track the accounts receivable for cycle arrears fees. See "About Cycle Arrears Events" in BRM Setting Up Pricing and Rating for more information about the events that these items represent.
Cycle forward arrears items track the accounts receivable for cycle forward arrears fees. See "About Cycle Forward Arrears Events" in BRM Setting Up Pricing and Rating for more information about the events that these items represent.
Usage items track the accounts receivable for usage fees, purchase fees, and cancel fees. These fees are stored in the /item/misc storable object.
An /item/misc object is created for each account and for every service that the account owns. This enables you to manage fees for each service independently; for example, you can display the usage fees for separate telephony services.
Custom items track the accounts receivable for customized bill items you create. See "About Custom Bill Items".
For more information on bill items and how you use them to manage accounts receivables, see "About Accounts Receivable" in BRM Managing Accounts Receivable.
An account's billing information is stored in a bill unit (a /billinfo object in the BRM database). The bill unit associates each account balance group with a bill and a payment method. When you bill accounts, a bill is produced for every bill unit.
You can create multiple bill units for a single account. Each bill unit in an account has its own payment method, accounting type, billing DOM, and billing frequency.
By default, accounts are created with one bill unit. You create additional bill units by using Customer Center. See the Customer Center Help.
You can also create bill units by implementing BRM opcodes in your custom code. Specify the account to which the bill unit belongs and link the account balance groups to the new /billinfo object. See "Managing Bill Units with Your Custom Application".
When an account has multiple bill units, a bill is produced for each bill unit in the account, as shown in Figure 1-6.
You perform the following for each bill unit in an account:
Associate a payment method, such as credit card, direct debit, or invoice. With multiple bill units, accounts can be billed for services separately, using a different payment method for each bill.
Specify the billing DOM.
Specify the billing frequency.
Specify the accounting type: open item accounting or balance forward accounting.
A child account is not required to use the same billing cycle as its parent account. However, if the child account has a subordinate (nonpaying) bill unit, that bill unit must have the same billing DOM and billing frequency as the parent account. Paying bill units in the child account that are paid by the child account use the child account's billing DOM and cycle.
For more information, see "Creating Hierarchical Bill Units" in BRM Managing Accounts Receivable.
The PCM_OP_BILL_MAKE_BILL opcode creates a /bill object. PCM_OP_BILL_MAKE_BILL does the following:
Applies cycle fees.
Totals pending items in the /bill current total field.
Totals open items in the /bill previous total field.
If rollover correction is enabled, can trigger the creation of rerating requests at the end of the delayed period if call detail records (CDRs) from the previous cycle borrow rollover from the current cycle. See "Enabling Rerating and Rollover Correction Due to Delayed Events".
To trigger the creation of rerating requests, this opcode can create a notification event of type /event/notification/rollover_correction/rerate for the account being billed and possibly other accounts from which a line was transferred into the account. Depending on how automatic rerating is configured, the notification event triggers the creation of rerating requests.
If rollover correction is enabled, triggers rollover correction if CDRs borrow from the previous cycle borrow rollover from the current cycle. See "Enabling Rerating and Rollover Correction Due to Delayed Events".
If payment incentives are enabled, calls the PCM_OP_PYMT_GRANT_INCENTIVE opcode, which determines whether to grant the payment incentive and also calculates the incentive. PCM_OP_BILL_MAKE_BILL then retrieves the payment incentives and recalculates the affected bill, changing the balance impacts accordingly. See "Configuring Payment Incentives" in BRM Configuring and Collecting Payments.
To determine the payment due date of a bill, calls the PCM_OP_BILL_POL_CALC_PYMT_DUE_T policy opcode. See "How BRM Calculates Bill Due Dates".
At the end of the last accounting cycle in a bill unit's billing cycle, PCM_OP_BILL_MAKE_BILL calls the PCM_OP_BILL_POL_CHECK_SUPPRESSION policy opcode to find out whether a bill should be suppressed.
If the output flist of the policy opcode indicates that the bill should be suppressed, performs these tasks:
Generates an /event/billing/suppression event.
Extends the bill for another billing cycle instead of finalizing it.
If the output flist of the policy opcode indicates that the bill should not be suppressed, performs these tasks:
If the output flist includes an exception to bill suppression, generates an /event/billing/suppression/exception object and then finalizes the bill. (See "Exceptions to Bill Suppression".)
If the result does not include an exception, finalizes the bill.
Whether or not the output flist of the policy opcode indicates that the bill should be suppressed, PCM_OP_BILL_MAKE_BILL always subtracts 1 from the /billinfo counter that tracks the remaining cycles for which a bill has been manually suppressed (PIN_FLD_SUPPRESSION_CYCLES_LEFT) if the value in the counter is greater than 0.
When you use delayed billing, PCM_OP_BILL_MAKE_BILL performs some functions on the billing DOM and performs the rest of the functions at the end of the delay interval. See "About Delayed Billing".
Calls the PCM_OP_SUBSCRIPTION_CALC_BEST_PRICING opcode to calculate the best price after applying all the charges and discounts and before applying the billing-time tax.
If the best pricing calculation is successful, PCM_OP_BILL_MAKE_BILL finalizes the bill, taking into account the use of any alternate deal.
If the /billinfo object being billed is a parent, PCM_OP_BILL_MAKE_BILL creates a single /bill object for that parent, which includes all pending and open items from its subordinate /billinfo objects.
By default, bill numbers for regular bills are B1-1, B1-2, B1-3, and so on. And for corrective bills, the default numbering is CB1-1, CB1-2, CB1-3, and so on.
The default numbering takes the format Prefix-Seq_Number, where:
Prefix represents the prefix to be used for the bill.
For regular bills, BRM assigns BDB_num as the default prefix. DB_num indicates the number of the database in which the original bill is stored. For example, when DB_num is 1, 3, or 7, the prefixes for regular bills are B1, B3, or B7.
For corrective bills, BRM assigns CBDB_num as the default prefix. For example, when DB_num is 1, 3, or 7, the prefixes for corrective bills are CB1, CB3, or CB7.
Seq_Number is the unique sequence number from the appropriate /data/sequence object. BRM supports two types of /data/sequence objects, (PIN_SEQUENCE_TYPE_BILL_NO and PIN_SEQUENCE_TYPE_CORR_BILL_NO).
Note:Of these two /data/sequence objects, PIN_SEQUENCE_TYPE_CORR_BILL_NO is used exclusively for corrective bills.
For regular bills, BRM uses the unique sequence number from the PIN_SEQUENCE_TYPE_BILL_NO /data/sequence object.
For corrective bills, you can select to use the unique sequence number from either of the two /data/sequence objects, (PIN_SEQUENCE_TYPE_BILL_NO and PIN_SEQUENCE_TYPE_CORR_BILL_NO).
A regular bill and all its corrective bills have the same POID (the bill object identifier in the BRM database). As a result, you can use the bill POID to retrieve the complete set of bills, that is, the corrected bill and its prior bills.
You can customize bill numbers in BRM as described in "Setting Business Policies for Billing".
The PCM_OP_BILL_MAKE_BILL_NOW opcode creates a bill for a specified /billinfo object immediately from Customer Center. If a /billinfo object is not specified, this opcode creates one /bill for each /billinfo for the given account.
The PIN_FLD_NAME field in the /bill object contains the type of billing the /bill object is for:
Billing on demand
Bill Now for the current cycle
Bill Now on the next cycle
The last two options enable creating two bills during the delayed period if your customer management system (CMS) supports that functionality. One bill is generated for the current cycle charges; the other is generated for the next cycle charges.
PCM_OP_BILL_MAKE_BILL_NOW performs the following tasks:
Calls the subscription management opcodes to apply cycle forward, cycle arrears, and cycle forward arrears fees.
If called for a service of a sponsored account, PCM_OP_BILL_MAKE_BILL_NOW calls the PCM_OP_BILL_CREATE_SPONSORED_ITEMS opcode. The bill produced is for the pending items for the specified service of the sponsored account.
If called on a subordinate /billinfo, creates one bill for the parent /billinfo that only includes the items from the subordinate /billinfo. In such cases, the PIN_FLD_GROUP_OBJ field in the /event/billing/cycle/tax object contains the POID of the subordinate /billinfo. If called on a parent /billinfo, creates one bill that contains a total of the items from both the parent and any subordinate /billinfo objects. This includes any subordinate cycle taxes. In such cases, the PIN_FLD_GROUP_OBJ field contains the POID of the parent /billinfo.
Calls the PCM_OP_SUBSCRIPTION_CALC_BEST_PRICING opcode to calculate the best price after applying all charges and discounts and before applying the billing-time tax. Best pricing operation is performed for the period between the start of the billing cycle to the time billing is run.
If you choose to bill only a subset of the pending items by using the PCM_OP_BILL_POL_GET_PENDING_ITEMS policy opcode, the best pricing calculation is performed for all the items. However, the bill contains only the selected items with the balance based on the alternate deals.
If the best pricing calculation is successful, this opcode finalizes the bill, taking into account the use of any alternate deal.
If configured, PCM_OP_BILL_MAKE_BILL_NOW calls the PCM_OP_BILL_CYCLE_TAX opcode to calculate taxes. See "Calculating Taxes during Billing" in BRM Calculating Taxes.
Note:Bill Now ignores the cycle_tax_interval value in the CM's configuration file (pin.conf) and always rolls activities for each subordinate /billinfo into the parent /billinfo and calculates taxes for the parent only.
If configured, Bill Now prorates cycle arrears and cycle forward arrears fees. See "Prorating Cycle Arrears and Cycle Forward Arrears for Bill Now".
Bill Now does not generate invoices. You must separately run the pin_inv_accts utility or the pin_bill_day script. For more information about invoices, see "How Invoices Are Generated" in BRM Designing and Generating Invoices.
Several options control how Bill Now works. See "Configuring Bill Now".
The PCM_OP_BILL_MAKE_BILL_ON_DEMAND opcode creates a /bill object immediately when a deal or plan that is flagged for on-demand billing is purchased.
To create a bill on demand for a deal or plan, the PCM_FLD_ON_DEMAND_INFO field must be set in /plan or /deal objects. Set this field using Pricing Center by selecting Bill on Demand on the plan or deal Attributes tab. For information about using on-demand billing see the discussion about enabling on-demand billing in the Pricing Center online help.
If your BRM system is setup for sponsorship and contains sponsor or resource sharing groups, you must reconfigure your billing setup to ensure that member accounts are billed before owner accounts. See "Setting Up Billing for Sponsorship".
Caution:If you do not reconfigure billing for sponsorship, members' sponsored charges might not be included in their owner's bill for the current billing cycle. Instead, they are added to the owner's bill for the next billing cycle.
For more information about billing, see the following: