In previous versions, the BRM Web Services Manager was deployed into an external server, such as Oracle WebLogic Server or Tomcat. Now, a standalone version of the Web Services Manager is available. This provides the following benefits:

• Simplifies deployment and customization.
• Improves performance and execution times.
• Removes dependency on external applications and total cost of ownership.
• Provides improved testing capabilities.

Support has not been removed for the older type of Web Services Manager, so you can continue to deploy it into WebLogic Server or Tomcat if that best meets your business needs. Support for this option may be removed in future releases, however.

For more information, see BRM Web Services Manager.

You can now associate general ledger IDs (G/L IDs) with tax codes in PDC. For more information, see "Creating Tax Codes" in PDC Online Help and "Creating Tax Codes" in BRM Calculating Taxes.

The pin_cycle_fees utility has been enhanced to support the splitting of events for backdated operations. When the backdate window includes multiple billing cycles, the pin_cycle_fees utility splits the events by cycle and applies the charges individually for each cycle based on the backdated activity.

For more information, see "Prorating Cycle-Forward Fees and Canceling Charge Offers By Using the pin_cycle_fees Utility" and "pin_cycle_fees" in BRM Configuring and Running Billing.

You can now modify or validate the maximum length of an opcode flist field for an existing opcode or create a loadable opcode specification for a custom opcode using the generate_config_xml_from_opcode_spec.py script.

For more information, see "Modifying the Maximum Length of an Opcode Flist Field" in BRM Developer's Guide.

BRM now allows you to change the billing day of month (DOM) for the parent accounts and child accounts asynchronously by performing parallel updates for all accounts in a large hierarchy. This avoids locking the parent account, which restricted any other operations during the update process.

For information, see "About Changing the Billing Day of Month for Large Hierarchies" in BRM Configuring and Running Billing.

Before generating a final invoice, you can now create a proforma invoice, which is an an initial, optional step in the billing process. It is similar to final billing, however, it does not finalize the bill. It creates a pre-invoice that your customers can review for accuracy before the final bill and invoice are generated. Afterward, your customers can manually accept or reject the proforma invoice. For more information, see "Generating Proforma Invoices" in BRM Designing and Generating Invoices.

You can now map business events to database queues based on the value of a new TAG token and specify to publish business events to multiple database queues. For more information, see "Mapping Business Events to Database Queues" in BRM System Administrator's Guide.

You can also have multiple definitions for the same publisher, but with different output format. For more information, see "Publisher Definitions" in BRM Developer's Guide.

The following new attributes have been introduced to define events and elements:

1. PcmOpFlag: Specifies an optional field that stores the flag value to run the PCM_OP_READ_FLDS or PCM_OP_READ_OBJ opcode.

2. ReadFlds: Specifies to read one or more fields in an object from the transaction cache or, if it is not in the cache, from the BRM database.

3. ElemId: Specifies to read a specific array element.

4. ReadObj: Specifies to read an entire object from the transaction cache or, if it is not in the cache, from the BRM database.

5. ReadValFrom: Specifies an optional attribute that retrieves an object POID (ObjPoid) from a specific array in the incoming opcode flist.

For more information, see "Syntax of Elements and Attributes " in BRM Developer's Guide.

You can now configure individual C-based BRM applications to rotate their pinlog files. The files can be rotated based on:

• The length of time the pinlog file has been open, such as every 3 days at 05:00

• The pinlog file’s size, such as 50 MB

You can also combine the rotation schemes (use time and file size to rotate files), such as 50 MB files open for 3 days closed at 05:00.

For more information, see "Rotating Log Files for C/C++-Based Applications" in BRM System Administrator's Guide.

The following BRM REST API endpoints have been updated in the 15.1 release:

• The Get Payment Methods and Get Payment Methods for an Account endpoints now support the name and invoice.name query parameters

• The Get an Applied Customer Billing Rate by ID and Get Applied Customer Billing Rates endpoints now support the bill.id query parameter

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

You can now improve the performance of rolling up balances from sharing group members to the owner's bill unit by doing the following:

• Enabling the sharing roll-up functionality. You enable this functionality when you create or modify a wholesale sharing group.

• Running the new pin_rollup_sharing_balances utility. This multithreaded utility launches a separate thread to roll up each member’s noncurrency balance to the owner.

Previously, the owner of the sharing group was locked during each member's billing, which led to contentions. Now, the owner is not locked during member billing, and the roll up of balances from members to the owner happens during owner billing.

For more information, see "Rolling Up Balances from Members to Owners for Wholesale Sharing Groups" in BRM Configuring and Running Billing.

You can now create contracts regardless of the revenue recognition scheme your BRM system uses. In previous releases, you could create contracts only if deliverable-based revenue recognition was enabled. Deliverable-based revenue recognition aligns with the ASC 606 and IFRS 15 accounting standards. For information, see "Managing Customer Contracts" in BRM Managing Customers.

In addition, contract management now supports the following operations:

• Performing backdated operations

• Using multiple G/L segments

• Using Conversion Manager

• Performing rerating

• Using the Web Services Manager opcodes

• Performing accounts receivable (A/R) operations, such as adjustments

BRM now supports the following contract management enhancements:

• Specifying a minimum contract length: You can now specify a minimum length for a contract with corresponding penalty charges for early cancellation. If customers cancel early, they must pay the remaining balance up to the minimum contract length. See "About Penalty Fees" in PDC Creating Product Offerings for more information.

  For example, assume a subscription term has a 1-year commitment period, a minimum contract length of 4 months, and a $50 monthly fee. Customers would be charged $50 for each month remaining in the 4-month minimum contract length. A customer canceling after 1 month would pay $150, and a customer canceling after 3 months would pay $50. A customer canceling after 6 months would pay $0 because they already paid the 4-month minimum.

• Applying penalty fees: The penalty fee can now consist of an early termination fee, the remaining contract balance, or both. See "About Penalty Fees" in PDC Creating Product Offerings for more information.

  In previous releases, the penalty fee could be an early termination fee or the contract balance. You could not apply both.

• Extending the /subscriber_contract storable class: You can now extend the /subscriber_contract storable class to store additional fields. To do so, see "Extending Subscriber Contracts" in BRM Opcode Guide.

• Customizing how penalty fees are applied during cancellation: You can use the new PCM_OP_CONTRACT_POL_CANCEL_CONTRACT policy opcode to customize how penalty fees are calculated and applied during the contract cancellation process.

When calling the PUT flist management macros, you can now set compile-time flags in your custom code's Makefile. The compile-time flags specify to automatically set source pointers to NULL during PUT operations and assign a NULL value to an flist or object after the macro call, preventing it from being destroyed in the future.

Table 5-1 lists each flist management macro, its compile-time flag, and what happens after the macro is called with the flag.

For information, see "Using Compile-Time Flags to Avoid Errors in Flists" in BRM Developer's Guide.

You can generate invoice documents for invoices that meet your custom criteria, such as only for Canadian customers with an invoice delivery type of email. You specify the criteria using a list of key-value pairs, which correspond to parameters you add to the data model defining the requirements for selecting invoices.

For information, see "Generating Invoice Documents Based on Custom Criteria" in BRM Designing and Generating Invoices.

BRM can now calculate the tax settlement details when a dispute or settlement is performed for a bill, item, or event, allowing you to know how much tax is being settled per jurisdiction.

You can configure BRM to segregate the tax amount for each dispute and settlement based on the tax code and tax jurisdiction by setting the TaxReturnJuris business parameter to itemize. By default, the parameter is set to summary, which specifies to segregate the tax amount based on the tax code. For information, see "Configuring Itemized Taxation for A/R and Payments" in BRM Calculating Taxes.

In addition, the PCM_OP_GET_ITEM_DETAILS opcode has been enhanced to show the settled tax and settled taxed amounts based on the tax code and jurisdiction level for each item. For information, see "About the Item Data Retrieved" in BRM Opcode Guide.

When setting up your system to send messages to customers through an external application, you can now configure BRM to trigger notifications before an event occurs, after an event occurs, or both. This applies to the following:

• Balance elements: You can configure any currency or noncurrency balance element to trigger notification events when its validity period is about to expire, when it has already expired without new funds being added, or for both.

• Product expiration: You can configure a subscription to trigger notification events before the subscription expires, after the subscription expires, or for both.

• Subscription renewals: You can configure a subscription to trigger notification events before it is due for renewal, after it is past due for renewal, or for both.

In previous releases, in-advance and post-expiration notifications were either both enabled or both disabled.

For information, see "Configuring BRM to Send Notifications to External Notification Applications" in BRM Managing Customers.

In wholesale bill unit hierarchies, you can now trigger trial billing for:

Prior to this release, trial billing had to be performed for all child accounts and then for all parent accounts.

For information, see "Running Trial Billing" in BRM Configuring and Running Billing.

The pin_cycle_fees utility now processes only the charge offers for which it is called. Earlier, pin_cycle_fees used to process all charge offers, even when it was called for a specific charge offer. For more information, see "Canceling an Account’s Charge Offer Using pin_cycle_fees Utility" in BRM Configuring and Running Billing.

All former BRM 32-bit components, such as the Connection Manager (CM), are now 64-bit components. In addition, you can now use all timestamps representing a date after January 19, 2038.

If you are upgrading to BRM 15.0, you need to recompile any BRM customizations, such as policy opcodes, as 64-bit extensions. For more information, see "Migrating Custom Code to a 64-bit Environment" in BRM Installation Guide.

The following upgrade paths to the 15.0 release are supported:

• BRM 12.0 to BRM 15.0

• Any BRM 12.0 Patch Set to BRM 15.0

• ECE 12.0 to ECE 15.0

• Any ECE 12.0 Patch Set to ECE 15.0

The upgrade paths support the following on-premise and cloud native versions:

• On-premise versions of BRM with an ECE charging engine to a 15.0 version

• On-premise versions of BRM with real-time and batch rating engines to a 15.0 version

• BRM cloud native with an ECE charging engine to a 15.0 version

• BRM cloud native with real-time and batch rating engines to a 15.0 version

• On-premise versions of BRM with real-time and batch rating engines to BRM cloud native 15.0 with real-time and batch rating engines

Previously, customers could extend the validity of a balance by purchasing a product or discount again, and the new balance was added to the existing balance. Now, you can track the new and existing balances separately, with separate validity dates.

You can use two new options with the loadpricelist utility. When creating deals in your XML file, you set the value for the <purchase_mode> element under the <deal_product> or <deal_discount> element. You can set the purchase mode to:

• 4: Longest date. Extends the old subscription with a separate balance, setting the validity end date to whichever is later, the new or existing validity.
• 5: Cumulative validity. Extends the old subscription with a separate balance, setting the validity end date by adding the new validity to what remains of the old validity.

For example, on June 1, a customer purchases a deal that grants 3GB of data, is valid for seven days, and has a grace period of 4 days. On June 3, after using 1GB, they purchased the deal again. With both options, the new 3GB balance is added to a new balance group, separate from the remaining 2GB in the old balance group.

With option 4, the new balance is valid starting on June 3, and BRM compares the validity periods of the old and new balances to set the validity end date for the new balance to the later of the two end dates, June 10. The old balance retains the original validity dates.

With option 5, the new balance is valid starting on June 8. BRM adds what remains of the validity period of the old balance to the new balance to set the validity end date for the new balance to June 15. The old balance retains the original validity dates.

For information, see "Purchasing the Same Product or Discount Multiple Times" in BRM Setting Up Pipeline Pricing.

The BRM REST Services Manager API now supports the following order bill fulfillment operations:

• Purchasing a product offering, such as a bundled offer, charge offer, or discount offer

• Suspending a purchased service

• Resuming a suspended service

• Terminating a purchased product offering

You can also specify to cancel a customer's service in the future.

If you support two-phase billing, you can specify whether to purchase an offer with the start date set to 365 days in the future or to the actual activation date.

You implement order bill fulfillment using the new Perform Billing Fulfillment operation in the BRM REST Services Manager API. For more information, see REST Services Manager API for Billing and Revenue Management.

The order bill fulfillment operations also support extending the framework by adding attributes to the request payload.

The BRM real-time and batch rating engines now support SSL communication with the BRM Connection Manager (CM), improving the security among all BRM components.

For information, see "Enabling SSL/TLS in Real-Time Pipeline" in BRM System Administrator's Guide.

Previously, when rounding to midnight was disabled, and a discount was purchased after midnight, the discount would not be applied to the entire day. For example, a discount purchased at 15:00 on June 1 would apply only from 15:00 through 24:00 on June 1. Now, you can specify to apply the discount to the entire day even when rounding to midnight is disabled. That is, a discount purchased at 15:00 would apply from 00:00 through 24:00 on June 1.

You can use the new option with the loadpricelist utility. When creating discounts in your XML file, you set the value for the <discount_validity_rounding> element under the <discount> element. You can set <discount_validity_rounding> to one of the following:

• ON: Sets the discount start time to the time of purchase.

• OFF: Sets the discount start time to midnight (00:00:00) of the day the discount is purchased.

• NOT_SET: Uses the systemwide setting in the /config/business_profile object. This is the default.

For information, see "Setting Discount Validity Rounding" in BRM Setting Up Pipeline Pricing.

Previously, timeouts in BRM terminated only the client side of the operation. The database operation was rolled back only after the transaction was completed.

BRM client applications contain a new parameter for setting the maximum timeout of BRM transactions. If a timeout occurs, the client side of the operation is terminated, and the transaction is not committed to the database. This guarantees that transactions are not committed when timeouts occur and writes to the database do not occur at any point during the transaction.

For information, see "Setting a Timeout Value for Requests Sent to the CM" in BRM System Administrator's Guide.

Previously, BRM used the Synchronization Queue Data Manager to synchronize pricing data, such as charge offers, discount offers, and chargeshare offers, with external customer relationship management (CRM) applications. In the 15.0 release, Synchronization Queue Data Manager has been obsoleted.

To improve performance, BRM now uses the Oracle Data Manager (DM) to synchronize data between BRM and your external CRM. Oracle DM sends pricing data in business events to Oracle Advanced Queuing (AQ) database queues in the BRM database, where your external CRM can retrieve it. For information, see "Synchronizing Pricing Data between the BRM Database and External CRMs" in BRM System Administrator's Guide.

The BRM 15.0 installation includes scripts and configuration files to help you create and configure the AQ database queues.

Previously, BRM thick client applications, such as Customer Center and Pricing Center, handled all authorization with BRM. In addition, command-line utilities could not manage fine-grained authorization because they are part of the BRM server and have access to all opcodes and storable classes.

To improve security, the CM layer now also performs authorization. Authorization in the CM is based on opcodes the user is allowed to run and storable classes the user is allowed to read or update. The list of opcodes and storable classes users can access are defined in roles.

For more information, see "Managing Login Names and Passwords" in BRM System Administrator's Guide.

BRM 15.0 includes a new POID generation logic that limits the number of times data needs to be retrieved from the database, which improves performance.

In BRM 15.0, the multischema installation process has been simplified, reducing the overall time to set up your system.

Previously, the process for creating the database schemas was a two-step process. First, it made the primary and secondary schemas with all tables and snapshots. Second, it dropped the tables and snapshots from the secondary schemas and replaced them with views.

Now, the BRM multischema installation creates the database schemas in one step. It creates the primary schema with all tables and snapshots and the secondary schemas with views.

See "Installing a Multischema System" in BRM Installation Guide for more information.

Previously, you could dynamically override pricing at purchase time with no validation. Now, the overrides you can use at purchase time are restricted and validated by price tags created as setup components.

You configure price tags as setup components in PDC and publish them to BRM in changesets. The price tags are stored in the /config/price_tags object.

The rules configured in the setup components determine which price tags are valid for a resource and which values can be used at purchase time. You can restrict price tags to certain resources, resource units, and services. You can restrict the values that can be used to a list or range of values.

For example, you could create the following price tag setup components:

• Applicable to the minute unit of free minutes resources of TelcoGSM and Telephony services, with permitted values of 10 and 20.
• Applicable to any unit of US Dollar resources of TelcoGSM services, with permitted values between 100 and 200.
• Applicable to the byte unit Euro resources of TelcoGSM services, with no restrictions on the value.

At purchase time, you retrieve the list of price tags and valid values for a specified resource, service, or product using the PCM_OP_SUBSCRIPTION_GET_PRICE_TAGS opcode. The opcode output includes the valid values you can use to override the price.

You can also see the details for price tags configured for products using the PCM_OP_PRICE_GET_PRODUCT_INFO opcode or the Get Offer Details endpoint of the Billing Care REST API.

For information, see "Configuring Dynamic Charging" in PDC Creating Product Offerings.

Conversion Manager supports all features added between the BRM 12.0 and BRM 15.0 releases, such as loan management and taxation exemptions.