Oracle BRM billing process

First, let’s take a look at an overall picture of what the Oracle BRM billing process does:

1. Compiles the total amount of balance impacts that have occurred in the past month. This can include usage fees and subscription fees.
2. Changes the status of all the bill items associated with the bill from pending to open so that they stop accumulating charges, and payments can be applied to them. In addition, a payment due date is added to the bill.
3. Automatically requests payments from a credit card processor or requests payments by sending invoices.
4. Automatically updates a customer’s account balance when a payment is recorded in the BRM database.

So, how is all this done in practice?

Before running a brm billing on production, it is necessary that all the prerequisite steps be executed. The first step is to prepare a copy of the production environment – this can either be preproduction or some testing environment. This step includes the installation of the latest production release onto this environment and the copying of the production database. Next, the environment configurations have to reflect those of production. Here are the main configurations, which should be set appropriately:

• cm configuration ($HOME/pin/sys/cm/pin.conf),

o Verify loglevel entry is set to 1

o Change the entry for agent_return parameter to 0

o Change the entry for simulate_agent parameter to 1

These two last changes are done so as not to involve any provisioning action during the bill-run.

• dm_oracle configuration ($HOME/pin/sys/dm_oracle/pin.conf),

o Set dm_bigsize parameter to 8388608 or higher

o Set dm_shmsize parameter to 33554432 or higher

o Set dm_n_fe to 8

o Set dm_max_per_fe to 16

o Set dm_n_be to 24

o Set dm_trans_be_max to 22

• pin_bill_accts configuration ($HOME/pin/apps/pin_billd/pin.conf),

o Verify loglevel. Change it to the appropriate value depending on what needs to be checked during the bill test, either 1 or 3.

o Change children parameter for pin_billd and pin_mta to 5

o Change per_batch parameter for pin_billd and pin_mta to 20000

o Change fetch_size parameter for pin_billd and pin_mta to 150000

• pin_inv_accts configuration ($HOME/pin/apps/pin_inv/pin.conf),

o Verify loglevel. Change it to the appropriate value depending on what needs to be checked during the bill test, either 1 or 3.

o Change children parameter for pin_billd and pin_mta to 5

o Change per_batch parameter for pin_billd and pin_mta to 2000

o Change fetch_size parameter for pin_billd and pin_mta to 15000

To get the best possible simulation of production, the billrun pin_virtual_time has to be set to the date when the real billrun on production will be executed. Once that’s done, the billrun can be started.

We run billing monthly with pin_bill_day script which creates about 100.000 bills per hour. The script creates bills for accounts where the billing date is any day before midnight of the day we run billing. So what does pin_billd_day script actually do? It runs the following billing utilities:

• pin_deferred_act: Executes deferred actions; for example, if an account should become inactive, this utility performs the status change on the scheduled date.
• pin_bill_accts: Calculates the balance due for accounts and creates a bill for the balance due.
• pin_collect: Collects the balance due for accounts that use credit cards and directs debit payment methods.
• pin_refund: Finds accounts that have refund items and makes online refund transactions.
• pin_inv_accts: Creates an invoice for each account that is billed.
• pin_cycle_fees: Applies the cycle forward fee balance impact to the customer’s account and cancels products that have an expired pending cancellation date.

To verify the progress and performance of the pin_bill_day script, we run queries against the database to get information on how many bills are done, how many are yet to be done, if there are any bills with errors, etc.

After the brm billing part is over and all the bills are created, invoicing starts. After the invoices are created, they are exported to XML documents, which are then converted into PDF format.

Besides the queries mentioned earlier, there are also other queries that need to be executed once billing and invoicing have finished, in order to verify the accuracy of the data generated by this process. We execute a batch of queries; here are some of them:

• Has billing failed?

select * from billinfo_t where billing_state = 4 and bill_info_id<>’Bill Unit(1)’;

–Expected results: No rows found

• Are there any unbilled accounts?

select poid_id0, first_name,last_name,a.status from account_t a, account_nameinfo_t an where

a.poid_id0=an.obj_id0 and

created_t<<bill_cycle_end_date> and

not exists (select b.account_obj_id0 from bill_t b

where end_t=<bill_cycle_end_date> and

b.account_obj_id0=a.poid_id0);

–Expected results: No rows found

• Are there any bills without a bill number?

select * from bill_t where end_t=<bill_cycle_end_date> and bill_no is null;

— Expected: No rows found

Any problems found are then investigated and fixed through the versioning control system, where fixes are later included in the next release version.