1. Patch Set Release Notes
  2. New Features in BRM

2 New Features in BRM

The Oracle Communications Billing and Revenue Management (BRM) 12.0 Patch Sets include many new features.

Topics in this document:

New Features in BRM 12.0 Patch Set 8

BRM 12.0 Patch Set 8 includes the following enhancements:

BRM Supports Flexible Proration Options

In previous releases, you could configure time stamp rounding only at a systemwide level by using the timestamp_rounding entry in the CM pin.conf file. You could specify that all time stamps were either:

  • Rounded to midnight. This meant that product validity periods started at midnight, even if it was purchased later in the day. In this case, purchases of recurring deals would be valid starting at midnight, causing any delayed usage that occurred between midnight and the purchase time to be incorrectly consumed from the new grant.

  • Set to the purchase time. This meant that charges had to be prorated for the first day of the billing cycle. For example, if a product was purchased at 15:00 for a 30-day billing cycle, the customer was charged for 29 days and 9 hours.

To make proration more flexible and to avoid any balance validity or charging issues, BRM now allows you to create a product with separate time stamp rounding values for the following:

  • The validity period: You can specify that the validity period starts at the purchase time or at midnight of the day the product is purchased. Alternatively, you can specify to use the systemwide setting in the CM pin.conf file.

  • The charging scale: You can specify whether to charge for a full day or a partial day for the first day of the billing cycle. That is, if a product is purchased at 15:00 on 5 May, the customer can be charged for a full day or 9 hours for 5 May. Alternatively, you can specify to use the validity period setting.

You can configure the proration settings by using the loadpricelist utility or the PCM_OP_PRICE_SET_PRICE_LIST opcode.

To configure proration settings using an XML file and the loadpricelist utility, set these new XML elements under the <product> element:

  • <offer_validity_rounding>: Specifies whether to start the product's validity period at the purchase time or at midnight of the purchase day.

    • OFF: Starts at the time of purchase. This overrides the CM pin.conf setting at the product level.

    • ON: Starts at midnight (00:00:00) of the day that the product is purchased. This overrides the CM pin.conf setting at the product level.

    • NOT_SET: Uses the systemwide setting in the CM pin.conf file. This is the default.

  • <scale_rounding>: Specifies whether to charge for a full day for the first day of the recurring cycle:

    • OFF: Calculate it based on the <offer_validity_rounding> setting.

    • ON: Calculate it based on full days.

To configure proration settings using the PCM_OP_PRICE_SET_PRICE_LIST opcode, set the following input flist fields:

  • PIN_FLD_OFFER_VALIDITY_ROUNDING: Specify whether to start the product's validity period at the purchase time or at midnight of the purchase day:

    • 0: Not Set. Uses the systemwide setting in the CM pin.conf file. This is the default.

    • 1: On. Starts at midnight (00:00:00) of the day that the product is purchased. This overrides the CM pin.conf setting at the product level.

    • 2: Off. Starts at the time of purchase. This overrides the CM pin.conf setting at the product level.

  • PIN_FLD_SCALE_ROUNDING: Specify whether to charge for a full day for the first day of the recurring cycle:

    • OFF: Calculate it based on the PIN_FLD_OFFER_VALIDITY_ROUNDING setting.

    • ON: Calculate it based on full days.

For more information, see "Setting Full Day Proration" in BRM Pipeline Rating and Discounting.

Support for Conversion to Wholesale Hierarchy

You can now convert an existing hierarchy (with a paying parent account and non-paying child accounts) into a wholesale hierarchy. As part of this feature, a new multithreaded application (pin_cust_convert_wholesale_hierarchy) and a new opcode (PCM_OP_CUST_CONVERT_WHOLESALE_HIERARCHY) are introduced to perform the conversion. See "Converting Existing Bill Unit Hierarchies to Wholesale Billing" in Configuring and Running Billing for more information.

Sharing Groups Now Support Multiple Schemas

By default, all members of a sharing group must reside in the same database schema. To include a member from a different schema, you must first migrate the member to the same schema as all other members of the sharing group.

You can now enable the following sharing groups to include members from multiple schemas:

  • Charge sharing groups (/group/sharing/charges)

  • Discount sharing groups (/group/sharing/discounts)

  • Profile sharing groups (/group/sharing/profiles)

  • Product sharing groups (/group/sharing/products)

To do so, enable the CrossSchemaSharingGroup business parameter in the system instance of the /config/business_params object. See "Enabling Group Members to Reside in Multiple Schemas" in BRM Managing Customers for more information.

Discount Offer Stacking Support

Previously, when a discount was purchased a second time, it was treated as separate from the original purchase. It is now possible to extend the validity of a discount subscription by purchasing the discount multiple times. You can also define a grace period for resubscribing to a discount offer.

You can change the handling for discount repurchases using the field PIN_FLD_MODE under /deal/discounts. The available values for this field are:

  • PIN_SUBS_PURCHASE_DEFAULT = 0 (This is the default value if not set.)
  • PIN_SUBS_PURCHASE_LONGEST_DATE = 1
  • PIN_SUBS_PURCHASE_EXTEND = 2
  • PIN_SUBS_PURCHASE_OVERWRITE = 3

You can set the grace period using the new PIN_FLD_GRACE_PERIOD field. This field has the following attributes:

  • PIN_FLD_GRACE_PERIOD_UNIT
  • PIN_FLD_GRACE_PERIOD_OFFSET

If the re-purchase of the offer is done within the defined grace period and the PIN_SUBS_PURCHASE_OVERWRITE mode is not in effect, then the same /purchased_discount instance will be extended. Otherwise, the normal purchase flow is followed.

For more information, see "Purchasing the Same Product or Discount Multiple Times" in BRM Configuring Pipeline Rating and Discounting.

Pre-Expiry/Post-Expiry Notification Support

When setting up your system to send messages to customers through an external notification application when triggering events occur in BRM, you can now:

  • Specify whether customers are automatically opted in to receive a specific notification message type.

  • Configure BRM to generate notification events a set amount of time before or after a service lifecycle state changes.

  • (For in-advance and post-expiration notifications only) Specify whether to aggregate multiple events for the same notification type into one notification message for the customer.

For information, see "Sending Messages to Customers through External Notification Applications" in BRM Managing Customers.

Kafka DM Enhancements

You can now run the Kafka DM in one of these modes:

  • Asynchronous mode: The Kafka DM records in a log file all business events that fail to publish to the Kafka server. You configure the name and location of the log file using the <KafkaAsyncMode> element in the BRM_home/sys/dm_kafka/log4j2.xml file. Asynchronous mode is the default.

  • Synchronous mode: When a business event fails to publish to the Kafka server, the Kafka DM rolls back the transaction and returns an error to BRM.

You define the Kafka DM mode using the BRM_home/sys/dm_kafka/dm_kafka_config.xml file. For more information, see "About the Kafka DM" and "Editing the dm_kafka_config.xml File" in BRM Developer's Guide.

You can now also configure BRM to replace dynamic keys in message payloads with a value you specify in the PCM_OP_PUBLISH_POL_PREP_EVENT policy opcode. For more information, see "Configuring the Dynamic Key Value" in BRM Developer's Guide.

Real-time Balances from ECE Available As a SOAP Web Service

The PCM_OP_BAL_GET_ECE_BALANCES opcode, which returns real-time balances for a service from ECE, is now exposed as a SOAP Web Service via BRM Web Services Manager.

For more information, see "About WSDL Files and BRM Opcodes" in BRM Web Services Manager.

Price-tag-based Price Override Support in REST Services Manager

BRM REST Services Manager now supports price-tag-based price overrides. Multiple date-range-based price overrides can be passed as part of the automatic offer and service bundle creation.

Two-phase Billing Support in REST Services Manager

BRM REST Services Manager now supports two-phase billing. Multiple date-range-based price overrides can be passed as part of atomic offer and service bundle creation. The initiate and fulfill actions can be sent as two separate orders. The service will be created as part of the initiate order and will be activated as part of the fulfill order.

BRM Supports Two-Way SSL Authentication

You can now set up two-way SSL authentication between the database and the on-premise and cloud native deployment versions of the following: BRM, BRM REST Services Manager, Pipeline Configuration Center (PCC), Pricing Design Center (PDC), Business Operations Center, and Billing Care.

Rated Event Manager Support for CDR Streaming

The Rated Event Manager now supports streaming events to and from Kafka. This enables near-real-time reporting of rated event data and makes rated event data available for consumption from Apache Kafka by third party systems as well as by BRM. See "Event Streaming Mode (Patch Set 8 or later)" in Loading Rated Events for more information.

New Features in BRM 12.0 Patch Set 7

BRM 12.0 Patch Set 7 includes the following enhancements:

Promise-to-Pay Enhancements

Customers can now pay off bills that are in collections through multiple promise-to-pay installments. The installment schedule and amount can be set up automatically by Collections Manager or manually according to the customer.

You can now also configure whether credit limits are automatically increased when an account enters a promise-to-pay agreement and then decreased when the amount due is paid off.

For information, see "Managing Promise-to-Pay Agreements" in BRM Collections Manager.

Balance Impact Stores Current Balance of Resources

BRM now stores the current balance and available loan balance in events. This allows CSRs to look up a customer’s available balance at the time of a particular transaction.

The main balance and available loan balance are recorded for both currency and non-currency resources, and for both debit and credit balance impacts.

Support for Setting Credit Floor Dynamically

BRM now allows for setting the credit floor dynamically from the granted sub-balance amounts that are valid for the current cycle. This allows BRM to set the credit floor automatically when customers are granted limited-time resources.

For example, assume you grant a subscriber 10 GB of data using a cycle fee. When the subscriber purchases a booster pack of 5 GB that is valid only during the current cycle, BRM sets the credit floor to 15 GB for the current cycle and then reverts it to 10 GB at the start of the next cycle.

A new field, PIN_FLD_DYNAMIC_CREDIT_FLOOR, has been added to the /config/credit_profile and /event/billing/limit objects to support this functionality.

For more information, see "Setting a Dynamic Credit Floor" and "Enabling Dynamic Credit Floors in Plans" in BRM Configuring Pipeline Rating and Discounting.

First Usage Activation Enhancements in BRM

You can now configure a deal or a plan to start on first usage without having to configure each product and discount in the deal or plan to start on first usage. When you use this option, the first usage of any product will activate all of the products in the deal or plan.

You can implement the first usage activation feature by using an XML file and the loadpricelist utility. See "Activating Products in Plans and Deals on First Usage" in BRM Configuring Pipeline Rating and Discounting for more information.

Note:

You can also use PDC to configure first usage activation in bundles and packages. See "First Usage Activation Enhancements in PDC".

Balance Monitoring Enhancements

BRM now supports a truly real-time balance monitoring group type: payment responsibility real-time credit enforcement (PR_RTCE). Its members include nonpaying child accounts and their services. PR_RTCE also allows you to change the credit limit settings for the group's owner and members to do the following:

  • Roll up the credit limits from one or more child bill units in the group to the owner's bill unit. For example, assume a group's owner has a $1000 credit limit and the three child group members each have $100 credit limits. If you specify to roll up the credit limits of all three child group members, the group owner's credit limit would change to $1300.

  • Nullify a child's credit limit after it is rolled up to the owner. If you specified to nullify the credit limits in the previous example, BRM would change the credit limit for all three child group members to NULL. If you specified to maintain the credit limits, BRM would keep the credit limit for all three child group members at $100.

For more information, see "Managing Balance Monitoring Groups" in BRM Managing Customers.

Support for Add-On Products in Deals

When you create your price list using the XML Pricing Interface, you can now include add-on products in your deals. All products in deals are base products by default, which means they are automatically included when the customer purchases the deal. Add-on products can be purchased with the deal or later on.

When you create an add-on product, you also specify how to determine its validity start date. The add-on product's validity start date is the end date of a product that you specify. For example, assume product A has a validity period from June 1 through June 15. If you specify to align add-on product B's validity period with product A, product B's validity start date would be June 15.

You can specify that an add-on product's validity dates align with:

  • The base product that you specify

  • The active base product that expires first

  • The active base product that expires last

  • The active product that expires first

  • The active product that expires last

For more information, see "Configuring Add-On Products in Deals" in BRM Configuring Pipeline Rating and Discounting.

Sharing Group Improvements

BRM now supports product sharing groups, which allow a group owner to share a package with all group members automatically. This allows you to change rates once at the group owner level, rather than having to change each of the subscriber accounts.

You can also automate discount sharing in a similar way. You can share discounts at the top level of the hierarchy, with multiple billing accounts at lower levels sharing in the discount. When members are added to the hierarchy, they can be automatically added to the parent group account's discount sharing group.

If the parent account is removed from the hierarchy, all of its member accounts are automatically removed from the hierarchy, and therefore from the discount sharing.

For more information, see "Managing Product Sharing Groups and Discount Sharing Groups" in BRM Managing Customers.

Notifications Can Be Triggered After Event Occurrence

BRM can now send notifications after the due date for the following business events:

  • PostBalanceExpiry
  • PostBillDue
  • PostProductExpiry
  • PostSubscriptionRenewalDue
  • PostCollectionsActionDue
  • PostInstallmentDue

This allows you to remind customers to, for example, renew an expired subscription or pay a bill that is one week past due.

For more information, see "Sending Messages to Customers through External Notification Applications" in BRM Managing Customers.

Proration Can Be Configured at the Product Level

Previously, you configured proration at the system-wide level. Now, you can also configure in deals whether a product is prorated based on 30 days or on the actual number of days in the month.

You implement proration at the product level by using an XML file and the loadpricelist utility. For more information, see "Setting Proration for Products in a Deal" in BRM Configuring Pipeline Rating and Discounting.

Improvements to Tax Handling for Bill Disputes

When a partial payment has been made on an account, and a dispute is raised for the remaining amount, it is now possible to avoid charging taxes on the disputed amount.

In the case of tax-only billing disputes, the dispute can be raised against a specific amount of tax, rather than needing to use a percentage.

Secure Communication to the BRM Database

TLS and SSL encryption is now supported between all BRM components and the BRM database, including all Data Managers, ECE, PDC, Business Operations Center, Pipeline Configuration Center, Rated Event Loader, and Rated Event Manager.

Running Stored Procedures in BRM

You can now run BRM stored procedures or your custom stored procedures against the BRM database.

For information, see "Running Stored Procedures" in BRM System Administrator's Guide.

New Features in BRM 12.0 Patch Set 6

BRM 12.0 Patch Set 6 includes the following enhancements:

Support for PINless Debit Payment Processing

BRM can now support PINless debit payment transactions. To enable this functionality, you set the new PINlessDebitProcessing business parameter.

For more information, see "Configuring PINless Debit Payment Processing" in BRM Configuring and Collecting Payments.

Kafka DM Enhancements

The Kafka DM includes the following enhancements:

  • You can now enable secure communication between the Kafka DM and the Kafka Server.

  • You can now customize the PCM_OP_PUBLISH_POL_PREP_EVENT policy opcode to look up or provide delivery identifiers for delivery methods, such as the email address for an email delivery method.

  • For each Kafka topic that you define, you can now specify to:

    • Use one of two new styles for messages sent in XML format: CamelCase and OC3CNotification.

      Note: The Notification XML style has been deprecated.

    • Add headers to each message sent to a Kafka topic.

    • Write business events in a separate message payload.

    • Specify the key value passed in a message or payload.

    • Override the default mapping between a BRM flist field and an XML or JSON element. This can be done at the topic level or the payload level.

To support this new functionality, the dm_kafka_config.xml configuration file has been updated to XML version 2.0. See "Mapping Business Events to Kafka Topics" in BRM Developer's Guide.

For more information about the Kafka DM, see "About Integrating BRM with an Apache Kafka Server" and "Configuring BRM to Publish Notifications to Kafka Servers" in BRM Developer's Guide.

BRM Notification Enhancements

When configuring your system to send messages to your customers through an external notification application, such as Oracle Communications Convergent Charging Controller, you can now:

  • Send messages when the following A/R actions occur: a payment method changes, a payment is successfully processed, a refund is issued, an auto-payment fails, and a payment is reversed.

  • Generate notifications in-advance for collections actions and installments.

  • Create custom delivery methods.

  • Prevent messages from being sent to your customers on certain days of the year (called silent days).

  • Add rollover details to /event/notification/subscription/renewal notification events before they are sent to the Kafka DM.

In addition, you now specify how long after the delivery time that messages can still be delivered to your customers by using the AcceptableDelayTime business parameter. In previous releases, you set this value by using the acceptable_delay_time parameter in the CM pin.conf file and pin_gen_notifications pin.conf file.

For more information, see "Sending Messages to Customers through External Notification Applications" in BRM Managing Customers.

BRM Supports Temporary Credit Limits

When creating or modifying an account, you can now add temporary credit limits to a customer's balance of minutes, US dollars (USD), or so on. For example, you could add a temporary credit limit of 400 USD that is valid from 1 November 2022 through 1 January 2023.

If a customer has both a permanent credit limit and a temporary credit limit for the same balance element, the temporary credit limit amount is appended to the permanent credit limit amount. For example, if a customer has a permanent credit limit of $100 and a temporary credit limit of $200 from 1 June 2023 through 1 July 2023, the customer's credit limit would be $300 from 1 June 2023 through 1 July 2023.

You implement temporary credit limits in your custom client applications by using BRM opcodes. For more information, see "Customizing Credit Limits and Sub-Balance Consumption Rules" in BRM Opcode Guide.

Customer Deposits

You can create and manage customer deposits for devices, services, packages, or accounts. As part of this feature, you can:

  • Create deposit specification profiles and deposit specifications, which define the underlying rules and properties for customer deposits. You can create these in Billing Care or by using the PCM_OP_DEPOSIT_CREATE_SPECIFICATION_PROFILE and PCM_OP_DEPOSIT_CREATE_SPECIFICATION opcodes.

  • Create deposits for individual customers using either Billing Care or the PCM_OP_DEPOSIT_PURCHASE_DEPOSIT opcode with a custom client application. Before they can make a deposit, customers purchase a package or bundle containing a charge offer that has a purchase deposit event mapped to the charging rule of the deposit.

  • Update, transfer, reverse, release, and refund deposits.

For more information, see "Managing Deposits" in BRM Managing Customers.

Loan Management Enhancements

Loan management contains the following enhancements:

  • Customers can choose to opt in to or out of receiving loans.
  • You can offer loans to customers who have opted in when their balance crosses specified thresholds, rather than automatically granting loans to all customers.
  • Customers can purchase entire packages using loans, without impacting their current account balance.
  • You can configure:
    • Thresholds for offering loans at the package level for all customers, and at the individual customer level.
    • Due dates for loan repayment.
    • What happens when the loan isn't repaid in time.
    • What to do if a top-up doesn't cover the full amount due.
    • The maximum number of active loans a customer can have.
  • Loan balances are now tracked and managed as separate sub-balances from other types of balances.

For more information, see "Configuring Loans" in BRM Configuring and Collecting Payments and "Loan Opcode Workflows" in BRM Opcode Guide.

BRM Can Now Track Failed Operations

BRM operations may occasionally fail to process completely. For example, a payment could fail due to an insufficient balance or an incorrect account address. You can now configure BRM to store information about multithreaded application (MTA) utilities and custom client applications that fail, so you can view them for analysis and reporting, or reprocess them at a later time. For more information, see "About Tracking Failed BRM Operations" in BRM System Administrator's Guide.

To configure MTA utilities to record failed operations, see "Configuring MTA Utilities to Record Operation Failures" in BRM System Administrator's Guide.

To configure a custom client application to record and retrieve failed operations, see "Managing Operation Failure Records" in BRM Opcode Guide.

Cloud Native Support for SSO

You can now set up a single sign-on (SSO) login method using SAML 2.0 for the following applications in a BRM cloud native environment:

Exposing Charge and Tax Details for Payments and Adjustments

You can now configure BRM to track how much tax is being settled as a part of a payment. If you configure this feature, the /item object contains the settled tax amount, the settled taxed amount, and the settled nontaxed amount. This feature supports using the tax percentage in the original event to calculate the tax amount during adjustments. See "Configuring Itemized Tax Information" in BRM Calculating Taxes for more information.

Support for More Granular Tax Code Application

You can now configure tax selectors and tax exemption selectors to apply taxes based on account, service, event, and profile attributes. This allows you to choose whether to use the direct tax code or to choose the tax code using the selectors in the rate plan while creating the product. See "About Calculating Taxes" in Calculating Taxes for more information.

New Features in BRM 12.0 Patch Set 5

BRM 12.0 Patch Set 5 includes the following enhancements:

Top-Up Enhancements

Top-up payments have been enhanced to support:

  • Cash and check payment methods

  • Recurring standard top-ups

  • Topping up noncurrency resources, such as minutes, tokens, or Gigabytes

    To be able to top-up noncurrency resources, you must do the following:

    • Add the following line to your BRM_home/sys/data/pricing/example/pin_rum file and then load it into the database using the load_pin_rum utility: 

      /event/billing/topup : Topup_Charge : PIN_FLD_TOPUP_RESOURCE_INFO.PIN_FLD_TOPUP_AMT : none

    • Add the following line to your BRM_home/sys/data/pricing/example/pin_usage_map file and then load it into the database using the load_usage_map utility: 

      /event/billing/topup : Topup : 0: 0: 0: 0: 0: 0: 0: topup_charge

    • Add the following line to your BRM_home/sys/data/pricing/example/pin_event_map file and then load it into the database using the load_event_map utility: 

      /account : /event/billing/topup : Topup Charge Event

For more information, see "Configuring Top-Ups" in BRM Configuring and Collecting Payments.

You implement this new top-up functionality in your custom client applications by calling BRM opcodes. For more information, see "Managing Top-Ups" in BRM Opcode Guide.

Loan Management

You can grant loans to prepaid customers when their credit is insufficient for rating (dynamic loans), or when their balance falls below a configured threshold (automatic loans).

For more information, see "Configuring Loans" in BRM Configuring and Collecting Payments.

You implement loan functionality in your custom client applications by calling BRM opcodes. For more information, see "Loan Opcode Workflows" in BRM Opcode Guide.

New Bill States

All /bill objects now include the PIN_FLD_STATE field, with the following possible values:

  • UNDEFINED
  • INPROGRESS
  • NEW
  • PARTIALLYPAID
  • SETTLED
  • ONHOLD
  • SENT
  • VALIDATED

BRM automatically sets the bill state to INPROGRESS, NEW, PARTIALLYPAID, or SETTLED as part of the bill life cycle.

You can submit requests to the Update a Customer Bill BRM REST Service Manager API endpoint to update the bill state from INPROGRESS to ONHOLD, then from ONHOLD back to INPROGRESS.

All bills created before applying patch set 5 have the state set to UNDEFINED. You can optionally set them to the other applicable states by using a stored SQL procedure.

For more information, see:

Sample Prepaid Service Life Cycle

The default config_lifecycle_states.xml file, which defines states for a sample prepaid service life cycle, contains a new lifecycle state: 109 (SuspendedActive).

Note:

If your existing state-to-status mapping uses the 109 lifecycle state, you will need to introduce a new macro and recompile the code.

For more information, see "About the Sample Prepaid Service Life Cycle" in BRM Managing Customers.

XML Price List Enhancements for BRM

BRM now supports the following enhancements when you define your price lists in XML and upload them using the loadpricelist utility:

  • Setting a grace period when purchasing the same product multiple times: When creating products, you can specify what happens if customers purchase the same product more than once.

    See "Purchasing the Same Product or Discount Multiple Times" in BRM Configuring Pipeline Rating and Discounting.

  • Granting noncurrency balances in increments: When you credit noncurrency balances, such as free minutes, in a one-time allotment or in a recurring cycle, you can choose to grant the noncurrency balance in smaller portions on an incremental basis. For example, a grant of 30 Gigabytes with a one-month validity could be distributed as 1 Gigabyte per day.

    See "Splitting Noncurrency Balances into Multiple Validity Periods" in BRM Configuring Pipeline Rating and Discounting.

  • Configuring how to apply cycle fees when customers transition from one plan or deal to another: When customers transition from one plan or deal to another in the middle of their billing cycle, BRM, by default, prorates the cycle fees for both the original and new plan or deal. You can now configure BRM to instead apply only the cycle fee for the original plan or deal, or apply only the cycle fee for the new plan or deal.

    See " Transitioning Plans and Deals" in BRM Configuring Pipeline Rating and Discounting.

  • Configuring how to apply cycle fees when customers change their billing day of month (DOM): When customers change their billing DOM in the middle of their billing cycle, a partial bill is created. For example, if the billing DOM is changed in June from the 15th to the 30th, a partial bill is created for June 15 through June 29. By default, BRM applies a prorated cycle fee to this partial billing cycle. You can now configure BRM to instead apply the full cycle fee or no cycle fee to the partial billing cycle.

    See "Prorating Fees for Billing DOM Changes" in BRM Configuring Pipeline Rating and Discounting.

  • Configuring cycle alignment for products in reactivated deals: When customers suspend and then reactivate a deal, you can specify when the cycle should align for products in the deal. By default, the cycle aligns with either the billing date or the original purchase date, but you can specify that it instead aligns with the reactivation date.

    See "Setting Product Cycle Alignment for Reactivated Deals" in BRM Configuring Pipeline Rating and Discounting.

  • Specifying whether to stop or continue rating inactive, canceled, or SuspendedActive accounts: When you create a rate, you can specify whether BRM should continue charging or stop charging accounts that have an Inactive status, a Cancelled status, or a SuspendedActive custom life cycle state.

    See "Stop Rating Inactive, Canceled, or SuspendedActive Accounts" in BRM Configuring Pipeline Rating and Discounting.

Rerating Noncurrency Resources When Products are Canceled

You can now configure BRM to automatically create rerate jobs when a product with noncurrency resources is canceled. To do so, you use the new CreateRerateJobDuringCancel business parameter.

For more information, see "Creating Rerate Jobs for Canceled Noncurrency Resources" in BRM Reraring Events.

Options for Exceeding Credit Limits

You can now specify what happens to subscriptions when customers exceed their credit limits.

You can prevent customers from exceeding their credit limit and either prorate the resources according to the available balance, or fail the subscription and notify an external system for further processing.

You can allow customers to exceed their credit limit and:

  • Use all available balance and record the remaining amount as an outstanding amount.
  • Use all available balance and grant a loan for the remaining amount.
  • Leave the available balance and record the entire amount as an outstanding amount.
  • Skip billing for this cycle.

You can configure this in the PDC UI or using the loadpricelist utility. For more information, see "Allowing Customers to Exceed Their Credit Limit" in PDC Creating Product Offerings and "Allowing Customers to Exceed Their Credit Limit" in BRM Configuring Pipeline Rating and Discounting.

New Residency Type to Support Distinct Searches

When searching for objects in the BRM database, because of the way row numbers are generated for complex searches, you cannot use pagination with the order by clause when PIN_FLD_FLAGS is set to perform a distinct search (256 or 768).

A new residency type (9 GLOBAL_DB_VIEW) lets you create custom storable classes and database views specifically for searching. These views create a flat structure for fields that are normally nested multiple levels within a storable class, without creating duplicate copies in the database. This allows you to search more effectively from only the required data, performing distinct searches with ordering and pagination.

See "About Performing Distinct Searches with Ordering and Pagination" in BRM Developer's Guide.

Customizing V$SESSION Table Details for dm_oracle and dm_ifw_sync

You can now customize the Oracle Data Manager (DM) and Account Synchronization DM to populate unique data in the V$SESSION table in the BRM database. This allows for unique classification and identification of BRM applications by properties set in their database sessions.

To customize the Oracle DM to populate data in the V$SESSION table, add the following entries to your BRM_home/sys/dm_oracle/pin.conf file: 

- dm vsession_module module
- dm vsession_action action
- dm vsession_client_info clientInfo
- dm vsession_client_id clientID

where:

  • module is the name of the module to run for a specific database session.

  • action is the name of the action to run for a specific database session.

  • clientInfo is the information for a specific database session.

  • clientID is the client identifier for a specific database session.

To customize the Account Synchronization DM to populate data in the V$SESSION table, add the following entries to your BRM_home/sys/dm_ifw_sync/pin.conf file: 

- dm_ifw_sync vsession_module module
- dm_ifw_sync vsession_action action
- dm_ifw_sync vsession_client_info clientInfo
- dm_ifw_sync vsession_client_id clientID

BRM Now Supports Dynamic Charging

You can now configure BRM to dynamically change the rate for one-time and recurring fees per customer based on the date.

For more information, see "Dynamically Changing One-Time and Recurring Fees Based on Date" in BRM Configuring Pipeline Rating and Discounting.

BRM Now Supports Dynamic Taxation

BRM now supports dynamic tax calculation, which defers tax calculation until the end of a billing cycle but calculates taxes using the tax rate at the time an event occurred. For example, if an account purchases a product on May 15 and has a billing date of May 30, BRM calculates the tax on May 30 using the tax rate from May 15. This provides the benefits of billing-time taxation while allowing you to change tax rates in the middle of a billing cycle. For more information, see "About Calculating Taxes" in BRM Calculating Taxes.

The way you configure tax codes has also changed in Patch Set 5. You now configure tax codes by doing the following:

  1. Editing the new BRM_home/sys/data/config/config_taxcodes_map.xml file.

  2. Running the load_config utility to load the tax codes into the /config/taxcodes_map object in the BRM database.

See "About Creating Tax Codes (Patch Set 5)" in BRM Calculating Taxes for more information.

Caution:

In Patch Set 5, you cannot use SyncPDC to synchronize tax codes from BRM to PDC. You must instead manually re-create the BRM tax codes in a PDC-compliant XML file and then load them into the PDC database. See "Moving Tax Codes to PDC".

Previously, you configured tax codes by editing the BRM_home/sys/cm/taxcodes_map file. You did not load the file into the database. Instead, BRM stored the contents of the taxcodes_map file in its cache.

When you install BRM 12.0 Patch Set 5, it enables the dynamic tax calculation option and starts reading tax codes from the /config/taxcodes_map object. You can disable dynamic taxation and continue using the BRM_home/sys/cm/taxcodes_map file to create tax codes by doing the following:

  1. Open the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf).

  2. Set the value of the dynamic_taxation entry to 1: 

    - fm_bill dynamic_taxation 1

    The default value of 0 enables the dynamic tax calculation option and requires tax codes to be stored in the /config/taxcodes_map object.

  3. Save and close the file.

  4. Stop and restart the CM.

BRM Now Supports Promotions Based on Special Dates, Events, and Actions

You can now apply promotions to your customers' accounts based on a special date, a specific event, or a specific action. For example, you could grant 100 free minutes to your customers when they successfully top up their account balance or on their membership anniversary.

For more information, see "Working with Promotions" in BRM Configuring Pipeline Rating and Discounting.

Sending Messages to Customers through External Notification Applications

You can now configure your system to send messages to your end customers through an external notification application, such as Oracle Communications Convergent Charging Controller, when a triggering event occurs in BRM. See "About Sending Messages to Customers through External Notification Applications" in BRM Managing Customers.

pin_inv_doc_gen Now Uses JDBC

The pin_inv_doc_gen utility now uses JDBC rather than JNDI for connecting to the BI Publisher database.

In addition, the utility's Infranet.properties file (BRM_home/apps/pin_inv_doc_gen/Infranet.properties) includes the following new entries for configuring the connection pool:

  • infranet.schedulerdb.url: Specifies the scheduler database URL in the following format: 

    jdbc:oracle:thin:hostname:port/service

    where hostname is the hostname of the scheduler database, port is the port number for the scheduler database, and service is the service name of the scheduler database.

  • infranet.schedulerdb.user: Specifies the user name for the scheduler database.

  • infranet.schedulerdb.credentials: Specifies the security credentials for connecting to the scheduler database.

  • infranet.jdbcpool.size: Specifies the initial number of connections maintained in the pool. The default is set to the same as burst.threadpool.size.

  • infranet.jdbcpool.maxsize: Specifies the maximum number of connections that can be created. The default is set to the same as burst.threadpool.maxsize.

For more information, see "Configuring the pin_inv_doc_gen Utility" in BRM Designing and Generating Invoices.

BRM Cloud Native Enhancements in Patch Set 5

BRM cloud native deployments include the following enhancements in BRM 12.0 Patch Set 5:

  • PDC cloud native services have moved to WebLogic Kubernetes Operator (WKO). This allows PDC to use WKOs features such as provisioning, lifecycle management, application versioning, product patching, scaling, and security. It also enables the use of tooling that is native to the WKO infrastructure for monitoring, logging, tracing, and security. For more information, see "Configuring Pricing Design Center" in BRM Cloud Native Deployment Guide.

  • Business Operations Center cloud native services include a new rcuArgs key for specifying the additional arguments to pass to the Repository Creation Utility (RCU) during the create operation. By default, the value is an empty string, but you can pass flags such as "-honorOMF" when the connected database system uses OMF to manage tablespace files. For more information, see "Adding Business Operations Center Keys" in BRM Cloud Native Deployment Guide.

  • To simplify the deployment of test and demonstration systems, BRM cloud native now includes a new uniform role key that allows you to set the DBA user role for all BRM services at once. For more information, see "Configuring Global Values" in BRM Cloud Native Deployment Guide.

New Features Supported by BRM REST Services Manager

You can now use BRM REST Services Manager to make additional TM Forum based REST requests.

BRM REST Services Manager supports the following capabilities of the TM Forum API specifications:

  • TMF 654: Prepay Balance Management API:
    • Retrieving balance actions, top-up balances, and transfer balances.
    • Creating buckets (balance groups), top-up balances, and transfer balances.
    • Updating bucket thresholds for accounts.
    • Limiting and offsetting results when retrieving buckets
  • TMF 666: Account Management API: Listener endpoints for creating and updating accounts based on notification events.
  • TMF 678: Customer Bill Management API: Updating the bill state of a customer bill from inProgress to onHold and from onHold to inProgress.
BRM REST Services Manager now also supports:
  • Using numbers in addition to BRM IDs for accounts, bills, bill item, adjustments, and disputes in certain endpoints.
  • As an extension, including originalBalance values for accumulated balances and buckets.
  • Monitoring for on-premises deployments of BRM REST Services Manager using Prometheus and Grafana. See "Monitoring BRM Components" in BRM System Administrator's Guide.

For more information, see REST Services Manager API for Billing and Revenue Management.

New Method for Loading Rated Events from ECE into BRM

The Rated Event Manager, a new method of loading rated events from Elastic Charging Engine (ECE) into BRM, has been added. This method includes four different operation modes. The primary reason for the new functionality is to allow rated events to be loaded directly into the BRM database without requiring an intermediate shared file store, although optimized modes using file stores are also included.

The modes of the new method are:

  • DIRECT: This mode loads the data directly from ECE into the regular tables in the BRM database. This is the most direct method, but it uses more bandwidth than the ZIP_DB option.
  • ZIP_DB: This mode creates a ZIP file and stores it in the /batch/rel object in the database, where a BRM process loads it into the regular tables.
  • ZIP_FILE: This mode compresses the CDRs in a transaction into a single file before transferring it to an intermediate file system where it is picked up by BRM.
  • CDR: This mode is similar to the original method. It transfers individual files to an intermediate file system, where they are picked up by BRM. You might choose this method if you want to read or perform some action on the files before they are picked up by BRM.

For more information about the methods of loading rated events, see "Methods of Transferring Rated Events to BRM" in BRM Loading Rated Events.

The RE Manager also includes a utility, rel_manager, some of which can be used even if you are not using the RE Manager. For more information about this utility, see "Rated Event Loader Manager Utility" in BRM Loading Rated Events.

For more information about configuring this feature, see "Configuring Rated Event Manager" in BRM Loading Rated Events.

New Features in BRM 12.0 Patch Set 4

BRM 12.0 Patch Set 4 includes the following enhancements:

BRM Cloud Native Enhancements in Patch Set 4

BRM cloud native deployments include the following enhancements in BRM 12.0 Patch Set 4:

To simplify the deployment of test and demonstration systems, BRM cloud native now includes:

  • A new uniform password key, named uniPass, that allows you to set the password for all BRM services at once. See "Configuring Global Values" in BRM Cloud Native Deployment Guide.

  • New isEnabled keys for enabling or disabling each BRM service in your cloud native deployment. See "Specifying the BRM Services to Deploy" in BRM Cloud Native Deployment Guide.

To improve system and application performance, BRM cloud native now allows you to:

To make it easier to navigate and find information in the BRM cloud native documentation, the BRM Cloud Native Installation and Administration Guide has been replaced with two separate books:

Monitoring BRM Components

You can now monitor the following BRM components by using external applications, such as Prometheus and Grafana:

  • Connection Manager (CM)

  • Oracle Data Manager (DM)

  • Account Synchronization DM

  • Synchronization Queue DM

  • BRM Java applications, such as Batch Controller and REL Daemon

  • Web Services Manager

For more information, see "Monitoring BRM Components" in BRM System Administrator's Guide.

BRM Now Supports ASC 606/IFRS 15 Revenue Recognition

BRM now allows you to set up revenue recognition that complies with the Accounting Standards Codification (ASC) 606 and International Financial Reporting Standard (IFRS) 15 accounting standards. In BRM, this is called deliverable-based revenue recognition.

You set up deliverable-based revenue recognition by doing this:

  1. Enabling deliverable-based revenue recognition in BRM.

  2. Setting up your general ledger.

  3. Creating deliverables, which define the goods and services that you sell to your customers.

  4. Associating deliverables with your charge offers.

  5. Creating subscription terms, which define the commitment periods, cancellation options, and renewal options for your customers' contracts.

  6. Creating bundles and packages for the products and services that you sell.

  7. Associating your subscription terms with the bundles and packages that you sell to your customers.

When customers purchase your packages and accept the terms, the subscription becomes a contract. You manage your customers' contracts, such as modifying its renewal options or canceling a contract early, by using Billing Care. When their contracts reach the end of the commitment period, the contracts are either canceled or automatically renewed when you run the pin_contracts utility.

For more information about:

Deferring Corrective Bills and Invoices

Whenever you make an adjustment to a bill, you also generate a corrective bill and a corrective invoice. You can now defer generating the corrective bill and corrective invoice until after the next regular billing and invoicing period. To do so, you enable the new ARItemsInCorrectiveInvoice business parameter.

For more information, see "About Deferred Corrective Invoices" in BRM Designing and Generating Invoices.

BRM Supports Integration with Apache Kafka Servers

You can now integrate BRM with Apache Kafka Servers. This allows you to keep data synchronized between BRM and your external applications that are connected to the Kafka server. To synchronize account, pricing, and other data, BRM takes data from internal notification events and constructs a business event that is published to a topic in your Kafka server. Your external applications can then retrieve and process the data from the Kafka topic.

You integrate BRM with a Kafka server and configure it to publish data to the Kafka server by using the Connection Manager (CM), the Enterprise Application Integration (EAI) framework, and the new Kafka Data Manager (DM).

For more information about this feature, see "About Integrating BRM with an Apache Kafka Server" in BRM Developer's Guide.

Upgrading from BRM 12.0 Patch Set 4

If you are an existing customer upgrading from BRM 12.0 Patch Set 4 to BRM 12.0 Patch Set 5, you install the Kafka DM on your system by following the instructions in "Installing the Patch Set" in BRM Patch Set Installation Guide.

Upgrading from BRM 12.0, BRM 12.0 Patch Set 1, BRM 12.0 Patch Set 2, or BRM 12.0 Patch Set 3

If you are an existing customer upgrading from BRM 12.0, BRM 12.0 Patch Set 1, BRM 12.0 Patch Set 2, or Patch Set 3 to BRM 12.0 Patch Set 4 or later, you install the Kafka DM on your system by doing the following:

  1. Install the BRM 12.0 Patch Set 4 or BRM 12.0 Patch Set 5 overlay package (brmserver_12.0.0.x.0_platform_generic.jar) on top of your existing system by following the instructions in "Installing the Patch Set" in BRM Patch Set Installation Guide.

  2. Install the latest version of Apache Kafka. For instructions on downloading and installing Kafka, see "Apache Kafka Quickstart" on the Apache Kafka website.

    For the latest compatible software version, see "BRM Software Compatibility" in BRM Compatibility Matrix.

  3. Set the KAFKA_HOME environment variable to the path in which the Kafka library JARs are installed.

    setenv KAFKA_HOME Kafka_path

  4. Open the BRM_home/inventory/registry.xml file in an editor.

  5. Remove the existing BRMServer and CORE sections.

    For example, if your existing system is BRM 12.0 Patch Set 3, you would remove this BRMServer section from the file: 

    <feature status="installed" name="BRMServer" version="12.0.0.3.0">
   <sessions>
      <session id="1" date="2021-06-23T03:02:21.969-07:00"action="install"/>               
   </sessions>               
   <components>                  
      <component status="installed" name="BRMServer"version="12.0.0.3.0">                     
         <sessions>                        
            <session id="1" date="2021-06-23T03:02:21.969-07:00"action="install"/>                     
         </sessions>                     
         <targets>                        
            <target qualifier="filegroup1.jar+BRM"source="filegroup1.jar" symbol="brm.symbol" location="BRM"status="installed"> 
               <sessions>                              
                  <session id="1"date="2021-06-23T03:02:21.969-07:00" action="install"/>                           
               </sessions>                        
            </target>                    
         </targets>                  
      </component>               
   </components>            
</feature>

    You would also remove this CORE section from the file: 

    <feature status="installed" name="CORE" version="12.0.0.3.0">               
   <sessions>        
      <session id="1" date="2021-06-23T03:02:21.969-07:00"action="install"/>
   </sessions>               
   <components>                  
      <component status="installed" name="CORE"version="12.0.0.3.0">                     
         <sessions>                        
            <session id="1" date="2021-06-23T03:02:21.969-07:00"action="install"/>                     
         </sessions>                     
         <targets>                        
            <target qualifier="filegroup1.jar+"source="filegroup1.jar" symbol="root.symbol" location="" status="installed">         
               <sessions>                              
                  <session id="1"date="2021-06-23T03:02:21.969-07:00" action="install"/>                           
               </sessions>                        
            </target>                        
            <target qualifier="filegroup2.jar+oui"source="filegroup2.jar" symbol="oracle.nginst.core.symbol" location="oui"status="installed">
               <sessions>
                  <session id="1"date="2021-06-23T03:02:21.969-07:00" action="install"/>
               </sessions>                        
            </target>                     
         </targets>                  
      </component>               
   </components>            
</feature>

  6. Save and close the file.

  7. Follow the instructions in "Installing BRM" in BRM Installation Guide to install the BRM 12.0 Patch Set 4 or BRM 12.0 Patch Set 5 full build package (brmserver_12.0.0.x.0_platform_generic_full.jar), where x is 4 or 5.

    When the Installation Type screen appears during the installation process, select the Custom installation option to install individual components. In the Feature Sets Selection screen, select Kafka Data Manager 12.0.0.x.0 under Data Manager Framework. Figure 2-1 shows an example of the Feature Sets Selection screen for Patch Set 4.

    Figure 2-1 Feature Sets Selection

    Description of Figure 2-1 follows
    Description of "Figure 2-1 Feature Sets Selection"

    For more information, see "Installing Individual BRM Components" in BRM Installation Guide.

Integrating BRM with External Care Applications

You can now integrate BRM with external care applications by using the new BRM REST Services Manager. This integration allows you to manage customer accounts, bills, payments, and so on in an external care application while using BRM to do the rating and billing.

BRM REST Services Manager includes an API and an SDK. The BRM REST Services Manager API supports the following TMF API specifications:

  • TMF 666: Account Management API
  • TMF 678: Customer Bill Management API
  • TMF 676: Payment Management API
  • TMF 654: Prepay Balance Management API
  • TMF 635: Usage Management API

The BRM REST Services Manager SDK allows you to extend the framework to support additional API query parameters, payload extensions, and attribute extensions.

For information about:

Running Business Operations and BRM Applications from Custom Clients

You can now set up your custom client applications to run business operation jobs, such as billing and invoicing, or other BRM applications such as pin_virtual_time.

For more information, see "Setting Up Custom Clients to Run Business Operations" in BRM System Administrator's Guide.

Using Paymentech Card Type Indicator

The Paymentech Data Manager (dm_fusa) can now request and receive Card Type Indicator (CTI) version 02 information from Paymentech during the authorization process. CTI specifies the type of payment card that is being used by the customer, such as a prepaid card, Visa credit card, or MasterCard credit card. dm_fusa automatically supports sending and receiving CTI information in online transactions, but you need to customize dm_fusa to support CTI in batch transactions.

For more information, see "Obtaining Card Type Indicator Information from Paymentech" in BRM Configuring and Collecting Payments.

XML Product Offering Enhancements

BRM now supports the following enhancements when you define your product offerings in XML and upload them using the loadpricelist utility:

  • Creating extended attributes: You can create extended attributes for charge offers, discount offers, chargeshare offers, bundles, and packages. Extended attributes save extra information that may be useful to external applications. You create extended attributes while creating your pricing components. You can add custom validation using a policy opcode.

    Although BRM does not act on the extended attributes, the information is stored in the BRM database, and can be queried by external applications.

    See "Defining Extended Attributes for Pricing Components" in Configuring Pipeline Rating and Discounting.

  • Purchasing the same charge offer multiple times: When creating bundles, you can specify what happens if customers purchase the same charge offer more than once.

    See "Purchasing the Same Product or Discount Multiple Times" in Configuring Pipeline Rating and Discounting.

  • Applying recurring charges on a specific day of the month: When creating charge offers with hourly validity, you can apply recurring charges on a specific day of the month instead of the customer's billing date or the purchase date.

    See "Aligning Recurring Charges and Product Validity to a Specific Day of the Month" in Configuring Pipeline Rating and Discounting.

  • Using date ranges for versioning: When creating charge offers, you can add charges with new date ranges to create new versions of the same charge offer and determine whether existing subscriptions move to the new charge or continue with the old charge.

    Charge offers created before BRM 12.0 Patch Set 4 automatically use the existing functionality, where existing subscriptions move to the new charge. You can update the value of the new date_range_type field for the charge offers to change to the new versioning options.

    See "Using Date Ranges for Versioning" in Configuring Pipeline Rating and Discounting.

Note:

PDC also supports these enhancements with the ImportExportPricing utility. See "XML Examples of Pricing Components" and "Configuring Extended Attributes for Pricing Components" in PDC Creating Product Offerings.

BRM Supports Additional Cipher Suites

BRM now supports additional cipher suites. For more information, see "BRM-Supported Cipher Suites" in BRM System Administrator's Guide.

Web Services Manager Now Supports Oracle Access Manager 12.2.1.3.0

Web Services Manager now supports OAuth 2.0 authentication through Oracle Access Manager 12.2.1.3.0. There are also new procedures for setting up OAuth authentication through Oracle Access Manager.

For more information, see "Securing Web Services Manager with OAuth 2.0" in BRM Web Services Manager.

Support for TM Forum REST APIs

You can now use BRM REST Services Manager to make TM Forum based REST requests to manage accounts, bills, payments, refunds, balances, and usage in BRM.

BRM REST Services Manager supports the following TM Forum API specifications:

  • TMF 635: Usage Management API

    Retrieves usage information.

  • TMF 654: Prepay Balance Management API

    Retrieves bucket, accumulated, disputed, and adjusted balances. Creates adjusted and disputed balances.

  • TMF 666: Account Management API

    Retrieves billing cycle specifications (bill units and bill unit infos in BRM).

  • TMF 670: Payment Methods API

    Creates, retrieves, and deletes payment methods.

  • TMF 678: Customer Bill Management API

    Retrieves customer bills, rates, and invoices. Creates bills on demand.

  • TMF 676: Payment Management API

    Creates payments, retrieves payment information, and allocates payments to a bill. Creates refunds and retrieves refund information.

BRM REST Services Manager also supports extending the TMF REST framework with Oracle-specific query, request, and response attributes.

For more information, see:

New Features in BRM 12.0 Patch Set 3

BRM 12.0 Patch Set 3 includes the following enhancements:

BRM Cloud Native Deployment Enhancements

The BRM cloud native deployment now includes containers for the following BRM components:

  • BRM Apps Job

  • Billing Care REST API

  • Configurator Job

  • Database Upgrade

  • Elastic Charging Engine

  • Email Data Manager

  • Pipeline Configuration Center

  • Roaming Manager

  • Web Services Manager

Billing Care and Business Operations Center now support high availability through WebLogic Kubernetes Operator.

The BRM cloud native deployment also includes enhancements that allow you to:

  • Automatically pull images from a private Docker registry.

  • Automatically roll deployments by using annotations.

  • Expose a directory as a CM ConfigMap, so the BRM cloud native deployment can access your custom input files that are outside of a Pod.

  • Integrate Business Intelligence (BI) Publisher with the BRM cloud native deployment, so you can generate invoices for your customers.

  • Integrate BRM thick clients, such as Customer Center and Pricing Center, with the BRM cloud native deployment.

  • Integrate the BRM JCA Resource Adapter with the BRM cloud native deployment, so you can run BRM opcodes from outside of a Pod.

  • Make the CM the SSL endpoint for the BRM cloud native deployment. In this case, TLS can be enabled only between BRM client applications and the CM. TLS is disabled between CM and all downstream components such as DMs and EMs.

  • Build and deploy Vertex Manager.

  • Rotate the BRM root password regularly.

  • Use custom TLS certificates to secure connections between the BRM cloud native deployment and external service providers, such as payment processors and tax calculators.

  • Run BRM applications and utilities on demand without entering into a Pod.

  • Configure and run PDC utilities, such as SyncPDC and ImportExportPricing, without entering into a Pod.

  • Deploy Paymentech Data Manager (dm-fusa) in high-availability mode.

  • Use a centralized logging system through an Elasticsearch, Kibana, and Fluentd image stack.

  • Upgrade existing BRM cloud native deployments from 12.0 Patch Set 2 to 12.0 Patch Set 3.

  • Upgrade existing PDC cloud native deployments from 12.0 Patch Set 2 to 12.0 Patch Set 3.

For more information, see BRM Cloud Native Deployment Guide.

BRM Server, Thick Clients, and PCC Now Localized

BRM server, BRM thick clients such as Customer Center and Pricing Center, and Pipeline Configuration Center (PCC) are now available in localized versions. The following languages are supported: French, Italian, Spanish, Japanese, Korean, Chinese Simplified, Chinese Traditional, Russian, and Portuguese Brazilian.

Localized versions of the software are available in the full installer JAR files. For example, to install a localized version of the BRM thick clients, use the brmclients_all_12.0.0.3.0_generic.jar file.

Revenue Assurance Supports Custom Applications

You can now configure BRM to collect revenue assurance data from the following when they are run as part of a custom business operations job:

Pipeline Manager Can Now Support 28-Digit Decimal

You can now configure Pipeline Manager to support 28-digit decimal rather than the default of 15-digit decimal.

To configure Pipeline Manager to support up to 28-digit decimal, set the MAX28DIGIT_DECIMAL_SUPPORT environment variable to Y before you start Pipeline Manager and its services.

New Timeout Parameter for Account Synchronization DM

You can now specify the length of time, in milliseconds, that the Account Synchronization DM waits for a response from the database before timing out. To do so, you use the new database_request_timeout_duration parameter in the BRM_Home/sys/dm_ifw_sync/pin.conf file. See "Configuring Account Synchronization DM Database Connection Attempts" in BRM Installation Guide.

Support Added for AES Encryption

BRM now supports the AES encryption method for systems that have upgraded from BRM 7.5 to BRM 12.0 Patch Set 3. See "About AES Encryption" in BRM Developer's Guide.

Note:

The AES encryption method is supported for backwards compatibility only. Oracle recommends using the more secure OZT encryption method instead.

Enable SSL/TLS between Client and the CM Only

You can now enable SSL/TLS between clients and the CM only, while disabling SSL/TLS between the CM and DM/EM. To do so, run this command from the BRM_home/setup/scripts directory: 

perl sslConfig.pl 2  

For more information, see "Enabling or Disabling SSL/TLS for BRM Components" in BRM System Administrator's Guide.

Adjusting Taxes by a Specified Amount

With this enhancement, you can adjust the tax levied on an event by a specified amount, such as by 5 US dollars, or by a percentage, such as by 5%. See "Calculating Taxes for Accounts Receivable Actions" in BRM Calculating Taxes.

In previous releases, you could adjust the tax by a percentage only.

New Features in BRM 12.0 Patch Set 2

BRM 12.0 Patch Set 2 includes the following enhancements:

Deploying BRM Services on a Cloud Native Environment

BRM, Oracle Communications Pricing Design Center (PDC), Billing Care, and Business Operations Center now support their deployment on a cloud native environment, allowing you to harness the benefits of cloud with the services of BRM.

To deploy these BRM services, you use the new Oracle Communications BRM Cloud Native Deployment Option. This automates the deployment of BRM products and speeds up the process to get services up and running. Product deployments are preconfigured to communicate with each other through Helm charts.

For more information, see BRM Cloud Native Deployment Guide.

Wholesale Billing Enhancements

With this enhancement, the following are supported in wholesale billing:

  • The usage charges calculated by ECE and Pipeline Manager are also considered for wholesale billing.

    During billing, all the usage charges applied to the nonpaying child bill units (wholesale child accounts) are aggregated and rolled up to the paying parent bill unit (wholesale parent account). When rated events of the nonpaying child accounts are loaded into BRM, the /tmp_journals_to_process objects are created in BRM instead of the /journal objects. The /tmp_journals_to_process objects are created if deferred taxation is configured and the CycleTaxInterval business parameter is set to billing. See "Specifying How to Calculate Deferred Taxes for Wholesale Billing" for setting the CycleTaxInterval business parameter and the discussions about enabling and disabling taxation globally in BRM Calculating Taxes for configuring deferred taxation.

  • You can move child bill units into a wholesale hierarchy or move them out of a wholesale hierarchy even if there are pending charges or due amounts. The due amount of the child bill unit or the bill generated before moving the child bill unit is moved along with the child bill unit. You can generate invoice and apply the payment for that due amount after moving the child bill unit.

  • You can generate invoices for both paying parent bill unit and nonpaying child bill units.

    In the Summary of Current Charges section in the parent bill unit's invoice, you can view the sum of the service-level charges, taxes, and surcharges rolled up from the nonpaying child bill units as account-level charges. The adjustment details for the child bill units are not displayed in the parent bill unit's invoice as they are performed at account-level. However, the adjustments in the parent bill unit's invoice includes the sum of all the adjustments performed for the nonpaying child bill units.

    In the child bill unit's invoice, you can view the plan and account receivable (A/R) action details for that specific bill unit.

  • The /tmp_ar_item_to_roll_up objects are enabled for partitioning automatically.

    You can create the /tmp_ar_item_to_roll_up objects for wholesale billing in partitions and purge these objects from the database by using the partition_utils utility. When the partition_utils utility is run, the /tmp_ar_item_to_roll_up objects with the status as 1 (processed) are purged. You can run the partition_utils utility for the specific time interval.

Specifying How to Calculate Deferred Taxes for Wholesale Billing

You can specify how BRM calculates deferred taxes for wholesale billing by setting the CycleTaxInterval business parameter to billing.

When set to billing, the tax is forwarded from the child account to the parent account. BRM calculates taxes for the parent account only, but the single tax item on the parent account includes taxes from both the parent and child accounts.

To specify how to calculate deferred taxes for wholesale billing:

  1. Go to the BRM_home/sys/data/config directory, where BRM_home is the directory where you installed BRM components.

  2. Create an XML file from the /config/business_params object: 

    pin_bus_params -r BusParamsBilling bus_params_billing.xml

    This command creates the XML file named bus_params_billing.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_billing.xml.out file.

  4. Search for the following line:

    <CycleTaxInterval>accounting</CycleTaxInterval>

  5. Change accounting to billing. 

    <CycleTaxInterval>billing</CycleTaxInterval>

    Note:

    BRM uses the XML in this file to overwrite the existing billing 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 this file as bus_params_billing.xml.

  7. Load the XML file into the BRM database:

    pin_bus_params bus_params_billing.xml

  8. Stop and restart Connection Manager (CM).

  9. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Additional Card Security Presence Values Supported for Card Validation or Authorization

For credit card validations or authorizations, Paymentech Data Manager (dm_fusa) sends the Fraud Format Indicator (FR) or Product Record (PFR) record with the card security presence value. When the card security code (such as VISA CVV2) is present in the PIN_FLD_SECURITY input flist field, Paymentech DM sets the card security presence value to 1 and sends the FR or PFR record for validation by default.

With this enhancement, you can customize BRM opcodes to send other card security presence values (such as 9 (No Value)) in the input flist to Paymentech DM. You can use the PIN_FLD_AVAILABLE flist field to provide the card security presence value.

Note:

The PIN_FLD_AVAILABLE field can be used for both online and batch transactions.

Following are the enumerated names and values supported in the PIN_FLD_AVAILABLE field:

typedef enum pin_pymt_card_secid_presence {
 PIN_PYMT_CSP_BLANK = 0,
 PIN_PYMT_CSP_AVAILABLE = 1,
 PIN_PYMT_CSP_ILLEGIBLE = 2,
 PIN_PYMT_CSP_NOT_PROVIDED = 5,
 PIN_PYMT_CSP_NO_CSV = 9,
 } pin_pymt_card_secid_presence_t;

These names and values are defined in the BRM_home/include/ pin_pymt.h file.

You can customize the PCM_OP_PYMT_POL_PRE_COLLECT opcode to send PIN_FLD_AVAILABLE and PIN_FLD_SECURITY_ID in the input flist.

For credit card transactions, Paymentech Data Manager now does the following:

  • If only PIN_FLD_SECURITY_ID value is present in the input flist, Paymentech DM sends the FR or PFR record for validation with the card security presence value set to 1 (value present).

  • If both PIN_FLD_SECURITY_ID and PIN_FLD_AVAILABLE values are present in the input flist, Paymentech DM sends the FR or PFR record for validation with the card security presence value set to the PIN_FLD_AVAILABLE value.

  • If only the PIN_FLD_AVAILABLE value is present in the input flist, Paymentech DM sends the FR or PFR record for validation with the card security presence value set to the PIN_FLD_AVAILABLE value.

  • If both PIN_FLD_SECURITY_ID and PIN_FLD_AVAILABLE values are not present in the input flist, FR or PFR record is not sent for validation.

Card Security Code Is Now Masked in Logs

BRM applications may log flists containing the sensitive customer data. In previous releases, the card security code, such as VISA CVV2 or American Express CID, passed in the PIN_FLD_SECURITY_ID input flist field was not masked and appeared as clear text in the logs.

With this enhancement, the PIN_FLD_SECURITY_ID value is masked during logging. The card security codes passed in this field appear as masked fields in logs.

Display Bills Generated Before Moving the Account to a Hierarchy

In previous releases, when an account was moved to a hierarchy as a child account, the bills generated for the account before moving it to the hierarchy were not displayed in the bills list in Billing Care.

BRM opcodes have been modified to retrieve and display all the bills for an account in hierarchy. This allows you to view the bills that are generated before and after moving the account to a hierarchy with the details (such as item list, event details, A/R actions, and payments) in Billing Care.

To support this feature, the following opcodes now include the new PIN_INCLUDE_CHILDREN_ALL value for the PIN_FLD_INCLUDE_CHILDREN parameter in the input flist:

  • PCM_OP_AR_GET_BILLS

  • PCM_OP_AR_GET_ACCT_BILLS

  • PCM_OP_AR_GET_BAL_SUMMARY

  • PCM_OP_AR_GET_ACCT_BAL_SUMMARY

  • PCM_OP_AR_GET_ACTION_ITEMS

  • PCM_OP_AR_GET_ACCT_ACTION_ITEMS

  • PCM_OP_AR_GET_DISPUTES

  • PCM_OP_AR_GET_DISPUTE_DETAILS

  • PCM_OP_AR_GET_BILL_ITEMS

When you set the value of PIN_FLD_INCLUDE_CHILDREN to 3 (PIN_INCLUDE_CHILDREN_ALL), all the bills generated for the child account (before and after moving to the hierarchy) are retrieved.

Note:

When the PIN_FLD_INCLUDE_CHILDREN parameter is set to 3, PIN_FLD_BILLINFO_OBJ is mandatory in the input flist.

Managing Discount Validity Starting or Ending in Future Cycles

In previous releases, the discount proration was not set properly if the discount validity was starting or ending in a future cycle.

With this enhancement, during billing, BRM identifies the discounts that starts or ends in the next billing cycle and sets the discount validity and proration appropriately. For example, if proration for a discount is set to Full discount, full discount is applied even if the discount validity ends in the middle of the next billing cycle.

For more information on discount validity, see the discussion about configuring discount validity in PDC Creating Product Offerings if you are using PDC or the Pricing Center Online Help if you are using Pricing Center.

Wildcard in Item Type Selectors

Oracle Communications Pricing Design Center (PDC) now supports wildcard (*) in item type selectors. By setting the true or false value for the applicableToAllChildServices and applicableToAllChildEvents elements in PDC, you can configure whether all the child services or events of a service or event must be considered for item assignment.

If set to true, the real-time rating engine and batch rating engine consider all child services or events for the specified item assignment. If set to false, the real-time rating engine and batch rating engine do not consider child services or events for the specified item assignment.

If you are using wildcard in item type selectors, you must set the PDCEnable entry to true in the DAT_ItemAssign module in the Pipeline_home/conf/wireless.reg file.

For more information on using wildcard in item type selectors, see "PDC Now Supports Wildcard in Item Type Selectors".

BRM Supports POID Generation in ECE

In the previous releases, ECE was using the Portal object IDs (POIDs) generated in BRM for tracking rated events and bill items created in ECE.

With this enhancement, POIDs can be generated in ECE. ECE uses Rated Event Formatter to generate the required POIDs. To support this feature, the following changes have been made in BRM:

  • All the existing BRM storable class definitions have been modified to include the event type. The event type is used for creating separate partitions for different set of events. When you create new custom classes in BRM, you must now set the Event Type field. For more information, see "About Creating Custom Classes".

  • The PCM_OP_SDK_SET_DD, PCM_OP_SET_DD, and PCM_OP_GET_DD opcodes have been modified to support the partitioning of prepaid events.

  • The following have been introduced to enable partitions for prepaid events:

    • The prepaid_partition_set and prepaid_partition_transition_mode entries introduced in dm_oracle.

    • The prepaidPartitionSet parameter introduced in the system instance of the /config/business_params object.

    For more information, see "Enabling Prepaid-Event Partitions".

  • The partition_utils utility now supports the -t prepaid parameter. You can run the partition_utils utility with the enable operation and this parameter to create partitions for the prepaid events.

Enabling Prepaid-Event Partitions

If you are using ECE for usage rating, you must enable prepaid-event partition in BRM for generating the POIDs in ECE.

To enable prepaid-event partitioning:

Note:

In multischema systems, perform this task first on the primary BRM installation machine and then on the secondary BRM installation machines.

  1. Open the BRM_Home/sys/dm_oracle/pin.conf file in a text editor.

  2. Set the prepaid_partition_set entry to a numerical value between 2 and 7. For example: 

    - dm prepaid_partition_set 2

    If this entry is set to 0, ECE uses the POIDs received from BRM for the prepaid events.

  3. Set the prepaid_partition_transition_mode entry to 1:

    Note:

    Setting this entry to 1 enables Data Manager to retrieve the partitions for the existing events. After retrieving all the partitions for the existing events (for example, after 90 days), set this entry to 0 to disable this mode. 

     - dm prepaid_partition_transition_mode 1

  4. Save and close the file.

  5. Create an editable XML file from the system instance of the /config/business_params object: 

    pin_bus_params -r BusParamsSystem bus_params_system.xml

  6. Set the prepaidPartitionSet parameter to the value you specified in step 2. For example: 

    <prepaidPartitionSet>2</prepaidPartitionSet>

  7. Save the file as bus_params_system.xml.

  8. Load the XML file into the BRM database:

    pin_bus_params bus_params_system.xml

  9. Stop and restart CM.

  10. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

  11. Go to the BRM_home/apps/partition_utils directory.

  12. Create partitions for the prepaid events by running the following command:

    partition_utils -o enable -t prepaid

    For more information, see the discussion about partitioning database tables in BRM System Administrator's Guide.

    For information on enabling POID generation and prepaid-event partitions for ECE, see the discussion about POID generation in BRM Elastic Charging Engine Release Notes.

About Creating Custom Classes

When you create new custom classes in BRM, you must now set the Event Type field. Table 2-1 lists the event types in BRM. For instructions on how to create custom classes, see the discussion about creating custom classes in BRM Developer's Guide.

Note:

When you create a custom class, note the following:

  • If the event type is set to NONE, the corresponding event is not synchronized with PDC.

  • When you add a subclass, ensure that the event type matches the event type of the parent class if the event type is set to anything other than NONE.

Table 2-1 Event Types in BRM

Event Type Description

USAGE_PREPAID

Specifies the prepaid events (real-time charging events) from ECE.

USAGE_POSTPAID

Specifies the delayed events in BRM and postpaid events (offline charging events) from ECE.

SUBSCRIPTION_RECURRING

Specifies the recurring subscription event.

SUBSCRIPTION_ROLLOVER

Specifies the subscription events generated for rollovers.

SUBSCRIPTION_BILL_TIME_DISCOUNT

(For internal use only) Specifies the subscription events generated for bill-time discounts.

SUBSCRIPTION_FOLD

(For internal use only) Specifies the subscription events generated for folds.

SUBSCRIPTION_ONE_TIME

(For internal use only) Specifies the one-time subscription events.

SUBSCRIPTION_REMITTANCE

(For internal use only) Specifies the subscription events generated for remittances.

NONE

Specifies that the event does not belong to any other event type.

After you create the custom class and synchronize it with PDC, it is not recommended to change the event type of the custom class. However, if you have set the incorrect event type, you can change the event type by updating it first in BRM and then in PDC.

For changing the event type in BRM by editing the custom class, see the discussion about creating, editing, and deleting fields and storable classes in BRM Developer's Guide.

For updating the event type in PDC and publishing it to ECE, see the discussion about synchronizing and publishing the event type in "PDC Synchronizes Event Data Using Event Types".

Support for Stored-Credential Transactions for Payments

Credit card networks, such as VISA, MasterCard, Diners, Discover, JCB, and American Express, support the stored credential framework. They allow the merchants to use stored credentials for transactions. A stored credential is a payment information (such as an account number or a payment token) of a card holder stored by a merchant or its agent, a payment facilitator, or a staged digital wallet operator to process future transactions for the card holder. The Paymentech card processors also support customer-initiated or merchant-initiated transactions with stored credentials.

With this enhancement, BRM supports payment transactions with stored credentials for VISA, MasterCard, Diners, Discover, JCB, and American Express cards. You can also customize BRM to support stored-credential transactions for other card networks. When VISA, MasterCard, Diners, Discover, JCB, and American Express cards are used for payments, the PCM_OP_PYMT_COLLECT opcode sends the following information required for card transactions to Paymentech Data Manager (dm_fusa) and stores the responses received from Paymentech DM for future transactions:

  • Type of charge, such as recurring, one-time, and installment.

  • Transaction type.

  • Information on whether the card details are stored for future use.

  • A unique ID (TXID) obtained from a previous verify/charge transaction of the same type

You can override this information sent to Paymentech DM based on your business requirements. If you do not want to store credentials for future transactions, you can remove this information from the input passed to the PCM_OP_PYMT_COLLECT opcode.

For more information on storing or purging card credentials, see the following:

If you already have payment information stored in BRM for cards that support the stored credential framework, see "Migrating Legacy Payment Information".

To support the stored credential framework, the following changes have been made in BRM for this feature:

  • A new array, PIN_FLD_TRANSACTIONS, has been introduced in the /payinfo/cc storable class with the following optional fields to hold the Stored Credential Framework-specific information:

    • PIN_FLD_BILLINFO_OBJ. The bill unit (billinfo) for which payment is applied using the payment information (payinfo) in this array.

      Note:

      You can associate one payment information with multiple bill units. Each bill unit has its own recurring cycle and each series of recurring cycles must have its own TXID.

    • PIN_FLD_MODE. The message type with which the initial transaction was performed.

    • PIN_FLD_TRANS_ID. The TXID received in the initial transaction response.

  • A new array, PIN_FLD_TRANSACTIONS, has been introduced in the /event/billing/charge/cc and /event/billing/validate/cc storable class with the following optional fields to hold the Stored Credential Framework-specific information:

    • PIN_FLD_TRANS_ID. The TXID received in the initial transaction response.

    • PIN_FLD_MODE. The message type with which the transaction was performed.

    • PIN_FLD_FLAGS. The flag which indicates whether the credentials are stored in the file.

    • PIN_FLD_TYPE. The transaction type.

  • The following opcodes have been modified to include the PIN_FLD_TRANSACTIONS array:

    • PCM_OP_PYMT_COLLECT

    • PCM_OP_PYMT_POL_PRE_COLLECT

    • PCM_OP_PYMT_CHARGE

    • PCM_OP_PYMT_CHARGE_CC

    • PCM_OP_CUST_COMMIT_CUSTOMER

    • PCM_OP_CUST_CREATE_PAYINFO

    • PCM_OP_CUST_SET_PAYINFO

    • PCM_OP_CUST_POL_VALID_PAYINFO

  • The following tables have been added to store the information in the PIN_FLD_TRANSACTIONS array:

    • EVT_BILLING_CHARGE_CC_TRANS_T

    • EVT_BILL_VLDT_CC_TRANS_T

    • PAYINFO_CC_TRANS_T

  • BRM payment collection utilities, such as pin_collect and pin_deposit, have been enhanced to support stored credentials.

For more information on the field definitions and valid values, see BRM Opcode Flist Reference.

Storing Card Credentials for Future Transactions

To store the credit card information for future transactions, use PCM_OP_PYMT_COLLECT.

This opcode does the following:

  1. Receives the PIN_FLD_TRANSACTIONS array from the following opcodes if a VISA, MasterCard, Diners, Discover, JCB, or American Express card is registered for payment:

    • PCM_OP_CUST_COMMIT_CUSTOMER. This opcode passes the PIN_FLD_TRANSACTIONS array as input when you register a new customer with Credit Card as the default payment method and the cc_validate or cc_collect flag in the CM configuration file or credit card tokenization is enabled.

    • PCM_OP_CUST_SET_PAYINFO. This opcode passes the PIN_FLD_TRANSACTIONS array as input when you set Credit Card as the default payment method for the account.

    • PCM_OP_CUST_CREATE_PAYINFO. This opcode passes the PIN_FLD_TRANSACTIONS array as input when you add a new credit card and set that as the default payment method for the account.

  2. Accepts the card information in the PIN_FLD_TRANSACTIONS array, adds missing information as required, and then passes the information as input to the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.

    Note:

    You can add, update, or remove the card information in the PIN_FLD_TRANSACTIONS array by customizing the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.

  3. Receives the updated card information and PIN_FLD_CHARGES from the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.

  4. Sends the card information in the PIN_FLD_TRANSACTIONS array to Paymentech DM by calling the PCM_OP_PYMT_CHARGE or PCM_OP_PYMT_CHARGE_CC opcode.

    Paymentech DM appends the required records based on the information received and sends the transactions to Paymentech. If the transaction is successful, Paymentech DM retrieves the TXID from the Paymentech response and passes it to the PCM_OP_PYMT_COLLECT opcode.

  5. Accepts the TXID received from Paymentech DM and stores it in the PIN_FLD_TRANSACTIONS array in the /payinfo/cc object for future transactions.

Purging Card Credentials

When Credit Card is set as the default payment method, the PIN_FLD_TRANSACTIONS array with the card information for each bill unit is stored in the /payinfo/cc object. If the default payment method is changed to any other method or card, the PIN_FLD_TRANSACTIONS array in the /payinfo/cc object are automatically purged from the database if the payments for the accounts are not in cardholder-initiated installments. If the payments are in cardholder-initiated installments, the card holder must delete the PIN_FLD_TRANSACTIONS array manually after the payment is made for the last installment.

Migrating Legacy Payment Information

If there is legacy payment information in BRM for cards that support stored credential framework, it is automatically migrated to the new format, which includes the fields for storing credentials. BRM uses this information only for merchant-initiated transactions.

After migration, when the merchant initiates the first transaction with this payment information, the PCM_OP_PYMT_COLLECT opcode sets the TXID in the input as EXISTING9999999 to indicate that this transaction is initiated with the legacy payment information. The opcode then stores the TXID received from Paymentech DM as an additional TXID.

Support for Migration of Legacy Data into BRM and ECE in Real Time

In previous releases, all the legacy data migrated to BRM were loaded into Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) asynchronously using CustomerLoader. In case if the ECE update failed, the BRM and ECE data would be unsynchronized. If ECE uses the unsynchronized data to rate usage events, the events might be rated incorrectly.

Also, it was not possible to migrate legacy service and balance data incrementally into BRM and ECE. For example, when the legacy data was migrated into BRM in phases, if the account already migrated to BRM had some services associated with it, you could not migrate additional legacy services for the same account. As a result, the legacy service and balance updates could not be loaded into ECE.

With this enhancement, you can migrate the legacy data completely or incrementally into the BRM system by using the pin_cmt utility and also load all the migrated data into ECE synchronously (in real time). For example, after the initial migration of the legacy account and service data into BRM and ECE, you can migrate additional services and balances for the same migrated accounts into BRM and also synchronize them with ECE in real time.

To support this feature, the following changes have been made in BRM:

  • The CMT_Service.xsd schema file has been introduced to support incremental migration of legacy service data.

  • The CMT_Balances.xsd schema file has been modified to support incremental migration of legacy balance data.

  • A new entry, infranet.cmt.uselegacybalances, has been introduced in the BRM_home/apps/cmt/Infranet.properties file to support incremental migration of legacy balance data.

  • The cmt_mta_cycle_fees utility, which is run internally by the pin_cmt utility, has been modified and renamed as cmt_mta_deploy. Do not run this utility by itself.

  • Following new parameters are introduced for migrating legacy data by using the pin_cmt utility:

    • deploy_ece specifies to deploy the migrated data in BRM and also load them into ECE synchronously. You can use this parameter for complete or incremental migration of legacy data into BRM and ECE synchronously.

      Note:

      If ECE is not integrated with BRM, you need to use the deploy parameter for both complete and incremental migration of legacy data into BRM. For more information, see the discussion about loading legacy data into the BRM database in BRM Migrating Accounts to the BRM Database.

    • deploy_db specifies to deploy the migrated data only in BRM. You can use this parameter if you want to load the legacy data into ECE asynchronously using CustomerLoader.

      Note:

      After deploying the legacy data by using the deploy_db parameter, you need to load the data manually into ECE by using the CustomerLoader utility and then run the pin_cmt utility with the apply_cycle_fees parameter to apply the cycle fees for the migrated accounts.

      For information on loading data using the CustomerLoader utility, see the discussion about using CustomerLoader in ECE Implementing Charging.

    • apply_cycle_fees specifies to apply the cycle fees for the migrated accounts. You can use this parameter only when you load the legacy data into ECE asynchronously.

When you use the deploy_ece parameter, the pin_cmt utility deploys the migrated legacy data in BRM and also sends it to ECE in real time through External Manager (EM) Gateway. In this case, both the BRM database and the ECE cache updates occur in a single transaction. If the ECE cache update succeeds, the updates are saved to the BRM database. If the cache update fails, the database updates are rolled back. This ensures that the BRM and ECE data remain synchronized whether the cache update succeeds or fails. You can use the cmt.pinlog files in BRM and error logs in ECE to troubleshoot the errors. For more information on troubleshooting Conversion Manager, see BRM Migrating Accounts to the BRM Database. For more information on troubleshooting ECE, see BRM System Administrator's Guide.

To migrate the legacy account, service, and balance data completely or incrementally into BRM and ECE, do the following:

  1. Import the legacy data into BRM. See "Importing Data".

  2. Deploy the converted data. See "Deploying Data in BRM and ECE".

Importing Data

You import legacy data into the BRM database one file at a time.

Before importing the legacy data, do the following:

  1. If you are migrating custom data, create new or extended storable classes for migration. See the discussion about migrating data by using new and extended storable classes in BRM Migrating Accounts to the BRM Database.

  2. Create XML files with the legacy data that you want to import, which conform to the format detailed in the corresponding XSD files; such as CMT_Account.xsd, CMT_Service.xsd, and CMT_Balances.xsd file. See the discussion about creating XML files in BRM Migrating Accounts to the BRM Database.

  3. Open the BRM_home/apps/cmt/Infranet.properties file in a text editor.

  4. Ensure that the database connection is specified.

  5. If you are migrating legacy balances, to replace the existing balances in BRM with the legacy balances, set the infranet.cmt.uselegacybalances entry to true.

    Note:

    This entry takes precedence over the infranet.cmt.deleteexistingbalances entry. If set to true, the infranet.cmt.deleteexistingbalances entry is not used.

    Note:

    When the infranet.cmt.uselegacybalances entry is set to true, you must ensure the following:

    • Check if the VALID_FROM date is specified for all the sub-balances to be migrated. The VALID_FROM date is required for identifying the sub-balances to be replaced.

    • Import the legacy balances before deploying the account and service data to the BRM production area. You cannot replace the balances after you deploy the migrated account and service data.

  6. Save and close the file.

To import the legacy data completely or incrementally into the BRM database:

  1. Go to the BRM_home/apps/cmt directory.

  2. Do one of the following:

    • If you have not created custom storable classes for migration, import the legacy data by running the following command:

      pin_cmt -import -file XML_input_data_file stage_ID

      where XML_input_data_file is the XML file with the legacy data, and stage_ID is the unique identity of the staging area.

    • If you have created custom storable classes for migrating custom data, import the legacy data by running the following command:

      pin_cmt -import_custom -file XML_input_data_file stage_ID

    Note:

    Ensure that the stage_ID is unique for each migration.

Deploying Data in BRM and ECE

Before deploying the imported data in BRM and ECE, do the following:

  • Ensure that all the pricing data is loaded into the ECE cache. See the discussion about verifying that pricing data is loaded into ECE in ECE Implementing Charging.

  • Ensure that the real-time synchronization is enabled in ECE. See the discussion about enabling real-time synchronization of BRM and ECE customer data updates in ECE Implementing Charging.

To deploy the imported data to the BRM production area and load the data into ECE synchronously, run the following command:

Note:

If you are migrating the complete legacy data, you can import the legacy account, service, and balance data into the BRM database and then deploy all the legacy data together.

You must import the legacy balances before deploying the account and service data to the BRM production area. You cannot replace the balances after you deploy the migrated account and service data.

pin_cmt -deploy_ece DOM stage_ID

where DOM is the billing cycle's day of month.

The migrated legacy data deployed in BRM and are synchronized with ECE in real time.

If you are deploying the services, the pin_cmt utility does the following:

  • Applies the cycle fees in BRM and synchronize them with ECE if the infranet.cmt.deploy.opcode entry is set to true. See the discussion about applying cycle fees to deployed accounts in BRM Managing Customers.

  • Deploys the legacy balances if the infranet.cmt.uselegacybalances entry is set to true.

Merging Legacy Balances

BRM merges the migrated legacy balance data with the existing balance data in the BRM database. If the sub-balance already exists in the BRM database, it replaces the sub-balance with the corresponding legacy balance. If the sub-balance does not exist, it adds the legacy balance to the BRM database. BRM identifies the existing sub-balances in the BRM database by using the combination of the following data in /cmt_balances objects:

  • resource ID

  • POID of the granting product/charge offer or discount

  • VALID_FROM date

In case if the VALID_FROM date is not specified, the first sub-balance available for the specified granting product or discount is replaced with the legacy balance. However, you must ensure that the VALID_FROM date is specified for all the legacy balances to be migrated. This ensures that the balances are replaced appropriately.

In case if the POID of the granting product or discount is not specified, a new sub-balance is created with the specified VALID_FROM and VALID_TO dates.

For more information on migrating data, see the discussion about loading legacy data into the BRM database in BRM Migrating Accounts to the BRM Database.

Support for Migrating Hierarchical Accounts Using Same Input File

In previous releases, you could migrate a legacy hierarchical account group to BRM only if the parent and child accounts belonging to that group were present in different XML input files.

With this enhancement, you can migrate the legacy hierarchical account groups to BRM even if the parent and child accounts in the groups are present in the same XML input file. When you run the pin_cmt utility, all the hierarchical account groups in the input file are loaded into the BRM database. However, if any group in the file contains a multi-level account hierarchy (for example, Account C's bill unit is paid by Account B, which is in turn paid by Account A), you cannot load the parent and child accounts in that group using the same input file. You must create separate input files for parent and child accounts and load the parent accounts into the BRM database before loading the child accounts.

Event Rounding Rules Can Be Used for Adjustments

You can now use the rounding rules configured for events in adjustments. For example, if you configured usage events with six decimal precision, the event-level adjustment on the usage fee is rounded to six decimal precision.

To enable this feature, run the pin_bus_params utility to change the UseEventRoundingRulesForAdjustment business parameter. For information about this utility, see BRM Developer's Guide.

To use the rounding rules of corresponding events for adjustments:

  1. Go to the BRM_home/sys/data/config directory.

  2. Create an XML file from the /config/business_params object:

    pin_bus_params -r BusParamsAR bus_params_AR.xml

  3. In the XML file, search for the following parameter and change disabled to enabled: 

    <UseEventRoundingRulesForAdjustment>enabled</UseEventRoundingRulesForAdjustment>

  4. Save the file as bus_params_AR.xml.

  5. Load the XML file into the BRM database:

    pin_bus_params bus_params_AR.xml

  6. Stop and restart CM.

  7. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

New Staging Directory for Exported G/L reports

In the previous releases, when the pin_ledger_report utility was run in the export mode, the utility created a staging directory named, TEMP_XML_STAGING, in the OutputDirectory and stored the output G/L report files temporarily in this directory before moving them to the OutputDirectory, where OutputDirectory is the directory on your system in which to create the output G/L report files.

With this enhancement, the pin_ledger_report utility creates a staging directory named, TEMP_GL_REPORT_STAGING, in the same location as the OutputDirectory and stores the output G/L report files temporarily in this directory before moving them to the OutputDirectory. For example, if the OutputDirectory is pin/users/GL, the G/L Report Files are stored in the new pin/users/TEMP_GL_REPORT_STAGING directory.

Note:

To enable the pin_ledger_report utility to store G/L report files in the new staging directory, do one of the following:

  • Ensure that the utility has the permission to create a directory and file in the location in which the OutputDirectory is available.

  • Manually create the TEMP_GL_REPORT_STAGING directory in the same location as the OutputDirectory and add the permission for the utility to create or store files in this directory.

BRM Client Applications Supported from 12.0 Patch Set 2

Table 2-2 lists the BRM client applications that are now released in BRM 12.0.

Table 2-2 Supported BRM Client Applications

Component Description

Customer Center

BRM now supports Customer Center (including Customer Center SDK). You can now use Customer Center or Oracle Communications Billing Care for customer management tasks. For more information, see the Customer Center Online Help.

Collections Center

BRM now supports Collections Center. You can now use Collections Center or Billing Care for collections or debt management tasks. For more information, see the Collections Center Online Help.

Configuration Center

BRM now supports Configuration Center.

Field Validation Editor

BRM now supports Field Validation Editor to define how to validate customer data.

Payment Center

BRM now supports Payment Center. You can now use Payment Center or Billing Care instead for payment management tasks. For more information, see the Payment Center Online Help.

Payment Tool

BRM now supports Payment Tool. You can now use Payment Tool or Billing Care for processing payments. For more information, see the Payment Center Online Help.

Pricing Center

BRM now supports Pricing Center. You can now use Pricing Center or Pricing Design Center for creating product offerings for BRM. For more information, see the Pricing Center Online Help.

New Features in BRM 12.0 Patch Set 1

BRM 12.0 Patch Set 1 includes the following enhancements:

Improved Performance for Large Accounts

Wholesale business accounts with large account hierarchies can have a large number of services each representing a subscription account. This can affect the billing and invoicing performance if the accounts had a large number of billing items to be processed.

With this enhancement, you can setup wholesale billing for handling large wholesale business accounts. In wholesale billing, you set up a bill unit hierarchy for account receivable (A/R) operations. In this hierarchy, the wholesale business account is the parent account with the paying parent bill unit and the services (subscriptions) in this account are child accounts with nonpaying child bill units. This enables BRM to consolidate the charges, discounts, A/R items, bill items, journals, and taxes across the services under the wholesale business account and perform the A/R operations, billing, and invoicing at the wholesale business account level. This improves the billing and invoicing performance for wholesale accounts with large hierarchies.

If you want to enable wholesale billing for all your accounts, you can enable system-wide wholesale billing by setting the WholesaleBillingSystem business parameter in the billing instance of the /config/business_params object. When this business parameter is enabled, you can create only wholesale accounts and bill unit hierarchies. For more information, see "Enabling Wholesale Billing" and "Creating Wholesale Accounts and Bill Unit Hierarchies".

If you want to enable wholesale billing only for specific accounts, you can set up an account with the paying parent bill unit as the wholesale parent and then create the wholesale bill unit hierarchy. You can create multiple wholesale bill unit hierarchies based on your business requirements. You need not enable system-wide wholesale billing. For more information, see "Creating Wholesale Accounts and Bill Unit Hierarchies".

Enabling Wholesale Billing

To enable wholesale billing system-wide:

  1. Go to BRM_home/sys/data/config.

  2. Create an XML file from the /config/business_params object: 

    pin_bus_params -r BusParamsBilling bus_params_billing.xml

  3. In the XML file, set the following entry to enabled: 

    <WholesaleBillingSystem>enabled</WholesaleBillingSystem>

  4. Save the file as bus_params_billing.xml.

  5. Load the file into the BRM database:

    pin_bus_params bus_params_billing.xml

  6. Stop and restart the Connection Manager (CM).

  7. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Creating Wholesale Accounts and Bill Unit Hierarchies

You can create accounts and bill unit hierarchies for wholesale billing by using Billing Care or by using custom applications to call BRM opcodes. A wholesale bill unit hierarchy is headed by a paying parent bill unit with nonpaying child bill units beneath it. You can have only one paying bill unit in a wholesale bill unit hierarchy. And, you cannot add more than one bill unit to a wholesale parent account.

For more information on accounts and bill unit hierarchies, see the discussion about creating and managing account and bill unit hierarchies in BRM Managing Accounts Receivable.

Note:

You cannot convert an existing bill unit hierarchy in your system into a wholesale bill unit hierarchy. You must ensure the following for enabling wholesale billing:

  • If you are enabling system-wide wholesale billing, you must set the WholesaleBillingSystem business parameter before creating wholesale accounts and bill unit hierarchies.

  • If you are enabling wholesale billing for specific accounts, you must set up a wholesale parent before creating the wholesale bill unit hierarchy.

To create accounts and bill unit hierarchies and set up the wholesale parent account by:

  • Using Billing Care, see the discussion about creating accounts and configuring billing hierarchies in the Billing Care Online Help.

  • Using BRM opcodes, see the discussion about creating accounts in the BRM Opcode Guide and "Setting Up a Wholesale Parent".

Note:

Before you set up the wholesale parent either by using Billing Care or BRM opcodes, you must configure the wholesale business profile. See "Configuring Wholesale Business Profile".

You can add any existing bill unit to a wholesale bill unit hierarchy or set up a new wholesale bill unit hierarchy by using the existing bill units in BRM. However, you must ensure the following:

  • There are no pending items or payments in the bill unit that you are adding to the hierarchy.

  • The parent bill unit is the paying bill unit and it is set as the wholesale parent for billing.

  • The wholesale parent for the wholesale bill unit hierarchy is set before creating the hierarchy.

This ensures that the charges and other billing-related items of the nonpaying child bill units in the hierarchy are rolled up to the paying parent bill unit during billing.

Configuring Wholesale Business Profile

To configure the wholesale business profile:

  1. Open the pin_business_profile.xml file in an XML editor or a text editor.

    By default, this file is in the BRM_home/sys/data/config directory.

  2. Search for the corporate wholesale business profile.

  3. Set the <WholesaleBilling> entry to yes: 

    <WholesaleBilling>yes</WholesaleBilling>

  4. Save and close the file.

  5. Load the pin_business_profile.xml file by running the following command: 

    load_pin_business_profile pin_business_profile.xml

    Note:

    • When you run the utility, the pin_business_profile.xml and business_configuration.xsd files must be in the same directory. By default, both files are in BRM_home/sys/data/config.

    • This utility needs a configuration (pin.conf) file in the directory from which you run the utility.

    • If you do not run the utility from the directory in which pin_business_profile.xml is located, include the complete path to the file.

  6. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Setting Up a Wholesale Parent

To set up a parent bill unit for wholesale billing, you assign the bill unit that you want use as the wholesale parent to the wholesale business profile. To configure the wholesale business profile, see "Configuring Wholesale Business Profile".

You can assign the bill unit (/config/business_profile object) during or after account creation:

  • To assign the bill unit to a business profile during account creation, see the discussion about assigning bill units to business profiles in BRM Opcode Guide.

  • To assign the bill unit of an existing account to a business profile, see the discussion about changing a bill unit's business profile in BRM Opcode Guide.

Rolling Charges Up to the Wholesale Parent

Note:

In BRM 12.0 and BRM 12.0 Patch Set 1, the usage charges calculated by ECE and Pipeline Manager are not considered for wholesale billing; for example, the usage charges for telephony services.

During final billing, all the charges (such as recurring, purchase, and usage charges) applied to the nonpaying child bill units (wholesale child accounts) are aggregated based on the item-tag-to-item-type mapping (item configuration) and are rolled up to the corresponding bill items of the paying parent bill unit (wholesale parent account).

If the bill item for any item type does not exist for the paying parent bill unit, the bill item is created during billing and the charges are rolled up to that item. However, Oracle recommends to pre-create the bill items for the different item types by setting the precreate element to true in the BRM_home/sys/data/pricing/example/config_item_types.xml file. For more information, see the discussion about mapping item tags to item types in BRM Configuring and Running Billing.

The total and due amounts of the paying parent bill unit are updated to reflect the roll-up and the due amount of each nonpaying child bill unit is set to 0. Payments are applied only to the paying parent bill unit. From BRM 12.0 Patch Set 2, invoicing of due amount of child bill unit is supported. See "Wholesale Billing Enhancements".

If you want the charges for different services to be rolled up to different bill items, you can assign different item types for different services. For example, for rolling up cycle forward fees for IP and GSM services, you can configure and assign the following items: /item/ip/cycle_forward for the IP service and /item/gsm/cycle_forward for the GSM service.

You can also assign a different item type (or a noncumulative bill item) to track charges specific to the paying parent bill unit.

For information on assigning items, see the discussion about using event and service combinations to assign bill items in BRM Configuring and Running Billing.

Rolling A/R Actions Up to the Wholesale Parent

To manage balances for the A/R actions, BRM uses A/R items. A/R items include adjustment, dispute, settlement, payment, refund, payment reversal, write-off, and write-off reversal items. For more information, see the discussion about A/R management in BRM Concepts.

To roll up A/R actions for wholesale billing, you use the pin_roll_up_ar_items utility. The pin_roll_up_ar_items utility processes all the temporary A/R items (/tmp_ar_item_to_roll_up object) of the nonpaying child bill units and rolls the balance impact up to the corresponding A/R items of the paying parent bill unit. For example, this utility rolls the adjustments allocated to the nonpaying child bill unit's /item/cycle_forward item up to the adjustment item associated with the /item/adjustment item of the paying parent bill unit.

You can run the pin_roll_up_ar_items utility on a daily basis to ensure that the A/R items of the paying parent bill unit are kept up to date. However, you must run this utility once before billing the paying parent bill unit. For more information on this utility, see "pin_roll_up_ar_items".

In addition, you can use the pin_roll_up_ar_items utility to roll up the adjustment items that are created as a result of rerating. During rerating, the temporary A/R items (/tmp_ar_item_to_roll_up object) are created for the nonpaying child bill units if the following conditions are met:

  • The event has already been billed.

  • The event occurred prior to general ledger posting.

  • The event is unbilled but the automatic allocation of rerating adjustments is disabled.

If the event is unbilled and the automatic allocation of rerating adjustments is enabled, the rerating adjustment is allocated to the bill item of the nonpaying child bill unit.

Note:

Rerating adjustments rolled up to the paying parent bill unit are allocated to the corresponding A/R item only if it exists in the paying parent bill unit. If the A/R item does not exist, the rerating adjustments remain unallocated at the parent level.

Rolling Journals Up to the Wholesale Parent

For nonpaying child bill units, the /tmp_journals_to_process objects are created instead of the /journal objects at the time of rating. The /tmp_journals_to_process objects are created only if the cycle_tax_interval entry in the CM configuration file is set to billing. For more information, see the discussion about tax calculation for account groups in BRM Calculating Taxes.

The /tmp_journals_to_process objects contain revenue and tax data. For wholesale billing, BRM uses these objects primarily to track and consolidate taxes for billing-time taxation. To roll up journals for wholesale billing, you use the pin_update_journals utility.

Note:

To roll up journals for wholesale billing, you must ensure that the general ledger reporting is enabled. For more information, see the discussion about general ledger reporting in BRM Collecting General Ledger Data.

The pin_update_journals utility processes all the /tmp_journals_to_process objects of the nonpaying child bill units and rolls them up to the corresponding /journal object of the paying parent bill unit.

You can run the pin_update_journals utility on a daily basis to ensure that the paying parent bill unit is kept up to date. However, you must run this utility once before billing the paying parent bill unit. For more information on this utility, see "pin_update_journals".

If deferred taxation is configured to consolidate taxes into a single item (if cycle_tax_interval is set to billing), the pin_update_journals utility enables you to roll the taxes up into a single item for both the paying parent and nonpaying child bill units. The total tax is calculated at the paying parent level for the entire hierarchy using the aggregated total due as the basis.

If deferred taxation is configured to calculate taxes separately for the parent and each nonpaying child bill unit (if cycle_tax_interval is set to accounting), the /journal objects are created for the nonpaying child bill units instead of /tmp_journals_to_process objects and the taxes are not rolled up to the paying parent bill unit.

Running Wholesale Billing

Note:

The following features are not supported for wholesale billing:

  • Bill Now

  • On-purchase (on-demand) billing

  • Skipped billing

If you are using bill suppression for billing wholesale accounts, you must run wholesale billing at the end of each accounting cycle.

To run wholesale billing:

  1. Run the pin_roll_up_ar_items utility which rolls A/R actions up to the paying parent bill unit. See "pin_roll_up_ar_items".

  2. Run the pin_update_journal utility which rolls journals up to the paying parent bill unit. See "pin_update_journals".

  3. Run the pin_bill_accts utility which performs regular billing. See the discussion about the pin_bill_accts utility in BRM Configuring and Running Billing.

    Note:

    After the nonpaying child bill units are billed, you cannot perform A/R activities (such as adjustments, disputes, and settlements) on the billed events of the nonpaying bill units until the paying parent bill unit is billed.

  4. Run the pin_inv_accts utility for the wholesale parent account to generate invoices for bills.

Configuring Billing Delay for Wholesale Hierarchies

Delayed billing is supported for wholesale hierarchies. You must specify the billing delay even if it is not used. In this case, you can set the billing delay interval to 0. See the discussion about configuring billing delay in BRM Configuring and Running Billing.

Setting Up Billing-Time Discounts for Wholesale Hierarchies

For wholesale bill unit hierarchies, you set up a billing-time discount as follows:

  • Configure billing-time discount only for the paying parent bill unit in the hierarchy.
  • Configure BRM to apply the billing-time discount at the end of the billing cycle instead of the accounting cycle.
  • Configure non-billing-time discounts (usage discounts) for the nonpaying child bill units in the hierarchy. The usage discount increments the counter. For example, if the billing-time discount for the paying parent bill unit is based on total monthly charges, you can create a discount for a nonpaying child bill unit that increments the counter when charges are applied.

And, for rolling the discounts up to the paying parent bill unit at the time of billing, you customize the PCM_OP_SUBSCRIPTION_POL_PRE_CYCLE_DISCOUNT policy opcode to return the list of balance element/resource IDs of the counters (in the PIN_FLD_BALANCES output flist field) for which the balances to be rolled up to the paying parent bill unit in the hierarchy.

For more information on billing-time discounts, see the discussion about creating discount offers in BRM Creating Product Offerings.

Suppressing Bills for Wholesale Hierarchies

You can use bill suppression to postpone finalizing bills for wholesale accounts. When bill suppression is enabled, the charges applied to the nonpaying child bill units are rolled up to the paying parent bill unit at the end of the accounting cycle. Therefore, you must run the pin_roll_up_ar_items, pin_update_journals, and pin_bill_accts utilities in the same order at the end of each accounting cycle. See "Running Wholesale Billing".

Trial Billing for Wholesale Hierarchies

When you perform trial billing for wholesale bill unit hierarchies, you must run the billing for nonpaying child bill units (wholesale child accounts) before running the billing for the paying parent bill unit (wholesale parent account). You can perform this by running the pin_trial_bill_accts utility with the -pay_type parameter. For more information, see the discussions about trial billing for bill unit hierarchies and sharing groups and running trial billing according to payment type in BRM Configuring and Running Billing.

Support for A/R Activities

For wholesale bill unit hierarchies, the support for A/R activities varies from level to level:

  • Account level. Adjustments, disputes, and settlements can be performed only at the parent bill unit level after billing.

  • Bill level. Adjustments, disputes, and settlements can be performed only after billing at the parent bill unit level.

  • Event level. Adjustments, disputes, and settlements can be performed at the child bill unit level before and after billing.

  • Item level. Adjustments and disputes can be performed at the child bill unit level only before billing. After billing, adjustments and disputes are allowed only at the parent bill unit level. However, settlements can be performed before and after billing at the child bill unit level.

Write-offs can be performed only at the parent bill unit level after billing.

Specifying Search Criteria for Retrieving Items, Events, and Bills

To retrieve a list of items, events, or bills, BRM uses the following A/R and payment opcodes:

  • PCM_OP_AR_GET_ACTION_ITEMS

  • PCM_OP_AR_GET_ACCT_ACTION_ITEMS

  • PCM_OP_AR_GET_BAL_SUMMARY

  • PCM_OP_AR_GET_ACCT_BAL_SUMMARY

  • PCM_OP_AR_GET_BILL_ITEMS

  • PCM_OP_AR_GET_BILLS

  • PCM_OP_AR_GET_DISPUTE_DETAILS

  • PCM_OP_AR_GET_DISPUTES

  • PCM_OP_AR_GET_ACCT_BILLS

  • PCM_OP_PYMT_ITEM_SEARCH

  • PCM_OP_PYMT_MBI_ITEM_SEARCH

  • PCM_OP_PYMT_SELECT_ITEMS

Based on the search criteria provided as input, these opcodes search all the bill units in a hierarchy. This can have an impact on the wholesale billing performance if you have large wholesale bill unit hierarchies.

To improve the wholesale billing performance, you must restrict the search to find items only for the specific bill units instead of searching all the bill units in a wholesale bill unit hierarchy.

Similarly, BRM uses the PCM_OP_AR_GET_ITEM_DETAIL and PCM_OP_AR_GET_ITEMS opcodes to retrieve the details of an A/R item or bill item for a bill unit. For wholesale hierarchies, these opcodes cannot retrieve all the details about the rolled-up items. For example, for the A/R items of the paying parent bill unit, these opcodes cannot retrieve the corresponding transfer events for the rolled-up disputes and settlements. Therefore, you must modify the search to retrieve only the details that are available for wholesale hierarchies.

For information on the search criteria for these opcodes, see BRM Opcode Guide.

Moving Bill Units into or out of Wholesale Hierarchies

You can move the nonpaying child bill units into or out of a wholesale bill unit hierarchy. You can also move them between wholesale bill unit hierarchies. Before moving a bill unit, ensure that there are no pending items or payments in that bill unit.

When you move the nonpaying child bill unit to another hierarchy, all the items in that bill unit are associated with the corresponding items of the new paying parent bill unit and the new parent is billed for them. If a bill item does not exist in the new parent, it is created and the charges are rolled up to that item.

Configuration Changes

You set the StagedBillingFeeProcessing business parameter to 4 to enforce cycle fee processing prior to billing and apply cycle forward fees in parallel by service with service charges aggregated to a single account item. With this enhancement, this option is no longer required. Now, the valid values for this parameter are only 0, 1, 2, and 3.

Opcode Changes

To support wholesale billing, the following opcode changes have been made:

  • The following new public opcode has been introduced:

    • PCM_OP_SUBSCRIPTION_POL_PRE_CYCLE_DISCOUNT

  • The following public opcodes have been modified:

    • PCM_OP_AR_ACCOUNT_ADJUSTMENT

    • PCM_OP_AR_ACCOUNT_WRITEOFF

    • PCM_OP_AR_BILL_ADJUSTMENT

    • PCM_OP_AR_BILL_DISPUTE

    • PCM_OP_AR_BILL_SETTLEMENT

    • PCM_OP_AR_BILL_WRITEOFF

    • PCM_OP_AR_BILLINFO_WRITEOFF

    • PCM_OP_AR_EVENT_ADJUSTMENT

    • PCM_OP_AR_EVENT_DISPUTE

    • PCM_OP_AR_EVENT_SETTLEMENT

    • PCM_OP_AR_ITEM_ADJUSTMENT

    • PCM_OP_AR_ITEM_DISPUTE

    • PCM_OP_AR_ITEM_SETTLEMENT

    • PCM_OP_AR_ITEM_WRITEOFF

    • PCM_OP_BILL_MAKE_BILL

    • PCM_OP_CUST_COMMIT_CUSTOMER

    • PCM_OP_CUST_CREATE_CUSTOMER

    • PCM_OP_CUST_DELETE_ACCT

    • PCM_OP_CUST_SET_BILLINFO

    • PCM_OP_INV_MAKE_INVOICE

    • PCM_OP_INV_POL_PREP_INVOICE

    • PCM_OP_PYMT_COLLECT

    • PCM_OP_PYMT_MBI_DISTRIBUTE

    • PCM_OP_SUBSCRIPTION_RERATE_REBILL

For more information, see "Opcode Changes".

Schema Changes

To support wholesale billing, the following schema changes have been made:

  • The following tables are added:

    • EVENT_ACT_ROLLUP_ITEMS_T

    • TMP_AR_ITEM_TO_ROLL_UP_T

  • The following columns are added in the ITEM_T table:

    • ITEM_CLASS

    • AR_ITEM_OBJ

  • The following column is added in the TMP_JOURNALS_TO_PROCESS_T table:

    • AR_BILLINFO_OBJ

  • The following indexes are added:

    • I_TMP_AR_ITM_ROLLUP__ID

    • I_TMP_AR_ITM_ROLLUP__STATUS

    • I_ITEM_AR_ITEM_OBJ__ID

    • I_TMP_JOURNALS_TO_PROCESS__AR

Storable Class Changes

To support wholesale billing, the following changes have been made:

  • The following new storable classes have been introduced:

    • /event/activity/roll_up

    • /tmp_ar_item_to_roll_up

  • The following storable class has been modified:

    • /tmp_journals_to_process

For more information, see "Storable Class Changes".

Utility Changes

To support wholesale billing, the following new utilities have been introduced:

pin_update_journals

Use the pin_update_journals utility to process temporary journals (/tmp_journals_to_process object) of the nonpaying child bill units and roll them up to the paying parent bill unit. You must run this utility before billing the paying parent bill unit.

To connect to the BRM database, the pin_update_journals utility needs a configuration file in the directory from which you run the utility. See "Connecting BRM Utilities" in BRM System Administrator's Guide.

Location

BRM_home/bin

Syntax

pin_update_journals [-verbose][-help]

Parameters

-verbose

Displays information about successful or failed processing as the utility runs.

-help

Displays the syntax and parameters for this utility.

Results

If the pin_update_journals utility does not notify you that it was successful, look in the utility log file (default.pinlog) to find any errors. The log file is either in the directory from which the utility was started or in a directory specified in the configuration file.

Error Handling

When the pin_update_journals utility encounters an error while processing the A/R items in the temporary tables, it sets the PIN_FLD_BILLING_STATUS billing status field of the paying parent bill unit (/billinfo object) to PIN_BILL_ERROR. In addition, it sets the appropriate bit of the PIN_FLD_BILLING_STATUS_FLAGS field of the /billinfo object as PIN_BILL_FLAGS_UPDATE_JOURNALS_ERROR (bit value 0x2000).

After you have resolved the processing errors, you can reprocess the A/R items by running the pin_update_journals utility again.

pin_roll_up_ar_items

Use the pin_roll_up_ar_items utility to process temporary A/R items (/tmp_ar_item_to_roll_up object) of the nonpaying child bill units and roll the balance impact up to the corresponding A/R items in the paying parent bill unit. You can run multiple threads of pin_roll_up_ar_items to process A/R items for different paying parent bill units.

You must run this utility before billing the paying parent bill unit. For more information, see "Rolling A/R Actions Up to the Wholesale Parent".

To connect to the BRM database, the pin_roll_up_ar_items utility needs a configuration file in the directory from which you run the utility. See the discussion about connecting BRM utilities in BRM System Administrator's Guide.

Location

BRM_home/bin

Syntax

pin_roll_up_ar_items [-verbose][-help]

Parameters

  • verbose: Displays information about successful or failed processing as the utility runs.

  • help: Displays the syntax and parameters for this utility.

Results

If the pin_roll_up_ar_items utility does not notify you that it was successful, look in the utility log file (default.pinlog) to find any errors. The log file is either in the directory from which the utility was started or in a directory specified in the configuration file.

Error Handling

When the pin_roll_up_ar_items utility encounters an error while processing the A/R items in the temporary tables, it sets the PIN_FLD_BILLING_STATUS billing status field of the paying parent bill unit (/billinfo object) to PIN_BILL_ERROR. In addition, it sets the appropriate bit of the PIN_FLD_BILLING_STATUS_FLAGS field of the /billinfo object as PIN_BILL_FLAGS_UPDATE_ITEMS_ERROR (bit value 0x4000).

After you have resolved the processing errors, you can reprocess the A/R items by running the pin_roll_up_ar_items utility again.

Delay Interval Can be Configured for Resolving Failed Payments

In previous releases, when the pin_recover utility and a custom application were run in parallel to resolve failed credit card or debit card payments, duplicate transaction IDs were created.

With this patch, a new entry, event_search_delay, has been introduced in the BRM_home/apps/pin_billd/pin.conf file to specify the delay interval for resolving failed payments. When set, the pin_recover utility processes only the events (/event/billing/charge/cc) that were created before the specified delay interval.

To configure the delay interval for resolving failed payments:

  1. Open the billing utility configuration file (BRM_home/apps/pin_billd/pin.conf) in a text editor.

  2. Search for the event_search_delay entry.

  3. Specify the delay interval:

    - pin_recover event_search_delay value

    where value is the delay interval in seconds. By default, it is set to 0.

    For example, setting the event_search_delay entry to 300 delays the event search for resolving failed payments by 5 minutes: 

    - pin_recover event_search_delay 300

  4. Save and close the file.

Enhanced Data Protection

BRM now includes the following security enhancements to protect the subscriber's personal data:

  • Deleting closed accounts and all the related objects (such as events, items, bills, invoices, journals, newsfeeds, and user activities) and the audit data automatically from BRM after the specified retention period.

  • Purge deleted accounts and the associated customer data synchronously on BRM and Oracle Communications Elastic Charging Engine (ECE). For more information, see the discussion about purging accounts from the ECE cache in BRM ECE Release Notes.

  • Securing communications between BRM applications and the database. See the discussion about configuring SSL for the BRM database in BRM 12.0 Patch Set Installation Guide.

To support the security enhancements, the following changes have been made in BRM:

  • The ClosedAcctsRetentionMonths business parameter has been introduced to specify the retention period for the closed accounts. See "Specifying Retention Period for Closed Accounts".

  • The pin_del_closed_accts utility has been introduced to delete closed accounts from BRM after the specified retention period. See "pin_del_closed_accts".

  • The PCM_OP_CUST_DELETE_ACCT opcode has been modified to ensure that all the BRM objects and audit entries containing the subscriber's personal data are purged.

    Note:

    You can use the PCM_OP_CUST_DELETE_ACCT opcode to delete accounts in a production system, but ensure that you use this opcode with care.

    For more information on the PCM_OP_CUST_DELETE_ACCT opcode, see the discussion about deleting accounts in BRM Opcode Guide.

    Note:

    The PCM_OP_CUST_DELETE_ACCT opcode does not delete all the custom objects. You can write a custom logic to clean up the custom objects in BRM when the /event/notification/account/pre_delete and /event/notification/account/delete events are generated by the PCM_OP_CUST_DELETE_ACCT opcode.

Specifying Retention Period for Closed Accounts

You can specify the number of months the closed accounts must be retained in BRM by setting the ClosedAcctsRetentionMonths parameter in the customer instance of the /config/business_params object.

To specify the retention period for closed accounts:

  1. Go to BRM_home/sys/data/config.

  2. Create an XML file from the /config/business_params object: 

    pin_bus_params -r BusParamsCustomer bus_params_customer.xml

  3. Set the ClosedAcctsRetentionMonths entry to the number of months that you want to retain the closed accounts: 

    <ClosedAcctsRetentionMonths>number_of_months</ClosedAcctsRetentionMonths>

  4. Save the file as bus_params_customer.xml.

  5. Load the XML file into the BRM database:

    pin_bus_params bus_params_customer.xml

  6. Stop and restart the CM.

  7. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Deleting Closed Accounts

You can delete closed accounts in BRM after the retention period by using the pin_del_closed_accts utility.

To delete closed accounts:

  1. Go to the BRM_home/apps/pin_billd directory.

  2. Do the following as appropriate:

    Note:

    To delete all closed child accounts in a hierarchy and sharing groups, run these commands in the following order.

    • To delete all closed nonpaying child accounts at different levels in a hierarchy:

      pin_del_closed_accts -subord -leaf
pin_del_closed_accts -subord

    • To delete member accounts in sharing groups:

      pin_del_closed_accts -members_sharing

    • To delete paying child accounts at different levels in a hierarchy:

      pin_del_closed_accts -members_billing

      Note:

      Run this command for each paying account in a hierarchy. For example, if there are two paying accounts in a hierarchy, run this command twice to delete both paying accounts.

  3. Run the following command, which deletes all remaining closed accounts, including the top-level parent account in the hierarchy:

    pin_del_closed_accts

  4. If you want to delete specific closed accounts by using a file, run the following command:

    Note:

    Run the pin_del_closed_accts -file command only if you want to delete specific accounts. Ensure you use this command with care. 

    pin_del_closed_accts -file file_name

    For example:

    pin_del_closed_accts  -file  closed_accts_list.txt

    The utility deletes the accounts specified in the input file. You must provide the account details in flist format. For example:

    0 PIN_FLD_RESULTS       ARRAY [0] allocated 20, used 1
1     PIN_FLD_POID       POID [0] 0.0.0.1 /account 123 0
0 PIN_FLD_RESULTS       ARRAY [1] allocated 20, used 1
1     PIN_FLD_POID       POID [0] 0.0.0.1 /account 234 0

For more information about the utility and its parameters, see "pin_del_closed_accts".

pin_del_closed_accts

Use the pin_del_closed_accts utility to delete closed accounts from BRM. This utility calls the PCM_OP_CUST_DELETE_ACCT opcode to delete the closed accounts that are older than the specified retention period. For specifying the retention period, see "Specifying Retention Period for Closed Accounts".

To connect to the BRM database, the pin_del_closed_accts utility needs a configuration file in the directory from which you run the utility. See the discussion about connecting BRM utilities in BRM System Administrator's Guide.

Location

BRM_home/bin

Syntax

pin_del_closed_accts  -subord [-leaf]
                      -members_sharing
                      -members_billing
                      -file file_name
                      [-verbose] [-help]

Parameters

  • subord [-leaf]: Deletes the closed nonpaying child accounts at the bottom of the hierarchy.

  • subord: Deletes the remaining closed nonpaying child accounts which are parents of other child accounts at the different levels of the hierarchy. Running the pin_del_closed_accts utility with this parameter does not delete the top-level parent account in the hierarchy.

    You need to run the pin_del_closed_accts utility without any parameters after deleting all the paying and nonpaying child accounts at different levels in the hierarchy to delete the top-level parent account.

  • members_sharing: Deletes the member accounts of the sharing groups; for example, discount and charge sharing groups.

  • members_billing: Deletes the closed paying accounts in the hierarchy that are used for billing purposes.

  • file file_name: Deletes the accounts specified in the input file. The file_name is the name and location of the file that contains the list of accounts for deletion. The account details in this file must be in the flist format.

    Note:

    Running the pin_del_closed_accts utility with this parameter deletes all the accounts specified in the input file even if the accounts are not older than the retention period. When you use this parameter, ensure that the input file contains only the closed accounts that need to be deleted.

  • verbose: Displays information about successful or failed processing as the utility runs.

  • help: Displays the syntax and parameters for this utility.

Results

The pin_del_closed_accts utility notifies you when it successfully deletes the closed accounts and the associated customer data.

If the pin_del_closed_accts utility does not notify you that it was successful, look in the utility log file (default.pinlog) to find any errors. The log file is either in the directory from which the utility was started or in a directory specified in the configuration file.

After you have resolved the errors, you can delete the closed accounts by running the pin_del_closed_accts utility again.

Enhanced Security for Root Wallet

When you run the pin_crypt_app utility with the -genrootkey parameter, BRM now prompts for the root wallet password. This ensures that the root wallet is secured.

For more information, see the discussion about modifying the root encryption key in BRM Developer's Guide.

Support for Rolling Back the BRM Patch Set

BRM now allows you to roll back a BRM patch set. For example, if you experience issues after installing BRM 12.0 Patch Set 1, you can roll back BRM to 12.0.

For more information, see the discussion about rolling back a patch set in BRM 12.0 Patch Set Installation Guide.

BRM 12.0 Is Now Certified with Mozilla Firefox 58.0

Currently, BRM 12.0 is certified with Mozilla Firefox 54.0.1. With this patch, BRM 12.0 is certified with Mozilla Firefox 58.0.

For more information, see BRM Compatibility Matrix.

BRM 12.0 Is Now Certified with Perl 5.28.0

Currently, BRM 12.0 is certified with Perl 5.24.0. With this patch, BRM 12.0 is certified with Perl 5.28.0.

For more information, see BRM Compatibility Matrix.

BRM 12.0 Is Now Certified with Paymentech 120 Byte Batch Version 3.0.0 R 12.4 and Online Authorization Version 7.4 R12.4

Currently, BRM 12.0 is certified with Paymentech 120 Byte Batch Version 3.0.0 R 4.2 and Paymentech Online Authorization Version 7.4 R5. With this patch, BRM 12.0 is certified with Paymentech 120 Byte Batch Version 3.0.0 R 12.4 and Paymentech Online Authorization Version 7.4 R12.4.

For more information, see BRM Compatibility Matrix.

BRM 12.0 Is Now Certified with Tomcat 8.5.32

Currently, BRM 12.0 is certified with Tomcat version 8.5.16. With this patch, BRM 12.0 is certified with Tomcat version 8.5.32.

For more information, see BRM Compatibility Matrix.